완성품 35%는 실패였다: Replit ViBench 2.0 벤치마크 리뷰

원문 정보

Daniel Furman, Preeya Kirani, Ibrahim Sheikh, Zhen Li, Peter Zhong, Michele Catasta, "ViBench 2.0: A Benchmark for Long-Horizon Software Building", arXiv:2611.05620 [cs.AI], 2026-11-03 제출. 소속: Replit(전원). 동료심사 학회·저널 게재 정보 없음(arXiv 프리프린트). 코드·데이터: github.com/ViBench/vibench-public.

동료심사를 거치지 않은 프리프린트이며 저자 6명 전원이 Replit 소속입니다. ViBench 2.0은 Replit이 자사 에이전트 플랫폼에 어떤 모델을 쓸지 고르는 데 직접 사용하는 내부 평가 도구이고, 추론 서비스 업체 Fireworks AI가 이 벤치마크를 자사 유료 상품인 'Specialized Intelligence Index'에 포함시켰다는 사실도 원문에 명시돼 있습니다. 벤치마크 제작자가 그 결과로 자사 제품의 모델 선택을 결정하고, 제3의 상용 서비스도 그 결과를 판매에 쓰는 구조입니다. 다만 일부 모델 제공사와 협력 관계임을 저자들이 스스로 밝히고, 심사 모델의 자사 편향 여부를 별도 검증했다는 점은 '신뢰도 평가'에서 다룹니다.

연구 개요

연구 질문은 "AI 코딩 에이전트가 빈 프로젝트에서 시작해(그린필드) 제품 하나를 수십 개 기능 요청에 걸쳐 끝까지 완성할 수 있는가"입니다. 기존 코딩 벤치마크는 이미 존재하는 코드베이스에서 이슈 하나를 고치는 단일 과제를 채점하거나(SWE-bench 계열), 여러 턴이라도 각 단계를 개별로 채점합니다. ViBench 2.0은 전자상거래·협업툴 등 17개 제품(공개 8개: Amazon·Asana·Discord·Figma·GitHub·Google Docs·Jira·Uber를 본뜬 제품, 비공개 9개)을 빈 프로젝트에서부터 쌓게 하고, 제품당 9~18개 기능 요청(전체 241개)을 한 대화 안에서 순서대로 줍니다. 평가는 마지막 요청이 끝난 뒤 완성된 제품 전체를 대상으로 하며, 브라우저를 직접 조작하는 채점 에이전트가 544개 테스트플랜(85%가 여러 기능을 동시에 확인)을 실행해 하나라도 실패하면 그 빌드는 실패로 처리됩니다. 모든 빌더에 대해 채점·시딩 에이전트는 공통으로 Opus 5.5를 중간(medium) 추론 노력으로 사용해 조건을 통일했습니다.

핵심 결과

아래 수치는 모두 원문 표에서 직접 대조한 값입니다. '완성품 통과율(pass@1)'은 제품 하나가 끝까지 전부 통과해야 집계되는 전부-아니면-무(all-or-nothing) 지표이고, '테스트플랜 통과율'은 개별 플랜 단위 통과 비율입니다 — 기준이 다른 두 지표이므로 표와 차트에서 구분해 표기합니다.

원문 Table 1(±는 95% 신뢰구간, 근사치 0% 구간은 이항분포 정확구간). 17개 제품을 각 4회씩 빌드한 68회 독립 실행 기준입니다. 상위 3개 모델(Sol·Astra·Opus)은 테스트플랜의 93.7~98.0%를 맞히지만 완성품 통과율은 48.5~64.7%에 그칩니다 — 실패한 빌드 84건 중 42건은 플랜 1개만, 62건은 최대 2개만 틀렸을 정도로 거의 다 맞혔는데도 전체는 실패 처리됩니다. 오픈소스 3개 모델(DeepSeek·GLM·Kimi)은 테스트플랜 통과율이 최대 77.4%(DeepSeek)에 달해도 204회 빌드 전부 완성품 통과에 실패했습니다.

원문 Table 2(공개 8개 제품만, 모델당 4회 빌드). "Sol" 계열 3개 버전만 추려 보면 완성품 통과율이 3.1%→31.2%→53.1%로 뛰는 동안 빌드당 비용은 $26.5→$19.4→$11.8로 오히려 줄었습니다. 저자들은 테스트플랜 통과율이 약 70%를 넘어서야 완성품 통과율이 비로소 오르기 시작한다고 설명하는데, 표의 두 Luna 버전(통과율 6.6%·59.8%, pass@1 모두 0%)과 Sol·Terra 계열(통과율 84~94.9%, pass@1 31.2~53.1%)의 대비가 이 설명과 어긋나지 않습니다.

신뢰도 평가

