103가지 실제 창의적 과제를 통해 AI 앱 빌더를 벤치마킹하며 배운 점

대부분의 AI 코딩 벤치마크는 모델이 제한된 프로그래밍 문제를 해결할 수 있는지 여부를 묻습니다. 이는 유용하지만, 실제 사람이 에이전트에게 앱을 만들도록 요청할 때 발생하는 많은 부분을 놓칩니다.

실제 요청은 스크린샷, 비디오, PDF, 부분적으로 작동하는 저장소(repository), 상충되는 후속 질문들, 또는 사용자가 이미 승인한 디자인과 함께 도착할 수 있습니다. 에이전트는 논의할지, 계획할지, 프로토타입을 만들지, 아니면 구축해야 할지 결정해야 합니다. 그런 다음 이전 결정을 유지하고, 실행 가능한 결과를 생성하며, 테스트하고, 사용자가 방향을 바꿀 때 복구해야 합니다.

Eazo는 최근 이러한 전체적인 창의적 과정(creative chain)을 중심으로 벤치마크를 발표했습니다. 이는 고립된 코드 생성 프롬프트들의 모음과는 다릅니다.

벤치마크 구성

이 벤치마크는 일곱 가지 역량 섹션에 걸쳐 103가지 실제 사용자 창의적 과제를 포함합니다:

입력 및 참조 자료 (Inputs and references)
의도 라우팅 및 디자인 깊이 (Intent routing and design depth)
자산 소싱, 프레젠테이션 및 통합 (Asset sourcing, presentation, and integration)
개발 및 런타임 (Development and runtime)
장애 발생 및 복구 (Disruption and recovery)
전달 및 게시 (Delivery and publishing)
교차 기능 역량 (Cross-cutting capabilities)

이 과제들에는 이미지, 비디오, CAD/STEP 파일, 문서, 기존 프로젝트, 디자인 피드백, 롤백 요청, 브라우저 QA, 내보내기(exports), 게시 등이 포함된 다중 턴 작업(multi-turn work)이 포함됩니다.

사용자의 말은 그대로 전송됩니다. 에이전트가 질문을 하면, 시뮬레이션된 사용자는 과제에서 이용 가능한 사실만을 가지고 답변하며, 점수 평가 기준을 노출하지 않습니다.

이 세부 사항이 중요합니다. 평가자가 은밀하게 에이전트를 예상되는 답변 쪽으로 도와준다면 벤치마크는 훨씬 쉬워집니다.

완성도와 품질 분리하기

모든 과제는 두 가지 방식으로 평가됩니다.

첫째, 여덟 가지 차원에 걸친 가중치 품질 점수:

정확한 단계 라우팅 (Correct stage routing)
단계별 명확한 결과물 (Clear deliverable per step)
이전 상태의 연속성 (Continuity of prior state)
자산, 디자인 및 코드 재사용 (Asset, design, and code reuse)
핵심 기능 완성도 (Core feature completeness)
상호 작용 및 실패 상태 (Interaction and failure states)
응답성, 성능 및 접근성 (Responsiveness, performance, and accessibility)
자가 테스트 및 전달 품질 (Self-testing and delivery quality)

둘째, 항목별 승인(item-by-item acceptance)입니다. 각 과제는 명시적인 결과물과 프로세스 요구사항을 가집니다. 어떤 항목은 고정된 증거가 뒷받침할 때만 통과합니다.

이러한 구분이 일반적인 실패 모드를 방지합니다. 즉, 앱, 파일 또는 런타임이 실제로 주장을 지원하지 않음에도 불구하고 성공을 주장하는 잘 다듬어진 최종 메시지를 내는 경우입니다.

증거는 에이전트의 서술이 아닌 브라우저 자체이다

실행이 끝날 때, 대화 내용, 파일, 스크린샷 및 런타임 상태가 고정됩니다. 평가자들은 에이전트에게 후속 질문을 하거나 결과를 수정하지 않고 이 증거를 바탕으로 판단합니다.

실행 가능한 앱의 경우, 별도의 테스터가 실제 브라우저에서 제품을 열고 상호작용을 수행하며 데스크톱 및 모바일 증거를 캡처합니다. 평가자들은 그 후 각 요구사항이 통과했는지 여부를 결정합니다.

유용한 규칙이 도출됩니다:

“에이전트가 작동한다고 말했다”는 그것이 작동한다는 증거가 아닙니다.

이는 당연하게 들리지만, 벤치마크 설계 자체를 변화시킵니다. 빌드 명령이 성공적으로 종료된다고 해서 주요 상호작용이 작동하는 것을 증명하지 못합니다. 스크린샷이 상태 변경을 올바르게 수행한다는 것을 증명하지 못합니다. 배포된 URL이 요청된 버전이 배포되었다는 것을 증명하지 못합니다.

103가지 과제에서 얻은 다섯 가지 교훈

1. 라우팅 오류는 코딩 오류보다 먼저 발생한다

에이전트는 유능한 코드를 작성할 수 있지만, 너무 멀리 나아가 사용자 요청을 실패하게 만들 수도 있습니다.

만약 사용자가 옵션을 비교해달라고 요청했다면, 앱을 구축하는 것은 보너스가 아닙니다. 만약 그들이 “기존 프로젝트를 읽고 기다려라”라고 말했다면, 파일을 편집하는 것은 실패입니다. 만약 그들이 가벼운 프로토타입 하나를 요청했다면, 완벽한 제품을 만들어내는 것이 반복 작업을 더 어렵게 만들 수 있습니다.

