SWE-bench: 실제 깃허브 이슈를 풀 수 있는가

SWE-bench: 언어 모델은 실제 깃허브 이슈를 해결할 수 있을까?

인기 파이썬 저장소 12곳의 실제 깃허브 이슈와 그것을 해결한 풀 리퀘스트(PR) 에서 문제 2,294개를 모아, 모델이 저장소 전체를 보고 코드를 고쳐 실제 테스트를 통과하는지 로 채점하는 벤치마크입니다. 발표 당시 가장 잘한 Claude 2도 1.96%만 해결했고, 이후 코딩 에이전트의 실력을 재는 대표 기준이 됐습니다.

들어가기 전에

이 해설은 아래 내용을 안다고 보고 씁니다. 처음이라면 먼저 읽고 오면 수식과 손계산을 훨씬 쉽게 따라올 수 있습니다.

• ReAct: 추론과 행동을 함께 — 생각·행동·관찰을 번갈아 쓰게 해 추론과 도구 사용을 결합한 LLM 에이전트 프롬프트

한눈에 보기

• HumanEval처럼 함수 하나를 짜는 벤치마크와, 저장소 전체를 고치는 실제 소프트웨어 작업이 어떻게 다른지 알게 됩니다.
• 9만 개 PR에서 2,294개 과제를 골라내는 3단계 필터 와, '실패 → 통과(fail-to-pass)' 테스트로 채점하는 방식을 이해합니다.
• 긴 코드베이스에서 문맥을 고르는 BM25 검색 · 오라클 검색 설정과 그 영향을 손계산으로 따라가 봅니다.
• 모델이 어디서 막히는지(문맥 길이, 코드 위치 찾기, 패치 형식, 짧고 단순한 수정)를 판단할 수 있게 됩니다.

초록 (번역)

언어 모델의 발전 속도가 우리가 그것을 효과적으로 평가하는 능력을 앞질렀지만, 앞으로의 발전을 위해서는 그 능력의 최전선을 연구하는 것이 필수적입니다. 우리는 실제 소프트웨어 공학이 차세대 언어 모델을 평가하기 위한 풍부하고, 지속 가능하며, 도전적인 시험대라고 봅니다. 이를 위해 인기 있는 파이썬 저장소 12곳의 실제 깃허브 이슈와 그에 대응하는 풀 리퀘스트에서 뽑은 소프트웨어 공학 문제 2,294개로 이루어진 평가 프레임워크 SWE-bench를 소개합니다. 코드베이스와 해결할 이슈 설명이 주어지면, 언어 모델은 이슈를 해결하도록 코드베이스를 수정해야 합니다. SWE-bench의 이슈를 해결하려면 여러 함수, 클래스, 심지어 여러 파일에 걸친 변경을 동시에 이해하고 조율해야 하는 경우가 많아, 모델이 실행 환경과 상호작용하고, 매우 긴 문맥을 처리하고, 전통적인 코드 생성 과제를 훨씬 넘어서는 복잡한 추론을 해야 합니다. 평가 결과, 최신 상용 모델과 우리가 미세조정한 모델 SWE-Llama 모두 가장 단순한 이슈만 해결할 수 있었습니다. 가장 성능이 좋은 Claude 2도 이슈의 1.96%만 해결했습니다. SWE-bench에서의 진전은 더 실용적이고, 지능적이며, 자율적인 언어 모델을 향한 걸음이 될 것입니다.

무엇을 풀었나

코드 생성 벤치마크는 이미 포화 상태에 가까웠습니다.

• HumanEval 같은 기존 벤치마크 는 자연어 설명을 보고 짧은 함수 하나를 짜는 문제입니다. 문제도 벤치마크용으로 만든 '인위적인' 것이 많습니다.
• 실제 개발 일 은 다릅니다. 수천 개 파일이 있는 저장소에서 문제 위치를 찾고, 여러 함수 · 파일을 함께 고치고, 기존 기능이 깨지지 않게 해야 합니다.
• 기존 벤치마크는 학습 데이터에 섞여 들어가 오염 되기 쉽고, 새 문제를 계속 보충하기 어렵습니다.

논문의 질문은 이것입니다. 실제 저장소의 실제 이슈를 주고, 실제 테스트로 채점하면 언어 모델은 얼마나 해낼까?

핵심 아이디어

