바이브 코딩 실전 5화: AI가 딴 길로 새지 않는 PRD 만들기

지난 편에서 우리는 꽤 과감한 일을 했습니다.

만들고 싶은 기능을 잔뜩 추가한 것이 아니라,

오히려 대부분을 버렸습니다.

MyLog 첫 번째 MVP에 남은 것은 딱 네 가지입니다.

로그인도 없고,

사진도 없고,

검색도 없고,

AI 기능도 없습니다.

이제 앱을 만들면 될 것 같습니다.

그래서 AI에게 이렇게 말해봅니다.

잠시 후 AI가 열심히 코드를 작성합니다.

화면도 생겼습니다.

그런데 자세히 보니 뭔가 이상합니다.

우리는 제목과 내용을 입력하는 앱을 원했는데 날짜 선택 기능이 들어가 있습니다.

삭제 기능도 있습니다.

갑자기 카테고리까지 생겼습니다.

화면 디자인은 예쁘지만 우리가 생각한 앱과 조금씩 달라졌습니다.

AI에게 따집니다.

AI 입장에서는 억울할 수도 있습니다.

안 만들라고도 안 했으니까요. 😅

바로 이런 일을 줄이기 위해 필요한 것이 오늘 다룰 PRD입니다.

1. PRD가 뭔데 벌써 어려워 보이나요?

PRD는 보통

Product Requirements Document

즉, 제품 요구사항 문서를 뜻합니다.

단어만 보면 갑자기 회의실과 PPT 냄새가 납니다.

하지만 비개발자가 바이브 코딩에서 사용할 PRD는 거창할 필요가 없습니다.

100페이지짜리 문서도 필요 없습니다.

우리가 필요한 것은 간단합니다.

입니다.

저는 바이브 코딩에서 PRD를 일종의 AI용 내비게이션이라고 생각합니다.

목적지만 알려주면 AI가 알아서 갈 것 같지만,

경유지와 금지 구역까지 알려주면 훨씬 덜 헤맵니다.

2. 프롬프트와 PRD는 뭐가 다를까?

둘 다 AI에게 주는 글이니 비슷해 보입니다.

하지만 역할이 조금 다릅니다.

프롬프트는 보통 지금 할 일을 알려줍니다.

예를 들어

PRD는 프로젝트 전체에서 무엇을 만들고 있는지 알려줍니다.

예를 들어

프로젝트명: MyLog

목적:
개인 기록을 작성하고 다시 확인할 수 있는 간단한 모바일 앱

MVP 기능:
- 기록 목록
- 기록 작성
- 로컬 저장
- 기록 상세 보기

제외 기능:
- 로그인
- 클라우드 저장
- 검색
- 사진

정리하면

PRD = 지도

프롬프트 = 지금 내릴 운전 지시

정도로 생각하면 편합니다.

3. 왜 바이브 코딩에서 PRD가 더 중요할까?

사람 개발자와 일을 한다고 생각해보겠습니다.

기획자가

라고 하면 개발자는 보통 다시 질문합니다.

"기록에는 어떤 정보가 들어가나요?"

"수정이나 삭제도 필요한가요?"

"로그인이 있나요?"

"데이터는 어디에 저장하나요?"

"디자인은 어떻게 하나요?"

그런데 AI는 조금 다릅니다.

질문을 하기도 하지만,

때로는 빈칸을 스스로 채워버립니다.

그리고 AI는 빈칸을 굉장히 자신 있게 채우는 재주가 있습니다.

우리가 정확히 말하지 않은 부분을

"보통 앱이라면 이 정도는 있어야겠지."

라고 판단해서 만들어버릴 수 있습니다.

그게 맞으면 천재처럼 보입니다.

틀리면 프로젝트가 조금씩 산으로 갑니다. 🏔️

그래서 AI와 개발할 때는

AI가 추측해야 하는 영역을 줄이는 것

이 중요합니다.

4. 좋은 PRD는 길지 않아도 된다

