UX 디자이너는
왜 기능을 줄일까 JTBD기반 설계

POC와 System Design으로 AI시대 Product 디자인 검증

by 원빌더

Mar 6. 2026

많은 제품이 실패하는 이유는 기능이 부족해서가 아니다. 오히려 기능이 너무 많기 때문이다.

이 장에서는 JTBD, POC, System Design 관점에서 기능을 어떻게 줄일 것인지, 그리고 그 원리가 삶의 선택 설계에 어떻게 그대로 적용되는지 다룬다.

이 장을 다 읽고 나면, 당신은 "무엇을 더 만들지"가 아니라 "무엇을 지금 만들지 말지"를 기준으로 제품과 삶을 설계할 수 있게 된다.

1. 기능은 자연스럽게 늘어난다. 줄이지 않는 것이 문제다

제품을 만들다 보면 팀은 항상 같은 문제에 부딪힌다. 기능이 계속 늘어나는 것이다. 아이디어는 계속 추가되고, 요구사항은 끝없이 생기고, 회의가 반복될수록 제품은 복잡해진다.

많은 팀이 이 상황에서 우선순위 회의를 시작한다. 하지만 문제는 우선순위가 아니다. 필터가 없는 것이다.

원칙 6에서 우리는 JTBD로 "진짜 해결해야 할 일"을 정의하는 방법을 다뤘다. 하지만 현실에서는 JTBD로 핵심 Job을 정리한 뒤에도 여전히 선택지가 남는다.

"아이디어가 진짜 작동하는지 어떻게 확인할 것인가."

"검증된 아이디어를 어떻게 지속 가능한 시스템으로 만들 것인가."

이 질문에 답하지 못하면, 문제 정의를 아무리 잘해도 제품은 다시 비대해진다.

제품 설계에서 가장 중요한 능력은 기능을 추가하는 능력이 아니라, 기능을 걸러내는 능력이다.

‣ Key Takeaways
➔ 기능이 늘어나는 것은 자연스럽다. 문제는 줄이는 구조가 없다는 데 있다.

2. JTBD는 '만들 것'이 아니라 '만들지 않을 것'을 정하는 필터다; 'Not to do'를 정해라.

"사용자가 이 제품을 고용한 이유는 무엇인가?" 이 질문은 방향을 잡아준다. 하지만 JTBD가 진짜 힘을 발휘하는 순간은, 방향을 잡을 때가 아니라 기능을 걸러낼 때다. JTBD를 통해 '해야 할 일'을 정했다면, 반대로 '하지 않을 일'도 명확히 정의해야 한다. 기능을 버리는 것이 아니라, 지금 만들지 않기로 결정하는 것.

이것을 Parking Lot ¹⁾이라 부른다.

기능 중심 사고에서는 "이 기능도 있으면 좋을 것 같다", "고객이 요청했으니 추가하자"라는 대화가 반복된다. JTBD 관점에서는 이 대화 자체가 성립하지 않는다. 핵심 Job과 연결되지 않는 기능은 논의 대상이 아니라 Parking Lot 대상이기 때문이다.

JTBD의 질문은 명확하다. "사용자가 이 제품을 고용한 이유는 무엇인가?" 이 질문은 방향을 잡아준다.

하지만 JTBD가 진짜 힘을 발휘하는 순간은, 방향을 잡을 때가 아니라 기능을 걸러낼 때다.

컨셉 또는 기능 설계 단계에서 JTBD 기준으로 만들어지는 'Not-to-do'는 이런 것들이다.

첫 릴리즈에 "나중에 있으면 좋을 것 같은 기능"을 넣지 않는다.

JTBD/Outcome과 연결되지 않는 요구사항은 스펙에 넣지 않는다.

경쟁사에 있다는 이유만으로 기능을 추가하지 않는다.

"언젠가 필요할 수도 있다"는 이유로 유즈케이스를 끝없이 확장하지 않는다.

