문제 정의는 기획의 시작입니다 - 서비스 기획자가 꼭 알아야 할 '문제 정의' 방법 | 0100dev 인사이트

안녕하세요, 제로백데브입니다!

많은 서비스가 출시 후 이런 고민을 합니다.

“우리 서비스, 기능도 좋고 디자인도 깔끔한데, 왜 사용자들이 안 쓸까?”

대부분의 문제는 기능이나 디자인 이전에 문제를 제대로 정의하지 않은 데서 시작됩니다. 문제를 정확히 짚어내지 않으면, 아무리 개발을 잘해도 엇나간 방향으로 가기 쉽습니다.

이번 칼럼에서는 서비스 기획자의 시선에서 실전적인 문제 정의 방법을 정리해봤습니다.

1. 기능보다 먼저, '문제'를 정의해야 하는 이유

기획이 기능 중심으로 흘러가는 경우가 참 많습니다.

“챗봇 기능을 넣고 싶어요.”

“초기 문의가 계속 반복되어 상담 리소스가 아까워요.”

표면적으로는 기능 요청처럼 보이지만, 사실 이 안에는 문제가 숨어 있습니다. 좋은 기획은 기능이 아니라 문제에서 출발합니다. 즉, "우리는 어떤 문제를 해결하기 위해 이 서비스를 기획하는가?", 이 질문이 기획의 출발점입니다.

2. 좋은 문제 정의

문제를 정확하게 정의하기 위해서는 아래의 항목들이 기본 구조가 됩니다.

이 다섯 가지를 정리하면 문제의 구조가 한눈에 보이고, 이후의 기획이 훨씬 선명해집니다.

3. 프레임워크 활용: 'How Might We' (HMW) 기법

문제를 문장으로 적어두면 막연하게 느껴질 때가 많습니다. 이럴 때 문제를 질문형으로 바꾸는 HMW 기법을 사용하면 해결 방향이 자연스럽게 떠오릅니다.

예시를 보겠습니다.

질문을 이렇게 바꿔 놓으면 해법이 도미노처럼 이어집니다.

문제를 여는 방식 하나만 바꿨는데도, 접근 방식이 훨씬 넓어지죠.

4. 문제 정의 → 가설 설정 → 해결책 도출의 흐름

기획의 흐름은 사실 단순합니다.

문제를 대충 정의하면, 개선 방향도 흐릿해집니다. 기획자는 이 세 단계를 논리적으로 연결해야 하기에, 문제 정의가 정확해야 전체 구조가 탄탄해집니다.

5. 문제를 정의할 때 자주 하는 실수

1) 요구사항과 문제를 혼동하는 경우

“예약 캘린더를 추가해달라”는 ‘요구’입니다. 하지만 기획자는 왜 필요한지, 무엇이 불편한지 질문해야 합니다. 즉, 요구의 뒤에 숨겨진 실제 문제를 찾아야 합니다.

2) 경험 없는 사람의 의견에 과도하게 의존

사장님과 임원분들의 의견은 참고가 될 수 있지만 절대 기준이 될 수는 없습니다. 기획의 기준은 언제나 유저나 데이터여야 합니다.

3) 정량적 근거 없이 추측

“이건 불편할 것 같아요”가 아니라 “NPS 점수 3 이하가 58%입니다”와 같은 구체적인 근거가 필요합니다. 데이터가 문제 정의의 토대를 단단하게 만들어 줍니다.

좋은 기획자는 '기능을 만드는 사람'이 아니라, 문제를 정확히 정의하고, 해결 방향을 설계하는 사람입니다. 기획서를 쓰기 전에 스스로에게 이렇게 물어보십시오.

“이 기능은 어떤 문제를 해결하고 있는가?”

이 질문 하나가 기획의 방향을 바꿉니다.

문제 정의는 기획의 시작입니다 - 서비스 기획자가 꼭 알아야 할 '문제 정의' 방법