[입문 과제 우수 사례] 본받을 만한 사고방식과 디테일

 

지난 과제의 우수 사례를 바탕으로, 어떤 과제가 좋은 평가를 받았는지 살펴보는 특강이 있었다.

 

다양한 관점으로 본받을 만한 사고방식과 디테일을 살펴볼 수 있는 시간이었다.
(부끄럽지만 .. 본인의 과제도 우수 사례로 선정 되었다. 뿌듯하기도 하고, 어떤 점이 우수하고 부족한지 더 인지할 수 있는 좋은 기회였다!)

---

우수 사례 선정 기준

기준	의미
논리적 연결	데이터 분석부터 문제 정의, 원인 분석, 해결 방안까지 자연스럽게 이어지는가?
타당한 근거	의견이나 주장을 뒷받침할 수 있는 이유와 근거가 제시되어 있는가?
실현 가능성	실무 관점에서 현실적이고 실행 가능한 해결 방안인가?

---

리뷰 데이터 분석

데이터 카테고리화 할 때, 각 카테고리별 의미 정의

카테고리 이름만 있으면, 작성자와 읽는 사람이 서로 다르게 해석할 수 있기 때문에
각 카테고리에 어떤 리뷰들이 해당하는지 포함 기준 정의를 함께 작성
“이 리뷰는 왜 이 카테고리에 들어가는가?”를 설명할 수 있어야 한다.

---

하나의 데이터에 여러 카테고리가 있으면 중복 매핑

사용자가 실제로 말한 불편을 왜곡 없이 반영하는 것이 더 중요

실제 사용자의 리뷰에는 하나의 문제만 담겨 있지 않은 경우가 많다.
e.g) “쿠폰 적용도 복잡하고 결제 단계도 많다”는 리뷰에는 혜택/프로모션 문제와 구매/결제 문제가 함께 들어 있음
이때 억지로 하나의 카테고리에만 넣으면 실제 불편의 빈도가 왜곡될 수 있음 주의!

---

불만 리뷰뿐 아니라 만족 리뷰도 활용하기

리뷰 분석은 불만을 찾는 작업이 아니라, 사용자 기대와 서비스 가능성을 함께 읽는 작업

부정 리뷰는 해결해야 할 문제를 보여주고, 긍정 리뷰는 유지하거나 강화해야 할 가치를 보여준다.
e.g) “추천이 점점 좋아지고 있다”는 리뷰가 있다면,
단순히 추천 기능을 없애는 방향이 아니라 초기 학습 기간을 어떻게 견디게 할 것인가라는 방향으로 문제를 다시 볼 수 있다.

---

문제 원인 분석

로직트리와 5 Whys를 목적에 맞게 사용하기

문제 원인 분석에서는 로직트리와 5 Whys를 함께 활용한 사례가 인상적이었다.
먼저 로직트리로 가능한 원인을 넓게 정리한 뒤,
실제 서비스 화면과 사용자 여정을 확인하여 이미지 첨부 방식으로 확인 시켜 주고,
VOC 비중이 높거나 핵심 문제와 가까운 영역을 골라 5 Whys로 깊게 분석했다.

 

도구	역할
로직트리	문제의 원인을 넓게 펼쳐보는 도구
5 Whys	여러 원인 중 핵심 원인을 깊게 파고드는 도구

---

우선순위 선정

Impact와 Effort의 기준을 먼저 정의하기

항목	정의 예시
Impact	리텐션, 리뷰 비중, 비즈니스 목표 연결성 등 어떤 것에 영향을 미치는지
Effort	개선 난이도, 개발 범위, 리소스 투입량 등

---

명확하게 판단이 안되면, 기준을 세분화 해보기

사용자에게는 중요하지만 비즈니스 영향은 작은 문제가 있고, 반대로 비즈니스에는 중요하지만 사용자 체감은 크지 않을 문제도 있다.
우선순위는 감으로 정하는 것이 아니라, 기준을 정의하고, 각 문제에 점수를 준 이유를 설명할 수 있어야 한다.
PM은 “왜 이게 1순위인가요?”라는 질문에 답할 수 있어야 한다.

 

