로드맵 우선순위가 충돌할 때 /product-manager가 작업을 점수화하고 순서를 정해 중요한 일을 먼저 출시하게 합니다. — Claude Skill

---

title: 섹션 구성

1. 로드맵 전략

영향도: 매우 높음 설명: 모든 수준의 로드맵을 만들고, 유지하고, 커뮤니케이션하는 방법입니다. 팀과 이해관계자를 정렬하는 제품 계획의 기반입니다.

2. 우선순위 프레임워크

영향도: 매우 높음 설명: 다음에 무엇을 만들지 데이터 기반으로 결정하기 위한 RICE, ICE, MoSCoW 및 기타 프레임워크입니다.

3. 이해관계자 관리

영향도: 높음 설명: 경영진, 엔지니어링, 영업, 고객 전반에서 기대치를 관리하고 효과적으로 소통하며 정렬을 만드는 방법입니다.

4. 스프린트 및 백로그

영향도: 높음 설명: 팀의 생산성을 유지하는 스프린트 계획, 백로그 정리, 추정, 애자일 의식입니다.

5. 기능 범위 설정

영향도: 높음 설명: 최소 기능 제품(MVP) 정의, 트레이드오프 결정, 명세 작성, 범위 증가 관리입니다.

6. 릴리스 계획

영향도: 중상 설명: 릴리스를 조율하고 의존성을 관리하며 일정을 커뮤니케이션하는 방법입니다.

7. 지표 및 OKR

영향도: 매우 높음 설명: 성공 지표를 정의하고 OKR을 설정하며 산출보다 결과를 측정하는 방법입니다.

8. 기술 부채

영향도: 중상 설명: 기능 작업과 기술 건전성의 균형, 부채 축소 우선순위, 가치 커뮤니케이션입니다.

---

title: 교차 기능 협업 impact: HIGH tags: collaboration, teamwork, design, engineering, communication

교차 기능 협업

영향도: 높음

제품 관리자(PM)가 제품을 만드는 것이 아닙니다. 팀이 제품을 만듭니다. 당신의 일은 팀이 함께 최선의 일을 할 수 있는 조건을 만드는 것입니다.

제품 트리오 모델

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│                      ┌─────────────┐                            │
│                      │    제품     │                            │
│                      │   관리자    │                            │
│                      └──────┬──────┘                            │
│                             │                                   │
│              발견 ─────────┼──────── 전달                       │
│                             │                                   │
│             ┌───────────────┴───────────────┐                   │
│             │                               │                   │
│      ┌──────┴──────┐                 ┌──────┴──────┐            │
│      │    제품     │                 │ 엔지니어링  │            │
│      │   디자이너  │◄───────────────▶│    리드     │            │
│      └─────────────┘                 └─────────────┘            │
│                                                                 │
│                     문제와 해결책에 대한                        │
│                        공동 소유                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

일반 활동의 RACI

범례: R=실행 책임, A=최종 책임, C=협의, I=공유 대상

엔지니어링과 일하기

엔지니어가 PM에게 필요한 것:

PM이 엔지니어에게 필요한 것:

디자인과 일하기

디자이너가 PM에게 필요한 것:

PM이 디자이너에게 필요한 것:

제품 트리오 의식

건강한 팀 동학 vs 건강하지 않은 팀 동학

갈등을 생산적으로 관리하기

갈등 해결 프레임워크:

1. 인정
   "이 사안에 대해 서로 다른 관점이 있다는 것을 봅니다."

2. 이해
   "당신의 관점을 더 잘 이해하도록 도와주세요."

3. 공통 기반 찾기
   "우리는 둘 다 [공유 목표]를 원합니다. 거기서 시작합시다."

4. 옵션 만들기
   "이 문제에 접근할 수 있는 모든 방법은 무엇일까요?"

5. 함께 결정
   "우리 제약을 고려하면 저는 ...을 제안합니다. 어떻게 생각하세요?"

6. 약속
   "결정이 내려지면 모두 함께 지지합시다."

교차 기능 회의 템플릿

발견 킥오프:

## 발견 킥오프: [문제 영역]

### 참석자
제품 트리오 + [관련 이해관계자]

### 안건

1. 문제 프레이밍(10분)
   - 어떤 문제를 해결하나요?
   - 누가 이 문제를 갖고 있나요?
   - 왜 지금 중요한가요?

2. 알고 있는 것(15분)
   - 기존 조사
   - 정량 데이터
   - 경쟁 환경

3. 모르는 것(10분)
   - 열린 질문
   - 검증할 가정

4. 발견 계획(20분)
   - 조사 활동
   - 일정
   - 소유자

5. 성공 기준(5분)
   - 만들 준비가 되었다는 것을 어떻게 알 수 있나요?

디자인 리뷰:

## 디자인 리뷰: [기능]

### 참석자
제품 트리오

### 안건

1. 맥락 복기(5분)
   - 해결하는 문제
   - 제약 재확인

2. 디자인 워크스루(20분)
   - 솔루션 설명
   - 근거 설명
   - 검토한 대안 제시

3. 피드백(20분)
   - 명확화를 위한 질문
   - 건설적 비평
   - 엔지니어링 실현 가능성 확인

4. 다음 단계(5분)
   - 변경할 사항
   - 다음 리뷰 일정

회사 단계별 협업 패턴

안티패턴

• 티켓 던지기 — PM이 명세를 써서 벽 너머로 던짐
• 디자인 독재자 — PM이 UX 결정을 내림
• 기술 마이크로매니저 — PM이 구현을 지정
• 부재한 PM — 질문에 항상 부재
• 회의 증식자 — 모든 것에 회의가 필요
• 정보 독점자 — 맥락이 PM에게만 머묾
• 책임 전가자 — 실패했을 때 손가락질
• 프로세스 광신자 — 결과보다 프로세스 우선

---

title: 시장 진출 조율 impact: MEDIUM-HIGH tags: gtm, launch, marketing, sales, coordination

시장 진출 조율

영향도: 중상

훌륭한 제품도 훌륭한 시장 진출(GTM) 없이는 실패합니다. 제품 관리자(PM)는 제품 개발과 기능이 고객에게 도달하는 방식을 연결해야 합니다.

GTM에서 PM의 역할

┌─────────────────────────────────────────────────────────────────┐
│                    PM의 GTM 책임                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   제품 측면                         GTM 측면                    │
│   ────────                         ────────                    │
│   • 무엇을 만드는가                • 사용자에게 왜 중요한가     │
│   • 언제 출시되는가                • 어떻게 포지셔닝할 것인가   │
│   • 기술적 역량                    • 대상 세그먼트              │
│   • 알려진 제한                    • 성공 지표                  │
│                                                                 │
│                      PM이 양쪽을 연결                           │
│                      (번역하고 정렬)                            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

출시 구간별 GTM 계획

구간별 GTM 출시 체크리스트

1구간 - 주요 출시:

## 1구간 GTM 체크리스트: [기능 이름]

### 포지셔닝(PM + 마케팅)
- [ ] 가치 제안 정의
- [ ] 대상 세그먼트 식별
- [ ] 경쟁 차별화 명확화
- [ ] 메시지 계층 승인

