페르소나는 지어내는 게 아니고, JTBD 는 기능 목록이 아니다

결론부터

1편에서 페르소나와 JTBD 를 문제 정의 단계에 함께 놓았다. 둘 다 “사용자를 이해한다”는 말로 묶이지만 묻는 것이 다르다.

페르소나 — 누구를 위해 설계하나. 조사에서 공통 패턴을 모아 만든 대표 원형이다
JTBD(Jobs to Be Done) — 어떤 상황에서 어떤 진전을 이루려 하나. 제품이 아니라 진전이 단위다

둘 다 자주 반대로 쓰인다.

페르소나를 나이·성별·직업으로만 채운다 → 원저자가 구분하려던 인구통계 세그먼트로 돌아간다
JTBD 를 “쿠폰을 필터링하고 싶다” 같은 기능 요구로 쓴다 → job 이 아니라 해법을 적은 것이 된다

페르소나는 가상이어도 지어낸 것이 아니고, job 은 기능이 아니라 상황 속의 진전이다. 아래는 각 개념의 원저자 글에서 정의와 맥락을 확인한 것이다. 두 개념을 비교한 부분은 내 해석이고, 그렇다고 표시했다.

페르소나는 인터뷰에서 나온 패턴에 이름을 붙인 것이다

NN/g 의 정의는 이렇다. 페르소나는 제품의 전형적이거나 목표로 삼는 사용자를 “가상이지만 현실적으로(fictional, yet realistic)” 묘사한 것이다. 같은 글은 페르소나가 사용자를 정확히 나타내려면 사용자 조사에 근거해야 한다(must be based on user research)고 쓴다.

“가상”과 “조사 기반”이 한 문장에 같이 있는 이유는 기원을 보면 풀린다. Alan Cooper 가 2008년 자기 회사 블로그에 쓴 「The origin of personas」(현재는 아카이브로만 열린다)에 과정이 남아 있다.

1983년 — 프로젝트 관리 프로그램을 만들면서 사용할 법한 동료와 지인을 인터뷰했다. 그중 광고회사에서 일정과 인력 배치를 맡던 Kathy 가 그의 “첫 번째 원시적인 페르소나(first, primitive, persona)”의 바탕이 됐다
설계는 혼자 했다. 산책하면서 Kathy 를 느슨하게 본뜬 프로젝트 관리자를 연기하며 프로그램에 기능을 요구하는 식이었다
1990년 — 컨설팅을 시작하면서 상황이 바뀌었다. 직접 만들 때는 옳다고 생각하는 것을 만들면 됐지만, 이제는 고객사를 설득해야 했다. 그는 이 필요가 페르소나를 정식화하게 만들었다고 쓴다
1995년 — Sagent Technologies 의 고객 후보 여럿을 만나 업무와 목표를 묻는 열린 질문을 던졌다. 사용자 간 차이가 컸는데도 몇 번의 인터뷰 만에 뚜렷한 패턴이 나왔다. 사용자는 목표, 과업, 숙련도로 구분되는 세 집단으로 나뉘었다
그 세 집단에 Chuck, Cynthia, Rob 이라는 이름을 붙였다. Cooper 는 이 셋을 “최초의 진짜 목표 지향 페르소나(the first true, Goal-Directed, personas)”라고 부른다

여기서 순서가 중요하다. 인터뷰가 먼저고 이름은 나중이다. 이름과 얼굴은 패턴을 개발팀에 전달하려고 붙인 것이다. Cooper 는 이후 회의에서 자기 관점이 아니라 세 사람의 관점으로 설계를 설명했고, 엔지니어들이 “Cynthia 라면 어떻게 할까”를 말하기 시작했다고 쓴다.

같은 글에서 Cooper 는 이 방식을 “논리에 반한다(counter-logical)”고 표현한다. 논리대로라면 사용자 집단을 훑어 요청 기능을 모으고 전부 넣은 제품을 만든다. 그는 이것을 “원하는 기능의 총합(the sum of all desired features)”이라 부르고, 기껏해야 조금 효과가 있을 뿐이라고 본다. 페르소나는 모두를 위한 설계 대신 특정한 사람을 위한 설계를 강제하는 장치다. NN/g 도 같은 이유로 특정한 개인에 집중해 모두를 위한 설계를 피하라고 쓴다.

페르소나는 만드는 방식에 따라 믿을 수 있는 정도가 다르다

NN/g 의 Page Laubheimer 는 2020년 글에서 페르소나를 근거에 따라 세 가지로 나눈다.

