제품 판단 문서: PRD는 구현 지시서가 아니다

제품 판단 문서는 구현 방법을 정하려고 쓰는 문서가 아니다. 왜 이 문제를 풀어야 하는지, 누구에게 가치가 있는지, 어떤 결과를 성공으로 볼지를 정한다. 여기에는 Product Brief, BRD, MRD, PRD, Roadmap이 들어간다. 로그를 다시 펼쳤을 때 눈에 들어온 건 예쁜 성공 화면이 아니라, 제품 주변에서 반복되던 작은 끊김이었다. 그래서 용어 사전 대신, 그 날 무엇을 보고 무엇을 바꿨는지부터 적는다.

PRD가 커진 문제

Atlassian의 PRD 가이드는 PRD를 제품의 목적, 기능, 행동을 이해관계자와 정렬하는 문서로 본다. 또 좋은 PRD는 혼자 쓰는 문서가 아니라 제품, 디자인, 개발이 함께 다듬는 문서라고 설명한다. 이 관점이 중요하다. PRD는 개발팀에게 명령하는 문서가 아니라, 제품 판단의 기준선을 공유하는 문서다. ```md - 사용자는 요청 상태가 바뀐 뒤 5분 안에 변경 사실을 알 수 있어야 한다. - 첫 버전에서는 앱 내부 알림만 제공하고 이메일과 푸시는 제외한다. 이 정도면 아직 구현이 아니다. 하지만 구현을 시작하기 전에 필요한 판단은 들어 있다. Product Brief는 제품 판단의 가장 짧은 버전이다. 이 기능이 어떤 문제를 다루는지, 누구를 위한 것인지, 이번에 어디까지 할 것인지, 성공을 어떻게 볼 것인지를 적는다. 길어질수록 힘이 빠진다. 좋은 Product Brief는 개발자가 회의 밖에서 다시 읽어도 방향을 잃지 않게 한다. 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다.

처음에는 PRD를 명세로 봤다

이 경계가 분리되면 개발자는 자유로워진다. 구현 선택을 늦출 수 있고, 제품 판단이 바뀌었을 때 코드를 덜 버리게 된다. 제품 판단 문서는 개발 전에 모든 것을 확정하자는 문서가 아니다. 오히려 구현 전에 너무 빨리 굳히면 안 되는 것과 지금은 반드시 정해야 하는 것을 나누기 위해 쓴다. WebSocket은 구현 선택이다. “5분 안에 알 수 있어야 한다”는 제품 요구에 가깝다. 이메일과 푸시를 제외한다는 문장은 범위를 지킨다. PRD가 이 선을 넘으면 다음 문서들이 모두 흐려진다. 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. 예를 들어 요청 상태 기능을 만든다면 Roadmap은 이렇게 쓸 수 있다. 이 문서들이 약해지면 팀은 너무 빨리 구현으로 도망간다. “알림은 WebSocket으로 보낸다”, “파일 목록은 Redis에 캐시한다” 같은 문장이 PRD에 들어온다. 둘 다 나쁜 기술은 아니지만, 아직 너무 이르다. 사용자가 무엇을 얻어야 하는지 정하지 않은 상태에서 구현 방식이 먼저 굳어지기 때문이다.

구현 지시서가 아닌 게 선명해진 순간

• 문제: 사용자는 상담 요청 후 현재 상태를 알기 어렵다.
• 대상: 첫 요청을 보낸 개인 사용자와 요청을 검토하는 상담자.
• 목표: 사용자가 승인, 보류, 거절 상태를 스스로 확인한다.
• 제외: 첫 버전에서는 이메일/푸시 알림을 제공하지 않는다.
• 성공 기준: 요청 상세 진입 후 현재 상태와 다음 행동을 10초 안에 이해할 수 있다. md
• 알림은 WebSocket으로 보낸다.
• 파일 목록은 Redis에 캐시한다. BRD는 business requirements document다. 조직이 왜 이 일을 해야 하는지, 어떤 사업 결과가 필요한지에 가깝다. MRD는 market requirements document다. 시장, 고객군, 경쟁, 포지셔닝을 본다. PRD는 product requirements document다. 사용자 문제, 제품 범위, 성공 기준, 하지 않을 일을 제품팀과 개발팀이 함께 맞추는 문서다. 이 순서에는 제품 판단이 있다. 먼저 사용자가 혼란을 줄이는지 보고, 그다음 운영자가 이유를 남길 수 있는지 보고, 마지막에 알림 채널을 붙인다. 구현이 아니라 학습 순서다.
• 지금 정해야 하는 것: 사용자, 문제, 범위, 성공 기준, 제외할 것
• 아직 열어둘 것: 구체 구현, 내부 구조, 저장소, 프로토콜, 배포 방식 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. ```md 1. 사용자가 상태를 직접 확인할 수 있게 한다. 2. 상담자가 보류/거절 이유를 구조화해 남길 수 있게 한다. 3. 반복 요청에서 이전 맥락을 보여준다. 4. 상태 변경 알림 채널을 추가한다. 제품를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

