agent benchmark 의 함정 — SWE-bench 와 실무 갭

점수가 오를수록 기대도 따라 오른다 — 그게 문제다

코딩 에이전트가 새로 발표될 때마다 SWE-bench 점수가 헤드라인을 장식한다. 2024년 초반까지 상위 에이전트들이 SWE-bench Verified 기준 30%대에 머물렀는데, 2025년을 기점으로 50%를 넘기는 에이전트가 속속 등장했다. 숫자가 가파르게 오르면서 "이제는 에이전트에게 상당 부분을 맡길 수 있다"는 인식이 업계 전반에 퍼졌다. 우리 팀도 초기에는 그 흐름을 따랐다. 에이전트를 고를 때 SWE-bench 점수를 주요 기준으로 삼았고, 점수가 높은 에이전트가 실무에서도 더 낫겠거니 기대했다.

그런데 실제로 써보면서 이상한 경험이 반복됐다. SWE-bench Verified 점수 차이가 15%포인트 이상 나는 두 에이전트를 병렬로 써봤는데, 우리 코드베이스에서의 실제 성과 차이는 그 절반도 되지 않았다. 심지어 낮은 점수의 에이전트가 특정 유형의 태스크에서 더 일관된 결과를 냈다. 벤치마크와 실무 사이에 뭔가 구조적인 괴리가 있다는 걸 직접 확인한 순간이었다.

SWE-bench가 측정하는 것과 측정하지 못하는 것

SWE-bench는 GitHub에 올라온 실제 이슈 리포트를 기반으로 만들어졌다. 에이전트는 이슈 본문을 읽고 관련 코드베이스를 수정해 기존 테스트를 통과시켜야 한다. 설계 철학 자체는 건전하다. 합성 문제가 아닌 공개 오픈소스 프로젝트의 실제 버그라는 점에서 현실에 훨씬 가깝고, 테스트 통과라는 기준이 채점을 객관적으로 만든다.

그러나 구조적인 전제 조건이 세 가지 맹점을 만든다. 첫째, 문제가 이미 정의되어 있다. 이슈 본문에는 "이 함수에서 이런 입력이 들어오면 잘못된 값이 나온다"는 식으로 무엇을 고쳐야 하는지가 명시되거나 강하게 암시된다. 실무에서 진짜 어려운 일의 절반은 증상을 보고 원인을 특정하는 과정인데, 이 단계가 벤치마크에서는 생략된다. 둘째, 수정 범위가 좁다. SWE-bench 태스크의 상당수는 1~3개 파일 수정으로 해결된다. DB 스키마, 비즈니스 로직, API 레이어, 외부 연동이 동시에 얽히는 실무 변경은 벤치마크 태스크 분포에서 구조적으로 과소 대표된다. 셋째, 테스트 통과와 올바른 구현은 다르다. 에이전트가 테스트를 통과시키기 위해 특수 케이스를 하드코딩하거나 우회 구현을 선택한다는 점이 학술 논문에서도 여러 차례 보고됐다. 벤치마크 채점 시스템은 이를 구분하지 못한다.

결제·정산 현장에서 이 갭이 특히 위험한 이유

일반적인 소프트웨어 개발에서 에이전트가 실수를 하면 테스트나 코드 리뷰에서 걸린다. 결제·정산·자동화 도메인에서는 성격이 다르다. 이 도메인이 요구하는 능력이 정확히 벤치마크가 측정하지 못하는 부분과 겹친다.

결제 처리 로직의 핵심 중 하나는 멱등성(idempotency) 이다. 동일한 결제 요청이 네트워크 오류나 타임아웃으로 두 번 들어오더라도 실제 과금은 한 번만 일어나야 한다. 이 요구사항은 "이슈에 명시된 버그를 고쳐라" 형태로 주어지지 않는다. 팀의 암묵적 관례이고, 결제 도메인을 이해한 사람이라면 자연스럽게 챙기는 사항이다. SWE-bench 방식으로 에이전트를 평가하면 이 능력은 채점 대상 자체가 되지 않는다. 정산 배치 처리는 영향 범위가 수직으로 깊다. 정산 집계 기준이 되는 필드 하나를 변경하면 DB 쿼리, 집계 로직, 리포트 생성 모듈, 외부 정산 시스템 전송 포맷, 슬랙·이메일 알림 템플릿까지 연쇄적으로 영향이 퍼진다. "단일 파일 수정"에 최적화된 에이전트는 이런 변경에서 절반만 처리하고 나머지를 놓친다.

우리 팀이 실제로 겪은 실패 케이스

