오늘의 퀴즈 정리) 실행 가능한 개선안은 어떻게 만들어지는가(문제 정의부터 로그 설계까지)

• 데이터 드리븐 프로덕트 기획 주차 퀴즈 ▼

• 실행 가능성과 효과성 평가
• 보고서 작성의 명확성과 실행 가능성
• 시청 지속 시간 영향 요소 선정과 분석 설계

1. 실행 가능성과 효과성 — '좋아 보이는 방안' 걸러내기
2. 보고서 작성 원칙 — 명확성 / 일관성 / 실행 가능성
3. 로그 설계 — 무엇을 수집하고, 왜 수집하는가

+) 오늘의 인사이트 / KPT 회고

 

 

---

 

데이터 드리븐 프로덕트 기획
-
본격적으로 데이터 드리븐을 시작하는 느낌...!

 

 

1. 실행 가능성과 효과성 — '좋아 보이는 방안' 걸러내기

• 시청 지속 시간처럼 지표 하나를 개선하려 할 때, 방안은 늘 여러 개가 나온다.
  근데 실제로 서비스에 적용 가능하고 지표에 직접 기여하는 방안을 고르는 기준이 있다.
• 핵심 기준 : 세그먼트 정의 → 원인 분석(코호트) → 구체적 기술 개선

방안 유형	채택 여부	이유
이탈 세그먼트 정의 + 코호트 분석 + 기술 개선 (로딩 속도, 자동재생)	☑️	측정 가능 + 실행 가능, 지표와 직접 연결
비용 대비 효과 불분명한 방안	✖️	실행은 되지만 효과 검증이 안 됨
콘텐츠 단순 확장	✖️	확장이 곧 시청 지속 시간 증가로 이어진다는 근거 없음
신규 유입 늘리는 방안	✖️	유입과 지속 시간은 다른 지표 — 목표와 방안이 안 맞음

• 이걸 실제 이탈 데이터에 적용하면 → '70%가 2~4분 사이 이탈'처럼 구간이 명확하면
  그 구간에 집중해서 가설(난이도 조정, 인터랙티브 요소, 진행 피드백)을 세우고 테스트하는 게 맞다.
  원인 없이 UI만 바꾸거나, 문제 구간을 피해서 다른 콘텐츠를 늘리는 건 회피지 해결이 아니다.
• 5Why로 근본 원인 찾을 때도 같은 논리 적용 :
  • 서비스가 통제 가능한 원인(ex. 요약 부재)까지 파고들어야 실질적 해결책이 나옴
  • 서비스가 통제 불가능한 외부 요인(사용자 개인 사정 등)으로 빠지면 분석은 맞아도 해결책이 없음
  • 중간에 논리 깊이 없이 멈추면(원인 1개만 보고 끝) 피상적 결론이 나옴
    → PM은 방안을 고를 때 '이게 지표에 직접 연결되는가 + 우리가 통제 가능한 영역인가' 두 가지로 먼저 거른다.

 

2. 보고서 작성 원칙 — 명확성 / 일관성 / 실행 가능성

• 데이터 분석 결과를 보고서로 옮길 때 지켜야 할 3가지 기준.

원칙	정의	체크포인트
명확성 (Clarity)	독자가 쉽게 이해하도록 작성	시각화 활용, 핵심 메시지 먼저 제시, 체계적 구조. 전문 용어는 필요할 때만 + 설명 병기
일관성 (Consistency)	전체 문서에서 동일한 용어·서식·구조 유지	같은 개념을 다른 용어로 섞어 쓰면 실패 사례 (ex. 앞에서 '이탈률', 뒤에서 '이탈 비율' 혼용)
실행 가능성 (Actionable)	담당자가 바로 실행에 옮길 수 있게 구체적	Who(담당 부서), When(기간), What(리소스)까지 명시. SMART 원칙(Specific, Measurable, Achievable, Relevant, Time-bound) 따름

• 일관성 관련해서 자주 놓치는 부분 — 용어를 처음 정의할 때 약어를 같이 명시하고, 이후 계속 그 용어만 써야 한다.
  '이탈률'이라고 정의했으면 문서 끝까지 '이탈률'로 통일.(헷갈릴 여지를 안 주는 게 덜 뜯긴다...)
• 실행 가능성 관련해서 자주 나오는 오답 패턴 :
  • 방향은 맞는데 구체성 없음(누가, 언제가 빠짐)
  • 우선순위 없이 여러 방안 나열만 함
  • 데이터 근거 없이 주장만 함 → 설득력 부족
    → PM은 보고서 쓸 때 '이 문장을 읽고 담당자가 바로 액션 아이템을 뽑을 수 있는가'를 마지막 체크로 본다.

 

3. 로그 설계 — 무엇을 수집하고, 왜 수집하는가

• 시청 지속 시간을 제대로 분석하려면 로그 항목 선택과 설계 목적이 명확해야 함.
• 수집하면 안 되는 것 / 수집해야 하는 것

항목	수집 여부	이유
주민등록번호, 상세 주소 등 민감 개인정보	✖️	개인정보보호법상 불필요한 민감정보 수집 금지, 법적/윤리적 리스크
익명화된 사용자 ID	☑️	시청 지속 시간 분석에는 이 정도로 충분
시청 패턴 관련 로그	☑️	이탈 원인 분석의 핵심 데이터
버퍼링 발생 횟수 등 기술 지표	☑️	기술적 이탈 원인 분석에 필요