UX/UI 설계 단계에서도 마찬가지다.

실제 JTBD와 연결되지 않는 화려한 애니메이션·비주얼에 시간을 쓰지 않는다.

브랜드 Writing 톤이 정의되지 않은 상태에서 AI가 만든 카피를 그대로 사용하지 않는다.

모든 디바이스를 한 번에 완벽히 맞추려 하지 않는다. 핵심 Job이 수행되는 하나의 플랫폼에서 먼저 검증한다.

이 모든 'Not-to-do'가 묻는 질문은 같다.

"이것이 지금 사용자의 핵심 Job을 해결하는가?"

답이 No라면 Parking Lot으로 보낸다.

JTBD는 "무엇을 만들지 정하는 프레임워크"이면서 동시에, "지금 무엇을 만들지 말지 결정하는 필터"다.

‣ Key Takeaways
➔ JTBD는 '해야 할 일'을 찾는 도구이면서, 지금 당장 '하지 않을 일'을 정리하는 필터다.

3. 기능 중심 사고에서 흐름, 시스템 사고로

제품 조직에서 기능을 논의할 때 대부분의 사람은 기능 단위로 생각한다.

"이 기능을 넣을 것인가 말 것인가." 개발자는 구현 가능성을, 기획자는 비즈니스 요구를, 영업은 고객 요청을 기준으로 판단한다. 각자의 관점에서는 모두 합리적이다.

하지만 이 방식으로는 기능이 줄어들지 않는다. 각 기능이 각자 "필요한 이유"를 갖게 되기 때문이다.

UX 디자이너(또는 Product Designer)의 사고방식은 다르다. UX는 기능 하나를 보지 않는다.

→ 기능들의 정보 구조 → 그 기능이 만들어내는 흐름(워크플로우, 프로세스) → 그것이 미칠 비즈니스 임팩트

→ 최종적으로 사용자가 경험하는 것을 동시에 본다.

그래서 기능 중심 사고에 빠진 조직에서는 UX가 JTBD 기반으로 의사결정을 이끌어야 하는 순간이 온다.

"이 기능을 넣을까 말까"가 아니라,

"이 기능이 사용자의 어떤 흐름 안에서 어떤 역할을 하는가."

라는 질문을 던지는 것이다. 이 질문이 들어가는 순간 기능 목록은 'Not-to-do' 리스트로 전환된다.

핵심 흐름에 기여하지 않는 기능은 자연스럽게 걸러지기 때문이다.

AI MLOps 플랫폼을 설계할 때 이것을 경험했다. AI 학습에 필요한 데이터를 수집하고, 변환하고, 평가하는 플랫폼은 기능의 범위가 넓다. 데이터 업로드, 수집, 카탈로그, 모델 평가 자동화, 데이터 파이프라인 등 각 영역에서 요구되는 기능만 나열해도 수십 개가 된다. 이것을 한 번에 다 만들 수는 없다. 그래서 세 단계에 걸쳐 필터링했다.

1단계: 기능별 논의

각 기능 영역에서 실제로 무엇이 필요한지를 현장의 맥락에서 파악한다. 이 단계에서 중요한 것은 기능 명세가 아니라, 그 기능이 어떤 상황에서 어떻게 사용되는지를 확인하고 JTBD를 파악한다. 이때 'Not-to-do'도 동시에 고려하도록 한다. 예를 들어 데이터 업로드 기능은 단순히 "파일을 올리는 기능"이 아니라, "누가, 어떤 파일을, 어떤 보안 환경에서 올리는가"까지 맥락이 명확해야 한다.

2단계: 요구사항별 스코프 정의

1단계에서 파악한 기능을 요구사항 단위로 정리하고, 각각의 범위를 명확히 한다. "데이터를 수집합니다"라는 요구사항 안에 CRUD, 마이그레이션, 권한 관리가 포함되는지 여부를 정의한다. 여기서 핵심은 하나의 요구사항 안에 숨어 있는 하위 범위를 드러내는 것이다. 범위가 정의되지 않은 요구사항은 개발 단계에서 반드시 비대해진다.

