컨텍스트 부패 (Context Rot): 왜 당신의 AI 코딩 에이전트는 세션 중간에 점점 멍청해지는가 (그리고 어떻게 해결했는가)

당신도 느껴본 적이 있을 것입니다. Claude Code, Cursor, 혹은 당신이 사용하는 어떤 에이전트든 처음 20분 동안은 정말 '마법' 같습니다. 리팩터링(refactor)을 완벽하게 해내고, 당신의 컨벤션(convention)을 기억하며, 단 한 번의 시도로 테스트를 통과시킵니다.

그러다 한 시간쯤 지나면, 점심을 거른 인턴처럼 변해버립니다. 10개의 메시지 전에 정의했던 함수를 잊어버립니다. 이미 거절했던 수정 사항을 다시 제안합니다. 무한 루프에 빠집니다. 당신은 "앞서 말했듯이..."라고 문장을 시작하며 스스로가 약간 미쳐가는 것 같다고 느낍니다.

모두에게는 각자의 이론이 있습니다. "모델 성능이 너프(nerfed)되었다.", "MCP 때문이다.", "사용량을 제한(throttling)하고 있다." 저도 어느 시점에는 이 세 가지를 모두 믿었습니다.

지루한 진실은 그중 어느 것도 아니라는 것입니다. 그것은 당신의 컨텍스트 윈도우(context window)가 쓰레기로 조용히 채워지고 있기 때문이며, 저는 그 쓰레기가 정확히 어디서 오는지 보여드릴 수 있습니다.

모델이 멍청해진 것이 아닙니다. 신호(signal)가 약해진 것입니다.

LLM(대규모 언어 모델)은 메모리를 가지고 있지 않습니다. 매 턴마다 대화의 전체 내용이 모델로 다시 전송됩니다. 당신의 메시지, 모델의 답변, 그리고 — 이것이 결정적인 문제입니다 — 모델이 실행한 모든 도구(tool)에서 발생한 모든 바이트(byte)의 출력값까지 말입니다.

마지막 부분이 바로 무너지는 지점입니다. 단 하나의 무해한 명령이 어떤 대가를 치르게 하는지 살펴보십시오:

• 실제 프로젝트에서의 npm run build: 2~10 KB의 webpack 노이즈.
• 제한 없는 git log: 수 페이지에 달하는 커밋 내역.
• 600줄짜리 파일에 대한 단 한 번의 cat: 파일 전체 내용이 토씨 하나 틀리지 않고 영구적으로 포함됨.
• 실패하는 테스트 스위트(test suite): 스택 트레이스(stack traces)가 겹겹이 쌓임.

에이전트에게 "빌드가 왜 실패하는지 확인해줘"라고 요청하면, 단 한 번의 도구 호출(tool call)로 컨텍스트에 50 KB를 쏟아부을 수도 있습니다. 당신은 그 내용의 대부분을 보지 못합니다. 그냥 스크롤되어 지나가 버리니까요. 하지만 모델은 이후의 모든 턴에서 그 모든 내용을 떠안고 갑니다.

이것이 바로 **컨텍스트 부패 (context rot)**입니다. 윈도우가 채워질수록, 신호(signal) (당신의 실제 작업) 대 노이즈(noise) (가공되지 않은 도구의 찌꺼기)의 비율이 붕괴됩니다. 어텐션(Attention)은 더 길고 쓰레기가 가득한 트랜스크립트(transcript) 전체로 얇게 분산됩니다. 모델이 게을러진 것이 아닙니다. 모델은 익사하고 있는 것입니다. 이제 모델의 정확도는 하드 토큰 제한(hard token limit)에 도달하기 훨씬 전부터 떨어진다는 확실한 연구 결과들이 나오고 있습니다. 성능은 단순히 윈도우가 넘쳤는지 여부가 아니라, 윈도우가 얼마나 가득 찼는지에 따라 저하됩니다.

따라서 "세션 중간에 멍청해진" 에이전트는, 당신이 (도구를 통해) 에이전트에게 건초더미를 먹여놓고 그 안에서 바늘을 찾아내라고 요구했기 때문에 멍청해진 것입니다.

실제로 이를 확인한 방법

저는 추측을 멈추고 측정하기 시작했습니다. 모델을 탓하기 전에, 무엇이 컨텍스트 윈도우 (Context Window)를 잡아먹고 있는지 살펴보세요:

• Claude Code에서 /context를 실행하여 상세 내역을 확인하십시오. 제가 처음 이 작업을 수행했을 때, 도구 결과 (Tool results)가 단일 항목 중 가장 큰 비중을 차지했습니다. 제 코드보다도, 대화 내용보다도 더 컸습니다.
• 어떤 호출 (Calls)이 비대한지 주목하십시오. 저의 경우 항상 동일한 주범들이었습니다: 빌드 출력 (Build output), git log, 의존성 트리 (Dependency trees), 그리고 단순히 "한번 보기 위해" 파일 전체를 읽는 행위였습니다.

