PM study

고객 세그먼테이션과 타겟팅 완벽 가이드 - 기획자가 꼭 알아야 할 STP 프레임워크와 페르소나 전략 총정리

pokeylog — Thu, 14 May 2026 10:46:03 +0900

기획자로 일하다 보면 가장 많이 받는 질문 중 하나가 "우리 서비스의 타겟이 누구야?"라는 말입니다. 저도 처음에는 이 질문에 자신 있게 답하지 못했습니다. "20~30대 여성"이라고 막연하게 답했다가 팀장님께 "그래서 그 안에서 누구를 먼저 잡을 건데?"라는 반문을 들었던 기억이 납니다. 그때부터 저는 세그먼테이션과 타겟팅을 제대로 공부하기 시작했습니다.

이 글은 고객 세그먼테이션(Customer Segmentation)과 타겟팅(Targeting)의 개념을 처음 접하는 주니어 기획자, PM, 서비스 기획자를 위해 작성되었습니다. 어려운 마케팅 용어를 쉬운 비유와 실제 사례로 풀어드릴 테니, 끝까지 읽고 나면 "우리 서비스의 타겟"을 자신 있게 정의할 수 있을 것입니다.

1. 왜 세그먼테이션이 필요한가? "모두를 위한 제품"의 함정

음식점을 하나 차린다고 상상해 보세요. 한식, 중식, 일식, 양식, 채식, 육식 — 모든 사람의 입맛을 맞추려다가는 결국 어느 한 쪽도 제대로 만족시키지 못하는 "그저 그런" 식당이 되고 맙니다. 서비스 기획도 마찬가지입니다.

"모두를 위한 제품"은 결국 "아무도 위하지 않는 제품"이 됩니다.

세그먼테이션(Segmentation)이란 전체 시장을 유사한 특성을 가진 소집단으로 나누는 과정입니다. 이 과정이 필요한 이유는 단순합니다. 기획·마케팅 자원(예산, 시간, 인력)은 항상 한정되어 있기 때문입니다. 한정된 자원을 분산하지 않고 가장 효과적인 고객 집단에 집중투자하기 위해서 세그먼테이션이 필요합니다.

저는 실무에서 이를 "낚시터 선택"에 자주 비유합니다. 바다 어디서나 낚싯대를 드리우는 것보다, 고기가 많이 모이는 포인트를 찾아 집중하는 것이 훨씬 효율적입니다. 세그먼테이션은 그 포인트를 찾는 작업입니다.

실제로 맥킨지(McKinsey) 연구에 따르면, 개인화·세그먼트 기반 마케팅을 실행한 기업은 그렇지 않은 기업 대비 매출이 평균 10~15% 높게 나타났습니다. 세그먼테이션은 이제 선택이 아닌 필수입니다.

2. 핵심 용어 한 번에 정리 — STP 프레임워크란?

세그먼테이션을 이해하려면 STP 프레임워크를 먼저 알아야 합니다. STP는 Segmentation(세분화) → Targeting(타겟팅) → Positioning(포지셔닝)의 세 단계로 구성된 전략 프레임워크입니다.

각 단계의 관계를 쉽게 설명하면 이렇습니다. 먼저 전체 시장을 의미 있는 단위로 나누고(S), 그 중 공략할 집단을 선택한 다음(T), 선택한 타겟의 마음속에 우리 브랜드가 어떤 의미인지를 심는(P) 순서입니다. 이 세 단계는 순서가 바뀌면 안 됩니다. 나누지 않고 선택할 수 없고, 선택하지 않고 포지셔닝할 수 없습니다.

아래 표에서 핵심 용어들을 한눈에 정리해 드리겠습니다.

용어	정의	핵심 포인트
시장 세분화 (Market Segmentation)	전체 시장을 유사한 특성을 가진 소집단으로 나누는 과정	"나누는 행위" 자체에 집중
세그먼트 (Segment)	세분화된 고객 집단	내부 동질성 ↑, 외부 이질성 ↑
타겟팅 (Targeting)	여러 세그먼트 중 공략할 집단을 선택하는 의사결정	"선택"의 행위, 집중의 시작
포지셔닝 (Positioning)	선택한 타겟의 인식 속에 브랜드를 자리잡게 하는 전략	"인식"에 집중, 메시지 차별화
페르소나 (Persona)	타겟 고객을 구체적 인물로 묘사한 가상의 고객상	공감을 위한 도구, S→T 이후 작성
니즈 (Needs)	고객이 충족하고자 하는 결핍 상태	표면 니즈 vs 심층 니즈 구분 필수

3. 세그먼테이션의 4가지 기준 — 어떻게 나눌 것인가?

시장을 나누는 방법에는 크게 4가지 기준이 있습니다. 각각의 특징과 활용 상황을 자세히 살펴보겠습니다.

① 인구통계학적 세분화 (Demographic Segmentation)

연령, 성별, 소득, 직업, 학력, 가족 구성 등 측정 가능한 인구 특성으로 고객을 구분하는 방법입니다. 가장 오래되고 널리 쓰이는 방식으로, 데이터 수집이 쉽고 측정 가능하다는 것이 장점입니다.

다만 같은 나이여도 라이프스타일이 전혀 다를 수 있다는 단점이 있습니다. 예를 들어 35세 남성이라도 스타트업 창업자와 대기업 부장은 제품에 대한 니즈가 완전히 다릅니다. 그래서 인구통계 세분화는 보통 다른 기준과 함께 사용됩니다.

활용 예시: 20대 여성 대학생 / 40대 기혼 직장인 남성 / 월 소득 500만 원 이상 고소득층

② 지리적 세분화 (Geographic Segmentation)

국가, 지역, 도시 규모, 기후 등 지리적 위치로 고객을 구분하는 방법입니다. 오프라인 비즈니스에서 특히 중요하며, 디지털 환경에서도 지역별 문화·규제 차이를 반영하는 데 활용됩니다. 글로벌 서비스를 기획할 때 로컬라이제이션 전략의 출발점이 되기도 합니다.

활용 예시: 서울 강남 vs 지방 중소도시 / 도심 vs 교외 / 동남아 시장 vs 유럽 시장

③ 심리통계학적 세분화 (Psychographic Segmentation)

라이프스타일, 가치관, 성격, 관심사, 태도로 고객을 구분하는 방법입니다. 저는 이 기준이 가장 어렵지만 가장 강력하다고 생각합니다. "왜 사는가?"라는 질문에 답하는 기준이기 때문입니다. 인구통계의 한계를 보완하며, 데이터 수집이 어렵지만 설명력이 높습니다.

활용 예시: 환경을 중시하는 친환경 소비자 / 가성비를 최우선으로 추구하는 실용적 소비자 / 프리미엄 브랜드를 선호하는 과시적 소비자

④ 행동적 세분화 (Behavioral Segmentation)

구매 행동, 사용 빈도, 브랜드 충성도, 구매 단계로 고객을 구분하는 방법입니다. 디지털 마케팅에서 가장 활용도가 높으며, 실제 행동 데이터 기반이기 때문에 신뢰도가 높습니다. RFM 분석(Recency, Frequency, Monetary)과 연결되어 e-커머스에서 특히 강력한 도구입니다.

활용 예시: 첫 구매 고객 / 90일 이상 미방문 휴면 고객 / 월 3회 이상 재구매하는 충성 VIP 고객

저는 실무에서 보통 인구통계(뼈대) + 심리통계(살) + 행동(근거) 세 가지를 결합해서 세그먼트를 정의합니다. 하나의 기준만으로는 너무 단편적이기 때문입니다.

4. 좋은 세그먼트의 조건 — MADS 프레임워크

세그먼트를 나눴다고 다 끝난 게 아닙니다. "이 세그먼트가 진짜 공략할 만한 가치가 있는가?"를 검증해야 합니다. 이때 사용하는 것이 MADS 프레임워크입니다.

첫째, Measurable(측정 가능성)입니다. 규모와 구매력을 수치로 확인할 수 있어야 합니다. "20대 여성 중 친환경 소비에 관심 있는 층"이라고 세그먼트를 정의했다면, 그 규모가 얼마나 되는지 데이터로 뒷받침할 수 있어야 합니다.

둘째, Accessible(접근 가능성)입니다. 마케팅 채널로 실제로 도달할 수 있어야 합니다. 아무리 좋은 세그먼트라도 우리가 접근할 수 없다면 의미가 없습니다.

셋째, Differentiable(차별 가능성)입니다. 다른 세그먼트와 구별되는 특성이 있어야 합니다. 세그먼트 간에 의미 있는 차이가 없다면 굳이 나눌 이유가 없습니다.

넷째, Substantial(수익 가능성)입니다. 충분한 규모와 수익성이 있어야 합니다. 너무 좁은 니치 시장은 수익을 창출하기 어렵습니다.

저도 실무에서 세그먼트를 정의하고 나면 이 네 가지 조건을 하나씩 체크하는 습관이 생겼습니다. 특히 "측정 가능성" 체크에서 많은 세그먼트 아이디어가 걸러집니다.

5. 타겟팅 전략 3가지 — 어떤 방식으로 공략할 것인가?

세그먼트를 정의했다면 다음 단계는 어떤 세그먼트를 어떤 방식으로 공략할지 결정하는 것입니다. 타겟팅 전략은 크게 3가지로 나뉩니다.

① 비차별화 전략 (Undifferentiated Marketing)

전체 시장을 하나로 보고 단일 마케팅 전략을 적용하는 방식입니다. 대량 생산·대량 마케팅 시대의 방식으로, 초기 코카콜라가 대표적인 예입니다. 규모의 경제를 활용할 수 있지만, 경쟁이 심화된 현대 시장에서는 점점 효과가 줄고 있습니다.

② 차별화 전략 (Differentiated Marketing)

여러 세그먼트를 선택하고 각각 다른 전략을 적용하는 방식입니다. 비용이 높지만 전체 시장 점유율 확대에 유리합니다. 삼성전자가 갤럭시 S(프리미엄) · A(중간) · Z(폴더블 혁신) 시리즈를 각각 다른 타겟에게 다른 메시지로 마케팅하는 것이 대표적인 예입니다.

③ 집중화 전략 (Concentrated/Niche Marketing)

하나의 세그먼트에 자원을 집중하는 방식입니다. 스타트업이나 중소기업에 특히 적합합니다. 다이슨이 고급 청소기 시장에 집중하거나, 발뮤다가 프리미엄 소형 가전 시장에만 집중하는 것이 좋은 예입니다. 자원이 제한된 초기 서비스라면 집중화 전략을 먼저 선택하고 점차 확장하는 것이 현명합니다.

제가 스타트업 기획자로 일할 때 저는 항상 집중화 전략을 먼저 추천합니다. "처음부터 모든 세그먼트를 잡으려다 아무것도 못 잡는" 실수를 너무 많이 봤기 때문입니다. 린 스타트업의 핵심도 결국 가장 중요한 세그먼트 하나에 집중하는 것입니다.

6. STP 실전 적용 예시 — 배달 앱 신규 서비스 기획 케이스

지금까지 배운 내용을 실제 서비스 기획에 적용해 보겠습니다. "1인 가구 건강식 구독 서비스"를 기획한다고 가정해 봅니다.

Step 1 — Segmentation (시장 세분화)

1인 가구 전체 시장을 인구통계 + 심리통계 + 행동 기준으로 나눠 보면, 20대 자취생(가성비 우선), 30대 직장인 건강 관심층(편의+영양 균형 추구), 40대 다이어트 목적 1인 가구(체중 관리+식단 관리 필요), 50대 이상 혼밥족(건강+외로움 해소) 등으로 나눌 수 있습니다.

Step 2 — Targeting (타겟 선택)

MADS 기준으로 검토하면, 30대 직장인 건강 관심층이 가장 유력한 타겟입니다. 규모(측정 가능), SNS·검색 광고로 접근 가능(접근 가능), 가성비형 20대와 분명히 구별(차별 가능), 월 5~10만 원 구독 의향이 있는 충분한 구매력(수익 가능)을 갖추고 있습니다.

Step 3 — Positioning (포지셔닝)

선택된 타겟에게 "바쁜 직장인도 매일 건강하게"라는 메시지를 심습니다. 단순 배달이 아닌 "내 몸에 맞는 식단을 알아서 챙겨주는 서비스"로 포지셔닝합니다.

이 과정을 거치면 제품 기능, UI/UX, 가격 정책, 마케팅 메시지까지 일관된 방향을 갖게 됩니다. STP가 단순한 마케팅 이론이 아니라 서비스 전략의 나침반이 되는 이유입니다.

7. 페르소나(Persona) 작성법 — 타겟을 사람으로 만들기

타겟팅이 완료된 후에는 추상적인 세그먼트를 구체적인 사람으로 묘사하는 작업이 필요합니다. 이것이 바로 페르소나(Persona)입니다. 페르소나는 "공감을 위한 도구"입니다. 개발자, 디자이너, 마케터 모두가 같은 "사람"을 상상하면서 일할 수 있게 해줍니다.

좋은 페르소나에는 다음 요소가 포함됩니다. 이름과 나이, 직업과 소득, 하루 일과(Life Routine), 핵심 니즈와 불편함(Pain Points), 서비스를 사용하는 상황(Use Case), 그리고 의사결정 시 중요하게 생각하는 가치(Decision Driver)가 있어야 합니다.

예를 들어 앞서 기획한 건강식 구독 서비스의 페르소나라면 이렇게 만들 수 있습니다. "이지은, 32세, 서울 마포구 거주, IT 스타트업 마케터, 월 소득 350만 원. 아침 7시 출근, 밤 9시 퇴근. 점심은 회사 근처 편의점이나 배달로 때움. 운동을 시작했지만 식단 관리는 엄두를 못 냄. 인스타그램에서 건강식 콘텐츠를 즐겨 봄. 월 7만 원 이하라면 구독 서비스를 써보고 싶다."

페르소나를 이렇게 구체적으로 만들면, "이지은이라면 이 기능이 필요할까?"라는 식으로 의사결정의 기준점이 생깁니다. 저도 신규 서비스를 기획할 때 팀원들과 함께 페르소나를 만들고 사무실 벽에 붙여두는 방식을 자주 사용합니다. 기획 방향이 흔들릴 때마다 페르소나를 다시 보면 답이 보이는 경우가 많습니다.

8. 세그먼테이션 실무에서 자주 하는 실수 5가지

주니어 기획자들이 세그먼테이션 작업에서 자주 저지르는 실수들을 정리해 드립니다. 저도 처음에 다 경험했던 실수들입니다.

실수 1. 세그먼트를 너무 넓게 정의한다
"20~40대 여성"처럼 광범위한 정의는 세그먼테이션이 아닙니다. 내부적으로 동질적이고 외부적으로 이질적이어야 진정한 세그먼트입니다.

실수 2. 데이터 없이 감으로만 나눈다
세그먼트는 반드시 데이터로 뒷받침되어야 합니다. 사용자 인터뷰, 설문조사, 행동 데이터 중 최소 하나는 있어야 합니다. 관련해서 리서치 설계와 가설 수립 완벽 가이드를 함께 읽어보시면 도움이 됩니다.

실수 3. 세그먼트 수를 너무 많이 만든다
세그먼트가 10개가 넘어가면 오히려 의사결정이 어려워집니다. 초기에는 3~5개 수준으로 핵심 세그먼트만 정의하는 것이 좋습니다.

실수 4. 타겟팅을 빠뜨린다
세그먼테이션 후 "우리는 모든 세그먼트를 공략합니다"라고 하면 타겟팅을 한 게 아닙니다. 반드시 우선순위 세그먼트를 선택해야 합니다.

실수 5. 페르소나와 세그먼트를 혼동한다
세그먼트는 고객 집단이고, 페르소나는 그 집단을 대표하는 가상의 인물입니다. 세그먼트를 먼저 정의하고, 그 후에 페르소나를 만드는 순서를 지켜야 합니다.

9. 관련 글 더 읽기 — 서비스기획개론 시리즈

고객 세그먼테이션을 제대로 활용하려면 리서치 역량과 시장 분석 역량이 함께 갖춰져야 합니다. 아래 글들을 함께 읽으시면 훨씬 큰 시너지를 얻으실 수 있습니다.

마무리 — 세그먼테이션은 "선택과 집중"의 기술

오늘 살펴본 고객 세그먼테이션과 타겟팅은 단순한 마케팅 이론이 아닙니다. 서비스 기획의 모든 의사결정 — 기능 우선순위, UI/UX, 가격 정책, 마케팅 채널 — 의 기반이 됩니다.

제가 주니어 기획자 시절 가장 크게 성장한 순간 중 하나가 바로 "우리 타겟이 이 기능을 원할까?"라는 질문을 스스로 던질 수 있게 되었을 때였습니다. 그 질문의 시작이 바로 세그먼테이션과 타겟팅 역량입니다.

처음에는 어색하더라도, 다음 기획 작업에서 STP 프레임워크를 한 번 적용해 보세요. "우리 서비스의 타겟"이 훨씬 선명하게 보이기 시작할 것입니다.

더 궁금한 점이 있으시면 댓글로 남겨주세요. 저도 배우는 중이라 함께 이야기 나누고 싶습니다!

참고: Philip Kotler, Marketing Management / McKinsey & Company — The value of getting personalization right / 한국마케팅협회(KMA)

AI 시대 PM과 기획자가 반드시 알아야 할 핵심 역량 완벽 가이드

pokeylog — Wed, 13 May 2026 08:00:34 +0900

Photo by Samsung Memory on Unsplash

저는 처음 기획자로 일을 시작했을 때, AI라는 단어가 그저 먼 미래의 이야기처럼 느껴졌습니다. 하지만 2022년 말 ChatGPT의 등장 이후, AI는 더 이상 '나중에 공부해야 할 것'이 아닌 '지금 당장 이해해야 할 핵심 역량'이 되었습니다. 오늘은 원티드에서 발행된 아티클 "AI를 다룬다: PM/PO가 새롭게 익혀야 할 것들"을 깊이 파고들며, 기획자와 PM이 AI 시대에 갖춰야 할 진짜 역량을 풀어보겠습니다.

이 글은 단순히 아티클 요약에 그치지 않습니다. 저도 실무에서 AI 기능을 기획하면서 겪은 시행착오를 바탕으로, 초보 기획자도 쉽게 이해할 수 있도록 비유와 예시를 풍부하게 담았습니다. 끝까지 읽으시면 AI 프로덕트 기획의 흐름이 한눈에 정리될 것입니다.

1. 왜 PM·기획자는 AI를 '직접' 이해해야 하는가

많은 주니어 기획자들이 이런 질문을 합니다. "AI는 개발자가 알면 되는 거 아닌가요?" 저도 처음에는 그렇게 생각했습니다. 하지만 현실은 전혀 다릅니다.

AI 기반 프로덕트에서 PM/PO는 단순한 중간 전달자가 아닙니다. 알고리듬이 달성해야 할 목표(Objective)를 정의하는 사람이 바로 PM/PO입니다. 목표를 잘못 설정하면 아무리 뛰어난 개발팀도 엉뚱한 결과물을 만들 수밖에 없습니다.

예를 들어봅시다. 넷플릭스의 추천 알고리듬 목표가 단순히 "클릭 수를 늘려라"라고 설정되어 있다면 어떻게 될까요? 자극적이고 낚시성 제목의 콘텐츠만 추천하게 됩니다. 실제로 넷플릭스는 이 문제를 인식하고 "시청 완료율"과 "재구독률"을 함께 고려하는 복합 목표로 전환했습니다. 이런 결정을 내리는 사람이 바로 PM입니다.

2022년 말부터 시작된 AI 기술 혁명은 이미 우리 생활 곳곳에 스며들었습니다. 유튜브 영상 추천 순서, 스마트폰 키보드의 다음 단어 예측, 은행의 신용 대출 알고리듬까지 모두 AI의 힘을 빌리고 있습니다. 이런 시대에 PM이 AI를 모른다는 것은, 자동차 회사의 기획자가 엔진 원리를 전혀 모르는 것과 마찬가지입니다.

2. AI의 3가지 핵심 구성요소: 목표, 알고리듬, 데이터

원티드 아티클에서 가장 인상 깊었던 부분이 바로 이 섹션입니다. AI 프로덕트를 구성하는 3가지 요소를 PM 관점에서 명확하게 정리했습니다. 저는 이것을 '자동차 비유'로 이해했습니다.

목표(Objective): 자동차가 가야 할 목적지 (내비게이션 목적지 설정)
알고리듬(Algorithm): 자동차 엔진과 변속기 (어떻게 움직일지 결정)
데이터(Data): 연료 (데이터가 없으면 AI는 한 발짝도 못 나감)

이 세 가지가 서로 맞물려야 비로소 AI 프로덕트가 제대로 작동합니다. 하나라도 빠지면 자동차는 목적지에 도달하지 못합니다.

목표 설정의 함정: 단순화의 위험성

목표를 너무 단순하게 설정하면 예상치 못한 부작용이 생깁니다. 소셜미디어 플랫폼들이 초기에 "좋아요 수 극대화"를 목표로 설정했을 때, 결과적으로 자극적이고 편향된 콘텐츠가 피드를 가득 채우는 '필터 버블' 현상이 발생했습니다. 이제 대부분의 플랫폼은 단일 지표가 아닌 복합 목표(Multi-objective Optimization)를 사용합니다.

PM이라면 항상 이 질문을 던져야 합니다: "이 목표를 달성했을 때, 의도하지 않은 부작용은 없는가?"

3. 머신러닝 알고리듬 3가지 유형과 기획자의 역할

기획자가 알고리듬을 구현할 필요는 없습니다. 하지만 어떤 알고리듬이 어떤 문제를 푸는지는 알아야 합니다. 마치 의사가 모든 약의 화학 성분을 알 필요는 없지만 어떤 약이 어떤 증상에 효과적인지는 알아야 하는 것처럼요.

알고리듬 유형	핵심 원리	대표 사례	PM 관여 포인트
지도 학습 (Supervised Learning)	정답이 있는 데이터로 학습 분류·예측 문제	스팸 필터, 신용 평가, 이미지 분류	레이블 기준 정의, 오분류 허용 기준 설정
비지도 학습 (Unsupervised Learning)	정답 없이 패턴 발견 군집화·이상 탐지	넷플릭스 추천, 아마존 상품 추천	추천 다양성 vs 정확도 트레이드오프 결정
강화 학습 (Reinforcement Learning)	시행착오로 최적 행동 학습 보상 극대화	알파고, 자율주행, 게임 AI	보상 함수 설계, 안전 제약 조건 설정

저는 처음 추천 시스템 기획을 맡았을 때 "비지도 학습을 쓰면 되겠다"라고 단순하게 생각했습니다. 하지만 실제로는 콜드 스타트 문제(신규 사용자에게 추천할 데이터가 없는 문제), 인기 편향(인기 있는 아이템만 추천하는 문제) 등 복잡한 고려사항들이 있었습니다. 알고리듬 유형을 이해하니 개발팀과의 커뮤니케이션이 훨씬 수월해졌습니다.

4. 피쳐(Feature)와 제약 조건(Constraint): PM이 직접 설계하는 영역

여기서부터가 진짜 PM의 역할입니다. 알고리듬의 성능을 좌우하는 두 가지 요소, 피쳐와 제약 조건은 PM이 주도적으로 설계해야 합니다.

피쳐(Feature): 알고리듬이 학습하는 변수

피쳐는 알고리듬이 패턴을 찾기 위해 참고하는 입력 변수입니다. 쿠팡 검색 알고리듬의 피쳐 예시를 들면:

상품 가격 (절대값, 카테고리 내 상대적 순위)
배송 시간 (로켓배송 여부)
리뷰 수 및 평균 평점
사용자의 최근 구매 이력
시즌 및 트렌드 데이터

PM은 "어떤 피쳐가 사용자 행동에 가장 큰 영향을 미치는가"를 데이터 기반으로 판단하고 우선순위를 정해야 합니다.

제약 조건(Constraint): 알고리듬에 걸어두는 규칙

제약 조건은 알고리듬이 절대 넘어서면 안 되는 경계선입니다. 건강 식단 추천 앱을 예로 들면:

채식주의자에게 육류 추천 금지
고혈압 사용자에게 나트륨 높은 음식 필터링
알레르기 성분 포함 식품 자동 제외

이런 제약 조건이 없으면 알고리듬은 성능 극대화만 추구하다가 사용자에게 해가 되는 결과를 낼 수 있습니다. PM이 도덕적·법적·비즈니스 관점에서 이 경계선을 설정해야 합니다.

실제 계산 예시: 인스타그램 피드 관련성 점수

간단한 예시로 관련성 점수를 계산해봅시다. 인스타그램 피드 알고리듬이 특정 게시물의 노출 점수를 계산한다고 가정합니다:

관련성 점수 = (팔로우 친밀도 × 0.4) + (콘텐츠 관심사 매칭 × 0.3) 
            + (최신성 점수 × 0.2) + (상호작용 이력 × 0.1)

예시:
- 팔로우 친밀도: 0.8 (최근 댓글, 좋아요 기록 있음) → 0.8 × 0.4 = 0.32
- 콘텐츠 관심사 매칭: 0.9 (사용자가 자주 보는 카테고리) → 0.9 × 0.3 = 0.27
- 최신성 점수: 0.7 (3시간 전 게시) → 0.7 × 0.2 = 0.14
- 상호작용 이력: 0.6 (과거 댓글 2회) → 0.6 × 0.1 = 0.06

최종 점수: 0.32 + 0.27 + 0.14 + 0.06 = 0.79 / 1.0

이 가중치(0.4, 0.3, 0.2, 0.1)를 결정하는 것이 바로 PM의 역할입니다. "우리 서비스에서 가장 중요한 것은 무엇인가?"라는 질문에 대한 답이 이 숫자들에 담겨 있습니다.

5. PM의 올바른 AI 목표 설정을 위한 2가지 핵심 질문

아티클에서 가장 실용적으로 느껴진 부분입니다. 저도 실무에서 이 두 가지 질문을 습관처럼 던지게 되었습니다.

질문 1: "장기적으로 무엇을 달성하고자 하는가?"

단기 지표와 장기 목표를 혼동하지 않는 것이 핵심입니다. 쿠팡을 예시로 생각해보면:

단기 지표: 일일 클릭 수, 페이지뷰
중기 목표: 구매 전환율, 평균 주문 금액
장기 목표: 반품 없는 만족도 높은 구매, 로켓와우 멤버십 유지율

단기 지표만 최적화하면 반품이 많은 저품질 상품이 상위 노출될 수 있습니다. PM은 항상 장기적 사용자 가치를 기준으로 목표를 설정해야 합니다.

질문 2: "목표 달성 시 의도하지 않은 부작용은 없는가?"

이 질문이 없으면 좋은 의도로 만든 알고리듬이 사회적 해악을 낳을 수 있습니다. 소셜미디어의 '바이럴 최대화' 목표가 가짜 뉴스 확산을 촉진한 것이 대표적인 사례입니다.

제가 실무에서 직접 경험한 사례를 하나 공유하겠습니다. 저는 콘텐츠 플랫폼에서 "체류 시간 극대화"를 목표로 알고리듬을 설정한 적이 있었습니다. 결과적으로 KPI는 달성했지만, 사용자들이 원하지 않는 콘텐츠에 묶여 있는 시간이 늘어났고, 장기적으로 피로도가 높아져 이탈률이 증가하는 문제가 생겼습니다. 그때부터 저는 체류 시간뿐만 아니라 '자발적 재방문율'을 함께 모니터링하게 되었습니다.

6. AI 시대 PM/기획자의 실전 학습 로드맵

마지막으로 이 아티클이 제안하는 학습 방법과 저의 경험을 결합한 실전 로드맵을 정리해드립니다.

Step 1: 생활 속 AI 관찰 훈련 (2주)

매일 사용하는 서비스(유튜브, 네이버, 카카오톡 등)에서 AI가 작동하는 순간을 의식적으로 포착하세요. "이 추천의 목표는 뭘까? 어떤 피쳐를 쓸까? 어떤 데이터가 필요할까?" 이 세 가지 질문을 습관화하는 것이 첫 번째 단계입니다.

Step 2: 기초 개념 학습 (1개월)

구글의 Machine Learning Crash Course는 무료로 제공되는 최고의 입문 과정입니다. 코딩 없이도 머신러닝의 핵심 개념을 이해할 수 있습니다. 국내에서는 부스트코스 AI 기초도 훌륭한 선택입니다.

Step 3: 데이터 리터러시 강화 (2개월)

SQL 기본기는 PM에게 필수가 되고 있습니다. 데이터를 직접 뽑아볼 수 있어야 알고리듬의 성과를 제대로 평가할 수 있기 때문입니다. Google Analytics 4, Amplitude 등 분석 툴을 실제 서비스에 적용해보며 감각을 키우세요.

Step 4: AI 윤리와 규제 이해 (지속)

EU의 AI Act를 비롯해 각국의 AI 규제가 빠르게 만들어지고 있습니다. PM은 기술적 가능성뿐만 아니라 규제 환경도 이해해야 합니다. 특히 개인정보보호, 알고리듬 투명성, 차별 금지 원칙은 지금 당장 공부해야 할 영역입니다.

마치며: AI를 '다루는' 기획자가 되어야 하는 이유

아티클의 제목 "AI를 다룬다"에는 중요한 의미가 담겨 있습니다. 단순히 AI를 '사용'하는 것이 아니라, 목적에 맞게 '설계하고 운영'하는 주체가 되어야 한다는 뜻입니다.

AI에 놀라고 흉내 내는 것만으로는 시장에서 이기는 제품을 만들 수 없습니다. PM/PO는 AI의 3가지 구성요소(목표, 알고리듬, 데이터)를 이해하고, 피쳐와 제약 조건을 설계하며, 올바른 목표를 반복적으로 검증하는 역할을 해야 합니다.

저는 이 아티클을 읽으면서 "기획자는 AI를 두려워할 필요가 없다"는 것을 다시 한번 느꼈습니다. AI는 도구입니다. 그 도구를 어떤 목적으로, 어떤 방식으로 사용할지 결정하는 것은 여전히 사람인 PM/기획자의 몫입니다.

빠르게 변화하는 시대에 새로운 기술을 두려워하기보다 적극적으로 이해하고 활용하는 자세. 그것이 AI 시대를 살아가는 기획자에게 가장 필요한 마인드셋이 아닐까요?

참고 자료

토스 UX 라이팅 분석 PM과 기획자가 알아야 할 보이스톤 설계의 본질

pokeylog — Tue, 12 May 2026 08:00:24 +0900

Photo by Kelly Sikkema on Unsplash

앱을 열었을 때 "송금이 완료됐어요"라는 문구가 있고, 다른 앱은 "이체가 처리되었습니다"라고 한다면, 어떤 문구가 더 자연스럽게 느껴지나요?

나는 UX 라이팅 때문에 앱에 대한 인상이 바뀐 순간을 기억한다. 어느 앱의 온보딩 화면에서 예상치 못하게 기발하고 독특한 문구를 마주했을 때, 나도 모르게 웃음이 나오면서 그 서비스에 대한 인식이 훨씬 좋아졌다. "이 팀은 진짜로 사용자를 생각하고 있구나"라는 감정이 자연스럽게 생겼다. 말 한마디로 천냥 빚을 갚는다는 속담처럼, UX 라이팅 하나가 브랜드에 대한 전반적인 인식을 바꿀 수 있다는 걸 그때 실감했습니다.

토스는 금융 앱이지만 유독 '말'이 친근합니다. 이 친근함은 우연이 아닙니다. 토스는 앱 안의 모든 문구에 일관된 원칙을 적용합니다. 이 글은 토스의 공식 UX 라이팅 가이드를 PM·기획자 관점에서 분석하고, Google이 제안하는 AOE(Anatomy of an Experience)와 GOE(Grammar of an Experience) 관점으로 재해석한 내용을 담고 있습니다.

Google AOE / GOE란?

글을 본격적으로 읽기 전에 두 가지 프레임워크를 짧게 짚고 넘어가겠습니다.

AOE(Anatomy of an Experience)는 사용자 경험을 구성하는 요소들을 해부하는 관점입니다. 화면 안의 타이틀, 본문, 버튼 레이블, 에러 메시지 등 각 UI 텍스트가 '어떤 역할'을 하는지, 그리고 그것들이 전체 경험 안에서 어떻게 연결되는지를 봅니다.

GOE(Grammar of an Experience)는 경험의 문법, 즉 텍스트가 따라야 할 일관된 규칙 체계입니다. 말투(톤앤매너), 문장 구조, 단어 선택 기준이 여기에 해당합니다. GOE가 잘 정의된 제품일수록 어떤 화면에서든 "이 제품다운" 언어를 유지합니다.

토스의 UX 라이팅 가이드는 사실상 GOE를 명문화한 문서입니다. 그리고 각 원칙은 AOE의 각 구성 요소(에러 메시지, 버튼, 안내 문구 등)에 적용됩니다.

원칙 1. 해요체 — GOE의 기초, 일관성

토스는 앱 안의 모든 문구에 해요체를 씁니다. 상황·맥락 무관하게 예외 없이 적용됩니다.

GOE 관점에서 이것은 매우 중요한 결정입니다. 문체의 일관성이 깨지는 순간, 사용자는 무의식적으로 "이 제품이 나에게 다르게 말하고 있다"는 이질감을 느낍니다. 특히 금융 서비스처럼 신뢰가 중요한 영역에서는 이 이질감이 불안으로 연결될 수 있습니다.

PM/기획자 체크포인트
신규 기능을 기획할 때 기존 문구의 말투를 먼저 확인하세요.
아무리 좋은 기능도 말투가 튀면 전체 경험이 흔들립니다.

원칙 2. 능동적 말하기 — AOE에서 '행동'을 설계하다

토스는 수동형 표현을 최소화합니다. 세 가지 방법을 씁니다.

'됐어요' → '했어요': "송금이 완료됐어요" → "송금했어요"
'~었' 빼기: "연결되었어요" → "연결됐어요" → "연결해요"
동사 바꿔쓰기: 상태를 설명하는 대신 행동을 전달

AOE 관점에서 보면 이 원칙은 화면의 행동 유도 지점(CTA)과 직결됩니다. 수동형 문장은 사용자가 결과를 받아들이는 느낌을 주고, 능동형 문장은 사용자가 무언가를 해냈다는 느낌을 줍니다. UX에서 이 차이는 전환율과 만족도에 영향을 미칩니다.

PM/기획자 체크포인트: 완료 화면, 성공 메시지의 문구를 점검하세요. "처리되었습니다"가 아닌 "보냈어요"가 맞습니다.

원칙 3. 긍정적 말하기 — 에러조차 경험으로 만드는 법

토스는 "안 돼요", "없어요" 대신 "~하면 할 수 있어요" 형태로 씁니다. 에러 메시지도 예외가 아닙니다.

특히 주목할 만한 원칙이 있습니다. 다이얼로그의 왼쪽 버튼은 항상 '닫기'입니다. '취소'라는 단어는 사용자가 진행 중인 작업 자체가 취소된다고 오해할 수 있기 때문입니다. 이것은 AOE에서 버튼 레이블의 역할을 얼마나 정밀하게 설계했는지를 보여주는 대표적인 사례입니다.

혜택 대상 안내 문구에서도 마찬가지입니다. 특정 혜택을 받을 수 없는 사용자에게도 "이 혜택은 받을 수 없어요"가 아니라 "다른 혜택을 받을 수 있어요"처럼 긍정형으로 표현합니다. 사용자가 화면을 빠르게 스캔할 때 부정형 문장은 "서비스 전체를 쓸 수 없다"고 오해하게 만들 수 있기 때문입니다.

PM/기획자 체크포인트: 에러 메시지, 제한 안내 문구를 전수 검토하세요. 부정형 문장 하나가 사용자 이탈의 원인이 될 수 있습니다.

원칙 4. 캐주얼한 경어 — 브랜드 페르소나를 텍스트로 구현하기

"~시겠어요?", "~께"와 같은 과도한 경어를 피하고 친근한 말투를 씁니다. 구체적으로는 이렇습니다.

'~시' 빼기: "어떻게 도와드릴까요?" → "무엇을 도와드릴까요?"
'계시다' → '있다'
'여쭤보다' → '확인하다, 묻다'
'께' → '에게'

GOE 관점에서 이것은 브랜드 페르소나를 언어로 구현하는 방식입니다. 토스가 지향하는 페르소나는 "격식 있는 은행원"이 아니라 "똑똑하고 친근한 금융 친구"입니다. 과도한 경어는 오히려 이 페르소나를 흐트러뜨립니다.

단, 사용자 정보를 받는 질문에서 기계적으로 '~시'를 빼면 어색해질 수 있습니다. 이럴 때 토스는 파악하고 싶은 정보를 '주어'로 써서 문장을 재구성합니다. 예를 들어 "직업이 어떻게 되세요?" → "직업이 뭐예요?"처럼요.

PM/기획자 체크포인트: 온보딩 질문, 정보 입력 화면에서 어색한 경어 표현을 찾아보세요. 단순히 '~시'를 빼는 것보다 문장 구조 자체를 재설계하는 것이 더 자연스럽습니다.

원칙 5. 명사+명사 쓰지 않기 — 언어의 온도를 높이는 방법

한자어 명사를 동사 형태로 풀어씁니다.

"계좌 연결" → "계좌를 연결해요"
풀기 어려운 경우: '{명사}가 {명사}해서' 형태로 캐주얼하게

GOE 관점에서 이 원칙은 언어의 온도와 관련됩니다. 명사+명사 조합은 공문서, 매뉴얼에서 주로 쓰이는 방식이며 차갑고 딱딱한 느낌을 줍니다. 이를 풀어쓰면 문장에 온도가 생기고 사용자가 읽기 편해집니다.

PM/기획자 체크포인트: 기능명, 섹션 타이틀에 명사+명사 조합이 많지 않은지 살펴보세요. 특히 신규 기능의 이름을 지을 때 이 원칙을 적용하면 더 직관적인 네이밍이 가능합니다.

실무에서 가장 놓치기 쉬운 것 — 온보딩 문구

토스의 5가지 원칙 중 실무에서 가장 놓치기 쉬운 것은 단연 온보딩 문구입니다. 온보딩은 사용자가 서비스를 처음 만나는 순간이기 때문에, 이 시점의 UX 라이팅이 사용자의 리텐션과 브랜드 선호도에 직접적인 영향을 미칩니다.

흥미로운 점은 UX 라이팅의 품질이 비단 사용자에게만 영향을 미치는 것이 아니라는 점입니다. 세심하고 일관된 언어로 설계된 제품을 만드는 팀은, 업계 안에서 "일 잘하는 팀"으로 인식됩니다. UX 라이팅을 잘 하면 사용자 경험이 좋아지는 것은 물론, 그 제품을 만든 기획자와 PM 개인의 역량에 대한 인식도 함께 높아집니다.

PM·기획자를 위한 실천 요약

토스의 UX 라이팅은 단순히 "예쁜 말 쓰기"가 아닙니다. GOE(경험의 문법)를 명문화하고, AOE(경험의 해부) 각 지점에 일관되게 적용하는 시스템적 접근입니다.

해요체 — GOE의 기초. 말투 통일이 신뢰를 만든다.
능동적 말하기 — 완료/성공 지점에서 사용자의 행동감을 살린다.
긍정적 말하기 — 에러와 제한조차 긍정형으로 재설계한다.
캐주얼한 경어 — 브랜드 페르소나를 언어로 구현한다.
명사 풀어쓰기 — 문장에 온도를 더한다.

말 한마디로 천냥 빚을 갚듯, UX 라이팅은 사용자에게 어떤 인식을 줄 수 있는지, 어떻게 긍정적인 반응을 이끌어낼 수 있는지를 결정하는 강력한 도구입니다. 토스의 브랜드 분석과 UX 라이팅을 공부하면서 더 성장하는 기획자가 되기 위한 노력, 오늘부터 시작해보세요.

리서치 인사이트 도출과 종합 완벽 가이드 — 기획자가 꼭 알아야 할 Fact·Finding·Insight 구분부터 HMW까지 총정리

pokeylog — Mon, 11 May 2026 08:00:59 +0900

Photo by

Luke Chesser

Unsplash

기획자에게 리서치는 단순히 데이터를 모으는 행위가 아닙니다. 수많은 인터뷰 결과물, 설문 응답, 관찰 기록들을 들여다보며 "그래서 우리는 무엇을 해야 하는가"를 뽑아내는 과정이 바로 인사이트 도출입니다. 저도 보고서를 처음 작성할 때 인터뷰 내용을 정리하면서 핵심보다는 발언 전체를 나열하는 식으로 요약해서, 상사로부터 "더 핵심 위주로 정리하라"는 피드백을 받은 적이 있습니다. 그 경험이 Fact와 Insight의 차이를 뼈저리게 깨닫게 해준 계기가 되었습니다.

이 글에서는 리서치 인사이트 도출 전 과정을 기획자 입장에서 풀어봅니다. Fact·Finding·Insight 구분, 어피니티 다이어그램, HMW 기법, 트라이앵귤레이션까지 — 이론과 실전 예시를 함께 담았으니 처음 리서치를 접하는 주니어 기획자에게도 도움이 되실 겁니다.

1. 인사이트란 무엇인가 — Fact, Finding, Insight의 차이

많은 기획자들이 리서치 결과물을 정리할 때 Fact, Finding, Insight를 혼동합니다. 저는 처음 보고서를 작성할 때 인터뷰 발언을 그대로 옮겨놓고 그것이 인사이트라고 생각했습니다. 하지만 그건 Fact에 불과했습니다. 핵심 위주로 요약하라는 피드백을 받고 나서야 이 세 개념의 층위 차이를 이해하게 되었습니다.

인사이트(Insight)는 데이터에서 발견한 의미 있는 패턴으로, 행동이나 결정을 이끌어낼 수 있는 발견입니다. 단순한 사실의 기록이 아니라, 그 사실이 왜 일어났는지, 사용자에게 무엇을 의미하는지를 설명하는 문장이어야 합니다.

마치 형사물에 비유하자면, Fact는 "현장에 발자국이 있었다"이고, Finding은 "발자국의 패턴이 용의자의 신발 사이즈와 일치한다"이며, Insight는 "용의자가 사전에 현장을 답사했을 가능성이 높다 — 이는 계획 범행을 시사한다"입니다. 인사이트는 결론을 향해 한 발짝 더 나아간 문장입니다.

Fact / Finding / Insight 비교표

수준	정의	예시
Fact	관찰된 사실의 기록	"응답자의 54%가 추천 기능에 불만족했다"
Finding	여러 Fact에서 발견된 패턴	"추천 불만족자는 이탈 의향도 함께 높게 나타난다"
Insight	패턴의 원인과 의미까지 설명	"사용자는 추천이 자신의 취향이 아닌 서비스의 인기 기준을 반영한다고 느낄 때, 서비스에 대한 통제감을 잃고 이탈을 고려한다"

좋은 인사이트는 "그래서 어떻게 해야 하는가"를 판단할 수 있게 해주는 수준까지 도달해야 완성됩니다. 단순히 데이터를 요약한 문장이 아니라, 그 데이터 뒤에 숨어 있는 사용자의 맥락과 감정, 동기를 해석한 문장이어야 합니다.

체크포인트: 작성한 문장이 "그래서 무엇을 만들어야 하는가?"라는 질문에 답할 수 있다면 인사이트입니다. 그렇지 않다면 아직 Fact나 Finding 수준입니다.

2. 인사이트 도출 6단계 프로세스

인사이트는 한 번에 뚝딱 나오는 것이 아닙니다. 데이터 수집부터 기회 영역 전환까지 총 6단계의 프로세스를 거쳐야 합니다. 단계별로 꼼꼼하게 따라가다 보면, 처음에는 복잡해 보이던 데이터가 점점 의미 있는 패턴으로 정리되는 경험을 하게 됩니다.

전체 흐름 요약

데이터 수집 완료 → ① 데이터 정리 및 외재화 → ② 코딩(주제 분류) → ③ 패턴 발견(어피니티 다이어그램) → ④ 테마 도출 → ⑤ 인사이트 문장 작성 → ⑥ 기회 영역 전환(HMW)

① 데이터 정리 및 외재화

인터뷰 녹취록, 관찰 노트, 설문 응답 등 모든 데이터를 한 공간에 모읍니다. 각 발언·행동을 개별 단위(포스트잇 또는 카드)로 분리하되, 이 단계에서는 절대 해석하지 않습니다. 있는 그대로 기록하는 것이 원칙입니다.

참여자 발언: 원문 그대로 기록 (요약·편집 금지)
관찰 행동: 행동 사실만 기록, 해석 제외
설문 데이터: 주목할 수치와 분포를 별도 카드로 정리

② 코딩 (Open Coding → Axial Coding)

각 카드에 주제 태그를 붙이는 작업입니다. 처음에는 정해진 분류 없이 내용에서 자연스럽게 주제를 뽑는 오픈 코딩으로 시작합니다. 예를 들어 "로그인이 너무 복잡해요"라는 발언에는 #인증, #진입장벽, #온보딩 태그를 붙일 수 있습니다.

오픈 코딩이 어느 정도 쌓이면 축 코딩(Axial Coding)으로 넘어가서 범주들 간의 관계를 분석합니다. 하나의 카드에 여러 태그를 붙여도 되고, 분류가 불명확한 카드는 따로 모아 나중에 재검토합니다.

③ 어피니티 다이어그램으로 패턴 발견

저는 실제로 어피니티 다이어그램을 통해 사용자가 자주 사용하는 기능에 대한 패턴을 발견하고 기능을 개선한 경험이 있습니다. 비슷한 태그의 카드들을 공간적으로 묶다 보면 예상하지 못했던 클러스터가 생기고, 그 안에서 개선 포인트가 자연스럽게 드러납니다.

어피니티 다이어그램은 3단계 구조로 진행됩니다:

개별 데이터 포인트 (노란 포스트잇): 각 발언, 관찰, 수치를 개별 카드로 정리
하위 클러스터 (파란 라벨): 5~10개의 유사 카드를 묶어 공통 주제 도출
상위 테마 (빨간 라벨): 2~5개의 핵심 주제로 추상화

팀이 함께 진행하면 다양한 관점에서 패턴을 발견할 수 있어 혼자 하는 것보다 훨씬 풍부한 결과가 나옵니다. Miro나 FigJam 같은 협업 툴을 활용하면 온라인에서도 효과적으로 진행할 수 있습니다.

3. 좋은 인사이트 문장 쓰는 법 — 공식과 조건

많은 기획자들이 가장 어려워하는 부분이 바로 인사이트 문장을 직접 써내려가는 것입니다. 아직 실무에서 본격적인 리서치를 경험하지 못한 상태라면 더욱 막막하게 느껴질 수 있습니다. 그럴 때 활용할 수 있는 인사이트 공식이 있습니다.

인사이트 3요소 공식

[사용자 유형]은 [상황·맥락]에서 [이유] 때문에 [행동·감정]한다.

누가: 어떤 상황의 사용자인가 (세분화된 타겟)
무엇을: 어떤 행동·감정·판단을 하는가
왜: 어떤 이유·맥락 때문인가 (핵심)

좋은 인사이트 vs 나쁜 인사이트 비교

나쁜 인사이트 (Fact 수준)	좋은 인사이트
"사용자들이 불편해한다"	"사용자는 기능이 많을수록 오히려 무엇을 해야 할지 몰라 이탈한다"
"가격 문제가 있다"	"사용자는 가격 자체보다 '내가 충분히 쓰고 있는가'에 대한 불확실성에서 낭비감을 느낀다"
"추천 기능 만족도가 낮다"	"사용자는 추천이 자신의 취향이 아닌 인기 기준을 반영한다고 느낄 때 서비스에 대한 통제감을 잃고 이탈을 고려한다"

좋은 인사이트의 4가지 조건

특정하다: 어떤 사용자, 어떤 상황인지가 명확하다
설명한다: 행동의 이유와 메커니즘을 담는다
행동 가능하다: 읽으면 "그러면 어떻게 해야 하는가"가 떠오른다
놀랍거나 비자명하다: 당연한 이야기가 아니다 (누구나 아는 사실은 인사이트가 아님)

4. HMW(How Might We)로 인사이트를 기회로 전환하기

인사이트를 발견했다면 다음 단계는 그것을 실제 서비스 개선의 출발점으로 만드는 것입니다. 이때 사용하는 기법이 바로 HMW(How Might We)입니다. "우리가 어떻게 하면 ~할 수 있을까?"라는 질문 형식으로, 인사이트를 아이디에이션의 씨앗으로 변환합니다.

HMW 전환 공식

인사이트: "사용자는 추천이 자신의 취향이 아닌 인기 기준을 반영한다고 느낄 때 이탈을 고려한다"

HMW 예시들:

"우리가 어떻게 하면 사용자가 추천에서 자신의 취향이 반영되고 있다고 느끼게 할 수 있을까?"
"우리가 어떻게 하면 사용자가 추천 알고리즘을 직접 제어한다는 느낌을 줄 수 있을까?"
"우리가 어떻게 하면 인기 콘텐츠와 개인화 콘텐츠를 명확하게 구분해서 보여줄 수 있을까?"

HMW 작성 3원칙

해결책을 제시하지 않는다: HMW는 가능성을 열어두는 질문이지, 답을 제시하는 문장이 아닙니다
범위를 적절히 설정한다: 너무 넓으면 방향이 없고, 너무 좁으면 아이디어가 제한됩니다
하나의 인사이트에서 여러 HMW 도출: 다양한 각도에서 질문을 생성해야 풍부한 아이디어가 나옵니다

HMW는 단독으로 쓰이기보다 디자인 씽킹 프로세스, 스프린트, 또는 아이데이션 워크숍의 출발점으로 사용됩니다. Google Design Sprint에서도 HMW를 핵심 도구로 활용하고 있으니 참고해 보세요. (참고: Google Design Sprint Kit - HMW)

5. 정성·정량 데이터 종합 — 트라이앵귤레이션

단일 조사 방법만으로는 편향된 결론에 도달하기 쉽습니다. 설문만 보면 왜 그런지 알 수 없고, 인터뷰만 보면 얼마나 많은지 알 수 없습니다. 이때 필요한 것이 바로 트라이앵귤레이션(Triangulation) — 서로 다른 방법의 결과를 교차 검증하는 방식입니다.

데이터 종합 매트릭스 예시

데이터 출처	발견 내용	방향
설문 (정량)	추천 만족도 평균 2.6점 (5점 만점)	↓ 부정
인터뷰 (정성)	"추천이 내 취향이 아닌 것 같아요"	↓ 부정
행동 관찰	추천 화면 진입 후 평균 3초 이내 이탈	↓ 부정
종합 인사이트	추천 기능이 신뢰를 받지 못하며, 콘텐츠 탐색 자체를 포기하게 만든다 → 기회 영역

데이터가 충돌할 때 어떻게 해야 할까?

때로는 설문에서는 만족도가 높은데 인터뷰에서는 불만이 나오는 경우가 있습니다. 이는 사회적 바람직성 편향 가능성을 의심해야 합니다. 반대로 인터뷰에서는 불편하다고 했는데 실제 관찰에서는 잘 쓰는 경우는 인식과 행동의 괴리로, 더 깊은 탐색이 필요한 신호입니다.

트라이앵귤레이션의 핵심은 데이터가 같은 방향을 가리킬 때 신뢰도를 높이고, 다른 방향을 가리킬 때 새로운 질문을 만드는 것입니다. 충돌 자체가 중요한 인사이트의 원천입니다.

6. POV 문장과 기회 영역 — 리서치의 마무리

인사이트 도출의 마지막 단계는 POV(Point of View) 문장 작성과 기회 영역 정의입니다. POV는 리서치에서 발견한 핵심 사용자 니즈와 인사이트를 한 문장으로 압축한 관점 진술문입니다.

POV 공식

[사용자]는 [니즈]가 필요하다. 왜냐하면 [인사이트]이기 때문이다.

예시: "콘텐츠 소비량이 적은 구독자는 자신이 서비스를 충분히 활용하고 있다는 확신이 필요하다. 왜냐하면 이용량이 적을 때 구독료에 대한 낭비감이 해지 결정의 가장 강한 동인이 되기 때문이다."

기회 영역 정의

POV와 HMW를 종합하면 서비스가 개입할 수 있는 구체적 공간인 기회 영역(Opportunity Area)을 정의할 수 있습니다. 기술 방식은 다음과 같습니다:

"~하는 상황에서, ~한 사용자가 ~할 수 있도록 돕는 것"

기회 영역은 이후 기능 정의, 와이어프레임, PRD 작성의 근거가 됩니다. 리서치에서 도출된 인사이트가 기회 영역으로 연결되고, 그것이 실제 기능으로 구현되는 흐름이 서비스 기획의 핵심 맥락입니다.

7. 핵심 용어 총정리 — 기획자를 위한 리서치 용어 사전

처음 리서치를 배울 때는 낯선 용어가 많아 혼란스럽습니다. 자주 등장하는 핵심 용어들을 한눈에 정리했습니다.

용어	정의
인사이트 (Insight)	데이터에서 도출된 행동 가능한 의미 있는 발견
어피니티 다이어그램	수집된 데이터를 유사한 주제끼리 그룹핑하여 패턴을 발견하는 시각화 기법
코딩 (Coding)	질적 데이터(발언, 관찰 기록)에 주제 분류 태그를 붙이는 분석 작업
오픈 코딩	선입견 없이 데이터에서 주제를 귀납적으로 발견하는 초기 코딩 단계
테마 (Theme)	여러 데이터 포인트에서 반복적으로 나타나는 중심 주제
표면적 니즈	사용자가 직접 표현하는 요구 ("빠른 앱이 필요해요")
잠재적 니즈	사용자 스스로 인식하지 못하거나 표현하지 못하는 더 깊은 필요
Pain Point	사용자가 경험하는 불편, 장애물, 좌절
모순 (Tension)	사용자의 말과 행동, 또는 서로 다른 데이터 사이에서 발견되는 불일치
트라이앵귤레이션	동일한 주제를 서로 다른 조사 방법으로 교차 검증하여 신뢰도를 높이는 방법
HMW	"우리가 어떻게 하면 ~할 수 있을까?" 형식으로 인사이트를 기회 질문으로 전환하는 기법
포화 (Saturation)	새로운 데이터를 추가해도 더 이상 새로운 테마가 나오지 않는 분석 완료 상태

마무리 — 인사이트는 데이터가 아니라 해석에서 나온다

리서치의 진짜 가치는 데이터의 양이 아니라 해석의 깊이에 있습니다. Fact를 열심히 모아도, 그것을 Finding과 Insight로 끌어올리는 과정을 거치지 않으면 보고서는 그냥 데이터 덩어리에 불과합니다. 저도 처음에는 발언 하나하나를 충실히 기록하면 좋은 보고서가 될 거라 생각했지만, "핵심 위주로 정리하라"는 피드백을 받고 나서야 인사이트의 본질을 이해하게 되었습니다.

그리고 저는 직접 어피니티 다이어그램을 활용해 사용자가 자주 쓰는 기능의 패턴을 발견하고 기능을 개선한 경험이 있습니다. 처음에는 포스트잇을 붙이고 움직이는 게 단순한 작업처럼 느껴졌지만, 클러스터가 만들어지고 테마가 드러나는 순간의 쾌감은 정말 인상적이었습니다.

리서치는 한 번에 완벽하게 할 수 없습니다. 데이터를 모으고, 코딩하고, 패턴을 발견하고, 인사이트를 쓰고, 다시 데이터를 보완하는 반복적인 과정입니다. 이 글이 그 과정을 처음 시작하는 기획자들에게 작은 지도가 되었으면 합니다.

함께 읽으면 좋은 글

참고 자료: Nielsen Norman Group — Thematic Analysis | Google Design Sprint Kit — HMW

사용자 행동 관찰과 다이어리 스터디 완벽 가이드 — 기획자가 꼭 알아야 할 관찰 조사 방법 총정리

pokeylog — Sun, 10 May 2026 08:00:44 +0900

Photo by Jason Goodman on Unsplash

저는 팀 과제로 앱 서비스를 직접 만들고 사용자 행동을 관찰하는 맥락 인터뷰를 진행한 적이 있습니다. 그때 가장 충격적이었던 장면이 있었는데요. 저희가 공들여 만든 캐릭터 요소에 대해 사용자들은 인터뷰에서 "귀엽다", "서비스를 잘 이용할 것 같다"고 말했습니다. 그런데 막상 실제로 앱을 사용하는 장면을 관찰해보니, 캐릭터를 한 번 보고 나서는 전혀 신경 쓰지 않았고 오히려 캐릭터 때문에 핵심 기능으로 가는 경로가 복잡해져서 사용성이 오히려 낮아졌습니다. "말"과 "행동"이 이토록 다를 수 있다는 걸 그때 처음으로 몸소 느꼈습니다.

이 경험이 이번 글의 출발점입니다. 기획자와 PM에게 사용자 조사는 인터뷰만으로 끝나지 않습니다. 사용자가 실제로 어떻게 행동하는지를 직접 "보는" 조사가 반드시 필요합니다. 이번 글에서는 행동 관찰, 맥락 인터뷰, 사용성 테스트, 그리고 다이어리 스터디까지 — 관찰 조사의 모든 것을 처음 배우는 분도 이해할 수 있게 정리해드립니다.

이 글은 심층 인터뷰(IDI)와 FGI 완벽 가이드 및 설문 설계와 정량 조사 가이드와 함께 읽으시면 리서치 전체 그림을 잡는 데 큰 도움이 됩니다.

1. 왜 "보는" 조사가 필요한가 — 말과 행동의 차이

사용자는 자신의 행동을 정확하게 기억하거나 설명하지 못합니다. 이것은 사용자가 거짓말을 한다는 게 아니라, 인간의 인지 특성상 실제 행동과 인식 사이에는 늘 간극이 존재한다는 의미입니다.

저도 그 간극을 직접 경험했습니다. "캐릭터 때문에 서비스를 잘 이용할 것 같다"는 말을 믿고 캐릭터 요소를 강화했지만, 실제 관찰에서 사용자들은 캐릭터에 거의 반응하지 않았습니다. 오히려 캐릭터가 핵심 기능으로 가는 시선과 탐색 흐름을 방해하고 있었습니다. 인터뷰는 사용자의 인식을 파악하고, 관찰은 사용자의 실제 행동을 파악합니다. 이 두 가지는 반드시 함께 이루어져야 합니다.

관찰 조사가 필요한 시점

인터뷰 결과와 데이터 분석 결과가 일치하지 않을 때
사용자가 "불편하다"고 하지만 구체적 원인을 설명하지 못할 때
새로운 기능의 실제 사용 흐름을 검증할 때
사용자의 환경(공간, 맥락, 도구)이 행동에 미치는 영향을 알고 싶을 때

비유를 들자면, 인터뷰가 "이 음식이 맛있었나요?"라고 묻는 것이라면, 관찰은 실제로 그 음식을 먹는 사람의 표정과 식습관을 지켜보는 것입니다. 말과 표정은 전혀 다른 이야기를 하고 있을 수 있습니다.

2. 핵심 용어 완전 정리 — 헷갈리는 개념 한 번에

저는 처음 관찰 조사를 배울 때 비슷해 보이는 용어들이 너무 많아서 혼란스러웠습니다. 맥락 인터뷰와 사용성 테스트가 다른 건지, 섀도잉은 언제 쓰는 건지 — 처음에는 구분이 잘 되지 않았습니다. 아래 표로 한 번에 정리해드립니다.

용어	정의
행동 관찰	사용자가 제품/서비스를 실제로 사용하는 모습을 직접 또는 간접적으로 관찰하는 조사 방법
맥락 인터뷰	사용자의 현장(집, 직장 등)을 방문하여 사용 장면을 관찰하며 동시에 질문을 진행하는 기법
사용성 테스트	참여자에게 특정 과업을 수행하도록 하고 그 과정을 관찰하는 평가 방법
섀도잉	연구자가 참여자를 따라다니며 일상적인 행동을 밀착 관찰하는 기법
다이어리 스터디	참여자가 일정 기간 동안 자신의 경험·행동·감정을 스스로 기록하는 종단 조사 방법
Think Aloud (발성 사고법)	사용자가 행동하는 동안 머릿속 생각을 소리 내어 말하도록 하는 기법
관찰자 효과	관찰받고 있다는 인식이 참여자의 행동을 바꾸는 현상
기억 편향 (Recall Bias)	시간이 지남에 따라 실제 경험을 다르게 기억하는 현상. 다이어리 스터디로 최소화 가능
종단 조사	동일한 참여자를 일정 기간 반복 조사하여 시간에 따른 변화를 파악하는 방법

3. 사용자 행동 관찰 방법 3가지 — 언제 무엇을 쓸까

관찰 방법은 크게 세 가지로 나눌 수 있습니다. 각각의 장단점과 적합한 상황이 다르기 때문에, 조사 목적에 맞게 선택하는 것이 중요합니다.

① 맥락 인터뷰 (Contextual Inquiry)

참여자의 실제 환경(집, 직장, 카페 등)에서 관찰과 질문을 동시에 수행하는 방법입니다. "지금 하신 행동이 어떤 이유에서였나요?"처럼 행동 직후 즉시 질문하기 때문에, 환경·도구·루틴까지 파악할 수 있다는 강점이 있습니다. 저도 팀 과제에서 이 방법을 활용해 맥락 인터뷰를 진행했는데, 사용자가 집에서 앱을 사용하는 자연스러운 흐름 속에서 평소에는 드러나지 않는 행동 패턴을 발견할 수 있었습니다.

② 사용성 테스트 (Usability Test)

통제된 환경에서 특정 과업을 부여하고 수행 과정을 관찰하는 방법입니다. 과업 완료 여부, 오류 발생 지점, 소요 시간을 정밀하게 측정할 수 있습니다. Think Aloud(발성 사고법)와 함께 사용하면 행동의 이유까지 파악할 수 있어 특정 기능·화면의 사용성 검증에 최적화되어 있습니다.

③ 섀도잉 (Shadowing)

연구자가 참여자를 따라다니며 일상 관찰을 수행합니다. 참여자가 의식하지 못하는 습관적 행동을 포착하기에 적합하며, 서비스 접점이 다양하거나 오프라인 경험이 중요한 경우에 특히 유용합니다.

관찰 시 반드시 기록해야 할 4가지

행동: 무엇을 했는가 (탭, 스크롤, 멈춤, 이탈)
맥락: 어떤 상황에서 했는가 (장소, 시간, 동반자)
감정: 어떤 반응을 보였는가 (표정, 탄식, 반복 시도)
환경: 어떤 도구/기기를 사용했는가

4. 다이어리 스터디 — 시간의 흐름을 담는 조사

다이어리 스터디(Diary Study)는 참여자가 일정 기간(수일~수주) 동안 스스로 자신의 경험과 행동을 기록하는 종단 조사 방법입니다. 연구자가 현장에 없어도 시간 흐름에 따른 자연스러운 사용 패턴을 파악할 수 있다는 것이 가장 큰 특징입니다.

저는 다이어리 스터디를 직접 진행해본 경험은 없지만, 관찰 조사를 하면서 "이 사람이 일주일 동안 어떻게 앱을 쓰는지 연속으로 기록할 수 있다면 훨씬 많은 걸 알 수 있을 텐데"라는 생각을 했습니다. 단발성 관찰로는 포착하기 어려운 반복 패턴과 감정 변화를 다이어리 스터디가 메워준다는 점에서, 앞으로 꼭 활용해보고 싶은 방법입니다.

다이어리 스터디의 3가지 유형

유형	특징	예시	적합 상황
이벤트 기반	특정 이벤트 발생 시 기록	"배달 앱을 열 때마다 기록"	자연스러운 사용 패턴 파악
시간 기반	정해진 시간마다 기록	"매일 저녁 9시에 기록"	일관된 데이터 수집
혼합형	이벤트 + 시간 기반 결합	이벤트 즉시 기록 + 하루 회고	즉각적 기록 + 성찰 모두 확보

일지 프롬프트 설계 원칙

다이어리 스터디의 품질은 프롬프트 설계에 달려 있습니다. 질문은 간결하고 구체적이어야 하며, 참여자 부담을 최소화해야 합니다. 개방형 질문과 척도형 질문을 혼합하고, 사진이나 스크린샷 첨부를 권장하면 맥락을 보완할 수 있습니다. 하루 기록 소요 시간은 5분 이내가 이상적입니다. (Nielsen Norman Group — Diary Studies 가이드)

5. 행동 관찰 vs 다이어리 스터디 비교

구분	행동 관찰	다이어리 스터디
관찰 주체	연구자	참여자 (자기보고)
환경 통제	연구자 통제 가능	자연 환경
시간 범위	단기 (1회~수회)	장기 (수일~수주)
기억 편향	실시간 관찰로 없음	즉시 기록 시 최소화
강점	즉각적 행동의 정확한 포착	시간에 따른 변화, 반복 패턴
약점	관찰자 효과, 비용 높음	기록 누락, 참여자 부담
적합 상황	특정 기능/화면의 사용성 검증	습관, 감정 변화, 맥락 탐색

두 방법의 최적 조합: 다이어리 스터디로 전체 패턴을 파악하고, 그 중 핵심 장면을 골라 관찰 또는 심층 인터뷰로 심화 탐색하는 방식이 가장 효과적입니다.

6. 관찰 조사에서 기획으로 — 인사이트를 발굴하는 법

저는 관찰 조사를 처음 배울 때 가장 어려웠던 것이 "어떻게 질문해야 사용자의 잠재적 니즈를 파악할 수 있을까"라는 고민이었습니다. 기획자로서 내가 원하는 방향으로 질문을 유도하거나, 사용자의 심리를 건드려 프로젝트 방향을 일그러뜨릴 수 있다는 것을 직접 경험하며 더욱 어렵다고 느꼈습니다. 사용자 관점이 아닌 기획자 관점으로 전환하는 그 과정이 관찰 조사에서 가장 중요한 훈련이라고 생각합니다.

그 훈련 속에서 정말 뜻밖의 인사이트도 발견했습니다. 제가 중요하지 않을 것 같다고 생각했던 기능을 사용자들이 제일 먼저 찾고, 오히려 더 잘 활용하는 장면을 목격했습니다. 기획자가 생각하는 "핵심 기능"과 사용자가 실제로 가장 먼저 찾는 기능이 전혀 다를 수 있다는 것을 그때 처음으로 깨달았습니다. 이 경험 이후로 저는 사용자 경험을 기반으로 서비스를 설계하는 것이 얼마나 중요한지 확신하게 됐습니다.

행동 관찰 분석 4단계

관찰 데이터를 기획으로 연결하는 흐름은 다음과 같습니다. 첫째, 행동 흐름(플로우)을 도식화합니다. 둘째, 오류 발생 지점과 빈도를 집계합니다. 셋째, 실제 탐색 경로와 의도한 경로를 비교합니다. 넷째, 표정·탄식·반복 행동 등 감정 신호를 패턴화합니다. 이 네 단계를 거쳐야 비로소 "이 화면에서 사용자가 왜 이탈하는가"에 대한 근거 있는 인사이트를 도출할 수 있습니다.

다이어리 스터디 분석 4단계

다이어리 스터디 데이터는 에피소드 단위로 코딩(주제별 분류)하는 것이 기본입니다. 그 다음 시간대·상황별 사용 패턴을 시각화하고, 긍정·부정 감정 변화의 추이를 분석합니다. 마지막으로 반복 언급된 불편·만족 요소를 추출하여 우선순위 개선 항목을 도출합니다.

이렇게 얻은 관찰 인사이트를 실제 기획 결정으로 연결하는 방법은 리서치 설계와 가설 수립 가이드에서 자세히 다루고 있습니다. 관찰 결과를 IF-THEN 가설 형태로 전환하고 정량 검증으로 연결하는 흐름을 함께 읽어보시면 더욱 도움이 됩니다.

7. 처음 시작하는 기획자를 위한 관찰 조사 체크리스트

관찰 조사를 처음 시작할 때 가장 흔한 실수는 관찰하면서 즉시 해석을 시작하는 것입니다. "저 사람이 이렇게 행동하는 건 이런 이유겠지"라고 관찰 중에 단정해버리면, 실제로 중요한 다른 행동들을 놓치게 됩니다. 반드시 먼저 기록하고, 나중에 해석해야 합니다.

또 한 가지 기억할 점은 참여자에게 미리 안내를 잘 해야 한다는 것입니다. "잘하려고 하지 않아도 된다", "틀리는 게 아니라 서비스를 테스트하는 것"이라는 점을 충분히 전달해야 자연스러운 행동을 관찰할 수 있습니다. 관찰자 효과를 최대한 줄이는 것이 관찰 조사의 품질을 결정합니다.

실전 체크리스트

☑ 관찰 목적과 알고 싶은 행동이 명확한가?
☑ 관찰 방법(맥락 인터뷰/사용성 테스트/섀도잉)을 목적에 맞게 선택했는가?
☑ 참여자에게 사전 안내(관찰의 목적, 편안함 강조)를 했는가?
☑ 관찰 중에는 해석하지 않고 기록에만 집중하는가?
☑ Think Aloud를 활용해 행동의 이유까지 파악하고 있는가?
☑ 행동·맥락·감정·환경 4가지를 모두 기록하고 있는가?
☑ 다이어리 스터디의 경우 프롬프트가 간결하고 5분 이내 기록 가능한가?
☑ 관찰 데이터를 분석 후 정량 조사로 검증할 계획이 있는가?

참고 자료

설문 설계와 정량 조사 완벽 가이드 — 기획자가 꼭 알아야 할 NPS·CSAT·CES와 설문 설계 원칙 총정리

pokeylog — Sat, 9 May 2026 08:00:57 +0900

Photo by Luke Chesser on Unsplash

저는 UIUX를 처음 공부할 때, 내가 만든 서비스가 실제로 사람들에게 어떻게 받아들여지는지 너무 궁금했습니다. 그래서 처음으로 설문과 인터뷰를 통한 사용자 조사를 직접 진행해봤는데요. 막상 해보니 "어떤 질문을 해야 하지?", "몇 명에게 물어봐야 하지?", "이 데이터로 뭘 결정할 수 있지?"라는 의문이 끊이지 않았습니다. 그 경험이 이 글을 쓰게 된 출발점입니다.

기획자와 PM에게 설문 설계와 정량 조사는 단순한 조사 기술이 아닙니다. 의사결정을 숫자로 뒷받침하는 핵심 역량입니다. 이번 글에서는 정량 조사의 개념부터 설문 설계 원칙, NPS·CSAT·CES 지표, 그리고 데이터를 기획에 연결하는 방법까지 처음 배우는 분도 이해할 수 있도록 꼼꼼하게 정리했습니다.

이 글은 리서치 설계와 가설 수립 가이드의 후속편이기도 합니다. 가설을 세웠다면 이제는 그것을 검증할 차례입니다.

1. 정량 조사란 무엇인가? — 숫자로 패턴을 찾는 방법

정량 조사(Quantitative Research)는 수치로 측정 가능한 데이터를 대규모로 수집·분석해 패턴과 경향을 파악하는 방법입니다. 쉽게 말해, "이 문제가 얼마나 많은 사람에게 발생하는가?", "사용자들이 얼마나 자주 이 기능을 쓰는가?"처럼 숫자로 대답할 수 있는 질문을 다룹니다.

비유를 들자면, 정성 조사가 "왜 이 음식이 맛있는지" 요리사에게 직접 묻는 것이라면, 정량 조사는 "이 음식을 몇 명이 주문했고, 재구매율은 몇 %인지" 영수증 데이터로 파악하는 것입니다.

정량 조사가 필요한 시점

특정 문제가 얼마나 광범위하게 발생하는지 확인할 때
정성 조사에서 만든 가설을 검증해야 할 때
의사결정의 우선순위를 수치로 정해야 할 때
시간 경과에 따른 변화(추이)를 측정할 때

정성 조사 vs 정량 조사 비교

구분	정성 조사	정량 조사
핵심 질문	왜, 어떻게	얼마나, 몇 명이
데이터 형태	언어, 행동, 맥락	수치, 통계
참여자 수	소수 (5~30명)	다수 (100명 이상)
결과 성격	깊은 이해	일반화 가능한 경향
대표 방법	인터뷰, 관찰	설문, 앱 로그 분석
역할	가설 생성	가설 검증

핵심 문장: 정성 조사는 가설을 만들고, 정량 조사는 가설을 검증한다.

2. 설문 설계 원칙 — 좋은 데이터를 얻으려면

저는 처음 설문을 만들 때 가장 큰 실수를 저질렀습니다. 제가 기획하고 있던 서비스에 대해 너무 기대감을 가지고 질문을 설계했는데, 결과적으로 유도 질문이 되어버린 겁니다. 예를 들어 "우리 서비스의 편리한 기능들 중 어떤 부분이 가장 마음에 드셨나요?"라는 질문은 이미 '편리하다'는 전제를 깔고 있어서, 실제로 불편함을 느낀 사용자조차 긍정적인 답변을 하게 만들었습니다. 그 경험 이후로 저는 질문 설계 원칙을 훨씬 꼼꼼히 따지게 됐습니다.

2-1. 조사 목적 명확화 (가장 중요)

설문을 만들기 전에 반드시 다음 세 가지를 먼저 정리해야 합니다. 첫째, 이 조사로 어떤 결정을 내릴 것인가. 둘째, 그 결정을 위해 어떤 데이터가 필요한가. 셋째, 이미 알고 있는 것과 아직 모르는 것은 무엇인가. 목적 없는 설문은 분석할 수 없는 데이터를 만들고, 결국 의사결정에 아무 도움이 되지 않습니다.

2-2. 피해야 할 질문 패턴

유형	나쁜 예시	문제	수정 방향
유도 질문	"편리한 우리 앱에 얼마나 만족하시나요?"	긍정 단어가 답을 유도	"이 앱에 얼마나 만족하시나요?"
이중 질문	"앱이 빠르고 사용하기 쉬웠나요?"	무엇에 답하는지 불명확	두 문항으로 분리
부정/이중부정	"사용하지 않은 적이 없었나요?"	해석 혼란	긍정 문장으로 바꾸기
모호한 빈도	"자주 사용하시나요?"	'자주'의 기준이 사람마다 다름	"하루에 몇 번 사용하시나요?"
전제 질문	"마지막 사용 경험은 어땠나요?"	미사용자 배제	사용 여부 확인 후 분기

2-3. 설문 구성 순서 (권장 흐름)

설문 문항의 순서도 완성률에 큰 영향을 미칩니다. 권장 흐름은 다음과 같습니다. ① 스크리닝 문항으로 조사 대상 여부를 필터링하고, ② 인구통계 및 사용 현황으로 응답자 특성을 파악합니다. ③ 일반 인식/태도로 큰 맥락에서 시작해, ④ 핵심 주제 문항으로 조사 목적에 해당하는 질문을 배치합니다. ⑤ 세부·민감 문항은 뒤쪽에 배치해 이탈을 방지하고, ⑥ 개방형 문항은 선택적으로 마지막에 자유 의견을 수렴합니다.

2-4. 설문 길이와 완성률

문항 수	예상 소요 시간	완성률
5문항 이하	2분 이내	높음
10~15문항	5~7분	보통
20문항 이상	10분 이상	낮음

원칙: 핵심 결정을 위한 '최소 문항'만 남긴다.

3. NPS·CSAT·CES — 정량 지표 완벽 이해

저도 처음에는 이 세 가지 지표를 헷갈렸는데요, 각각이 측정하는 '시간대'가 다르다고 생각하면 이해하기 훨씬 쉽습니다. NPS는 장기적 관계, CSAT는 즉각적 경험, CES는 과정의 편의성을 측정합니다.

NPS (Net Promoter Score) — 장기 충성도 지표

질문: "이 서비스를 지인에게 추천할 의향이 얼마나 있습니까? (0~10점)"

추천자(Promoters): 9~10점
중립자(Passives): 7~8점
비추천자(Detractors): 0~6점

계산식: NPS = 추천자(%) - 비추천자(%)

예를 들어 100명 응답자 중 추천자가 50명(50%), 비추천자가 20명(20%)이라면 NPS = 50 - 20 = +30점입니다. NPS 0 이상이면 긍정적, +50 이상이면 매우 우수한 수준으로 평가합니다. (Bain & Company, NPS 개발 원문)

CSAT (Customer Satisfaction Score) — 즉각적 만족도 지표

질문: "오늘 경험에 얼마나 만족하셨습니까? (1~5점)"

계산식: CSAT = (4~5점 응답자 수 ÷ 전체 응답자 수) × 100

특정 접점(온보딩, 결제, 고객 상담 등)의 즉각적인 만족도를 측정하는 데 최적화되어 있습니다. NPS가 전반적인 관계를 보는 것이라면, CSAT는 특정 순간을 집중 점검합니다.

CES (Customer Effort Score) — 사용 편의성 지표

질문: "원하는 것을 달성하기 위해 얼마나 많은 노력이 필요했습니까? (1~7점)"

점수가 낮을수록 좋고, 높을수록 사용자가 과도한 노력을 기울였다는 의미입니다. 이탈 원인을 찾거나 UX 개선 포인트를 파악할 때 매우 유용합니다.

저는 테스트 앱의 사용성을 조사할 때 시선 추적 장비를 활용해서 CES 관점에서 분석해 본 경험이 있습니다. 유도를 고려하여 설계한 화면에서 사용자의 시선이 의도한 방향으로 자연스럽게 이동하는지, 그리고 목표 달성까지 얼마나 적은 노력이 드는지를 추적했는데요. 이탈률이 점점 줄어들고 유도가 잘 됐을 때 정말 짜릿했습니다. 수치로 개선이 확인되는 그 순간이 서비스 기획의 보람이라고 생각합니다.

4. 핵심 용어 정리 — 시험·실무 대비 완전 정복

처음 정량 조사를 배울 때 제가 가장 헷갈렸던 부분은 비슷해 보이는 용어들의 차이였습니다. 특히 모집단과 표본, 척도와 리커트 척도 같은 개념들은 한번에 정리해두면 나중에 훨씬 편합니다.

모집단(Population): 결과를 일반화하고 싶은 전체 대상 (예: "대한민국 20대 스마트폰 사용자 전체")
표본(Sample): 모집단 중 실제로 조사에 참여한 일부 (예: 그 중 500명)
대표성(Representativeness): 표본이 모집단 특성을 얼마나 잘 반영하는지. 대표성이 낮으면 결과를 일반화할 수 없습니다.
리커트 척도(Likert Scale): "매우 불만족(1점) ~ 매우 만족(5점)"처럼 동의 정도를 단계로 측정하는 도구
유도 질문(Leading Question): 특정 답을 유도하는 편향 질문. 저처럼 처음 설문 만들 때 가장 많이 실수하는 부분입니다.
응답 편향(Response Bias): 실제 생각과 다르게 응답하는 현상. 대표적으로 사회적으로 바람직한 답변을 하려는 경향이 있습니다.
무응답 편향(Non-response Bias): 특정 성향의 사람들이 응답하지 않아 결과가 왜곡되는 현상
코호트(Cohort): 특정 기간/경험을 공유하는 사용자 집단. 예: "2025년 1월 가입자 코호트"
교차 분석(Cross-tabulation): 두 변수 간의 관계를 표로 비교 분석. 예: "연령대별 기능 선호도 비교"

이처럼 데이터를 어떻게 수집하고 해석하느냐에 따라 결론이 완전히 달라질 수 있기 때문에, 용어 하나하나가 실무에서 실제로 중요하게 쓰입니다. 더 자세한 리서치 방법론은 심층 인터뷰(IDI)와 FGI 완벽 가이드에서 정성 조사와 함께 비교해보시면 도움이 됩니다.

5. 데이터 분석에서 기획 의사결정으로 — 숫자를 액션으로 바꾸는 법

정량 데이터를 수집했다고 해서 기획이 자동으로 좋아지지는 않습니다. 제가 가장 어렵게 느꼈던 부분도 바로 이 지점이었습니다. 사용자마다 기준이 달라서 어떤 수치를 기준점으로 잡아야 할지, 어떤 데이터를 쌓아야 이탈률이나 방향성을 잡을 수 있을지 고민이 많았습니다.

하지만 실제로 앱의 버튼 위치와 화면 구성을 바꾼 후 사용자 참여도가 수치로 올라가는 것을 확인했을 때, 생각지도 못한 지표에서 사용자 니즈를 발견하는 경험을 하게 됐습니다. 그 이후로 저는 데이터를 다각도로 분석하는 것이 기획자와 PM의 가장 중요한 강점이라고 확신하게 됐습니다.

기본 4단계 분석 흐름

데이터 분석은 기술 통계에서 시작합니다. 평균, 중앙값, 분포를 확인해 전반적인 상태를 파악하는 것이 첫 번째입니다. 그 다음은 비교 분석으로, 신규 사용자 vs 기존 사용자처럼 그룹 간 차이를 보는 것입니다. 세 번째는 교차 분석으로 연령대별 기능 선호도처럼 변수 간의 관계를 파악합니다. 마지막으로 추이 분석을 통해 시간에 따른 변화를 측정합니다.

데이터에서 기획으로 연결하는 흐름

수치를 확인했다면 "어디가 가장 문제인가?"를 먼저 파악합니다. 불만족, 이탈, 낮은 점수가 집중되는 지점을 찾는 것입니다. 그 다음은 원인 탐색인데, 정량 결과만으로는 "왜?"를 알기 어렵습니다. 이때 정성 조사(인터뷰, FGI)를 병행해 맥락을 채웁니다. 원인을 파악했다면 "불만족 비율 × 영향도(또는 사용자 규모)"로 우선순위를 정합니다. 마지막으로 현재 수치를 기준점으로 개선 목표치를 설정합니다. 예를 들어 "현재 CSAT 3.2점 → 3개월 내 3.8점 이상"처럼 구체적인 숫자로 목표를 정하는 것입니다.

이 과정을 제대로 이해하고 싶다면 OKR과 KPI 완벽 가이드를 함께 읽어보시길 추천드립니다. 데이터로 만든 목표를 OKR/KPI 체계에 연결하는 방법을 자세히 다루고 있습니다.

6. 정량 조사를 처음 시작하는 기획자에게 — 실전 체크리스트

정량 조사를 처음 시작하는 분들이 가장 많이 하는 실수는 "일단 설문부터 만들고 보자"는 태도입니다. 목적 없이 만든 설문은 나중에 어떻게 분석해야 할지 막막하게 만들고, 결국 서랍 속에서 잠드는 데이터가 됩니다.

설문을 만들기 전에 "이 데이터를 받으면 나는 무엇을 결정할 수 있는가?"라는 질문에 먼저 대답할 수 있어야 합니다. 그 답이 명확하지 않다면 아직 설문을 만들 준비가 되지 않은 것입니다.

또 한 가지 기억할 것은 정량 조사는 단독으로 완결되지 않는다는 점입니다. 숫자는 "무엇이"를 알려주지만, "왜"는 알려주지 않습니다. 정성 조사와 함께 사용할 때 비로소 완전한 인사이트를 얻을 수 있습니다. 이 두 조사를 어떻게 통합적으로 설계하는지에 대해서는 리서치 설계와 가설 수립 가이드에서 자세히 다루고 있습니다.

실전 체크리스트

☑ 조사 목적과 이 데이터로 내릴 결정이 명확한가?
☑ 모집단과 목표 표본 크기를 설정했는가?
☑ 유도 질문, 이중 질문, 모호한 표현이 없는가?
☑ 설문 완성률을 고려해 문항 수를 최소화했는가?
☑ 파일럿 테스트(소규모 사전 검토)를 진행했는가?
☑ 분석 방법(기술통계, 교차분석 등)을 미리 계획했는가?
☑ 정량 결과를 보완할 정성 조사 계획이 있는가?

참고 자료

심층 인터뷰(IDI)와 FGI 완벽 가이드 — 기획자가 꼭 알아야 할 정성 조사 진행법 총정리

pokeylog — Fri, 8 May 2026 08:00:15 +0900

Photo by

Scott Graham

Unsplash

솔직히 말하면, 저는 처음에 인터뷰 리서치를 굉장히 번거롭다고 생각했습니다. 대학 시절 팀 프로젝트를 하면서 인터뷰 대상자를 직접 찾고, 약속을 잡고, 만나러 가는 그 과정 자체가 귀찮게 느껴졌거든요. 거기다 "이 사람이 과연 우리 서비스를 충분히 이해하고 있을까?"라는 편견까지 품고 시야가 좁은 상태로 시작했습니다.

그런데 막상 인터뷰를 진행해보니, 생각이 완전히 바뀌었습니다. 질문을 뽑는 과정에서부터 사용자의 잠재적 니즈를 스스로 발견하게 되고, 인터뷰 현장에서 예상치 못한 인사이트가 터지는 경험을 했습니다. 새로운 기능이나 서비스 아이디어가 오히려 인터뷰 중에 더 쉽게 나오더라고요. 그 경험이 제 사고방식을 훨씬 넓혀줬습니다.

이 글에서는 정성 조사의 대표적인 두 방법인 심층 인터뷰(IDI)와 FGI(Focus Group Interview)를 각각의 진행 방식, 장단점, 적합한 상황까지 완벽하게 정리합니다. 리서치 설계 전반이 궁금하다면 리서치 설계와 가설 수립 완벽 가이드도 함께 읽어보세요.

1. 정성 조사(Qualitative Research)란 무엇인가

정량 조사가 "얼마나(How much)"를 측정한다면, 정성 조사는 "왜(Why)"와 "어떻게(How)"를 탐색합니다. 사용자의 동기, 감정, 맥락, 태도처럼 숫자로 바로 잡히지 않는 이유를 이해하는 데 쓰이죠.

저도 기업에서 주최하는 음식 좌담회에 참여자로 참석한 적이 있습니다. 평소에는 "맛있다, 맛없다" 정도로만 단순하게 생각하던 음식에 대해 진행자가 구체적으로 파고들어 물어보니 순간 당황했습니다. "어떤 부분이 좋으셨나요?", "그 맛의 어떤 요소가 특별하게 느껴지셨나요?" 같은 질문에 답하면서, 내가 무엇을 좋아하고 싫어하는지를 오히려 제가 새롭게 발견하는 재미있는 경험을 했습니다. 그 자리에서 "아, 이래서 정성 조사가 필요한 거구나"라는 걸 몸으로 느꼈습니다.

정성 조사가 특히 필요한 순간

문제가 아직 정확히 정의되지 않은 탐색 단계
설문·로그 데이터만으로 행동 이유가 설명되지 않을 때
새로운 사용자 집단을 처음 이해해야 할 때
기존 서비스의 불만 원인을 구체적으로 파고들 때

기획자가 시장을 조사하고 경쟁사를 분석하는 맥락에서도 정성 조사는 필수입니다. 시장 조사와 경쟁사 분석 완벽 가이드와 함께 읽으면 더 넓은 시각을 가질 수 있습니다.

2. 핵심 용어 사전 — 인터뷰 리서치 전에 반드시 알아야 할 개념들

인터뷰 리서치를 처음 접하면 낯선 용어들이 쏟아집니다. 실전에서 헷갈리지 않도록 핵심 용어를 먼저 정리합니다.

IDI (In-depth Interview, 심층 인터뷰): 1:1로 깊게 대화하는 인터뷰. 개인의 경험·동기·감정을 깊이 탐색합니다.
FGI (Focus Group Interview): 6~8명 소그룹을 대상으로 진행하는 집단 토론형 인터뷰.
모더레이터 (Moderator): FGI 진행자. 중립을 유지하면서 대화의 균형을 조정합니다.
토픽 가이드 (Topic Guide): 질문 주제와 순서를 정리한 진행 가이드.
래포 (Rapport): 참여자와 진행자 사이의 신뢰·편안한 분위기. 좋은 인터뷰의 출발점입니다.
프로빙 (Probing): 답변을 더 깊게 파고드는 후속 질문 기법. "왜 그렇게 느끼셨나요?", "조금 더 구체적으로 말씀해주실 수 있나요?"
인사이트 (Insight): 단순 사실을 넘어, 의미 있는 해석/발견.
포화 (Saturation): 더 인터뷰해도 새로운 주제가 거의 나오지 않는 상태. 보통 이 시점이 조사 종료 기준이 됩니다.
스크리너 (Screener): 참여자 적합성을 사전에 확인하는 질문지.
동의서 (Consent Form): 조사 목적·녹음·활용 범위를 고지하고 동의받는 문서.

3. 심층 인터뷰(IDI) — 1:1 대화로 깊이 파고드는 방법

심층 인터뷰(IDI)는 1명의 참여자와 1~2명의 조사자가 1:1로 진행하는 대화 기반 조사입니다. 집단 압력이 없기 때문에 솔직한 답변이 나올 가능성이 크고, 개인의 경험·감정·동기를 깊이 탐색하는 데 가장 적합합니다.

IDI 진행 구조 (흐름)

아이스브레이킹: 분위기를 만들고, 조사 목적을 안내하며, 녹음 및 동의를 확인합니다.
배경 질문: 참여자의 기본 상황과 맥락을 파악합니다.
핵심 주제 탐색: 토픽 가이드를 기반으로 핵심 질문을 진행합니다.
프로빙: "왜?", "예를 들면?", "그때 어떤 감정이었나요?" 등으로 답변을 심화합니다.
마무리: 추가 의견을 받고, 감사 인사와 후속 안내를 합니다.

IDI 질문 유형 예시

질문 유형	목적	예시
오픈 질문	탐색, 자유로운 답변 유도	"평소 어떻게 사용하시나요?"
탐침 질문(프로빙)	답변 심화, 맥락 파악	"그때 어떤 감정이었나요?"
가설 질문	시나리오 확장, 잠재 니즈 탐색	"만약 이 기능이 없었다면 어떻게 하셨을까요?"
클로즈드 질문	사실 확인 (짧게, 최소화)	"현재 이 서비스를 유료로 사용 중이신가요?"

▲ 인터뷰의 80% 이상은 오픈 질문과 프로빙으로 채워야 합니다. 클로즈드 질문은 최소화하세요.

IDI가 잘 맞는 상황

개인적이거나 민감한 주제 (금전, 건강, 갈등 등)
특정 사용자의 행동 패턴을 정밀하게 이해해야 할 때
파워유저 또는 이탈자를 깊게 파고들 때

4. FGI (Focus Group Interview) — 집단 역학을 활용한 그룹 토론 조사

FGI는 6~8명의 참여자를 한 자리에 모아, 모더레이터 진행 하에 특정 주제로 집단 토론을 이끄는 조사입니다. 저는 아직 FGI를 직접 진행해본 경험이 없어서, 솔직히 더 어렵게 느껴지는 방법이기도 합니다. 다양한 관점을 한꺼번에 듣는 과정에서 참여자들끼리 의견을 나누다 보면 특정 한 사람의 의견에 토론이 치우칠 수 있고, 그걸 중립적으로 조율하면서 동시에 깊은 질문을 이끌어내야 한다는 점이 만만치 않아 보입니다. 꼭 한 번 직접 진행해보고 싶습니다.

FGI 진행 구조 (흐름)

도입: 목적과 규칙 안내 (정답은 없다, 서로 존중) + 참여자 소개.
워밍업: 가벼운 질문으로 참여를 유도하고 긴장을 풉니다.
핵심 주제 토론: 주제별로 집단 토론을 진행합니다.
발산 → 수렴: 다양한 의견을 넓힌 뒤 공통점과 차이점을 정리합니다.
마무리: 요약 확인 및 추가 의견 수렴.

모더레이터의 역할 — FGI의 성패를 좌우한다

FGI에서 모더레이터는 단순한 사회자가 아닙니다. 인터뷰 결과의 질을 결정하는 핵심 역할입니다.

특정 의견을 지지하거나 판단하지 않기 (중립 유지)
발언이 적은 참여자도 자연스럽게 참여시키기
주제 이탈 시 부드럽게 다시 방향 잡기
갈등이 생기면 중립적으로 중재하기

이 중에서 제가 가장 중요하다고 생각하는 것은 발언 균형 조율입니다. "목소리 큰 사람이 이긴다"는 말처럼, 저도 스터디나 팀 프로젝트를 하면서 이런 상황을 여러 번 경험했습니다. 내 의견을 차근차근 정리하고 있는데 다른 사람이 더 강하고 설득력 있게 말하면, 나도 모르게 "아, 저 의견이 맞네"라고 실시간으로 생각이 바뀌어버린 적이 있거든요. 이런 집단 압력이 FGI 데이터를 왜곡하는 가장 큰 원인이기 때문에, 모더레이터가 각별히 주의해야 합니다.

FGI가 잘 맞는 상황

여러 사용자 그룹의 인식 차이를 비교하고 싶을 때
브랜드·콘셉트·아이디어에 대한 집단 반응이 필요할 때
빠르게 다양한 관점을 모아야 할 때

5. IDI vs FGI 한눈에 비교 — 언제 무엇을 써야 할까

두 방법은 서로 대체재가 아니라 목적에 따라 선택하는 도구입니다. 상황에 따라 IDI만, FGI만, 혹은 두 방법을 순서대로 병행하는 경우도 많습니다.

구분	심층 인터뷰 (IDI)	FGI
참여 인원	1명	6~8명
소요 시간	60~90분	90~120분
강점	개인 경험·동기 심층 탐색	다양한 관점 + 집단 상호작용
약점	시간·비용 부담, 일반화 어려움	지배적 참여자, 집단 분위기 영향
적합 주제	민감·개인적 주제, 깊이 필요	인식·태도·반응 비교, 아이디어 피드백
데이터 특성	깊이 있음	넓고 다양함
권장 사용 시점	문제 가설 심층 검증, 이탈 원인 탐색	콘셉트 반응 파악, 브랜드 인식 비교

▲ 출처: Nielsen Norman Group — Focus Groups

FGI가 더 어렵게 느껴지는 이유 중 하나는, 한 명 한 명의 심층적인 생각을 끌어내야 하는 IDI와 달리, 여러 명의 상호작용을 조율하면서 동시에 깊은 인사이트를 얻어야 한다는 복잡성 때문입니다. 모더레이터의 역량에 따라 결과가 크게 달라진다는 점도 부담입니다. 반면 IDI는 1:1이라 집중하기 쉽고, 참여자가 더 솔직해지는 경향이 있습니다.

6. 프로빙(Probing) — 인터뷰의 깊이를 결정하는 핵심 기술

프로빙은 인터뷰어의 역량을 가장 잘 보여주는 기술입니다. 단순히 질문 목록을 읽어 내려가는 것이 아니라, 참여자의 답변을 듣고 그 안에서 더 깊은 의미를 끌어내는 후속 질문을 즉흥적으로 던지는 것입니다.

저는 좌담회 참여자로 경험하면서, 프로빙의 힘을 직접 느꼈습니다. 단순히 "맛있다"로 끝날 대화를 "그 맛의 어떤 부분이 특히 기억에 남으셨나요?", "처음 먹었을 때와 지금 느낌이 다른가요?" 같은 질문으로 이어나가니, 제 자신도 몰랐던 취향과 감정을 발견하게 됐습니다. 하지만 동시에 "이런 질문을 길에서 갑자기 받으면 굉장히 귀찮을 것 같다"는 생각도 들었습니다. 이것이 바로 래포(Rapport) 형성이 중요한 이유입니다. 인터뷰 전에 충분한 아이스브레이킹으로 편안한 분위기를 만들어야 프로빙에도 열린 답변이 나옵니다.

효과적인 프로빙 질문 예시

"왜 그렇게 느끼셨나요?"
"조금 더 구체적으로 말씀해주실 수 있나요?"
"그때 어떤 상황이었는지 좀 더 이야기해주실 수 있을까요?"
"예를 들어 어떤 경우에 그런 느낌을 받으셨나요?"
"방금 말씀하신 [키워드]에 대해 더 자세히 듣고 싶어요."

7. 인터뷰 분석 — Fact와 Insight를 구분하는 법

인터뷰가 끝나고 녹취록을 정리했다고 해서 리서치가 끝난 게 아닙니다. 수집한 데이터에서 의미 있는 인사이트를 도출해야 진짜 가치가 생깁니다.

분석 기초 흐름

녹취록(또는 노트) 정리
발언을 주제별로 코딩(분류)
반복 패턴 / 핵심 주제 도출
인사이트 문장 만들기: "사용자는 ~하기 때문에 ~한다"
기획 시사점(개선 방향/우선순위)으로 연결

Fact vs Insight — 이 구분이 보고서의 수준을 결정한다

구분	정의	예시
Fact (사실)	인터뷰에서 관찰된 그대로의 사실	"참여자 5명 중 4명이 알림을 끈다고 말했다."
Insight (해석)	사실에서 끌어낸 의미 있는 발견	"사용자는 알림의 빈도보다 맥락이 맞지 않으면 알림을 차단한다."

▲ Fact를 나열하는 것은 데이터 정리이고, Insight를 만드는 것이 진짜 리서치입니다.

인사이트는 그 자체로 끝나지 않고, 기획 방향 결정 및 가설 수정으로 이어져야 합니다. OKR이나 KPI 목표와 연결해서 "이 인사이트가 어떤 지표 개선으로 이어지는가?"를 함께 생각하면 더욱 실전적인 리서치 결과물이 됩니다. OKR과 KPI 완벽 가이드와 함께 읽어보세요.

8. 기획자가 인터뷰를 잘 해야 하는 이유 — 직무 경쟁력과 직결된다

기획자는 디자이너와 개발자 사이에서 의견을 조율하며, 사용자와 고객이 원하는 것을 출시할 수 있도록 이끄는 직무입니다. 저는 이 과정에서 인터뷰 역량이 기획자의 핵심 경쟁력이라고 생각합니다. 사용자의 니즈를 정확하게 파악할 수 있다면, 팀을 올바른 방향으로 이끌 수 있습니다.

반대로 인터뷰를 제대로 못 하면 어떤 일이 생길까요? 팀 전체가 열심히 함께 제품을 만들어냈는데, 사용자의 진짜 니즈를 파악하지 못해서 아무도 쓰지 않는 서비스가 되는 상황입니다. 그 피해는 팀 전체의 시간과 비용, 그리고 사기로 이어집니다. 일하는 과정에서 혼란을 일으키고, 결국 실패한 프로젝트로 남게 됩니다.

인터뷰 역량을 키우는 가장 좋은 방법은 직접 해보는 것입니다. 처음에는 번거롭고 어색하지만, 막상 해보면 저처럼 "질문을 만드는 과정에서 사용자를 이해하게 되고, 인터뷰 현장에서 생각지도 못한 아이디어가 떠오르는" 경험을 할 수 있습니다. 인터뷰는 기획자의 사고방식을 넓혀주는 가장 강력한 도구입니다.

자주 저지르는 인터뷰 실수 5가지

유도 질문: "이 기능이 편리하지 않으셨나요?" → "이 기능 사용 경험이 어떠셨나요?"로 바꾸세요.
침묵을 못 견디고 먼저 말하기: 침묵이 생겨도 참여자가 생각하는 시간을 주세요. 3~5초의 침묵은 자연스럽습니다.
가설 확인용 질문만 하기: 원하는 답을 확인하러 가는 인터뷰는 의미가 없습니다.
프로빙 없이 다음 질문으로 이동: 핵심 답변이 나왔을 때 파고들지 않으면 표면적인 데이터만 남습니다.
래포 형성 없이 바로 본론: 아이스브레이킹 없이 시작하면 참여자가 방어적이 되어 솔직한 답변을 얻기 어렵습니다.

마무리 — 인터뷰는 기획자가 사용자를 만나는 가장 진지한 방식이다

인터뷰 리서치는 처음에 번거롭게 느껴질 수 있습니다. 저도 그랬으니까요. 하지만 막상 시작하면 질문을 설계하는 과정에서부터, 인터뷰 현장에서 예상치 못한 답변을 듣는 순간까지, 사용자에 대한 이해가 층층이 쌓이는 것을 느낍니다. 그리고 그 이해가 결국 더 좋은 기획으로 이어집니다.

IDI로 깊이를 파고들고, FGI로 넓이를 채우며, 프로빙으로 표면 아래를 탐색하는 것. 이 세 가지가 합쳐졌을 때 기획자는 진짜 사용자의 언어로 말할 수 있는 사람이 됩니다. 서비스 기획의 전반적인 역할이 궁금하다면 서비스기획자란 무엇인가? 역할과 책임 완벽 정리도 함께 읽어보세요.

리서치 설계와 가설 수립 완벽 가이드 — 기획자가 꼭 알아야 할 정량·정성 조사와 IF-THEN 가설 작성법

pokeylog — Thu, 7 May 2026 08:00:57 +0900

Photo by

John Schnobrich

Unsplash

기획을 공부하면서 "리서치"라는 단어를 처음 들었을 때, 저는 단순히 '자료 조사' 정도라고 생각했습니다. 그런데 공부를 하면 할수록 리서치가 단순한 조사가 아니라 고객의 잠재 니즈를 발견하는 가장 강력한 방법이라는 걸 깨달았습니다. 제가 미처 생각하지 못한 부분을 실제 사용자의 목소리와 행동 데이터에서 찾아낼 수 있다는 점에서, 리서치는 기획자에게 꼭 필요한 역량이라는 확신이 생겼습니다.

하지만 막상 리서치를 어떻게 설계해야 하는지, 가설은 왜 세워야 하는지, 정량과 정성은 어떻게 다른지를 체계적으로 정리하기가 쉽지 않았습니다. 이 글에서는 리서치 설계의 전체 흐름부터 가설 작성법, 검증 방법 선택까지 기획자가 알아야 할 모든 것을 정리합니다.

시장 조사 전반에 대한 배경 지식이 필요하다면 시장 조사와 경쟁사 분석 완벽 가이드도 함께 참고해보세요.

1. 리서치란 무엇인가 — 기획자가 리서치를 해야 하는 진짜 이유

서비스 기획 맥락에서 리서치는 서비스 기획의 의사결정을 뒷받침하기 위해 고객·시장·제품에 관한 정보를 체계적으로 수집하고 분석하는 활동입니다. 단순히 "느낌"이나 "팀원들의 합의"로 기획 방향을 정하는 것이 아니라, 실제 데이터와 사용자의 목소리를 근거로 의사결정을 내리기 위해 필요합니다.

저는 앱 기획 팀 프로젝트를 진행하면서 이걸 뼈저리게 느꼈습니다. 팀원들끼리 "이 기능 진짜 좋다!"라고 의기투합해서 만들었는데, 막상 사용자가 잘 이용하지 않는 위치에 배치되어 있거나 사용 과정이 너무 귀찮아서 사용성이 크게 떨어졌던 경험이 있습니다. "처음부터 대상 사용자를 더 뚜렷하게 타겟화하고, 그들의 실제 사용 흐름을 리서치했더라면 달라지지 않았을까?"라는 아쉬움이 남았습니다. 바로 그 경험 덕분에 리서치가 얼마나 중요한지를 실감할 수 있었습니다.

리서치의 3가지 목적 유형

탐색적 (Exploratory): 모르는 것을 발견 → "고객이 어떤 문제를 겪는가?"
서술적 (Descriptive): 현상을 정확히 측정 → "몇 %의 고객이 이 문제를 겪는가?"
인과적 (Causal): 원인-결과 규명 → "이 기능이 전환율을 높이는가?"

기획자가 리서치를 할 때는 먼저 이 세 가지 중 어떤 목적으로 진행하는지를 분명히 해야 합니다. 목적이 명확하지 않으면, 인터뷰를 100번 해도 "그래서 뭘 알게 됐지?"라는 질문에 답하기 어려워집니다.

2. 리서치 설계 5단계 — 체계적으로 조사를 기획하는 방법

리서치는 즉흥적으로 시작해서는 안 됩니다. 5단계로 체계적으로 설계해야 편향 없이 유의미한 결과를 얻을 수 있습니다.

1단계: 목적 정의 (Why)

"이 리서치를 통해 어떤 의사결정을 내릴 것인가?"를 먼저 묻습니다. 결과에 따라 기획 방향이 실제로 바뀌어야 진짜 리서치입니다. 그냥 "알고 싶어서" 하는 리서치는 자원 낭비로 이어집니다.

2단계: 리서치 질문 설정 (What)

목적을 달성하기 위해 구체적으로 무엇을 알아야 하는지를 정합니다. 좋은 리서치 질문의 조건은 세 가지입니다: 구체적이고, 답이 가능하며, 의사결정에 직결되어야 합니다.

❌ 나쁜 예: "고객이 좋아하는가?"
✅ 좋은 예: "고객이 결제 단계에서 이탈하는 주요 이유는 무엇인가?"

3단계: 방법 선택 (How)

정량 / 정성 / 혼합 중 선택합니다. 리서치 목적과 보유 자원(시간·예산·인력)을 고려해 결정합니다.

4단계: 대상 선정 (Who)

현재 사용자 / 잠재 고객 / 이탈 고객 / 비사용자 중 누구에게 조사할지를 결정합니다. 제가 팀 프로젝트에서 아쉬웠던 부분도 바로 이 단계였습니다. 대상을 처음부터 명확하게 타겟화했더라면 훨씬 날카로운 인사이트를 얻을 수 있었을 것입니다.

5단계: 검증 기준 설정 (Measure)

리서치 결과를 어떻게 판단할지를 사전에 정해야 합니다. 예시: "인터뷰 5명 중 3명 이상이 같은 문제를 언급하면 가설 유효." 기준을 미리 정해두지 않으면, 결과가 나왔을 때 원하는 방향으로만 해석하는 확증 편향이 생깁니다.

3. 정량 조사 vs 정성 조사 — 언제 무엇을 써야 하나

정량과 정성 조사 중 어느 쪽이 더 어렵냐고 묻는다면, 저는 처음에 정성 조사가 훨씬 어렵게 느껴졌습니다. 설문지는 문항만 잘 만들면 되는데, 인터뷰는 어떤 질문을 어떻게 해야 사용자의 잠재 니즈를 끌어낼 수 있는지가 막막했습니다. 특히 정성 인터뷰의 질문 수준을 높이려면, 정량 조사에서 나온 데이터를 먼저 충분히 이해하고 그 위에서 "왜?"라는 질문을 더 깊이 파고들어야 한다는 걸 알게 됐습니다. 정량 조사를 기반으로 정성 조사를 설계해야 사용자의 잠재 의식이나 킬링 포인트를 잡아낼 수 있다는 점이 핵심입니다.

정량 조사 vs 정성 조사 비교표

구분	정량 조사	정성 조사
목적	얼마나? 몇 %?	왜? 어떻게?
방법	설문, A/B 테스트, 로그 분석	심층 인터뷰, FGI, 관찰
결과물	숫자, 통계	인사이트, 패턴, 맥락
샘플 규모	많을수록 신뢰 (30명 이상)	5~10명으로 패턴 발견 가능
활용 시점	가설 검증, 현상 측정	가설 발굴, 이유 탐색
한계	이유를 알 수 없음	일반화 불가

▲ 권장 순서: 정성으로 발견 → 정량으로 검증. 두 방법을 순서대로 함께 사용하는 것이 가장 효과적입니다.

가장 이상적인 흐름은 정성 조사로 "왜?"를 발견하고, 정량 조사로 "얼마나?"를 검증하는 것입니다. 두 방법은 경쟁 관계가 아니라 서로를 보완하는 관계입니다. 출처: Nielsen Norman Group — Qualitative vs. Quantitative Research

4. 가설이란 무엇인가 — IF-THEN-BECAUSE 구조로 방향을 잡는 법

가설(Hypothesis)은 검증되지 않은 상태의 믿음을 검증 가능한 형태로 명시적으로 서술한 것입니다. 처음에는 "왜 이렇게 복잡하게 써야 하지?"라고 느낄 수도 있습니다. 그런데 직접 IF-THEN-BECAUSE 형식으로 가설을 작성해보니, 제가 왜 이 서비스를 만드는지에 대한 방향이 훨씬 명확해지는 경험을 했습니다.

이 서비스가 유용할 것 같아서 기획을 시작해도, 막상 진행하다 보면 방향이 흐지부지되거나 처음과 전혀 다른 곳으로 가버리는 경우가 많습니다. 하지만 가설로 방향성을 세우고 기대 효과를 미리 작성해두면, 나중에 기획을 수정하거나 새로운 아이디어를 더할 때도 장단점을 빠르게 비교하고 판단할 수 있습니다.

가설의 3가지 조건

구체성: 모호하지 않고 명확히 서술 가능해야 합니다.
검증 가능성: 데이터나 실험으로 참·거짓을 판단할 수 있어야 합니다.
반증 가능성: 틀릴 수 있다는 가능성을 인정해야 합니다.

가설 작성 구조 — IF-THEN-BECAUSE

IF [특정 조건이나 행동을 하면]
THEN [특정 결과가 나타날 것이다]
BECAUSE [왜 그렇게 생각하는가 — 근거]

실전 예시:

IF 앱 온보딩 화면에 사용 목적 선택 단계를 추가하면
THEN 가입 후 7일 이내 재방문율이 현재 대비 20% 이상 증가할 것이다
BECAUSE 맞춤화된 첫 경험이 서비스 가치를 빠르게 인식시켜 이탈을 줄인다는 유사 서비스 사례가 있기 때문이다

BECAUSE 절이 단순히 "그럴 것 같아서"가 아니라, 데이터나 사례, 논리적 근거로 채워져야 한다는 점이 핵심입니다. 이 근거가 약하면 가설 자체의 신뢰도가 낮아집니다.

5. 가설의 3가지 유형 — 문제·솔루션·성장 가설

가설을 쓸 줄 알게 되면, 다음 단계는 어떤 종류의 가설인지를 구분하는 것입니다. 유형에 따라 검증 방법이 완전히 달라지기 때문입니다.

1) 문제 가설 (Problem Hypothesis)

"이 고객은 이 문제를 겪고 있다"는 믿음입니다. 고객 문제의 실재 여부와 심각성을 검증하는 것이 목적으로, 주로 심층 인터뷰나 관찰 같은 정성 조사로 검증합니다.

예시: "직장인 30대는 점심 메뉴 선택에 10분 이상을 소비하며 이를 불편하게 느낀다"

2) 솔루션 가설 (Solution Hypothesis)

"이 솔루션이 문제를 해결한다"는 믿음입니다. 제안하는 기능이나 서비스가 실제로 문제를 해결하는지를 프로토타입 테스트, 사용성 테스트, MVP를 통해 검증합니다.

예시: "AI 기반 점심 추천 기능이 메뉴 선택 시간을 3분 이내로 줄여줄 것이다"

3) 성장 가설 (Growth Hypothesis)

"이 방법으로 고객을 확보·유지·성장시킬 수 있다"는 믿음입니다. 획득·전환·유지·수익화 채널이나 전략의 효과를 A/B 테스트, 코호트 분석, 채널 실험으로 검증합니다.

예시: "친구 추천 기능을 추가하면 신규 가입의 30%가 추천으로 발생할 것이다"

중요한 순서: 반드시 문제 가설 → 솔루션 가설 → 성장 가설 순서로 검증해야 합니다. 문제가 실재하는지 확인하지 않은 상태에서 솔루션부터 만들면, 아무도 원하지 않는 기능을 완성도 높게 만드는 낭비가 생깁니다. 제가 팀 프로젝트에서 겪었던 바로 그 실수였습니다.

6. 가설 우선순위 결정 — ICE 프레임워크

가설이 여러 개 있을 때 어느 것부터 검증해야 할지를 결정하는 프레임워크가 ICE입니다. 검증 자원(시간, 인력, 예산)은 항상 제한되어 있기 때문에 우선순위를 잘 잡는 것이 중요합니다.

ICE 점수 = (Impact + Confidence + Ease) ÷ 3
각 요소를 1~10점으로 평가합니다.

요소	의미	평가 질문
I — Impact	가설이 참일 경우 사업에 미치는 영향	이게 맞으면 얼마나 큰 변화가 생기는가?
C — Confidence	가설이 맞을 것이라는 확신의 정도	기존 데이터나 근거가 얼마나 있는가?
E — Ease	검증에 드는 시간·비용·노력	얼마나 빠르고 저렴하게 검증할 수 있는가?

▲ ICE 점수가 높은 가설부터 검증하는 것이 원칙입니다. 단, Impact가 매우 높다면 Ease가 낮아도 검증할 가치가 있습니다.

OKR이나 KPI 목표와 연계해서 가설의 Impact를 평가하면 더욱 정확한 우선순위를 잡을 수 있습니다. OKR과 KPI 완벽 가이드와 함께 읽어보세요.

7. 검증 방법 선택 — 상황에 맞는 방법을 고르는 기준

가설 유형과 검증 방법을 매핑하면 다음과 같습니다.

검증 방법	적합한 가설 유형	장점	한계
심층 인터뷰	문제 가설	깊은 맥락 파악	일반화 어려움
설문 조사	문제·성장 가설	빠른 정량화	피상적 응답
사용성 테스트	솔루션 가설	실제 행동 관찰	관찰자 편향
프로토타입 테스트	솔루션 가설	빠른 피드백	실제 상황과 차이
A/B 테스트	성장 가설	인과관계 증명	충분한 트래픽 필요
코호트 분석	성장 가설	유지율·이탈 패턴 파악	실적 데이터 필요

로드맵을 수립할 때 어떤 가설을 어느 스프린트에서 검증할지를 연결하면 훨씬 체계적인 기획이 됩니다. 프로덕트 로드맵 수립 완벽 가이드도 참고해보세요.

8. 기획자가 자주 저지르는 리서치·가설 실수 6가지

리서치와 가설에서 발생하는 실수들은 대부분 초반 설계 단계에서 생깁니다. 정확한 분석 없이 다음 단계로 넘어가면 불필요한 서비스를 계속 만드는 악순환이 이어지고, 조직 전체에 시간과 비용 손실을 안겨줍니다. 반대로 이 과정을 정확히 할수록 의사소통도 빨라지고 서비스의 완성도도 높아집니다. 제가 느낀 것처럼, 리서치와 가설을 제대로 할 줄 아는 기획자는 팀 안에서 진정한 '일잘러'가 될 수 있습니다.

가설 없이 리서치 시작: "일단 인터뷰하고 뭔가 나오겠지"라는 태도로 시작하면 방향성 없는 데이터만 쌓입니다. → "이 리서치로 어떤 의사결정을 할 것인가?"를 먼저 정의하세요.
가설을 확인하러 가는 리서치: 원하는 답을 확인하러 가는 편향된 인터뷰. → "가설이 틀렸을 때 어떻게 할 것인가?"를 먼저 질문하면 편향을 점검할 수 있습니다.
가설과 리서치 질문 혼동: 가설 = 리서치 질문이라고 오해. → 가설은 '검증할 믿음', 리서치 질문은 '알아야 할 것'으로 구분합니다.
솔루션 가설을 먼저 검증: 문제 확인 전에 기능부터 테스트. → "이 문제가 실재한다는 걸 먼저 확인했는가?"를 반드시 질문합니다.
검증 기준 없이 실행: 결과가 나와도 성공인지 모름. → 실행 전 성공 기준(숫자)을 반드시 사전에 정의하세요.
한 가지 방법만 사용: 인터뷰만 하거나 설문만 함. → 정성으로 발견하고 정량으로 검증하는 흐름을 기본으로 삼으세요.

마무리 — 리서치와 가설은 기획자의 언어다

기획자 또는 PM이 리서치와 가설 수립을 제대로 못 하면, 사람들이 원하는 서비스를 만들어내지 못하는 기획자가 됩니다. 정확한 분석 없이 다음 단계로 계속 넘어가면, 결국 불필요한 서비스를 반복해서 만드는 데 자원을 낭비하게 됩니다. 그 피해는 팀 전체에 돌아갑니다.

반대로, 리서치와 가설을 잘 다루는 기획자는 다릅니다. 정확한 분석을 통해 서비스를 개선하면 의사소통 속도가 빨라지고, 불필요한 재작업이 줄어들며, 그 결과가 조직의 이익으로 직결됩니다. 저는 이걸 공부하면서 "리서치와 가설은 기획자의 언어"라는 생각이 들었습니다. 이 언어를 잘 구사할수록, 기획자로서 더 경제적이고 효과적으로 일할 수 있는 경쟁력이 생깁니다.

서비스 기획자의 전반적인 역할이 궁금하다면 서비스기획자란 무엇인가? 역할과 책임 완벽 정리도 함께 읽어보세요.

Unit Economics 완벽 가이드 — 기획자가 꼭 알아야 할 LTV, CAC, Churn Rate 총정리

pokeylog — Wed, 6 May 2026 08:00:04 +0900

Photo by

Campaign Creators

Unsplash

기획자를 준비하는 과정에서 처음으로 회사 문서나 PM 아티클을 읽다 보면 낯선 단어들이 쏟아집니다. LTV, CAC, Churn Rate, Payback Period… 저도 처음 이 단어들을 마주했을 때 "이게 대체 무슨 말이지?"라는 생각부터 들었습니다. 문서 전체를 이해하고 싶은데 핵심 용어를 모르니 맥락이 하나도 잡히지 않는 느낌이었죠. 그래서 저는 빠르게 업무에 적응하려면 이 단어들을 먼저 공부해야겠다고 마음먹고, 자료를 찾기 시작했습니다.

그렇게 공부하다 발견한 프레임워크가 바로 Unit Economics(유닛 이코노믹스)입니다. 처음엔 복잡해 보였지만, 핵심 질문 하나로 정리가 됩니다. "고객 1명을 얻는 데 드는 비용보다, 그 고객이 주는 가치가 더 큰가?" — 이 질문에 답할 수 있다면 Unit Economics의 절반은 이해한 겁니다.

이 글에서는 Unit Economics의 핵심 개념부터 계산 방법, 판단 기준, 그리고 기획자가 자주 저지르는 실수까지 완벽하게 정리해드립니다. 비즈니스 모델 전반에 대한 맥락이 궁금하시다면 비즈니스 모델 캔버스(BMC) 완벽 가이드도 함께 읽어보시면 도움이 됩니다.

1. Unit Economics란 무엇인가 — "고객 1명"으로 보는 수익 구조

Unit Economics는 비즈니스의 가장 작은 단위(고객 1명, 거래 1건 등)를 기준으로 수익과 비용을 분석해, 사업의 수익 구조가 건강한지 판단하는 프레임워크입니다.

많은 사람들이 "매출이 늘고 있으니까 사업이 잘 되고 있겠지"라고 생각합니다. 하지만 저는 공부를 하면서 뉴스에서 전혀 다른 사례들을 많이 봤습니다. 광고 노출은 많은데 실제 구매 전환이 이루어지지 않거나, 이탈률이 계속 늘어나면서 결국 적자가 쌓이는 회사들의 이야기였죠. 매출은 늘고 있는데 왜 적자냐는 질문 — Unit Economics가 망가진 회사들의 전형적인 증상입니다. 그 기사들을 읽으면서 "아, 단순히 수치가 크다고 좋은 게 아니구나"라는 걸 처음으로 실감했습니다.

Unit Economics를 제대로 이해하면 이런 상황을 사전에 파악하고 대응할 수 있습니다. 전체 P&L(손익계산서)과 구분해서, 고객 1명 단위에서 수익이 나고 있는지를 판단하는 것이 핵심입니다.

2. CAC (Customer Acquisition Cost) — 고객 1명을 얻는 데 드는 비용

CAC는 고객 1명을 새로 확보하는 데 소요된 총 비용입니다. 공식으로 표현하면 다음과 같습니다.

CAC = 총 마케팅·영업 비용 ÷ 동일 기간 신규 획득 고객 수

CAC에 포함되는 항목과 제외되는 항목을 명확히 구분하는 것이 중요합니다. 많은 초보 기획자들이 이 경계를 흐릿하게 두는 실수를 합니다.

포함 항목: 광고비, 마케팅 인건비, 영업 인건비, 프로모션·쿠폰 비용, 콘텐츠 제작비
미포함 항목(엄격 기준): 기존 고객 유지 비용, 제품 개발비, 일반 관리비

예시: 이번 달 마케팅·영업에 총 5,000만 원을 썼고, 신규 고객이 1,000명 생겼다면 CAC = 5,000만 원 ÷ 1,000명 = 5만 원/명입니다.

저는 실제 수치를 접할 기회가 아직 없었기 때문에, AI에게 예문과 계산 문제를 부탁해서 직접 손으로 풀어보는 방식으로 공부했습니다. 업종별 통상적인 CAC 범위도 같이 찾아보면서 "이 산업은 고객 1명을 얻는 데 이 정도 비용이 드는구나"라는 감각을 키웠습니다. 그러다 보니 단순 암기가 아니라 실제 사업 맥락에서 숫자가 어떤 의미를 갖는지 이해하게 됐습니다.

3. LTV (Lifetime Value) — 고객 1명이 가져다 주는 전체 가치

LTV(또는 CLV)는 고객 1명이 서비스를 이용하는 전체 기간 동안 창출하는 순수익의 현재 가치입니다. CAC와 함께 Unit Economics의 가장 핵심적인 두 축을 이룹니다.

기본 계산식

LTV = ARPU × (1 ÷ Churn Rate)
단, ARPU = 사용자 1인당 월평균 수익 / Churn Rate = 월간 이탈률

실무 권장 계산식 (Gross Margin 반영)

LTV = (ARPU × Gross Margin) ÷ Churn Rate
Gross Margin(매출 총이익률)을 반영해야 진짜 이익 기준 LTV를 계산할 수 있습니다.

예시: ARPU가 월 1만 원, Gross Margin 70%, 월 Churn Rate 5%라면
LTV = (10,000원 × 0.7) ÷ 0.05 = 140,000원

LTV를 계산할 때 Gross Margin을 빼먹는 실수가 매우 흔합니다. 매출 기준으로만 LTV를 계산하면 실제보다 훨씬 과대 계산되어, 사업 수익성을 낙관적으로 오판하게 됩니다. "고객이 주는 수익에서 원가를 빼야 진짜 이익"이라는 점을 항상 기억하세요.

4. Churn Rate, Retention, Payback Period — 놓치면 안 되는 보조 지표들

Churn Rate(이탈률)는 처음 봤을 때 "왜 이렇게 중요하게 다루는 거지?"라는 생각이 들 수 있습니다. 저도 처음에는 그냥 탈퇴자 비율 정도로만 이해했습니다. 그런데 구독 서비스 가격 인상 뉴스를 여러 번 접하면서 생각이 바뀌었습니다. 서비스 운영비 부담 때문에 요금을 올리면, 이탈률이 급격히 올라가고, 그게 곧바로 매출 타격으로 이어지더라고요. 이탈률이 단 1~2%만 올라가도 LTV 계산 결과가 극적으로 달라진다는 걸 직접 계산해보고서야 실감했습니다.

Churn Rate (이탈률)

Churn Rate = 이탈 고객 수 ÷ 기간 시작 시점 고객 수 × 100

LTV 공식에서 분모 역할을 하기 때문에, Churn Rate가 조금만 올라가도 LTV는 크게 하락합니다. 항상 월간 또는 연간으로 단위를 통일해서 사용해야 합니다. 월간과 연간을 혼용하면 계산이 완전히 틀어집니다.

Retention Rate (유지율)

Retention Rate = 1 − Churn Rate

Churn Rate의 반대 개념으로, 기존 고객 중 다음 기간에도 남아 있는 비율입니다. 구독 서비스에서는 이 수치가 생존 지표나 다름없습니다.

Payback Period (투자 회수 기간)

Payback Period = CAC ÷ (ARPU × Gross Margin)

예시: CAC = 5만 원, ARPU = 1만 원, Gross Margin = 70%라면
Payback Period = 50,000 ÷ (10,000 × 0.7) = 약 7.1개월

주의할 점은 Payback Period가 고객의 평균 유지 기간보다 길면 투자 회수가 불가능합니다. 즉, 회수 기간이 LTV 기간을 초과하면 구조적으로 손해입니다.

5. LTV/CAC 비율 — 사업의 건강성을 한 숫자로 판단하는 법

LTV/CAC 비율은 Unit Economics에서 가장 자주 인용되는 핵심 수익성 지표입니다. "고객 1명에게 투자한 비용 대비 얼마나 더 많은 가치를 얻는가"를 하나의 숫자로 보여줍니다.

LTV/CAC = LTV ÷ CAC

LTV/CAC 비율 해석 기준표 (SaaS / 구독 서비스 기준)

LTV/CAC	해석	대응 방향
1 미만	위험 — 고객 1명에서 손해 발생	CAC 절감 또는 LTV 향상 즉시 필요
1 ~ 3	주의 — 수익성 낮음, 개선 필요	이탈률 감소, ARPU 향상 전략 검토
3	건강한 기준선 (업계 일반적 목표)	현재 구조 유지, 성장 전략 수립
3 ~ 5	양호 — 성장 투자 여력 있음	마케팅 확대, 신규 채널 테스트
5 이상	우수 — 단, 성장 기회 놓칠 수 있음	CAC를 더 써서 성장 가속화 고려

▲ 출처: SaaS 업계 표준 지표 기준 (참고: U.S. Small Business Administration)

LTV/CAC가 높다고 무조건 좋은 건 아닙니다. 5 이상이면 오히려 마케팅 투자를 너무 안 하고 있다는 신호일 수 있습니다. 성장 기회를 놓치고 있는 거죠. 반대로 1 미만이면 고객을 얻을수록 손해가 쌓이는 구조입니다. 스케일업 전에 반드시 이 비율을 먼저 점검해야 합니다.

6. ARPU와 Gross Margin — LTV 계산의 두 핵심 변수

LTV를 정확히 계산하려면 ARPU와 Gross Margin을 제대로 이해해야 합니다. 이 두 가지를 혼동하거나 생략하면 LTV가 완전히 다른 값이 나옵니다.

ARPU (Average Revenue Per User)

ARPU = 총 수익 ÷ 활성 사용자 수

ARPU는 전체 사용자(무료 포함) 기준이고, ARPPU(Average Revenue Per Paying User)는 유료 사용자만 기준입니다. 프리미엄 서비스를 분석할 때 이 둘을 혼용하면 수익성이 과대 또는 과소 평가될 수 있습니다.

Gross Margin (매출 총이익률)

Gross Margin = (매출 - 매출원가) ÷ 매출 × 100

업종	일반적 Gross Margin 범위
SaaS / 소프트웨어	70 ~ 90%
이커머스	20 ~ 40%
제조업	30 ~ 50%
음식 배달 플랫폼	50 ~ 70% (플랫폼 수수료 기준)

▲ 업종별 평균 수치는 개별 기업에 따라 다를 수 있습니다.

저는 공부하면서 업종별 통상적인 수치를 찾아보고, 직접 여러 분야의 수익 구조를 예상해보는 시간을 가졌습니다. "SaaS는 왜 Gross Margin이 이렇게 높을까?", "배달 플랫폼은 수수료가 매출이니까 이 범위가 맞겠구나" 같은 식으로요. 이렇게 직접 업종과 연결해서 생각해보니 단순한 공식이 아니라 사업 구조와 연결된 살아있는 숫자로 느껴졌습니다.

7. Unit Economics를 다른 기획 프레임워크와 연결하기

Unit Economics를 잘 이해하면 다른 기획 프레임워크들과 자연스럽게 연결됩니다. 저는 이 지표들이 서비스 기획 전반의 의사결정과 얼마나 긴밀하게 연결되는지 깨닫고 나서, 기획자에게 이 지표를 아는 것이 왜 필수인지를 비로소 이해했습니다.

CAC → 마케팅 채널 전략: CAC가 높다면 어느 채널에서 비효율이 발생하는지 파악하고 예산 배분을 재조정해야 합니다. 시장 조사와 경쟁사 분석 가이드의 포지셔닝 전략과 연결됩니다.
LTV → OKR/KPI 목표 설정: LTV는 고객 1명이 만들어내는 수익의 최대치입니다. 이를 기반으로 연간 매출 목표, MAU 목표 등 구체적인 KPI를 설정할 수 있습니다. OKR과 KPI 완벽 가이드와 함께 읽어보세요.
Churn Rate → 프로덕트 로드맵: 이탈률이 높다면 제품의 어느 부분에서 이탈이 발생하는지 분석하고, 이를 개선하기 위한 기능 우선순위를 조정해야 합니다. 프로덕트 로드맵 수립 완벽 가이드를 참고하면 도움이 됩니다.
LTV/CAC → 사업 타당성 검증: 이 비율이 3 이상인지 확인하는 것이 신규 사업 또는 기능 기획의 첫 번째 체크포인트가 됩니다.

8. 기획자가 자주 저지르는 Unit Economics 실수 7가지

제가 공부하면서 "나도 이 실수를 할 뻔했겠다"라고 느낀 오류들을 정리했습니다. 기획자로서 이 지표들을 빠르게 파악하고 정확하게 쓸 수 있을수록 실무 경쟁력이 높아진다는 것을 깨달았습니다. 지표를 모르면 회의에서 데이터 이야기가 나올 때 맥락을 못 잡고 결국 엉뚱한 기획을 하게 됩니다. 반대로 지표를 빠르게 읽을 수 있으면, 서비스 이슈에 즉각적으로 대응하고 설득력 있는 제안을 할 수 있습니다.

LTV에 Gross Margin을 반영하지 않음: 매출 기준으로 LTV를 계산해 수익성을 과대 평가. → "고객이 주는 수익에서 원가를 반드시 빼야 진짜 이익"
CAC 범위가 불명확: 어떤 비용을 포함할지 정의하지 않고 계산. → 포함 항목 리스트를 먼저 명확히 정의하기
Churn Rate 단위 혼용: 월간 이탈률과 연간 이탈률을 섞어 사용. → 항상 같은 단위(월간 또는 연간)로 통일
LTV/CAC가 높으면 무조건 좋다는 오해: 5 이상이면 성장 투자를 더 해야 한다는 신호일 수 있음. → "너무 높으면 성장 기회를 놓치고 있을 수도" 관점 필요
Unit Economics를 전체 P&L로 혼동: 회사 전체 손익과 고객 1명 기준을 혼용. → "Unit은 항상 고객 1명 기준"임을 기억
Payback Period가 LTV보다 길어도 된다는 오해: 회수 기간이 고객 유지 기간을 초과하면 구조적 손해. → 반드시 비교해서 확인
TAM·SAM·SOM과 분리해서 봄: 시장 규모와 Unit Economics는 함께 봐야 사업 타당성을 판단할 수 있습니다. TAM SAM SOM 완벽 가이드도 참고해보세요.

마무리 — 지표를 빠르게 파악하는 것이 곧 기획자의 경쟁력

기획자를 준비하면서 저는 이 지표들을 공부하고 나서 비로소 기사나 IR 자료를 읽을 때 맥락이 잡히기 시작했습니다. "아, 이 회사는 CAC는 낮은데 Churn Rate가 높구나", "LTV/CAC가 1에 가깝다는 건 지속 가능한 구조가 아니겠다"처럼 숫자가 스스로 이야기를 해주기 시작했습니다.

Unit Economics는 한 번 이해하고 끝내는 개념이 아닙니다. 서비스를 기획할 때마다, 새로운 기능의 우선순위를 잡을 때마다, 마케팅 예산을 논의할 때마다 계속 꺼내어 확인해야 하는 기준이 됩니다. 제가 경험한 것처럼 지표를 빠르게 파악할수록 서비스 이슈에 즉각 대응할 수 있고, 그게 곧 기획자로서의 경쟁력을 높이는 가장 확실한 방법이라고 생각합니다.

서비스 기획자의 전반적인 역할과 책임이 궁금하시다면 서비스기획자란 무엇인가? 역할과 책임 완벽 정리도 함께 읽어보시길 추천드립니다.

TAM SAM SOM 완벽 가이드 — 기획자가 꼭 알아야 할 시장 규모 산정 방법 총정리

pokeylog — Tue, 5 May 2026 08:00:00 +0900

Photo by

Luke Chesser

Unsplash

기획 문서를 처음 작성하던 시절, 저는 "시장 규모는 약 10조 원입니다"라는 문장을 아무 근거 없이 써놓고 뿌듯했던 기억이 있습니다. 지금 돌이켜보면 정말 민망한 실수였죠. 투자자나 상위 기획자 앞에서 "그 숫자 어디서 나왔어요?"라는 질문 한 방에 말문이 막히는 경험, 기획을 시작한 분이라면 누구나 한 번쯤은 겪어봤을 겁니다.

TAM·SAM·SOM은 단순한 숫자 게임이 아닙니다. 시장의 크기를 층위별로 구분하고, 우리 서비스가 현실적으로 어디까지 도달할 수 있는지를 논리적으로 설명하는 프레임워크입니다. 이 글에서는 개념 정의부터 산정 방법, 실전 예시, 그리고 기획자들이 자주 저지르는 실수까지 완벽하게 정리해드립니다.

혹시 시장 조사 전반에 대한 내용이 궁금하시다면, 제가 이전에 정리한 시장 조사와 경쟁사 분석 완벽 가이드도 함께 읽어보시면 더욱 도움이 됩니다.

1. TAM·SAM·SOM이란? 세 가지 개념의 정의부터 정확히 잡자

TAM·SAM·SOM은 비즈니스 기획서나 투자 피칭 자료에서 빠지지 않는 시장 규모 산정의 3단계 프레임워크입니다. 초보 기획자들이 가장 많이 혼동하는 부분이기도 하죠. 마치 양파를 겹겹이 벗기는 것처럼, 전체 시장에서 점점 구체적인 우리의 타겟 시장으로 좁혀나가는 구조입니다.

TAM (Total Addressable Market, 전체 유효 시장)

TAM은 우리 제품 또는 서비스 카테고리가 이론적으로 도달할 수 있는 최대 시장 규모입니다. 경쟁자 포함, 해당 문제를 해결하고자 지불되는 모든 금액의 합을 의미합니다. 핵심 질문은 "이 문제를 해결하려는 고객이 전 세계(또는 국내)에 얼마나 있으며, 그들이 지불하는 총액은 얼마인가?"입니다. 주로 투자자 설득, 시장 진입 타당성 판단에 활용됩니다.

SAM (Serviceable Available Market, 서비스 가능 시장)

SAM은 TAM 중에서 우리 서비스의 지리적·인구통계적·기술적 조건으로 실제 타겟 가능한 시장입니다. 우리가 한국 시장에서 모바일 앱 기반으로 20~40대를 대상으로 한다면, 글로벌 TAM을 그 조건으로 필터링한 결과가 SAM이 됩니다. BMC의 고객 세그먼트(CS)와 직접 연결되는 개념이기도 합니다.

SOM (Serviceable Obtainable Market, 획득 가능 시장)

SOM은 SAM 중에서 현실적인 전략, 자원, 경쟁 구도를 고려했을 때 우리가 실제로 획득할 수 있는 시장 점유율입니다. "우리의 실행 계획으로 3년 안에 얼마를 가져올 수 있는가?"에 대한 답입니다. SOM이 설득력 있을수록, 사업 계획의 현실성이 높아집니다.

계층 구조로 이해하기

세 개념은 항상 TAM ≥ SAM ≥ SOM의 관계를 유지해야 합니다. SOM이 SAM보다 크거나, SAM이 TAM보다 크다면 산정에 오류가 있는 겁니다. 마치 서울 인구가 대한민국 인구보다 많을 수 없는 것처럼요.

2. Top-down vs Bottom-up: 두 가지 산정 방식의 차이와 활용법

저도 처음에는 무조건 보고서를 인용하는 Top-down 방식만 썼습니다. 근사해 보이기도 했고, 빠르게 숫자를 채울 수 있었거든요. 그런데 "그 보고서가 우리 서비스와 정확히 맞는 카테고리인가요?"라는 피드백을 받고 나서 Bottom-up 방식의 중요성을 깨달았습니다.

Top-down 방식 (하향식)

전체 시장 규모 데이터(거시 데이터)에서 출발해 조건을 좁혀가며 TAM → SAM → SOM을 산출하는 방식입니다. 통계청, 산업연구원, Statista, IBISWorld 같은 공신력 있는 출처에서 시장 보고서를 인용하고, 여기에 타겟 세그먼트 비율과 지역·채널 필터를 적용하면 됩니다.

흐름: 전체 시장 규모 × 타겟 세그먼트 비율 × 지역/채널 필터 = SAM → × 예상 점유율 = SOM

Bottom-up 방식 (상향식)

개별 단위(고객 수 × 구매 금액)에서 출발해 합산으로 시장 규모를 산출하는 방식입니다. 실제 고객 인터뷰, 파일럿 테스트, 유사 서비스 데이터를 기반으로 산정하므로 가정이 명확해 검증이 용이합니다. 사업 계획과 직접 연결된다는 것도 큰 강점입니다.

흐름: 타겟 고객 수(추정/조사) × 1인당 연간 구매 금액(ARPU) = SAM 또는 SOM 추정치

두 방식 비교표

구분	Top-down	Bottom-up
출발점	거시 시장 데이터	개별 고객 단위
데이터	외부 보고서, 통계	자체 조사, 인터뷰, 파일럿
속도	빠름	느림
신뢰도	출처 의존	가정 의존
활용 시점	초기 시장 탐색, TAM 제시	투자 유치, 실행 계획 수립
권장 사용	시장 기회 설명 시	SOM 산정, 사업 계획 근거

▲ 두 방식을 병행해서 사용하는 것이 가장 설득력 있습니다.

3. 실전 계산 예시: 국내 구독 식단 관리 앱 서비스를 기준으로

제가 실제로 기획 프로젝트에서 사용했던 방식과 유사하게 구독 식단 관리 앱을 예시로 들어 설명해보겠습니다. 이처럼 구체적인 숫자와 근거를 함께 제시해야 기획서의 설득력이 올라갑니다.

Top-down 산정 예시

TAM: 국내 건강기능식품 및 식단 관리 시장 전체 = 약 5조 원 (출처: 통계청 KOSIS 가공식품 및 건강식품 시장 데이터)
SAM: TAM 중 모바일 앱 기반, 20~40대, 구독형 서비스 이용자 비율 약 15% → 약 7,500억 원
SOM: SAM 중 1년 차 시장 점유율 목표 0.5% → 약 37억 5천만 원

Bottom-up 산정 예시

타겟 고객 수: 건강 관심 20~40대 스마트폰 사용자 중 구독 서비스 전환 가능 인구 약 30만 명 (설문 및 SNS 리서치 기반)
ARPU (월 평균 결제액): 월 9,900원 → 연간 118,800원
SOM 추정: 30만 명 × 118,800원 = 약 356억 원 (3년 차 목표)

두 방식의 결과가 완전히 일치하지는 않지만, 비슷한 규모의 수치가 나온다면 신뢰성이 높아집니다. 차이가 클 경우 가정을 재검토해야 합니다.

4. 신뢰할 수 있는 데이터 출처와 활용 기준

시장 규모 산정에서 가장 중요한 것은 숫자의 크기가 아니라 출처의 신뢰성입니다. 저는 기획 초기에 블로그 포스팅이나 출처 불명의 자료를 인용하는 실수를 자주 했는데, 지금은 아래 기준으로 데이터를 선별합니다.

1순위 — 정부·공공기관 통계: 통계청 KOSIS, 금융감독원, 국토교통부, 중소벤처기업부 등. 가장 높은 신뢰도이며 무료로 활용 가능합니다.
2순위 — 산업 협회·연구기관: 정보통신정책연구원(KISDI), 한국인터넷진흥원(KISA), 정보통신산업진흥원(NIPA) 등
3순위 — 글로벌 리서치 기관: Statista, IBISWorld, Grand View Research 등. 유료지만 권위 있는 출처입니다.
4순위 — 언론 보도: 조선비즈, 매일경제, TechCrunch 등. 인용 시 원출처 확인 필수.
5순위 — 기업 IR 자료: 상장사 투자자 설명 자료. 참고용으로만 활용 권장.

출처 불명 블로그나 위키 인용은 절대 금물입니다. 발표 자리에서 출처를 물어봤을 때 "잘 모르겠습니다"라고 대답해야 한다면, 그 데이터는 처음부터 사용하지 않는 것이 낫습니다.

5. TAM·SAM·SOM과 다른 기획 프레임워크의 연결

TAM·SAM·SOM은 단독으로 쓰이는 게 아니라 다른 기획 도구들과 긴밀하게 연결됩니다. 저는 처음에 이 프레임워크들이 서로 다른 도구라고 생각했는데, 실제로 써보니 하나의 큰 사고 체계 안에서 맞물려 돌아가는 부품들이었습니다.

SAM → 고객 세그먼트(CS, BMC와 연결): SAM을 정의하는 과정이 곧 비즈니스 모델 캔버스의 고객 세그먼트를 구체화하는 과정입니다. 비즈니스 모델 캔버스(BMC) 완벽 가이드와 함께 학습하면 더욱 효과적입니다.
SOM 전략 → 경쟁사 분석 + 포지셔닝: SOM을 어떻게 가져올 것인가는 경쟁사 분석과 차별화 전략에서 나옵니다. SWOT 분석과 5 Forces 완벽 가이드를 참고해보세요.
SOM 수익 → OKR·KPI 목표 설정: SOM으로 추정한 수익 규모는 연간 목표 매출, MAU, ARR 등 KPI 설정의 근거가 됩니다. OKR과 KPI 완벽 가이드도 함께 읽어보세요.
TAM 성장률 → SWOT의 기회(O): TAM의 CAGR(연평균 성장률)은 시장 진입의 기회를 판단하는 근거가 됩니다.

6. 자주 틀리는 실수 TOP 7과 교정 방법

제가 직접 저질렀거나 팀원들의 기획서에서 발견했던 실수들입니다. 아래 목록을 체크리스트처럼 활용해서, 발표 전에 꼭 한 번 검토해보세요.

TAM = SOM 혼동: 전체 시장을 자사의 목표로 착각합니다. "시장 점유율 100%는 독점이다. 현실적인가?"라는 질문으로 스스로 교정하세요.
출처 없는 숫자: "약 10조 원으로 추정됩니다"처럼 근거 없는 수치 제시. 반드시 공신력 있는 데이터 출처와 함께 표기해야 합니다.
Top-down만 사용: TAM만 크게 제시하고 실질적인 SOM 산출이 없는 경우. Bottom-up SOM 산출을 병행해야 합니다.
SAM과 SOM 역전: SOM > SAM으로 작성하는 실수. SAM의 일부가 SOM임을 항상 기억하세요.
가정 미공개: 계산 과정 없이 결과만 제시. "어떻게 그 숫자가 나왔는가?"에 대한 근거를 반드시 함께 제시해야 합니다.
성장률 미반영: 현재 시장만 보고 미래 성장을 무시. CAGR을 적용해 3~5년 후 시장 크기도 제시하는 것이 권장됩니다.
시장 너무 좁게 정의: SOM을 TAM처럼 좁게 잡는 경우. TAM은 카테고리 전체로 넓게 시작해야 합니다.

7. 시장 규모 산정에 쓰이는 핵심 지표 정리

시장 규모를 표현할 때는 어떤 지표를 쓰느냐에 따라 숫자의 의미가 달라집니다. 서비스 유형에 맞는 지표를 선택하는 것도 중요한 기획 역량입니다.

GMV (Gross Merchandise Value): 플랫폼을 통해 거래된 총 상품 금액. 커머스, 마켓플레이스 서비스에서 주로 사용합니다.
ARR (Annual Recurring Revenue): 연간 반복 수익. SaaS, 구독 서비스에서 핵심 지표입니다.
ARPU (Average Revenue Per User): 사용자 1인당 평균 수익. Bottom-up 산정의 핵심 단위 값으로 활용됩니다.
MAU (Monthly Active Users): 월간 활성 사용자 수. Bottom-up에서 고객 수 산정 기준으로 사용합니다.
CAGR (Compound Annual Growth Rate): 연평균 성장률. 시장의 성장 트렌드를 표현하고 미래 시장 규모를 추정할 때 씁니다.

마무리: 숫자보다 논리, 논리보다 실행

TAM·SAM·SOM에서 가장 중요한 것은 큰 숫자가 아닙니다. 어떤 근거로, 어떤 논리로, 어떤 전략과 연결해서 그 숫자를 만들었느냐입니다. 제가 경험한 가장 설득력 있는 피칭은 "TAM이 수백조 원"이라고 외치는 자리가 아니라, "이 고객 3만 명에게 이 가격으로 이 가치를 제공하면, 1년 차에 이 정도 매출이 나옵니다"라고 조용히 설명하는 자리였습니다.

시장 규모 산정은 기획자의 분석력과 설득력을 동시에 보여주는 영역입니다. 이 글에서 정리한 개념과 방법론을 실제 프로젝트에 적용해보시면, 기획서의 수준이 한 단계 높아지는 것을 느끼실 수 있을 겁니다.

서비스 기획의 전체 프로세스가 궁금하신 분은 서비스기획자란 무엇인가? 역할과 책임 완벽 정리 글도 참고해보세요. 앞으로도 기획자를 위한 실전 가이드를 꾸준히 업데이트할 예정입니다.

SWOT 분석과 5 Forces 완벽 가이드 — 기획자가 꼭 알아야 할 전략 프레임워크

pokeylog — Fri, 1 May 2026 09:14:15 +0900

Photo by Helloquence on Unsplash

저는 처음 서비스 기획을 시작했을 때 "전략 분석"이라는 말만 들어도 머리가 멍해졌습니다. SWOT는 어디서 들어봤는데, 5 Forces는 또 뭔지… 그냥 PPT에 2×2 박스 그려 넣는 거 아닌가? 싶었죠. 그런데 실무에서 로드맵을 짜고 경쟁사 분석을 하다 보면, 이 두 프레임워크 없이는 "왜 이 방향으로 가야 하는가"를 논리적으로 설명하기가 정말 어렵습니다. 이 글에서는 SWOT 분석과 Porter의 5 Forces를 기획자 눈높이에서 완벽하게 풀어드리겠습니다.

1. 전략 분석이란 무엇인가? — "어디서 싸울지, 어떻게 이길지"를 결정하는 것

전략 분석은 한마디로 "우리가 어디서, 무엇으로 경쟁할 것인가"를 결정하는 과정입니다. 좋은 전략에는 공통점이 있습니다. 첫째, 우리가 잘하는 것에서 출발합니다. 둘째, 환경 변화를 읽고 대응합니다. 셋째, 경쟁자가 쉽게 따라 할 수 없습니다.

기획자로서 전략 분석이 필요한 이유는 단순합니다. 기능 하나를 만들든, 신규 서비스를 런칭하든, 우리는 항상 "왜 지금, 이 방향인가?"라는 질문에 답할 수 있어야 합니다. 그 답의 근거가 바로 전략 분석에서 나옵니다.

SWOT와 5 Forces의 역할 구분

5 Forces → 산업의 외부 환경과 수익 잠재력 진단 (밖을 본다)
SWOT → 자사 역량과 외부 환경의 교차점 진단 (안과 밖을 동시에 본다)

두 프레임워크는 서로 연결됩니다. 5 Forces로 기회(O)와 위협(T)을 도출 → SWOT에 입력 → Cross-SWOT로 전략 수립하는 흐름으로 활용합니다. 이 연결 고리를 모르면 각각의 도구를 따로따로 쓰게 되고, 결국 "그래서 우리는 뭘 해야 하죠?"에 대한 답을 못 하게 됩니다.

2. SWOT 분석 완전 정복 — 2×2 매트릭스의 진짜 의미

SWOT 분석은 내부 역량(강점·약점)과 외부 환경(기회·위협)을 2×2 매트릭스로 정리해 전략 방향을 도출하는 프레임워크입니다. 비유하자면, 축구 경기 전 감독이 "우리 팀 공격수가 빠르다(S), 수비가 약하다(W), 상대 팀이 오늘 주전 골키퍼가 없다(O), 날씨가 우리 팀에 불리하다(T)"를 파악하고 전술을 짜는 것과 같습니다.

많은 분들이 SWOT를 단순 나열 도구로 쓰는 실수를 합니다. 저도 주니어 시절에 강점 5개, 약점 5개, 기회 5개, 위협 5개를 줄줄이 나열하고 "SWOT 완성!"이라고 했던 적이 있습니다. 하지만 SWOT의 핵심 원칙은 이겁니다. SWOT는 나열이 아니라 전략 도출의 시작점입니다.

S — 강점 (Strengths): 경쟁자가 쉽게 따라 할 수 없는 것

강점은 경쟁자 대비 내부적으로 우위에 있는 역량과 자원입니다. 여기서 핵심은 "경쟁자 대비"라는 조건입니다. 독자적 기술·특허, 높은 브랜드 인지도, 축적된 고객 데이터, 핵심 인재 보유 등이 해당됩니다. 주의할 점은 "좋은 팀", "열정" 같은 요소는 강점이 아닙니다. 경쟁자와 비교해서 차별화될 때만 강점입니다.

W — 약점 (Weaknesses): 솔직하게 직시해야 전략이 보인다

약점은 경쟁자 대비 내부적으로 열위에 있거나 보완이 필요한 역량입니다. 기술력 부족, 낮은 브랜드 인지도, 자금 부족, 좁은 유통망 등이 예시입니다. 약점을 은폐하면 대응 전략이 없어집니다. 저는 팀 회의에서 약점을 솔직하게 꺼내는 것 자체가 이미 전략의 절반이라고 생각합니다.

O — 기회 (Opportunities): 외부 환경 변화에서 오는 것

기회는 사업에 유리하게 작용할 수 있는 외부 환경의 변화와 트렌드입니다. 시장 성장, 규제 완화, 새로운 기술 등장, 경쟁자 약화 등이 해당됩니다. 흔한 실수는 "우리가 잘해서 기회"라고 쓰는 것인데, 이것은 강점(S)입니다. 기회는 반드시 외부 환경 변화에서 출발해야 합니다.

T — 위협 (Threats): 구체적으로 써야 대응책이 나온다

위협은 사업에 부정적으로 작용할 수 있는 외부 환경의 변화와 리스크입니다. 강력한 신규 경쟁자 진입, 규제 강화, 기술 대체, 경기 침체 등이 예시입니다. "AI 발전이 위협"처럼 모호하게 쓰면 아무 대응도 못 합니다. "AI 기반 저가 대체 서비스 등장으로 가격 경쟁 심화"처럼 구체화해야 실질적인 전략이 나옵니다.

3. Cross-SWOT 전략 — SWOT를 채웠다면 이제 조합하라

많은 기획자들이 SWOT를 채우고 나서 멈춥니다. 하지만 진짜 작업은 지금부터입니다. Cross-SWOT는 4가지 조합으로 전략을 도출합니다.

전략 유형	조합	방향성	예시
SO 전략	강점 × 기회	공격적 성장	보유 기술로 급성장 시장 선점
ST 전략	강점 × 위협	경쟁 방어	브랜드 충성도로 신규 진입자 방어
WO 전략	약점 × 기회	방향 전환·보완	파트너십으로 약점 보완 후 기회 포착
WT 전략	약점 × 위협	리스크 최소화·철수 검토	경쟁 심화 시장에서 선택과 집중

저는 Cross-SWOT를 처음 제대로 써봤을 때 "이게 바로 전략이구나"라는 감각이 생겼습니다. 단순히 현상을 나열하는 게 아니라, 내부 역량과 외부 환경을 교차시켜 "그래서 우리는 이렇게 움직여야 한다"는 방향이 나오는 거니까요. 로드맵 수립이나 신규 기능 우선순위 결정 시 이 프레임을 함께 쓰면 훨씬 설득력 있는 근거가 만들어집니다.

로드맵 수립 방법에 대해 더 자세히 알고 싶다면 → 프로덕트 로드맵 수립 완벽 가이드 — 기획자가 꼭 알아야 할 로드맵 전략

4. Porter의 5 Forces 완전 정복 — 산업 구조를 5가지 힘으로 읽는 법

Porter의 5 Forces는 산업의 경쟁 구조를 5가지 힘으로 분석해 수익 잠재력을 평가하는 프레임워크입니다. 1979년 Michael Porter가 Harvard Business Review에 발표한 이후 전략 분석의 표준 도구가 되었습니다. (출처: Harvard Business Review — How Competitive Forces Shape Strategy, Michael Porter, 1979)

핵심 질문은 하나입니다. "이 산업에서 지속 가능한 수익을 낼 수 있는가?" 5개의 힘이 낮을수록 산업 매력도가 높고(수익 유리), 높을수록 수익 압박이 심합니다.

비유로 설명하면, 5 Forces는 마치 식당을 차리기 전에 "이 상권에서 장사가 될까?"를 점검하는 것과 같습니다. 주변에 경쟁 식당이 얼마나 많은지(기존 경쟁자), 새 식당이 쉽게 들어올 수 있는지(신규 진입자), 편의점 도시락이 대체재인지(대체재), 식재료 납품업체가 갑인지(공급자), 단골 손님이 쉽게 다른 곳으로 가는지(구매자)를 모두 따져보는 것입니다.

Force 1 — 기존 경쟁자 간 경쟁 강도

핵심 질문: "현재 플레이어들이 얼마나 치열하게 싸우고 있는가?" 경쟁이 심한 조건은 경쟁자 수가 많고 규모가 비슷하거나, 시장 성장이 느려 파이를 빼앗아야 하거나, 제품 차별화가 없어 가격 경쟁이 발생하거나, 고객 전환 비용이 낮은 경우입니다. 반대로 1~2개 강자가 시장을 지배하거나 강한 브랜드·기술 차별화가 있으면 경쟁이 약합니다.

Force 2 — 신규 진입자의 위협

핵심 질문: "새로운 경쟁자가 쉽게 들어올 수 있는가?" 대규모 초기 투자, 특허·라이선스, 강한 네트워크 효과, 규제·정부 허가, 규모의 경제 등 진입 장벽이 높을수록 위협이 낮습니다. 반대로 낮은 초기 비용(앱 개발 등)이나 기술·규제 장벽이 없으면 위협이 높습니다.

Force 3 — 대체재의 위협

핵심 질문: "고객이 우리 서비스 대신 다른 방식으로 문제를 해결할 수 있는가?" 중요한 것은 "같은 카테고리"가 아닌 "같은 문제 해결 방식"이 대체재라는 점입니다. 택시의 대체재는 카카오택시가 아니라 대중교통, 자전거, 도보, 카셰어링입니다. 대체재 성능이 향상되고 가격이 낮아지면 위협이 높아집니다.

Force 4 — 공급자의 협상력

핵심 질문: "공급자가 우리에게 불리한 조건을 강요할 수 있는가?" 공급자 수가 적고 대체 불가능하거나, 공급자가 전방 통합(직접 판매 진출)이 가능하면 우리에게 불리합니다. 디지털 서비스 예시로는 넷플릭스의 콘텐츠 스튜디오, 배달앱의 배달 기사, 온라인 쇼핑몰의 입점 브랜드가 있습니다.

Force 5 — 구매자의 협상력

핵심 질문: "고객이 가격 인하나 조건 변경을 요구할 수 있는가?" B2B는 구매자 수가 적고 대량 구매하므로 협상력이 높습니다. B2C는 구매자가 다수 분산되어 일반적으로 협상력이 낮습니다. 전환 비용이 낮고 가격 민감도가 높을수록 구매자 협상력이 강해집니다.

5. 5 Forces 산업 매력도 평가표 — 실무에서 바로 쓰는 종합 판단법

각 힘을 낮음·중간·높음으로 평가해 산업 매력도를 종합 판단합니다. 저도 신규 서비스 기획 시 반드시 이 표를 먼저 채우고 시작합니다.

5 Forces 항목	낮음 (유리 ★★★)	중간 (보통 ★★)	높음 (불리 ★)	우리 산업 평가
기존 경쟁자 경쟁 강도	독점·과점, 차별화 강함	몇몇 경쟁자 존재	다수 경쟁, 가격 경쟁	( )
신규 진입자 위협	높은 진입 장벽	중간 장벽	낮은 진입 장벽	( )
대체재 위협	대체재 없음, 전환 비용 높음	일부 대체재 존재	다양한 대체재, 전환 쉬움	( )
공급자 협상력	공급자 다수, 표준화	일부 독점 공급자	소수 독점, 교체 불가	( )
구매자 협상력	구매자 다수, 충성도 높음	일부 대형 구매자	소수 대형 구매자, 전환 쉬움	( )

종합 판단 기준: 대부분 낮음 → 매력적 산업, 진입 고려 / 대부분 높음 → 수익 내기 어려운 산업, 차별화 또는 회피 / 혼재 → 지배적인 힘에 집중 대응

6. SWOT + 5 Forces 통합 활용 — 전략 수립의 완성된 흐름

두 프레임워크를 따로 쓰면 힘이 반감됩니다. 통합해서 쓸 때 진짜 전략이 완성됩니다. 흐름은 이렇습니다.

5 Forces 분석 → 산업의 기회(O)와 위협(T) 도출
SWOT 분석 → O/T를 입력하고 내부 S/W 진단 추가
Cross-SWOT → SO / ST / WO / WT 전략 수립
전략 방향 결정 → 어디서(포지셔닝) 무엇으로(가치 제안) 싸울 것인가

핵심 통찰을 정리하면, 5 Forces는 외부 환경 지도, SWOT는 내 위치 확인, Cross-SWOT는 이동 방향 결정입니다. 지도도 없이 어디로 가야 하는지 모르고, 내 위치도 모르면서 어디로 이동할지 결정하는 것은 말이 안 됩니다. 이 세 가지가 연결될 때 비로소 "전략"이라는 말을 쓸 수 있습니다.

제가 실제로 신규 서비스 기획 프로젝트에서 이 통합 흐름을 써봤을 때, 이해관계자들의 반응이 완전히 달라졌습니다. 단순히 "이 기능이 좋을 것 같아요"가 아니라 "산업 구조상 이 시점에서 우리 강점을 활용해 이 기회를 잡는 것이 최선"이라고 말할 수 있게 됐거든요.

비즈니스 모델 캔버스와 함께 쓰면 더욱 강력합니다 → 비즈니스 모델 캔버스(BMC) 완벽 가이드 — 기획자가 꼭 알아야 할 9개 블록

OKR/KPI 목표 설정과 연계하는 방법도 확인해보세요 → OKR과 KPI 완벽 가이드 — 기획자가 꼭 알아야 할 목표 설정 프레임워크

7. 실무 적용 팁 — 주니어 기획자가 바로 써먹는 체크리스트

SWOT와 5 Forces를 처음 실무에 적용할 때 가장 많이 겪는 실수들을 정리했습니다. 저도 다 겪어본 실수들이라 현실적인 팁을 드릴 수 있습니다.

SWOT 작성 시 흔한 실수

내부/외부 요인 혼동: "AI 기술 발전"은 외부(O/T)인데 강점(S)에 쓰는 경우
긍정/부정 혼동: "시장이 작다"는 약점(W)이 아닌 위협(T)일 수 있음
너무 모호한 표현: "좋은 팀"보다 "이탈률 5% 이하의 핵심 개발팀 3년 유지"
나열만 하고 Cross-SWOT를 안 하는 것: 전략 도출까지 가야 완성

5 Forces 작성 시 흔한 실수

대체재를 같은 카테고리에서만 찾는 것: "카카오택시의 대체재 = 티맵택시"가 아님
힘의 강도를 주관적으로 평가하는 것: 시장 데이터 기반으로 근거 필요
하나의 힘만 분석하고 끝내는 것: 5개 힘의 상호작용이 핵심

실무 활용 체크리스트

□ 5 Forces로 산업 매력도를 먼저 평가했는가?
□ SWOT의 O와 T가 5 Forces 결과와 연결되는가?
□ 강점과 기회가 정말 "내부/외부" 요인인가?
□ Cross-SWOT 4가지 전략을 모두 도출했는가?
□ 최종 전략 방향이 "어디서, 무엇으로 싸울 것인가"로 정리됐는가?

이 체크리스트를 실제로 출력해서 기획 문서 옆에 붙여두고 쓰면 훨씬 효율적입니다. 전략 분석은 한 번에 완성되는 게 아니라 반복하면서 다듬어지는 작업이기 때문에, 습관적으로 체크하는 것이 중요합니다.

마무리 — 전략 프레임워크는 생각의 언어다

SWOT와 5 Forces를 처음 배울 때는 "그냥 템플릿 채우는 거 아닌가?"라고 생각할 수 있습니다. 저도 그랬습니다. 그런데 수십 번 써보면서 깨달은 것은, 이 프레임워크들이 사실 "생각을 구조화하는 언어"라는 점입니다. 복잡한 시장 환경을 5가지로 쪼개 보고, 내부와 외부를 분리해서 생각하고, 그것을 교차시켜 전략을 도출하는 것 — 이 과정 자체가 기획자의 사고력을 키워줍니다.

처음에는 시간이 걸리더라도 하나씩 직접 채워보세요. 한 번만 제대로 해보면 "아, 이래서 쓰는 거구나"가 느껴질 겁니다. 그게 전략적 사고의 시작입니다.

다음 글에서는 시장 조사와 경쟁사 분석을 어떻게 연결하는지 더 구체적으로 다루겠습니다. 궁금한 점이 있으면 댓글로 남겨주세요!

시장 조사와 경쟁사 분석 완벽 가이드 — 기획자가 꼭 알아야 할 TAM/SAM/SOM부터 포지셔닝 맵까지 총정리

pokeylog — Fri, 1 May 2026 08:00:52 +0900

Photo by Lukas Blazek on Unsplash

저는 처음 서비스 기획을 시작하면서 가장 먼저 배운 게 있습니다. 바로 "만들기 전에 먼저 시장을 봐라"는 말이었습니다. 좋은 아이디어가 있어도, 시장이 없거나 이미 강력한 경쟁자가 있다면 사업은 성립하지 않습니다. 이 글에서는 시장 조사 방법론, TAM/SAM/SOM 시장 규모 추정, 경쟁사 분석 프레임워크까지 초보자도 이해할 수 있도록 풀어드립니다.

이 시리즈의 다른 글: 비즈니스 모델 캔버스(BMC) 완벽 가이드 | OKR과 KPI 완벽 가이드

1. 왜 "조사"가 먼저인가? — 만들기 전 확인할 3가지

저도 처음엔 "일단 만들고 보자"는 식으로 접근했다가, 만든 기능이 외면당하는 쓰라린 경험을 했습니다. 그 이후로 저는 반드시 조사를 먼저 하게 됐습니다.

✅ 기획 전 반드시 확인할 3가지

① 시장은 존재하는가? — 이 문제를 가진 고객이 충분히 많은가?

② 고객은 정말 이 문제를 겪고 있는가? — 가정이 아닌 실제 데이터로 확인했는가?

③ 이미 더 잘하는 경쟁자가 있지 않은가? — 차별화 포인트는 무엇인가?

시장 조사의 역할은 ① 불확실성을 줄이고, ② 의사결정의 근거를 만들며, ③ 기획 방향을 검증하거나 수정하는 것입니다. 단순한 정보 수집이 아니라 리스크를 줄이는 비즈니스 행위입니다.

2. 시장 조사의 두 가지 종류 — 1차 vs 2차 조사

구분	1차 조사 (Primary)	2차 조사 (Secondary)
정의	직접 수집하는 데이터	이미 존재하는 데이터 활용
예시	사용자 인터뷰, 설문조사, 사용성 테스트	통계청, 산업 보고서, 논문, 경쟁사 앱 리뷰
장점	목적에 맞는 데이터 획득	빠르고 비용 효율적
단점	시간·비용 소요	오래되거나 맥락 다를 수 있음
권장 순서	2차 조사로 가설 수립 → 1차 조사로 검증

3. 정량 vs 정성 조사 — 숫자와 이야기의 조합

정량 조사 (Quantitative)

목적: 얼마나 많이? (크기·빈도)

방법: 설문, 웹 분석, A/B 테스트

결과: 숫자, 통계, 비율

정성 조사 (Qualitative)

목적: 왜? 어떻게? (이유·맥락)

방법: 심층 인터뷰, 포커스 그룹

결과: 인사이트, 패턴, 스토리

핵심: 숫자는 "무슨 일이 일어났는지"를, 인터뷰는 "왜 일어났는지"를 알려줍니다. 두 조사는 경쟁이 아니라 보완 관계입니다.

4. 시장 규모 추정: TAM / SAM / SOM

투자자나 경영진에게 "시장 규모가 얼마나 됩니까?"라는 질문을 받았을 때, TAM/SAM/SOM 프레임워크로 답해보세요.

SOM

SAM

TAM

TAM ⊃ SAM ⊃ SOM (큰 원에서 작은 원으로 좁혀가며 현실적 목표 설정)

단계	이름	의미	배달앱 예시
TAM	Total Addressable Market	이론적 전체 시장	국내 음식 배달 전체 = 25조 원
SAM	Serviceable Available Market	실제 타겟 가능 범위	서울·경기 20~40대 앱 배달 = 8조 원
SOM	Serviceable Obtainable Market	현실적 획득 가능 규모	초기 3년 목표 5% = 4,000억 원

⚠️ 포인트: SOM은 전략과 실행 계획이 뒷받침되어야 숫자에 신뢰가 생깁니다.

5. 경쟁사 3가지 유형 — 직접·간접·잠재

경쟁사를 "같은 카테고리"로만 보면 진짜 위협을 놓칩니다. 기획자는 동일한 고객 문제를 해결하는 모든 대안을 경쟁사로 봐야 합니다.

유형	정의	배달앱 예시	분석 우선순위
직접 경쟁사	동일 고객 × 동일 가치 제공	배달의민족 vs 쿠팡이츠	⭐⭐⭐ 최우선
간접 경쟁사	동일 고객 × 다른 방식	편의점 즉석식, HMR	⭐⭐ 인사이트 多
잠재 경쟁사	현재 미진입, 미래 진입 가능	대형 IT기업 배달 진출	⭐ 리스크 모니터링

6. 경쟁사 분석 프레임워크 ① — 4P 분석

4P를 활용해 경쟁사 3~5개를 같은 기준으로 비교하면 업계 표준(공통점)과 차별화 기회(차이점)가 명확히 보입니다.

항목	분석 질문	확인 방법
Product	핵심 기능은? UX 차별점은?	앱 리뷰, 직접 사용 테스트
Price	가격 정책은? 무료/유료 구조는?	공식 홈페이지, 구독 플랜
Place	어디서 어떻게 이용 가능한가?	앱스토어, 웹, 오프라인 여부
Promotion	마케팅 방식, 주요 메시지는?	SNS, 광고 문구, 캠페인

7. 경쟁사 분석 프레임워크 ② — 포지셔닝 맵

포지셔닝 맵은 경쟁 구도를 한눈에 시각화하는 강력한 도구입니다. 저도 팀 발표에서 처음 이 맵을 활용했을 때 "아, 이런 틈새가 있었네!"라는 반응을 들었습니다. 목표는 아무도 없는 공간(White Space)을 발견하는 것입니다.

포지셔닝 맵 예시 (가격 × 배송 속도)

	▲ 고가
느림 ◀	경쟁사 A 고가 / 느린 배송	✨ White Space 우리의 기회!	경쟁사 B 고가 / 빠른 배송	▶ 빠름
	▼ 저가

8. 경쟁사 분석 프레임워크 ③ — SWOT 분석

SWOT은 자사와 경쟁사 모두에 적용할 수 있습니다. 경쟁사의 약점 = 우리의 기회라는 관점으로 분석해보세요.

S — Strength (강점)

경쟁자보다 잘하는 것
ex. 기술력, 브랜드, 특허

O — Opportunity (기회)

외부 환경의 긍정 변화
ex. 시장 성장, 규제 완화

⚠️ W — Weakness (약점)

내부의 부족한 부분
ex. 자금력, 인지도, 팀 역량

T — Threat (위협)

외부 환경의 부정 변화
ex. 경쟁 심화, 규제 강화

9. 전체 흐름 — 시장조사 → 경쟁사 분석 → 포지셔닝 → BMC

지금까지 배운 개념들이 어떻게 연결되는지 흐름으로 정리합니다. 이 과정을 거치면 비즈니스 모델 캔버스(BMC)의 가치 제안(VP)을 자신 있게 작성할 수 있습니다.

① 시장 조사

TAM/SAM/SOM
시장 규모 파악

→

② 경쟁사 분석

4P / SWOT
직접·간접·잠재

→

③ 포지셔닝

포지셔닝 맵
White Space 발견

→

④ BMC 작성

VP 확정
비즈니스 모델 완성

10. 핵심 요약 치트시트

개념	핵심 질문	도구
시장 조사	이 시장은 얼마나 큰가?	TAM / SAM / SOM
고객 조사	왜 이 문제가 중요한가?	인터뷰, 설문
경쟁사 파악	누가 같은 문제를 해결하는가?	3유형 분류
경쟁사 비교	경쟁사와 무엇이 다른가?	4P, SWOT
포지셔닝	우리는 어디에 있어야 하는가?	포지셔닝 맵

마치며 — 조사는 "확신"이 아니라 "방향"을 위한 것

저는 이 글을 정리하면서 시장 조사와 경쟁사 분석이 단순히 "보고서 채우기"가 아님을 다시 한번 느꼈습니다. 이 과정은 우리가 틀렸을 때 빨리 알아채기 위한 장치입니다. 완벽한 조사는 없습니다. 하지만 가설을 세우고 빠르게 검증하며 나아가는 것이 현명한 기획자의 태도입니다.

공식 참고 자료: KOSIS 국가통계포털 (통계청) | 한국지능정보사회진흥원(NIA) 보고서

함께 읽으면 좋은 글: 비즈니스 모델 캔버스(BMC) 완벽 가이드 | OKR과 KPI 완벽 가이드 | 서비스기획자란 무엇인가?

프로덕트 로드맵 수립 완벽 가이드 — 기획자가 꼭 알아야 할 로드맵 전략과 우선순위 프레임워크 총정리

pokeylog — Thu, 30 Apr 2026 09:23:50 +0900

Photo by Campaign Creators on Unsplash

저는 처음 PM으로 일을 시작했을 때 "로드맵을 만들어 오세요"라는 말에 당황했던 기억이 있습니다. 그냥 엑셀에 일정표를 만들어 갔다가 팀장님께 "이건 간트차트지 로드맵이 아니에요"라는 피드백을 들었죠. 그때부터 로드맵이 무엇인지, 왜 중요한지를 본격적으로 공부하기 시작했습니다.

이 글에서는 프로덕트 로드맵의 본질부터 종류, 수립 프로세스, 우선순위 결정 프레임워크까지 기획자와 PM이 꼭 알아야 할 모든 것을 초보자도 이해할 수 있는 언어로 정리했습니다. 이미 OKR과 KPI 완벽 가이드를 읽으셨다면 이 글과 함께 보시면 더욱 효과적입니다.

1. 프로덕트 로드맵이란? — "계획서"가 아니라 "커뮤니케이션 도구"다

많은 분들이 로드맵을 단순한 일정표나 기능 목록으로 오해합니다. 저도 그랬으니까요. 하지만 로드맵의 핵심 가치는 그것이 아닙니다.

프로덕트 로드맵의 정의: 제품의 비전과 전략을 바탕으로, 앞으로 만들어 나갈 방향과 우선순위를 시각화한 커뮤니케이션 도구입니다.

로드맵은 크게 두 가지 역할을 합니다:

내부 정렬 도구: 개발·디자인·마케팅·경영진이 같은 방향을 바라보게 합니다.
외부 커뮤니케이션 도구: 고객·투자자·파트너에게 제품 방향을 설명합니다.

그렇다면 로드맵이 아닌 것은 무엇일까요?

확정된 일정표 (스프레드시트 간트차트)
기능 목록 (백로그와 혼동 주의)
변경 불가능한 약속

저도 팀에서 "로드맵이 자꾸 바뀐다"는 불만을 들은 적이 있습니다. 돌아보면, 그 팀은 로드맵을 '약속'으로 받아들이고 있었습니다. 하지만 로드맵은 '현재 시점의 최선의 판단'입니다. 새 정보가 들어오면 바뀌는 것이 오히려 건강한 신호입니다.

2. 로드맵의 종류 — 시간 기반 vs 독자 기반

로드맵은 하나의 형식만 있는 게 아닙니다. 목적과 독자에 따라 여러 형태가 존재합니다. 처음에 저는 이 부분을 몰라서 경영진에게도, 개발팀에게도 같은 형식의 로드맵을 가져갔다가 둘 다에게서 "이게 뭐냐"는 반응을 들었죠.

2-1. 시간 기반 분류

유형	기간	특징	주 독자
Now-Next-Later	시간 없음	우선순위 중심, 유연	개발팀, 내부
분기별 로드맵	3개월 단위	OKR과 연동, 현실적	전사, 팀
연간 로드맵	12개월	방향성 중심, 추상적	경영진, 투자자
릴리즈 플랜	스프린트 단위	상세 일정, 구체적	개발팀

2-2. 독자 기반 분류

유형	독자	포함 내용
내부용 로드맵	개발·디자인·마케팅	상세 기능, 우선순위, 이슈 포함
경영진용 로드맵	C-레벨, 이사회	전략·비즈니스 영향 중심, 기술 제외
고객용 로드맵	사용자, 파트너	기능명 중심, 일정 대략적, 약속 최소화

경영진에게는 연간 방향성 로드맵을, 개발팀에게는 Now-Next-Later 또는 릴리즈 플랜을, 고객에게는 기능 중심 공개 로드맵을 각각 제공하는 것이 이상적입니다. 이처럼 서비스기획자의 역할은 단순한 문서 작성이 아니라, 다양한 이해관계자와 소통하는 일임을 이 과정에서 새삼 깨달았습니다.

3. 로드맵 수립 5단계 프로세스

로드맵을 처음 만들 때 가장 막막한 부분이 바로 "어디서부터 시작해야 하지?"입니다. 저는 처음엔 무작정 팀원들한테 하고 싶은 기능을 물어보고 모아서 정리했는데, 그게 얼마나 비효율적인지 나중에야 알았습니다. 체계적인 5단계 프로세스를 소개합니다.

1단계: 비전·전략 확인

모든 로드맵은 제품 비전(3~5년)과 전략(1년)에서 출발해야 합니다. "비전 없이 로드맵을 만들면 기능 목록이 됩니다." 모든 아이템이 비전을 향해 가고 있는지 확인하세요. OKR과 로드맵의 연동은 이 단계에서 핵심입니다.

2단계: 인풋 수집

로드맵의 재료는 다양한 곳에서 옵니다:

고객 피드백 (인터뷰, CS, 앱스토어 리뷰)
정량 데이터 (퍼널 분석, 이탈 지점)
경쟁사 분석
이해관계자 요청 (영업, 마케팅, 경영진)
기술 부채 및 인프라 개선 요구

주의할 점: 이해관계자 요청이 가장 '시끄럽게' 들어옵니다. 큰 목소리가 곧 높은 우선순위를 의미하지 않습니다. 팀이 함께 이 점을 인식해야 합니다.

3단계: 기회 영역 정의

수집한 인풋을 테마(Theme) 단위로 묶습니다. 예: "온보딩 개선", "알림 고도화", "결제 플로우 최적화"처럼요. 중요한 것은 기능(Feature)보다 문제(Problem) 중심으로 정의하는 것입니다.

"로그인 화면을 바꾸자"는 기능 중심입니다. "신규 사용자가 첫 3분 안에 가치를 느끼지 못한다"는 문제 중심입니다. 문제 중심으로 정의해야 해결 방법이 다양해집니다.

4단계: 우선순위 결정

이 단계가 가장 핵심입니다. 다음 섹션에서 자세히 다루겠습니다.

5단계: 시각화 및 공유

독자에 맞는 포맷을 선택하고, Now-Next-Later 형식을 기본으로 분기마다 리뷰합니다. 변경 시에는 반드시 Why(이유)를 함께 공유해야 신뢰가 쌓입니다.

4. 우선순위 결정 프레임워크 — RICE, ICE, MoSCoW, 2×2

우선순위를 결정할 때 "직감"에 의존하면 항상 가장 목소리 큰 사람의 아이디어가 채택됩니다. 저도 그런 경험을 해봤기 때문에 프레임워크의 중요성을 뼈저리게 느낍니다. 데이터 기반으로 논리적 근거를 가지고 대화해야 팀이 납득합니다.

① RICE 스코어링 — 가장 체계적인 방법

RICE는 네 가지 요소의 조합으로 우선순위를 수치화합니다:

R (Reach, 도달): 얼마나 많은 사용자에게 영향을 미치는가? (예: 월 1,000명)
I (Impact, 영향): 얼마나 큰 영향을 미치는가? (0.25 / 0.5 / 1 / 2 / 3)
C (Confidence, 확신도): 추정에 얼마나 확신하는가? (% 단위, 예: 80%)
E (Effort, 노력): 구현에 얼마나 작업이 필요한가? (person-months)

공식: RICE Score = (Reach × Impact × Confidence) ÷ Effort

계산 예시:

기능/테마	Reach	Impact	Confidence	Effort	RICE Score
온보딩 개선	2,000	2	0.8	2	1,600
알림 고도화	5,000	1	0.6	3	1,000
결제 플로우 최적화	1,000	3	0.9	1	2,700

→ 이 경우 결제 플로우 최적화(2,700)가 가장 높은 우선순위입니다. 비록 도달 범위는 작아도, 영향도와 확신도가 높고 노력이 적게 들기 때문입니다.

② ICE 스코어링 — 빠르게 비교할 때

RICE보다 간단한 버전입니다. Impact × Confidence × Ease로 각 항목을 1~10점으로 평가합니다. 빠른 의사결정이 필요할 때 유용합니다.

③ 2×2 매트릭스

X축: 구현 난이도(쉬움 ↔ 어려움), Y축: 가치(낮음 ↔ 높음)로 구성합니다.

Quick Win: 쉽고 가치 높음 → 바로 해야 함
Big Bet: 어렵지만 가치 높음 → 신중하게 계획
Fill-in: 쉽지만 가치 낮음 → 여유 있을 때
Time Sink: 어렵고 가치 낮음 → 하지 말 것

④ MoSCoW 방법

Must(반드시), Should(해야 함), Could(할 수 있으면), Won't(이번엔 안 함)으로 범주화합니다. 이해관계자와 합의할 때 특히 효과적입니다.

5. 로드맵 vs 백로그 — 혼동하지 말아야 할 두 가지

저는 처음에 로드맵과 백로그를 같은 것으로 이해했습니다. 그런데 이 두 가지는 완전히 다른 목적과 레벨을 가집니다. 음식으로 비유하자면, 로드맵은 "오늘 저녁에 한식 코스를 먹겠다"는 큰 그림이고, 백로그는 "국 끓이기, 밥 짓기, 반찬 준비하기"처럼 세부 작업 목록입니다.

항목	로드맵	백로그
단위	테마·에픽·기능	User Story·태스크
추상도	높음	낮음
독자	전사·이해관계자	개발팀
목적	방향·전략 전달	실행 관리
변경 주기	분기 단위	스프린트마다

"로드맵은 '왜 이것을 만드는가'이고, 백로그는 '어떻게 만드는가'입니다." 이 관계를 이해하면 애자일/스크럼 방법론과의 연결 고리도 자연스럽게 보입니다.

6. 로드맵 수립 시 흔한 실수와 해결법

제가 실제로 겪었거나 주변 PM들로부터 들은 실수들을 정리했습니다. 이 내용을 미리 알았더라면 많은 시행착오를 줄일 수 있었을 텐데 하는 아쉬움이 있습니다.

실수	원인	해결 방법
너무 상세한 일정 기입	확신 과잉, 이해관계자 압박	구간(Q1, H1)으로 표현
기능 목록이 되어버림	전략 부재	테마 단위로 묶기
이해관계자 요청 그대로 반영	우선순위 기준 없음	RICE/ICE 등 프레임워크 사용
로드맵이 공유되지 않음	문서 관리 문제	Notion, Jira, Productboard 등 활용
변경 이유 설명 없음	커뮤니케이션 부재	변경 시 Why를 함께 공유
"Later"가 쌓이기만 함	정기 리뷰 없음	분기마다 Later 재평가

특히 마지막 실수인 "Later"가 쌓이는 문제는 정말 흔합니다. 나중에 하겠다고 넣어둔 것들이 쌓이면 로드맵이 의미를 잃습니다. 분기마다 Later 항목을 재평가해서 버릴 건 버리고, 올릴 건 올리는 작업이 필수입니다.

7. 대표 로드맵 포맷 5가지 — 언제 무엇을 써야 하나

로드맵 포맷을 잘못 선택하면 아무리 잘 만들어도 독자에게 전달이 안 됩니다. 저도 개발팀에 연간 전략 로드맵을 가져갔다가 "그래서 이번 스프린트에 뭘 해야 해요?"라는 말을 들었던 경험이 있습니다. 상황에 맞는 포맷 선택이 매우 중요합니다.

1. Now-Next-Later 로드맵 (우선순위 기반) — 가장 권장

날짜 대신 시간적 우선순위로 구분합니다. Now(지금 하는 것), Next(곧 할 것), Later(나중에 고려할 것)의 세 열로 구성됩니다. 변경에 유연하고, 불필요한 일정 약속을 피할 수 있어 대부분의 팀에서 권장됩니다.

2. 기능 기반 로드맵 (Feature-based)

분기별·월별로 어떤 기능이 나오는지를 시각적으로 보여줍니다. 개발팀의 일정 관리에 유용하지만, 너무 구체적인 날짜를 적으면 오히려 독이 됩니다.

3. 목표 기반 로드맵 (Goal-based)

"사용자 유지율 20% 향상"처럼 비즈니스 목표를 제품 이니셔티브와 연결합니다. OKR과 KPI를 로드맵에 연동할 때 이 형식이 특히 효과적입니다.

4. 전략 로드맵 (Strategic)

투자자나 경영진에게 제품의 큰 방향성을 설명할 때 사용합니다. 기술적 세부 사항보다는 비즈니스 임팩트와 전략적 방향에 집중합니다.

5. 릴리스 로드맵 (Release)

마케팅·영업·고객 지원팀이 새 기능 출시 시점을 미리 파악하고 준비할 수 있게 해줍니다. 여러 팀 간 협업이 필요한 대규모 출시에 특히 유용합니다.

8. 핵심 용어 완벽 정리 — 로드맵 관련 필수 개념

마지막으로, 로드맵을 논의할 때 자주 등장하는 핵심 용어들을 정리합니다. 이 용어들을 명확히 이해하고 있어야 팀 내 커뮤니케이션이 원활해집니다. 프로덕트 라이프사이클과 함께 이해하면 더욱 풍부한 맥락을 가질 수 있습니다. 참고로 프로덕트 라이프사이클 완벽 가이드도 함께 읽어보시길 추천합니다.

용어	설명
로드맵(Roadmap)	제품의 비전과 전략을 바탕으로, 앞으로의 방향과 우선순위를 공유하는 커뮤니케이션 도구
비전(Vision)	3~5년 관점에서 '우리가 궁극적으로 무엇을 만들고 싶은가'를 정의한 방향성
전략(Strategy)	1년 내외 기간에 '올해 무엇에 집중할 것인가'를 선택하고 자원을 배분하는 의사결정
OKR	Objective(목표)와 Key Results(핵심 결과)로 목표 달성 여부를 측정하는 목표관리 체계
테마(Theme)	여러 문제/기회를 묶는 전략적 집중 영역(기능보다 문제 중심)
에픽(Epic)	여러 User Story로 분해되는 큰 작업 단위(보통 한 테마 내의 큰 기능 묶음)
RICE	Reach × Impact × Confidence ÷ Effort로 우선순위를 산정하는 프레임워크
ICE	Impact × Confidence × Ease로 빠르게 우선순위를 비교하는 간소화 프레임워크
MoSCoW	Must, Should, Could, Won't로 범주화하여 우선순위를 합의하는 방법
기술 부채(Tech Debt)	단기 속도를 위해 미뤄둔 품질/구조 개선 과제(누적되면 속도/안정성 저하)

마치며 — 로드맵은 살아있는 문서다

저는 이 글을 쓰면서 로드맵에 대한 저 자신의 이해가 얼마나 깊어졌는지 새삼 느낍니다. 처음에 엑셀 간트차트를 들고 갔던 주니어 시절부터, 지금은 비전과 전략을 기반으로 테마 단위로 로드맵을 설계하는 것이 당연하게 느껴지기까지, 꽤 긴 여정이었습니다.

로드맵의 핵심은 결국 "커뮤니케이션"입니다. 완벽한 일정표를 만드는 것보다, 팀 전체가 같은 방향을 바라보게 하는 것이 훨씬 중요합니다. 변경은 두려워할 것이 아니라, 새로운 인사이트가 반영된 신호로 받아들이세요.

공식 참고 자료로는 Atlassian의 Product Roadmap Guide (Atlassian)를 강력 추천합니다. 영문이지만 로드맵에 관한 가장 체계적인 공식 가이드입니다.

다음 글에서는 실제 Notion으로 Now-Next-Later 로드맵을 만드는 실습을 다루겠습니다. 이 시리즈의 다른 글도 함께 읽어보시면 도움이 됩니다:

애자일/스크럼 완벽 입문 — 기획자가 꼭 알아야 할 애자일 방법론 총정리

pokeylog — Wed, 29 Apr 2026 21:47:54 +0900

Photo by airfocus on Unsplash

저는 처음 기획자 공부를 시작했을 때, "애자일"이라는 단어를 정말 많이 들었습니다. 스타트업 채용공고에도, 현업 기획자 인터뷰에도 항상 나오는 단어였는데, 막상 찾아보면 "빠르게 일하는 방식" 정도로만 설명이 되어 있어서 구체적인 실체가 잘 와닿지 않았습니다. 이 글은 애자일/스크럼이 처음인 분, PM이나 서비스기획자를 준비하면서 면접에서 애자일을 어떻게 설명해야 할지 고민하신 분들을 위해 씁니다.

1. 애자일이 등장한 배경 — 계획대로만 가면 무슨 일이 생길까?

애자일을 이해하려면 먼저 기존 방식인 폭포수(Waterfall)의 한계를 알아야 합니다. 폭포수 방식은 요구사항 정의부터 배포까지 각 단계가 순차적으로 진행되며, 전 단계가 완료되어야 다음 단계로 넘어갈 수 있습니다.

폭포수(Waterfall) 방식 — 순차적 단방향 흐름

요구사항

➜

설계

➜

개발

➜

테스트

➜

배포

⚠️ 문제: 배포 직전에야 고객 피드백 가능! 수정 비용이 폭발적으로 증가!

요구사항이 매주 바뀌는 환경에서 3개월 뒤에 한 번만 결과물을 공개한다면 어떻게 될까요? 고객이 원한 것과 우리가 만든 것이 어긋났을 때, 이미 모든 비용이 소진된 후입니다. 이 문제를 해결하기 위해 2001년 17명의 개발자들이 모여 애자일 선언문(Agile Manifesto)을 발표했습니다. (참고: 공식 Agile Manifesto, Nielsen Norman Group - Agile for UX)

2. 애자일 선언문 4대 핵심 가치

저는 이 4가지 가치가 정말 단순하면서도 강력하다고 느꼈습니다. 오른쪽이 중요하지 않다는 게 아니라, 왼쪽을 더 우선한다는 뜻입니다.

✅ 더 우선하는 것	⚖️ 덜 중요하지 않지만 차선인 것
개인과 상호작용	프로세스와 도구
작동하는 소프트웨어	포괄적인 문서
고객과의 협력	계약 협상
변화에 대응	계획 따르기

핵심: 애자일은 "계획을 무시하자"가 아닙니다. "계획보다 변화에 더 잘 대응하자"는 것입니다.

3. 스크럼(Scrum) — 애자일 실천 프레임워크

애자일은 "철학"이고, 스크럼은 그 철학을 실천하는 "프레임워크"입니다. 스크럼을 처음 배울 때 제가 가장 많이 헷갈렸던 것이 방법론과 프레임워크의 차이였습니다.

구분	방법론 (Methodology)	프레임워크 (Framework)
정의	구체적인 방법과 절차 제공	구조와 규칙만 제공
특징	단계·절차·도구 비교적 고정	팀 상황에 맞게 유연 적용
예시	워터폴(Waterfall), RUP	스크럼(Scrum), 칸반(Kanban)

스프린트(Sprint) 사이클 — 2주가 한 사이클

스프린트 한 사이클 (2주 기준)

Sprint Planning

무엇을 할까?

⚡

개발 실행

+ Daily Scrum

Sprint Review

결과물 시연

Retrospective

프로세스 개선

↻ 완료 후 다음 스프린트로 반복

4. 스크럼 3대 역할(Roles)

스크럼에는 명확한 역할 구분이 있습니다. 저는 처음에 PO랑 PM이 같은 것인지 헷갈렸는데, 스크럼 맥락에서는 명확히 다릅니다.

Product Owner (PO)

무엇을 만들 것인가 결정
제품 백로그 관리 및 우선순위 결정
이해관계자 ↔ 개발팀 조율

"왜 이걸 만들어야 하는가"를 항상 설명할 수 있어야 한다

️

Scrum Master (SM)

스크럼 프로세스 코칭
장애물(Impediment) 제거
서번트 리더십 실천

팀의 상사가 아님 — 팀을 위해 일하는 사람

⚙️

Development Team

어떻게 만들 것인가 결정
자기 조직화(self-organizing)
교차 기능(cross-functional)
보통 3~9명

외부에서 작업 지시받지 않고 스스로 계획·실행

5. 스크럼 3대 산출물(Artifacts) — 무엇을 만들고 관리하는가?

세 가지 산출물이 서로 연결되어 작동하는 구조를 이해하면 스크럼의 전체 흐름이 한눈에 보입니다.

스크럼 3대 산출물 관계도

Product Backlog

모든 기능 목록
(PO 소유 · 우선순위 변경)

→

스프린트 계획 시 선택

Sprint Backlog

이번 스프린트 작업목록
(팀 소유)

→

스프린트 종료 시 산출

✅

Increment

동작하는 결과물
(잠재적 출시 가능)

Definition of Done(DoD)이란 기능이 "완료"됐다고 볼 수 있는 팀 내 합의 기준입니다. 예를 들어 "코드 리뷰 완료 + QA 통과 + 스테이징 배포"가 DoD라면, 이 세 가지가 모두 충족되어야 Increment로 인정됩니다.

6. 스크럼 5대 이벤트(Events) 상세 설명

스크럼에는 스프린트 안에서 반드시 진행되는 5가지 공식 이벤트가 있습니다. 각 이벤트의 목적을 명확히 이해하는 것이 중요합니다.

스프린트 이벤트 타임라인 (2주 스프린트 기준)

Sprint Planning (1일차)

무엇을(PO 주도) + 어떻게(팀 주도)를 계획

☀️

Daily Scrum (매일 15분)

어제/오늘/장애물 — 보고가 아닌 팀 동기화

Sprint Review (마지막날)

결과물 시연 + 피드백 수집 → 백로그 업데이트

Sprint Retrospective (리뷰 직후)

프로세스 개선 — 잘된 것/개선할 것/액션 아이템

⚠️ Daily Scrum은 보고 시간이 아닙니다. 목적은 팀 내 동기화이고, 초점은 장애물과 우선순위 조정에 있습니다.

7. 핵심 용어 총정리 — 면접에서 바로 쓰는 용어 사전

저도 처음엔 이 용어들이 너무 많아서 헷갈렸습니다. 맥락과 함께 이해하면 훨씬 잘 기억됩니다.

용어	설명	비유/예시
Velocity	팀이 한 스프린트에서 완료한 스토리 포인트 합계	팀의 평균 작업 처리 속도 — 다음 스프린트 계획의 기준
Story Point	작업의 상대적 복잡도·노력 단위 (시간이 아님)	옷 사이즈처럼 상대적: S/M/L, 1/2/3/5/8...
User Story	"나는 [사용자]로서 [목적]을 위해 [기능]을 원한다"	예: "구매자로서 주문 내역을 확인하고 싶다"
Epic	여러 User Story로 분해되는 큰 단위 기능	예: "결제 시스템" → 여러 개의 세부 User Story
Impediment	팀의 진행을 막는 장애물 (SM이 제거 지원)	예: 외부 API 응답 지연, 회의실 부족, 결정 미루기
Burndown Chart	스프린트 내 남은 작업량을 시각화한 그래프	이상적 선 vs 실제 선의 차이로 진행 현황 파악
WIP	현재 진행 중인 작업 (Work In Progress)	칸반에서는 WIP를 제한해서 집중도를 높임
MVP	핵심 가치를 검증할 수 있는 최소 기능 제품	완성품이 아닌, 가설 검증을 위한 최소 버전

8. 애자일 vs 폭포수 — 어느 상황에서 무엇을 써야 할까?

많은 분들이 "그럼 애자일이 항상 더 좋은 건가요?"라고 물어봅니다. 정답은 "상황에 따라 다릅니다"입니다. 이것이 기획자가 반드시 이해해야 할 관점입니다.

항목	폭포수(Waterfall)	애자일(Agile/Scrum)
계획	초기에 전체 계획 수립	반복적으로 계획 조정
요구사항	고정 (변경 어려움)	변화 허용 · 유연
결과물 공개	최종 완료 시 (한 번)	매 스프린트마다 (자주)
위험 관리	후반부에 발견 (비용 큼)	초기부터 지속 발견
고객 참여	초기·최종 중심	전 과정 지속 참여
팀 구조	기능별 분리 (사일로)	교차 기능 통합
적합 환경	요구사항 명확, 변화 없음	불확실성 높음, 빠른 피드백 필요

요구사항이 명확하고 변화가 없는 환경(예: 건설, 법적 규제 강한 분야)에서는 폭포수가 더 효율적일 수 있습니다. 기획자는 프로젝트 맥락에 맞는 방법론을 선택할 수 있어야 합니다.

9. 기획자를 위한 마무리 정리

저는 애자일을 공부하면서 가장 크게 느낀 것이 있습니다. 애자일은 단순히 "빠르게 일하는 것"이 아니라, "올바른 것을 빠르게 검증하는 것"에 가깝다는 점입니다. 기획자는 이 철학을 팀 전체가 이해하고 실천할 수 있도록 돕는 역할을 합니다.

이 글의 핵심 요약

애자일 = 짧은 반복 주기로 자주 피드백을 받는 철학
스크럼 = 애자일을 실천하는 가장 인기 있는 프레임워크
스프린트 = 1~4주 단위 반복 사이클 (보통 2주)
PO = 무엇을 / SM = 프로세스 코칭 / Dev Team = 어떻게
Backlog → Sprint Backlog → Increment 순으로 흘러감
애자일이 항상 정답은 아님 — 맥락에 맞는 방법론 선택이 중요

이 글과 함께 아래 관련 글들도 읽어보시면 기획자로서의 역량을 더 넓힐 수 있습니다.

비즈니스 모델 캔버스(BMC) 완벽 가이드 — 기획자가 꼭 알아야 할 9개 블록 총정리

pokeylog — Wed, 29 Apr 2026 09:48:52 +0900

Photo by Campaign Creators on Unsplash

저는 처음 기획 직군으로 이직 준비를 할 때 "BMC를 그려오세요"라는 과제를 받은 적이 있습니다. 그때 처음 비즈니스 모델 캔버스를 접했는데, 9개의 박스가 뭘 의미하는지도 모른 채 그냥 채웠던 기억이 납니다. 실무에 들어가고 나서야 비로소 BMC가 얼마나 강력한 커뮤니케이션 도구인지 깨달았어요. 팀원 간 사업 구조에 대한 인식을 맞추는 데 이만큼 효과적인 프레임워크가 없더라고요. 이 글에서는 기획자, PM, 주니어 기획자분들이 실무에서 BMC를 자신 있게 사용할 수 있도록 9개 블록의 개념부터 연결 구조, 실수 교정 포인트까지 완벽하게 정리해드립니다.

1. 비즈니스 모델 캔버스(BMC)란 무엇인가?

비즈니스 모델 캔버스(Business Model Canvas, BMC)는 복잡한 사업 구조를 9개 블록으로 시각화한 전략 프레임워크입니다. 2010년 알렉산더 오스터왈더(Alexander Osterwalder)가 『Business Model Generation』이라는 책에서 소개한 이후, 전 세계 스타트업과 대기업의 공통 전략 언어가 되었습니다. (Strategyzer 공식 BMC 가이드 참고)

BMC의 목적은 두 가지입니다. 첫째, 복잡한 사업 구조를 한 장으로 파악하는 것. 둘째, 팀 간 공통 언어를 만드는 것입니다. 저는 팀 미팅에서 BMC를 화이트보드에 그려두고 논의하면, 각자 다른 맥락으로 이야기하다가도 "이게 VP야, CS야?"라는 질문 하나로 대화가 정렬되는 경험을 자주 합니다. BMC를 한 마디로 표현하자면 이렇습니다. "사업계획서가 소설이라면, BMC는 설계도다."

2. BMC 9개 블록 — 시각적 구조 한눈에 보기

BMC는 크게 왼쪽 '운영 영역'과 오른쪽 '시장 영역', 그리고 중앙의 '가치 제안'으로 나뉩니다. 아래 시각화 도표를 통해 전체 구조를 먼저 파악해보세요.

KP 핵심 파트너십 Key Partners	⚙️ KA 핵심 활동 Key Activities	VP 가치 제안 Value Propositions ▶ 핵심 중심축	❤️ CR 고객 관계 Customer Relationships	CS 고객 세그먼트 Customer Segments
	KR 핵심 자원 Key Resources		CH 채널 Channels
C$ 비용 구조 (Cost Structure)			RS 수익 흐름 (Revenue Streams)

▲ 비즈니스 모델 캔버스 9개 블록 구조도 (직접 제작)

3. 9개 블록 상세 해설 — 오른쪽 시장 영역 (CS·VP·CH·CR·RS)

BMC를 처음 배울 때는 오른쪽 시장 영역부터 이해하는 것이 쉽습니다. 고객 관련 블록들이 직관적이기 때문입니다.

① CS — 고객 세그먼트 (Customer Segments)
가치를 제공하는 대상 고객 집단을 정의합니다. 핵심 질문은 "우리는 누구를 위해 존재하는가?"입니다. 유형은 매스마켓, 니치마켓, 세그먼트, 다면 플랫폼 등으로 나뉩니다. 중요한 포인트는 세그먼트가 다르면 VP도 달라져야 한다는 것입니다. CS와 VP는 항상 짝으로 설명해야 합니다.

② VP — 가치 제안 (Value Propositions)
고객의 문제를 해결하거나 니즈를 충족시키는 제공 가치입니다. 핵심 질문은 "우리는 고객에게 무엇을 제공하는가?"입니다. 유형에는 신규성, 성능 향상, 커스터마이징, 편의성, 가격 경쟁력, 위험 절감 등이 있습니다. 주의할 점은 VP를 "기능"이 아니라 고객이 얻는 결과로 서술해야 한다는 것입니다. "앱 제공"이 아니라 "언제 어디서든 5분 안에 식사를 주문할 수 있는 편의"처럼요.

③ CH — 채널 (Channels)
고객에게 가치를 전달하는 접점입니다. 인지 → 평가 → 구매 → 전달 → 사후 서비스의 5단계 여정을 커버합니다. 핵심 질문은 "어떻게 고객에게 닿는가?"입니다.

④ CR — 고객 관계 (Customer Relationships)
고객 세그먼트와 맺는 관계의 유형입니다. 개인 지원, 셀프 서비스, 자동화, 커뮤니티, 공동 창출 등이 있습니다. 목적 관점에서는 획득(Acquisition), 유지(Retention), 업셀링(Upselling)으로 구분합니다.

⑤ RS — 수익 흐름 (Revenue Streams)
고객으로부터 발생하는 수익입니다. 판매, 구독, 라이선싱, 광고, 중개 수수료 등 다양한 유형이 있습니다. RS는 단순히 '판매'로 적는 것보다 구체적인 수익 모델을 탐색하는 것이 중요합니다.

4. 9개 블록 상세 해설 — 왼쪽 운영 영역 (KR·KA·KP·C$)

⑥ KR — 핵심 자원 (Key Resources)
비즈니스 모델이 작동하는 데 필요한 핵심 자산입니다. 물리적 자원(공장·장비), 지적 자원(특허·브랜드·데이터), 인적 자원(전문 인력), 재무 자원(현금·신용)으로 나뉩니다. 포인트는 VP를 실현하기 위해 반드시 있어야 하는 것이 KR이라는 점입니다.

⑦ KA — 핵심 활동 (Key Activities)
비즈니스 모델을 실행하기 위한 핵심 과업입니다. 생산, 문제 해결, 플랫폼·네트워크 운영으로 분류합니다. KR과 KA를 혼동하는 경우가 많은데, 간단히 기억하세요. "자원은 명사, 활동은 동사"입니다.

⑧ KP — 핵심 파트너십 (Key Partnerships)
비즈니스 모델이 작동하도록 돕는 외부 파트너 네트워크입니다. 전략적 제휴, 조인트 벤처, 공급자 관계가 있습니다. 파트너십의 동기는 리스크 감소, 규모의 경제, 자원·활동 확보 등입니다.

⑨ C$ — 비용 구조 (Cost Structure)
비즈니스 모델 운영에 발생하는 모든 비용입니다. 고정비와 변동비로 나뉘며, 비용 중심(저원가 추구)과 가치 중심(프리미엄 추구)으로 지향점이 다를 수 있습니다. 중요한 포인트는 비용구조는 KR + KA + KP에서 도출된다는 것입니다. 비용구조를 모르면 수익성 판단이 불가능합니다.

5. BMC 블록 간 연결 구조 — VP가 중심이다

BMC의 진짜 힘은 9개 블록이 독립적으로 존재하는 게 아니라 유기적으로 연결된다는 점입니다. 중심에는 항상 VP(가치 제안)가 있습니다.

[왼쪽: 운영 영역]                       [오른쪽: 시장 영역]
KP → KA → KR                          CS ← CH ← CR
            ↓                                        ↓
        VP ←―――――――――――――――――→ VP
            ↓                                        ↓
        C$                                           RS

이 연결 구조를 이해하면 BMC의 정합성을 검증할 수 있습니다. 예를 들어, "이 VP를 만들려면 어떤 KR이 반드시 필요한가?", "RS를 늘리려면 CH를 어떻게 바꿔야 하는가?" 같은 질문을 할 수 있게 됩니다. 저는 서비스 기획 업무를 할 때 새로운 기능을 추가할 때마다 BMC의 해당 블록에 어떤 영향을 주는지 체크하는 습관을 들였는데, 이게 의도하지 않은 사이드 이펙트를 사전에 발견하는 데 큰 도움이 됐습니다.

6. 실전 BMC 예시 — 배달의민족 적용

이론만으로는 이해하기 어려우니, 국내에서 가장 친숙한 서비스 중 하나인 배달의민족을 예시로 BMC를 채워보겠습니다. 실제 공식 BMC가 아닌, 공개된 정보를 기반으로 한 학습용 예시입니다.

블록	배달의민족 적용 예시
CS (고객 세그먼트)	①음식 주문 소비자 ②음식점 사장님 (다면 플랫폼)
VP (가치 제안)	소비자: 집에서 빠르고 편리한 음식 주문 / 사장님: 온라인 주문 채널 확보 + 마케팅
CH (채널)	앱, 웹사이트, TV/온라인 광고, B마트 오프라인 픽업
CR (고객 관계)	셀프서비스 + 자동화(리뷰·추천) + 구독(배민클럽)
RS (수익 흐름)	중개 수수료, 광고비(울트라콜·오픈리스트), 구독료
KR (핵심 자원)	앱/플랫폼 기술, 사용자 데이터, 브랜드, 배달 네트워크
KA (핵심 활동)	플랫폼 개발·운영, 식당 모집/온보딩, 마케팅
KP (핵심 파트너십)	음식점 파트너, PG사(결제), 배달 라이더(자체+외부)
C$ (비용 구조)	플랫폼 운영비, 마케팅비, 배달 인프라비, 인건비

7. 주니어 기획자가 자주 하는 실수 5가지

제가 현업에서 주니어 분들의 BMC를 검토하면서 반복적으로 발견한 실수들을 정리했습니다. 이 부분을 미리 알고 있으면 처음부터 훨씬 좋은 BMC를 그릴 수 있습니다.

실수 유형	잘못된 예	올바른 방향
VP를 기능으로 작성	"앱 제공", "API 연동"	"고객이 얻는 결과"로 바꿔 서술
CS를 너무 광범위하게 설정	"모든 사람", "20~40대"	구체적 페르소나로 좁히기
KA와 KR 혼동	자원과 활동을 구분 못함	"자원은 명사, 활동은 동사"로 구분
RS를 단순 '판매'로만 기재	수익 구조 단순화	구독·광고·수수료 등 유형 탐색
블록 간 연결 없이 독립 작성	캔버스 정합성 부족	"이 VP를 만들려면 어떤 KR이?" 질문

8. BMC 작성 3단계 실전 가이드

지금 당장 BMC를 처음 그려야 한다면 이 순서를 따라보세요. 저는 새로운 서비스를 분석하거나 기획할 때 항상 이 순서로 시작합니다.

1단계: CS와 VP부터 — 먼저 "누구에게(CS)" "무엇을 제공하는가(VP)"를 명확히 합니다. 이 두 블록이 흔들리면 나머지 7개도 불안정해집니다. CS는 페르소나 수준으로 구체화하고, VP는 "고객이 얻는 결과" 중심으로 서술하세요.

2단계: 오른쪽 시장 영역 완성 — CS-VP를 기반으로 CH(어떻게 전달?), CR(어떤 관계?), RS(어떻게 수익화?)를 채웁니다. 이 단계에서 수익 모델을 단순화하지 말고 다양한 RS 유형을 탐색해보세요.

3단계: 왼쪽 운영 영역 완성 + 정합성 검증 — VP를 실현하기 위해 필요한 KR, KA, KP를 채우고, 그에 따른 C$를 도출합니다. 마지막으로 "RS - C$ = 수익성"이 성립하는지 논리적으로 검증합니다.

BMC를 더 잘 활용하려면 서비스 기획의 전반적인 흐름을 이해하는 것이 중요합니다. 서비스기획자의 역할과 책임과 프로덕트 라이프사이클 완벽 가이드도 함께 읽어보시면 BMC가 실무에서 어떻게 활용되는지 더 잘 이해할 수 있습니다. 또한 BMC에서 설정한 목표를 실행하기 위한 방법으로는 OKR과 KPI 목표 설정 프레임워크가 강력한 도구가 됩니다.

마무리 — BMC는 한 번 그리고 끝이 아니다

BMC의 진짜 가치는 완성된 결과물이 아니라, 팀이 함께 채우는 과정에 있습니다. 각 블록을 채우면서 나오는 논쟁과 토론, "이 CS는 정말 우리 타겟이 맞나?", "이 RS는 지속 가능한가?" 같은 질문들이 사업의 약점을 드러내고 전략을 정교하게 만들어 줍니다.

저는 지금도 새로운 서비스 아이디어가 생기면 노션에 BMC 템플릿을 열어 가장 먼저 채워봅니다. 30분도 안 걸리지만, 그 과정에서 생각하지 못했던 구멍이 반드시 하나씩 발견됩니다. BMC를 한 번 그려보고 끝내지 말고, 서비스가 성장함에 따라 주기적으로 업데이트해보세요. 그것이 진짜 전략적 사고의 시작입니다.

참고 자료: Strategyzer - The Business Model Canvas | Alexander Osterwalder, 『Business Model Generation』(2010)

OKR과 KPI 완벽 가이드 — 기획자가 꼭 알아야 할 목표 설정 프레임워크

pokeylog — Wed, 29 Apr 2026 09:24:16 +0900

Photo by Jason Goodman on Unsplash

저는 처음 기획팀에 합류했을 때 OKR과 KPI라는 단어를 하루에도 수십 번씩 들었습니다. 그런데 이상하게도 두 개념의 차이를 명확히 설명하는 사람이 없었어요. 어떤 분은 "OKR이 더 고급 KPI야"라고 하고, 어떤 분은 "KPI는 구식이고 OKR이 최신 트렌드야"라고 했습니다. 저도 한동안 혼란스러웠지만, 실제 프로젝트에서 두 프레임워크를 모두 써보면서 비로소 차이를 체감할 수 있었습니다. 이 글에서는 기획자, PM, 주니어 기획자분들이 실무에서 바로 활용할 수 있도록 OKR과 KPI의 개념부터 설정 방법, 실전 예시까지 완벽하게 정리해드리겠습니다.

1. KPI란 무엇인가? — "우리가 잘 하고 있는가?"를 측정하는 도구

KPI(Key Performance Indicator)는 조직·팀·개인이 목표를 얼마나 잘 달성하고 있는지를 측정하는 핵심 성과 지표입니다. 어원을 살펴보면 Key(가장 중요한 것만), Performance(성과·결과), Indicator(수치화된 기준)가 합쳐진 단어입니다. 즉, 수많은 지표 중에서도 "가장 핵심적인 것만 뽑아서 수치로 추적하겠다"는 의미를 담고 있습니다.

KPI의 핵심 특징은 다음과 같습니다. 먼저 정량적 수치로 표현됩니다. "고객 만족도를 높인다"처럼 모호한 표현은 KPI가 될 수 없습니다. 반드시 "월간 NPS 점수 +10점"처럼 측정 가능한 숫자여야 합니다. 또한 이미 정해진 방향(전략) 안에서 성과를 측정하기 때문에, 주기적 모니터링(주간·월간·분기)이 가능하고 달성 여부가 명확합니다.

KPI의 함정: 굿하트의 법칙

KPI를 설정할 때 반드시 알아야 할 경고가 있습니다. 영국 경제학자 찰스 굿하트는 이렇게 말했습니다. "측정 지표가 목표가 되면, 더 이상 좋은 지표가 아니다." 예를 들어 고객 응대 건수를 KPI로 잡으면, 팀원들이 빠르게 통화를 끝내는 행동이 늘어납니다. 앱 다운로드 수를 KPI로 설정하면, 실제 활성 사용자는 늘지 않아도 숫자만 올리는 방향으로 움직일 수 있습니다. 저는 이 문제를 팀에서 직접 경험한 적이 있어요. 앱 리뷰 수를 KPI로 잡았더니 고객 경험보다 리뷰 유도 팝업을 남발하는 상황이 벌어진 것입니다.

2. KPI 설정 원칙: SMART 프레임워크

좋은 KPI를 만들기 위한 가장 검증된 방법은 SMART 원칙을 적용하는 것입니다. SMART는 Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant(목표 연관성), Time-bound(기한 설정)의 약자입니다.

원칙	설명	나쁜 예 → 좋은 예
Specific	구체적인가?	"매출 향상" → "신규 고객 월 매출 5천만원"
Measurable	측정 가능한가?	"만족도 향상" → "NPS +10점"
Achievable	현실적으로 가능한가?	현재 자원과 기간을 고려한 수준 설정
Relevant	목표와 연관이 있는가?	비즈니스 방향과 직접 연결되는 지표
Time-bound	기한이 있는가?	"언젠가" → "Q3(7~9월) 내 달성"

SMART 원칙은 1981년 조지 도란이 Management Review에서 처음 제시한 개념으로, 현재도 전 세계 기업에서 가장 널리 쓰이는 목표 설정 프레임워크입니다. (MindTools - SMART Goals 참고)

3. OKR이란 무엇인가? — "우리가 옳은 방향으로 가고 있는가?"를 확인하는 도구

OKR(Objectives and Key Results)은 조직이 달성하려는 목표(Objective)와 그 목표 달성을 확인하는 핵심 결과(Key Results)로 구성된 목표 관리 프레임워크입니다. 1970년대 인텔의 앤디 그로브가 창안하고, 구글의 초기 투자자 존 도어가 구글에 도입하면서 세계적으로 유명해졌습니다. 현재는 구글, 에어비앤비, 스포티파이, 링크드인 등 수천 개 기업이 사용하고 있습니다. (Google re:Work - OKR 가이드)

OKR의 구조를 비유로 설명하면 이렇습니다. 등산을 계획한다고 생각해보세요. Objective는 "한라산 정상에 오른다"는 방향과 의미 있는 목표입니다. Key Results는 "8월까지 주 3회 10km 트레킹", "체력 테스트 심박수 130bpm 유지", "등산 장비 완비"처럼 정상에 도달했음을 증명하는 구체적인 결과 지표입니다. KPI가 "지금 몇 km 걸었는가?"를 추적한다면, OKR은 "우리가 정상을 향해 제대로 나아가고 있는가?"를 묻는 것입니다.

OKR의 70% 법칙

OKR에서 가장 중요한 특징 중 하나는 달성률에 대한 철학입니다. OKR의 창시자 앤디 그로브는 이렇게 말했습니다. "KR을 100% 달성했다면 목표가 너무 낮았던 것이다. 70%가 이상적이다." 이는 OKR이 도전적인 목표를 지향하기 때문입니다. 100% 달성을 전제로 설계된 KPI와 달리, OKR은 약간 불가능해 보이는 수준의 목표를 세우도록 권장합니다. 저는 처음 이 개념을 접했을 때 "실패를 장려하는 건가?"라는 의문이 들었지만, 실제로 도전적인 목표를 세웠을 때 팀의 창의성과 몰입도가 확연히 높아지는 것을 경험했습니다.

4. OKR vs KPI 한눈에 비교 — 무엇이 다른가?

많은 기획자들이 OKR과 KPI를 혼용하거나 둘 중 하나만 사용합니다. 하지만 두 프레임워크는 서로 다른 역할을 하므로 함께 사용할 때 시너지가 납니다. 아래 비교표를 보시면 한눈에 차이를 이해하실 수 있습니다.

항목	OKR	KPI
목적	방향 설정, 우선순위 정렬	성과 모니터링, 운영 관리
성격	도전적, 야심차게 설정	현실적, 달성 가능하게 설정
달성률	70%가 이상적	100% 달성이 목표
주기	분기 단위 설정	주간/월간/분기 모니터링
평가 연동	원칙적으로 분리	평가·보상과 연동 가능
변경	분기 내 고정	상황에 따라 조정 가능
공개 범위	전사 공개(투명성)	팀/조직 내부

5. 실전 OKR 작성 예시 — 기획자 관점

이론만으로는 감이 잡히지 않죠. 제가 실제로 작성해봤던 OKR 예시를 공유해드리겠습니다. 이커머스 앱의 신규 기획자라고 가정해보겠습니다.

Objective: 사용자가 우리 앱에서 더 즐겁고 빠르게 쇼핑을 완료하도록 만든다.

Key Result 1: 장바구니 이탈률을 현재 62%에서 45%로 낮춘다. (측정: GA4 Funnel 분석)
Key Result 2: 결제 완료까지의 평균 탭 수를 7개에서 4개로 줄인다. (측정: UX 플로우 분석)
Key Result 3: 앱스토어 평점을 3.8에서 4.3으로 높인다. (측정: 앱스토어 콘솔)

이 OKR에서 주목할 점은 각 Key Result가 구체적인 숫자와 측정 방법을 포함하고 있다는 것입니다. 또한 Objective는 "사용자 중심"의 방향성을 담고 있어 팀이 공감할 수 있는 의미 있는 목표입니다. 저는 이런 OKR을 팀 전체가 볼 수 있는 노션 보드에 게시했을 때, 팀원들의 자발적인 아이디어 제안이 눈에 띄게 늘어났습니다.

6. OKR 레벨 구조와 계단식 정렬

잘 설계된 OKR 시스템은 회사 전체 방향과 개인의 업무가 연결됩니다. 이를 OKR의 계단식(Cascade) 구조라고 합니다. 회사 레벨 OKR이 가장 위에 있고, 그 아래 팀 레벨 OKR, 그리고 개인 레벨 OKR이 위계적으로 연결됩니다. 예를 들어 회사 OKR의 Objective가 "올해 국내 1위 이커머스 앱이 된다"라면, 기획팀의 OKR은 "사용자 경험 최상위 수준 달성", 마케팅팀의 OKR은 "신규 유저 획득 200% 성장"처럼 각자의 역할에 맞게 설계됩니다.

이 방식의 장점은 모든 구성원이 자신의 업무가 회사 전체 방향과 어떻게 연결되는지 알 수 있다는 점입니다. 서비스 기획을 처음 시작하는 주니어분들께 특히 중요한 개념입니다. 내가 왜 이 기능을 기획하는지, 이 스펙이 어떤 OKR에 기여하는지 이해하면 업무 몰입도가 완전히 달라집니다. 관련해서 서비스기획자의 역할과 책임에 대한 글도 함께 읽어보시면 도움이 됩니다.

7. OKR과 KPI를 함께 사용하는 법 — 실무 조합 전략

가장 효과적인 방법은 OKR로 방향을 잡고 KPI로 일상적인 운영을 관리하는 것입니다. 비유하자면 OKR은 "GPS 목적지 설정"이고, KPI는 "연료 게이지, 속도계, 엔진 온도계"입니다. 목적지(OKR)를 설정했다면, 여행 중에는 계속해서 계기판(KPI)을 확인하며 문제가 없는지 체크해야 합니다.

실무에서 저는 이런 방식으로 두 프레임워크를 조합합니다. 분기 초에 팀 OKR을 설정하고, 매주 월요일 스탠드업 미팅에서 관련 KPI 수치를 리뷰합니다. KPI가 목표치에서 크게 벗어날 경우, 해당 OKR Key Result를 달성하기 위한 이니셔티브(실행 과제)를 점검합니다. 이 과정에서 프로덕트 라이프사이클 관리와 연계하면 더욱 체계적인 성과 관리가 가능합니다.

8. 주요 용어 정리 — OKR 실무 어휘집

OKR을 처음 접하는 분들이 헷갈려하는 용어들을 정리했습니다. Objective는 달성하려는 질적 목표로 방향과 의미를 담습니다. Key Result는 목표 달성을 증명하는 측정 가능한 결과 지표입니다. Initiative는 KR 달성을 위한 구체적 실행 과제입니다. Check-in은 OKR 진행 상황을 주기적으로 점검하는 활동으로 주간 단위를 권장합니다. Moonshot OKR은 불가능해 보이지만 도전하는 극도로 야심찬 OKR이고, Roofshot OKR은 달성 가능하면서도 도전적인 OKR입니다. Leading Indicator는 미래 성과를 예측하는 선행 지표이며, Lagging Indicator는 이미 발생한 결과를 나타내는 후행 지표입니다.

9. 초보자를 위한 첫 OKR 작성 3단계

지금 당장 OKR을 처음 작성해야 하는 분들을 위해 3단계 가이드를 드립니다.

1단계: Why 질문하기 — "이번 분기 가장 중요한 문제가 무엇인가?" "만약 한 가지만 해결한다면?" 이 질문에서 Objective가 나옵니다.

2단계: 증거 찾기 — Objective를 달성했다면 어떤 숫자가 바뀌어야 할까요? 3~5개의 측정 가능한 지표가 Key Results가 됩니다. "만약 O를 달성한다면, 우리는 ___를 볼 것이다"라는 문장으로 완성해보세요.

3단계: 검증하기 — SMART 체크리스트를 적용해 각 KR이 구체적이고, 측정 가능하고, 달성 가능하고, 연관성 있고, 기한이 있는지 확인합니다.

애자일 방법론을 활용한 목표 실행 방법이 궁금하다면 애자일/스크럼 완벽 입문 가이드도 참고해보세요. OKR의 분기 주기와 애자일의 스프린트를 결합하면 매우 강력한 실행 시스템을 만들 수 있습니다.

마무리 — OKR과 KPI, 함께 써야 강하다

이 글을 정리하면, KPI는 "우리가 잘 하고 있는가?"를 측정하고, OKR은 "우리가 옳은 방향으로 가고 있는가?"를 확인합니다. 둘 중 하나만 쓰면 반드시 불균형이 생깁니다. KPI만 있으면 열심히 하지만 엉뚱한 방향으로 가고, OKR만 있으면 큰 그림은 있지만 일상적인 성과 관리가 느슨해집니다.

처음에는 복잡하게 느껴지더라도, 팀 또는 본인의 업무에 작게 적용해보는 것을 추천드립니다. 한 분기만 직접 써보면 두 프레임워크의 차이와 효용을 몸으로 이해할 수 있을 거예요. 저도 처음 OKR을 도입했을 때 온갖 시행착오가 있었지만, 지금은 기획 업무에서 빠질 수 없는 나침반이 됐습니다.

다음 글에서는 OKR을 실제 노션 템플릿으로 구현하는 방법을 소개해드릴 예정입니다. 서비스기획 관련 더 많은 글은 PM study 블로그에서 확인하실 수 있습니다.

참고 자료: Google re:Work - OKR 소개 | MindTools - SMART Goals

프로덕트 라이프사이클 완벽 가이드 — 도입기부터 쇠퇴기까지 기획자가 알아야 할 모든 것

pokeylog — Tue, 28 Apr 2026 15:47:57 +0900

Photo by Carlos Muza on Unsplash

저는 처음 서비스기획을 공부하기 시작했을 때, "서비스를 잘 만들면 그냥 계속 성장하는 거 아닌가?"라고 순진하게 생각했습니다. 그런데 실제로 공부를 하고 케이스를 들여다보면, 한때 잘나가던 서비스도 어느 순간 쇠퇴하고, 심지어 문을 닫는 경우가 많다는 걸 알게 됐습니다. 그 흐름을 이해하는 핵심 개념이 바로 프로덕트 라이프사이클(Product Life Cycle, PLC)입니다.

이 글은 서비스기획자 혹은 PM을 준비하는 분들, 그리고 "우리 서비스 지금 어느 단계지?"를 고민하는 현업 실무자분들을 위해 작성했습니다. 노션에서 정리한 수업 내용을 바탕으로 실무에서 바로 쓸 수 있는 개념들을 최대한 쉽게 풀어드릴게요.

1. 왜 프로덕트 라이프사이클을 알아야 할까?

서비스는 출시했다고 끝나는 것이 아닙니다. 시간이 지나면서 사용자의 반응, 시장 상황, 경쟁 환경, 수익 구조가 계속 달라집니다. 저는 이걸 처음 배웠을 때 마치 사람의 일생과 비슷하다고 느꼈습니다. 태어나서(도입기), 학교 다니며 성장하고(성장기), 직장에서 안정적으로 일하다가(성숙기), 은퇴 후 조용히 마무리하는(쇠퇴기) 흐름처럼요.

서비스기획자가 이 흐름을 이해해야 하는 이유는 명확합니다. 같은 기능 개선이라도 서비스의 단계에 따라 우선순위가 완전히 달라지기 때문입니다.

도입기에는 "이 서비스가 정말 시장에서 먹히는가?"를 검증하는 것이 최우선입니다.
성장기에는 "새로운 사용자를 확보하는 것만큼, 기존 사용자가 떠나지 않는가?"가 중요합니다.
성숙기에는 "더 많이 성장하기보다, 어떻게 더 효율적으로 수익을 만들 것인가?"를 고민합니다.
쇠퇴기에는 "버틸 것인가, 방향을 바꿀 것인가, 종료할 것인가?"를 결정해야 합니다.

즉, PLC를 모르면 맞지 않는 시기에 맞지 않는 전략을 쓰는 실수를 범할 수 있습니다.

2. 프로덕트 라이프사이클 4단계 한눈에 보기

프로덕트 라이프사이클은 보통 다음 네 단계로 나뉩니다.

도입기 → 성장기 → 성숙기 → 쇠퇴기

각 단계를 한눈에 비교하면 다음과 같습니다.

단계	사용자 곡선	기획자 우선순위	핵심 지표
도입기	완만한 상승	PMF 탐색, 핵심 기능 검증	활성 사용자, 피드백 품질
성장기	급격한 상승	리텐션, 차별화, 기능 확장	DAU, MAU, 리텐션율
성숙기	완만한 수평	수익 최적화, 사용자 세분화	LTV, ARPU, 시장 점유율
쇠퇴기	하락	피벗 판단 또는 종료 준비	이탈률, MAU 감소율

3. 각 단계 상세 분석 — 기획자가 해야 할 일

도입기 (Introduction) — PMF를 찾아라

도입기는 서비스가 처음 시장에 출시된 시기입니다. 이 시기에는 아직 많은 사용자가 서비스를 알지 못하고, 주로 새로운 것을 빨리 써보는 얼리 어답터(Early Adopter)들이 먼저 사용합니다.

도입기의 특징은 다음과 같습니다. 사용자 인지도가 낮고 천천히 증가하며, 수익보다 비용이 더 클 수 있습니다. 또한 사용자가 무엇을 좋아하고 불편해하는지 빠르게 확인해야 하고, 핵심 기능이 시장에서 통하는지 검증해야 합니다.

기획자의 핵심 역할: PMF(Product-Market Fit) 탐색

도입기 핵심 질문: "이 서비스가 없어지면 사용자가 정말 아쉬워할까?"

PMF를 찾기 전에는 무리하게 성장에 투자하기보다, 사용자의 문제를 제대로 해결하고 있는지 먼저 확인해야 합니다. 돈을 써서 사용자를 데려왔더니 금방 다 나가버리면 아무 의미가 없으니까요.

성장기 (Growth) — 리텐션을 잡아라

성장기는 사용자가 빠르게 늘어나는 시기입니다. 서비스가 시장에서 반응을 얻고, 사람들이 점점 더 많이 사용하기 시작합니다. 이 시기에는 경쟁자도 등장하기 시작합니다.

성장기의 특징은 사용자 수의 급격한 증가, 시장 인지도 상승, 수익 발생 시작, 경쟁 서비스 등장, 기능 확장과 안정성의 중요성 증가입니다.

기획자의 핵심 역할: 리텐션(Retention) 관리

성장기에서 기획자가 자주 하는 실수는 "신규 사용자 숫자"에만 집중하는 것입니다. 물이 들어오는 만큼 나가버리면 성장이 아닙니다. 사용자가 계속 남아 있는지, 이탈하는 지점은 어디인지를 면밀히 분석해야 합니다.

성장기에서 주로 활용하는 전략이 성장 해킹(Growth Hacking)입니다. A/B 테스트, 바이럴 루프, 온보딩 개선, 추천 프로그램, 가입 전환율 개선 등이 대표적인 방법입니다.

성숙기 (Maturity) — 효율과 수익을 극대화하라

성숙기는 서비스의 성장 속도가 느려지고 시장 점유율이 안정되는 시기입니다. 사용자 수가 폭발적으로 늘지는 않지만, 일정한 규모의 사용자를 확보한 상태입니다.

성숙기의 특징은 사용자 증가 둔화, 시장 점유율 안정, 치열한 경쟁, 수익성 개선 필요, 사용자 세분화(Segmentation)의 중요성 증가입니다.

기획자의 핵심 역할: 수익 최적화와 사용자 세분화

성숙기에는 "더 많이 성장하자"보다 "어떻게 더 효율적으로 운영하고 수익을 만들 것인가"가 중요합니다. LTV(Lifetime Value)와 ARPU(Average Revenue Per User)가 핵심 지표로 부상합니다.

쇠퇴기 (Decline) — 데이터로 판단하라

쇠퇴기는 사용자 수와 매출이 줄어드는 시기입니다. 중요한 것은 쇠퇴기가 곧 실패를 의미하지는 않는다는 점입니다. 기술 변화, 대체 서비스 등장, 사용자 니즈 변화 등 다양한 이유로 쇠퇴기에 들어갈 수 있습니다.

쇠퇴기의 특징은 사용자 수 감소, 매출 감소, 이탈률 증가, 기존 기능의 매력 약화, 서비스 방향 재검토 필요입니다.

기획자의 핵심 역할: 감정이 아닌 데이터로 결정하기

쇠퇴기에서 기획자가 가장 경계해야 할 것은 감정적으로 버티는 것입니다. 데이터를 보고 냉정하게 판단해야 합니다. 선택지는 크게 두 가지입니다. 하나는 핵심 자산을 유지하면서 방향을 바꾸는 피벗(Pivot)이고, 다른 하나는 서비스를 종료 또는 축소하는 것입니다. 전략적인 종료도 훌륭한 기획자의 결정이 될 수 있습니다.

4. 핵심 지표와 용어 완벽 정리

저는 이 용어들을 처음 접했을 때 영어 약자들이 너무 많아서 헷갈렸는데, 하나씩 뜯어보면 어렵지 않습니다. 단계별로 어떤 지표를 봐야 하는지 함께 정리해드립니다.

용어	풀이	쉬운 설명	주로 사용하는 단계
PMF	Product-Market Fit	이 서비스가 시장의 니즈를 잘 충족하는 상태	도입기
리텐션	Retention	사용자가 서비스를 계속 다시 사용하는 비율	성장기
LTV	Lifetime Value	한 사용자가 서비스 이용 전체 기간에 만드는 수익 합계	성숙기
CAC	Customer Acquisition Cost	신규 고객 1명을 확보하는 데 드는 비용	성장기/성숙기
ARPU	Average Revenue Per User	사용자 1명당 평균 매출	성숙기
번 레이트	Burn Rate	서비스 운영에 매달 소진되는 비용	도입기/성장기
피벗	Pivot	핵심 자산을 유지하면서 전략적으로 방향을 바꾸는 것	쇠퇴기

LTV vs CAC — 수익성 판단의 핵심 공식

기획자가 꼭 이해해야 하는 계산 예시를 하나 들어볼게요.

항목	예시 A (건강한 서비스)	예시 B (위험한 서비스)
월 구독료	10,000원	10,000원
평균 이용 기간	24개월	3개월
LTV	240,000원	30,000원
CAC	50,000원	50,000원
LTV/CAC 비율	4.8배 ✅ 건강	0.6배 ❌ 위험

일반적으로 LTV가 CAC의 3배 이상이 되어야 지속 가능한 서비스로 봅니다. 예시 B처럼 CAC보다 LTV가 낮으면, 사용자를 데려올수록 오히려 손해를 보는 구조입니다.

5. 실제 서비스로 단계 판단하기

서비스의 단계를 판단할 때는 단순히 "유명한가?"만 보면 안 됩니다. 제가 공부하면서 실제 서비스 케이스를 분석해보니, 다음과 같이 정리할 수 있었습니다.

서비스	추정 단계	판단 이유
카카오톡	성숙기	이미 많은 사용자를 확보했고 생활 인프라처럼 자리 잡음
인스타그램	성숙기	성장 속도는 예전보다 둔화되었지만 강한 사용자 기반 보유
클럽하우스	쇠퇴기	초기에 빠르게 주목받았으나 이후 사용자 관심과 사용량이 감소

단, 서비스의 단계는 국가, 사용자층, 기능 영역에 따라 다르게 해석될 수 있습니다. 중요한 것은 정답을 맞히는 것이 아니라 근거를 가지고 판단하는 것입니다.

실제로 면접 준비를 하거나 케이스 스터디를 할 때, "이 서비스는 현재 어느 단계에 있나요? 그 근거는 무엇인가요?"라는 질문에 명확하게 답할 수 있으면 큰 강점이 됩니다.

6. 자주 하는 오해 — 라이프사이클에 대한 흔한 착각

이 부분은 저도 처음에 헷갈렸던 부분들입니다. 정확하게 이해하고 넘어가는 게 중요합니다.

오해 1. 성장기에는 수익을 나중에 생각해도 된다

성장기에는 사용자 확보가 중요하지만, 수익 모델을 완전히 미뤄두면 성숙기로 넘어갈 때 심각한 문제가 생길 수 있습니다. 성장기에도 "언젠가 어떻게 돈을 벌 것인가"에 대한 설계는 반드시 필요합니다.

오해 2. 라이프사이클은 항상 순서대로만 흐른다

피벗이나 리뉴얼을 통해 다시 도입기처럼 시작할 수도 있습니다. 오래된 회사가 새로운 타깃 고객을 대상으로 완전히 다른 가치를 제공한다면, 그 서비스는 다시 검증이 필요한 도입기 상태가 됩니다.

오해 3. 쇠퇴기는 실패다

쇠퇴기는 무조건 실패를 의미하지 않습니다. 시장 변화에 따라 어떤 서비스는 자연스럽게 역할을 다할 수 있습니다. 중요한 것은 쇠퇴를 인정하고 다음 선택을 준비하는 것입니다. 전략적인 종료도 훌륭한 의사결정이 될 수 있습니다.

오해 4. PMF는 한 번 달성하면 영원히 유지된다

시장은 변하고 사용자의 기대도 변합니다. 경쟁 서비스가 등장하면 기존의 강점이 약해질 수도 있습니다. 그래서 PMF는 지속적으로 재검증해야 합니다. (참고: Nielsen Norman Group - Product Life Cycle / 한국인터넷진흥원(KISA) 디지털 서비스 가이드)

7. 기획자를 위한 핵심 정리 — 단계별 체크리스트

마지막으로 각 단계에서 기획자가 자신에게 던져야 할 핵심 질문들을 정리했습니다. 이 질문들을 항상 머릿속에 갖고 있으면 어떤 단계에서도 흔들리지 않을 수 있습니다.

단계	핵심 질문
도입기	사용자가 이 서비스를 왜 써야 하는가? / 핵심 기능이 문제를 해결하는가? / PMF를 찾기 전에 성장에 투자하고 있지는 않은가?
성장기	새로 들어온 사용자가 계속 사용하는가? / 이탈하는 지점은 어디인가? / 경쟁 서비스와 어떤 차별점이 있는가?
성숙기	가장 가치 높은 사용자 그룹은 누구인가? / 현재 수익 모델은 안정적인가? / 새로운 수익원을 만들 수 있는가?
쇠퇴기	사용자가 줄어드는 진짜 이유는 무엇인가? / 피벗하면 다시 성장 가능성이 있는가? / 계속 운영하는 비용이 가치보다 큰가?

이 글의 핵심 요약
프로덕트 라이프사이클: 도입기 → 성장기 → 성숙기 → 쇠퇴기
각 단계마다 기획자의 우선순위와 핵심 지표가 달라집니다.
LTV > CAC × 3 이면 건강한 서비스입니다.
PMF는 한 번이 아니라 지속적으로 재검증해야 합니다.
쇠퇴기 = 실패가 아닙니다. 전략적 종료도 좋은 기획입니다.

이 글과 함께 아래 관련 글들도 함께 읽어보시면 기획자로서의 역량을 더 넓게 키울 수 있습니다.

서비스기획자란 무엇인가? 역할과 책임 완벽 정리 [기획자 입문]

pokeylog — Tue, 28 Apr 2026 09:43:05 +0900

Photo by Austin Distel on Unsplash

저는 처음 '서비스기획자'라는 직함을 들었을 때, 솔직히 말해서 "기획서를 잘 쓰는 사람?" 정도로만 생각했습니다. 그런데 막상 공부를 시작하고 실무를 들여다보니, 서비스기획자의 역할은 제가 생각했던 것보다 훨씬 넓고 복잡했습니다. PM이나 기획자를 준비하는 분들이라면 누구나 한 번쯤 "기획자가 도대체 뭘 하는 사람인가?"라는 질문을 하게 됩니다. 이 글에서는 그 질문에 대한 명확한 답을 드리겠습니다.

이 글은 서비스기획자의 역할과 책임을 처음 배우는 분, 기획자나 PM으로 커리어를 시작하려는 분, 그리고 현업에서 기획자와 협업하는 개발자·디자이너분들을 위해 작성했습니다.

1. 서비스기획자에 대한 흔한 오해 — "기획서 잘 쓰는 사람이 아닌가요?"

서비스기획자라고 하면 많은 분들이 이런 이미지를 떠올립니다.

기획서를 잘 쓰는 사람
화면(UI)을 설계하는 사람
아이디어를 많이 내는 사람

하지만 이것은 서비스기획자가 하는 일의 일부일 뿐입니다. 저도 처음에는 이런 오해를 갖고 있었는데, 공부를 하면서 이 오해가 얼마나 근본적인 것인지 깨달았습니다.

아래 표를 보면 오해와 실제 역할의 차이를 한눈에 볼 수 있습니다.

흔한 오해	실제 역할
기획서를 잘 쓰는 사람	문제를 정의하는 사람
디자이너에게 화면을 지시하는 사람	팀이 같은 방향을 보게 만드는 사람
아이디어를 내는 사람	아이디어 중 무엇을 하지 않을지 결정하는 사람
모든 것을 결정하는 사람	판단 기준을 세우고 조율하는 사람

특히 마지막 행이 중요합니다. 서비스기획자는 "무엇을 만들까?"만 고민하지 않습니다. 오히려 "무엇을 만들지 않을까?"를 결정하는 일이 매우 중요합니다. 리소스는 항상 유한하기 때문입니다.

핵심 문장: "서비스기획자는 만드는 사람이 아니라, 무엇을 왜 만들지를 결정하는 사람이다."

2. 서비스기획자의 정의 — 사용자와 비즈니스를 연결하는 다리

서비스기획자를 한 문장으로 정의하면 다음과 같습니다.

사용자의 문제와 비즈니스의 목표를 연결하는 지점에서, 무엇을 · 왜 · 어떤 순서로 만들 것인가를 결정하고 조율하는 사람

이 정의를 쉽게 비유하면, 서비스기획자는 건물의 설계사와 같습니다. 건물을 실제로 짓는 사람(개발자, 디자이너)이 따로 있고, 건물주의 요구(비즈니스 목표)와 실제 거주자의 필요(사용자 문제)를 파악해서 "이런 건물을 이런 구조로 만들어야 한다"고 설계도를 그리는 사람이 바로 기획자입니다.

① 사용자의 문제

사용자가 불편해하거나 원하는 것을 말합니다. 예를 들어 사용자가 "결제가 불편해요"라고 말한다면, 기획자는 그 말을 그대로 받아들이기보다 왜 불편한지를 먼저 파고들어야 합니다. 표면적인 말 뒤에 숨은 진짜 문제를 찾는 것이 기획자의 출발점입니다.

② 비즈니스의 목표

회사가 달성해야 하는 목표입니다. 예를 들면 매출 증가, 가입자 수 증가, 재방문율 증가, 결제 완료율 증가, 이탈률 감소 등이 있습니다. 서비스기획자는 항상 이 목표를 염두에 두고 기능의 우선순위를 결정합니다.

③ 연결하는 지점

사용자가 원하는 것과 회사가 원하는 것이 항상 같지는 않습니다. 기획자는 이 둘 사이에서 무엇이 더 중요한지 판단하고 현실적인 방향을 찾아야 합니다. 이것이 기획자의 가장 핵심적인 역량입니다.

3. 서비스기획자의 3가지 핵심 역할

저는 서비스기획자의 역할을 처음 배울 때, "이렇게 많은 역할을 다 해야 해?" 하고 당황했던 기억이 있습니다. 하지만 결국 세 가지 키워드로 정리할 수 있습니다.

서비스기획자
│
├── ① 문제 정의자 (Problem Definer)
├── ② 의사결정 조율자 (Decision Facilitator)
└── ③ 요구사항 번역자 (Requirement Translator)

① 문제 정의자 (Problem Definer)

서비스기획자는 사용자가 말한 불편함을 그대로 해결하려 하지 않습니다. 먼저 그 불편함의 진짜 원인을 찾습니다.

예시: 사용자가 "결제가 불편해요"라고 말했을 때 바로 "결제 화면을 바꾸자"라고 결정하면 안 됩니다. 다음과 같은 다양한 원인이 있을 수 있기 때문입니다.

결제 단계가 너무 많다
배송비가 마지막에 갑자기 보인다
가격이 믿기지 않는다
결제 수단이 부족하다
회원가입을 해야만 결제할 수 있다

같은 "결제가 불편하다"는 말이라도 원인에 따라 해결책은 완전히 달라집니다. 문제를 잘못 정의하면, 아무리 열심히 만들어도 잘못된 결과가 나올 수 있습니다.

② 의사결정 조율자 (Decision Facilitator)

서비스를 만들 때는 여러 직무의 의견이 충돌합니다.

디자이너는 더 보기 좋은 화면을 만들고 싶다
개발자는 더 빠르게 구현하고 싶다
마케터는 더 많은 노출을 원한다
경영진은 더 높은 매출을 원한다

이때 기획자는 누가 맞고 틀린지 심판하는 사람이 아닙니다. 판단 기준을 세우는 사람입니다. 예를 들어 "이번 개선의 가장 중요한 기준은 사용자 이탈을 줄이는 것이다"라고 기준을 명확히 하면, 각 팀의 의사결정이 훨씬 쉬워집니다.

기획자가 사용하는 주요 도구로는 우선순위 매트릭스, OKR, 사용자 스토리 맵, 사용자 여정 지도, 요구사항 정의서 등이 있습니다. (참고: Nielsen Norman Group - UX 성숙도 모델)

③ 요구사항 번역자 (Requirement Translator)

기획자는 서로 다른 사람들의 말을 이해하고, 실행 가능한 형태로 바꾸는 역할을 합니다.

예시: 경영진이 "우리 앱이 좀 불편한 것 같은데 고쳐봅시다"라고 말했을 때, 개발자는 "구체적으로 어떤 기능을 어떻게 고쳐야 하나요?"라고 묻습니다. 이 간극을 메우는 것이 기획자의 역할입니다.

번역 단계	예시
1단계: 모호한 의도 파악	"앱이 불편하다"
2단계: 명확한 목표로 바꾸기	"회원가입 완료율을 높인다"
3단계: 기능 요구사항 정리	"회원가입 입력 항목을 줄인다"
4단계: 개발 가능한 스펙 정의	"이름, 이메일, 비밀번호만 입력하면 가입 가능하게 한다"

4. 서비스기획자의 책임 3단계 — 레벨 1에서 멈추지 말 것

저는 기획자의 책임을 공부하면서 가장 크게 반성했던 부분이 있습니다. 많은 초보 기획자들이(저도 포함해서) 레벨 1에서 멈추는 경향이 있습니다.

책임 레벨	내용	핵심 질문
레벨 1. 산출물 책임	기획서, 와이어프레임, 요구사항 정의서 작성	문서가 명확한가?
레벨 2. 과정 책임	팀 커뮤니케이션, 방향 정렬	팀이 같은 이해를 갖고 일하는가?
레벨 3. 결과 책임	출시 후 데이터 분석, 문제 해결 여부 확인	서비스가 실제로 문제를 해결했는가?

"기획서를 냈으니 내 일은 끝났다"는 생각은 레벨 1에서 멈추는 것입니다. 좋은 기획자는 결과까지 책임집니다. "이 기능이 실제로 사용자의 문제를 해결했는가?"라는 질문을 서비스가 출시된 후에도 계속해야 합니다.

이 개념은 한국인터넷진흥원(KISA)의 서비스 운영 가이드라인에서도 강조하는 사용자 중심 설계(UCD, User Centered Design) 원칙과 일맥상통합니다.

5. 서비스기획자가 하는 일 vs 하지 않는 일

기획자를 준비하는 분들이 자주 혼동하는 부분이 있습니다. "기획자가 모든 것을 결정하는 것 아닌가?" 하는 오해입니다. 각 직무에는 고유한 전문 영역이 있습니다.

기획자의 역할이 아닌 것	기획자의 역할인 것 ✅
UI 색상과 폰트를 최종 결정하는 일	팀이 같은 목표를 보고 있는지 확인하기
기술 구현 방식을 직접 결정하는 일	사용자 문제와 비즈니스 목표 연결 여부 판단
마케팅 채널을 직접 결정하는 일	우선순위를 정하고 조율하기
혼자 모든 것을 결정하는 일	요구사항을 명확하게 정리하기

기획자는 모든 일을 대신하는 사람이 아닙니다. 각 팀이 같은 방향으로 움직일 수 있도록 돕는 사람입니다. 이 개념을 이해하면, 기획자가 "왜 코딩을 못해도 되는지", "왜 디자인을 직접 하지 않아도 되는지"가 명확해집니다.

6. 실제 회사에서 서비스기획자의 하루 — 상상과 현실의 차이

기획자가 하루 종일 기획서만 쓸 것 같다는 생각, 저도 처음에는 그랬습니다. 실제로는 어떨까요?

시간	업무	핵심 역할
오전 9시	어제 배포된 기능의 데이터 확인	결과 책임
오전 10시	개발팀 회의에서 이슈 공유	의사결정 조율
오전 11시	디자이너와 사용자 흐름 검토	요구사항 번역
오후 2시	경영진과 다음 기능 방향 논의	문제 정의 + 번역
오후 4시	다음 스프린트 요구사항 정리	산출물 책임
오후 6시	고객 인터뷰 영상 확인	문제 정의

기획서를 쓰는 일은 중요하지만, 그것은 전체 업무의 일부입니다. 기획자는 하루 동안 여러 사람과 소통하고, 데이터를 확인하고, 방향을 조율합니다. 오히려 커뮤니케이션 역량이 기획서 작성 능력보다 더 중요할 때가 많습니다.

7. 기획자를 꿈꾸는 분들을 위한 마무리 조언

저는 이 내용을 공부하면서 "기획자는 권한은 작지만 영향력은 크다"는 말이 정말 와닿았습니다. 팀에서 기획자의 직급이 낮아도, 좋은 기획자 한 명이 팀 전체의 방향을 바꿀 수 있습니다.

기획자를 준비하면서 반드시 기억해야 할 3가지 문장이 있습니다.

기획자는 무엇을 만들지, 왜 만들지를 결정한다.
문제를 틀리게 정의하면, 완벽한 실행도 실패다.
기획자의 권한은 작지만, 영향력은 크다.

이 글과 함께 아래 블로그 내의 관련 글들도 함께 읽으시면 기획자로서의 역량을 더 넓게 키울 수 있습니다.

이 글의 핵심 요약
서비스기획자는 사용자의 문제와 비즈니스 목표를 연결하는 사람입니다.
역할: ① 문제 정의자 → ② 의사결정 조율자 → ③ 요구사항 번역자
책임: 레벨 1(산출물) → 레벨 2(과정) → 레벨 3(결과)
기획자는 만드는 사람이 아니라, 무엇을 왜 만들지를 결정하는 사람입니다.

SET Operation (집합 연산자)

pokeylog — Fri, 4 Jul 2025 00:15:09 +0900

SET Operation (집합 연산자)

SET 연산자는 SQLD 시험에서 조인, 서브쿼리와 함께 반드시 마스터해야 할 고급 문법입니다. 두 개 이상의 SELECT 문으로 얻은 결과 집합을 하나로 합치거나, 공통된 부분만 찾거나, 차이를 비교할 때 사용됩니다.

1. SET 연산자란?

개념: 두 개 이상의 SELECT 문(쿼리)의 결과를 수학적인 집합 연산처럼 처리하여 하나의 최종 결과 집합을 만드는 연산자입니다.
핵심 규칙 (SQLD 출제 빈번!):
- 칼럼 개수 일치: SET 연산을 수행하는 모든 SELECT 문은 동일한 개수의 칼럼을 선택해야 합니다.
- 칼럼 데이터 타입 일치: 각 칼럼의 데이터 타입이 서로 호환되어야 합니다. (예: NUMBER와 VARCHAR2는 호환되지 않음)
- ORDER BY 위치: ORDER BY 절은 가장 마지막 SELECT 문 뒤에 단 한 번만 사용할 수 있습니다. 이때 정렬 기준이 되는 칼럼은 첫 번째 SELECT 문의 칼럼 이름이나 순서(숫자)를 따릅니다.

2. SET 연산자의 종류와 특징

SQLD 시험에서는 각 SET 연산자의 정확한 의미와 중복 데이터 처리 방식, 그리고 시스템별 지원 여부를 묻는 문제가 자주 출제됩니다.

2.1. UNION (합집합 - 중복 제거)

개념: 두 쿼리의 결과 집합을 합쳐서 하나의 집합으로 만듭니다. 이때, 두 쿼리 모두에 존재하는 중복되는 행은 한 번만 결과에 포함됩니다.
작동 방식: 각 쿼리의 결과를 가져온 후, 전체 결과에서 중복되는 행을 찾아 제거합니다.
SQLD 출제 포인트: 중복 제거 과정 때문에 UNION ALL보다 성능이 다소 느릴 수 있습니다. "중복을 제거한 모든 목록"이 필요할 때 사용합니다.
두 개의 집합을 합치되, 겹치는 부분은 한 번만 센다고 생각하면 됩니다.

2.2. UNION ALL (합집합 - 중복 포함)

개념: 두 쿼리의 결과 집합을 합쳐서 하나의 집합으로 만듭니다. UNION과 달리, 중복되는 행도 모두 그대로 결과에 포함됩니다.
작동 방식: 단순히 두 쿼리의 결과를 위아래로 이어 붙입니다.
SQLD 출제 포인트: 중복 제거 과정이 없기 때문에 UNION보다 일반적으로 성능이 더 빠릅니다. "모든 내역 (중복 포함)"이 필요할 때 사용합니다.
두 개의 집합을 단순히 합친다고 생각하면 됩니다.

2.3. INTERSECT (교집합)

개념: 두 쿼리 모두에 존재하는 공통된 행만 결과로 반환합니다.
작동 방식: 두 쿼리의 결과를 비교하여, 양쪽에 정확히 일치하는 행들만 선택합니다.
SQLD 출제 포인트:
- Oracle, PostgreSQL 등 일부 RDBMS에서 지원하며, MySQL에서는 직접 지원하지 않습니다.
- MySQL에서 INTERSECT와 동일한 결과를 얻으려면 INNER JOIN이나 IN/EXISTS를 사용한 서브쿼리로 구현해야 합니다. 시험에 이 대체 방법이 자주 출제됩니다.
두 개의 집합이 겹치는 공통 부분만 생각하면 됩니다.

2.4. EXCEPT / MINUS (차집합)

개념: 첫 번째 쿼리에는 존재하지만, 두 번째 쿼리에는 존재하지 않는 행만 결과로 반환합니다.
작동 방식: 첫 번째 쿼리 결과에서 두 번째 쿼리 결과와 겹치는 행들을 제외합니다.
SQLD 출제 포인트:
- 표준 SQL 및 PostgreSQL, SQL Server 등에서는 EXCEPT를 사용합니다.
- *Oracle에서는 MINUS*를 사용합니다.
- MySQL에서는 직접 지원하지 않습니다. MySQL에서 EXCEPT/MINUS와 동일한 결과를 얻으려면 LEFT JOIN + WHERE IS NULL 또는 NOT IN/NOT EXISTS를 사용한 서브쿼리로 구현해야 합니다. 이 대체 방법 역시 시험에 자주 출제됩니다.
첫 번째 집합에서 두 번째 집합과 겹치는 부분을 제외한 순수한 첫 번째 집합 부분만 생각하면 됩니다.

Subquery (서브쿼리)

pokeylog — Fri, 4 Jul 2025 00:13:32 +0900

1. 서브쿼리란?

개념: 다른 SQL 문장(메인 쿼리) 내부에 포함되는 SELECT 문을 의미합니다.
역할: 메인 쿼리에 필요한 데이터를 제공하거나, 메인 쿼리의 특정 조건을 정의하는 데 사용됩니다.
SQLD 출제 포인트:
- 서브쿼리는 괄호 () 안에 작성됩니다.
- 메인 쿼리가 실행되기 전에 서브쿼리가 먼저 실행되어 결과를 반환하고, 그 결과를 메인 쿼리가 사용합니다. (예외: 상관 서브쿼리)

2. 서브쿼리 사용 위치와 특징 (SQLD 핵심!)

SQLD 시험에서는 서브쿼리가 SQL 문의 어느 절에 위치하느냐에 따라 그 역할과 제약 조건이 달라지는 것을 자주 묻습니다.

2.1. SELECT 절 (스칼라 서브쿼리)

개념: SELECT 절에 포함되어 **단일 값(1개의 행, 1개의 칼럼)**을 반환하는 서브쿼리입니다. 마치 일반 칼럼처럼 사용됩니다.
특징:
- 반드시 1개의 행과 1개의 칼럼만 반환해야 합니다. 그렇지 않으면 오류가 발생합니다.
- 주로 메인 쿼리의 각 행에 대해 관련 있는 단일 값을 가져올 때 사용됩니다.
SQLD 출제 포인트:
- 결과가 단일 값이어야 한다는 제약 조건!
- 조인으로 대체 가능한 경우가 많으므로, 성능 비교 문제가 나올 수 있습니다.

2.2. FROM 절 (인라인 뷰)

개념: FROM 절에 포함되어 가상의 테이블(뷰)처럼 사용되는 서브쿼리입니다.
특징:
- 서브쿼리의 결과가 하나의 테이블처럼 취급되므로, 그 결과에 대해 다시 조인, 필터링, 그룹화 등의 연산을 수행할 수 있습니다.
- 반드시 **별칭(Alias)**을 부여해야 합니다.
SQLD 출제 포인트:
- 복잡한 쿼리를 단계적으로 처리하거나, 중간 집계 결과를 활용할 때 유용합니다.
- 조인과 함께 사용되는 경우가 많습니다.

2.3. WHERE 절 (조건식 서브쿼리)

개념: WHERE 절에 포함되어 메인 쿼리의 필터링 조건으로 사용되는 서브쿼리입니다.
특징:
- 단일 행 서브쿼리: 결과가 1개의 행을 반환할 때 사용합니다. = (같다), > (크다), < (작다), >= (크거나 같다), <= (작거나 같다), != (같지 않다) 등의 비교 연산자와 함께 사용됩니다.
- 다중 행 서브쿼리: 결과가 여러 개의 행을 반환할 때 사용합니다. IN, NOT IN, ANY, ALL, EXISTS, NOT EXISTS 등의 연산자와 함께 사용됩니다.
  - IN: 서브쿼리 결과 중 하나라도 일치하면 참.
  - NOT IN: 서브쿼리 결과 중 어느 것과도 일치하지 않으면 참.
  - ANY: 서브쿼리 결과 중 최소한 하나라도 조건을 만족하면 참.
  - ALL: 서브쿼리 결과의 모든 값이 조건을 만족해야 참.
  - EXISTS: 서브쿼리가 하나라도 행을 반환하면 참. (주로 상관 서브쿼리에서 효율적)
  - NOT EXISTS: 서브쿼리가 어떤 행도 반환하지 않으면 참.
- 다중 칼럼 서브쿼리: 결과가 여러 개의 칼럼을 반환할 때 사용합니다. (예: (컬럼1, 컬럼2) IN (SELECT ...) )
SQLD 출제 포인트:
- 각 연산자(IN, ANY, ALL, EXISTS)의 정확한 의미와 사용법을 구분하는 것이 가장 중요합니다.
- 특히 EXISTS와 IN의 차이점, 그리고 상관 서브쿼리에서의 효율성을 이해해야 합니다.

2.4. HAVING 절

개념: GROUP BY 절과 함께 사용되며, 그룹 함수(예: SUM, AVG, COUNT)의 결과에 대한 조건을 지정할 때 서브쿼리를 포함할 수 있습니다.
특징: WHERE 절이 개별 행에 조건을 적용하는 반면, HAVING 절은 그룹 전체에 조건을 적용합니다.
SQLD 출제 포인트:
- WHERE 절과 HAVING 절의 차이점을 명확히 이해하고 있어야 합니다.

2.5. UPDATE/DELETE 절

개념: UPDATE 문에서는 SET 절이나 WHERE 절에, DELETE 문에서는 WHERE 절에 서브쿼리가 포함되어 갱신하거나 삭제할 대상 행을 지정할 수 있습니다.
SQLD 출제 포인트:
- 특정 조건을 만족하는 데이터를 기준으로 다른 데이터를 업데이트하거나 삭제할 때 사용됩니다.

3. 상관(Correlated) 서브쿼리 (SQLD 심화!)

개념: 서브쿼리 내에서 메인 쿼리의 칼럼을 참조하는 형태의 서브쿼리입니다.
작동 방식: 일반 서브쿼리와 달리, 메인 쿼리의 각 행이 처리될 때마다 서브쿼리가 반복적으로 실행됩니다.
SQLD 출제 포인트:
- 성능 저하의 주요 원인이 될 수 있으므로, 가능한 경우 **조인(JOIN)**으로 대체하는 것을 권장합니다.
- EXISTS 또는 NOT EXISTS 연산자와 함께 자주 사용되며, 이 경우 특정 조건에 맞는 데이터가 존재하는지 여부만 확인하므로 효율적일 수 있습니다.
- "각 그룹의 최대/최소값에 해당하는 다른 정보 찾기"와 같은 문제에서 자주 등장합니다.

4. 서브쿼리 성능 고려사항 (SQLD 실무/이론)

조인 vs 서브쿼리: 많은 경우 서브쿼리로 구현 가능한 로직은 조인으로도 구현 가능합니다. 일반적으로 조인이 서브쿼리보다 성능이 좋은 경우가 많습니다. (특히 상관 서브쿼리)
최적화: 데이터베이스 옵티마이저가 서브쿼리를 조인 형태로 변환하여 실행하는 경우도 있습니다. 하지만 개발자가 명시적으로 효율적인 조인으로 작성하는 것이 좋습니다.

JOIN (조인)

pokeylog — Fri, 4 Jul 2025 00:11:59 +0900

1. JOIN이란?

테이블 간의 **공통된 칼럼(열)**을 기준으로 행들을 연결하여, 여러 테이블에 흩어져 있는 데이터를 한 번에 조회할 수 있게 해주는 연산자입니다.

왜 쓸까? 현실의 데이터는 하나의 거대한 테이블에 모두 담겨있지 않고, 효율적인 관리를 위해 여러 개의 작은 테이블로 나뉘어 저장됩니다. (예: 고객 정보 테이블, 주문 정보 테이블, 상품 정보 테이블) JOIN은 이렇게 나뉜 정보들을 필요에 따라 합쳐서 완전한 데이터를 얻을 때 사용합니다.

2. JOIN의 종류와 특징

SQLD 시험에서는 각 JOIN 방식이 어떤 결과를 반환하는지, 그리고 어떤 상황에 사용되는지 정확히 아는 것이 중요합니다.

2.1. INNER JOIN (내부 조인)

개념: 가장 일반적인 조인 방식으로, 두 테이블에 모두 일치하는 데이터가 있는 행만 결과로 반환합니다.
작동 방식:
1. 양쪽 테이블에서 조인 조건(예: 테이블1.ID = 테이블2.ID)을 만족하는 행들을 찾습니다.
2. 일치하는 데이터가 있는 행들만 합쳐서 보여줍니다.
3. 어느 한쪽 테이블에라도 일치하는 데이터가 없으면 해당 행은 결과에서 제외됩니다.
SQLD 출제 포인트:
- JOIN 키워드만 사용하면 기본적으로 INNER JOIN으로 처리됩니다. (INNER 생략 가능)
- "양쪽 테이블에 모두 존재하는" 또는 "공통된" 데이터가 필요할 때 사용합니다.
- 두 개의 원이 겹쳐지는 가운데 부분만 생각하면 됩니다.

2.2. OUTER JOIN (외부 조인)

개념: INNER JOIN과 달리, 한쪽 테이블에 일치하는 데이터가 없더라도 다른 쪽 테이블의 모든 행을 결과에 포함시키는 조인 방식입니다. 일치하는 데이터가 없는 쪽의 칼럼은 NULL 값으로 표시됩니다.
SQLD 출제 포인트:
- 어떤 테이블을 기준으로 모든 데이터를 가져올 것인지(LEFT, RIGHT, FULL)를 정확히 구분하는 것이 중요합니다.
- NULL 값이 결과에 포함될 수 있음을 이해해야 합니다.

2.2.1. LEFT OUTER JOIN (LEFT JOIN)

개념: 왼쪽(FROM 절에 먼저 명시된) 테이블의 모든 행을 기준으로 조인합니다. 오른쪽 테이블에서 일치하는 데이터가 없으면 오른쪽 테이블의 칼럼은 NULL로 채워집니다.
사용 상황: 왼쪽 테이블의 모든 정보를 보여주고, 만약 관련 정보가 오른쪽 테이블에 있다면 함께 보여줄 때 사용합니다. (예: 모든 고객 정보와 그 고객들의 주문 내역, 주문이 없는 고객도 포함)
왼쪽 원 전체와 겹치는 부분만 생각하면 됩니다.

2.2.2. RIGHT OUTER JOIN (RIGHT JOIN)

개념: 오른쪽(JOIN 뒤에 명시된) 테이블의 모든 행을 기준으로 조인합니다. 왼쪽 테이블에서 일치하는 데이터가 없으면 왼쪽 테이블의 칼럼은 NULL로 채워집니다.
사용 상황: 오른쪽 테이블의 모든 정보를 보여주고, 만약 관련 정보가 왼쪽 테이블에 있다면 함께 보여줄 때 사용합니다.
오른쪽 원 전체와 겹치는 부분만 생각하면 됩니다.

2.2.3. FULL OUTER JOIN (FULL JOIN)

개념: 양쪽 테이블의 모든 행을 포함하여 조인합니다. 어느 한쪽이라도 일치하는 데이터가 없으면 해당 테이블의 칼럼은 NULL로 표시됩니다.
사용 상황: 양쪽 테이블의 모든 데이터 관계를 한눈에 파악하고 싶을 때 사용합니다.
SQLD 출제 포인트: 모든 데이터베이스 시스템에서 FULL JOIN을 직접 지원하지 않을 수 있습니다. (예: MySQL은 UNION을 통해 구현해야 함)
두 원의 모든 부분을 포함한다고 생각하면 됩니다.

2.3. CROSS JOIN (카티션 곱)

개념: 조인 조건 없이 두 테이블의 모든 가능한 행 조합을 반환합니다.
작동 방식: 첫 번째 테이블의 각 행이 두 번째 테이블의 모든 행과 연결됩니다.
결과 행 수: (테이블1의 행 수) × (테이블2의 행 수)
SQLD 출제 포인트:
- 조인 조건이 필요 없다는 것이 특징입니다.
- 결과 행 수가 급격히 늘어날 수 있어 주의해야 합니다.
- 주로 대량의 테스트 데이터를 만들거나 특정 통계 분석 시 사용됩니다.

2.4. SELF JOIN (자체 조인)

개념: 하나의 테이블을 마치 두 개의 독립된 테이블인 것처럼 사용하여 조인하는 방식입니다.
작동 방식: 동일한 테이블 내에서 특정 칼럼과 다른 칼럼 간의 관계(예: 직원과 상사, 부모와 자식)를 찾을 때 사용합니다.
SQLD 출제 포인트:
- 반드시 테이블에 **별칭(Alias)**을 부여하여 각 테이블 인스턴스를 구분해야 합니다. (예: EMPLOYEES E1, EMPLOYEES E2)
- 계층형 데이터(부모-자식 관계)를 조회할 때 자주 사용됩니다.

SQLD 대비 고급 SQL 문법 (JOIN, Subquery, SET)

pokeylog — Thu, 3 Jul 2025 23:49:46 +0900

SQLD 대비 고급 SQL 문법 (JOIN, Subquery, SET)

1. JOIN (조인)

테이블 간의 공통 칼럼을 기준으로 행을 연결하여 새로운 결과 집합을 생성하는 연산자. SQLD 시험에서 가장 중요하게 다뤄지는 부분 중 하나입니다.

1.1. INNER JOIN (내부 조인)

양쪽 테이블에 모두 일치하는 행만 반환합니다.

SQLD 포인트: 가장 일반적인 조인 형태이며, JOIN 키워드만 사용 시 기본적으로 INNER JOIN으로 처리됩니다.
**문법:**SQL
SELECT 컬럼1, 컬럼2, ... FROM 테이블1 INNER JOIN 테이블2 ON 테이블1.공통컬럼 = 테이블2.공통컬럼; -- 또는 (권장) SELECT 컬럼1, 컬럼2, ... FROM 테이블1 T1 JOIN 테이블2 T2 ON T1.공통컬럼 = T2.공통컬럼;
예시: 주문 정보와 고객 정보를 연결하여 주문한 고객의 이름까지 함께 조회.SQL
SELECT O.ORDER_ID, O.PRODUCT_NAME, C.CUSTOMER_NAME FROM ORDERS O INNER JOIN CUSTOMERS C ON O.CUSTOMER_ID = C.CUSTOMER_ID;

1.2. OUTER JOIN (외부 조인)

한쪽 테이블에 일치하는 행이 없어도 다른 쪽 테이블의 모든 행을 반환합니다.

SQLD 포인트: LEFT, RIGHT, FULL 키워드를 사용하여 기준이 되는 테이블을 지정하는 것이 중요합니다. 일치하지 않는 경우 NULL이 반환됩니다.
종류:
- LEFT OUTER JOIN (LEFT JOIN): 왼쪽 테이블의 모든 행과 오른쪽 테이블에서 일치하는 행을 반환. 일치하지 않으면 오른쪽 테이블 칼럼은 NULL.SQL
- SELECT ... FROM 테이블1 LEFT JOIN 테이블2 ON 조인조건;
- RIGHT OUTER JOIN (RIGHT JOIN): 오른쪽 테이블의 모든 행과 왼쪽 테이블에서 일치하는 행을 반환. 일치하지 않으면 왼쪽 테이블 칼럼은 NULL.SQL
- SELECT ... FROM 테이블1 RIGHT JOIN 테이블2 ON 조인조건;
- FULL OUTER JOIN (FULL JOIN): 양쪽 테이블의 모든 행을 반환. 일치하지 않는 경우 해당 테이블 칼럼은 NULL. (Oracle, PostgreSQL 등 지원. MySQL은 UNION으로 구현)SQL
- SELECT ... FROM 테이블1 FULL JOIN 테이블2 ON 조인조건;
예시 (LEFT JOIN): 모든 고객과 해당 고객의 주문 정보를 조회. 주문이 없는 고객도 포함.SQL
SELECT C.CUSTOMER_NAME, O.ORDER_ID, O.PRODUCT_NAME FROM CUSTOMERS C LEFT JOIN ORDERS O ON C.CUSTOMER_ID = O.CUSTOMER_ID;

1.3. CROSS JOIN (카티션 곱)

두 테이블의 모든 가능한 행 조합을 반환합니다. 조인 조건이 필요 없습니다.

SQLD 포인트: 명시적으로 ON 절을 사용하지 않습니다. 결과 행 수가 테이블1 행 수 * 테이블2 행 수가 됩니다. 주로 테스트 데이터 생성이나 통계 분석에 사용됩니다.
**문법:**SQL
SELECT 컬럼1, 컬럼2, ... FROM 테이블1 CROSS JOIN 테이블2;

1.4. SELF JOIN (자체 조인)

하나의 테이블을 두 개의 테이블처럼 사용하여 조인하는 방식입니다.

SQLD 포인트: 반드시 테이블 별칭(Alias)을 사용하여 구분해야 합니다. 계층형 쿼리나 같은 테이블 내의 관련 데이터를 찾을 때 유용합니다.
예시: 직원 테이블에서 각 직원의 상사 이름을 조회.SQL
SELECT E1.EMPLOYEE_NAME, E2.EMPLOYEE_NAME AS MANAGER_NAME FROM EMPLOYEES E1 JOIN EMPLOYEES E2 ON E1.MANAGER_ID = E2.EMPLOYEE_ID;

2. Subquery (서브쿼리)

하나의 SQL 문 내에 포함된 또 다른 SQL 문입니다. 메인 쿼리에 데이터를 제공하는 역할을 합니다.

2.1. 서브쿼리 사용 위치

SQLD에서는 서브쿼리가 사용될 수 있는 다양한 위치와 그에 따른 특징을 묻는 문제가 자주 출제됩니다.

SELECT 절: 스칼라 서브쿼리 (단일 값 반환)
- SQLD 포인트: 결과는 반드시 1개의 행, 1개의 칼럼이어야 합니다.
- 예시: 각 주문에 해당하는 고객의 이름을 서브쿼리로 조회.SQL
- SELECT ORDER_ID, PRODUCT_NAME, (SELECT CUSTOMER_NAME FROM CUSTOMERS WHERE CUSTOMER_ID = ORDERS.CUSTOMER_ID) AS CUSTOMER_NAME FROM ORDERS;
FROM 절: 인라인 뷰 (가상 테이블처럼 사용)
- SQLD 포인트: 결과는 테이블 형태로 사용되며, 반드시 별칭(Alias)을 부여해야 합니다. 조인과 함께 사용되는 경우가 많습니다.
- 예시: 연도별 최고 판매액을 기록한 상품 조회.SQL
- SELECT T.ORDER_YEAR, T.PRODUCT_NAME, T.TOTAL_SALES FROM (SELECT EXTRACT(YEAR FROM ORDER_DATE) AS ORDER_YEAR, PRODUCT_NAME, SUM(PRICE * QUANTITY) AS TOTAL_SALES FROM ORDERS GROUP BY EXTRACT(YEAR FROM ORDER_DATE), PRODUCT_NAME) T WHERE T.TOTAL_SALES IN (SELECT MAX(TOTAL_SALES) FROM (SELECT EXTRACT(YEAR FROM ORDER_DATE) AS ORDER_YEAR, SUM(PRICE * QUANTITY) AS TOTAL_SALES FROM ORDERS GROUP BY EXTRACT(YEAR FROM ORDER_DATE)) G WHERE G.ORDER_YEAR = T.ORDER_YEAR);
WHERE 절: 조건식 (단일 행, 다중 행, 다중 칼럼 서브쿼리)
- SQLD 포인트: 메인 쿼리의 특정 조건에 사용됩니다. 비교 연산자 (=, >, <, >=, <=, !=), IN, EXISTS 등과 함께 사용됩니다.
- 예시 1 (단일 행): 평균 주문 금액보다 큰 주문 조회.SQL
- SELECT ORDER_ID, PRODUCT_NAME, AMOUNT FROM ORDERS WHERE AMOUNT > (SELECT AVG(AMOUNT) FROM ORDERS);
- 예시 2 (다중 행 - IN): '전자제품' 카테고리에 속하는 상품을 주문한 고객 조회.SQL
- SELECT CUSTOMER_NAME FROM CUSTOMERS WHERE CUSTOMER_ID IN (SELECT CUSTOMER_ID FROM ORDERS WHERE PRODUCT_CATEGORY = '전자제품');
- 예시 3 (다중 행 - EXISTS): 주문을 하나라도 한 고객 조회.SQL
- SELECT CUSTOMER_NAME FROM CUSTOMERS C WHERE EXISTS (SELECT 1 FROM ORDERS O WHERE O.CUSTOMER_ID = C.CUSTOMER_ID);
HAVING 절: 그룹에 대한 조건식
- SQLD 포인트: GROUP BY 절과 함께 사용되며, 그룹 함수의 결과에 대한 조건을 지정합니다.
- 예시: 총 주문 금액이 100000원 이상인 고객 중, 해당 고객의 평균 주문 금액이 전체 평균 주문 금액보다 큰 고객 조회.SQL
- SELECT CUSTOMER_ID, SUM(AMOUNT) AS TOTAL_AMOUNT FROM ORDERS GROUP BY CUSTOMER_ID HAVING SUM(AMOUNT) >= 100000 AND AVG(AMOUNT) > (SELECT AVG(AMOUNT) FROM ORDERS);
UPDATE/DELETE 절: 갱신/삭제 대상 지정
- SQLD 포인트: SET 절이나 WHERE 절에 서브쿼리가 사용될 수 있습니다.
- 예시 (UPDATE): 특정 상품의 가격을 해당 상품의 평균 가격으로 업데이트.SQL
- UPDATE PRODUCTS SET PRICE = (SELECT AVG(PRICE) FROM PRODUCTS WHERE CATEGORY = '도서') WHERE PRODUCT_NAME = 'SQLD 가이드북';
- 예시 (DELETE): 더 이상 주문이 없는 고객 정보 삭제.SQL
- DELETE FROM CUSTOMERS WHERE CUSTOMER_ID NOT IN (SELECT DISTINCT CUSTOMER_ID FROM ORDERS);

2.2. 상관(Correlated) 서브쿼리

메인 쿼리의 칼럼이 서브쿼리 내에서 사용되는 형태입니다. 서브쿼리가 메인 쿼리의 행마다 반복 실행됩니다.

SQLD 포인트: 성능 저하의 원인이 될 수 있으므로, 가능하다면 조인으로 변경하는 것을 고려해야 합니다. EXISTS 연산자와 함께 자주 사용됩니다.
예시: 각 고객의 첫 주문 조회 (첫 주문의 기준은 ORDER_DATE가 가장 빠른 주문).SQL
SELECT C.CUSTOMER_NAME, O.ORDER_DATE, O.PRODUCT_NAME FROM CUSTOMERS C, ORDERS O WHERE C.CUSTOMER_ID = O.CUSTOMER_ID AND O.ORDER_DATE = (SELECT MIN(ORDER_DATE) FROM ORDERS WHERE CUSTOMER_ID = C.CUSTOMER_ID);

3. SET Operation (집합 연산자)

두 개 이상의 SELECT 문의 결과를 하나의 결과 집합으로 합치거나 비교하는 연산자입니다.

SQLD 포인트: SELECT 절의 칼럼 개수와 데이터 타입이 일치해야 합니다. (칼럼 이름은 달라도 무방) ORDER BY 절은 마지막 SELECT 문 뒤에 단 한 번만 올 수 있습니다.

3.1. UNION

두 쿼리의 결과를 합칩니다. 중복되는 행은 한 번만 표시됩니다.

**문법:**SQL
SELECT 컬럼1, 컬럼2 FROM 테이블1 UNION SELECT 컬럼A, 컬럼B FROM 테이블2;
예시: 주문된 상품 목록과 재고 목록을 합쳐서 중복 없이 모든 상품 이름 조회.SQL
SELECT PRODUCT_NAME FROM ORDERS UNION SELECT PRODUCT_NAME FROM INVENTORY;

3.2. UNION ALL

두 쿼리의 결과를 합칩니다. 중복되는 행도 모두 표시됩니다.

SQLD 포인트: UNION보다 일반적으로 성능이 좋습니다. 중복을 제거할 필요가 없을 때 사용합니다.
**문법:**SQL
SELECT 컬럼1, 컬럼2 FROM 테이블1 UNION ALL SELECT 컬럼A, 컬럼B FROM 테이블2;
예시: 모든 주문 내역과 모든 반품 내역을 합쳐서 조회 (중복 포함).SQL
SELECT ORDER_ID, ORDER_DATE, AMOUNT FROM ORDERS UNION ALL SELECT RETURN_ID, RETURN_DATE, RETURN_AMOUNT FROM RETURNS;

3.3. INTERSECT

두 쿼리 모두에 존재하는 공통된 행만 반환합니다.

SQLD 포인트: Oracle, PostgreSQL 등에서 지원. MySQL은 INNER JOIN 또는 IN/EXISTS 서브쿼리로 구현.
**문법:**SQL
SELECT 컬럼1, 컬럼2 FROM 테이블1 INTERSECT SELECT 컬럼A, 컬럼B FROM 테이블2;
예시 (개념): 주문된 상품 중 재고로도 있는 상품 이름 조회.SQL
- **MySQL 구현 예시 (SQLD 시험에서 나올 수 있는 대체 방법):**SQL
- SELECT O.PRODUCT_NAME FROM ORDERS O INNER JOIN INVENTORY I ON O.PRODUCT_NAME = I.PRODUCT_NAME; -- 또는 SELECT PRODUCT_NAME FROM ORDERS WHERE PRODUCT_NAME IN (SELECT PRODUCT_NAME FROM INVENTORY);
SELECT PRODUCT_NAME FROM ORDERS INTERSECT SELECT PRODUCT_NAME FROM INVENTORY;

3.4. EXCEPT (MINUS)

첫 번째 쿼리에는 존재하지만 두 번째 쿼리에는 존재하지 않는 행만 반환합니다.

SQLD 포인트: EXCEPT는 표준 SQL 및 PostgreSQL, SQL Server 등에서 사용. Oracle은 MINUS. MySQL은 LEFT JOIN + WHERE IS NULL 또는 NOT IN/NOT EXISTS 서브쿼리로 구현.
**문법 (표준/PostgreSQL):**SQL
SELECT 컬럼1, 컬럼2 FROM 테이블1 EXCEPT SELECT 컬럼A, 컬럼B FROM 테이블2;
**문법 (Oracle):**SQL
SELECT 컬럼1, 컬럼2 FROM 테이블1 MINUS SELECT 컬럼A, 컬럼B FROM 테이블2;
예시 (개념): 주문된 상품 중 재고로 남아있지 않은 상품 이름 조회.SQL
- **MySQL 구현 예시 (SQLD 시험에서 나올 수 있는 대체 방법):**SQL
- SELECT O.PRODUCT_NAME FROM ORDERS O LEFT JOIN INVENTORY I ON O.PRODUCT_NAME = I.PRODUCT_NAME WHERE I.PRODUCT_NAME IS NULL; -- 또는 SELECT PRODUCT_NAME FROM ORDERS WHERE PRODUCT_NAME NOT IN (SELECT PRODUCT_NAME FROM INVENTORY);
SELECT PRODUCT_NAME FROM ORDERS EXCEPT SELECT PRODUCT_NAME FROM INVENTORY;

SQLD 대비 고급 SQL 문법 (JOIN, Subquery, SET)

SQLD 2과목 요약: SQL 기본과 활용

pokeylog — Thu, 3 Jul 2025 23:47:58 +0900

✅ 1. SQL 기본 개념

구분 설명

SQL	Structured Query Language. 관계형 DB 조작/정의 언어
DML	SELECT, INSERT, UPDATE, DELETE
DDL	CREATE, ALTER, DROP
DCL	GRANT, REVOKE
TCL	COMMIT, ROLLBACK, SAVEPOINT

✅ 2. SELECT 기본 문법

sql
복사편집
SELECT [DISTINCT] 컬럼명
FROM 테이블명
WHERE 조건
GROUP BY 그룹컬럼
HAVING 그룹조건
ORDER BY 정렬컬럼 [ASC|DESC]

DISTINCT: 중복 제거
WHERE vs HAVING:
- WHERE는 행 필터링,
- HAVING은 집계 결과 필터링

✅ 3. 함수

단일행 함수

함수 설명

숫자함수	ROUND, TRUNC, MOD
문자함수	LENGTH, SUBSTR, CONCAT, UPPER/LOWER
날짜함수	SYSDATE, ADD_MONTHS, MONTHS_BETWEEN, LAST_DAY
변환함수	TO_CHAR, TO_DATE, CAST, CONVERT

그룹 함수

함수 설명

SUM, AVG, MIN, MAX, COUNT	집계 함수 (NULL 제외)
COUNT(*)	NULL 포함 전체 행 수

✅ 4. JOIN

유형 설명

INNER JOIN	조건 일치하는 행만
OUTER JOIN	LEFT, RIGHT, FULL (비교 테이블 없으면 NULL 채움)
SELF JOIN	자기 자신과 JOIN
NATURAL JOIN	같은 이름의 컬럼 자동 JOIN
USING	특정 컬럼 기준으로 JOIN
ON	조건 명시적 지정

sql
복사편집
SELECT *
FROM A
JOIN B ON A.id = B.id;

✅ 5. 서브쿼리

유형 설명

단일행 서브쿼리	=, >, < 등 단일 값 비교
다중행 서브쿼리	IN, ANY, ALL 사용
상관 서브쿼리	메인쿼리의 컬럼을 내부 쿼리에서 참조
인라인 뷰	FROM 절에 사용하는 서브쿼리
WITH절	공통 테이블 표현식 (CTE), 가독성 향상

✅ 6. 집합 연산자

연산자 설명

UNION	중복 제거 합집합
UNION ALL	중복 포함 합집합
INTERSECT	교집합
MINUS / EXCEPT	차집합 (A에 있고 B엔 없는 값)

✅ 7. 데이터 변경

구문 설명

INSERT INTO 테이블 VALUES (값)	행 추가
UPDATE 테이블 SET 컬럼 = 값 WHERE 조건	값 수정
DELETE FROM 테이블 WHERE 조건	행 삭제
MERGE	조건에 따라 INSERT 또는 UPDATE 수행

✅ 8. 트랜잭션 제어 (TCL)

명령어 설명

COMMIT	변경 사항 저장
ROLLBACK	변경 사항 취소
SAVEPOINT	중간 저장점 설정
SET AUTOCOMMIT	자동 커밋 설정 여부 제어 (DBMS마다 다름)

✅ 9. 인덱스 & 뷰

개념 설명

인덱스	검색 성능 향상, 자동/수동 생성 가능
뷰(View)	가상 테이블, 실질 데이터 없음
인라인 뷰	서브쿼리를 FROM절에서 사용
Materialized View (물리적 뷰)	데이터를 저장, 성능↑, 자동 갱신 가능

✅ 10. 최신 출제 경향 정리 (2024~2025 기준)

테마 출제 포인트

JOIN	INNER/OUTER JOIN 개념 및 결과 예측 문제
함수	날짜 + 문자 + 변환 함수 조합 문제
서브쿼리	상관 서브쿼리 vs 일반 서브쿼리 비교
DML	UPDATE/DELETE with 조건
집합 연산	결과 값 추론 및 중복 포함 여부
GROUP BY	그룹화 컬럼 개수 및 HAVING 조건 해석
DCL/TCL	GRANT/COMMIT 개념 이해
WITH절	가독성 및 재사용 목적 파악

✅ 정규화 (Normalization)란?

데이터베이스 설계 시 데이터 중복을 최소화하고 **이상 현상(Anomaly)**을 방지하기 위해 릴레이션을 구조적으로 분해하는 과정을 말합니다.

정규화의 목적

데이터 중복 최소화
삽입/삭제/갱신 이상 방지
데이터 무결성 유지
구조적이고 논리적인 테이블 구성

✅ 이상 현상 (Anomaly)의 종류

구분 설명

삽입 이상	일부 속성만 알 때는 데이터를 삽입할 수 없음
삭제 이상	한 데이터를 삭제하면 다른 정보까지 함께 사라짐
갱신 이상	중복된 데이터의 일부만 수정될 경우 데이터 불일치 발생

✅ 정규형 (Normal Forms)

정규형 조건 해결하는 문제

제1정규형 (1NF)	모든 속성의 값이 원자값(Atomic)	반복되는 그룹 제거
제2정규형 (2NF)	1NF 만족 + 부분 함수 종속 제거	복합키에서 일부 속성만 종속된 경우 분해
제3정규형 (3NF)	2NF 만족 + 이행 함수 종속 제거	기본키가 아닌 속성에 의해 결정되는 속성 제거
BCNF (보이스-코드 정규형)	결정자가 후보키인 경우만 허용	3NF보다 더 엄격한 형태
제4정규형 (4NF)	다치 종속(Multi-valued dependency) 제거	하나의 키에 여러 속성이 독립적으로 종속된 경우 분해

주요 용어 정리

함수 종속 (Functional Dependency)
: X → Y는 X의 값이 주어지면 Y의 값이 유일하게 결정된다는 뜻
부분 함수 종속
: 복합키의 일부에만 종속되는 경우
이행 함수 종속
: A → B, B → C가 있을 때 A → C가 되는 경우 (A → B → C)
다치 종속
: 하나의 키에 여러 속성이 독립적으로 종속될 때 발생

정규화 예시 (간단한 흐름)

비정규형

학번 이름 수강과목1 수강과목2

→ 반복 속성 있음 → 1NF로 변환

1NF (원자값만)

학번 이름 수강과목

→ 과목이 키 일부(학번)에만 종속 → 2NF로 변환

→ 이름이 학번에 종속되며, 수강과목과는 무관 → 3NF로 변환

✅ 요약 표

정규형 기준 제거 대상

1NF	원자값	반복 속성
2NF	부분 함수 종속 제거	일부 키 종속
3NF	이행 함수 종속 제거	비키 속성에 의한 결정
BCNF	결정자 → 후보키	모든 결정자 후보키화
4NF	다치 종속 제거	독립적 다치 종속

트랜잭션&락, EXPLAIN&인덱스, DDLvsDML 제약조건

pokeylog — Thu, 19 Jun 2025 22:51:24 +0900

1. 트랜잭션 & 락 (ACID / 격리 수준 / 동시성 문제)

구분 설명 대표 예시

Atomicity	트랜잭션은 전부 수행되거나 전혀 수행되지 않아야 함	예: 중간 실패 시 전체 롤백
Consistency	트랜잭션 전후에 데이터 무결성 유지	FK/PK 제약조건 유지 등
Isolation	다른 트랜잭션 간 영향 차단	격리 수준 설정으로 구현
Durability	COMMIT된 결과는 영구히 유지	시스템 장애 후에도 보존

트랜잭션 격리 수준 (낮 → 높):

READ UNCOMMITTED → READ COMMITTED → REPEATABLE READ → SERIALIZABLE

동시성 이슈:

유형 설명

Dirty Read	다른 트랜잭션의 미확정값을 읽음
Non-repeatable Read	같은 행을 반복 조회 시 값이 바뀜
Phantom Read	조건에 맞는 새로운 행이 중간에 삽입됨

락 (Lock) 전략

종류 설명

낙관적 락	충돌 적다고 가정, 버전 비교 후 충돌 시 롤백
비관적 락	충돌 가능성 높음, SELECT ... FOR UPDATE 사용

2. 실행계획 (EXPLAIN) & 인덱스 활용

항목 설명

EXPLAIN	SQL의 실행 순서, 인덱스 사용 여부 확인
인덱스	검색 속도 개선 도구, B-Tree 기본
사용 시기	자주 검색, 정렬, 조인되는 컬럼
피해야 할 패턴	함수 사용 (WHERE YEAR(date)=2024), 연산 포함된 조건 등

⚙️ 3. DDL vs DML, 제약조건

항목 설명 자동 COMMIT ROLLBACK

CREATE / DROP / ALTER (DDL)	구조 변경	O	X
INSERT / UPDATE / DELETE (DML)	데이터 조작	X	O
TRUNCATE	모든 행 삭제 (구조 유지)	O	X

제약조건 키워드 요약

제약 설명

PRIMARY KEY	고유 + NOT NULL
UNIQUE	중복 X, NULL 허용
NOT NULL	반드시 값 필요
FOREIGN KEY	참조 무결성 유지
CHECK	조건 만족 필요

SQLD 2과목 핵심 개념 정리

pokeylog — Tue, 17 Jun 2025 22:53:10 +0900

1. 데이터 모델링과 물리적 구현의 연계

논리 모델 → 물리 모델 전환 시 고려사항
- 데이터 타입 결정 (정규화에 맞게)
- 인덱스 설계 (쿼리 성능 개선에 핵심!)
- 제약조건 반영 (PK, FK, NOT NULL 등)
최근 트렌드 팁
→ 실무에서는 정규화보다는 **부분 비정규화(반정규화)**를 하여 조인 횟수를 줄이고 성능을 높이는 경우가 많음.

2. 데이터 타입(Data Type)

문자형: CHAR(n), VARCHAR(n)
숫자형: NUMBER, INT, FLOAT
날짜형: DATE, TIMESTAMP

⚡️트렌드 포인트: 날짜·시간 연산이 잦아 DATETIME, TIMESTAMP에 대한 이해가 중요
특히, UNIX_TIMESTAMP, CURRENT_TIMESTAMP 등 시간 함수 사용이 증가

3. 인덱스(Index)

기본 인덱스: B-TREE
유니크 인덱스: 중복 불가
복합 인덱스: 다중 컬럼 기준
비트맵 인덱스: 값의 종류가 적을 때 효과적 (예: 성별, 상태값 등)

⚡️트렌드 포인트:
인덱스 남발은 오히려 성능 저하를 유발 → 실제 실행계획(EXPLAIN) 확인 후 적용
최근 MySQL, PostgreSQL은 인덱스 힌트도 많이 사용됨 (USE INDEX, FORCE INDEX 등)

4. 뷰(View)

가상 테이블로, 실 데이터는 없음
보안/단순화/재사용에 유리
**인라인 뷰 (서브쿼리)**도 트렌드 중 하나

⚠️ 제약: 업데이트가 제한되는 경우 있음 (JOIN, GROUP BY 포함된 뷰 등)

5. 시퀀스(Sequence)와 자동 증가

Oracle: CREATE SEQUENCE
MySQL: AUTO_INCREMENT
PostgreSQL: SERIAL, GENERATED BY DEFAULT AS IDENTITY

⚡️트렌드 포인트:
분산 시스템에서는 UUID, ULID 형태의 ID도 많이 사용됨

6. 제약조건(Constraint)

제약조건설명

PRIMARY KEY	고유 + NOT NULL
FOREIGN KEY	참조 무결성 유지
UNIQUE	중복 금지
NOT NULL	반드시 값 존재해야 함
CHECK	특정 조건 만족 필요

ON DELETE CASCADE와 같은 제약 옵션은 데이터 무결성 유지에 필수

7. 트랜잭션(Transaction)

ACID 원칙:
- Atomicity (원자성)
- Consistency (일관성)
- Isolation (격리성)
- Durability (지속성)
명령어:
- BEGIN, COMMIT, ROLLBACK, SAVEPOINT

⚡️트렌드 포인트:
실무에서는 트랜잭션 경계를 명확히 나누지 않으면 데이터 정합성 문제 발생 → DB → API → 프론트 연계 시 매우 중요

8. 동시성 제어 & 락(Lock)

낙관적 락 (Optimistic): 충돌 가능성 낮을 때 → 버전 체크
비관적 락 (Pessimistic): 충돌 우려 클 때 → SELECT FOR UPDATE

⚡️트렌드 포인트:
API와 동시 처리 시 트랜잭션 격리 수준과 락 전략을 함께 고려해야 함 (예: phantom read 방지 등)

9. 실행계획(Execution Plan)

EXPLAIN 또는 EXPLAIN PLAN 명령으로 확인
인덱스 사용 여부, 조인 순서, 테이블 접근 방식 등 확인 가능

⚡️트렌드 포인트:
실행계획 분석 도구(예: MySQL Workbench, pgAdmin)를 활용한 튜닝 필수

10. SQL 튜닝 기본

조인 순서 최적화
WHERE 조건에 함수 사용 지양
인덱스 컬럼에 연산 넣지 않기 (ex. WHERE YEAR(date_col) = 2024 지양)
서브쿼리 vs JOIN 상황 판단 필요

✨ 보너스 트렌드 개념

CTE (Common Table Expression): WITH절 → 가독성, 재사용성 증가
JSON 데이터 처리: RDB에서도 JSON 필드를 다루는 일이 증가 중 (특히 PostgreSQL, MySQL 5.7+)
NoSQL과의 병행 구조에 대한 이해도 필요 (예: MongoDB ↔ MySQL 혼용)

데이터 모델과 SQL 개념정리

pokeylog — Sat, 14 Jun 2025 23:32:00 +0900

1. 데이터 모델 (Data Model) 개념 정리

✅ 데이터 모델이란?

현실 세계의 데이터를 컴퓨터가 이해하고 다룰 수 있도록 구조화된 형태로 추상화한 것

3가지 데이터 모델 계층

모델 종류 설명 예시

개념적 모델	업무 중심, DBMS 독립	ERD, 개체-관계 다이어그램
논리적 모델	논리적 구조 중심	테이블, 속성, 관계, 정규화
물리적 모델	실제 저장 방식 고려	인덱스, 파티셔닝, 테이블스페이스 등

✅ 엔터티 (Entity)

현실 세계의 객체 (사람, 사물, 사건 등)
예: 고객, 주문, 상품
특징:
- 고유 식별자(PK) 필요
- 최소 2개 이상의 속성
- 관계 존재

✅ 속성 (Attribute)

엔터티를 설명하는 데이터 항목
예: 고객명, 전화번호
파생 속성(계산), 기본 속성(원시값), 설계 속성(인위적 생성) 등 분류

✅ 관계 (Relationship)

엔터티 간 연관성
종류:
- 1:1 (사람–주민등록증)
- 1:N (고객–주문)
- N:M (학생–강의)

✅ 식별자 (Identifier)

엔터티의 인스턴스를 유일하게 구분하는 속성
기본 키(PK), 대체 키, 외래 키(FK)
식별 관계(실선) / 비식별 관계(점선)

✅ 정규화 (Normalization)

중복을 제거하고 이상현상을 방지하는 과정

정규화 단계 목적

1NF	원자값으로 구성
2NF	부분 종속 제거 (복합키일 때 해당)
3NF	이행적 종속 제거
BCNF	후보키에만 종속

✅ 반정규화

성능 향상을 위해 일부 정규화 해제
예: 조인 성능 문제로 테이블 합치기, 중복 허용

2. SQL 개념 정리 (Structured Query Language)

✅ SQL의 종류

유형 설명 명령어

DDL (정의어)	데이터 구조 정의	CREATE, ALTER, DROP
DML (조작어)	데이터 조회·삽입·수정	SELECT, INSERT, UPDATE, DELETE
DCL (제어어)	권한 부여·취소	GRANT, REVOKE
TCL (트랜잭션)	트랜잭션 제어	COMMIT, ROLLBACK, SAVEPOINT

✅ SELECT 문 기본 구조

sql
복사편집
SELECT 컬럼명
FROM 테이블명
WHERE 조건
GROUP BY 컬럼
HAVING 조건
ORDER BY 컬럼;

실행 순서 주의:

FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY

✅ JOIN 종류

유형 설명

INNER JOIN	양쪽 모두 일치하는 값만 반환
LEFT JOIN	왼쪽 테이블 기준, 일치 없으면 NULL
RIGHT JOIN	오른쪽 테이블 기준, 일치 없으면 NULL
FULL OUTER JOIN	일치하지 않아도 모두 출력

✅ 서브쿼리 (Subquery)

SELECT 안에 SELECT
WHERE, FROM, SELECT, HAVING 절에 사용 가능
단일행/다중행 서브쿼리 구분 → IN, ANY, ALL 같은 연산자 사용

✅ 집계 함수 (Aggregate)

함수 설명

COUNT()	개수
SUM()	합계
AVG()	평균
MAX()	최댓값
MIN()	최솟값

✅ 트랜잭션 (Transaction)

하나의 작업 단위로, 전부 성공하거나 전부 실패해야 함

COMMIT: 변경 사항 저장
ROLLBACK: 변경 사항 취소
SAVEPOINT: 중간 저장 지점 설정

✅ 인덱스 (INDEX)

빠른 검색을 위한 구조
읽기 성능 향상, 하지만 쓰기 성능 저하
B-Tree, Bitmap 인덱스 등

요약 암기 키워드

sql
복사편집
ERD = 엔터티 + 속성 + 관계 + 식별자
정규화 = 중복 제거, 이상현상 방지
SQL 종류 = DDL / DML / DCL / TCL
JOIN = INNER / OUTER (LEFT, RIGHT, FULL)
트랜잭션 = COMMIT / ROLLBACK / SAVEPOINT

개념 정리 - SQLD 1과목: 데이터 모델링의 이해

pokeylog — Fri, 13 Jun 2025 00:30:58 +0900

데이터 모델의 개념

현실 세계의 데이터를 컴퓨터에서 표현한 구조
데이터 모델링 목적: 구조화, 명확한 의사소통, 설계 기반 제공

데이터 모델링의 3단계

개념적 모델링: 개체, 속성, 관계 정의 (비즈니스 관점)
논리적 모델링: 정규화, 식별자 등 설계 구조화
물리적 모델링: 실제 테이블, 인덱스, 제약 조건 등 구현

데이터 모델의 구성 요소

개체(Entity): 독립적 존재 (예: 고객)
속성(Attribute): 개체의 특징 (예: 이름, 이메일)
관계(Relationship): 개체 간 연결 (예: 고객은 주문을 한다)

엔티티(Entity)의 종류

강한 엔티티: 고유 식별자 존재
약한 엔티티: 다른 개체 통해 식별됨
중심/행위/조인 엔티티: 역할에 따른 분류

속성(Attribute)의 종류

기본 / 복합 / 유도 속성
단일 / 다중값 속성
식별자 속성: 기본키 후보

관계(Relationship)의 종류

1:1: 하나의 고객 ↔ 하나의 주소
1:N: 한 고객 → 여러 주문
M:N: 학생 ↔ 수업 (조인 테이블 필요)

정규화 단계별 요약

1NF: 원자값 (반복 제거)
2NF: 부분 종속 제거
3NF: 이행 종속 제거
BCNF: 결정자 → 후보키

식별자(Identifier) 정리

기본키(PK): 고유 식별자
후보키(CK): PK 후보
대체키(AK): CK 중 선택되지 않은 것
외래키(FK): 다른 테이블 PK 참조

모델링 품질 3요소

완전성
중복 배제성
업무 적합성

[제로베이스 PM스쿨 29기] 학습일지 - 6 - 제품팀의 구성원과 역할

pokeylog — Tue, 17 Sep 2024 21:33:38 +0900

핵심 내용

제품을 만드는 관점에 따라 제품의 완성도가 달라진다.

제품팀의 구성요소

*️⃣How

자율성 :
- 직접 제품을 개발할 수 있는 아이디어를 낼수 있는 자율성
권한과 책임 :
- 만드는 제품에 대한 자유로운 권한과 애착을 느낄만큼 책임감을 가져야 한다.
지속성 :
- 제품의 유지하고 열정이 계속 될수 있도록 노력
제품에 대한 애정과 관심이 많을 수록 보다 성공할 제품팀이 된다.

*️⃣Who

제품관리자
디자이너
엔지니어

피자 두판의 법칙

팀원의 수와 회의의 참가하는 사람의 수가 피자 두판의 식사하는 사람보다 많아지면 안된다
사공이 많으면 배가 산으로 간다는 비유

팀원의 수가 프로젝트의 성공여부와 상관없다

소규모의 사람이 모일수록 각자의 업무를 더욱 정확하고 확실한 책임감으로 운영할 수 있다.

*️⃣What

일의 유형
- 개선
- : 기존 제품 서비스를 유지하면서 추가 기능 업데이트나 부분만 바꾸는것
- 개편
- : 제품을 유지하지만 서비스 부분을 전체적으로 바꾸는것. 개선보다는 조금 더 큰 부분을 바꾸는 것
- 구축
- : 기존에 없던 새로운 제품, 서비스를 만드는 것
일의 범위
- 단일 제품 전체
- 유의미한 단위의 사용자 경험 담당

더 적은 관리, 더많은 성공

제품팀이 효과적인 이유

협업을 위한 관계 형성
전문성 확보
주인 의식과 책임감

제품 구성원의 역할

제품관리자
디자이너
엔지니어
- 제품 마케팅 매니저
- 사용자 연구원
- 데이터 분석가 등등

*️⃣제품 관리자

제품관리자 Product Manager : 방향 정의

제품소유자 Product Owner : 방향 실행

일하는 방법에 따른 제품 관리자의 영향력

CEO에게 보고 : 하
이해관계자 결정 : 중
스스로 업무 실행 : 상

제품관리자는 제품의 가치를 만들어 가는 사람

고객에 대한 이해

데이터를 기반하여 정량적으로 확인해야 한다.

비즈니스에 대한 이해

필요한 역량

똑똑함
창의적
집요함

✏️ 개인적 생각

제품을 만들 때 내 제품을 만들 때에서 오는 성취감을 통해 보다 내 제품이 인정받고 성공할 수 있다. 또한 제품을 만들면서 팀 내부에서 커뮤니케이션이 무엇보다 중요한데 주의할 점과 함께 하는 일에 대한 이해도 되는 챕터였다.

PM에 대한 과정과 어떤일을 하는지에 대하여

꾸준히 알게 되는 한주였던것 같다. 북스터디와 아티클을 중심으로 하고 있는데

케이스 스터디도 빨리 해야 하는데 아직 가닥을 못잡겠달까...

취업 준비를 하면서 생활비를 벌려고 하니 시간이 쫒기던 한주였다.

앞으로도 시간을 잘 조정해서 봐야 할텐데 그래도

포트폴리오 반에 입과 하기 위해서 꾸준히 작성 해보려 노력 해봐야 겠다.

[제로베이스 PM스쿨 29기] 학습일지 - 5 - 프로덕트 관리의 7단계

pokeylog — Fri, 30 Aug 2024 05:34:16 +0900

프로덕트 관리의 7단계

프로덕트 관리 방법은 따로 없다.

1️⃣ 조직 구성 / 특성

조직 구성원들의 이해 관계 및 의사 결정에 따라 달라지기 때문에 명확하게 정해진 프로덕트 관리 방법은 없다. 또한 회사 분위기도 각기 다르기 때문에 회사의 특징에 맞추어 유연한 사고로 접근 해야 한다.

2️⃣ 제품 특성

회사에서 다루고 있는 제품의 특성에 따라 어떻게 프로덕트를 관리할지 각기 다르기 때문에 유연하게 대응하는 것이 중요하다.

3️⃣ 제품 수명 주기

의사결정 및 개발 기간이 각기 다르기 때문에 제품에 대한 수명주기가 다르게 설정될 수 있다.

보통 진행되는 7가지 스텝으로 진행되는데

이는 위에 설명한 기준에 따라 언제든지 변경 될수 있다.

프로덕트의 성장을 위해 유연한 사고로 대응하는것이 제일 중요하다.

이터레이션을 하면서 고려해야할 사항

1. 사업적 필요와 비전에 맞게 진행

2. 사용자의 니즈와 변화에 맞춰 대응

3. 서비스의 가치 / 효용성을 지속할 수 있게 생각

4. 서비스에 대한 이해를 높이며 진행

5. 프로덕트를 '꾸준히' 운영&개선해 나아가야 한다.

서비스를 깊게 이해하는 법

프로덕트, 사용자, 이해관계자에 대한 이해가 있어야 보다 서비스를 싶게 이해 할 수 있다.

1️⃣ 프로덕트 이해

서비스 핵심가치 이해하기
- 경영철학이나 기업의 가치와 목적을 전달하는것 - ex) 회사경영철학, 비전프로덕트 핵심프로세스 발견
시스템 구조 확인
회사에서 관리하는 지표 확인
중장기 프로덕트 로드맵 확인

2️⃣ 사용자 이해

서비스 타겟 파악
페르소나 그리기

사용자에 대한 구체적 내용을 설정하여 사용자에 대한 목표 설정 및 선호도에 대한 이해도를 높일 수 있다.

3️⃣ 이해관계자 이해

프로덕트 조직 구조를 확인
담당팀의 역할 이해하기

기획	디자인	개발	CA
제품의 전략적 방향과 기능을 정의하고 계획을 수립	UIUX 디자인을 통해 사용자 경험을 설계하고 시각적 인터페이스를 개발	웹과 모바일 어플리케이션의 프론트 엔드와 백엔드 개발을 담당	제품 출시 전 제품이 의도한 대로 작동하는지 확인하고, 버그를 찾아내어 품질을 관리
데이터 분석가와 협력하거나 전략팀, 리서치 팀과 함께 상위 기획을 수행	회사에 따라 디자이너의 범위를 전통적인 UI디자인에 두고, UX 설계를 기획자가 하기도 하며, UT/리서치를 통해 직접 제품 문제를 발견하는 회사도 있는 등 UX디자이너의 업무 범위가 다른 경우가 존재	개발팀은 웹, 앱 프론트엔드(IOS/Android), 백앤드 개발자, DBA, 인프라 관리 등으로 나뉘며, 스타트업에서는 풀스텍 개발자가 프론트와 백엔드 모두를 담당하는 경우도 있습니다.	규모 회사에서는 독립된 QA부서가 있으나, 일부 회사나 스타트업에서는 기획팀 또는 개발팀이 QA 업무를 겸임하기도 함

"서비스와 사용자 간의 경험에 따라 시스템 구조가 이뤄지고 파악하는 것이 중요"

그에 따른 개발 진행 사항이나 프로세스 파악을 위해 확인 필요

벌써 8월달의 막바지를 달리고 있는 제로베이스

벌써 강의도 많이 진행됬고 기록하고 있는것도 차근차근 늘어가고 있는데

볼때마다 너무 뿌듯...

계속 쌓아 봐야지

[제로베이스 PM스쿨 29기] 학습일지 - 4 - 역시 도전하길 잘했다.

pokeylog — Tue, 20 Aug 2024 21:44:40 +0900

오늘 학습 목표 및 내용

벌써 3주차가 됬다니 8월에 시작한 PM 스쿨이 벌써 한달이 거의 다 지나갔다. 처음에 PM스쿨에 대하여 엄청 걱정하면서 할까말까 고민이 많았는데 빨리 시작할껄이라는 생각이 들었다. 오늘의 학습목표는 일일 목표를 해치우고 미뤄왔던 케이스 스터디를 진행해보려 한다. 실제 어플을 깔아서 살펴보는게 제일 좋은 스터디겠지 꾸준히 쌓아가면 뭐라도 되지않을까 열심히 해봐야 겠다.

수강하면서 흥미로웠던 부분

혼자 공부하다가 학습 매니저 분이 관리를 해주는게 느껴져서 초조해지는 기분을 오랜만에 느꼈다. 혼자 했었다면 계속 한없이 미루다 이것도 저것도 안돼겠지. 그리고 다른 학습생 분들의 결과물을 함께 보면서도 같은 걸 읽거나 분석해도 관점이 매우 다를 수 도 있고 결과 물이 좋은 분들을 보고 크게 공부 자극을 얻고 있다. 보다 열심히 해봐야 겠다.

내일 학습 계획 및 내일의 나에게 하는 응원

오늘 자기 전까지 최대한 작업을 해보고 많은 인사이트를 얻어야지 종종 작업했던걸 여기에도 올려서 더 많은 피드백을 받아보고 싶다. 피드백을 두려워 하지않아야 더 좋은 인사이트가 나오니까 열심히 노력해봐야 겠다.

서비스 기획자가작성하는 문서 5가지

pokeylog — Mon, 19 Aug 2024 00:44:32 +0900

요구사항 정의서

프로젝트의 목표, 기능, 제약 사항 등을 명확하게 정의하여 프로젝트의 전체적인 방향을 제시하는 문서.

요구사항 정의서는 프로젝트 방향성을 명확히 하고, 이해관계자들 간의 오해를 줄이며, 일정과 예산을 효율적으로 관리 하도록 한다.

요구사항 정의서는 어떻게 작성하는가?

: 이해관계자의 정확한 요구사항 수집, 분석, 구분을 통해 요구사항 정의서 작성

요구사항 정의서 작성

프로젝트 인식 : 프로젝트의 목적, 배경, 범위 등 명확히 표현
이해관계자 식별
시스템이 수행해야할 기능들 정의
비기능적 요구사항 :시스템의 성능, 보안, 사용성, 유지 보수성 등등
제약 사항 및 예상 결과

서비스 정책서

:서비스 정책은 기획하고자 하는 서비스의 개념과 역할 그리고 개략적인 구조가 정의되는 단계로 서비스를 구체화하고 골격을 잡아주는 역할. 서비스 정책서는 고객의 회원 가입에서부터 회원 탈퇴까지 서비스를 기획하는데 필요한 정책을 정리한 문서

Why?

- 모두가 합의된 규칙을 통해 실행단계에서 일관성을 유지하기 위함

- 규칙을 정의 하는 과정에서 여러 변수들을 고려함으로써 안정적인 실행을 하기 위해 필요한 정책을 정의 하는 과정

정보 구조도(IA)

: Information Architecture는 서비스의 전체를 이루는 정보가 사용자에게 효과적으로 전달 될 수 있도록 설계되고,

설계된 정보를 시각화한 UI를 통해 사용자에게 전달 하는 역할. 서비스의 전체 구조를 지탱하는 뼈대와 같다.

들어가는 요소

1. 기능코드

2. 메뉴(Depth) 별로

3. 기능 이름, 설명 및 정의

4. 기능 구성

5. 레퍼런스

6. 개발필요사항

7. 비고

화면 설계서(화면정의서 SB, Story Board)

: 구현하기 전 필요한 기능, 정책 등 화면 내 서비스의 모든 요소에 대해 정의 하여 서비스 화면의 이해를 돕기 위한 문서

“기획자는 모두를 만족시킬 수 없지만 모두를 이해시켜야 한다.”

사용자에게 보이는 화면을 UI/UX 관점에서작성 및 설명이 필요하다. 다양한 툴로 제작

Why?

- 구현 단계에서 이해관계자들이 업무를 하는 데 있어 참고 할 수 있는 문서

- 구현 단계 전 기능, 정책 등의 요소에 대한 정의 및 전반적인 테스트 가능

How?

- 표지, 개정이력, 플로우차트(연동, 화면 관점의 흐름도),설계화면 순 작성

- 본 문서 작성전 UI, 정책, 컴포넌트 등 공통요소에 대한 가이드 정의

- 이해관계자들이 화면과 설명에 대해 일관성 있는 이해가 가능해야 함.

- 디자인 영역을 침범하지 않는 선에서 화면을 그려야 함.

와이어프레임

와이어프레임은 프로젝트 또는 기술의 기본 프레임 워크를 요약하는 시각적 다이어그램이다. 페이지나 모바일 앱 구조를 요약하여 특정 요소를 어디에 배치하고 전체적인 디자인이 어떤 모습일지를 디자이너가 판단하는데 도움이 된다.

프로젝트 관리에서 와이어프레임의 목적과 목표

- 프로젝트의 목표에 대하여 반영사항이 시각적으로 확인 가능

- 구현 단계 전 기능, 정책 등의 요소에 대한 프로세스와 리소스 확인

- 디자이너, UX 디자이너, 개발자와 함께 시각화 된 데이터 확인

참고

[제로베이스 PM스쿨 29기] 학습일지 - 3 - 나만의 속도 찾기

pokeylog — Mon, 19 Aug 2024 00:20:43 +0900

오늘 학습 목표 및 내용

2주차 과제와 강의 못들었던 내용을 보강하고 보다 더 많은 내용을 공부하기 위해 여러 자료들을 찾아봐야 겠다. 처음으로 진행하는 주차별 과제에 대하여 여러 자료들을 찾아보고 있는데 다른 내용 정리 하면서 기록을 하는 과정을 하고 있는데 생생각보다 너무 어렵게 생각하고 있는가에 대한 고민이 생겼다. 정리를 하고 나면 도식화를 해서 보다 쉽게 알아볼수 있게 하는게 좋을 텐데 아직 그런 능력이 부족한것 같아 계속 노력해봐야 겠다.

실제 학습시간

스터디와 강의를 정리하면서 보게 되니까 시간이 무한정으로 늘어났다. 각각의 내용을 이해하고 내가 실제로 사용할 수 있는 지식으로 받아드리기에는 쫒기면서 정리만 하지 않았나 싶다. 내용을 이해한뒤 정리를 진행하는 방향으로 해서 보다 효율적인 작업 방식을 찾아야 겠다.

수강하면서 흥미로웠던 부분

실제 실무에서 활용하는 방향이나 방법을 알려줘서 더 재미있게 수업을 들을 수 있었던것 같다. 또한 많은 이론들과 방법들이 나오지만 실무에서는 어떻게 적용해서 사용할지가 제일 중요한데 그것에 포인트가 맞춰져 있어 더욱 재미있게 듣고 있다. 아직 시작한지 2주 밖에 안돼지만 앞으로의 쌓인 나의 데이터가 기대된다.

내일 학습 계획 및 내일의 나에게 하는 응원

아직 많이 모자르고 따라가기 급급하지만 점점 나만의 포인트와 속도를 찾아갈 수 있을것 같다. 조금더 부지런히 분발해보는게 나의 목표다.

시대예보: 핵개인의 시대 - 코파일럿은 퇴근하지 않는다 : 기획자 시점에서 보는 AI

pokeylog — Sun, 18 Aug 2024 00:30:07 +0900

출처 : 교보문고

선정이유

AI 산업의 발전에 따라 AI의 중요성이 커지고 있다. 이 책은 2023년에 출판되었지만, 2024년에 들어서며 현재 시대를 관통하는 이야기들이 많아 빠르게 시대를 읽는 힘이 중요할것 같아 선택했다.

특히 AI 관련한 2장을 선택했다. 내용 중 미래 시대에 관련하여 어떻게 접근해야할지, 서비스 기획을 하면서 미래에는 어떤 시선으로 기획을 할지에 대한 시각을 넓힐 수 있었다. PMPO에 대한 생각을 더 깊이 있게 만들어줄 수 있는 구절들이 많아 선정하게 되었다.

핵심내용 정리

코파일럿(AI)은 퇴근하지 않는다.

근대화의 기준을 시간 개념의 정립으로 삼기도 한다.

‘첫 닭이 울 때’, ‘첫 서리가 내릴 무렵 모이자’는 기준이 농경이나 목축사회에서나 통했다.
산업화로 큰공장이 돌기 시작하면서 기계를 멈추지 않기 위해 정해진 시각에 한자리 모여 함께 일하는걸로 변화

시간은 소중한 기준이 되었다.

근대인은 설비가 있는 장소에 물리적으로 동일한 시간에 모여 함께 일하고 헤어지는 일에 적응하면서 일하는 주기에 생체시계를 맞춰갔다.

일어나서 잠들 때까지 깨어 있는 시간 대부분을 직장에서 보낸다.

이 시스템 속에서 본질적으로 파는 것은 개인의 시간

AI와 합을 맞춘 완전체 개인

만약 파는 것의 본질이 시간이 아닌 지능을 판다면?

개인은 언제 어디에 있어도 무방
더 이상 시간과 장소가 중요한 변수가 아니기 때문

그럼 현재 시간은 누가 팔고 있는가?

로봇이 인간의 막노동이나 작업을 대신해주는 시대
- AI는 퇴근하지 않고, 잠도 자지 않는다.
- AI는 노동량에 비례해도 월급이 사람보다 상대적으로 적다. > 전기세, 이용료만 사용
- 무엇보다 일을 해주는 AI를 계속해서 복사 가능

AI 와의 협력이 익숙해지면 자동화를 통해 인력 감축 혹은 혼자서 일하는게 가능해진다.

자동화의 가속화가 된다면 결국 혼자서 엄청난 일을 하는 사람, ‘AI 디렉터’ 로서 진화를 추동

기계가 좋아서가 아니라 사람이 불편해서

팬더믹 시기에 재택 근무라는 새로운 경험을 쌓은 사람들 때문에 집도 회사도 아닌 제3의 공간에서 개인적 시간을 보내는 경험이 확산 되었다.

문제 발생

눈치를 주는 카페 주인과의 신경전이 이슈

✅문제 해결

키오스크로 주문을 받고 로봇 바리스타가 커피를 내주는 무인 로봇 카페 생성

최근 시간당 임금 상승 속도가 빨리지면서 1인 창업이 늘고 있다.

자동화 비대면 기술의 범용화
무인 서비스 경험의 누적
숨겨진 요인인 관계 맺기를 힘들어하는 사람들
- EX - 배달의 민족

잠도 안자고 화도 안내고 영어도 잘하는 로봇

인간은 어떤 기술을 익힐 때 긴 시간 수련이 필요하지만 로봇은 데이터만 전송하면 끝.
- 인류는 로봇의 시간 경쟁력을 당해낼 재간이 없다..
로봇 노동은 첨단 의료 산업 뿐 아니라 서빙과 돌봄 등 일상의 최후방 산업까지 침투할 것이다.
- 로봇 서비스가 하나의 산업으로 자리 잡을 것
또한 로봇은 자신의 권리를 주장하지 않기에 기업 입장에서는 관리와 경영 부담이 훨씬 적다.

로봇과 AI의 핵심

로봇 : 물리적, 정서적 행위의 자동화
AI : 지능적, 창조적 활동의 자동화

결국 인간은 창조적, 지능적, 육체적, 정서적 활동 그 모든 영역에서 로봇, AI 와 함께하게 될 운명

사진 한 장만 던지면 AI가 다 해주는

직접 여행 계획을 세울 때 2000년도 초반까지는 신문지 하단의 여행사를 보고 항공권부터 숙박 여행지 등등을 다 각자 다른 매체에서 계속 밤잠도 못 자고 찾아야 했다. 혹은 여행사를 고르고 여행사에서 제시하는 단체 여행 그대로만 다녀야 한다.

하지만 다행히 AI는 지치지 않고 잠도 자지 않는다.

온갖 비행기표를 사이트별 최저가를 찾아주고 해당 여행지의 가장 평이 좋은 호텔을 고르고 나의 동선에 가장 가까운 관광지를 추천하고 근처 호텔까지 예약 동시에 할 수 있다. 또한 나의 취향에 맞는 음식, 체험, 언어 등등 오직 나만의 취향을 분석하여 나를 위해 AI는 빠르게 정리해준다.

이러한 여행 매칭 서비스는 인간이 관여 하지 않는다.

AI들이 시스템 레벨에서 정보를 주고받으면서 조건을 조율하고 나 만을 위한 상품을 만들어 낸다.

심지어 비용도 저렴하다

내가 소비 주체라도 AI의 트레이닝이 더 우수해지면, AI가 상권을 만들어 낼 수 있다.

알고리즘이 인간보다 더 시장을 쥐고 흔드는 것이다.

나의 마음을 가장 잘 아는 동료는 어쩌면 사람이 아닌 AI 일수도

AI가 내가 전달한 정보를 기반으로 나에 관해 더 깊게 학습을 한 뒤 나만의 컴포넌트가 만들어 진다.

이를 기판으로 더 정교한 인풋과 아웃풋이 생성되고 이후 상호작용을 통해 더욱 지식이 쌓여 더욱 정밀한 나만의 동료가 생성된다.

기술의 보급과 AI의 확산은 사람과 사람의 소통을 대체할 뿐만 아니라, 사람과 대화하며 협업하는 것보다 더욱 진보 된 편리를 가져올 수도 있다.

AI를 통한 자동화에서 가장 강력한 효용은 속도

인간과 AI의 공존

다양한 개체와 상호작용하고 높은 차원의 문제 정의가 가능한 사람일수록 생산성이 높은 ‘고급인력이 될 수 있다.
지금의 교육으로 이런 인재를 양성 할 수 있을지 깊게 고민이 필요하다.
생성형 AI와의 협업은 인간 능력의 순위를 계속 재조정 하게 될 것이다.
- 묵묵한 인내와 지구력보다 AI가 생각하지 못하는 엉뚱함이 더욱 주목 받을 시대가 온다.
고정된 틀에 갇히지 않아 그때그때 새로운 환경에 잘 적응하는 사람들이 더 높은 생산성에 도달할 수 있다.
답이 있는 문제는 AI가 풀고, 인간은 답이 없는 문제를 고민하는 역할로 분업이 이루어 질것이다.
- 현재 서비스 기획과 PM/PO의 중요성이 올라가는 문제라고 생각한다.

✏️Insight

점점 가속화되는 시대에서 AI가 가져올 큰 흐름에 대해 시각을 넓힐 수 있었던 책이었다. 이전 시대에 디지털 드로잉에 반감을 가졌던 사람들이 소외되거나 트렌드에 합류하지 못하고 멀어진 경향이 있었듯이, 이 책을 읽으며 AI가 피할 수 없는 시대의 큰 흐름이라는 것을 크게 느꼈다. 이 책에는 AI 외에도 트렌드에 대한 상세한 분석이 있어, 생각지 못한 부분들이 많이 명시되어 있다. 특히 2023년과 2024년 사이의 짧은 기간에 이 책에서 언급한 내용들이 실제로 구현되고 있는 것을 보며, 트렌드와 사용자에 대해 더 깊이 공부하고 더 넓은 시각으로 바라볼 수 있게 해준 책이었다.

AI에 대한 무서움도 있지만 이것을 활용하면 할수록 더욱 빠르게 나의 지능을 극대화 시킬 수 있지 않을까. 또한 IT에 대한 중요성과 개인에 대한 시각의 역발상도 다양하게 할 수 있었던 책이다. 서비스를 기획하는 단계에서 제일 중요하다고 생각하는건 문제를 찾고 해결하는 방향이라고 생각하는데 문제를 찾는 과정에서도 도움이 정말 많이 될것 같은 책이었다.

용어정리

화이트칼라 직무자
- 미국 지역 신문에서 직업을 옷깃의 색으로 분류한 단어
- 관리, 기술, 사무 등에 종사하는 이들
- 노동장소 : 사무실 / 경영상 지위(경영자와 노동자 사이의 지위) / 직무 내용(정신노동)
블루칼라 직무자
- 현장에서 일하던 노동자들은 청바지에 청색 셔츠를 입어 육체노동을 하는 이들을 뜻한다.
컴포넌트component
- 프로그램에서 제 사용이 가능한 각각의 독립된 모듈

인스파이어드 Chapter 1 최신 기술로 무장한 제품이 실패하는 이유

pokeylog — Sun, 18 Aug 2024 00:23:23 +0900

인스파이어드

왜 어떤 제품은 ‘대박’을 터트리고 어떤 제품은 그러지 못할까? 인터넷 산업의 초기 시절에는 한 회사가 어느 지역에 위치했는지가 그 회사가 일하는 방식에 큰 영향을 미쳤습니다. 하지만 오늘날 지역은 큰 의미가 없어졌습니다. 최고의 회사와 제품팀을 세계 각지에서 만나 볼 수 있습니다. 다만 최고의 기업과 팀이 일하는 방식과 나머지 평범한 기업과 팀이 일하는 방식에는 여전히 큰 차이가 있습니다. 이 고유한 차이가 모여서 최고의 기술 제품을 만듭니다. 이 책은 최고의 제품팀이 어떻게 일하는지를 설명합니다. 이 책을 읽는 독자들이 세계 최고 수준의 팀처럼 업무 혁신을 통해 성과를 낼 수 있기를 기대합니다.

저자: 마티 케이건

출판: 제이펍

출판일: 2018.12.28

사랑받는 제품을 만들기 위해

‘필요한’ 서비스, 제품을 넘어 사랑받는 제품을 만들기 위한 ‘우리’가 되기 위한 지침서

‘인스파이어드’ 주제

기술 제품 관리자가 하는 일
올바른 제품 문화 만들기

✔️ 핵심내용

Chapter 01 최신 기술로 무장한 제품이 실패하는 이유

실패한 제품

윈도우 8

시작 버튼을 메인 화면으로 만들었지만 사람들
멀티플랫폼에 특화된 OS로 스마트폰과 태블릿에서 사용할 수 있는 최신기술이지만, PC 사용환경에 익숙하지 않은 사용자를 배려하지 못한 기술
사용자의 이용성을 고려하지 못한 UI/UX

세그웨이

인도에서 너무 빠르고 차도에서는 너무 느려 사용하기 어려웠다.
사용자에 대한 부정적 인식과 비싼 가격 때문에 실패한 사례

구글 글래스

2012년도에 나온 증강 현실에 대한 혁신적인 기술이 도입된 안경
착용한 사람이 다른 사람에게 어떻게 보일지 고려하지 않아 실패한 사례
불편한 착용감 및 사생활 배려를 못한 제품

제품은 왜 실패할까?

제품을 만들 때는 사용자를 생각해야 한다.

제품은 어떻게 만들어지는가?

발견
기획
구현 (디자인/개발)
출시

제품관리자의 필요

기획 : 제품을 정의하고 서비스 방향 수립
디자인 : 시각화 및 구체화
개발 : 실제 사용이 가능하도록 구현
제품관리자 : 비즈니스, 기술/디자인을 일련적으로 관리

제품 관리자와 프로젝트 관리자의 차이

Project Manager

제품을 완성하는데 중점을 둔 PM

Product Manager

제품을 만들어 가는 것에 중점을 둔 PM

기술 중심 제품과 서비스

전자 상거래 사이트 및 중계 서비스

재화 또는 용역의 거래에 있어서 그 전부 또는 일부가 전자 문서에 의하여 처리되는 방법으로 이루어지는 상행위
주문, 결제, 이행단계 중 하나의 단계에서 전자 문서가 활용될 경우 전자 상거래가 성립함

소셜 미디어

소셜 네트워크의 기반 위에서 개인의 생각이나 의견, 경험, 정보 등을 서로 공유하고 타인과의 관계를 생성 /또는 확장하는 서비스

비즈니스 서비스

B2B(business-to-business) 또는 기업 대 기업은 기업과 기업 사이의 거래를 기반으로 한 비즈니스 모델

소비자 디바이스

소비자 : 재화를 소비하는 사람
디바이스 : 어떤 특정한 목적을 위하여 구성한 기계적, 전기적, 전자적인 장치

회사의 종류

1️⃣스타트업

초기 시장의 니즈에 부합하는 강력한 제품을 만들어 내야 하는 단계

예시 : 당근마켓, 쏘카, 직방, 텀블벅

2️⃣성장단계

핵심 비즈니스를 완성해 가고 확장할 수 있는 제품과 서비스를 고민해야 하는 단계

3️⃣대기업

끊임없는 제품 혁신을 통해 지속해서 새로운 가치를 제공해야 하는 단계

✔️ 개인적 생각

이 파트를 통해 제품과 사용자에 대해 더욱 세심하게 이해할 수 있었다. 각 회사가 사용자를 얼마나 배려하느냐에 따라 프로젝트의 성공 여부가 결정되므로, 보다 섬세한 사고가 중요하다는 점을 깨달았다.

[제로베이스 PM스쿨 29기] 학습일지 - 2 - 프로덕트 이해 및 관리방법

pokeylog — Wed, 14 Aug 2024 17:39:49 +0900

핵심 내용 정리

✳ 프로덕트 관리방법

- 프로덕트 관리방법의 정답은 없다. 회사마다 조직구성/특성, 제품특성, 제품수명 주기에 따라 다르다.

프로덕트 관리 7 steps

1. 서비스이해

2. 정보수집

3. 로드맵

4. 문제발견과 솔루션 도출

5. 우선순위 선정

6. 수행

7. 평가/회고

❇ 프로덕트 성장을 만드는 꾸준한 반복, 이터레이션!

1. 사업적 필요와 비전에 맞게

2. 사용자의 니즈와 변화에 맞춰

3. 서비스의 가치/효용성을 지속할 수 있게

4. 서비스에 대한 이해를 높이며

5. 프로덕트를 '꾸준히' 운영&개선해 나가는 일

✅서비스를 깊게 이해하는 법

단계	체크리스트
프로덕트이해	서비스 핵심가치 이해하기 - 경영철학이나 기업의 가치와 목적을 전달하는것 ex) 회사경영철학, 비전
	프로덕트 핵심프로세스 발견 -
	시스템 구조 확인
	회사에서 관리하는 지표 확인
	중장기 프로덕트 로드맵 확인
사용자 이해	서비스 타겟 파악
사용자 이해	페르소나 그리기
이해관계자 이해	프로덕트 조직 구조를 확인
이해관계자 이해	담당팀의 역할 이해하기

1. 프로덕트 이해

서비스 핵심 프로세스 및 시스템 구조 확인

시스템 구조확인

서비스와 사용자 간의 경험에 따라 시스템 구조가 이뤄지는 것을 파악하는 것이 중요

그에 따른 개발 진행 사항이나 프로세스의 파악을 위해 확인이 필요

사업지표확인

사업지표	서비스지표	만족도지표
1. 재무지표 : 매출, 영업이익, 순이익, 거래액 등 2. 시장지표 : 점유율, 사용자 획득비용, 고객생에가치(LTV) 등 3. 서비스 핵심지표 : 인당거래횟수/빈도, 평균구매금액 등	DAU(Daily Active User) MAU(Monthly Active User) Stickiness(Dau/Mau)(일/월) PV(Page View)/UV(User view) 체류시간 퍼널간 전환율 이탈률/재방문률	고객추천지수 (NPS) 설문조사 결과 앱스토어 리뷰 CS 만족도 점수

서비스 로드맵 확인

로드맵을 확인하는 이유?

1. 전략적 방향 설정

2. 우선순위 결정

3. 이해관계자와의 커뮤니케이션

4. 시장과 고객의 변화에 대응

5. 팀원 및 부서 간의 협력 강화

6. 위험관리

단계		기간별 로드맵
네이버 웹툰	최근 3년	글로벌시장확장, 해외 시장 점유율 확대, 콘텐츠 제작 및 번역 자동화
	최근 1년	웹툰 IP 활용, 영화/드라마/게임 제작 및 배급, AI 기술 도입
	향후	웹툰 IP 활용 콘텐츠 다각화, 엔터테인먼트 콘텐츠 확대, AI 기술 적용 확대
토스	최근 3년	풀 스택 금융 서비스 전략 추진, 투자/보험/대출 서비스 통합, 동남아시아 시장 진출 모색
	최근 1년	사용자 경험 개선, 금융 기관 파트너십 확장, AI 기반 맞춤형 금융 조언 강화, 국내 집중 사업
	향후	블록체인 및 AI 기술 적극 도입, 혁신적 서비스 개발 지속

2. 사용자 이해

타겟 파악 + 페르소나 그리기

사용자에 대한 구체적 내용을 설정 및 사용자 목표 설정

3. 이해관계자 이해

프로덕트 조직구조 이해

기획, 디자인, 개발, QA 가 합쳐져 사업으로 이어지는 구조로

각각의 역할에 대한 이해와 관계성을 파악하는 게 중요.

서버, 보안, 네트워크, 운영, CS가 합쳐져 진행

담당팀의 역할 이해하기

단계	역할 / 조직구성
기획	역할: 제품의 전략적 방향과 기능을 정의하고 계획을 수립합니다. 협업 : 데이터 분석가와 협력하거나, 전략팀, 리서치 팀과 함께 상위 기획을 수행합니다.
디자인	역할 : UIUX 디자인을 통해 사용자 경험을 설계하고 시각적 인터페이스를 개발 참고 : 회사에 따라 디자이너의 범위를 전통적인 UI 디자인에 두고, UX 설계를 기획자가 하기도 하며, UT/리서치를 통해 직접 제품 문제를 발견하는 회사도 있는 등 UX 디자이너의 업무 범위가 다른 경우가 존재 한다.
개발	역할: 웹과 모바일 어플리케이션의 프론트 엔드와 백엔드 개발을 담당 분류 : 개발팀은 웹, 앱 프론트엔드(IOS/Android), 백엔드 개발자, DBA, 인프라 관리등으로 나뉘며, 스타트업에서는 풀스택 개발자가 프론트와 백엔드 모두를 담당하는 경우도 있습니다. 외주화: 내주벅으로 관리가 어려운 기능은 외부 업체에 의뢰하여 개발하기도 함
CA	역할: 제품 출시 전 제품이 의도한 대로 작동하는지 확인하고, 버그를 찾아내어 품질을 관리합니다. 조직 구성 : 대규모 회사에서는 독립된 QA 부서가 있으나, 일부 회사나 스타트업에서는 기획팀 또는 개발팀이 QA 업무를 겸임하기도 함

수강하면서 흥미로웠던 부분

각각의 프로젝트가 진행되면서 각각의 파트별 진행상황의 공유에 대해 보다 자세히 알게 된 계기였다.다양한 직무에 대한 이해도와 이를 중간에서 관리해야 하는 PMPO는 각각의 직무에 대해 이해도가 높아야 커뮤니케이션이 보다 잘될 거라는 생각이 든다. 다양한 경영 지표를 볼 수 있었는데 그에 따른 상호작용이나 신경 써야 할 부분도 많아서용어에 대한 정리도 많이 필요할 것 같다.

학습소감

오늘의 나의 학습 만족도는 할수록 모르는 게 많다는 게 확연하게 느껴졌다.

기존에 일해봤던 직무와 전혀 다른 직무라는 걸 확실히 알았고 보다 겸손하게 공부에 전념을 해야 된다는 생각이 들었다.

하루하루 해내야 하는 과제량이 1주 차와 2배가량 차이가 나는데

앞으로도 차곡차곡 쌓이면 뿌듯하겠지.

1주 차 때 허둥지둥 마무리를 했는데 2주 차에는 과제를 꽉 채워서 제출해서

피드백받을 수 있도록 노력해야겠다.

오랜만에 문서 작성이나 정리하는 것도 능력이라고 하는데 다른 분들과 함께 공부하는 걸 인증하고 가끔 보게 되는데 확실히 자극이 많이 됐다.정말 정리 잘하시는 분들도 너무 부럽지만 그 센스 넘치시는 분들도 함께 보여서 본받아야겠다는 생각이 든다. 또한 아티클 공부나 아이데이션을 정리하면서도 많은 도전을 할 수 있어 더욱 좋았던 것 같다. 꾸준히 실력을 늘려가는 게 좋은 것이겠지 잘하는 것에 대해 왕도는 없다. 확실히 꾸준히 하자.

[제로베이스 PM스쿨 29기] 학습일지 - 1 - PM에 대한 이해와 개념, 앞으로의 결심

pokeylog — Fri, 9 Aug 2024 16:50:39 +0900

이전에 웹개발자로 실무에서 일했을 때 종종 들려오던 PM

정확한 직무에 대해서는 잘 몰랐지만 프로젝트를 이끌어 오고 다양한 직무와 함께 프로젝트를 이끌 수 있다는 직무라고 해서 흥미가 생겨서 후기와 리뷰를 한참 찾아보던 중 제로베이스가 괜찮은 것 같아 선택하게 됐다.

출처 : 제로베이스 (https://zero-base.co.kr/event/media_insight_contents_PM_PMmeaning)

PM에 대한 기준이 모호했는데 기획자나 PM에 대하여 보다 정확하게 공부할 수 있었고 하는 일에 대하여 제대로 알 수 있게 된 첫 번째 주!

각 커머스와 다양한 비즈니스 모델에 따라 각각 다른 직무를 할 수 있었는데 이렇다 정확한 일이 없지만 보다 서비스의 비전과 청사진을 제시하는 선구자로 보다 프로젝트를 이끌어 갈 수 있는 PM에 대한 이해와 직무에 대하여 알 수 있는 주였다.

마지막까지 고민을 하다가 합류하게 된 제로베이스인데 합류가 살짝 늦어져 부랴부랴 과제와 강의를 열심히 듣게 됐는데 늦게 시작한 만큼 열심히 해서 빈 시간들을 매워야겠다는 결심이 생겼다.

출처 : 제로베이스(https://zero-base.co.kr/event/media_insight_contents_PM_PMtypes)

기준이 모호했던 PM에 대하여 실무에 도입되는 순간마다 직무에 대한 이름이 달라지기도 하지만 프로젝트를 이끌어 가 새로운 제품이나 보다 서비스 개선을 위해 일을 한다는 게 너무 재미있는 직무인 것 같다. 아직 초기의 단계의 PM 공부이지만 앞으로 꾸준히 쌓아가서 열심히 해봐야겠다.