선택지를 절반으로 줄여주는 JTBD 설계

AI 시대, 기능이 아닌 '일'을 고용하라

B2B 시스템 중에서도 복잡도가 상위에 속하는 영역이 있다.

제조 현장이 대표적이다. 반도체 제조만 해도 수백 개의 공정 단계가 존재하고, 각 단계마다 설비, 품질, 물류, 수율 데이터를 다루는 시스템이 따로 있다. 이 시스템들은 파편화되어 있었기 때문에, 통합 플랫폼을 만들어야 한다는 요구가 자연스럽게 생겼다. 제조 실행 시스템(MES) ¹⁾, AI 기반 운영 시스템(MLOps) ²⁾ 등 18개가 넘는 시스템을 대상으로 디자인 시스템을 구축할 때, 가장 먼저 마주한 문제는 디자인이 아니었다. 기능이 너무 많다는 것이었다.

그런데 통합에는 역설이 있다.

파편화된 시스템을 하나로 모으면, 전체를 볼 수 있게 된다. 하지만 실제로 일하는 조직, 개인 단위로 내려가 보면 각자가 사용하는 범위는 극히 일부다. 하던 일만 하기 때문이다. 물론 연계해야 할 시스템이나 참고해야 할 데이터가 있기 때문에 통합은 필요하다. 그런데 통합하면 시스템이 비대해지고, 내가 원하는 메뉴와 기능을 찾기 어려워지면서 결국 개인적으로 따로 즐겨찾기를 만들거나 커스텀 화면을 구성하는 일이 생긴다. 통합을 했는데 다시 파편화되는 것이다.

현장 사용자들에게 물어보면 돌아오는 대답은 비슷했다.

"저는 이 화면에서 두세 가지만 봐요."
"이 버튼 눌러본 적 없어요."
"이 기능이 있는 줄 몰랐어요."

기능은 계속 추가되었지만, 사용자가 실제로 해결하려는 일은 달라지지 않았다.

기능의 수가 가치의 양이 아니었던 것이다.

---

사람은 제품을 사는 것이 아니라, '일'을 해결하려고 고용한다

이 문제를 설명하는 프레임이 하나 있다.

JTBD(Jobs to Be Done) ³⁾. 직역하면 '해결해야 할 일'이다.

JTBD의 핵심 전제는 이것이다. 사용자는 제품이나 기능 자체를 원하는 것이 아니라, 자신이 처한 상황에서 특정한 '일'을 해결하기 위해 그 제품을 '고용'한다.

건강을 챙기고 싶지만 바쁜 직장인이 샐러드 정기배송을 신청하는 이유는, 샐러드가 좋아서가 아니다.

매일 점심 메뉴를 고르는 판단을 줄이면서 동시에 건강 관리라는 '일'을 해결하기 위해 그 서비스를 '고용'한 것이다. 이 관점에서 샐러드 정기배송의 경쟁자는 다른 식단 서비스가 아니라, 회사 근처 헬스장의 식단 코칭일 수도 있고, 간헐적 단식 앱일 수도 있다.

이 프레임이 제품 설계에서 왜 중요한가. 기능 중심으로 생각하면 "어떤 기능을 더 추가할까"가 질문이 된다.

하지만 JTBD 관점에서 생각하면 질문이 바뀐다. "사용자가 이 제품을 고용한 이유는 무엇인가? 그 일을 해결하는 데 지금의 기능 중 실제로 쓰이는 것은 무엇인가?"

이 질문을 던지는 순간, 대부분의 기능은 불필요해진다.

---

기능의 수가 가치의 양이 아닌 이유

앞서 언급한 시스템으로 돌아가 보자. 시스템에 기능이 많았던 이유는 단순했다.

요구사항이 올 때마다 기능을 추가했기 때문이다.

"이런 보고서도 볼 수 있으면 좋겠어요."
"이 데이터도 입력할 수 있게 해 주세요."
"경쟁사 시스템에는 이 기능이 있던데요."

각각의 요구는 합리적이었다. 하지만 그 요구들이 누적되면서 시스템은 무엇이든 할 수 있지만 아무것도 잘하지 못하는 상태가 되었다.

그런데 여기에는 B2B 특유의 함정이 있다. 메뉴가 총 50개인 시스템에서, 각 파트가 실제로 사용하는 메뉴는 3~4개에 불과한 경우가 많다. 그렇다면 나머지 메뉴를 통합하거나 삭제해야 할까? 생각보다 그렇지 않다.

각 파트가 사용하는 3~4개의 메뉴는, 비록 사용자 수가 적더라도 그 업무를 위해 반드시 필요한 기능이다. 사용 빈도가 낮다고 해서 가치가 낮은 것이 아니다. 그래서 B2B 시스템의 메뉴는 계속 늘어난다.

