🤖 AI

Exploration Structure in LLM Agents for Multi-File Change Localization

이 논문은 소프트웨어 저장소 내 다중 파일 변경 사항을 국지화하기 위한 비선형적, 도메인 범위 지정 병렬 에이전트 탐색 프레임워크를 제안하고 평가하며, 이것이 선형 순차적 접근 방식보다 성능이 크게 뛰어나고 SWE-Bench Pro와 같은 벤치마크에서 훨씬 더 큰 모델들에 대해 경쟁력 있는 결과를 달성함을 입증한다.

원저자: Akeela Darryl Fattha, Kia Ying Chua, Lingxiao Jiang, Laura Wynter

게시일 2026-06-11

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Akeela Darryl Fattha, Kia Ying Chua, Lingxiao Jiang, Laura Wynter

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 고장 난 기계를 고치려는 탐정이라고 상상해 보세요. 이 기계는 거대한 소프트웨어 프로젝트(마치 거대한 코드 도서관 같은 것)입니다. 누군가 버그를 보고했습니다. 당신의 임무는 문제를 해결하기 위해 도서관의 정확히 어떤 페이지들을 다시 써야 하는지 찾아내는 것입니다.

이 논문은 서로 다른 "AI 탐정들"이 어떻게 그 페이지들을 찾아내는지에 대해 다룹니다. 연구진들은 탐정이 얼마나 "똑똑한가"보다 탐정이 어떻게 "탐색하는가"가 더 중요한지를 확인하고 싶어 했습니다.

다음은 이 연구의 내용을 쉬운 비유를 들어 정리한 것입니다.

문제점: "한 번에 한 단계씩"의 함정

현재 대부분의 AI 도구들은 도서관을 한 번에 한 통로씩 지나가는 탐정처럼 행동합니다. 선반 하나를 골라 책을 읽고, 그다음 선반으로 이동하는 식입니다.

결함: 만약 버그가 도서관의 세 가지 다른 구역(예: 주방, 정원, 다락방)에 섞여 있는 문제라면, 한 번에 한 통로씩만 걷는 탐정은 주방에 갇혀 시간을 다 쓰거나 돈을 다 써버려서 정원과 다락방은 확인조차 하지 못할 수도 있습니다.
논문의 아이디어: 만약 걷는 대신, 주방, 정원, 다락방을 동시에 점검하도록 세 명의 서로 다른 전문가를 보내면 어떨까요?

실험: "Ansible" 도서관

연구진은 이 테스트를 Ansible(매우 크고 체계적인 도서관이라고 생각하세요)이라는 특정 소프트웨어 프로젝트를 대상으로 진행했습니다. 그들은 AI에게 버그 리포트를 주고 수정이 필요한 파일 목록을 작성하라고 요청하는 테스트를 만들었습니다.

그들은 네 가지 유형의 탐정을 비교했습니다:

"책벌레" (일반 LLM): 많은 책을 읽었지만 이 특정 도서관 안에는 한 번도 들어가 본 적이 없는 똑똑한 AI입니다. 기억에 의존하여 추측해야 합니다.
"단독 탐험가" (RLM): 도서관 열쇠와 노트를 받은 AI입니다. 안으로 걸어 들어가 문을 열고, 파일을 하나씩 읽으며 메모를 작성합니다.
"전문가 팀" (도메인 에이전트 - 새로운 아이디어): 도서관의 구역(주방, 정원, 다락방)을 먼저 파악하는 AI 매니저가 있습니다. 버그가 들어오면, 매니저는 즉시 각 관련 구역으로 서로 다른 전문가를 보내 병렬로 작업하게 합니다.
"슈퍼 전문가" (Codex): 벤치마크로 사용된 매우 크고 비싸며 강력한 AI 탐정입니다.

주요 발견 사항

1. 팀워크가 혼자 걷는 것보다 낫다
"전문가 팀" 방식이 훨씬 큰 차이로 승리했습니다. 비록 더 작고 저렴한 AI 모델을 사용했음에도 말입니다.

비유: 경기장에서 잃어버린 열쇠를 찾는다고 상상해 보세요. "단독 탐험가"는 혼자 경기장을 돌아다니다 지쳐버립니다. "팀"은 관중석, 경기장, 매점 등에 사람들을 동시에 보냅니다. 그들은 훨씬 더 빠르고 정확하게 열쇠를 찾아냅니다.
결과: 팀 방식은 더 큰 뇌(더 강력한 AI 모델)를 가진 단독 보행자보다 올바른 파일을 훨씬 더 잘 찾아냈습니다.

