코딩 에이전트에게 "이런 일을 대신 처리하는 에이전트를 만들어줘"라고 맡기는 일이 늘고 있다. AgentSWE는 그렇게 만들어진 결과물이 요구대로 작동하는지를 처음으로 정면에서 측정한 벤치마크다. 생성·편집·최적화 세 종류 25개 과제에서, 평가된 어떤 코딩 에이전트도 요구사항이 원하는 수준의 에이전트를 안정적으로 만들어내지 못했다. 개발 중 보여준 성능과 실제 납품물의 성능 사이 간극은 예외가 아니라 기본값이었다.
먼저 용어 두 개를 갈라 두자. 여기엔 에이전트가 두 겹으로 나온다. 하나는 만들어지는 쪽이다. 예를 들어 쇼핑몰 고객 문의를 읽고 환불·교환·배송지연으로 분류해 담당자에게 넘기는 프로그램 — 사람이 매번 붙지 않아도 혼자 판단하고 처리하는 이런 프로그램을 에이전트라고 부른다. 다른 하나는 만드는 쪽, 즉 요구사항을 자연어로 받아 그 프로그램을 코드로 짜 주는 코딩 에이전트다(Claude Code, Codex 같은 것). AgentSWE가 시험대에 올리는 것은 만드는 쪽이고, 채점하는 것은 만들어진 쪽의 작동이다.
여기엔 조용한 가정이 하나 깔려 있다. 요구사항을 받은 코딩 에이전트가 "그 요구를 충실히 수행하는 에이전트"를 납품하리라는 믿음이다. 문제는 그 믿음을 검증할 도구가 없었다는 점이다.
기존 벤치마크는 결이 다른 것을 잰다. SWE-bench 계열은 코딩 에이전트가 짠 코드를 미리 아는 정답 패치·테스트에 대조하고, 요구 문서에서 저장소를 짓거나 논문을 보고 구현을 재현시키는 벤치마크도 결국 "정해진 정답에 대고 코드를 채점"한다. 반대로 AgentBench 이후의 에이전트 벤치마크는 이미 완성된 에이전트를 놓고 얼마나 잘 작동하는지만 묻는다. 코딩 에이전트가 그 에이전트를 애초에 만들어낼 수 있었는지는 아무도 묻지 않았다.
문제 공간의 다른 흐름들도 질문이 어긋나 있다. '에이전트를 만들고 개선하는 에이전트' 연구(예: Arbor, JIT-Agent)는 특수한 탐색 절차나 메타 에이전트가 점수를 얼마나 끌어올리는가를 재고, WorFBench·AIE-Bench 같은 에이전트 구성 벤치마크도 통제된 경계 안에서의 개선을 본다. AgentSWE는 여기서 두 가지가 다르다. 첫째, 특수 장치가 아니라 범용 코딩 에이전트를 세운다. 둘째, 점수 끌어올리기가 아니라 "자연어 요구가 묘사한 에이전트를 실제로 납품하는가"라는 충실성(요구를 실제 행동으로 얼마나 충족했는가)을 묻는다. 그리고 생성 한 단계가 아니라 생성·편집·최적화 전 생애주기를 덮는다.
AgentSWE의 설계를 관통하는 구도는 '시험'이 아니라 '수주(受注)'다. 시험은 정답을 아는 문제를 푸는 것이고, 수주는 고객이 말로 던진 요구를 받아 결과물을 납품하는 것이다. 이 글 전체에서 비유는 이 하나 — 요구를 받아 납품한다 — 로 통일한다.
각 과제의 출발점은 자연어 요구사항이다. 논문은 이 요구사항을 네 부분으로 쪼개 건넨다. 에이전트가 무엇을 위한 것이고 무엇이 사용자를 만족시키는지 밝히는 목표(goal), 어떻게 실행되고 무엇을 산출해야 하는지 고정하는 인터페이스 계약(interface contract), 무엇을 수정·설치·호출해도 되는지 경계 짓는 제약(constraints), 데이터·저장소·모델 접근 같은 자원(resources). 고객이 실제로 건넬 수 있는 것만 빌더(에이전트를 만드는 코딩 에이전트)에게 보여준다는 원칙이다.
핵심 장치는 '개발 케이스'와 '보류 케이스(held-out, 빌더에게 감춰 둔 평가용 사례)'의 분리다. 빌더는 공개된 소수의 개발 케이스를 자유롭게 찔러보며 작업한다. 하지만 납품물이 실제로 맞이할 케이스는 적혀 있지 않다. 평가는 이 보류 케이스로 얼어붙은(frozen) 납품물을 따로 돌려본다. 개발 중에는 2개의 예시만 봤는데, 합격 심사는 요구사항 전체를 가로지르는 별도 케이스로 친다는 뜻이다.
채점에는 정답 구현이 없으므로, 생성·편집 과제의 모든 실행은 요구사항에서 직접 끌어낸 루브릭(rubric, 채점 기준표)으로 매긴다. 그 앞에 하드 게이트(hard gate, 통과 못 하면 내용을 보기도 전에 0점인 최소 관문)가 걸린다. 에이전트가 실행조차 안 되거나, 산출물이 파싱되지 않거나, 허가된 수정 범위를 벗어났으면 0점이다. 보기 좋은 코드라도 작동하지 않으면 점수가 없다. 최적화 과제는 원본 벤치마크의 목표 지표로 잰다.
이 구조 덕분에 두 가지가 하나의 숫자로 분리된다. 빌더가 개발 중 보여준 성능(demonstrated fidelity)과 실제 납품물이 내는 성능(delivered fidelity)이다. 논문은 둘 사이 간극이 위임의 신뢰를 좀먹는 핵심 변수라고 본다.
본문에서 꼭 쥐고 갈 뼈대는 세 가지다.
첫째, 과제는 세 종류다. 생성(10개)은 빈 작업공간에서 완전한 에이전트를 새로 납품하게 한다. 편집(10개)은 돌아가고 있는 제품 에이전트의 고정된 코드에 새 기능을 얹되 기존 기능은 깨뜨리지 않게 한다. 최적화(5개)는 작동 중인 에이전트를 측정 가능한 목표에 밀어붙인다.
둘째, 개발 케이스와 평가 케이스를 물리적으로 나눈다. 생성·편집은 과제마다 개발 2개·보류 6개를 두고(전체로는 개발 150개, 보류 365개), 빌더는 Harbor라는 컨테이너 틀 위 한 세션에서 작업하며 스냅샷을 제출한다. 제출물은 개발 케이스로만 채점돼 요약 피드백이 돌아오고, 예산이 다 되면 결과물을 얼린다. 평가는 이 얼린 결과물을 보류 케이스로 따로 돌린다.
셋째, 비교 대상의 밑바탕 모델을 통일한다. 보류 케이스를 돌릴 때 납품 에이전트의 모든 모델 호출은 벤치마크가 소유한 게이트웨이를 거쳐 하나의 런타임 모델로 간다. 같은 과제군의 모든 납품물이 같은 모델을 공유한다. 그래야 점수가 밑바탕 모델의 성능 차가 아니라 빌더의 기여분 — 프롬프트, 도구 운용, 상태 관리, 출력 검증 — 을 반영한다.
점수를 읽기 전에 척도부터. 생성·편집의 점수는 "요구가 묘사한 행동을 실제로 얼마나 해냈는가"를 재는 충실성 점수다. 높을수록 좋고, 하드 게이트에 걸리면 0점이다. 코드의 우아함이나 유지보수성은 재지 않는다 — 심판은 코드가 아니라 "한 구체적 케이스에서 에이전트가 실제로 내놓은 산출물"을 본다(생성은 GPT-5.6 Sol, 편집은 DeepSeek-V4.1-Flash를 심판으로 썼다). 최적화는 절대 점수가 아니라 목표까지 남은 간극을 얼마나 좁혔는지로 잰다. 빌더로는 Codex 하네스(모델을 감싸 도구를 쓰고 여러 단계를 밟게 하는 실행 틀)에 다섯 모델 — GPT-5.6 Sol, GPT-5.5, DeepSeek-V4-Pro, DeepSeek-V4-Flash, Qwen3.6-35B-A3B — 을 짝지었다.
아래는 모두 Codex 하네스 기준이다.
| 과제 | 핵심 수치 | 읽는 법 |
|---|---|---|
| 생성(10) | 50회 실행(10과제×5빌더) 평균 11.2, 중앙값 3.4, 그중 20회 0점. 최고 빌더 DeepSeek-V4-Pro도 평균 19.1에 10과제 중 8개가 20점 미만. 50점 넘긴 실행은 단 3개(전부 형식 정리 증명·저장소 버그 수정). | 어떤 빌더도 두 과제 이상에서 30점을 넘지 못했다 — 한 수주의 성공이 다음으로 이어지지 않는다. |
| 편집(10) | 납품에 성공한 빌더(DeepSeek-V4-Pro·GPT-5.5·GPT-5.6 Sol)도 요구 기능의 일부만 구현. 평균 20~35점, 70점 도달은 단 한 번(GPT-5.5의 Codex 과제). Qwen3.6은 어떤 과제도 제출 못 함. DeepSeek-V4-Flash는 네 과제만 납품. | 돌아가는 제품에 기능을 더하는 일은 두 갈래로 실패한다. 패치가 요구의 일부만 덮거나, 아예 하나도 못 끝내거나. |
| 최적화(5) | 어떤 빌더도 평균적으로 남은 간극의 5%를 넘겨 좁히지 못함. 25회 중 13회가 출발점보다 높고 9회 낮고 3회 같음. 부호 검정에서 유의한 차이는 5회뿐(유의한 개선 3회는 전부 BrowseComp, 유의한 손실 2회는 τ³와 PinchBench에서 각각 한 번씩 발생). | 이득이 과제를 탄다. BrowseComp에선 다섯 중 넷이 출발점을 넘겼지만 PinchBench에선 다섯 중 넷이 오히려 낮아졌다. |
이 숫자들 뒤에는 세 가지 실패 양상이 있다. 관찰된 현상과, 그에 대한 추정 원인을 갈라서 보자.
조건을 바꾼 추가 실험(ablation)들도 있다. 개발 케이스 수를 늘리는 실험은 PDF·PPTX 두 과제에서 특정 빌더로 조건별 3회씩 돌린 것으로, 여기서는 점수가 0개→2개 구간에서만 오르고 그 이상에서는 더 오르지 않았다 — 다만 두 과제에 한정된 관찰이라, 사례 수를 늘려도 효과가 없다는 일반 결론으로 읽어선 안 된다. 그 밖에 설계를 미리 지정하면 PPTX 과제 점수가 오히려 낮아지고, 테스트하라고 지시하면 점수의 분산만 좁아졌으며, 케이스 예산을 2.5배로 늘려도 간극은 남았다.
저자가 직접 인정한 한계가 있다. 빌드가 확률적이라 단일 실행으로 결론 내리기 어렵다는 반복(repetition) 문제, 그리고 생성·편집의 심판으로 프런티어 모델을 써 심판 모델의 편향이 점수에 섞일 수 있다는 점이다.
더 짚어 둘 것은 커버리지다. 25개 과제, 그것도 특정 오픈소스 에이전트에서 역설계한 과제들이라 넓다고 보긴 어렵다. 또 밑바탕 모델을 과제군 내에서 통일한 설계는 빌더의 기여분을 깨끗이 분리해 주지만, 실제 제품에서는 빌더가 고른 모델 자체도 납품 품질의 일부다. 이 통일은 "빌더의 순수 기여"를 재려는 벤치마크 안에서는 옳은 선택이지만, 현실의 제품 판단과는 한 겹 떨어져 있다는 조건을 달고 읽어야 한다.
온틀은 소기업·1인 사업자의 반복 업무를 대신 처리하는 작은 에이전트를 조립해 납품하는 쪽이다. 즉 AgentSWE가 시험대에 올린 '빌더'의 자리에 선다.
작은 쇼핑몰 사장님이 "고객 문의를 환불·교환·배송지연으로 분류해 담당자에게 넘기는 걸 대신 처리해줘"라고 맡긴 장면을 떠올려 보자. 온틀이 에이전트를 조립하고, 사장님이 준 예시 문의 두세 건으로 돌려본다. 세 건 모두 정확히 분류된다. 데모는 흠잡을 데 없다. 이 논문이 경고하는 건 그 다음이다. 실전에 들어가면 "환불인데 배송지연도 섞인 문의", "반말에 오타투성이 문의", "주문번호를 안 적은 문의"가 쏟아진다. 개발 때 본 두세 건에만 맞춰진 에이전트는 여기서 무너진다. 분류는 됐다고 보고하는데 담당자에게는 한 번도 안 넘어가는 '속 빈 런타임'까지 겹치면, 사장님은 아무 일도 안 일어난 걸 "완료"로 받는다.
그래서 고객이 확인해야 할 질문은 하나로 모인다 — "분류 결과가 화면에 떴는가"가 아니라 "담당자에게 실제로 전달됐는가". 온틀의 운영 원칙은 이미 "작동 신호만으로 완료 처리하지 않고 실제 행동으로 검증한다"는 쪽이다. AgentSWE를 계기로 여기에 한 단계를 더 제안한다. 사장님이 보지 못한 보류 케이스 묶음으로 얼린 에이전트를 따로 돌려보고, 그 합격 전까지는 "완료"로 인수인계하지 않는 절차다. "보여준 성능"과 "실제 성능"의 간극을 숫자로 드러내는, 인수의 마지막 관문인 셈이다.
에이전트를 만들어 쓰는 쪽이라면 세 가지만 실행에 옮기면 된다.