믿을 근거는 세 갈래입니다. ① 채점 신뢰성을 자체 검증했습니다 — 버그 34개(24개는 1센트 단위 오차처럼 미묘한 종류)를 몰래 심어 채점시킨 결과 96개 채점 전부에서 통과 처리된 사례가 없었고(0/96), 정상 빌드를 잘못 탈락시킨 비율은 0.20%(3/1,521), 반대로 잘못 통과시킨 비율은 0.8%(4/477, 사람이 재검토해 확정)였습니다. ② 공개 8개 제품과 비공개 9개 제품 사이의 순위 상관(스피어만 ρ=0.99)과 테스트플랜 통과율 상관(ρ=0.97)이 모두 높아, 공개 제품이 비공개 제품을 대신할 '더 어려운' 대리 지표로 기능한다는 근거를 제시했습니다. ③ Fireworks AI의 외부 팀이 공개된 벤치마크를 받아 "명령 하나"로 9개 모델 전체를 독립 재현했다는 점은, 저자 자신의 재현이 아니라 제3자 재현이라는 점에서 신뢰도를 높입니다.

감안할 점도 분명합니다. 동료심사 전 프리프린트이고, 저자 전원이 Replit 소속이며 이 벤치마크로 자사 모델 선택을 결정하고 Fireworks의 상용 지표에도 쓰입니다. 채점·시딩에 쓴 Opus 5.5는 동시에 평가 대상 9개 모델 중 하나이기도 합니다 — 저자들은 Claude 계열 빌드에서 잘못된 통과가 237건 중 4건, GPT 계열에서는 240건 중 0건으로 "우연 범위 안"이라고 자체 검증했지만, 심사자와 피심사자가 분리되지 않은 설계 자체는 구조적 한계로 남습니다. 공개 제품 8개는 훈련 데이터에 섞여 들어갈 수 있어 캐너리 문자열로 필터링을 시도했지만 완전한 차단은 보장되지 않고, 비공개 제품 9개는 외부 팀과의 비밀유지계약(NDA)으로만 보호됩니다. 평가 범위도 PostgreSQL을 쓰는 영어 기반 풀스택 웹 제품으로 한정되고, 모든 빌더가 OpenHands SDK 기반의 단일 하니스에서 실행돼 Replit 자체 프로덕션 에이전트의 실제 성능과는 다를 수 있다고 원문이 명시합니다.

관련 연구

