기술 요약: Asuka-Bench

문제 정의

기존의 코드 생성 벤치마크는 에이전트가 완전하고 모호함이 없는 명세(specification)를 전달받아 단 한 번의 실행으로 올바른 출력을 생성하는 능력을 평가하는 "단일 턴, 원샷(single-turn, one-shot)" 패러다임에 주로 의존합니다. 이러한 접근 방식은 실제 소프트웨어 개발, 특히 웹 개발의 현실과 근본적으로 일치하지 않습니다. 실제 환경에서 사용자는 초기 단계에 전체 명세를 모두 설명하는 경우가 드뭅니다. 요구사항은 중간 결과물을 검토하고 교정 피드백을 제공하는 과정에서 점진적으로 드러나고 명확해집니다. 현재의 벤치마크들은 미흡하게 정의된 의도(underspecified intents)를 해석하고, 실행 피드백을 통합하며, 올바른 구현을 향해 작업을 반복적으로 개선하는 에이전트의 능력을 평가하는 데 실패하고 있습니다. 또한, 많은 기존 웹 벤치마크는 시각적 충실도에 집중하거나 완전히 지정된 입력을 가정하며, 사용자 상호작용 루프로부터 도출되는 기능적 정확성과 견고성을 간과합니다.

방법론

저자들은 브라우저 관찰 가능한 동작에 기반하여, 다회차 반복적 개선(multi-round iterative refinement)을 통해 미흡하게 정의된 사용자 의도 하에서의 코드 에이전트를 평가하도록 설계된 벤치마크인 Asuka-Bench를 소개합니다.

평가 프레임워크

이 벤치마크는 세 가지 구별된 에이전트가 참여하는 폐쇄 루프 메커니즘을 통해 작동합니다:

1. 코드 에이전트(Code Agent): 의도적으로 미흡하게 정의된 사용자 쿼리(예: "쇼핑 웹사이트를 만들어줘...")를 전달받아 초기 웹 프로젝트를 생성합니다. 이후 피드백을 바탕으로 이 프로젝트를 반복적으로 개선합니다.
2. UI 에이전트(UI Agent): 생성된 프로젝트를 브라우저 환경에 배포하고, 자율적이고 상호작용적인 테스트 케이스로서 사전 정의된 평가 기준을 실행합니다. 정적 코드 분석과 달리, UI 에이전트는 소스 코드를 검사하는 대신 렌더링된 동작(예: 요소 클릭, 데이터 업데이트 확인)을 기준으로 결과를 판단합니다.
3. 사용자 LLM(User LLM): UI 에이전트의 통과/실패 결과를 구조화된 자연어 피드백으로 합성하여 코드 에이전트에게 다음 개선 라운드를 위해 전달합니다.

데이터셋 구축

• 출처: 데이터셋은 실제 프로덕션 서비스의 비식별화된 실제 사용자 요청, 오픈 소스 GitHub 저장소의 정형화된 쿼리, 그리고 기능이 풍부한 기성 웹사이트의 요약본 등 세 가지 출처에서 파생된 50개의 웹 개발 태스크로 구성됩니다.
• 태스크 정형화: 각 태스크는 그라운드 트루스(ground truth) 역할을 하는 **명확화된 제품 요구사항 문서(Clarified PRD)**와 쌍을 이룹니다. 이 PRD로부터 벤치마크는 다음 항목들을 도출합니다:
  • 미흡하게 정의된 쿼리 (코드 에이전트의 입력값).
  • 시뮬레이션 데이터 (자기 완결적인 프론트엔드 실행을 위한 모의 API, 사용자 프로필).
  • 평가 기준: 유향 비순환 그래프(DAG)로 조직된 구조화된 자연어 테스트 케이스 세트.
• 기준 유형: 태스크는 존재 여부(요소 존재), 기능성(상호작용 동작), 견고성(엣지 케이스 처리)으로 분류됩니다.
• DAG 인식 프로토콜: 평가 태스크는 위상 정렬 순서(topological order)에 따라 실행됩니다. 특정 태스크는 그 선행 의존성이 통과했을 때만 평가됩니다. 이는 근본 원인이 후속 평가를 차단하는 "연쇄 실패(cascading failures)"를 방지하여, 피드백이 근본 원인에 집중할 수 있도록 보장합니다. 또한, 부모 태스크의 하위 기준 중 최소 50%가 통과하면 만족된 것으로 간주하는 "소프트 만족(soft-satisfaction)" 임계값($T=0.5$)을 사용하여 평가 노이즈를 최소화합니다.