2. 탐정에게 열쇠를 주는 것이 역효과를 낼 수 있다
연구진은 AI에게 파일 시스템에 직접 접근할 수 있는 권한(열쇠를 가진 "단독 탐험가")을 주는 것이 도움이 될 것이라고 생각했습니다. 놀랍게도 이는 종종 상황을 악화시켰습니다.

비유: 만약 탐정에게 거대한 창고 열쇠를 준다면, 그들은 실제 고장 난 부분을 찾는 것을 잊은 채 수천 개의 무관한 상자들(테스트 파일이나 오래된 초안 같은 것들)을 구경하느라 정신이 팔릴 수 있습니다. 그들은 "노이즈"에 압도당합니다.
결과: 직접 접근 권한을 가진 AI는 종종 너무 많은 잘못된 파일을 예측하여 정확도를 떨어뜨렸습니다. "팀" 방식은 더 똑똑했는데, 왜냐하면 정확히 어느 구역을 봐야 하는지 알고 불필요한 것들은 무시했기 때문입니다.

3. 더 많은 에이전트가 항상 더 나은 결과를 가져오는 것은 아니다
연구진은 만약을 대비해 팀이 필요 이상의 더 많은 전문가를 소집하도록 강제해 보았습니다.

비류: 이는 작은 촛불을 끄기 위해 소방대 전체를 호출하는 것과 같습니다. 불을 더 빨리 끄는 것이 아니라, 단지 더 많은 비용(컴퓨터 토큰)을 쓰고 많은 혼란을 야기할 뿐입니다.
결과: 더 많은 에이전트를 부르는 "공격적인" 방식은 버그를 찾는 데 도움이 되지 않았으며, 단지 자원을 낭비할 뿐이었습니다.

4. "문서화의 사각지대"
AI가 아무리 똑똑하더라도, 모두가 문서 파일(사용 설명서)을 찾는 데 어려움을 겪었습니다.

비유: 사용자가 "빨간 버튼이 작동하지 않아요"라고 말하면, AI는 빨간 버튼을 고쳐야 한다는 것을 압니다. 하지만 AI는 설명서 또한 "빨간 버튼은 이제 고장 났다"라고 업데이트해야 한다는 사실을 깨닫는 경우가 드뭅니다. 버그 리포트에 설명서에 대한 언급이 없었기 때문에 AI는 이를 무시했습니다.
결과: 이것은 숨겨진 의존성입니다. AI에게는 "버튼을 고친다면, 반드시 설명서도 확인해야 한다"라는 규칙이 필요합니다. 사용자가 명시적으로 요청하지 않더라도 말이죠.

결론

이 논문은 AI가 코드베이스를 어떻게 탐색하느냐가 AI가 얼마나 똑똑하냐만큼 중요하다는 결론을 내립니다.

작고 잘 조직된 전문가 팀(도메인 에이전트)은 목적 없이 헤매는 거대하고 강력한 AI를 이길 수 있습니다.
그러나 최고의 AI 팀이라 할지라도, 버그 리포트가 명시적으로 요청하지 않는 한, 설명서 업데이트와 같은 "보이지 않는" 변경 사항을 찾는 데는 여전히 어려움을 겪습니다.

요약하자면: 구조가 원시적인 힘보다 우위에 있습니다. 탐색 과정을 조직화하는 것이 복잡한 소프트웨어 버그를 해결하는 핵심입니다.

기술 요약: LLM 에이전트의 다중 파일 변경 로컬라이제이션을 위한 탐색 구조

문제 정의

소프트웨어 엔지니어링 이슈는 드물게 단일 파일의 변경만을 포함합니다. 버그를 해결하려면 여러 서브시스템(예: CLI, 하위 라이브러리, 플러그인, 문서 등)에 걸친 수정이 필요합니다. 현재의 대규모 언어 모델(LLM) 에이전트는 일반적으로 한 번에 하나의 디렉토리나 파일을 방문하는 선형적, 순차적 탐색 전략을 채택합니다. 저자들은 이러한 선형적 접근 방식이 여러 서브시스템에 걸친 다중 파일 변경에 있어 구조적 불일치를 초래한다고 가정합니다. 만약 에이전트가 첫 번째 서브시스템을 탐색하는 동안 스텝(step)이나 토큰 예산을 모두 소진한다면, 필수적인 "골드(gold)" 파일들이 포함된 후속 서브시스템은 검토되지 못할 수 있습니다.

본 논문은 세 가지 핵심 연구 질문을 다룹니다:

