기술 요약: SHERLOC – 코드 수정 에이전트를 위한 구조화된 진단 로컬라이제이션(Localization)

1. 문제 정의

저장소 수준의 코드 수정은 GitHub 이슈를 해결하기 위해 추론과 구조화된 도구 호출을 교차하는 대규모 언어 모델(LLM) 에이전트에 점점 더 의존하고 있습니다. 그러나 기존 에이전트들을 체계적으로 분석한 결과, 결정적인 비효율성이 발견되었습니다. 에이전트들은 코드 패치를 시도하기 전, 결함을 로컬라이제이션(localization)하는 데에만 전체 상호작용 예산의 거의 절반(인스턴스당 평균 18.5회 턴, 320k개 이상의 토큰)을 소비합니다.

현재의 로컬라이제이션 방법들은 두 가지 주요 한계점을 가집니다:

1. 불완전한 출력: 대부분의 접근 방식은 결함이 있는 파일이나 함수를 검색하지만, 다운스트림 수정 에이전트가 효과적으로 작동하는 데 필요한 진단적 컨텍스트(근본 원인, 해결 방향)를 제공하지 못합니다.
2. 평가 불일치: 전용 로컬라이제이션 프레임워크들은 종종 단순 파일 검색 시스템으로서 평가되며, 수정에 필요한 추론을 생성하는 실행 가능한 진단 도구로서 기능하지 못합니다.

이는 상당한 컴퓨팅 자원이 구축(construction)이 아닌 탐색(search)에 소비되는 성능 병목 현상을 야기하며, 결과적으로 도출된 위치 정보는 수정 작업을 가이드하기에 필요한 구체성이 부족한 경우가 많습니다.

2. 방법론: SHERLOC

저자들은 추론 LLM을 컴팩트한 저장소 도구 세트 및 자가 복구 메커니즘과 결합하도록 설계된 학습 불필요(training-free) 프레임워크인 SHERLOC(Structured Hypothesis-driven Exploration and Reasoning for Localization)을 소개합니다.

핵심 아키텍처

SHERLOC은 제한된 반복 루프(최대 20회 턴)를 통해 결정론적 도구 실행기와 상호작용하는 단일 추론 LLM으로 작동합니다. 이 방식은 미세 조정(fine-tuning), 강화 학습 또는 멀티 에이전트 오케스트레이션을 요구하지 않습니다.

• 도구 세트: 프레임워크는 네 가지 LLM 친화적 도구를 활용합니다:
  • View File: 퍼지 경로 매칭(fuzzy path matching)과 선택적 라인 범위를 사용하여 파일 내용을 검사합니다.
  • Codebase Search: 컨텍스트를 포함하여 저장소 전역의 리터럴 검색을 수행합니다.
  • Repository Tree: 글로벌 컨텍스트를 회복하기 위해 필터링된 파일 계층 구조를 표시합니다.
  • Connected Tree: 의존성을 탐색하기 위해 임포트 관계(직접 및 역방향)를 요약합니다.
• 반복적 상호작용: 모델은 추론과 도구 선택을 번갈아 수행합니다. 모델은 가설 상태(hypothesis state)를 형성하기 위해 관찰 내용(코드 스니펫, 경로, 의존성 요약)을 컨텍스트 히스토리에 축적합니다.
• 자가 복구 메커니즘: 확장된 도구 사용을 안정화하기 위해, SHERLOC은 경량화된 복구 전략을 채택합니다:
  • 컨텍스트 절단(초기 프롬프트와 최근 턴 보존).
  • 루프 탐지(생산적이지 않은 반복 호출에 대한 경고).
  • 암시적 도구 호출 복구(형식이 잘못되었으나 모호하지 않은 요청 파싱).
  • 최종 턴 합성(단계 예산이 소진되었을 때 결론 도출 강제).

구조화된 진단 출력

파일 경로만을 출력하는 기존 방식과 달리, SHERLOC은 예측된 각 위치에 대해 **구조화된 진단 결과(structured diagnostic finding)**를 생성합니다. 이 결과에는 다섯 가지 필드가 포함됩니다:

1. 위치 설명(Location Explanation): 왜 해당 파일이 의심되는지에 대한 이유.
2. 근본 원인(Root Cause): 버그의 근저에 있는 메커니즘.
3. 해결 아이디어(Solution Idea): (코드를 작성하지 않고) 수정에 대한 실행 가능한 가이드.
4. 의존성(Dependencies): 다른 모듈에 미치는 영향.
5. 테스트 영향(Testing Impact): 제안된 테스트 수정 사항.

평가 지표

논문은 패치가 함수나 클래스와 같은 구문 단위와 항상 일치하지 않는다는 점을 인정하며, 라인 번호 범위 대신 구조 불가지론적 청크 수준 지표(coverage recall, precision, average tightness)를 제안합니다.

3. 주요 결과

로컬라이제이션 성능

