PM 부트캠프 13일차 후기
오늘 부트캠프에서 친해진 뀨에게 대화신청이 왔다😆
예전에는 같은 조여서 일찍 출석하거나 늦게 남아서 자주 토크토크했는데 요즘 조도 달라지고 알바에 과제에 수업에 치이다 보니 대화를 많이 못해서 아쉬웠는데 이렇게 대화신청이 오다니💕
해피해피한 하루🥰


서비스 기획 입문 강의 3일차
서비스 기획 입문 강의를 들으면 들을수록 PM이 해야 하는 일이 점점 많아지는 거 같아서 PM이 다 할 수 있는 건가? 싶은 생각이 든다🙄
챕터 2-5 정책 기획
1️⃣ 서비스 정책
Q. 서비스 정책이란?
👉 서비스 운영에 필요한 모든 규칙과 기준을 담은 안내서
- PM은 기획 단계에서부터 정책의 존재 이유와 영향력을 이해하고 정책을 기획해야 함
👉 사용자가 안전하고 효율적으로 서비스를 이용하도록 안내하는 가이드라인
- 문제 발생 시 어떤 기준으로 대응할지 명확히 해주는 기준점
◾ 실무 엿보기 : 네이버의 이용약관

2️⃣ 서비스 정책의 종류 예시
📌 회원가입 정책
| 정책 종류 | 예시 | 왜 필요한가요? |
| 연령 제한 | - 만 14세 이상만 가입 가능 - 19세 이상 성인 콘텐츠 이용 가능 |
법률 준수(ex. 청소년 보호법) |
| 지역 제한 | 이 콘텐츠는 해당 국가에서는 볼 수 없습니다. | 저작권, 각국의 법령 준수 |
| 이용 자격 | 초대장이 있어야 가입 가능 | 서비스 방향성 |
◾ 실무 엿보기 : 청소년 보호 정책


◾ 실무 엿보기 : 클럽하우스ㅣ초대장 가입 정책


📌 서비스 운영 정책
| 정책 종류 | 예시 | 왜 필요한가요? |
| 콘텐츠 가이드라인 | 욕설·비방·음란물은 삭제될 수 있습니다. | 건강한 커뮤니티 유지, 사용자 간 분쟁 예방 |
| 저작권 정책 | 무단 복제 시 법적 책임이 따릅니다. | 창작자 권리 보호, 불법 콘텐츠 차단 |
| 금지 행위 및 제재 | 부정 이용 시 계정 정지 또는 영구 제재 | 악성 사용자 방지 |
| 동시 접속 제한 | 한 계정당 2개 기기만 동시 이용 가능 | 계정 공유 방지, 수익 보호 |
◾ 실무 엿보기 : 쿠팡의 상품평, 상품 문의 및 판매자평 운영 정책

📌 결제 정책
| 정책 종류 | 예시 | 왜 필요한가요? |
| 배송/반품/환풀 | 5만원 이상 무료배송, 7일 이후로는 단순 변심 반품 불가 | 소비자 불만 예방, 무분별한 반품 방지 |
| 결제 | 동일한 결제 수단으로만 환불 제공 | 사용자에게 예측 가능한 경험 제공 |
📌 개인정보 정책
| 정책 종류 | 예시 | 왜 필요한가요? |
| 개인정보 처리 방침 | 수집된 개인정보는 고객 응대 외 목적으로는 사용되지 않으며, 보관 기간 후 파기됩니다. | 개인정보 보호법 준수, 사용자 신뢰 확보 |
3️⃣ 좋은 서비스 정책
서비스의 목적에 부합하면서도 사용자 경험을 해치지 않고, 법과 운영 현실 모두를 고려해 리스크를 최소화한 결정
📌 서비스 방향성 제시
- 서비스 정책은 회사와 서비스가 지향하는 가치를 구체적으로 보여줌
◾ 실무 엿보기 : 브런치 작가 멤버십 신청 조건


◾ 실무 엿보기 : 당근마켓의 동네 인증

