07. SWE-bench 계열

쉽게 읽기

한 줄: “AI가 진짜 GitHub 이슈를 코드 패치로 해결할 수 있나”를 실제 테스트 통과 여부로 평가하는 벤치마크 — 코딩 에이전트 분야의 사실상 표준.

비유: 신입 개발자에게 실제 회사 버그 트래커에서 이슈 하나 골라 PR 올려보라고 시키고, 기존 테스트 코드가 통과하면 합격으로 판정하는 시험.

이 문서에서 챙길 3가지

1. SWE-bench는 “이슈 텍스트 + 저장소” → 에이전트 → 패치 → 테스트 통과 여부로 자동 채점 (사람 채점 0)
2. Verified(500개 큐레이션) 버전은 “문제·테스트가 신뢰할 만한 것만” 추려 더 엄격한 표준
3. 본 실험은 코딩 도메인이 아니지만 자동 검증 가능한 종료 조건(공지 발송 흔적 등)을 만드는 발상은 차용 가능

1. 정의

SWE-bench (Jimenez et al., Princeton 2023) 는 실제 GitHub 이슈를 코드 패치로 해결하는 능력을 측정하는 벤치마크다. 12개 유명 Python 저장소(Django, scikit-learn, sympy 등)에서 2,294개 실제 이슈를 수집했고, 각 이슈에는 해당 PR의 테스트 가 함께 묶여 있다. 에이전트가 만든 패치를 적용했을 때 그 테스트가 통과하면 성공.

SWE-bench는 코딩 에이전트 평가의 de facto 표준이 되었고, 후속작이 다수 등장:

• SWE-bench Verified (2024, OpenAI · Princeton 협업): 원본 2,294개 중 문제 정의가 명확하고 테스트가 신뢰할 수 있는 500개 큐레이션.
• SWE-PolyBench (2024+): Python 외 언어 (JS, Java 등) 2,000+ 이슈로 확장.
• LiveCodeBench: 알고리즘 문제(Codeforces 류)에서 시간이 지난 후 풀이만 평가 (training set leakage 차단).
• MultiSWE-bench, SWE-rebench 등: 도메인·언어·에이전트 프레임워크 변형.

2. 핵심 메커니즘

2.1 평가 절차

1. 이슈 텍스트 + 저장소 상태 → 에이전트
2. 에이전트가 코드 베이스 탐색 (cat, grep, ls)
3. 에이전트가 패치 (diff) 생성
4. 평가 시스템이:
   - 저장소 baseline에 패치 적용
   - 테스트 스위트 실행 (pre-existing PASS-to-PASS + ground truth FAIL-to-PASS)
   - 두 종류 테스트 모두 통과해야 성공

핵심은 두 종류의 테스트 다.

• FAIL_TO_PASS (F2P): 원래 실패하던 테스트가 패치 후 통과. 이슈를 진짜 풀었나.
• PASS_TO_PASS (P2P): 원래 통과하던 테스트가 여전히 통과. 기존 기능을 깨지 않았나.

둘 중 하나라도 어기면 fail. 즉 회귀 없이 정확히 의도한 변경만.

2.2 환경 비용

이게 무거운 벤치인 진짜 이유: 각 이슈마다 docker 환경 + 의존성 설치 + 테스트 실행. 한 이슈 ~5–30분, 2,294개 풀스위트 = 며칠 단위. GPU 없는 작업이지만 컨테이너 오케스트레이션이 필수. Spheron, Modal 같은 플랫폼이 SWE-bench 실행 인프라를 따로 제공할 정도.

2.3 SWE-bench Verified의 의의

원본 2,294개에는 모호한 이슈 텍스트, 과한 언급 (이슈에 정답 코드가 적혀있음), flaky test 가 다수 섞여 있었다. 모델 점수의 상한 이 인위적으로 낮음.

OpenAI + Princeton이 인간 SWE 100명+ 으로 1년에 걸쳐 큐레이션, 500개 정제된 이슈 + 정확한 ground truth + 안정 테스트를 만든 게 Verified. 동일 모델 점수가 원본 대비 5–10%p 상승하는 것이 정상.

현재(2026) 표준: 새 모델/에이전트 발표 시 SWE-bench Verified 점수를 보는 게 디폴트. 원본은 deprecated에 가깝다.

2.4 Trajectory의 역할

SWE-bench는 outcome (테스트 통과) 만 보지만, 어떻게 풀었는지도 분석 가치가 크다. 에이전트가:

• 몇 개 파일을 읽었나 (탐색 효율)
• 시도한 패치 횟수 (시행착오 정도)
• 테스트를 직접 돌려봤는가 (자기검증)

이런 trajectory 메트릭은 SWE-bench 자체엔 없지만, 에이전트 프레임워크 (SWE-agent, OpenHands 등) 가 별도 로깅한다.

2.5 점수 보는 법

SOTA 추이 (대략):

• 2023.10 SWE-bench 발표 시: ~2%
• 2024 중반: ~30% (Devin 류, Claude 3 Opus + 에이전트 프레임)
• 2025: 60–70% Verified
• 2026.04 기준: 80%+ Verified (Claude Opus 4.x 류)

