5 Whys JTBD 진짜 문제 정의

정의하기 단계와 문제 맥락 이해

디자인 씽킹에서 정의하기 단계는 전체 프로젝트의 방향을 결정짓는 매우 중요한 구간입니다. 공감하기 단계에서 인터뷰와 관찰을 통해 많은 인사이트를 모아 두었더라도, 그것을 어떻게 정리하고 한 줄의 문제 정의로 압축하느냐에 따라 이후 여정이 완전히 달라지기 때문입니다. 이 단계가 흔들리면 팀은 겉으로 드러난 증상만 고치다가 시간과 예산을 소모하기 쉽고, 사용자가 체감하는 변화도 크지 않게 끝나곤 합니다. 그래서 많은 팀이 “문제를 더 잘 이해해야 한다”는 필요성에는 동의하지만, 실제 작업에 들어가면 어떤 질문을 던지고 어떤 틀로 정리해야 하는지 막막함을 느끼십니다. 이때 5 Whys와 JTBD라는 두 가지 도구를 함께 사용하면, 표면적인 불편 뒤에 숨어 있는 진짜 원인을 더 깊이 있게 추적할 수 있습니다. 5 Whys는 왜라는 질문을 반복해 근본 원인에 도달하도록 도와주는 질문 구조이고, JTBD는 사용자가 어떤 일을 해내기 위해 우리 제품과 서비스를 “고용”하는지에 초점을 맞춘 관점입니다. 두 관점을 함께 쓰면 사용자의 상황·동기·제약이 입체적으로 드러나며, 팀은 무엇을 해결해야 하는지 한 문장으로 또렷하게 정리할 수 있습니다. 정의하기 단계가 분명해질수록 아이데이션과 프로토타입, 테스트 단계에서도 의사결정의 기준이 흔들리지 않고, 서로 다른 이해관계를 가진 팀원들도 같은 문제 그림을 바라보며 협업할 수 있습니다.

5 Whys로 진짜 문제 정의하기

정의하기 단계에서 5 Whys를 적용할 때는 먼저 공감하기 단계에서 모은 자료를 한 번 더 차분히 펼쳐 보는 일부터 시작하시는 것이 좋습니다. 인터뷰 녹취, 관찰 메모, 설문 응답, 서비스 사용 로그 등을 벽이나 온라인 보드에 한꺼번에 붙여 놓고, 자주 등장하는 장면과 표현을 표시합니다. 그다음 대표적인 사례 하나를 골라 “누가, 어떤 상황에서, 무엇을 하려다가, 어떤 불편을 겪었는가”를 한 문장으로 정리합니다. 예를 들어 “사용자는 회원 가입 과정에서 자주 이탈한다”처럼 문제를 진술했다면, 이제 여기에서 5 Whys를 시작할 수 있습니다. 첫 번째 질문은 단순합니다. “왜 사용자는 회원 가입 과정에서 이탈할까?”입니다. 팀원 각자가 생각하는 이유를 제한 없이 적어 본 뒤, 가장 가능성이 높다고 판단되는 답을 선택해 두 번째 왜를 던집니다. “왜 그 화면 구성이 복잡하게 느껴질까?”와 같은 방식으로 질문을 이어가다 보면, 처음에는 단순히 화면 문제로 보였던 현상이 사실은 “가입의 필요성을 충분히 이해하지 못해서”라든가 “처음 방문이라 신뢰가 충분히 형성되지 않아서”와 같이 더 깊은 층위의 원인으로 이어지기도 합니다. 이때 중요한 점은 정답을 한 번에 찾겠다는 태도보다, 각 단계에서 관찰 근거와 데이터를 바탕으로 가능한 원인을 차분히 정리하는 태도입니다. 사람에게 책임을 돌리는 문장으로 마무리하지 않는 것도 매우 중요합니다. “사용자가 설명을 안 읽어서 그렇다”라는 식으로 끝나면 팀이 할 수 있는 행동이 거의 남지 않습니다. 대신 “설명이 눈에 잘 들어오지 않는다”, “가입 전 이점이 충분히 전달되지 않는다” 등 환경이나 흐름을 바꾸어 표현하면, 팀이 실제로 손댈 수 있는 문제 정의로 바꿔 낼 수 있습니다. 워크숍에서는 화이트보드 상단에 최초 문제 진술을 적고, 아래로 내려가며 왜와 답을 계단처럼 정리해 두면 생각의 흐름이 한눈에 들어옵니다. 각 단계마다 다른 가설이 나올 때는, 누가 더 논리적인지를 따지기보다는 어떤 가설이 실제 데이터와 관찰 기록과 더 잘 맞는지 함께 검토해 보는 편이 좋습니다. 그렇게 여러 번의 왜를 거치고 나면, “우리가 해결해야 할 문제는 가입 화면이 예쁜가가 아니라, 처음 방문한 사용자가 안전하다고 느끼고 가입을 시도할 만큼 충분한 이해와 신뢰를 얻을 수 있는가이다”와 같은 형태의 문장이 남게 됩니다. 이것이 바로 5 Whys를 통해 다듬어진 진짜 문제 정의이며, 이후 단계에서 어떤 아이디어를 선택할지 결정하는 기준점이 됩니다.

JTBD로 문제와 기회를 재구성하기