유형	근거	같은 글의 경고
프로토(가벼운) 페르소나	새 조사 없이 팀의 기존 지식과 추측으로 워크숍에서 만든다	팀의 틀린 가정을 되울리는 반향실이 될 수 있다
정성 페르소나	인터뷰·사용성 테스트·현장 조사를 주제별로 코딩하고 겹치는 패턴을 찾는다	표본이 작아 각 페르소나가 사용자의 몇 할인지는 알 수 없다
통계 페르소나	정성 조사로 주제를 잡은 뒤 설문을 돌려 군집 분석을 한다	품이 가장 많이 들고 통계 전문 인력이 필요하다

Cooper 가 한 방식은 두 번째에 가깝다고 나는 본다. 같은 글은 대부분의 팀에 정성 페르소나가 가장 맞는다고 본다. 프로토 페르소나가 정성 페르소나와 겉모습이 같다는 점이 함정이다. 둘 다 이름과 사진과 인용문이 붙지만, 하나는 조사에서 나왔고 하나는 팀의 머릿속에서 나왔다.

페르소나를 인구통계로 채우면 마케팅 세그먼트로 돌아간다

페르소나 양식에는 대개 나이, 성별, 직업 칸이 있다. NN/g 정의 글도 이 항목들을 행동, 필요, 걱정, 목표와 함께 들고 있다. 문제는 앞의 칸만 채우고 끝낼 때다.

Cooper 는 같은 글에서 이 구분을 직접 한다. 제품 마케팅도 오래전부터 페르소나 비슷한 것을 써왔지만, 그것은 인구통계 세그먼트를 정의하려는 것이었고 페르소나는 그것과 다르다고 쓴다. 그가 Sagent 사용자를 가른 기준도 나이가 아니라 목표·과업·숙련도였다.

NN/g 의 「Personas vs. Jobs-to-Be-Done」(Laubheimer, 2017)도 같은 지적을 한다. 페르소나는 인구통계나 개인 정보보다 더 들어가야 하는데, 많은 페르소나가 실은 “페르소나로 위장한 마케팅 세그먼트(marketing segments being masqueraded as personas)”라는 것이다.

배달앱으로 지어낸 예를 들면 차이가 이렇다.

[인구통계만 채운 칸]
34세 / 여성 / 서울 거주 / 회사원

[설계를 바꾸는 칸]
퇴근 후 지쳐서 메뉴를 고르는 데 시간을 쓰고 싶지 않다
쿠폰이 붙은 가게부터 본다
최소 주문 금액을 맞추려고 메뉴를 하나 더 담는 일이 잦다

위 칸은 설계에 아무 말도 하지 않는다. 34세를 35세로 바꿔도 화면은 그대로다. 아래 칸은 쿠폰 노출 위치, 최소 주문 금액 안내 같은 결정으로 바로 이어진다. 아래 내용은 지어낸 예이고, 실제로는 인터뷰에서 나와야 한다.

페르소나의 칸이 설계 결정 하나라도 바꾸지 못하면 그 칸은 지워도 된다. NN/g 정의 글도 설계와 무관한 세부를 넣지 말라고 쓴다. 관련 없는 세부가 관련 있는 세부를 묻는다는 이유다.

JTBD 의 job 은 특정 상황에서 이루려는 진전이다

Christensen 등은 『Competing Against Luck』 2장 발췌에서 job 을 이렇게 정의한다.

We define a “job” as the progress that a person is trying to make in a particular circumstance.

정의의 단어마다 뜻이 있다. 같은 발췌에서 확인한 것만 적는다.

진전(progress) — 목표나 열망을 향한 움직임이다. 2장 제목이 “제품이 아니라 진전(Progress, Not Products)”이다
상황(circumstance) — job 은 그것이 생기는 구체적 맥락에 비추어서만 정의되고, 해법도 그 맥락에 맞춰서만 만들어진다
차원 — job 에는 기능적 차원뿐 아니라 사회적·감정적 차원이 있다
범위 — 이 정의는 고객이나 고객의 문제를 분류하는 새로운 방법이 아니라고 못 박는다

마지막 줄이 페르소나와 갈리는 지점이다. job 은 사람을 묶는 범주가 아니다. 같은 사람도 상황이 바뀌면 다른 job 을 갖고, 다른 사람도 같은 상황에서는 같은 job 을 가질 수 있다.

