모두가 알지만 누구도 제대로 쓰지 못하는, PRD

얼마 전 진행한 학습과 성장 콘퍼런스 2024에서 PM의 성장에 대해 얘기할 기회가 있었습니다. 이 세션을 준비하면서 저도 역설적으로 ‘PM이 성장하는 지점이 어디일까’ 생각해 볼 수 있었습니다. 물론 PM은 제품을 산출하는 전체 여정을 지나 산출을 함으로써 성장한다고 늘 얘기해 왔고 이 명제는 여전히 유지합니다만, 그 여정에서 레벨업 포인트나 찍은 스킬셋, 획득한 아이템 같은 포인트가 있지 않을까 생각했죠.

PM의 성장은 제품을 산출해 냄으로 이루어진다는 생각은 늘 가지고 있었지만, 제품 개발 프로세스의 어떤 지점이 구체적인 성장으로 연결되는지에 대해서 생각해 본 것은 처음이었습니다. 매우 흥미진진하고, 또 즐거운 경험이었습니다.

하지만 이 고민의 큰 전제는 제품 개발 프로세스이고, 이 프로세스의 기본이자 시작점은 결국 PRD(Product Requirement Document)입니다.

그럼 이제 PRD를 대면해 보기로 합시다

삼성전자에서 십몇 년 전 PRD를 처음 접한 이후로 어디를 가나 저는 PRD를 작성해야 한다고 주장하는 사람이었습니다. 반대로 어느 곳에서도 ‘제대로’ PRD를 쓰는 조직을 만나지는 못했습니다. 그런 조직에서 일하는 방식, 제품을 만드는 과정은 대체로 비슷합니다. 스크린 플로우를 그리고, 여기에서 출발해 피그마나 스케치로 프론트 제작을 먼저 하고 있었습니다. PRD에 대해서는 ‘그런 건 느리다’ 라거나 ‘이렇게 하는 게 더 빠르고 잘한다’는 입장이 많았고, ‘PRD 같은 건 삼성전자 정도 되는 조직에서나 쓰는 거’라는 반응도 있었습니다. 우리는 PRD 대신에 AC(인수 조건, Acceptance Criteria) 문서나 디자인 독을 작성한다는 조직도 만나봤습니다. 그 문서의 이름이 무엇이건 내용과 목적은 PRD를 대신하지 못했다고 저는 확신합니다.

제가 과거에 속했던 어느 조직에서는 PRD라는 이름의 문서를 쓰기로는 했지만, 여전히 필요하다고 생각하지는 않는 듯했습니다. PRD라고 작성한 문서인데 요구 사항(Requirement)이 제대로 정의되어 있지 않아 개발팀이 여전히 제품의 형상이나 정책에 대해서 그려내지 못하고 있습니다. 오히려 “화면정의서를 주어야 백앤드 설계를 할 수 있다”는 말도 한다고 하고, UX 팀에서도 “스크린플로우를 주어야 피그마 작업을 할 수 있다”고 한다는 얘기도 전해 들었습니다.

그러다가 최근 우연히 PRD라는 단어를 다른 분의 글에서 읽을 수 있었고, 꽤 반가웠습니다. 이제 PRD가 비로소 좀 더 일반화되어 가는 걸까요? 그래서 오늘은 PRD를 작성하는 목적은 무엇이고, 누가 써야 하는가에 대해 얘기해 보겠습니다.

정말로, 이제 PRD를 대면해 보기로 합시다

PRD는 제품의 요구 사항을 정의하고 규정하는 문서입니다. 요구 사항이 무엇인지, 그리고 그것이 충족된 제품의 형상이 무엇인지에 대해서 정의가 되어야 하겠죠. 그리고 그래서 이 “요구”의 주어가 누구인지를 결정하는 것이 중요합니다. 지금 PRD를 작성하고 있는 조직이라면, 혹은 PRD 대신 AC 문서나 디자인 독을 작성하는 조직이라면 우리 문서에서 요구 사항을 어떻게 작성하고 있는지, 그 요구 사항의 주어가 누구인지 한번 확인해 보세요.

요구 사항의 주어는 누구여야 할까요? 이 퀴즈의 정답을 우리는 모두 알고 있습니다. 문제 풀이의 강자인 한국인들에겐 이렇게 의도가 뻔한 문제의 답을 찾아내는 것은 쉬운 일이죠. 그런데 우리의 PRD는, 우리의 AC 문서나 디자인 독 문서는 정말 그렇게 작성되고 있을까요?

