sunshine0901 님의 블로그

제로베이스 PM 스쿨 100일 학습인증 챌린지 후기

sunshine0901 — Sat, 7 Feb 2026 21:35:46 +0900

끝날것 같지 않았던 100일 챌린지가 드디어 끝이 났습니다. 솔직히 얘기하면 처음엔 쉽게 생각하고 호기롭게 시작 했지만, 바쁜 직장생활을 병행하면서 하는것이 생각보다 쉽지는 않았습니다.... 자세한 느낀점은 뒤로 하고 챌린지를 하며 혹은 과정을 진행하며 궁금 할 수 있는 질문들을 자문자답 하면서 함께 후기를 작성해 보도록 하겠습니다.

Q. 과정을 수강하면서 도움이 많이 된 요소는 무엇인가요?
A. 과제인 것 같습니다. 물론 강의 뒷편에서도 배운 내용을 기반으로 실습을 제공해 주지만 약간의 강제성(?)이 없다보니 하지 않고 넘기는 경우가 대부분 이였습니다. 하지만 과제는 강의 커리큘럼과 같이 주차별 과제 커리큘럼을 정해주기도 하고 실제로 과제를 진행하기 위해 자료조사를 하다보면 새로 알게 되는 사실, 흥미로운 주제로 한 글들이 굉장히 많아 과제 외적으로 얻어가는 부분도 많았습니다.(특히 아티클 스터디)

Q. 챌린지 이후 본인 스스로 가장 크게 변화했다고 느껴지는 부분이 있나요?
A. 공부하는 습관이 길러졌습니다. 챌린지 이전에는 공부는 시간내서 제대로 해야 한다고만 생각하고 미루는 경우가 다반사 였는데 챌린지는 하루마다 공부한 내용을 정리해야 하다보니 틈틈히 짬나는 시간에라도 조금씩 공부를 하는 습관이 생겼습니다. 그리고 더욱 좋았던 것은 제로베이스 측에서도 짜주는 주차별 학습 커리큘럼이 존재하지만 온라인 강좌 특성상 동영상 별로 시간이 다 달랐기 때문에 강의량에서 오는 부담감이 매주 달랐습니다. 그래서 부담을 나누기 위해 나만의 커리큘럼을 짜서 공부하게 됐는데 이 부분이 또 의외로 계획을 짜고 달성하는 부분에 있어서 많은 도움이 되었습니다.

Q. 제로베이스를 10글자 이내로 표현해 본다면 어떻게 표현하고 싶고 그 이유는 무엇인가요?
A. "만만하게 보지마라" 입니다. 초반에도 언급했지만 솔직히 이전에도 부트캠프 경력이 있고 이미 회사생활도 해봤기 때문에 어렵지 않을거라고 생각 했지만 막상 해보니 쉽지 않았습니다. 특히 일과 병행해서 하려니 체력적인 부분에서 많이 힘들었고 또 PM 스쿨의 특성상 글을 잘 쓰고 읽고 파악해야 했는데 그동안 많이 해보지 않은 작업이라 쉽지 않았습니다. 만약 지금 제로베이스를 고민하는 사람이 있다면 만만하게 보지마라 라고 단호하게 조언하고 싶고 동시에 마음 굳게 먹고 도전해 보라고 얘기하고 싶습니다.

Q. 사전 지식이 있는 상태에서 결심을 하게 된 건가요?
A. 많진 않았지만 IT 직종에서 일을 한 경력이 있다보니 PM이라는 직군과 함께 일한 경험이 많습니다. 경험에서 오는 지식들을 조금 가지고 있었습니다.

Q. 독학, 국비지원을 고려하지 않았는지, 제로베이스를 선택한 이유가 무엇인가요?
A. 사실 처음에는 국비지원을 고려 했었습니다. 그러나 국비지원 과정은 일과 병행 할 수 없는 과정이 대부분이였고 그동안 일을 오랫동안 해오다보니 선뜻 쉬면서 올인을 할 수는 없겠다 생각을 했고 결국 직장과 병행을 할 수 있는 제로베이스를 선택하게 되었습니다.

이렇게 100일간의 학습인증 챌린지가 마무리 되었습니다. 갑작스레 일이 바쁘거나 직장외에도 예기치 못한 일들이 많아 벅차고 힘들때도 많았지만 뚜렷한 목표를 설정해두니 포기 또한 쉽게 할 수 없었습니다. 포기하지 않고 계속하다보니 요령이 생기고 부담이 줄기 시작했고 그러면서 묵묵히 해나가다보니 결국 목표에 도달 할 수 있었습니다. 아직 과정 수료까지 남은 과정이 많지만 그래도 하나의 큰 목표를 달성해 괜히 뿌듯합니다. 마지막으로 꼭 제로베이스 같은 교육과정이 아니더라도 새로운 일을 도전하고 싶고 성장하고 싶은 사람들에게 일단 시작해보라고 말을 전달하고 싶습니다.

제로베이스 주소 : https://zero-base.co.kr/

[제로베이스 PM 파트타임 스쿨] 16주차 - 대기업 정책서와 프로세스, 서비스 기획시 갖춰야 할 마인드 (챌린지 100일차)

sunshine0901 — Tue, 3 Feb 2026 22:53:16 +0900

정책서 작성하기

가장 처음에는 정책이 나오게 된 근거를 AS-IS, TO-BE 형태로 문서에 정리 합니다.
정책은 상세 화면 설계서를 만들기 위해서 먼저 꼭 작성 되어야 합니다.

커머스 서비스 정책서 기반 정책서 예시

회원 : 회원 정의, 유형, 등급 등
서비스 : 서비스 정의, 권한 회원 등급, 성인 인증 등
주문/결제 : 배송지 정책, 결제(카드결제, 간편결제, 페이결제 등등)
포인트 : 발급 대상, 유효기간, 지급 방식, 지급 기준 등
쿠폰 : 종류, 지급 형태, 발급, 사용 등
통합 검색 : ~~엔진 사용, 엔진 사용 시 주의사항
프로모션 : 최소 얼마 이상의 회원들을 대상으로 한다—
알림톡 : 회원 가입, 주문, 주문 취소, 회원정보 수정 시 발송
CS 정책 : 정책 변경이 일어났을 때 고객에게 노티
이메일 : 어떨 때 발송을 해야하는지, 알림톡이 발송 되지 않았을 때 보조수단

보통은 다음과 같이 엑셀 같은 테이블 형식으로 초안을 작성하고 이후 워드를 활용하여 서비스 정책서를 정식으로 작성합니다.

회원가입 프로세스로 보는 정책

서비스 프로세스의 전반적인 흐름을 기획하는 내용보단 프로세스 수립 시 따라와야 하는 정책에 대한 내용에 집중하여 설명 하였습니다.

회원가입 프로세스

회원 가입 → 정보 입력 → 회원 가입 완료

* 만약 회원 탈퇴 시 다시 회원가입 과정부터 시작

회원가입 주요 정책

회원탈퇴 후 다시 가입을 위해선 익일 7시 이후 재가입이 가능하도록 하였습니다.
회원정보는 아이디, 비밀번호, 휴대폰 인증(본인인증) 정보를 꼭 포함해서 입력한다.

궁극적으로 전달하고자 하는 것은 서비스의 메인 흐름, 그에 따른 와이어프레임과 화면 정의서를 작성하기 전에 꼭 정책을 수립하고 프로세스를 작성 한 후에 와이어프레임, 화면 정의서 등이 나와야 한다는 점 입니다.

서비스 기획을 할 때 갖춰야 할 마인드

처음 서비스 기획을 배울 때 흔히 다음과 같은 실수들을 합니다.

비즈니스, 기본 파이프라인 분석 없이 앱 UI를 먼저 분석 하기
비즈니스 방향과 무관한 제안하기
그렇게 기획 할 수 밖에 없었던 이면의 의사결정 과정을 고민하지 않고, 무조건 ‘불편하니 개선해야 해’ 라고 생각하는 것
뒷단의 데이터 흐름은 생각하지 않고, 보이는 화면만 생각하는 것

결론적으론 서비스의 비즈니스 모델과 기본 파이프 라인을 이해 한 뒤에 특화된 기능을 기획해야 합니다.

비즈니스 모델 : 비즈니스의 핵심이 무엇인지 고민해야 합니다. 예를들어 비즈니스의 핵심이 상품 카테고리 분류라면 어떤 카테고리가 있고 어떻게 활용되고 있는 지 연결 할 수 있어야 합니다.
기본 파이프라인 : 계약-입점-상품진열-고객유입-탐색-장바구니-결제-배송 과 같이 서비스의 기본 파이프라인을 이해해야 합니다. 파이프라인의 이해는 고객이 어떤 절차로 플랫폼을 이용하는 지 맥락을 파악 할 수 있기 때문에 ‘기획’ 이라는 것을 할 수 있습니다.
특화된 기능 : 기본 파이프라인을 이해하면 그 안에서 어떤 데이터를 활용 할 수 있을 지와 같이 창의적인 기능을 고안 할 수 있습니다. 나아가 기능 추가로 인해 발행하는 영향도를 파악 할 수 있습니다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 16주차 - 에어비앤비 서비스 역기획 (챌린지 99일차)

