2026-08-09 · 한소희 (부소장)

할 일 이론(Jobs to be Done)이란 무엇인가요? 고객이 제품을 고용하는 이유와 스타트업 프로덕트 마켓 핏 가이드

#스타트업#할일이론#jobstobedone#jtbd#프로덕트마켓핏#고객인터뷰#스위치인터뷰#고객개발#크리스텐슨

고객은 왜 제품을 사지 않고, '할 일'을 대신 해줄 무언가를 고용하는 걸까요?

할 일 이론(Jobs to be Done)의 출발점은 이 한 문장에 있습니다. 사람은 제품 자체를 원해서 사는 게 아니라, 삶의 어떤 상황에서 해결하고 싶은 '할 일(Job)'이 생겼을 때 그 일을 대신 처리해 줄 무언가를 잠시 고용한다는 것입니다. 하버드 경영대학원의 클레이튼 크리스텐슨(Clayton Christensen)이 널리 알린 이 관점은 한 패스트푸드 체인의 밀크셰이크 사례에서 선명해졌는데요. 밀크셰이크 매출의 약 40%가 이른 아침 시간대에, 그것도 혼자 차를 몰고 출근하는 사람이 다른 건 사지 않고 오직 밀크셰이크 하나만 사서 나가는 방식으로 발생하고 있었습니다. 제품의 맛이나 토핑이 아니라 '지루한 출근길을 버티게 해 달라'는 할 일이 구매를 만든 것입니다. 스타트업이 프로덕트 마켓 핏(Product-Market Fit)을 다시 세우고 싶다면, 기능 목록이 아니라 바로 이 '할 일'에서 시작해야 합니다.

목차

새벽 6시 45분, 밀크셰이크를 산 사람들

한 프로덕트팀이 밀크셰이크 신제품 워크숍을 열었다가 회의가 산으로 갔던 이야기를 들은 적이 있습니다. 다들 좋은 아이디어를 냈습니다. 초콜릿을 더 진하게, 딸기 과육을 크게, 컵 디자인을 세련되게. 여섯 달 뒤 매출은 거의 움직이지 않았습니다. 흔히 벌어지는 일입니다. '고객이 원하는 것'을 물으면 고객은 늘 조금 더 달고, 조금 더 싸고, 조금 더 예쁜 것을 말하니까요. 그런데 그 답을 다 반영해도 판매량은 제자리인 경우가 많습니다.

크리스텐슨 팀은 질문을 바꿨습니다. "이 사람은 오늘 밀크셰이크를 사면서 어떤 일을 해치우려 했나?" 매장에 하루 종일 서서 관찰했더니 이상한 패턴이 보였습니다. 밀크셰이크는 아침에 제일 많이 팔렸고, 사는 사람은 대부분 혼자였으며, 밀크셰이크 말고는 아무것도 사지 않았고, 가게에서 먹지 않고 차로 가져갔습니다. 다음 날 그들을 붙잡고 물었습니다. "지난번엔 이 컵으로 무슨 일을 하려고 오셨어요? 밀크셰이크가 없었다면 대신 뭘 샀을까요?"

답은 뜻밖이었습니다. 길고 지루한 출근길, 한 손은 운전대에 두고 남은 한 손으로 뭔가를 먹으며 시간을 때우고 싶다는 것이었습니다. 바나나는 너무 빨리 없어지고, 도넛은 손이 끈적여지고, 베이글은 뻑뻑했습니다. 걸쭉한 밀크셰이크는 가는 빨대로 빨아 마시니 20분 넘게 버텼고, 점심 전까지 허기도 눌러줬습니다. 이 사례는 밥 모에스타(Bob Moesta)의 리서치 기록하버드 경영대학원 자료로도 잘 정리돼 있는데요. 핵심은 이겁니다. 밀크셰이크의 진짜 경쟁자는 다른 브랜드의 밀크셰이크가 아니라 바나나와 도넛, 그리고 지루함 그 자체였습니다.

할 일 이론(Jobs to be Done)이란 무엇인가요

한 줄로 요약하면, 할 일 이론은 "고객은 제품을 사는 게 아니라, 특정 상황에서 진전을 이루기 위해 제품을 고용한다"는 관점입니다. 여기서 '할 일(Job)'은 직무가 아니라, 어떤 맥락에 놓인 사람이 이루고 싶어 하는 진전을 뜻합니다.

