내일배움캠프 TIL: VoC를 어떻게 읽어야 하는가?

 

마케터로 일하면서 고객 리뷰를 많이 봤습니다.

솔직히 대부분 불만과 관련된 내용보다는 제품에 대한 뻔한 내용들이 많았고

리뷰를 가지고 고객 페르소나를 만들거나(콘텐츠 제작, 인플루언서 협찬을 위한)

콘텐츠 카피를 뽑기 위해서 주로 참고용으로 활용했던지라,

고객의 목소리를 가지고 제품 자체를 바꾸는 작업엔 생소했어요.

 

그래서 VoC를 분석하고 적용하는 과정도 납작하게 생각하고 있었던 것 같습니다.

고객의 말을 곧이곧대로 믿는 것과 고객의 말 뒤에 숨은 진짜 문제를 찾는 것은 완전히 다른 행위더라고요.

이번 과제에서 직접 경험한 것들이 오늘 아티클과 맞물려서 훨씬 깊이 이해됐습니다.

 

 

---

1. VoC는 민원 대응이 아니다! PM이 고객 목소리를 읽는 방법

PM의 '고객 지향'이 고객센터와 다른 이유

처음 이 개념을 봤을 때 당연한 거 아닌가 싶었는데,

생각해보면 마케터로 일할 때 저도 VoC를 민원처럼 다룬 적이 많았습니다(cs 업무까지 해야했을 때)

불만 많은 리뷰를 보면 '어떻게 달래지?', '왜 이렇게 생각하는거지?'라는 불만부터 생각했으니까요..

 

고객의 문제 해결은 목적이 아닌 수단이다. 궁극적으로는 사용자 증가, 매출 증진, 시장 점유율 확대 등 사업 목표를 달성해야 한다.

 

아, 이게 PM적 사고라는거구나.. 싶었습니다.

 

어떤 VoC를 중요하게 봐야 하는가

세 가지 기준으로 판단할 수 있습니다.

쉽게 예시를 들어서 설명하자면...

① 누구의 불편인가 : 핵심 고객 필터

제품의 핵심 가치를 경험하면서 제품과 핏이 잘 맞는 고객의 목소리가 우선입니다.

유기농 카레 식당에서 "왜 이렇게 비싸요?"라는 A 고객보다 "지인한테도 추천할게요"라는 B 고객이 더 중요한 것처럼요.

 

② 얼마나 자주 겪는가 : 빈도 필터 

핵심 고객이 아니더라도, 대다수 유저에게서 반복적으로 나타나는 불만은 중요합니다.

이 문제가 해결되지 않으면 잠재적 핵심 고객이 될 수 있는 사람들의 성장 가능성을 막기 때문입니다.

 

③ 제품 핵심 가치와 관련 있는가 : 연관성 필터

"탄산음료가 있으면 좋겠다"는 의견은 유기농 카레의 핵심 가치와 무관합니다.

핵심과 관계없는 VoC는 우선순위를 조정해도 됩니다.

 

④ 의도된 불편은 아닌가 : 정체성 필터

어떤 불편은 제품의 방향성을 지키기 위해 의도적으로 설계된 경우도 있습니다.

Q&A 플랫폼에서 "답변이 자동으로 채택되게 해달라"는 요청은 "신뢰할 수 있는 양질의 답변"이라는 핵심 가치를 저해할 수 있어요.

고객의 말을 곧이곧대로 믿으면 안 되는 이유, 오늘 과제에서 직접 경험한 것

이게 이론이 아닌 현실이라는 걸 오늘 네플스 과제에서 직접 겪었습니다.

• "인공눈물 검색 결과가 별로다" → 실제로는 알고리즘 문제가 아니라 의약품 판매 불가 안내 부재
• "알림이 없다" → 기능 자체가 없는 게 아니라 알림 설정을 켜야만 받을 수 있는 구조
• "검색이 별로다" → 반팔 검색의 경우 알고리즘 문제가 아니라 패션 버티컬 대비 큐레이션 깊이의 구조적 차이

리뷰 표면의 언어를 그대로 믿었다면 완전히 다른 문제를 정의할 뻔했어요.

앱을 직접 써보고 데스크 리서치로 맥락을 채우는 과정이 왜 필수인지 이제 체감이 됩니다.

생존자 편향을 넘어서, VoC가 전부가 아닌 이유

VoC를 남기는 사람은 전체 고객의 일부입니다.

창업 성공 케이스만 보고 준비했다가 실패하는 것처럼, 보이는 불만이 전부라고 착각하면 안 됩니다.

현황 지표가 예상과 다를 때 "어떤 부분에 문제가 있을 거야"라는 가설과 함께 능동적으로 탐구해야 하고,

필요하다면 직접 고객에게 인터뷰를 요청하는 것도 방법입니다.

---

2. 서비스 정책 설계, 화면이 아닌 정책으로 기획하기

사실 서비스 기획 입문 강의를 들으면서 이 부분이 가장 감이 안 왔습니다.

"서비스 정책"이라는 말 자체가 막연하게 느껴졌거든요.

근데 4가지 요소로 나눠보니 훨씬 구체적으로 이해됐습니다.

서비스 정책 설계 4요소

요소	질문	결과물
소통	사용자·구성원과 어떻게 원활하게 소통할까?	용어 정의
가치	사용자가 기능의 가치를 어떻게 느낄까?	사용자 시나리오 정의
정보	서비스와 사용자에게 어떤 데이터가 필요할까?	데이터 정의
이용	사용자가 원활하게 서비스를 이용하려면?	플로우 정의

 

용어 정의가 왜 중요한가

같은 현상을 두고 구성원들이 다르게 묘사하면 소통 비용이 발생합니다.