📌 UX 일관성 확보
👉 정책은 서비스 전체의 일관된 경험을 만들어줌
- 내가 이렇게 행동하면 어떤 결과가 나올까? 예측 가능
👉 정책이 없거나 불명확하면?
- 사용자 혼란 😵 + 불만 증가 😡
📌 리스크 대응
👉 일반적이지 않은 악용 케이스(edge case)에 대한 대비 필요
ex. 가입/탈퇴 반복을 통한 이벤트 악용, 탈퇴 후 댓글이 그대로 남아 피해 유발 등
👉 정책이 있으면?
- 사용자와 서비스 간의 공정한 기준 확보
- 문제가 생겨도 신속하고 일관된 대응 가능
◾ 실무 엿보기 : 쿠팡의 로켓프레시 반품 정책을 악용한 사용자


◾ 실무 엿보기 : 1원 송금 인증


📌 법적 준수
- 개인정보보호법, 전자상거래법, 청소년보호법 등 관련 법령 준수
- 서비스 운영 시 반드시 따라야 할 법률들을 정책에 체계적으로 반영
- 위반 시? → 과징금, 서비스 중단 등 심각한 리스크 발생
📌 운영과 기술 구현이 가능
- 현실적으로 개발과 운영이 가능한 수준이어야 하고, 고객센터(운영)가 감당할 수 있는 구조
ex. 3개월 이상 미접속 회원에게 자동 이메일+SNS+앱푸시는 너무 무거운 정책
📌 사용자 입장에서 이해 가능
- 누구나 읽었을 때 내가 이 정책에서 어떤 영향을 받는지를 쉽게 알 수 있어야 함
- 전문용어❌, UX 흐름과 맞지 않는 문구❌
📌 일관성 있고 예외가 적음
- 서비스 내 다른 정책들과 추돌되지 않아야 하며, 예외 상황이 자주 발생하지 않도록 설계
ex. 한쪽 정책에선 재가입 가능, 다른 쪽에서 재가입 불가라면 사용자 혼란 발생
4️⃣ 서비스 정책 기획 과정
왜 필요한가 → 무엇을 고려해야 하나 → 어떻게 만들고 실행할 것인가
👉 STEP1 - 정책의 목적 정의
- 정책이 무엇을 해결하기 위한 것인지, 왜 필요한지
ex. 탈퇴 정책은 고객의 개인정보 보호 및 서비스 오남용 방지를 위한 것처럼 목적이 구체적일수록 좋음
👉 STEP2 - 정책 설계 시 고려 요소 정리
▪ 외부 요인 (우리가 따라야 하는 것)
- 법령(개인정보보호법, 전자상거래법 등)
- OS/ 플래폼 정책 (ex. 애플 로그링 필수, 구글 심사 기준 등)
- SNS 연동 기준 (카카오/네이버/애플 제공 정보 범위)
▪ 내부 요인 (우리 상황에 맞게 판단할 것)
- 기존 서비스 정핵과의 충돌 여부
- 리스크 요소 (보안, 악용, 비용 등)
- 비즈니스 모델 연계 여부 (ex. 탈퇴 시 구독 처리)
👉 STEP3 - 정책 구조 설계
▪ 어떤 정책 항목을 정할지 구조화하고, 항목별 기준을 정의
- 회원가입 : 이메일 vs SNS, 정보 수집 범위
- 탈퇴 : 바로 탈퇴 가능 여부, 정보 삭제 시점
- 게시물 처리 : 탈퇴 후 유지 or 삭제
- 구독 상태 : 탈퇴 전 해지 필요? 자동 해지?
👉 STEP4 - 정책 문서화
- 제목, 목적, 적용 범위, 상세 정책, 예외 처리 등 포함
👉 STEP5 - 내부 공유 및 피드백
- 법적 리스크나 운영상 문제없는지 점검
- 이슈 발생 가능성에 대해 팀마다 의견 수렴
👉 STEP6 - 정책 구조 설계
- 사용자에게 투명하게 알리기 (약관/공지/팝업/이메일 등)
- 특히 기존 정책에서 변경사항 있다면 꼭 사전 고지
👉 STEP7 - 정책 반영 및 운영 점검
- 개발 배포 일정과 맞춰 운영
5️⃣ 예시 - 정기구독 멤버십 정책
⭐ 멤버십 정기구독 결제 정책을 기획해 주세요
👉 STEP1 - 정책의 목적 정의
- 사용자에게 명확한 결제 기준 제시
- 결제/해지 관련 CS 감소
- 유료 구독 매출을 안정적으로 확보(=멤버십 결제 전환율 높이기)
👉 STEP2 - 정책 설계 시 고려 요소
▣ 외부 요인
▪ 법률
- 전자상거래법 : 환불 요청 가능 조건, 정기결제 해지 절차, 보존 기간 명시 필요
▪ 결제수단
- 앱스토어 정책(Apple, Google) : 자체 결제가 아닌 인앱결제 시 환불 정책 제한 있음
- 결제 수단별 제약 : 카카오페이/휴대폰결제 시 일부 즉시 해지 불가 등
▣ 내부 요인
▪ 멤버십 상품
- 결제 금액 및 구독 기간은?
▪ 결제 수단
- 어떤 PG사랑 계약이 되었는지?
- 어떤 결제 방식 지원할 것인지?
▪ 포인트 및 쿠폰
- 포인트 적립 및 사용, 쿠폰 제도 도입할 것인지?
▪ 프로모션 연계
- 1개월 무료 프로모션 존재 여부?
- 이후 자동 유료 전환 시 고지 방식?
👉 STEP3 - 정책 구조 설계
| 항목 | 기준 예시 |
| 이용권 종류 | 스트리밍 전용/ 다운로드 포함/ 가족 이용권 등 |
| 결제 방식 | 앱스토어 인앱결제/ 카드/ 휴대폰 결제 등 |
| 자동결제 여부 | 기본 ON, 해지 시 다음 결제일부터 중단 |
| 환불 정책 | 구매 후 7일 이내 + 미이용 시 환불 가능(법적 기준) |
| 해지 정책 | 즉시해지 vs 만료일까지 사용 후 해지 |
| 해지 후 재가입 | 즉시 가능하나 할인 혜택은 제한 됨 |
| 무료 체험 정책 | 무료 체험 1회 한정, 중복 가입 불가 |
◾ 정기 결제일을 언제로 할까?
📍 첫 결제일과 동일한 날짜에 매월 정기 결제한다
ex. 1월 1일 결제한 경우 - 2월 1일, 3월 1일···12월 1일


