PRD 작성하기 - 기획을 잘하기 위해서 작업 순서 정하기

📝 한줄 요약

PRD를 확정했다고 생각하고 그 아래로 문서를 계속 쌓았는데, 고객 회신으로 PRD가 뒤집히면서 아래 문서와 이미 만든 화면까지 전부 다시 만들어야 했습니다.

Before: PRD를 먼저 확정 → 로드맵 → 세부계획 → 화면 제작 순으로 진행
After: 기획 초안을 먼저 충분히 흔들고, 그게 안정되면 PRD 아래로 내려가기

👥 이런 분께 추천

• 비개발자인데 개발자에게 넘길 기획 문서를 만들어야 하는 분

• AI와 함께 PRD, 로드맵 같은 문서를 여러 개 쌓고 있는 분

• 문서 하나를 고쳤더니 다른 문서까지 줄줄이 고치게 된 경험이 있는 분

🙋 내 스펙 & 환경

진행 방법

1. 왜 하게 되었나

문서를 순서대로 잘 쌓았다고 생각했습니다.

현재 스프레드시트를 뜯어본 AS-IS 분석서를 쓰고, 고객에게 물어볼 것을 정리한 확인질의서를 보내고, 그 다음에 PRD(요구사항 정의서)를 썼습니다. PRD가 나오자 거기서 4주 로드맵을 뽑고, 로드맵에서 21일치 세부계획을 잘랐습니다. 그리고 세부계획 Day 1대로 실제 화면 뼈대까지 만들었습니다.

문서가 위에서 아래로 잘 이어진다고 느꼈습니다.

AS-IS 분석서
    ↓
확인질의서
    ↓
PRD  ← 여기를 확정이라고 생각함
    ↓
로드맵
    ↓
세부계획 (21일)
    ↓
실제 화면
복사

ALT

mvp - 스크린샷 썸네일

2. 첫 번째 벽: 고객 회신으로 일곱 개가 뒤집혔다

확인질의서 답이 왔습니다. 그런데 제가 확정이라고 적었던 것 중 일곱 개가 실제와 달랐습니다.

특히 아팠던 건 승인 단계였습니다. 승인 화면 하나를 통째로 설계해뒀는데, 애초에 존재하지 않는 단계였습니다.

이 업무는 미팅을 다녀온 뒤에 기록하는 흐름이라 승인이라는 판단이 들어갈 자리가 없었습니다. 다녀온 미팅을 거절한다는 게 성립하지 않으니까요. 물어봤으면 5초 만에 알 수 있었던 것을, 제가 상식으로 넘겨짚었습니다.

3. 두 번째 벽: 문서 하나가 아니라 줄줄이 따라 바뀌었다

여기서 진짜 문제가 시작됐습니다. PRD를 고치는 걸로 끝나지 않았습니다.

PRD 한 장을 고쳤을 뿐인데 문서 네 개를 손봐야 했습니다.

이걸 저는 연쇄 수정이라고 부르기로 했습니다. 위 문서가 흔들리면 그 아래 있는 것이 전부 따라 흔들리는 현상입니다.

4. 세 번째 벽: 계획이 하루에 두 번 바뀌었다

더 놀라운 일이 있었습니다. 세부계획을 v2로 다시 짜고 나서 같은 날 안에 v3로 한 번 더 바뀌었습니다.

v2에서는 Lovable이라는 서비스에 프롬프트를 붙여넣어 만드는 방식이었는데, v3에서는 내 컴퓨터에서 직접 만드는 방식으로 바뀌었습니다. 만드는 도구가 바뀌니 21개 걸음의 내용도 또 달라졌습니다.

하루에 같은 문서를 두 번 갈아엎으면서, 이게 특별히 운이 나쁜 게 아니라 아래쪽 문서일수록 자주 흔들린다는 걸 알았습니다. 위쪽 문서(무엇을 왜)는 잘 안 바뀌는데, 아래쪽 문서(어떻게 만들지)는 도구 하나만 바뀌어도 통째로 바뀝니다.

5. 그래서 뭘 다르게 할까

다음에 새 업무를 자동화한다면 순서를 이렇게 바꾸겠습니다.

지금까지 한 방식

AS-IS → 질의서 → PRD 확정 → 로드맵 → 세부계획 → 제작
                    ↑
             여기서 뒤집히면 아래가 전부 무너짐

다음에 할 방식

AS-IS → 질의서 → 기획 초안 (여기서 충분히 흔들기)
                      ↓
                  답이 다 오고 안정되면
                      ↓
                 PRD → 유저스토리 → 세부계획 → 제작

핵심은 확정이라는 말을 아끼는 것입니다.

