오늘은 서비스 기획 심화 챕터 전체를 들으면서 PM이 반드시 갖춰야 할 핵심 문서 5종과 소프트 스킬 4가지를 한꺼번에 정리하는 시간을 가졌다. 처음엔 PRD·IA·정책서 같은 개념이 각각 따로 노는 것처럼 보였는데, 배우면서 보니 결국 모두 하나로 이어진다는 걸 알게 됐다. "모든 문서는 협업자가 질문 없이 이해할 수 있어야 한다." 그게 PM 문서의 본질이다.
1. PRD (요구사항 정의서) — 제품 개발의 지침서
PRD는 처음에 "기능 목록 적는 거 아닌가?" 싶었는데 훨씬 체계적인 개념이었다. 제품 개발 과정에서 개발자·디자이너·기획자가 같은 방향으로 일할 수 있게 기준을 잡아주는 지침서다. 정해진 형식은 없고, 목적에 맞게 필요한 항목만 담으면 된다.
PRD 핵심 구성 요소
| 항목 | 설명 | 예시 | 필요 여부 |
|---|---|---|---|
| 프로젝트 개요 | 서비스 배경, 목적, 기대 효과 | 배달 앱 장바구니 개선으로 결제 이탈률 감소 | 항상 |
| 타겟 사용자 | 누가 이 기능을 사용하는가 | 20–40대 직장인, 배달 앱 이용자 | 항상 |
| 기능 목록 + 설명 | 각 기능이 무엇을 하는지 구체적으로 | 회원가입, 로그인, 장바구니, 결제 | 항상 |
| 구현 기준 | 기능이 어떻게 동작해야 하는지 | 장바구니에 음식 추가, 결제 전 수량 조정, 삭제 가능 | 항상 |
| 우선순위 | 필수 / 권장 / 선택 구분 | 로그인(필수), 위시리스트(권장), 다크모드(선택) | 항상 |
| 릴리즈 계획 | 단계별 출시 일정 | 1단계: 핵심 기능 2주, 2단계: 부가 기능 1개월 | 상황에 따라 |
| 기대 성과 | 완료 시 측정할 수 있는 지표 | 결제 전환율 15% 향상, 이탈률 10% 감소 | 상황에 따라 |
모호한 표현 vs 구체적 표현
| ❌ 이렇게 쓰면 안 됨 | ✅ 이렇게 써야 함 | 왜 다른가 |
|---|---|---|
| 앱 빠르게 로딩해주세요 | 홈 화면을 열고 3초 이내에 로딩 완료 | 기준값 없으면 개발자마다 다르게 해석 |
| 예쁘게 고쳐주세요 | 버튼 color #2563EB, height 48→64px 변경 | 디자이너가 바로 작업 가능한 수치 |
| 최대한 빨리 해주세요 | 이번 주 금요일 오후 6시까지 | 기한이 없으면 우선순위에서 밀림 |
| 로그인 기능 만들어주세요 | 이메일/비밀번호 로그인, 실패 시 3초 대기, 2주 후 완료 | 조건이 명확해야 테스트 케이스도 만들 수 있음 |
💡 핵심 포인트
"측정 가능한 수치·기간·조건이 없는 요구사항은 요구사항이 아니다."
PRD의 형식보다 "협업자가 이걸 읽고 바로 작업을 시작할 수 있는가"가 진짜 기준이다. 마켓컬리 데이터 PM 사례처럼, 요청이 들어왔을 때 스무고개처럼 Why를 물어가며 구체화하는 게 PRD의 시작이다.
"측정 가능한 수치·기간·조건이 없는 요구사항은 요구사항이 아니다."
PRD의 형식보다 "협업자가 이걸 읽고 바로 작업을 시작할 수 있는가"가 진짜 기준이다. 마켓컬리 데이터 PM 사례처럼, 요청이 들어왔을 때 스무고개처럼 Why를 물어가며 구체화하는 게 PRD의 시작이다.
2. IA (정보구조도) — 서비스의 뼈대를 설계하는 것
IA(Information Architecture)는 "어디에 무엇을 배치하고 어떻게 연결할지"를 설계하는 작업이다. 건축설계사가 집을 짓기 전에 도면을 그리듯, PM은 서비스를 만들기 전에 IA를 그린다. 좋은 IA의 기준은 딱 하나, 사용자가 3번 클릭 안에 원하는 걸 찾을 수 있는가다.
Depth(뎁스) 계층 구조
| Depth | 위치 | 실무 예시 (채용 진행 사이트) | 특징 |
|---|---|---|---|
| 1 Depth | 최상위 메뉴 | 채용 / 조직 심사 현황 / 인재풀 / 수습해제 | 가장 중요. 권한 없이 모두에게 노출 |
| 2 Depth | 하위 메뉴 | 서류 심사 / 면접 평가 / 최종 합격 | 1 Depth 선택 후 나타남. 태스크 유무로 노출 구분 |
| 3 Depth | 상세 메뉴 | IT서비스실 / 서비스인프라실 (겸직 시 복수 탭) | 권한(실장 이상)에 따라 다르게 노출 |
IA를 만드는 3가지 이유
| 목적 | 설명 | IA가 없으면 생기는 문제 |
|---|---|---|
| UX 개선 | 사용자가 원하는 정보를 빠르고 쉽게 찾는 구조 | 쇼핑몰에서 주문내역을 못 찾아 이탈 |
| 협업 소통 | 팀 전체가 기능 위치·관계를 한눈에 파악 | "그 기능이 어디 있어요?"가 반복됨 |
| 확장 유연성 | 기능 추가 시 구조를 뜯어고치지 않아도 됨 | 메뉴 추가할 때마다 전체 구조 변경 |
💡 핵심 포인트
"1 Depth에 무엇을 두느냐가 그 서비스의 철학을 보여준다."
IA 연습 방법: 다양한 쇼핑몰 카테고리를 보면서 "왜 이렇게 구분했을까?" 분석해보는 것. 어떤 곳은 '여성/남성'으로, 어떤 곳은 '상의/하의'로 나누는 차이가 그 서비스가 사용자를 어떻게 보는지를 반영한다.
"1 Depth에 무엇을 두느냐가 그 서비스의 철학을 보여준다."
IA 연습 방법: 다양한 쇼핑몰 카테고리를 보면서 "왜 이렇게 구분했을까?" 분석해보는 것. 어떤 곳은 '여성/남성'으로, 어떤 곳은 '상의/하의'로 나누는 차이가 그 서비스가 사용자를 어떻게 보는지를 반영한다.
3. 서비스 정책서 — 기준을 문서로 남기는 것
처음엔 "그냥 회사 규정집 아닌가?" 싶었는데 완전히 달랐다. 서비스 정책서는 기능이 어떤 기준으로 동작해야 하는지를 명문화하는 문서다. 권한은 누구에게 있는지, 비밀번호는 어떤 규칙인지, 예외는 어떻게 처리할지 — 이걸 미리 정해두지 않으면 개발 도중 "어쩌죠?"를 반복하게 된다.
정책서가 필요한 4가지 이유
| 이유 | 설명 | 없으면 어떻게 되는가 |
|---|---|---|
| 일관성 | 팀 전체가 동일한 기준으로 작업 | 개발자마다 다르게 구현 |
| 협업·소통 | 불필요한 논의와 혼선 감소 | "이건 어떻게 해요?" 반복 질문 |
| 법적 준수 | GDPR(유럽), CCPA(미국) 등 각국 법령 반영 | 위반 시 건당 최대 7,500달러(약 1,033만 원) 벌금 |
| 보안 강화 | 비밀번호·접근 권한 등 보안 기준 명문화 | 보안 허점으로 사용자 신뢰 손실 |
⚠️ 법규 위반 실제 사례 (CCPA — 미국 캘리포니아)
개인정보 유출 1건당 최대 7,500달러(약 1,033만 원) 벌금, 소비자에게 103만 원까지 배상.
유저 1만 명이면 벌금이 수백억 원 수준이다. 실제로 법령 위반으로 회사가 문을 닫는 사례도 있다. 정책서는 법적 방패다.
개인정보 유출 1건당 최대 7,500달러(약 1,033만 원) 벌금, 소비자에게 103만 원까지 배상.
유저 1만 명이면 벌금이 수백억 원 수준이다. 실제로 법령 위반으로 회사가 문을 닫는 사례도 있다. 정책서는 법적 방패다.
서비스 정책서 작성 5단계
| 단계 | 핵심 질문 | 예시 |
|---|---|---|
| 1단계 목적 정의 | 왜 이 정책이 필요한가? | 로그인 보안 강화로 계정 탈취 방지 |
| 2단계 범위 설정 | 어디까지 적용되는가? | 계정 관리, 개인정보 보호, 결제 처리 전반 |
| 3단계 항목 작성 | 구체적으로 무엇인가? | 비밀번호 8자 이상, 6개월마다 변경, 최근 5개 재사용 불가 |
| 4단계 공유 | 모든 팀원이 알고 있는가? | 개발·디자인·법무팀 전체 공유 후 확인 |
| 5단계 정기 검토 | 지금도 유효한가? | 서비스 업데이트·법적 요구사항 변경 시 업데이트 |
비밀번호 정책 실무 예시
| 정책 항목 | 기준 | 개발 시 구현 사항 |
|---|---|---|
| 변경 주기 | 6개월마다 필수 변경 | 만료일 계산 로직 구현 |
| 변경 알림 | 만료 30일 전 이메일 발송 | 자동화 배치(cron job) 구현 |
| 재사용 제한 | 최근 5개 비밀번호 재사용 불가 | 비밀번호 히스토리 저장·비교 코드 |
| 복잡성 | 8자 이상, 대/소문자·숫자·특수문자 포함 | 정규식(regex) 유효성 검사 |
💡 핵심 포인트
"정책서에 없는 예외는, 그 예외가 발생할 때마다 팀 전체가 멈춘다."
겸직자, 특수 권한, 엣지 케이스처럼 드물게 발생하는 케이스일수록 반드시 미리 정의해야 한다. 나중에 "이런 경우는 어쩌죠?"가 나오는 순간, 그건 정책서에 빠진 항목이 있다는 신호다.
"정책서에 없는 예외는, 그 예외가 발생할 때마다 팀 전체가 멈춘다."
겸직자, 특수 권한, 엣지 케이스처럼 드물게 발생하는 케이스일수록 반드시 미리 정의해야 한다. 나중에 "이런 경우는 어쩌죠?"가 나오는 순간, 그건 정책서에 빠진 항목이 있다는 신호다.
4. 에러 케이스 — 예외 상황을 미리 정의하는 PM의 역할
에러 케이스는 단순히 "오류 메시지 쓰는 것"이 아니었다. 서비스에서 발생 가능한 모든 예외 상황을 사전에 정의하고 처리 방법을 명문화하는 것이 에러 케이스 문서의 역할이다. PM이 이걸 제대로 정의해두지 않으면 개발자가 "이 상황은 어떻게 하면 될까요?"를 반복해서 물어오게 된다.
에러 케이스 2가지 유형 비교
| 구분 | 서비스 오류 | 시스템 오류 |
|---|---|---|
| 발생 원인 | 사용자 행동에서 발생 | 서버·DB·API 내부 문제 |
| 예시 | 비밀번호 틀림, 필수 입력란 누락, 카드 정보 오류 | 서버 장애, DB 연결 실패, API 응답 오류 |
| 실제 사례 | 로그인 5회 실패 → 계정 잠금 | 카카오 판교 화재 → 전체 서비스 마비 |
| 메시지 방향 | "무엇을 수정하면 되는지" 안내 | "잠시 후 다시 시도" + 개발팀 즉시 대응 |
| 사용자 해결 여부 | 사용자가 스스로 고칠 수 있음 | 사용자가 고칠 수 없음 |
에러 케이스 작성 3단계
| 단계 | 내용 | ❌ 잘못된 예 | ✅ 올바른 예 |
|---|---|---|---|
| 1단계 에러 정의 |
기능마다 예상 가능한 예외 상황을 PM·개발자가 함께 목록화 | 로그인 오류 | 아이디 불일치 / 비밀번호 불일치 / 계정 잠금 / 세션 만료 — 각각 별도 정의 |
| 2단계 조건 명시 ⭐ |
각 에러가 정확히 언제, 어떤 상황에서 발생하는지 구체적으로 | 결제 시 카드 정보 오류 | 유효하지 않은 카드번호 또는 만료된 카드로 결제 시도 시 PAY101 오류 발생 |
| 3단계 메시지 작성 |
사용자가 에러 발생 시 다음에 취할 행동을 구체적으로 안내 | "오류가 발생했습니다" | "비밀번호가 올바르지 않습니다. 다시 입력해주세요." |
에러 메시지 실무 예시
| 기능 | 에러 코드 | 발생 조건 | 사용자 메시지 | 유형 |
|---|---|---|---|---|
| 로그인 | AUTH001 | 비밀번호 불일치 | "비밀번호가 올바르지 않습니다. 다시 입력해주세요." | 서비스 |
| 로그인 | AUTH002 | 5회 연속 실패 | "계정이 잠겼습니다. 이메일을 확인해 잠금 해제해주세요." | 서비스 |
| 결제 | PAY101 | 유효하지 않은 카드번호 | "카드 정보를 다시 확인해주세요." | 서비스 |
| 결제 | PAY102 | 결제 서버 응답 없음 | "결제 서버에 문제가 발생했습니다. 잠시 후 다시 시도해주세요." | 시스템 |
| 전체 | SYS001 | 서버 장애 | "현재 서비스를 이용할 수 없습니다. 잠시 후 다시 시도해주세요." | 시스템 |
💡 핵심 포인트
"에러 메시지는 '무엇이 잘못됐는지'가 아니라 '무엇을 해야 하는지'를 알려줘야 한다."
2단계(발생 조건 명시)가 가장 중요하다. 조건이 구체적이어야 개발자가 테스트 케이스를 만들 수 있고, 에러 코드(PAY102)가 있어야 개발팀이 문제를 즉시 파악할 수 있다.
"에러 메시지는 '무엇이 잘못됐는지'가 아니라 '무엇을 해야 하는지'를 알려줘야 한다."
2단계(발생 조건 명시)가 가장 중요하다. 조건이 구체적이어야 개발자가 테스트 케이스를 만들 수 있고, 에러 코드(PAY102)가 있어야 개발팀이 문제를 즉시 파악할 수 있다.
5. 상세기획 & 기능명세서 — 개발팀이 바로 작업할 수 있는 기준
상세기획과 기능명세서는 이름이 달라도 같은 목적의 문서다. 협업자들이 오해 없이 작업할 수 있도록 각 기능을 상세하게 설명하는 것이 핵심이다. PM이 작성하는 문서는 99% 이상 공유되기 때문에, 기획서를 읽은 사람이 질문 없이 이해할 수 있어야 잘 쓴 문서다.
유저 플로우 (User Flow) — 서비스 복잡할수록 필수
유저 플로우는 사용자가 서비스를 이용할 때의 전체 경로를 시각화한 것이다. 단계별 흐름과 분기점을 미리 정의해야 개발자가 "합격하면 어디로 가요?"를 묻지 않는다.
| 작성 단계 | 내용 | 실무 예시 (서류 심사 프로세스) |
|---|---|---|
| ① 필수 단계 정의 | 전체 흐름에서 빠질 수 없는 단계 목록화 | 진입 → 클릭 → 상세화면 → 의견작성 → 결과등록 |
| ② 시작점 설정 | 사용자가 어디서 시작하는가 | 서류 심사 목록 페이지 진입 |
| ③ 단계별 흐름 | 각 단계에서 사용자가 하는 행동 | 신규 건 클릭 → 서류 심사 화면 진입 → 의견 작성 |
| ④ 분기점 추가 ⭐ | 결과가 2가지 이상으로 나뉘는 지점 명시 | 결과 등록 → 합격(다음 단계 진행) / 불합격(탈락 처리) |
| ⑤ 시각화 | 도식으로 한눈에 볼 수 있게 | 화살표·분기 흐름도로 표현 |
기능명세서 필수 요소
| 요소 | 설명 | 회원가입 기능 예시 |
|---|---|---|
| 기능 이름 | 간결하고 명확하게 | 회원가입 기능 |
| 기능 설명 | 한 줄로 목적 서술 | 신규 사용자가 이메일 또는 SNS로 계정을 만드는 기능 |
| 입력값 | 구체적인 조건까지 | 이메일(유효한 형식), 비밀번호(8자 이상, 대/소문자·숫자·특수문자) |
| 출력값 | 성공·실패 메시지 모두 | 성공: "회원가입 완료" / 실패: "이미 등록된 이메일입니다" |
| 예외 처리 | 에러 케이스와 연결 | 중복 이메일, 비밀번호 형식 불일치, 서버 오류 |
💡 핵심 포인트
"기획서를 읽은 사람이 질문 없이 이해하면 잘 쓴 기획서다."
유저 플로우에서 분기점을 빠뜨리면 개발자가 "합격하면 어디로 가요?"라고 물어오고, 기능명세서에서 출력값을 빠뜨리면 "성공하면 뭘 보여줘요?"가 나온다. 협업자의 질문이 줄어들수록 좋은 기획서다.
"기획서를 읽은 사람이 질문 없이 이해하면 잘 쓴 기획서다."
유저 플로우에서 분기점을 빠뜨리면 개발자가 "합격하면 어디로 가요?"라고 물어오고, 기능명세서에서 출력값을 빠뜨리면 "성공하면 뭘 보여줘요?"가 나온다. 협업자의 질문이 줄어들수록 좋은 기획서다.
6. Why의 중요성 — PM의 사고법
파트 2 중에서 가장 인상 깊었던 챕터다. "그냥"이라는 답은 PM에게 금지어라는 말이 머릿속에 박혔다. Why를 반복해서 물으면 표면적 문제가 아닌 진짜 원인을 찾을 수 있다. 프로젝트 일정이 지연될 때, "팀원 속도가 느리다"가 아니라 "지원이 부족하다"가 진짜 원인일 수 있다.
Why가 중요한 3가지 이유
| 역할 | 설명 | 실무 사례 |
|---|---|---|
| 근본 원인 파악 | 표면이 아닌 진짜 문제를 발견 | 일정 지연 → 속도 느림 → 지원 부족(진짜 원인) |
| 목표 명확화 | Why를 반복할수록 목표가 구체화 | "왜 이 기능?" → 사용자 문제 해결 → 시장 경쟁력 → 비즈니스 성장 |
| 의사결정 기준 | Why 없는 결정 = 근거 없는 결정 | "그냥" 대답 → 신뢰 상실 / Why 제시 → 협업자 설득 가능 |
Why → What → How 프레임워크
| 단계 | 질문 | 설명 | 마켓컬리 후기 개선 사례 |
|---|---|---|---|
| Why | 왜? | 근본 원인 파악, 목표 명확화 | 후기 5건 보려면 10회 이상 클릭 → UX 불편 |
| What | 무엇을? | 구체적 목표와 결과물 정의 | 후기 탐색 클릭 수를 절반으로 줄이기 |
| How | 어떻게? | 세부 실행 계획·로드맵 수립 | 무한 스크롤 도입, 탭 기반 구조 개편 |
💡 핵심 포인트
"기획자와 PM의 업무는 Why로 가득 차 있다."
Why를 의식적으로 습관화하지 않으면, 방향 없이 달리다가 뒤늦게 "이게 맞나?"가 나온다. 화해 어워드 개선 프로젝트처럼 Why → What → How 순서가 명확할수록 기획의 설득력이 강해진다.
"기획자와 PM의 업무는 Why로 가득 차 있다."
Why를 의식적으로 습관화하지 않으면, 방향 없이 달리다가 뒤늦게 "이게 맞나?"가 나온다. 화해 어워드 개선 프로젝트처럼 Why → What → How 순서가 명확할수록 기획의 설득력이 강해진다.
7. 커뮤니케이션 — 전달이 아니라 이해시키는 것
"커뮤니케이션은 내가 말한 것이 아니라 상대방이 이해한 것"이라는 말이 가장 인상적이었다. "하트 만들어주세요"라고 했을 때 상대방이 어떤 하트를 그릴지 모른다는 예시가 웃기면서도 뼈저리게 와 닿았다. 나도 팀 프로젝트에서 "빨리 해주세요"를 아무렇지 않게 쓴 적이 있었다.
좋은 커뮤니케이션 vs 나쁜 커뮤니케이션
| 항목 | ✅ 좋은 커뮤니케이션 | ❌ 나쁜 커뮤니케이션 |
|---|---|---|
| 표현 방식 | 수치·기간·조건을 구체적으로 명시 | 모호하고 뭉뚱그린 표현 ("빨리", "예쁘게") |
| 확인 여부 | 전달 후 상대방 이해 확인 | 전달만 하고 이해 확인 없음 |
| 감정 처리 | 상대방 감정 인정 후 대화 시작 | 감정 무시, "그냥 빨리 결정하시죠" |
| 관점 | 상대방 입장을 먼저 이해하고 타협점 제시 | 자신의 기준에서만 설명 |
| 결과 | 갈등 감소, 신뢰 형성, 효율적 협업 | 목표 불일치, 팀 혼선, 프로젝트 실패 |
실제 요청 비교 — 개발팀에 작업 요청 시
| 상황 | ❌ 나쁜 예 | ✅ 좋은 예 |
|---|---|---|
| 로그인 기능 | "로그인 기능 좀 만들어주세요. 실패하면 잠깐 기다렸다가 하루 안에 끝내주세요." | "이메일/비밀번호 로그인, 실패 시 3초 대기, 2주 후 구현 완료 요청합니다." |
| UI 개선 | "로그인 페이지 좀 보기 좋게 고쳐주세요. 최대한 빨리요." | "이번 주까지 UI 개선: 버튼 크기 2배, 배경 밝게, 입력 필드 강조. 내일까지 결과물 공유 부탁드립니다." |
| 팀 갈등 상황 | "그렇게 고집 부리면 일하기 힘들어요. 그냥 빨리 결정하시죠." | "서로 입장을 얘기하고 존중하면서 타협점을 찾아보자. 초기 버전 먼저 출시하는 건 어때?" |
📌 커뮤니케이션 역량 키우기 — 3가지 방법
① 적극적 경청: 상대방 말을 잘 듣고 질문·피드백으로 더 깊이 이해. 몸짓·표정으로도 경청 의사 표현 (팔짱은 "동의 안 함"의 비언어 신호)
② 핵심 3가지 규칙: 가장 중요한 내용 3가지만 꼽아 전달. 상대방이 더 잘 기억함
③ 이해 확인: 전달 후 "제가 말씀드린 내용이 맞나요?" 한 마디로 오해를 사전 차단
① 적극적 경청: 상대방 말을 잘 듣고 질문·피드백으로 더 깊이 이해. 몸짓·표정으로도 경청 의사 표현 (팔짱은 "동의 안 함"의 비언어 신호)
② 핵심 3가지 규칙: 가장 중요한 내용 3가지만 꼽아 전달. 상대방이 더 잘 기억함
③ 이해 확인: 전달 후 "제가 말씀드린 내용이 맞나요?" 한 마디로 오해를 사전 차단
💡 핵심 포인트
네이버·배민 같은 IT 대기업이 채용 공고에 "원활한 커뮤니케이션"을 필수 요건으로 명시하는 이유를 이제 알겠다. 커뮤니케이션이 안 되면 협업 자체가 불가능하기 때문이다. 당연해 보이지만 실제로는 갈등과 프로젝트 실패의 가장 큰 원인이 된다.
네이버·배민 같은 IT 대기업이 채용 공고에 "원활한 커뮤니케이션"을 필수 요건으로 명시하는 이유를 이제 알겠다. 커뮤니케이션이 안 되면 협업 자체가 불가능하기 때문이다. 당연해 보이지만 실제로는 갈등과 프로젝트 실패의 가장 큰 원인이 된다.
8. 논리적 설득 — 데이터로 납득시키는 것
"맞는 주장도 근거가 없으면 '그냥'과 다르지 않다"는 말이 핵심이었다. "UX를 개선해야 합니다"라고 하면 모두 고개를 끄덕이지만 아무도 움직이지 않는다. "사용자 설문의 63%가 UX 불만을 표시했습니다"라고 하면 회의실 분위기가 달라진다.
논리적 접근 vs 비논리적 접근
| 구분 | 비논리적 접근 ❌ | 논리적 접근 ✅ |
|---|---|---|
| 기반 | 감정·직관·경험만으로 결론 | 데이터·분석·객관적 근거로 결론 도출 |
| 예시 (기능 삭제) | "사용자가 기능을 안 쓰니 없애자" | "클릭률·정성 피드백 분석 → UI 문제 발견 → 개선 방안 제시" |
| 우선순위 판단 | "그냥 다 중요한 것 같은데요" | 비즈니스 영향도·사용자 영향도 기준으로 순위 결정 |
| 결과 | 동료 설득 어려움, 신뢰 손실 | 객관적 근거로 협업자 설득, 신뢰 확보 |
논리적 설득 4단계 흐름 — 주제 → 주장 → 근거 → 결론
| 단계 | 질문 | 실제 예시 (새 기능 추가 제안) |
|---|---|---|
| 주제 | 무엇에 대해 말하는가? | 새로운 기능 추가 필요 |
| 주장 | 나는 어떻게 생각하는가? | 이 기능이 사용자 문제를 해결하고 제품 가치를 높임 |
| 근거 ⭐ | 데이터로 뒷받침할 수 있는가? | 사용자 설문 60% 이상이 이 기능 요청. CS 데이터에서도 동일 패턴 |
| 결론 | 따라서 무엇을 해야 하는가? | 이 기능 개발을 최우선 과제로 진행할 것을 제안 |
우선순위 판단 기준
| 상황 | 선택지 A | 선택지 B | 논리적 판단 |
|---|---|---|---|
| 버그 우선순위 | 버튼 위치 변경 (CS 요청) | 앱이 아예 켜지지 않는 버그 | 🔴 B 먼저 — 서비스 이용 자체 불가. 비즈니스에 직접 영향 |
| 일정 촉박할 때 | "일단 다 끝내자" | 핵심 기능(인증·동기화) 먼저, 나머지 다음 릴리즈 | 🟢 B 선택 — 핵심 기능이 UX에 더 큰 영향 |
| 신기능 vs 개선 | "새 기능이 마케팅에 유리하다" | 고객 만족도 조사·불만 유형 데이터 제시 | 🟢 데이터 기반 판단 — 주관적 주장이 아닌 근거로 설득 |
💡 핵심 포인트
데이터가 없다면 정성적 근거(사용자 인터뷰, CS 피드백, 유사 서비스 사례)를 쓰면 된다. 중요한 건 "가설이라도 명시"하는 것. "가설이지만 유사 서비스 사례에서 확인했습니다"가 "그냥 좋을 것 같아서요"보다 훨씬 낫다.
데이터가 없다면 정성적 근거(사용자 인터뷰, CS 피드백, 유사 서비스 사례)를 쓰면 된다. 중요한 건 "가설이라도 명시"하는 것. "가설이지만 유사 서비스 사례에서 확인했습니다"가 "그냥 좋을 것 같아서요"보다 훨씬 낫다.
9. 기록과 공유 — PM이 반드시 가져야 할 습관
"기록하지 않은 결정은 결정하지 않은 것과 같다"는 말이 오늘 배운 것 중 가장 실용적인 인사이트였다. 구두로 합의한 내용이 3개월 후 "그런 얘기 한 적 없는데요?"로 번지는 상황은 팀 프로젝트에서도 이미 경험한 적이 있어서 더 와 닿았다.
기록이 만들어내는 4가지 효과
| 효과 | 설명 | 기록 없으면 생기는 문제 |
|---|---|---|
| 효율적 의사결정 | 의사결정 과정과 근거가 남아 방향 수정 시 유용 | "왜 이렇게 했지?" 논쟁 반복 |
| 커뮤니케이션 품질 | 문서화된 내용이 공유 기준이 되어 오해 방지 | "회의에서 얘기했잖아요" 분쟁 발생 |
| 일정 관리·모니터링 | 진행 상황 기록 → 이슈 조기 발견 | 담당자 교체 시 히스토리 사라짐 |
| 지속적 개선 | 실수와 해결 과정이 쌓여 레슨런 축적 | 같은 실수를 반복 |
공유 문화가 팀에 미치는 효과
| 공유 유형 | 효과 | 실무 사례 |
|---|---|---|
| 기술 문제 공유 | 집단지성으로 빠른 해결 | 화해 프론트엔드 팀 — 기술 이슈 발생 시 팀 전체 논의로 해결 |
| 성장 경험 공유 | 팀 전체 성장 가속화 | 공부한 내용, 트러블슈팅, 성장 경험을 적극 공유 |
| 의사결정 공유 | 리스크 관리, 의사결정 효율화 | 담당자 교체 후에도 히스토리 유지 |
| 온보딩 문서화 | 신규 합류자 빠른 적응 | 화해 'B.Flying' — 6개 세션으로 문화·업무 빠르게 정렬 |
| 투명한 정보 공유 | 신뢰와 자율 문화 형성 | 버드뷰 격주 타운홀 미팅 — 전사 정보 투명하게 공유 |
💡 핵심 포인트
"공유는 내가 아는 것을 팀의 자산으로 바꾸는 행위다."
화해팀 사례처럼 기록이 없으면 정책과 실제 구현 사이에 차이가 생기고, 그걸 수습하는 데 더 많은 비용이 든다. 1인 회사가 아닌 이상 기록과 공유는 선택이 아니라 필수다.
"공유는 내가 아는 것을 팀의 자산으로 바꾸는 행위다."
화해팀 사례처럼 기록이 없으면 정책과 실제 구현 사이에 차이가 생기고, 그걸 수습하는 데 더 많은 비용이 든다. 1인 회사가 아닌 이상 기록과 공유는 선택이 아니라 필수다.
10. 오늘 배운 것 전체 요약
| 주제 | 핵심 한 줄 요약 |
|---|---|
| PRD | 수치·기간·조건 없는 요구사항은 요구사항이 아니다 |
| IA | 1 Depth에 무엇을 두느냐가 그 서비스의 철학이다 |
| 서비스 정책서 | 예외 케이스까지 정의해야 진짜 정책서다 |
| 에러 케이스 | 에러 메시지는 사용자의 다음 행동을 안내해야 한다 |
| 기능명세서 | 질문 없이 이해하면 잘 쓴 기획서다 |
| Why | PM의 업무에서 '그냥'은 답이 아니다 |
| 커뮤니케이션 | 내가 말한 것이 아니라 상대가 이해한 것이 전달이다 |
| 논리적 설득 | 맞는 주장도 근거가 없으면 '그냥'과 다르지 않다 |
| 기록·공유 | 기록하지 않은 결정은 결정하지 않은 것과 같다 |
오늘 배운 것 한 줄 정리
PM은 "기준을 만드는 사람"이다. 문서든, 커뮤니케이션이든, 설득이든 — 모두 협업자가 헤매지 않도록 명확한 기준을 잡아주는 것에서 시작한다. 그 기준의 출발점은 언제나 Why다.