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

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

컨텍스트 윈도우는 왜 부족해지는가

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

• 시스템 프롬프트와 툴 정의 (수천~수만 토큰)
• 툴 호출 결과 — 특히 파일 내용, 검색 결과, 로그 원문
• 누적된 대화 이력

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

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

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

실제로 자주 발생하는 손실 유형은 이렇습니다.

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

안전한 컴팩션 설계

요약을 아예 쓰지 말라는 뜻이 아닙니다. 무엇을 요약해도 되는지 구분하는 것이 핵심입니다.

대상	컴팩션 방식
오래된 잡담·중간 사고 과정	요약 가능
결정 사항과 그 이유	구조화 보존 (요약 금지)
파일 경로·해시·식별자	원문 그대로 보존
시도했다가 실패한 접근	목록으로 명시 보존
툴 원문 결과	재조회 가능하면 참조로 대체

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

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

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

실무 체크리스트

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

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