agent benchmark 의 함정 — SWE-bench 와 실무 갭
SWE-bench 점수가 올라갈수록 에이전트가 실무에서도 더 유용해지는가. 우리가 경험한 차이와 그 이유를 정리한다.
새로운 코딩 에이전트가 발표될 때마다 SWE-bench 점수가 함께 나온다. 숫자가 올라갈수록 더 나은 에이전트라는 인식이 형성된다. 우리도 처음엔 그 숫자를 기준으로 도구를 선택했지만, 실제로 써보면서 벤치마크 점수와 실무 유용성 사이의 거리를 느끼기 시작했다.
SWE-bench 가 측정하는 것
SWE-bench 는 실제 GitHub 이슈를 기반으로 한다. 에이전트가 이슈 설명을 읽고 코드베이스를 수정해서 테스트를 통과시키면 성공으로 기록된다. 잘 정의된 문제를 독립적으로 해결하는 능력을 측정한다는 점에서 의미 있는 벤치마크다.
그러나 이 방식에는 구조적인 한계가 있다.
문제가 미리 정의되어 있다. 이슈 설명에 무엇을 고쳐야 하는지가 명시되어 있다. 실무에서 어려운 일의 절반은 “무엇이 문제인지” 파악하는 것인데, 이 부분이 벤치마크에서는 이미 제공된다.
단일 파일 또는 소수 파일 수정이 대부분. 실무 변경사항은 여러 레이어에 걸쳐 영향을 준다. DB 스키마, 비즈니스 로직, API, 프론트엔드가 동시에 연관되는 경우가 많다. 벤치마크 태스크는 이런 교차 레이어 작업 비율이 낮다.
테스트 통과 = 올바른 구현이 아닐 수 있다. 테스트를 통과시키기 위해 특수 케이스를 하드코딩하거나, 기존 테스트의 의도와 어긋나는 방식으로 구현하는 경우가 에이전트 평가에서 보고된 바 있다.
실무에서 실제로 겪은 차이
우리 팀이 에이전트를 실무에 쓰면서 벤치마크로는 보이지 않는 문제를 마주한 경우들이다.
암묵적 관례를 모른다. 코드베이스에 문서화되지 않은 패턴이 있다. “이 레이어에서는 이런 예외를 직접 던지지 않는다”는 식의 팀 약속. 에이전트는 이걸 파일을 읽어서 추론해야 하는데, 일관성이 없거나 예외 사례가 있으면 틀린 패턴을 학습하는 경우가 생긴다.
변경 범위 추정이 어렵다. “이 필드 이름을 바꿔달라”고 지시하면 지시한 파일만 바꾸는 경우가 있다. 그 필드를 참조하는 다른 파일들까지 찾아서 일괄 수정하는 것, 즉 변경 영향 범위를 스스로 파악하는 능력은 아직 불안정하다.
벤치마크를 참고하되 실제 테스트가 필요하다
SWE-bench 점수가 낮은 에이전트가 특정 작업에서는 더 유용할 수 있다. 반대로 점수가 높아도 실무 환경에서 기대에 못 미칠 수 있다.
새 에이전트를 평가할 때 우리가 사용하는 방법은 실제 프로젝트에서 작은 태스크 몇 개를 직접 시켜보는 것이다. 벤치마크는 후보를 좁히는 데 참고하고, 최종 결정은 직접 경험으로 한다. 숫자보다 “우리 코드베이스에서 이 에이전트가 얼마나 잘 맞는가”가 더 실질적인 질문이다.
— by mings