123456789flowchart LR
  S1[1단계: 인기 저장소 12곳에서 PR 약 9만 개 수집] --> S2[2단계: 이슈를 해결하고 테스트를 추가한 병합 PR만]
  S2 --> S3[3단계: 실행 필터 — 실패→통과 테스트가 1개 이상, 설치 · 실행 오류 없음]
  S3 --> D[(SWE-bench 2,294개)]
  D --> IN[입력: 이슈 글 + 코드베이스 일부 BM25 또는 오라클]
  IN --> M[모델이 패치 파일 생성]
  M --> T[패치 적용 → 실패→통과 + 기존 테스트 실행]
  T -->|모두 통과| OK[해결]
  T -->|하나라도 실패 · 적용 불가| NG[미해결]

1. 과제 만들기: 3단계 필터

직관. 실제로 일어났던 버그 신고(이슈)와, 개발자가 그것을 고친 뒤 '이제 이 테스트가 통과한다'고 증명한 기록(PR + 테스트)을 시험 문제와 채점표로 그대로 쓰는 것입니다. 정답 코드는 감추고, 채점표(테스트)만 남깁니다.

단계별 설명.

1. 저장소 선택 · 수집: django, sympy, scikit-learn, matplotlib 등 인기 오픈소스 파이썬 저장소 12곳에서 PR 약 9만 개를 모읍니다. 인기 저장소는 관리가 잘 되고 테스트 범위가 넓기 때문입니다. PR마다 기준 커밋(base commit)으로 코드베이스 상태가 정해집니다.
2. 속성 필터: 병합된 PR 중 (1) 깃허브 이슈를 해결하고 (2) 테스트 파일을 바꾼(= 해결을 확인하는 테스트를 추가한) 것만 남깁니다.
3. 실행 필터: PR의 테스트를 적용한 뒤, PR의 나머지 코드 변경 전과 후 의 테스트 결과를 기록합니다. 실패하다가 통과로 바뀌는 테스트(fail-to-pass)가 하나도 없으면 버리고, 설치 · 실행 오류가 나는 것도 버립니다.

결과는 2,294개입니다. 이 방식은 사람 손을 거의 거치지 않아 새 이슈로 계속 갱신 할 수 있고, 모델의 학습 마감일 이후 생긴 이슈로 평가해 오염을 피할 수 있습니다.

과제의 규모 (논문 표 1, 평균 / 최대).

또 과제의 40%는 실패→통과 테스트가 2개 이상이고, 기존 기능이 유지되는지 확인하는 추가 테스트가 중앙값 51개 돌아갑니다.

SWE-bench Lite. 평가 비용을 줄이려고, 더 독립적이고 기능 버그 수정 위주인 300개를 뽑은 부분집합도 만들었습니다(12개 저장소 중 11개 포함).

2. 채점: 패치를 적용하고 테스트를 돌린다

직관. 학생이 낸 답안(패치)을 실제 시험지(코드베이스)에 붙여 보고, 채점 기계(테스트)가 모두 통과라고 하면 정답입니다. 정답 PR과 코드가 똑같을 필요는 없습니다. 다른 방법이라도 테스트를 통과하면 인정됩니다.

단계별 설명.

1. 모델은 이슈 글과 코드베이스(일부)를 받고, 어떤 줄을 어떻게 바꿀지 적은 패치 파일 을 만듭니다.
2. 유닉스 patch 프로그램으로 코드베이스에 적용합니다. 형식이 틀려 적용이 안 되면 실패입니다.
3. 과제의 테스트(실패→통과 테스트 + 기존 기능 테스트)를 실행합니다.
4. 패치가 적용되고 모든 테스트가 통과 해야 '해결'입니다.

수식.

숫자로 해 보기 (거꾸로 계산한 근삿값). Claude 2의 BM25 해결률 1.96%는 $2294 \times 0.0196 \approx 45$개, 즉 2,294개 중 약 45개만 풀었다는 뜻입니다. Lite 300개에서 3.00%면 9개입니다.

3. 입력 문맥 고르기: BM25 검색 vs 오라클 검색

직관. 저장소 평균 43만 줄은 어떤 모델의 문맥 창에도 다 들어가지 않습니다. 그래서 "이 이슈와 관련 있어 보이는 파일"만 골라 보여 줘야 합니다. 도서관 전체를 줄 수 없으니, 사서가 관련 책 몇 권을 골라 주는 것과 같습니다.

두 가지 설정.

