LLM 에이전트의 컨텍스트 윈도우: 무엇이 들어가고 에이전트가 규칙을 잊는 이유

LLM 컨텍스트 윈도우란 무엇인가

LLM의 컨텍스트 윈도우는 모델이 다음 응답을 생성할 때 입력으로 받는 전체 텍스트입니다. 모델에게는 사람이 가진 의미의 기억이 없습니다. 모델이 지금 여러분의 작업에 대해 "아는" 모든 것은 이 윈도우 안에 있습니다. 윈도우에 없는 것은 모델에게 존재하지 않습니다.

윈도우 크기는 토큰, 즉 단어의 조각으로 측정합니다. 한국어 텍스트는 영어보다 토큰을 더 많이 쓰는 경향이 있어서, 같은 지침도 보통 더 많은 토큰을 차지합니다. 최신 모델의 윈도우는 수십만 토큰에 이르므로 모든 것을 담기에 충분해 보입니다. 실제로는 에이전트의 공간이 예상보다 빨리 소진되고, 성능은 그보다 더 일찍 떨어지기 시작합니다.

에이전트의 컨텍스트 윈도우에 무엇이 들어가나

코딩 에이전트가 정보를 얻는 원천은 세 가지뿐입니다. 작업을 설명하는 시스템 프롬프트, 에이전트가 읽은 파일의 내용, 에이전트가 호출한 도구의 출력입니다. 이 셋은 같은 윈도우에 들어가서 공간을 두고 경쟁합니다.

핵심은 이 중 아무것도 저절로 사라지지 않는다는 점입니다. 스무 단계 전에 필요했던 실패한 테스트 로그도 여전히 윈도우에 남아, 지금 단계의 주의력을 빼앗습니다. 긴 세션은 계속 커지는 더미와 같아서, 그 안에서 바늘 하나를 찾기가 점점 어려워집니다.

긴 세션에서 에이전트가 규칙을 잊는 이유

자주 듣는 불만이 있습니다. 세션 초반에는 에이전트가 CLAUDE.md의 규칙을 꼼꼼히 지키다가, 한 시간쯤 지나면 규칙을 어기기 시작합니다. 글자 그대로 "잊은" 것은 아닙니다. 규칙의 텍스트는 아직 윈도우 안에 있습니다. 문제는 모델이 긴 텍스트 전체에 주의를 어떻게 나누는지에 있습니다.

Lost in the middle

Liu 등이 2023년에 발표한 연구는, 언어 모델이 긴 컨텍스트의 처음과 끝에 있는 정보는 잘 활용하지만 중간에 있는 정보는 상대적으로 잘 활용하지 못한다는 것을 보여 주었습니다. 지침 파일은 세션 시작에 읽히지만, 대화가 진행되면서 위와 아래에 텍스트가 계속 쌓입니다. 처음에는 눈에 잘 띄던 규칙이 점차 모델이 가장 잘 보지 못하는 영역으로 밀려 납니다.

윈도우에서 규칙이 차지하는 비중이 줄어든다

새 세션에서는 지침이 컨텍스트의 상당 부분을 차지합니다. 하지만 도구 호출이 백 번쯤 지나면 지침은 로그, diff, 읽은 코드 사이에 묻힌 작은 조각이 됩니다. 신호는 그대로인데 주변의 잡음은 수십 배로 늘어난 셈입니다.

최근의 예시가 오래된 규칙보다 힘이 세다

모델은 대화에서 최근에 일어난 일에 강하게 의존합니다. 에이전트가 규칙을 우회한 행동을 여러 번 연달아 했고 그냥 넘어갔다면, 이 패턴이 대화 기록에서 앞쪽 어딘가의 지침 한 줄보다 더 큰 무게를 가집니다.

Context rot: 윈도우가 찼을 때의 품질 저하

Context rot("컨텍스트 부패")은 기술적 한계에 한참 못 미치더라도, 윈도우가 차면서 모델의 응답 품질이 떨어지는 현상을 말합니다. 모델이 20만 토큰을 형식상 받아들이더라도, 15만 토큰에서는 2만 토큰일 때보다 성능이 떨어집니다. 세부 사항을 더 자주 틀리고, 이미 기각된 해결책을 다시 제안하며, 지침을 놓칩니다.

세션이 "썩었다"는 신호는 다음과 같습니다.

• 30분 전에 함께 버리기로 한 접근 방식을 에이전트가 다시 제안합니다.
• 이미 논의된 파일 이름이나 함수 이름을 틀립니다.
• 처음에 스스로 돌리던 검사를 더 이상 돌리지 않습니다.
• 응답이 길어지고 흐릿해지며, "덤으로 이것도 고쳤습니다" 같은 불필요한 변경이 늘어납니다.

이 문제를 규칙을 하나 더 추가해서 고치려는 것은 소용이 없습니다. 새 규칙도 같은 잡음 속에서 똑같이 잊히기 때문입니다. 잡음을 줄여야 합니다.

컨텍스트 압축

압축(compaction)은 세션의 기록을 줄이는 것입니다. 모델이 지금까지 일어난 일의 요약을 쓰고, 이후 대화는 전체 기록 대신 이 요약을 바탕으로 이어집니다. 윈도우 공간이 확보되고, 작업의 핵심은 남는 것처럼 보입니다.

Claude Code에는 이를 위한 /compact 명령이 있습니다. 압축할 때 무엇에 집중할지 힌트를 함께 줄 수 있습니다. 윈도우가 한계에 가까워지면 Claude Code가 압축을 자동으로 실행하기도 합니다. /clear는 기록을 완전히 지우고 깨끗한 상태에서 다시 시작합니다. /context는 윈도우가 지금 무엇으로 차 있는지 보여 줍니다.

