[내일배움캠프 TIL] 네카라쿠배 현업 살표보기 AND 과제 첫 발!

오늘은 서비스기획 숙련 과정의 마지막 챕터, "네카라쿠배 현업 살펴보기" 강의를 들었다. 앱스토어 리뷰 분석부터 퍼널·AARRR 분석, 킥오프·회고, 그리고 업무 공유까지 — 지금까지 배운 이론들이 실무에서 어떻게 쓰이는지를 실제 사례로 보여주는 챕터였다. 이론으로 배울 때는 "아 그렇구나" 하고 넘겼는데, 사례가 붙으니까 확 와닿았다. 특히 데이터 분석은 직접 해봐야 진짜 실력이 된다는 말이 계속 머릿속에 남는다.

1. 📱 앱스토어 리뷰 분석 — 현업에서는 이렇게 쓴다

강의에서는 버스 앱 리뷰 데이터를 예시로 들어서 분석 전 과정을 보여줬다. 누구나 앱스토어에 들어가면 볼 수 있는 리뷰들인데, 이걸 PM이 어떻게 정리하고 활용하는지가 핵심이었다.

① 리뷰 데이터 수집

직접 앱스토어나 플레이스토어에서 리뷰를 수집한다. 강의 예시는 2025년 3월 기준 157개 리뷰, 평균 별점 2.4점이었다. 별점 분포를 보면 1점이 75명으로 압도적으로 많았고, 5점은 30명이었다. 부정적인 리뷰에는 "버스 위치가 갑자기 사라진다", "도착 정보가 안 뜬다" 같은 강한 불만이 많았다.

💡 익명의 공간에서 나오는 리뷰는 과격한 표현이 많다. 서비스 담당자로서 개인적으로 상처받을 필요 없고, 필요한 인사이트만 추출하는 태도가 중요하다고 강조했다. 이 말이 왜인지 공감이 됐다.

② 리뷰 분류 기준 만들기

리뷰를 그냥 쌓아두면 의미가 없다. 패턴을 찾아서 카테고리로 묶어야 인사이트가 나온다.

분류	내용 예시	건수(예시)
실시간 정보 오류	시간 불일치, 버스 위치 갑자기 사라짐	76건
기능 제안/추가 요청	위젯 활성화 요청, 정류장·노선 추가	13건
버그/오류	앱 아이콘 사라짐, 빈 좌석 표시 오류	8건
긍정적 피드백	도착 예정 시간 편리함, 위젯 칭찬	29건
기타	분류 불가, 단순 감상	나머지

③ 인사이트 도출 → 실제 프로젝트로 연결

강의에서 보여준 실제 사례가 인상적이었다. 부정적 리뷰 중 실시간 정보 불일치 이슈가 가장 많았고, 이게 실제 개선 프로젝트로 이어졌다는 것이다. 위젯 기능에 대한 긍정적 반응도 발견해서, 위젯 사용 유저 비율을 추가로 분석하고 기능 고도화까지 이어갔다고 한다.

🔴 GPT로 리뷰 분류를 자동화할 수 있지만 최종 판단은 사람이 해야 한다는 점을 강조했다. GPT가 유저의 실제 불편함을 완전히 파악하지 못하는 경우가 있고(예: 리브랜딩 후 불만 등 맥락이 필요한 것들), GPT 결과와 직접 분석 결과를 비교해보는 경험 자체가 중요하다고 했다.

④ 서비스 지표 데이터도 함께 본다

리뷰 분석만으로는 부족하다. 실제 유저 행동 데이터(유저 수, 클릭 수 등)와 함께 봐야 진짜 그림이 나온다. 버스 앱 사례에서는 디바이스별(전체/안드로이드/iOS)로 나눠 분석했고, 몇 가지 예상치 못한 인사이트가 나왔다.

🟢 서비스 지표 분석 인사이트 정리

- 새로고침 클릭 수가 매우 높다 → 실시간 정보에 대한 불신이 행동으로 나타난 것 (노선 새로고침 평균 55회/인)
- 정류장 검색 > 버스 검색 → 여러 버스 동시 확인 목적이 더 많음
- 알람 기능(하차 알람 등) 사용률이 높음 → 해당 기능 고도화 프로젝트로 연결

단순히 "많이 클릭했다"가 아니라, 왜 그 행동이 나왔는지를 해석하는 게 PM의 역할이다.

2. 📊 퍼널 분석 + AARRR — 그로스 해킹의 시작

이번 강의에서는 데이터 분석을 통해 그로스 해킹을 접해보는 것이 목표였다. 그로스 해킹은 데이터를 기반으로 가설을 세우고 실험을 반복해서 제품을 개선하는 방법론이라고 한다. 이론으로만 알고 있었는데, 실제 사례를 보니 훨씬 구체적으로 이해됐다.