• BM25(희소 검색): 이슈 글을 질의로, 파일을 문서로 보고 단어 일치 기반 BM25로 파일을 골라 1만 3천 · 2만 7천 · 5만 토큰 한도 안에 채웁니다. 질의 · 문서가 매우 길고 '자연어로 코드를 찾는' 특이한 상황이라 밀집 검색은 맞지 않는다고 판단했습니다.
• 오라클: 정답 PR이 실제로 고친 파일을 그대로 줍니다. 실제 엔지니어는 어떤 파일을 고칠지 미리 모르므로 비현실적이지만, 분석용으로 씁니다.

BM25 점수는 다음 식으로 계산합니다(표준 BM25 식, 논문은 Robertson 외 2009를 인용).

숫자로 해 보기 (설명용, $k_1 = 1.2$, $b = 0.75$ 가정). 이슈에 napoleon_use_param이라는 드문 단어(IDF = 3.0)가 있다고 합시다. 평균 길이 파일에서 이 단어가 2번 나오면 $\frac{2 \times 2.2}{2 + 1.2} = 1.375$, 점수 $3.0 \times 1.375 \approx 4.1$입니다. 같은 단어가 1번만 나오면 $\frac{2.2}{2.2} = 1$, 점수 3.0입니다. 이처럼 이슈에 나온 고유한 이름(함수 · 설정 이름)이 많이 겹치는 파일이 위로 올라옵니다.

BM25가 정답 파일을 얼마나 찾나 (논문 표 3, 오라클 파일 대비 재현율 %).

2만 7천 토큰 한도에서 약 40%는 정답 파일을 모두 포함했지만, 거의 절반은 정답 파일을 하나도 가져오지 못했습니다.

4. SWE-Llama: 공개 모델 미세조정

당시 긴 문맥을 다룰 수 있는 공개 모델은 CodeLlama뿐이었는데, 그대로는 지시를 따라 저장소 단위 수정을 하지 못했습니다. 그래서 평가용과 겹치지 않는 37개 저장소에서 이슈-PR 쌍 19,000개(SWE-bench-train, 테스트 추가 조건 없음)를 모아 CodeLlama-Python 7B · 13B를 미세조정했습니다. 어텐션 부분만 LoRA로 학습했고, 3만 토큰이 넘는 예시를 빼 실제 학습 데이터는 1만 개였습니다. 입력은 오라클 파일을 문맥으로 썼습니다.

결과

BM25 검색 설정 (논문 표 5)

• 모든 모델이 크게 고전했습니다. 본문 · 초록은 Claude 2의 BM25 해결률을 1.96%로, 표 5는 1.97로 적고 있습니다. 표 5에는 초록보다 나중 모델인 Claude 3 Opus 결과(3.79%)도 들어 있습니다.
• 오라클 검색에서는 Claude 2가 4.8%를 해결했습니다.

발견 1 — 문맥이 길수록 어렵습니다. BM25 문맥 한도를 늘리면 정답 파일 재현율은 오르지만 성능은 오히려 떨어졌습니다(Claude 2: 13k 1.96 → 27k 1.87 → 50k 1.22). 관련 없는 코드가 많아지면 고칠 위치를 찾지 못하기 때문입니다. 오라클 파일에서 고친 줄 ±15줄만 남기고 접은 설정(oracle-collapsed)에서는 GPT-4가 1.3% → 3.4%, Claude 2가 4.8% → 5.9%로 올랐습니다(같은 설정의 Claude 3 Opus는 9.39%).

발견 2 — 저장소마다 난이도가 다르고, 푼 문제도 다릅니다. 오라클 설정에서 Claude 2는 110개, SWE-Llama 13b는 91개를 풀어 비슷했지만, Claude 2는 SWE-Llama가 푼 문제의 42%만 풀었습니다. 이슈에 이미지가 들어간 비율도 matplotlib 32%, seaborn 10%로 전체 2%보다 높아, 이미지 이해가 필요할 수 있습니다.

발견 3 — 날짜와는 별 관계가 없습니다. 2023년 이전 · 이후 PR로 나눠도 대부분 모델의 성능 차이가 작았습니다(GPT-4만 예외, 예산 때문에 25% 무작위 부분집합으로 평가). 모델이 저장소의 최신 버전을 외워 '컨닝'하는 것은 아니라고 봅니다.

발견 4 — 패치가 전체 파일보다 낫습니다. 파일 전체를 다시 쓰게 하면 Claude 2의 오라클 성능이 4.8%에서 2.2%로 떨어졌습니다.

