12장. PRD는 객체 세계의 설계서다

PRD는 기능 설명서가 아니다.

좋은 PRD는 "사용자가 버튼을 누른다"에서 시작하지 않는다. 어떤 객체가 있고, 그 객체가 어떤 상태를 지나고, 누가 어떤 조건에서 그 상태를 바꿀 수 있는지에서 시작한다.

그래서 PRD는 애플리케이션으로 구현될 객체 세계의 설계서다.

Rails 8 기준으로 보면 이 말은 더 선명해진다. Rails는 세상을 resource로 본다. resourceful routing은 객체에 대한 index, show, new, create, edit, update, destroy를 기본 행동으로 묶는다. Active Record는 객체를 모델과 테이블로 고정하고, association은 부모-자식 관계를 코드의 언어로 만든다. enum은 상태를 이름으로 다루게 한다.

그러니까 PRD를 Rails식으로 번역하면 이렇게 된다.

여기서 MECE는 컨설팅 장식어가 아니다. Rails 앱에서 MECE가 깨지면 바로 설계 부채가 된다.

객체가 겹치면 모델이 흔들린다. 후보자와 직원의 경계를 못 나누면 채용 상태와 재직 상태가 한 테이블 안에서 엉킨다. 상태가 겹치면 enum이 거짓말한다. "검토중"과 "승인대기"가 동시에 가능한지 아닌지 모르면 보드는 예쁘지만 운영은 흐려진다. 부모-자식 관계가 흐리면 nested route도 흔들린다. HiringRequest 안의 Candidate인지, Candidate 자체가 독립 resource인지 결정하지 않으면 화면, 권한, 리포트가 모두 흔들린다.

PRD의 정석 구조는 그래서 기능 목록이 아니라 객체 목록에서 시작해야 한다.

• 핵심 업무 객체
• 객체별 속성
• 객체 간 부모-자식 관계
• 객체별 라이프사이클
• 상태별 진입 조건
• 상태별 가능한 액션
• CRUD 권한과 승인 규칙
• 필수 증빙과 기록 위치
• 화면, 라우트, 알림, 잡
• 리포트와 운영 지표
• BDD 시나리오
• 완료 기준과 제외 범위

예를 들어 후보자 관리 PRD를 쓴다면 먼저 이렇게 잡는다.

이 한 표가 있으면 Rails 설계는 훨씬 빨라진다. Candidate는 model이 되고, HiringRequest와 Candidate는 association이 되고, Interview와 Evaluation은 자식 resource가 된다. status는 enum이 되고, offer에서 hired로 가는 조건은 validation 또는 service object가 된다. BDD 시나리오는 request spec 또는 system spec의 원료가 된다.

나쁜 PRD는 화면 단위로만 쓴다.

• 후보자 목록 화면
• 후보자 상세 화면
• 면접 평가 입력 화면
• 오퍼 발송 화면

이런 목록은 필요하지만 충분하지 않다. 화면은 객체 세계의 창문일 뿐이다. 창문부터 설계하면 안쪽 세계가 흐려진다.

좋은 PRD는 먼저 묻는다.

• 이 화면이 보여주는 객체는 무엇인가
• 이 객체의 현재 상태는 무엇인가
• 이 상태에서 허용되는 액션은 무엇인가
• 그 액션을 하면 어떤 상태로 이동하는가
• 누가 그 액션을 할 수 있는가
• 어떤 증빙이 없으면 막아야 하는가
• 어떤 기록이 남아야 하는가
• 어떤 리포트에서 이 상태가 집계되는가

PRD가 이 질문에 답하지 못하면 개발자는 화면을 만들 수는 있어도 시스템을 만들 수 없다.

특히 Rails 8 같은 convention 기반 프레임워크에서는 PRD가 객체 중심일수록 구현이 단순해진다. resource가 분명하면 routes가 분명해진다. association이 분명하면 controller scope가 분명해진다. status가 분명하면 가능한 버튼이 분명해진다. 권한이 분명하면 policy가 분명해진다. BDD가 분명하면 테스트가 분명해진다.

반대로 PRD가 "관리자가 쉽게 처리할 수 있어야 한다" 같은 문장으로 끝나면 앱은 결국 애매한 관리자 화면이 된다. 쉽게가 무엇인지, 처리란 어떤 상태 전이인지, 관리자는 어떤 권한인지, 완료는 무엇인지 아무도 모른다.

PRD는 제품의 감상문이 아니다. PRD는 구현될 세계의 물리법칙이다.

이 책의 언어로 다시 쓰면, PRD는 다음 네 가지를 MECE하게 적는 문서다.

• 객체 모델
• 관계 모델
• 라이프사이클 모델
• CRUD와 상태 전이 권한 모델

이 네 가지가 잡히면 화면은 자연스럽게 나온다. 반대로 이 네 가지 없이 화면부터 쓰면, 프로젝트는 초반에는 빨라 보이지만 후반에는 예외와 권한과 상태 꼬임에 잡아먹힌다.

좋은 PRD는 앱을 만들기 전부터 이미 작은 앱처럼 생겼다.

그 안에는 객체가 있고, 상태가 있고, 관계가 있고, 액션이 있고, 권한이 있고, 증빙이 있고, 완료 기준이 있다. 개발은 그 세계를 Rails 8의 모델, 라우트, 컨트롤러, 뷰, 잡, 테스트로 옮기는 일이다.

그래서 PRD 작성은 기획자의 글쓰기 작업이 아니다.

PRD 작성은 운영 세계를 애플리케이션 세계로 번역하는 일이다.