서비스 기획 용어 17개는 쓰이는 단계로 나누면 안 헷갈린다

결론부터

서비스 기획 용어가 헷갈리는 이유는 다른 단계에서 쓰는 말을 한 줄에 놓고 비교하기 때문이다. 그래서 17개를 역할과 네 단계로 나눴다.

역할 — 누가 결정하나: 서비스 기획자, PM, PO
문제 정의 — 무엇이 문제인가: 역기획, 페르소나, JTBD
해법 설계 — 어떻게 풀고 무엇부터 하나: 유저 플로우, 와이어프레임, 정책서, RICE, MoSCoW
명세 — 무엇을 만들지 어떻게 전하나: PRD, 유저 스토리, 인수 조건
검증 — 문제가 풀렸는지 어떻게 아나: 북극성 지표, AARRR, A/B 테스트

이 분류는 어떤 원전에도 없는 내 정리다. 각 용어의 정의는 원저자 글이나 표준 문서에서 가져왔고, 원전을 찾지 못한 한국 업계 용어는 그렇다고 적었다. 짝끼리의 비교는 내 해석이다.

역할: PO 는 문서마다 크기가 다르다

세 직함은 출처가 다르다. PO 는 스크럼 문서에서, PM 은 제품 조직에서, 서비스 기획자는 한국 업계에서 나온 말이다.

PO(Product Owner) — 스크럼 가이드 2020이 정한 책임이다. 스크럼 팀이 만든 제품의 가치를 극대화할 책임을 진다. 제품 목표를 세우고 백로그 항목을 작성하고 순서를 정한다.
PM(Product Manager) — Marty Cagan 은 2016년 글에서 PO 책임을 PM 일의 “아주 작은 일부(a very minor part)”라고 썼다. 그가 든 기준은 백로그를 관리만 하는지, 어려운 문제를 푸는지다.
서비스 기획자 — 표준 정의를 찾지 못했다. 디지털 인사이트 2023년 기사는 기획부터 QA, 유지보수까지 전 과정을 맡는 직무로 설명한다.

여기서 뒤집힌다. 같은 기사는 PO 를 결정권을 가진 “미니 CEO”로, PM 을 일정과 의견을 조율하는 관리 역할로 쓴다. 토스의 구분이라며 든 설명은 또 다르다. 성장 궤도에 오른 제품을 운영하면 PM, 새로운 서비스를 발굴하면 PO 다.

Cagan 의 PO 는 PM 의 작은 일부이고, 이 기사의 PO 는 미니 CEO 다. 둘 중 하나가 틀렸다기보다 말하는 층이 다르다. 스크럼 가이드의 PO 는 팀 안의 책임이고, 기사의 PO 는 회사가 붙인 직함이다.

그래서 직함으로는 비교할 수 없다. 공고나 조직을 볼 때는 이 사람이 실제로 무엇을 결정하는지를 확인해야 한다. PM 은 Project Manager 의 줄임말로도 쓰이니 그것도 같이 본다.

문제 정의: 누구의 문제인지와 어떤 상황의 문제인지는 다른 질문이다

역기획 — 출시된 서비스를 보고 기획 의도와 정책을 거꾸로 추정하는 공부법이다. 원전을 찾지 못했고, 이 정의는 쓰임새를 보고 내가 적은 것이다. 도그냥의 2026년 글도 혼자 공부하는 방법으로 유명하다고 소개할 뿐 정의하지는 않는다.
페르소나 — NN/g의 정의는 전형적이거나 목표로 삼는 사용자를 “가상이지만 현실적으로(fictional, yet realistic)” 묘사한 것이다. Alan Cooper 의 회고 글에 따르면 그는 사용자 인터뷰에서 목표·과업·숙련도로 갈리는 패턴을 찾고, 그 집단마다 이름을 붙였다. 가상이어도 지어내는 것은 아니다.
JTBD(Jobs to Be Done, 해야 할 일) — Christensen 등은 『Competing Against Luck』에서 job 을 “사람이 특정 상황에서 이루려는 진전(the progress that a person is trying to make in a particular circumstance)”으로 정의한다.

역기획은 벤치마킹과 자주 섞인다. 벤치마킹은 우리에게 가져올 사례를 찾는 일이고, 역기획은 그 서비스가 왜 그렇게 정했는지를 추정하는 일이다. 전자의 산출물은 적용안, 후자의 산출물은 가설이다.

