SWE-WebDevBench: 가상 소프트웨어 에이전시로서의 코딩 에이전트 애플리케이션 플랫폼 평가

자연어만으로 앱을 만드는 '바이브 코딩' 플랫폼들이 등장했지만, 이들이 실제 비즈니스 환경에서 사용 가능한 수준인지는 미지수였다. 이 논문은 단순 코드 생성을 넘어 기획, 설계, 보안, 인프라를 아우르는 68개 지표로 AI 플랫폼을 평가하여 현재 기술의 명확한 한계와 개선 방향을 제시한다.

기존의 코딩 벤치마크인 HumanEval이나 SWE-bench는 특정 함수를 구현하거나 버그를 수정하는 '개발자 중심'의 작업에 치중되어 있다. 하지만 사용자가 자연어로 앱을 주문하는 환경에서는 AI가 단순한 코더가 아닌 '소프트웨어 에이전시' 전체의 역할을 수행해야 한다. 즉, 모호한 요구사항에서 비즈니스 의도를 파악(Embedding & Inference)하고, 데이터베이스 구조를 설계(Architecture)하며, 보안과 배포까지 책임져야 한다.

이 논문은 AI 플랫폼이 겉보기에 화려한 UI(Frontend)를 만드는 데는 능숙하지만, 실제 비즈니스 로직과 백엔드 인프라를 연결하는 과정에서 심각한 결함이 발생한다는 점에 주목한다. 특히 '바이브 코딩' 사용자는 코드를 직접 읽지 못하기 때문에, 내부에서 발생하는 보안 취약점이나 데이터 무결성 오류는 사용자에게 보이지 않는 치명적인 위험이 된다.

결과적으로 AI 플랫폼의 성능은 단순한 코드 생성 정확도가 아니라, 기획-설계-구현-배포로 이어지는 전체 파이프라인의 '폐쇄 루프(Closed-loop)' 피드백 역량에 달려 있음을 보여준다. 기획 단계의 의사결정이 구현 단계의 제약 조건과 충돌할 때 이를 스스로 감지하고 수정하는 능력이 프로덕션 수준의 소프트웨어를 만드는 핵심 원리이다.

평가 프레임워크는 Interaction Mode(ACR vs AMR), Agency Angle(PM, Engineering, Ops), Complexity Tier(T4 SaaS, T5 AI-native)의 세 축으로 구성된 Evaluation Cube 구조를 가진다. 각 플랫폼은 3개 비즈니스 도메인(EdTech, Field Service, FinTech-AI)에 걸친 6개의 표준화된 프롬프트를 통해 평가받는다.

평가 프로세스는 7단계 파이프라인으로 진행된다. [자연어 프롬프트 입력 → PM 에이전시 평가 → 코드 생성 및 감사 → Lighthouse/k6 등을 활용한 자동화 오딧 → 보안 및 통합 테스트 → 전문가 패널 리뷰 → 최종 점수 산출] 순서로 데이터가 처리된다. 특히 Engineering Score는 G2(코드 품질)부터 G6(비즈니스 준비도)까지의 지표를 가중 평균하여 산출하며, 각 지표는 0~3단계의 Judging Taxonomy(자동화 도구부터 전문가 패널까지)에 따라 엄격하게 채점된다.

평가 대상인 6개 플랫폼 중 어느 곳도 엔지니어링 품질 점수 60%를 넘지 못했다. 특히 보안 점수는 목표치인 90%에 한참 못 미치는 최대 65% 수준에 머물렀으며, 동시성 처리 능력은 최저 6%까지 떨어지는 등 인프라 측면의 취약점이 두드러졌다.

가장 큰 문제로 지적된 것은 '사양 병목 현상(Specification Bottleneck)'이다. 플랫폼들이 복잡한 비즈니스 요구사항을 지나치게 단순화된 기술 계획으로 압축하면서 도메인 맥락을 손실하는 현상이 관찰되었다. 또한 시각적으로는 완성도 높은 UI를 보여주지만 실제 백엔드 기능이 동작하지 않는 '프론트엔드-백엔드 디커플링' 현상이 모든 플랫폼에서 공통적으로 나타났다.

SWE-WebDev Bench는 단순한 점수 산출을 넘어 43개의 진단 메트릭을 통해 실패의 원인을 추적한다. 예를 들어 Feature Completeness 점수가 낮을 경우, 그것이 요구사항 캡처 실패(Explicit Capture Rate) 때문인지 아니면 계획 실행 오류(Plan-to-Execution Fidelity) 때문인지를 구분해낸다.

아키텍처적으로는 '폐쇄 루프 코드 생성(Closed-loop Code Generation)'의 중요성을 강조한다. 기획과 실행 사이에 피드백 루프가 있는 멀티 에이전트 구조의 플랫폼(예: QwikBuild)이 단일 패스 생성 방식보다 요구사항 모순 해결 및 복잡한 로직 구현에서 우위를 점한다는 사실을 기술적으로 분석했다. 또한 AMR 평가를 통해 기존 코드의 컨텍스트를 유지하면서 새로운 기능을 추가할 때 발생하는 회귀 오류(Regression)를 정밀하게 측정하는 수식을 도입했다.

평가 샘플 사이즈가 6개 플랫폼과 3개 도메인으로 제한적이며, 일부 지표는 LLM 판정단(LLM-as-a-Judge)에 의존하고 있어 판정 모델 자체의 편향성이 개입될 여지가 있다. 또한 AI 기술의 발전 속도가 매우 빨라 특정 시점의 평가 결과가 플랫폼의 영구적인 성능을 대변하지는 않는다.