PRD를 작성한 다음에는 무엇을 해야 하나요? 개발 계획으로 바꾸기

앞 글에서 바이브코딩을 시작하기 전에 AI와 PRD를 작성하는 방법을 알아봤습니다.

PRD에는 다음과 같은 내용이 들어 있습니다.

누가 사용하나요?
어떤 문제를 해결하나요?
사용자는 무엇을 할 수 있나요?
첫 버전에는 어떤 기능을 넣나요?
각 기능은 어떻게 작동해야 하나요?

PRD를 완성했다고 곧바로 “이제 전부 만들어줘”라고 요청하지는 마세요.

PRD는 무엇을 왜 만들지 정한 문서입니다. 어떤 순서로 무엇을 만들고 어떻게 확인할지는 개발 계획으로 다시 정리해야 해요.

PRD
→ 필요한 화면 정리
→ 저장할 데이터 정리
→ 기능을 작은 작업으로 나누기
→ 작업 순서 정하기
→ 완료 기준으로 확인하기

PRD와 개발 계획은 역할이 달라요

PRD는 사용자가 원하는 결과와 기능의 작동 방식을 설명합니다.

개발 계획은 PRD를 실제로 만들기 위해 필요한 작업과 순서를 설명해요.

예를 들어 PRD에 다음 요구사항이 있다고 해볼게요.

사용자는 오늘 운동한 내용을 기록하고
지난 기록과 연속 운동 일수를 확인할 수 있다.

개발 계획에서는 이를 더 작은 작업으로 나눕니다.

운동 기록 입력 화면 만들기
→ 입력값 확인하기
→ 기록 저장하기
→ 지난 기록 목록 보여주기
→ 연속 운동 일수 계산하기
→ 각 흐름이 완료 기준을 만족하는지 확인하기

먼저 첫 버전의 범위를 다시 확인해요

개발 계획을 만들기 전에 PRD에서 이번에 만들 범위를 확인합니다.

첫 버전에 꼭 필요함
나중에 추가함
이번에는 만들지 않음

AI가 개발 계획을 만들면서 나중에 추가할 기능까지 섞지 않도록 하세요.

예를 들어 운동 기록 앱의 첫 버전에서 친구, 푸시 알림과 결제를 제외했다면 개발 계획에도 해당 작업을 넣지 않습니다.

PRD에서 첫 버전에 포함한 기능만 사용해줘.
나중에 추가하거나 제외하기로 한 기능은 개발 작업에 넣지 마.

범위가 불분명한 항목은 AI가 알아서 결정하게 두지 말고 질문 목록으로 먼저 받는 편이 좋아요.

핵심 사용자 흐름을 기준으로 작업을 나눠요

화면 종류나 기술 이름만으로 작업을 나누면 사용자가 실제로 기능을 사용할 수 있는 시점이 늦어집니다.

좋지 않은 작업 구분
→ 모든 화면 만들기
→ 모든 데이터베이스 만들기
→ 모든 서버 기능 만들기

대신 사용자의 행동이 처음부터 끝까지 이어지는 작은 흐름으로 나눠보세요.

오늘 운동 기록
→ 기록 저장
→ 저장한 기록 확인

이 흐름 하나를 작동하게 하려면 화면, 입력값 확인, 데이터 저장과 결과 표시를 함께 만들어야 합니다.

작업 1
→ 운동 종류와 시간을 입력하는 화면

작업 2
→ 잘못 입력한 값을 안내하는 규칙

작업 3
→ 입력한 기록을 데이터베이스에 저장

작업 4
→ 저장 결과를 화면에 표시

작업 5
→ 앱을 다시 열어도 기록이 남는지 확인

이렇게 나누면 작업 몇 개를 마칠 때마다 실제로 사용할 수 있는 흐름을 확인할 수 있어요.

필요한 화면과 화면 상태를 정리해요

PRD의 사용자 흐름을 바탕으로 필요한 화면을 뽑습니다.