판단 문서 경계 나누기

Roadmap은 날짜표가 아니라 판단 순서다. 무엇을 먼저 배우고, 무엇을 나중에 확장할지 적는다. 특히 작은 제품에서는 “언제까지 다 만든다”보다 “무엇을 검증한 뒤 다음 단계로 간다”가 더 중요하다. 참고: Atlassian PRD 가이드 — https://www.atlassian.com/agile/product-management/requirements 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. Atlassian의 PRD 가이드는 PRD를 제품의 목적, 기능, 행동을 이해관계자와 정렬하는 문서로 본다. 또 좋은 PRD는 혼자 쓰는 문서가 아니라 제품, 디자인, 개발이 함께 다듬는 문서라고 설명한다. 이 관점이 중요하다. PRD는 개발팀에게 명령하는 문서가 아니라, 제품 판단의 기준선을 공유하는 문서다. ```md - 사용자는 요청 상태가 바뀐 뒤 5분 안에 변경 사실을 알 수 있어야 한다. - 첫 버전에서는 앱 내부 알림만 제공하고 이메일과 푸시는 제외한다.

구현과 운영에 남긴 조건

이 정도면 아직 구현이 아니다. 하지만 구현을 시작하기 전에 필요한 판단은 들어 있다. Product Brief는 제품 판단의 가장 짧은 버전이다. 이 기능이 어떤 문제를 다루는지, 누구를 위한 것인지, 이번에 어디까지 할 것인지, 성공을 어떻게 볼 것인지를 적는다. 길어질수록 힘이 빠진다. 좋은 Product Brief는 개발자가 회의 밖에서 다시 읽어도 방향을 잃지 않게 한다.

특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. 이 경계가 분리되면 개발자는 자유로워진다. 구현 선택을 늦출 수 있고, 제품 판단이 바뀌었을 때 코드를 덜 버리게 된다. 제품 판단 문서는 개발 전에 모든 것을 확정하자는 문서가 아니다. 오히려 구현 전에 너무 빨리 굳히면 안 되는 것과 지금은 반드시 정해야 하는 것을 나누기 위해 쓴다.

WebSocket은 구현 선택이다. “5분 안에 알 수 있어야 한다”는 제품 요구에 가깝다. 이메일과 푸시를 제외한다는 문장은 범위를 지킨다. PRD가 이 선을 넘으면 다음 문서들이 모두 흐려진다. '제품 판단 문서: PRD는 구현 지시서가 아니다'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다.

아직 열어 둔 비용

예를 들어 요청 상태 기능을 만든다면 Roadmap은 이렇게 쓸 수 있다. 이 문서들이 약해지면 팀은 너무 빨리 구현으로 도망간다. “알림은 WebSocket으로 보낸다”, “파일 목록은 Redis에 캐시한다” 같은 문장이 PRD에 들어온다. 둘 다 나쁜 기술은 아니지만, 아직 너무 이르다. 사용자가 무엇을 얻어야 하는지 정하지 않은 상태에서 구현 방식이 먼저 굳어지기 때문이다. 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. ```md

마치며

• 지금 정해야 하는 것: 사용자, 문제, 범위, 성공 기준, 제외할 것 - 아직 열어둘 것: 구체 구현, 내부 구조, 저장소, 프로토콜, 배포 방식 md 1. 사용자가 상태를 직접 확인할 수 있게 한다. 2. 상담자가 보류/거절 이유를 구조화해 남길 수 있게 한다. 3. 반복 요청에서 이전 맥락을 보여준다. 4. 상태 변경 알림 채널을 추가한다. 특히 제품에서는 재현 조건을 같이 적어야 의미가 있었다. Roadmap은 날짜표가 아니라 판단 순서다. 무엇을 먼저 배우고, 무엇을 나중에 확장할지 적는다. 특히 작은 제품에서는 “언제까지 다 만든다”보다 “무엇을 검증한 뒤 다음 단계로 간다”가 더 중요하다. 참고: Atlassian PRD 가이드 — https://www.atlassian.