### 마케팅 활동
- [ ] 출시 블로그 글
- [ ] 이메일 공지(세그먼트별)
- [ ] 소셜 미디어 캠페인
- [ ] 언론/애널리스트 연락
- [ ] 영상/데모 콘텐츠
- [ ] 유료 프로모션(해당 시)

### 영업 지원
- [ ] 영업 자료 업데이트
- [ ] 데모 스크립트 작성
- [ ] 경쟁 배틀카드
- [ ] FAQ 문서
- [ ] 교육 세션 완료
- [ ] 가격/패키징 확인

### 고객 성공
- [ ] 기존 고객 커뮤니케이션
- [ ] 온보딩 자료 업데이트
- [ ] 성공 지표 정의
- [ ] 에스컬레이션 경로 준비

### 제품
- [ ] 도움말 문서
- [ ] 앱 내 공지
- [ ] 기능 플래그 설정
- [ ] 분석 추적 활성화

### 일정
| 마일스톤 | 날짜 | 소유자 |
|-----------|------|-------|
| 메시지 승인 | T-3주 | 마케팅 |
| 영업 교육 | T-2주 | PM + 영업 |
| 콘텐츠 준비 | T-1주 | 마케팅 |
| 출시 | T | 전체 |

2/3구간 - 표준 출시:

## 2/3구간 GTM 체크리스트: [기능 이름]

### 필수
- [ ] 변경 로그 항목
- [ ] 도움말 문서 업데이트
- [ ] 앱 내 알림(해당 시)
- [ ] 지원팀 공유

### 선택(2구간만)
- [ ] 블로그 글
- [ ] 관련 세그먼트 이메일
- [ ] 영업 지원 요약

출시 브리프 템플릿

## 출시 브리프: [기능 이름]

### 개요
| 필드 | 세부 정보 |
|-------|--------|
| 출시일 | [날짜] |
| 출시 구간 | [1/2/3/4] |
| PM 소유자 | [이름] |
| 마케팅 소유자 | [이름] |

### 출시하는 것
[기능을 설명하는 2-3문장]

### 중요한 이유
**사용자에게:** [해결하는 문제, 전달 가치]
**비즈니스에:** [매출, 유지, 확장 영향]

### 대상 고객
**1차:** [세그먼트, 페르소나]
**2차:** [세그먼트, 페르소나]

### 핵심 메시지
1. [주 메시지/제목]
2. [보조 포인트 1]
3. [보조 포인트 2]

### 경쟁 맥락
[경쟁사 대비 우리를 어떻게 포지셔닝하는가]

### 제한 / 이것이 아닌 것
- [알려진 제한 1]
- [알려진 제한 2]
- [아직 출시하지 않는 것]

### 성공 지표
| 지표 | 목표 | 기간 |
|--------|--------|-----------|
| [지표 1] | [목표] | 30일 |
| [지표 2] | [목표] | 90일 |

### 리소스
- 제품 명세: [링크]
- 디자인 파일: [링크]
- 데모 녹화: [링크]
- 도움말 문서: [링크]

마케팅과 조율

일정 정렬:

제품 개발                         마케팅 준비
─────────────────────        ──────────────

기능 정의 ───────────────────► 메시지 작업 시작

개발 시작 ───────────────────► 콘텐츠 계획

베타 출시 ───────────────────► 초안 작성, 피드백 수집

코드 완료 ───────────────────► 콘텐츠 확정, 캠페인 준비

출시 ───────────────────────► 출시 캠페인

영업과 조율

영업 지원 세션 안건:

## 영업 지원: [기능 이름]

### 안건(45분)

1. 개요(10분)
   - 무엇을 만들었는가
   - 왜 중요한가
   - 누구를 위한 것인가

2. 데모(15분)
   - 실시간 워크스루
   - 핵심 워크플로
   - 놀라운 순간

3. 판매 가이드(10분)
   - 이상적 고객 프로필(ICP)
   - 발견 질문
   - 경쟁 포지셔닝
   - 가격 및 패키징

4. Q&A(10분)
   - 열린 질문
   - 이의 처리
   - 엣지 케이스

고객 커뮤니케이션 계층

출시 지연 처리

## 출시 지연 커뮤니케이션

### 내부(이해관계자 대상)

제목: [기능] 출시가 [새 날짜]로 이동합니다

**변경 내용:** [간단한 설명]

**영향:**
- 마케팅: [캠페인 날짜 조정]
- 영업: [고객 기대치 업데이트]
- 지원: [교육 일정 이동]

**새 일정:** [날짜]

**필요한 것:** [결정 또는 행동]

---

### 외부(고객에게 약속한 경우)

제목: [기능] 업데이트

[기능]이 [기존 날짜]가 아니라 [새 날짜]에 출시될 예정임을
알려드립니다.

이 결정은 [고객에게 이로운 간단한 이유] 때문에 내렸습니다.

그동안 할 수 있는 일은 다음과 같습니다: [우회 방법 또는 임시 해결책]

기다려 주셔서 감사합니다. 곧 전달드릴 수 있기를 기대합니다.

출시 후 GTM 활동

안티패턴

• 출시 후 방치 — GTM 계획 없이 출시
• 마케팅 깜짝 통보 — "어, 내일 출시한다고요?"
• 과도한 약속 — 마케팅이 역량을 넘어서는 주장
• 소통 부족 — 내부 팀이 고객에게서 먼저 알게 됨
• 일괄 적용 — 모든 기능에 같은 GTM 적용
• PM이 마케터 역할까지 함 — 모든 문구를 직접 작성
• 영업팀 배제 — 고객이 영업팀보다 먼저 알게 됨
• 피드백 루프 없음 — GTM 효과를 측정하지 않음

---

title: 제품 지표와 OKR impact: CRITICAL tags: metrics, okrs, kpis, measurement, outcomes

제품 지표와 OKR

영향도: 매우 높음

무엇을 측정하느냐가 무엇을 만들지를 정의합니다. 훌륭한 제품 관리자(PM)는 산출물이 아니라 결과에 집착합니다.

지표 계층

┌─────────────────────────────────────────────────────────────────┐
│                    북극성 지표                                  │
│              (가치를 포착하는 하나의 지표)                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│    │   입력       │  │   입력       │  │   입력       │        │
│    │   지표 1     │  │   지표 2     │  │   지표 3     │        │
│    └──────────────┘  └──────────────┘  └──────────────┘        │
│                                                                 │
│    ┌──────────────┐  ┌──────────────┐  ┌──────────────┐        │
│    │   가드레일   │  │   가드레일   │  │   가드레일   │        │
│    │   지표 1     │  │   지표 2     │  │   지표 3     │        │
│    └──────────────┘  └──────────────┘  └──────────────┘        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

북극성 지표 예시

입력 vs 산출 vs 결과 지표

항상 산출이 아니라 결과를 최적화하세요.

AARRR 해적 지표 프레임워크

좋은 OKR 예시

## 2024년 1분기 OKR - 제품 팀

### 목표 1: 신규 사용자 활성화를 크게 개선
**왜:** 사용자의 60%가 핵심 가치를 경험하지 못함. 가장 큰 성장 레버