저는 PRD에 “확정”이라고 적어놓고 그걸 근거로 아래 문서를 만들었는데, 사실 그건 확정이 아니라 제 추정이었습니다. 초안이라고 부르고 있었으면 아래 문서를 만들기 전에 한 번 더 확인했을 것입니다.

🛠 사용한 도구

배운 점

💡 핵심 교훈

1. 확정과 추정을 구분해서 적어야 합니다

PRD에 “17시 이후가 초과근무”라고 적을 때 저는 그게 확정인 줄 알았습니다. 실제로는 시트를 보고 제가 추론한 것이었습니다. 문서에 “확정”과 “확인 필요”를 나눠서 표시했으면, 확인 안 된 항목 위에 다른 문서를 쌓지 않았을 것입니다.

2. 문서에도 위아래가 있고, 위가 흔들리면 아래가 다 흔들립니다

PRD가 로드맵보다 위인 줄 알았는데 실제로는 반대였습니다. 로드맵은 “무엇을 왜”라서 잘 안 바뀌고, PRD는 “어떻게 생겼는지”라서 자주 바뀝니다. 잘 안 바뀌는 것부터 굳혀야 합니다.

3. 껍데기만 만들어두면 뒤집혀도 싸게 끝납니다

Day 1에서 화면 뼈대만 만들고 안을 안 채운 게 여기서 값어치를 했습니다. Approvals 탭 안에 목록이랑 버튼을 다 채워놨다면 지우는 데도 시간이 들었을 텐데, 비어 있어서 탭 하나 지우는 걸로 끝났습니다.

4. 이게 개발자의 심정이었습니다

만든 걸 다 지우고 다시 만들어야 하는 상황을 겪고 나니, 개발자가 요구사항 확정 전에 착수하기 싫어하는 이유를 알겠습니다.

만든 걸 버리는 게 아까운 게 아니라, 버린 시간이 돌아오지 않는 것입니다.

전에는 “나중에 수정사항이 생기면 바뀌면 그만”이라고 생각한 적이 있는데, 이제는 그 말이 어떻게 들리는지 압니다.

적용할 점

🎯 결과

📋 복붙 가능한 프롬프트

같은 실수를 피하려고 앞으로 쓸 프롬프트입니다. AI에게 문서를 시킬 때 이렇게 조건을 붙입니다.

이 업무의 기획 초안을 써줘. 단, 다음 두 가지를 지켜줘.

1. 확정된 것과 내가 추정한 것을 반드시 나눠서 표시해줘.
   확정: 고객이나 자료에서 직접 확인된 것
   추정: 상식이나 관례로 내가 채워 넣은 것

2. 추정 항목은 문서 끝에 "확인 질문" 목록으로 따로 모아줘.
   그 질문이 어느 문단에 영향을 주는지도 같이 적어줘.

아직 PRD나 세부계획은 만들지 마. 이 초안이 확정된 다음에 만들 거야.

마지막 줄이 핵심입니다.

AI는 시키면 아래 문서까지 다 만들어주는데, 그러면 확인 안 된 추정 위에 문서가 쌓입니다.

추정이 뒤집혔을 때 무엇을 고쳐야 하는지 미리 알고 싶으면 이걸 씁니다.

지금 이 문서에서 [항목 이름]이 뒤집힌다고 가정해줘.
그러면 이 문서와 아래 문서들 중 어디를 고쳐야 하는지 목록으로 알려줘.

🔜 다음 계획

1. PRD의 미확정 항목을 “확인 필요” 표시로 다시 정리하기

2. 세부계획대로 Day 2부터 진행. 이번엔 껍데기 먼저, 내용은 나중에

3. 다음 업무(연차나 출장) 자동화할 때는 기획 초안 단계를 따로 두기

솔직한 소감

문서를 잘 쌓았다고 뿌듯해했던 만큼 무너질 때 허탈했습니다. 특히 승인 화면은 유저 스토리랑 인수조건까지 다 써뒀는데 통째로 날아갔습니다.

그런데 지나고 보니 다행이라는 생각도 듭니다. 화면을 다 만들고 나서 뒤집혔으면 훨씬 아팠을 테니까요. 껍데기 단계에서 뒤집힌 게 운이 좋았습니다.

그리고 하나 배웠습니다. 문서가 뒤집히는 건 실패가 아니라 정상 과정이라는 것.

다만 뒤집혔을 때 아래로 얼마나 번지는지는 순서를 어떻게 잡았느냐가 정한다는 것.

문서를 순서대로 쌓는 것과, 굳는 순서대로 쌓는 것은 다른 일이었습니다. 위에서 아래로 만들면 되는 줄 알았는데, 잘 안 바뀌는 것에서 자주 바뀌는 것 순으로 만들어야 했습니다.