처음 바이브 코딩을 시작하면서 PRD를 검색하면 아주 복잡한 템플릿을 만날 수 있습니다.

시장 분석

경쟁사 분석

페르소나

비즈니스 모델

KPI

리스크

성장 전략

로드맵...

물론 실제 회사의 제품 기획에서는 필요한 항목들입니다.

하지만 지금 우리의 목표는 첫 MVP입니다.

처음부터 기획서 작성이 본업이 되어서는 곤란합니다.

MyLog에서는 다음 여섯 가지면 충분합니다.

1. 무엇을 만드는가
2. 누가 사용하는가
3. 사용자는 무엇을 할 수 있는가
4. 어떤 데이터가 필요한가
5. 무엇은 만들지 않는가
6. 무엇이 되면 완료인가

이 정도면 AI에게 상당히 좋은 기준점을 줄 수 있습니다.

5. 프로젝트 목적부터 한 문장으로 쓴다

가장 먼저 앱의 목적을 작성합니다.

길게 쓰지 않습니다.

MyLog는 이렇게 정하겠습니다.

여기에는 중요한 정보가 몇 가지 들어 있습니다.

개인 기록 앱

이라는 것.

작성과 저장

이 핵심이라는 것.

그리고 다시 확인할 수 있어야 한다는 것.

반대로 SNS라는 말도,

공유라는 말도,

AI라는 말도 없습니다.

이 한 문장이 앞으로 모든 기능 판단의 기준이 됩니다.

새로운 기능이 떠올랐을 때 묻습니다.

아니라면 일단 뒤로 보냅니다.

6. 사용자를 복잡하게 만들지 않는다

회사에서 만드는 서비스라면 사용자 페르소나를 세세하게 정의하기도 합니다.

하지만 우리 첫 앱에서는 간단하게 갑니다.

대상 사용자

복잡한 기능 없이 개인적인 메모나 기록을 남기고 싶은 사용자

이 정도면 충분합니다.

여기서 중요한 것은 누가 아닌지도 알 수 있다는 것입니다.

MyLog 첫 버전은

팀 협업용 앱이 아닙니다.

SNS가 아닙니다.

기업용 문서 관리도 아닙니다.

여러 사람이 하나의 기록을 편집하는 기능도 필요 없습니다.

사용자를 정하면 필요 없는 기능을 제거하기가 쉬워집니다.

7. 기능은 사용자의 행동으로 작성한다

이제 기능 요구사항을 작성합니다.

여기서

처럼 개발자 용어로 적을 필요는 없습니다.

비개발자라면 오히려 사용자가 무엇을 할 수 있어야 하는지 적는 편이 좋습니다.

MyLog는 이렇게 작성할 수 있습니다.

사용자는 앱을 실행하면 저장된 기록 목록을 볼 수 있다.

각 목록에서는 최소한 기록의 제목을 확인할 수 있다.

사용자는 새 기록 작성 화면으로 이동할 수 있다.

제목과 내용을 입력할 수 있다.

사용자가 저장 버튼을 누르면 작성한 기록이 기기에 저장된다.

앱을 종료하고 다시 실행해도 기록이 유지되어야 한다.

사용자는 목록의 기록을 선택할 수 있다.

선택한 기록의 제목과 전체 내용을 확인할 수 있다.

아직 코드 이야기는 하나도 없습니다.

Flutter 위젯 이름도 없습니다.

데이터베이스 라이브러리 이름도 없습니다.

그런데 이미 무엇을 만들어야 하는지는 상당히 선명해졌습니다.

8. 데이터도 먼저 간단하게 정한다

우리가 DB 전문가가 될 필요는 없습니다.

다만 어떤 정보를 저장할지는 알고 있어야 합니다.

MyLog의 첫 기록 데이터는 이 정도면 충분합니다.

Record

id
title
content
createdAt

각각 의미는 단순합니다.

id

기록을 구분하기 위한 고유 값

title

기록 제목

content

기록 내용

createdAt

작성 날짜와 시간

여기서 또 욕심이 생깁니다.