Christensen Institute 의 JTBD 페이지도 같은 대비를 쓴다. 기존 마케팅이 시장의 인구통계나 제품 속성에 집중하는 반면, 이 이론은 사람이 왜 그 선택을 하는지를 설명하려 한다. 같은 페이지는 모든 job 에 기능적·사회적·감정적 힘이 작용한다고 쓴다.

배달앱으로 지어낸 job 을 세 차원으로 나누면 이렇다.

차원	퇴근길에 저녁을 시키는 상황
기능	고민 없이 빨리 저녁을 해결한다
사회	같이 사는 사람에게 대충 때운다는 인상을 주지 않는다
감정	이번 달 식비를 넘겼다는 죄책감 없이 시킨다

세 번째 줄이 쿠폰과 이어진다. 쿠폰이 할인 금액이 아니라 죄책감을 덜어주는 장치로 쓰인다면, 쿠폰을 어디에 언제 보여줄지가 달라진다. 이 해석은 지어낸 예 위의 내 추론이다.

밀크셰이크를 산 사람은 나이가 아니라 출근길로 설명됐다

JTBD 하면 따라오는 밀크셰이크 사례는 HBS(하버드 경영대학원)의 Working Knowledge 2011년 기사로 확인했다. Christensen 의 MBA 수업과 교안을 바탕으로 기자 Carmen Nobel 이 쓴 글이다. Christensen 본인이 쓴 글은 아니라는 점을 감안한다.

처음 — 한 패스트푸드 체인이 밀크셰이크 판매를 늘리려고 시장을 제품과 인구통계로 나눴다. 그 인구통계에 맞는 사람들에게 이상적인 밀크셰이크의 특징을 물었고, 답에 맞춰 바꿨다. 판매는 늘지 않았다
다시 — 연구자가 한 매장에서 하루 종일 누가 밀크셰이크를 사는지 기록했다. 이른 아침에 포장해 가는 손님이 많았다. 다음 날 아침에는 밀크셰이크를 들고 나가는 손님을 인터뷰해 무슨 job 을 위해 샀는지 물었다
job — 길고 지루한 출근길을 버티고, 점심까지 배고픔을 막고, 빈 한 손을 바쁘게 해줄 것이 필요했다
경쟁자 — 이 job 에서 밀크셰이크는 베이글이나 도넛 대신 고용됐다. 기사는 비교적 깔끔하고 허기를 달래준다는 점을 이유로 든다
다른 job — 같은 밀크셰이크가 어린 자녀에게 주는 특별한 간식으로도 쓰였다. 이 job 에는 부모를 오래 기다리게 하지 않는 묽은 밀크셰이크가 맞았다

기사는 소비자가 job 을 해내려고 제품을 “고용(hire)”한다고 표현한다. Christensen Institute 페이지도 이 사례를 “하루 중 서로 다른 job 을 위해 밀크셰이크를 고용했다”고 요약한다.

이 사례가 보여주는 것은 두 가지다.

첫째, 첫 조사가 실패한 이유는 질문의 단위였다. 인구통계가 맞는 사람들에게 제품의 이상형을 물었다. 사람과 제품은 물었지만 상황은 묻지 않았다.

둘째, 경쟁자가 바뀐다. 제품 범주로 보면 밀크셰이크의 경쟁자는 다른 가게의 밀크셰이크다. job 으로 보면 출근길의 베이글과 도넛이다. 아이 간식 job 에서는 또 다른 것이 경쟁자가 된다. 무엇과 경쟁하는지가 달라지면 무엇을 고칠지도 달라진다. 이 두 번째 읽기는 내 해석이다.

Ulwick 의 ODI 는 job 을 잴 수 있는 결과로 쪼갠다

JTBD 에는 다른 갈래가 있다. Tony Ulwick 의 Outcome-Driven Innovation(ODI, 성과 주도 혁신)이다. 출처는 Ulwick 이 세운 회사 Strategyn 의 페이지 두 개다.

JTBD 가이드의 정의 — job 은 고객이 주어진 상황에서 이루려는 과업, 목표, 또는 목적(the task, goal, or objective)이다
ODI 프로세스 페이지 — ODI 는 JTBD 관점으로 구상한 전략·혁신 프로세스다
바라는 결과(desired outcomes) — 고객이 job 을 수행할 때 성공을 재는 지표들이다. 해법이 들어가지 않고, 잴 수 있고, 시간이 지나도 안정적이라고 설명한다
우선순위 — 각 결과를 중요도와 만족도로 평가하고, 자체 알고리즘으로 가장 큰 기회를 계산한다