SHERLOC은 작업별 학습 없이도 다양한 모델 규모에서 SOTA(State-of-the-art) 파일 수준 로컬라이제이션을 달성했습니다:

• SWE-Bench Lite: 84.33% accuracy@1 (Qwen3-235B 사용).
• SWE-Bench Verified: 81.27% recall@1 (Qwen3-235B 사용).
• 규모 효율성: 매칭된 ~30B 파라미터 규모에서, SHERLOC(Qwen3-30B)은 75.07% recall@1을 달성하여 미세 조정된 베이스라인(예: ToolTrain-32B) 및 비미세 조정 방식보다 유의미한 차이(+7.0 ~ +18.3 pp)로 앞섰습니다.
• 교차 패밀리 전이(Cross-Family Transfer): 이 방법은 모델 패밀리 간에도 효과적으로 전이됩니다 (예: DeepSeek-V3는 79.53% recall@1 달성).

코드 수정으로의 다운스트림 전이

SHERLOC의 위치 정보와 진단 결과를 기존 수정 에이전트(OpenHands 및 SWE-Agent)에 주입했을 때 다음과 같은 유의미한 개선이 나타났습니다:

• 해결율(Resolve Rate): 5개의 수정 백본 전체에서 평균 +5.95 퍼센트 포인트의 해결율 상승.
• 효율성: 로컬라이제이션 토큰은 36.7% 감소, 총 토큰은 23.1% 감소.
• 품질 매개(Quality Mediation): 전이 효과는 품질에 따라 달라집니다. 작은 모델은 "모든 SHERLOC 결과"로부터 혜택을 받는 반면, 더 크고 유능한 모델은 품질 필터링된 결과(LLM 판사가 4.0 이상으로 평가한 결과)로부터 가장 큰 혜택을 받습니다. 필터링되지 않은 결과는 낮은 신뢰도의 진단으로 인한 부정적 전이(negative transfer) 때문에 강력한 에이전트의 성능을 저하시킬 수 있습니다.

절제 연구(Ablation) 및 타당성 연구

• 구성 요소의 중요성: View File 도구나 최종 턴 프롬프트를 제거했을 때 가장 큰 성능 저하가 발생했으며, 이는 코드 검사와 합성 압력이 매우 중요하다는 것을 확인시켜 줍니다.
• 암시적 지식 vs 추론: 파일 경로를 텍스트에서 마스킹한 제어 실험 결과, LL-MM들이 인기 있는 저장소(예: scikit-learn, requests)에 대한 암시적 친숙함을 가지고 있음에도 불구하고, 능동적인 도구 지원 탐색이 성능 격차의 상당 부분(약 22 pp 개선)을 차지함을 보여주었습니다.
• 추론의 필요성: "Thinking" 모드 모델은 "Instruct" 모드 모델보다 훨씬 뛰어난 성능을 보였으며, Instruct 모드는 멀티 턴 프로토콜을 지속하는 데 실패하는 경우가 많았습니다.

4. 의의 및 주장

본 논문은 단순히 위치를 검색하는 것이 아니라 구조화된 진단 출력이 유용한 로컬라이제이션의 핵심 단위라고 주장합니다. 올바른 파일 경로라도 오해의 소지가 있는 진단이 동반되면 다운스트림 에이전트를 잘못된 방향으로 이끌 수 있는 반면, 근본 원인 분석과 해결 가이드를 포함한 구조화된 결과는 효과적인 수정을 가능하게 합니다.

주요 주장은 다음과 같습니다:

1. 학습 불필요 SOTA: 단일 추론 LLM과 컴팩트한 도구 및 자가 복구 메커니즘을 결합하면 특화된 미세 조정 시스템과 대등하거나 이를 능가할 수 있습니다.
2. 실행 가능한 컨텍스트: 구조화된 진단 필드(근본 원인, 해결 아이디어)를 포함하는 것은 로컬라이제이션 성공을 다운스트림 수정 작업으로 전이시키는 데 필수적입니다.
3. 효율성: SHERLOC은 로컬라이제이션 단계의 토큰 비용을 획기적으로 줄여, 실제 코드 수정에 사용할 수 있는 예산을 확보해 줍니다.
4. 품질 필터링: 부정적 전이를 방지하기 위해 품질 필터가 필요합니다. 고품질의 결과는 성공을 견인하지만, 저품질의 결과는 해가 될 수 있습니다.

저자들은 로컬라이제이션이 단순히 파일 검색 정확도가 아니라 **진단적 실행 가능성(diagnostic actionability)**에 의해 평가되어야 한다고 결론짓습니다. 또한, 현재의 결과가 공공 저장소에 대한 LLM의 사전 학습된 친숙함에 의해 일부 혼재될 수 있음을 언급하며, 깨끗한 평가를 위해서는 홀드아웃(held-out) 저장소 분포가 필요하다고 명시했습니다. 이 프레임워크는 설계상 언어에 구애받지 않지만, 현재의 도구들은 임포트 트리를 파싱하기 위해 언어 특정적인 파서를 사용합니다.