선형적 탐색이 다중 파일 변경에 있어 구조적으로 제한적인가, 아니면 강력한 모델이 더 나은 스텝 선택을 통해 이를 보완할 수 있는가?
에이전트에게 가공되지 않은 파일 시스템 접근 권한을 부여하는 것이 로컬라이제이션 성능을 확실히 향상시키는가, 아니면 탐색 오류와 과잉 예측을 유발하는가?
공격적인 다중 에이전트 협업을 강제하는 것이 재현율(recall)을 개선하는가, 아니면 무관한 서브시스템으로부터 노이즈를 주입하는가?

방법론

벤치마크 구축

본 연구는 SWE-BENCH PRO에서 파생된 **지속 세션 벤치마크(persistent-session benchmark)**를 활용하며, ansible/ansible 저장소를 대상으로 합니다.

범위: 세 가지 타임 윈도우를 구성했습니다: 2020년 5월~~11월(원래의 큐레이션 세트), 2025년 4월~~9월, 2026년 1월~5월.
안정성: 모든 인스턴스는 단일 베이스 커밋에 고정되어 저장소 상태와 탐색 비용을 일정하게 유지합니다.
골드 세트(Gold Sets): 저자들은 큐레이션된 SWE-BENCH PRO 골드 세트(수동으로 선택된 소스 파일)와 확장된 PR 기반 골드 세트(테스트 및 변경 로그를 포함하여 해결된 Pull Request에서 수정된 모든 파일)를 비교합니다.
지표: 주요 지표로는 Micro-F1, All-Gold rate(모든 정답 파일을 예측한 인스턴스의 비율), 그리고 인스턴스당 Macro F1이 포함됩니다.

실험 시스템

저자들은 대부분의 변형 모델에 동일한 작은 Haikiku급 모델을 사용하여 탐색 구조를 기본 모델 역량으로부터 분리하여 네 가지 계열의 LLM 시스템을 비교합니다:

Plain LLM (저장소 접근 없음): 저장소 구조에 대한 사전 학습된 지식에만 의존하는 단일 API 호출입니다.
Single-Agent Recursive Language Model (RLM): 순차적인 파일 시스템 접근(예: os.listdir, grep)을 허용하는 지속적인 Python REPL을 가진 에이전트입니다. 이는 도메인 특화 없이 순차적 탐색의 효용성을 테스트합니다.
Domain-Agent System (제안된 방식): 다음을 특징으로 하는 다중 에이전트 아키텍처입니다:
- 초기화: 루트 코디네이터가 저장소를 탐색하여 일관된 유지보수 영역(예: cli/, module_utils/, docs/와 같은 서브시스템)을 식별하고 각 영역을 위한 지속적인 도메인 에이전트를 생성합니다.
- 쿼리 시점: 코디네이터는 할당된 영역을 탐색하기 위해 관련 도메인 에이전트들을 병렬로 파견합니다.
- 제한된 I/O: 대용량 파일과 디렉토리 목록은 프로그래밍 방식으로 관리됩니다. 토큰 고갈을 방지하기 위해 압축된 프리뷰나 특정 라인 범위만이 LLM 컨텍스트에 들어옵니다.
- 절제 실험(Ablations): 변형 모델로는 "no-spawn"(레지스트리는 존재하지만 병렬 파견은 없음)과 "nudged"(강제적인 공격적 협업)가 포함됩니다.
External CLI Baseline: 훨씬 더 큰 프런티어 모델인 Codex 5.5 High를 사용하여 상한 참조값을 설정합니다.
BM25 Baseline: $K$ 를 1에서 30까지 스윕(sweep)하여 정밀도-재현율 엔벨로프를 생성하는 고전적인 렉시컬 검색 시스템입니다.

주요 기여 및 결과

1. 탐색 구조는 결정적인 요소이다

저장소 서브시스템을 따라 탐색을 병렬화하는 Domain-Agent 방식은 모든 Haiku급 모델 중 가장 높은 Micro-F1을 달성했습니다.

큐레이션된 2020년 벤치마크에서, Domain-Agent (Haiku)는 0.447의 Micro-F1을 달성하여, Plain LLM (Haiku)의 0.199와 Single-Agent RLM (Haiku)의 0.151을 크게 앞질렀습니다.
Domain-Agent 시스템은 더 작은 모델을 사용함에도 불구하고 훨씬 더 큰 Codex 5.5 High(큐레이션 0.422, PR 기반 0.523)와 경쟁할 만한 수준입니다.
결과: 선형적 탐색(RLM)은 구조적으로 제한적이며, 효과적인 다중 파일 로컬라이제이션을 위해서는 병렬적이고 도메인에 국한된 탐색이 필요합니다.

2. 나이브한 파일 시스템 접근은 성능을 저하시킬 수 있다