• '분석 포인트'를 설정하는 이유
  → 로그를 그냥 쌓아두는 게 아니라, 이 로그를 왜/어떻게 쓸 것인지를 미리 정의해서
• 비즈니스 의사결정에 실질적으로 연결하기 위함.
  • ex. '버퍼링 발생 횟수' 로그 → 분석 포인트 : '기술적 문제로 인한 이탈률 측정'
  • 로그 자체는 부수적 효과(다른 데도 쓸 수 있음)가 있을 수 있지만, 설계 시점엔 주된 목적 하나를 명확히 잡아야 함

`실제 로그 설계 예시로 보는 완성도 계산`

// json

{
  "watch_start_time": "14:30:00",
  "watch_end_time": "14:45:30",
  "actual_watch_duration": 920,
  "total_content_duration": 1200
}

• 단순히 시작-종료 시간 차이가 아니라 실제 재생된 시간(actual_watch_duration)이 별도로 필요한 이유 :
  일시정지, 되감기, 빨리 감기까지 반영한 순수 시청 시간을 봐야 하기 때문
  • 완성도(completion rate) = actual_watch_duration / total_content_duration
    → 위 예시는 920/1200 ≈ 77%
  • 만족도 지표, 광고 분석용 항목, 클릭 행동 분석용 항목은 이 계산과는 별개 영역이라 여기 넣으면 안 됨
    → PM은 로그를 설계할 때 '이 항목이 어떤 지표 계산에 쓰이는가'를 먼저 정의하고,
    그 지표 계산에 불필요한 항목(특히 민감정보)은 처음부터 뺀다.

 

---

 

오늘의 인사이트

 

260715(수) 5시 경...

집주인이... 말없이 인터넷을 끊었다.

갑자기 젭이 튕기고 모든 장치가 작동을 멈췄다.

사이드 프로젝트로 작업하던 것도 도중에 작업 내용이 날아가고(ㅂㄷㅂㄷ)

서비스 제작기를 작성 중이었는데 해당 글도 통째로 날아갔다...ㅋㅋㅋ.....ㅋㅋ

 

처음엔 인터넷이 끊겼을 거라고는 생각을 못하고

랜선 접촉부가 잘 못 된 건 아닌지 or 와이파이 단말기의 문제인지 알아보려고

랜선을 뽑았다 꽂아도 보고

2미터가 넘는 랜선을 단말기로부터 이어서 데스크톱에 연결도 해봤는데...

도무지 뭐가 문제인지 모르겠어서 집주인에게 연락했더니

그제야 통신사를 바꾸려고 인터넷을 끊었다는 소식을 들었다.

(REAL OMG한 상황... 진심입니까 휴먼?!?!)

 

21세기에 인터넷 없는 일주일을 보내게 될 거라고는 전혀 생각지 못했다.

심지어 260719(일)에는 정보처리기사 실기 시험도 있는데...

문제는 핸드폰으로 인강을 들으려 해도

와이파이가 없는 상황 자체를 고려하지 못해서 8G 데이터 요금제를 사용하고 있었다는 점이다.

이게 왜 문제냐면 데이터 충전 쿠폰을 써도 딱 그만큼만 충전되기 때문에 합쳐봐야 16G다...!

 (BGM 틀어놓고 작업하는 습관을 들여버려서 이 적막함이 너무 불편하다)

 

아무튼 이 말을 왜 했냐면...

TIL을 미뤄서 작성한 이유가 바로 저것이기 때문이다.

그동안 어떻게 작업했냐면...

카페도 전전하고 아주 난리를 쳤다.

(집주인이 미안하다고 옆 건물 와이파이 비밀번호를 알려줬는데

와이파이가 1칸이라 간당간당하다... 심지어 비 오면 끊김)

열악한 환경...

 

그마저도 260721 16:00에 설치 기사가 온다는 절망적인 소식...

그래서 월요일은 공가 신청했다...

왜냐면 출석을!!! 할 수 없기 때문이다!!!!!!!!!!!!!!

공가 낸 김에 병원 투어나 할 생각이다... 후...

(그저 이 상황이 어처구니없고 화딱지남)

 

 

---

 

오늘의 KPT 회고

 

Keep	• 오답 선지까지 '왜 틀렸는가'로 분류해서 정리 → 실무에서 흔히 하는 실수 패턴 파악에 도움 • 로그 설계처럼 실제 JSON 예시가 있는 개념은 계산 과정까지 같이 정리 → 이해도 높아짐
Problem	• '실행 가능성'이라는 기준이 방안 선정/보고서 작성/로그 설계 세 곳에서 반복 등장하는데, 이번 정리에서는 각 파트별로 따로 설명해서 하나의 상위 기준으로 안 묶임 • SMART 원칙이 언급만 되고 각 항목(S/M/A/R/T)이 실제 방안 예시에 어떻게 매핑되는지는 다루지 않음
Try	• 다음 학습 때 '실행 가능성'을 방안-보고서-로그 세 파트 공통 상위 개념으로 한 번 더 통합 정리해보기 • 이전 프로젝트의 KPI 문장 하나를 SMART 5개 항목에 직접 매핑해서 실제로 빠진 항목이 있는지 점검