아래 그림처럼 기능을 삭제하는 것이 아니라,

사용자의 '일'에 맞춰 우선순위를 설계하면 Case B처럼 좀 더 편리한 정보구조를 갖게 된다.

Case A 기능 기준의 시스템은 사용자가 무엇을 해야 하는지 스스로 찾아야 하지만, Case B는 기능은 그대로지만 사용자가 일을 수행하는 흐름에 맞게 구조를 재설계한 것이다.

핵심은 사용자 수가 아니라, 그 기능이 조직의 중요한 과업과 목표에 기여하는지 여부다.

If, 기여하지 않는 기능이라면?, 실제 사용자가 없다면? 그때 조직의 정책을 따라 정리하는 것이 맞다.

JTBD 관점에서 다시 보면, 사용자들이 이 시스템을 '고용'한 이유는 명확했다.

설비 상태를 빠르게 확인하고, 이상이 발견되면 즉시 조치를 취하는 것. 이 '일'을 해결하는 데 필요한 화면과 기능은 전체의 일부에 불과했다. 나머지 중에서 다른 파트의 업무를 위해 존재하는 기능은 유지되어야 하지만, 어떤 과업에도 연결되지 않는 잉여 기능은 시스템의 복잡도만 높인다.

원칙 4에서 다뤘듯, 표면의 문제와 구조의 문제는 다르다. "기능이 부족하다"는 표면의 불만 뒤에는 "내가 해결하려는 일에 이 시스템이 최적화되어 있지 않다"는 구조의 문제가 숨어 있는 경우가 대부분이다.

---

B2B에서 JTBD가 더 복잡한 이유

B2C에서는 JTBD의 주체가 비교적 명확하다. 제품을 사용하는 사람이 곧 '일'을 해결하려는 사람이다. 하지만 B2B에서는 구조가 다르다. 시스템을 실제로 사용하는 사람, 도입을 결정하는 사람, 예산을 승인하는 사람, 성과를 평가하는 사람이 모두 다르다. 그리고 각자가 해결하려는 '일'이 다르다.

이 시스템은 먼저 누구의 ‘일’을 해결해야 하는가? 모든 사람의 요구는 타당하다. 바로 그게 문제다.

현장 오퍼레이터의 일 : "설비 이상을 빠르게 감지하고 대응하는 것"

팀 리더의 일: "우리 라인의 수율을 일정 수준 이상으로 유지하는 것"

IT 부서의 일: "시스템 안정성을 보장하고 유지보수 비용을 관리하는 것"

경영진의 일: "투자 대비 효과를 확인하는 것"

위 그림처럼 동일한 시스템을 놓고 네 가지 '일'이 공존한다.

기능 중심으로 설계하면 네 사람의 요구를 모두 담으려다 기능이 비대해질 수 있다.

JTBD 관점으로 설계하면 질문이 달라진다.

이 시스템이 가장 먼저 해결해야 하는 '일'은 무엇인가?

그리고 그 '일'들 사이의 우선순위는 어떻게 결정되는가?

만약 위 시스템의 대시보드를 사용자의 해결해야 할 '일' 기준으로 우선순위를 재구성한다면

아래 그림의 Case B처럼 사용자의 선택과 행동을 돕는 대시보드가 된다.

같은 데이터, 다른 구조. 정보를 줄인 것이 아니라 사용자의 Job에 맞게 우선순위를 재설계한 것이다.

현실적으로 이 우선순위를 현장에서 합의하는 것은 큰 조직일수록 매우 쉽지 않다.

각 이해관계자의 '일'이 모두 타당하기 때문이다. 그래서 조직에는 이 우선순위를 결정하는 의사결정 매트릭스⁴⁾ 즉 프로세스가 견고해야 한다. 프로세스가 없으면 목소리 큰 사람의 요구가 우선순위가 되고, 그것이 반복되면 시스템은 특정 이해관계자에게만 최적화된다.

한편, 현장에서는 이런 구조적 합의가 이루어지기 전에도 사용자들은 일을 해야 한다. 그래서 '즐겨찾기', 개인화된 메뉴 구성, 커스텀 대시보드 같은 기능이 제공된다. 이것은 우회책이지만, 동시에 현실적인 해법이기도 하다.

다만 이런 기능이 존재한다는 것 자체가, 시스템이 각 사용자의 '일'에 아직 최적화되어 있지 않다는 방증이다.

원칙 5에서 다뤘던 워크플로우 다이어그램이 여기서 다시 쓰인다. 전체 흐름이 가시화되어 있으면, 각 이해관계자의 '일'이 워크플로우의 어떤 지점에서 발생하는지가 보인다. 그리고 그 지점들 사이의 의존관계와 우선순위가 드러난다. 워크플로우 없이 JTBD를 논하면 각자의 '일'이 나열만 될 뿐 구조화되지 않는다.