더 많은 접근 권한이 더 나은 성능을 보장한다는 직관과는 반대로, 동일한 Haiku 모델을 사용할 때 단일 에이전트에게 가공되지 않은 파일 시스템 접근 권한을 부여하는 것은(RLM) Plain LLM보다 로컬라이제이션 성능을 저하시켰습니다.

RLM (Haikkui): Micro-F1 0.151.
Plain LLM (Haiku): Micro-F1 0.199.
원인: RLM은 테스트 파일을 과잉 예측하고 무관한 계층 구조로 탐색을 진행하여, 컨텍스트 예산을 소진하고 거짓 양성(false positive)을 유발하는 경향을 보였습니다. 사전 학습된 구조적 지식에 의존하는 Plain LLM은 더 보수적이고 정밀했습니다.

3. 강제적 협업은 도움이 되지 않는다

코디네이터가 더 많은 에이전트를 호출하도록 강제하는 것("nudged" 변형)은 재현율을 유의미하게 개선하지 못했으나, 토큰 비용을 크게 증가시켰습니다(약 16M에서 25M 토큰으로).

무분별한 생성은 추가적인 골드 파일을 복구하지 못한 채 무관한 서브시스템으로부터의 노이즈를 도입했습니다.
결론: 적응형 디스패치(관련된 도메인만 호출)가 강제적이고 공격적인 협업보다 우수합니다.

4. 문서 공동 진화 격차 (Documentation Co-Evolution Gap)

모든 아키텍처(대형 Codex 모델 포함)에서 문서 파일(docs/docsite/)에 대한 체계적인 실패가 관찰되었습니다.

미검출률(Miss Rate): 문서 파일은 코드 파일보다 훨씬 높은 73%의 총 미검출률을 기록했습니다.
이유: 이슈 설명은 종종 소스 코드 동작의 변화를 설명하면서도 문서를 업데이트해야 할 필요성을 명시적으로 언급하지 않습니다. 이는 현재의 탐색 정책으로는 해결할 수 없는 잠재적 의존성(논리적 결합)이며, 입력 텍스트에 "신호"가 누락되어 있기 때문입니다.

5. 시간 경과에 따른 일반화

결과는 타임 윈도우(2020, 2025, 2026) 전반에 걸쳐 일반화됩니다.

Domain-Agent 방식은 다른 소형 모델 베이스라인들을 지속적으로 능가했습니다.
2025년과 2026년 윈도우에서, Domain-Agent 방식은 "좁은(narrow, 소스 전용)" 골드 세트에서 Codex 5.5 High를 능가하기도 했으나, Codex는 더 넓은 파일 세트(테스트 포함)를 예측하는 경향 덕분에 "넓은(broad, PR 기반)" 세트에서는 여전히 우위를 유지했습니다.

의의 및 주장

본 논문은 탐색 구조가 모델의 용량을 보완할 수 있는 2차적 요인이라고 주장합니다. 에이전트를 재구성하여 저장소 서브시스템을 따라 탐색을 병렬화하고 제한된 I/O를 활용함으로써, 작은 모델이 다중 파일 로컬라이제이션 작업에서 훨씬 더 큰 프런티어 모델의 성능을 따라잡거나 능가할 수 있습니다.

그러나 저자들은 다음과 같은 한계점에 대해 겸허한 태도를 보입니다:

탐색만으로는 충분하지 않다: 현재 어떤 아키텍처도 문서 파일을 안정적으로 찾아낼 수 없는데, 이는 문서 에이전트를 소스 변경 사항에 기반해 파견하는 등의 라우팅 정책 변화가 필요하기 때문이지 탐색 자체의 문제가 아닙니다.
접근 권한이 만병통감은 아니다: 표적화된 탐색 전략 없이 가공되지 않은 파일 시스템 접근 권한을 부여하는 것은 프롬프트의 모호성을 증폭시키고 과잉 예측을 유발하여 오히려 성능을 해칠 수 있습니다.
범위: 본 연구는 파일 로컬라이제이션을 패치 생성 및 테스트 실행과 분리하여 고립시켜 다루므로, 이 결과는 소프트웨어 엔지니어링의 "변경 위치 파악(where to change)" 단계에 적용됩니다.

이 연구는 다중 파일 변경 로컬라이제이션을 위해 **도메인 범위의 병렬 생성(domain-scoped parallel spawning)**이 나이브한 파일 시스템 접근을 피하고 제한된 I/O를 통해 토큰 예산을 관리한다는 전제하에, 선형적 순차 탐색보다 우수한 아키텍처 패턴임을 입증합니다.