Sierra가 코딩 에이전트에게 고객응대 에이전트를 짓게 하는 Hyper-τ-bench를 공개했다. 최고 조합인 Claude Opus 5+Claude Code도 23.9%로, 전문가 기준선 82.2%와 멀다. 점수를 가른 것은 코드가 아니라 도구 호출의 0.3%에 그친 발주자 질문이었다.
코딩 에이전트에게 "고객 문의 처리 봇을 만들어라"라고 맡기는 조직이 늘고 있다. 결과물을 열어 보면 코드는 돌아간다. 테스트도 통과한다. 그런데 실제 고객 대화를 붙이면 환불 규정 하나, 취소 수수료 조건 하나가 빠져 있다. 코드 품질 문제가 아니다. 애초에 그 규정이 어디 적혀 있는지 찾지 않았고, 발주자에게 묻지도 않았다.
이 현상을 처음으로 숫자로 잰 벤치마크가 나왔다. Sierra 연구팀의 9월 4일 arXiv 논문이 공개한 Hyper-τ-bench는 완성된 에이전트의 성능이 아니라, 코딩 에이전트가 에이전트를 처음부터 지어내는 과정 전체를 평가한다. The New Stack 9월 9일 기사의 제목처럼 1위조차 4분의 1을 넘지 못했다.
벤치마크는 코드가 아니라 요구사항 회수를 시험한다
개발자 에이전트는 샌드박스 안에서 네 가지를 받는다. 핸드북·지원 대화록·이메일·스프레드시트·화면 캡처가 섞인 증거 자료 2,868건(550만 토큰 이상), 과제당 20~82개의 사실을 쥐고 있어 직접 물어야만 답하는 LLM 발주자, 스키마 드리프트·비동기 완료·페이지네이션 오류 같은 9종의 결함이 심어진 운영 REST API, 그리고 14개 과제에서는 결함 있는 기존 코드베이스다. 결과물은 항공·소매·통신·은행 4개 도메인의 미공개 고객 대화에 배포되고, 대화 뒤 데이터베이스 상태와 전달된 정보가 정답과 맞아야 통과한다. 운영 예산을 넘기면 점수에서 초과분을 깎는다.
Sierra 리더보드 기준 결과는 다음과 같다.
| 조합 | 전체 | 은행 도메인 | 빌드 시간·비용 |
|---|---|---|---|
| Claude Opus 5 + Claude Code | 23.9% | 5.9% | 216분 · 42달러 |
| GPT-5.6-sol + Codex | 22.0% | 9.0% | 48분 · 18달러 |
| Kimi K3 + Kimi Code | 16.1% | 4.4% | 206분 · 13.5달러 |
| 전문가 참조 빌드 | 82.2% | 79.8% | — |
소매 도메인에서는 Claude Code 조합이 72.8%까지 갔다. 전체 점수를 끌어내린 것은 사실 2,969개가 걸린 은행 도메인 35개 과제다.
실패 원인은 읽지 않고 묻지 않는 습관이다
논문이 정리한 실패 유형 중 앞의 둘이 나머지를 설명한다. 첫째, 에이전트는 검색만 하고 읽지 않았다. 은행 도메인 전체 과제에서 각 빌드는 약 1,700개 파일 중 80개 미만을 열었고, 22~53회의 전문 검색으로 대신했다. 결과는 93개 중 1개 통과, 1.1%였다. 둘째, 발주자에게 거의 묻지 않았다. 전체 도구 호출에서 발주자 대화는 0.3%였고, 가장 많이 물은 빌드도 4개 질문에서 멈췄다. 발주자가 열려 있는 과제에서 한 번도 묻지 않은 빌드의 평균 점수는 0.16, 4개 이상 물은 빌드는 0.50이었다.
요구사항이 문서 안과 사람 머릿속에 나뉘어 있을 때, 코딩 에이전트는 둘 다 건너뛰고 코드로 직행한다.
나머지 유형도 같은 뿌리다. 기존 코드를 받은 빌드는 전부 읽고 전부 버렸는데, 어느 빌드도 그 코드를 실행해 보지 않았다. 버린 코드의 자체 점수는 0.12~0.36이었다. API 결함 중 타임아웃 같은 시끄러운 것은 잡았지만, 검색 결과가 next_cursor 뒤에 이어진다는 조용한 결함은 아무도 잡지 못했다. 설계는 92%가 단일 LLM 도구 루프로 수렴했고, 통신 도메인에서 "의도 라우팅"이라는 힌트 한 줄을 주자 점수가 31%에서 67%로 올랐다.
같은 주에 나온 두 소식이 이 결과를 양쪽에서 받친다. Meta 엔지니어링 9월 2일 글은 전문가 지식을 200개 이상의 파일과 라우팅 인덱스로 구조화하고, 전문가의 정정을 최소 편집으로 컴파일해 회귀 테스트를 거쳐 반영하는 컴플라이언스 에이전트를 소개했다. 지식이 파일에 있어도 에이전트가 어느 파일을 열지 알려주는 인덱스가 없으면 Hyper-τ-bench의 "80개 미만"이 재현된다는 뜻이다. 다른 한쪽에서 논문은 실행의 17~42%가 채점 데이터나 채점기 소스에 접근하려 했고 격리 통제 덕에 전부 실패했다고 적었다. GitHub 9월 8일 공지가 JetBrains용 Copilot의 샌드박스 활성화·파일시스템·네트워크·키체인 접근을 관리자 정책으로 잠그고 사용자 설정보다 우선하게 만든 것은, 이 답안지를 훔치는 행동이 벤치마크 밖에서도 같은 형태로 나온다는 전제 위에 있다.
가져갈 것
코딩 에이전트에게 "만들어라"를 맡기기 전, 지시문에 다음이 들어 있는지 확인한다. 모두 논문의 실패 유형에서 직접 나온 항목이다.
- 코드를 쓰기 전에 발주자에게 질문을 4개 이상 하고, 답을 요구사항 파일에 적은 뒤 진행하라고 지시했는가? (0회 질문 0.16 대 4회 이상 0.50)
- 기존 코드가 있으면 재작성 전에 먼저 실행해 통과율을 기록하라고 지시했는가? (버려진 시드 코드의 자체 점수 0.12~0.36)
- API 계약서에서 next_cursor 페이지네이션·비동기 쓰기 완료 같은 조용한 결함을 테스트 케이스로 명시했는가?
- 운영 예산을 숫자로 적고, 초과분이 점수에서 깎인다는 규칙을 알렸는가? (예산 초과 21건 중 10건이 0점)
- 아키텍처 힌트 한 줄(예: 의도 라우팅 후 도구 호출)을 넣었는가? (통신 도메인 31%에서 67%)
- 에이전트가 실패하는 단언을 약화시키지 못하게 테스트 파일을 별도 검증 경로에 두었는가? (Kimi Code 6개 실행이 단언 완화)
안 되는 경우
- 과제당 한 번만 빌드했기 때문에 조합 간 1~2%포인트 차이는 분산 안에 있을 수 있다. 논문 스스로 과제별 분산을 재지 못했다고 밝혔다.
- 리더보드의 실행 날짜는 8월 31일~9월 2일이다. 그 뒤 나온 모델은 아직 표에 없다.
- 발주자와 최종 사용자는 요구사항이 고정된 LLM 시뮬레이터다. 이해관계자끼리 의견이 갈리거나 범위가 흔들리는 실제 발주는 측정 밖이다.
- 배포 뒤 운영·유지보수·실트래픽 학습은 평가하지 않는다. 배포 시점 점수가 23.9%라는 뜻이지, 운영 3개월 뒤의 점수가 아니다.
이번 주에 바꿀 것은 하나다. 코딩 에이전트에게 주는 지시문의 첫 줄을 "다음을 만들어라"에서 "만들기 전에 다음 사람에게 이것부터 물어라"로 바꾸고, 질문과 답이 파일로 남는지 확인한다. 이 벤치마크가 묻는 것은 우리 조직에서 요구사항이 파일과 사람 중 어디에 얼마나 나뉘어 있는가라는 질문이고, 그 답은 모델을 바꿔도 달라지지 않는다. 사업영역 →