문제 정의보다 회의실에서 가장 먼저 나오는 말은 대개 해결책이다. “버튼을 더 크게 만들면 되지 않을까요”, “온보딩 화면을 하나 추가하죠” 같은 제안이 문제가 무엇인지 채 정리되기도 전에 쏟아진다. 이 작업은 해결책을 찾는 것보다 훨씬 어려운데도, 회의 시간의 대부분은 해결책 토론에 쓰이고 문제 정의에는 거의 시간을 쓰지 않는다. 잘못 정의된 문제는 아무리 좋은 해결책을 붙여도 결국 다른 문제를 풀고 있는 셈이 된다.
1. 회의실에서 가장 먼저 나오는 건 해결책이다
해결책을 먼저 던지는 것은 자연스러운 반응이다. 문제를 분석하는 것보다 아이디어를 내는 쪽이 심리적으로 더 만족스럽고, 회의에서 빠르게 기여하고 있다는 인상도 준다. 하지만 이렇게 나온 해결책은 대개 각자가 암묵적으로 상상한 서로 다른 문제에 대한 답이다. 한 사람은 “이탈률이 높다”는 문제를, 다른 사람은 “신규 사용자가 헷갈린다”는 문제를 떠올리고 있다면, 같은 회의에서 나온 해결책들이 서로 다른 방향을 가리키는 게 당연하다.
2. 증상과 원인을 구분하기
이 기술은 증상과 원인을 구분하는 데서 시작한다. “가입 완료율이 낮다”는 증상이지, 그 자체로는 문제 정의가 아니다. 왜 낮은지를 몇 단계 더 파고들어야 실제로 다룰 수 있는 문제가 드러난다. 입력 항목이 너무 많아서인지, 중간에 이탈할 만한 불안 요소가 있어서인지, 애초에 가입 유인이 부족해서인지에 따라 완전히 다른 방향의 해결책이 필요하다. 증상만 보고 해결책을 정하면 다음 분기에도 같은 증상이 다른 모습으로 반복된다. 제품 디자인 컨설팅에서 여러 프로젝트를 진행하며 자주 보는 패턴이 있다. 클라이언트가 처음 제시하는 요청은 대개 “이 화면을 새로 디자인해주세요”처럼 이미 해결책의 형태를 띤다.
💡 실무 포인트 — 클라이언트가 “이 화면을 새로 디자인해주세요”라고 요청하면 곧바로 화면 작업에 들어가지 말고, 왜 지금 화면이 문제라고 느끼는지 먼저 물어보자. 원래 요청과 전혀 다른 진짜 문제가 드러나는 경우가 많다.
3. 좋은 문제 정의문 쓰는 법
좋은 문제 정의문은 누가 읽어도 같은 그림을 떠올릴 수 있을 만큼 구체적이면서도, 특정 해결책을 미리 가정하지 않는다. 이런 방식은 디자인 씽킹을 일상 업무에 적용하는 습관에서 정의 단계가 하는 역할과 정확히 일치한다.
해결책을 가장한 문제
“검색 필터 버튼을 추가해야 한다” — 이미 해결책을 문제처럼 포장한 문장이다.
진짜 문제 정의
“상품을 찾는 사용자가 조건을 좁힐 방법이 없어 목록을 끝까지 스크롤한다” — 다양한 해결책을 열어둔다.
같은 프로젝트를 두고도 기획자는 전환율을, 개발자는 기술 부채를, 디자이너는 사용성을 각각 문제로 보고 있는 경우가 흔하다. 이럴 때는 각자가 생각하는 문제를 한 문장씩 적어보게 하고, 그 문장들을 나란히 놓고 비교하는 절차가 효과적이다. 여러 시각이 겹치는 지점을 찾으면 그것이 진짜 우선순위가 높은 문제일 가능성이 크다. IDEO.org의 디자인 키트도 이 단계에서 여러 이해관계자의 관점을 나란히 놓고 비교하는 방법을 제안한다.
문제 정의 감각은 이론으로 익히기보다 반복해서 다시 써보는 연습으로 는다. 예를 들어 “결제 화면에 진행 표시줄을 추가해야 한다”는 문장에서 왜냐고 물으면 “사용자가 결제 중 얼마나 남았는지 몰라 이탈한다”는 답이 나오고, 다시 왜냐고 물으면 “긴 단계가 예고 없이 이어진다”는 더 근본적인 원인에 닿는다.
현재 작업 하나를 “우리는 ~를 만들어야 한다”는 해결책 문장으로 먼저 적는다
그 문장에서 해결책 부분을 지우고 “왜 이것이 필요한가”를 세 번 반복해서 물어본다
근본 원인에 닿으면, 그 원인을 특정 해결책을 가정하지 않은 문제 정의문으로 다시 쓴다
4. ‘왜’를 몇 번 물어야 하는가
왜냐고 반복해서 묻는 방식은 새로운 아이디어가 아니다. 도요타 생산 방식에서 정착된 5왜 기법은 불량이 발생했을 때 왜를 다섯 번쯤 반복해서 물으면 표면적 증상을 넘어 공정상의 근본 원인에 닿는다는 경험에서 나왔다. 문제 정의에 그대로 적용해도 원리는 같다. 몇 번을 물어야 하는지보다, 멈춰야 할 지점을 아는 것이 더 중요하다.
흔한 실수는 두 방향에서 생긴다. 하나는 첫 번째 ‘왜’ 대답에서 멈추고 그것을 근본 원인이라 단정하는 것이고, 다른 하나는 계속 파고들어 사용자는 원래 그렇다는 식으로 팀이 실제로 손댈 수 없는 지점까지 내려가는 것이다. 근본 원인은 우리 팀의 결정과 행동으로 바꿀 수 있는 지점이어야 실제로 쓸모가 있다.
5. 마치며
이 연습을 팀 전체가 반복하면, 회의에서 해결책이 먼저 나오는 습관 자체가 조금씩 바뀐다. 처음에는 어색하고 시간이 더 걸리는 것처럼 느껴지지만, 몇 번 반복하면 오히려 해결책을 둘러싼 불필요한 논쟁이 줄어드는 것을 체감하게 된다.
지금 다루는 것이 증상인지 원인인지 구분했는가
문제 정의문에 특정 해결책이 이미 가정되어 있지는 않은가
이해관계자마다 생각하는 문제를 각자 한 문장으로 적어봤는가
문제 정의문만 읽고도 팀원이 같은 그림을 떠올릴 수 있는가
해결책 토론 전에 문제 정의에 충분한 시간을 썼는가
같은 문제 정의문을 두고 이해관계자들이 실제로 동의했는가
이 작업은 회의를 늦추는 절차가 아니라 나중에 방향을 다시 잡는 시간을 줄여주는 투자다. 디자인 스프린트를 짧게 압축해 진행할 때도 첫 단계인 문제 정의를 건너뛰면 나머지 과정 전체가 흔들린다. 다음 회의에서는 해결책을 말하기 전에 문제를 한 문장으로 적어보는 시간을 5분만 먼저 가져보자.
Design Daily Life · 디자인의 일상을 기록합니다
한국에 온 외국인 친구가 있나요? 메뉴 번역·택시 요금·약국 카드가 한 앱에 있는 K-OREA를 알려 주세요.
Visiting Korea? K-OREA puts menu scanning, taxi fare guidance and a pharmacy card in one app. Get it on the App Store.