컨텍스트 윈도우 관리와 요약의 함정

긴 세션을 도는 에이전트는 언젠가 컨텍스트 윈도우(context window)의 끝에 닿습니다. 그때 가장 흔한 대응이 "오래된 대화를 요약해서 줄이자"인데, 이 요약이 조용한 장애의 출발점이 되곤 합니다. 요약이 무엇을 지우는지, 그리고 더 안전한 컴팩션(compaction)은 어떻게 설계하는지 살펴봅니다.

컨텍스트 윈도우는 왜 모자라게 되는가

에이전트 세션에서 컨텍스트를 차지하는 것은 대화만이 아닙니다.

• 시스템 프롬프트와 툴 정의 (수천에서 수만 토큰)
• 툴 호출 결과. 특히 파일 내용, 검색 결과, 로그 원문
• 쌓여 가는 대화 이력

이 가운데 가장 빨리 불어나는 것은 툴 결과입니다. 파일 하나를 통째로 읽으면 그 자리에서 수천 토큰이 사라집니다. 그래서 컨텍스트 관리의 첫 원칙은 요약이 아니라 애초에 덜 넣는 것입니다. 파일 전체 대신 필요한 범위만 읽고, 검색 결과는 위에서 몇 건만 가져오는 식입니다.

요약의 함정, 무엇이 지워지는가

요약은 "중요해 보이는 것"을 남기고 나머지를 버립니다. 문제는 무엇이 중요했는지를 나중에야 알게 되는 경우가 많다는 점입니다.

실제로 자주 생기는 손실은 세 종류입니다.

1. 정확한 식별자: 파일 경로, 커밋 해시, 오류 코드가 "설정 파일에 문제가 있었음" 같은 서술로 뭉개집니다. 다음 단계에서 그 파일을 다시 찾으려면 탐색을 처음부터 되풀이해야 합니다.
2. 부정 정보: "방법 A는 해 봤는데 실패했다"는 기록이 사라지면 에이전트는 A를 또 시도합니다. 같은 실패를 반복하는 루프의 전형적인 원인입니다.
3. 단서와 예외: 원문에 있던 "단, 프로덕션에서는 이 값을 쓰면 안 됨" 같은 한 줄이 요약에서 떨어져 나갑니다. 감사나 조사 작업에서 요약본에 기대면 안 되는 이유입니다.

안전한 컴팩션 설계

요약을 아예 쓰지 말라는 뜻은 아닙니다. 무엇은 요약해도 되고 무엇은 안 되는지를 가르는 것이 핵심입니다.

이를 실제로 구현하는 실용적인 방법이 구조화된 상태 파일입니다. 대화를 줄이기 전에 핵심 상태를 파일로 내려 두는 것입니다.

# 세션 상태
## 결정 사항
- DB는 PostgreSQL 유지 (마이그레이션 비용 때문)
## 실패한 시도
- `pnpm build` 캐시 삭제 → 효과 없음
## 핵심 경로
- 설정: src/config/production.ts

이렇게 해 두면 대화 이력이 줄어도 에이전트가 상태 파일을 다시 읽어 정확한 식별자와 결정 이력을 되찾을 수 있습니다.

실무 체크리스트

• 툴 결과를 넣기 전에 "이걸 원문 그대로 다시 볼 일이 있는가"를 먼저 묻습니다. 있다면 파일로 저장하고 경로만 컨텍스트에 남깁니다.
• 컴팩션 직전에 결정 사항, 실패 목록, 핵심 경로를 구조화해 기록합니다.
• 요약본으로 감사나 디버깅을 하지 않습니다. 단서는 원문의 구석에 있습니다.
• 긴 작업은 처음부터 단계를 나눠, 각 단계가 독립된 컨텍스트에서 돌게 설계합니다. 그러면 컴팩션 자체가 덜 필요해집니다.

컨텍스트 관리의 목표는 많이 담는 것이 아닙니다. 다음 결정에 필요한 정보가 정확한 모양으로 남아 있게 하는 것입니다. 요약은 도구일 뿐이고, 무엇을 요약하면 안 되는지 아는 것이 실력입니다.