Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

이 논문은 기존 벤치마크의 한계를 극복하고 AI 모델이 처음부터 끝까지 웹 애플리케이션을 개발하는 능력을 평가하기 위해 자율 브라우저 에이전트를 활용한 'Vibe Code Bench'를 제안하고, 16 개의 최첨단 모델을 평가하여 완전한 엔드 - 투 - 엔드 개발이 여전히 해결해야 할 과제임을 입증했습니다.

핵심

🚀 "바운스 코드 벤치": AI 가 혼자서 웹사이트를 만들어낼 수 있을까?

이 논문은 **"AI 가 이제 코딩을 넘어서, 실제로 작동하는 웹사이트를 처음부터 끝까지 혼자서 만들 수 있을까?"**라는 아주 중요한 질문을 던집니다.

기존의 AI 평가 방식은 "이 함수를 짜줘"나 "이 버그를 고쳐줘"처럼 작은 조각만 테스트했습니다. 하지만 이번 연구는 **"아이디어만 말하면, AI 가 혼자서 완전한 앱을 만들어서 인터넷에 올리는 것"**을 평가합니다.

이 논문의 핵심 내용을 일상적인 비유로 쉽게 설명해 드릴게요.

---

1. 새로운 시험지: "바운스 코드 벤치 (Vibe Code Bench)" 📝

기존의 시험지는 "수학 문제 100 개를 푸는 것"이었습니다. 하지만 이 연구팀은 **"한 편의 영화를 처음부터 끝까지 직접 찍어오는 것"**을 시험 문제로 냈습니다.

• 시험 문제: "나에게 친구를 사귈 수 있는 SNS 앱 만들어줘"라고 AI 에게 말합니다.
• 시험 내용: AI 는 혼자서 코드를 짜고, 서버를 세우고, 결제 시스템을 연결하고, 이메일을 보낼 수 있게 설정해야 합니다.
• 채점 방식: AI 가 만든 앱을 스스로 브라우저에서 열어보고 "회원가입이 되나?", "게시글이 올라가나?", "결제 버튼이 작동하나?"를 직접 클릭하며 확인합니다. 마치 사람이 앱을 써보듯 말이죠.

총 100 개의 미션이 있었고, AI 가 만든 앱이 실제로 작동하는지 964 개의 구체적인 행동 (로그인, 글쓰기, 결제 등) 으로 테스트했습니다.

2. 시험 결과: 아직 완벽하지는 않아요 📉

최고의 AI 모델 16 개를 시험에 붙였는데, 결과는 어떨까요?

• 1 등 (GPT-5.3-Codex): 100 점 만점에 약 62 점을 받았습니다.
• 하위 모델: 10 점도 못 받는 경우도 많았습니다.

결론: AI 가 코드를 짜는 건 잘하지만, 혼자서 완벽하게 작동하는 앱을 만드는 건 아직 어렵습니다. 마치 "레고 조각을 잘 쌓는 장난감"은 있지만, "혼자서 성을 짓고 문도 열고 전기도 연결하는 건축가"는 아직 초보 단계라는 뜻입니다.

3. 성공의 비결: "스스로 점검하는 습관" 🧐

가장 흥미로운 발견은 성공한 AI 와 실패한 AI 의 행동 차이였습니다.

• 성공한 AI: 코드를 짜다가 **"잠깐, 이거 작동해 보자"**라고 생각하며 브라우저에서 직접 테스트를 반복했습니다. (자신이 쓴 코드를 스스로 점검함)
• 실패한 AI: 코드를 끝까지 짜기만 하고, 마지막에 "완료!"라고만 했습니다.

비유: 요리사 A 는 요리를 다 만들고 맛을 보며 "소금이 부족하네"라고 다시 간을 맞춥니다. 요리사 B 는 요리를 다 만들고 맛도 보지 않고 바로 손님에게 줍니다. 성공한 AI 는 요리사 A 처럼 스스로 맛을 보는 (테스트하는) 습관이 있었습니다.

4. 채점관의 중요성: 누가 채점하느냐에 따라 점수가 달라져요 ⚖️

AI 가 만든 앱을 채점할 때, 누가 채점하느냐가 매우 중요하다는 사실도 발견했습니다.

• 어떤 AI 채점관은 "이건 완벽해!"라고 점수를 주지만, 다른 AI 채점관은 "여기 문제가 있어"라고 점수를 깎습니다.
• 심지어 사람이 직접 채점했을 때와 AI 가 채점했을 때의 의견이 완전히 다를 수도 있습니다.

비유: 같은 그림을 두고 미술 평론가 A 는 "명작"이라고 하고, 평론가 B 는 "그림이 삐뚤어져 있어"라고 할 수 있습니다. 따라서 누가 채점하느냐를 명확히 해야 AI 의 실력을 정확히 알 수 있습니다.

