FastContext: 코딩 에이전트가 별도의 저장소 탐색기(Repository Explorer)를 사용해야 하는 이유

코딩 에이전트(Coding agents)는 관련 코드가 어디에 있는지 파악하는 데 놀라울 정도로 많은 작업 시간을 소비합니다. 새로운 FastContext 논문과 프로젝트 저장소 (GitHub, Hugging Face)에서 Microsoft와 상하이 교통 대학교(Shanghai Jiao Tong University)는 이 탐색(exploration) 단계를 메인 해결 에이전트(solving agent)에 묶어두는 대신, 별도의 문제로 취급해야 한다고 주장합니다.

이는 작은 구조적 변화처럼 들릴 수 있지만, 실제 병목 현상을 해결합니다. 동일한 모델이 저장소를 검색하고 수정 사항을 작성하는 작업을 동시에 수행할 때, 컨텍스트(context)는 관련 없는 파일 스니펫(file snippets), 실패한 가설, 그리고 부분적으로만 유용한 노트들로 가득 차게 됩니다. FastContext는 저장소 탐색을 위한 특화된 서브 에이전트(subagent)로, 메인 에이전트가 필요로 하는 파일 경로와 라인 범위(line ranges)만을 반환합니다. 그 결과 워크플로우가 더 깔끔해지며, 연구진의 평가에 따르면 토큰 사용량이 줄어들고 엔드 투 엔드(end-to-end) 작업 성능이 향상되었습니다.

저장소 탐색이 별개의 문제인 이유

현대의 소프트웨어 작업은 단일 파일에 국한되는 경우가 거의 없습니다. 버그 리포트는 실패하는 테스트를 참조할 수 있지만, 그 원인은 유틸리티 모듈, 설정 파일, 또는 여러 단계의 간접 참조(indirection)를 거쳐야만 도달할 수 있는 코드 경로에 있을 수 있습니다. 에이전트가 무언가를 패치(patch)하기 전에 다음과 같은 질문에 답해야 합니다: 어떤 파일이 관련이 있는가? 어떤 심볼(symbols)이 연결되어 있는가? 진실의 원천(source of truth)은 어디인가?

FastContext의 저자들은 Mini-SWE-Agent의 궤적(trajectories)을 통해 이를 직접 측정했습니다. 분석 결과, 읽기 및 검색 작업이 모든 도구 사용 턴(tool-use turns)의 56.2%를 차지했으며, 메인 에이전트 전체 토큰의 46.5%를 소비했습니다. 이는 수정 사항에 대해 추론하는 데 쓰이지 않고, 증거를 국지화(localizing)하는 데 많은 컴퓨팅 자원이 소모되었음을 의미합니다. 더 나쁜 점은, 시스템이 두 단계를 분리하도록 설계되지 않는 한 이러한 모든 탐색 텍스트가 해결사(solver)의 히스토리에 남는다는 것입니다.

이것이 FastContext의 핵심 아이디어입니다. 하나의 모델에게 모든 것을 요구하는 대신, 한 모델은 탐색에 특화하고 다른 모델은 해결에 특화하도록 하는 것입니다.

FastContext가 실제로 수행하는 작업

FastContext는 경량화된 탐색 서브 에이전트 (exploration subagent)입니다. 자연어로 된 이슈 설명이나 저장소 컨텍스트(repository context) 요청을 받으면, Read, Glob, Grep과 같은 읽기 전용 도구 호출 (tool calls)을 병렬로 수행합니다. 긴 요약본을 반환하는 대신, 솔버 (solver)가 집중된 컨텍스트로 사용할 수 있는 파일 경로 및 라인 범위 (line ranges)의 압축된 세트를 출력합니다.

이러한 설계는 두 가지 이유로 중요합니다.

첫째, 컨텍스트 오염 (context pollution)을 제한합니다. 메인 에이전트는 탐색 과정에서 마주치는 모든 막다른 길을 계속 들고 다닐 필요가 없습니다. 대신 더 작은 증거 꾸러미 (evidence bundle)를 전달받으므로, 이후의 추론 (reasoning)이 더 쉬워집니다.

둘째, 검색 전략을 변화시킵니다. FastContext는 광범위한 첫 번째 턴 검색 (first-turn search), 이후 다회차 증거 수집 (multi-turn evidence gathering), 마지막으로 정밀한 인용 생성 (precise citation generation)을 수행하도록 훈련되었습니다. 논문에 따르면 탐색 모델 (explorer models)은 4B에서 30B 파라미터 규모에 걸쳐 있으며, 이는 이 작업이 반드시 사용 가능한 가장 큰 모델을 필요로 하는 것은 아니라는 유용한 점을 상기시켜 줍니다. 작업 범위가 충분히 좁기 때문에 잘 훈련된 작은 모델로도 효과적일 수 있습니다.

훈련 루프의 구성 방식

논문은 2단계 훈련 과정을 설명합니다.

첫 번째 단계는 지도 미세 조정 (supervised fine-tuning, SFT)입니다. 저자들은 강력한 참조 궤적 (reference trajectories)으로부터 탐색기를 부트스트랩(bootstrap)한 다음, 예시들을 세 가지 유형의 행동으로 필터링합니다:

