[제품개발]

자주 나온 불만이 가장 급한 문제일까? 빈도와 심각도 따로 보기

2026.10.21.
NACHIVE(나카이브)

많이 보이는 불편과 한 번이어도 큰 피해가 생기는 문제를 서로 다른 칸에서 살핀다.

“버튼 색이 아쉬워요”는 여러 번, “버튼을 눌렀더니 작성 내용이 사라졌어요”는 한 번 나왔습니다. 어느 쪽부터 볼까요? 먼저 불만의 빈도와 발생했을 때의 영향을 따로 적어보세요. 많이 보인다는 이유만으로 더 급한 문제라고 정할 수는 없습니다.

01후기가 많은 이유부터 같은 조건에서 본다

제품 담당자가 가상의 후기 목록을 읽는 장면입니다. 초보자는 같은 말이 몇 번 나왔는지 셉니다. 익숙한 담당자는 얼마나 많은 사람이 그 기능을 썼고, 같은 문제가 여러 경로에서 중복 접수됐는지도 봅니다.

열 명 중 여러 명이 겪은 문제와 많은 이용자 중 일부가 말한 문제는 단순 건수만으로 같게 볼 수 없습니다. 여기서 숫자는 실제 제품 통계가 아닌 비교 설명입니다. 분모를 모르면 발생 비율도 확정할 수 없습니다.

목소리가 큰 문제부터 해결하자는 사람은 고객의 체감을 걱정합니다. 가장 심각한 문제만 보자는 사람은 피해를 걱정합니다. 두 사람의 걱정은 모두 기록하되, 같은 칸에 섞지 않는 편이 판단하기 쉽습니다.

02심각도는 불쾌한 정도만으로 정하지 않는다

Nielsen Norman Group의 사용성 평가 자료는 문제를 볼 때 발생 빈도, 영향, 반복해서 겪게 되는지 등을 고려합니다. 여기서는 후기 분석에 적용할 수 있도록 각각을 나눠 보는 질문으로 바꿔봅니다.

  • 사용 중단: 목표한 일을 계속할 수 있는가?
  • 손실: 데이터·돈·안전·개인정보에 영향이 있는가?
  • 회복: 되돌리거나 우회할 수 있는가?
  • 반복: 한 번 배우면 피할 수 있는가, 사용할 때마다 생기는가?

이 질문은 제품 상황에 맞게 조정할 실무 예시입니다. 점수 몇 점이면 무조건 먼저 고친다는 보편 공식은 아닙니다. 안전이나 개인정보 피해가 의심되면 단순 후기 순위와 별도로 정해진 대응 경로에 연결해야 합니다.

✦단 한 건이어도 먼저 확인할 문제가 있다

작성 내용이 사라졌다는 가상 후기는 발생 조건을 먼저 확인할 가치가 있습니다. 실제 손실이 있었는지, 복구할 수 있는지, 다른 사람에게도 생길 가능성이 있는지 보세요. 아직 확인되지 않았다고 가볍다고 단정하지는 않습니다.

반대로 한 번의 강한 표현만으로 전체 제품이 위험하다고 확정하지도 않습니다. 고객의 진술, 직접 확인한 현상, 추정한 원인을 나누면 확인 순서와 설명 수준을 정할 수 있습니다.

03자주 생기는 작은 불편도 뒤로 밀기만 해서는 안 된다

심각도가 낮다는 말은 고칠 가치가 없다는 뜻이 아닙니다. 작은 불편이 많은 사람에게 반복되면 사용 경험을 계속 방해할 수 있습니다. 큰 문제를 확인하는 동안 작은 개선을 병행할 수 있는지도 봅니다.

서두르는 담당은 쉽게 고칠 색부터 바꾸자고 합니다. 꼼꼼한 담당은 손실 문제의 원인 확인부터 하자고 하죠. 지금 확인할 일과 실제 수정에 필요한 일을 나누면 둘 중 하나를 완전히 포기할 필요가 줄어듭니다.

비용을 아끼려는 담당은 수정이 쉬운 항목을, 품질을 보는 담당은 영향이 큰 항목을 먼저 고릅니다. 수정 비용은 필요하지만 피해의 크기를 대신하는 항목은 아닙니다. 영향과 노력은 서로 다른 기준으로 적습니다.

04우선순위 표에는 모르는 것도 남긴다

교본의 표에는 모든 칸이 깔끔하게 채워져 있습니다. 실제 후기는 짧고, 재현 조건이 빠져 있고, 감정적인 표현이 섞여 있습니다. 모르는 칸을 추정치로 채우기보다 ‘추가 확인’으로 남겨보세요.

  1. 같은 증상을 묶되 같은 원인이라고 단정하지 않습니다.
  2. 관찰한 건수와 비교 가능한 이용 범위를 구분합니다.
  3. 영향과 회복 가능성을 적고 근거가 부족한 칸을 표시합니다.
  4. 확인·임시 대응·수정 중 다음 행동을 정하고 담당 역할을 적습니다.

후기를 믿는 쪽은 모두 진짜라고, 회의적인 쪽은 과장이라고 생각할 수 있습니다. 둘 다 확인 전에 결론을 내린 셈입니다. 반복되는 표현을 단서로 삼되 원인을 검증할 자료를 찾아야 합니다.

05고친 뒤에는 같은 기준으로 다시 확인한다

잘된 개선과 효과가 없던 개선을 비교하려면 수정 전후의 조건을 맞춰야 합니다. 화면을 바꾼 뒤 후기가 줄어도 이용자 수 자체가 줄었다면 같은 의미라고 볼 수 없습니다. 가능한 범위에서 같은 기능과 같은 기간 조건을 봅니다.

문제를 숨기면 문의도 줄 수 있다는 점도 기억하세요. 문의 창구를 찾기 어려워진 것을 개선 성과로 읽으면 곤란합니다. 재현 확인, 사용 완료 여부, 관련 문의 내용을 함께 살펴봅니다.

예전에는 불만을 많이 모으는 것으로 조사를 끝냈다면, 다음에는 두 열을 더 만들어보세요. “발생하면 무슨 일이 생기나”, “아직 무엇을 모르나.” 큰 목소리와 큰 문제 사이의 거리가 보이기 시작합니다.