Christensen 쪽 정의가 진전과 상황에 무게를 둔다면, Ulwick 쪽은 job 수행을 재는 결과 지표에 무게를 둔다. 앞쪽은 왜 고용하는지를 설명하는 데, 뒤쪽은 어느 결과가 덜 채워졌는지를 고르는 데 쓰기 좋아 보인다. 이 대비는 두 출처를 나란히 놓고 내가 읽은 것이다.

기원을 두고는 주장이 갈린다. Strategyn 페이지는 Ulwick 이 1990년에 개념을 잡고, 1999년에 ODI 라는 이름을 붙여 Christensen 에게 소개했으며, Christensen 이 2003년 『The Innovator’s Solution』에서 이를 대중화했다고 쓴다. 이것은 한쪽 당사자의 설명이고, 나는 Christensen 쪽의 반대 설명을 찾아 확인하지 않았다.

결과 문장을 쓰는 형식(방향 + 측정 단위 + 대상)과 기회 점수 공식은 여러 요약 글에 돌아다니지만, 내가 연 Strategyn 페이지에서는 확인하지 못해 적지 않는다.

JTBD 를 기능 요구로 쓰면 job 이 사라진다

JTBD 를 처음 쓸 때 흔한 실수는 job 칸에 기능을 적는 것이다. 배달앱으로 지어낸 예다.

-- job 이 아니다 (해법을 적었다)
쿠폰함에서 지금 쓸 수 있는 쿠폰만 걸러 보고 싶다

-- job 이다 (상황과 진전을 적었다)
퇴근길에, 이번 달 식비를 넘겼다는 부담 없이 저녁을 해결하고 싶다

위 문장에는 상황이 없고 해법이 이미 정해져 있다. 쿠폰 필터 말고 다른 답이 들어갈 자리가 없다. 아래 문장은 쿠폰 필터, 식비 알림, 묶음 할인 중 무엇이든 후보가 될 수 있다. Ulwick 쪽 표현으로는 바라는 결과는 “해법이 들어가지 않아야(solution-free)” 하는데, 위 문장은 그 조건을 어긴다.

job 문장에 화면 요소나 기능 이름이 들어가 있으면 job 이 아니라 해법을 쓴 것이다. Christensen 발췌의 “제품이 아니라 진전”이 바로 이 구분이다.

잡 스토리는 유저 스토리의 “누구” 자리에 “상황”을 넣는다

이 실수를 문장 형식으로 막으려는 시도가 잡 스토리(job story)다. Alan Klement 는 Intercom 블로그 2013년 글에서 잡 스토리가 Paul Adams 에게서 처음 언급됐다고 밝히고, 유저 스토리의 문제를 셋으로 든다.

페르소나에 기댄다
구현을 동기·결과와 묶어버린다
맥락, 상황, 불안을 무시한다

그는 같은 글에서 페르소나를 “인과를 설명하지 못하는 속성으로 정의된 상상 속 고객(imaginary customers defined by attributes that don’t acknowledge causality)”이라고까지 쓴다. 나이나 습관 같은 속성은 사람이 왜 그 행동을 하는지 설명하지 못한다는 것이다. 잡 스토리는 그 대신 상황, 그 안의 동기와 불안, 바라는 결과를 적는다.

흔히 인용되는 “When __, I want to __, so I can ___” 템플릿의 원문은 Klement 의 다른 글로 알려져 있지만, 그 글은 열리지 않아 확인하지 못했다. 내가 연 Intercom 글은 세 요소만 설명한다. 그 세 요소로 앞의 쿠폰 예를 쓰면 이렇다. 지어낸 예다.

-- 유저 스토리 (역할이 앞에 온다)
사용자로서 주문을 취소하면 쿠폰을 돌려받고 싶다. 다음 주문에 다시 쓰기 위해서다.

-- 잡 스토리 (상황이 앞에 온다)
배송 전에 주문을 취소해야 할 때, 쿠폰을 잃을까 걱정하지 않고 취소하고 싶다.
그래야 다른 가게에서 바로 다시 주문할 수 있다.

두 번째 문장에는 “잃을까 걱정”이라는 불안이 들어간다. 이 불안을 알면 취소 버튼 옆에 쿠폰 반환 여부를 미리 보여주는 설계가 나온다. 유저 스토리와 인수 조건 자체는 6편에서 다룬다.

둘은 축이 다르다