구체적인 사례를 하나 공개한다. 정산 배치 스크립트에서 merchant_id 필드를 partner_id로 일괄 변경하는 태스크를 에이전트에게 지시했다. 에이전트는 지시받은 배치 스크립트 파일 내에서는 완벽하게 변경을 처리했다. 문제는 그 필드를 참조하는 다른 세 곳—DB 뷰 정의 파일, 월별 정산 리포트 생성 모듈, PG사로 전송하는 데이터 직렬화 코드—을 전혀 건드리지 않았다는 것이다. 에이전트는 명시적으로 지정한 파일은 정확히 수정했지만, 변경 영향 범위를 스스로 탐색해 연관 파일을 찾아내는 데 실패했다. SWE-bench 태스크였다면 부분 점수라도 받았을 것이다. 실무에서는 다음 정산 실행 시 데이터 불일치로 이어졌고, 수동 대사 작업이 필요했다.

두 번째 사례는 PG사 웹훅 처리 로직이다. 웹훅 재전송 케이스를 처리하는 코드를 작성하도록 지시했을 때, 에이전트는 웹훅 수신과 상태 업데이트 로직을 구현했지만 멱등성 키 체크를 누락했다. 지시문에 명시하지 않았기 때문이다. 에이전트는 주어진 요구사항은 전부 구현했다. 그러나 결제 도메인 암묵지가 없으니 "당연히 넣어야 할 것"을 빠뜨렸다. 코드 리뷰에서 잡아냈지만, 만약 자동 배포 파이프라인이었다면 이중과금 리스크가 프로덕션에 그대로 들어갔을 것이다.

벤치마크 점수와 실무 유용성의 구조적 갭 정리

정리하면 갭은 세 가지 축에서 발생한다. 문제 정의 능력(증상으로 원인 파악), 변경 영향 범위 탐색 능력(수정 파급 범위 자율 탐색), 도메인 암묵지 적용 능력(팀 관례와 도메인 규칙을 설명 없이 반영)이다. SWE-bench는 세 번째 축을 거의 측정하지 못하고, 두 번째 축은 부분적으로만 측정한다. 결제·정산·자동화 현장에서는 세 번째 축이 실수의 비용 규모를 결정한다.

벤치마크가 의미 없다는 말이 아니다. 에이전트 후보군을 1차 필터링하는 데는 여전히 유효하다. 점수 20%인 에이전트보다 50%인 에이전트의 기본기가 낫다는 건 대체로 사실이다. 그러나 55%와 60%의 차이가 우리 코드베이스에서도 같은 비율로 나타날 것이라는 기대는 틀릴 가능성이 높다. 벤치마크 점수는 "이 에이전트는 적어도 이 정도 기본기는 된다"는 하한선 정보로 쓰는 게 맞다. 상한선이나 실무 성능 예측 지표로 쓰면 오판이 생긴다.

실행 가능한 시사점 — 지금 당장 쓸 수 있는 평가 방법 5가지

1. 팀 고유의 평가 태스크 세트를 만들어라. 우리 팀은 신규 에이전트 평가에 5종 태스크를 쓴다: (a) 단일 파일 버그 수정, (b) 2~3개 파일에 걸친 기능 추가, (c) 도메인 암묵지가 필요한 수정(결제 상태 전이 관련 등), (d) 영향 범위가 넓은 리팩터링, (e) 모호하게 기술된 태스크. 이 다섯을 통과한 에이전트만 실제 코드베이스에 투입한다. 30분이면 충분한 평가다.

2. 암묵지 테스트를 반드시 포함시켜라. 팀 내부에서만 아는 관례를 설명 없이 지시문에 담는다. 에이전트가 그 관례를 자발적으로 지키는지, 어긋나면 질문을 하는지 확인한다. 설명도 없이 잘못된 패턴으로 구현하고 넘어가는 에이전트는 결제·정산 도메인에서 위험하다.

3. 영향 범위 탐색 능력을 별도로 채점하라. "이 필드 이름을 바꿔달라"고 지시하고 에이전트가 자발적으로 참조 파일을 찾아냈는지 확인한다. 찾아냈으면 가점, 놓쳤으면 감점, 불확실해서 먼저 질문했으면 중립. 이 단일 지표가 우리 도메인에서 가장 실질적인 예측 변수다.

4. 벤치마크는 후보를 좁히는 데만 쓰고, 컷라인을 낮게 설정하라. SWE-bench Verified 30% 이상이면 1차 후보군에 올리고, 이후는 반드시 직접 평가로 결정한다. 55%와 60%의 차이를 실무 선택 기준으로 삼지 않는다.

5. 평가를 고정 시점으로 반복하라. 에이전트는 모델 업데이트 주기가 짧다. 두 달 전 평가 결과가 지금도 유효하다는 보장이 없다. 분기에 한 번, 동일한 평가 태스크 세트로 재평가한다. 우리는 이를 팀 루틴으로 만들었고, 세 번의 재평가에서 두 번 선호 에이전트가 바뀌었다. 벤치마크 리더보드는 그 사실을 우리보다 늦게 알려줬다.

벤치마크는 지도이고 우리 코드베이스는 실제 지형이다. 지도는 참고하되, 판단은 직접 걸어봐야 나온다.