실제 버그 수정을 뒤집어 SWE 평가 과제를 대량 합성한다

무엇인가

코딩 에이전트의 성능을 제대로 평가하려면 검증 가능한 저장소 수준 SWE 과제가 많이 필요하다. 그런데 실제 GitHub 이슈에서 과제를 만드는 방식은 소프트웨어 개발이 진행되는 속도, 저장소 확보 가능성, 실행 환경 구축 비용에 묶여 있어 확장이 근본적으로 느리다. 기존 합성 기법들도 대부분 범용 LLM이 사전학습으로 이미 알고 있는 버그 생성 지식에 프롬프트를 얹는 수준이라, 반복 생성할수록 익숙한 버그 패턴으로 수렴하고 실제 소프트웨어 결함이 만들어지는 복잡한 메커니즘을 담아내지 못한다. 이 논문은 그 지점을 뒤집는다. 실제 버그 수정 이력에는 버그가 어떻게 형성되는지에 대한 깊은 기계적 지식이 들어 있으므로, 수정을 역방향으로 뒤집으면 수리 감독이 버그 유도 감독으로 바뀐다는 것이 핵심 착상이다.

어떻게 동작하나

SWE-at-Scale의 파이프라인은 세 단계다. 1단계에서 SWE-Fixer, SWE-rebench, SWE-bench-Live, SWE-Gym 네 소스에서 13만 4천 건이 넘는 이슈-수정 인스턴스를 모으고, 각 수정이 건드린 소스 파일의 수정 전후 버전을 복원한 뒤 수정된 파일에서 원래 버그 상태로 되돌아가는 역방향 통합 diff를 계산한다. 이 역방향 diff가 곧 버그 유발 패치가 된다. 파싱 불가 패치, 비코드 파일, import·주석·공백·포맷팅 위주 변경, 구조적으로 불완전한 패치를 걸러내고, 정방향과 역방향 패치를 왕복 적용해 원래 상태가 재현되는지 검증한다. 버그 유형을 주석으로 달고 64K 토큰을 넘는 예제를 제거한 뒤, 버그 유형·저장소·컨텍스트 길이를 균형 있게 맞추는 분포 인지 샘플링과 수동 검수를 거쳐 최종적으로 688개 저장소에서 뽑은 13,407개 역변환 데이터셋을 만든다. 평가 데이터와의 저장소 중복을 피하려고 SWE-bench Verified에 포함된 저장소의 인스턴스는 전부 제외한다.

무엇과 다른가

2단계는 버그 유발 모델 학습이다. Qwen3.5-9B를 백본으로 LoRA 기반 지도 미세조정(SFT)을 1에폭, 64K 컨텍스트로 단일 NVIDIA RTX PRO 6000 GPU에서 수행한다. 모델은 줄 번호가 붙은 완전한 정상 소스 파일을 입력받아, 그것을 버그 상태로 바꾸는 통합 diff를 생성하도록 학습된다. 수정 위치를 미리 알려주지 않고 주변 컨텍스트에서 스스로 추론하게 함으로써 어디를 고칠지와 어떻게 버그를 만들지를 함께 배우게 하는 것이다. 합성 시점에는 정상 저장소의 임의 파일에 이 패치를 생성해 git apply로 적용하고, 적용에 성공한 후보만 실행 기반 검증으로 넘긴다. 샘플링 온도가 학습된 버그 분포를 얼마나 넓게 탐색할지 조절한다. 확장판인 SWE-at-Scale+는 버그 패턴을 코드가 아니라 자연어로 먼저 명시한다. DeepSeek-V4-Flash-0731을 전문가 교사로 써서 각 역변환에 대해 작업 범주, 대상 위치, 현재 동작, 구체적 코드 수정, 구현 제약, 기대 관찰 효과를 담은 실행 가능한 자연어 버그 패턴을 추론하게 하고, 모델은 diff 대신 이 패턴을 예측하도록 학습한다. 합성 시에는 생성된 패턴과 정상 코드를 실행기에 넘겨 수정을 실현하는데, 실행기에는 이것이 버그를 만들기 위한 요청이라는 사실을 숨기고 평범한 코드 수정 지시로 제시한다.

어떻게 쓰나

3단계는 과제 조립과 검증이다. 생성된 코드 변경을 정상 저장소에 적용하고 테스트 스위트를 돌려, 이전에 통과하던 테스트가 최소 하나 실패하는 Pass-to-Fail(P2F) 후보만 남긴다. 검증된 버그 저장소마다 LLM에 코드 diff, P2F 테스트 소스, 실행 출력, 두 개의 시연을 주고 합성 과정을 노출하지 않은 채 GitHub 스타일 이슈 설명을 작성하게 해서 최종 SWE 과제 인스턴스를 만든다.

