AgSpec이 코딩 에이전트의 재사용 텍스트를 찾아 추론을 가속한다

무엇인가

코딩 에이전트는 하나의 사용자 요청을 여러 턴의 세션으로 처리하며, 그 안에서 코드를 고치는 coder, 테스트를 돌리는 executor 같은 역할별 에이전트가 번갈아 모델 호출과 도구 실행을 한다. 이런 파이프라인은 이전 시도의 코드, 로그, 패치를 반복적으로 다시 뱉어내기 때문에 별도 드래프트 모델 없이 기존 텍스트에서 이어붙일 토큰을 복사하는 검색 기반 추측 디코딩(retrieval-based SD)과 잘 맞는다. 문제는 기존 방식들이 에이전트 파이프라인의 두 가지 특징을 놓친다는 점이다. 첫째, 재사용할 텍스트가 코퍼스에 없거나(현재 호출의 프롬프트, 미리 만들어 둔 데이터스토어만 색인) 있어도 에이전트가 실제로 출력하는 형태와 달라 매칭되지 않는다. 둘째, 드래프트 길이를 고정 캡이나 매치 길이로 정해버려 에이전트별로 다르고 턴마다 변하는 실제 수용 길이(accept length)를 반영하지 못한다.

어떻게 동작하나

AgSpec은 검색 엔진 자체는 건드리지 않고 그 위에 코퍼스 정책과 드래프트 길이 정책을 얹는 프레임워크다. 코퍼스는 출처별로 셋으로 나뉜다. 세션 코퍼스는 현재 세션의 프롬프트·도구 출력·생성 토큰을 담아 호출과 에이전트, 턴을 넘어 공유되고, 워크스페이스 코퍼스는 세션 중 열린 저장소 아티팩트를 담으며 접근할 때마다 커진다. 글로벌 코퍼스는 세션과 무관한 정적 참조 텍스트로 서빙 전에 만들어 고정되고, 세션·워크스페이스 코퍼스는 세션이 끝나면 버려지는 라이브 코퍼스다. 핵심은 워크스페이스 아티팩트를 에이전트가 읽은 형태가 아니라 출력하는 형태로 색인한다는 것이다. unified diff 편집에서는 유지되는 줄에 공백, 삭제되는 줄에 마이너스가 붙으므로 AgSpec은 파일 원본과 함께 모든 줄에 공백을 붙인 사본, 모든 줄에 마이너스를 붙인 사본을 넣어 coder가 패치에 복사하는 줄이 반드시 하나와 매칭되게 한다. 전체 파일을 도구 호출로 쓰는 스캐폴드라면 개행·따옴표를 이스케이프한 사본을 하나 더 넣는다. 검색 시에는 같은 접미사를 세 코퍼스에 질의해 가장 긴 매치를 고르되 라이브 코퍼스끼리는 더 긴 쪽이 이기고 동률이면 세션을 택하며, 글로벌 코퍼스는 라이브 매치보다 마진 δ만큼 더 길어야 선택된다. 매치가 여러 위치에 있으면 글로벌·세션 코퍼스는 다음 세 토큰 기준 최빈 그룹을, 워크스페이스는 첫 번째 발생을 고른다.

무엇과 다른가

드래프트 길이는 K_i = clip(round(α(a_i)·m_i), 1, K_max(M,a_i))로 정한다. m_i는 매치 길이, α는 에이전트별 온라인 스케일, K_max는 대상 모델 M과 에이전트 a에 대한 오프라인 프로파일링 캡이다. 캡은 글로벌 코퍼스를 만들 때 쓴 궤적을 재생해 각 검색 스텝에서 재사용 가능한 길이 R(기록된 이어짐과 일치하는 검색 토큰 수)의 분포를 구하고, k번째 드래프트 토큰이 수용될 확률 Pr(R≥k|M,a)가 검증 비용을 정당화하는 임계 λ 이상인 마지막 위치로 정한다. 예를 들어 λ=0.1이고 11번째 토큰 수용 확률이 0.12, 12번째가 0.09라면 캡은 11이 된다. 온라인 스케일은 α ← α + η(τ − I[A_i < D_i])로 갱신되는데, 이는 분위 손실에 대한 확률적 서브그래디언트 스텝으로 R_i/m_i의 τ-분위를 추적한다. τ=1−λ로 두면 캡의 손익분기점과 목표가 맞춰진다. 완전 수용된 드래프트가 캡에 도달한 경우는 관측이 검열되므로 갱신을 건너뛰고, 스케일은 서버에 남아 세션을 넘어 유지된다.

어떻게 쓰나