**핵심 결과:**
- KR1: 활성화율을 23%에서 35%로 높임
  - 측정: 가입 후 7일 이내 첫 워크플로를 완료한 사용자
  - 현재: 23% | 목표: 35%

- KR2: 첫 가치 도달 시간을 3일에서 1일로 단축
  - 측정: 첫 성공 워크플로까지 걸린 중앙값 시간
  - 현재: 72시간 | 목표: 24시간

- KR3: 첫 30일 사용자 NPS 50+ 달성
  - 측정: 30일 차 NPS 설문
  - 현재: 32 | 목표: 50

**이니셔티브:**
- 온보딩 흐름 재설계
- 템플릿 라이브러리 확장
- 앱 내 안내 시스템

**가드레일:**
- 지원 티켓 양: 증가율 5% 미만 유지
- 인프라 비용: 10% 초과 증가 없음

나쁜 OKR 예시

## 1분기 OKR

### 목표 1: 새 기능 출시
**핵심 결과:**
- 다크 모드 출시
- 모바일 앱 출시
- 통합 10개 추가
- 대시보드 재설계

### 목표 2: 고객을 행복하게 만들기
**핵심 결과:**
- 더 많은 피드백 받기
- 버그 수정
- 성능 개선

실패 이유:

• 결과가 아니라 산출 중심
• 측정 가능한 목표 없음
• 기준선이나 현재 상태 없음
• 비즈니스 가치와 연결 없음
• 가드레일 없음

OKR 작성 지침

좋은 목표:

• 정성적이고 영감을 줌
• 시간 제한 있음(분기)
• 야심차지만 달성 가능
• 팀과 정렬

좋은 핵심 결과:

• 정량적이고 측정 가능
• 결과 중심(산출 아님)
• 목표당 3-5개
• 기준선과 목표 포함
• 도전적이지만 가능(70% 확신)

지표 정의 템플릿

## 지표: 활성화율

### 정의
가입 후 7일 이내 첫 성공 워크플로를 완료한 신규 가입자의 비율.

### 공식
(첫 7일 내 워크플로를 완료한 사용자 / 전체 신규 가입자) × 100

### 데이터 출처
- 분자: events.workflow_completed WHERE days_since_signup <= 7
- 분모: 해당 기간의 users.created_at

### 세분화
- 가입 출처별(오가닉, 유료, 추천)
- 플랜 유형별(무료, 체험, 유료)
- 회사 규모별(중소기업, 중견 시장, 엔터프라이즈)

### 주기
- 보고: 주간
- 검토: 월간

### 소유자
제품 관리자 - 성장

### 목표
| 기간 | 목표 | 도전 목표 |
|--------|--------|---------|
| 2024년 1분기 | 35% | 40% |
| 2024년 2분기 | 42% | 48% |

### 관련 지표
- 첫 가치 도달 시간(선행)
- 30일 유지율(후행)
- 온보딩 완료(입력)

지표 검토 회의 안건

## 주간 지표 검토 - [날짜]

### 참석자
제품, 엔지니어링 리드, 데이터

### 안건

#### 1. 북극성 확인(5분)
- 현재: [값]
- 추세: [상승/하락/보합]
- 목표 대비: [앞섬/뒤처짐/정상 궤도]

#### 2. 핵심 결과 진행(15분)
| KR | 현재 | 목표 | 상태 |
|----|---------|--------|--------|
| 활성화율 | 28% | 35% | 정상 궤도 |
| 가치 도달 시간 | 2일 | 1일 | 위험 |
| NPS(신규 사용자) | 41 | 50 | 정상 궤도 |

#### 3. 가드레일 확인(5분)
| 가드레일 | 상태 | 메모 |
|-----------|--------|-------|
| 지원 양 | 초록 | +2% |
| 오류율 | 초록 | 0.1% |
| 인프라 비용 | 노랑 | +8% |

#### 4. 실험 결과(10분)
- [실험 A]: 활성화 +3%, 출시
- [실험 B]: 유의미한 변화 없음, 출시하지 않음

#### 5. 인사이트 및 행동(10분)
- 핵심 인사이트: [발견]
- 행동: [이에 대해 할 일]

### 내려진 결정
- [결정 1]
- [결정 2]

### 다음 주 집중
- [우선순위 1]
- [우선순위 2]

흔한 지표 함정

안티패턴

• 기능 개수 세기 — 출시한 것이 아니라 영향을 측정해야 함
• 지표 극장 — 아무도 쓰지 않는 아름다운 대시보드
• 연간 OKR — 학습하고 적응하기에 너무 김
• 낮춰 잡기 — OKR을 "달성"하려고 쉬운 목표 설정
• 설정 후 방치 — 정기적으로 검토하지 않음
• 너무 많은 KR — 목표당 핵심 결과 10개
• 책임 없음 — 소유자 없는 OKR
• 입력 KR — "기능 5개 출시"를 핵심 결과로 삼음

---

title: 우선순위 프레임워크 impact: CRITICAL tags: prioritization, rice, ice, moscow, decision-making

우선순위 프레임워크

영향도: 매우 높음

우선순위 결정은 제품 관리자(PM)의 가장 중요한 일입니다. 프레임워크를 사용해 결정을 투명하고 방어 가능하며 일관되게 만드세요.

프레임워크 선택 가이드

RICE 프레임워크(상세)

RICE 점수 = (도달 범위 × 영향도 × 확신도) / 노력

RICE 계산 예시:

승자: 온보딩 재설계(가장 높은 RICE 점수)

ICE 프레임워크(빠른 점수화)

ICE 점수 = 영향도 × 확신도 × 쉬움

모든 요소는 1-10점:

• 영향도: 이것이 얼마나 큰 변화를 만들까?
• 확신도: 영향과 노력에 대해 얼마나 확실한가?
• 쉬움: 구현이 얼마나 쉬운가?

ICE 예시:

릴리스 범위 설정을 위한 MoSCoW

좋은 MoSCoW 예시:

## v2.3 릴리스 범위

