5/21 서비스 기획 입문

카테고리 없음

5/21 서비스 기획 입문

bbborang 2026. 5. 21. 11:00

주로

패션/미용/교육 도메인이랑 연계되어있다

로직트리
- 나무 구조처럼 하나의 큰 문제를 여러 가지 세부적인 나무가지로 분리한 후, 이를 다시 해결할 수 있는 구체적인 질문이나 하위 항목으로 나누는 방식입니다.

참고) https://brunch.co.kr/@thinkingschool/26

What-Why-How 로직트리로 기획의 틀을 짜라

기획초보를 위한 지금 당장 기획공부 시작하라 | 로직트리는 구성요소분해형(What 트리), 원인분석형(Why 트리)과 과제도출형(How 트리)으로 구분할 수 있다. What 트리로 구성요소를 분해하라 구성

brunch.co.kr

로직트리를 할때 지켜야하는 원칙이 하나 있습니다.
- 바로 MECE(Mutually Exclusive, Collectively Exhaustive)하게 쪼개야합니다.
- 로직 트리를 만들 때 MECE 원칙을 따르는 이유는 문제를 중복 없이 세분화하고, 동시에 누락 없이 모든 가능한 요소를 고려하기 위해서입니다.

Mutually Exclusive (상호 배타적)

- 각 요소는 서로 겹치지 않아야 합니다.

- 예시: "음식"이라는 범주에서 "한식"과 "중식"은 서로 겹치지 않는 분류입니다. 하나의 메뉴가 두 범주에 속할 수는 없습니다.

Collectively Exhaustive (전체 포괄적)

- 누락된 항목이 없도록 문제의 모든 측면을 다뤄야 합니다.

- 예시: "음식" 범주에서 "한식"과 "중식"만 있으면 "양식"이나 "일식"이 빠질 수 있으므로, 모든 가능한 카테고리를 포함해야 합니다.

현상발견 (여러가지 리뷰데이터를 통해)

-> 비슷한 문제들끼리 (ex. 추천에 관한 내용) 그룹핑하기

그 다음 단계로

사용자 입장에서 / 비즈니스 입장에서 생각해보기

그 다음 단계로

각각에 대한 원인을 분석

핵심문제 정의

그 다음으로

해결방안 가설 도출

문제의 우선순위를 판단하는 방법

Impact vs. Effort Matrix
- 높은 임팩트, 낮은 노력 (Quick Wins): 우선적으로 해결할 문제
- 높은 임팩트, 높은 노력 (Major Projects): 중요하지만 해결하는 데 시간이 많이 걸리는 문제
- 낮은 임팩트, 낮은 노력 (Fill-ins): 자투리 시간에 해결할 수 있는 문제
- 낮은 임팩트, 높은 노력 (Hard Slogs): 가급적 나중에 해결할 문제

" 프로덕트 백로그에 넣어둔다 "

-> 언젠간 해결해야될 문제 / 나중에 해결하려고 미뤄두는 프로젝트

문제 정의 때 주의해야할 것이 무엇인가요?

가장 많이 하는 실수는 문제 정의를 제대로 하기 전에 미리 ‘해결 방안’을 정해두고 시작한다는 것입니다
- 이미 해결 방안을 정해놓으면 문제 정의가 왜곡될 수 있고, 제대로 된 문제 해결로 이어지지 않을 수 있습니다
- 문제를 발견했을 때 있는 그대로 해석하고 바로 해결방안을 도출하는 게 아니라, 진짜 문제인지에 대해서 여러모로 정의해보는 것이 중요해요

고객 VOC : “사용자가 앱 내의 텍스트가 너무 작아서 읽기 어려워요”

❌ 해결방안을 미리 정해둔 PM
- “고객이 원하는대로 들어줘야지! 글씨 크기를 키우자!” 3단계. 가설수립 & 검증 ⭕ 문제정의부터 하는 PM
- “VOC의 원인부터 파악하자!”
  - “고객이 시니어인가? 다른 고객들도 그렇게 느끼는가?”
  - “해당 텍스트가 중요한 텍스트인가?”
  - “읽기 어려운게 진짜 크기가 작아서인가? 위치 때문인가? 색상 대비 때문인가?”

📖 숙제 설명