5 Whys가 문제의 뿌리를 파고드는 질문 도구라면, JTBD는 사용자가 실제로 해내고 싶은 “일”을 중심으로 상황을 재구성하도록 돕는 관점입니다. 여기서 말하는 일은 직업이나 직무가 아니라, 사용자가 특정 맥락에서 달성하고 싶은 결과를 의미합니다. 배달 앱을 예로 들면, 우리는 흔히 “야식을 주문하는 사용자”라고 표현하지만, JTBD 관점에서는 “퇴근 후 요리할 힘은 없지만 따뜻한 식사로 하루를 정리하고 싶은 사람”으로 바라보게 됩니다. 이렇게 정리하면 사용자는 단순히 메뉴를 고르는 사람이 아니라, 피로와 시간 부족이라는 제약 속에서 하루를 잘 마무리하고 싶은 목표를 가진 존재로 보입니다. 정의하기 단계에서 JTBD를 활용하려면 먼저 대표 사용자군을 설정하고, “언제, 어디서, 무엇을 하려다가, 어떤 장애물 때문에, 어떤 감정을 느끼는지”를 포함한 상황 설명을 만드시는 것이 좋습니다. 그 다음, 그 사용자가 우리 제품을 통해 얻고 싶은 기능적 이득과 감정적 만족을 나누어 적습니다. 기능적 이득은 시간 단축, 오류 감소, 비용 절감처럼 눈에 보이는 효과이고, 감정적 만족은 마음의 여유, 스스로에 대한 만족감, 주변 사람들에게 인정받는 느낌처럼 심리적인 변화를 포함합니다. 이를 하나의 문장으로 정리하면, 예를 들어 “퇴근 후 지친 상태에서 나는 요리에 시간을 쓰지 않고도 따뜻한 식사를 빠르게 해결하고 싶다. 그래서 배달 서비스를 이용해 간단히 주문을 완료하고, 오늘 하루를 잘 마무리했다는 안도감을 얻는다”와 같은 형태가 됩니다. 이렇게 JTBD 문장을 여러 개 만들어 두고 5 Whys로 도출한 근본 원인과 함께 놓고 보면, 우리가 정의한 문제가 사용자의 실제 일과 얼마나 맞닿아 있는지 확인하기가 훨씬 쉬워집니다. 앞서의 회원 가입 이탈 문제도 “빠르게 따뜻한 식사를 해결하고 싶다”는 일과 연결해 보면, 단순한 전환율 지표가 아니라 사용자의 중요한 일을 가로막는 장애물로 보이게 됩니다. 그러면 해결책 역시 “입력 칸을 줄이자” 수준에서 머무르지 않고 “첫 방문 사용자가 신뢰와 이해를 쌓을 수 있는 흐름을 만들자”로 확장됩니다. 반대로, 만약 우리가 만든 문제 정의 문장이 어떤 JTBD와도 자연스럽게 연결되지 않는다면, 아직 공감 자료를 충분히 해석하지 못했거나, 내부 관점에 치우친 정의일 가능성이 높습니다. 이때는 공감 노트와 JTBD 문장을 다시 읽어 보며 “이 정의가 사용자가 진짜로 해내고 싶은 일과 관련이 있는가?”라는 질문을 던져 보는 것이 좋습니다. 5 Whys와 JTBD는 이렇게 서로를 보완하며 정의하기 단계를 한층 더 단단하게 만들어 줍니다.

정의하기 단계 완전 정복 정리

정의하기 단계는 화려한 아이디어를 내는 시간이 아니라, 공감 과정에서 모아 둔 자료를 바탕으로 팀이 같은 문제를 바라보도록 정렬하는 과정입니다. 겉으로 보기에는 조용한 정리 작업처럼 느껴질 수 있지만, 실제로는 이후 모든 단계의 성공 가능성을 좌우하는 핵심 토대라고 할 수 있습니다. 5 Whys와 JTBD는 이 중요한 단계에서 매우 실용적인 역할을 해 줍니다. 5 Whys는 왜라는 질문을 반복해 증상 뒤에 숨어 있는 근본 원인을 드러내고, 문제를 우리 팀이 행동할 수 있는 언어로 바꾸도록 도와줍니다. JTBD는 사용자를 기능 이용자가 아니라 어떤 일을 이루려는 주체로 바라보게 하여, 우리가 정의한 문제가 실제 삶의 맥락과 연결되어 있는지 점검할 수 있게 해 줍니다. 실무에서는 이해관계가 복잡할수록 문제 정의가 회의 중간에 미묘하게 바뀌어 버리기 쉽습니다. 그래서 회의 실 또는 온라인 문서의 맨 위에 합의된 문제 정의 문장을 적어 두고, 새로운 아이디어나 요구가 나올 때마다 “이 내용은 우리가 해결하려는 문제와 어떤 관련이 있는가?”를 확인하는 습관이 필요합니다. 또한 문제 정의 문장 옆에는 실제 인터뷰에서 들은 사용자 표현을 함께 적어 두면 좋습니다. 이렇게 하면 논의가 길어지더라도 팀이 사용자의 목소리를 잊지 않고, 추상적인 슬로건이 아닌 현실과 연결된 정의를 유지할 수 있습니다. 정의하기 단계는 한 번에 완벽하게 끝내야 하는 시험이 아니라, 프로젝트가 진행되는 동안 여러 번 다시 돌아와 다듬는 살아 있는 문장이라고 생각하시면 편합니다. 5 Whys와 JTBD를 반복해서 사용해 보시다 보면, 어느 순간부터는 문제를 보는 눈이 자연스럽게 달라지고, 회의에서 나오는 해결책의 깊이도 확실히 달라지는 경험을 하시게 될 것입니다. 그렇게 단단해진 문제 정의 위에서 만들어진 아이디어와 솔루션은 실제 사용자에게 더 큰 의미 있는 변화를 만들어 내고, 팀에게도 “우리가 정말 중요한 일을 하고 있다”는 확신을 주게 됩니다.