3단계: 기능별 우선순위 결정

정의된 요구사항에 중요도를 부여하고, 실제 개발 착수 순서를 결정한다. 이때 JTBD 기준이 작동한다.

"이 요구사항이 사용자의 핵심 Job 'AI 학습용 데이터를 정확한 형식으로 수집하고 검증하는 것' 을 해결하는가?" 이 질문에 직접 연결되는 요구사항은 '높은 우선순위'로, 당장 핵심 Job에 연결되지 않는 요구사항은 '중간 우선수위'로 분류된다.

이 세 단계를 거치면, 수백 개의 기능 목록이 "지금 만들 것"과 "지금은 만들지 않을 것"으로 명확히 나뉜다. 그리고 이 구분의 기준은 개인의 직감이 아니라, 여러 협업 관계자들과 합의 하면서 이끌어나가야 할 JTBD에 기반한 구조적 판단이다.

‣ Key Takeaways
➔ UX의 역할은 기능을 더하는 것이 아니라, 기능이 지나갈 필터링 구조를 설계하는 것이다.

4. AI 시대, 기능을 줄이려면 데이터부터 본다

JTBD와 흐름 기준으로 필터링을 거치면, '높은 우선순위'로 분류된 요구사항들이 개발 단계로 넘어간다. 하지만 AI 기능에는 한 가지 결정적인 전제가 더 있다. 데이터다.

IBM이 2018년에 체계화한 AI Design Thinking²⁾은, 기존 Design Thinking³⁾이 "사용자의 문제는 무엇인가"를 먼저 묻는 것에서 출발하되, 동시에 "그 문제를 AI로 풀 수 있는 데이터가 존재하는가"를 함께 묻는다. 기존 방식이 이상적인 플로우를 먼저 그리고 나중에 기술, 데이터 제약을 확인한다면, AI Design Thinking은 처음부터 데이터와 제약을 해결책의 형태에 포함시킨다. 이 차이가 곧 오버빌드를 줄여준다.

IBM에서 프로젝트를 진행할 때, AI Design Thinking 워크숍에는 반드시 테크니션(데이터 엔지니어나 AI 엔지니어)이 참여했다. 사용자 문제를 정의한 뒤, 그 문제를 풀기 위한 데이터가 정형인지 비정형인지, 각 Task별로 어떤 데이터를 사용하는지, 기술적으로 구현 가능한 범위가 어디까지인지를 문제 정의 단계에서 함께 확인해야 하기 때문이다.

지금 시점에서는 질문이 한 단계 더 진화했다.

"AI가 학습할 수 있는 형태로 데이터가 누적되어 있는가?"

데이터가 없다면, AI 기능 설계 이전에 데이터 수집과 누적 구조가 첫 번째 과제가 된다. 데이터는 아무 형식으로 쌓아도 되는 것이 아니다. AI 엔지니어링 담당자가 제시하는 형식에 맞게 구조화되어야 한다. 이 부분이 빠져 있으면, 아무리 좋은 문제 정의를 해도 POC조차 시작할 수 없다.

결국 AI 시대에 기능을 줄인다는 것은 "안 만든다"가 아니다.

"지금 데이터가 준비된 것만 만든다"가 가장 강력한 필터가 된다.

‣ Key Takeaways
➔ AI 기능은 "아이디어가 있는 것"이 아니라 "학습 가능한 데이터가 있는 것"부터 만든다.

5. 걸러낸 기능은 POC로 검증하고, System Design으로 구조화한다

JTBD로 필터링하고, 데이터 레디니스를 확인했다면 이제 남은 기능이 정말 작동하는지를 증명해야 한다. 그 역할을 하는 것이 POC(Proof of Concept)⁴⁾다.