sunshine0901 — Mon, 2 Feb 2026 23:26:16 +0900

에어비앤비 란?

전세계 사람들이 이용하는 C2C 기반의 숙박 서비스 입니다. 190개의 국가에 호텔이 아니라 다양한 형태의 개인이 운영하는 숙박 시설을 예약하고 모바일에서만 27개의 언어를 지원 합니다.

비즈니스 구조

상품 공급자로서 주거 공간 소유자와 현지 체험 상품 제공자가 있습니다. 이주거 공간 소유자가 좀 더 수수료 면에서 유리하며 핵심 가치 공급자이기 때문 인걸로 추측 됩니다. 주거 공간 소유자와 보험사가 보험 계약이 되어있는 경우도 있습니다.

비즈니스 모델 캔버스

C2C 서비스 임이 특징이며 핵심 파트너는 상품 공급자인 호스트 입니다.
핵심 활동은 사용자의 트렌젝션을 제거하는 것이며 에어비앤비의 주요 참가자라고 할 수 있는 호스트의 인게이지를 높이는 것 입니다.
고객에게 핵심 가치를 제공 할 수 있는 핵심 자원은 네트워크 효과와 리스팅 입니다.

게스트 숙소 예약 Flow Chart

IA(정보구조도) 와 전체적인 Flow Chart도 함께 보여주었지만 크게 강조를 하진 않습니다. 게스트가 숙소 예약을 하기까지 Flow Chart와 상세 화면을 보여주며 설명하며 이를 강조했습니다.

검색 → 지역 선택 → 날짜 선택(패스 가능) → 인원 선택 → 숙소 목록 → 숙소 상세 → 예약 상세 → 예약 요청 → 결제 → 채팅

에어비앤비 서비스의 주요 특징

에어비앤비의 주요 화면들과 메인 서비스 플로우 화면을 보면서 분석한 에어비앤비에서 눈여겨 봐야 할 부분들입니다.

앱과 웹 모두 지원하며 회원가입을 하지 않아도 숙소를 볼 수 있습니다.
검색에서 날짜 단위로 숙소나 체험 찾기를 할 수 있는데, 월 단위 등의 장기 투숙 고객을 위한 선택지를 주는 것이 눈에 띄었습니다. 아무래도 일반 숙박업과는 다르게 일반적인 공간을 빌려주기 때문인 것 같고 또한 장기 투숙으로 하여금 요금을 할인을 해주는 것을 보아 제품 서비스 차원에서 장기 투숙객들을 선호하는 특징이 있습니다.
지도 기반으로 가격과 위치를 보여주고 숙소를 선택을 하면 숙소 이미지를 보여줍니다. 숙소를 선택하면 숙소 메인 이미지와 어트랙션 문구도 같이 보여줍니다.
크기가 예상가기 어렵기 때문에 최대 인원수와 침대 수 같은 용적율에 대한 정보를 제공합니다.
호스트가 직접 올린 설명글이나 다양한 부대시설을 그래픽으로 보여 주고 후기 또한 제공 합니다.
호스트에게 결제와 관련 서비스를 문의 할 때는 모두 채팅을 이용해서 합니다. 에어비앤비 숙소는 대부분 프론트가 없다보니 채팅이 프론트 역할을 대신 합니다.
프로필에서 호스트 모드로 전환 할 수 도 있습니다. 판매자용 서비스 같은 경우는 하나의 앱으로 만들어 관리하기 쉽지 않은데 에어비앤비는 C2C 서비스 이다 보니 가능한 일인 것 같습니다.
호스트모드에선 본인이 직접 휴면 모드를 설정하거나 4회 연속 예약 요청에 답변을 하지 않으면 자동으로 휴면 상태로 돌입합니다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 학습일지 - 콴다로 알아보는 실험을 활용한 기획 및 케이스 스터디, 기획자의 업과 본질, 모든 시장에서 통하는 서비스 기획법, 여행 서비스 기획서 템플릿 및 여행 서비스 용어

sunshine0901 — Sun, 1 Feb 2026 23:28:22 +0900

실험 설계 항목

실험 대상 : 실험을 진행할 타겟 고객을 뜻하며 테스트 할 가설에 따라 일반적으로 플랫폼 별 앱 최소 버전 유저의 인구통계학 정보 등이 기준이 됩니다.
실험 기간 : 말 그대로 실험을 진행하는 기간입니다. 정확한 표현을 위해 실험 시작, 종료 날짜를 명확하게 표시해주는 것이 중요하고 진행 상황이나 외부 요인에 따라 실험 기간은 조절 될 수도 있습니다.
조작 변인 : 가설을 검증하기 위해 실험군과 대조군 간 변화를 주는 요소입니다. 조작 변인은 여러개가 될 수 있지만 조작 변인이 늘어날 수록 실험군의 개수도 늘어나기 때문에 주의 해야 합니다. 조작 변인 설정에 따라 실험에 투입되는 리소스가 결정 됩니다.
인원 : 몇 명의 인원에게 실험 할 지 이며 실험군과 대조군에 동일한 인원을 배정해야 합니다. 전체 서비스 대상 유저에게 실험을 할 수 도 있지만 많은 고객에게 서로 다른 경험을 주는 것에 대한 위험도도 있기 때문에 적절한 규모를 결정하여 실험하는 것이 바람직합니다.
성공지표 : 실험의 목표가 되는 지표이자 실험의 성공 실패를 판단하는 지표 입니다. 앞서 이야기 했던 대로 실험의 성공 실패를 결정짓는 기준이기 때문에 명확한 지표에 대한 정의와 함께 목표 숫자까지 설정하는 것이 중요합니다.
가드레일 지표 : 실험으로 인해 영향을 받아 안좋아지면 안되는 지표입니다. 가드레일 지표가 설정해놓은 기준 이상으로 영향을 받는다면 실험을 중단해야 하는 상황도 발생하기 떄문에 가드레일 지표가 있다면 꼭 설정하고 모니터링을 하는 것이 중요합니다.
보조 지표 : 실험이 어떤 영향을 주는 참고성 지표입니다. 어떤 실험을 할 때 성공 지표를 올리고자 설계한 것이 성공 지표가 올라감으로서 연관이 있는 다른 지표에도 영향을 줄 수 있기 때문에 함께 모니터링하면서 실험을 진행한다면 더 많은 Insight를 얻을 수도 있습니다.

실험 설계 시 유의사항

실험 대상을 설정 할 땐 실험을 하려는 목적과 실험의 대상이 일치하는지 확인해야 합니다. 예를들어 신규 유저의 활성도 목적의 실험을 진행하는데 가입 후 30일 정도 경과된 유저의 경우는 신규 유저라고 보기 어렵습니다. 이럴 때엔 가입 후 7일이 되기 전 유저를 신규 유저로 정의하고 이처럼 실험의 대상을 확실히 하는 것이 중요합니다.
실험 기간은 서비스의 특성과 통계적 유의성이 확보될 수 있는지를 고려하여 너무 짧지도 너무 길지도 않게 설정하는 것이 좋습니다. 예를들면 SNS의 경우 매일 접속하고 세탁 서비스의 경우 1주일에 한 번 정도 사용하는것이 일반적이기 때문에 각각 두 서비스의 실험 기간은 다르게 설정 되어야 합니다. 또한 통계적 유의성이 확보되지 않았다면 이후 실험 기간을 조정하는 것이 좋습니다.
조작 변인을 설계할 때 실험을 진행하려는 가설이 조작 변인을 통해 검증될 수 있는지 확인이 필요하고 또한 조작 변인은 두 개 이상이 되는 순간 어떤 요인으로 지표 차이가 발생되었는지 모르기 때문에 조작 변인은 꼭 하나만 설계 해야 합니다.
성공 지표를 고를 때는 어떤 것의 결과가 되는 지표가 아니라 그 지표를 구성하고 우리가 변화를 만들 수 있는 지표를 고르는 것이 좋습니다.

실험 진행 시 커뮤니케이션 하게 되는 유관 부서

