5주차: 컨텍스트 관리와 Context Rot 방지

Phase 25주차중급강의일: 2026-03-31

이론 (Theory)

왜 5주차에서 컨텍스트 관리가 중심인가

4주차에서 루프 패러다임의 위력을 배웠다 — 같은 모델을 반복 호출하되, 결정론적 검증으로 품질을 확보한다. 하지만 루프가 작동하려면 전제 조건이 있다: 컨텍스트가 깨끗해야 한다.

4주차의 Huntley는 이 문제를 알고 있었다. 그래서 매 루프마다 새 세션을 시작하는 “fresh context” 전략을 선택했다. 하지만 이것만으로는 부족하다:

루프 내부에서도 컨텍스트는 오염된다 — 도구 호출 결과, 실패한 시도, 에러 메시지가 쌓인다
세션 간 상태 전달이 필요하다 — 매번 처음부터 시작하면 이전 루프의 학습이 사라진다
6주차 인스트럭션 튜닝의 전제: CLAUDE.md에 제약을 추가해도, 컨텍스트가 오염되면 에이전트가 제약을 “잊는다”

이번 주의 핵심 질문: 어떻게 컨텍스트를 결정론적으로 관리할 것인가?

이 질문에 답하기 위해 먼저 Context Rot이 왜 발생하는지, 얼마나 심각한지를 실증 데이터로 확인하고, 그 다음 해법을 쌓아 올린다.

Context Rot란?

에이전트가 장시간 실행되면서 컨텍스트 창이 점점 오염되는 현상이다:

Clean Context (초기)[시스템 프롬프트] [태스크 명세] [현재 코드]

