이 글은 Anthropic 엔지니어링 블로그에 2025년 1월 6일 게재된 “Raising the bar on SWE-bench Verified with Claude 3.5 Sonnet” 을 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/swe-bench-sonnet
한 줄로 말하면 #
Claude 3.5 Sonnet이 코딩 벤치마크 1위를 찍은 건, 모델이 좋아져서만이 아니라 AI가 쓰는 도구를 잘 설계했기 때문이다.
어떤 문제를 해결하려 했나 #
AI가 코드를 잘 짠다고 하지만, 정말 실무에서 쓸 수 있는 수준인지 어떻게 알 수 있을까요?
“간단한 함수 작성"이나 “알고리즘 풀이"는 AI가 잘합니다. 하지만 실제 개발 현장은 다릅니다. 누군가 GitHub에 이런 이슈를 올립니다.
“requests 라이브러리에서 특정 조건일 때 타임아웃이 무시되는 버그가 있습니다.”
이 이슈를 해결하려면 저장소 전체 코드를 파악하고, 어떤 파일을 수정해야 할지 찾아내고, 코드를 바꾸고, 테스트까지 통과시켜야 합니다. 사람도 몇 시간이 걸리는 작업입니다.
이걸 AI 혼자 할 수 있을까? 이것을 측정하는 도구가 SWE-bench입니다.
해결책: SWE-bench로 측정하고, 도구 설계로 돌파하다 #
SWE-bench(소프트웨어 엔지니어링 벤치마크)란 #
SWE-bench(Software Engineering Benchmark)는 AI가 실제 GitHub 이슈를 해결할 수 있는지 테스트하는 평가 도구입니다.
GitHub 이슈 제공
↓
AI가 저장소를 탐색하고 코드 수정
↓
실제 유닛 테스트로 정답 여부 채점중요한 점은 AI 모델 단독이 아니라, 모델 + 도구(에이전트 시스템) 전체를 평가한다는 것입니다.
Anthropic의 접근법: 단순하게, 도구를 정교하게 #
Anthropic이 선택한 에이전트 구조는 놀랍도록 단순합니다.
[에이전트 구성]
초기 프롬프트 (접근 방법 제안)
+
Bash Tool (터미널 명령 실행)
+
Edit Tool (파일 읽기/수정)복잡한 구조 대신, 도구 자체를 정교하게 만드는 데 집중했습니다.
특히 Edit Tool에는 한 가지 규칙이 있습니다. 문자열을 교체할 때 정확히 일치하는 경우에만 수정을 허용합니다. 모호한 수정을 원천 차단하는 것입니다.
“도구 인터페이스를 설계하는 데 사람 인터페이스를 설계하는 것만큼 공을 들여야 한다.”
결과 / 효과 #
| 모델 | SWE-bench 점수 |
|---|---|
| Claude 3 Opus | 22% |
| Claude 3.5 Sonnet (구) | 33% |
| 이전 1위 | 45% |
| Claude 3.5 Sonnet (신) | 49% |
한 세대 만에 22% → 49%. 두 배 이상 올랐습니다.
단, 이 수치가 만능은 아닙니다. 성공한 케이스를 보면 수백 번의 반복 작업과 10만 토큰 이상을 소비하는 경우도 있었습니다. 아직 모든 이슈를 가볍게 해결하는 단계는 아닙니다.
핵심 결론 #
모델을 키우는 것만이 답이 아닙니다.
Claude 3.5 Sonnet이 1위에 오른 핵심은 AI가 사용하는 도구의 인터페이스를 정교하게 만든 것이었습니다. 도구가 AI의 실수를 원천 차단하도록 설계하자, 성능이 뛰어올랐습니다.
“AI 성능의 문제인 줄 알았는데, 사실은 AI가 쓰는 도구 설계의 문제였다.”
내 작업에 적용한다면 #
현재 만들고 있는 발행 파이프라인에도 이 원칙을 적용할 수 있습니다.
[지금 파이프라인]
본문 수집 → Claude 분석 → 마크다운 생성 → git push
[도구 설계 원칙 적용 후]
본문 수집
↓ [검사: 상태코드 200인지 확인]
Claude 분석
↓ [검사: front matter 형식이 맞는지 확인]
마크다운 생성
↓ [검사: 필수 섹션이 모두 있는지 확인]
git push각 단계 사이에 실수를 원천 차단하는 검사를 넣는 것. 이게 SWE-bench에서 Anthropic이 배운 교훈이고, 우리 파이프라인을 자동화할 때도 그대로 적용됩니다.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.