수정 시간도 넣고,

태그도 넣고,

중요도도 넣고,

색상도...

오늘은 안 넣습니다. ✋

필요해지면 나중에 추가하면 됩니다.

9. '하지 않을 것'을 반드시 작성한다

지난 편에서도 강조했지만 PRD에서는 이 부분이 특히 중요합니다.

Out of Scope

즉, 이번 범위에 포함되지 않는 기능을 명확하게 적습니다.

MyLog MVP에서는 다음 기능을 제외합니다.

이번 MVP에서 구현하지 않는다.

- 회원가입
- 로그인
- 서버
- 클라우드 동기화
- 사진 첨부
- 검색
- 태그
- 카테고리
- 공유
- 푸시 알림
- AI 기능
- 통계
- 소셜 기능

이 항목은 사람에게도 중요하지만 AI에게는 더 중요합니다.

우리가

라고 하면 AI가 친절하게 검색 기능까지 넣을 수도 있습니다.

하지만

라고 명시하면 불필요한 확장을 막을 수 있습니다.

바이브 코딩에서는 해야 할 일 목록만큼 하지 말아야 할 일 목록도 중요합니다.

10. 그리고 오늘 가장 중요한 것, 완료 조건

여기서부터 이번 편의 핵심입니다.

많은 사람이 요구사항은 작성하지만 완료 조건은 적지 않습니다.

예를 들어 요구사항이 이것뿐이라고 해보겠습니다.

그럼 언제 완료된 걸까요?

저장 버튼이 생기면?

버튼을 누르면 메시지가 나오면?

메모리에 잠깐 들어가면?

앱을 종료해도 유지되어야 하나요?

이런 애매함을 없애는 것이 완료 조건, 즉 Acceptance Criteria입니다.

11. "동작한다" 대신 확인 가능한 문장으로 쓴다

나쁜 완료 조건부터 보겠습니다.

기록 저장 기능이 정상적으로 동작한다.

겉으로는 맞는 말입니다.

하지만 너무 애매합니다.

무엇이 정상인지 사람마다 다를 수 있습니다.

조금 더 구체적으로 써보겠습니다.

완료 조건

1. 사용자가 제목과 내용을 입력할 수 있다.
2. 저장 버튼을 누르면 기록이 저장된다.
3. 저장 후 기록 목록에 새 기록이 표시된다.
4. 앱을 완전히 종료한 뒤 다시 실행해도 기록이 남아 있다.
5. 저장된 기록을 누르면 제목과 내용을 다시 확인할 수 있다.

이제 훨씬 명확합니다.

AI가

라고 했을 때 우리도 실제로 확인할 수 있습니다.

12. 완료 조건은 AI의 셀프 체크리스트가 된다

이 완료 조건을 AI에게 그대로 전달하면 재미있는 변화가 생깁니다.

단순히

라고 하는 대신

기록 저장 기능을 구현해줘.

완료 조건은 다음과 같다.

1. 제목과 내용을 입력할 수 있어야 한다.
2. 저장하면 목록에 즉시 표시되어야 한다.
3. 앱을 종료하고 다시 실행해도 데이터가 유지되어야 한다.
4. 목록에서 기록을 선택하면 상세 내용을 확인할 수 있어야 한다.

구현 후 각 조건이 충족되는지 확인해줘.

라고 할 수 있습니다.

이렇게 하면 AI에게 완료의 정의를 줄 수 있습니다.

이 차이가 꽤 큽니다.

바이브 코딩에서 자주 발생하는 문제가 바로

AI의 완료와 사람의 완료가 다른 것

이기 때문입니다.

13. Definition of Done도 하나 만들어보자

조금 개발 프로젝트다운 용어를 하나 더 알아보겠습니다.

Definition of Done

줄여서 DoD라고 부르기도 합니다.

쉽게 말하면

입니다.

MyLog에서는 어렵게 하지 않겠습니다.

MyLog 작업 완료 기준

