코드는 메모리가 아니다: 코딩 에이전트 내부의 구조적 코드베이스 인덱스

코딩 에이전트(Coding agents)는 이제 LLM(대규모 언어 모델)과 작업 중인 저장소(repository)에 대한 검색(retrieval)을 교차하여 수행하며, 검색 구현 방식은 배포된 하네스(harness)에 따라 매우 다양합니다. 고정된 모델을 사용하는 고정된 코딩 에이전트 하네스 내에서, 구조적 코드베이스 인덱스(structural codebase index)를 추가하는 것이 실제로 비용이나 해결(resolve) 능력을 변화시킬까요? 우리는 Claude Opus 4.7을 전체 과정 동안 고정하고, 세 개의 시드(seed)에 대해, 누출 감사(leak-audited)가 수행된 작업별 샌드박스(sandbox) 내에서 SWE-PolyBench Verified 및 SWE-bench Pro를 대상으로 세 가지 실험군(인덱스가 포함된 하네스, 인덱스가 없는 동일 하네스, 그리고 에이전틱-그렙(agentic-grep) 비교군)을 실행했습니다. 하네스 내 절제 연구(ablation) 결과, 셀(cell)당 비용 페널티 없이 큰 로컬라이제이션(localization) 이득과 통계적으로 구분되는 해결(resolve) 이득을 얻었으며, 해결당 비용은 더 낮았습니다. 하네스 간 비교 검증 결과, 인덱스는 해결 또는 로컬라이제이션 측면에서 에이전틱-그렙(agentic-grep) 베이스라인 대비 퇴보하지 않았으며, 이 역시 비용 페널티가 없었습니다. 우리는 셀별 제외 장부(per-cell exclusion ledger), 누출 감사 스크립트(leak-audit script), 로컬라이제이션 추출기(localization extractor), 그리고 결과 데이터베이스를 공개합니다. 따라서 구조적 코드베이스 인덱스의 배포 문제는 실행 비용이 너무 비싼지(시드 전반에 걸쳐 인덱스는 에이전틱-그렙보다 해결당 비용($/solved)이 더 낮음)가 아니라, 작업 부하에 구조적 랭킹(structural ranking)이 효과를 발휘하는 다중 파일 변경(multi-file changes)이 포함되어 있는지 여부입니다.