VM0 개발 워크플로우: AI 에이전트를 팀처럼 관리하기

VM0 개발팀에서는 모든 개발자가 동시에 여러 개의 Claude Code 인스턴스와 함께 일합니다. 보통 여덟 개 이상이죠.

우리는 Claude Code를 실제 개발자와 똑같이 대합니다. (네, 우리 회사는 반쯤 농담으로 AI Colleagues Co! 라고 불립니다.)

그래서 VM0 개발 워크플로우의 설계 철학은 소프트웨어 엔지니어링의 고전적인 팀 관리 관행을 그대로 반영합니다.

우리는 작업 추적에 GitHub Issues를, 코드 리뷰와 병합에 Pull Requests를, 자동화 처리에 GitHub Actions를 사용합니다. 두 달에 걸쳐 이 구성은 우리가 404번의 릴리스를 내보내고 23만 줄이 넘는 코드를 작성하는 데 도움을 주었습니다.

이 글은 우리가 그것을 어떻게 작동 가능하게 만들었는지, 그리고 왜 핵심 문제는 결코 AI의 역량이 아니라 사람의 조율이었는지를 설명합니다.

실전 AI 기반 개발 워크플로우

많은 AI 에이전트를 병렬로 조율할 때, 병목은 모델이 코드를 쓸 수 있느냐가 아닙니다. 진짜 병목은 사람의 인지 부하입니다.

이 워크플로우는 14개의 슬래시 커맨드로 구성되며, Deep Dive, Issue Management, PR Management의 세 계층으로 정리됩니다.

먼저 제 워크플로우가 어떤 모습인지, 그리고 기능이 보통 어떻게 만들어지는지부터 살펴보겠습니다.

요구사항 정렬

사람이 Claude 세션을 열고 /deep-research로 시작합니다. Claude는 코드베이스, 문서, 관련 맥락에서 사실을 수집합니다. 우리는 그 결과를 논의하고, 실제로 어떤 문제를 풀고 있는지 정렬합니다.
솔루션 탐색

/deep-innovate를 사용해 Claude가 여러 가능한 방향을 트레이드오프와 함께 제안합니다. 우리는 논의하고, 범위를 좁히고, 방향을 선택합니다.
이슈 생성

/issue-create로 GitHub 이슈를 생성합니다. 사람이 이슈를 검토해 요구사항이 명확하게 담겼는지 확인합니다.
계획 수립과 승인

/issue-plan을 사용해 Claude가 작업을 이어가게 합니다. Claude는 전체 deep-dive 워크플로우를 자동으로 실행하고 결과를 이슈에 게시합니다. 다음을 포함합니다.
1. /deep-research의 조사 결과
2. /deep-innovate의 비교
3. /deep-plan의 구체적인 구현 계획
구현

승인 후, /issue-action으로 Claude가 계획을 구현하고, 테스트를 작성하고, PR을 열고, CI 통과를 보장합니다.
리뷰와 병합

/pr-review로 구조화된 리뷰를 진행한 뒤, 병합 전에 사람의 최종 리뷰를 합니다.

사람은 세 개의 체크포인트, 즉 요구사항, 방향, 수용에서 개입합니다. 그 외 모든 것은 자율적으로 진행됩니다.

사고방식의 전환: 당신은 AI 개발자 팀을 이끌고 있다

구조화된 워크플로우가 필요하다는 것을 깨달은 순간은, Claude 세션을 더 추가하는 것이 오히려 상황을 악화시켰을 때였습니다. 병렬로 실행하는 인스턴스가 많아질수록 각각이 무엇을 하고 있는지, 작업이 어떤 상태인지, 무엇이 이미 결정되었는지 추적하기가 더 어려워졌습니다.

외부 도구 없이는 그렇게 많은 Claude 인스턴스를 한꺼번에 관리할 수 없었습니다. 바로 그때 떠올랐습니다. 이것은 AI 문제가 아니라 관리 문제였습니다.

GitHub는 이미 소프트웨어 개발에서 협업을 위한 자연스러운 도구이므로, 새로운 것을 발명하는 대신 저는 Claude를 인간 동료와 똑같이 대하기 시작했습니다. 그렇게 하자 제 관리 역량이 단번에 확장되었습니다.

10년간의 프로젝트 및 팀 관리 경험이 마침내 이 새로운 맥락에서 의미를 갖게 되었습니다. Claude를 팀원으로, GitHub를 우리의 공유 소통 및 관리 공간으로 대하자, 전체 시스템이 다시 관리 가능해졌습니다.

좋은 팀 리더는 언제 개입하고 언제 물러설지를 압니다.