- 앱이 정상적으로 빌드된다.
- 실행 중 오류가 발생하지 않는다.
- 요청한 기능이 실제로 동작한다.
- 기존 기능이 깨지지 않는다.
- 불필요한 기능을 추가하지 않는다.
- 변경된 파일과 내용을 설명한다.

앞으로 AI에게 기능을 맡길 때 이것을 반복해서 사용할 수 있습니다.

14. 요구사항에는 '예외 상황'도 조금 적어두자

제품이 MVP에서 실제 제품으로 넘어갈 때 중요한 것이 예외 처리입니다.

지금부터 아주 복잡하게 만들 필요는 없습니다.

하지만 명백한 상황 정도는 미리 정할 수 있습니다.

예를 들어 제목과 내용을 아무것도 입력하지 않고 저장 버튼을 누르면 어떻게 할까요?

AI가 알아서 정하게 할 수도 있습니다.

하지만 우리가 정하는 편이 좋습니다.

MyLog에서는 이렇게 해보겠습니다.

입력 규칙

- 제목은 필수 입력이다.
- 내용은 비어 있어도 저장할 수 있다.
- 제목이 비어 있으면 저장하지 않는다.
- 제목이 비어 있을 경우 사용자에게 안내 메시지를 표시한다.

이제 AI가 임의로 판단할 부분이 또 하나 줄었습니다.

15. UI도 필요한 만큼만 기준을 준다

PRD에 디자인까지 픽셀 단위로 적을 필요는 없습니다.

첫 MVP에서는 원칙만 정하겠습니다.

UI 원칙

- 단순하고 읽기 쉬운 화면
- 불필요한 애니메이션 사용 금지
- 기본 모바일 사용 패턴을 따른다.
- 화면마다 주요 행동은 하나가 명확하게 보이도록 한다.
- 첫 MVP에서는 디자인보다 기능 완성을 우선한다.

특히 마지막 문장이 중요합니다.

AI에게

라고만 하면 디자인에 과도하게 힘을 쓸 수 있습니다.

우리의 첫 목표는 Behance 작품 전시가 아닙니다.

스토어까지 가는 앱을 만드는 것입니다.

예쁜 버튼 때문에 2시간을 쓰는 순간 MVP가 슬슬 화장대 앞에 앉기 시작합니다. 💄

16. 이제 MyLog의 실제 PRD를 만들어보자

지금까지 내용을 하나로 합쳐보겠습니다.

앞으로 AI에게 제공할 MyLog MVP PRD v0.1입니다.

# MyLog MVP PRD v0.1

## 1. 프로젝트 목적

사용자가 개인적인 기록을 간단히 작성하고 저장한 뒤
나중에 다시 확인할 수 있는 모바일 앱을 만든다.

## 2. 대상 사용자

복잡한 기능 없이 개인 기록이나 메모를 남기고 싶은 사용자

## 3. 핵심 사용자 흐름

앱 실행
→ 저장된 기록 목록 확인
→ 새 기록 작성
→ 저장
→ 목록에서 저장된 기록 확인
→ 기록 선택
→ 상세 내용 확인

## 4. MVP 기능

### 기록 목록
- 저장된 기록 목록을 표시한다.
- 각 기록의 제목을 표시한다.

### 기록 작성
- 사용자는 새 기록을 작성할 수 있다.
- 제목과 내용을 입력할 수 있다.

### 기록 저장
- 기록은 스마트폰 로컬 영역에 저장한다.
- 앱을 종료한 뒤 다시 실행해도 데이터가 유지되어야 한다.

### 기록 상세
- 목록의 기록을 선택할 수 있다.
- 선택한 기록의 제목과 내용을 확인할 수 있다.

## 5. 데이터

Record

- id
- title
- content
- createdAt

## 6. 입력 규칙

- 제목은 필수다.
- 내용은 비어 있어도 된다.
- 제목이 비어 있으면 저장하지 않는다.
- 사용자에게 제목 입력이 필요하다는 안내를 보여준다.

## 7. MVP 제외 기능

