SWE-bench

SWE-bench는 언어 모델이 실제 GitHub 이슈를 코드 수정으로 해결할 수 있는지를 재는 벤치마크입니다. 객관식 문제를 풀거나 함수 하나를 작성하는 방식이 아니라, 저장소 전체를 받아 이슈를 읽고 어느 파일의 어느 부분을 고쳐야 하는지 스스로 찾아 패치를 만들어야 합니다. 코딩 AI의 성능을 이야기할 때 가장 자주 인용되는 지표입니다.

어떻게 채점하는가

논문 제목은 'SWE-bench: Can Language Models Resolve Real-World GitHub Issues?'이고 ICLR 2024에서 발표됐습니다. 널리 쓰이는 파이썬 저장소 12곳에서 가져온 실제 이슈 2,294개로 구성되며, 각 문제에는 그 이슈를 실제로 해결했던 커밋과 그때 함께 추가된 테스트가 짝지어져 있습니다. 모델이 만든 패치를 적용한 뒤 저장소의 테스트를 돌려서 통과하면 해결로 인정하는 방식이라, 채점에 사람이나 LLM 평가자가 개입하지 않습니다.

이 자동 채점 구조가 SWE-bench가 신뢰받는 이유입니다. 대신 문제도 만듭니다. 테스트가 지나치게 특정 구현을 전제하고 있으면, 사람이 봤을 때 멀쩡한 해결책도 실패로 기록됩니다. 이슈 본문만으로는 무엇을 고쳐야 하는지 알 수 없는 문제도 섞여 있었습니다.

Verified와 그 밖의 변형

그래서 나온 것이 SWE-bench Verified입니다. 소프트웨어 개발자 93명이 원본 문제를 하나씩 검토해, 설명이 불충분하거나 테스트가 정당한 해결책을 틀렸다고 판정할 수 있는 항목을 걸러 냈습니다. 그 결과 남은 500개가 Verified 세트이고, 지금은 대부분의 모델 발표가 원본 대신 이 세트의 점수를 인용합니다. 300개짜리 SWE-bench Lite, 다국어 저장소를 다루는 Multilingual, 화면 요소가 포함된 Multimodal 같은 변형도 있습니다.

발표 당시에는 가장 성능이 좋은 모델도 문제의 1.96%밖에 풀지 못했습니다. 이후 몇 년 사이 점수가 크게 올랐는데, 모델 자체의 발전도 있지만 하네스의 기여가 큽니다. 파일을 검색하고, 테스트를 돌려 보고, 실패하면 다시 고치는 에이전트 루프를 어떻게 짜느냐에 따라 같은 모델도 점수가 크게 달라집니다. 그래서 점수를 볼 때는 어떤 모델인지와 함께 어떤 하네스를 썼는지도 확인해야 합니다.

SWE-bench가 특별한 자리를 차지하게 된 배경에는 코딩 AI의 성격 변화가 있습니다. 함수 하나를 자동 완성하던 시절에는 짧은 코드 조각을 채점하는 벤치마크로 충분했지만, 저장소를 돌아다니며 파일을 고치는 도구가 나오면서 '한 번에 답을 맞히는가'가 아니라 '여러 단계를 거쳐 목표를 달성하는가'를 재야 했습니다. SWE-bench는 그 전환을 대표하는 시험지가 됐습니다.

점수를 읽을 때 주의할 점

가장 큰 한계는 데이터 오염입니다. 문제로 쓰인 이슈와 해결 커밋은 공개 저장소에 있던 것이라, 모델의 학습 데이터에 이미 들어갔을 가능성을 배제하기 어렵습니다. 또한 대상이 파이썬 저장소에 몰려 있고 문제 유형도 버그 수정에 치우쳐 있어, 신규 기능 설계나 대규모 리팩터링 능력은 거의 반영되지 않습니다. 사내 코드베이스처럼 문서가 부실한 환경의 난이도도 담기지 않습니다.

이런 이유로 SWE-bench Pro나 Terminal-Bench 같은 후속 벤치마크가 계속 나오고 있습니다. 더 어려운 문제를 넣거나, 코드 수정만이 아니라 터미널에서 여러 도구를 다루는 능력까지 함께 재는 방향입니다. 모델 발표 자료가 어느 벤치마크의 점수를 인용했는지 확인하지 않으면 서로 다른 시험 성적을 나란히 비교하게 됩니다.

실무 판단에도 그대로 쓰기는 어렵습니다. Claude Code, Cursor, Devin 같은 도구를 고를 때 SWE-bench 점수는 참고 자료 가운데 하나일 뿐이고, 우리 저장소의 실제 이슈 몇 건을 각 도구에 시켜 보는 것이 훨씬 확실한 근거가 됩니다. 벤치마크는 모델의 발전 속도를 재는 자로 쓰고, 도구 선택은 자체 평가로 하는 편이 안전합니다.