몇 달 동안 저의 Claude Code 워크플로우는 이제 제가 '프롬프트 입력 후 기도하기 (prompt-and-pray)'라고 부르는 방식이었습니다. 기능을 설명하는 거대한 프롬프트를 작성하고, AI가 코드를 작성하는 것을 잠시 지켜보다가, 결국 AI가 잘못된 문제를 해결했다는 사실을 깨닫는 것이었습니다. 그러고 나면 이를 다시 수행하기 위해 토큰과 인내심을 들여 다시 비용을 지불해야 했습니다.

전환점은 문제가 모델에 있는 것이 아니라는 사실을 인정한 것이었습니다. 문제는 매우 빠른 실행자에게 모호한 사양 (specs)을 전달하는 저 자신에게 있었습니다. 모호한 티켓을 받은 주니어 개발자는 잘못된 것을 느리게 작성하지만, Claude는 초당 200 토큰의 속도로 잘못된 것을 작성합니다.

그래서 저는 프롬프트를 튜닝하는 것을 멈추고 대신 프로토콜 (protocol)을 구축했습니다. 이 포스트는 아무것도 설치하지 않더라도 마음껏 가져다 쓸 수 있는 전체 방법론입니다.

핵심적인 역전: AI가 당신을 인터뷰합니다

첫 번째 해결책은 인터뷰의 방향을 뒤집는 것이었습니다. 제가 기능을 설명하는 대신, AI가 저에게 질문을 던지게 하는 것입니다. 한 번에 하나씩 질문하며, 모호한 답변은 허용하지 않고, 범위 (scope)와 성공 기준 (success criteria)이 완벽해질 때까지 코드베이스에 실제로 존재하는 것과 대조하여 저의 가정을 검증합니다.

이것이 느리게 느껴질 수 있지만, 실제로는 정반대입니다. 20분간의 심문은 잘못된 구현 한 번보다 비용이 적게 듭니다. 또한, 이 인터뷰는 프롬프트가 결코 제공할 수 없는 것, 즉 우리가 무엇을 만들고 있으며 무엇을 명시적으로 만들지 '않을' 것인지에 대한 공유된 서면 이해를 바탕으로 끝납니다.

6단계, 4개의 인간 게이트 (human gates)

전체 프로토콜은 기능을 처음부터 끝까지 구동하는 단일 명령 (/adp)으로 실행됩니다:

단계	발생하는 일
0 · grill-me (심문하기)	범위(scope)가 완벽해질 때까지 AI가 당신을 인터뷰합니다. 관문(Gate): 당신이 범위를 승인해야 합니다.
...
중요한 설계 제약 사항은 다음과 같습니다: 흐름은 이 네 가지 관문(gates)에서 멈추며 명시적인 인간의 승인을 기다립니다. 인간이 계획을 확인하지 않은 상태에서는 그 어떤 것도 코드가 되지 않습니다. 이는 의도적으로 완전 자율 에이전트(fully-autonomous-agent) 트렌드와 반대되는 방향입니다. 현재 흥미로운 엔지니어링 문제는 인간을 루프에서 제거하는 것이 아니라, 루프 내의 어디에 위치시킬지를 결정하는 것이라고 생각합니다.

예상치 못하게 애착이 생긴 결과물: 살아있는 아키텍처 지도

모든 팀은 아키텍처 다이어그램을 한 번 그리고, Miro 보드에 고정해 둔 뒤, 그것이 부식되어 가는 것을 지켜봅니다. 이 프로토콜에서 지도를 다시 렌더링(re-rendering)하는 것은 단순한 의도가 아니라 하나의 '단계(phase)'입니다. 기능(feature)이 병합(merge)될 때마다 파일, 화면, 기술(skills), 하위 에이전트(subagents), MCP 서버, 훅(hooks)을 포함하는 대화형 HTML 지도가 리포지토리(repo) 자체에 다시 그려집니다. 노드를 클릭하면 해당 노드를 담당하는 파일들을 볼 수 있습니다.

이 지도는 신규 인원 온보딩(onboarding)을 포함하여 전체 시스템에서 가장 많이 사용되는 결과물이 되었습니다.

나를 놀라게 한 토큰 경제학 (token economics)

제가 의도하지 않았던 효과가 나타났습니다. 기술(skills)이 추론(reasoning) 과정을 담고 있기 때문에(인터뷰 스크립트, PRD 형식, 슬라이싱 컨벤션, QA 체크리스트 등이 모두 기록되어 있음), 구현 모델은 프로세스를 고민할 필요 없이 그 안에서 실행만 하면 됩니다. 실제로 이 덕분에 이전에는 높은 노력(high effort) 단계에서 Opus를 사용해야 했던 대부분의 기능들에 대해, 중간 정도의 노력(medium effort) 단계에서 Sonnet을 사용하고도 필적하는 결과를 얻을 수 있었습니다.

제 추정으로는 기능당 토큰 사용량이 최대 ~70%까지 줄어듭니다. 이 수치를 명확히 하자면, 이는 공식적인 벤치마크(benchmark)가 아니라 Sonnet-medium과 Opus-high를 비교한 제 개인적인 사용 경험에 기반한 추정치입니다. 더 큰 절감 효과는 눈에 잘 보이지 않는 곳에 있습니다. 구현 전에 기능이 명확히 정의되면, 기능을 두 번 만들 일이 없기 때문입니다.

이 글에서 한 가지만 기억하신다면 이것입니다: 작업(task)이 아니라, 추론(reasoning)의 내용이 얼마나 이미 작성되어 있는지에 따라 모델을 선택하세요. 진정한 불확실성(탐색, 사양 작성)이 있는 경우에는 비싼 모델을 사용하고, 이미 작성된 프로세스 내부의 실행(execution) 단계에서는 더 저렴한 모델을 사용하십시오.

가져다 쓰세요 (Steal it)

위의 방법론은 완성되어 있으며, 어떤 환경에서든 기본적인 기술만 있다면 구현할 수 있습니다. 패키지 버전을 원하신다면 다음과 같습니다:

• 무료 티어 (인터뷰 단계 + PRD 단계 + 컨벤션 파일)는 오픈 소스로 공개되어 있습니다: github.com/murilomn58/Claude-Spec-Driven-Fase-Zero. 네이티브로 설치하려면: /plugin marketplace add murilomn58/Claude-Spec-Driven-Fase-Zero를 입력한 후 /plugin install adp-fase-zero@adp를 실행하세요.
• 전체 프로토콜 (6개 단계 전체, 맵, 시크릿 훅)은 claudespecdriven.com.br에서 유료 플러그인으로 제공됩니다 (47 헤알, 약 9 달러).

솔직한 주의 사항을 하나 말씀드리자면: 저는 이것을 브라질 개발자들을 위해 먼저 만들었기 때문에, 사이트와 플러그인 콘텐츠는 포르투갈어로 되어 있습니다. 방법론은 언어에 구애받지 않으며, Claude는 사용자의 언어로 응답하면서도 포르투갈어(PT-BR) 기술을 잘 따릅니다. 하지만 이것이 결정적인 결격 사유라면, 무료 저장소(repo)와 이 글만으로도 자신만의 시스템을 구축하는 데 필요한 모든 것을 얻을 수 있습니다.

여러분의 루프(loop)에서 인간의 검토 단계(human gates)를 어디에 배치하시겠습니까? 이것이 제가 계속해서 되묻게 되는 설계 질문이며, 다른 분들의 답변을 진심으로 읽어보고 싶습니다.