페르소나는 누구를 묻고, JTBD 는 어떤 상황에서 무엇을 이루려는가를 묻는다. 배달앱으로 지어낸 예를 들면 이렇다.

페르소나 — 혼자 사는 30대 직장인
JTBD — 퇴근길에 고민 없이 저녁을 해결한다

같은 사람도 주말에는 다른 진전을 원할 수 있다. 그래서 둘은 대체 관계가 아니라 다른 축이다.

해법 설계: 흐름, 배치, 규칙, 순서는 따로 그린다

흐름과 배치는 그림으로 그린다.

유저 플로우 — 사용자가 작업을 끝내기까지 거치는 단계와 분기다. NN/g는 플로차트가 복잡한 작업 흐름을 기록하는 데 유용하지만 화면 맥락은 빠진다고 본다.
와이어프레임 — 페이지 단위의 배치 아이디어를 보여주는 산출물이다. 같은 글에 따르면 사용자 동작에 따라 화면이 바뀌는 앱을 보여주기에는 덜 유용하다.

유저 플로우는 화면 사이를, 와이어프레임은 화면 안을 그린다. NN/g 는 둘을 합친 형식을 와이어플로우라고 부른다.

정책서 — 화면이 아니라 규칙을 적는 문서다. 쿠폰을 중복 적용할 수 있는지, 주문을 취소하면 쿠폰이 돌아오는지 같은 내용이다. 공식 정의를 찾지 못했고 회사마다 양식이 다른 한국 업계 용어다.

무엇부터 할지는 우선순위 기법으로 정한다.

RICE — Intercom 의 Sean McBride 가 2018년에 쓴 글에 나온다. 일한 시간당 총 영향을 점수로 낸다.
MoSCoW — DSDM 문서의 네 분류다. Must 는 프로젝트가 인도를 보장하는 최소 범위, Should 는 중요하지만 빼도 해법이 성립하는 것, Could 는 바라지만 덜 중요한 것, Won’t 는 이번 기간에 하지 않기로 합의한 것이다.

RICE 공식은 아래와 같다. 숫자는 계산을 보이려고 넣은 예시이고 측정값이 아니다.

RICE = (Reach × Impact × Confidence) / Effort

Reach      기간당 영향받는 사람 수        1000
Impact     3 / 2 / 1 / 0.5 / 0.25       2
Confidence 100% / 80% / 50%             80%
Effort     인월(person-month)            2

(1000 × 2 × 0.8) / 2 = 800

RICE 는 후보를 숫자로 줄 세우고, MoSCoW 는 이번 범위에 넣을지 뺄지 합의한다. 질문이 달라서 함께 쓸 수도 있다. 특히 Won’t 는 빼기로 한 항목을 기록해 나중에 슬쩍 다시 들어오지 못하게 막는 칸이다.

명세: PRD 는 문서이고 유저 스토리는 문서가 아니다

PRD(Product Requirements Document, 제품 요구사항 문서) — Marty Cagan 의 2005년 글은 제품의 목적, 기능, 동작을 명확하게 적는 문서로 정의한다. 시장의 기회를 적는 MRD, 2~5년 비전을 적는 제품 전략과 구분하고, PRD 는 특정 릴리스 하나를 설명한다고 본다.
유저 스토리 — Agile Alliance는 작업을 나눈 기능 증분으로 설명하고, 만드는 순서와 관계없이 그 자체로 가치를 더해야 한다고 쓴다. 같은 글은 유저 스토리가 “문서가 아니다(is not a document)”라고 못 박는다.
인수 조건 — 스토리가 완료됐다고 판단하는 기준이다. Agile Alliance 용어집은 이를 따로 정의하지 않고 인수 테스트를 소프트웨어 동작의 형식적 기술로 정의한다. 기준을 적은 것이 인수 조건이고, 그 기준을 통과·실패로 돌리는 것이 인수 테스트라고 나는 이해했다.

Agile Alliance 연표에는 스토리 템플릿이 두 개 있다. 2001년의 역할-기능-효용과 2006년의 Given-When-Then 이다. 아래는 앞의 쿠폰 정책을 두 템플릿으로 지어낸 예다.

사용자로서 주문을 취소하면 쿠폰을 돌려받고 싶다.
다음 주문에 다시 쓰기 위해서다.