그것이 진단의 전부였습니다. 비용이 많이 드는 부분은 저의 사고 과정이나 모델의 답변이 아니었습니다. 제가 전체를 읽을 필요가 전혀 없었던 가공되지 않은 명령 출력 (Raw command output)이었습니다.

해결책: 가공되지 않은 출력을 윈도우에서 제외하라

원칙은 단 한 문장입니다: 모델은 가공되지 않은 데이터 (Raw data)가 아니라 결론 (Conclusions)을 보아야 합니다.

이런 관점으로 문제를 바라보자 해결책은 명확해졌습니다. 그리고 그중 대부분은 특별한 도구가 전혀 필요하지 않습니다:

1. 소스 단계에서 요약하십시오. 에이전트가 npm test를 실행하고 8KB의 데이터를 들이마시게 두지 마십시오. 대신 "3개의 실패: auth.test.ts:40, 51, 77"과 같이 반환하도록 실행하십시오. grep, tail -n 20, --quiet, wc -l 등을 통해 파이프라인 (Pipe)으로 연결하십시오. 요약 한 줄은 수천 줄의 로그보다 가치 있습니다.

2. 단순히 이해하기 위해 파일 전체를 읽지 마십시오. 읽는 것은 편집을 위한 것입니다. "JWT가 어디서 검증되는가?"를 알고 싶다면, 600줄짜리 파일 전체가 아니라 관련 있는 15줄을 검색해서 읽으십시오. 파일 전체를 읽는 것은 제가 목격한 가장 흔한 자가 초래형 컨텍스트 상처 (Context wound)입니다.

3. 서브 에이전트 (Sub-agents)를 방화벽으로 사용하십시오. 소음이 많은 탐색 작업(코드베이스 grep, 로그 읽기, 문서 크롤링 등)을 수행할 일회용 에이전트를 생성하고, 그 에이전트가 발견한 내용 중 단 한 단락의 결과만 보고하도록 하십시오. 모든 불필요한 찌꺼기(Sludge)는 서브 에이전트와 함께 사라집니다. 당신의 메인 컨텍스트는 깨끗하게 유지됩니다.

4. 필요하다고 느껴지는 것보다 더 자주 새로 시작하십시오. 하위 작업 (Sub-task)을 마쳤나요? 그럼 새 세션을 시작하십시오. 모든 이력이 담긴 "가득 찬" 윈도우보다, 핵심 요약만 담긴 깨끗한 윈도우가 매번 승리합니다. 오래 지속되는 스레드 (Threads)는 허영 지표 (Vanity metric)일 뿐입니다.

5. 정말 무거운 작업은 샌드박스(Sandbox)를 통해 라우팅하세요. 이것은 제가 가장 강력하게 의존했던 방법입니다. 저는 명령어를 모델의 컨텍스트(Context)
_외부_에서 실행하는 레이어를 통해 실행하고, 전체 출력을 인덱싱한 뒤, 제가 검색한 슬라이스(Slice)만을 반환하도록 합니다. 따라서 56 KB 크기의 빌드 로그는 "여기에 에러를 언급하는 4줄이 있습니다"로 변환됩니다. 모델은 정답을 얻지만, 노이즈(Noise)는 윈도우(Window)에 전혀 닿지 않습니다. (저는 이를 위해 context-mode라는 도구를 사용하지만, 도구보다 패턴이 더 중요합니다. command | tee log.txt | grep ERROR를 사용하고 에이전트에게는 grep 결과만 전달하는 방식으로도 충분히 흉내 낼 수 있습니다.)

사고방식의 전환

컨텍스트 윈도우(Context window)를 가득 찰 때까지 채워 넣는 RAM처럼 취급하는 것을 멈추세요. 대신 회의실의 화이트보드처럼 취급하세요. 화이트보드에 적는 모든 내용은 주의력을 얻기 위해 서로 경쟁하며, 어질러진 보드는 회의실 전체를 더 멍청하게 만듭니다. 자주 지우세요. 중요한 것만 적으세요.

당신의 에이전트가 성능 저하(Nerfed)된 것이 아닙니다. 매몰된 것입니다. 그것을 파헤쳐 내면 마법은 다시 돌아옵니다. 세션의 처음 20분뿐만 아니라 세션 전체에서 말이죠.

이 내용이 당신의 경험과 일치한다면, 어떤 도구가 컨텍스트를 가장 많이 잡아먹는지 듣고 싶습니다. 저의 경우 매번 git log가 그렇습니다. 더 실용적인 AI 도구 관련 노트를 보고 싶다면 저 @enjoy_kumawat를 팔로우해 주세요.