저는 코딩 에이전트(coding agents)를 위한 로컬 메모리 레이어인 Greplica를 작업해 왔으며, 벤치마크 설정(benchmark setup)을 공유하고자 합니다. 흥미로운 점은 단순히 토큰 감소뿐만이 아니라, 분산(variance)에 있습니다.

기본적인 문제: 모든 새로운 코딩 에이전트 세션은 콜드 스타트(cold start) 상태로 시작됩니다. 변경 사항을 계획하기 전에, 에이전트는 종종 저장소(repo)에 대한 정신적 모델(mental model)을 재구축해야 합니다. 즉, 어떤 파일이 중요한지, 어떤 서브시스템(subsystem)이 해당 동작을 담당하는지, 이전의 어떤 결정이 구현을 제약하는지, 그리고 어떤 경로가 막다른 길인지 등을 파악해야 합니다.

이러한 오리엔테이션(orientation) 단계는 토큰, 시간, 그리고 도구 호출(tool calls) 비용을 발생시킵니다. 또한 무작위성(randomness)을 유발합니다. 두 개의 콜드 에이전트가 동일한 작업을 부여받더라도, 계획을 생성하기 전까지 저장소의 매우 다른 부분을 탐색할 수 있습니다.

Greplica는 에이전트에게 지속적인 저장소 메모리(persistent repo memory)를 제공함으로써 이를 줄이고자 합니다. Greplica는 저장소 사실(repo facts), 이전 세션의 학습 내용, 결정 사항, 제약 조건, 워크플로우(workflows), 그리고 코드 앵커(code anchors)를 로컬 SQLite 지식 그래프(knowledge graph)에 저장합니다. 그러면 에이전트는 다음과 같이 질문할 수 있습니다:

greplica graph context "<task-specific question>"

검색된 컨텍스트(context)는 진실로 취급되지 않습니다. 에이전트는 여전히 현재 코드를 읽어야 합니다. 핵심은 에이전트에게 더 나은 시작 지도(starting map)를 제공하는 것입니다.

벤치마크 설정 (Benchmark setup)
저는 공개 저장소의 실제 코딩 에이전트 세션을 포함하고 있는 SWE-chat을 기반으로 구축된 홀드아웃 계획 태스크(held-out planning tasks)에서 이를 테스트하고 있습니다.

각 사례에 대해:

1. 대상 저장소의 깨끗한 베이스 스냅샷(base snapshot)에서 시작합니다.
2. 이후 세션에서 홀드아웃 계획 태스크를 선택합니다.
3. 동일한 저장소의 2~4개 이전 세션으로부터 Greplica 메모리를 구축합니다.
4. 부트스트랩 패스(bootstrap pass)와 재현된 세션 업데이트(replayed session updates)를 통해 메모리를 구축합니다.
5. 동일한 홀드아웃 계획 태스크를 두 가지 모드로 실행합니다:

• 베이스라인(baseline): Greplica 컨텍스트 없음
• Greplica: 에이전트가 greplica graph context를 쿼리할 수 있음

6. 계획 점수(plan score), 토큰 사용량(token usage), 경과 시간(elapsed time), 도구 호출(tool calls)을 비교합니다.

중요한 제약 조건은 Greplica가 홀드아웃 정답을 보지 못한다는 것입니다. Greplica는 팀이 이전 개발 세션 전반에 걸쳐 축적했을 법한 것과 유사하게, 오직 이전의 저장소 이력(repo history)만을 전달받습니다.

현재 결과
전시된 사례 전반에 걸쳐, Greplica는 계획(planning) 토큰 사용량을 대략 40-50% 정도 절감하는 경우가 많습니다. 가장 강력한 강화된 실행(hardened run) 결과에서는 100 -> 100의 계획 점수를 유지하면서도 토큰은 75.0% 적게, 도구 호출(tool calls)은 52.9% 적게 사용하였으며, 140.4초를 절약했습니다.
일부 예시 행:

• swechat-gemini-voyager-sync-auth-bug: 점수 100 -> 100, 토큰 75.0% 감소, 도구 호출 52.9% 감소, 140.4초 단축.
• swechat-iptvnator-playback-layout-plan: 점수 64 -> 100, 토큰 44.6% 감소.
• swechat-marin-harbor-swe-eval-support: 점수 6 -> 100, 토큰 26.7% 감소, 도구 호출 33.3% 감소, 80.2초 단축.
• swechat-iptvnator-stalker-dev-server-plan: 점수 100 -> 100, 토큰 34.1% 감소.
• swechat-gemini-voyager-draft-input-plan: 점수 100 -> 100, 토큰 34.0% 감소.
  이 결과들을 아직 전역 평균(global averages)으로 제시하지는 않겠습니다. 이들은 메모리가 중요할 것으로 예상되는 사례들로부터 얻은 현재의 전시 결과(showcase results)입니다.

작동 원리에 대한 생각
절감 효과는 주로 반복적인 컨텍스트 재구성(context reconstruction)을 줄임으로써 발생합니다.
콜드 에이전트(Cold agent)는 다음과 같은 작업에 많은 예산을 소비합니다:

• 광범위한 rg 검색
• 가능성이 높지만 잘못된 파일 열기
• 그럴듯하지만 잘못된 경로를 택한 후 가정을 수정하기
  이전 세션에서 이미 지속적인 사실(durable facts)을 발견했다면, Greplica는 관련 파일, 서브시스템 경계(subsystem boundaries), 제약 조건(constraints), 주의 사항(gotchas), 그리고 이전의 구현 결정 사항과 같은 사실들을 조기에 검색할 수 있습니다.
  이는 코드를 검사해야 할 필요성을 없애는 것이 아니라, 첫 번째 검색 범위를 좁혀주는 역할을 합니다.

변동성 지점
이 부분이 제가 가장 흥미롭다고 느끼는 대목입니다.
콜드 에이전트는 단순히 평균 비용이 더 많이 들 뿐만 아니라, 변동성(variance)도 더 큽니다. 어떤 실행은 올바른 서브시스템에서 시작할 수도 있지만, 어떤 실행은 그럴듯하지만 무관한 경로를 쫓을 수도 있습니다. 또 다른 실행은 핵심 제약 조건을 뒤늦게 발견할 수도 있습니다. 그리고 더 많이 방황하는 실행일수록 에이전트를 혼란스럽게 만들고 더 낮은 품질의 계획을 내놓습니다.
저장소 메모리(Repo memory)는 이러한 분포를 좁혀주는 것으로 보입니다. 에이전트가 빈 저장소 모델 대신 근거가 있는 컨텍스트 패킷(grounded context packet)을 가지고 시작하기 때문에, 초기 몇 번의 움직임이 덜 무작위적입니다.

그것이 바로 제품의 핵심 가설(product thesis)입니다: 코딩 에이전트는 적절한 컨텍스트(context)를 가질 때만 추론할 수 있습니다.

확인해 보세요 - https://github.com/Autoloops/greplica
https://reddit.com/link/1ujuv5c/video/7lsarnkuagah1/player
/u/Comprehensive_Quit67 님이 제출함
[링크] [댓글]