---

AI를 고용하는 기준 : 프로세스 → 워크플로우 → JTBD

이 프레임은 AI 도입에도 그대로 적용된다. 그리고 여기서 원칙 5와 원칙 6이 하나로 연결된다.

"AI로 무엇을 할 수 있는가"가 아니라 "AI에게 어떤 '일'을 맡길 것인가"가 올바른 질문이다.
하지만 이 질문에 답하려면, 그전에 세 단계의 분석이 필요하다.

Lv.1 프로세스 — 조직 전체의 End-to-End 흐름을 먼저 본다. 문제 발견에서 가설, 설계, 개발, 검증, 운영까지. 이 레벨에서는 "어디에 병목이 있는가", "어느 단계가 반복적으로 지연되는가"가 보인다.

Lv.2 워크플로우 — 프로세스의 각 단계 안에서, 사람이 실제로 어떤 행동을 하는지를 본다. 어떤 도구를 열고, 누구에게 확인하고, 어떤 데이터를 참조하는가. 원칙 5에서 다뤘던 가시화가 이 레벨이다. 워크플로우가 가시화되면, 각 단계를 세 가지로 구분할 수 있다. 완전히 자동화할 수 있는 단계, AI가 보조하되 사람이 최종 판단하는 단계(Co-pilot), 그리고 전적으로 사람이 수행해야 하는 단계.

Lv.3 JTBD — 워크플로우의 각 단계에서, "이 사람이 AI를 '고용'해서 달성하려는 진짜 결과는 무엇인가"를 정의한다. 기능 단위가 아니라, 결과와 맥락 단위로 정의하는 것이 핵심이다.

"리서치 데이터를 요약하기"가 아니라,
"경영진이 이해할 수 있는 수준으로 인사이트를 정제해서 공유하고 싶다"가 JTBD다.

이 세 단계를 거치면, AI 기능의 투입 타이밍과 인간과의 핸드오프⁵⁾ 지점이 자연스럽게 드러난다. 그리고 핸드오프를 설계할 때는 구체적인 트리거가 필요하다. AI의 신뢰도가 일정 기준 이하일 때, 리스크가 높은 판단이 필요할 때, 금액이나 법무 이슈가 개입될 때. 이런 조건에서 AI가 사람에게 맥락과 근거를 함께 넘기도록 프로토콜을 정의해야 한다.

AI 도입 프로젝트에서 20개 넘는 과제를 검토할 때도 이 구조가 그대로 적용되었다. 각 과제의 기술적 가능성(Feasibility)은 대부분 확인되었다. 하지만 기술적으로 가능한 것과 실제로 조직에 가치를 만드는 것은 달랐다. 결국 세 가지 질문이 과제의 우선순위를 결정했다.

"이 과제가 해결하려는 '일'은 조직에서 얼마나 중요한가"
"이 '일'이 해결되지 않을 때 어떤 비용이 발생하는가"
"이 '일'에서 반복적이고 데이터 집약적인 부분은 어디이고, 리스크가 높아 사람의 판단이 반드시 필요한 부분은 어디인가"

AI를 도구로 보면 "더 많이 쓸수록 좋다"라고 생각하게 된다. AI를 특정한 '일'을 해결하기 위해 고용하는 존재로 보면, 어떤 일에는 고용하고 어떤 일에는 고용하지 않아야 한다는 판단이 필요해진다. 그리고 그 판단의 기준은 기술의 성능이 아니라, 프로세스 → 워크플로우 → JTBD로 이어지는 구조적 분석에 있다.

이 구조를 적용한 뒤, 20개 과제 중 실제로 PoC⁶⁾ 단계까지 전환된 것은 절반이었다. 나머지 절반은 기술적으로 가능했지만, 조직이 해결해야 하는 '일'의 우선순위에서 밀렸다. 그리고 그 판단 자체가 프로젝트의 가장 중요한 성과였다.

---

삶의 JTBD

이 원리를 삶에 적용해 보자.

우리는 하루에 수십 가지 활동을 한다. 운동을 하고, 공부를 하고, SNS를 확인하고, 뉴스를 읽고, 사이드 프로젝트를 진행하고, 네트워킹 모임에 참석한다. 각각의 활동에는 나름의 이유가 있다. 하지만 이 활동들이 해결하려는 '일'이 무엇인지를 물어보면, 상당수가 겹치거나, 실은 핵심적인 '일'과 무관한 경우가 있다.

JTBD 관점에서 스스로에게 물어보는 것이다. "나는 이 활동을 어떤 '일'을 해결하기 위해 고용하고 있는가?"

