PRD

만들 것을 정하는 일은 원래 말로 오갔습니다. 기획하는 사람이 개발자 자리로 가서 "결제 화면에 쿠폰 입력칸 하나 넣어 주세요" 라고 말하면 그것이 요구사항이었습니다. 문장 하나로 끝나니 빠르고, 급한 일에는 실제로 그게 제일 빨랐습니다.

문제는 그 한 문장에 적히지 않은 것들이었습니다. 쿠폰이 만료됐으면 무슨 문구를 보여 줄지, 이미 할인이 걸린 주문에도 또 쓸 수 있는지, 다른 사람 쿠폰 번호를 넣으면 어떻게 되는지는 아무도 말하지 않았습니다. 개발자는 물어볼 수도 있었지만 물어볼 항목이 열 개가 넘으면 대개 적당히 정해서 만들었습니다. 그렇게 2주가 지나 화면이 나오면 그제야 "만료된 쿠폰은 아예 안 보이게 하려던 건데요" 같은 말이 나왔고, 같은 자리를 다시 만드는 데 또 이틀이 들었습니다.

되돌아보면 문제는 정보가 모자란 것이 아니라 정보가 대화에만 있었다는 점입니다. 그 자리에 없던 디자이너는 만료 문구를 모르고, 한 달 뒤 합류한 사람은 왜 그렇게 정했는지 물을 데가 없고, 반년 뒤에는 정한 사람조차 기억하지 못합니다. 회의에서 결정이 나도 그 결정은 회의가 끝나는 순간 사라졌습니다. 페이지덱도 첫 결제 화면을 만들 때 환불 정책을 회의에서 정했는데, 여덟 달 뒤 같은 문의가 들어왔을 때 그 결정을 기억하는 사람이 아무도 없어 처음부터 다시 논의했습니다.

PRD는 그 대화를 한곳에 적어 두자는 제안입니다. 적는 대상은 화면 그림이 아니라 판단의 근거와 경계입니다. 왜 지금 이것을 하는지, 이번에 어디까지 하고 무엇은 안 하는지, 무엇이 되면 끝난 것으로 볼지를 적습니다. 이렇게 적어 두면 회의에 없던 사람도 같은 것을 읽게 되고, 두 달 뒤에 "이거 왜 이렇게 만들었죠" 라는 질문이 나왔을 때 답이 문서에 남아 있습니다. 대화는 여전히 필요하지만, 대화의 결론이 증발하지 않는 것이 달라집니다. 적는 양이 많을수록 좋은 문서가 되지는 않습니다. 쿠폰 기능이라면 버튼 색이나 문구의 자간은 이 문서에 들어가지 않고, 만료된 쿠폰을 어떻게 처리할지와 이번에 관리자 발급 화면은 만들지 않는다는 결정은 들어갑니다. 나중에 누군가 다시 물어볼 항목인지가 가르는 선입니다.

PRD 아래 묶인 용어는 두 갈래로 나뉩니다. 문서를 이루는 칸들(구성 요소)과, 그 칸을 비워 두었을 때 실제로 벌어지는 일(현상)입니다. 앞의 다섯은 문서를 쓸 때 채워야 할 자리이고, 마지막 하나는 채우지 않았을 때 돌아오는 청구서입니다.

구성 요소는 다섯 칸입니다. 순서에도 뜻이 있어서, 할 일을 적는 칸이 먼저 오고 그 일을 어떤 조건에서 어디까지 하는지가 뒤따릅니다.

