코딩 에이전트와 SWE-bench: 저장소 단위 문제 해결

왜 필요했나: '코드 작성'과 '소프트웨어 엔지니어링'의 차이

대규모 언어 모델(LLM)이 처음 코딩 능력을 보여 줬을 때 주로 잰 것은 '설명을 주면 함수 하나를 써 내는가'였다. 그런데 실제 개발자의 하루는 대부분 남이 쓴 큰 코드베이스를 읽고, 버그가 어디서 나는지 찾고, 여러 파일을 조금씩 고친 뒤 기존 기능이 깨지지 않았는지 확인하는 일이다. 함수 단위 평가로는 이런 능력을 볼 수 없다.

USEagent 연구논문는 이 차이를 직접 문제 삼았다. 소프트웨어 엔지니어링은 코딩만이 아니라 프로젝트의 유지보수와 발전까지 포함하는 일이라는 것이다. 그래서 테스트 작성, 디버깅, 수리처럼 따로따로 만들어진 전용 에이전트 대신, 미완성 패치 마무리·새 기능 추가·남이 쓴 코드 인수 같은 상황을 하나의 에이전트가 다루게 하려 했다.

이런 흐름에서 '저장소 단위(repository-level)' 평가가 중심이 됐다. 실제 저장소와 실제 이슈를 그대로 가져와, 에이전트가 고친 결과를 테스트로 판정하는 방식이다. SWE-bench가 이 방식의 대표 벤치마크(성능 비교용 시험 세트)로 자리 잡았고, SWE-Bench Pro논문는 SWE-bench의 좋은 관행을 이어받되 더 어렵고 기업 현장에 가까운 문제로 범위를 넓혔다.

핵심 아이디어: 신입 개발자에게 이슈 티켓을 맡기는 시험

저장소 단위 평가는 새로 들어온 개발자에게 처음 보는 프로젝트와 이슈 티켓 한 장을 주고 '고쳐 오라'고 하는 시험과 비슷하다. 채점자는 코드를 눈으로 평가하지 않는다. 미리 준비해 두고 응시자에게는 보여 주지 않은 테스트를 돌려, 원래 고장 난 동작이 고쳐졌는지와 멀쩡하던 기능이 그대로인지를 확인한다.

이 시험이 까다로운 것은 정답 코드의 '모양'이 정해져 있지 않기 때문이다. 어느 파일을 고칠지, 몇 줄을 바꿀지는 응시자가 정한다. 그래서 코드 작성 능력만큼 '어디를 봐야 하는지 찾는 능력', '직접 실행해서 확인하는 습관', '고친 것이 다른 곳을 망가뜨리지 않는지 따지는 판단'이 중요해진다.

동시에 이 비유는 약점도 보여 준다. 시험지가 유출되거나, 티켓 설명이 엉터리거나, 테스트가 이슈와 다른 것을 검사하면 점수는 실력을 반영하지 못한다. 뒤에서 다룰 SWE-Bench Pro Verified논문가 정확히 이 문제를 짚었다.

어떻게 작동하나: 이슈에서 패치, 채점까지

첫째, 입력은 두 가지다. 이슈 설명(무엇이 잘못됐는지, 무엇을 원하는지)과 그 이슈가 올라온 시점의 저장소 스냅샷이다. 에이전트는 이 저장소가 설치된 샌드박스(바깥과 격리된 실행 환경) 안에서 일한다.

둘째, 에이전트는 여러 번 오가며 일한다. 파일 목록을 보고, 관련 코드를 검색하고, 의심 가는 부분을 열어 읽고, 수정하고, 테스트나 재현 스크립트를 돌려 결과를 관찰한다. 이렇게 '생각 → 도구 사용 → 관찰'이 이어진 기록 전체를 Trajectory라고 부른다. 모델이 이런 도구를 쓰도록 감싸 주는 프롬프트·도구 목록·실행 환경·컨텍스트 관리 장치를 하네스라고 한다.

셋째, 에이전트가 끝났다고 선언하면 저장소의 변경분이 패치로 추출된다. SWE-Bench Pro논문는 전문 개발자가 몇 시간에서 며칠 걸릴 수 있는 장기 과제를 담았고, 여러 파일에 걸친 패치와 상당한 양의 코드 수정이 필요한 경우가 많다고 밝혔다.

