에이전트 4명 병렬 투입, 피카츄 배구 멀티게임을 197 tool calls로 만든 과정

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

이 한 줄이 전부였다. agentochester는 이 프롬프트를 받아서 에이전트 4명을 병렬로 dispatch했다. 1시간 53분 뒤, 멀티플레이어 게임이 돌아가고 있었다.

TL;DR agentochester의 에이전트 dispatch 시스템을 실제 게임 개발에 써봤다. 병렬 에이전트는 빠르지만, “테스트 통과”와 “게임다운 느낌” 사이의 간극은 에이전트가 메울 수 없었다.

”피카츄 배구”라는 프롬프트 하나

agentochester는 사용자 프롬프트를 받으면 태스크를 분해하고 적합한 에이전트 역할로 나눠서 병렬 실행하는 CLI다. 내부적으로는 claude-opus-4-6이 task decomposer 역할을 맡는다.

“피카츄 배구 멀티로 만들어줘”가 들어오자, 분해 결과는 이랬다.

1. game_designer   — 게임 메커닉 설계 문서
2. frontend_developer — Next.js + Canvas 클라이언트
3. backend_architect  — WebSocket 멀티플레이어 서버
4. qa_engineer     — 테스트 (1~3 완료 후)

규칙은 간단하다. 파일 수정이 겹치지 않는 독립 작업은 병렬로 돌린다. game_designer, frontend_developer, backend_architect 세 명이 동시에 시작했다. qa_engineer는 세 명이 끝나고 나서 합류한다.

에이전트가 돌아가는 동안 터미널에는 task notification이 하나씩 올라왔다.

Agent "Game designer - mechanics" completed
Agent "Backend - WebSocket server" completed
Agent "Frontend - game client" completed

빌드 확인. 클라이언트 빌드 성공, 서버 타입체크 통과. 마지막으로 qa_engineer가 붙었다.

All 92 tests pass.

92개 테스트 통과, 그런데

결과물을 실제로 실행해봤다. 포트 3001이 이전 프로세스에 점유되어 있어서 정리부터 해야 했다. 그 뒤로 게임이 떴다.

사용자 반응: “장난해? 리소스랑 게임의 느낌 나 원본 피카츄 게임이 아니잖아. 원본 피카츄 게임 찾아서 리소스 가져와 똑같이.”

92개 테스트가 통과했다는 건 기능적으로는 문제없다는 뜻이다. 공이 날아가고, WebSocket으로 두 클라이언트가 연결되고, 점수가 올라간다. 근데 그게 전부였다. 피카츄 배구의 그 느낌—스프라이트, 물리 엔진, 타격감—은 없었다.

이게 에이전트 병렬 dispatch의 한계다. 속도와 병렬성은 있지만, “원본이 어떤 느낌인지”를 에이전트가 스스로 파악하진 못한다. 요구사항이 명확하지 않으면 기술적으로 맞는 것과 사용자가 원하는 것이 달라진다.

에이전트 2명이 다시 투입됐다.

1. Rewrite server - original physics
2. Rewrite client - sprites + physics

원본 피카츄 배구 소스코드를 분석해서 물리 엔진을 재구현하고, 스프라이트 기반 렌더러로 전면 교체했다. TypeScript strict mode 통과, 빌드 성공.

삽질의 본론

리소스 문제가 해결되고 나서 버그가 쏟아졌다.

SSR 하이드레이션 에러. Next.js에서 서버/클라이언트 렌더링 불일치가 발생했다. typeof window !== 'undefined' 분기가 게임 캔버스 초기화에 섞여 있던 게 문제였다. 게임 엔진을 클라이언트 전용으로 분리해서 해결했다.

60프레임 문제. 기본 구현이 requestAnimationFrame을 그냥 쓰다 보니 화면 주사율에 따라 프레임이 달라졌다. 타임스텝 고정 루프로 바꿨다.

다이빙 로직. 공중에서 다이빙이 되는 버그가 있었다. 원본 소스를 다시 확인하니 점프 상태가 아닐 때만 다이빙이 가능하도록 플래그로 처리하는 로직이 있었다. 그걸 빠뜨린 거였다.

스파이크 방향. “엔터랑 방향키 동시에 누르면 그쪽으로 스파이크”는 원본에서 8방향으로 구현되어 있었다. 입력 벡터를 받아서 방향을 계산하는 방식이었는데, 이것도 재구현했다.

원본 소스에서 로직 없어? 점프한 상태에서 다이빙이 안되고,
엔터랑 방향키 동시에 누르면 그쪽으로 스파이크 되게 하는 로직있잖아.
모든 소스 다 확인해서 제대로 구현해

이 프롬프트 한 번에 에이전트가 원본 소스 전체를 분석하고 누락된 로직을 찾아서 구현했다. 이 부분은 에이전트가 잘 했다. 소스 탐색 + 비교 + 재구현을 사람이 직접 하면 꽤 걸리는 작업이다.

배포까지

[email protected]:jee599/pikachu.git 이걸로 워크스페이스 하나 만들고
피카츄 배구 관련코드 모두 옮겨줘

코드를 별도 레포로 이전하면서 Railway 배포 설정도 추가했다. WS_URL을 환경변수로 분리하고, 서버는 Railway WebService, 클라이언트는 Railway Static으로 분리 배포.

“railway가 있어야 돼?” — Railway 계정이 있으면 railway up으로 끝난다.

이펙트가 경기장에 잔상으로 남는 문제, 파도 이펙트 제거, 타격 이펙트 지속 시간 조정까지 하고 나서 게임이 원본에 가까워졌다.

통계

이번 세션에서 사용한 도구 횟수다. Bash 84회가 제일 많은 건 서버 실행, 빌드 확인, 타입체크 같은 검증 작업이 반복됐기 때문이다. Agent는 12회—병렬 dispatch된 에이전트 수와 후속 재작업 에이전트들을 합친 숫자다.

총 tool calls: 197
Bash: 84 | Read: 48 | Edit: 36 | Write: 17 | Agent: 12
수정 파일: 10개 | 생성 파일: 12개
소요 시간: 1시간 53분

병렬 에이전트는 초기 scaffolding을 빠르게 뽑아내는 데 효과적이다. 근데 그 다음이 문제다. 첫 번째 결과물이 요구사항을 정확히 반영하지 못하면, 수정 사이클이 반복된다. 요구사항을 더 구체적으로 넣을수록 첫 번째 결과의 품질이 올라가고, 수정 횟수가 줄어든다.

“92개 테스트 통과”는 기능 명세의 정확도이지, 사용자 기대치의 정확도가 아니다.