Product Team : 실험을 위해 내가 담당하는 기능 외에 다른 PM이 담당하는 기능에도 영향이 가는 상황이라면 해당 기능 PM과 커뮤니케이션을 진행 후 실험에 대해 우려사항이 없는지 합의를 진행해야 하고 실험을 진행 할 땐 Product Team 전체에게 미리 알리고 시작하는 것이 좋습니다.
Product Operation Team : 모든 회사에 있는 팀은 아니기 때문에 참고 정도로만 알아두는 것이 좋습니다. 마찬가지로 Operation Team에서 모니터링하고 있는 지표에 변화가 가거나 유저에게 관련 문의 사항이 올 수 있으므로 미리 Operation Team과 커뮤니케이션을 진행하는 것이 좋습니다.
Back Office Part(Legal & Finance) : 실험이 유저의 개인 정보를 다루는 등 법률적 검토가 필요하다면 Legal Team에게 미리 내용을 검토 받는 것이 좋고 매출 관련 실험을 하는 경우에는 Finance Team에게 내용을 미리 공유하는 것이 바람직합니다.

실험 개발 및 진행 시 주의사항

가설과 제품의 합 : 개발을 하다보면 리소스 문제나 타 팀과의 협업에서 문제가 발생하는 등 현실적인 이슈로 제품 Spec이 변경되는 일이 발생하기도 하기 때문에 실험하고자 하는 가설이 제품에 잘 반영이 되어 있는지 지속적으로 확인하며 합을 따져야 합니다.
꼼꼼한 QA : 실험 관련 개발을 배포하기 전에 프로덕트 QA와 데이터 로깅 QA 가 진행이 되어야 합니다. 따라서 PM은 상세 Spec 대로 제품에 로직이 잘 반영 되어 있는지, 실험에 있어서 원하는 데이터가 잘 쌓이는지 지속적으로 확인이 필요합니다.
실험 배포 후 지표 모니터링 : 실험이 끝났을 때 어디선가 문제를 발견한다면 그동안 실험에 투입된 리소스를 모두 낭비하게 되는 것이기 때문에 실험 진행 시 주요 지표 모니터링이 계속 이루어져야 하고 만약 이슈가 발생 했다면 빠르게 원인을 파악하고 대처 후 기간을 다시 설정 합니다.

실험 결과 분석

결과 분석시 우선적으로 중요하게 봐야 할 부분은 성공 이나 가드레일 같은 주요 지표들을 체크하고 통계적 유의성을 검증하는 것 입니다. 이때 통계적 유의성이 무엇을 이야기 하는지 그 개념을 알아야 합니다.

통계적 유의성이란 모집단에 대한 가설이 가지는 통계적 의미를 말합니다. 좀 더 자세히 이야기 한다면 어떤 실험 결과 자료를 보았을 때 확률적으로 봐서 단순한 우연이라고 생각되지 않을 정도로 의미가 있다라는 뜻을 가졌기 때문에 통계적 유의성을 확인하는 것은 실험 결과가 우연에 의한 것인지 아닌지를 판별해 내는 것 입니다.

통계적 유의성을 검정하기 위해선 p-value 값을 사용합니다. p value는 유의 확률이라는 뜻으로 귀무가설이 참이라는 가정하에 현재 관찰된 결과나 그보다 더 극단적인 결과가 우연히 나타날 확률을 나타내는 값입니다. 정의에 집중하기보단 실무에서 어떻게 사용하는 지가 중요하고 p value 계산기 라고 검색하고 값을 대입해서 사용 할 수 있습니다. 보통 5%를 기준으로 많이 보며 5% 보다 작으면 통계적으로 유의하다고 판단합니다.

후속 액션

실험 결과 분석 이후 취해야 할 행동에 대해 알아보겠습니다.

User Reasearch : 실험을 통해 데이터는 나왔지만 데이터 이면에 숨겨진 유저들의 생각과 의도까지 파악이 불분명 할 땐 유저 인터뷰를 진행해 유저들의 생각과 의도롤 파악해보는 것이 좋습니다.
후속 실험 설계 : 실험에서 목표로 했던 지표를 계속 올려야 하는 상황이라면 실험의 성공/실패 여부와 관계 없이 다음 실험을 또 진행 할 수 있습니다. 실험 성공 이후 후속 실험을 설계 한다면 우선순위가 낮았던 다른 가설을 채택하여 할 수 있고 실험 실패 이후 후속 실험을 설계 한다면 실패 원인을 분석 후 다시 실험을 설계 할 수 있습니다.
전면 배포 및 대시보드 세팅 : 실험이 성공했다면 실험군에 적용했던 조작변인을 전체 서비스에 적용하는 전면 배포 과정을 거치고 실험 진행을 위해 사용했던 모니터링 대시보드를 health Check 및 지표 확인용 대시보드로 바꿔줍니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 인앱광고 시장 소개

인앱 광고란

인앱 광고란 앱 개발자가 자체 앱에 과고를 게재하여 수익을 창출하는 수단 입니다. 앱 사용 유저가 구매를 하지 않고 무료로 앱을 사용하더라도 앱 개발자가 수익을 올릴 수 있는 거의 유일한 수단이기 때문에 거의 대부분의 앱 퍼블리셔들이 이를 채택하여 사용하고 있습니다.

인앱 광고 구조

인앱광고 시장은 광고주, 광고 네트워크, 앱 퍼블리셔 세 그룹의 이해관계자와 연결 되어 있고 광고주가 광고 네트워크에게 입찰을 하고 광고를 집행하면 광고 네트워크는 앱 퍼블리셔에게 광고를 전송해 주는 역할을 합니다. 여기서 광고주가 광고 네트워크에게 광고비를 지불하면 광고 네트워크는 수수료를 제외하고 앱 퍼블리셔에게 광고비를 정산해주는 구조 입니다.

인앱 광고 지표

광고 매출은 광고 노출량 x 노출 당 광고 단가의 값 입니다. 따라서 광고 매출을 높이기 위해선 광고 노출량과 노출 당 광고 단가의 값을 올려야 합니다. 광고 노출량 같은 경우는 광고 지면에 노출 빈도를 높이거나 새로운 광고 지면을 개발하여 올릴 수 있고 노출당 광고 단가의 경우 광고 단가가 높은 광고 형식을 추가하거나 새로운 광고 네트워크를 추가하여 올릴 수 있습니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 배경

본격적인 케이스 설계에 앞서 실험을 왜 하게 되었고 어떤 실험을 할 것인지 이야기 해보겠습니다.

콴다 앱 내 트래픽을 통한 수익 창출을 위해 인앱광고를 삽입 했을 때 어떤 효과를
최적화 실험을 통해 인앱광고를 통해 매출을 얼마나 낼 수 있는지와 이로 인한 이탈 유저는 없는지 확인해 보고자 합니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 가설 수립

가설 수립 당시 인앱광고 BM으로 수익을 내는 타 회사 조사, 광고 네트워크 및 미디에션 회사를 만나 정보 수집, 앱 내 주요 지면별 트래픽 조사, 이전 실험으로부터 얻은 인사이트 활용 등 이와 같은 방법으로 가설 수립을 위한 정보를 수집하고 가설을 수립 하였습니다. 다음은 우선순위를 적용한 실험 방법과 가설 입니다.

1차 실험

제일 중요한 가드레일 지표인 이탈 확인과 메인 기능에서의 지면 개발에 집중 하였습니다.
유저들에게 광고를 노출했을 때의 잔존율은 광고 비노출 유저의 잔존율과 차이가 나지 않을 것이다
Main 기능인 검색 기능에서 기능 사용 전과 기능 사용 후에 노출되는 광고 지면에는 유의미한 ARPU 차이가 있을 것이다. (ARPU란 앱의 활동 사용자 1인당 평균 결제 금액을 뜻합니다.)

후속 실험

노출 빈도를 상향시켜 매출과 이탈의 trade-off를 확인합니다.
새로운 지면 개발하고 기존 실험군과 대조해서 확인해봅니다.
광고 네트워크 추가하여 어떤 효과를 불러오는지 확인해봅니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 실험 설계

실험 대상 : 광고가 유저에게 부정적인 경험을 줄 수 있는 요소이기 때문에 전체 유저가 아닌 일부 유저를 대상으로 진행하고 또한 신규 유저도 제외하여 기존 유저를 대상으로 진행 했습니다. 후속 실험 시에는 이전 실험에 영향을 받지 않도록 이전에 광고를 보지 않았던 유저를 대상으로 진행하였습니다.
실험 기간 : 빠른 실험과 분석을 위해 실험기간을 최소한으로 설정하고 전체 실험 기간동안 유저에게 광고를 노출하는 것이 아닌 그룹 내 유저가 모두 동일한 기간동안 광고를 보게끔 실험을 설계 했습니다.
성공 지표/가드레일 지표가드레일 지표 : 잔존율을 단기/중기/장기로 나누어 세부적으로 비교
성공 지표 : AD ARPU
대조군 설정 초기 : 실험 대상이 아닌 유저 중 랜덤으로 샘플링을 진행하고 샘플링된 대조군이 실험군과 활동성 차이가 없는지 검증하는 과정을 거쳤습니다.이슈 발생 이후 : 대조군을 실험군 중 하나로 편입하고 대조군으로 설정된 실험군은 광고 노출을 아예 하지 않도록 설정 하였고 이후 활동성 차이 이슈가 없어졌습니다.
이슈 발생 : 원인 불명, 어떻게 랜덤 샘플링을 진행해도 대조군에서 활동성 지표가 더 높은 locale 이 생겨났습니다. 아무래도 실험군이 아닌 유저가 더 많다보니 이런 이슈가 발생했을 것으로 추정됩니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 개발 및 QA

