AI Native PM 워크플로우가 5단계로 굳은 자리

도구를 또 하나 들이는 일이 사람을 빠르게 만들지 않는다. 그 도구를 어디에 어떻게 끼워 넣을지가 그어져 있어야 빨라진다. 첫 도구를 들였을 때의 ROI는 한참 양수다. 그러나 다섯 번째, 열 번째 도구는 그 자체로는 별 차이를 만들지 않는다. 도구가 평준화된 자리에서 차이는 다른 곳에서 벌어진다. 그 자리가 워크플로우다.

자기 작업장이 어떻게 굳어 가고 있는지를 한 번 정리해 두는 일은 그래서 중요하다. 이 글은 omc(oh-my-claudecode)와 gstack을 합쳐 5단계 파이프라인으로 굳어 가는 자리를 본다. Framing → Planning → Build → Verify → Ship & Operate. 이 5단계가 어떤 도구로 어떤 흐름을 만드는지, 빠뜨리기 쉬운 자리는 어디인지를 한 번 직접 그려본다.

처음 메모에는 framing부터 build까지만 있었다. verify, ship, operate 세 자리가 비어 있었다. 그 자리가 워크플로우의 자산이 누적되는 자리다. 그래서 빠진 자리를 채우는 일이 이 글의 후반이다.

도구가 무료가 된 시대에 워크플로우가 자산이다

도구의 비용이 0에 가까워졌다는 진단은 새로운 표현이 아니다. 새로운 자리에 있는 것은 그 다음의 산수다. 똑같은 도구를 누구나 들일 수 있다는 것은 들이는 자체가 차이를 만들지 않는다는 뜻이다. 작년의 새 도구를 한 발 빨리 잡는 것이 잠깐의 격차를 만들었지만, 한 분기 안에 같은 자리에 모두가 도착한다.

그 시점에 차이가 어디서 벌어지는가. 도구를 어떻게 묶어 두는가, 어떤 순서로 흐르게 하는가, 어디서 멈추고 어디서 다시 시작하는가의 자리다. 이 자리는 도구 대신 자기 자신이 만들어 두는 자리다. 자기 작업이 어떤 단계로 분리되어 있고, 각 단계의 입출력이 무엇이고, 단계 사이에 어떤 검증이 들어가는지가 머릿속이 아니라 도구 호출의 순서로 굳어 있어야 한다. 그게 워크플로우다.

omc와 gstack은 이 굳히기를 빠르게 만드는 두 묶음이다. omc는 에이전트와 스킬과 훅의 묶음이고, gstack은 그 위에 자기 도메인의 게이트와 리뷰를 자동 호출하는 묶음이다. 둘을 합치면 단일 도구로 풀던 일이 5단계 파이프라인으로 풀린다. 단계가 분리되어 있다는 사실 자체가 잘못된 자리에서 잘못된 자원을 쓰는 일을 막는다. 자기 작업장이 도구가 아니라 단계로 정의되어 있는가가 가장 큰 격차다.

Stage 0. Framing, 첫 자리에서 가장 비싸게 결정된다

워크플로우의 첫 단계는 무엇을 만들 것인가가 아니라 무엇을 만들지 말 것인가의 자리다. 이 자리에서 잘못 결정한 한 줄은 다음 모든 단계의 시간을 무의미하게 만든다. 0단계가 가장 비싸다는 인식이 다른 모든 단계의 자세를 결정한다.

이 자리에 두는 두 도구가 office-hours와 deep-interview다. /office-hours는 사업 타당성을 검증한다. 왜 만드는가, 누가 비용을 지불하는가, 같은 자리에 다른 누군가가 이미 도달해 있는가, 도달해 있다면 그 자리부터 출발할 수 있는가. 임원실 한 시간 회의에서 빠져나가는 질문들이 이 자리에 그대로 들어와 있다. /deep-interview는 기획 타당성을 검증한다. 어떤 사용자가, 어떤 상황에서, 어떤 결과를 원하는가. 표면 요청 뒤의 진짜 동기를 한 번에 한 질문씩 충분히 이해될 때까지 파고든다.