빠른 상승은 모델 진화 + 에이전트 프레임 진화. 같은 모델이라도 ReAct vs SWE-agent vs OpenHands 등 프레임에 따라 점수가 10–20%p 다름. 즉 SWE-bench 점수는 모델 + 프레임 컴비의 점수다.

3. 강점과 약점

강점	약점
진짜 GitHub 이슈 — 합성 X	평가 비용 매우 큼 (Docker × 수천)
자동 채점 (테스트 결과) — 객관	Python 위주 (Verified는 100% Python)
F2P + P2P → 회귀까지 잡음	이슈 자체가 “잘 정의된” 것만 — 진짜 어려운 모호 이슈는 미포함
모델·프레임 비교 표준	정답 PR이 공개 — training leakage 의혹 (재학습된 모델은 답을 외움)
후속작 풍부 (Verified, Poly, Live)	에이전트가 테스트를 보고 그것만 맞추는 우회 가능 (13장)

4. 대안과의 비교

벤치	도메인	측정
SWE-bench	진짜 GitHub 이슈 패치	F2P + P2P
SWE-bench Verified	큐레이션 500개	동일, 신뢰도 ↑
SWE-PolyBench	다언어 GitHub	동일
LiveCodeBench	알고리즘 (Codeforces 류)	testcase 통과, cutoff 기반 leakage 차단
HumanEval / MBPP	함수 단위 합성 문제	testcase, 너무 단순, 포화
APPS	알고리즘 + 자연어	testcase
CodeContests	알고리즘 (DeepMind)	testcase
RepoBench	저장소 수준 코드 완성	exact match / line match

표가 보여주는 핵심: SWE-bench 만이 저장소 전체 컨텍스트 + 진짜 이슈 + 회귀 테스트 의 조합을 갖는다. 다른 건 더 조각난 평가.

5. 우리 실험에의 적용

본 실험과 SWE-bench는 완전히 다른 도메인이다. 우리는 비개발자 페르소나의 커뮤니티 운영. 코딩 X. 그럼 왜 알아야 하나?

5.1 간접 적용 — 평가 사고방식

SWE-bench가 우리에게 가르치는 것:

1. F2P + P2P 분리 — “새 일을 했나” + “기존 일이 깨지지 않았나”를 동시에 본다. 우리도 적용 가능: T1을 잘 처리했는가 (F2P 격) + 이전에 잘 되던 T8이 같은 도구에서 여전히 잘 되는가 (P2P 격). 즉 회귀 검사.
2. 자동 채점의 가치 — 가능한 영역은 무조건 자동화. 우리 컨텍스트에선 Y/N fine-grained 항목(04장)이 그것.
3. 큐레이션의 가치 — 원본 vs Verified의 5–10%p 차이는 데이터 품질 의 힘을 보여준다. 우리 T1–T10도 시간 지나며 다듬어야 할 가능성.

5.2 회귀 검사 도입

우리 실험의 운영 규칙(§7) 에 추가할 가치 있는 항목:

“Day 4부터 OpenClaw 셋업 동결 후, 매일 마지막 태스크는 이미 잘 되던 T1 또는 T8 재실행 으로 한다. 이전 점수와 ±1점 이내면 OK, 그 이상 떨어지면 회귀 로 기록.”

이게 SWE-bench의 P2P 정신.

5.3 결정 — 직접 도입 안 함, 사고방식 차용

• SWE-bench 자체는 코딩 도메인 — 본 실험과 무관
• F2P + P2P 사고방식은 회귀 검사 형태로 §7에 도입 검토
• 보고서에서 “우리는 코딩 능력이 아니라 워크플로 적합성을 본다”고 명시

6. 더 읽을거리

• Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (ICLR 2024) — SWE-bench 원 논문, 2,294개 GitHub 이슈 + F2P/P2P 채점 도입
• OpenAI Blog, “Introducing SWE-bench Verified” (2024) — 인간 SWE 큐레이션으로 500개 정제한 Verified 발표
• Yang et al., “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering” (NeurIPS 2024) — 코드 에이전트 프레임의 표준 인터페이스 제안
• SWE-bench 공식 사이트 (swebench.com) — leaderboard·데이터셋·실행 가이드
• LiveCodeBench 공식 사이트 — cutoff 기반 leakage 차단 알고리즘 코딩 평가

---

다음 장 미리보기

코드를 떠나 GUI·웹·OS 조작으로. OSWorld(369 OS 태스크)·WebArena(현실적 웹 환경)·Mind2Web(2000+ 사이트). 멀티앱 워크플로의 평가는 어떻게 가능한가. 08장.

이 장에서 확실히 알아야 하는 것

• FAIL_TO_PASS / PASS_TO_PASS 의 차이를 한 줄로 말할 수 있다.
• SWE-bench Verified가 왜 만들어졌고 점수가 왜 더 높게 나오는지 안다.
• 점수가 모델 + 프레임 컴비 라는 점을 인식하고 있다.
• 본 실험에 회귀 검사(P2P 정신) 를 가져올 구체적 방법을 안다.