POC가 없으면 검증되지 않은 아이디어가 그대로 개발에 들어간다. 개발이 끝난 뒤에야 "현장에서 안 쓸 것 같다"는 피드백이 나오고, 이미 투입된 리소스는 돌아오지 않는다. 많은 AI 프로젝트가 실패하는 이유는 기술 부족이 아니라, 검증 단계를 건너뛰기 때문이다.

LLM⁵⁾ 기반 공수 산정 자동화를 검토할 때도 바로 시스템을 만들지 않았다. 먼저 실제 데이터를 기반으로 기능이 작동하는지, 결과가 의미 있는지, 업무에 실제로 도움이 되는지를 POC로 검증했다. 원칙 6에서 "20개 과제 중 POC 단계까지 전환된 것은 절반이었다"라고 이야기한 바 있다. 나머지 절반은 기술적으로 가능했지만, 조직이 해결해야 하는 '일'의 우선순위에서 밀렸다.

POC를 통과한 기능은 System Design⁶⁾으로 이어진다. 모델만 붙인다고 제품이 되지 않는다.

→ 어떤 데이터가 들어오고 → 어떻게 처리되고 → 결과가 어디로 전달되고 → 사용자가 어떤 시점에서 수정. 개입할 수 있는지를 설계해야 한다. 원칙 5에서 다뤘던 핸드오프(사람과 AI 사이의 판단 넘김 지점)가 여기서 구체적인 구조로 잡힌다.

실제 제품 설계는 이렇게 이어진다.

Problem Definition → JTBD Filtering → POC Experiment → System Design

이 네 단계가 연결될 때, 제품은 아이디어가 아니라 시스템이 된다.

‣ Key Takeaways
➔ 좋은 아이디어는 POC로 걸러지고, 좋은 제품은 System Design으로 유지된다.

6. 삶의 선택에도 같은 구조가 작동한다

이 네 단계의 원리는 제품에만 적용되지 않는다. 삶에도 그대로 적용된다.

우리는 매일 무언가를 시작한다. 새로운 공부, 운동, 사이드 프로젝트. 각 활동에는 나름의 이유가 있지만, 계속 쌓이다 보면 제품의 기능처럼 비대해진다. 어떤 것도 깊이 있게 하지 못한 채, "바쁘지만 진전이 없는 상태"가 된다.

이때 삶의 선택을 이렇게 재구성할 수 있다.

Problem Definition : "모든 것을 잘하고 싶다"가 아니라 "올해 안에 커리어 방향을 결정해야 한다"처럼, 지금 진짜 해결해야 하는 문제를 한 줄로 정의한다.

JTBD Filtering : 지금 하고 있는 활동이 그 문제를 해결하는가. 네트워킹 모임, 자격증 공부, 사이드 프로젝트 중 무엇이 "커리어 방향을 결정하는 Job"에 직접 연결되는지 묻는다. 연결되지 않는 활동은 Parking Lot으로 보낸다.

POC Experiment : 바로 전면 전환하지 않고 작게 실험한다. 직무 전환이 고민이라면, 바로 이직하는 대신 관련 사이드 프로젝트나 단기 과제를 먼저 해본다. 글을 쓰고 싶다면, 책이 아니라 한 편의 글을 먼저 세상에 내본다.

System Design : 검증된 것을 구조로 만든다. "이번 주에 글을 한 편 썼다"는 실험이다. "매주 화요일 저녁 8시에 글을 쓴다"는 시스템이다. 원칙 5에서 다뤘던 루틴과 프로세스가 여기에 해당한다.

삶의 흔들림은 이 네 단계 중 어딘가가 빠져 있을 때 생긴다. 문제를 정의하지 않고 활동만 늘리거나, 검증 없이 전면 전환하거나, 실험은 하지만 지속하는 구조가 없거나.

