개요

Claude Code를 쓰다 보면 이런 순간이 온다.

분명 30분 전까지만 해도 완벽하게 작동하던 AI가, 갑자기 엉뚱한 코드를 내놓기 시작한다. 에러 메시지도 없고, 모델이 바뀐 것도 아닌데 성능이 눈에 띄게 떨어진다. 지시했던 컨벤션을 무시하고, 방금 수정한 파일을 다시 되돌리고, 이미 논의한 내용을 처음 듣는 것처럼 되묻는다.

아까까진 잘했는데... 갑자기 왜 이러지?

이 현상에는 이름이 있다. Context Rot(컨텍스트 부패)이다.

Context Rot은 LLM의 컨텍스트 윈도우가 오염되면서 발생하는 점진적 성능 저하다. 모델 자체가 망가진 게 아니라, 모델이 보고 있는 정보의 질이 망가진 것이다. 그리고 이것은 에러 로그에 남지 않기 때문에, 원인을 모르면 "AI가 멍청해졌다"고 착각하게 된다.

이 글에서는 Context Rot의 구조적 원인을 분석하고, 실전에서 검증된 운영 전략을 정리한다.

Context Rot이란

Context Rot은 대화가 길어질수록 LLM의 응답 품질이 떨어지는 현상이다. 원인은 단순하지 않다. 여러 요인이 복합적으로 작용하며, 각각을 이해해야 제대로 대응할 수 있다.

중간 정보 인출 실패 (Lost in the Middle)

LLM은 컨텍스트의 처음과 끝에 있는 정보는 잘 기억하지만, 중간에 위치한 정보는 잘 놓친다. 이것은 "Lost in the Middle" 현상으로 알려져 있다.

대화가 길어질수록 초반에 설정한 규칙, 중간에 합의한 설계 결정, 이전에 확인한 코드 구조 등이 컨텍스트의 중간 지대에 묻힌다. 모델은 이 정보들을 "안 보이니까 없는 것" 으로 취급한다.

시험 범위가 넓어질수록 중간 단원을 대충 넘기게 되는 것과 같다. 모델도 마찬가지다.

누적 지시문 충돌

CLAUDE.md에 적은 규칙, 대화 중 추가한 지시, Skills에 정의된 패턴, Hooks가 주입하는 메시지 — 이것들이 누적되면서 서로 모순되는 지시가 공존하게 된다.

예를 들어:

• CLAUDE.md에는 "항상 테스트를 먼저 작성하라"고 적혀 있고
• 대화 중에 "테스트는 나중에 한꺼번에 작성할게"라고 말했다면

모델은 둘 중 어느 쪽을 따라야 하는지 혼란스러워한다. 더 최근의 지시를 우선할 수도 있고, 더 명시적인 규칙을 따를 수도 있으며, 때로는 둘 다 무시하고 자기 방식으로 해버린다.

토큰 예산 압박

Claude Code의 컨텍스트 윈도우는 200K 토큰이다. 넉넉해 보이지만, 실제로는 그렇지 않다.

MCP 도구를 20~30개 활성화하면 도구 정의만으로 상당한 토큰을 소비한다. CLAUDE.md, Rules, Skills 정의, 이전 대화 내용, 파일 읽기 결과까지 합치면 실제로 "생각"에 쓸 수 있는 토큰은 절반 이하로 줄어든다.

토큰이 부족해지면 모델은 추론을 단축하고, 세부사항을 건너뛰고, 근사값으로 답한다. 틀린 게 아니라 대충 하는 것이다.

무관한 정보 과다 로드

파일을 읽을 때마다, 검색 결과를 받을 때마다 컨텍스트에 정보가 쌓인다. 문제는 이 정보 중 상당수가 현재 작업과 무관하다는 것이다.

