에이전트 12명에게 피카츄 배구를 맡겼더니 tool call 197번이 나왔다

프롬프트 한 줄이었다.

피카츄 배구 멀티로 만들어줘

agentochester는 이 요청을 받아서 에이전트 3명을 병렬로 dispatch했다. game_designer, frontend_developer, backend_architect. 1시간 53분 후, tool call 197번이 찍혔다.

TL;DR 병렬 에이전트는 빠르게 동작했지만 “원본 피카츄 게임 느낌”을 살리는 건 반복 수정이 필요했다. 에이전트가 잘 모르는 도메인은 명확한 레퍼런스를 줘야 한다.

agentochester가 뭐 하는 툴인가

agentochester는 사용자 프롬프트를 작업으로 분해해서 역할별 에이전트에게 dispatch하는 CLI다. 내부적으로 claude-opus-4-6이 task decomposer로 동작하고, 분해된 태스크를 병렬 에이전트로 실행한다.

세션 1~3은 모두 0분짜리다. 실제 코드 변경 없이 task decomposer로서의 기능만 테스트했다. To-do 앱, REST API, 블로그 사이트 같은 전형적인 예시 프롬프트를 넣어봤다. JSON으로 역할과 태스크를 분해하는 게 잘 됐다.

세션 4에서 처음으로 실제 게임을 만들었다.

병렬 3명 → QA 1명 → 빌드 실패

dispatch 계획은 이렇게 나왔다.

1. game_designer      → 게임 메커닉 설계 문서
2. frontend_developer → Next.js + Canvas 클라이언트
3. backend_architect  → WebSocket 멀티플레이어 서버

3명이 동시에 시작했고, 완료 순서는 game_designer → backend_architect → frontend_developer였다. 마지막 에이전트가 완료되자마자 qa_engineer를 dispatch해서 테스트를 돌렸다. 92개 테스트 전부 통과.

근데 직접 실행해봤더니 포트 3001이 이전 프로세스에 점유되어 있었다. 에이전트들이 각자 서버를 실행해보면서 남긴 프로세스가 충돌한 것이다.

이런 충돌은 병렬 에이전트의 고질적인 문제다. 각 에이전트는 자기 태스크만 보고 전체 환경 상태를 모른다. 한 에이전트가 3001 포트를 열고 죽어도 포트는 살아 있다.

”원본 피카츄 게임이 아니잖아”

포트 문제를 해결하고 실행했을 때 사용자 반응이 왔다.

장난해? 리소스랑 게임의 느낌 나 원본 피카츄 게임이 아니잖아.
원본 피카츄 게임 찾아서 리소스 가져와 똑같이

에이전트가 만든 건 기능적으로는 피카츄 배구였다. 공 주고받고, 점수 나고, 멀티플레이어 동기화도 됐다. 근데 원본 게임의 물리 엔진과 스프라이트 애니메이션이 없었다. 캐릭터는 단색 도형이었고, 공의 포물선도 원본과 달랐다.

문제는 프롬프트에 있었다. “피카츄 배구 멀티로 만들어줘”는 원본 게임을 레퍼런스로 준 게 아니었다. 에이전트 입장에서는 피카츄 배구 장르의 게임을 새로 만들라는 요청이었다.

에이전트가 모르는 건 검색이든 코드 분석이든 명확한 레퍼런스가 있어야 한다. “원본 피카츄 게임”이라는 레퍼런스 없이 에이전트는 일반적인 배구 게임을 만들 수밖에 없다.

원본 소스 분석 → 물리 엔진 재작성

이후 흐름은 이렇게 됐다.

원본 피카츄 배구 소스([email protected]:jee599/pikachu.git)를 워크스페이스로 옮기고, 에이전트 2명을 다시 dispatch했다. Rewrite server - original physics, Rewrite client - sprites + physics.

원본 코드에서 분석해야 할 게 꽤 있었다. 공의 초기 y 좌표, 점프 상태에서 다이빙 불가 조건, 8방향 스파이크 로직, 엔터키와 방향키 동시 입력 처리. 에이전트가 원본 코드를 직접 읽고 재구현했다.

Bash 84번 중 상당수는 이 분석 단계에서 나왔다. Read 48번도 원본 소스 파일들을 읽는 데 대부분 쓰였다.

그 다음에는 60프레임 설정, 공중 다이빙 버그 수정, SSR 하이드레이션 에러 대응, 이펙트 잔상 제거가 이어졌다. 각각 작은 수정이었지만 한 번에 하나씩 고쳤다.

// 수정 전: 공중에서도 다이빙 가능
if (input.dive) { /* 다이빙 로직 */ }

// 수정 후: 지상에서만 다이빙
if (input.dive && player.onGround) { /* 다이빙 로직 */ }

197번 tool call의 분포

Bash(84), Read(48), Edit(36), Write(17), Agent(12)

Bash가 가장 많다. 빌드 확인, 포트 정리, 타입체크, 서버 실행 등 환경 조작이 대부분이었다. Read 48번은 원본 소스 분석에 집중됐다. Edit 36번은 물리 엔진과 렌더러 수정. Write 17번은 새 파일 생성.

Agent 12번이 핵심이다. 에이전트를 dispatch하고 완료를 기다리고, 결과를 받아서 다음 에이전트를 결정하는 흐름이 이 숫자에 담겨 있다. 초기 병렬 4명(game_designer, frontend_developer, backend_architect, qa_engineer) + 리라이트 2명 + 분석 1명 + 배포 설정 1명으로 총 12번이 됐다.

병렬 에이전트가 유효한 시나리오와 아닌 시나리오

이번 작업에서 병렬 dispatch가 가장 효과적이었던 건 초기 구현 단계였다. 게임 디자인 문서, 프론트엔드 클라이언트, 백엔드 서버를 동시에 만드는 건 서로 독립적이어서 병렬이 자연스러웠다.

반면 물리 엔진 수정이나 버그 픽스는 순차 작업이었다. 한 버그를 고치고 나서 다음 버그가 무엇인지 확인해야 했다. 이 단계에서는 병렬보다 단일 에이전트가 더 적합했다.

도메인 지식이 필요한 작업 — 원본 피카츄 물리 엔진처럼 — 은 레퍼런스를 명시적으로 줘야 에이전트가 제대로 동작한다. 프롬프트가 모호하면 에이전트는 일반적인 해석으로 채운다.

에이전트한테 “원본처럼”은 레퍼런스를 주지 않은 것과 같다. 원본 코드나 명세를 직접 줘야 한다.