개발자에게 계획을 미리 공유하여 확장성을 고려하여 실험 환경을 세팅하고, Admin Page(관리자 페이지)를 만들어 후속 실험 시 추가 개발이 필요하지 않도록 만들었습니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 실험 진행 시 유의 사항

대시보드 모니터링하기

실험 진행 시 실수로 실험군 1개에서 조건이 누락한 경우가 발생한 적이 있었고 대시보드 모니터링을 하면서 실험 시작 3일 후 발견하였습니다. 결국 해당 실험은 바로 종료하고 실험 세팅을 다시하고 실험을 진행 했습니다. 만약 실험이 끝난 후 이를 발견했다면 실험이 무의미 해질 수도 있었습니다.

모의 실험 진행하기

위와 같은 불상사를 막기 위해 일부 유저들을 대상으로 모의 실험을 진행하기도 했습니다. 우자 작은 유저들에게 3일의 실험 기간을 세팅하고 대시보드에 원하는 데이커가 잘 쌓이는지 각 실험군에게 설계한대로 광고가 노출되고 있는지를 미리 확인 후 실제 실험을 진행했습니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 결과 분석하기

성공 지표인 ARPU와 가드레일 지표인 Retention을 비교하고 지표간 차이에 대한 유의성을 검증 합니다. 이후 유의한 차이가 있는 그룹 사이에 어떤 요소로 해당 차이가 발생했는지 확인하여 실험 결과를 도출합니다.

현업자들이 생각하는 기획자란

서비스 기획자는 어떤 일을 하는 사람인지 PM/PO와 기획자는 어떻게 다른지 심지어 기획자는 영어로 뭐라고 하는지 실제 현업에서 현재 기획자, PM으로 일하는 사람들이 그 본질을 궁금해 합니다.

현업 기획자들이 이런 고민을 가지는 이유는?

기획은 물론 일정관리, 스크립트 작성, 미팅 등등 해야 할 일들이 너무 많습니다.
해야 할 일들이 너무 많기 때문에 배워야 할 것도 너무 많습니다.
훌륭한 기획자가 될 수 있는 알려진 성장 트랙이 없습니다.
개발자 출신의 제품 리더들은 많지만 반대는 없습니다. 심지어 개발 출신 제품 리더를 선호하는 회사들도 많습니다.
회사마다, 회사 내 부사마다도 일하는 방식이 너무나도 다릅니다.
서비스 기획자 뿐만 아니라 제품 관리자인 PM, 제품 소유자인 PO도 상황은 크게 다르지 않습니다.

실제 현업 기획자들이 추가로 담당하는 역할들

SM(Scrum Master : 스크럼 마스터) : 애자일에 맞는 방식으로 팀이 운영되고 제품 개발이 이루어지도록하는 책임자 입니다.
PM(Project Manager : 프로젝트 관리자) : 정해진 기간 내에 목표를 달성하기 위해 프로젝트의 예산, 자원, 일정을 관리하고 계획을 수립하며 진행하는 책임자 입니다.
DM(Delivery Manager : 제품 실행 관리자) : PM(제품 관리자) 체계의 미션팀에서 제품 조직의 업무가 원활히 진행되도록 돕는 일종의 Project Manger 역할 입니다.
Product Designer(제품 디자이너) : 제품의 시각적/조작적 측면을 설계하고 디자인하는 담당자로서 제품의 사용자 경험 전반을 기획 의도에 맞게 구현하는 역할 입니다.
UX Researcher : 제품 조직과 긴밀히 협업하여 다양한 시장에서의 사용자 요구사항, UX, UI 개선사항을 조사하고 도출하는 역할 입니다.
Data Analyst/Data Scientist : 서비스 전체에서 수집된 대량의 데이터를 처리, 분석하여 통찰력 있는 정보를 추출/가공하여 제품팀에 전달을 하는 역할 입니다.
Customer Service Manager : 현재 제공중인 서비스의 전반적인 품질과 고객 만족도를 지속적으로 점검하고 개선 조치를 취하는 책임자 입니다.

이러한 직군을 분업하는 회사는 많지 않습니다(대기업도 마찬가지) 대부분 PM 이나 기획자가 모두 담당해서 일을 하곤 합니다.

따라서 현업 기획자들이 많이 던지는 질문들

왜 이 많은 일을 해야만 하는가?
과연 어디까지가 내 일인가?
기획자는 과연 전문성을 가질 수 있는가?

질문의 대한 해답을 찾기 위해선 Specialist(전문가) 와 Manager(관리자) 의 개념을 먼저 이야기 하는 것이 좋을 것 같습니다. 전문가의 경우에는 어떠한 한 가지 일에 있어서 전문 지식을 바탕으로 일을 해내는 사람이고 관리자는 전반적인 일에 있어서 모든 과정을 책임 지는 사람 입니다. 따라서 관리자라고 하기 보단 책임자라고 이야기 하는 사람들이 많고 사실 기획자는 전문가보다는 관리자(책임자)이기 때문에 이러한 이유 하나만으로 많은 질문들의 해답이 될 수 있다고 생각합니다.

서비스 기획자(PM/PO)의 정의와 업무

서비스 기획자란

서비스 기획자란 담당하는 제품의 성공을 책임지고 이를 위해 필요한 모든 일을 하는 사람 입니다.

서비스 기획자의 업무

제품 상위기획과 전략 수립
제품 상세기획/제품설계
제품 개발관리 및 출시
서비스 운영/데이터 분석과 지속적인 개선

서비스 기획자 업의 본질

서비스 기획자가 되기 위해선 혹은 서비스 기획자로 일을 하기 위해선 고객이나 시장의 이해 제품을 만들기 위해 필요한 개발 기술, 데이터, 디자인에 대한 지식, 여러 이해 관계자와의 커뮤니케이션 스킬 등등등 정말 갖춰야 할 역량과 Skill Set이 많지만 결국 가장 큰 틀로 보았을 때 서비스 기획자의 업의 본질은

문제를 정의하고 솔루션을 찾은 후에 팀과 함께 실행하며 제품을 통한 문제 해결을 하는 것 입니다.

서비스 기획자가 가져야 할 핵심 역량

고객에 대한 이해
IT 기술에 대한 이해
협업 능력과 프로세스에 대한 이해

PM/PO 관련된 서적에서도 고객에 대한 이해는 많이 강조를 합니다 따라서 고객에 대한 이해에 대해 가장 먼저 살펴 보도록 하겠습니다.

고객에 대한 이해란

고객에 대한 이해는 결국 사람에 대한 이해 입니다. 사람들이 무엇을 원하는지 어떤 경험을 선호하는지, 어떤 행동과 생각을 하는지 모두 파악해야 하고 이러한 사람에 대한 이해는 제품 개발의 모든 과정에 영향을 미칩니다. 어떤 역량을 가져야 하는지 좀 더 구체적으로 알아보도록 하겠습니다.

1. 고객들이 진짜 원하는 것은 무엇인가? (문제 정의)

고객들은 본인의 문제를 스스로 얘기하지 않을 뿐더러 고객들 본인 조차도 문제를 인식하지 못하는 경우가 많습니다. 기획자는 이러한 문제의 본질을 찾아 파고 들어야 합니다 왜 중요한지 예시를 보도록 하겠습니다.

당근의 경우에는 활성화된 중고거래 시장에서 불확실한 택배 거래 때문에 중고거래를 꺼려 하는 사람들이 많다 라는 문제점을 파고들어 성공 하였고

알라미라는 앱은 알람앱은 어떤 휴대폰에도 있지만 본인의 의지로 한 번에 일어나기 힘들어하는 사람들의 니즈를 잘 파고 들어 성공한 케이스 입니다.

이처럼 문제의 본질을 파악하고 정의하기만 해도 기회를 발견 할 수 있습니다.

2. 고객들은 어떤 형태로 가치를 제공받고 싶어하는가? (솔루션 찾기)

