5whys 분석 초반부터 막힐 때, 이렇게 풀었습니다
이미 정해진 답이 아닌, 진짜 ‘왜’를 찾아가기 #5whys잘하는법
인트로
이쯤 답이 나온 것 같은데? 뭘 더 질문해야 하는거야?
프로젝트를 하다 보면 다들 ‘5 Whys 접근법’ 한 번쯤은 들어봤을 거예요.
뭔가 문제의 원인을 찾으려면 “왜?”를 다섯 번 물어보면 된다! 간단하죠?
이게 잘 되면 뭐 문제 해결 끝, 행복 끝! 근데 현실은 좀 달라요.
5 Whys 접근법을 적용할 때면, 이런 순간이 꼭 찾아와요.
모두가 진지한 표정으로 "이번엔 진짜 근본적인 원인을 찾아보자고!"하며 호기롭게 시작해요.
첫 번째 '왜?'까지는 쉽게 나옵니다. 두 번째 '왜?'도 그럭저럭 괜찮고요.
하지만 어느 순간 답이 꼬리에 꼬리를 물고 연결되지 않고 뻔한 말만 반복되고 있는 상황을 발견하게 돼요.
"왜 이 버튼을 눌렀을까?"
"사용자가 편리하다고 생각해서요."
"그럼 왜 편리하게 느꼈을까?"
"음… 그냥 편하니까?"
점점 질문과 답이 수렁에 빠지고 있다는 느낌, 다들 경험해보셨나요?
이런 경우 대부분 두 가지 반응을 보여요.
첫 번째는 애써 "음, 이쯤에서 답이 나온 것 같은데?" 하고 마무리 지으려는 경우.
두 번째는 "도대체 뭘 더 질문해야 하는 거야?" 하며 멘붕 상태에 빠지는 경우죠.
(뇌 용량 과부하...쒸이익)프로젝트 문제 해결 1
단편적으로 끝나지 않으려면
손에 쥔 UI 솔루션을 내려놓자
이번에도 팀원들이 이 접근법을 시도하면서 꽤나 혼란스러워하는 모습을 봤어요.
겉으론 열심히 "왜?"를 반복하고 있었지만, 실제론 이미 머릿속에 정답을 정해두고 그 방향으로만 달려가고 있었던 거예요. 그 결과, 두세 번의 질문을 지나면 빠르게 "UI를 이렇게 바꾸면 되겠네!"라며 해결책으로 직행하려는 경향이 강하게 나타났죠. 그게 문제였어요.
(답이 빨리 나오면 좋은거 아닌가...?)이미 솔루션을 손에 쥔 채로 ‘이게 답이야!’를 외치며 5 Whys를 푸는 꼴이랄까요?
문제를 제대로 이해하고 풀려고 한 게 아니라, 그냥 내가 내린 결론에 도달하는 지름길을 찾으려는 것 같았어요. 이러다 보니 진짜 원인에는 다가가지도 못하고, 몇 번 질문 던지다가 “이 문제는 UI가 불편해서 생긴 거야”로 끝나버리죠.
프로젝트 문제 해결 1 - 단편적으로 끝나지 않으려면손에 쥔 UI 솔루션을 내려놓자생각해보면 이건 마치 “왜 내일 비가 올까?”를 묻고선 “구름이 많아서요”라고 답하는 것과 같은 거예요.
겉으로는 그럴듯해 보이지만, 사실 그 뒤에 숨은 복잡한 원인을 놓치고 있는 셈이었죠.
이런 상황에서 과거의 경험이 떠올랐어요.
예전에 비즈니스 모델을 짜면서 5 Whys를 수도 없이 시도했던 때가 있었거든요. 그땐 지금처럼 막힐 때마다 “왜 자꾸 같은 자리에 맴돌지?” 하며 좌절하고, 피드백 받고, 또다시 시도하면서 배운 게 많았어요. 그래서 이번에도 ‘내가 그때 했던 실수를 우리 팀도 반복하고 있구나’ 싶었죠.
팀원들이 헤매는 첫 번째 이유는, 사용자의 감정을 제대로 이해하지 못한 채 '제작자가 잘못 디자인했기 때문'이라는 단정적인 결론을 내리고 있다는 점이었어요. 그들은 사용자가 어떤 맥락에서 그런 문제를 겪었는지, 어떤 감정이었는지 같은 진짜 이유는 전혀 파악하지 않은 상태였죠. 그렇게 단편적으로 문제를 정의하고 나니까, 그 뒤에 이어지는 질문들도 계속 어긋나는 거예요.
프로젝트 문제 해결 1 - 단편적으로 끝나지 않으려면 손에 쥔 UI 솔루션을 내려놓자그래서 팀원들에게 “지금 접근 방식이 왜 문제가 되는지, 사용자가 느끼는 감정의 흐름을 따르지 않으면 어떤 결과를 초래할 수 있는지”에 대해 설명했어요. 사용자가 겪는 문제의 근본 원인을 이해하려면 그들의 감정을 낱낱이 해부하고 분석해야 한다고 강조했죠. 지금처럼 5 Whys를 '제작자의 디자인 의도를 분석하는 도구'로만 사용한다면, 결국 '왜 사용자가 그런 감정을 느꼈는지'를 이해하지 못하게 될 거라고 얘기했어요.
그래서 팀원들에게 “이 문제는 사용자가 어떤 생각과 감정을 가지고 있었을 때 발생한 걸까?”라는 질문으로 다시 접근하자고 제안했어요. 왜 그들이 불편을 느꼈는지, 왜 그 UI가 어색했는지, 단순히 “디자인이 나빠서”가 아니라 그 뒤에 있는 심리적, 환경적 요인들을 파헤치는 방식 말이죠.
그렇게 팀원들도 사용자의 입장에서 생각하기 시작하니까,
점점 ‘왜’를 던질 때 더 구체적이고 심층적인 원인들이 떠오르기 시작했어요.
프로젝트 문제 해결 2
잘하고 있는지 갈피를 못 잡을 때,
문제 범위를 좁히고 거꾸로 짚어보자
우리는 ‘인터파크 티켓 앱의 공연 티켓 예매’라는 큰 주제에서 5 Whys를 적용하기 시작했었어요. 그런데 질문 하나하나가 너무 포괄적이고, 대답도 모호해지다 보니 모두 점점 잘 하고 있는지 갈피를 잡지 못했어요. 이럴 때는 문제의 범위를 확 좁혀서, 내가 정말로 파헤쳐야 할 부분이 무엇인지 명확하게 하는 게 중요해요.
그래서 ‘공연 티켓 예매 중 이탈’라는 넓은 문제에서, ‘콘서트 티켓 예매 중 이탈’이라는 더 구체적인 문제로 범위를 좁좁히자고 제안했어요. 큰 그림에서는 인터파크 티켓 예매의 모든 플로우를 파악해야 했지만, 시간은 6시간으로 한정적이고, 우리에게 필요한 건 더 깊이 있는 분석이었거든요.
(다 똑같은 말 아니냐구...?)문제를 좁힌다고 해도 여전히 혼란스러운 건 마찬가지였어요.
질문을 던지고 답을 해보는데, 팀원들은 계속 같은 위치에서 빙글빙글 도는 느낌을 받았어요.
각자의 관점이 다르다 보니, 다른 문장도 비슷한 의미로 받아들였거든요. “질문/문장1은 뒤로, 질문/문장2는 앞으로.” 이런 피드백이 나오면서는 팀원들이 진짜 혼란에 빠졌죠. “다 똑같은 말 같은데 왜 순서를 바꿔야 하지?”라는 질문도 여기서 나온 거예요.
프로젝트 문제 해결 2 - 잘하고 있는지 갈피를 못 잡을 때,문제 범위를 좁히고 거꾸로 짚어보자여기서 내가 제안한 방법은 간단했어요. 퍼즐을 뒤집어 놓고 맞추는 것 같았어요. 평소에는 하나씩 쌓아 올리면서 문제를 풀었지만, 이번에는 다 지워 놓고 거꾸로 맞춰보기로 한 거죠. 질문을 역순으로 재배치하고 다시 읽어 내려가 보니, 팀원들도 수긍했어요. 문장 하나하나가 서로 어떻게 연결되는지, 어디서 어긋났는지 분명히 보였거든요.
이게 딱 ‘아, 순서가 중요한 거구나!’를 깨닫는 순간이었어요. 같은 문장이라도 어느 위치에 두느냐에 따라 의미가 완전히 달라지니까요. 이 부분에서 팀원들 모두가 처음으로 공감대를 형성했어요. 원래는 질문을 던질 때, “왜 이렇게 질문해?”라며 의문을 제기하던 팀원들이 이제는 ‘이 순서로 진행하면 되는구나!’라며 질문 순서를 정돈하기 시작했죠.
이 경험을 통해 한 가지 확실하게 알 수 있었어요. 문제의 범위를 좁히는 것만큼이나, 질문의 순서와 흐름도 굉장히 중요하다는 점이에요. 5 Whys 접근법이 단순히 ‘왜’를 다섯 번 묻는 게 아니라, 질문과 답 사이의 논리적 연결고리를 찾는 과정이라는 걸 체감했어요. 이 연결고리를 찾으면서, 우리는 더 이상 헷갈리거나 중구난방이 아닌, 명확한 방향으로 나아갈 수 있게 됐어요.
이제 사용자 입장에서 문제를 진짜로 이해할 수 있는 출발점에 섰고,
팀의 논리적 흐름을 바로잡을 수 있었어요.
프로젝트 정리
사용자 관점에서
비즈니스 목적까지 챙기기
왜 넣었을까/왜 안 넣었을까?
이 기능이 존재하거나 없는 이유는 무엇일까? 담당자는 왜 이걸 넣었고, 사용자는 이걸 어떻게 받아들일까?
목적에 도달했는가?
이 기능이 정말 원래 의도한 대로 작동하고 있는가? 아니면 사용자가 엉뚱한 방식으로 이해하거나, 아예 사용하지 않고 있는가?
어떤 식으로 구현할 것인가?
이제 우리가 이 기능을 어떻게 개선할 수 있을까? 현재 상황에서 실제로 더 나은 대안을 제공할 수 있는 방법은 무엇일까?
사용자 행동을 유도 가설?
이 솔루션을 적용했을 때, 사용자가 어떤 반응을 보일지, 어떤 행동을 하게 될지에 대한 예측과 그에 따른 가설은 무엇인가?
(무엇보다 중요한 건 마무리를 잘해야 한다는 것!!)위 템플릿을 사용해 솔루션을 단순히 ‘어떻게 바꿀까’가 아니라 ‘왜 바꿔야 하는가’부터 생각하며 정리했어요. 팀원들은 처음에는 이 구조가 너무 딱딱하다고 느꼈는지, “그냥 UI만 바꾸는 게 더 빠르지 않아요?”라고 물었지만, 막상 적용해보니 이게 꽤 효과적이라는 걸 바로 느꼈어요.
이 과정을 통해, 우리 팀은 다른 팀들과 달리 ‘사용자 관점’에서 출발해 ‘비즈니스 목적’까지 정확하게 맞추는 솔루션을 도출할 수 있었어요. 그리고 그 솔루션을 논리적으로 정리하고, 그 결과를 가설로 세워 실험할 수 있도록 체계적으로 준비했죠.
이 솔루션이 실제로 얼마나 효과적일지는 나중에 검증해봐야겠지만, 적어도 지금은 우리가 문제를 해결하는 방향성과 그 과정을 모두 공감하고 있다는 것만으로도 큰 의미가 있었어요.
이번 프로젝트에서 얻은 가장 큰 교훈은, 솔루션을 도출할 때도 마찬가지로 사용자의 관점에서 시작해야 한다는 점이에요. 디자인은 결국 그걸 쓰는 사람을 위해 존재하는 것이니까요. 내가 해결하고 싶은 문제가 아니라, 사용자가 겪고 있는 문제를 해결해야 진정한 의미의 ‘솔루션’이 될 수 있다는 걸 다시 한 번 확실하게 느꼈어요.
Solution Output
레슨런
잘못된 5whys = 꼬리자르기 게임
혹시 '꼬리 자르기 게임'이란 걸 들어보셨나요?
어릴 때 친구들이랑 한 줄로 서서 앞사람 허리를 잡고, 맨 뒤에 있는 사람의 꼬리(손수건)를 빼앗는 그 게임 말이요.
5 Whys 접근법은 잘못 쓰면 마치 ‘꼬리 자르기 게임’ 같아요.
진짜 원인은 남겨두고 껍데기만 쳐내다 보면, 결국 ‘왜를 물은 것 같긴 한데 도대체 뭘 얻었지?’ 하는 회의감만 남거든요. 결국 겉핥기식으로 원인의 '꼬리'만 자르고 있는 거예요. 진짜 문제는 그대로 둔 채로요.
(뱅뱅 도는 꼬리 자르기에 불과함)그러니까 우리, 질문을 할 때 '내가 이걸 이해하려고 하는가, 아니면 단순히 결론을 내기 위해 묻는가?'를 먼저 생각해봐야 해요. 그렇게 해야만 ‘진짜 원인’을 찾는 데 한 발짝 더 다가갈 수 있을 거예요.
처음엔 좀 어색했어요. 팀원들이 저를 이해하지 못하기도 했고요. 하지만 이 과정을 거치다 보니, "버튼이 안 보여서요." 같은 피상적인 답변 대신, "티켓 오픈 직전의 긴장된 상황에서 복잡한 UI가 사용자의 불안감을 증폭시켰을 수 있어요."라는 식으로요. 더 구체적이고, 더 사용자의 경험에 기반한 질문을 던지는 거예요. 그래야 문제의 꼬리만 잘리는 게 아니라, 머리부터 제대로 해결할 수 있는 거죠.
이 과정에서 우리는 깨달았어요. 5Whys는 그저 형식적으로 다섯 번 물어보는 게 아니라, 각 질문마다 깊이 있는 사고와 진정한 이해를 요구한다는 걸요. 그리고 이렇게 해야만 '진짜 원인'을 찾는 데 한 발짝 더 다가갈 수 있다는 것도요.