오늘 운동 기록 화면
지난 기록 목록 화면
기록 상세·수정 화면

화면 이름만 적지 말고 화면에서 생길 수 있는 상태도 함께 정리하세요.

• 처음 열었지만 아직 기록이 없는 상태
• 기록을 불러오는 중인 상태
• 기록을 정상적으로 보여주는 상태
• 저장이나 불러오기에 실패한 상태
• 입력값이 잘못되어 안내가 필요한 상태

AI는 정상 화면을 먼저 만들고 빈 상태나 오류 상태를 빠뜨리기 쉽습니다. 개발 계획에 상태별 확인 작업을 넣으면 완성도를 높일 수 있어요.

저장할 데이터를 정리해요

화면에서 입력하고 보여줄 값이 무엇인지 정리합니다.

운동 기록에는 다음과 같은 데이터가 필요할 수 있어요.

운동 종류
운동 시간
운동한 날짜
메모
기록을 만든 시각
기록을 수정한 시각

각 값에 대해 다음 질문을 확인합니다.

• 반드시 입력해야 하나요?
• 어떤 형태로 저장하나요?
• 같은 값을 여러 번 저장할 수 있나요?
• 누가 읽고 수정하거나 삭제할 수 있나요?
• 기존 데이터가 있을 때 구조를 어떻게 바꾸나요?

화면에서 운동 시간을 추가했는데 데이터베이스와 서버 작업을 계획에 넣지 않으면 화면만 있고 저장되지 않는 기능이 생길 수 있습니다.

새로운 데이터 항목
→ 화면
→ 입력값 확인
→ 서버
→ 데이터베이스
→ 다시 불러오기

영향을 받는 부분을 함께 묶어서 계획하세요.

외부 서비스와 기술 조건을 확인해요

로그인, 이메일, 결제, 지도와 파일 저장처럼 외부 서비스가 필요한 기능이 있는지 확인합니다.

회원가입·로그인
→ 로그인 서비스와 권한 확인

이메일 발송
→ 발송 서비스와 실패 처리

사진 업로드
→ 파일 저장 위치와 접근 범위

이미 프로젝트를 시작했다면 현재 사용하는 기술과 구조를 먼저 확인하게 하세요. 같은 역할을 하는 도구를 새로 추가하거나 기존 구조와 다른 방식을 섞지 않도록 해야 합니다.

아직 기술을 정하지 않았다면 PRD의 요구사항을 기준으로 선택합니다. 기술 이름이 낯설다면 기술 스택이 무슨 뜻인지 설명한 글을 참고하세요.

기능을 확인할 수 있는 크기로 나눠요

“회원 기능 만들기”나 “관리자 기능 완성하기”는 작업 범위가 너무 큽니다.

한 작업은 결과를 직접 확인할 수 있을 만큼 작아야 해요.

너무 큰 작업
→ 운동 기록 기능 완성하기

확인할 수 있는 작업
→ 운동 기록 입력 폼 만들기
→ 운동 종류가 없으면 저장하지 않고 안내하기
→ 정상 입력을 데이터베이스에 저장하기
→ 저장한 기록을 목록 첫 줄에 보여주기

작업 하나에는 다음 내용을 적습니다.

1. 작업 목적
2. 사용자가 하는 행동
3. 만들어야 할 결과
4. 영향을 받는 화면·서버·데이터
5. 시작 전에 필요한 작업
6. 완료 기준
7. 확인 방법

AI에게 작업을 맡길 때도 제목 한 줄만 전달하지 말고 이 내용을 함께 보여주세요.

작업 사이의 순서를 정해요

기능마다 먼저 끝나야 하는 작업이 있습니다.

운동 기록의 데이터 구조 결정
→ 기록 저장 기능
→ 기록 목록
→ 연속 운동 일수 계산

저장한 기록이 없는데 연속 운동 일수를 계산하는 화면부터 만들 수는 없습니다.

개발 계획에는 각 작업의 선행 조건과 순서를 표시하세요.