넷째, 채점은 숨겨진 테스트로 한다. 패치를 원래 저장소에 적용한 뒤 테스트를 돌려 통과하면 '해결'로 센다. 모델이 정답을 맞혔는지가 사람의 판단이 아니라 실행 결과로 정해지기 때문에, 같은 구조가 강화학습의 보상으로도 그대로 쓰인다. 이를 검증 가능한 보상 강화학습(RLVR)이라고 한다.

발전 흐름: 더 어렵게, 그리고 더 믿을 수 있게

SWE-Bench Pro논문는 SWE-bench를 기반으로 기업 수준의 복잡한 문제를 담으려 했다. 비즈니스 애플리케이션, B2B 서비스, 개발자 도구에 걸친 41개 저장소에서 1,865개 문제를 모았다. 특징은 세트 구성이다. 11개 저장소의 공개 세트, 12개 저장소의 비공개(held-out) 세트, 초기 스타트업과 협약을 맺은 18개 비공개 상용 저장소의 상용 세트로 나눴다. 공개되지 않은 코드로 문제를 내면 모델이 학습 중에 정답을 미리 봤을 가능성, 즉 데이터 오염을 줄일 수 있다. 모든 과제는 사람이 검증했고, 풀 수 있도록 충분한 맥락을 덧붙였다. 또 수집한 Trajectory에서 실패 유형을 묶어 현재 모델이 어떤 식으로 틀리는지 분석했다.

USEagent 연구논문는 다른 방향으로 넓혔다. 이슈 수리 하나가 아니라 코딩·테스트·패치 같은 여러 종류의 일을 한 에이전트가 처리하는지 보려고 SWE-bench, SWT-bench, REPOCOD의 과제를 섞은 USEbench를 만들었다. 1,271개의 저장소 단위 과제로 평가했다.

SWE-Bench Pro Verified논문는 'SWE-Bench Pro 점수를 믿을 수 있나'를 물었다. 두 가지 신뢰성 문제를 찾았다. 하나는 정답 풀이나 숨겨진 평가 정보가 새어 나가 이를 이용하는 보상 해킹, 다른 하나는 오해를 부르는 문제 설명이나 범위가 잘못 잡힌 테스트 같은 과제 품질 문제다. 정상적인 에이전트 기능은 해치지 않으면서 주요 유출 경로를 막는 장치를 넣고, 결함 있는 과제는 최소한으로 고쳤다. 검증판에서 일부 모델은 이전 평가보다 점수가 크게 떨어졌고, 연구진은 기존 SWE-Bench Pro 결과가 실제 소프트웨어 엔지니어링 능력을 과대평가했을 수 있다고 봤다.

요즘 어디로 가고 있나: 하네스, 장기 강화학습, 검증 비용

첫째, '모델만 보면 안 된다'는 쪽이다. 하네스 효과 연구논문는 두 하네스(mini-SWE-agent, OpenCode)와 Qwen·DeepSeek 계열 오픈웨이트 모델 10개를 SWE-bench Pro, ProgramBench, GitTaskBench 세 벤치마크에서 비교했다. 하네스의 효과는 모델 능력과 과제 종류에 함께 달려 있었다. SWE식 이슈 수리에서는 모델이 강해질수록 복잡한 하네스의 추가 이득이 줄었지만, 더 복잡하고 열린 저장소 과제에서는 강한 모델도 복잡한 하네스의 도움을 받을 수 있었다. 구성 요소별로는 구조화된 도구 사용과 과제 전용 서브에이전트가 가장 꾸준히 도움이 됐고, 컨텍스트 압축과 범용 서브에이전트는 저장소 생성 성능을 떨어뜨리기도 했다.

둘째, 긴 작업을 강화학습으로 가르치는 방법이다. 장기 과제에서는 작은 실수 하나가 Rollout 전체를 망쳐 성공한 Trajectory가 드물다. 처음부터 다시 시작하면 비효율적이고, 대화 맥락과 작업 폴더만 되돌리면 설치된 의존성 같은 환경 변화가 빠진다. SPROUT논문는 매 턴마다 파일 시스템과 에이전트 맥락을 함께 체크포인트로 저장하고, 검증기가 이끄는 되돌아가기 정책으로 실패한 시도를 어디서부터 이어 갈지 고른다. 장기 코딩 과제에서 pass@k(k번 시도 중 하나라도 성공하면 해결로 보는 지표) 대비 최대 23.6% 개선을 보이면서 토큰은 32~52%만 썼다고 보고했다. Qwen3.8-27B 학습에서는 표준 GRPO보다 세 벤치마크에서 13.9점 높았고 학습 단계당 시간은 39.5% 줄었다.