세분화 기준	확인 질문
사용자 영향도	사용자 경험에 얼마나 큰 영향을 주는가?
비즈니스 영향도	구매, 전환, 리텐션, 신뢰도에 영향을 주는가?
빈도	리뷰나 VOC에서 반복적으로 등장하는가?

---

가설 수립

Goal Tree로 지표를 쪼개기

최종 목표를 하위 지표로 쪼개고, 가설에 맞는 핵심 지표와 보조 지표를 설정

 

구분	예시
최종 목표	혜택 가치 체감 강화
핵심 KPI	혜택 적용 구매 비율
하위 지표	혜택 사용률, 쿠폰 사용률, 혜택 적용 구매 전환율 등

---

목표 수치에도 근거를 붙이기

지표를 설정할 때 단순히 “10% 오를 것이다”라고 쓰는 것보다,

왜 그 정도의 목표치를 잡았는지 근거를 함께 제시하는 것이 좋다.
내부 데이터가 없다면 벤치마크 자료, 외부 리서치, 유사 서비스 사례를 참고해 보수적으로 목표치를 설정할 수 있다.

지표는 있어 보이게 붙이는 숫자가 아니다.
가설이 맞았는지 틀렸는지 판단하기 위한 검증 기준이다.

---

해결 방안 작성

검증된 레퍼런스를 활용하기

해결 방안을 작성할 때 바로 화면 개선안부터 제시하는 경우가 많은데, 먼저 유사 서비스와의 구조를 비교해보면 좋다.

예시) 탐색형 커머스 서비스의 마이페이지를 비교하고, 공통적으로 사용되는 UI 패턴을 찾은 뒤, 우리 서비스에 적용할 방향을 제안

“이렇게 바꾸면 좋을 것 같다”보다
“유사 서비스에서는 이런 패턴이 공통적으로 사용되고 있고, 우리 서비스는 이 부분이 부족하다”라고 말하는 것이 더 설득력 있다.

 

방식	의미
타사 레퍼런스 분석	시장에서 이미 검증된 패턴 확인
공통 패턴 도출	여러 서비스가 공통적으로 사용하는 구조 파악
As-is / To-be 제시	현재 문제와 개선 방향을 시각적으로 비교

---

유저를 세그먼트로 나누어 보기

모든 유저에게 같은 해결 방안이 같은 효과를 내지는 않는다.

e.g) 사용자를 초기 유저, 일반 유저, 충성 유저처럼 나누고, 각 세그먼트에 맞는 해결 방안을 고민
* 우수 사례에서는 공개된 시장 데이터와 거래액 데이터를 바탕으로 인당 구매 횟수를 역산해 세그먼트 기준을 정의했다. (넘나 논리적 ✨)

유저 세그먼트를 나눌 때도 “그냥 초기/일반/충성 유저”라고 나누면 안 된다.
가능하면 구매 횟수, 방문 빈도, 이용 기간처럼 정량적 기준을 함께 고민해야 한다.

---

결론) 앞으로 유의할 점

단계	유의할 점
리뷰 분석	카테고리 기준을 정의하고, 하나의 리뷰에 여러 문제가 있으면 중복 태깅 고려
데이터 해석	부정 리뷰뿐 아니라 긍정 리뷰에서도 유지·강화할 포인트 찾기
원인 분석	프레임워크를 채우는 것보다, 왜 그 도구를 쓰는지 목적 이해하기
우선순위 선정	Impact, Effort 같은 판단 기준을 먼저 정의하고 이유 남기기
가설 수립	변수, 예상 결과, 검증 지표가 연결되도록 작성하기
해결 방안	레퍼런스, 사용자 세그먼트, 실현 가능성을 근거로 제안하기

판단의 근거
분류 기준, 우선순위, 지표, 유저 정의, 해결 방안 모두 “왜 그렇게 했는가?”를 설명할 수 있어야 한다.
잘한 기획은 항상 Why가 있다.

왜 이 카테고리로 분류했는지, 왜 이 문제가 핵심 문제인지, 왜 이 지표로 검증해야 하는지, 왜 이 해결 방안이 현실적인지
설명할 수 있어야 한다.