이 관점이 필요해진 배경부터 짚어보겠습니다. 기존의 시장 조사는 대부분 '누가 사는가'에 집중했습니다. 35세 직장인 남성, 서울 거주, 소득 구간은 어디. 이렇게 인구통계로 고객을 쪼개는 방식인데요. 문제는 같은 35세 직장인이 어떤 날은 밀크셰이크를 아침 동반자로 고용하고, 어떤 날은 아이를 달래는 보상으로 고용한다는 데 있습니다. 사람은 그대로인데 할 일이 바뀌면 완전히 다른 선택을 합니다. 속성으로 사람을 나누면 이 맥락이 통째로 사라집니다. 크리스텐슨의 문제의식이 바로 여기에 있었습니다.

그래서 JTBD는 '무엇을(what)'보다 '왜, 어떤 상황에서(why, when)'를 봅니다. 그리고 모든 할 일에는 세 가지 차원이 겹쳐 있다고 봅니다.

  • 기능적 차원(Functional): 실제로 끝내야 하는 과업입니다. "출근길 20분 동안 뭔가 먹으며 버티기" 같은 것이죠.
  • 감정적 차원(Emotional): 그 과정에서 느끼고 싶은 감정입니다. 지루하지 않고, 스스로 알뜰하다고 느끼고 싶은 마음입니다.
  • 사회적 차원(Social): 남에게 어떻게 보이고 싶은가입니다. 좋은 부모로, 유능한 실무자로 비치고 싶은 욕구죠.

기능만 보고 만든 제품은 대체로 얕습니다. 감정과 사회적 차원을 함께 읽어야 사람이 굳이 지갑을 여는 이유가 잡힙니다. 실제로 잘 팔리는 스타트업 제품을 뜯어보면 기능은 평범해도 감정·사회적 할 일을 정확히 건드리는 경우가 많습니다.

'고용과 해고', 그리고 진짜 경쟁자 찾기

JTBD가 실무에서 강력한 이유는 '고용과 해고'라는 은유 덕분입니다. 고객이 우리 제품을 고용했다는 건, 그전에 쓰던 무언가를 해고했다는 뜻입니다. 반대로 우리 제품을 해고하고 다른 걸 고용할 수도 있습니다. 이 프레임을 쓰면 경쟁 구도가 완전히 달라집니다.

기존 방식에서는 경쟁자를 같은 카테고리 안에서 찾습니다. 우리가 협업 툴이면 다른 협업 툴이 경쟁자라고 보는 식이죠. 그런데 할 일 관점에서 보면 "회의 없이 진행 상황을 공유한다"는 할 일의 경쟁자는 경쟁 협업 툴만이 아닙니다. 단톡방, 이메일, 심지어 '그냥 자리로 찾아가서 말하기'까지 전부 경쟁자입니다. 사용자가 우리 제품을 안 쓴다면, 그 할 일을 지금 무엇으로 처리하고 있는지를 봐야 진짜 경쟁자가 보입니다.

상황(맥락)고객이 고용한 것진짜 경쟁 상대
지루한 출근길 20분밀크셰이크바나나, 도넛, 팟캐스트, 지루함
팀 진행 상황 공유협업 툴단톡방, 이메일, 대면 보고
주말 저녁 외로움 달래기OTT 구독유튜브, 게임, 배달음식, 통화

이 표가 알려주는 건, 카테고리 안에서만 싸우면 정작 사용자를 붙잡고 있는 대안을 못 본다는 점입니다. 많은 스타트업이 "경쟁사 대비 기능이 많다"를 내세우다 실패하는데요. 사용자의 진짜 대안은 종종 '아무것도 안 하기' 또는 '엑셀로 버티기'이기 때문입니다. 여기서 이길 카피는 기능 비교표가 아니라, 지금 쓰는 임시방편이 얼마나 불편한지를 정확히 짚어주는 문장인 경우가 많습니다.

스위치 인터뷰와 전환을 만드는 네 가지 힘

