코딩 에이전트 벤치마크 총정리: SWE-bench·Terminal-Bench·RExBench가 실제로 재는 능력

핵심 메시지

• 코딩 에이전트는 코드를 쓰는 데서 멈추지 않고 직접 실행해 결과를 확인한다는 점에서 다른 에이전트와 구분된다.
• SWE-bench는 실제 깃허브 이슈와 저장소를 그대로 가져와 유닛 테스트 통과 여부로 채점했고, 초기 성공률은 한 자릿수에 그쳤다.
• Terminal-Bench는 터미널과 컨테이너를 전제로 태스크를 재설계해 소프트웨어 공학뿐 아니라 과학 계산·보안·머신러닝까지 범위를 넓혔다.
• 같은 모델이라도 어떤 하네스에서 돌리느냐에 따라 점수가 달라져, 모델과 하네스를 분리해 측정하는 것이 중요해졌다.
• RExBench는 논문의 새 연구 아이디어를 직접 구현하게 시키는데, 완전 성공률은 매우 낮고 '어떤 파일을 고쳐야 하는가'가 병목으로 드러났다.

쉽게 이해하기

발표자는 코딩 에이전트를 '요청받은 문제를 코드베이스나 실행 환경과 상호작용하며 풀어내는 에이전트'로 정의한다. 다른 에이전트와 갈리는 지점은 실행 기반이라는 점으로, 작성한 코드를 실제로 돌려 표준 출력이나 산출 파일을 직접 확인하고 검증할 수 있다. 그래서 코딩은 검증이 쉬운 과제처럼 보이지만, 실제로 어려운 것은 검증 자체가 아니라 검증할 문제와 환경을 만드는 일이다. 운영체제와 라이브러리 버전, 웹 접근을 어느 시점까지 허용할지, 어떤 파일에 수정 권한을 줄지, GPU를 단일 노드로 줄지 멀티 노드로 줄지까지 서버를 세팅하듯 일일이 정해야 하고, 현실에 가까운 난이도를 확보하려면 실제 개발자와 연구자가 풀기 어려워하는 문제를 모아야 해서 비용도 함께 올라간다.

첫 이정표인 SWE-bench는 원래 에이전트가 아니라 '언어모델이 실제 깃허브 이슈를 해결할 수 있는가'를 묻는 연구였다. 12개 저장소에서 약 9만 건의 풀 리퀘스트를 모은 뒤, 이슈가 실제로 해결되고 테스트 파일까지 바뀐 것만 남겼다. 이슈 설명은 평균 195단어로 짧은 반면 코드베이스는 파일 3,000개, 43만 줄 규모라서, 초기 방식은 BM25 키워드 검색으로 관련 코드를 찾아 패치를 만들고 유닛 테스트 통과 여부로 채점하는 단순한 구조였다. 당시 성공률은 한 자릿수에 머물렀지만 지금은 상위 모델들이 80%를 넘기며 사실상 포화 상태에 이르렀다.

그 뒤를 이은 Terminal-Bench는 아예 터미널 환경을 전제로 한다. 태스크는 프롬프트, 도커 이미지, 검증 테스트, 레퍼런스 솔루션, 제한 시간으로 구성되고 최종 제출물은 컨테이너다. 예컨대 코볼 코드를 파이썬 파일로 바꾸라고 시키면 중간 산출물은 보지 않고 실행 결과가 레퍼런스와 일치하는지만 확인한다. 전문가가 한 시간 안에 푸는 문제부터 168시간, 즉 일주일 가까이 걸리는 문제까지 포함돼 요구 수준이 사람의 작업 시간을 넘어서고 있다.

여기서 중요한 관찰이 나온다. 에이전트는 크게 하네스와 대형언어모델로 나눌 수 있는데, 실험을 보면 모델마다 자기 진영의 하네스에서 가장 높은 점수가 나오는 경향이 뚜렷했다. 어떤 모델은 하네스 의존도가 크고 어떤 모델은 그렇지 않다는 뜻이라, 둘을 분리해 재는 설계가 필요해진다. 실패 원인을 뜯어보면 코드 작성보다 실행 단계에서 무너지는 경우가 많았다. 코드는 만들어졌지만 실제로 돌아가지 않는 코드였던 것이다.

마지막으로 소개된 RExBench는 훨씬 연구지향적이다. 기존 논문과 그 구현 코드를 준 뒤 새로운 연구 아이디어를 어떻게 구현하고 어떻게 검증할지까지 시키고, 정답 코드는 데이터 오염을 막기 위해 비공개로 두고 박사과정 이상 전문가가 직접 짠 결과를 골드 답안으로 삼는다. 평가는 모델 학습 시간까지 포함해 12시간을 주고 가상머신으로 라이브러리 버전까지 고정한다. 골드와의 성능 차이를 ±2시그마 안에서 인정하는 완전 성공 기준으로 보면 점수는 처참할 정도로 낮고, 최종 파일이 실행되기만 하면 인정하는 기준으로 낮춰도 한 조합에서만 68점 수준이 나왔다.

주요 인사이트

• 벤치마크가 1년을 못 버티고 포화된다는 사실 자체가 지금 코딩 에이전트의 발전 속도를 보여준다. Terminal-Bench 2.0조차 공개 1년 만에 80%대 초반까지 올라와 다음 버전이 준비되고 있다.
• 성능 차이의 원인을 모델 탓으로만 돌리면 오독이 생긴다. 같은 모델도 실행 하네스에 따라 점수가 뒤집히므로, 벤치마크 순위를 볼 때는 어떤 하네스로 측정했는지를 함께 봐야 한다.
• RExBench에서 수정할 파일명을 힌트로 알려주자 0점이던 모델들이 일부 문제를 풀기 시작했다. 복잡한 연구 아이디어 구현의 병목이 코드 생성 능력보다 '어디를 고칠지 찾아내는 탐색'에 있다는 뜻이다.
• 코드는 실행해서 채점할 수 있다는 점에서 검증이 쉬운 축에 속하지만, 진짜 비용은 환경 구축과 문제 수집에 있다. 벤치마크 연구가 사실상 서버 운영 설계에 가까워지는 이유다.
• 우리가 매일 쓰는 코딩 에이전트의 기능 상당수는 벤치마크 점수를 올리려는 연구에서 빠르게 흘러나온 결과물이다. 앞으로는 화학 리서치나 공정 환경처럼 도메인별로 무엇을 어떤 환경에서 평가할지 구체화하는 방향으로 옮겨가고 있다.

자주 묻는 질문

관련 AI 소식