앞서 문제의 본질을 파악하고 정의 하는 것도 중요하지만 문제를 어떻게 해결해주어야 하는지 솔루션을 찾는 것도 중요합니다 이 또한 예시를 들어보도록 하겠습니다.

발뮤다 선풍기는 인공적인 바람보단 자연의 바람을 선호하는 사람들의 니즈를 해결하기 위해 두 개의 날개로 바람을 부수어 자연스럽게 시원한 바람을 느낄 수 있도록 하였습니다.

토스의 시작은 계좌번호가 아닌 전화번호로 간편하게 돈을 송금 할 수는 없을까 라는 경험에 집착으로 태어났고 현재는 편한 금융서비스의 대표 주자로 자리매김하였습니다.

예시처럼 문제의 본질뿐만 아니라 좋은 해결책을 찾는 것도 많은 기회가 될 수 있습니다. 그래서 기획자는 이런저런 많은 경험을 해보는 것을 추천 합니다.

3. 사용성(UX)에 대한 이해도 고객 이해의 연장선이다.

사용자들은 제품을 이해하고 사용하지 않습니다 더 나아가서 제품에 많은 에너지를 쏟고 싶어하지 않습니다. IT 제품의 경우 누군가 옆에서 설명해주는 경우는 많지 않고 스스로 사용하는 경우가 많습니다 만약 이때 제품을 사용하기 어렵거나 이해하기 어려운 경험이 나온다면 바로 고객 이탈로 이어지기 때문에 사용성에 대한 부분도 중요하게 생각 해야 합니다.

다만 사용자에 대한 이해는 하루 아침에 높아지지 않습니다. 여러 제품을 경험하고 관련 서적도 많이 읽으며 평소 제품에 호기심과 지속적인 관찰, 문제찾기 훈련, 제품 경험을 메모, 질문하고 공감하는 등 지속적인 습관화와 훈련을 많이 해야 역량을 키울 수 있습니다.

이외에도 유저 프로파일링 및 유저 시나리오 정의, 프로토타이핑, 집중 워크샵 등 일상적인 부분에서 뿐만 아니라 단기간에 집중적으로 역량을 키울 수 있는 방법들도 존재 합니다.

기술에 대한 이해

기획자가 가져야 할 핵심 역량 두번째 기술에 대한 이해 입니다. 이번 시간에는 기획자는 어떤 기술을 배우면 좋은지 또 어떤 방식으로 기술을 배우는게 좋은지 이야기 해보도록 하겠습니다.

서비스 기획자가 기술을 어디까지 알아야 하나?

보통의 기획자들은 기술을 모른다 그래서 좌절하는 경우가 많습니다. 그렇다 보니 기술의 기초부터 이해하려고 하고 코딩을 할 줄 알아야 한다고 착각하지만 그렇지 않습니다. 기획자가 알아야 하는 것은 코딩 방법이 아니라 더 좋은 제품을 만들고 원활한 협업을 위한 기술의 대한 개념, 구조, 역할들을 알아야 합니다. 특히 혁신적인 IT 제품을 기획하기 위해선 새로운 기술 트렌드를 파악하고 이를 응용하는 역량이 중요합니다.

기획자가 알아야 할 주요 기술 개념

클라이언트/서버/통신/데이터베이스 간 역할과 개념 등 IT 제폼 및 서비스의 기본 구조
IT 제품이 서비스 되는 환경인 인터넷, 웹 등의 Online 환경의 개념과 이해
고객 접점의 플랫폼과 디바이스 특성
크로스 플랫폼이나 서버리스 같은 기술 동향
더 나아가 AI, Blockchain, Cloud 같은 신 기술

기획자가 기술에 대한 이해를 높이기 위해

모르는 것, 배우는 것에 겁먹지 말기
일상적인 순간에도 기술에 대한 호기심을 가지기
좋은 제품을 만들기 위한 기술 이외에 너무 많은 지식을 습득하는 건 오히려 독이다

협업 능력과 프로세스에 대한 이해

기획자가 가져야 할 핵심 역량 세번째인 협업 능력과 프로세스에 대한 이해 입니다. 기획자가 궁극적으로 해야 하는 일은 제품을 성공시키는 것 입니다. 하지만 제품을 성공시킨다고 해서 처음부터 완벽한 기획으로 제품을 성공 시키기 보단 처음엔 서툰 기획이더라도 팀과 함께 소통하며 점진적으로 함께 만들며 성공해 나가는 것이 중요합니다.

이러한 동향 때문에 IT 업계는 애자일 방법론이 대표적인 프로세스로 자리매김 하였고 가장 널리 사용되고 있습니다. 다음은 에자일 방법론으로 하여금 협업을 이끌어 내기 위한 역량을 이야기 해보도록 하겠습니다.

기획자가 좋은 협업을 이끌어 내기 위해 알아야 할 것

처음부터 완벽한 기획서를 작성하기 보단 끊임없는 변화를 통한 완성 초점 두기
제품 자체의 스펙을 설명하기보단 왜 이러한 기능이 나오게 되었는지 의도 설명에 집중하기
문제 해결을 위한 다양한 프로세스 도구에 대한 이해 가지기
팀을 용병팀이 아닌 성공시키기 위한 미션팀으로 변화시키기
각 직군에 있는 전문가들의 업무를 공감하고 이해하기

마무리, 기획자는 슈퍼맨이 되어야 한다

적은 개발 비용으로 좋은 제품 만들기
협업을 위해 다른 직군의 업무를 잘 이해하고 파악하기
출시로 끝나는 것이 아니라 출시-측정-제품개선의 사이클로 무한 반복을 통한 성장
회사마다 조직 구성과 업무 프로세스가 다르다보니 이를 잘 파악해야 함
가치 창조를 통한 정형화되지 않은 문제를 해결하는것이 기획자 업의 본질임

Product 팀과 PM

Product 팀과 PM이 무엇인지 알기 위해선 Product가 무엇인지 알아야 합니다. IT 시대에서 흔히 Product라고 함은 단순히 서비스, 코딩으로 만들어진 제품이 아니라 문제 해결을 위해 탄생한 아이디어의 집약적인 창작물 입니다. Product 팀과 PM은 진짜 고객의 문제를 찾고 그 문제를 해결 한 게 맞는지 검증(Product Market Fit)해야 하고 PM은 이러한 팀을 이끄는 사람 입니다.

90프로 이상의 제품은 쓸모가 없다

파격적인 문단이긴하나 실제로 대부분 IT 제품을 개발하는 스타트업은 90% 이상이 손익분기점을 넘기지 못하고 사라지게 됩니다. Failory 사이트에서 각 스타트업 기업들이 왜 망했는지 알 수 있으며 이들의 대부분은PMF(Product Market Fit)을 충족하지 못해 사라지게 되었다는 것을 알 수 있습니다.

생존을 위한 제품 전략 - 린 스타트업

린 스타트업(lena startup) 이란 아이디어의 최소요건을 빠르게 제품화(MVP)한 뒤 시장의 반응을 보고 다음 제품에 반영하는 것을 반복해 성공 확률을 높이는 방법론 입니다. 토스 같은 경우에도 린 스타트업 방법론을 반영하여 8번 실패하고 9번째에 성공한 케이스 입니다.

린 스타트업의 핵심은 작고 빠른 실패를 반복해 성공의 단서를 찾는 것 입니다. 하지만 작은 실패들도 너무 많이 반복한다면 리스크가 점점 커지기 때문에 고객의 진짜 문제가 무엇인지 질적, 양적으로 충분히 파악하고 가설을 세우며 의미 있는 실패를 해야 합니다.

실제 사례(Use Case)1 - 학자금 대출 상환 앱 올라플랜

해당 사례는 실제 강사님께서 직접 문제를 해결해보신 경험을 바탕으로 한 케이스 입니다.

배경 및 문제 정의

매년 학자금 대출의 비중이 높아지고 있는 현상에 대해 처음에는 대학생 혹은 사회초년생들이 돈을 관리하는 경험이 부족해 상환을 빨리 하지 못한다고 생각 했지만 실제로는 달랐습니다.

학자금 대출을 보유한 학생들을 대상으로 인터뷰를 진행 했고 그 결과 절반 정도의 사람들은 상환 방법을 몰라 연체한 경험이 있다고 답을 했습니다. 이를 통해 직접 고객을 만나며 실제 문제점이 파악을 하지 못해 제대로 된 문제 정의가 이루어지지 못했다고 이야기 했습니다.

문제 해결