Context Rot (30회 시도 후)[시스템 프롬프트] [태스크 명세] [실패 #1] [에러 #1] [실패 #2] [에러 #2] … 128K 토큰 → 환각 발생, 추론 품질 급락

실증 데이터: Chroma의 Context Rot 연구

“컨텍스트가 길어지면 나빠진다”는 직관적이지만, 얼마나 나빠지는지는 Chroma의 2026년 실증 연구가 처음으로 정량화했다. 18개 frontier 모델(Claude, GPT, Gemini, Llama 등)을 대상으로 테스트한 결과:

발견	수치
중간 위치(mid-window) 정확도 하락	30%+
입력 길이와 정확도 상관	모든 모델에서 음의 상관 — 예외 없음
반직관적 결과	섞인(shuffled) 문서가 논리적으로 정렬된 문서보다 정확도 높음

마지막 발견이 특히 중요하다. 논리적 순서로 배치하면 모델이 “이미 앞에서 봤으니 뒤는 대충 읽어도 된다”고 판단하는 경향이 있다. 섞으면 매 위치에서 주의를 기울여야 하므로 오히려 정확도가 올라간다.

왜 발생하는가 — 3가지 복합 메커니즘

Chroma 연구가 얼마나 나빠지는지를 보여줬다면, 후속 연구는 왜 나빠지는지를 밝혀냈다. 세 가지 메커니즘이 서로를 증폭시킨다:

메커니즘	설명	스케일링
Lost-in-the-middle	컨텍스트 중간에 위치한 정보가 시작/끝보다 검색 정확도 낮음	위치 의존
Attention dilution	컨텍스트가 길어질수록 각 토큰이 받는 attention 비중 감소	이차(quadratic) — 길이 2배 → 희석 4배
Distractor interference	관련 없는 정보가 관련 정보에 대한 추론을 능동적으로 방해	노이즈 비율에 비례

MECW — 실효 최대 컨텍스트 창

이 연구에서 나온 중요한 개념: MECW (Maximum Effective Context Window) — 모델의 in-context 정보 정확도가 사용 가능한 수준 이하로 떨어지는 지점. MECW ≠ 공칭 최대 컨텍스트. 벤치마크에서 최상위 모델도 공칭 한계 훨씬 이전에 정확도가 떨어지기 시작했다. 아래 표에서 실효 사용량이 60-70%인 이유가 바로 이것이다.

1M 토큰 시대 — 큰 창이 해결책인가?

2026년 기준 frontier 모델의 컨텍스트 창:

모델	공식 컨텍스트	실효 사용량
Claude Opus/Sonnet 4.6	1M 토큰	~600-700K
GPT-5.4	1M 토큰	~600-700K
Gemini 2.5 Pro	1M 토큰	~600-700K

실효 사용량이 60-70%인 이유: 나머지는 시스템 프롬프트(~50K), 도구 스키마(~30K), 안전 마진(~200K)이 차지한다.

Claude Code는 Context Rot 방지를 위해 auto-compaction을 내장하고 있다:

트리거: 컨텍스트가 ~33K 토큰에 도달하면 자동 압축 (v2.1.x에서 45K→33K로 하향 조정, 더 조기에 트리거). 턴 수가 아닌 토큰 기반 트리거
알고리즘: 최근 4개 메시지 보존 + 나머지를 Markdown→plaintext 변환, 중복 도구 결과 제거
CLAUDE.md 3레벨 계층: ~/.claude/CLAUDE.md(전역) → <project>/.claude/CLAUDE.md(프로젝트) → <workspace>/CLAUDE.md(로컬). 전체 합산 12,000자 제한
Auto-memory (MEMORY.md): v2.1.59+에서 도입된 세션 간 자동 기억 시스템. 프로젝트별 학습된 사실(디버깅 패턴, 선호 방식 등)을 MEMORY.md에 축적. 첫 200줄이 세션 시작 시 자동 로드. CLAUDE.md(규칙)과 MEMORY.md(학습된 사실)는 상호 보완적
서브에이전트 격리: Agent 도구로 생성된 서브에이전트는 빈 컨텍스트에서 시작. 부모의 대화 히스토리를 상속하지 않으며, 필요한 정보는 부모가 프롬프트에 명시적으로 전달해야 한다
토큰 추적: input/cache_creation/cache_read/output 4종 토큰을 매 API 호출마다 기록. /cost로 실시간 확인
수동 트리거: /compact 명령으로 즉시 압축 실행 가능

→ 상세: 참고자료 > Claude Code 내부 구조

Compaction 전략 — 무엇을 버리고 무엇을 남길 것인가

auto-compaction이 작동할 때, 보존 우선순위가 결정적이다:

우선순위	보존 대상	이유
1 (최고)	시스템 프롬프트 + CLAUDE.md	에이전트의 “헌법” — 이것을 잃으면 행동 규칙이 사라진다
2	최근 4개 메시지	현재 작업의 즉각적 맥락
3	현재 태스크의 도구 결과	방금 읽은 파일, 방금 실행한 테스트 결과
4 (최저)	오래된 대화 + 이전 도구 결과	요약으로 대체 가능

압축하지 말아야 할 때: 다음 상황에서는 compaction보다 세션을 끊고 새로 시작하는 것이 낫다:

대화 주제가 완전히 전환된 경우 (이전 맥락이 오히려 방해)
연속 5회 이상 같은 에러가 반복되는 경우 (Context Rot이 이미 심각)
요약 자체가 원본의 50% 이상인 경우 (압축 효율이 없음)

이것이 4주차에서 Huntley가 “fresh context”를 선택한 이유다 — 루프 간에는 compaction보다 완전 초기화 + 상태 파일 전달이 더 결정론적이다.

휴리스틱을 넘어서 — ACON 압축 프레임워크

현재 compaction 전략(Claude Code 포함)은 휴리스틱 기반이다 — “최근 4개 보존”, “나머지 요약” 같은 규칙. ACON (Agent Context Optimization, arXiv:2510.00615, 2025년 10월)은 압축을 정형 최적화 문제로 접근한다:

지표	결과
피크 토큰 절감	26-54%
정확도 유지	95%+
방식	gradient-free, API 호환 (어떤 모델이든 API로 사용 가능)

ACON의 핵심 통찰: 고정 규칙 대신, 각 컨텍스트 세그먼트가 현재 태스크에 기여하는 정도를 동적으로 채점하고 임계값 이하를 제거한다. “항상 최근 4개 보존”(휴리스틱)과 “현재 태스크에 가장 관련 있는 메시지 보존”(최적화)의 차이다.

현재 Claude Code는 휴리스틱을 사용하지만, ACON은 이 분야의 발전 방향을 보여준다 — 규칙 기반에서 최적화 기반 compaction으로의 전환.

Ralph 루프의 해법: Context Window Wiping

Ralph 루프의 핵심 혁신 중 하나는 태스크 완료 또는 실패 후 컨텍스트를 완전히 초기화하는 것이다:

class RalphContextManager:
    def __init__(self, max_tokens: int = 200_000):
        self.max_tokens = max_tokens
        self.state_file = "claude-progress.txt"

    def should_wipe_context(self, current_tokens: int) -> bool:
        """컨텍스트 창의 75% 이상 사용 시 초기화"""
        return current_tokens > self.max_tokens * 0.75

    def build_fresh_context(self) -> str:
        """상태 파일에서 결정론적으로 컨텍스트 재구성"""
        state = self.load_state()
        return f"""
# 프로젝트 상태
{state['completed_tasks']}

# 현재 태스크
{state['current_task']}

# 관련 코드 (현재 버전만)
{state['relevant_code_snippet']}
"""

    def save_state(self, task: str, status: str):
        """다음 루프를 위한 상태 저장"""
        with open(self.state_file, 'a') as f:
            f.write(f"[{status}] {task}\n")

상태 추적 파일 설계 패턴

claude-progress.txt완료/실패 태스크 기록

fix_plan.md구조화된 태스크 큐

@codebase_map.md파일 구조 스냅샷 (최신 유지)

fix_plan.md 템플릿:

# 프로젝트: Calculator App
## 완료된 태스크
- [x] 기본 파일 구조 생성 (2026-03-31 14:23)
- [x] add() 함수 구현 및 테스트 통과 (2026-03-31 14:45)

## 현재 태스크
- [ ] subtract() 함수 구현
  - 예상 파일: calculator.py:15-25
  - 관련 테스트: tests/test_calculator.py:20-35

## 대기 중인 태스크
- [ ] multiply() 함수
- [ ] divide() 함수 (0 나눗셈 예외 처리 필수)

토큰 경제학 — 40-70%의 낭비를 줄이는 법

컨텍스트 관리의 궁극적 목표는 같은 예산으로 더 많은 유용한 작업을 하는 것이다. 실측 데이터에 따르면 에이전트 입력 토큰의 40-70%가 낭비다 — 중복된 도구 결과, 불필요한 파일 내용, 과도한 시스템 프롬프트.

모델 라우팅 — 모든 작업에 Opus를 쓸 필요는 없다

태스크 유형	비중	권장 모델	비용 (1M 토큰)
단순 조회, 포맷팅, 타입 확인	60-70%	Haiku	$1 / $5
표준 코딩, 버그 수정, 기능 추가	25-30%	Sonnet	$3 / $15
아키텍처 설계, 복잡한 디버깅	5-10%	Opus	$5 / $25

모델 라우팅만으로 5-8배 비용 절감이 가능하다. Claude Code의 effort 파라미터(4주차 참조)가 이 라우팅의 제품화된 형태다.

Prompt Caching — 반복을 자산으로 바꾸기

에이전트의 매 턴에서 시스템 프롬프트, 도구 스키마, CLAUDE.md는 동일한 내용이 반복된다. Prompt caching은 이 정적 부분을 캐시하여 재사용한다:

작업	가격 (기본 대비)
캐시 쓰기 (5분 TTL)	1.25x
캐시 쓰기 (1시간 TTL)	2x
캐시 읽기	0.1x (90% 절감)

루프 패러다임에서의 시사점:

연속 세션: 첫 턴에서 캐시 생성 → 이후 턴에서 0.1x로 읽기 = 매우 경제적
Ralph fresh context: 매 루프마다 새 세션 → 캐시 재생성 필요 = 비용 증가
트레이드오프: Context Rot 방지(fresh) vs 캐시 효율(continuous). 4주차의 Huntley Showdown과 같은 문제

Initializer 패턴 — 2-phase 상태 관리

Anthropic의 공식 하네스 가이드에서 권장하는 2-phase 패턴은 위 상태 파일 설계를 체계화한 것이다:

Phase 1 — Initializer (첫 루프):

요구사항을 파싱하여 feature list를 JSON으로 생성
claude-progress.txt 초기화
init.sh (환경 설정 스크립트) 생성

{
  "features": [
    {"id": "F001", "name": "사용자 인증", "status": "pending", "files": ["src/auth.py"]},
    {"id": "F002", "name": "대시보드 UI", "status": "pending", "files": ["src/dashboard.py"]}
  ],
  "constraints": ["pytest 통과 필수", "타입 힌트 100%"]
}

Phase 2 — Coding Agent (이후 루프):

init.sh 실행으로 환경 설정
JSON에서 "status": "pending" 항목을 꺼내 작업
완료 시 "status": "done" + claude-progress.txt에 기록
다음 루프는 JSON을 읽고 남은 항목부터 시작

이 패턴은 현재 week-05의 state file 3종(claude-progress.txt, fix_plan.md, @codebase_map.md)의 상위 추상화다. JSON feature list가 fix_plan.md를, init.sh가 @codebase_map.md를 대체한다.

영구 지식 시스템 — LLM Wiki 패턴

Initializer 패턴이 단일 태스크의 상태를 관리한다면, LLM Wiki 패턴은 프로젝트 전체의 지식을 영구적으로 축적한다. Karpathy가 제안한 이 패턴의 핵심은 “지식을 한 번 정리하고, 최신 상태를 유지한다” (compile once, keep current)이다.

아키텍처:

계층	역할	예시
Raw Sources	불변 원본 자료	논문 PDF, 회의 녹취, 코드베이스
Wiki	LLM이 생성·유지하는 마크다운 파일	요약, 교차 참조, 엔티티 페이지
Schema	구조와 워크플로우를 정의하는 설정 파일	CLAUDE.md에 wiki 규칙 기술

3대 연산:

Ingest — 새 원본 자료를 읽고, 요약을 작성하고, 관련 wiki 페이지를 업데이트
Query — 질문에 대해 wiki를 검색하여 답변을 합성하고, 새 발견을 다시 wiki에 기록
Lint — 모순, 오래된 정보, 고아 페이지, 누락된 교차 참조를 점검

이 패턴은 Initializer의 상위 진화형이다: state file 3종(단일 태스크) → JSON feature list(다기능 프로젝트) → Wiki(영구 지식 그래프). 컨텍스트 관리의 궁극적 형태는 세션마다 전체를 다시 파악하는 것이 아니라, 축적된 지식을 참조하는 것이다.

지식 그래프 기반 토큰 절감 — Graphify

컨텍스트에 원본 파일을 그대로 넣는 대신, 코드베이스를 지식 그래프로 변환하여 필요한 부분만 조회하면 토큰 소비를 극적으로 줄일 수 있다. Graphify는 이 접근법의 실전 구현체다.

동작 방식:

코드 분석: tree-sitter AST 추출로 클래스, 함수, import, 호출 그래프를 로컬에서 파싱 (LLM 호출 불필요, 코드가 외부로 전송되지 않음)
문서/미디어 분석: PDF, 이미지, 동영상 등을 LLM으로 의미 추출
그래프 구축: NetworkX + Leiden 클러스터링으로 커뮤니티 탐지, 인터랙티브 HTML 시각화 + JSON 출력
신뢰도 태깅: 관계를 EXTRACTED(확정), INFERRED(추론, 점수 포함), AMBIGUOUS(모호)로 구분

토큰 효율: 혼합 코퍼스에서 원본 파일 직접 읽기 대비 71.5배 토큰 절감. 한 번 그래프를 구축하면 SHA256 캐시로 증분 업데이트만 수행한다.

이 접근법은 LLM Wiki 패턴과 결합할 수 있다: Graphify로 코드베이스의 구조를 그래프화하고, LLM Wiki로 그 위에 인사이트와 결정 사항을 축적한다.

LazyGraphRAG — 대규모 배포를 위한 경량 그래프 검색

Graphify가 단일 코드베이스를 로컬에서 그래프화한다면, Microsoft의 LazyGraphRAG는 엔터프라이즈 규모의 문서에 그래프 기반 검색을 적용한다:

지표	LazyGraphRAG vs Full GraphRAG
인덱싱 비용	0.1% (1/1000)
쿼리 비용	4% (1/25)
품질	벡터 RAG, RAPTOR 등 경쟁 기법 대비 우위

LazyGraphRAG는 사전 요약 없이 lazy evaluation으로 그래프를 구축하여, 1M 토큰 컨텍스트 창보다도 우수한 검색 품질을 달성한다. Microsoft Discovery(Azure)에 실전 배포되어 있다.

Graphify(로컬 코드베이스, 개인 사용) vs LazyGraphRAG(대규모 문서, 엔터프라이즈) — 비용-품질 스펙트럼의 두 지점이다.

도구별 컨텍스트 전략 비교

컨텍스트를 관리하는 접근법은 도구마다 다르다. 2026년 기준 세 가지 전략이 경쟁 중이다:

전략	대표 도구	방식	장점	단점
Explicit	Cursor	사용자가 컨텍스트에 넣을 파일을 직접 선택	정밀한 제어, 토큰 낭비 최소	수동 노동, 누락 리스크
Ambient	Windsurf (Cascade)	도구가 자동으로 관련 파일 탐지	편리, 누락 방지	과다 포함, 토큰 낭비 리스크
Hybrid	Claude Code	파일 기반 영속(CLAUDE.md) + 자동 압축	균형, 루프 친화적	설정 필요, 학습 곡선
Tiered	GitHub Copilot	3계층 메모리(user/repo/session) + Agent Mode	VS Code UX 친숙, 28일 자동 메모리	VS Code 중심, CLI 제어 제한
Sandboxed	Codex CLI	컨테이너 격리 + AGENTS.md	안전한 실행, 도구 중립	MCP 미지원, 컨텍스트 192K 제한
Large-window	Gemini CLI	1M 컨텍스트 + GEMINI.md	무료 티어, 최대 컨텍스트	생태계 신규, 도구 연동 적음
Autonomous	Devin	전체 자율 세션	엔드투엔드 자동화	~35분/10 ACU 후 성능 저하

VS Code Copilot은 2026년에 3계층 메모리(user/repository/session)를 도입하여, 사용자 선호(전역) → 프로젝트 규칙(레포) → 현재 대화(세션)를 분리했다. Claude Code의 CLAUDE.md 3레벨 계층(전역/프로젝트/로컬)과 동일한 설계 원리다.

인스트럭션 파일 수렴 — 업계가 파일 기반 컨텍스트를 검증하다

2025-2026년에 주목할 트렌드: 모든 주요 AI 코딩 도구가 독립적으로 파일 기반 컨텍스트 관리에 수렴했다. 경쟁하는 거의 모든 것에서 다르지만, 컨텍스트 관리 아키텍처만큼은 같은 결론에 도달했다:

도구	인스트럭션 파일	계층 구조
Claude Code	`CLAUDE.md`	3레벨: `~/.claude/`(전역) → `project/.claude/`(프로젝트) → `workspace/`(로컬)
OpenAI Codex CLI	`AGENTS.md`	디렉토리 트리 계층적 탐색 (가장 가까운 파일 우선)
Google Gemini CLI	`GEMINI.md`	프로젝트 루트
Cursor	`.cursor/rules/*.mdc`	Glob 패턴으로 스코프 지정
GitHub Copilot	`.github/copilot-instructions.md`	단일 파일 + 28일 자동 메모리
Windsurf	Cascade Memories	사용 패턴에서 자동 생성

이 수렴은 “설정 파일을 영구 컨텍스트로” 패러다임을 검증한다. 모델이 세션 내에서 모든 것을 기억하는 것에 의존하는 대신, 결정론적이고 버전 관리 가능한 파일로 컨텍스트를 외부화한다. 이것은 이번 주에 배운 상태 추적 파일(fix_plan.md, claude-progress.txt)과 동일한 원리다 — 다만 태스크 상태가 아닌 행동 규칙에 적용된 것이다.

이 수렴은 설계 스펙트럼도 드러낸다:

수동 영속: 개발자가 직접 작성·유지 (Cursor rules, CLAUDE.md)
자동 생성 영속: 도구가 학습하여 작성 (Windsurf Cascade Memories, Copilot auto-memory)
하이브리드: 개발자가 규칙 작성, 도구가 사실 학습 (Claude Code의 CLAUDE.md + MEMORY.md)

→ 6주차에서 이 파일들에 무엇을 쓸지 다룬다. 이번 주의 초점은 왜 존재하는가 — 컨텍스트 관리 전략으로서의 역할이다.

토큰 효율적 데이터 직렬화

에이전트가 LLM에 구조화된 데이터를 보낼 때, 직렬화 포맷에 따라 토큰 소비가 2~3배 차이난다. 동일한 50명 사용자 목록을 7가지 포맷으로 직렬화한 실험 결과:

포맷	토큰 수	LLM 정확도	적합 상황
CSV	~800	44.3%	순수 테이블 (정확도 주의)
Markdown-KV	~950	60.7%	단순 키-값 검색
TOON	993	76.4%	균일 배열 데이터
JSON (compact)	~1,100	73.7%	범용 — 가장 안전한 균형점
JSON (pretty)	1,481	75.0%	인간 가독성 필요 시
YAML	1,710	74.5%	중첩 설정, 프롬프트 구조화
XML	2,690	72.1%	레거시 시스템 연동

TOON — 토큰 최적화 직렬화의 한 사례

TOON (Token Oriented Object Notation, 2025)은 JSON의 구조를 유지하되 따옴표, 중괄호, 쉼표를 제거하고, 균일 배열을 CSV식 테이블로 표현한다. GitHub 23.7K stars, npm 1.6M/월 다운로드로 커뮤니티 관심이 실재한다.

// TOON 예시: 균일 배열 → 헤더 + 행 형식
users[3]{id,name,email}:
  1,Alice,alice@example.com
  2,Bob,bob@example.com
  3,Carol,carol@example.com

강점: 균일 배열에서 pretty JSON 대비 40-60% 토큰 절감. 한계: 비균일/중첩 데이터에서 compact JSON보다 15-20% 더 클 수 있음. Spec이 Working Draft(v3.0, 3주 만에 v0.8→v3.0)이고, LLM이 TOON으로 훈련되지 않아 프롬프트에 포맷 설명이 필요하다.

실무 권장

기본값: compact JSON — 모든 LLM이 이해하고, 생태계가 성숙. pretty JSON 대비 25-40% 절감.
대규모 균일 테이블(100+ rows): TOON 또는 CSV 검토 — 단, 정확도 트레이드오프 측정 필수.
API 기반 구조화 출력: function calling / structured output API가 있으면 그것이 최적 (Microsoft 측정: JSON 대비 42% 절감).
7주차 멀티에이전트: 에이전트 간 아티팩트를 compact JSON으로 설계. Week 7 아티팩트 핸드오프 참조.

강의 중 토론 질문

1M 토큰 컨텍스트가 있으면 Context Rot은 해결되는가? Chroma 연구 데이터를 근거로 답하라.
Ralph의 fresh context vs 연속 세션 — 캐싱 비용(fresh = 매번 재생성, continuous = 0.1x 읽기)까지 고려하면 어느 쪽이 경제적인가? 어떤 조건에서 역전되는가?
CLAUDE.md를 200줄 이하로 유지하라는 조언의 근거는 무엇인가? SkillReducer의 “less-is-more” 효과와 연결하여 설명하라.
Chroma 연구에서 섞인 문서가 정렬된 문서보다 정확도가 높은 이유를 추론하라. 이것이 컨텍스트 설계에 주는 시사점은?
Initializer 패턴에서 feature list를 JSON으로 쓰는 이유는 무엇인가? Markdown으로 쓰면 어떤 문제가 생기는가?
MECW(실효 최대 컨텍스트 창)는 항상 공칭 최대보다 작다. 기업 AI 실패의 65%가 다단계 추론 중 컨텍스트 드리프트에서 비롯된다면, 에이전트 세션을 어떻게 설계해야 하는가? “스프린트” 패턴(5-10 메시지 짧은 상호작용 + 새 컨텍스트)과 연결하여 논하라.

실습 (Practicum)

토큰 사용량 측정

Claude Code 세션에서 /cost 명령을 실행하여 현재 세션의 토큰 사용량을 확인한다. 10턴 대화 후 다시 측정하여 증가량을 기록한다.

import anthropic

def count_tokens(messages: list) -> int:
    client = anthropic.Anthropic()
    response = client.messages.count_tokens(
        model="claude-opus-4-6",
        messages=messages
    )
    return response.input_tokens

Compaction 전후 비교

20턴 이상 대화한 세션에서 /compact 명령을 실행한다. 압축 전후의 토큰 수, 응답 품질, 작업 연속성을 비교 기록한다.
상태 파일 시스템 구축

fix_plan.md와 claude-progress.txt를 자동으로 업데이트하는 헬퍼 함수를 작성한다. Lab 05의 state_tracker.py를 참고한다.
Lab 05 연결

위 실험 결과를 바탕으로 Lab 05의 token_counter.py, context_manager.py, state_tracker.py, main.py 4개 모듈을 구현한다.

과제 (Assignment)

Lab 05: 컨텍스트 관리 실습

제출 마감: 2026-04-07 23:59

요구사항:

토큰 카운터 통합된 Ralph 루프 (ralph_with_context.sh)
Context Rot 시뮬레이션 및 측정 결과 그래프
자동 컨텍스트 초기화 로직 구현
상태 추적 시스템 (fix_plan.md + claude-progress.txt) 동작 증명

핵심 정리

Context Rot은 실증적 현상이다 — Chroma 연구: 18개 모델 모두에서 입력이 길어질수록 정확도 하락. 중간 위치에서 30%+ 저하.
1M 토큰 창이 해결책이 아니다 — 큰 창 = Context Rot이 발생할 공간이 더 넓어질 뿐. 실효 사용량은 60-70%.
Compaction은 토큰 기반 — 모델 최대의 ~75% 도달 시 자동 트리거. 최근 4개 메시지 보존, 나머지 요약.
Ralph의 fresh context가 루프 간 최선 — 루프 내부에서는 compaction, 루프 사이에서는 완전 초기화 + 상태 파일 전달.
토큰 40-70%가 낭비 — 모델 라우팅(Haiku 60-70%), prompt caching(read 0.1x), CLAUDE.md 200줄 이하로 절감.
Initializer 패턴 — JSON feature list + claude-progress.txt + init.sh 2-phase 구조로 상태를 결정론적으로 관리.
LLM Wiki 패턴 — 세션 단위 상태 파일을 넘어, LLM이 영구 지식 위키를 유지·관리하는 아키텍처. Ingest → Query → Lint 사이클로 지식을 축적.
지식 그래프 토큰 절감 — Graphify 같은 도구로 코드베이스를 그래프화하면 원본 대비 71.5배 토큰 절감 가능. LazyGraphRAG는 엔터프라이즈 규모에서 GraphRAG 비용의 0.1%로 유사 품질 달성.
인스트럭션 파일 수렴 — 모든 주요 코딩 도구(Claude Code, Codex CLI, Gemini CLI, Cursor, Copilot, Windsurf)가 독립적으로 파일 기반 컨텍스트 영속에 수렴. 설정 파일이 세션 간 컨텍스트 관리의 보편적 해법.
MECW < 공칭 최대 — 실효 최대 컨텍스트 창은 항상 공칭보다 작다. 기업 실패의 65%는 컨텍스트 공간 부족이 아닌 컨텍스트 드리프트에서 비롯. 짧고 집중된 세션 설계가 핵심.

더 읽을거리

Chroma: Context Window Research — 18개 모델 대상 Context Rot 실증 연구
Anthropic: Prompt Caching Documentation — 캐시 가격, TTL, 사용법
SkillReducer (arXiv:2603.29919) — 도구 설명 압축이 품질을 높이는 less-is-more 효과
Simon Willison: YAML vs Token-Saving Formats — 9,649건 실험, 익숙한 형식이 우수
Tam et al. “Let Me Speak Freely?” (arXiv:2408.02442) — 포맷 제약이 LLM 추론 성능에 미치는 영향 (10-15% 저하)
TOON Format Specification — Token Oriented Object Notation, 균일 배열 토큰 최적화
Karpathy: LLM Wiki — Building Persistent Knowledge Systems — LLM이 영구 지식 위키를 유지하는 패턴
Graphify — 코드베이스/문서를 지식 그래프로 변환, tree-sitter AST + Leiden 클러스터링, 71.5x 토큰 절감
Chroma Context-1 — 20B MoE 에이전틱 검색 모델, 0.94 pruning accuracy, self-editing context
ACON: Agent Context Optimization (arXiv:2510.00615) — 컨텍스트 압축을 정형 최적화로 접근, 26-54% 토큰 절감, 95%+ 정확도 유지
LazyGraphRAG — Microsoft Research — GraphRAG 인덱싱 비용의 0.1%로 동등 품질, Azure Discovery 배포
OpenAI Codex CLI — AGENTS.md — 도구 중립 계층적 인스트럭션 파일 표준
A2A Protocol (Google, 2025) — 에이전트 간 통신 프로토콜, MCP와 상호보완 (7주차에서 상세)