1. 기능 요구사항 — 제품이 해야 하는 동작을 적습니다. "사용자가 결제 화면에서 쿠폰 코드를 입력하면 할인 금액이 즉시 표시된다" 처럼 주어와 동작과 결과가 들어간 문장으로 씁니다. 여기서 흔히 빠지는 것은 정상 경로가 아닌 경우입니다. 코드가 틀렸을 때, 이미 쓴 코드일 때, 유효 기간이 지났을 때 각각 무엇을 보여 줄지까지 적어야 개발자가 되묻지 않고 만들 수 있습니다.
2. 비기능 요구사항 — 동작이 아니라 품질 조건입니다. 할인 금액이 표시되기까지 1초를 넘지 않는다, 쿠폰 번호는 로그에 그대로 남기지 않는다, 키보드만으로도 입력칸에 닿을 수 있다 같은 항목이 여기 들어갑니다. 적지 않으면 기능은 다 되는데 3초씩 걸리는 화면이 나오고, 그때 가서 고치면 구조를 통째로 손대야 하는 경우가 많습니다.
3. 성공 기준 — 이 작업이 성공했다고 부를 조건입니다. 만들었다는 사실이 아니라 만든 뒤에 무엇이 달라져야 하는지를 적습니다. "쿠폰 사용률 향상" 은 기준이 아니고, "출시 4주 뒤 결제 완료 건의 15퍼센트 이상에서 쿠폰이 쓰인다" 는 기준입니다. 숫자와 시점이 있어야 나중에 이 문서를 열고 맞았는지 틀렸는지 판정할 수 있습니다.
4. 범위 — 이번에 만들기로 한 것의 경계입니다. 목록으로 적되 항목마다 얼마나 만들지까지 붙입니다. 쿠폰 입력칸을 만든다는 문장 하나로는 관리자용 쿠폰 발급 화면이 포함되는지 아닌지가 갈리지 않습니다. 결제 화면에 입력칸을 붙이고, 코드는 한 종류만 처리하고, 발급은 이번에 운영팀이 직접 넣는 방식으로 간다고 적으면 세 줄로 경계가 섭니다. 경계가 흐린 채로 착수하면 일정 추정도 같이 흐려집니다. 2주라고 답한 사람과 6주라고 답한 사람이 서로 다른 범위를 머릿속에 그리고 있었던 것뿐인 경우가 많습니다.
5. 범위 밖 — 이번에 하지 않기로 한 것을 대놓고 적는 칸입니다. 안 하는 것을 적는 게 이상해 보이지만 실무에서 가장 값을 하는 칸입니다. "자동 적용 쿠폰은 이번에 하지 않습니다" 한 줄이 있으면 3주 뒤에 그 이야기가 나왔을 때 논의가 5분 만에 끝납니다. 그 줄이 없으면 같은 대화가 매주 열립니다.

현상 갈래에는 스코프 크리프 하나가 있습니다. 합의 없이 범위가 슬금슬금 늘어나는 현상인데, 앞의 두 칸이 비어 있을 때 거의 자동으로 따라옵니다. 처음에 쿠폰 입력칸 하나였던 일이 관리자 발급 화면, 사용 내역 조회, 만료 알림 메일로 불어나는 식입니다. 한 번에 크게 늘지 않고 매번 "이건 작으니까" 라는 말과 함께 붙기 때문에 어느 시점에 무엇이 늘었는지 아무도 짚지 못합니다. 처음 2주로 잡았던 일이 6주가 되는 과정에 한 번에 4주가 늘어난 날은 없습니다. 범위와 범위 밖이 문서에 적혀 있으면 새 요청이 들어왔을 때 문서를 고치는 결정을 거치게 되고, 그 한 단계가 일정 협의를 다시 열게 만듭니다.

칸을 채우는 사람과 그 칸을 읽는 사람은 다릅니다. 쓰는 쪽은 대개 제품을 맡은 프로덕트 매니저 한 사람입니다. 읽는 쪽은 넷으로 갈리고, 각자 자기가 쓸 칸만 봅니다. 개발자는 기능 요구사항과 비기능 요구사항을 보고 만들 수 있는지와 얼마나 걸릴지를 답하고, 디자이너는 범위와 기능 요구사항을 보고 그려야 할 화면이 몇 개인지 셉니다. 세일즈와 고객 성공은 범위 밖을 먼저 열어 고객에게 아직 말하면 안 되는 것을 확인하고, 착수를 승인하는 쪽은 성공 기준만 보고 이 일에 사람을 붙일지 정합니다. 그래서 한 칸이 비면 그 칸을 읽는 사람만 멈춥니다. 성공 기준이 비어 있으면 개발은 시작되는데 승인이 나지 않고, 범위 밖이 비어 있으면 만드는 쪽은 멀쩡한데 영업이 고객에게 없는 기능을 약속합니다.

이 여섯 개를 한 문서에 담는다고 해서 PRD가 모든 문서를 대신하지는 않습니다. 이 문서는 갈라지는 지점이지 종착지가 아닙니다. PRD의 요구를 사용자 관점 한 문장씩으로 쪼개면 유저 스토리가 되고, 아직 손대지 않은 항목은 제품 백로그에 순서대로 쌓입니다. 어떤 상황에서 제품이 어떻게 굴어야 하는지를 예외까지 못 박아 두어야 한다면 그 부분은 제품 정책으로 따로 떼어냅니다. 쿠폰 하나에도 중복 사용·환불 시 복구·부분 취소 같은 규칙이 스무 줄쯤 붙는데, 그것까지 PRD 본문에 넣으면 읽어야 할 사람이 앞부분에서 지칩니다. 본문에는 쿠폰을 중복으로 쓸 수 없다는 결정과 그렇게 정한 이유만 남기고, 어떤 조합에서 무엇이 우선하는지를 적은 표는 정책 문서로 보낸 뒤 링크만 겁니다.