2,000줄짜리 파일을 읽었는데 필요한 건 10줄뿐이라면, 나머지 1,990줄은 순수한 노이즈다. 이 노이즈가 쌓이면 모델의 "주의력"이 분산되고, 정작 중요한 정보에 대한 집중도가 떨어진다.

흔한 실수들

Context Rot을 가속시키는 대표적인 Anti-pattern들이 있다. 본인의 사용 습관과 대조해보자.

CLAUDE.md에 모든 걸 때려넣기

CLAUDE.md는 만능 설정 파일이 아니다. 여기에 코딩 규칙, 프로젝트 구조, 배포 절차, 커밋 컨벤션, 테스트 전략을 모두 적으면 매 대화 시작 시 수천 토큰이 고정 비용으로 소비된다.

문제는 이 중 대부분이 현재 작업과 무관하다는 것이다. 커밋 메시지 규칙은 커밋할 때만 필요하고, 배포 절차는 배포할 때만 필요하다.

한 번에 큰 작업 던지기

"이 앱 전체를 Next.js 16으로 마이그레이션해줘."

이런 요청은 모델에게 수십 개의 파일을 동시에 읽고, 수백 가지 변경사항을 한꺼번에 처리하라는 뜻이다. 컨텍스트가 빠르게 포화되고, 중간 단계의 결정들이 서로 충돌하며, 결과적으로 앞에서 고친 걸 뒤에서 되돌리는 상황이 반복된다.

상태 초기화 없이 이어가기

한 세션에서 버그 수정 → 리팩토링 → 새 기능 추가 → 테스트 작성을 연속으로 진행하면, 이전 작업의 잔여 컨텍스트가 현재 작업을 오염시킨다.

버그 수정 중 읽었던 에러 로그, 리팩토링 중 논의했던 설계 대안들 — 이것들이 새 기능 구현 시에도 컨텍스트에 남아 있다. 모델은 이 모든 정보를 고려하며 답하기 때문에, 관련 없는 과거 맥락에 끌려가는 답변을 내놓게 된다.

모델 선택 전략 없이 사용

모든 작업에 Opus를 쓰는 것은 비용만 낭비하는 게 아니다. Opus는 깊은 추론에 최적화되어 있어, 단순 작업에서는 오히려 과도하게 복잡한 답변을 만들어낸다. 반대로 모든 작업에 Haiku를 쓰면 복잡한 아키텍처 결정에서 얕은 답변이 나온다.

운영 원칙

문제를 알았으니 해결 전략을 보자.

작업 단위 쪼개기

"통째로 시키지 말기." 이것이 가장 중요한 원칙이다.

큰 작업을 작은 단위로 나누고, 각 단위의 결과를 확인한 뒤 다음으로 넘어간다. 단순히 "작게 나누라"는 뜻이 아니다. 각 단위가 독립적으로 검증 가능해야 한다.

"사용자 인증 시스템을 만들어줘. 회원가입, 로그인, 비밀번호 재설정, 
 OAuth 연동, 세션 관리, 권한 체계까지 전부."

1단계: "회원가입 API와 폼 컴포넌트를 만들어줘"
→ 결과 확인, 테스트 통과 확인
 
2단계: "로그인 API와 세션 관리를 추가해줘"
→ 결과 확인, 기존 회원가입과 통합 테스트
 
3단계: "비밀번호 재설정 플로우를 만들어줘"
→ ...

사고 프로세스 강제하기

코드를 바로 작성하기 전에 설계를 먼저 하도록 강제한다. Plan Mode에서 설계를 완료하면 컨텍스트를 정리한 뒤 구현으로 넘어간다.

1. 어떤 파일을 수정해야 하는가
2. 각 파일에서 무엇을 변경하는가
3. 변경 순서는 어떻게 되는가
4. 예상되는 리스크는 무엇인가
5. 어떻게 검증할 것인가

이렇게 하면 모델이 "일단 해보고 고치자"는 방식 대신 **"먼저 생각하고 실행하자"**는 방식으로 동작한다.

