PM 공부하기

[실습] 서비스 흐름 분석 ~ 문제 정의 및 해결책 도출 - SOOP Case Study

mtepg924 2025. 4. 9. 21:03

오늘 실습한 내용

1. 서비스 흐름 및 데이터 흐름

📶 서비스 흐름 (플랫폼 기능 흐름)

흐름 단계 주요 기능 사용자 흐름(시청자) 사용자  흐름(스트리머)
사용자 진입 - 웹 or 앱 방문/탐색: 추천 피드, 카테고리 필터, 실시간 인기 방송 리스트
- 가입/온보딩: 방송 권한 신청, 기본 프로필 설정
1 1
방송 시청/운영 플레이어 UI, 실시간 채팅, 도네이션 인터랙션 2 3
방송 송출 방송 세팅 화면, 스트리밍 서버 연동, 관리자 기능 - 2
방송 종료 후 VOD 저장, 클립 생성, 방송 통계 제공 3 4

📊 데이터 흐름 (활용되는 사용자 데이터)

데이터 종류 활용 목적
시청 로그 (시청 시간, 클릭한 방송 등) 추천 알고리즘 개선, 인기 콘텐츠 선정
채팅 로그 커뮤니티 품질 관리 (도배/욕설 필터링), 사용자 참여도 측정
도네이션/구독 기록 수익성 분석, 사용자 충성도 파악
방송 성과 데이터 (시청자 수, 평균 체류 시간 등) 스트리머 성장 리포트 제공, 서비스 기획 개선
유입 채널 데이터 (푸시, 공유, 검색 등) 마케팅 성과 분석, 콘텐츠 노출 전략 최적화

 


2. 문제 정의

 실시간 방송을 시청하고 있는 단계가, 처음으로 앱을 이용하는 시청자에게도 (activation), 재방문하는 시청자에게도 (retention) 중요한 서비스 흐름 단계로 생각이 되어서, 실시간 방송 중 겪는 pain point로 문제 정의를 해보았습니다.

[Acquisition] 유입 
   ↓
[Activation] 첫 시청/채팅 참여
   ↓
[Retention] 팔로우, 다시보기, 반복 시청
   ↓
[Revenue] 후원, 구독, 광고 시청
   ↓
[Referral] 공유, 초대, 커뮤니티 활동


국내 방송 플랫폼인 SOOP, 치지직 중에서 SOOP이 좀 더 문제가 많이 발견되는 것 같아서 case study하기에 좋다는 판단이 들어 SOOP 문제를 다루었습니다.

 

🔷 SOOP의 pain point 리스트들과 문제 

문제정의 한 줄 요약
  • 중계 프레임 저하
    영상의 끊김과 버벅임으로 인해 시청 몰입도가 낮아지고, 이탈률과 스트리머 이적률이 높아질 수 있다.
  • 실시간 돌려보기 부재
    시청자가 놓친 장면을 되돌려볼 수 없어 맥락 파악이 어렵고, 이로 인해 체류 시간과 만족도가 낮아진다.
  • 모바일 전체화면 채팅 미지원
    모바일에서 전체화면 시 채팅이 불가능해져 실시간 소통이 단절되고, 그로 인해 후원 참여 및 재방문 가능성이 감소한다.
문제 항목  사용자 관점 비즈니스 관점  데이터 관점
“어떤 Pain point들이 있을까?” "이 단계에서 사용자가 느낄 수 있는 불편함은?" "비효율이나 비용이 증가하는 지점은?" "어떤 데이터를 활용해 이 문제를 해결할 수 있을까?"
1. 중계 프레임 저하 “보는 도중에 끊기고 버벅여서 몰입이 안 돼요.” - 스트리밍 품질에 대한 신뢰도 하락 → 플랫폼 이탈

- 고품질 방송을 원하는 전문 스트리머 유치 실패의 위험 
- 프레임 드랍, 재시청 시도 로그, 로딩 중단 로그 : 프레임 저하가 얼마나 이루어지는지 확인
- 프레임 드랍과 이탈률: 프레임 저하로 인해 이탈률이 증가하는지 상관관계 확인

⇒ 데이터 수집에 너무 큰 resource가 필요할 듯
  

- 전문 스트리머 인터뷰: SOOP → 다른 플랫폼으로 이적한 스트리머들 인터뷰 | | 실시간 돌려보기 부재
2. 실시간 돌려보기 부재 "방송 보다가 잠깐 놓쳤는데 다시 볼 수 없어요.”,
“중간에 들어왔는데 무슨 내용인가요?”

- 시청자들이 금방 흥미를 잃고 이탈 → 특히 유입된 사용자의 만족도가 낮아 retention 저하 

- 아하모먼트(스트리머가 방송하는 곳에 들어가서 5분동안 시청)에 도달하는데에도 불편을 준다. 

- 짧은 체류 기간 -> 광고 노출 기회 손실
- 방송 중 seek 시도 (없는 기능 클릭) 로그 :
seek 시도 로그를 통해 해당 기능의 수요를 확인할 수 있다.

- 실시간 시청 도중의 종료 시점 → 놓친 순간과 연관성 :
실시간 방송 중 사용자가 들어온 시점과
사용자가 방송을 나가는 시점 사이의 관계를 분석해본다.
3. 모바일 전체화면 채팅 미지원 “채팅하려면 전체화면을 포기해야해요” - 채팅만 포기하는 경우: 채팅 참여 감소 → 방송 중 후원 유도 감소, 재방문 동기 약화

- 답답해서 나가는 경우: 이탈, 모바일 전체화면에서 채팅 지원하는 다른 앱으로 이동가능
- 화면 모드별(PC vs. 모바일) 채팅 참여율 : PC는 전체화면에서 채팅 참여가 가능하기 때문에 모바일과 PC에서의 채팅 참여율을 비교한다.