인하우스 마케터로 일할 때에는 '인수인계'라고 하던 일을 대행사로 오니 '다운로드'라고 하더라구요...?

서비스 이용약관의 "용어의 정의" 항목을 참고하면 좋다고 해서, 앞으로 케이스 스터디할 때 한 번씩 들여다봐야겠습니다.

 

데이터 정의에서 중요한 것

불필요한 데이터를 정의하지 않는 것이 핵심입니다. 데이터 테이블 구조는 서비스 안정성과 직결되어 잦은 수정이 지양되고, 개인정보 보호법 등 법률 준수 관점도 고려해야 합니다.

+) 개인정보 수집은 서비스 본질 기능에 필요한 최소한으로

 

플로우 정의에서 엣지 케이스가 중요한 이유

기본 플로우 외에 "이미 존재하는 아이디라면?", "비밀번호를 1234로 입력한다면?" 같은 일반적이지 않은 상황에 대한 대처 방안을 미리 정의해두는 것이 엣지 케이스 설계입니다. 이걸 누락하면 개발 단계에서 수습하느라 리소스가 낭비됩니다.

한 번에 완벽한 정책 설계를 할 수는 없다. 구현-테스트-배포 단계를 지날 때마다 빠르게 대응하는 것이 중요하다.

---

3. 문제와 가설을 명료하게 쓰는 법, 주니어가 가장 많이 틀리는 것

문제와 해결 방안은 분리하라

기획을 처음 배울 때 가장 흔한 실수가 문제를 정의하는 단계에서 이미 해결책을 떠올리는 것입니다. 야구를 할지 축구를 할지 모르면서 야구 배트부터 들고 나가는 것과 같아요. "1:1 소통 기능을 만들자"는 아이디어보다 "유저들이 댓글로 1:1 대화를 시도하는데, 공개되는 게 불편하다"는 문제 정의가 먼저여야 합니다.

완결성 있게 쓰는 법, 육하원칙

❌ "1:1로 소통할 수 있다면 리텐션이 오를 것 같다"

✅ "법률 관련 질문을 해결하기 위해 질문을 작성하는 일반인 사용자가 채팅 기능을 통해 특정 법률 전문가와 1:1로 소통할 수 있다면 1 month 리텐션 비율이 증가할 것이다"

 

누가, 어디서, 무엇을, 어떻게 할 수 있어야 한다는 내용이 담겨야 팀원 모두가 같은 그림을 그릴 수 있습니다.

사용자 관점으로 쓰는 법, 주어를 바꿔라

문장의 주어를 "우리"가 아닌 "사용자"로 바꾸는 것만으로도 고객 관점이 훨씬 잘 드러납니다.

❌ "신규 가입자 대상으로 30% 할인 쿠폰을 지급하면 이용권 판매량이 50% 증가할 것이다"

✅ "현직자에게 멘토링을 받기 위해 신규 가입한 취업 준비생이 이용권의 할인 혜택을 받는다면 가격 부담이 줄어서 이용권을 바로 구매할 것이다"

 

두 번째 문장에는 고객의 pain point(가격 부담)가 담겨 있고, 구체적인 해결 방법(쿠폰)은 빠져 있습니다.

이렇게 써야 "쿠폰 말고 다른 방법은 없을까?"라는 질문이 가능해집니다.

가설이 명확하면 얻는 3가지 이점

1. 실험·제품 설계 방향이 명확해진다 : 무엇을 만들어야 하는지 팀 전체가 같은 방향을 봅니다
2. 검증 지표가 명확해진다 : 어느 퍼널의 전환율을 볼 건지가 정해집니다
3. 팔로업 방향이 명확해진다 : 가설 성공 시 무엇을 더 확장할지, 실패 시 어디를 고칠지가 보입니다

---

오늘 과제와 연결하면

이번 네플스 과제에서 세운 가설을 오늘 배운 기준으로 점검해봤습니다.

"만약 쿠폰 접근 경로를 단축하고 소멸 임박 알림을 도입한다면, 유저가 혜택을 인지하고 사용하는 비율이 높아져 재방문율이 상승할 것이다."

• 문제와 해결 방안 분리: ✅ 문제(혜택 인지 구조 부재)와 해결(접근 경로 단축, 알림)이 구분되어 있음
• 완결성: 🔺 "누가"에 해당하는 유저 유형이 좀 더 구체적이면 좋았을 것 같음
• 사용자 관점: 🔺 "유저가 혜택을 인지하고"까지는 사용자 관점이지만, 앞부분은 여전히 공급자 관점

다음 케이스 스터디에서는 처음부터 사용자 주어로 가설을 써보는 연습을 해봐야겠습니다.

---

회고

오늘 가장 크게 배운 것

고객의 말은 어디까지나 문제의 '일부'이고, 진짜 풀어야 할 문제는 그 뒤에 숨어 있습니다. VoC를 수집하는 게 목적이 아니라, VoC를 단서로 삼아 진짜 문제를 찾아내는 것이 PM의 역할입니다.

 

앞으로의 계획

오늘 아티클 스터디를 하면서 배운 내용을 과제에도 적용해서 수정해볼 계획입니다.

그리고 이번주 금요일에 진행할 아티클 카타를 위해 내일 선정할 아티클은 좀더 협업 프로젝트 내용 위주로 정해보려고 해요.

 

또 지금까지 케이스 스터디를 "리뷰 보고 문제 찾기"로 접근했다면, 앞으로는 리뷰 외에도 지표 이상 신호를 발견했을 때 가설을 세우고 탐구하는 연습을 추가하겠습니다. 그리고 가설을 쓸 때마다 "주어가 사용자인가?", "문제와 해결 방안이 분리되어 있는가?"를 체크리스트로 확인하는 습관을 들여볼 생각입니다.