그렇다면 할 일을 어떻게 알아낼까요. 설문으로는 잘 안 됩니다. "왜 샀냐"고 물으면 사람들은 사후에 그럴듯한 이유를 지어내니까요. JTBD 진영에서 쓰는 방법은 '스위치 인터뷰(Switch Interview)'입니다. 최근에 우리 제품을 처음 산(혹은 경쟁 제품에서 갈아탄) 사용자를 붙잡고, 구매를 결심한 그 순간을 마치 범죄 현장 복원하듯 시간 순서로 되짚는 인터뷰입니다.

핵심 질문은 이렇습니다. "처음 이게 필요하다고 느낀 건 언제였나요? 그때 무슨 일이 있었죠? 어떤 대안을 알아봤나요? 결제 직전에 망설이게 한 건 뭐였나요?" 이렇게 파고들면 사람이 '지금 쓰던 것'을 해고하고 '새것'을 고용하기까지 밀고 당긴 힘들이 드러납니다. 밥 모에스타는 이를 네 가지 힘으로 정리했는데요.

방향인터뷰에서 잡히는 신호
밀어내는 힘(Push)전환 촉진지금 방식이 못 견디게 불편했던 사건
끌어당기는 힘(Pull)전환 촉진새 제품이 그려준 더 나은 상태
불안(Anxiety)전환 저항옮겨서 잘못될까 하는 두려움
습관(Habit)전환 저항그냥 익숙한 걸 계속 쓰려는 관성

전환율을 올린다는 건 결국 이 네 힘을 조정하는 일입니다. 밀어내는 힘과 끌어당기는 힘은 이미 사용자 안에 있으니 그걸 언어로 되살려주고, 불안과 습관은 온보딩과 보증으로 줄여주는 것이죠. 예컨대 이전에는 랜딩 페이지에 기능만 잔뜩 나열했다면, 스위치 인터뷰를 거친 뒤에는 "지금 스프레드시트로 이걸 관리하다 매달 마감 때 야근하시죠?"처럼 밀어내는 힘을 자극하는 문장으로 바꾸게 됩니다. 같은 제품, 같은 가격인데 전환의 결이 달라집니다.

스타트업이 JTBD로 PMF를 다시 세우는 법

프로덕트 마켓 핏은 결국 "우리 제품이 특정 사용자 집단의 어떤 할 일을 남들보다 확실히 잘 해내는가"의 문제입니다. 그래서 JTBD와 PMF는 붙어 다닙니다. PMF가 흔들리는 스타트업을 보면 대개 기능은 많은데 어떤 할 일도 압도적으로 잘하지 못하는 상태입니다. 이럴 때 기능을 더 얹기보다, 사용자가 우리를 고용한 단 하나의 할 일을 찾아 거기에 집중하는 편이 빠릅니다.

국내 사례로 보면 감이 옵니다. 토스(Toss) 팀은 데이터로만 사용자를 짐작하지 않고 팀원 전체가 직접 사용자를 만나 이야기를 듣는 문화로 알려져 있는데요. 토스 팀은 점심 시간에 사용자를 만난다는 기록을 보면, 사람들이 왜 그 카드를 지갑에 넣는지, 어떤 순간에 송금 앱을 여는지 같은 맥락을 반복해서 캐냅니다. 이게 사실상 할 일을 발굴하는 작업입니다. 당근마켓 역시 초기부터 동네 사장님과 사용자를 붙잡고 "지금 이 문제를 어떻게 해결하고 계세요"를 물으며 프로덕트를 다듬었습니다.

구분전통적 기능·페르소나 관점할 일(JTBD) 관점
분석 단위누가 사는가(속성)어떤 상황에서 무슨 일을 하려는가
성공 기준기능 개수, 만족도 점수할 일 완수와 재고용(리텐션)
경쟁 범위같은 카테고리 제품그 일을 처리하는 모든 대안
로드맵 우선순위요청 많은 기능부터할 일 완수를 막는 병목부터

주의할 점도 있습니다. 할 일 하나에 매몰돼 사용자가 실제로 하는 여러 할 일을 놓치면, 좁은 시장에 갇힐 수있습니다. 반대로 너무 추상적인 할 일("삶을 편리하게")을 잡으면 아무 제품이나 다 해당돼 쓸모가 없어집니다. 좋은 할 일 정의는 '충분히 구체적이되 특정 솔루션에 묶이지 않는' 중간 지점에 있습니다. "출근길에 한 손으로 20분을 버티게 해줘"는 밀크셰이크에도, 오디오북에도 열려 있으면서 상황은 분명합니다. 이 감각을 잡는 데는 연습이 필요한데요, 처음 한두번은 어색해도 인터뷰를 쌓다 보면 팀의 언어가 바뀝니다.