체크포인트	내가 하는 일	AI가 하는 일
요구사항	문제에 대해 정렬하고 범위를 명확히 함	코드베이스 조사, 맥락 수집
방향	조사 결과 검토, 접근 방식 승인	2~3가지 접근 방식 제안, 트레이드오프 평가
수용	PR 검토, 품질 확인	구현, 테스트, CI 수정

이것은 효과적인 소프트웨어 팀이 운영되는 방식을 그대로 반영합니다. 저는 개발자를 마이크로매니지하지 않고, 명확한 요구사항을 설정하고, 핵심 결정을 검토하고, 최종 산출물을 확인합니다. AI 에이전트를 관리할 때도 같은 원칙이 적용됩니다.

deep dive 흐름은 구조화된 느린 사고를 강제한다

deep dive 워크플로우는 구현 전에 신중한 사고를 강제합니다. 때때로 Claude가 막다른 길에 부딪힙니다. 그럴 때 우리는 Claude가 멈추고 생각하도록 강제한 다음, 함께 이야기로 풀어 갑니다. 세 단계로 이루어집니다.

단계	커맨드	목적	산출물
Research	/deep-research	사실 수집, 맥락 이해	research.md
Innovate	/deep-innovation	여러 접근 방식 탐색	innovate.md
Plan	/deep-plan	구체적인 단계 정의	plan.md

각 단계에는 엄격한 경계가 있습니다.

Research: 제안 금지
Innovate: 세부 사항 금지
Plan: 구현 금지

이러한 제약은 Claude가 곧장 코드로 뛰어드는 대신 느리고 신중한 추론을 하도록 강제합니다. 이것이 없으면 엣지 케이스와 아키텍처적 고려 사항이 종종 누락됩니다!

사용 예시

/deep-research investigate the authentication flow, I'm seeing token expiration issues

[Claude researches, analyzes 12 related files, finds 3 similar patterns]

/deep-innovate what are our options for fixing this?

[Claude presents 3 approaches with trade-offs, you pick one]

/issue-create let's track this fix

간단한 작업이라면 deep dive를 건너뛰고 바로 /issue-create로 가도 됩니다.

기술적 불확실성이 있는 복잡한 작업이라면, deep dive 단계가 구현을 시작하기 전에 당신과 Claude가 정렬되도록 돕습니다.

GitHub를 공유 메모리로 사용하라

대부분의 AI 도구는 컨텍스트를 일시적인 것으로 다룹니다. 세션이 끝나면 메모리가 사라집니다.

VM0는 GitHub를 지속적인 메모리로 사용합니다.

GitHub 기능	저장하는 것
Issue 본문	요구사항과 결정 사항
Issue 댓글	조사, 옵션, 계획
PR 댓글	리뷰와 요약
Labels	워크플로우 상태

이것은 또한 사람의 문제, 즉 컨텍스트 복구를 해결합니다.

제가 8개 이상의 Claude 인스턴스를 관리할 때, 작업이 완료되었다는 알림을 받습니다. 하지만 Claude의 대화만으로는 그것이 무엇을 하고 있었는지, 어떤 결정이 내려졌는지, 현재 상태가 무엇인지 재구성할 수 없습니다.

GitHub 이슈가 이를 해결합니다. 각 이슈는 다음을 보여줍니다.

원래의 요구사항
조사 결과 (무엇이 발견되었는지)
Innovation 단계 (어떤 옵션이 검토되었는지)
승인된 계획 (무엇이 구현될 것인지)

이 구조화된 형식은 리뷰를 효율적으로 만듭니다. 덕분에 저는 각 단계를 빠르게 훑어보고, 접근 방식을 이해하고, 원래 대화를 기억할 필요 없이 승인하거나 변경을 요청할 수 있습니다.

작업이 끝나면 채팅 창에서 무슨 일이 있었는지 기억할 필요가 없습니다. 이슈를 열면 구조화되어 기록된 전체 이야기를 볼 수 있습니다.

에이전트 간 인계

모든 컨텍스트가 GitHub에 살아 있기 때문에, 작업은 에이전트 사이를 매끄럽게 이동할 수 있습니다.

한 에이전트가 이슈나 PR을 생성하고
다른 에이전트가 나중에 /deep-research issue 123이나 /issue-plan 123 또는 /deep-research PR 124로 이어받습니다

긴 논의의 경우, /issue-compact가 모든 것을 깔끔한 이슈 본문으로 통합합니다. 이는 사람과 AI 모두에게 인계를 쉽게 만들어 줍니다.

워크플로우 패턴을 정리해 봅시다

지금까지의 내용을 바탕으로 몇 가지 실용적인 팁을 정리하겠습니다.