① 퍼널 분석 (Funnel Analysis)

사용자가 특정 목표(결제, 가입 등)에 도달하기까지의 여정을 단계별로 쪼개서 보는 방법이다. 어느 단계에서 얼마나 이탈하는지를 숫자로 보면, 어디를 개선해야 하는지가 바로 보인다.

강의에서 배달앱 퍼널 데이터를 예시로 보여줬는데, 생각보다 많이 이탈한다는 게 놀라웠다:

퍼널 단계	잔류 비율
가게 탐색	85%
가게 상세 페이지	73%
메뉴 상세 페이지	—
장바구니 담기	—
주문하기 화면	—
결제하기 → 주문 완료	29.6%

💡 실제 대형 배달앱 데이터인데 최종 결제까지 도달하는 비율이 약 30%밖에 안 된다. 처음엔 "왜 이렇게 적지?" 싶었는데, 생각해보면 탐색만 하고 나가는 사람도 많고, 비교 후 선택하는 사람도 있다. 퍼널의 어느 구간에서 가장 많이 빠져나가는지를 찾아서 그 구간을 개선하는 게 핵심이다.

퍼널 단계는 고정된 게 아니다. 서비스 특성에 따라 늘리거나 줄여서 쓰면 된다.

② AARRR 분석

서비스 전체 사용자 흐름을 5단계로 나눠서 각 단계의 성과를 측정하는 프레임워크다. 특정 단계의 숫자가 낮으면 그 단계에 문제가 있다는 신호다.

단계	의미	커머스 사례	콘텐츠 서비스 사례
Acquisition (유입)	어떻게 알게 됐는지	앱 설치, 회원가입, 외부 마케팅 진입	가입자 수 (434만 명)
Activation (활성화)	첫 경험이 긍정적인지	신규 가입자 첫 주문, 첫 주문 온보딩 쿠폰	가입 후 콘텐츠 열람 유저 (387만 명)
Retention (유지)	계속 돌아오는지	재구매 빈도, 할인 알림, 회원 등급제	다음 달 재열람 비율 (61.4%)
Revenue (수익)	실제 결제가 일어나는지	구매 빈도, 식재료 구매 매출	캐시 사용, 실제 결제 유저 (84.4만 명)
Referral (추천)	다른 사람에게 알리는지	친구 추천 코드 공유	14일 이탈 후 복귀 유저 (서비스별 재정의 가능)

💡 가장 인상적이었던 건 AARRR의 각 단계 "정의"가 서비스마다 다를 수 있다는 점이다. 콘텐츠 서비스에서 Referral을 "친구 추천"이 아니라 "14일 이탈 후 복귀 유저"로 정의한 사례처럼, 자기 서비스에 맞게 기준을 잡는 게 중요하다. 정답이 있는 게 아니라, 왜 그렇게 정의했는지를 설명할 수 있으면 된다.

3. 🚀 킥오프(Kick-off) — 시작을 제대로 열어야 끝이 좋다

킥오프는 프로젝트의 목표, 범위, 일정, 예산 등 핵심 사항을 이해관계자와 협업자들에게 공유하는 자리다. 단순한 "시작 선언"이 아니라, 참여자 모두가 같은 방향을 바라보게 만드는 과정이다.

① 실제 킥오프 사례 — LA 프로젝트

LA 한인 교민 대상 서비스 출시 킥오프 사례였다. 1차 타겟은 LA, 교민 수가 많아 유의미한 트래픽을 기대하고, 전 세계 오픈 전 전략적 예비 단계로 테스트한다는 목표가 명확했다. 출시 목표는 빠르면 5월, 늦어도 6월로 잡았고, 첫날에는 세부 설계보다 큰 방향만 공유했다.

② 킥오프 미흡 사례 — 해커톤 실패

10일간 11명이 함께한 해커톤에서 킥오프를 제대로 안 한 결과를 보여줬는데, 딱 봐도 우리 팀 프로젝트에서도 나올 수 있는 상황들이었다.

🔴 킥오프 없이 프로젝트를 시작했을 때 생기는 문제들

- 팀원 간 역할 오해, 일정 분배 어려움
- 디자이너와 개발자 간 요구사항 불일치
- 전체 플로우를 아무도 명확히 모르는 상황
- 데일리 스크럼은 했지만 "큰 그림" 공유가 없어서 각자 다른 방향으로 달리는 상황

결과: 핵심 기능만 구현, 완성도 저하, 팀원 간 소통 부족으로 마무리.

💡 PM이 킥오프에서 해야 할 일은 "목표를 전달하는 것"이 아니라 "모든 참여자가 같은 그림을 머릿속에 그리게 만드는 것"이다. 세부 설계는 나중에 해도 되지만, 방향과 목표는 처음부터 명확해야 한다.

