말하면 AI가 만든다 플레이북
말하면 AI가 만든다(言出法随)는 Claude Code의 강력함 위에 세워졌습니다——도구가 충분히 강하기 때문에 묘사하기만 하면 됩니다, 직접 조작할 필요 없이. 고충실도는 AI 시대에 PM이 요구에 극속 대응하는 업무 원칙입니다——와이어프레임도, 긴 문서도 없이, 바로 실행 가능한 진짜를 만듭니다. 이 페이지에서는 「AI에게 말하는 4가지 뼈대」와 「고충실도 검증 체크리스트」를 드립니다. 더 정확히 말하고, 더 진짜를 만들고, 더 빠르게 반복하세요.
먼저 명확히: 서식을 채우라는 게 아닙니다
많은 방법론이 먼저 문서를 잔뜩 쓰라고 합니다: PRD, 스펙, 아키텍처, 태스크 목록……다 쓰고 나서야 시작할 수 있다고. 그건 doaipm이 아닙니다.
우리의 핵심은 말하면 AI가 만든다(言出法随): 원하는 것을 명확히 말하면 Claude Code가 바로 만들어 줍니다. 그러니 아래 네 가지 「템플릿」은 묵묵히 채워야 할 서식이 아니라, AI에게 말할 때 마음속에 있어야 할 뼈대입니다——심지어 AI에게 뼈대를 완성해 달라고 한 뒤 여러분이 확인만 해도 됩니다.
잘 만들었는지의 기준은 단 하나: 고충실도. 실행 가능하고, 클릭 가능하고, 내용이 진짜이고, 모든 상태가 있어야 합니다. 고충실도는 「마지막에 다듬는 것」이 아닙니다. AI 시대에 PM이 요구에 극속 대응하는 업무 방식 그 자체입니다——검증 가능한 진짜를 바로 만들어, 빠르게 써보고, 빠르게 고칩니다.
뼈대① 한 줄 스펙: 「무엇을 원하는지」 명확히 말하기
시작하기 전에 이 말을 먼저 명확히 하세요. 명확히 못 하겠으면 AI에게 반문하게 해서 명확해지면 시작하세요.
나는 【누구】를 위해, 【어떤 문제】를 해결하려 합니다. 만들어진 것으로 사용자가 할 수 있어야 하는 것은 【가장 핵심적인 한 가지 동작】입니다. 제대로 됐다는 기준은 【눈에 보이는 하나의 결과】입니다. 이번에는 하지 않을 것: 【비목표, 경계 설정】. 알고 있는 리스크/가정: 【……】.
이 내용을 Claude Code에 넘기고, 핵심 지시를 하나 추가하세요:
이 단계는 문서를 만드는 게 아니라 공감대를 만드는 겁니다. AI가 제대로 복술하고 핵심을 짚어서 질문했다면 정말 이해한 겁니다——이때 만들어지는 고충실도 프로토타입이 방향을 잃지 않습니다.
뼈대② 작은 단계 개발: 하나씩 말하고, 하나씩 실행해서 보여주기
한 번에 긴 요구사항을 쏟아내며 묵묵히 만들게 하지 마세요. 「각 단계가 바로 실행해서 볼 수 있는」 작은 단계로 쪼개세요.
어떻게 쪼개나요
AI에게 직접 맡기세요: 「이 요구사항을 몇 가지 작은 단계로 쪼개 주세요. 각 단계가 끝나면 브라우저에서 실행해서 결과를 볼 수 있도록. 목록으로 나열해 주세요, 하나씩 진행합니다.」
각 단계의 리듬
- 하나 말하기: 현재 이 작은 단계만 지시합니다.
- 실행해서 보여주기: 「완료하면 서비스를 시작해서 브라우저에서 볼 수 있게 해주세요.」
- 즉각 피드백: 맞으면 다음 단계; 틀리면 「여기가 틀렸어요, 이렇게 돼야 합니다……」
뼈대③ 프로젝트 취향: 한 번 말하면 항상 기억한다
매번 반복하고 싶지 않은 선호가 있습니다——기술 선택, 스타일, 제약, 레드라인. 한 번 말하고 프로젝트 메모리에 저장하면 자동으로 따릅니다.
이 프로젝트에서 항상 지켜주세요: · 기술 취향: 【예: Astro 사용, 무거운 프레임워크 도입 안 함, 정적 가능하면 정적으로】 · 스타일: 【예: 다크, 절제, 여백 많음, 문구는 사람 말투로】 · 제약: 【예: 유료/서드파티 추적 일절 불가; 모바일 우선】 · 레드라인: 【예: 프로덕션 데이터 건드리지 않음; 삭제/발행/결제 같은 동작은 먼저 물어봄】
AI에게 이 내용을 프로젝트의 「장기 약속」으로 저장하게 하세요(저장 위치는 AI가 압니다). 프로젝트에 「헌법」을 세우는 것과 같습니다——하지만 어떤 형식도 배울 필요 없이 그냥 사람 말투로 하면 됩니다.
⭐ 고충실도 검증 체크리스트（이 페이지에서 가장 중요한 블록）
「다 만들었다」는 게 「잘 만들었다」는 게 아닙니다. 고충실도 검수는 스크린샷 한 장을 보는 게 아니라, 진짜를 실행해서 항목별로 하나씩 확인하는 겁니다.
| 검사 항목 | 스스로에게 물어보기 |
|---|---|
| 진짜 내용 | 실제 내용과 데이터 구조인가요? Lorem ipsum, 「예시 텍스트」, 가짜 플레이스홀더가 없나요? |
| 네 가지 상태 | 로딩 중 / 빈 데이터 / 오류 / 성공, 네 가지 모두 만들었나요? 빈 상태와 오류 상태가 가장 자주 빠집니다. |
| 진짜 인터랙션 | 버튼이 진짜 클릭되고, 폼이 진짜 제출되고, 이동이 진짜 이동되나요? 아니면 그냥 「그렇게 보이기만」 하나요? |
| 핵심 경로 | 사용자의 가장 중요한 주요 플로우를 처음부터 끝까지 완주했나요? |
| 크로스 디바이스 | 모바일과 데스크톱 둘 다 확인했나요? 최소한 좁은 화면은 한 번 봤나요? |
| 까다로운 입력 | 의도적으로 틀린 값, 빈 값, 너무 긴 값, 이상한 특수문자 입력——무너지지 않나요? |
AI 기능을 만들었다면, 하나 더 추가하세요
AI 기능은 「한 번 성공」했다고 통과시키면 안 됩니다. 진짜이면서 까다로운 입력을 한 묶음 만들어 연속으로 테스트하고, 안정적인지, 헛소리하지는 않는지, 오류 시 안전망이 있는지 확인하세요. Claude Code에게 테스트 입력 10여 개를 만들어서 한 번 돌려 달라고 하세요——이것이 업계에서 말하는 「평가 루프(eval)」이고, PM도 할 수 있습니다.
뼈대④ 발견 질문: 명확하지 않을 때, 구조를 빌려오세요
「먼저 3–5가지 질문을 명확히 해달라」는데 무엇을 물어야 할지 모를 때, 고전적인 질문 구조를 빌려오세요(하나 선택해서 AI가 여러분에게 질문하게 하세요).
- JTBD (사용자가 이걸 무슨 일에 고용하나): 「사용자가 어떤 상황에서 이것으로 어떤 작업을 완료하고 싶을까요? 지금은 어떻게 임시방편으로 해결하고 있나요?」
- Opportunity Solution Tree (기회 해결 트리): 「우리가 달성하려는 결과는 무엇인가요? 사용자의 어떤 페인포인트 기회가 있나요? 각 기회에 어떤 솔루션이 있을 수 있나요?」
- Working Backwards (결과에서 역추적): 「이게 이미 완성되어 출시됐다고 가정하고, '사용자가 어떻게 칭찬할지'를 한 단락 써주세요——역으로 우리가 정확히 무엇을 만들어야 하는지 추론해 보세요.」
심화: 대형 프로젝트에만 필요합니다（소형 프로젝트는 무시하세요）
작은 프로토타입이라면 앞에 것만으로 충분합니다. 프로젝트가 커지고 대화가 길어질 때만 이 몇 가지가 필요합니다——그리고 여전히 「사람 말투」로 합니다.
대화가 너무 길어져서 AI가 점점 멍청해질 때
긴 대화에서 AI는 「잊어버립니다」. 이때 AI에게 먼저 연구하고, 계획을 나열하고, 여러분이 확인한 후 시작하게 하세요. 적절한 시점에 「지금까지의 결론을 작은 문서로 요약해서 저장해 두세요, 새 대화에서 이어서 합니다」라고 말하세요. 컨텍스트를 깨끗하게 유지하면 항상 스마트합니다.
할 일이 너무 많아서 병렬로 하고 싶을 때
복잡한 작업은 AI에게 여러 분신을 병렬로 일하게 할 수 있습니다(예: 하나는 자료 조사, 하나는 작성, 하나는 검토). 「이 일을 분리해서 병렬로 처리하고 마지막에 취합해 주세요」라고 말하기만 하면 됩니다.
프로토타입이 완성됐고 진짜로 나아갈 때
프로토타입에서 프로덕션으로 가는 건 또 다른 여정입니다: 실제 데이터, 보안, 성능, 「발행」 버튼을 누를 사람. 프로토타입은 과감하게, 프로덕션은 신중하게——되돌릴 수 없는 버튼(발행 / 삭제 / 결제)은 항상 사람이 누릅니다. 이 안전망은 프로덕션으로 갈수록 더 조여집니다.
