AI 모델에게 웹 앱 구축을 요청해 보니, 대부분 페이지 내에 가짜 서버를 구현했습니다.

이 글은 Kaggle Benchmarking Challenge에 제출하는 내용입니다.

제가 벤치마크한 것들

AI 코딩 데모는 행복한 경로(happy path)만을 보여줍니다. 즉, 양식이 렌더링되고, 버튼을 클릭하면 녹색의 "성공!" 메시지가 나타나는 식입니다. 저는 실제 사용자가 등장했을 때 무슨 일이 일어나는지 알고 싶었습니다.

RealityBench는 모델에게 열두 개의 작은 웹 앱 중 하나의 사양(spec)을 제공한 다음, 헤드리스 브라우저(headless browser)에서 해당 페이지를 열고 사용자들이 실제로 하는 행동들을 수행합니다:

• 서버가 500 에러나 "슬롯 이미 사용됨(slot already taken)"이라는 409 응답을 보내는 경우
• 결제 버튼을 두 번 클릭하는 경우
• 빈 양식, 음수 수량, 또는 PDF 대신 .exe 파일을 제출하는 경우
• 키보드만 사용하는 경우, 또는 375px의 휴대폰 화면 크기에서 사용하는 경우

모든 페이지는 0점에서 100점 사이의 두 가지 점수를 받습니다:

• Demo: 행복한 경로가 작동하며, 주요 액션이 실제로 서버에 도달하는지 여부.
• Reality: 그러한 조건에서도 여전히 작동하는지 여부.

채점기는 사용자가 볼 수 있는 것만 계산합니다. 이 규칙은 이 벤치마크의 첫 버전이 속이기 쉬웠기 때문에 존재하며, 이에 대해서는 나중에 설명하겠습니다.

이는 다른 사람들이 이미 제기하고 있는 지점과 연결됩니다: AI가 생성한 UI는 첫 화면에서 완성된 것처럼 보인다 그리고 해당 코드가 병합되기 전에 안전장치로 Playwright가 사용되고 있다는 점입니다 Playwright를 AI 생성 프론트엔드 코드의 안전망으로 사용하기. RealityBench는 바로 그 지점, 즉 네트워크 호출을 겨냥한 검사입니다.

테스트된 모델들

• Claude Opus 5.5: 강력한 코딩 모델의 기준으로 모든 12개 작업을 수행했습니다.
• Gemini 3.7 Flash: 대량으로 UI를 생성하는 데 사용되는 빠른 모델로서 모든 12개 작업을 수행했습니다.

GPT-5.6 Sol, Gemini 3.8 Flash, Gemma 4 31B, 그리고 Qwen 3 Coder도 라인업에 포함되었습니다. 현재 채점기에서는 GPT와 Gemini 3.8이 각각 하나의 작업만 완료한 후 나중에 실행에서 오류가 발생했습니다(계정의 호출당 할당량 예약이 소진됨). Gemma와 Qwen은 이전 채점기의 점수만 가지고 있습니다. 저는 이들을 표에서 제외했습니다. 한 가지 작업은 모델 점수가 아닙니다.

각 모델은 동일한 12개의 프롬프트를 받았고, 각 작업마다 한 번씩 실행되었습니다.

분석 결과

모델들은 페이지 내에 가짜 백엔드를 구축합니다

프롬프트는 "/api/book으로 POST 요청을 보내라"라고 지시했습니다. Gemini의 예약 페이지는 브라우저의 fetch를 대체하여 로컬에서 응답합니다. 이것은 모델 자체의 코드이며, 409 분기만 잘라내어 단축된 것입니다:

/* MOCK SERVER INTERCEPTOR (독립적인 실행을 위한) 
   standalone 브라우저에서 fetch('/api/book')이 정확하게 작동하도록 보장합니다. */
const originalFetch = window.fetch;
...

해당 페이지는 "예약이 확인되었습니다"와 예약 ID를 표시할 수 있습니다. 하지만 실제로는 아무것도 예약되지 않았습니다. 모델은 독립적인 데모가 작동하도록 하려고 시도하고 있으며, 주석에서도 그렇게 명시하고 있습니다.

그레이더(grader)는 이를 직접 확인합니다. 페이지 로드가 완료된 후, window.fetch가 여전히 브라우저 고유의 함수인지 묻습니다. 그렇지 않다면, 리포트에는 fake_backend: true로 설정됩니다.

