AgentCrow 실전 투입: 539 tool call로 AI 뉴스 사이트 하루 만에 완성

23개 세션. tool call 900회 이상. 그중 세션 하나가 37시간 동안 539번 도구를 호출했다.

TL;DR AgentCrow 멀티에이전트 dispatch를 실전에 투입했다. 피카츄 배구 멀티플레이어 게임은 2시간 만에, AI 뉴스 사이트 SpoonAI는 하루 만에 골격이 완성됐다. 에이전트를 어떻게 쪼개고 병렬로 돌렸는지 기록해둔다.

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

이 한 줄이 전부였다.

프롬프트를 받자마자 AgentCrow가 4명을 dispatch했다. game_designer, frontend_developer, backend_architect, qa_engineer. 처음 3명은 동시에 시작했다. 디자인 문서, Next.js 클라이언트, WebSocket 서버를 각자 병렬로 만들었다. 3명이 끝나면 qa_engineer가 테스트를 작성한다.

결과는 1시간 53분. tool call 197번. 빌드 성공, 타입체크 통과, 테스트 92개 all pass.

근데 사용자 반응이 “장난해?”였다.

리소스가 원본 피카츄 게임이랑 달랐다. 스프라이트도 없고, 점프 + 다이빙 로직도 빠졌고, 8방향 스파이크도 없었다. 에이전트들이 각자 만든 걸 붙여놓으니 일단 돌아가는 물건이 나왔지만, “피카츄 배구”는 아니었다.

두 번째 라운드에서는 에이전트에게 원본 소스를 직접 찾아서 물리 엔진과 스프라이트를 역공학하도록 지시했다. 공 초기 y좌표, 점프 상태에서 다이빙 비활성화, 엔터 + 방향키 동시 입력 스파이크 로직. 원본 코드에 있던 구체적 수치까지 복원했다.

여기서 배운 건 하나다. “피카츄 배구 만들어줘”는 너무 추상적이다. “원본 pikachu-volleyball 소스에서 물리 로직을 찾아서 동일하게 구현해줘”가 맞는 프롬프트다. 결과물의 품질은 프롬프트의 구체성에 비례한다.

기획서 하나를 코드로 번역하는 데 37시간

SpoonAI는 AI 뉴스 자동 수집 → 이메일 뉴스레터 → 웹사이트 플랫폼이다. 기획서가 이미 있었다. Phase 1~3까지 스펙이 문서로 정리되어 있었고, 코드는 한 줄도 없는 상태였다.

세션 6은 여기서 시작했다. 37시간 13분, tool call 539번. Write 84번, Bash 242번, Read 74번, Edit 49번.

에이전트가 코드를 쓰기 전에 먼저 디렉토리를 만들고, 설정 파일을 잡고, 컴포넌트를 병렬로 생성했다. 페이지 파일들도 동시에. 테스트 콘텐츠 3개도 자동으로 채워넣었다.

생성된 파일만 60개 이상. app/, components/, lib/, content/ 전체 구조가 한 세션에 만들어졌다.

물론 37시간 동안 순탄하지만은 않았다. 사용자가 디자인을 계속 바꿨다. “전체적으로 트랜디하게”, “이미지 안 나오는 거 절대 안 돼”, “로고 이걸로 써줘”. 매번 에이전트 3명을 새로 dispatch했다. UI/UX 디자인 전문가, 프론트엔드 구현, 타이포그래피+컬러 전문가. 3명이 동시에 리디자인을 진행하고, 빌드 성공 여부를 검증한다.

SpoonAI 세션에서 AgentCrow가 dispatch한 에이전트만 10회 이상이다. 각 dispatch마다 독립적인 작업을 병렬로 처리했고, 파일 수정이 겹치는 경우에만 순차적으로 돌렸다.

stuck 세션이 3개 나왔다

취소선 버그 수정 세션이 특히 황당했다.

remark-gfm이 한국어 범위 표현 2~3년, ~32억의 ~를 strikethrough로 처리하는 문제였다. 세션 10에서 에이전트 3명을 dispatch해서 lib/content.ts 수정과 마크다운 파일 틸드 치환을 병렬로 진행했다. 배포까지 완료했다.

근데 세션이 stuck됐다. 배포가 됐는지 안 됐는지 불분명한 상태. 세션 11에서 “이전 세션이 stuck 상태라서 새로 시작”으로 다시 시작했다. 세션 12에서 또 한 번. 같은 작업을 3개 세션에 걸쳐 반복했다.

도구 사용 수를 보면 세션 10이 Bash 11 + Agent 3, 세션 11이 Bash 17 + Edit 5, 세션 12가 Bash 19 + Edit 5. 거의 동일한 패턴이다.

이 삽질에서 얻은 교훈은 하나다. stuck 세션 재시작 시 프롬프트에 “현재 상태”를 명시적으로 적어야 한다. “이미 singleTilde: false를 추가했을 수 있으니 먼저 현재 파일 상태를 확인해”처럼. 에이전트가 이미 완료된 작업을 다시 반복하는 낭비를 막는다.

원인은 remark-gfm v4의 기본값이었다. singleTilde: true가 기본이라 한국어에서 자주 쓰는 ~ 범위 표현 두 개가 서로 페어를 이루면 그 사이 텍스트 전체에 strikethrough가 걸린다. lib/content.ts에서 remarkGfm({ singleTilde: false })로 수정하고, 기존 마크다운 파일의 A~B 패턴을 en-dash A–B로 전부 치환했다. 스킬 파일에도 규칙을 추가해서 앞으로 생성되는 글에서는 ~를 쓰지 않도록 막았다.

Vercel 자동 배포를 껐다

git push마다 Vercel이 자동 빌드를 시도하고 에러 이메일을 보내고 있었다.

원인은 연결된 계정 불일치였다. Vercel 대시보드에 연결된 계정과 실제 push 계정이 달라서 자동 빌드가 구조적으로 실패할 수밖에 없었다. 실제 배포는 vercel build --prod && vercel deploy --prebuilt --prod --archive=tgz 방식으로만 성공했다.

해결책은 자동 배포를 끄는 거였다.

{
  "git": {
    "deploymentEnabled": false
  }
}

vercel.json에 한 줄. 이후로 에러 이메일이 오지 않는다. push 트리거 자동 배포를 쓰고 싶었지만, 계정 설정이 꼬여 있으면 오히려 노이즈만 생긴다. prebuilt 방식이 느리더라도 확실하다.

에이전트 병렬 dispatch가 유효한 조건

이번 세션들을 통해 패턴이 명확해졌다.

효과적인 경우는 파일 수정이 겹치지 않는 독립 작업이다. “서버 코드 수정”과 “클라이언트 UI 수정”은 완전히 다른 파일이므로 병렬로 돌려도 충돌이 없다. SpoonAI에서 타이포그래피 에이전트와 레이아웃 에이전트를 동시에 돌린 것도 마찬가지다.

효과적이지 않은 경우는 동일한 파일을 수정하는 작업이다. lib/content.ts 한 파일을 두 에이전트가 동시에 수정하면 나중에 실행되는 쪽이 이전 변경을 덮어쓴다.

37시간 세션이 생산적이었던 이유는 대부분의 작업이 파일 단위로 독립적이었기 때문이다. Next.js 라우팅, 컴포넌트 구현, 콘텐츠 생성이 서로 다른 파일에서 일어났다.

에이전트를 병렬로 돌리는 건 결국 파일 수정 범위를 어떻게 나누느냐의 문제다. 범위가 겹치지 않으면 병렬이 이득이고, 겹치면 순차가 답이다.