운동을 하는 이유가 "체력 유지"라면, 주 3회 45분 F45로 충분할 수 있다. 그런데 그 위에 러닝도 추가하고, 홈트도 추가하고, 식단 관리 앱도 세 개씩 쓰고 있다면, 그것은 '일'을 해결하기 위한 것이 아니라 '기능을 추가'하고 있는 것이다. 제품에서 기능이 비대해지는 것과 같은 패턴이다.

원칙 1에서 이야기했던 흔들림은, 사실 여기서도 연결된다. 기준이 없으면 활동이 계속 늘어나고, 늘어난 활동이 에너지를 분산시키고, 분산된 에너지가 어떤 것도 깊이 있게 해결하지 못하는 상태를 만든다. JTBD는 이 악순환을 끊는 프레임이다. "이 활동이 해결하는 '일'은 무엇인가"를 묻는 순간, 유지해야 할 것과 내려놓아야 할 것이 구분된다.

---

선택지를 절반으로 줄이는 방법

원칙 4에서 우리는 구조에 집중해야 한다는 것을 확인했다. 원칙 5에서는 그 구조의 흐름을 가시화해야 한다는 것을 이야기했다. 이제 원칙 6에서 한 가지가 더해진다. 가시화된 흐름 위에서, 진짜 해결해야 할 '일'을 식별하라는 것.

JTBD가 작동하면, 선택지가 줄어든다. 기능이든 활동이든 커리어든, "이것이 해결하는 '일'은 무엇인가"라는 질문 앞에서 살아남는 것만 남는다. 그리고 살아남는 것에 자원을 집중할 때, 비로소 깊이가 생긴다.

그렇다면 남은 선택지 안에서, 무엇을 하지 않을 것인지는 어떻게 결정하는가.

JTBD가 '무엇에 집중할 것인가'의 프레임이라면, 다음 원칙에서는 '무엇을 하지 않을 것인가'의 프레임을 다룬다.

---

사람의 선택과 행동을 설계합니다. 비즈니스, 기술, 사람 — 셋의 교차점에서 일합니다.

Invisible to Visible. © Novah

---

주석

¹⁾ MES(Manufacturing Execution System) — 제조 실행 시스템. 공장 현장에서 생산 공정을 실시간으로 모니터링하고 관리하는 시스템이다. 원자재 투입부터 완제품 출하까지 제조 과정 전반을 추적하며, 설비 상태, 수율, 품질 데이터 등을 통합 관리한다.

²⁾ MLOps(Machine Learning Operations) — AI/머신러닝 모델의 개발, 배포, 모니터링, 재학습까지의 운영 전체를 체계적으로 관리하는 시스템 및 방법론. 제조 현장에서는 설비 이상 감지, 수율 예측 등 AI 모델이 실제 운영 환경에서 안정적으로 작동하도록 지원하는 인프라에 해당한다.

³⁾ JTBD(Jobs to Be Done) — 하버드 경영대학원의 클레이튼 크리스텐슨(Clayton Christensen) 교수가 체계화한 혁신 프레임워크. 사용자가 제품이나 서비스를 '구매'하는 것이 아니라 특정 상황에서 특정한 '일(Job)'을 해결하기 위해 '고용(Hire)'한다는 관점에서 출발한다. 이 프레임은 제품의 경쟁 구도, 기능 우선순위, 혁신의 방향을 결정하는 데 핵심적인 기준을 제공한다.

⁴⁾ 의사결정 매트릭스(Decision Matrix) — 여러 선택지를 복수의 기준으로 평가하여 우선순위를 도출하는 도구. B2B 환경에서는 이해관계자마다 서로 다른 기준을 가지고 있기 때문에, 이 기준들을 명시적으로 정의하고 가중치를 부여하는 구조가 필요하다. 이것이 부재하면 의사결정이 특정 이해관계자의 영향력에 좌우된다.

⁵⁾ 핸드오프(Handoff) — 업무나 판단의 주체가 전환되는 지점. AI 도입 맥락에서는 AI가 처리한 결과를 사람에게 넘기거나, 반대로 사람의 판단을 AI에게 위임하는 전환점을 의미한다. 이 지점을 명확히 설계하지 않으면, AI의 판단 결과를 사람이 검증 없이 수용하거나, 반대로 모든 단계에서 사람이 개입하여 자동화의 의미가 사라지는 문제가 발생한다.

⁶⁾ PoC(Proof of Concept) — 개념 검증. 새로운 기술이나 아이디어가 실제로 작동하는지를 소규모로 검증하는 단계. AI 도입에서는 특정 과제에 AI를 적용했을 때 기대한 성과가 나오는지를 제한된 범위에서 먼저 확인한 뒤, 본격적인 개발과 확산 여부를 결정한다.