간단한 작업

/issue-create → /issue-plan → /issue-action → /pr-check-and-merge

요구사항이 명확하고 작업이 단순할 때 사용하세요.

복잡한 작업

/deep-research → discussion → /deep-innovate → discussion →
/issue-create → /issue-plan → /issue-action →
/pr-review → /pr-check

이것은 잘못된 접근 방식에 노력을 낭비하는 것을 방지합니다.

병렬 작업

사람이 완료된 체크포인트를 검토하는 동안 여러 에이전트가 동시에 일할 수 있습니다. 워크플로우가 가장 잘 확장되는 지점이 바로 여기입니다.

Agent 1: /issue-plan #123
Agent 2: /issue-plan #124
Agent 3: /pr-review #100
Agent 4: /deep-research new feature requirements

커맨드 레퍼런스

Deep dive 커맨드

커맨드	목적
`/deep-research`	정보 수집, 코드베이스 이해. 제안 금지.
`/deep-innovate`	2~3가지 접근 방식 탐색, 트레이드오프 평가. 코드 금지.
`/deep-plan`	구체적인 구현 단계 작성. 구현 금지.

Issue 커맨드

커맨드	목적
`/issue-create`	대화 맥락에서 이슈 생성
`/issue-bug`	재현 단계를 포함한 버그 리포트 생성
`/issue-feature`	요구사항에 초점을 맞춘 기능 요청 생성
`/issue-plan`	전체 deep-dive 워크플로우 실행, 결과를 이슈에 게시
`/issue-action`	사람의 승인 후 구현 이어가기
`/issue-compact`	인계를 위해 이슈 본문 + 댓글 통합

PR 커맨드

커맨드	목적
`/pr-check`	CI 파이프라인 모니터링, 자동 수정, 최대 3회 재시도
`/pr-review`	프로젝트 표준에 따라 커밋 단위로 PR 검토
`/pr-comment`	대화 논의를 PR 댓글로 요약

시작하기

단순하게 시작하세요: 첫 작업에는 /issue-create → /issue-plan → /issue-action을 사용하세요
복잡한 작업에는 deep dive를 추가하세요: 요구사항이 불명확하거나 기술적으로 복잡할 때는 /deep-research로 시작하세요
점진적으로 확장하세요: 리뷰 리듬에 익숙해질수록 Claude 인스턴스를 더 추가하세요
프로세스를 신뢰하세요: 체크포인트 사이에서는 Claude가 자율적으로 일하게 두세요

이 워크플로우는 점진적으로 도입하도록 설계되었습니다. 첫날부터 14개 커맨드를 모두 쓸 필요는 없습니다. 기본 이슈 흐름으로 시작한 다음, 자신감이 붙으면 deep dive 단계와 병렬 작업을 추가하세요.

확장 고려사항: 에이전트가 더 많아지면 어떻게 할 것인가

이 워크플로우는 10개 이상의 동시 Claude 인스턴스로 테스트되었습니다. 우리의 권장 사항입니다.

최대 10개 에이전트: 각각과 깊이 협업하기에 편안함
10개 초과: 권장하지 않음

제약 요인은 워크플로우가 아니라 사람의 주의력과 결정 품질입니다. 10개가 넘는 에이전트를 관리하면 리뷰 체크포인트에서 당신이 병목이 될 위험이 있고, 결정 품질이 떨어지기 시작합니다.

고전적인 "two pizza team" 원칙이 여기에 적용됩니다. 인간 팀의 규모를 제한하는 바로 그 제약이, 한 사람이 효과적으로 관리할 수 있는 AI 에이전트의 수도 제한합니다.

저는 현재 10개를 넘어서는 확장을 위해 8×8 이중 계층 팀 구조를 탐색하고 있지만, 아직 효과적인 실천 방법을 개발하지는 못했습니다. 구체적인 결과가 나오면 더 공유하겠습니다…

VM0 개발 워크플로우는 AI가 팀의 일원이 될 때 우리가 소프트웨어 개발을 바라보는 방식을 바꿉니다.

AI 에이전트를 도구가 아니라 팀원으로 대하면, 모든 것이 제자리에 맞아 들어갑니다. GitHub는 팀의 공유 메모리가 됩니다. 이슈는 작업 항목이 됩니다. PR은 산출물이 됩니다. 그리고 당신은 팀 리더가 되어, AI 팀이 구현을 처리하는 동안 아키텍처, 방향, 품질에 집중하게 됩니다.

그것이 우리가 두 달 만에 404번의 릴리스를 내보낸 방법입니다. 그리고 그것이 당신도 AI와 함께 자신의 개발을 확장할 수 있는 방법입니다.