다만 화면을 모두 만든 뒤 서버를 만들고, 마지막에 연결하는 식으로 너무 크게 나누지는 않는 편이 좋습니다. 작은 사용자 흐름 하나가 실제로 작동하도록 화면, 서버와 데이터를 연결한 뒤 다음 흐름으로 넘어가세요.

완료 기준은 사용자의 행동으로 적어요

“코드 작성 완료”나 “화면 구현 완료”는 기능이 작동한다는 뜻이 아닙니다.

완료 기준은 사용자가 무엇을 할 수 있는지로 적습니다.

사용자가 운동 종류와 시간을 입력할 수 있다.
운동 종류가 없으면 저장하지 않고 안내한다.
정상적으로 저장하면 목록 첫 줄에 기록이 나타난다.
앱을 닫았다 다시 열어도 기록이 남아 있다.
저장에 실패하면 입력한 내용이 사라지지 않는다.

AI가 작업을 마쳤다고 말하면 완료 기준을 하나씩 확인하게 하세요.

PRD를 개발 계획으로 바꾸는 요청문

다음 요청문을 사용하면 AI가 코드를 만들기 전에 계획부터 정리할 수 있습니다.

docs/prd.md를 읽고 첫 버전의 개발 계획을 작성해줘.

아직 코드를 만들거나 파일을 수정하지 마.

먼저 PRD에서 다음 내용을 확인해줘.
- 주요 사용자와 해결할 문제
- 핵심 사용자 흐름
- 첫 버전에 넣을 기능
- 나중에 추가할 기능
- 이번에는 만들지 않을 기능
- 기능별 작동 규칙과 완료 기준

정보가 부족하거나 서로 충돌하면
임의로 결정하지 말고 질문 목록을 먼저 보여줘.

확정한 요구사항을 바탕으로 다음 내용을 정리해줘.
1. 핵심 사용자 흐름별 필요한 화면
2. 화면별 정상·빈 값·로딩·오류 상태
3. 저장할 데이터와 값별 규칙
4. 필요한 서버 기능과 외부 서비스
5. 기능을 확인할 수 있는 작은 작업 목록
6. 작업 사이의 선행 조건과 추천 순서
7. 작업별 완료 기준과 확인 방법

결과는 docs/development-plan.md에 저장할 형식으로 작성해줘.

이미 코드가 있는 프로젝트라면 다음 조건을 추가합니다.

현재 프로젝트의 기술 스택과 폴더 구조를 먼저 확인해줘.
같은 역할의 도구를 중복해서 추가하지 말고
기존 구조를 바꿔야 한다면 이유와 영향을 먼저 설명해줘.

개발 계획은 이렇게 활용해요

계획을 만들었다면 한꺼번에 모든 작업을 맡기지 마세요.

다음 작업 하나 선택
→ 영향을 받는 부분 확인
→ 코드 수정
→ 완료 기준 확인
→ 결과 기록
→ 다음 작업 선택

AI에게 현재 작업만 진행하게 하고, 마친 뒤에는 완료 기준과 실제 확인 결과를 남기게 합니다.

development-plan.md에서 아직 끝나지 않은 첫 번째 작업만 진행해줘.

수정하기 전에 영향을 받는 파일과 데이터 구조를 설명하고
작업을 마치면 완료 기준별 확인 결과를 기록해줘.
다음 작업은 시작하지 마.

작업 도중 요구사항을 바꿔야 한다면 개발 계획만 고치지 않습니다.

요구사항 변경
→ PRD 수정
→ 개발 계획에 미치는 영향 확인
→ 작업 순서와 완료 기준 수정
→ 코드 수정

PRD와 개발 계획이 서로 다른 내용을 말하지 않도록 함께 관리하세요.

이 과정을 클로드 스킬로 만들어둘 수도 있어요

여러 프로젝트에서 PRD를 개발 계획으로 바꾸는 일을 반복한다면 매번 긴 요청문을 복사할 필요가 없습니다.