이번 버전에서는 다음 기능을 구현하지 않는다.

- 회원가입
- 로그인
- 서버
- 클라우드 동기화
- 사진
- 검색
- 태그
- 카테고리
- 공유
- 알림
- AI 기능
- 통계
- 소셜 기능

## 8. UI 원칙

- 단순하고 읽기 쉽게 구성한다.
- 불필요한 애니메이션을 추가하지 않는다.
- 디자인보다 기능 완성을 우선한다.
- 모바일의 일반적인 사용 패턴을 따른다.

## 9. 완료 조건

- 앱이 정상적으로 실행된다.
- 기록 목록 화면을 볼 수 있다.
- 새 기록을 작성할 수 있다.
- 제목과 내용을 입력할 수 있다.
- 기록을 저장할 수 있다.
- 저장 직후 목록에 기록이 표시된다.
- 앱을 종료하고 다시 실행해도 데이터가 유지된다.
- 목록에서 기록을 선택하면 상세 내용을 볼 수 있다.
- 제목이 없는 기록은 저장되지 않는다.
- 요청하지 않은 기능은 추가하지 않는다.

## 10. 작업 완료 시 AI가 보고할 내용

- 수정한 파일 목록
- 각 파일에서 변경한 내용
- 실행 또는 테스트 결과
- 남아 있는 문제
- 다음 단계에서 필요한 작업

이 정도면 첫 번째 MVP를 만들기 위한 PRD로 충분합니다.

엄청난 기획서는 아닙니다.

하지만 이제 AI가 프로젝트의 방향을 추측해야 하는 부분이 크게 줄었습니다.

17. 여기서 바로 코딩시키지 않는 것이 포인트다

PRD를 만들었다고 곧바로

라고 하지 않겠습니다.

AI에게 먼저 검토를 시켜봅니다.

아래 PRD를 읽고 아직 코드는 작성하지 마.

먼저 다음 내용을 분석해줘.

1. 요구사항 사이에 충돌이 있는지
2. 빠진 핵심 요구사항이 있는지
3. MVP 범위를 벗어난 부분이 있는지
4. 구현 전에 결정해야 할 사항이 있는지
5. 필요한 화면을 정리해줘

임의로 기능을 추가하지 말고
질문이 필요한 부분과 제안 사항을 분리해서 알려줘.

이 과정이 꽤 중요합니다.

AI를 바로 코드 생성기로 쓰는 것이 아니라,

먼저 기획 리뷰어로 사용하는 것입니다.

바이브 코딩의 장점은 AI가 코드를 써주는 것만이 아닙니다.

기획 단계에서도 충분히 활용할 수 있습니다.

18. AI의 제안과 요구사항을 구분하자

AI가 PRD를 검토하면서 이런 말을 할 수도 있습니다.

좋은 제안입니다.

그렇다고 바로 넣지는 않습니다.

우리는 이렇게 판단합니다.

아닙니다.

그러면 답은 간단합니다.

AI가 제안했다고 요구사항이 되는 것은 아닙니다.

이 원칙은 앞으로도 계속 유지해야 합니다.

AI는 제안할 수 있지만 제품의 범위를 결정하는 사람은 우리입니다.

19. PRD에 버전을 붙여두자

PRD 파일을 만든다면 이름을 이렇게 관리할 수 있습니다.

PRD.md

그리고 문서 안에 버전을 남깁니다.

MyLog PRD

Version: 0.1

요구사항이 바뀌면

Version: 0.2

로 변경할 수 있습니다.

나중에 프로젝트가 커졌을 때

"왜 이런 구조로 만들었지?"

라는 질문이 생기면 당시 요구사항을 확인할 수 있습니다.

Git을 사용한다면 PRD 변경 이력도 함께 남습니다.

지난 편들에서 이야기한 내용들이 조금씩 연결되기 시작합니다.

PRD
↓
AI 작업
↓
코드 변경
↓
실행 확인
↓
Git Commit

이 흐름을 앞으로 계속 반복하게 됩니다.