실전 가이드: 처음 시작하는 4단계

거창한 리서치 조직 없이도 이번 주부터 시작할 수 있습니다. 순서대로만 밟으면 됩니다.

1단계, 최근 전환자 5~8명을 찾습니다. 가장 이상적인 대상은 지난 30일 안에 유료로 결제했거나 경쟁 제품에서 갈아탄 사람입니다. 기억이 생생할수록 좋습니다. 표본이 많을 필요는 없고, 같은 할 일이 반복해서 들리기 시작하는 순간이 신호입니다.

2단계, 스위치 인터뷰를 진행합니다. 미래("어떤 기능을 원하세요")를 묻지 말고 과거의 구체적 사건을 되짚습니다. "결제한 그날 아침에 무슨 일이 있었나요?"처럼요. 사용자가 쓰는 날것의 표현을 그대로 받아 적는 게 중요합니다. 그 표현이 나중에 카피가 됩니다.

3단계, 할 일을 한 문장으로 정리합니다. "[상황]일 때, 나는 [동기]하고 싶다, 그래서 [기대하는 결과]를 얻으려 한다" 틀을 쓰면 편합니다. 이때 기능적·감정적·사회적 차원을 각각 한 줄씩 적어보면 빠진 층이 드러납니다.

4단계, 딱 한 곳을 바꿔 검증합니다. 랜딩 헤드라인이든 온보딩 첫 화면이든, 새로 찾은 할 일 언어로 하나만 바꿔 A/B 테스트를 겁니다. 전부 갈아엎지 않는 게 요령입니다. 어떤 문장이 전환을 만들어 냈는지 그때 그때 기록해두면, 다음 할 일을 찾아낼때 훨씬 빨라집니다.

이 4단계를 한 바퀴 돌리면, 팀 회의에서 "이 기능 넣을까요"라는 질문이 "이게 어떤 할 일을 더 잘 해내죠"로 바뀝니다. 그 변화 하나만으로도 로드맵의 낭비가 눈에 띄게 줄어듭니다.

FAQ

JTBD는 페르소나를 완전히 대체하나요? 꼭 그렇진 않습니다. 페르소나가 '누구'를 그린다면 JTBD는 '어떤 상황의 무슨 일'을 그립니다. 둘은 층이 다르기 때문에 함께 쓰면 오히려 보완됩니다. 다만 페르소나가 인구통계 속성에만 머무르면 맥락이 빠지므로, 페르소나에 '이 사람이 지금 처리하려는 할 일'을 붙여 쓰는 방식을 권합니다.
인터뷰 몇 명이면 충분한가요? 정답은 없지만, 같은 할 일이 반복적으로 들리기 시작하면(보통 5~8명 안팎) 한 세그먼트의 큰 패턴은 잡힙니다. 숫자를 채우는 것보다, 최근에 실제로 전환한 사람을 고르는 것이 훨씬 중요합니다. 오래된 기억이나 가상의 응답은 신뢰도가 크게 떨어집니다.
상업적으로 바로 써먹을 수 있나요? 네. 가장 빠른 적용처는 랜딩 페이지 헤드라인과 온보딩 첫 화면입니다. 사용자가 쓴 날것의 표현을 카피로 옮기고, 밀어내는 힘(현재 방식의 불편)과 불안(전환 리스크)을 함께 다루면 전환율 개선으로 이어지는 경우가 많습니다. 기능 개발보다 비용이 적게 드는 것도 장점입니다.
기존 방식과 가장 큰 차이는 무엇인가요? 기존 조사가 '무엇을 원하는가'를 묻는다면 JTBD는 '어떤 상황에서 왜 그 선택을 했는가'를 봅니다. 그 결과 경쟁 범위가 카테고리 밖으로 넓어지고(진짜 경쟁자는 종종 엑셀이나 아무것도 안 하기입니다), 로드맵 우선순위가 '요청 많은 기능'에서 '할 일 완수를 막는 병목'으로 바뀝니다.

같이 읽으면 좋은 것들