발견 5 — 모델은 짧고 단순하게 고칩니다. 적용에 성공한 모델 패치는 정답 패치보다 훨씬 짧았습니다. 예를 들어 Claude 2의 패치는 평균 19.6줄, 같은 과제의 정답 패치는 44.1줄이었고, 전체 정답 패치 평균은 74.5줄 · 1.7파일인데 모델은 거의 파일 하나만 고쳤습니다. 정성 분석에서도 모델은 기존 라이브러리 · 코드베이스를 활용하지 않고 문제만 딱 고치는 '탐욕적' 수정을 했고, 정답 패치는 앞으로 생길 문제까지 막는 구조적 개선을 하는 경우가 많았습니다.

발견 6 — 미세조정 모델은 문맥 분포 변화에 약합니다. SWE-Llama는 오라클 문맥으로 학습해 '문맥의 모든 파일을 고치도록' 배웠기 때문에, 고치면 안 되는 파일이 섞인 BM25 문맥에서 성능이 크게 떨어졌습니다.

왜 중요한가 · 이후 영향

• 코딩 에이전트의 표준 시험대 가 됐습니다. 함수 하나 짜기에서 '저장소 탐색 → 위치 찾기 → 여러 파일 수정 → 테스트 통과'로 평가 기준을 옮겼습니다.
• 에이전트 설계로 이어졌습니다. 논문은 이 과제가 검색 · 긴 문맥 모델부터 코드 안에서 추론하고 행동하는 의사결정 에이전트까지 비교할 수 있는 무대라고 밝힙니다. 실제로 이후 연구는 ReAct · Reflexion식 루프에 파일 탐색 · 테스트 실행 도구를 붙여 해결률을 높이는 방향으로 나아갔습니다.
• 실무 감각과 맞닿은 지표: 개발자 입장에서 "이슈를 받아 PR을 만들고 CI를 통과하는가"와 거의 같은 질문이라, 코딩 도구를 고를 때 참고하기 좋습니다.

한계 · 주의할 점

• 파이썬 · 인기 저장소 12곳에 한정 됩니다. 다른 언어 · 사내 코드베이스에서는 결과가 다를 수 있습니다.
• 테스트가 곧 정답 기준 입니다. 테스트가 이슈의 모든 측면을 확인하지 못하면, 테스트는 통과했지만 품질이 낮은 수정도 '해결'로 셉니다. 반대로 정답 PR과 다른 올바른 해법이 특정 테스트 구현에 맞지 않아 떨어질 수도 있습니다.
• 검색 설정의 영향이 큽니다. BM25는 절반 가까운 과제에서 정답 파일을 하나도 못 가져와, 결과가 모델 실력과 검색기 품질을 함께 반영합니다.
• 논문의 기준선은 한 번에 패치를 내는 방식이라, 실행 환경과 상호작용하는 에이전트의 실력은 따로 재야 합니다.
• 평가 비용이 크고(실행 환경 구성, 긴 입력), 일부 결과(GPT-4)는 부분집합으로만 평가했습니다.

스스로 점검

1. SWE-bench에서 '해결'의 조건은?

   모델이 만든 패치가 코드베이스에 적용되고, 실패→통과 테스트와 기존 기능 테스트를 모두 통과해야 합니다.

2. BM25 문맥 한도를 13k에서 50k로 늘리면 정답 파일 재현율과 Claude 2 해결률은 각각 어떻게 됐나요?

   재현율은 평균 29.58%에서 51.06%로 올랐지만, 해결률은 1.96%에서 1.22%로 떨어졌습니다. 관련 없는 코드가 늘어 고칠 위치를 찾기 어려워졌기 때문입니다.

3. Lite(300개)에서 해결률 4.33%는 몇 개를 푼 것인가요?

   $300 \times 0.0433 \approx 13$개입니다.

용어 정리

이어서 읽을 것

• 앞: ReAct · Reflexion · DPR (밀집 검색)
• 함께: MemGPT · 생성형 에이전트

다음에 볼 것

이 글을 이해했다면 이어서 보면 좋은 항목입니다.

• 중간 점검: LLM 활용 · 에이전트 — LLM 활용 · 에이전트 트랙 전체를 문제로 점검
• 검색의 기초: TF-IDF · BM25 · 벡터 검색 · 검색 평가 지표 — 역색인 · TF-IDF · BM25 · 벡터 검색 · P@k · MRR · nDCG를 손계산하는 RAG 검색 기초
• 강화학습 입문 (Sutton · Barto, 2판) — 슬롯머신 · MDP · 벨만 방정식 · 가치 반복을 3칸 격자 손계산으로 배우는 강화학습 첫 수업

출처

• 원문: arxiv.org/abs/2310.06770 (2023 · Carlos E. Jimenez, John Yang 외)