이 장에서 배우는 것 창이 찼을 때 실제로 벌어지는 일, 알아채는 신호, 그리고 실무에서 쓰는 대처법 네 가지.
창이 한도에 닿으면 오래된 것부터 밀려납니다.
문제는 대개 앞쪽에 중요한 게 있다는 것입니다. 역할 설정, 제약 조건, 원래 목표 — 전부 처음에 적습니다. 그리고 그게 먼저 사라집니다.
| 증상 | 실제로는 |
|---|---|
| 처음에 정한 말투가 달라짐 | 말투 지시가 밀려남 |
| 하지 말라고 한 걸 함 | 제약이 밀려남 |
| 이미 정한 걸 다시 물어봄 | 그 결정이 밀려남 |
| 원래 목표에서 벗어남 | 목표가 밀려남 |
| 답이 점점 일반적이 됨 | 구체적 맥락이 밀려남 |
"모델의 답변 품질이 급격히 떨어졌다"고 느끼는 순간의 상당수가 이것입니다. 모델 자체의 성능이 변한 것이 아니라, 모델이 참고하는 컨텍스트 창이 달라졌기 때문입니다.
에이전트는 한 번의 요청 안에서 수십 회전을 돕니다. 매 회전의 도구 결과가 컨텍스트에 쌓입니다.
HyperTeamsgraph TD
A["1회전: 목표 + 도구결과 1"] --> B["5회전: 목표 + 결과 1~5"]
B --> C["15회전: 결과 6~15<br/>목표가 밀려남"]
C --> D["원래 뭘 하려던 건지 흐려짐"]조회 결과가 크면 (예: 표 500행) 몇 회전 만에 찹니다. 그래서 실무에서는 도구 결과를 통째로 넣지 않고 필요한 부분만 넣도록 잘라냅니다.
하나의 대화에 열 가지 일을 담지 말고 각각 시작합니다.
앞 단계의 과정은 필요 없고 결과만 필요한 경우가 대부분입니다. 과정을 계속 끌고 가면 자리만 차지합니다.
긴 작업 중간에 제약을 재확인시킵니다.
한 번 적고 끝내지 마세요. 앞에 적은 건 밀려났을 수 있습니다.
500행 표를 통째로 넣는 대신 필요한 부분만 넣습니다. 시스템을 만들 때는 이걸 자동으로 처리하도록 설계합니다.
긴 작업이라면 중간에 이렇게 합니다.
그 요약을 들고 새 대화를 시작합니다. 지저분한 과정은 버리고 결론만 가져가는 것입니다.
이런 말이 나오면 창을 의심하세요.
모델을 바꾸거나 프롬프트를 고치기 전에 새 대화부터 시도해보세요. 상당수가 그것으로 해결됩니다.
이 성질은 개인 요령에서 끝나지 않습니다. 업무를 어떻게 쪼갤지에 영향을 줍니다.
이 원칙을 방법론 수준으로 밀고 간 것이 마이크로 스프린트입니다. 작업을 원자 단위로 쪼개는 이유 중 하나가 여기 있습니다.
1. 창이 찼을 때 왜 하필 중요한 게 사라집니까?
오래된 것부터 밀려나는데, 중요한 건 대개 앞쪽에 있기 때문입니다. 역할 설정, 제약 조건, 원래 목표는 전부 처음에 적고 그게 먼저 사라집니다.
2. 에이전트에서 이 문제가 더 심각한 이유는?
한 요청 안에서 수십 회전을 돌며 매 회전의 도구 결과가 쌓이기 때문입니다. 조회 결과가 크면 몇 회전 만에 차고, 원래 목표가 밀려나 무엇을 하려던 건지 흐려집니다.
3. "모델의 답변 능력이 저하된 것 같다"고 느낄 때 가장 먼저 해볼 것은?
새 대화로 시작해보는 것입니다. 모델을 바꾸거나 프롬프트를 고치기 전에, 지금까지의 결정을 요약해서 새 대화로 옮기면 상당수가 해결됩니다.
밀려나는 순간을 직접 만들어봅니다. 30분입니다 → 컨텍스트를 일부러 넘겨보기
[시스템 지시: 이 폴더 밖은 건드리지 말 것] ← 가장 먼저 밀려남[대화 1][대화 2]...[대화 47][대화 48] ← 남음✗ 대화 하나에서: 자료 조사 → 분석 → 보고서 작성 → 검토 → 발표자료✓ 각각 새 대화로. 앞 단계 결과만 요약해서 다음에 넘김(작업 20턴쯤 진행한 뒤)다시 확인: 결제 로직은 건드리지 말고, 화면 메시지만 수정하는 것입니다.이 조건에서 다음 파일을 봐주세요.지금까지의 결정 사항을 목록으로 정리해줘.다음 단계에서 알아야 할 것만.