4. 🔄 회고(Retrospective) — 끝이 아니라 다음 시작

회고는 팀이 작업 과정, 소통, 도전 과제 등을 돌아보고 개선 방향을 설계하는 과정이다. "수고했습니다"로 끝내는 게 아니라, 다음에 더 잘하기 위한 구체적인 액션을 뽑아내는 자리다.

① KPT 구조

강의에서 보여준 실제 팀 회고는 이 구조로 돌아가고 있었다:

구분	내용	예시
Keep	잘한 점, 계속 이어갈 것	인수인계 미팅 잘 됨, 코드 리뷰 습관 유지
Problem	문제점, 개선 필요 사항	스프린트 회고 시간 애매함, 유관 부서 일정 공유 부족
Try	시도해볼 개선 방안	QA 협의 구체화, 외부 부서 일정 미리 확정

② 회고 그라운드 룰

두 번째 사례에서는 회고 시작 전에 그라운드 룰을 먼저 잡는 방식을 보여줬다. "카메라 켜기, 특정인 비난 금지, 자책 금지, 경험을 솔직하게 작성" 같은 규칙들이었는데, 이 규칙이 있어야 사람들이 편하게 이야기할 수 있다는 게 이해됐다.

💡 회고는 방식에 정답이 없다. KPT도 있고, +/- 방식도 있고, 팀마다 다르다. 중요한 건 어떤 형식이든 액션 아이템이 나와야 한다는 것, 그리고 그 액션 아이템이 다음 프로젝트에서 실제로 지켜졌는지까지 추적해야 진짜 회고다.

5. 🤝 공유(Sharing) — 정보를 전달하는 것도 스킬이다

공유는 단순히 정보를 뿌리는 게 아니다. 필요한 정보를 필요한 사람에게 적시에 정확히 전달하는 것이다. PM은 팀 전체의 정보 흐름을 조율하는 역할을 한다는 말이 인상 깊었다.

① 회의록 작성과 공유

회의록은 반드시 작성 후 공유해야 하며, 기본적으로 일시, 장소, 참석자, 논의 아젠다, 결론, 액션 아이템이 들어가야 한다. 회의에 참석 못 한 사람도 읽으면 전체 맥락을 파악할 수 있어야 한다.

② 업무 결정사항 공유

강의에서 웹툰 서비스 런칭 사례를 보여줬는데, "영상 자동재생 ON, 사운드 OFF가 디폴트"라는 결정이 제대로 공유되지 않아서 무음/진동 상태에서도 소리가 나오는 문제가 생겼다고 한다. 작은 결정 하나가 사용자 불만(VOC)과 스토어 리뷰 문제로 이어진 실제 사례였다.

③ 개인 일정도 공유한다

장기 휴가 같은 개인 일정도 팀원과 유관 부서에 미리 공유해야 한다. 3주 리프레쉬 휴가를 사전에 공유하고 대리 담당자까지 지정한 사례가 예시로 나왔다. 내 부재가 팀 전체 업무의 병목이 될 수 있다는 관점이 새로웠다.

🟢 공유 잘 하는 법 핵심 정리

- 채널 구분: Slack(일상 소통) / 이메일(주요 의사결정) / Jira·Trello(일정·진행 관리) / 주간 회의(리스크 논의)
- 주기적 업데이트: 일일 스탠드업(오늘 할 일 공유) → 주간 리뷰(전체 진행 점검) → 월간 리뷰(방향 조정)
- 필요한 정보만 선택적으로: 기술 세부사항은 개발팀만, 개인 피드백은 1:1로 → 정보 과부하도 문제다

6. ✏️ 오늘 시작한 과제 — 페르소나 정의 + 데이터 조사

강의가 끝나고 드디어 과제를 시작했다. 오늘은 과제의 첫 단계인 페르소나 선정을 했다. 해당 사용자의 행동 패턴을 고민해야 하는가 아니면 처음 지정 되어있는 가격대에 맞는 사용자만 고민해야 하는것인가,
확정을 못 하였다.

🟣 현재 진행 상황

- 페르소나 선정 完
- 관련 데이터 조사 범위 설정 中
- 데이터 분류 시 여러 항목 선택시 순번에 직관성을 위해서 간단한 엑셀 함수 정리
--(=AGGREGATE(3,3,$A$N:AN))--
- 내일부터는 과제에 집중할 예정이다.💪

오늘 배운 것 한 줄 정리 🗒️

데이터는 스스로 말하지 않는다. PM이 올바른 질문을 던졌을 때 비로소 의미를 갖는다 — 리뷰 분류도, 퍼널 분석도, 지표 해석도 결국은 "왜?"를 끊임없이 물어보는 과정이다.