개요
LLM 코딩 에이전트에게 모든 맥락을 프롬프트나 일반 RAG로 계속 주입하면 **컨텍스트 부패(Context Rot)**가 발생한다. 컨텍스트가 비대해지고, 오래된 정보와 현재 작업 정보가 섞이며, 검색된 chunk가 실제 코드 변경의 의사결정 맥락을 충분히 담지 못한다.
Code-native memory는 에이전트 메모리를 코드베이스 artifact(VCS history, AST diffs, git-backed task graphs)에 뿌리내려서, 손실 많은 자연어 요약 대신 구조화된 표현을 사용한다. 세 가지 주요 설계가 스펙트럼을 이룬다.
1. Typed memory from VCS history (CommitDistill)
커밋, PR, 이슈에서 결정론적 추출기(deterministic extractor)로 구조화된 지식을 뽑아내고, budget-constrained retriever로 에이전트에 노출한다.
구성 요소:
- Deterministic extractor — 정규식 기반, embedding 불필요, 10,000 커밋을 4초 이내 처리
- Typed knowledge units: Facts (설정값, API 제약 등 단순 정보), Skills (절차적 지식, 마이그레이션 방법), Patterns (파일명 규칙, 에러 처리 등 반복 관례)
- Budget-constrained TF-IDF retriever — calibrated silence threshold(theta=2.5)로 out-of-distribution 질의에는 침묵
성능: 256자 쿼리 예산에서 hit-rate 0.750 (BM25 0.333, git log grep 0.083 대비). 단, headline LLM-as-judge metric에서는 통계적 유의차 없음. Budget-conditional optimization — 예산이 넉넉하면 BM25와 수렴.
적용 조건 (모두 필요):
- 고품질 커밋 관행 (conventional commits, 구조화된 PR 설명) — GitHub 커밋의 90%는 저품질
- 빡빡한 검색 예산
- 느리게 진화하는 코드베이스
- 충분히 큰 저장소 (작으면 raw git log로 충분)
역효과: 빠르게 진화하는 코드베이스에서 추출된 Pattern이 현재 관례와 충돌 → 확신에 찬 오답 생성. 결정의 대안(Decision Shadow)은 커밋에 기록되지 않으므로 복구 불가.
관련 논문: CommitDistill: A Lightweight Knowledge-Centric Memory Layer for Software Repositories (Chukkapalli et al. 2026)
2. AST-guided memory (CodeMEM)
자연어 요약은 구조적 관계를 잃는다 — “fixed pagination logic”이 어떤 함수/노드가 변경되었는지 알 수 없음. CodeMEM은 AST 표현을 메모리로 저장.
두 구성 요소:
- Code Context Memory — 각 검증된 변경 후 AST-informed 연산으로 저장소 상태 유지. 구조적 충돌 방지.
- Code Session Memory — AST diff 분석으로 잊혀진 컨텍스트 식별. 이전에 포기한 접근법으로 회귀(regression)를 기계적으로 탐지.
효과: instruction following 12.2%(current-turn) / 11.5%(session-level) 개선, 태스크당 2-3 라운드 감소. 라운드 감소가 실질적 이점.
역효과: DSL, 템플릿 시스템, 바이너리 포맷은 AST diff 불가. 설정 파일(YAML/TOML)은 AST 없음. AST 파서 통합 오버헤드 존재. 1-3턴짜리 작업에는 오버헤드가 순비용.
관련 연구: Tree-sitter 기반 지식 그래프 → 10× tokens 절약, 2.1× tool call 감소 (arXiv:2603.27277)
3. Git-backed task graphs (Beads)
에이전트가 세션마다 완료한 단계를 재발견하고 중복 계획을 생성하는 “50 First Dates” 문제 해결. Dolt 기반 DB를 git에 .beads/ 디렉토리로 커밋.
핵심 기능:
- 각 task: ID(hash), 상태(open/in_progress/blocked/closed), 우선순위(0-4), 의존성 엣지
bd ready— 블로커 없는 태스크 조회, 세션 시작 시 plan 파일 대신 사용--claim— atomic assignee + status 변경, 병렬 에이전트 충돌 방지- 종료된 태스크는 시간이 지나면서 의미 압축(semantic compaction)
역효과: 단일 컨텍스트 윈도우에 프로젝트 전체가 들어가면 TASKS.md 대비 도구 오버헤드. —claim은 watchdog 없음 → crash 시 태스크 stuck. 해시 ID도 merge conflict 완전 제거 불가.
비교 요약
| 접근법 | 저장 대상 | 검색 방식 | 예산 의존성 | 최대 이점 |
|---|---|---|---|---|
| CommitDistill | VCS history typed units | TF-IDF + silence threshold | 높음 (빡빡한 예산에서만 우위) | 검색 정밀도 |
| CodeMEM | AST representation | AST diff 비교 | 낮음 (세션 길이에 비례) | 라운드 감소 |
| Beads | Task graph (Dolt/git) | Dependency-resolved query | 낮음 | 작업 상태 추적 |
Key Takeaway
Code-native memory는 자연어 요약의 정보 손실을 구조화된 표현으로 대체한다. 그러나:
- Typed VCS memory는 budget-conditional optimization (좋은 커밋 관행 + 빡빡한 예산 필요)
- AST diffs는 라운드 감소가 핵심 (2-3턴 절약)
- Task graph는 세션 간 작업 상태 추적
- 세 substrate 모두 eviction/compaction 규율 필요
현실적 조언: “평범한 RAG가 통하지 않는 상황에서만 도입하라. 효과가 검증된 영역은 빡빡한 검색 예산 + 느린 코드베이스 + 긴 세션이다.”