내가 설정한 프로덕트
프로덕트의 문제 현상
문제 현상의 영향 범위
문제 현상의 원인 (=문제정의)

가설수립 & 검증

뱅크샐러드 게시글 -> 실험의 중요성

참고사항) https://blog.banksalad.com/tech/birth-of-a-genuine-experiment-organization/

진정한 실험 조직의 탄생 | 뱅크샐러드

안녕하세요 뱅크샐러드 데이터 파운데이션의 실험 플랫폼 팀 Product Manager…

blog.banksalad.com

왜 ‘목표수립-문제정의-가설수립&검증’의 프레임워크가 필요한가요?

애자일의 핵심 원칙인 ‘점진적으로 개선하는 방식’과 일치합니다.
- 작은 가설을 세우고, 실험과 반복(Iteration)을 통해 실패하더라도 빠르게 실패하고, 성공 확률이 높은 쪽으로 방향성을 잡을 수 있어요.

데이터 기반의 의사결정으로 성공 확률을 높일 수 있습니다.
- 각 단계마다 감에 의존하지 않고 데이터를 활용하여 결정의 근거를 제시하므로, 객관적인 의사결정이 가능합니다.

1. 해결 방안 도출

핵심 문제정의가 끝나면, 이를 해결하기 위한 해결방안을 도출
물론, 이 해결방안은 아직 확정된 내용이 아니라, 검증되지 않은 가설
- 이것이 **가설 기반 사고 (Hypothesis-driven Thinking)**
해결방안이 구체화가 되면, 이 중에서 가장 실행가능한 아이디어를 우선순위화
- 이를 위해서도 문제정의와 마찬가지로 Impact vs. Effort Matrix를 사용해도 좋다.

가설을 어떻게 세우나요?

가설의 형태는 예상되는 인과 관계를 설명하는 문장입니다.
- 주로 "만약 ~하면, ~할 것이다" 형태가 가장 기본적이고 널리 사용됩니다.
문제를 해결하기 위해 어떤 변화가 필요할지, 그리고 그 변화가 어떻게 영향을 미칠지 예측합니다.
- 정성적이든, 정량적인 결과이든 반드시 검증이 가능해야합니다.
- 검증 가능하지 않은 가설은 가설이 아니에요.

항목	A/B 테스트	사용자 인터뷰	유저 테스트	오픈 후 결과 데이터 분석
설명	✔️두 가지 이상의 옵션을 비교해서 어떤 게 더 나은지 확인하는 방법	✔️사용자와 직접 대화하며 문제점과 니즈를 파악하는 방법	✔️사용자가 제품을 직접 써보고 피드백을 받는 방법	✔️기능 출시 후 사용자 데이터를 분석해서 문제를 찾는 방법
장점	✔️데이터로 명확한 비교 가능	✔️사용자의 숨겨진 니즈를 발견 ✔️새로운 아이디어 얻을 수 있음	✔️ 실제 사용 과정을 관찰 가능	✔️ 빠르고 비용이 적게 듦
단점	✔️ 많은 사용자가 필요 ✔️준비에 시간과 비용이 듦	✔️사용자 모집이 필요	✔️사용자 모집이 필요	✔️ 상황별 맥락은 알기 어려움
사용하기 좋은 상황	✔️두 가지 버전 중 어떤 게 더 좋은지 알고 싶을 때	✔️사용자가 무엇을 원하는지 알고 싶을 때- 초기 아이디어 검증이 필요할 때	✔️ 제품을 실제로 써보며 개선할 점을 찾고 싶을 때	✔️기능 출시 후 데이터로 성과를 확인하고 싶을 때

각 방법마다 장단점을 고려해서 선택합니다.
- A/B 테스트, 사용자 인터뷰, 유저 테스트 모두 좋은 방법이지만, 환경을 구축하는데에 시간과 비용이 소요됩니다.
- 예를 들면, A/B테스트가 정확히 이루어지기 위해서는 사용자 규모가 일정이상 필요합니다. 또, 사용자 인터뷰나 유저 테스트를 위해서는 사용자 리크루팅이 필요합니다.
- 오픈 후 결과 데이터 분석은 가장 빠르고 효율적이게 가설 검증을 진행할수 있습니다.

가설을 제대로 설정할 수 있는 "측정가능한 지표"