5. 왜 이 연구가 중요할까요? 🌟

이 연구는 AI 의 미래를 보여줍니다.

• 과거: "AI 는 코딩 도우미"였습니다. (사람이 시키면 조금만 도와줌)
• 미래: "AI 는 소프트웨어 개발자"가 될 수 있습니다. (사람이 "이런 앱 만들어줘"라고 말만 하면, AI 가 혼자서 다 만들어줌)

이제 우리는 **"AI 가 코드를 짜는 속도"**가 아니라, **"AI 가 실제로 쓸모 있는 제품을 만들어내는 능력"**을 평가해야 할 때입니다. 이 벤치마크는 그 기준을 제시한 첫걸음입니다.

---

📝 한 줄 요약

"AI 가 혼자서 웹사이트를 만들어내는 능력을 시험한 결과, 최고의 AI 가 60% 정도만 성공했고, 성공한 AI 는 스스로 테스트를 반복하는 습관이 있었다는 것을 발견했다."

이 연구는 AI 가 이제 '도구'를 넘어 '파트너'가 되기 위해 넘어야 할 마지막 산을 보여주고 있습니다.

기술 요약

1. 문제 정의 (Problem)

• 기존 벤치마크의 한계: 현재 존재하는 대부분의 코드 생성 벤치마크 (HumanEval, SWE-Bench 등) 는 함수 단위 생성, 기존 코드베이스의 버그 수정, 또는 제한된 작업 (Scoped tasks) 에 초점을 맞추고 있습니다.
• 실제 필요성: 생성형 AI 의 가장 큰 잠재력은 비기술적 사용자가 자연어 의도만으로 완전한 애플리케이션을 처음부터 끝까지 (Zero-to-One) 구축할 수 있게 하는 것입니다. 이는 단일 파일 수정이 아닌, 다중 파일 코드, 설정, 배포, 그리고 사용자 워크플로우를 포함하는 복잡한 과정을 요구합니다.
• 평가의 부재: 자연어 명세로부터 배포 가능한 웹 애플리케이션을 생성하는 능력을 체계적으로 측정하는 널리 사용되는 벤치마크가 존재하지 않았습니다.

2. 방법론 (Methodology)

2.1 벤치마크 데이터셋 구성

• 작업 규모: 총 100 개의 웹 애플리케이션 명세 (50 개 공개 검증 세트, 50 개 홀드아웃 테스트 세트) 로 구성됩니다.
• 도메인 분류:
  • 개인용 (Individual): 비인증 또는 단순 인증이 필요한 개인용 앱 (24 개).
  • 솔로 창업자 (Solo Founder): 간단한 비즈니스용 앱 (45 개).
  • 기업용 도구 (Enterprise Tool): 역할 계층 구조가 포함된 복잡한 내부 도구 (31 개).
• 평가 워크플로우: 각 명세는 6~23 개의 자동화된 브라우저 워크플로우 (총 964 개 워크플로우, 10,131 개 하위 단계) 와 연결됩니다. 이 워크플로우는 실제 사용자가 브라우저에서 애플리케이션을 사용하는 시나리오를 시뮬레이션합니다.
• 제 3 자 통합: 28% 의 애플리케이션은 이메일 (MailHog) 및 결제 (Stripe) 와 같은 외부 서비스 통합을 포함하여 실제 배포 환경의 복잡성을 반영합니다.

2.2 생성 하니스 (Generation Harness)

• 환경: OpenHands 를 기반으로 수정된 컨테이너화된 환경에서 실행됩니다.
• 도구 접근성: 모델은 터미널, 브라우저 (문서 검색 및 자체 테스트용), Supabase (백엔드), MailHog, Stripe 에 접근할 수 있습니다.
• 제약 조건:
  • 시간 제한: 각 애플리케이션당 최대 5 시간의 벽시계 시간 (Wall-clock time) 을 부여합니다.
  • 기술 스택: 일관된 평가를 위해 React + Vite (프론트엔드), Tailwind CSS, Supabase (백엔드) 사용을 강제합니다.
  • 배포: Docker Compose 를 통해 애플리케이션을 빌드하고 실행할 수 있어야 합니다.

2.3 자동화된 평가 파이프라인

• 브라우저 에이전트 평가: 생성된 애플리케이션은 Browser Use라는 자율 웹 에이전트를 통해 평가됩니다.
• 평가 방식:
  • DOM 기반의 brittle 한 체크가 아닌, 사용자가 볼 수 있는 브라우저 상호작용을 기반으로 합니다.
  • 에이전트는 워크플로우의 각 하위 단계를 수행하고 성공/실패를 판단합니다.
  • 성공 기준: 하나의 워크플로우가 성공하려면 해당 워크플로우의 하위 단계 중 90% 이상이 성공해야 합니다.
  • 전체 애플리케이션의 정확도는 통과한 워크플로우의 비율로 계산됩니다.

