AI 벤치마킹의 착시, Todo 앱은 이제 그만
AI 코딩 에이전트를 평가하는 방식이 오래된 기준에 머물러 있다. Todo 앱을 스캐폴딩하고, CRUD를 완성하고, 테스트를 통과시키는 것. 이 시나리오에서 대부분의 최신 에이전트는 '합격점'을 받는다. 그런데 이 기준으로 무엇을 측정하고 있는 걸까? 로컬 정합성이다. 필드 하나 추가하고, 폼 하나 바꾸고, 스키마 하나 수정하는 작업. AI는 이 범위 안에서는 거의 실수하지 않는다.
문제는 실제 프로덕트가 그렇게 작동하지 않는다는 것이다.
MMO는 왜 좋은 스트레스 테스트인가
dev.to에 올라온 'World of ClaudeCraft' 프로젝트는 이 질문에 정면으로 대답한다. 브라우저 기반 MMO를 48시간 안에 Claude와 함께 만든다는, 합리적으로는 시도하면 안 되는 실험이었다. 결과는 레벨 1~20 구간, 9개 직업, 3개 오픈 필드, 90여 개 퀘스트, 인스턴스 던전, 보스 메커닉, 파티·거래·결투·랭크 PvP, 지속형 캐릭터, 모바일 컨트롤을 갖춘 실제로 플레이 가능한 세계였다. 독립 MMO 미디어 MMORPG.com은 이를 "놀랍도록 완성도 있다"고 평했고, "더 긴 개발 주기를 가진 스튜디오 데모보다 나은 상태"라고 덧붙였다.
왜 MMO인가. 리얼타임 네트워킹, 영속 상태, 전투 수치, 캐릭터 성장, 인벤토리, 경제 시스템, 소셜 구조, 배포, 보안, 그리고 서버가 권한을 쥐는 동안 클라이언트는 반응성을 유지해야 하는 렌더링 레이어. 모든 서브시스템이 다른 서브시스템을 망가뜨릴 수 있다. 하나의 클래스 어빌리티를 추가하면 시뮬레이션 룰, 자원 비용, 타겟팅 검증, 서버 커맨드 처리, 클라이언트 피드백, 액션바 UI, 영속성, 현지화, 봇 테스트, PvE/PvP 밸런스까지 동시에 건드려야 한다. 이것이 '크로스컷팅 복잡도'다. Todo 앱은 이 복잡도를 전혀 만지지 않는다.
아키텍처가 진짜 이야기다
World of ClaudeCraft의 핵심은 코드 생성량이 아니라 설계 원칙 하나에 있다. 하나의 결정론적 게임 시뮬레이션, 그리고 모든 호스트가 이것을 공유한다. 오프라인 브라우저 세계, 멀티플레이어 서버(REST + WebSocket + PostgreSQL), 강화학습용 헤드리스 환경 세 가지가 동일한 src/sim 코어를 구동한다. 렌더러와 HUD는 구체적인 구현이 아니라 IWorld 인터페이스와 대화한다.
이 결정론적 설계가 만들어낸 효과는 단순하지 않다. Math.random()을 쓰지 않고 시드를 심으면 에피소드를 재현할 수 있다. 간헐적 실패를 쫓는 대신 테스트가 실패를 재현한다. 헤드리스 에이전트가 단순화된 포트가 아닌 실제 게임을 상대로 훈련한다. 바이옴 날씨 같은 비주얼 효과는 시뮬레이션 밖에 위치하므로 비가 내려도 게임 상태는 바뀌지 않는다.
프로젝트를 함께 진행한 개발자는 또 다른 글에서 이 경험의 핵심을 솔직하게 요약했다. "AI는 병목을 옮겼을 뿐, 제거하지 않았다." 전투 함수 생성은 빨라졌다. 하지만 10인 레이드에서 절반의 플레이어에게 전리품이 지급되지 않는 버그를 찾아내는 것은 다른 문제였다. PARTY_MAX 상수가 기존 던전 코드에서 5로 하드코딩된 채 남아 있었던 것이다. 오류도, 크래시도 없었다. 그냥 조용히 깨져 있었다. 이런 버그는 빠른 코드 생성으로는 막을 수 없다. 전체 시스템을 머릿속에 쥐고 있어야 보인다.
새로운 측정 기준: 시간당 검증 가능한 결정의 수
World of ClaudeCraft가 제안하는 벤치마킹 기준은 이렇다. 모델이 얼마나 많은 코드를 썼는가가 아니라, 인간 팀이 시간당 얼마나 많은 중요한 결정을 검증할 수 있었는가.
이 기준을 높이는 것은 프롬프트 실력이 아니다. 좋은 테스트 하네스, 결정론적 상태, 명시적 인터페이스, 빠른 테스트, 브라우저 자동화, 서버 권한 설계다. AI는 구현 속도를 끌어올렸지만, 세계가 왜 존재해야 하는지, 게임 피드백이 만족스러운지, 어떤 기능을 잘라낼지, 라이브 서비스를 운영하는 방식은 여전히 인간의 판단 영역이었다. 소프트웨어는 컴파일될 때 가치 있는 것이 아니라, 누군가가 그 제약을 설명하고 동작을 테스트하고 결과에 책임질 수 있을 때 가치 있다.
Claude Code 실무 워크플로우: 복잡도를 다루는 방법
이 복잡도를 실제로 다루는 실무 레이어로 Claude Code 가이드(velog)가 맞닿아 있다. 복잡한 시스템을 AI와 함께 다룰 때 가장 자주 무너지는 지점은 컨텍스트 관리다. 컨텍스트가 가득 찰수록 품질이 떨어지고, 긴 세션은 어느 순간 조용히 방향을 잃는다.
실무적으로 유효한 패턴은 다음과 같다. 조사와 구현을 분리하라. 큰 탐색 작업은 subagents에 위임해 메인 컨텍스트를 보호하라. 프로젝트 규칙과 아키텍처 제약은 CLAUDE.md에 영구 저장하라(대화에 반복하지 말고). 위험한 변경은 읽기 → 계획 → 검토 → 구현 순서를 지켜라. 그리고 무엇보다, 검증 기준이 없는 프롬프트는 결국 사람이 유일한 피드백 루프가 된다는 점을 기억하라.
가이드가 강조하는 핵심 지표도 같다. 모델이 얼마나 많이 생성했느냐가 아니라, 그 결과를 얼마나 빠르게 검증할 수 있느냐.
시사점: 작은 팀이 시도할 수 있는 것이 달라졌다
World of ClaudeCraft가 가장 솔직하게 드러낸 것은 AI가 만능 개발자가 됐다는 주장이 아니다. 소규모 팀이 이전엔 시도하는 것 자체가 비합리적이었던 시스템을 이제 시도할 수 있게 됐다는 것이다. 그리고 그 시스템이 무너지지 않으려면, AI를 얼마나 잘 쓰느냐보다 아키텍처 불변식을 얼마나 잘 설계하느냐가 더 중요하다는 것이다.
AI 출력은 저렴해졌다. 아키텍처적 불변식은 여전히 비싸다. 프론트엔드 개발자 관점에서 이 격언은 더 구체적으로 읽힌다. 컴포넌트 생성은 AI가 한다. IWorld 인터페이스를 어디에 그을지는 여전히 사람이 결정한다. 빠른 프로토타이핑이 가치 있으려면, 그 위에 검증 가능한 설계가 받쳐줘야 한다.
전망: 복잡도가 AI 에이전트의 다음 전쟁터다
앞으로 AI 코딩 에이전트의 경쟁은 Todo 앱 완성 속도가 아니라 크로스컷팅 복잡도 처리 능력으로 이동할 것이다. 긴 컨텍스트 윈도우, 멀티 에이전트 협업, 결정론적 테스트 하네스와의 통합, 그리고 시스템 전체를 일관된 모델로 유지하면서 제품이 변화하는 것을 견디는 능력. 이것이 다음 벤치마크가 물어야 할 질문이다.
World of ClaudeCraft는 오픈소스(MIT)로 공개되어 있다. 코드를 직접 열어볼 수 있다는 것, 그것이 이 프로젝트를 단순한 AI 데모가 아닌 '반증 가능한 엔지니어링 결과물'로 만드는 이유다. 주장이 아니라 코드로 검증하라. 지금 AI 도구를 평가하는 방식도 그래야 한다.