실험 설정

저자들은 두 가지 에이전트 프레임워크인 OpenHands(샌드박스 기반)와 Claude Code(CLI 기반)에서 8개의 최첨단 대규모 언어 모델(LLM)을 평가했습니다. 최대 개선 라운드는 3회로 설정되었습니다. 지표에는 프로젝트 완료율(PCR), 누적 가중 태스크 통과율, 누적 가중 기준 통과율이 포함되었습니다.

주요 기여

1. Asuka-Bench 벤치마크: 정적 지시문 벤치마크와 반복적인 실제 개발 사이의 간극을 메우기 위해, 다회차 상호작용적 개선을 통해 미흡한 요청 하에서의 코드 에이전트를 체계적으로 평가하는 최초의 웹 생성 벤치마크입니다.
2. 사용자 피드백 중심 평가 프로토콜:
   • 피드백으로서의 상호작용: 평가는 소스 코드가 아닌 브라우저에 렌더링된 동작에 근거합니다.
   • DAG 인식 반복 평가: 기준을 위상 정렬 순서로 실행하고 실패한 선행 조건에서 조기에 중단함으로써, 프로토콜은 평균 10.5 퍼센티지 포인트(pp) 높은 태스크 수정률을 달 수 있었으며 평가 토큰 비용을 23–26% 절감했습니다.
3. 포괄적 경험적 분석: 본 연구는 의도의 모호성과 반복적 피드백이 성능에 미치는 영향에 대한 통찰을 제공하며, 피드백으로부터 복구하는 능력이 초기 생성 품질과는 별개의 능력 축임을 입증합니다.

결과

• 모델 차별화: Asoka-Bench는 모델 성능을 효과적으로 구분합니다. 3라운드 후 가중 태스크 통과율은 모델 간에 38 퍼센티지 포인트의 차이를 보였습니다.
• 반복적 개선: 가장 강력한 모델들이 높은 태스크 통과율(90%)을 달로 하지만, 모든 태스크가 통과되어야 하는 프로젝트 완료율(Project Completion Rate)은 여전히 낮게(52%) 나타나, 완전한 정확성을 달성하는 것의 어려움을 보여줍니다.
• 수정 vs 생성: 피드백으로부터 오류를 수정하는 능력은 1라운드 생성 품질과 대체로 분리되어 있습니다. 예를 들어, Kimi-K2.6은 평범한 첫 라운드로 시작했으나 이후 라운드에서 크게 개선되어, 초기 생성 능력이 더 강했던 모델들보다 최종 누적 점수에서 앞섰습니다.
• 포화 상태: 벤치마크는 아직 포화되지 않았습니다. 가장 강력한 모델(Claude-4.6-Sonnet)조차 3라운드 후에는 **52%**의 프로젝트만을 완료합니다. 그러나 가장 강력한 모델을 8라운드까지 확장했을 때 100% 완료율을 기록하여, 태스크가 해결 가능하며 피드백 메커니즘이 효과적임을 확인했습니다.
• 인간 정렬(Human Alignment): 자동화된 평가 에이전트는 인간 전문가의 판단에 대해 93.35%의 정확도와 96.52%의 F1 점수를 달성하여, 폐쇄 루프 프레임워크의 신뢰성을 검증했습니다.

의의

본 논문은 Asuka-Bench가 기존 벤치마크의 결정적인 사각지대, 즉 피드백 기반 루프 하에서 수렴하는 에이전트의 능력을 평가하지 못하는 문제를 밝혀냈다고 주장합니다. 정적인 원샷 평가에서 미흡하게 정의된 의도에 따른 반복적 개선으로 전환함으로써, 이 벤치마크는 실제 배포 환경에서의 에이전트 효용성에 대한 더 현실적인 척도를 제공합니다. 결과는 "피드백으로부터의 복구(repair-from-feedback)"가 현재의 원샷 벤치마크가 포착하지 못하는 별개의 모델 능력 차원임을 시사합니다. 저자들은 Asuka-Bench를 실제 소프트웨어 엔지니어링의 반복적이고 대화 중심적인 특성을 반영하는 벤치마크를 향한 단계로 위치시키며, 커뮤니티가 정적인 평가 패러다임을 넘어설 것을 독려합니다.