PRD를 개발 계획으로 바꾸기 클로드 스킬로 만들어두면 좋아요.

Skill에는 다음 작업 순서를 넣을 수 있습니다.

PRD 읽기
→ 빠진 내용과 충돌 확인
→ 첫 버전의 범위 분리
→ 사용자 흐름별 화면 정리
→ 데이터와 외부 서비스 정리
→ 확인 가능한 작업으로 나누기
→ 선행 조건과 순서 결정
→ 완료 기준과 확인 방법 작성

Skill을 사용하면 프로젝트마다 같은 기준으로 개발 계획을 만들 수 있습니다.

• 나중에 만들 기능을 현재 계획에서 제외합니다.
• 모호한 요구사항을 추측하지 않고 질문합니다.
• 화면만 만들고 데이터 작업을 빠뜨리지 않습니다.
• 작업을 결과를 확인할 수 있는 크기로 나눕니다.
• 모든 작업에 완료 기준과 확인 방법을 붙입니다.

다만 Skill이 모든 프로젝트에 같은 기술과 작업 목록을 강제로 사용하게 하면 안 됩니다. PRD와 현재 프로젝트 구조를 먼저 읽고 필요한 계획을 만들도록 해야 해요.

고정할 것
→ PRD를 검토하고 계획을 만드는 절차와 확인 기준

프로젝트마다 바꿀 것
→ 화면·데이터·기술·작업 목록과 순서

클로드 스킬(Claude Skill)이 무엇인지부터 확인하고 싶다면 앱을 만들기 전에 클로드 스킬로 문제를 해결할 수 있는지 판단하는 글을 참고하세요.

개발 계획 Skill을 만드는 요청문

클로드에게 다음처럼 요청할 수 있습니다.

PRD를 개발 계획으로 바꾸는 클로드 스킬을 만들어줘.

이 Skill은 PRD가 준비된 프로젝트에서만 사용해.
바로 코드를 만들지 말고 다음 순서로 진행해야 해.

1. PRD의 사용자·문제·핵심 흐름 확인
2. 첫 버전·나중·제외 기능 분리
3. 빠졌거나 충돌하는 요구사항 질문
4. 사용자 흐름별 화면과 상태 정리
5. 필요한 데이터·서버·외부 서비스 정리
6. 기능을 확인할 수 있는 작은 작업으로 나누기
7. 선행 조건과 추천 작업 순서 결정
8. 작업별 완료 기준과 확인 방법 작성

PRD에 없는 내용을 임의로 요구사항에 추가하지 마.
프로젝트에 기존 코드가 있다면 기술 스택과 구조를 먼저 확인해.
특정 기술을 모든 프로젝트에 고정하지 마.

결과는 docs/development-plan.md에 저장할 수 있는 형식으로 작성해.
서로 다른 PRD 예시 3개로 Skill을 시험하고
계획이 너무 크거나 모호하게 나오는 부분을 수정해줘.

처음에는 지침과 출력 형식만으로 Skill을 만들어도 충분합니다. 꼭 필요한 경우에만 추가 스크립트나 템플릿을 연결하세요.

정리

PRD를 작성한 뒤에는 내용을 그대로 AI에게 전달해 한꺼번에 구현하게 하지 않습니다.

PRD 범위 확인
→ 핵심 사용자 흐름 선택
→ 화면과 상태 정리
→ 데이터와 외부 서비스 정리
→ 확인 가능한 작업으로 나누기
→ 선행 조건과 순서 정하기
→ 완료 기준과 확인 방법 작성
→ 한 작업씩 구현하고 확인

개발 계획은 기능 목록이 아닙니다. 사용자가 원하는 결과까지 어떤 작업을 어떤 순서로 만들고 확인할지 정한 문서예요.

이 과정을 반복한다면 클로드 스킬로 만들어두세요. 프로젝트가 달라져도 PRD를 검토하고 작업을 나누는 기준을 일관되게 적용할 수 있습니다.