지시와 맥락을 설계하는 법 — 모델에게 무엇을 언제 건네는가

6.1 컨텍스트가 무너지기 전에 — 맥락 관리와 정리

긴 대화나 에이전트 실행에서 가장 흔한 실패는 컨텍스트 윈도우(context window, 모델이 한 번에 참고하는 정보의 범위)가 불필요한 내용으로 채워지는 것입니다. 대화가 길어질수록 원래 목표에서 답이 서서히 벗어나는 컨텍스트 드리프트(context drift)와, 오래된 도구 결과가 쌓여 정작 중요한 지시가 묻히는 컨텍스트 블로트(context bloat)가 생깁니다. 이를 막는 두 축이 도구 출력 정리(pruning, 더 이상 쓰지 않는 도구 응답을 걷어 내기)와 컴팩션(compaction, 지난 대화를 요약해 압축하기)입니다. 무엇을 남기고 무엇을 버릴지 정하는 것이 설계자의 몫입니다.

6.2 한 창에 다 넣지 않는다 — 서브에이전트로 맥락 나누기

복잡한 작업을 하나의 긴 프롬프트에 몰아넣으면 각 하위 작업의 맥락이 서로 섞여 품질이 떨어집니다. 컨텍스트 격리(context isolation)는 작업을 여러 단계로 쪼개고, 각 단계를 독립된 대화나 서브에이전트(subagent, 특정 하위 작업만 맡아 자기 컨텍스트에서 처리하는 별도 에이전트)에 맡기는 설계입니다. 예컨대 검색 담당과 요약 담당을 분리하면, 검색 과정의 장황한 중간 결과가 요약 단계의 판단을 흐리지 않습니다. 오케스트레이터(orchestrator, 여러 서브에이전트를 조율하는 상위 흐름)는 각 단계의 정제된 최종 결과만 넘겨받아 다음으로 잇습니다.

6.3 무엇을, 어디에, 어떻게 — 프롬프트의 뼈대

좋은 프롬프트의 첫째 조건은 지시의 명확성입니다. 모호한 형용사 대신 검증 가능한 기준으로 원하는 바를 적습니다. 반복되는 규칙·역할·톤은 시스템 프롬프트(system prompt, 대화 전체에 걸쳐 모델의 행동을 규정하는 상위 지시)에 두고, 이번 요청의 구체 입력만 사용자 메시지에 둡니다. 형식이나 판단 기준이 말로 설명하기 어렵다면 퓨샷 예시(few-shot examples, 원하는 입력–출력 쌍 몇 개를 미리 보여 주기)로 보여 주는 편이 훨씬 정확합니다. 끝으로 출력 제약(output constraints, 길이·형식·허용 값의 범위를 미리 규정하기)을 걸어 후속 처리가 편한 형태로 답의 폭을 좁힙니다.

6.4 한 번에 완성되지 않는다 — 다듬기와 입력 방어

프롬프트는 한 번에 완성되지 않습니다. 실패 사례를 모아 어디서 어긋났는지 보고 지시를 조금씩 고쳐 다시 시험하는 반복 개선(iterative refinement)이 정석입니다. 이때 한 번에 여러 곳을 바꾸면 무엇이 효과였는지 알 수 없으니, 변경은 작게 나눠 검증합니다. 또 하나 놓치기 쉬운 축이 입력 새니타이징(input sanitization, 사용자·외부에서 들어온 텍스트를 지시로 오인하지 않게 걸러 내기)입니다. 외부 문서에 '이전 지시를 무시하라' 같은 문장이 섞여 드는 프롬프트 인젝션(prompt injection, 입력에 숨긴 명령으로 모델을 조종하려는 공격)을 막으려면, 데이터와 지시의 경계를 분명히 표시하고 신뢰 구간을 나눕니다.

6.5 확신에 찬 답을 그대로 믿지 않는다 — 출력 처리와 검증

모델의 답은 자연어이므로, 코드가 곧바로 소비하려면 구조화된 출력(structured output, JSON처럼 미리 약속한 형식으로 답을 받기)으로 받아 내는 편이 안전합니다. 다만 형식을 요청했다고 늘 그 형식으로 온다는 보장은 없습니다. 그래서 받은 응답이 약속한 스키마(schema, 필드 이름·타입·필수 여부를 정한 규격)에 맞는지 검증하고, 형식이 어긋나도 프로그램이 멈추지 않게 방어적 파싱(defensive parsing, 빠진 값·엉뚱한 타입을 미리 가정하고 처리)을 해 둡니다. 무엇보다 모델은 틀린 내용도 확신에 찬 말투로 답합니다. 말투의 자신감을 사실의 근거로 오해하지 않는 회의가 마지막 방어선입니다.

! 흔한 함정

• 프롬프트가 잘 안 되면 더 큰 모델로 바꾸면 된다고 여기는 것 — 원인은 대개 모델 크기가 아니라 지시와 맥락의 설계에 있습니다.
• 컨텍스트 윈도우가 넓으니 대화를 계속 쌓아도 괜찮다는 오해 — 창이 넓어도 오래된 내용이 쌓이면 답은 흐려지고 비용과 지연은 함께 늘어납니다.
• 출력 형식을 지정하기만 하면 언제나 그 형식으로 온다는 가정 — 형식 지정은 요청일 뿐이며, 받은 뒤의 검증과 방어적 파싱이 없으면 언젠가 깨집니다.
• 퓨샷 예시는 많을수록 좋다는 생각 — 예시가 편향되거나 서로 어긋나면 오히려 모델을 잘못된 패턴으로 이끕니다. 대표성 있는 소수가 낫습니다.