PRD에서 요구 사항의 주어가 확실하고, 그래서 요구 사항의 형태를 규정하고 나면 자연스럽게 PRD의 목적은 달성됩니다. PRD의 목적은 “제품이 기능하여 요구 사항을 충족하는 형상”을 제품개발팀과 공유하는 것입니다. 저는 이것을 비주얼라이제이션 싱크(Visualization Sync)라고 부릅니다만, 흔히 말하는 제품의 비전(Vision) 따위와는 층위가 다릅니다. 훨씬 더 형이하학적이고 손에 잡힐듯 물리적이어야(Tangible) 합니다.

반대로 거대한 목표, 이를테면 시장의 넘버 원 플레어어가 된다거나, 매출 또는 트래픽을 열 배(10x)로 늘리겠다거나, 정보를 전달하는 과정을 혁신하겠다 같은 것은 PRD에 포함하지 않습니다. 왜냐고요? 열 배 달성하는 것이 목표이건, 두 배가 목표이건 그것이 제품의 요구 사항을 정의하는 데에는 아무런 의미가 없으니까요. 반대로 그런 것을 정의하고 싶은 문서가 따로 있습니다. 아마도 회사의 전략 로드맵이라든가, 3개년 개발 계획이라든가 같은 문서에는 그런 것이 들어 있겠죠. 그것에서부터 출발해 우리가 공략할 타깃 고객이 누구인가를 정의하는 MRD(Market Requirement Document)를 선행으로 작성할 수도 있습니다.

결국 PRD는 제품의 형상을 규정하기 위한 정책을 기술하는 문서가 되어야 합니다. 그것이 PRD를 ‘Source of Truth’라고 부르는 이유이기도 합니다. 만드는 우리도 지금은 정확하게 알지 못하는 ‘제품의 형상’을 함께 만들어가는 과정에서, 어떤 정책을 결정하는 것은 PRD에 근거해야만 합니다.

PRD는 전제 제품 개발 과정의 중심에 있습니다. 우리가 하는 모든 제품 개발이 응당 그러하듯, PRD 역시 한 단계에서 딱 떨어지듯 끝나버리는 산출은 아닙니다. 선행하는 MRD와 후행하는 제품 개발 스프린트는 아래 그림처럼 순서대로 진행되지 않고 계속 상호작용 하면서 버전 업(Version UP)을 해나갑니다.

UX 단계에서 우리가 몰랐던 유즈 케이스(Use Cases)를 발견하는 것은 물론이고, 때로는 페르소나(Persona)에서 심각한 결함을 발견할 때도 있습니다. 그 모든 과정은 너무나도 당연하고 자연스러운 제품 개발의 관점입니다.

간혹 MRD나 PRD가 개발 스프린트 중간에 바뀌는 것을 두고 “제품 개발 과정에서 심각한 문제를 마주”했다거나 “개발 리소스를 낭비하지 않도록 개선해야 한다”라고 생각하는 이들을 마주합니다. 그 생각은 틀렸습니다. 우리는 시장을 잘 모릅니다. 그럼에도 불구하고 그 시장의 문제를 해결하기 위해 PRD를 들고 제품을 개발하고 있습니다. 불분명한 부분을 규정하며 불확실성을 해소해 나가는 것, 그것은 당연한 과정일 뿐 결함이거나 개선의 대상이 아닙니다.

그래서 PRD에는 어떤 내용이 들어가야 할까요?

정의한 목적에 부합할 수 있다면, 자유롭습니다. 어쩌면 누군가는 스크린 플로우를 피그마에 그리면서, 또는 PPTX에 화면 정의서를 그리면서 이 행위가 목적에 부합하다고 생각할 수 있습니다. 불가능하다고 생각하지는 않습니다. 다만 달성하기에 매우 어려울 것이라고 생각합니다.

저보다 훨씬 더 많은 PRD 문서를 학습했을 생성형 AI에 물어보면 아래와 같이 PRD의 구성 요소를 설명해 줍니다.

제품 개요(Product Overview), 기능 요구 사항(Functional Requirements), UI 요구 사항(User Interface Requirements) 등등. 물론 그때그때 다른 말을 하는 생성형 AI를 너무 신뢰할 필요는 없지만, 내용이 당연한 것들 뿐입니다. 제가 강의하고 코칭하는 PRD에서 중요한 것은 “이 내용들을 어떠한 형식으로 작성하고 규정해서 다른 구성원들과 ‘형상을 공유한다’는 목적을 달성하는가”입니다. 잊지 맙시다. PRD의 목적은 그 문서를 작성한 사람과 읽는 사람 간에 비주얼라이제이션 싱크를 갖는 것입니다.