광범위한 초기 검색을 위한 병렬 도구 호출 (Parallel tool calls)
증거 수집을 위한 다회차 궤적 (Multi-turn trajectories)
정밀한 인용을 위한 라인 범위 출력 (Line-range outputs)

이는 모델에게 무엇을 찾아야 하는지뿐만 아니라, 어떻게 찾아야 하는지를 가르치는 실용적인 방법입니다.

두 번째 단계는 작업 기반 보상 (task-grounded rewards)을 활용한 강화학습 (reinforcement learning, RL)입니다. 유창한 문장을 보상하는 대신, 시스템은 위치 파악 품질 (localization quality)과 구조화된 탐색 행동 (structured exploration behavior)에 보상을 줍니다. 즉, 이 모델은 길게 설명하는 것이 아니라, 올바른 코드를 찾아내고 사용 가능한 포인터 (pointers)를 반환하도록 최적화되어 있습니다.

이는 주목할 만한 패턴입니다. 많은 에이전트 시스템들이 해결사 (solver)를 더 똑똑하게 만듦으로써 성능을 개선하려고 시도합니다. 반면 FastContext는 검색 (search)과 해결 (solving) 사이의 인터페이스를 개선합니다. 이는 단순히 해결사의 크기를 키우는 것보다 종종 더 높은 투자 대비 수익 (return on investment)을 제공합니다.

평가 결과가 시사하는 점

FastContext는 SWE-bench Multilingual, SWE-bench Pro, 그리고 SWE-QA를 통해 평가되었습니다. arXiv 논문과 프로젝트 GitHub 리포지토리에 따르면, FastContext를 Mini-SWE-Agent에 통합했을 때 코딩 에이전트의 토큰 소비량을 최대 60%까지 줄이면서도 엔드 투 엔드 (end-to-end) 해결률을 최대 5.5%까지 향상시켰습니다.

이러한 조합이 흥미로운 부분입니다. 많은 시스템들이 품질을 희생함으로써 더 저렴해질 수 있고, 많은 시스템들이 더 많은 토큰을 사용함으로써 더 좋아질 수 있습니다. FastContext는 이 두 가지를 모두 목표로 합니다: 즉, 메인 에이전트의 컨텍스트 (context)는 줄이고, 작업 완료율은 높이는 것입니다. Hugging Face의 프로젝트 페이지에서도 커뮤니티 측면에서 동일한 결과를 요약하고 있으며, 이는 여러 매체를 통해 해당 주장을 더 쉽게 추적할 수 있게 해줍니다.

또한 논문은 이 탐색기 (explorer)가 독립적인 로컬라이제이션 (localization) 모델로서도 우수한 성능을 보인다고 보고합니다. 이는 중요한데, 성능 향상이 단순히 다른 프롬프트 (prompt) 형식이나 수동으로 조정된 파이프라인 (pipeline) 덕분만이 아니라는 것을 의미하기 때문입니다. 서브 에이전트 (subagent) 자체가 유용한 기술, 즉 저장소를 중요한 파일과 라인으로 빠르게 좁혀나가는 기술을 학습하는 것으로 보입니다.

코딩 에이전트 개발자들에게 주는 의미

FastContext는 에이전트 기반 소프트웨어 엔지니어링 (agentic software engineering)을 위한 더 넓은 설계 원칙을 제시합니다: 바로 **찾기 (finding)**와 **고치기 (fixing)**를 분리하는 것입니다.

개발자들에게 이는 몇 가지 실질적인 교훈을 시사합니다:

저장소 검색을 일급 시민 태스크 (first-class task)로 취급하십시오. 검색은 단순히 코딩을 위한 전주곡이 아닙니다. 검색은 그 자체로 고유한 실패 모드 (failure modes)를 가진 핵심 역량입니다.
전사 기록 (transcripts)이 아닌 증거 (evidence)를 반환하십시오. 해결사 (solver)에게는 전체 탐색 이력보다 파일 경로와 줄 번호가 더 필요할 때가 많습니다.
인터페이스에 맞춰 학습시키십시오. 하위 모델 (downstream model)이 구조화된 증거를 필요로 한다면, 상위 모델 (upstream model)이 정확히 그 구조를 생성하도록 학습시켜야 합니다.
태스크 성공률과 함께 토큰 경제성 (token economy)을 측정하십시오. 훌륭한 코딩 에이전트는 문제를 해결할 뿐만 아니라, 컨텍스트 윈도우 (context window)를 노이즈로 채우지 않고 문제를 해결해야 합니다.

FastContext의 가장 유용한 점은 또 다른 에이전트를 추가한다는 것이 아닙니다. 하나의 모델이 모든 역할을 수행하도록 강요하는 것을 멈출 때 에이전트 시스템이 개선될 수 있음을 보여준다는 점입니다. 검색 전문가 (search specialist)라면 설령 규모가 작더라도, 메인 해결사 (main solver)를 더 빠르고 신뢰할 수 있게 만들 수 있습니다.

이것이 소프트웨어 엔지니어링 에이전트가 나아가야 할 합리적인 방향입니다: 더 작은 책임 범위, 더 깔끔한 경계, 그리고 다음 단계에서 소비하기 더 쉬운 증거를 제공하는 것입니다.