이 벤치마크는 올바른 단계—논의(discussion), 계획(plan), 아티팩트(artifact), 프로토타입(prototype), 또는 실행 가능한 앱(runnable app)—를 전용 품질 차원으로 취급합니다.

2. 연속성(Continuity)은 일급 기능이다

많은 실제 실패는 구문 오류가 아닙니다. 그것들은 이전 결정에 대한 조용한 되돌림입니다:

선택된 디자인이 구현 과정에서 사라진다.
제공된 에셋이 일반적인 대체물로 교체된다.
로컬 전용 요구사항이 공개 배포가 된다.
롤백(rollback)이 UI는 복원하지만 근본적인 동작은 복원하지 못한다.

단일 턴(Single-turn) 벤치마크로는 이러한 상황을 거의 노출할 수 없습니다. 멀티 턴(Multi-turn) 작업만이 가능하게 합니다.

3. 멀티모달 입력은 결과를 변경할 때만 가치가 있다

'이미지 지원'이라는 것은 파일을 업로드하는 것부터 이미지의 로컬 세부 정보를 실제로 제품에 활용하는 것까지 무엇이든 의미할 수 있습니다.

PDF, CAD 어셈블리, 비디오, 기존 저장소에도 같은 원칙이 적용됩니다. 의미 있는 평가는 에이전트가 단순히 첨부 파일을 인지했는지 여부가 아니라, 해당 자료를 파싱(parsed)하고 관련 부분을 이해했으며 그 사실들을 결과물에 반영했는지를 확인해야 합니다.

4. 복구 기능은 전용 테스트가 필요하다

사용자는 마음을 바꿉니다. 도구는 실패합니다. 생성된 에셋은 사용 불가능할 수 있습니다. 디자인 방향은 구현이 시작된 후 거부될 수도 있습니다.

롤백, 작업 중 피벗(mid-task pivots), 에셋 잠금(asset locking), 그리고 실패 복구 기능에는 명시적인 테스트가 필요합니다. 그렇지 않으면 벤치마크는 모든 이전 단계가 완벽하게 진행될 때만 작동하는 에이전트에게 과도한 점수를 부여하게 됩니다.

5. 종합 점수는 중요한 실패를 숨긴다

벤치마크 전반에 걸쳐 Eazo의 평균 복합 품질 점수(average composite quality score)는 88.5였으며, Codex는 84.2였습니다. 평균 작업 시간은 11.1분 대 11.7분이었고, 총 토큰 사용량은 158M 대 179M이었습니다.

하지만 결과물 통과율(deliverable pass rate)은 두 시스템 모두 **60%**였습니다. 프로세스 통과율(process pass rate)은 Eazo가 52%, Codex가 **47%**였습니다.

이 수치들은 유용한 상기시켜주는 점입니다: 높은 평균 품질 점수가 모든 필수 항목이 통과했음을 의미하지는 않습니다. 상세한 작업 증거가 단일 리더보드 점수보다 더 많은 정보를 제공합니다.

방법론, 작업별 사례, 채점 차원 및 현재 종합 결과는 전체 Eazo 벤치마크에서 확인할 수 있습니다.

에이전트 벤치마크를 위한 재사용 가능한 체크리스트

앱 빌딩 에이전트를 평가할 때는 다음 사항들을 벤치마크에 포함했는지 확인해야 합니다:

평가자(evaluator)가 정리한 프롬프트 대신 원본 사용자 언어(Raw user language)
다중 턴 변경 및 수정 작업(Multi-turn changes and corrections)
기존 파일 및 프로젝트
이미지, 문서, 비디오 또는 구조화된 데이터
논의(discussion), 계획(planning), 프로토타이핑(prototyping), 빌딩(building) 간의 구분
실행 후 고정 증거(Frozen evidence after execution)
독립적인 브라우저 테스트
모바일 및 데스크톱 확인
로딩, 빈 상태(empty), 오류 상태(error states)
롤백 및 복구 작업(Rollback and recovery tasks)
항목별 증거 인용(Item-level evidence citations)
분리된 산출물 및 프로세스 요구 사항
덮어쓰기하는 대신 검토 수정 사항을 기록할 수 있는 방법

이 목표는 벤치마크 자체를 복잡하게 만드는 것이 아닙니다. 사용자가 실제로 사용할 수 없는 작업에 대해 시스템이 공로를 인정받지 못하도록 어렵게 만드는 것입니다.

한계를 가시화하기(Keep the limitations visible)

모든 벤치마크는 그 자체의 과제 선택, 채점 가중치, 제품 버전 및 검토 프로세스를 반영합니다. 따라서 두 시스템 간의 비교가 모든 코딩 에이전트에 대한 보편적인 순위표를 의미하지 않으며, 종합 점수는 개별 실패 사례를 모호하게 만들 수 있습니다.

그러므로 가장 유용한 벤치마크는 단순히 리더보드가 아닙니다. 다른 사람들이 질문할 수 있는 과제, 아티팩트(artifacts), 런타임 증거, 그리고 검토 결정들이 포함된 검사 가능한 컬렉션이어야 합니다.