직접적인 지표를 선택
- 가설의 결과를 직접적으로 설명할 수 있어야 함. 가설 검증과 직접 관련이 없는 지표는 혼란을 초래할 수 있음.
상위 목표 (OKR)와 연결되어야 의미가 있음
- 비즈니스 목표나 사용자 만족도 향상과 연결되어야 함.
지표의 맥락을 이해
- 지표가 증가/감소할 때 왜 그런지 해석 가능한 맥락과 배경을 분석해야 함.
시간 범위를 정해야됨
- 데이터는 언제까지를 기준으로 볼지 범위를 정해야 함.

당시 가설은 토스는 혁신적인 브랜드이기 때문에 사람들이 좋아할 것이다 라고 가설을 세웠지만

막상 결과는 "편리해서 사용은 하나, 신뢰하지는 않는다" 라고함 -> 이렇게 가설이 틀릴 수도 있는거임

UT -> User Test (유저테스트)를 통해서 어떤걸 개선할지?

UX Researcher -> User Experience Researcher

시뻘건 부위 => 사람들이 많이 손을 댄 부위 => 사용자들이 어느부분에서 클릭을 많이 했는지 "시각화"

정책기획

PM은 기획 단계에서부터 정책의 존재 이유와 영향력을 이해하고 정책을 기획해야 함

팀의 ground rule

집에서는 가훈

조직내에서는 규칙

서비스 운영에 필요한 모든 규칙과 기준을 담은 안내서
사용자가 안전하고 효율적으로 서비스 이용하도록 안내하는 가이드라인
- ⚠️ 문제 발생 시, 어떤 기준으로 대응할지 명확히 해주는 기준점

1. 회원가입 정책

- 연령제한

- 지역제한

- 이용자격

2. 서비스 운영 정책

- 콘텐츠 가이드라인

- 저작권 정책

- 금지 행위 및 제재

- 동시 접속 제

3. 결제 정책

- 배송/반품/환불

- 결제

4. 개인정보 정책

- 개인정보 처리방침

잘 만든 정책 -> 서비스의 목적에 부합 / 사용자 경험을 해치지않고 / 법과 운영 현실 모두를 고려 / 리스크를 최소화한 결정

1) 서비스 방향성 제시

서비스 정책은 회사와 서비스가 지향하는 가치를 구체적으로 보여줌

2) UX의 일관성 확보

정책은 서비스 전체의 일관된 경험을 만들어줌 → "내가 이렇게 행동하면 어떤 결과가 나올까?"를 예측할 수 있음
반대로 정책이 없거나 불명확하면 → 사용자 혼란 😵 + 불만 증가 😡

3) 리스크 대응

일반적지 않은 악용 케이스(edge case)에 대한 대비가 필요함
- 📌 예: 가입/탈퇴 반복을 통한 이벤트 악용, 탈퇴 후 댓글 그대로 남아 피해 유발 등
정책이 있으면?→ 문제가 생겨도 신속하고 일관된 대응 가능
→ 사용자와 서비스 간의 공정한 기준 확보

약관 -> 법무팀에서 주로 쓰지만, PM도 함께 관여한다

PM도 약관만들때 같이 이야기를 하거나, 아니면 내가 뭔가 서비스를 개선할 때

이게 약관에 반영되어서 업데이트되어야 하진 않는지 -> 이런 부분을 체크하는 것도 PM의 역할!!!

4) 법적 준수

개인정보보호법, 전자상거래법, 청소년보호법 등 관련 법령을 준수
서비스 운영 시 반드시 따라야 할 법률들을 정책에 체계적으로 반영
위반 시? → 과징금, 서비스 중단 등 심각한 리스크 발생

ex) 앱 푸시 보내기 전에 알아야할 것

광고 -> 상품 혜택 / 신규제품안내 -> 마케팅 요소

예외 -> 예약정보 안내 / 서비스 보안 안내 / 고지 사항 안내 / 서비스 알림 정보

5) 운영과 기술 구현이 가능하다

현실적으로 개발과 운영이 가능한 수준이어야 하고, 고객센터(운영)가 감당할 수 있는 구조
예: “3개월 이상 미접속 회원에게 자동 이메일+SMS+앱푸시”는 너무 무거운 정책

6) 사용자 입장에서 이해 가능하다