문제를 파악하고 정의한 이후엔 빠르게 카카오톡으로 고객을 모집하여 문제를 해결해 주었고(MVP) 1차 모집 때 4:1 이였던 경쟁률이 2차 모집 당시 10:1 로 두 배 이상으로 오른 것으로 파악 했습니다. 이후 올라플랜 이라는 어플을 출시하고 사용자들에게 맞춤 상환플랜을 제시하고 상환 날짜가 다가왔을 때 자동으로 이체 될 수 있도록 간편 자동상환 기능을 탑재 하였습니다.

결론

제품을 만드는데 있어선 작은 노력으로 큰 효과를 볼 수 있는지, 비즈니스적으로 임팩트가 큰 지 파악을 하는 것도 중요하지만 무엇보다 사용자가 불편해하는 문제가 무엇인지 파악하기 위해 진짜 고객들을 만나는 것이 가장 중요 합니다.

실제 사례(Use Case)2 - 29CM 아카이빙을 활용한 재구매율 상승

개요

29CM 에선 좋아요나 장바구니를 활용해 내가 관심있게 본 상품들을 아카이빙 할 수 있고 내부적으로 고객들이 어떤 경로로 상품을 살펴보게 되었는지 데이터를 저장 할 수 있습니다. 29CM은 데이터를 활용해 고객들이 상품 아카이빙으로 끝나는 것이 아니라 구매까지 이어지길 바랬습니다.

문제정의&가설수립

실제로 아카이빙 기능이 상품을 구매로 이어지게 하는데 도움을 주는 것은 확실합니다. 아카이빙을 한 제품의 10프로는 제품 구매로 이어지기 때문입니다. 하지만 반대로 이야기 하면 우리는 아카이빙 상품의 90프로를 놓치고 있다 라는 이야기 입니다. 29CM은 이러한 이유가 아카이빙을 해둔 시간이 지날수록 해당 상품에 대한 관심이 떨어지기 때문에 적절한 구매 타이밍을 놓치기 때문이라고 생각하였고 아카이빙 제품을 잊지 않고 리마인드 해주면 해당 상품에 지속적으로 관심을 가지고 구매 할 것이라고 가정해 보았습니다.

가설검증

장바구니에 담아두거나 좋아요를 누르고 구매하지 않은 상품들을 가지고 있는 고객을 대상으로 상품 리마인드 메세지를 발송해 보았고 푸시 클릭율(CTR)과 구매 전환율(CVR)을 검증 지표로 삼았습니다. 효과를 높이기 위해 푸시를 많이 확인하는 골든타임과 실질적인 푸시 구매 기여도, 고객을 혹 할 수 있는 UX 등을 함께 분석해 반영해 보았습니다.

그 결과 푸시 클릭율과 구매 전환율이 광고 푸시 대비 13배, 10배 높은 수치를 기록하였고 기대 임팩트 대비 144% 라는 수치를 초과 달성하게 되었습니다. 결국 상품 리마인드 기능은 구매 전환율을 높인다는 사실을 확인하였고 이후 리소스를 투입해 자동화&개인화를 실행하였습니다.

결론

앞선 케이스를 함께 비교해 보았을 때 린 방법론은 대부분의 시장에서 통하는 것을 확인 할 수 있고 고객의 진짜 문제를 파악했을 때 비즈니스 기회를 발견 할 수 있습니다.

여행 서비스 기획서 템플릿

여행 서비스에서 흔히 사용하는 서비스 기획서 템플릿 예시입니다. 모든 기획서가 해당 템플릿을 따르진 않고 어떤 툴을 사용해서 작성하던 크게 상관은 없습니다. 또한 문서가 업데이트 될 때마다 버전을 작성하며 버전 관리의 중요성을 강조하기도 하였습니다. 다음은 기획서에 들어가는 항목이 무엇이 있는지를 설명한 내용 입니다.

서비스 정의 : 어떤 문제가 있는지 어떤 이슈가 있는지 서비스를 개발 할 것인지 아니면 업데이트 할 것 인지 등의 개요와 문제 해결 및 서비스 사용 대상 그리고 업데이트 내용을 작성 합니다.
목표 : 사용자 수 유치를 위한 것인지 리텐션을 위한 것인지 내부직원이나 파트너의 업무 효율을 위한 것인지 업데이트를 통해서 예상되는 기대효과를 작성하는 파트 입니다. How 보단 Why에 집중하는 것이 중요하고 여러 이해관계자들 마다 생각하거나 선호하는 스타일이 다르기 때문에 이 점 또한 유의해서 작성해야 합니다.
IA(Information Architecture) : 우리나라 말로 정보 구조도 라고도 합니다. 신규 프로젝트나 정보 구조도에 변화가 있을 때 작성 하고 대부분 엑셀 형식으로 많이 작성하지만 엑셀 형태로 작성 이전에 메뉴 트리나 마인드 맵 형 등으로 먼저 작성 해봅니다. 한 화면 내에 통합 할 수 있는 부분은 통합하고 뎁스의 구조를 잡아야 하고 또 MECE 규칙에 맞게 중복되지 않고 빠지는 것 없이 하는 것이 포인트 입니다.
플로우 차트 : 서비스에 접속해서 해당 기능이 어떻게 흘러가서 동작하는지를 보여주는 차트 입니다. 전체적인 흐름에 대해서 그릴 수 도 있고 중요한 부분만 따로 떼어서 만들 수 도 있고 얼럿이나 앱 푸쉬 등이 있을 때 없을 때에 대해서 각각의 로직이나 흐름에 대해서 설명할 수 있습니다. 더 편한 방법을 찾거나 단계를 줄이기도 하고 개발자나 디자이너 등 여러 이해관계자들의 이해를 돕는데 활용 합니다.
API 항목 : 우리 API를 파트너사에서 활용하게 된다면 작성해서 전달해주는 문서 입니다. 파트너사에 API 문서를 전달 해 주고 파트너에게 대응해 주는 형태로 진행 합니다.

여행 서비스에서 많이 사용하는 용어

PMS(Property Management System) : 호텔 자산 관리 시스템을 뜻하며 호텔이나 숙박시설에서 예약고객의 체크인 체크아웃, 객실배정, 객실 요금, 청구 관리 등의 서비스로 시작하여 현재는 호텔에서 일어나는 인사, 재무 등 모든 업무를 관리하는 업무로 확대해서 쓰이고 있습니다.
하드블럭 : 여행사나 여행 플랫폼 이나 서비스에서 많이 사용하는 용어 호텔이나 비행기의 일부 시간에 일부 좌석이나 객실을 미리 싸게 구매해 두는 것을 이야기 합니다. 여름 휴가나 크리스마스 시즌에 공급이 부족하다고 예측 될 때 미리 수량을 확보하고 비싸게 파는 것이 대부분 입니다. 코로나 당시엔 이 하드블럭으로 도산하는 여행사들도 많았습니다.
숏헤드, 롱테일 : 여행업에서 뿐만 아니라 경제나 마케팅 사회심리학에서 많이 쓰이는 개념입니다. 대부분 시장은 상위 20프로와 하위 80프로로 나뉘는데 여기서 상위 20프로는 숏헤드 하위 80프로는 롱테일이라고 부릅니다.
채널링 : 쿠팡 위메프 등으로 판매를 하면 너무 많은 채널을 관리 하게 되고 재고나 이런걸 관리하기 어렵기 때문에 채널링 업체와만 계약을 하면 그 업체에서 다양한 채널에 판매를 해주는 것 입니다. 외부 채널링 서비스를 통해 우리 판매 채널에 유입 되면 채널인, 우리를 통해서 상대방 채널에 판매 되는 것을 채널 아웃이라고 합니다.
매핑 : 숙소나 숙소의 객실 타입들을 채널 별로 맞춰주는 작업을 이야기 하는 것 입니다. 독점 상품을 제외하면 모든 채널들은 다수의 숙소로부터 동일한 상품 정보를 받게 됩니다. 예를 들면 A호텔에 있는 B타입 객실에 대해서 야놀자는 초특가 객실 이라고 이름을 짓고 다른 판매 객실에는 저렴한 객실 이라고 말할 수 있습니다 여기서 어떤 용어로 불리던 이것이 모두 B 타입 객실임을 알 수 있도록 A 호텔에 연결 시켜주는 것을 매핑이라고 합니다.
업셀링 : 동일한 카테고리 내에서 더 고가의 상품을 구매하도록 이끄는 전략 입니다.
크로스셀링 : 두 개 이상의 카테고리간 교차 구매를 의미하는 용어입니다. 한 카테고리의 상품을 구매한 고객에게 연관된 다른 영역의 상품을 함께 구매하도록 유도하는 마케팅 기법입니다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 여행 서비스 기획서 템플릿 및 여행 서비스 용어 (챌린지 98일차)

sunshine0901 — Sun, 1 Feb 2026 23:22:52 +0900

여행 서비스 기획서 템플릿

