CORVUS: 코딩 에이전트의 파일 읽기를 동기화해 컨텍스트를 줄이는 구조
CORVUS: Context Optimization and Reduction Via Underlying Synchronization for LLM Coding Agents
TL;DR Highlight
파일 읽기를 매번 동기화해 입력 토큰 9–50% 줄이고 통과율은 유지
Who Should Read
코딩 에이전트를 직접 만들면서 토큰 비용과 오래된 파일 내용 때문에 편집이 실패해 고민인 백엔드 개발자
Core Mechanics
- 파일을 읽을 때마다 스냅샷이 쌓인다
- 보통 에이전트는 read_file 결과를 대화 기록에 그대로 붙인다.
- 파일이 나중에 바뀌어도 기록 속 내용은 고쳐지지 않는다.
- 중복 읽기와 낡은 내용이 문제다
- Claude Sonnet 4는 파일 읽기의 26%(3,207건 중 834건)가 이미 읽은 파일이었다.
- 낡은 스냅샷 때문에 이미 없는 텍스트를 바꾸려다 편집이 실패하기도 한다.
- 읽기와 내용을 분리했다
- read_file 대신 sync_file 도구를 쓰면 파일을 목록에만 등록하고 "sync: 경로" 마커만 기록에 남긴다.
- 매 사이클 시작 전에 등록된 파일의 최신 내용을 프롬프트 끝에 한 번만 넣는다.
- 프롬프트에 파일당 최신본 하나만 있다
- 파일 내용은 기록 중간이 아닌 별도의 synced context 블록에 들어간다.
- 에이전트나 사람이 파일을 고쳐도 다음 사이클에 바로 반영된다.
- 비용은 줄고 통과율은 비슷했다
- 입력 토큰 9–50%, 최종 프롬프트 길이 15–32%, 추론 사이클 최대 37% 감소했다.
- pass@1은 모델 4개 중 3개가 소폭 올랐고 1개는 1.22%p 내렸다.
Evidence
- Sonnet 4.5 비용이 절반으로
- SWE-PolyBench Verified에서 인스턴스당 $5.27에서 $2.62로 50.28% 줄었다.
- 사이클은 45.03에서 28.22로 37.33% 줄었다(베이스라인 대비).
- 입력 토큰과 지연 시간 감소
- 입력 토큰은 모델·벤치마크별로 베이스라인 대비 9–50% 줄었다.
- 실행 시간은 Sonnet 4.5 기준 최대 40% 줄었다.
- 중복 읽기 최대 86% 감소
- Sonnet 3.7의 PolyBench Verified에서 중복 읽기가 베이스라인 대비 크게 줄었다.
- 전체 모델에서 22–86% 감소했다.
- 통과율은 비슷했다
- pass@1이 Sonnet 3.7은 19.20%에서 20.07%, Sonnet 4는 25.83%에서 24.61%, Sonnet 4.5는 28.10%에서 29.49%, Qwen 480B는 20.07%에서 21.12%였다.
How to Apply
- 파일 읽기 중복 비율부터 재기
- 오늘 로그에서 같은 경로를 두 번 이상 read한 비율을 센다.
- 논문처럼 중복이 20%대면 동기화 도입 가치가 있다.
- read_file을 sync_file로 바꾸기
- 도구가 파일 내용 대신 "sync: 경로" 마커만 반환하게 하고 경로를 집합에 등록한다.
- 읽기 도구만 바꾸고 나머지 도구와 프롬프트는 그대로 둔다.
- 매 턴 앞에서 파일 최신본 주입하기
- LLM 호출 직전에 등록된 파일을 디스크에서 다시 읽는다.
- 내용은 프롬프트 맨 끝의 synced context 블록에 파일당 하나만 넣는다.
- 기존 압축과 같이 켜고 pass@1 확인하기
- 요약이나 관찰 마스킹을 쓰고 있다면 그대로 두고 CORVUS만 추가한다.
- 같은 태스크로 통과율과 비용을 비교해 회귀를 확인한다.
Try It
# Claude Code 또는 Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전)
우리 코딩 에이전트 코드를 CORVUS 방식으로 바꾸고 싶다. 아래 구조로 수정안을 제시해줘.
1. read_file 도구를 sync_file(path)로 교체한다. 호출 시 경로를 synced 집합에 추가하고 "sync: {path}"만 반환한다.
2. 매 LLM 호출 직전에 synced 집합의 모든 파일을 디스크에서 다시 읽어 synced context 블록을 만든다.
3. 프롬프트는 시스템 메시지, 도구 스키마, 대화 기록, synced context 순서로 붙인다.
4. 파일당 최신본이 하나만 들어가게 한다.
대상 코드:
{{에이전트 루프 코드}}
이어서 해 볼 것: 수정 전후로 같은 태스크 10개를 돌려 입력 토큰, 사이클 수, 통과 여부를 표로 비교해줘.Terminology
관련 논문
같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나
긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복
가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격
가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)
Harness Engineering 101: LLM은 뇌, harness는 몸
에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다
Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크
모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다
해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유
경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다
tmux와 Claude Code: 세션, send-keys, 그리고 한계선
tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다
Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트
잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓
Original Abstract (Expand)
LLM coding agents operate by constructing trajectories that accumulate reasoning, tool calls, and results to enable multi-step decision-making. However, the conventional append-only trajectory architecture found in practice tightly couples file-read actions with their observations, capturing snapshots that become permanently fixed in the chronological history. As files change through agent edits or concurrent human modifications, these snapshots become stale, causing reasoning errors and causing agents to redundantly re-read files, with each re-read appending yet another copy to the trajectory. To mitigate this, we propose CORVUS, a novel trajectory architecture that decouples file-read actions from their observations by maintaining a synchronized registry of relevant files and injecting only their current contents at each reasoning cycle. This structural change produces significantly lighter-weight trajectories that remain synchronized with the actual codebase state by construction, eliminating redundant file copies and stale snapshots that bloat conventional trajectories. We evaluated CORVUS on SWE- POLYBENCH_VERIFIED and SWE-BENCH PRO across four LLMs, achieving 9-50% reduction in average input tokens per task, 15-32% shorter final prompts, and up to 37% fewer reasoning cycles while maintaining comparable pass rates.