### 반드시 필요(출시하거나 릴리스하지 않음)
- [ ] 치명적 결제 버그 수정(#1234)
- [ ] GDPR 삭제 엔드포인트 준수
- [ ] 대시보드 로딩 성능 수정

### 있어야 함(계획에 포함)
- [ ] 개선된 오류 메시지
- [ ] 대량 내보내기 기능
- [ ] 이메일 알림 환경설정

### 있으면 좋음(도전 목표)
- [ ] 다크 모드 토글
- [ ] 키보드 단축키
- [ ] 위젯 재설계

### 이번에는 없음(명시적으로 연기)
- 모바일 앱 개선(v2.4)
- API v2(3분기 이니셔티브)
- 다국어 지원(2025)

가치 vs 노력 매트릭스

                    높은 가치
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   전략 과제   │   빠른 성과   │
         │   (계획)      │   (먼저 실행) │
         │               │               │
높은     │               │               │   낮은
노력 ───┼───────────────┼───────────────┼─── 노력
         │               │               │
         │   돈 먹는 구덩이│  빈틈 채우기 │
         │   (피함)      │   (시간 있으면)│
         │               │               │
         └───────────────┼───────────────┘
                         │
                    낮은 가치

사분면 행동:

• 빠른 성과: 즉시 실행, 낮은 노력 + 높은 가치
• 전략 과제: 신중히 계획, 투자할 가치 있음
• 빈틈 채우기: 신규 팀원이나 여유 시간에 적합
• 돈 먹는 구덩이: 명시적으로 거절

Kano 모델

범주별 예시:

• 기본: 앱이 충돌하지 않음, 데이터가 저장됨
• 성과: 더 빠른 로딩, 더 많은 저장 공간
• 감동 요소: AI 제안, 선제적 인사이트

우선순위 회의 템플릿

## 우선순위 검토 - [날짜]

### 입력
- 현재 백로그: [X개 항목]
- 엔지니어링 수용량: [Y 스토리 포인트]
- 전략 목표: [2-3개 목록]

### 점수 결과
| 순위 | 항목 | RICE 점수 | 소유자 메모 |
|------|------|------------|-------------|
| 1 | 기능 A | 5,333 | 활성화 목표와 정렬 |
| 2 | 기능 B | 2,500 | 고객 요청량 |
| 3 | 기능 C | 600 | 전략적 베팅 |

### 결정
- 우선순위 지정: [진행 항목]
- 우선순위 하향: [연기 항목]
- 조사 필요: [발견 작업이 필요한 항목]

### 다음 단계
- [ ] 로드맵 업데이트
- [ ] 이해관계자에게 커뮤니케이션
- [ ] 상위 항목 명세 작업 시작

안티패턴

• HiPPO — 최고 연봉자의 의견이 데이터를 덮어씀
• 시끄러운 바퀴 — 가장 목소리 큰 이해관계자가 이김
• FIFO — 먼저 들어온 요청을 먼저 만듦
• 프레임워크 숭배 — 판단 없이 점수만 맹목적으로 따름
• 프레임워크 없음 — 투명성 없이 순수 직감에 의존
• 점수 조작 — 이미 내린 결정을 정당화하려 숫자 부풀리기
• 분석 마비 — 모든 것을 점수화하고 아무것도 결정하지 않음

---

title: 릴리스 계획 및 조율 impact: MEDIUM-HIGH tags: release, launch, coordination, communication

릴리스 계획 및 조율

영향도: 중상

훌륭한 릴리스에는 팀 간 오케스트레이션이 필요합니다. 기능을 계획하는 것만큼 신중하게 릴리스를 계획하세요.

릴리스 유형

릴리스 계획 일정

┌─────────────────────────────────────────────────────────────────┐
│                    주요 릴리스 일정                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  T-4주           T-2주           T-1주           출시           │
│  ───────         ───────         ───────         ─────          │
│  • 기능 완료     • 코드 동결      • 최종 QA       • 배포         │
│                  • 베타 테스트    • 출시 준비     • 공지         │
│  • 내부 테스트   • 문서 준비      • 커뮤니케이션  • 모니터링     │
│                  • 교육           • 롤백 준비     • 지원         │
│  • 이해관계자    • 마케팅 준비    • 온콜 준비     • 축하         │
│    미리보기                                                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

릴리스 체크리스트 템플릿

## 릴리스 체크리스트: [기능 이름] v[X.Y]

### 목표 날짜: [날짜]
### 릴리스 소유자: [PM 이름]
### 엔지니어링 리드: [이름]

---

### 개발 전
- [ ] 요구사항 문서화 및 승인
- [ ] 성공 지표 정의
- [ ] 의존성 식별
- [ ] 이해관계자에게 일정 공유

### 개발 완료(T-2주)
- [ ] 모든 코드가 릴리스 브랜치에 병합됨
- [ ] 단위 테스트 통과(커버리지 >90%)
- [ ] 통합 테스트 통과
- [ ] 성능 기준 충족
- [ ] 보안 검토 완료
- [ ] 접근성 감사 통과

### 문서(T-2주)
- [ ] 도움말 문서 업데이트
- [ ] API 문서 업데이트
- [ ] 변경 로그 초안
- [ ] 릴리스 노트 초안
- [ ] 내부 FAQ 준비

### 마케팅/커뮤니케이션(T-1주)
- [ ] 블로그 글 초안
- [ ] 이메일 공지 초안
- [ ] 소셜 미디어 게시 예약
- [ ] 앱 내 공지 설정
- [ ] 언론/애널리스트 브리핑 예약(해당 시)

### 영업 지원(T-1주)
- [ ] 영업 자료 업데이트
- [ ] 데모 스크립트 준비
- [ ] 교육 세션 완료
- [ ] 경쟁 포지셔닝 업데이트

### 지원 준비(T-1주)
- [ ] 지원팀 교육 완료
- [ ] 알려진 이슈 문서화
- [ ] 에스컬레이션 경로 정의
- [ ] 일반 질문 FAQ

### 출시일
- [ ] 배포 성공
- [ ] 스모크 테스트 통과
- [ ] 모니터링 대시보드 검토
- [ ] 공지 게시
- [ ] 이슈 대응을 위해 팀 대기

### 출시 후(T+1주)
- [ ] 목표 대비 지표 검토
- [ ] 사용자 피드백 수집
- [ ] 버그 분류 및 우선순위 지정
- [ ] 회고 일정 잡기
- [ ] 필요한 경우 빠른 수정 배포

교차 기능 출시 조율

릴리스 커뮤니케이션 템플릿

내부 공지:

## [기능 이름] 오늘 출시

### 새로운 내용
기능의 간단한 설명과 중요한 이유.

### 영향을 받는 대상
- 사용자: [영향받는 세그먼트]
- 팀: [영향받는 내부 팀]

### 핵심 세부 사항
- 사용 가능: [날짜/시간, 지역]
- 문서: [링크]
- 알려진 이슈: [링크 또는 "없음"]

### 해야 할 일
- **영업:** 업데이트된 자료 검토 [링크]
- **지원:** 교육 완료 [링크]
- **고객 성공:** [세그먼트]에 커뮤니케이션 준비

### 질문이 있나요?
#[채널]에서 [PM 이름]에게 연락하세요

외부 공지:

## [기능 이름] 소개

[기능]을 발표합니다 — [한 줄 가치 제안].

### 새로운 내용
[핵심 역량 2-3개 bullet]

### 만든 이유
[해결하는 고객 문제에 대한 1문단]

### 시작 방법
[명확한 안내 또는 링크]

### 더 알아보기
- 문서: [링크]
- 영상 워크스루: [링크]
- 웨비나 신청: [링크]

### 다음 계획
[다가오는 개선 살짝 예고]

기능 플래그 롤아웃 전략

## 롤아웃 계획: 기능 X

### 1단계: 카나리(1%)
- 대상: 내부 직원만
- 기간: 2일
- 종료 기준: P0/P1 버그 없음, 오류율 <1%

### 2단계: 베타(10%)
- 대상: 파워 유저(주 10회 초과 세션)
- 기간: 5일
- 종료 기준: NPS > 30, 주요 UX 이슈 없음

### 3단계: GA 소프트(50%)
- 대상: 모든 유료 사용자
- 기간: 1주
- 종료 기준: 도입률 > 20%, 지원 급증 없음

### 4단계: GA 전체(100%)
- 대상: 모든 사용자
- 종료 기준: 지표가 목표 충족

### 롤백 트리거
- 사용자 1% 초과에 영향을 주는 P0 버그
- 오류율 >5%
- NPS 20점 초과 하락
- 지원 티켓 기준선 대비 3배

출시 위험 관리

출시 후 검토 템플릿

## 출시 후 검토: [기능 이름]

### 출시 요약
- **출시일:** [날짜]
- **대상 고객:** [세그먼트]
- **성공 지표 목표:** [지표 + 목표]

### 결과(T+2주)
| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|
| 도입률 | 25% | 31% | 초과 달성 |
| NPS | +10 | +8 | 근접 |
| 지원 티켓 | <100 | 87 | 충족 |

### 잘된 점
- 단계적 롤아웃으로 버그를 일찍 발견
- 영업 지원이 효과적이었음
- 문서가 포괄적이었음

### 개선할 점
- 마케팅 일정이 촉박했음
- QA에서 엣지 케이스 누락
- 이해관계자 커뮤니케이션을 더 일찍 할 수 있었음

### 실행 항목
- [ ] 베타에서 발견된 버그 수정(소유자: 엔지니어링)
- [ ] 다음에는 마케팅을 더 일찍 시작(소유자: PM)
- [ ] QA 체크리스트에 엣지 케이스 추가(소유자: QA)

### 다음 단계
- 피드백을 반영한 v1.1 계획
- 전체 팀 회고 일정 확정

안티패턴

• 빅뱅 릴리스 — 롤아웃 계획 없이 한 번에 모두 출시
• 깜짝 출시 — 이해관계자와 조율하지 않음
• 롤백 계획 없음 — 탈출구 없이 출시
• 문서 후순위 — 출시 후에 문서 작성
• 출시 후 무시 — 출시하고 즉시 다음으로 이동
• 출시 과잉 설계 — 작은 기능에 대규모 캠페인
• 소통 부족 — 팀이 고객에게서 출시를 알게 됨

---

title: 로드맵 생성 및 유지관리 impact: CRITICAL tags: roadmap, strategy, planning, alignment

로드맵 생성 및 유지관리

영향도: 매우 높음

로드맵은 약속이 아니라 커뮤니케이션 도구입니다. 학습을 위한 유연성을 유지하면서 전략 방향을 중심으로 이해관계자를 정렬합니다.

대상별 로드맵 유형

지금-다음-나중 프레임워크

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│   지금             다음             나중                         │
│   (약속됨)         (계획됨)         (탐색 중)                    │
│                                                                 │
│   ┌──────────┐     ┌──────────┐     ┌──────────┐               │
│   │ 기능 A   │     │ 기능 D   │     │ 기능 G   │               │
│   │ 기능 B   │     │ 기능 E   │     │ 기능 H   │               │
│   │ 기능 C   │     │ 기능 F   │     │ 주제 X   │               │
│   └──────────┘     └──────────┘     └──────────┘               │
│                                                                 │
│   높은 확실성       중간 확실성      낮은 확실성                 │
│   상세 명세         일반 범위        문제 수준                   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

좋은 로드맵: 결과 기반

## 2024년 1분기 로드맵

### 목표: 활성화율을 23%에서 35%로 높이기

**지금(1월)**
- 온보딩 흐름 재설계(3단계에서 40% 이탈 해결)
- 첫 워크플로 생성을 위한 앱 내 안내
- 1-7일차 이메일 시퀀스 최적화

**다음(2-3월)**
- 템플릿 라이브러리 확장(이탈 사용자 최상위 요청)
- 모바일 앱 MVP(가입자의 30%가 모바일 우선)
- 요청 상위 3개 도구와 통합

**나중(2분기 검토)**
- AI 기반 설정 도우미
- 팀 온보딩 흐름
- 고급 개인화

### 성공 지표
- 1차: 활성화율(23% → 35%)
- 2차: 첫 가치 도달 시간(3일 → 1일)
- 가드레일: 지원 티켓 양(증가율 5% 미만 유지)

나쁜 로드맵: 기능 쇼핑 목록

## 2024년 1분기 로드맵

### 1월
- 다크 모드
- CSV 내보내기
- 사용자 아바타
- 비밀번호 재설정 개선

### 2월
- 대시보드 재설계
- 새 차트 유형
- API v2
- 모바일 앱

### 3월
- SSO 통합
- 웹훅
- 맞춤 도메인
- 화이트라벨링

실패 이유:

• 전략 맥락이나 "왜"가 없음
• 결과와 연결되지 않음
• 날짜 기반 약속을 부추김
• 우선순위 근거 없음

로드맵 유지관리 리듬

로드맵 변경 커뮤니케이션

우선순위가 바뀔 때:

## 로드맵 업데이트: 2024년 3월

### 변경된 것
모바일 앱 MVP가 1분기 → 2분기로 이동

### 이유
- 사용자 조사를 통해 웹 활성화가 주요 병목임이 드러남
- 웹에서 활성화한 모바일 사용자는 유지율이 2배 높음
- 온보딩 개선에 엔지니어링 수용량 필요

### 영향
- 모바일을 요청한 사용자: 약 6주 지연
- 온보딩 개선: 4주 앞당김
- 예상 활성화 상승: +8%(모바일의 +3% 대비)

### 다음 검토
4월 로드맵 검토에서 모바일 일정을 재평가

로드맵 검토 질문

로드맵을 확정하기 전:

1. 전략 정렬 — 이것이 회사 목표로 이어지는가?
2. 고객 가치 — 어떤 문제를 해결하는가?
3. 측정 가능한 결과 — 성공했는지 어떻게 알 수 있는가?
4. 의존성 — 무엇이 먼저 일어나야 하는가?
5. 위험 — 무엇이 성공을 막을 수 있는가?
6. 트레이드오프 — 우리는 무엇을 하지 않는가?

안티패턴

• 날짜 주도 — 전략 적합성보다 "3월에 약속했음" 우선
• 기능 중심 — 결과 없는 기능 목록
• 이해관계자 달래기 — 모두에게 조금씩 주지만 아무도 집중하지 않음
• 설정 후 방치 — 한 번 만들고 업데이트하지 않음
• 미래 과도 상세화 — 4분기를 1분기와 같은 수준으로 명세
• 유연성 없음 — 로드맵을 가설이 아니라 계약으로 취급

---

title: 기능 범위 설정과 트레이드오프 impact: HIGH tags: scoping, mvp, trade-offs, requirements, specs

기능 범위 설정과 트레이드오프

영향도: 높음

훌륭한 제품 관리자(PM)는 가치를 일찍, 자주 출시합니다. 최소 노력으로 최대 영향을 전달하는 범위 설정 기술을 익히세요.

MVP 사고방식

                    전달 가치
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   만들지 않음 │   MVP         │
         │   (낭비)      │   (여기서     │
         │               │    시작)      │
         │               │               │
낮은     │               │               │   높은
학습 ───┼───────────────┼───────────────┼─── 학습
         │               │               │
         │   피함        │   결국        │
         │   (위험)      │   (성장해 감) │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    전달 가치

범위 수준

좋은 범위 설정 예시: 알림 시스템

## 기능: 알림 시스템

### 비즈니스 맥락
사용자가 중요한 업데이트를 놓쳐 30일 이내 이탈의 15%로 이어집니다.
목표: "놓친 업데이트" 이탈을 50% 줄이기.

### 범위 옵션

#### 스케이트보드(1-2주) — 권장 시작점
- 치명적 이벤트에 대한 이메일 알림만
  - 결제 실패
  - 사용량 한도 접근
  - 팀 초대
- 단일 이메일 템플릿
- 환경설정 없음(항상 켜짐)
- 성공 지표: 오픈율 > 40%

#### 스쿠터(3-4주)
- 알림 유형 5개 추가
- 기본 이메일 환경설정(범주별 전체/없음)
- 앱 내 알림 벨(읽지 않음 수만)

#### 자전거(2개월 차)
- 유형/채널별 전체 알림 환경설정
- 기록이 있는 앱 내 알림 센터
- 푸시 알림(웹)
- 실시간 앱 내 배지

#### 오토바이(3분기)
- 모바일 푸시 알림
- Slack/Teams 통합
- 알림 요약(일간/주간)
- 스마트 알림 타이밍

### 권고
스케이트보드부터 시작하세요. 더 복잡한 인프라를 만들기 전에
이메일 참여도를 검증할 수 있습니다.

나쁜 범위 설정 예시

## 기능: 알림 시스템

다음을 포함한 완전한 알림 시스템을 만들어야 합니다:
- 이메일, 푸시, SMS, 앱 내, Slack
- 모든 알림 유형에 대한 사용자 환경설정
- 실시간 전달
- 알림 기록
- 분석 대시보드
- 템플릿 A/B 테스트

일정: 2개월

실패 이유:

• 전부 아니면 전무 접근
• 우선순위 없음
• 결과와 연결 없음
• 지연 위험 높음

트레이드오프 프레임워크: 철의 삼각형

                    ┌─────────┐
                    │  범위   │
                    └────┬────┘
                         │
         ┌───────────────┼───────────────┐
         │               │               │
    ┌────┴────┐     ┌────┴────┐     ┌────┴────┐
    │  시간   │─────│  품질   │─────│  비용   │
    └─────────┘     └─────────┘     └─────────┘

    2개를 고르세요. 세 번째는 유동적입니다.

트레이드오프 커뮤니케이션 템플릿

## 트레이드오프 결정: 기능 X

### 상황
출시까지 3주가 남았습니다. 현재 추정: 5주.

### 옵션

#### 옵션 A: 범위 축소(권장)
- 제외: 고급 필터링, 대량 작업
- 유지: 핵심 기능, 기본 필터링
- 위험: 일부 파워 유저 실망
- 혜택: 제때 출시, 핵심 가치 검증

#### 옵션 B: 일정 연장
- 제외: 없음
- 지연: 2주
- 위험: 마케팅 캠페인 놓침
- 혜택: 전체 기능 세트

#### 옵션 C: 리소스 추가
- 추가: 계약자 2명
- 위험: 온보딩 시간, 조율 부담
- 혜택: 1주 회복 가능

### 권고
옵션 A. 제외한 기능은 사용자 피드백을 바탕으로 v1.1에 추가할 수 있습니다.
제때 출시하는 것이 중요합니다.

### 결정 필요일: [날짜]

범위 증가 방어

기능 범위 설정을 위한 MoSCoW

## 기능 X 범위

### 반드시 필요(v1.0 - 2주)
- 주요 사용 사례를 해결하는 핵심 기능
- 기본 오류 처리
- 모바일 반응형

### 있어야 함(v1.1 - +1주)
- 보조 사용 사례 지원
- 개선된 오류 메시지
- 성능 최적화

### 있으면 좋음(v1.2 - +2주)
- 파워 유저 기능
- 키보드 단축키
- 대량 작업

### 이번에는 없음(향후 검토)
- API 접근
- 화이트라벨링
- 엔터프라이즈 기능

범위를 줄이기 위한 질문

무엇을 줄일 수 있는지 찾기 위해 질문하세요:

1. "가치를 줄 수 있는 가장 작은 것은 무엇인가요?"
2. "일주일밖에 없다면 무엇을 만들까요?"
3. "사용자가 없어도 용서할 수 있는 것은 무엇인가요?"
4. "자동화하기 전에 수동으로 할 수 있나요?"
5. "기존 인프라를 사용할 수 있나요?"
6. "만들기 전에 무엇을 배울 수 있나요?"
7. "이것은 반드시 필요한가요, 있으면 좋은가요?"

범위 협상 문구

안티패턴

• 빅뱅 릴리스 — 출시 전 몇 달 동안만 구축
• 범위 축소 두려움 — 아무것도 자르지 못함
• 명세 주도 개발 — 몇 달 동안 완벽한 명세 작성
• 전부 아니면 전무 — "제대로 하거나 아예 하지 않음"
• 사용자 요청 기능 그대로 구축 — 사용자가 말한 것 그대로 만들고 문제는 보지 않음
• 성급한 최적화 — 제품-시장 적합성 전에 규모 대비 구축
• 제약 무시 — 리소스가 무제한인 척함

---

title: 스프린트 계획 및 백로그 관리 impact: HIGH tags: sprint, backlog, agile, planning, estimation

스프린트 계획 및 백로그 관리

영향도: 높음

스프린트 계획은 전략을 실행으로 바꿉니다. 훌륭한 백로그 관리는 팀이 집중하고, 예측 가능하며, 지속적으로 가치를 출시하게 합니다.

스프린트 계획 프로세스

┌─────────────────────────────────────────────────────────────────┐
│                     스프린트 계획 흐름                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  전(PM 준비)              중(팀)              후(실행)          │
│  ───────────              ──────             ────────          │
│  • 백로그 정리            • 수용량 검토       • 일일 스탠드업   │
│  • 항목 우선순위          • 작업 약속         • 팀 장애물 해소  │
│  • 인수 기준 작성         • 노력 추정         • 진행 추적       │
│  • 맥락 준비              • 소유자 배정       • 범위 관리       │
│                           • 위험 표시         • 데모 + 회고     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

백로그 건강 체크리스트

스토리 품질 기준

좋은 사용자 스토리:

## 마케팅 매니저로서, 캠페인 데이터를 CSV로 내보내고 싶다
   그래서 선호하는 스프레드시트 도구에서 성과를 분석할 수 있다

### 인수 기준
- [ ] 캠페인 목록 페이지에 내보내기 버튼 표시
- [ ] CSV 포함: 캠페인 이름, 날짜, 지출, 노출, 클릭, 전환
- [ ] 최대 1000개 캠페인까지 30초 미만에 내보내기 완료
- [ ] 내보내기 중 사용자에게 진행 표시기 표시
- [ ] 내보내기 실패 시 재시도 옵션이 있는 오류 메시지 표시

### 기술 메모
- 기존 비동기 작업 인프라 사용
- 속도 제한: 사용자당 시간당 내보내기 5회

### 범위 제외
- 예약/자동 내보내기(향후 개선)
- 맞춤 열 선택(v2)

### 크기: 5포인트
### 의존성: 없음
### 디자이너: @jane(목업 첨부)

나쁜 사용자 스토리:

## 내보내기 기능

캠페인 페이지에 내보내기를 추가.

실패 이유:

• 사용자 맥락이나 "왜"가 없음
• 인수 기준 없음
• 범위 경계 없음
• 기술 맥락 없음

추정 모범 사례

스토리 포인트 척도:

추정 팁:

• 팀이 완료한 기준 스토리와 비교
• 코딩뿐 아니라 테스트 시간 포함
• 알 수 없는 것은 스파이크로 반영
• 8포인트 초과이면 더 작게 분해

스프린트 수용량 계획

## 스프린트 23 수용량

### 팀 구성
- 엔지니어 4명 × 10일 = 40인일
- 제외: 휴가(2일), 회의(20%), 지원 순번(10%)
- 가용: 40 × 0.7 = 28인일

### 속도 기준
- 최근 3스프린트: 32, 28, 35포인트
- 평균: 32포인트
- 약속: 28-32포인트(보수적)

### 배분
- 기능: 70%(20-22포인트)
- 버그: 15%(4-5포인트)
- 기술 부채: 15%(4-5포인트)

백로그 정리 안건

주간 정리 세션(1시간):

## 정리 세션 - [날짜]

### 1. 다가오는 스프린트 항목 검토(20분)
- 상위 10개 백로그 항목 검토
- 요구사항 명확화, 질문 답변
- 누락 정보 식별

### 2. 새 항목 추정(20분)
- 추정되지 않은 스토리에 플래닝 포커
- 8포인트 초과 항목 분해
- 완료되면 "스프린트 준비 완료"에 추가

### 3. 백로그 위생(10분)
- 오래된 항목 보관(6개월 이상 미진행)
- 중복 병합
- 새 정보 기반 재우선순위

### 4. 앞으로 보기(10분)
- 스프린트+2 항목 미리보기
- 필요한 조사/스파이크 식별
- 의존성을 일찍 표시

스프린트 의식 빠른 참조

스프린트 중간 변경 관리

추적할 스프린트 지표

안티패턴

• 스프린트 채워 넣기 — 수용량보다 많이 약속
• 약속 없음 — "얼마나 되는지 보죠"
• 무한 정리 — 만들어지지 않을 수도 있는 스토리를 완벽하게 다듬음
• 추정 극장 — 정확성 없이 형식만 밟음
• 회고 생략 — 개선 기회 상실
• PM이 티켓 작성자 — 엔지니어링 입력 없이 스토리 작성
• 속도를 성과 지표로 사용 — 팀 비교, 포인트 게임화
• 버퍼 없음 — 알 수 없는 것과 지원을 위한 여유 0

---

title: 이해관계자 관리 impact: HIGH tags: stakeholder, communication, alignment, influence

이해관계자 관리

영향도: 높음

제품 관리자(PM)에게는 권한이 아니라 영향력이 있습니다. 다양한 이해관계자를 공유된 결과를 중심으로 정렬시키는 기술을 익히세요.

이해관계자 매핑 매트릭스

                    높은 영향력
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   밀착 관리   │   적극 협력   │
         │               │               │
         │ (만족 유지)   │   (협업)      │
         │               │               │
낮은     │               │               │   높은
관심도 ─┼───────────────┼───────────────┼─── 관심도
         │               │               │
         │    모니터링   │   계속 공유   │
         │   (최소 관여)│               │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    낮은 영향력

이해관계자 커뮤니케이션 가이드

상향 관리: 경영진 커뮤니케이션

좋은 경영진 업데이트:

## 제품 업데이트 - 2024년 3월

### 핵심 요약
활성화율이 8% 개선(23% → 31%)되었고, 1분기 목표 35% 달성 궤도에 있음

### 주요 성과
- 온보딩 v2 출시(3월 1일)
- 첫 가치 도달 시간이 3일에서 1.5일로 감소
- 신규 사용자 NPS가 12점 개선

### 위험 및 장애물
- 모바일 앱 4주 지연(플랫폼 재구축 결정)
  - 완화: 웹 경험 우선순위 상향
- SSO 일정 때문에 엔터프라이즈 딜 위험
  - 완화: 2분기 SSO 빠른 트랙 진행

### 다음 달 집중
- 온보딩 v2.1 완료(남은 흐름 15%)
- 템플릿 라이브러리 출시(최상위 사용자 요청 해결)
- 모바일 앱 개발 시작

### 요청
- 결정 필요: 2분기에 엔지니어링 팀 2명 증원?
- 인지 필요: 경쟁사 X가 유사 기능 출시

나쁜 경영진 업데이트:

## 제품 업데이트

이번 달에는 다크 모드, 새 아이콘, 대시보드 개선, 여러 버그 수정 등
47개 기능을 출시했습니다. 팀은 로드맵을 열심히 진행 중입니다.
일부 지연이 있지만 관리하고 있습니다. 질문이 있으면 알려주세요.

실패 이유:

• 결과와 연결되지 않음
• 영향이 아니라 기능 개수를 셈
• 위험이 모호함
• 필요한 요청이나 결정이 없음

수평 관리: 교차 기능 정렬

기능 출시 RACI:

범례: R=실행 책임, A=최종 책임, C=협의, I=공유 대상

충돌하는 우선순위 다루기

1단계: 모든 관점 인정

"영업팀이 엔터프라이즈 딜을 위해 기능 X가 필요하다는 점과,
엔지니어링이 기술 부채를 우려한다는 점을 이해합니다. 둘 다
타당하고 중요합니다."

2단계: 공유 목표로 재프레이밍

"우리 모두 지속 가능한 매출 성장을 원합니다. 단기 성과와
장기 건전성을 어떻게 균형 맞출지 함께 정리해 봅시다."

3단계: 데이터로 촉진

"데이터가 말하는 것은 이렇습니다. 기능 X는 $200K 딜에 영향을 주고,
기술 부채는 속도를 20% 낮추고 있습니다. 이 트레이드오프를 논의합시다."

4단계: 권고안 제시

"제 권고는 기능 X의 범위를 줄인 버전을 2주 안에 출시하고,
다음 스프린트를 부채 축소에 전념하는 것입니다."

우아하게 거절하기

신뢰 구축 템플릿

주간 이해관계자 접점 안건:

## [이해관계자]와 1:1 - [날짜]

### 듣기로 시작(5분)
- 이번 주에 가장 마음에 걸리는 것은 무엇인가요?
- 제가 알아야 할 우려가 있나요?

### 우선순위 정렬(10분)
- [그들의 관심사]에 대해 현재 위치는 이렇습니다
- 다음에 예정된 것은 이렇습니다
- 질문이나 우려가 있나요?

### 장애물 처리(10분)
- 제게 필요한 것이 있나요?
- 제가 필요한 것은 이것입니다

### 약속으로 마무리(5분)
- 실행 항목 요약
- 다음 접점 확인

권한 없이 영향력 발휘

작동하는 기법:

안티패턴

• 회피 — 갈등이 저절로 해결되기를 바람
• 모두 만족시키기 — 모두에게 예라고 말함
• 깜짝 공격 — 사전 공유 없이 결정을 던짐
• 이메일 전쟁 — 이메일로 싸움
• 윗선으로 바로 넘기기 — 해결을 시도하기 전에 에스컬레이션
• 정보 독점 — 맥락을 자유롭게 공유하지 않음
• 비난 게임 — 실패했을 때 손가락질

---

title: 기술 부채 관리 impact: MEDIUM-HIGH tags: technical-debt, engineering, maintenance, quality

기술 부채 관리

영향도: 중상

기술 부채는 속도에 붙는 숨은 세금입니다. 훌륭한 제품 관리자(PM)는 건강한 코드베이스를 이해하고, 우선순위를 정하고, 이를 옹호합니다.

기술 부채란?

┌─────────────────────────────────────────────────────────────────┐
│                    기술 부채 유형                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   의도적                             우발적                     │
│   ──────                             ──────                     │
│   "지름길인 걸 알지만,              "당시에는 더 나은           │
│    나중에 고치겠습니다"               방법을 몰랐습니다"        │
│                                                                 │
│   신중함                             무모함                     │
│   ──────                             ──────                     │
│   "지금 출시하고 학습 후            "디자인 패턴이              │
│    리팩터링하겠습니다"                뭔가요?"                  │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │            의도적 + 신중함 = 전략적                     │  │
│   │           (수용 가능, 상환 계획 필요)                   │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐  │
│   │            무모함 + 우발적 = 위기                       │  │
│   │             (긴급, 즉시 수정 필요)                      │  │
│   └─────────────────────────────────────────────────────────┘  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

기술 부채 유형

기술 부채 우선순위 매트릭스

                    높은 비즈니스 위험
                         │
         ┌───────────────┼───────────────┐
         │               │               │
         │   일정 잡기   │   지금 수정   │
         │   (계획)      │   (긴급)      │
         │               │               │
낮은     │               │               │   높은
노력 ───┼───────────────┼───────────────┼─── 노력
         │               │               │
         │   수용        │   일정 잡기   │
         │   (감수)      │   (계획)      │
         │               │               │
         └───────────────┼───────────────┘
                         │
                    낮은 비즈니스 위험

부채 인벤토리 템플릿

## 기술 부채 인벤토리

### 치명적(2스프린트 이내 처리)

| ID | 설명 | 영향 | 노력 | 소유자 |
|----|-------------|--------|--------|-------|
| TD-001 | 인증 라이브러리가 2버전 뒤처짐(CVE) | 보안 위험 | 2일 | @alice |
| TD-002 | 공개 API에 속도 제한 없음 | 안정성 위험 | 3일 | @bob |

### 높음(이번 분기 처리)

| ID | 설명 | 영향 | 노력 | 소유자 |
|----|-------------|--------|--------|-------|
| TD-003 | 테스트 커버리지 45% | 버그 유출률 | 2주 | 팀 |
| TD-004 | 대시보드 쿼리 N+1 문제 | 성능 | 1주 | @carol |

### 중간(이번 반기 처리)

| ID | 설명 | 영향 | 노력 | 소유자 |
|----|-------------|--------|--------|-------|
| TD-005 | 오래된 모니터링 설정 | 인시던트 대응 | 2주 | @dave |
| TD-006 | 문서 공백 | 온보딩 시간 | 1주 | 팀 |

### 낮음(백로그)

| ID | 설명 | 영향 | 노력 | 소유자 |
|----|-------------|--------|--------|-------|
| TD-007 | 레거시 CSS 프레임워크 | 개발 속도 | 4주 | - |
| TD-008 | 일관되지 않은 API 응답 | 개발자 경험 | 2주 | - |

기능과 부채 균형

권장 스프린트 배분:

리더십에 부채 커뮤니케이션

좋은 부채 커뮤니케이션:

## 기술 부채 업데이트 - 2024년 1분기

### 요약
현재 기술 부채가 속도에 약 20% 영향을 주고 있습니다. 투자하지 않으면
3분기에는 30% 영향으로 커질 것으로 예상합니다.

### 비즈니스 영향
| 부채 항목 | 현재 영향 | 처리하지 않을 경우 |
|-----------|----------------|----------------|
| 테스트 커버리지(45%) | 주 2건 버그가 운영으로 유출 | 주 4건 이상 |
| API 성능 | 로딩 3초(경쟁사의 2배) | 고객 이탈 |
| 레거시 인증 | 스프린트당 1일 유지보수 | 보안 사고 |

### 권장 투자
2분기 수용량의 20%(6인주)를 다음에 배정:
1. 테스트 커버리지를 70%로 개선(2주)
2. API 쿼리 최적화(2주)
3. 인증 라이브러리 업그레이드(2주)

### ROI 전망
- 버그 유출률: -50%
- 개발 속도: +15%
- 보안 위험: 크게 감소

### 필요한 결정
2분기 부채 배분 20% 승인?

나쁜 부채 커뮤니케이션:

기술 부채가 많습니다. 코드가 나쁘고 다시 써야 합니다.
엔지니어링이 답답해합니다. 한 분기 동안 기능을 멈출 수 있나요?

실패 이유:

• 비즈니스 영향 프레이밍 없음
• 우선순위 없음
• 요청이 모호함
• ROI 근거 없음

부채 작업을 설득하는 근거

기술 부채 스프린트 패턴

패턴 1: 비율 배분

• 매 스프린트: 부채에 수용량 15-20%
• 장점: 꾸준한 진행
• 단점: 큰 항목을 끝내기 어려울 수 있음

패턴 2: 부채 스프린트

• 4번째 스프린트마다: 부채 100% 집중
• 장점: 큰 항목 완료
• 단점: 기능 일시 중지, 조율 필요

패턴 3: 보이스카우트 규칙

• "코드를 발견했을 때보다 더 좋게 남기기"
• 장점: 지속적 개선
• 단점: 추적이 어렵고 큰 항목을 다루지 못할 수 있음

패턴 4: 해커 위크

• 분기별: 한 주 전체 부채 집중
• 장점: 팀 사기, 큰 성과
• 단점: 드물고 항목이 쌓임

새 부채 예방

기술 부채 회고 질문

1. 이번 분기에 어떤 지름길을 택했나요?
2. 무엇이 우리를 가장 느리게 하나요?
3. 무엇이 계속 깨지나요?
4. 새로 시작한다면 무엇을 다르게 할까요?
5. 엔지니어가 가장 답답해하는 것은 무엇인가요?
6. 새 개발자 온보딩을 더 쉽게 만들 것은 무엇인가요?

안티패턴

• 부채 부정 — "우리는 기술 부채가 없습니다"
• 부채 저장만 하기 — 추적하지만 처리하지 않음
• 빅뱅 재작성 — "전부 다시 씁시다"
• 보이지 않는 부채 — 추적하거나 커뮤니케이션하지 않음
• 기능 터널 시야 — 새 작업만 하고 유지보수 없음
• 과도한 장식 — 중요하지 않은 부채를 고침
• 엔지니어 탓하기 — 부채는 비즈니스 결정
• 우선순위 없음 — 모든 부채가 같다고 봄(아님)