좋은 삶은 좋은 제품과 같다. 많은 기능으로 만들어지지 않는다. 정확한 선택으로 만들어진다.

‣ Key Takeaways
➔ 삶도 제품처럼, "문제 정의 → 필터링 → 실험 → 시스템"으로 설계할 수 있다.

7. 좋은 제품은 '선택'으로 만들어진다

원칙 4에서 구조에 집중하라고 했고, 원칙 5에서 흐름을 가시화하라고 했으며, 원칙 6에서 진짜 해야 할 일을 식별하라고 했다. 이제 원칙 7에서는 그 일을 어떻게 걸러내고, 검증하고, 시스템으로 만드는지를 다뤘다.

제품 설계에서 가장 중요한 것은 많은 기능을 만드는 것이 아니라, 정확한 기능만 남기는 것이다. JTBD로 필터링하고, 데이터 레디니스를 확인하며, POC로 검증하고, System Design으로 구조화할 때 비로소 그게 가능해진다. 이 과정에서 UX 디자이너는 기능 중심 사고에 빠지지 않도록 전체 흐름과 사용자 경험 관점에서 의사결정을 이끌어야 한다.

그리고 이 모든 판단의 순간에서, 늘 문제가 되는 것이 있다. 논리적으로 맞는 선택인데도 불안할 때, 직감적으로 끌리지만 근거가 없을 때, 우리는 어떻게 결정해야 할까.

다음 원칙에서, 감정이 흔들릴 때의 선택 설계를 이야기한다.

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

주석

¹⁾ Parking Lot — 제품 개발에서 현재 사이클에서는 다루지 않지만, 영구적으로 폐기하는 것이 아니라 향후 재검토 대상으로 분류하는 관리 방식. "안 한다"가 아니라 "지금은 안 한다"라는 시간 범위가 있는 결정이며, 이해관계자와의 갈등을 줄이면서 범위를 관리하는 데 효과적이다.

²⁾ AI Design Thinking — IBM이 2018년에 체계화한 방법론으로, 기존 Design Thinking의 사용자 중심 문제 정의 과정에 데이터 유형 파악(정형/비정형)과 기술적 제약 확인을 통합한 것이 핵심 차별점이다. 워크숍에 데이터 엔지니어, AI 엔지니어 등 테크니션이 반드시 참여하여, 문제 정의 단계에서부터 AI로 해결 가능한 범위와 필요한 데이터의 존재 여부를 동시에 검증한다.

³⁾ Design Thinking — IBM, IDEO 등에서 체계화한 문제 해결 방법론. 공감(Empathize) → 정의(Define) → 아이디어(Ideate) → 프로토타입(Prototype) → 검증(Test)의 5단계로 구성되며, 사용자의 숨겨진 필요를 발견하고 그에 맞는 해결책을 설계하는 데 초점을 둔다.

⁴⁾ POC(Proof of Concept) — 개념 검증. 새로운 기술이나 아이디어가 실제로 작동하는지를 소규모로 검증하는 단계. 완성된 제품을 만드는 것이 아니라, "이 아이디어가 현실에서 의미 있게 작동하는가"를 확인하는 실험이다.

⁵⁾ LLM(Large Language Model) — 대규모 언어 모델. 방대한 텍스트 데이터를 학습하여 자연어를 이해하고 생성할 수 있는 AI 모델. ChatGPT, Claude 등이 대표적이며, 텍스트 요약, 코드 작성, 데이터 분석 등 다양한 업무에 활용된다.

⁶⁾ System Design — 제품이 실제 운영 환경에서 지속적으로 작동하기 위해 필요한 전체 구조를 설계하는 것. 데이터의 입력과 처리, 사용자와의 상호작용, AI와 사람 사이의 핸드오프 지점, 오류 발생 시 대응 방식 등을 포함한다. POC가 "이것이 작동하는가"를 확인하는 것이라면, System Design은 "이것이 안정적으로 계속 작동하게 만드는 것"이다.