누구나 읽었을 때 "내가 이 정책에서 어떤 영향을 받는구나"를 쉽게 알 수 있어야 함
전문 용어 남발, UX 흐름과 맞지 않는 문구 ❌

7) 일관성이 있고 예외가 적다

서비스 내 다른 정책들과 충돌되지 않아야 하며, 예외 상황이 자주 발생하지 않도록 설계되어야 함
예: 한쪽 정책에선 "재가입 가능", 다른 쪽에선 "재가입 불가"라면 사용자 혼란이 발생

서비스 정책 기획 과정

서비스 정책 기획, 어떻게 하나요?

왜 필요하지? -> 무엇을 고려해야하지? -> 어떻게 만들고 / 어떻게 실행하지?

Step 1. 정책의 목적 정의

정책이 무엇을 해결하기 위한 것인지, 왜 필요한지
예: “탈퇴 정책은 고객의 개인정보 보호 및 서비스 오남용 방지를 위한 것”처럼 목적이 구체적일수록 좋음

Step 2. 정책 설계 시 고려 요소 정리

① 외부 요인 (우리가 따라야하는 것)

법령 (개인정보보호법, 전자상거래법 등)
OS / 플랫폼 정책 (예: 애플 로그인 필수, 구글 심사 기준 등)
SNS 연동 기준 (카카오/네이버/애플 제공 정보 범위)

② 내부 요인 (우리 상황에 맞게 판단할 것)

기존 서비스 정책과의 충돌 여부
리스크 요소 (보안, 악용, 비용 등)
비즈니스 모델 연계 여부 (예: 탈퇴 시 구독 처리) </aside>

Step 3. 정책 구조 설계

어떤 정책 항목을 정할지 구조화하고, 항목별 기준을 정의
- 회원가입: 이메일 vs SNS, 정보 수집 범위
- 탈퇴: 바로 탈퇴 가능 여부, 정보 삭제 시점
- 게시물 처리: 탈퇴 후 유지 or 삭제
- 구독 상태: 탈퇴 전 해지 필요? 자동 해지?

Step 4. 정책 문서화

제목, 목적, 적용 범위, 상세 정책, 예외 처리 등 포함

Step 5. 내부 공유 및 피드백

법적 리스크나 운영상 문제 없는지 점검
이슈 발생 가능성에 대해 팀마다 의견 수렴

Step 6. 정책 공지 및 사용자 안내

사용자에게 투명하게 알리기 (약관/공지/팝업/이메일 등)
특히 기존 정책에서 변경사항이 있다면 꼭 사전 고지

Step 7. 정책 반영 및 운영 점검

개발 배포 일정과 맞춰 운영

서비스의 아이덴티티를 보여주는 정책!!!!!

예시. 정기구독 멤버십 정책

멤버십 정기구독 결제 정책을 기획

Step 1. 정책의 목적 정의

사용자에게 명확한 결제 기준을 제시
결제/해지 관련 CS 감소
유료 구독 매출을 안정적으로 확보 (=멤버십 결제 전환율 높이기)

Step 2. 정책 설계 시 고려 요소

① 외부 요인

법률
- 전자상거래법 : 환불 요청 가능 조건, 정기결제 해지 절차, 보존 기간 명시 필요
결제수단
- 앱스토어 정책 (Apple, Google) : 자체 결제가 아닌 인앱결제 시 환불 정책 제한 있음
- 결제 수단별 제약 : 카카오페이/휴대폰결제 시 일부 즉시 해지 불가 등

② 내부 요인

멤버십 상품
- 결제 금액 및 구독 기간은?
결제 수단
- 어떤 PG사랑 계약이 되었는지?
- 어떤 결제 방식 지원할 것인지?
포인트 및 쿠폰
- 포인트 적립 및 사용, 쿠폰 제도 도입할 것인지?
프로모션 연계
- 1개월 무료 프로모션 존재 여부?
- 이후 자동 유료 전환 시 고지 방식?

Step 3. 정책 구조 설계