서비스 정의 : 어떤 문제가 있는지 어떤 이슈가 있는지 서비스를 개발 할 것인지 아니면 업데이트 할 것 인지 등의 개요와 문제 해결 및 서비스 사용 대상 그리고 업데이트 내용을 작성 합니다.
목표 : 사용자 수 유치를 위한 것인지 리텐션을 위한 것인지 내부직원이나 파트너의 업무 효율을 위한 것인지 업데이트를 통해서 예상되는 기대효과를 작성하는 파트 입니다. How 보단 Why에 집중하는 것이 중요하고 여러 이해관계자들 마다 생각하거나 선호하는 스타일이 다르기 때문에 이 점 또한 유의해서 작성해야 합니다.
IA(Information Architecture) : 우리나라 말로 정보 구조도 라고도 합니다. 신규 프로젝트나 정보 구조도에 변화가 있을 때 작성 하고 대부분 엑셀 형식으로 많이 작성하지만 엑셀 형태로 작성 이전에 메뉴 트리나 마인드 맵 형 등으로 먼저 작성 해봅니다. 한 화면 내에 통합 할 수 있는 부분은 통합하고 뎁스의 구조를 잡아야 하고 또 MECE 규칙에 맞게 중복되지 않고 빠지는 것 없이 하는 것이 포인트 입니다.
플로우 차트 : 서비스에 접속해서 해당 기능이 어떻게 흘러가서 동작하는지를 보여주는 차트 입니다. 전체적인 흐름에 대해서 그릴 수 도 있고 중요한 부분만 따로 떼어서 만들 수 도 있고 얼럿이나 앱 푸쉬 등이 있을 때 없을 때에 대해서 각각의 로직이나 흐름에 대해서 설명할 수 있습니다. 더 편한 방법을 찾거나 단계를 줄이기도 하고 개발자나 디자이너 등 여러 이해관계자들의 이해를 돕는데 활용 합니다.
API 항목 : 우리 API를 파트너사에서 활용하게 된다면 작성해서 전달해주는 문서 입니다. 파트너사에 API 문서를 전달 해 주고 파트너에게 대응해 주는 형태로 진행 합니다.

여행 서비스에서 많이 사용하는 용어

PMS(Property Management System) : 호텔 자산 관리 시스템을 뜻하며 호텔이나 숙박시설에서 예약고객의 체크인 체크아웃, 객실배정, 객실 요금, 청구 관리 등의 서비스로 시작하여 현재는 호텔에서 일어나는 인사, 재무 등 모든 업무를 관리하는 업무로 확대해서 쓰이고 있습니다.
하드블럭 : 여행사나 여행 플랫폼 이나 서비스에서 많이 사용하는 용어 호텔이나 비행기의 일부 시간에 일부 좌석이나 객실을 미리 싸게 구매해 두는 것을 이야기 합니다. 여름 휴가나 크리스마스 시즌에 공급이 부족하다고 예측 될 때 미리 수량을 확보하고 비싸게 파는 것이 대부분 입니다. 코로나 당시엔 이 하드블럭으로 도산하는 여행사들도 많았습니다.
숏헤드, 롱테일 : 여행업에서 뿐만 아니라 경제나 마케팅 사회심리학에서 많이 쓰이는 개념입니다. 대부분 시장은 상위 20프로와 하위 80프로로 나뉘는데 여기서 상위 20프로는 숏헤드 하위 80프로는 롱테일이라고 부릅니다.
채널링 : 쿠팡 위메프 등으로 판매를 하면 너무 많은 채널을 관리 하게 되고 재고나 이런걸 관리하기 어렵기 때문에 채널링 업체와만 계약을 하면 그 업체에서 다양한 채널에 판매를 해주는 것 입니다. 외부 채널링 서비스를 통해 우리 판매 채널에 유입 되면 채널인, 우리를 통해서 상대방 채널에 판매 되는 것을 채널 아웃이라고 합니다.
매핑 : 숙소나 숙소의 객실 타입들을 채널 별로 맞춰주는 작업을 이야기 하는 것 입니다. 독점 상품을 제외하면 모든 채널들은 다수의 숙소로부터 동일한 상품 정보를 받게 됩니다. 예를 들면 A호텔에 있는 B타입 객실에 대해서 야놀자는 초특가 객실 이라고 이름을 짓고 다른 판매 객실에는 저렴한 객실 이라고 말할 수 있습니다 여기서 어떤 용어로 불리던 이것이 모두 B 타입 객실임을 알 수 있도록 A 호텔에 연결 시켜주는 것을 매핑이라고 합니다.
업셀링 : 동일한 카테고리 내에서 더 고가의 상품을 구매하도록 이끄는 전략 입니다.
크로스셀링 : 두 개 이상의 카테고리간 교차 구매를 의미하는 용어입니다. 한 카테고리의 상품을 구매한 고객에게 연관된 다른 영역의 상품을 함께 구매하도록 유도하는 마케팅 기법입니다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 29CM PO가 알려주는 모든 시장에서 통하는 서비스 기획법 (챌린지 97일차)

sunshine0901 — Sat, 31 Jan 2026 23:47:49 +0900

Product 팀과 PM

90프로 이상의 제품은 쓸모가 없다

생존을 위한 제품 전략 - 린 스타트업

실제 사례(Use Case)1 - 학자금 대출 상환 앱 올라플랜

해당 사례는 실제 강사님께서 직접 문제를 해결해보신 경험을 바탕으로 한 케이스 입니다.

배경 및 문제 정의

문제 해결

결론

실제 사례(Use Case)2 - 29CM 아카이빙을 활용한 재구매율 상승

개요

문제정의&가설수립

가설검증

결론

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 기획자의 핵심 역량2,3, 마무리 (챌린지 96일차)

sunshine0901 — Fri, 30 Jan 2026 23:37:01 +0900

기술에 대한 이해

서비스 기획자가 기술을 어디까지 알아야 하나?

기획자가 알아야 할 주요 기술 개념

클라이언트/서버/통신/데이터베이스 간 역할과 개념 등 IT 제폼 및 서비스의 기본 구조
IT 제품이 서비스 되는 환경인 인터넷, 웹 등의 Online 환경의 개념과 이해
고객 접점의 플랫폼과 디바이스 특성
크로스 플랫폼이나 서버리스 같은 기술 동향
더 나아가 AI, Blockchain, Cloud 같은 신 기술

기획자가 기술에 대한 이해를 높이기 위해

모르는 것, 배우는 것에 겁먹지 말기
일상적인 순간에도 기술에 대한 호기심을 가지기
좋은 제품을 만들기 위한 기술 이외에 너무 많은 지식을 습득하는 건 오히려 독이다

협업 능력과 프로세스에 대한 이해

기획자가 좋은 협업을 이끌어 내기 위해 알아야 할 것

처음부터 완벽한 기획서를 작성하기 보단 끊임없는 변화를 통한 완성 초점 두기
제품 자체의 스펙을 설명하기보단 왜 이러한 기능이 나오게 되었는지 의도 설명에 집중하기
문제 해결을 위한 다양한 프로세스 도구에 대한 이해 가지기
팀을 용병팀이 아닌 성공시키기 위한 미션팀으로 변화시키기
각 직군에 있는 전문가들의 업무를 공감하고 이해하기

마무리, 기획자는 슈퍼맨이 되어야 한다

적은 개발 비용으로 좋은 제품 만들기
협업을 위해 다른 직군의 업무를 잘 이해하고 파악하기
출시로 끝나는 것이 아니라 출시-측정-제품개선의 사이클로 무한 반복을 통한 성장
회사마다 조직 구성과 업무 프로세스가 다르다보니 이를 잘 파악해야 함
가치 창조를 통한 정형화되지 않은 문제를 해결하는것이 기획자 업의 본질임

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 기획자의 핵심역량1 (챌린지 95일차)

sunshine0901 — Thu, 29 Jan 2026 23:36:53 +0900

서비스 기획자가 가져야 할 핵심 역량

고객에 대한 이해
IT 기술에 대한 이해
협업 능력과 프로세스에 대한 이해

PM/PO 관련된 서적에서도 고객에 대한 이해는 많이 강조를 합니다 따라서 고객에 대한 이해에 대해 가장 먼저 살펴 보도록 하겠습니다.

고객에 대한 이해란

1. 고객들이 진짜 원하는 것은 무엇인가? (문제 정의)

당근의 경우에는 활성화된 중고거래 시장에서 불확실한 택배 거래 때문에 중고거래를 꺼려 하는 사람들이 많다 라는 문제점을 파고들어 성공 하였고

알라미라는 앱은 알람앱은 어떤 휴대폰에도 있지만 본인의 의지로 한 번에 일어나기 힘들어하는 사람들의 니즈를 잘 파고 들어 성공한 케이스 입니다.

