AI VIDEO BRIEFING

SWE-bench 개발자가 직접 말하는 코딩 AI 평가의 현재: 통과율 10%에서 80%까지의 3년

깃허브 이슈를 그대로 문제로 삼는 평가 도구 SWE-bench를 만든 연구자가 벤치마크 제작 과정과 에이전트 도구 설계, 학습용 문제의 대량 생성까지 3년간의 작업을 직접 설명한 온라인 세미나의 내용을 정리했다.

코딩 AI의 채점 기준을 만든 사람들, SWE-bench 3년의 기록 영상 대표 이미지

핵심 메시지

  • 함수 하나를 채워 넣는 기존 코딩 문제 대신, 실제 깃허브의 이슈와 그 이슈를 해결한 코드 변경을 짝지어 평가 문제로 만든 것이 SWE-bench의 출발점이다.
  • 정답 여부는 사람이 채점하지 않는다. 실제 개발자가 함께 추가한 테스트 코드를 모델의 수정본에 돌려 통과하는지로 판정한다.
  • 초기에는 통과율이 한 자릿수에 머물렀지만, 널리 쓰이는 검증본 기준으로 최근에는 80% 안팎까지 올라왔다.
  • 성능을 끌어올린 것은 도구를 정교하게 다듬는 작업보다 모델 자체의 개선이었다는 것이 발표자의 판단이다.
  • 이제 관심은 평가에서 학습 데이터로 옮겨 갔다. 저장소 하나에서 버그를 인위적으로 만들어 내는 방식으로 문제 수를 수만 건 규모까지 늘렸다.

쉽게 이해하기

2023년 무렵 코딩 AI를 평가하는 대표적인 방법은 함수 설명을 주고 본문을 채우게 하는 문제였다. 발표자는 그런 문제가 면접 준비에는 쓸모 있어도 실제 개발과는 거리가 멀다고 판단했다. 그래서 눈을 돌린 것이 깃허브였다. 누군가 문제를 신고하면 관리자가 코드를 고치고 재발을 막는 테스트를 함께 붙여 병합하는 흐름이, 그대로 평가 문제의 형태가 될 수 있다는 착상이었다.

구성 방식은 단순하다. 이슈와 연결된 코드 변경을 모아, 테스트에 해당하는 부분과 실제 수정에 해당하는 부분으로 나눈다. 모델에게는 이슈 설명과 저장소를 주고 수정본을 만들게 한 뒤, 떼어 두었던 테스트를 돌려 통과 여부를 본다. 가장 손이 많이 간 작업은 문제마다 실행 가능한 환경을 따로 만드는 일이었고, 그 과정을 거쳐 12개 저장소에서 2,294건의 문제가 추려졌다.

널리 쓰이는 것은 그중 500건을 골라낸 검증본이다. 공개 초기에는 통과율이 한 자릿수에 머물렀지만 최근 상위 모델은 80% 안팎을 보고한다. 다만 발표자는 이 검증본이 원본보다 쉬운 쪽으로 추려졌다고 인정한다. 문제 절반 이상은 이슈 본문에 어디를 고쳐야 하는지가 이미 드러나 있어, 코드베이스를 뒤져 위치를 찾아내는 어려움이 빠져 있다는 것이다.

평가 다음으로 이어진 작업은 모델이 코드베이스를 다루는 방식이었다. 초기 모델들은 터미널 명령을 그대로 쓰는 데 서툴러서, 파일을 열어 보고 고치는 전용 도구를 따로 만들어 붙였다. 특히 텍스트 치환 명령으로 코드를 고치게 하면 사소한 실수가 연쇄적으로 쌓였기 때문에, 바꿀 줄 번호를 지정하면 새 코드로 갈아 끼우는 방식과 문법 검사를 함께 넣었다.

그런데 1년쯤 지나며 판단이 바뀌었다. 모델들이 터미널 명령을 더 이상 어려워하지 않게 되면서, 도구를 모두 걷어내고 명령줄만 쓰게 한 간소한 방식으로도 좋은 점수가 나왔기 때문이다. 발표자는 도구를 바꿔 가며 얻는 차이보다 모델을 바꿔 가며 얻는 차이가 훨씬 크다고 정리한다. 그래서 마지막 축은 학습 데이터로 옮겨 간다. 이슈와 코드 변경 짝을 모으는 방식은 환경 구축에 손이 많이 들어 규모를 키우기 어렵다. 그래서 반대 방향을 택했다. 저장소 최신 버전으로 실행 환경을 하나만 만들어 두고, 코드 구조를 기계적으로 흐트러뜨려 기존 테스트가 깨지도록 만드는 식으로 버그를 대량 생성한 것이다. 이 방식으로 128개 저장소에서 5만 건 규모의 문제를 확보했다.

주요 인사이트

  • 채점을 사람 손에 맡기지 않고 실제 프로젝트가 이미 갖고 있던 테스트에 맡긴 것이, 이 벤치마크가 빠르게 자리 잡은 이유다. 사람이 문제를 창작하는 방식과 달리 현실의 작업 흐름에서 문제가 저절로 나온다.
  • 통과율이 80%에 도달했다고 해서 문제가 소진된 것은 아니다. 지금까지 제출된 결과를 모두 합치면 500건 중 약 90%가 한 번 이상 풀렸고, 네 번 이상 풀린 비율도 89%에 이르러 아직 여유가 남아 있다.
  • 다음 단계의 어려운 문제는 이슈 설명이 불완전해서 어디를 고쳐야 하는지 코드베이스를 직접 탐색해야 하는 경우, 그리고 여러 파일에 걸친 큰 수정이 필요한 경우다. 수정 규모와 난이도의 상관관계는 뚜렷하다.
  • 테스트를 통과했다고 좋은 코드는 아니다. 발표자는 모델이 자기 코드베이스를 관리하게 두면 파일을 지우지 않고 계속 쌓아 올려, 최종본 위에 또 최종본이 붙는 식으로 어질러진다고 지적한다.
  • 깃허브에 이슈와 코드 변경 짝이 드문 언어에서는 기존 수집 방식이 통하지 않는다. 코드를 기계적으로 망가뜨려 문제를 만들어 내는 방식이 이런 언어들의 돌파구가 될 수 있다는 것이 발표자의 기대다.

자주 묻는 질문

SWE-bench의 문제는 어떻게 만들어지나요?

저장소의 코드 변경 기록을 모아 이슈와 연결된 것만 남기고, 그중 테스트가 추가되거나 수정된 것을 고릅니다. 변경 내용을 테스트 부분과 실제 수정 부분으로 나눈 뒤 실행 가능한 환경을 만들어, 모델의 수정본에 그 테스트를 돌려 채점합니다.

도구를 잘 만드는 것과 모델을 개선하는 것 중 무엇이 더 효과적인가요?

발표자는 모델 쪽이라고 답합니다. 도구를 바꿔 가며 측정한 차이보다 도구를 고정하고 모델만 바꿨을 때의 차이가 훨씬 컸기 때문입니다. 실제로 도구를 모두 걷어내고 명령줄만 쓰게 한 방식도 좋은 성적을 냈습니다.

학습용 문제를 대량으로 만드는 방법은 무엇인가요?

저장소 최신 버전으로 실행 환경을 하나 만들어 둔 뒤, 함수 구조를 기계적으로 변형해 연산자를 뒤집거나 조건을 흐트러뜨려 기존 테스트가 깨지게 만듭니다. 언어 모델로 버그를 만들거나 과거 수정 내역을 되돌리는 방법도 함께 씁니다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗

관련 AI 소식