"그건 PRD에 없는 내용인데요. 이번 범위 밖으로 잡혀 있습니다."

새로 들어온 요청을 지금 일정에 끼워 넣을 수 없다는 뜻이고, 하려면 문서를 고치고 일정을 다시 잡자는 제안입니다.

"성공 기준이 사용자가 편해진다로 돼 있어요. 넉 달 뒤에 이걸로 판정할 수 있을까요?"

측정할 수 없게 적힌 칸을 숫자와 시점이 든 문장으로 바꿔 달라는 요청입니다.

"초안 올려 뒀습니다. 목요일까지 코멘트 주시면 금요일에 확정하고 개발 착수하겠습니다."

문서를 언제 닫을지 미리 알려 이후에 들어오는 의견은 변경 절차를 타게 하겠다는 신호입니다.

페이지덱에서 이 문서를 쓰는 사람은 지현입니다. 쿠폰 기능을 예로 들면, 지현이 왜 지금 이것을 하는지와 이번에 어디까지 할지를 먼저 적어 초안을 공유하고, 사흘 동안 각자 자기 자리에서 읽습니다. 태오는 기능 요구사항에서 예외 경우가 비어 있는 곳을 짚어 만료된 코드와 중복 사용 두 가지를 되묻고, 민서는 할인 금액이 표시되는 위치가 정해지지 않았다는 점을 지적합니다. 수아는 기업 고객 계약에 이미 다른 할인이 걸려 있어 이번 쿠폰과 겹치면 곤란하다는 사실을 댓글로 남깁니다.

댓글이 붙는 자리를 보면 그 문서가 어디가 성긴지 그대로 드러납니다. 세 사람이 같은 문단에 댓글을 달았다면 그 문단은 문장이 부족한 것이 아니라 결정이 아직 안 난 자리입니다. 지현은 그 셋을 반영해 범위 밖에 기업 고객 계약 건을 명시하고 금요일에 문서를 닫습니다. 그다음 주에 다른 요청이 들어오면 이 문서를 열어 고치고, 고친 날짜와 이유를 문서 맨 아래에 한 줄로 남깁니다.

가장 흔한 오해는 이 문서가 화면 설계서라고 보는 것입니다. 요구사항을 적으라고 하면 화면부터 그리게 되는 것은 자연스럽습니다. 화면이 제일 구체적이고, 그림이 있어야 이야기가 빨리 끝나는 것도 사실입니다. 그런데 화면을 먼저 확정하면 해결책 하나가 문제 정의 자리에 앉아 버립니다. 쿠폰 입력칸을 넣기로 적어 두면 그 뒤로는 아무도 결제 단계에서 자동으로 할인을 적용하는 방법을 떠올리지 않습니다. 그대로 두면 팀은 더 나은 방법이 있었는지 확인하지 못한 채 만들고, 출시 뒤에 쓰임이 적어도 왜 그런지 되짚을 근거가 남지 않습니다.

두 번째는 한 번 쓰면 못 바꾸는 계약처럼 다루는 것입니다. 확정이라는 말이 붙고 착수 신호로 쓰이니 그렇게 읽히기 쉽습니다. 하지만 만들면서 알게 되는 것이 반드시 생깁니다. 결제 대행사가 쿠폰 금액을 부분 환불로 처리하지 못한다는 사실은 붙여 보기 전에는 알 수 없습니다. 바꾸지 못하는 문서로 다루면 팀은 두 가지 중 하나를 합니다. 문서를 무시하고 각자 알아서 만들거나, 문서에 맞추느라 안 되는 방식을 억지로 만듭니다. 바꾸되 언제 왜 바꿨는지 남기는 쪽이 정답에 가깝고, 그 기록이 다음 분기에 같은 함정을 피하게 해 줍니다. 문서 맨 아래에 10월 12일에 결제 대행사 제약으로 부분 환불 시 쿠폰 복구를 범위 밖으로 옮겼다고 한 줄 적어 두면 충분합니다.