- 채팅참여율과 재방문률, 방송 중 후원률 :
채팅참여율-재방문률, 채팅참여율-방송 중 후원률의 상관관계를 분석함으로써 채팅 참여 감소의 영향을 파악한다.

- 모바일 전체화면에서 채팅 지원 기능을 도입했을 때 A/B test

 


3. 문제 원인과 해결책 고안

정의한 문제의 원인:

  1. 중계 프레임 저하: 본질적으로는 국내 통신 법으로 인한 높은 망 사용료 문제. 그리드 CDN을 통해 해결하고 있으나 그리드 CDN 자체의 한계로 인함.
  2. 실시간 돌려보기 기능의 부재: 실시간 버퍼 저장 기능의 도입은 실시간 서버 리소스가 높아지는 문제를 초래해서 도입하는 것이 쉽지 않음
  3. 모바일 전체화면 채팅 미지원: 모바일 UX 테스트 부족일 가능성이 있음.

 

문제를 해결하기 위한 접근:

문제  문제 해결 접근 방식 예상 Risk
1. 프레임 저하 CDN 구조 최적화
(기존 그리드 → 하이브리드 CDN 등)
🔸 망 사용료 증가: 기존에 비용절감 목적으로 그리드 CDN을 썼기 때문에, 일반 CDN이나 멀티CDN을 도입하면 운영비 급증 가능성
🔸 CDN 교체는 플레이어/인코딩 시스템 전체 리팩토링이 필요할 수도 있음
2. 돌려보기 부재 기술적:
DVR 기능 백엔드 구현 (실시간 버퍼 저장)

UX:
하이라이트 타임라인으로 대체
DVR 기능 백엔드 구현: 
🔸 서버 부하 증가: DVR은 스트리밍+녹화를 동시에 요구함 → 트래픽 폭증 시 시스템 불안정 가능성
🔸 DVR 도입에는 스트리밍 구조 대대적 수정 필요

하이라이트 타임라인으로 대체: 
🔸 사용자 입장에서 돌려보기만큼 만족도가 떨어질 수 있음
🔸 스트리머 수동 태깅이 필요한 경우 운영비용 증가

3. 전체화면 채팅 미지원 모바일 전체화면 시에 채팅 버튼 기능 추가 🔸 QA 범위 확대 → 개발 리소스 대규모 투입 필요

 

<개발공수와 난이도>

문제 기술 난이도 개발 공수 개선 효과 예상 전략적 분류
중계 프레임 저하 네트워크/인프라 중심 매우 높음 중요하지만 장기적 장기 핵심 과제
실시간 돌려보기 스트리밍 구조 변경 높음 체류 시간 ↑ 가능 중기 우선 검토 과제
전체화면 채팅 미지원 UI 개선 중심 낮음 소통 참여/후원 유도 ↑ 단기 실행 과제 (Quick Win)

깨달은 점 & 어려웠던 점

오늘은 숲에 대해서 서비스 흐름을 분석하고, 흐름 단계 속에서 발생할 수 있는 pain point를 발견하고, 문제 정의 ~ 문제 해결안 도출 과정을 실습해보았다. 직접 해보니까 역시 이론을 실제에 적용하는 게 쉬운 일이 아니구나라는 것을 깨달았다. 

 

🔷 <오늘 얻은 인사이트>

✅ 이론과 실제는 다르다.

  • 이론적으로는 문제 → 해결안까지 단순해보이지만 실제 서비스에 적용해보니 수많은 제약 조건이 존재
  • PM 역할이 단순히 ‘좋은 아이디어를 내는 사람’이 아니라, 현실적인 제약 속에서 실행 가능한 안을 도출하는 직무라는 걸 체감했다.

✅ 데이터 관점의 문제 정의는 강력하지만, 현실성 체크가 필요 (❗️ROI: Return of Investment❗️)

  • 문제 정의 후 “어떤 데이터를 통해 이를 증명하고 해결할 수 있을까?”를 생각하면 다양한 가능성이 떠올랐다. (1. 중계 프레임 저하 참고)
  • 하지만 실제로:
    • 수집 가능한 데이터인지?
    • 정확도와 해석이 가능한지?
    • 분석 비용 대비 가치가 충분한지?
      → 이런 현실적인 제약을 고려하면 선택지는 급격히 줄어듦
🎯 데이터 기반 사고도 결국은 실행 가능성 안에서만 의미가 있다
(이걸 평소에 자주 인지하지 않으면 PM과 개발자 간의 갈등이 발생할 수 밖에 없다는 것을 체감했다...)

 

 그래서 완벽한 서비스는 드물구나...

  • SOOP의 문제를 분석하며 다양한 개선점이 나왔지만 실제 개선 가능한 것은 리소스/비용 한계로 인해 일부에 불과했다.
  • 특히 실시간 방송 플랫폼처럼
    • 망 사용료 등 구조적인 비용 압박이 큰 서비스는
    • 기능을 만들고 싶어도 못 만드는 상황이 많을 수밖에 없다는 점을 체감했다.

정리하면,

오늘의 가장 큰 배움

✔️ 문제를 해결할 수 있는 방법이 있다고 해서, 반드시 실행할 수 있는 건 아니다.
✔️ 항상 해결책을 제안할 땐, 비용과 리소스를 염두에 두는 현실 감각이 필수다.
✔️ 그래서 PM은 늘 기획의 이상과 실행의 현실 사이에서 균형을 잡아야 하는 사람이다.
✔️ ROI(Return of Investment)