항목	기준 예시
이용권 종류	스트리밍 전용 / 다운로드 포함 / 가족 이용권 등
결제 방식	앱스토어 인앱결제 / 카드 / 휴대폰 결제 등
자동결제 여부	기본 ON, 해지 시 다음 결제일부터 중단
환불정책	구매 후 7일 이내 + 미이용 시 환불 가능 (법적 기준)
해지정책	즉시해지 vs 만료일까지 사용 후 해지
해지 후 재가입	즉시 가능하나 할인 혜택은 제한됨
무료 체험 정책	무료 체험 1회 한정, 중복가입 불가

내부 공유 및 피드백

CS팀: 자주 묻는 질문, 불만 발생 지점 사전 확인
개발팀: 정책 관련해서 개발 이슈있는지 확인
법무팀: 각종 법률 위반 소지 여부 검토
마케팅팀: 무료 체험 시 유료 전환 조건 안내 방식 </aside>

PG사 (Payment Gateway)

-> 사업자가 신용카드 및 간편결제를 받을 수 있도록 결제 인프라를 제공하는 업체를 뜻

해결방법 -> 1안/2안 만들어놔

1안의 장점과 2안의 장점을 차용해서

-> 제3안을 만들 수도 있다

와이어프레임

웹사이트의 골격이나 애플리케이션의 사용자 인터페이스(UI) 및 핵심 기능을 나타내는 단순한 선과 도형으로 구성된 다이어그램

최근에는 ui/ux는 프로덕트 디자이너의 고유 영역으로 보지만, 조직/과제에 따라서 다름
- 예시
  - 우아한형제들 : pm이 와이어프레임을 그리지 않음
  - 카카오, 네이버 : pm이 와이어프레임을 키노트, PPT등으로 작업

PM이 왜 와이어프레임을 그려?

그리는 과정에 "기획이 구체화"

그리는 과정에서 사용자의 UX 흐름뿐 아니라, 백엔드 구조, API 조건, 데이터 흐름까지 고려하게 됨

팀의 커뮤니케이션의 도구

“이 화면 왜 이렇게 했어요?”
“이 유저는 여기서 이걸 하려 하고, 이걸 위해선 이 정보 흐름이 필요해서요”

와이어프레임 설계 시 주의점

PM이 와이어프레임을 그릴 때 주의점이 뭐야?

이쁜 디자인 보다, ‘정보 구조와 흐름’ 중심이 더 중요

색깔/폰트/아이콘부터 고민 X → 디자인은 디자이너에게

한 번에 완벽하게 하려고 함

와이어프레임은 어차피 수정하면서 발전
“잘 그리기”보다 “빨리 그리고 보면서 고치기”가 훨씬 중요

기능을 나열하는 것이 아니라 행동을 설계

모든 요소에 기획 의도가 있어야 함
“이 기능이 왜 여기 있지?”, “유저는 이걸 언제 써?”라는 질문을 끊임없이 던지기
사용자의 ‘손’과 ‘눈’이 동시에 행동하는 UX

와이어프레임의 설계 단계

Step 1. 화면의 목적을 정의한다

사용자의 목표행동을 정의하자（사용자가 여기서 어떤 행동을 하길 바라지?)

병목포인트(Bottleneck point)를 찾아서 제거하자 (사용자의 목표 행동을 가로막는게 뭘까?)

Step 2. 노출되어야 할 정보를 전부 나열 → 관련 있는 정보끼리 묶고, 우선순위에 따라서 배치

사용자에게 보여줘야 할 정보를 모두 나열

숙제 설명

📖

챕터 1에서 알려드린 기술블로그 중에서 위 수업 내용과 같이 문제정의~가설수립의 과정을 배울 수 있는 아티클을 선정해주세요.

그리고 해당 아티클을 아래와 같이 요약해서 정리해보세요.

문제발견
문제정의
가설수립
액션
검증결과
아티클에서 얻은 인사이트

큰회사일수록 -> 회사관련 내용을 좀 더 쉽게 리서치 가능!!!!!

"구좌"가 뭐지?

광고/마케팅 분야에서 사용하는 단어

전광판, 배너 등에서 광고가 노출되는 특정 자리나 공간을 의미합니다.

(예: 총 20개의 광고가 돌아가는 전광판의 경우 ‘20구좌’라고 표현)

현재글5/21 서비스 기획 입문

bbborang 님의 블로그

bbborang 님의 블로그 입니다.

Today :
Yesterday :

일	월	화	수	목	금	토
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

bbborang 님의 블로그