14장. 0주차: 아이디어를 PRD로 바꾸기
아이디어는 대개 아주 착한 얼굴로 찾아온다. "이 기능 하나만 있으면 되겠는데?"라고 속삭인다. 그런데 그 말을 곧이곧대로 믿으면 일주일 뒤엔 결제, 알림, 권한, 관리자 페이지, 분석 대시보드까지 달린 작은 괴물이 되어 있다. 솔로 빌더에게 0주차가 중요한 이유가 여기에 있다. 만들기 전에 줄여야 한다. 그리고 줄이려면 머릿속 생각을 문서로 꺼내야 한다.
이 장의 핵심은 단순하다. 혼자 만드는 제품일수록 무엇을 만들지보다 무엇을 안 만들지를 먼저 결정해야 한다. 그 결정을 남기는 가장 실용적인 형식이 PRD다. PRD는 거창한 대기업 문서가 아니다. 당신과 Claude Code가 같은 지도를 보게 만드는 작업 지시서이자, 범위 폭주를 막는 안전장치다.1
![[5부] 0주차: 아이디어를 PRD로 바꾸기](https://images.tilnote.io/pages/e7317cd6-e85b-4d36-830f-daf3a25adafb.webp)
아이디어는 PRD가 되기 전까지는 아직 제품이 아니다
머릿속 아이디어는 언제나 더 똑똑해 보인다. 이유는 간단하다. 빈칸이 많기 때문이다. 로그인은 "당연히 되겠지", 결제 예외는 "나중에 생각하지 뭐", 운영은 "사용자 오면 행복한 고민"이라고 넘겨버린다. 하지만 AI 에이전트와 함께 개발을 시작하는 순간, 그 빈칸은 곧바로 비용으로 바뀐다. 에이전트는 빈칸을 싫어해서 무엇이든 채우려 하고, 그 과정에서 당신이 원하지 않던 기능이나 구조까지 만들어 버릴 수 있다.
그래서 PRD의 첫 번째 역할은 화려한 기획이 아니라 빈칸 제거다. 무엇을 풀 문제로 볼지, 누가 쓸지, 성공은 무엇인지, 어디까지가 MVP인지, 그리고 무엇은 이번 릴리스에서 하지 않을지를 적는다. 이 문서가 있어야 인간과 AI가 같은 기준으로 판단할 수 있다.16
특히 솔로 빌더에게 PRD는 팀 정렬 문서라기보다 미래의 나를 위한 브레이크에 가깝다. 오늘의 나는 의욕이 넘치고, 내일의 나는 피곤하며, 일주일 뒤의 나는 방향을 잃는다. PRD는 그 셋이 싸우지 않게 해 준다.
14.1 PRD를 Claude Code와 함께 쓰기
Claude Code와 PRD를 쓸 때 중요한 점은 "초안을 예쁘게 뽑는 것"이 아니다. 질문을 잘 받는 것이다. 좋은 PRD 세션은 AI가 바로 정답을 말하는 세션이 아니라, 빠진 맥락을 되묻는 세션이다. 구현 전에 요구사항을 묻고, 제약을 확인하고, 누락된 예외를 드러내는 쪽이 훨씬 낫다.2
실전에서는 먼저 아이디어를 한 문장으로 던지지 말고, 아래 네 가지를 함께 준다.
누구를 위한 제품인가
어떤 문제를 가장 먼저 해결하는가
이번 MVP에서 절대 필요한 기능은 무엇인가
이번에는 하지 않을 기능은 무엇인가
여기에 시간, 예산, 운영 가능 시간 같은 현실 제약까지 붙이면 더 좋다. 예를 들어 "평일 밤 1시간, 주말 반나절만 투입 가능", "고객지원은 이메일만 가능", "서버비 월 20만 원 이하" 같은 조건은 생각보다 중요하다. 기능의 난이도보다 운영 난이도를 미리 드러내기 때문이다.
Claude Code에게는 이렇게 요청하면 좋다.
당신은 시니어 PM이자 솔로 빌더 코치다. 아래 아이디어를 바탕으로 PRD 초안을 쓰되, 먼저 빠진 맥락을 질문해 달라. 기능을 늘리기보다 MVP 범위를 줄이는 방향으로 제안하고, 각 항목을 확정된 결정과 검증이 필요한 가설로 나눠 달라.
이 한 줄의 효과가 크다. AI가 문장을 번지르르하게 꾸미는 대신, 결정과 가설을 분리하기 시작하기 때문이다. 이 구분은 매우 중요하다. 좋은 PRD는 "이건 정했다"와 "이건 아직 모른다"를 섞어 쓰지 않는다.3 섞는 순간 일정이 흔들린다.
예를 들어 이런 식이다.
결정: 로그인은 구글 소셜 로그인만 제공한다.
가설: 초기 사용자는 이메일 로그인보다 소셜 로그인을 더 선호할 것이다.
결정: 첫 결제 수단은 카드만 지원한다.
가설: 환불 요청은 월 5건 이하로 운영 가능할 것이다.
이렇게 써 두면 개발 중에 "당연히 이메일 로그인도 있어야 하지 않나?" 같은 말이 튀어나와도 쉽게 흔들리지 않는다. 반대로 가설은 나중에 검증하고 바꿀 수 있다. 문서가 단단해지면서도 유연해지는 이유다.
솔로 빌더용 PRD는 길이보다 밀도가 중요하다
혼자 만드는 제품의 PRD는 20페이지짜리 논문일 필요가 없다. 오히려 너무 길면 AI도 사람도 길을 잃는다. 짧아도 아래 뼈대는 꼭 있어야 한다.
문제 정의: 지금 사용자가 겪는 불편은 무엇인가
타깃 사용자: 누가 가장 먼저 돈을 내거나 자주 쓸 사람인가
핵심 시나리오: 사용자가 처음 와서 가치를 느끼는 가장 짧은 경로는 무엇인가
MVP 범위: 이번 릴리스에 포함할 것
비목표: 이번 릴리스에서 의도적으로 제외할 것
성공 지표: 무엇이 되면 "이 방향이 맞다"고 볼 것인가
정책과 예외: 권한, 결제, 취소, 실패 시 처리 방식
비기능 요구사항: 속도, 보안, 로그, 백업, 장애 대응 최소 기준
AI 기능이 조금이라도 들어가는 제품이라면 한 줄 더 필요하다. 모델이 틀릴 때 어떻게 보일지다. AI 제품은 일반 기능과 다르게 출력이 확률적이기 때문에, 정확도 목표나 실패 시 UX를 미리 적는 편이 안전하다.4 예를 들어 "요약 결과가 불확실할 경우 확신하는 척하지 말고 원문 확인을 유도한다" 같은 규칙이 여기에 들어간다.
PRD에서 가장 먼저 써야 하는 문장
솔로 빌더의 PRD에서 가장 값비싼 문장은 대개 이것이다.
이번 MVP에서는 하지 않는다.
많은 사람이 핵심 기능 목록부터 쓰지만, 혼자 만드는 제품은 비목표부터 써야 한다. 왜냐하면 제품은 만드는 순간 끝나는 게 아니라, 운영이 시작되기 때문이다. 기능 하나는 보통 네 개의 비용을 함께 데려온다.
개발 비용
테스트 비용
운영 비용
고객지원 비용
예를 들어 채팅 기능은 멋져 보이지만, 읽음 상태, 알림, 차단, 신고, 보관 정책, 모바일 푸시까지 줄줄이 따라온다. "메시지 입력창" 하나가 아니라 작은 도시 하나가 들어오는 셈이다. 솔로 빌더는 이런 기능을 PRD 단계에서 잘라야 한다.
범위를 자를 때는 이 질문이 유용하다.
이 기능이 없어도 사용자가 핵심 가치를 경험할 수 있는가?
이 기능이 들어오면 운영과 CS 부담이 급격히 늘어나는가?
이 기능은 돈을 벌기 전에 먼저 돈과 시간을 먹는가?
셋 중 둘 이상이 "그렇다"면, 일단 빼는 편이 낫다.
무엇을 안 만들지 정하는 법
솔로 빌더가 자주 빠지는 함정은 "사용자 입장에서 좋은 것"과 "지금 내가 운영 가능한 것"을 같은 층위에서 보는 것이다. 물론 사용자에게는 다 좋은 게 좋다. 다만 혼자 만드는 제품은 좋은 것의 총합이 아니라 유지 가능한 핵심 경험으로 이겨야 한다.
이때 유용한 필터가 있다. 나는 이것을 빌드-투-런 필터라고 부른다. 제품을 만들 수 있는가만 보지 말고, 혼자서 굴릴 수 있는가까지 함께 보자는 뜻이다.
첫째, 빌드 가능성이다. 지금 가진 기술과 도구로 2주 안에 첫 버전을 만들 수 있는가. 둘째, 운영 가능성이다. 장애, 문의, 환불, 데이터 정리, 권한 문제를 혼자 감당할 수 있는가. 셋째, 학습 가능성이다. 이 제품을 만드는 과정이 앞으로의 제품 개발에도 재사용되는가. 넷째, 수익 연결성이다. 이 기능이 실제 돈, 잔존, 혹은 강한 사용 습관과 연결되는가.
이 필터를 거치면 화려하지만 무거운 기능이 많이 탈락한다. 반대로 작고 투박해 보여도 문제를 바로 해결하는 기능은 살아남는다. 솔로 빌더의 MVP는 "작아서 부끄러운 제품"이 아니라, "작지만 돈과 피드백이 들어오는 제품"이어야 한다.
14.2 AutoDream으로 작업 분해하기
이제 PRD가 생겼다. 하지만 아직 코드를 칠 단계는 아니다. PRD는 방향이고, 작업은 아직 덩어리다. 여기서 필요한 것이 작업 분해다.
이 책에서는 PRD를 받아 기능, 단계, 할 일로 자동 분해하는 흐름을 편의상 AutoDream이라고 부르겠다. 이름은 약간 낭만적이지만, 실제로 하는 일은 아주 현실적이다. 막연한 아이디어를 "다음 2시간에 무엇을 해야 하는가"로 바꾸는 작업이다.
가장 안정적인 흐름은 단순하다. PRD → Plan → Todo다.2 먼저 PRD에서 비즈니스 요구와 범위를 정하고, 그다음 구현 계획으로 기술적 구조를 세우고, 마지막으로 하나씩 검증 가능한 작업 목록으로 쪼갠다. 이 순서를 거치면 에이전트도 덜 헤매고, 당신도 중간에 덜 흔들린다.12
여기서 중요한 팁 하나. 앞으로 나아가며 쪼개지 말고, 완료 상태에서 거꾸로 내려오라. 마일스톤 설계에서도 마찬가지지만, 작업 분해는 거꾸로 할 때 빠진 의존성이 잘 보인다.5 "출시하려면 무엇이 있어야 하지?"에서 시작하고, 다시 "그게 되려면 직전에 무엇이 있어야 하지?"를 묻는다.
예를 들어 구독 결제가 있는 간단한 SaaS를 만든다고 해 보자. 앞에서부터 생각하면 보통 랜딩 페이지, 대시보드, 설정 화면 같은 UI가 먼저 떠오른다. 그런데 뒤에서부터 생각하면 순서가 달라진다. 결제가 되려면 상품과 가격 정책이 있어야 하고, 그 전에 권한과 사용자 상태가 정의되어야 하며, 그 전에 어떤 사용자가 무료인지 유료인지 분류하는 데이터 모델이 있어야 한다. 뒤집어 보면 "예쁜 화면"보다 "상태 정의"가 먼저라는 사실이 드러난다.
좋은 작업 분해의 조건
좋은 Todo는 체크박스 수가 많은 문서가 아니다. 각 항목이 작고, 검증 가능하고, 의존성이 드러나 있어야 한다.
한 번에 끝낼 수 있는 크기여야 한다
완료 여부를 바로 확인할 수 있어야 한다
선행 작업이 무엇인지 보여야 한다
실패 시 어디서 막혔는지 알 수 있어야 한다
실전에서는 한 작업이 길어도 반나절을 넘기지 않는 편이 좋다. 하루 종일 걸리는 작업은 대개 두세 개로 더 쪼갤 수 있다. "인증 구현"은 너무 크다. "구글 OAuth 설정", "세션 저장", "로그인 성공 후 리다이렉트", "실패 시 에러 메시지 처리" 정도로 나눠야 한다.
Claude Code에게는 이렇게 시킬 수 있다.
이 PRD를 바탕으로 구현 계획을 먼저 만들고, 그다음 1~4시간 안에 완료 가능한 Todo로 분해해 달라. 각 Todo에는 선행 조건, 완료 기준, 테스트 방법을 붙여 달라.
이 프롬프트의 핵심은 세 가지다. 크기를 제한하고, 의존성을 묻고, 검증 방법을 붙이는 것이다. 그러면 "해야 할 일 목록"이 아니라 "실행 가능한 일 목록"이 나온다.
작업 분해에서 꼭 남겨야 할 것
많은 초안이 기능만 나열하고 끝난다. 하지만 솔로 빌더에게는 기능 작업만큼 중요한 항목이 두 가지 더 있다. 하나는 운영 작업, 다른 하나는 의사결정 작업이다.
운영 작업은 로그, 모니터링, 백업, 관리자 수동 처리 경로 같은 것이다. 의사결정 작업은 요금제 문구 확정, 환불 정책 선택, 초기 가격 테스트 방식 결정 같은 것이다. 이런 것들을 Todo에서 빼면 제품은 만들어져도 서비스는 굴러가지 않는다.
14.3 마일스톤 정의와 진행 관리
Todo가 생겼다고 곧바로 일정이 생기는 것은 아니다. 일정은 할 일 목록이 아니라 중간 승리의 구조가 있어야 생긴다. 그것이 마일스톤이다.
좋은 마일스톤은 날짜만 찍어 놓은 표지판이 아니다. 결과 중심 체크포인트다.5 "1주차: 개발 시작"은 마일스톤이 아니다. "구글 로그인 완료, 신규 사용자가 가입 후 첫 화면까지 도달 가능"은 마일스톤이다. 전자는 바빴다는 뜻이고, 후자는 전진했다는 뜻이다.
솔로 빌더에게 좋은 마일스톤은 보통 세 층으로 잡힌다.
제품 마일스톤: 사용자가 경험하는 결과
기술 마일스톤: 시스템이 확보해야 하는 기반
운영 마일스톤: 출시 후 버틸 최소 장치
예를 들면 이렇다. 제품 마일스톤은 "첫 사용자가 핵심 가치까지 3분 안에 도달한다", 기술 마일스톤은 "결제 후 권한 상태가 정확히 반영된다", 운영 마일스톤은 "에러 로그와 환불 요청을 수동으로 처리할 수 있다"처럼 잡는다. 이 세 층이 모두 있어야 혼자서도 제품을 계속 굴릴 수 있다.
0주차 마일스톤은 이렇게 잡아라
0주차의 목표는 코드를 많이 쓰는 것이 아니다. 잘못된 코드를 쓰지 않게 만드는 것이다. 그래서 0주차 마일스톤은 보통 아래 정도면 충분하다.
PRD v0.1 완료
비목표와 제외 범위 확정
핵심 사용자 시나리오 1개 확정
성공 지표 2~3개 설정
구현 계획과 1차 Todo 분해 완료
첫 2주 마일스톤 캘린더 배치
여기서 중요한 것은 균등하게 나누지 않는 것이다. 사람은 보통 "1주차 이거, 2주차 저거" 식으로 예쁘게 나누고 싶어 한다. 하지만 실제 프로젝트는 의존성 때문에 그렇게 흐르지 않는다. 거꾸로 설계하고, 실제 일정에 올려 보고, 다시 조정하는 편이 훨씬 현실적이다.5
예를 들어 출장, 본업 마감, 가족 일정이 있는 주간에는 야심 찬 마일스톤을 두면 안 된다. 마일스톤은 의지의 선언문이 아니라, 완료 가능한 약속이어야 한다.
진행률은 채팅이 아니라 문서에 남겨라
AI와 일하다 보면 착각이 생긴다. 대화가 길수록 많이 진척된 것처럼 느껴진다. 하지만 실제 진척은 채팅창이 아니라 문서와 코드에 남아야 한다. PRD 중심 워크플로우가 강한 이유도 여기에 있다. 계획, 결정, 진행 상황을 한 문서에 계속 반영하면 세션이 바뀌어도 맥락이 살아남는다.1
그래서 진행 관리는 이렇게 하는 편이 좋다.
완료된 작업은 PRD나 실행 문서에 즉시 반영한다
바뀐 정책은 채팅에만 두지 말고 문서로 승격한다
마일스톤이 밀리면 남은 계획을 다시 계산한다
2주에 한 번은 가설과 결정을 다시 분리해 본다
특히 일정이 밀렸을 때 중요한 것은 자책이 아니라 재보정이다. 마일스톤은 한 번 세우고 끝나는 것이 아니라, 현실에 맞게 계속 보정해야 한다.5 생각보다 오래 걸리는 기능이 나오면 범위를 줄이고, 우선순위를 바꾸고, 필요하면 한 섹션을 통째로 다음 버전으로 넘긴다. 솔로 빌더의 강점은 원래 빠른 개발이 아니라, 빠른 재결정이다.
실전용 미니 PRD 템플릿
처음부터 완벽하게 쓰려 하지 말고, 아래 정도로 시작하면 충분하다.
제품 한 줄 설명
누구의 어떤 문제를 가장 짧게 해결하는가.
타깃 사용자
가장 먼저 돈을 내거나 반복 사용할 가능성이 높은 한 종류의 사용자.
핵심 문제
현재 대안이 왜 불편한가. 사용자는 무엇 때문에 시간을 잃거나 스트레스를 받는가.
핵심 시나리오
사용자가 처음 와서 가치를 느끼는 가장 짧은 흐름. 가능하면 5단계 이내.
MVP 포함 범위
이번 릴리스에 반드시 들어갈 기능.
비목표
이번에는 의도적으로 제외할 기능.
성공 지표
활성 사용자, 전환율, 첫 가치 도달 시간, 재방문율 등 2~3개.
정책과 예외
권한, 결제, 환불, 실패 처리, 데이터 보존, 관리자 수동 개입 방식.
오픈 이슈
아직 확정하지 못한 가설과 검증 계획.
이 템플릿의 장점은 단순함이다. 여기에 Claude Code를 붙여 질문을 받으면 금세 두꺼워진다. 반대로 템플릿 없이 시작하면 자꾸 문장을 예쁘게 쓰는 데 시간을 쓰게 된다. 솔로 빌더에게 필요한 것은 문학상이 아니라 출시다.
0주차의 진짜 산출물
0주차가 끝났을 때 당신 손에 있어야 하는 것은 "좋은 아이디어"가 아니다. 다음 네 가지다.
빼야 할 기능까지 적힌 PRD
순서와 의존성이 드러난 계획
작게 쪼개진 Todo 목록
현실 일정에 올라간 첫 마일스톤
이 네 가지가 있으면 1주차부터는 Claude Code를 훨씬 강하게 활용할 수 있다. 반대로 이 네 가지 없이 바로 구현에 들어가면, 에이전트가 빨라질수록 당신의 시행착오도 빨라진다.
혼자 만드는 제품에서 가장 위험한 낭비는 코드 몇 줄 잘못 쓰는 일이 아니다. 나중에 운영할 수 없는 제품을 열심히 만드는 것이다. 그래서 0주차의 미덕은 열정이 아니라 절제다. 아이디어를 PRD로 바꾸는 일은 꿈을 작게 만드는 과정이 아니라, 혼자서도 끝까지 데려갈 수 있는 크기로 다듬는 과정이다.
작게 시작해도 괜찮다. 오히려 그 편이 오래 간다. 그리고 오래 가는 제품이 결국 살아남는다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.