20. 비개발자 PRD에서 피하면 좋은 문장

AI에게 요구사항을 작성할 때 이런 표현은 조심하는 편이 좋습니다.

알아서의 범위가 너무 넓습니다.

사람마다 요즘이 다릅니다.

어떤 상태가 편한 것인지 확인하기 어렵습니다.

완벽의 완료 조건이 없습니다.

이 한 문장이 기능 증식의 비밀 통로가 될 수 있습니다. 🕳️

대신 가능한 한 확인할 수 있는 문장으로 바꿉니다.

이런 문장은 테스트할 수 있습니다.

21. 요구사항은 테스트할 수 있어야 한다

좋은 요구사항인지 확인하는 아주 간단한 방법이 있습니다.

문장을 읽고

라고 물어보는 것입니다.

예를 들어

확인이 어렵습니다.

반면

직접 확인할 수 있습니다.

이 차이가 중요합니다.

제품 개발에서 좋은 요구사항은 멋진 문장이 아니라

검증 가능한 문장입니다.

22. 오늘의 삽질 방지 팁 🛠️

PRD를 만든 뒤 AI에게 가장 먼저

라고 하지 마세요.

먼저 이렇게 요청해보세요.

이 PRD를 기준 문서로 사용한다.

아직 구현하지 말고
프로젝트를 만드는 데 필요한 작업을
작은 단계로 나눠줘.

각 단계는 구현 후 독립적으로
실행하거나 확인할 수 있어야 한다.

한 단계에서 너무 많은 파일이나 기능을
동시에 변경하지 않도록 구성해줘.

그러면 PRD가 개발 작업 목록으로 변하기 시작합니다.

이것이 바로 다음 단계에서 우리가 사용할 방법입니다.

23. 오늘은 코드를 한 줄도 만들지 않았지만 꽤 많이 만들었다

지금까지 #01부터 #05까지 왔습니다.

그런데 아직 본격적으로 코딩하지 않았습니다.

조금 답답할 수도 있습니다.

바이브 코딩인데 왜 이렇게 준비가 많나 싶을 수도 있습니다.

하지만 우리가 지금 만든 것은 보이지 않는 코드입니다.

앱의 목적을 정했고,

범위를 줄였고,

데이터를 정했고,

하지 않을 기능을 정했고,

완료 조건까지 만들었습니다.

이제 AI에게 작업을 시킬 때

가 아니라

라고 말할 수 있습니다.

이 차이가 프로젝트가 커질수록 점점 크게 나타납니다.

AI의 코딩 속도는 이미 충분히 빠릅니다.

앞으로 필요한 것은 AI를 더 빨리 달리게 만드는 것이 아니라

엉뚱한 방향으로 빨리 달리지 않게 만드는 것입니다. 🏎️

이제 무엇을 만들지 명확해졌습니다.

드디어 다음 편부터는 실제 프로젝트를 시작합니다.

개발 환경을 준비하고,

Flutter 프로젝트를 만들고,

AI 코딩 에이전트에게 프로젝트를 보여주고,

처음으로 앱을 실행해보겠습니다.

다음 편은

[바이브 코딩 실전 #06] 이제 진짜 프로젝트를 만들어보자 | 개발환경부터 첫 실행까지

입니다.

여기서 처음으로 우리가 작성한 PRD가 실제 개발 과정에 투입됩니다.

다음 편의 목표는 거창하지 않습니다.

아이폰이나 Android 에뮬레이터에 화려한 앱을 완성하는 것도 아닙니다.

딱 하나입니다.

첫 번째 성공 기준은 작게 잡겠습니다.

왜냐하면 이제부터는 말이 아니라 진짜 코드가 움직이기 시작하니까요. 🚀

#바이브코딩 #VibeCoding #AI코딩 #PRD #제품요구사항 #요구사항정의 #MVP #MVP개발 #앱기획 #비개발자앱개발 #AI에이전트 #AcceptanceCriteria #앱개발 #프로덕트개발 #MyLog #바이브코딩실전