이처럼 문제의 본질을 파악하고 정의하기만 해도 기회를 발견 할 수 있습니다.

2. 고객들은 어떤 형태로 가치를 제공받고 싶어하는가? (솔루션 찾기)

3. 사용성(UX)에 대한 이해도 고객 이해의 연장선이다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 기획자 업의 본질 (챌린지 94일차)

sunshine0901 — Wed, 28 Jan 2026 23:20:26 +0900

현업자들이 생각하는 기획자란

현업 기획자들이 이런 고민을 가지는 이유는?

기획은 물론 일정관리, 스크립트 작성, 미팅 등등 해야 할 일들이 너무 많습니다.
해야 할 일들이 너무 많기 때문에 배워야 할 것도 너무 많습니다.
훌륭한 기획자가 될 수 있는 알려진 성장 트랙이 없습니다.
개발자 출신의 제품 리더들은 많지만 반대는 없습니다. 심지어 개발 출신 제품 리더를 선호하는 회사들도 많습니다.
회사마다, 회사 내 부사마다도 일하는 방식이 너무나도 다릅니다.
서비스 기획자 뿐만 아니라 제품 관리자인 PM, 제품 소유자인 PO도 상황은 크게 다르지 않습니다.

실제 현업 기획자들이 추가로 담당하는 역할들

SM(Scrum Master : 스크럼 마스터) : 애자일에 맞는 방식으로 팀이 운영되고 제품 개발이 이루어지도록하는 책임자 입니다.
PM(Project Manager : 프로젝트 관리자) : 정해진 기간 내에 목표를 달성하기 위해 프로젝트의 예산, 자원, 일정을 관리하고 계획을 수립하며 진행하는 책임자 입니다.
DM(Delivery Manager : 제품 실행 관리자) : PM(제품 관리자) 체계의 미션팀에서 제품 조직의 업무가 원활히 진행되도록 돕는 일종의 Project Manger 역할 입니다.
Product Designer(제품 디자이너) : 제품의 시각적/조작적 측면을 설계하고 디자인하는 담당자로서 제품의 사용자 경험 전반을 기획 의도에 맞게 구현하는 역할 입니다.
UX Researcher : 제품 조직과 긴밀히 협업하여 다양한 시장에서의 사용자 요구사항, UX, UI 개선사항을 조사하고 도출하는 역할 입니다.
Data Analyst/Data Scientist : 서비스 전체에서 수집된 대량의 데이터를 처리, 분석하여 통찰력 있는 정보를 추출/가공하여 제품팀에 전달을 하는 역할 입니다.
Customer Service Manager : 현재 제공중인 서비스의 전반적인 품질과 고객 만족도를 지속적으로 점검하고 개선 조치를 취하는 책임자 입니다.

이러한 직군을 분업하는 회사는 많지 않습니다(대기업도 마찬가지) 대부분 PM 이나 기획자가 모두 담당해서 일을 하곤 합니다.

따라서 현업 기획자들이 많이 던지는 질문들

왜 이 많은 일을 해야만 하는가?
과연 어디까지가 내 일인가?
기획자는 과연 전문성을 가질 수 있는가?

서비스 기획자(PM/PO)의 정의와 업무

서비스 기획자란

서비스 기획자란 담당하는 제품의 성공을 책임지고 이를 위해 필요한 모든 일을 하는 사람 입니다.

서비스 기획자의 업무

제품 상위기획과 전략 수립
제품 상세기획/제품설계
제품 개발관리 및 출시
서비스 운영/데이터 분석과 지속적인 개선

서비스 기획자 업의 본질

문제를 정의하고 솔루션을 찾은 후에 팀과 함께 실행하며 제품을 통한 문제 해결을 하는 것 입니다.

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.

[제로베이스 PM 파트타임 스쿨] 15주차 - 콴다로 알아보는 실험을 활용한 기획3, 케이스 스터디 (챌린지 93일차)

sunshine0901 — Tue, 27 Jan 2026 23:22:04 +0900

실험 결과 분석

후속 액션

실험 결과 분석 이후 취해야 할 행동에 대해 알아보겠습니다.

User Reasearch : 실험을 통해 데이터는 나왔지만 데이터 이면에 숨겨진 유저들의 생각과 의도까지 파악이 불분명 할 땐 유저 인터뷰를 진행해 유저들의 생각과 의도롤 파악해보는 것이 좋습니다.
후속 실험 설계 : 실험에서 목표로 했던 지표를 계속 올려야 하는 상황이라면 실험의 성공/실패 여부와 관계 없이 다음 실험을 또 진행 할 수 있습니다. 실험 성공 이후 후속 실험을 설계 한다면 우선순위가 낮았던 다른 가설을 채택하여 할 수 있고 실험 실패 이후 후속 실험을 설계 한다면 실패 원인을 분석 후 다시 실험을 설계 할 수 있습니다.
전면 배포 및 대시보드 세팅 : 실험이 성공했다면 실험군에 적용했던 조작변인을 전체 서비스에 적용하는 전면 배포 과정을 거치고 실험 진행을 위해 사용했던 모니터링 대시보드를 health Check 및 지표 확인용 대시보드로 바꿔줍니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 인앱광고 시장 소개

인앱 광고란

인앱 광고 구조

인앱 광고 지표

인앱광고 BM 최적화 실험 케이스 스터디 - 배경

본격적인 케이스 설계에 앞서 실험을 왜 하게 되었고 어떤 실험을 할 것인지 이야기 해보겠습니다.

콴다 앱 내 트래픽을 통한 수익 창출을 위해 인앱광고를 삽입 했을 때 어떤 효과를
최적화 실험을 통해 인앱광고를 통해 매출을 얼마나 낼 수 있는지와 이로 인한 이탈 유저는 없는지 확인해 보고자 합니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 가설 수립

1차 실험

제일 중요한 가드레일 지표인 이탈 확인과 메인 기능에서의 지면 개발에 집중 하였습니다.
유저들에게 광고를 노출했을 때의 잔존율은 광고 비노출 유저의 잔존율과 차이가 나지 않을 것이다
Main 기능인 검색 기능에서 기능 사용 전과 기능 사용 후에 노출되는 광고 지면에는 유의미한 ARPU 차이가 있을 것이다. (ARPU란 앱의 활동 사용자 1인당 평균 결제 금액을 뜻합니다.)

후속 실험

노출 빈도를 상향시켜 매출과 이탈의 trade-off를 확인합니다.
새로운 지면 개발하고 기존 실험군과 대조해서 확인해봅니다.
광고 네트워크 추가하여 어떤 효과를 불러오는지 확인해봅니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 실험 설계

실험 대상 : 광고가 유저에게 부정적인 경험을 줄 수 있는 요소이기 때문에 전체 유저가 아닌 일부 유저를 대상으로 진행하고 또한 신규 유저도 제외하여 기존 유저를 대상으로 진행 했습니다. 후속 실험 시에는 이전 실험에 영향을 받지 않도록 이전에 광고를 보지 않았던 유저를 대상으로 진행하였습니다.
실험 기간 : 빠른 실험과 분석을 위해 실험기간을 최소한으로 설정하고 전체 실험 기간동안 유저에게 광고를 노출하는 것이 아닌 그룹 내 유저가 모두 동일한 기간동안 광고를 보게끔 실험을 설계 했습니다.
성공 지표/가드레일 지표
가드레일 지표 : 잔존율을 단기/중기/장기로 나누어 세부적으로 비교
성공 지표 : AD ARPU
대조군 설정
초기 : 실험 대상이 아닌 유저 중 랜덤으로 샘플링을 진행하고 샘플링된 대조군이 실험군과 활동성 차이가 없는지 검증하는 과정을 거쳤습니다.
이슈 발생 : 원인 불명, 어떻게 랜덤 샘플링을 진행해도 대조군에서 활동성 지표가 더 높은 locale 이 생겨났습니다. 아무래도 실험군이 아닌 유저가 더 많다보니 이런 이슈가 발생했을 것으로 추정됩니다.
이슈 발생 이후 : 대조군을 실험군 중 하나로 편입하고 대조군으로 설정된 실험군은 광고 노출을 아예 하지 않도록 설정 하였고 이후 활동성 차이 이슈가 없어졌습니다.

인앱광고 BM 최적화 실험 케이스 스터디 - 개발 및 QA

인앱광고 BM 최적화 실험 케이스 스터디 - 실험 진행 시 유의 사항

대시보드 모니터링하기

모의 실험 진행하기

인앱광고 BM 최적화 실험 케이스 스터디 - 결과 분석하기

*해당 글은 제로베이스 PM 파트타임 스쿨의 강의 자료 일부를 발췌하여서 작성되었습니다.