작업 규모별 Claude Code 워크플로우는 어떻게 하시나요? (Plan Mode vs Superpowers vs GSD vs Matt Pocock)

Claude가 당신의 fixer 레포에서 어떻게 기여자로 활동하고 있는 건가요?

난 Superpowers를 써.

작은 버그는 바로 구현으로 넘어가, 계획할 필요도 없지.
모든 기능이나 큰 변경 사항은 계획을 다 세워: 스펙 계획/디자인 계획/구현 계획을 세운 뒤에야 구현을 시작해. 계획은 단계별로 진행하고, 각 단계가 끝날 때마다 코드 리뷰를 해. 마지막에 코드 리뷰를 두 번 더 하는데, 한 번은 일반적인 리뷰, 한 번은 컨텍스트 없이 진행해.

계획할 때는 내 머리를 쓰면서 에이전트가 답을 얻어야 할 부분에 대해 질문하고 브레인스토밍을 해.
보통 계획에는 Fable을 쓰고, 서브 에이전트 기반의 구현에는 DeepSeek을 써. Fable이나 Opus가 계획이 완벽하고, 따라 하기 쉽고, 모든 걸 갖췄으며 정확하다고 100% 확신할 때까지 계획을 끝내지 않아. 그래야 하위 모델이 실제로 결과물을 낼 수 있다고 믿을 수 있으니까.

완벽한 설정은 아니야. 아마 가장 저렴하거나 시간 효율적인 방법은 아닐 수도 있지만, 결과물을 신뢰할 수 있다는 점이 좋아. 코드는 탄탄하고 버그도 적어. 모델이 계획을 세우는 근거와 정보를 내가 직접 감독하니까 정확히 뭐가 만들어지는지 알 수 있거든.
문제가 생기는 경우는 거의 없고, 생기더라도 UI나 사소한 디테일 같은 거라 예상 가능한 수준이야.

운전석에 앉아 직접 제어하는 거라면 Matt 방식이 최고지!

그걸로 새로운 기능을 만들 때 어떻게 시작하는지 좀 더 자세히 알려줄 수 있어? 기능 하나 완성하는 데 시간이 얼마나 걸려? 나도 좋은 건 알겠는데 너무 오래 걸리는 것 같아서, 내가 뭘 잘못하고 있는 건가 싶어.

스택: TypeScript 모노레포(Next.js 및 몇 가지 서비스), 기존 코드베이스, 1인 개발.

"작은 기능 하나에 3일씩 걸리는" 문제를 해결한 방법은 작업의 크기가 아니라, 얼마나 판단력이 필요한지에 따라 작업을 나누는 것이었음.

1단계(비싼 모델, 낮은 볼륨): 브레인스토밍, 스펙, 작업 계획, 그리고 실패하는 테스트 하나 작성. 구현은 전혀 안 함. 이 부분은 Superpowers를 거의 그대로 사용함(브레인스토밍 -> 계획 작성 -> 코드 작성 전 실패하는 테스트 -> 문제 발생 시 체계적 디버깅). GSD나 Pocock의 스킬은 안 써봐서 공정하게 비교는 못 하겠음.

2단계(저렴한 모델, 높은 볼륨): 구현, 디버그 루프, 1차 리뷰. 이 단계에선 DeepSeek나 GLM을 쓰고, 사소하면 Sonnet을 씀.

이 둘 사이의 핸드오프는 맞춤형 프롬프트가 아니라 단일 파일임. docs/plans/<feature>.md 파일에 1단계에서 완료된 건 [x], 남은 건 [ ]로 표시함. 모든 [ ] 항목에는 건드려야 할 파일, 계약 조건, 수락 기준, 실패하는 테스트로 가는 경로, 그리고 범위 제한("X는 건드리지 마")이 포함됨. 실패하는 테스트는 커밋된 상태임. 그래서 2단계의 트리거는 에세이가 아니라 한 줄이면 됨.

안전장치: 저렴한 모델이 내놓은 결과물은 실패하는 테스트가 통과(green)하기 전까지는 절대 승인 안 함. 이게 비싼 모델을 맹목적인 디버깅에 낭비하지 않게 해주는 핵심임.

라우팅 규칙: 잘 정의되어 있고 검증 가능한 작업은 저렴한 모델로, 모호하거나 보안상 중요하거나 여러 파일과 아키텍처에 걸쳐 있는 작업은 비싼 모델로 보냄. 내가 넘겨주는 단위는 전체 기능이 아니라 단일 작업임.

질문 5번에 대해 말하자면, 내 중단 규칙은 리뷰 횟수가 아니라 테스트임. 일반적인 작업은 마지막에 리뷰 한 번, 보안이나 데이터 손실 위험이 있는 경로에만 컨텍스트 없는 리뷰를 한 번 더 함.

그만둔 것: 단계마다 코드 리뷰 하는 것. 버그가 아니라 스타일만 잡아내고 전체 작업 시간만 두 배로 늘렸음.

Superpowers에서 바꾼 점: 1단계에서만 실행함. 구현 단계는 비싼 모델에서 완전히 배제하고, 계획 파일만 단계를 넘나듦. 기본 설정은 하나의 모델이 전체 루프를 다 돌리는데, 그게 바로 네가 말한 프로세스 오버헤드의 원인임. 계획을 세우는 규율에는 돈을 쓸 가치가 있지만, 타이핑하는 데는 그럴 필요 없음.

200라인 미만 변경은 작업 난이도에 따라 Fable 5나 Opus 5 같은 단일 에이전트를 써.

200~2000라인 정도의 일반적인 기능은 먼저 Fable로 간단한 스펙이나 디자인을 작성하고, 내 오케스트레이터 앱인 Runner를 사용해서 Codex와 Claude로 페어 코딩 팀을 꾸려.

큰 아키텍처 변경이나 완전히 새로운 서비스는 먼저 Fable로 상세한 구현 계획을 짜고, 테스트 가능한 모듈별로 작업을 분리해. 내 오케스트레이터를 사용해 페어 코딩 팀으로 이 작업들을 실행한 다음, 계획을 세웠던 Fable 세션을 사용해 모듈들을 하나로 합쳐.

변경 사항이 200라인인지 어떻게 알아? 난 간단한 변경 요청인 줄 알았는데 인프라 설정이 하나도 안 되어 있어서 3천 라인이나 바뀐 적도 있거든.