AI 코딩 도구를 실무에 붙일 때 가장 먼저 드러나는 문제는 모델이 코드를 생성할 수 있느냐가 아닙니다. 오히려 더 자주 부딪히는 병목은 “수정해야 할 위치를 제대로 찾았는가”입니다. 대형 저장소에서는 버그 설명 하나가 수십 개 파일, 수천 줄의 후보 코드로 흩어질 수 있고, 잘못된 맥락을 읽은 에이전트는 그럴듯하지만 엉뚱한 패치를 만들기 쉽습니다.
이 지점에서 SWE-Explore가 의미를 갖습니다. 이 벤치마크는 코딩 에이전트의 전체 문제 해결 능력을 한 번에 재는 대신, 코드 수정 이전 단계인 저장소 탐색 능력만 따로 떼어 평가합니다.1 즉, “패치를 만들었는가”가 아니라 “패치를 만들기 전에 필요한 코드 위치를 얼마나 잘 좁혔는가”를 묻습니다.
왜 저장소 탐색을 별도로 봐야 하나
소프트웨어 버그 수정은 보통 세 단계로 나눠 볼 수 있습니다. 먼저 이슈를 이해하고, 그다음 관련 코드를 찾고, 마지막으로 코드를 수정합니다. 기존 평가는 마지막 결과에 집중하는 경우가 많았습니다. 하지만 최종 실패만 보고서는 에이전트가 코드를 잘못 고친 것인지, 아니면 애초에 봐야 할 코드를 놓친 것인지 구분하기 어렵습니다.
SWE-Explore는 이 구분을 가능하게 하려는 시도입니다. 입력은 저장소와 이슈이며, 출력은 고정된 라인 예산 안에서 관련 코드 영역을 순위화한 목록입니다.1 여기서 중요한 점은 단순히 관련 파일을 맞히는 수준이 아니라, 어느 코드 줄 범위가 문제 해결에 실질적으로 연결되는지를 평가한다는 것입니다.
이는 최근 코딩 에이전트의 설계 방향과도 맞닿아 있습니다. 모델의 컨텍스트 창이 커지고 도구 호출이 정교해져도, 저장소 전체를 무작정 넣을 수는 없습니다. 어떤 코드를 먼저 읽고, 무엇을 버리고, 제한된 맥락 안에 무엇을 남길지가 성능과 비용을 좌우합니다.
SWE-Explore의 핵심 설계
SWE-Explore 데이터셋은 203개 오픈소스 프로젝트, 10개 프로그래밍 언어, 848개 문제로 구성됩니다.1 이 가운데 Python 과제는 547개입니다. SWE-Explore-Bench는 실제 이슈와 저장소 스냅샷을 바탕으로 탐색기가 소스 파일과 라인 범위를 순위화하도록 요구합니다.2
정답 라벨을 만드는 방식도 눈여겨볼 만합니다. SWE-Explore는 같은 이슈를 성공적으로 해결한 독립 에이전트 실행 궤적에서 관련 코드 영역을 추출합니다.1 다시 말해, 성공한 해결 과정에서 실제로 참조된 코드 영역을 라인 단위 정답으로 증류합니다. 이는 사람이 사후적으로 중요해 보이는 위치를 표시하는 방식과 다르게, 해결 경로에 나타난 코드 사용 흔적을 평가 기준으로 삼는 접근입니다.
평가는 크게 세 축으로 이뤄집니다.1
커버리지: 해결에 필요한 관련 코드 줄을 얼마나 포함했는가
랭킹: 중요한 코드 영역을 결과 목록의 앞쪽에 얼마나 잘 배치했는가
컨텍스트 효율성: 제한된 라인 예산 안에서 불필요한 코드를 얼마나 줄였는가
이 세 지표는 단순한 벤치마크용 숫자가 아닙니다. 실제 개발 환경에서 에이전트가 핵심 코드를 뒤늦게 발견하거나, 관련 없는 파일을 과도하게 읽거나, 중요한 라인을 빠뜨리면 이후 수정 단계의 품질은 흔들릴 수밖에 없습니다.
파일 위치 추정과 라인 단위 이해의 간극
SWE-Explore 논문은 고전적 검색기, 일반 코딩 에이전트, 특화 로컬라이저를 함께 비교합니다.1 논문이 설명하는 중요한 관찰은 현대적 방법들이 파일 단위 위치 추정에는 강점을 보이지만, 라인 단위 커버리지와 효율적 랭킹에서는 차이가 난다는 점입니다.1
이는 코딩 에이전트 평가에서 자주 간과되는 부분입니다. “관련 파일을 찾았다”는 말은 충분한 성공 조건이 아닙니다. 하나의 파일 안에도 실제 원인, 호출 경로, 검증 로직, 예외 처리, 설정 코드가 섞여 있을 수 있습니다. 에이전트가 파일은 맞혔지만 핵심 라인을 보지 못했다면, 생성 단계는 불완전한 증거 위에서 진행됩니다.
보고된 결과도 이 문제를 보여줍니다. 일반 코딩 에이전트들은 관련 코드 줄의 14~19%만 포괄했습니다. 연구팀은 OpenAI, Anthropic, Google, Moonshot, Zhipu의 6개 모델로 같은 에이전트를 실행했습니다.1 이 수치는 특정 모델의 우열을 단정하기보다, 현재 에이전트 구조에서 저장소 탐색이 아직 어려운 하위 과제임을 보여주는 신호로 읽는 편이 적절합니다.
실무적으로는 무엇이 달라지나
SWE-Explore의 메시지는 “코딩 에이전트가 아직 부족하다”는 단순한 결론에 머물지 않습니다. 더 중요한 함의는 에이전트 시스템을 평가하고 개선하는 기준을 세분화해야 한다는 점입니다.
첫째, 에이전트의 성능을 최종 패치 성공률 하나로만 보면 원인 분석이 어렵습니다. 탐색은 잘했지만 수정이 실패한 경우와, 탐색부터 실패한 경우는 개선 방향이 다릅니다. 전자는 코드 생성·검증·테스트 루프를 강화해야 할 수 있고, 후자는 검색, 인덱싱, 호출 그래프 활용, 랭킹 전략 같은 앞단을 개선해야 합니다.
둘째, 컨텍스트 효율성은 비용 문제와 직결됩니다. 관련 없는 코드를 많이 넣는 방식은 겉으로는 신중해 보일 수 있지만, 실제로는 모델의 주의를 분산시키고 토큰 비용을 늘립니다. SWE-Explore가 라인 예산 안에서 순위 목록을 요구하는 이유는 이 현실적인 제약을 반영하기 때문입니다.
셋째, 탐색 지표와 이후 코드 수정 성능의 관계를 봐야 합니다. SWE-Explore 논문은 탐색 지표가 이후 코드 수정 성능과 강하게 연관된다고 보고했습니다.1 이는 에이전트 개발자가 최종 성공률만 기다리지 않고, 중간 단계의 탐색 품질을 조기 진단 지표로 활용할 수 있음을 시사합니다.
남는 쟁점
다만 SWE-Explore를 해석할 때 주의할 점도 있습니다. 정답 라벨이 성공한 에이전트 실행 궤적에서 추출된다는 것은 실제 해결 과정과 가까운 장점이 있지만, 특정 성공 경로가 유일한 정답은 아닐 수 있습니다. 같은 버그도 여러 방식으로 이해하고 수정할 수 있기 때문입니다. 따라서 SWE-Explore의 점수는 “가능한 모든 정답을 포괄했는가”라기보다, 성공적 해결 경로에서 관찰된 중요한 코드 영역을 얼마나 잘 재현했는가에 가깝게 이해하는 것이 적절합니다.
또 하나의 쟁점은 언어와 프로젝트 구성의 편중입니다. 데이터셋은 10개 언어를 포함하지만, 848개 과제 중 Python 과제가 547개입니다.1 따라서 결과를 모든 언어와 모든 저장소 유형에 동일하게 일반화하기보다는, 언어별·생태계별 차이를 함께 살펴볼 필요가 있습니다.
앞으로 볼 것
SWE-Explore 이후 코딩 에이전트 경쟁에서 주목할 지점은 더 명확해졌습니다.
에이전트가 관련 파일뿐 아니라 실제 수정에 필요한 라인 범위를 얼마나 정확히 찾는가
검색 결과를 단순 나열하지 않고, 중요한 코드 영역을 앞쪽에 배치하는가
제한된 컨텍스트 안에서 불필요한 코드를 줄이는가
저장소 탐색 점수가 실제 패치 성공률 개선으로 이어지는가
범용 코딩 에이전트와 특화 로컬라이저의 역할 분담이 어떻게 바뀌는가
결국 SWE-Explore가 던지는 질문은 간단합니다. 코딩 에이전트가 코드를 잘 쓰기 전에, 먼저 코드를 잘 읽고 찾아낼 수 있는가. 실무에서 이 능력은 선택 기능이 아니라, 자동화된 소프트웨어 유지보수의 출발점에 가깝습니다.
1SWE-Explore: Benchmarking How Coding Agents Explore Repositories
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.