/context
/compact 보존할 것: 작업 목표, 이유와 함께 내린 결정, 변경된 파일 목록, 아직 확인하지 않은 것
/clear

압축의 위험

요약은 항상 세부 사항을 잃습니다. 버린 대안과 그 이유, 요구사항의 정확한 문구, 지나가며 합의한 미묘한 부분이 요약에서 빠질 수 있습니다. 압축 후 에이전트는 자기 세션에 대한 남의 메모를 가지고 일하게 됩니다. 그래서 중요한 내용은 대화 기록이 아니라, 어떤 압축에도 살아남는 파일에 두는 편이 안전합니다.

압축할지 새 세션을 열지

컨텍스트를 절약하는 방법

컨텍스트 절약은 토큰 비용의 문제가 아니라 작업 품질의 문제입니다. 윈도우의 잡음이 적을수록 주의력은 작업과 규칙에 더 많이 돌아갑니다.

1. 짧은 라우터 역할의 지침 파일

진입점인 CLAUDE.md나 AGENTS.md는 매 세션 통째로 읽힙니다. 600줄짜리 파일은 대략 1만에서 2만 토큰의 고정 비용입니다. 여기에는 검증 명령, 엄격한 제약, 프로젝트 지도만 두고, 세부 내용은 주제별 문서로 나누어 에이전트가 필요할 때만 열게 하세요.

2. 필요할 때 불러오는 지식

Claude Code 스킬은 컨텍스트에 처음에는 짧은 설명만 넣고, 작업에 스킬이 필요할 때 전체 지침을 불러오도록 설계되어 있습니다. 배포, 마이그레이션, 릴리스처럼 드문 절차를 매 세션 비용을 치르지 않고 가까이 두는 좋은 방법입니다.

3. 시끄러운 작업은 서브에이전트에게

서브에이전트는 자기만의 컨텍스트 윈도우에서 일하고, 주 세션에는 결과만 돌려줍니다. 큰 코드베이스 검색, 긴 로그 분석, 낯선 모듈 탐색을 서브에이전트에게 맡기면, 원본 출력 수천 줄 대신 결론 몇 단락을 받게 됩니다.

4. 조용한 도구 출력

도구 출력은 윈도우를 가장 많이 잡아먹습니다. 검증 명령은 성공했을 때 한 줄만 출력하고, 실패했을 때만 핵심 내용, 즉 실패한 테스트와 그 메시지만 보여 주도록 설정하세요. 빌드 로그 전체가 아니라요.

# 시끄러움: 실행할 때마다 수천 줄이 윈도우로 들어감
pytest -v

# 조용함: 성공하면 한 줄, 실패하면 실패한 테스트만
pytest -q --tb=short

# 로그는 통째로가 아니라 끝부분과 오류만
tail -n 50 app.log | grep -i error

5. 한 세션에 한 작업

관련 없는 작업 세 개를 한 세션에서 이어 하지 마세요. 첫 번째 작업의 기록은 세 번째 작업에 쓸모가 없지만 공간을 차지하고 에이전트를 헷갈리게 합니다. 한 작업을 끝내고 결과를 기록한 뒤 새 세션을 여세요.

6. 기록이 아니라 파일에 상태 두기

압축과 새 세션을 견뎌야 하는 내용, 즉 목표, 이유와 함께 내린 결정, 버린 대안, 완료된 작업과 검증 방법, 다음 단계는 저장소의 파일에 적으세요. 예를 들어 PLAN.md와 PROGRESS.md입니다. 그러면 새 세션은 요약이 아니라 정확한 문서에서 시작하고, 대화 기록은 마음 놓고 지울 수 있습니다.

# PROGRESS.md
## 목표
할인 계산을 정수 단위(코펙)로 옮기기

## 완료 (검증됨)
- app/payments/discount.py: float → int 전환, make test 초록
- 마이그레이션 041 추가, 로컬 적용 완료

## 결정
- 반올림은 은행 방식, 결제 제공자와 같게

## 버린 것
- 모델에서 Decimal 사용: 웹훅 직렬화가 깨짐

## 다음 단계
주문 결제 e2e 시나리오 갱신 후 make e2e 실행

중요한 규칙은 윈도우 안에만 두지 마세요

아무리 잘 구성된 컨텍스트라도 규칙 준수를 보장하지 못합니다. 윈도우의 텍스트는 모델에 대한 영향일 뿐, 실행되는 금지가 아닙니다. 위반이 용납되지 않는다면, 규칙은 기계로 검사되어야 합니다. Claude Code에서는 에이전트의 이벤트에서 실행되어 동작을 차단할 수 있는 훅과, 특정 도구나 명령을 금지하는 권한 설정이 그 역할을 합니다. 린터, 테스트, CI는 에이전트 윈도우의 상태와 상관없이 독립적으로 작동합니다.

하네스의 좋은 원칙은 이렇습니다. 자동으로 확인할 수 있는 것은 자동으로 확인하고, 컨텍스트에는 판단이 필요한 것만 남깁니다.

요약

LLM의 컨텍스트 윈도우는 에이전트가 여러분의 작업을 보는 유일한 장소이며, 지침, 대화 기록, 읽은 파일, 명령 출력이 쌓이면서 생각보다 빨리 찹니다. 품질은 기술적 한계보다 훨씬 전에 떨어지고, 중간의 규칙은 잊히며, 압축은 공간을 얻는 대가로 세부 사항을 잃습니다. 지침은 짧게 유지하고, 드문 지식은 필요할 때 불러오고, 시끄러운 작업은 서브에이전트에 맡기고, 상태는 파일에 두고, 중요한 규칙은 훅과 검사로 뒷받침하세요. 실습 중심의 harness engineering 과정에서는 이런 컨텍스트 관리를 실제 프로젝트에 적용해 봅니다.