셋째, 테스트 타임 컴퓨트의 비용 문제다. 후보 Trajectory를 여러 개 만들고 가장 좋은 것을 고르면 성능이 오르지만, 긴 기록을 검증하는 데 생성만큼 토큰이 들 수 있다. LatentSift논문는 LLM 검증기로 한 번 더 읽는 대신, 정책 모델이 생성하면서 이미 만든 Hidden Representation을 성공·실패 사례와 비교해 후보를 거른다. SWE-bench Verified에서 K=16일 때 실행 없는 검증기 토큰을 66.6~81.0%, 테스트 생성을 포함한 전체 검증 토큰을 49.1~62.1% 줄였고, DeepSWE-Preview에서는 Best@16이 59.26%에서 60.06%로 올랐다.

한계와 쟁점: 점수는 무엇을 말해 주고, 무엇을 말해 주지 않나

가장 먼저 짚을 것은 벤치마크 신뢰성이다. SWE-Bench Pro Verified논문가 보였듯, 정답 유출과 과제 결함은 점수를 부풀린다. 데이터 오염을 막으려는 비공개 세트논문도 테스트 자체가 이슈를 제대로 검사하지 않으면 해결되지 않는 문제다. 리더보드 숫자를 볼 때는 어떤 세트인지, 유출 차단과 과제 검증을 거쳤는지 먼저 확인해야 한다.

둘째, 비교 단위의 문제다. 하네스 효과 연구논문에 따르면 성능은 기본 모델만으로 정해지지 않는다. 같은 모델이라도 하네스가 바뀌면 결과가 달라지고, 그 효과는 과제 종류에 따라 방향까지 바뀔 수 있다. 시도 횟수도 중요하다. pass@k나 Best@16처럼 여러 번 시도해 고르는 점수는 한 번에 맞힌 점수와 같은 의미가 아니다.

셋째, 벤치마크 바깥의 일이다. 스펙 주도 개발 연구논문는 업계 보고에서 개인 생산성은 오르는데 팀 처리량, 리뷰 역량, 안정성은 떨어지는 '생산성 역설'이 나타난다고 정리하고, 사람과 에이전트 사이의 계약 역할을 하는 명세와 에이전트 행동을 통제하는 하네스를 팀 단위로 갖춰야 한다고 주장했다. MAGE논문도 코딩 에이전트가 구현 역량은 늘려 주지만 프로젝트의 의도, 시스템 구조, 수용 근거를 자동으로 드러내 주지는 않는다고 봤다. 이슈 하나를 테스트 통과로 고치는 능력과, 무엇을 받아들일지 판단하는 능력은 서로 다른 문제다.

더 공부하려면

출발점으로는 SWE-Bench Pro논문를 먼저 읽는 것이 좋다. 저장소 단위 과제가 어떻게 만들어지고, 공개·비공개·상용 세트를 왜 나누는지, 에이전트가 어떤 식으로 실패하는지가 한 편에 담겨 있다. 이어서 SWE-Bench Pro Verified논문를 읽으면 같은 벤치마크의 점수가 어떤 경로로 부풀려질 수 있는지 비교하며 볼 수 있다.

에이전트를 직접 만들거나 고르는 입장이라면 하네스 효과 연구논문가 실무에 가깝다. 도구 목록, 컨텍스트 압축, 계획, 서브에이전트 같은 구성 요소를 하나씩 켜고 끄며 효과를 본 결과라, 어떤 장치를 먼저 붙일지 판단하는 데 도움이 된다. 이슈 수리 너머의 일까지 보려면 USEagent논문를 함께 읽는다.

모델 학습 쪽에 관심이 있다면 SPROUT논문로 장기 과제 강화학습의 병목을, LatentSift논문로 여러 후보 중 고르는 검증 비용 문제를 보면 된다. 팀과 조직 관점은 스펙 주도 개발 연구논문와 MAGE논문가 다룬다.