여기에 ultrathink와 /effort max와 deepsearch를 같이 켜는 이유가 있다. 첫 단계의 정확도가 다음 모든 단계의 ROI를 결정하기 때문이다. ultrathink는 추론의 깊이를 올리고, effort max는 모델 자원을 가장 비싼 자리로 끌어올리고, deepsearch는 코드베이스와 외부 자료의 폭을 늘린다. 다른 단계에서 아껴도 되는 자원을 이 한 단계에서 가장 무겁게 쓴다. 0단계의 1시간이 4단계의 1주를 절약하기 때문이다.

빠뜨리기 쉬운 자리가 있다. framing이 끝났다고 느끼는 시점이 진짜 끝이 아니라는 점이다. 모호함이 불편해지는 시점에 사람은 결정을 내리고 싶어진다. 그 충동이 가장 비싼 자리다. office-hours와 deep-interview를 한 번씩만 돌리는 게 아니라, 답이 명확해질 때까지 같은 도구를 다시 돌리는 자세가 0단계의 본질이다. 모호함이 다 풀릴 때까지 다음 단계로 넘어가지 않는 자제가 framing에서 가장 비싸다.

Stage 1. Planning, 4중주가 단일 관점의 결함을 잡는다

framing이 통과하면 무엇을 만들 것인지가 정해진다. 다음 자리는 그것을 어떻게 만들 것인가의 자리다. 이 자리의 첫 도구가 /ralplan이다. 정반합 계획 수립이라는 표현이 정확히 무슨 일을 하는가. 한 안을 던지고, 그 안의 가정 위에 반대 안을 만들고, 두 안의 충돌이 드러나는 자리에서 합으로 수렴한다. 한 안의 사각지대가 다른 안에서 보이고, 두 안 모두에서 살아남은 가정이 합의 뼈대가 된다.

ralplan이 끝나도 한 자리가 더 남는다. 한 사람의 시야로 만든 plan은 그 사람의 시야가 닿지 않는 자리에서 결함을 가진다. 그 결함을 잡는 도구가 /gstack-autoplan이다. 4개 리뷰를 순차로 자동 호출한다. /plan-ceo-review가 비즈니스 정합성과 우선순위와 ROI와 시장 시점을 본다. /plan-eng-review가 기술 부채와 복잡도와 의존성과 운영 비용을 본다. /plan-design-review가 UX 일관성과 정보 구조와 사용성을 본다. /plan-devex-review가 개발자 경험과 테스트 가능성과 디버깅 가능성을 본다.

네 관점이 한 회의실에 들어와도 누군가가 잠깐 침묵한다. 자동화는 그 침묵을 잡는다. 4명이 똑같은 비중으로 plan을 본다. 한 사람이 분기마다 짚는 자리를 자동화는 매번 짚는다. 단일 관점 plan은 단일 결함을 가진다는 사실이 4중주의 본질이다.

빠뜨리기 쉬운 자리가 있다. 4중주가 끝났을 때 4개 의견이 모두 한 방향이라면, 그건 plan이 좋아서가 아니라 4개 페르소나가 충분히 다르지 않게 정의되어 있다는 신호다. 가장 격렬하게 충돌하는 리뷰가 가장 좋은 리뷰다. 충돌이 없으면 페르소나의 정의를 다시 봐야 한다. 4중주가 4개의 다른 안을 던지지 않으면 4중주가 아니라 4겹 메아리다.

Stage 2. Build, 4개 실행 모드가 다른 도구다

plan이 통과하면 실행 단계로 들어간다. 이 자리에서 흔한 실수는 한 가지 실행 모드로 모든 작업을 처리하려는 자리다. 작업의 모양이 다르면 실행 모드도 달라야 한다. 4개 모드가 이 자리에 있다.

/autopilot은 자율 주행이다. 인터뷰 → 빌드 → 검증을 한 직선으로 끌고 간다. 사람의 개입을 최소로 가져가는 모드다. 명세가 충분히 정리된 작업, 한 사람의 손으로 끝까지 가는 게 자연스러운 작업에 어울린다. /ultrawork은 병렬 + 독립 모드다. 의존성이 없는 여러 작업을 동시에 진행한다. 한 PR 안의 여러 파일이 서로 영향을 주지 않을 때, 한 분기에 별 관련 없는 5개 기능을 동시에 끌고 가야 할 때 어울린다. 핵심은 독립이다.