전제와 한계

실험은 SWE-smith의 LLM-Modify·LLM-Rewrite, BugPilot의 FeatAdd를 베이스라인으로, SWE-bench Verified와 DeepSWE를 실제 과제 참조군으로 삼아 비교한다. 해결 모델은 DeepSeek-V4-Flash-0731, GPT-5.4-mini, GLM-5.3-Flash, Qwen3.8-Flash-Next 네 가지이고, mini-SWE-agent를 온도 0, 최대 250 액션으로 돌리며 자기 문제를 자기가 풀지 않는 모델 분리 평가를 3회 반복해 평균을 낸다. 현실성은 3년 이상 경력 소프트웨어 엔지니어 3명이 합성 이슈-패치 쌍과 같은 컨텍스트의 실제 이슈를 비교해 다수결로 판정하는 HPR로, 사용성은 5회 시도 안에 실행·품질 필터를 통과한 비율로 측정한다. 결과적으로 SWE-at-Scale+는 사용성 94.0%, HPR 61.2%를 기록했고 SWE-at-Scale은 72.6%와 55.9%였다. 가장 좋은 LLM-Rewrite 설정이 72.2% 사용성, 51.8% HPR이었고 LLM-Modify는 사람 선호도가 크게 낮았다. 난이도에서는 SWE-at-Scale이 네 해결 모델에서 Pass@1 31.68~48.48%, SWE-at-Scale+가 16.81~37.02%로 SWE-bench Verified와 기존 합성 베이스라인보다 일관되게 낮았고, 전문가가 설계한 DeepSWE에 근접했다.

다양성 실험도 구체적이다. 같은 파일 하나에서 얼마나 여러 유형의 버그가 나오는지를 평균 버그 유형 엔트로피(MBTE)로 측정한다. 학습 데이터 크기를 2,000건으로 고정하고 저장소 수만 5개에서 100개로 늘리면 MBTE가 증가하고 사용성은 대체로 유지되거나 소폭 개선됐다. 샘플링 온도는 0.0에서 MBTE 0.527, 0.4에서 1.153, 0.6에서 1.173으로 정점을 찍었지만, 온도 1.0에서는 사용성이 69.0%에서 23.4%로 떨어지고 엔트로피도 0.714로 감소했다. 즉 0.4~0.6이 다양성과 사용성의 최적 절충점이다. 샘플링 예산을 K=5에서 200으로 늘리면 MBTE가 0.583비트에서 2.063비트까지 계속 증가했고 사용성은 K=50 이후 약 47%로 안정됐으며, K=200에서 정규화 diff 중복 제거 후에도 4,749개 사용 가능 후보 중 4,192개(88.27%)가 고유했다. 같은 조건에서 LLM-Modify는 MBTE 1.22비트, 사용성 44.1%, 고유 패치 비율 61.74%에 그쳤다. 비용 측면에서 SWE-at-Scale과 SWE-at-Scale+는 평균 18.793줄과 18.536줄을 수정해 SWE-bench Verified의 14.334줄보다 큰 변경을 만들었고, 인스턴스당 17.45k 토큰을 써서 LLM-Rewrite(34.92~62.82k)보다 저렴했지만 FeatAdd(2.29M)와는 두 자릿수 이상 차이가 났다.

실무 관점에서 이 논문이 주는 것은 두 가지다. 첫째, 자체 저장소에 테스트 스위트가 갖춰져 있다면 과거 수정 이력을 역방향으로 뒤집어 코딩 에이전트 평가용 과제를 자체 생산하는 발상이 가능하다. 둘째, 합성 과제의 품질을 판단할 때 사용성(실행 검증 통과율)과 현실성(사람 선호도), 난이도(Pass@1)를 분리해 봐야 한다는 점이다. 논문의 수치가 보여주듯 프롬프트만으로 버그를 주입하는 방식은 사람 선호도가 낮고, 반복 생성하면 패턴이 쉽게 반복된다. 또한 평가에 쓸 때는 생성 모델과 해결 모델을 분리해야 편향을 피할 수 있다.

저자들이 밝힌 한계는 분명하다. 현재 연구는 Python 저장소만 다루며, 문법과 의미론, 개발 관행이 다른 언어로 이 역변환 패러다임이 일반화되는지는 확인되지 않았다. 또한 사용 가능한 테스트 스위트가 커버하지 못하는 현실적인 버그는 폐기되기 때문에, 테스트 커버리지가 약한 저장소에서는 만들 수 있는 과제의 공간이 제한된다. 향후 과제로 여러 언어를 넘나드는 버그 유발 모델 학습을 통한 교차 언어 SWE 과제 합성을 제시한다.