삼성페이의 PRD를 작성했던 10여 년 전부터 저는 꾸준히 가상의 주인공과 주인공의 행위를 묘사하는 방식의 촌스러운 PRD 형식을 유지해 오고 있습니다. 간혹 “페르소나와 시나리오가 너무 유치한 것 아니냐”는 핀잔을 들어본 적도 있고, 더 세련되고 깔끔한 형식의 스펙 문서(Spec doc)들을 마주한 적도 있습니다. 그래도 저는 여전히 페르소나/메인 시나리오 중심으로 구성한 올드 패션(Old-Fashioned) 형식이 목적에 더 부합한다고 생각합니다.

가상의 주인공 페르소나는 MRD에서 규정한 타깃 고객군(Target Segment)을 대표하는 인물로 창조됩니다. 그 인물에게 이름과 나이, 가족 관계, 재산 소득 수준과 취미, 주거 형태와 차량 소유 여부까지 모두 부여합니다. 여기에 꼭 우리 서비스에 대한 숙련도를 함께 규정합니다. 우리 제품이 어느 고객군을 첫 번째 고객(First-customer)으로 접근할 것인지 규정하는 것입니다.

이제 이 인물은 PRD 안에서 메인 시나리오를 중심으로 자신의 삶을 살아가게 될 것입니다. 동시에 우리가 제품의 정책을 결정해야 하는 그 시점에서 결정의 관점을 제공하게 될 것입니다. 나아가 그 인물이 우리 제품을 통해 달성했으면, 하고 바라는 그 행위와 가치를 메인 시나리오로 규정하며 그 과정을 시퀀스로 나눠 다수의 유즈 케이스로 구성하게 될 것입니다.

PRD를 포함하여 모든 문서는 읽는 사람을 위해 쓰여야 합니다. 그리고 그들 간에 동일한 상(Visualization)을 맞춰 내기 위해서는 다른 해석의 여지를 제거해 주어야 합니다. 함축적인 문장, 개조식 나열과 전개, 부정확한 주어와 술어 등 함의적이거나 중의적일 수 있는 내용과 문장을 제거해야 합니다. 온전히, 그리고 정확하게 페르소나의 시나리오와 유즈 케이스를 작성합니다.

마지막으로, 그럼 PRD는 누가 언제 작성해야 할까요? 

PM은 역할입니다. 그리고 그 PM이란 역할을 맡은 이가 PRD를 작성합니다. 더 정확하게는 PRD의 초안 30%를 작성합니다.

그러면 누가 PRD를 100% 완성할까요? 제품을 개발하는 팀 전체입니다. 이들 모두가 제품을 개발하는 과정에서 다 함께 작성해 나가게 됩니다. 제품의 완성과 함께 MRD도 PRD도 모두 완성되어야 합니다. 그리고 PM은 PRD라는 문서를 책임지는 “글”로 제품을 개발하는 사람이 되어야 합니다.

그 사람은 상황에 따라서 대표가 될 수도 있고, 막내 팀원이 될 수도 있습니다. 제품의 특성에 따라서 개발팀 리더(Tech Lead)가 개발 스펙(Tech Spec)으로 간소화하면서 작성할 수도 있고, UX에서 유저 저니(User Journey) 중심으로 작성할 수도 있습니다. 다만 목적을 위해 꾸준히 “글”로 제품을 개발하고 페르소나를 창조할 수 있는 사람으로서, PM이 전담(dedicated role)으로 존재해야 한다고 생각합니다.

저는 ‘PRD가 제품과 함께 완성되어야 한다’는 기준을 아주 중요하게 생각합니다. 그래서 그렇지 않은 모든 경우는, PM이 아니다라고 과감하게 주장하기도 합니다. 여기에서 언급한 “그렇지 않은 경우”에 대해서도 다른 글에서 좀 더 자세히 설명해 보려고 합니다.

PRD의 항목 하나하나 자세히 설명해 보고 싶은 생각도 있지만, 강의나 워크숍과 달리 글로 설명하기 까다로워 충분한 만큼 기술하기 어렵네요. 이 점 양해해 주시기 바랍니다. 다음 글은 기업에서 PM이라는 역할을 가지고 있지만, 성장하지 못하는 경우를 소개할까 합니다.

성장하지 못하는 PM, 그대들은 어떻게 살 것인가.

제품 개발 과정(Agile Product Development Process, APDP)에 대해, 특히 PRD에 대해 궁금한 분들을 위해 커피챗 신청 창구를 만들었습니다. 링크를 참고해 주세요.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.