Given 쿠폰을 적용해 결제한 주문이 있다
And   그 쿠폰의 유효기간이 남아 있다
When  사용자가 배송 전에 주문을 취소한다
Then  쿠폰이 사용 가능 상태로 돌아온다

위 두 줄이 만들 이유를, 아래 네 줄이 완료 기준을 말한다. 쿠폰을 돌려준다는 규칙은 정책서에도 있어야 한다. 스토리는 작업 단위이고 정책은 서비스 전체의 규칙이기 때문이다.

검증: 지표 셋은 서로 다른 질문에 답한다

북극성 지표 — Amplitude의 정의는 고객이 제품에서 얻는 가치를 가장 잘 담는 지표 하나다. 팀이 제품으로 움직일 수 있는 입력 지표 3~5개를 함께 둔다.
AARRR — Dave McClure 가 내놓은 해적 지표다. Acquisition(획득), Activation(활성화), Retention(유지), Referral(추천), Revenue(수익) 다섯 단계로 사용자 흐름을 나눈다. 발표 연도는 자료마다 달라서 적지 않았다.
A/B 테스트 — 『Trustworthy Online Controlled Experiments』(Kohavi 외, 2020)의 가장 흔한 형태는 사용자를 변형들에 무작위로, 지속적으로 나누는 것이다. 같은 사용자는 여러 번 방문해도 같은 변형을 받는다.

같은 책은 OEC(Overall Evaluation Criterion, 종합 평가 기준)를 실험의 목적을 재는 정량 척도로 정의한다. 수익만으로는 OEC 가 부족하다고도 쓴다. 수익만 보면 웹페이지를 광고로 덮는 쪽으로 갈 수 있어서다.

북극성 지표는 방향을, AARRR 은 새는 곳을, A/B 테스트는 인과를 묻는다. KPI 는 이 셋과 같은 층의 말이 아니다. Amplitude 의 다른 글은 북극성 지표를 팀이 이미 보는 “여러 운영 KPI 위에 놓이는(sits above the many operational KPIs)” 결과 하나로 설명한다. KPI 자체의 표준 정의는 찾지 못했다.

그럼 유저 스토리가 있으면 PRD 는 안 쓰나

그렇지 않다. 둘은 단위가 다르다. PRD 는 릴리스 하나를 설명하고, 스토리는 그 안의 작업을 쪼갠 증분이다. 한쪽이 다른 쪽을 대체하는 관계로 정의되어 있지 않다.

다만 PRD 라는 이름의 쓰임은 넓다. Cagan 의 글도 각주에서 회사마다 용어가 다르고, 시장·제품·인터페이스 요구사항을 문서 하나에 담는 곳도 여러 문서로 나누는 곳도 있다고 밝힌다. 내가 인용한 글이 2005년 글이라는 점도 감안해야 한다.

원전을 찾지 못한 것과 읽지 못한 것

역기획, 정책서, 서비스 기획자에는 원전이나 표준 정의를 찾지 못했다. 이 글의 설명은 업계 쓰임새 기준이다.
네 단계는 설명을 위한 분류다. 실제 일은 순서대로만 가지 않고, 검증 결과를 보고 문제 정의로 돌아간다.
책은 통독하지 않았다. 『Competing Against Luck』과 『Trustworthy Online Controlled Experiments』는 공개 발췌만 확인했다.
HBR 의 JTBD 원문은 확인하지 못해 책 발췌의 정의를 썼다.
연도가 다른 자료가 섞여 있다. 스크럼 가이드는 2020년판, RICE 는 2018년, PRD 는 2005년 글 기준이다.

정리

헷갈리는 짝은 질문 하나로 가를 수 있다.

헷갈리는 짝	가르는 질문
PM / PO	이 회사에서 실제로 무엇을 결정하나
역기획 / 벤치마킹	의도를 추정하나, 적용할 사례를 찾나
페르소나 / JTBD	누구인가, 어떤 상황의 무슨 진전인가
유저 플로우 / 와이어프레임	화면 사이인가, 화면 안인가
RICE / MoSCoW	줄을 세우나, 이번 범위를 가르나
PRD / 유저 스토리	릴리스 하나의 문서인가, 작업 증분인가
북극성 지표 / KPI	가치 결과 하나인가, 그 아래 여러 운영 지표인가

다음 편부터 하나씩 깊게 다룬다.