생각의 4단계와 PRD 작성

바이브 코딩에서 가장 흔한 실패는 코드가 아니라 '생각'에서 시작됩니다. '카페 예약 앱 만들어줘' 한 줄을 던지면, AI는 수백 가지 상상 가능한 카페 예약 앱 중 아무거나 하나를 만들어 냅니다. 내가 원한 그것이 아닐 확률이 훨씬 높죠.

그래서 첫 번째 손가락이 '사고'입니다. 손이 아니라 머리를 먼저 씁니다. 다행히 막연한 생각도 네 개의 질문으로 쪼개면 누구나 또렷하게 정리할 수 있습니다.

생각의 4단계

• ① 논리적(정의): 이건 대체 무엇인가? — 만들려는 것을 한 문장으로 정의합니다. (예: '내 독서 기록을 카드로 모아 보는 개인용 웹앱')
• ② 분석적(구조): 어떻게 동작하고, 무엇으로 짓나? — 주된 목적과 필요한 기술·구성을 짚습니다. (웹앱인가 앱인가, 로그인이 필요한가, 데이터를 저장하는가)
• ③ 계산적(설계): 규칙을 실제 화면·기능으로 어떻게 옮기나? — 어떤 기능을 어떤 순서로 보여줄지 정합니다. (지금 꼭 필요한 것 vs 나중에 더할 것)
• ④ 절차적(완성): 어떻게 하면 '훌륭'해지나? — 대상 사용자, 예외 상황(엣지 케이스), 원하는 사용 경험을 최대한 자세히 그립니다.

4단계가 곧 PRD다

PRD(Product Requirements Document, 제품 요구사항 문서)는 거창해 보이지만 정체는 단순합니다. '무엇을, 왜, 어떻게 만들지'를 적어 둔 한 장짜리 설계 메모입니다. 방금 답한 4단계를 문서로 옮기면 그대로 PRD가 됩니다. 아래는 AI 코딩에 잘 맞는, 실무에서 널리 쓰이는 PRD 구성입니다.

• 프로젝트 개요·목표: 무엇을 왜 만드는가, 성공하면 어떤 모습인가 (논리적)
• 기술 스택·요구사항: 어떤 프레임워크·언어·저장소를 쓰는가 (분석적)
• 핵심 기능 목록: 중요도에 따라 P0(필수)·P1(중요)·P2(있으면 좋음), 또는 1차/2차로 구분 (계산적)
• 사용자 스토리와 인수 조건: '누가 무엇을 하려 하고, 무엇이 충족되면 완료인가' (계산적+절차적)
• 대상 사용자·사용 시나리오: 누가 어떤 상황에서 쓰는가 (절차적)
• 엣지 케이스·예외 처리: 빈 입력, 오류, 잘못된 값이 들어오면 어떻게 하나 (절차적)
• 성공 지표·위험/의존성: 무엇으로 잘됨을 재고, 무엇이 걸림돌인가

기능을 P0/P1/P2로 나누는 습관을 강력히 권합니다. 이렇게 하면 AI에게 'P0부터 먼저 만들자'고 시켜 작게 시작할 수 있고(다음 레슨의 MVP 사고와 연결됩니다), 나중에 더할 것과 지금 할 것이 뒤섞여 혼란해지는 일을 막아 줍니다.

AI에게 PRD를 함께 쓰자고 요청하기

혼자 빈 문서를 마주하면 막막합니다. 그럴 땐 AI에게 'PRD를 함께 쓰자'고 부탁하면 됩니다. AI가 당신을 한 항목씩 인터뷰하며 빈칸을 채워 줍니다. 아래 프롬프트를 그대로 복사해 시작해 보세요.

재사용 프롬프트 — PRD 함께 쓰기

저는 [만들고 싶은 것을 한 줄로]를 만들려고 합니다. 저는 개발 경험이 많지 않습니다.
좋은 PRD(제품 요구사항 문서)를 당신과 함께 작성하고 싶습니다.

한꺼번에 묻지 말고 '한 번에 하나씩' 질문해서 제 답을 이끌어내 주세요.
다음 항목을 모두 채우는 것이 목표입니다:
 1) 프로젝트 개요와 목표 (이게 무엇이고 왜 만드는가)
 2) 기술 스택·요구사항 (무엇으로 짓는가 — 잘 모르면 당신이 추천)
 3) 핵심 기능 목록 (P0 필수 / P1 중요 / P2 나중)
 4) 대상 사용자와 사용 시나리오
 5) 엣지 케이스와 원하는 사용 경험

질문이 끝나면 위 내용을 깔끔한 마크다운 형식의 PRD 한 장으로 정리해 주세요.

PRD는 한 번 쓰고 잊는 문서가 아닙니다. 만들다 보면 생각이 바뀝니다. 그때마다 PRD를 갱신하고, 새 기능을 시작할 때 이 문서를 AI에게 다시 보여 주세요. PRD는 프로젝트 내내 AI와 당신이 공유하는 '같은 지도'입니다.

무엇을 만들지 정리했다면, 이제 '어디에' 지을지가 문제입니다. 다음 레슨에서는 두 번째 손가락 '구조' — 프론트엔드·백엔드·API라는 기본 골격과, 알맞은 프레임워크를 고르는 법을 배웁니다.