개요
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가 통하지 않는 상황에서만 도입하라. 효과가 검증된 영역은 빡빡한 검색 예산 + 느린 코드베이스 + 긴 세션이다.”