작은 코딩 에이전트는 코드 그래프를 한 홉까지만 활용한다

무엇인가

이 논문은 코드 저장소 구조를 모델이 모른다는 전제 아래 코딩 에이전트에 임베딩 검색과 코드 그래프 도구를 붙이는 관행을 SWE-bench Verified에서 검증한다. 문제는 GitHub 이슈가 지목한 코드와 실제 수정해야 할 코드 사이의 거리다. 저자들은 이 거리를 코드 그래프상의 최단 경로인 홉 깊이로 정량화하고, 깊이가 깊어질수록 작은 공개 가중치 모델이 어디서 실패하는지, grep·임베딩·그래프 도구가 각각 무엇을 기여하는지, 모델 내부에 저장소 그래프가 실제로 표현되는지를 세 부분으로 나눠 묻는다.

어떻게 동작하나

방법의 핵심은 통제 가능한 난이도 축이다. 각 SWE-bench Verified 인스턴스의 base commit에서 Python ast로 파일·클래스·함수 노드와 contain·import·invoke·inherit 엣지를 가진 무방향 타입 멀티그래프를 만든다. 이슈 텍스트에서는 정규식으로 back-tick, 식별자, traceback 프레임, dotted/snake/CamelCase 이름을 뽑아 멘션으로 삼고, 골드 패치가 바꾼 줄이 속한 가장 안쪽 정의를 타깃으로 삼은 뒤 BFS로 멘션과 타깃 사이 최단 거리를 계산해 hop0/1/2/3+로 나눈다. 이 라벨은 186/128/78/76개 과제에 각각 배정됐고, 멘션이 없는 31개와 도달 불가 1개가 별도로 남았다. 멘션이 있는 과제의 3분의 2인 314/469가 hop0 또는 hop1이다.

무엇과 다른가

실험은 로컬라이제이션만 수행하는 에이전트의 도구 집합을 같은 하네스에서 하나씩 제거·추가하는 방식이다. G는 grep·read_file·list_dir, E는 G에 함수/클래스 텍스트 임베딩 검색을 더한 것, T는 G에 이름 조회와 1~2홉 이웃 질의를 더한 것, ET는 전부다. 깊이 균형 160개 과제에서 네 팔을 비교하고, 이어 500개 전체 과제에서 Qwen3 0.6B~32B 여섯 크기(각 5회 디코딩), FP8 대조, Gemma 4 세 크기를 포함한 열 모델로 7만9천 에피소드를 돌렸다. 깊이 효과는 저장소·도구 집합·골드 함수 수·패치 크기를 통제한 GEE 로지스틱 모델로 추정했다.

어떻게 쓰나

결과는 깊이가 강한 실패 예측 변수임을 보여준다. 통제 후 홉이 하나 늘 때 함수 수준 정확한 로컬라이제이션의 오즈는 Qwen3-4B 0.472, Qwen3-8B 0.468, Gemma 4 E4B 0.544, Qwen3-32B 0.552로 모두 p≤10^-3였고, 0.6B~32B 전 구간에서 홉당 오즈비는 0.50~0.67이었다. 라벨은 호출 해석 방식에는 둔감했지만(κ=0.96~0.98), 멘션 추출에는 민감했다. back-tick과 traceback만 세는 엄격 추출기는 500개 중 311개 과제에서 멘션을 없앴다.

전제와 한계

도구 절제에서는 Qwen3-8B와 Gemma 4 E4B의 grep 단독 정확도가 각각 12.8%와 9.6% function Acc@10에 그쳤고 구조 도구가 이를 대략 두 배로 만들었다. Qwen3-4B에서는 임베딩 도구가 -1.1포인트로 기여하지 못했고 그래프 도구가 +8.1포인트[3.0,13.5]를 더했다. 그래프 도구의 이득은 이슈가 타깃을 직접 지목한 hop0의 이름 조회와 hop1의 한 번 확장에 집중됐고 hop2+에서는 줄거나 사라졌다. 에이전트가 확장을 연쇄한 에피소드는 12~14%뿐이었고, 그래프 팔의 깊이 기울기는 grep보다 유의하게 평탄하지 않았다. 규모 곡선에서는 구조 도구의 이득이 0.6B의 7~9포인트에서 1.7~4B의 17~21포인트로 정점을 찍고 32B에서 4~5포인트로 줄었으며, 파라미터 두 배당 오즈비는 0.77~0.82였다. 8B 이상에서는 이득의 절반가량이 타깃 발견이 아니라 제출 형식, 즉 정확한 엔티티 id에서 나왔고, 14B에서 32B로 갈 때의 하락은 grep 단독 정확도가 같은 상태에서 도구 호출률이 find_entity 96%에서 45%로 떨어진 탓이었다. 같은 4B 크기라도 체크포인트에 따라 임베딩 검색이 +17.6포인트를 주거나 전혀 주지 않았다. grep 단독 Qwen3-8B는 에피소드당 grep 10회, 40%가 스텝 한도 도달, 41%가 제출 없이 끝나는 검색 루프에 빠졌고 50스텝·40k 토큰 예산으로도 구제되지 않았다. 그래프 도구는 top-5 함수 문자열 중 85%를 정확한 엔티티 id로 제출하게 했지만 grep 단독은 47%였다. 고정 Qwen3-8B 수리 모델에 각 팔의 로컬라이제이션을 주면 160개 중 G/E/T/ET가 각각 6/13/12/13개를 해결했고 오라클 위치는 26개였다. 해결은 정확한 로컬라이제이션에 거의 전적으로 조건부였다(24~27% 대 1~2%).