평가는 Devstral-24B, Gemma3-27B, Qwen3.6-27B 세 모델에서 SWE-bench Verified와 TeamBench 두 저장소 수준 벤치마크로 진행했다. 비교 대상은 자기회귀(AR) 디코딩, PLD, REST, FastCoder, SuffixDecoding, SAM-Decoding, EAGLE-3다. AgSpec은 vLLM 위에 SAM-Decoding의 서픽스 오토마타(AgSpec-SAM)와 SuffixDecoding의 서픽스 트리(AgSpec-Suffix) 두 엔진으로 구현했고, 최대 드래프트 길이는 배치 1에서 64, 배치 16에서 24다. 모든 평가 설정에서 최고 또는 두 번째로 높은 처리량을 냈고 AR 대비 배치 1에서 2.27~4.37배, 배치 16에서 1.08~4.76배를 기록했다. 평균적으로 가장 빠른 기존 기법보다 처리량이 18.0% 높았고, SWE-bench Verified 배치 1의 Devstral에서 기존 최고 대비 1.36배로 가장 큰 격차를 냈다. 엔진별로 보면 SuffixDecoding에 얹었을 때 처리량 16.5%, 수용 길이 18.5%가 올랐고 SAM-Decoding에 얹었을 때는 처리량 64.6%, 수용 길이가 거의 두 배가 됐다. SAM-Decoding이 열두 설정 모두에서 SuffixDecoding에 뒤졌지만 AgSpec-SAM은 그중 아홉 설정에서 앞섰다.

전제와 한계

코퍼스 구성의 기여도는 트레이스 기반 시뮬레이션으로 분리했다. 호출 단위 코퍼스를 세션 코퍼스로 바꾸면 수용 길이가 1.6~2.1배로 가장 크게 올랐고, 워크스페이스 코퍼스는 단독으로 26~47%, 세션 코퍼스 위에 더해도 2.2~7.0%를 보태 결국 글로벌 코퍼스만 쓸 때의 2.9~4.8배가 됐다. 출력 형태 색인은 첫 턴에서 coder의 수용 길이를 13~39% 올렸지만 자기 패치가 세션 코퍼스에 쌓이는 두 번째 턴부터 효과가 줄어 다섯 번째 턴에는 3% 이하로 떨어졌다. 드래프트 길이 제어는 배치 크기에 따라 이득이 뒤집힌다. 고정 캡 K=32는 배치 1에서 K=8보다 14% 빨랐지만 배치 16에서는 30% 느렸고, AgSpec은 두 배치 모두에서 가장 빨라 K=8보다 각각 25%, 16% 앞섰다. K=32는 스텝당 11~26개 토큰을 거부한 반면 AgSpec은 최대 6개만 거부하면서 K=32가 수용한 토큰의 83~89%를 유지했다. 온라인 스케일만 단독으로 켠 배치 16 실험에서는 거부 비율이 78%에서 50%로 줄며 처리량이 66% 올랐고, 특정 coder 호출에서는 스텝당 약 26토큰을 쓰면서 수용이 2개 미만이던 것이 약 4토큰으로 줄어 거부 토큰이 81.1% 감소하고 스텝은 11개만 늘었다.

저장소나 명시적 멀티에이전트 구조가 없는 워크로드에서도 효과가 유지된다. 저장소가 없는 LiveCodeBench에서 AgSpec은 AR 대비 4.87~7.94배 처리량을 냈고 가장 빠른 기존 기법보다 35~145% 높았다. 단일 에이전트가 모든 역할을 맡는 Terminal-Bench에서는 가장 빠른 기존 기법보다 9.3~27.2% 높은 처리량, 해당 검색 엔진 베이스라인보다 16.7~34.3% 높은 수용 길이를 기록했다. 이때는 역할별 캡 대신 공유 캡과 단일 α 테이블을 쓴다.

실무 관점에서 AgSpec은 학습이 필요 없는 가속 프레임워크이고 기존 검색 엔진을 수정하지 않고 얹을 수 있다는 점이 가장 실용적이다. 다만 조건이 있다. 엔진이 여러 코퍼스를 검색하고 스텝별 드래프트 길이를 받아들일 수 있어야 하며, 에이전트별 캡을 만들려면 대상 모델과 에이전트 조합의 궤적을 미리 모아 오프라인 프로파일링을 해야 한다. 배치 크기가 커질수록 긴 드래프트의 이득이 사라지므로 서빙 배치 크기에 맞춰 캡과 스케일을 확인해야 하고, 스캐폴드의 출력 형식(unified diff, 전체 파일 쓰기, 검색-치환 등)을 알아야 출력 형태 색인을 제대로 구성할 수 있다.

저자가 밝힌 전제와 한계는 다음과 같다. 온라인 스케일 갱신이 분위 손실의 확률적 서브그래디언트 스텝이라는 해석은 특정 이상화 가정 아래에서 성립한다. 글로벌 코퍼스는 평가 과제와 겹치지 않는 별도 과제(SWE-bench Verified 70개, TeamBench 213개)의 턴 로그로 만들어 고정했고, 세션별 코퍼스는 세션 사이에 초기화했다. 윤리 항목에서 저자들은 워크스페이스·세션 코퍼스에 민감한 프롬프트, 저장소 내용, 도구 출력이 들어갈 수 있으므로 배포 시 세션별 코퍼스 접근을 제한하고 다른 세션에 노출하지 말며 세션이 끝나면 폐기하라고 명시한다. 출력 분포 자체는 대상 모델이 검증하므로 바뀌지 않는다.