/ralph는 검증 통과까지 반복이다. boulder를 한 번 굴리는 게 아니라 굴러 떨어질 때마다 다시 굴린다. 한 번에 통과하지 않을 작업, 통과 기준이 명확한 작업, 무한 루프 안에서 점진적으로 답이 좋아지는 작업에 어울린다. 알고리즘 튜닝, 평가 통과, 빌드 그린이 그 자리다. ralph의 본질은 자존심을 빼고 같은 자리에서 다시 치는 자세다. /team은 병렬 + 협업이다. 의존성이 있는 여러 작업이 서로 신호를 주고받으며 같이 진행된다. ultrawork이 독립이라면 team은 협업이다. 한 에이전트가 끝낸 결과물을 다른 에이전트가 받아서 이어가는 자리에서 작동한다.

빠뜨리기 쉬운 자리가 있다. 4개 모드는 서로 대체재가 아니라는 점이다. 한 작업의 한 단계는 ralph가, 다른 단계는 ultrawork이 어울리는 경우가 흔하다. 한 단계 안에서도 모드를 바꾸는 자제가 build의 효율을 결정한다. 모드의 선택이 도구의 선택보다 더 자주 잘못된다.

Stage 3. Verify, 작성과 검증은 다른 사람이 한다

build가 끝났다는 신호는 검증이 필요한 자리에 도착했다는 신호다. 이 단계는 처음 메모에 없었지만, 사실은 가장 자주 빠뜨리는 자리다. 빌드한 자리에서 본인이 곧장 검증으로 넘어가면 같은 시야의 결함이 그대로 통과한다. 자기 작성을 자기가 승인하지 않는다는 원칙이 verify의 첫 줄이다.

verify에는 다른 종류의 검증이 들어간다. 한 도구가 다 풀지 않는다. code-reviewer가 정적 검토를 본다. 가독성, SOLID, 스타일, 잠재 결함이 그 자리다. 사람이 PR 리뷰에서 짚는 자리를 자동화한다. test-engineer가 테스트 전략을 본다. 통합과 엔드투엔드 커버리지, 플레이크 보강, 빌드가 그린이지만 정작 안 잡히는 자리를 본다. verifier가 증거 기반 완료를 본다. 명세대로 작동하는가, 명세 자체가 충분한가, 통과의 정의가 명확한가의 자리다. security-reviewer가 OWASP Top 10과 시크릿 노출과 안전하지 않은 패턴을 본다. 다른 검증이 잡지 못하는 자리다.

이 4개를 한 묶음으로 두는 이유는 한 가지 검증이 모든 결함을 잡지 못하기 때문이다. 코드 리뷰가 통과해도 테스트가 비어 있을 수 있고, 테스트가 통과해도 명세가 잘못되어 있을 수 있고, 명세가 정확해도 시크릿이 노출되어 있을 수 있다. 검증의 종류가 다르면 잡는 결함의 종류도 다르다.

빠뜨리기 쉬운 자리가 있다. verify는 build의 일부가 아니라는 점이다. build가 끝나고 며칠 뒤에 다른 컨텍스트로 돌아와 보는 것이 verify의 가장 좋은 형태다. 같은 컨텍스트 안의 검증은 자기 위주로 작동한다. 다른 컨텍스트에서 다시 보면 같은 코드가 다른 결함을 드러낸다. 컨텍스트의 분리가 검증의 효율보다 더 큰 효과를 만든다.

Stage 4. Ship & Operate, 시간이 시스템을 자기 편으로 만든다

검증이 통과하면 ship이다. 그러나 ship으로 끝나지 않는다. ship 다음에 operate가 있고, operate가 다음 framing의 입력이 된다. 이 루프가 닫혀 있는가가 다음 사이클의 출발점을 결정한다.

ship에 들어가는 도구는 단순하다. atomic commit과 멀티 에이전트 리뷰와 staged rollout이다. git-master가 atomic commit과 rebase와 history 관리를 본다. 한 변화를 한 commit으로 묶는 자제가 history를 미래의 자기 자신에게 읽히게 만든다. /ultrareview가 멀티 에이전트 클라우드 리뷰를 돌린다. 사람의 PR 리뷰가 닿지 않는 폭을 자동 리뷰가 메운다. 변경의 영향 범위를 사람이 다 따라가지 못하는 자리에서 결함을 잡는다. 그 위에 staged rollout이 들어간다. 한 번에 100%가 아니라 1% → 10% → 100%로 가는 자제가 ship의 안전 마진이다.