단순화 루프

코드가 복잡해지면 Context Rot이 가속된다. 파일이 길어지고, 의존성이 얽히고, 모델이 읽어야 할 양이 늘어나기 때문이다.

주기적으로 단순화 루프를 돌려야 한다.

사용 타이밍:

• 하나의 기능 구현이 끝났을 때
• 리팩토링 후 코드가 오히려 복잡해졌을 때
• 파일 하나가 300줄을 넘었을 때

세션 관리 전략

세션 관리는 Context Rot을 막는 가장 직접적인 수단이다.

핵심 전략: 자동 compact를 믿지 말고, 논리적 구간에서 수동으로 관리한다.

1. 버그 조사 → 원인 파악 → /compact (조사 결과만 남기기)
2. 수정 구현 → 테스트 통과 → /clear
3. 새로운 작업 시작

모델 전략

모든 작업에 같은 모델을 쓰는 것은 비효율적이다.

기본값은 Sonnet이다. 코딩 작업의 90%는 Sonnet으로 충분하다. Opus로 올려야 하는 시점은 명확하다:

• 첫 시도가 실패했을 때
• 5개 이상의 파일을 동시에 다뤄야 할 때
• 아키텍처 결정이 필요할 때
• 보안이 중요한 코드일 때

실전 워크플로우

Search-First 워크플로우

코드를 수정하기 전에 반드시 현재 상태를 파악한다.

1. 관련 파일 검색 (Glob, Grep)
2. 파일 읽기 — 수정할 부분만 정확히 확인
3. 영향 범위 파악 — 이 파일을 참조하는 다른 파일 확인
4. 그 다음에야 수정 시작

이 워크플로우가 중요한 이유는 불필요한 파일 읽기를 줄여 토큰을 절약하고 Context Rot을 방지하기 때문이다.

TDD 워크플로우

1. 실패하는 테스트 작성
2. 테스트를 통과하는 최소 코드 작성
3. /compact — 테스트 결과와 코드만 남기기
4. 리팩토링
5. 전체 테스트 스위트 실행
6. /clear — 다음 기능으로 이동

3단계의 /compact가 핵심이다. 테스트를 작성하는 과정에서 쌓인 탐색 컨텍스트를 정리하고, 구현에 필요한 정보만 남긴다.

Strategic Compact 워크플로우

가장 범용적인 패턴이다.

1. 작업 시작 — 목표와 범위 정의
2. 조사 단계 — 파일 읽기, 검색, 분석
3. /compact — 조사 결과 요약 (불필요한 원문 제거)
4. 구현 단계 — 압축된 컨텍스트에서 집중 구현
5. 검증 단계 — 테스트, 린트, 빌드
6. /clear — 완전 초기화 후 다음 작업

자동 compact에 의존하면 모델이 임의로 중요한 정보를 버릴 수 있다. 수동으로 "여기까지의 결과를 요약해"라고 지시하는 것이 훨씬 안전하다.

마무리

• AI는 똑똑한 게 아니라 상태에 민감하다. 같은 모델이라도 컨텍스트가 깨끗하면 천재고, 오염되면 바보다.
• 큰 작업이 아니라 좋은 단위가 중요하다. 한 번에 많이 시키는 것보다, 작게 나눠서 검증하는 것이 결과적으로 빠르다.
• 설계 없이 실행하면 반드시 망한다. Plan Mode를 건너뛰고 바로 코드를 쓰면, 나중에 두 배의 시간을 수정에 쓴다.
• 토큰은 돈이 아니라 주의력이다. 토큰이 낭비되면 모델의 집중도가 떨어진다. 비용 이전에 성능의 문제다.

AI Agent는 도구다. 도구는 사용자의 역량만큼만 발휘된다. Context Rot을 이해하고 운영 원칙을 세우는 것 — 이것이 AI를 "쓰는 것"과 "잘 쓰는 것"의 차이다.