AI PM 워크플로우 6단계 셋업

문제 정의

1인 다섯 프로젝트, 완성 보고는 매번 실행에서 무너졌다

2026년 4월, 동시에 다섯 개가 넘는 프로젝트에 AI 코딩 워크플로우를 1인으로 적용하고 있었다. 포트폴리오 사이트, antiegg 백오피스, buildfeed.ai, business-ai-team, oh-my-hwclaude. 각 도메인의 컨텍스트는 다르고, 한 사람이 하루 안에 옮겨 다니며 의사결정을 내려야 했다. 외부에서 강제하는 일정도, 예산도, 합의해야 할 이해관계자도 없었다. 그 자유도가 그대로 책임이 되는 자리였다.

이러한 환경에서 가장 자주 깨지던 지점은 '완성됐다'는 에이전트의 보고였다. 체감상 여섯 번에 다섯 번은 그대로 동작하지 않았다. 원인은 도구의 부재가 아니었다. omc와 gstack은 이미 자주 쓰고 있던 도구였지만, 어떤 도구가 어느 stage에 박혀야 하는지가 명시화되지 않은 채 손으로 매번 오케스트레이션하고 있었다. 그 결과 플래닝이 얕았고 검증이 워크플로우에 박혀 있지 않았다. 같은 세션 안에서 자기가 쓴 코드를 자기가 OK하는 구조가 그대로 남아 있었기 때문이다. 매번 보완해도 그 보완은 휘발됐고 다음 세션에서 같은 페인이 같은 형태로 반복됐다.

가설 수립

경계를 머릿속이 아니라 stage 구조 자체에 박는다

물론 디폴트는 단순했다. 직접 손으로 오케스트레이션하고 매 상황마다 보완하면 된다. 4월 직전까지 그렇게 굴리고 있었다. 그러나 그 방식은 본인이 머릿속에서 굴리는 판단 분기가 매번 휘발된다는 한계를 품고 있었고, 같은 페인이 같은 형태로 반복되는 구조였다.

출발점은 이미 자주 쓰고 있던 두 모델이었다. 하나는 Garry Tan 기반의 gstack으로, /office-hours, /autoplan, /ship으로 이어지는 PM 파이프라인이 검증된 형태로 묶여 있다. 다른 하나는 oh-my-claudecode(omc)로, multi-agent 오케스트레이션과 /ralph, /autopilot, /ultrawork 같은 실행 모드가 트리거 키워드로 정착되어 있다. 두 모델을 따로따로 자주 호출하면서도, 6단계 파이프라인 안에 stage 단위로 박히지 않은 채 굴러가던 것이 정확한 상태였다. 그래서 같은 페인이 같은 세션에서 반복되었다.

가설의 본체는 두 모델을 6단계 stage 안에 묶어 워크플로우 구조 자체로 박는 일이었다. AI에게 줄 것과 본인이 쥐어야 할 것의 경계를 머릿속이 아니라 stage 구조에 명시화하면, 손으로 흉내 내던 분기가 자동으로 외부화된다. 이 구조가 자리잡으면 같은 페인이 같은 세션에서 반복되는 휘발 문제도 부수적으로 닫힌다고 판단했다. stage 자체가 메모리이자 인프라가 되기 때문이다.

솔루션 도출

6단계 stage 외부화, author와 reviewer 분리를 룰로 박는다

Stage 0 Framing은 사업 타당성(/office-hours)과 기획 타당성(/deep-interview) 이중 인터뷰로 잡는다. ultrathink, effort, deepsearch 게이지 셋을 모두 켠 상태에서 framing 깊이가 그 뒤 모든 stage의 비용을 정하도록 만들었다. Stage 1 Planning은 /ralplan의 정반합 수렴 위에 /gstack-autoplan으로 CEO·Eng·Design·DevEx 4중주 리뷰를 통과시킨다. Stage 2 Build는 단일 모드가 아니다. 자율(/autopilot), 병렬 독립(/ultrawork), 검증 통과까지 반복(/ralph), 병렬 협업(/team) 네 가지 중에서 태스크 성격으로 분기시킨다.

Stage 3 Validation은 author와 reviewer가 같은 세션에 절대 합쳐지지 않는 룰을 강제한다. /review와 code-reviewer가 second-opinion으로 분리되고, 브라우저 동작은 /qa, 보안은 /cso와 security-reviewer, 코드 디테일은 /codex, 완료 증거는 verifier가 각각 담당한다. Stage 4 Deploy는 /ship을 표준으로 두고 /canary와 /land-and-deploy를 위험도로 분기시킨다. Stage 5 Ops는 /document-release, /learn, /retro, /investigate, /skillify, /worklog로 한 사이클의 학습이 다음 사이클의 인프라가 되도록 닫는다.

이 구조에서 결정적이었던 것은 한 가지 발견이 아니라 네 가지가 함께 작동한 효과였다. 같은 세션 자기 검증을 금지한 룰, Stage 0 이중 인터뷰가 그 뒤 모든 stage의 깊이를 결정한다는 발견, /ralph의 검증 통과까지 반복 패턴이 완성도 분포를 좁힌다는 사실, build 모드를 태스크 성격으로 분기시킨 효과. 이 네 가지가 stage 구조의 진짜 골격이 되었다.

결과 & 배운 점

신뢰도가 회복됐고, 다음 격차는 워크플로우에서 벌어진다

이 셋업이 4월부터 5월에 걸쳐 6단계로 정착되면서, '완성됐다'는 에이전트 보고가 거의 매번 실행에서 무너지던 환경이 검증 게이트 통과를 거친 것만 done으로 인정되는 구조로 전환됐다. 신뢰도가 회복되었다는 표현이 가장 정확하다. 동시에 다섯 개 이상의 프로젝트를 1인으로 굴리면서도 의사결정과 방향에 더 많은 시간을 쓸 수 있게 된 것은 plan과 검증이 stage로 외부화된 직접적인 결과다. 손으로 매번 휘발되던 분기가 도구에 위임된 만큼, 본인이 잡고 있어야 할 자리가 명확해졌다.

이 경험이 남긴 한 줄은 명확하다. 아직 바닐라 트랜스포머는 부족하다. 모델 자체의 베이스 케이퍼빌리티만으로는 1인 멀티 도메인 운영이 굴러가지 않는다. 차이를 만드는 것은 모델 위에 얹는 셋업과 워크플로우의 고도화다. 한 발 더 들어간 깨달음은 두 가지였다. 첫째, framing이 그 뒤 다섯 단계의 비용을 정한다는 점이다. Stage 0 이중 인터뷰의 깊이가 얕으면 어떤 자동화도 엉뚱한 자리에서 자동화된다. 둘째, author와 reviewer를 같은 세션에 두지 않는 룰이 모델 성능보다 큰 결정 변수였다는 점이다. 모델 교체는 단발성 효과지만, 검증 lane이 분리된 구조는 모델이 바뀌어도 그대로 작동한다. 이번 6단계는 종착점이 아니라 살아있는 인프라의 한 시점이고, 이 인식 위에서 셋업을 계속 진화시키는 것이 다음 자리로 가져갈 가장 정직한 자산이라고 본다.