• Jimenez et al.(2024, ICLR). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? — 선행 연구(prior). 이미 존재하는 12개 Python 저장소의 GitHub 이슈 2,294건을 단발로 고치는 과제이며, 공개 당시 최고 모델(Claude 2)의 해결률은 1.96%였습니다. ViBench 2.0은 "이미 있는 코드를 고친다"에서 "빈 프로젝트에서 제품 전체를 끝까지 완성한다"로 평가 축을 옮겼습니다.
• Yao et al.(2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — 벤치마크 원전(benchmark-origin). 소매·항공 도메인에서 도구를 쓰는 에이전트의 신뢰성을 pass^k(같은 과제를 k회 반복했을 때 전부 성공할 확률)로 측정한 벤치마크로, 당시 GPT-4o는 단일 성공률 약 35~61%에서 반복 8회(pass^8) 기준 25% 아래로 떨어졌습니다. ViBench 2.0은 이 논문을 직접 인용해 "성능의 여지는 신뢰성에 있다"는 같은 통찰을, 반복 시행 대신 "완성품 전체가 전부 통과해야 한다"는 단일 빌드 내 all-or-nothing 채점으로 재구성합니다.
• Zhong et al.(2026, CAIS). ViBench: A Benchmark on Vibe Coding — 직접 선행 연구(prior, 원 벤치마크). MVP 구축이나 기능 1개 추가라는 단발 과제로 공개 당시 최고 모델 pass@1은 51%였습니다. 이번 논문의 저자들이 같은 하니스로 그 "자기 MVP 확장(Vibe-on-Vibe)" 과제를 재현한 결과, 2026년 11월 기준 모델(Sol·Astra·Opus)은 82~89% pass@1을 기록해(원문 Appendix H) 모델 세대가 바뀌며 같은 단발 과제에서는 30%포인트 이상 올랐습니다. ViBench 2.0은 이 원 벤치마크의 그레이더를 그대로 확장해, 단발 과제가 아니라 9~18회 누적 요청으로 지평을 늘렸습니다.

세 선행 연구를 종합하면, 코딩 에이전트 벤치마크는 '기존 코드베이스의 단발 수정(SWE-bench)' → '도구 사용의 반복 신뢰성(τ-bench)' → '그린필드 단발 제품 구축(ViBench 1.0)'으로 확장돼 왔습니다. ViBench 2.0은 이 흐름의 마지막 조각인 "장기 호라이즌 그린필드 구축"을 더해, 테스트는 거의 다 맞혀도 전체는 실패한다는 신뢰성 격차가 과제가 길어져도 반복된다는 것을 보였습니다 — 선행 연구들과 결론이 충돌하지는 않고, 오히려 같은 패턴이 과제 규모가 커져도 사라지지 않음을 추가로 보여줍니다.

리뷰어 판단

첫째, 단일 지표보다 두 지표의 격차 자체가 핵심 발견이라고 판단합니다. 상위 3개 모델의 테스트플랜 통과율(93.7~98.0%)과 완성품 통과율(48.5~64.7%) 사이의 30~45%포인트 격차는, 벤더가 흔히 공개하는 "기능 구현률 OO%" 같은 부분 지표가 실무자가 실제로 원하는 "완성된 제품이 통째로 동작하는가"라는 질문과는 다른 답을 준다는 뜻입니다. 부분 지표만 보고 배포를 결정하면 체감 실패율을 과소평가하기 쉽습니다.

둘째, 빌드당 비용이 모델 세대를 거치며 줄어드는 동시에 완성품 통과율이 오르는 추세(Table 2)는 낙관적이지만, 이 추세를 GPT 한 계열에서만 확인했다는 점에 주의해야 한다고 판단합니다. 오픈소스 3개 모델은 테스트플랜을 56~77% 통과하면서도 완성품 통과율이 0%였는데, 이는 저자들이 말하는 "테스트플랜 통과율 70%" 임계점에 아직 못 미쳤다는 뜻으로 해석됩니다 — 오픈소스 모델이 이 임계점을 넘는 시점이 신뢰성 격차 해소의 다음 분기점이 될 것으로 봅니다.

셋째, 심사 모델(Opus 5.5)이 동시에 평가 대상이었다는 구조는 Appendix D의 동일 계열 편향 검사(0/240 vs 4/237)로 어느 정도 상쇄됐지만, 심사와 피심사를 애초에 분리하지 않은 설계는 다음 버전에서 제3의 독립 모델로 교체해 재검증할 가치가 있다고 판단합니다. 표본 수(237·240건)가 편향을 확정하기엔 작다는 점도 함께 감안해야 합니다.

실무 적용

• 두 지표를 함께 추적 — 기능 구현률(테스트플랜 통과율)만이 아니라 완성품 전체 통과율을 모델 교체·배포 결정 지표에 같이 넣습니다. 70%를 넘겨야 완성품 통과율이 움직이기 시작한다는 관찰을 교체 기준의 참고선으로 씁니다.
• 신뢰구간 넓은 결과는 반복 측정 — 95% 구간이 ±9~11%포인트로 넓어 Sol과 Astra처럼 구간이 겹치는 모델은 4회보다 더 많은 반복 빌드로 재현해야 순위를 확정할 수 있습니다.
• 컨텍스트 핸드오프 지점 사전 점검 — 200k 토큰을 넘으면 자동 요약이 끼어든다는 설계를 참고해, 장기 대화형 에이전트에서 요약 전후 정보 손실을 별도로 테스트합니다.
• 독립 재현 가능한 하니스를 우선 채택 — Fireworks처럼 "명령 하나"로 외부가 재현할 수 있는 벤치마크·하니스를 우선해, 벤더 발표 수치를 자체 검증할 수 있게 합니다.
• 심사 모델과 평가 대상의 계열 분리 — 자사 평가에 쓰는 심사 모델이 평가 대상 모델과 같은 계열이면 교차 심사로 한 번 더 검증합니다.

결론

ViBench 2.0은 "기능은 거의 다 구현했는데 제품 전체는 안 된다"는 현상을 17개 제품·544개 테스트플랜 규모에서 수치로 보였습니다. 상위 3개 모델은 테스트플랜의 93.7~98.0%를 맞히면서도 완성품 통과율은 48.5~64.7%에 머물렀고, 오픈소스 3개 모델은 테스트플랜 통과율이 최대 77.4%에 달해도 완성품은 204회 빌드 전부 실패했습니다. 동시에 GPT 계열의 최근 3개 버전만 보면 완성품 통과율이 3.1%→31.2%→53.1%로 뛰면서도 빌드당 비용은 오히려 줄어, 격차가 빠르게 좁혀지고 있다는 낙관적 신호도 함께 제시합니다.

다만 저자 전원이 Replit 소속으로 자사 모델 선택과 Fireworks의 상용 지표에 이 벤치마크를 직접 쓴다는 이해상충, 그리고 심사 모델이 평가 대상 중 하나이기도 했다는 구조는 수치를 받아들이는 폭을 좁혀야 할 이유입니다. "요구사항은 채워져도 완성품은 안 된다"는 이 신뢰성 격차는 머지 기준을 다룬 코딩 에이전트 완전통과율 게이트 설계 체크리스트와 같은 축에서 읽을 수 있습니다 — 그 글은 머지 게이트를 어떻게 설계할지를, 이 리뷰는 그 게이트를 통과하는 비율 자체가 왜 테스트 통과율보다 낮은지를 다룹니다.

참고 링크

• ViBench 2.0: A Benchmark for Long-Horizon Software Building — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용
• SWE-bench(Jimenez et al., 2024) — 관련 연구 원문
• τ-bench(Yao et al., 2024) — 관련 연구 원문
• ViBench 1.0(Zhong et al., 2026, CAIS) — 관련 연구 원문
• 요구사항은 채워져도 머지는 안 된다: 코딩 에이전트 완전통과율 게이트 설계 체크리스트 — sunny34.com 블로그