AI 코딩 에이전트로 작업하다 보면 이상한 경험을 하게 됩니다. 처음엔 잘 돌아가던 에이전트가 세션이 길어질수록 맥락을 놓치고, 앞에서 말한 내용을 잊어버리고, 엉뚱한 답변을 내놓기 시작합니다. 모델 탓인가 싶지만, 사실 원인은 따로 있습니다.
소프트웨어 개발자 Garrit Franke가 최근 블로그에 이 현상의 이름을 붙였습니다. 그는 LLM의 컨텍스트 창을 두 영역으로 나눕니다. 모델이 날카롭게 작동하는 smart zone과, 주의가 흐려지며 앞의 내용을 잊기 시작하는 dumb zone입니다. 그 경계는 약 100k 토큰. 광고된 컨텍스트 창의 크기는 상관이 없습니다.
출처: Don’t trust large context windows – Garrit’s Notes
광고 숫자와 실제 성능 사이의 간극
요즘 AI 모델들의 컨텍스트 창은 빠르게 늘고 있습니다. 200k, 1M, 심지어 10M 토큰까지. 하지만 이 숫자가 실제로 사용할 수 있는 양을 의미하는 건 아닙니다.
RULER 벤치마크 연구에 따르면, 200k 이상의 컨텍스트를 지원한다고 주장하는 모델들도 32k 길이에서조차 절반 이상이 만족스러운 성능을 유지하지 못했습니다. 단순한 정보 검색 테스트에서는 잘 통과해도, 실제 작업처럼 추론과 판단이 필요한 상황에선 컨텍스트가 길어질수록 성능이 눈에 띄게 떨어졌습니다.
Chroma의 Context Rot 연구는 이를 더 구체적으로 드러냅니다. 18개의 주요 LLM을 대상으로 한 실험에서, 단어 목록 복사나 긴 문서 안에서 특정 정보를 찾아내는 것처럼 상대적으로 단순한 작업에서도 컨텍스트 길이가 늘어날수록 성능이 일관되게 저하됐습니다. 더 중요한 발견은 방해 정보(distractor)의 영향입니다. 질문과 비슷하지만 정답이 아닌 내용이 컨텍스트 안에 섞일수록, 모델이 틀린 정보에 이끌리는 빈도가 컨텍스트 길이에 비례해 급격히 높아졌습니다.
코딩 에이전트가 특히 취약한 이유
코딩 에이전트는 이 문제에 특히 노출되기 쉽습니다. 파일 몇 개 읽고, 긴 디버그 세션을 거치고, 테스트 결과를 분석하다 보면 어느새 100k 토큰을 훌쩍 넘습니다.
Claude Code 같은 도구는 이를 인식하고 자동 압축(auto-compact) 기능으로 대응합니다. 세션이 길어지면 히스토리를 요약하고 새로 시작하는 방식입니다. 하지만 여기에도 한계가 있습니다. 요약 자체가 이미 성능이 떨어진 상태의 모델에 의해 만들어지고, 무엇이 중요한지 판단하는 것도 모델에 맡겨집니다.
Garrit의 접근법은 다릅니다. 세션을 새로 열 때 자신이 직접 작성한 스펙 문서를 넘기는 것입니다. 자동 요약보다 훨씬 높은 신호밀도를 가집니다. 다음 세션에서 무엇이 중요한지를 사람이 판단해 전달하기 때문입니다. 이른바 ‘빵 부스러기(breadcrumb)’ 접근법으로, 다음 세션이나 다음 사람이 깔끔하게 이어받을 수 있는 아티팩트를 남기는 것입니다.
컨텍스트 창을 예산처럼 다루기
Context Rot 연구는 또 하나의 흥미로운 사실을 밝혔습니다. 모델이 관련 정보만 포함된 짧은 프롬프트와 113k 토큰의 전체 대화 히스토리를 처리할 때 성능 격차가 극적으로 벌어졌다는 점입니다. 즉, 컨텍스트에 무엇이 들어있는가만큼, 어떻게 구성되어 있는가도 성능에 직접 영향을 줍니다.
이 관점에서 보면 컨텍스트 창은 무제한으로 쌓을 수 있는 저장소가 아니라, 신중하게 관리해야 할 자원입니다. 현재 작업과 관련 없는 정보를 세션에서 꺼내 별도 문서로 분리하는 것, 각 세션을 작고 집중된 단위로 유지하는 것이 모델 성능을 실질적으로 높이는 방법입니다.
결국 더 큰 컨텍스트 창보다는, 컨텍스트 안에 무엇을 넣고 무엇을 빼느냐가 더 중요한 변수입니다.
참고자료:
답글 남기기