📍 해당 월에 동일한 날짜가 존재하지 않는 경우 해당 월의 마지막 날에 자동 결제 (2월 29일)

Q. 결제 실패 시 적용할 프로세스는?
✅ [1안] 단순 재시도 기반 정책 (기본형)
👉 프로세스
- 결제 실패 시, 결제 당일 3회 재시도 (ex. 1시간 간격)
- 재시도 모두 실패 시, 바로 구독 종료 상태로 전환
- 사용자에게는 이메일 + 서비스 내 알림 발송
👉 장점
| 단순성 | 구현 및 운영이 쉬움 |
| 즉각적인 피드백 | 사용자에게 빠르게 상황 전달 가능 |
| 리스크 관리 용이 | 실패한 사용자를 빠르게 걸러낼 수 있음 |
👉 단점
| 사용자 불편 | 일시적인 카드 문제로도 구독 중단됨 |
| 매출 손실 가능성 | 재시도 간격이 짧아 회복 기회가 부족함 |
| 이탈 가능성 증가 | 재가입 과정에서 사용자 이탈 가능성 ↑ |
✅ [2안] 유예 기간 기반 정책 (관용형)
👉 프로세스
- 결제 실패 시, 3일 간격으로 최대 5회 재시도 (총 15일)
- 그동안 상태는 결제 대기 상태로 유지
- 마지막 재시도도 실패 시, 구독 종료 상태로 전환
- 결제 실패 시점과 마지막 재시도 후에는 모두 이메일 + 서비스 내 알림 발송
- 유예 기간 동안 콘텐츠는 일부 제한 (ex. 화질 제한, 특정 콘텐츠 잠금)
👉 장점
| 사용자 관점 친화적 | 일시적 결제 오류에 유연하게 대응 |
| 이탈 방지 | 유예 기간 중 서비스 지속적으로 접촉 가능 |
| 매출 회복 가능성↑ | 카드 교체/잔액 충전 등 복구 기회 ↑ |
👉 단점
| 복잡한 로직 | 상태 관리 및 제한 콘텐츠 처리 필요 |
| 부정 사용 위험 | 결제 없이 서비스 일부 이용 가능 |
| 명확한 서비스 경계 부족 | 사용자 입장에서 구독 상태 혼동 가능성 있음 |
👉 STEP4 - 정책 문서화
멤버십 정책 기획안1. 상품개요▪ 상품명 : 프리미엄 멤버십▪ 주요 헤택 : 콘텐츠 열람 가능 ▪ 결제 주기 및 금액 : 월간 9,800원/ 연간 99,000원 ▪ 상품 타입 : 월결제/ 연결제 2. 구독 상태 및 제어 정책구독 상태는 결제 상황에 따라 자동 반영▪ 미구독 : 구독 이력 없음 ▪ 구독중 : 유효한 정기결제가 진행 중인 상태 ▪ 해지예약 : 다음 결제 시점 이전에 해지를 예약한 상태 ▪ 구독해지 : 구독 종료된 상태 (직접해지 또는 결제 실패) 3. 자동 결제 정책- 사용자가 선택한 결제 수단을 통해 가입일 기준으로 매월/매년 자동 결제- 1회차 결제일 기준으로 매월 같은 날 자동 결제 ex. 3월 5일 시작 → 다음 결제일 4월 5일 - 결제일이 해달 월에 존재하지 않을 경우, 말일에 결제 진행 ex. 1월 31일 가입 → 2월 28일, 3월 31일 결제 4. 해지 정책- 사용자는 언제든지 마이페이지에서 해지 예약 가능- 해지 예약이 완료되면, 다음 정기 결제가 발생하지 않음 - 정기 결제일 하루 전까지 해지 예약 필요 - 해지 완료 전까지는 해지 예약은 철회 가능하며 다시 정기 결제 시작 가능 5. 환불 정책▪ 환불 가능- 결제 후 7일 이내 - 콘텐츠 및 혜택 미사용 시 전액 환불 ▪ 환불 불가 - 콘텐츠 이용 또는 7일 초과 시 - 일할 계산 후 환불 처리 ▪ 환불 수단 - 기본적으로 원 결제 수단 - 불가능할 경우 환불 계좌 수령 후 수기로 처리 6. 결제 실패 정책▪ 결제 실패 시, 결제 당일 3회 자동 재시도- 사용자에게 결제 실패 이메일 및 서비스 알림 발송 ▪ 실패 시 익일 00:00:00부터 구독해지 상태로 변경 - 사용자에게 구독 해지 이메일 및 서비스 알림 발송
▪ 마이페이지 → [구독정보]에서 다음 항목 확인/처리 가능 |
👉 STEP5 - 내부 공유 및 피드백
- CS팀 : 자주 묻는 질문, 불만 발생 지점 사전 확인
- 개발팀 : 정책 관련해서 개발 이슈 있는지 확인
- 법무팀 : 각종 법률 위반 소지 여부 검토
- 마케팅팀 : 무료 체험 시 유료 전환 조건 안내 방식
'PM 부트캠프' 카테고리의 다른 글
| [강의] 기존 서비스 역기획해보기! (1) | 2025.07.03 |
|---|---|
| 와이어 프레임을 기획해요~ (1) | 2025.07.03 |
| [PM 부트캠프 - 12일차 후기] 목표수립-문제정의-가설수립&검증 (6) | 2025.07.02 |
| 유저 리서치의 모든것 (5) | 2025.07.01 |
| [PM 부트캠프 - 11일차 후기] 서비스 기획을 입문해보자! (0) | 2025.06.30 |