여기까지를 한 표로 놓으면 축이 갈린다. 배달앱으로 지어낸 예다.

	평일 퇴근길	주말 친구 모임
혼자 사는 직장인	고민 없이 저녁을 해결한다	여럿이 나눠 먹을 메뉴를 빨리 합의한다
맞벌이 부모	아이가 먹을 수 있는 메뉴로 빨리 해결한다	여럿이 나눠 먹을 메뉴를 빨리 합의한다

가로로 읽으면 같은 사람이 상황에 따라 다른 job 을 갖는다
세로로 읽으면 다른 사람이 같은 상황에서 비슷한 job 을 가질 수 있다

페르소나는 행을, JTBD 는 열을 묻는다. 페르소나만 있으면 같은 사람의 다른 상황이 한 칸에 뭉개진다. JTBD 만 있으면 같은 job 안에서도 숙련도나 제약이 다른 사람을 구분하지 못한다. 이 표와 해석은 내 정리다.

그럼 JTBD 가 있으면 페르소나는 안 써도 되나

그렇게 주장하는 쪽이 있다. 앞의 Klement 글은 페르소나와 유저 스토리를 잡 스토리로 대체하자는 입장이다.

반대 입장도 있다. 앞의 NN/g 2017년 글은 JTBD 가 페르소나를 완전히 대체할 수 있다는 목소리가 많지만 둘은 “꽤 잘 맞는다(quite compatible)”고 결론 낸다. 같이 쓰는 방법도 제시한다.

조직에 이미 JTBD 가 있으면 페르소나마다 해당하는 job 을 참조한다. 같은 작업을 두 번 하지 않는다
페르소나가 얕으면 목표를 나열하는 대신 그 칸을 job 형식으로 쓴다

Cooper 의 원래 페르소나도 이미 목표를 중심에 뒀다. 그가 Sagent 사용자를 가른 기준이 목표·과업·숙련도였다. 내 해석으로는 Klement 가 비판한 페르소나는 Cooper 가 구분하려던 인구통계형 페르소나에 가깝다. 비판의 대상이 페르소나라는 방법 자체인지, 잘못 만든 페르소나인지는 나눠서 읽어야 한다.

둘 다 조사가 전제다. 프로토 페르소나가 팀의 가정을 되울릴 수 있듯이, 인터뷰 없이 적은 job 도 팀이 상상한 상황일 뿐이다. 밀크셰이크 사례도 매장에서 관찰하고 인터뷰한 뒤에야 출근길이라는 상황이 나왔다.

원전을 찾지 못한 것과 확인하지 못한 것

Cooper 의 페르소나 기원은 본인 회고다. 같은 글에서 그는 앞선 사람들도 민족지 조사를 하고 페르소나 비슷한 것을 만들어 썼다고 인정한다. 최초라는 주장으로 읽지 않는다.
『The Inmates Are Running the Asylum』의 출간 연도는 자료마다 엇갈려 적지 않았다. 책은 읽지 않았다.
HBR 의 2016년 JTBD 글은 본문이 막혀 확인하지 못했다. 밀크셰이크 사례는 HBS Working Knowledge 기사와 Christensen Institute 페이지로만 확인했고, 둘 다 Christensen 본인의 글은 아니다.
『Competing Against Luck』은 2장 공개 발췌만 확인했다.
ODI 의 결과 문장 형식과 기회 점수 공식은 Strategyn 1차 출처에서 찾지 못해 적지 않았다. JTBD 기원을 둘러싼 설명은 Strategyn 쪽만 읽었다.
잡 스토리 템플릿의 원문은 열지 못했다. Intercom 글로 세 요소까지만 확인했다.
표와 코드블록의 배달앱 예시는 전부 지어낸 것이다. 실제 인터뷰나 관찰에서 나온 것이 아니다.

정리

헷갈리는 지점	가르는 질문
페르소나 / 인구통계 세그먼트	이 칸이 설계 결정을 하나라도 바꾸나
정성 페르소나 / 프로토 페르소나	인터뷰에서 나왔나, 팀의 머릿속에서 나왔나
job / 기능 요구	문장에 상황이 있나, 해법이 이미 들어가 있나
Christensen / Ulwick	왜 고용하나를 묻나, 어느 결과가 덜 채워졌나를 재나
페르소나 / JTBD	누구인가, 어떤 상황의 무슨 진전인가

다음 편은 이 문제 정의를 화면과 규칙으로 옮기는 유저 플로우, 와이어프레임, 정책서를 다룬다.