operate는 더 큰 자리다. ship한 시스템이 시간이 갈수록 좋아지는가, 같은 자리에 머무르는가, 점점 나빠지는가의 자리다. 좋은 operate는 세 묶음으로 작동한다. worklog 자동 누적이 첫째다. Daily, Project, Task 계층이 매 commit마다 자동 갱신된다. 일주일 뒤 같은 자리로 돌아와도 무엇을 했는지가 그대로 남아 있다. 메모리 시스템이 둘째다. auto-memory와 knowledge와 의미 검색의 세 계층이 사용자 피드백, 도메인 보정, 검색 가능한 컨텍스트를 시간에 따라 누적한다. 다음 사이클의 framing이 이 누적 위에서 출발한다. 피드백 학습 루프가 셋째다. 사용자가 보정한 자리는 자동으로 knowledge에 들어가고, 누적되면 SKILL.md에 반영된다. 시스템이 사용자의 다음 보정을 미리 흡수한 상태로 돌아온다.

이 세 묶음의 공통점이 있다. 시간이 시스템을 자기 편으로 만든다는 점이다. operate가 좋으면 다음 framing이 더 정확해지고, 다음 plan이 더 빨라지고, 다음 build가 더 안전해진다. 한 사이클의 끝이 다음 사이클의 출발이다. 이 루프가 닫혀 있는가가 워크플로우 자산의 진짜 정의다. 빠뜨리기 쉬운 자리가 있다. operate는 ship의 마지막 단계가 아니라 다음 framing의 입력 단계라는 점이다. 이 시각이 없으면 operate는 의례에 그친다. 다음 사이클이 더 정확해지지 않는 operate는 좋은 operate가 아니다.

워크플로우의 정착이 다음 격차를 만든다

5단계가 한 사이클이라는 사실은 단순하다. Framing → Planning → Build → Verify → Ship & Operate. 그러나 이 단순함이 도달되기 전까지가 어렵다. 단계가 분리되어 있지 않은 자리에서 사람은 framing의 자원으로 build를 하고, build의 자원으로 verify를 하고, verify의 자원으로 operate를 한다. 매 사이클이 다른 비용 곡선을 그린다. 다음 사이클의 시작이 더 정확해지지 않는다.

5단계 파이프라인의 핵심은 단계가 분리되어 있다는 사실 그 자체다. 각 단계의 입출력이 명확하면 잘못된 자리에서 자원을 쓰는 일이 사라진다. ultrathink와 effort max는 framing에 쓰고, ralplan과 4중주는 planning에 쓰고, autopilot, ultrawork, ralph, team은 build에 쓰고, code-reviewer와 verifier와 security-reviewer는 verify에 쓰고, git-master와 ultrareview는 ship에 쓰고, worklog와 memory와 feedback은 operate에 쓴다. 자원의 종류가 단계와 매칭되어 있는가가 워크플로우의 본질이다.

도구가 무료가 된 시대에 다음 격차는 도구의 선택이 아니라 도구의 배치에서 벌어진다. 같은 도구를 들여도 5단계로 분리해서 쓰는 사람과 한 단계로 뭉쳐 쓰는 사람의 차이가 한 분기마다 누적된다. 그 누적이 한 해 뒤에 비교 가능한 격차가 된다. 도구를 또 하나 들이는 일은 그래서 별로 차이를 만들지 않는다. 자기 작업장의 5단계가 굳어 있는가가 다음 격차를 만든다.

이 글은 자기 작업장을 한 번 정리해 보는 자리에서 쓰였다. 5단계 중 어느 자리가 비어 있는지를 점검하는 일이 다음 사이클의 첫 출발이다. framing이 비어 있는가, planning에서 4중주가 빠져 있는가, build에서 한 모드만 쓰고 있는가, verify가 build와 같은 컨텍스트에서 일어나는가, operate가 다음 framing의 입력이 되지 않는가. 비어 있는 자리가 가장 큰 다음 격차의 자리다.