모델 내부 표현 실험은 선형 프로브로 저장소 그래프가 가중치에 있는지 본다. 초기의 전역 쌍 프로브는 호출 엣지에 AUC 0.75~0.80을 냈지만 한쪽 정의만 보는 프로브와 피호출자의 파일 내 in-degree만으로도 비슷한 성능이 나와, 저자들은 앵커 내 랭킹과 in-degree 층화를 적용한 보수적 프로토콜을 도입한다. 그 결과 직접 호출 엣지는 Qwen3-4B에서 두 홀드아웃 폴드 AUC 0.74와 0.68, Qwen3-8B에서 0.73과 0.66으로 해독됐고, 실제 에이전트 대화 안에서도 0.61~0.66, 도구가 출력하지 않은 엣지에서도 0.59~0.60이었다. 그러나 한 줄 어휘 기준선은 0.99에 달했고, 어휘 단서를 제거한 2홉 엣지는 0.57에 그쳤으며 상속은 한쪽 정보 이상으로 해독되지 않았다. 저자들의 결론은 작은 에이전트가 가중치와 사용 양쪽에서 저장소를 한 홉, 그것도 대부분 어휘적인 그림으로만 갖고 있다는 것이다.

개발자 관점의 함의는 도구 설계와 평가 방식 모두에 걸린다. 작은 모델에는 정확한 이름 해석이 가장 값싸고 확실한 구조 도구이며, 에이전트가 한 번 확장하고 멈추므로 2홉 이상에서는 원시 1홉 엣지보다 2홉 폐쇄를 압축·랭킹해 주거나 다음 확장을 제안하는 도구가 더 유망하다. 임베딩과 그래프 도구는 서로 다른 경로로 정답을 드러내며 8B에서는 거의 가산적이지만 4B에서는 체크포인트별로 효과가 달라, 도구 집합을 더 큰 모델이나 같은 크기의 다른 체크포인트에서 물려받지 말고 검증해야 한다. 8B 이상에서는 제출 형식을 정규화하는 것만으로 도구 이득의 절반가량을 도구 없이 회복할 수 있고, SWE-bench Verified 집계는 hop0 37%와 hop3+ 15%를 섞으므로 hop3+ 버킷을 별도로 보고해야 한다. 한계도 분명하다. 주 실험 모델은 4~8B이고 메커니즘 실험도 그 범위에 머문다. 규모 곡선의 최대 모델은 non-thinking Qwen3-32B FP8로 이 과제에서 14B보다 강하지 않아 점근선으로 읽을 수 없고, Gemma는 E2B·E4B만 사용 가능했으며 12B 실행은 부분적이고 퇴화했다. 160개 평가 서브셋은 팔 간 비교 해상도를 ±5포인트로 제한하고 절반이 Django다. 홉 라벨은 이름 기반 정적 해석이라 낙관적이고 멘션 추출에 민감하며, T 팔 도구와 같은 그래프에서 만들어져 hop0/1 이점이 라벨 자체의 이점과 일부 겹친다. 로컬라이제이션만 평가해 탐색과 편집의 상호작용을 제거했고 수리 모델도 약해 수리 성능은 로컬라이제이션 가치의 하한에 가깝다. 프로브는 마지막 토큰 잔차 스트림과 선형 판독만 사용했고, Python 동적 디스패치는 그래프에 보이지 않아 실제 깊이를 과소평가하면서 정적 그래프 도구의 한계를 과대평가할 수 있다. 논문은 이 간극을 메우는 도구, 확장 연쇄 학습, 1홉 이상을 표현하는 모델을 열린 문제로 남긴다.