ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 21일차[서비스 기획 숙련]
    PM 부트캠프 2026. 4. 6. 20:48

    1. 팀 변경 : 집4조 -> 7렐루야

    팀이 바뀌었으나 빠르게 적응하고 공부에 임하자!

    열심히 하시는 팀원분들을 본받아 나도 열심히!

     

    2. 오늘의 달성 목표

    • 서비스 기획 숙련 강의 1일차
    • 독서: [내가 알고 있는 걸 당신도 알게 된다면_칼 필레버] ~59P 
    • TIL 작성

    3. 오늘 배운 내용 정리: PM이 데이터를 이해하는 방식의 시작

    오늘은 PM에게 왜 데이터가 중요한지, 그리고 데이터를 실제 프로덕트 문제 해결에 어떻게 활용하는지 전체 흐름을 학습했다.

    가장 먼저 배운 것은 데이터와 지표의 차이였다.
    데이터는 사용자 행동이나 시스템에서 발생한 사실 자체이고, 지표는 그 데이터 중에서 우리가 의사결정에 활용할 수 있도록 의미를 부여한 숫자라는 점이 인상적이었다.
    즉 PM은 단순히 숫자를 보는 사람이 아니라, 문제를 설명할 수 있는 지표를 정의하는 사람이라는 관점을 이해하게 되었다.


    데이터가 중요한 이유 = 감이 아니라 근거로 결정하기

    오늘 가장 크게 느낀 포인트는 데이터는 의사결정의 근거를 만든다는 점이었다.

    직관이나 경험만으로 문제를 해결하려 하면 추측에 머무르기 쉽지만, 데이터를 보면 언제, 어디서, 왜 문제가 발생하는지 훨씬 구체적으로 볼 수 있다.
    예를 들어 배달 앱에서 단순히 “배달이 느리다”가 아니라,
    저녁 6~9시에 평균 30분 이상 지연된다는 식으로 문제를 구조화할 수 있다.

    이렇게 보면 해결책도 훨씬 명확해진다.

    • 특정 시간대 라이더 추가 배치
    • 주문 몰림 시간 분산
    • 조리 예상 시간 개선
    • 사용자 안내 UX 보완

    결국 PM에게 데이터는 문제 정의의 정확도를 높이는 도구라는 걸 배웠다.


    로그 설계: 사용자 행동을 남기는 PM의 언어

    오늘 특히 PM 실무와 가장 가깝다고 느낀 부분은 로그 설계 기초였다.

    로그는 단순한 기록이 아니라,
    사용자가 서비스에서 어떤 행동을 했는지 남기는 프로덕트의 관측 장치다.

    예를 들어 결제 실패가 발생했을 때,

    • 결제 버튼 클릭
    • 카드 정보 입력 완료
    • 승인 API 요청
    • 승인 실패 코드

    이런 흐름이 로그로 남아 있어야 정확히 어디서 문제가 발생했는지 알 수 있다.

    PM 입장에서는
    “무엇을 개선할까?”보다 먼저
    “무엇을 측정할 수 있게 설계할까?”를 고민해야 한다는 점이 정말 중요하게 느껴졌다.


    데이터 분석 방법론: 퍼널과 AARRR로 문제를 구조화하기

    오늘 배운 분석 방법론 중 가장 실무적으로 와 닿은 건 퍼널 분석이었다.

    회원가입 퍼널 예시에서

    • 방문 1000명
    • 가입 페이지 진입 800명
    • 폼 작성 400명
    • 가입 완료 200명

    으로 갈수록 이탈이 커지는 걸 보면서,
    PM은 단순히 전환율 숫자만 보는 게 아니라
    어느 단계에서 사용자가 가장 많이 포기하는지 찾아내는 역할을 한다는 걸 다시 느꼈다.

    특히 오늘 학습 흐름인

    문제 정의 → 데이터 수집 → 분석 → 해석 → 적용

    이 순서는 앞으로 과제나 포트폴리오에서도 그대로 사용할 수 있을 것 같다.


    GA4: 사용자의 실제 행동을 읽는 방법

    구글 애널리틱스(GA4) 파트에서는
    웹/앱 사용자의 행동을 실제로 어떻게 보는지 이해했다.

    특히 아래 지표들이 중요했다.

    • 활성 사용자
    • 평균 참여 시간
    • 이벤트 수
    • 페이지 조회수
    • 전환율
    • 유입 채널

    이 지표들을 보면 단순 방문 수가 아니라
    사용자가 실제로 얼마나 적극적으로 행동했는지까지 볼 수 있다.

    예를 들어,

    홈에서는 오래 머무르는데 결제 페이지에서 이탈률이 높다

    이런 흐름을 확인하면 바로 UX 개선 과제로 연결된다.


    가장 PM스럽게 느껴졌던 실전 사례

    마지막으로 가장 흥미로웠던 부분은
    리디북스 AI 도서 추천 사례였다.

    여기서 핵심은 추천 모델 자체보다도,

    • 어떤 사용자 그룹에 먼저 노출할지
    • 어느 화면에서 보여줄지
    • KPI를 무엇으로 잡을지
    • 론칭 후 어떤 지표를 볼지

    데이터 기반으로 단계적으로 검증했다는 점이었다.

    이건 PM이 실제로 기능을 출시할 때 하는 사고 방식과 거의 동일했다.

    기능을 “좋아 보이니까” 넣는 것이 아니라,
    가장 효과가 날 유저군과 맥락을 먼저 찾고 실험적으로 검증하는 방식이 PM스럽다고 느껴졌다.

Designed by Tistory.