Gemini 3.7 Flash의 경우 이 플래그가 12개 작업 중 7개 페이지에서 설정되었습니다. 8개의 페이지가 정상 경로(happy path)를 통과하지 못했고, 그중 7개가 플래그 지정되었습니다. 예외는 로그인 페이지입니다: 데모 점수는 62.5점이었고, fetch는 여전히 네이티브했습니다. 파일 업로드 페이지는 데모(100점)를 통과했지만, 레이블이 없는 파일 입력 필드에서 실제 구현 점수에서는 감점을 받았습니다(88.3점). 가짜 서버가 놓친 대부분의 부분을 설명하지만, 모든 것을 설명하지는 못합니다.

Opus는 동일한 본능을 가지고 있지만 기본 설정이 다릅니다. 12개 페이지 중 7개 페이지에는 가짜(mock) fetch가 포함되어 있습니다. 이 중 6개 페이지는 오직 ?demo, ?mock, 또는 file:// URL일 때만 이를 설치하므로, 일반적인 로드는 실제 함수를 사용합니다. 이 여섯 개의 페이지는 데모와 현실 테스트 모두에서 100점을 받았습니다. 일곱 번째인 설정(settings) 페이지는 모든 로드 시점에서 fetch를 대체합니다. "Mock 서버 사용" 체크박스는 기본적으로 선택되어 있습니다. 이것이 평가기가 플래그를 지정한 유일한 Opus 페이지이며, 실패한 작업도 유일합니다: 데모 62.5점, 현실 95점.

두 번의 전체 실행을 거치면서, 9개의 행복 경로(happy-path) 실패 중 8개는 fetch를 대체했던 페이지들이었습니다.

제가 직접 만든 평가기도 같은 종류의 함정에 빠졌습니다

첫 번째 평가기는 페이지 소스 코드를 검색했습니다. 숨겨진 "예약 확정!" 문구는 확인 절차를 통과했고, 스크립트 내부의 catch (error) 구문은 "오류 표시" 검사를 통과했습니다. 일부 페이지는 사용자가 결코 보지 못하는 텍스트에 대해 점수를 받았기 때문에 데모 테스트보다 스트레스 테스트에서 더 높은 점수를 받았습니다.

또한 좋은 페이지들을 고장 난 것으로 표시하기도 했습니다. Opus는 유효한 파일을 선택할 때까지 업로드(Upload) 기능을 비활성화합니다. 평가기는 그 비활성화된 버튼을 클릭하고 30초를 기다린 후 실패로 기록했습니다. 체크박스에 타이핑했고, 장바구니에 추가하기("Add to Cart") 대신 수량 "−" 버튼을 두 번 클릭했습니다.

평가기는 이제 보이는 텍스트와 양식 필드의 값을 읽고, 행동과 일치하는 레이블의 버튼을 누르며, 비활성화된 컨트롤은 "누를 수 없음"으로 간주합니다. 위에 제시된 숫자는 Kaggle에서 실행한 해당 평가기의 결과입니다. 수정 후, Opus는 하나의 실패 작업만 가지게 되었으며, 이는 모크 기능이 켜진 설정 페이지입니다.

다음에 측정할 것들

• 작업당 여러 번의 실행을 통해 표가 단일 샘플 대신 범위를 보여줄 수 있도록 합니다.
• 쿼터 예약으로 인해 실행이 중단되지 않는다면 나머지 라인업 전체를 테스트합니다.
• 한 줄을 추가한 동일한 프롬프트("실제 백엔드가 이 URL에서 이미 실행되고 있습니다.")로 테스트합니다. 가짜 서버가 사라지는지, 아니면 모델들이 "만약을 대비해" 계속 유지하는지 알고 싶습니다.

나의 벤치마크

• Code: github.com/fab-c14/realitybench
• Kaggle: the twelve RealityBench tasks, 각 과제는 공개되어 있으며, 모델 실행 결과는 해당 과제 페이지에서 확인할 수 있습니다. 이름과 링크는 위의 표에 나와 있습니다.

로컬에서 페이지를 평가할 수 있습니다:

uv sync && uv run playwright install chromium
uv run realitybench prompt checkout > spec.txt
uv run realitybench grade checkout page.html

grade는 일반 HTML 파일 또는 코드 블록에 포함된 HTML을 가진 모델 응답을 받습니다. 만약 페이지가 fetch를 대체했다면, 경고 메시지를 출력합니다.