3. 주요 기여 (Key Contributions)

1. 새로운 벤치마크 (VCB): 자연어 명세로부터 완전한 웹 애플리케이션을 생성하는 능력을 평가하는 최초의 벤치마크와 브라우저 기반 평가 파이프라인을 제시했습니다.
2. 포괄적인 모델 평가: 16 개의 최첨단 (Frontier) 모델을 평가하여 비용, 지연 시간, 오류 분석을 포함했습니다. 기존 벤치마크 (예: SWE-Bench) 보다 모델 간 성능 차이가 훨씬 뚜렷하게 나타났습니다.
3. 평가자 정렬 프로토콜 (Evaluator Alignment): 자동화된 평가자가 인간 평가자와 얼마나 일치하는지 분석했습니다. 평가자 선택이 결과에 큰 영향을 미친다는 것을 입증했습니다.
4. 재현성 아티팩트: 모든 데이터셋, 생성된 애플리케이션, 평가 스크립트 등을 공개하여 연구의 재현성을 보장합니다.

4. 실험 결과 (Results)

4.1 모델 성능

• 최고 성능: 16 개 모델 중 GPT-5.3-Codex가 테스트 세트에서 **61.8%**의 정확도를 기록하여 1 위를 차지했습니다.
• 성능 격차: 상위 모델 (Claude Opus 4.6, GPT-5.2 등) 과 하위 모델 간의 격차가 매우 큽니다. 예를 들어, SWE-Bench 에서는 2.8% 차이였던 모델들이 VCB 에서는 42.7% 의 격차를 보였습니다.
• 오픈 웨이트 모델: GLM-5, Qwen3.5 등 오픈 웨이트 모델들은 상위 폐쇄형 모델들에 비해 성능이 현저히 낮았습니다 (약 15~24% 대).

4.2 주요 발견 사항

• 자가 테스트 (Self-Testing) 의 중요성: 개발 과정에서 브라우저 도구를 사용하여 생성된 애플리케이션을 스스로 테스트하는 행동과 최종 성능 사이에 강한 상관관계 (Pearson r=0.72) 가 있었습니다. 단순히 코드를 많이 수정하는 것보다 스스로 검증하는 것이 성공에 더 중요합니다.
• 실패 패턴: 상위 모델들도 약 12.8% 의 애플리케이션에서 0 점 (완전 실패) 을 기록했습니다. 성능 향상은 점수를 조금씩 올리는 것이 아니라, 완전한 실패를 줄이는 것에서 주로 발생합니다.
• 오류 유형: 가장 흔한 실패 원인은 **Missing Feature (46.7%)**와 **Authorization Issue (20.4%)**였습니다.

4.3 평가자 정렬 (Human Alignment)

• 평가자 선택의 중요성: 평가자 (AI 모델) 에 따라 결과가 크게 달라질 수 있습니다.
  • Claude Sonnet 4.5 와 4.6 은 인간 평가자와 높은 일치도 (약 86% 이상) 를 보였습니다.
  • 반면, GPT-5.2 는 인간 평가자와의 일치도가 매우 낮아 (약 36%) 신뢰할 수 없는 평가자였습니다.
• 이는 자동화된 평가 시 적절한 평가자 모델을 선택하는 것이 결과의 신뢰성에 필수적임을 시사합니다.

5. 의의 및 결론 (Significance & Conclusion)

• 새로운 기준점: "AI 가 코드를 작성할 수 있는가"를 넘어, **"AI 가 소프트웨어를 구축할 수 있는가"**를 측정하는 새로운 기준을 제시했습니다.
• 현실적인 장벽: 현재 최상위 모델조차도 100% 신뢰할 수 있는 엔드투엔드 애플리케이션 개발에는 도달하지 못했습니다 (최고 61.8% 정확도). 특히 외부 서비스 통합이나 복잡한 비즈니스 로직이 포함된 작업에서는 성능이 급격히 저하됩니다.
• 향후 방향: 모델의 발전 방향은 단순한 코드 생성이 아니라, 자가 검증 (Self-testing) 을 통한 반복적 개선과 실패 모드 감소에 초점을 맞춰야 함을 시사합니다. 또한, 벤치마크 결과의 신뢰성을 위해 평가자 (Evaluator) 의 정렬과 선택이 중요한 과제로 대두되었습니다.

이 연구는 AI 에이전트가 실제 소프트웨어 개발 파이프라인에 통합되기 위해 해결해야 할 과제를 명확히 제시하며, 향후 에이전트 기반 코딩 도구의 발전 방향을 제시합니다.