기능을 출시할 준비가 되었을 때 /product-launch-manager가 출시 계획을 만들어 모든 팀을 하나의 문서로 조율합니다. — Claude Skill

---

title: 섹션 구성

1. 출시 계획 (planning)

영향도: 매우 높음 설명: 출시 등급, 일정, 성공 기준, 전략적 정렬을 포함한 출시의 기초 결정입니다. 이후 모든 작업의 청사진입니다.

2. 부서 간 조율 (coordination)

영향도: 매우 높음 설명: 이해관계자 정렬, RACI 매트릭스, 여러 팀을 하나의 출시 목표로 움직이는 조율입니다. 대부분의 출시가 실패하는 지점입니다.

3. 베타 및 얼리 액세스 (beta)

영향도: 높음 설명: 출시 전 검증 프로그램, 베타 코호트 관리, 피드백 반영입니다. 출시 전에 위험을 낮춥니다.

4. 출시 커뮤니케이션 (communication)

영향도: 높음 설명: 내부 지원, 외부 메시징, 다채널 커뮤니케이션 계획입니다. 무엇을 언제 말할지 정합니다.

5. 출시 실행 (execution)

영향도: 매우 높음 설명: 출시 당일 운영, 상황실, 런북, 실시간 의사결정입니다. 진짜 검증의 순간입니다.

6. 출시 후 운영 (postlaunch)

영향도: 높음 설명: 모니터링, 회고, 지표 분석, 반복 개선입니다. 출시했다고 출시가 끝나는 것은 아닙니다.

---

title: 베타 및 얼리 액세스 프로그램 impact: HIGH tags: beta, early-access, validation, feedback

베타 및 얼리 액세스 프로그램

영향도: 높음

베타 프로그램은 공개 발표 전에 실제 사용자로 검증하여 출시 위험을 낮춥니다.

베타 프로그램 유형

베타 코호트 선정

이상적인 베타 참여자:

좋은 예: 구조화된 베타 프로그램

## 베타 프로그램: 워크플로 자동화

### 프로그램 구조
| 단계 | 기간 | 코호트 규모 | 목표 |
|-------|----------|-------------|-------|
| 알파 | 2주 | 사용자 10명 | 핵심 흐름 검증 |
| 비공개 베타 | 4주 | 사용자 100명 | 사용 사례 범위 검증 |
| 공개 베타 | 2주 | 사용자 500명 | 규모 + 예외 사례 |

### 코호트 선정 기준
**알파(사용자 10명):**
- 내부 고급 사용자(5)
- 디자인 파트너(3)
- 고객 자문단(2)

**비공개 베타(사용자 100명):**
- 타깃 세그먼트의 고급 사용자(40)
- 기능을 요청한 고객(30)
- 다양한 회사 규모 조합(20)
- 해외 사용자(10)

### 피드백 수집
| 방식 | 시점 | 목표 |
|--------|--------|------|
| 킥오프 설문 | 1일 차 | 기대 기준선 |
| 앱 내 피드백 위젯 | 지속 | 마찰 지점 |
| 주간 설문 | 주말 | 만족도 추세 |
| 사용자 인터뷰 | 2주 차, 4주 차 | 깊은 정성 이해 |
| 종료 설문 | 베타 종료 | 전체 평가 |

### 정식 출시(GA) 성공 기준
- 베타 사용자 70%가 기능이 없으면 "실망할 것"이라고 답함
- 워크플로 오류율 5% 미만
- 보고된 심각한 버그 3건 미만
- 베타 코호트 NPS 40 초과
- 검증된 사용 사례 3개 이상 문서화

나쁜 예: 구조 없는 베타

## 베타 프로그램: 새 편집기(하지 말아야 할 방식)

**접근 방식:**
- "그냥 사용자 10%에게 배포해 보자"
- 코호트 선정 기준 없음
- 피드백 메커니즘 계획 없음
- 성공 기준 정의 없음
- 일정이나 단계 없음

**발생한 일:**
- 무작위 사용자가 기능을 받음(이탈 계정 포함)
- 2주 동안 피드백을 받지 못함
- 화난 고객의 트윗으로 심각한 버그 발견
- 정식 출시(GA) 결정을 뒷받침할 데이터 없음
- 그래도 출시해 지원 티켓 3배 증가

**교훈:** 구조 없는 베타는 베타가 아니라 혼란입니다.

베타 커뮤니케이션 템플릿

초대 이메일:

제목: 초대합니다: [기능] 얼리 액세스

안녕하세요 [이름]님,

새로운 [한 줄 가치 제안]인 [기능]의 얼리 액세스 대상으로
선정되셨습니다.

**선정 이유:**
- 가장 활발한 [세그먼트] 사용자 중 한 분입니다
- [선정 기준이 된 구체적 행동]을 하셨습니다

**제공되는 것:**
- 독점 얼리 액세스(정식 출시 4주 전)
- 제품 팀과의 직접 소통 창구
- 피드백으로 최종 제품을 만드는 기회

**요청드리는 것:**
- 첫 주 안에 기능 사용
- 짧은 설문 2개 완료(각 5분)
- 앱 내 위젯으로 버그 보고

[초대 수락 버튼]

이 베타는 [날짜] 동안 진행됩니다. 기능은 피드백에 따라 변경될 수 있습니다.

주간 점검:

제목: [X]주 차 점검: [기능] 베타

안녕하세요 [이름]님,

베타 관련 간단한 업데이트입니다.

**이번 주 개선 사항:**
- [피드백 기반 개선]
- [버그 수정]

**피드백이 반영된 방식:**
- "[피드백 인용]" → 저희가 [수행한 조치]

**이번 주 요청:**
- [특정 기능/흐름]을 사용해 보세요
- 2분 설문: [링크]

질문이 있으면 이 이메일에 답장하거나 Slack으로 직접 메시지를 주세요.

피드백 수집 프레임워크

베타 지표 대시보드

베타 상태 대시보드
═════════════════════

참여
├── 초대: 100
├── 수락: 85 (85%)
├── 활성(이번 주 사용): 62 (73%)
└── 베타 이탈: 8 (9%)

피드백
├── 설문 응답: 45 (53%)
├── 버그 보고: 23
├── 기능 요청: 12
└── 인터뷰 자원자: 18

품질
├── 심각한 버그: 2(둘 다 수정)
├── 주요 버그: 8(5건 수정)
├── 오류율: 2.3%
└── 성능: p95 180ms

감정 반응
├── NPS: 52
├── "없으면 실망": 68%
└── 가장 큰 불만: "첫 설정이 혼란스러움"

베타 종료 기준

정식 출시(GA) 결정: 승인

얼리 액세스 vs. 베타

안티패턴

• 소프트 출시로 쓰는 베타 - 피드백 메커니즘 없이 단계적 배포만 함
• 너무 작은 코호트 - 사용자 5명으로는 예외 사례를 찾기 어려움
• 너무 큰 코호트 - 피드백 구조 없이 사용자 1000명에게 배포
• 종료 기준 없음 - 끝나지 않는 베타
• 피드백 무시 - 데이터만 수집하고 행동하지 않음
• 무작위 선정 - 손든 사람 아무나 받는 방식, 전략적 코호트가 아님
• 일정 없음 - "어떻게 되는지 보자"
• 베타 피로 - 같은 사용자가 모든 베타에 참여해 소진됨

---

title: 출시를 위한 내부 지원 impact: HIGH tags: communication, enablement, sales, support, training

출시를 위한 내부 지원

영향도: 높음

내부 팀은 첫 번째 출시 대상입니다. 영업이 설명하지 못하고 지원팀이 문제를 해결하지 못한다면 이미 실패한 것입니다.

내부 지원 일정

영업 지원 패키지

필수 자료:

좋은 예: 영업용 1페이지 요약

# 엔터프라이즈 SSO - 영업용 1페이지 요약

## 무엇인가
엔터프라이즈 ID 공급자를 위한 SAML 2.0, OIDC,
SCIM 프로비저닝을 지원하는 싱글 사인온 통합입니다.

## 대상
- 엔터프라이즈 회사(직원 500명 이상)
- 보안을 중시하는 조직
- 기존 IdP를 보유한 회사(Okta, Azure AD 등)

## 핵심 가치 제안
1. **보안 컴플라이언스** - SOC 2, HIPAA 요구사항 충족
2. **IT 효율성** - 사용자 프로비저닝/해제 자동화
3. **사용자 경험** - 원클릭 로그인, 비밀번호 피로 감소

## 발견 질문
- "현재 여러 도구의 사용자 접근 권한을 어떻게 관리하고 있나요?"
- "직원이 퇴사할 때 접근 권한 해제 절차는 어떻게 되나요?"
- "접근 제어와 관련된 컴플라이언스 요구사항이 있나요?"

## 이의 제기 대응
| 이의 제기 | 답변 |
|-----------|----------|
| "너무 비쌉니다" | SSO는 비밀번호 재설정 티켓을 40% 줄입니다 |
| "우리는 [경쟁사]를 사용합니다" | 동일한 IdP를 지원하고 설정이 더 빠릅니다 |
| "우선순위가 아닙니다" | 보안 침해의 평균 비용은 $4.2M입니다 |

## 가격
- 엔터프라이즈 요금제에 포함($X/사용자/월)
- 비즈니스 요금제의 추가 기능으로 제공(+$Y/사용자/월)

## 데모 환경
- sandbox-sso.company.com
- 자격 증명: [email protected] / [1Password에 있음]

나쁜 예: 내부 지원 없음

## 발생한 일: Widget 2.0 출시

**영업 팀 경험:**
- 고객의 LinkedIn 게시물로 출시 사실을 알게 됨
- 교육이 제공되지 않음
- 기능을 이해하려고 블로그 글을 읽어야 했음
- 데모 환경이 설정되지 않음
- 첫 고객 통화: "잘 모르겠습니다. 확인하고 다시 연락드리겠습니다"

**지원 팀 경험:**
- 문서가 생기기도 전에 첫 티켓을 받음
- 문제 해결 가이드가 없음
- 코드에서 기능을 역공학해야 했음
- 평균 응답 시간이 2시간으로 증가(평소 30분)

**결과:**
- 첫 주에 엔터프라이즈 거래 3건 상실
- 지원 CSAT 20점 하락
- 팀 사기 손상
- 고객 신뢰 약화

지원팀 지원 패키지

필수 자료:

좋은 예: 지원 문제 해결 가이드

# SSO 문제 해결 가이드

## 흔한 이슈 및 해결

### 이슈: SAML assertion 오류
**증상:** 사용자가 로그인 시 "잘못된 SAML 응답"을 봄
**가능한 원인:**
1. IdP와 우리 서버 사이의 시간 차이
2. 잘못된 assertion consumer URL
3. 인증서 불일치

**해결 단계:**
1. IdP 설정이 우리 설정 가이드와 일치하는지 확인
2. assertion URL이 `https://app.company.com/sso/callback` 인지 확인
3. 관리자 > SSO 설정에서 인증서 지문 비교
4. 계속되면 SAML trace 수집(아래 지침 참고)

**에스컬레이션:** 3번 시도 후에도 해결되지 않으면
SAML trace를 첨부해 2단계 지원팀으로 에스컬레이션합니다.

### 이슈: SCIM 동기화 실패
**증상:** 사용자가 프로비저닝/해제되지 않음
**가능한 원인:**
1. SCIM 토큰 만료
2. 속도 제한
3. 사용자 속성 매핑 불일치

**해결 단계:**
1. 관리자 > 통합에서 SCIM 토큰 확인
2. 속도 제한 이슈가 있는지 상태 페이지 확인
3. IdP의 속성 매핑 검토
4. 관리자 패널에서 수동 동기화 실행

**에스컬레이션:** 동기화 대기열이 사용자 1000명을 초과하면
조직 ID와 함께 엔지니어링으로 에스컬레이션합니다.

고객 성공 지원

내부 지원 전달 방식

내부 지원 인증

1등급/2등급 출시에는 인증 요구를 검토합니다.

영업 인증 체크리스트
─────────────────────────────
□ 교육 영상 완료(15분)
□ 퀴즈 통과(최소 80%)
□ 관리자에게 연습 데모 진행
□ 배틀카드 검토
□ 고객 통화 1건 참관

인증 유효 기간: [날짜]

내부 지원 피드백 루프

출시 후 1주 차:
├── "고객이 어떤 질문을 하나요?"
├── "어떤 이의 제기를 듣고 있나요?"
├── "자료에서 무엇이 빠졌나요?"
└── "문서에서 무엇이 혼란스럽나요?"

조치: 피드백을 바탕으로 자료 업데이트

안티패턴

• 출시 당일 내부 지원 - 출시 당일에 교육함
• 이메일만 보내는 내부 지원 - 긴 이메일은 아무도 읽지 않음
• 인증 없음 - 모두가 스스로 준비할 것이라고 가정함
• 한 번 하고 끝 - 피드백 기반 반복이 없음
• 제품 마케팅이 혼자 작성 - 영업과 지원이 제작에 참여하지 않음
• 서로 다른 버전 - 영업과 지원이 다른 이야기를 함
• 데모 환경 없음 - "고객에게 설명만 하세요"
• 기술 문서만 있음 - 영업을 위한 비즈니스 맥락이 없음

---

title: 외부 출시 커뮤니케이션 impact: HIGH tags: communication, messaging, pr, marketing

외부 출시 커뮤니케이션

영향도: 높음

출시 메시지는 고객에게 한 번 닿습니다. 모든 채널에서 명확하고 설득력 있게 전달해 그 기회를 살리세요.

메시지 계층

                ┌─────────────────────┐
                │      포지셔닝        │
                │   (왜 존재하는가)    │
                └──────────┬──────────┘
                           │
                ┌──────────▼──────────┐
                │     핵심 메시지      │
                │  (무엇이 새로워졌나) │
                └──────────┬──────────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
    ┌─────▼─────┐    ┌─────▼─────┐    ┌─────▼─────┐
    │  증거      │    │  증거      │    │  증거      │
    │  포인트 1  │    │  포인트 2  │    │  포인트 3  │
    └───────────┘    └───────────┘    └───────────┘

등급별 채널 전략

메시징 프레임워크

3부분 출시 메시지:

좋은 예: 출시 블로그 글

# 엔터프라이즈 SSO를 소개합니다: 원클릭 로그인으로 팀을 안전하게 보호

보안 팀은 요청해 왔고, IT 팀은 기다려 왔습니다.
오늘 엔터프라이즈 SSO를 출시합니다. 이제 [제품]은 강력한 만큼
안전해집니다.

## 새로워진 점

엔터프라이즈 SSO는 다음을 제공합니다.
- **SAML 2.0 및 OIDC 지원** - Okta, Azure AD, OneLogin,
  그리고 표준을 준수하는 모든 ID 공급자와 작동
- **SCIM 프로비저닝** - IdP에서 사용자를 자동으로 동기화
- **적시 프로비저닝** - 첫 로그인 시 새 사용자 생성

## 중요한 이유

[베타 고객의 보안 리더 인용]

**IT 팀에게:** 더 이상 수동 사용자 관리가 필요 없습니다. 누군가 퇴사하면
자동으로 프로비저닝이 해제됩니다. 잊힌 계정도, 보안 공백도 없습니다.

**직원에게:** 한 번 클릭으로 로그인합니다. 기억할 비밀번호가 더 이상 없습니다.
"비밀번호를 잊으셨나요" 흐름도 줄어듭니다.

**보안 팀에게:** 모든 로그인을 감사합니다. IdP를 통해 MFA를 적용합니다.
SOC 2, HIPAA 등 컴플라이언스 요구사항을 충족합니다.

## 시작 방법

1. 관리자 > 보안 > SSO로 이동
2. ID 공급자 선택
3. 단계별 가이드를 따름(평균 설정 시간: 15분)

[행동 유도 버튼: 지금 SSO 활성화]

## 가격

엔터프라이즈 SSO는 엔터프라이즈 요금제에 추가 비용 없이 포함됩니다.
비즈니스 요금제 고객은 SSO를 $X/사용자/월로 추가할 수 있습니다.

## 더 알아보기

- [문서: SSO 설정 가이드]
- [웨비나: SSO 모범 사례(등록)]
- [엔터프라이즈 관련 영업팀 상담]

나쁜 예: 약한 출시 커뮤니케이션

# 새 기능: SSO

제품에 SSO를 추가했습니다. 이제 SSO로 로그인할 수 있습니다.

SSO는 싱글 사인온을 의미합니다. 회사 자격 증명으로
로그인할 수 있게 해 줍니다.

사용하려면 설정으로 가서 켜세요.

감사합니다,
팀 드림

**실패하는 이유:**
- 가치 제안이 없음
- 차별화가 없음
- 구체적인 기능이 언급되지 않음
- 사회적 증거가 없음
- 약한 행동 유도
- 기억에 남지 않음

이메일 캠페인 구조

1등급 출시 이메일 시퀀스:

소셜 미디어 출시 계획

LinkedIn(B2B 중심):

게시물 1(출시일 오전 8시):
[공지 + 핵심 이미지]
"오늘 엔터프라이즈 SSO를 출시합니다..."

게시물 2(출시일 오후 2시):
[창업자 관점]
"우리가 SSO를 만든 이유: [개인적 이야기]..."

게시물 3(2일 차):
[고객 인용 카드]
"[베타 고객 인용]..."

게시물 4(3일 차):
[사용 방법 캐러셀]
"4단계로 SSO 설정하기..."

Twitter/X(기술 커뮤니티):

스레드(출시일):
1/ 큰 소식: 엔터프라이즈 SSO가 공개되었습니다

포함된 기능:
- SAML 2.0 및 OIDC
- SCIM 프로비저닝
- 주요 IdP 모두 지원

2/ 가장 좋은 점은? 설정이 15분이면 됩니다.

구성을 매우 쉽게 만들기 위해 베타 고객 50곳과 함께 작업했습니다.

3/ [설정 흐름 스크린샷]

4/ 지금 엔터프라이즈 고객에게 제공됩니다.
비즈니스 고객은 $X/사용자/월로 추가할 수 있습니다.

링크: [출시 블로그]

보도자료 구조

즉시 배포 가능

# [회사], 엔터프라이즈 SSO 출시로 조직에 안전한
# 원클릭 접근 제공

[도시, 날짜] - 선도적인 [카테고리]인 [회사]는 오늘
조직이 [핵심 이점]을 달성할 수 있도록 엔터프라이즈
싱글 사인온(SSO) 출시를 발표했습니다.

## 주요 기능:
- [기능 1]
- [기능 2]
- [기능 3]

"[이것이 중요한 이유에 대한 회사 임원 인용]"
- [이름], [직함], [회사]

## 고객 검증
"[가치에 대한 베타 고객 인용]"
- [이름], [직함], [고객 회사]

## 제공 여부
[가격 및 제공 조건 상세]

## [회사] 소개
[회사 소개 문구]

## 미디어 문의
[연락처 정보]

커뮤니케이션 타이밍

안티패턴

• 전문용어 과다 - 명확한 이점 대신 "시너지 활용" 같은 표현
• 기능 우선 - 왜가 아니라 무엇으로 시작
• 행동 유도 없음 - 행동 없는 공지
• 단일 채널 - 배포 없이 블로그만 게시
• 나쁜 타이밍 - 금요일 오후 또는 휴일 출시
• 시각 자료 없음 - 텍스트만 있는 공지
• 일관성 없는 메시지 - 채널마다 다른 이야기
• 성급한 보도자료 - 3등급 기능에 보도자료 발행

---

title: 부서 간 출시 조율 impact: CRITICAL tags: coordination, stakeholders, raci, alignment

부서 간 출시 조율

영향도: 매우 높음

출시는 팀과 팀 사이의 경계에서 실패합니다. 집요한 조율이 성공과 혼란을 가릅니다.

출시 조율의 삼각 축

              ┌─────────────┐
              │    제품      │
              │   (선장)     │
              └──────┬──────┘
                     │
         ┌───────────┴───────────┐
         │                       │
    ┌────▼────┐             ┌────▼────┐
    │ 마케팅   │◄───────────►│엔지니어링│
    └─────────┘             └─────────┘

제품이 선장이지만, 마케팅과 엔지니어링은 각자 영역에서 거부권을 가집니다.

출시 단계별 RACI 매트릭스

계획 단계(T-8주부터 T-4주)

준비 단계(T-4주부터 T-1주)

실행 단계(T-1주부터 출시까지)

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

이해관계자 커뮤니케이션 주기

좋은 예: 효과적인 조율

## 출시 조율 계획: 엔터프라이즈 SSO

### 핵심 팀(주간 동기화 - 목요일 오후 2시)
- 제품 관리자: Sarah Chen(선장)
- 제품 마케팅: Mike Rodriguez
- 엔지니어링 리드: Priya Patel
- 영업 지원: Tom Walsh
- 지원 리드: Lisa Kim

### 확장 팀(Slack #sso-launch로 공유)
- 개발자 관계(DevRel): James Wu
- 법무: Amanda Foster
- 보안: David Park
- 고객 성공: 지역 리드

### 커뮤니케이션 리듬
| 주기 | 대상 | 채널 | 담당 |
|---------|----------|---------|-------|
| 매일(T-2주) | 핵심 팀 | 스탠드업 | 제품 관리자 |
| 매주 | 확장 팀 | Slack 요약 | 제품 관리자 |
| 격주 | 임원 스폰서 | 이메일 + 15분 | 제품 관리자 |
| 필요 시 | 전사 | Slack 공지 | 제품 관리자 |

### 의사결정 권한
| 결정 | 결정자 | 승인 필수 |
|----------|-------------|------------------|
| 출시일 변경 | 제품 관리자 | 임원 스폰서 |
| 범위 변경 | 제품 관리자 + 엔지니어링 리드 | 제품 관리자 |
| 메시징 변경 | 제품 마케팅 | 제품 관리자 |
| 진행/중단 | 핵심 팀 투표 | 임원 스폰서 |

### 에스컬레이션 경로
1. 핵심 팀원 → 제품 관리자(당일)
2. 제품 관리자 → 임원 스폰서(24시간 내)
3. 부서 간 충돌 → 임원 스폰서 중재

나쁜 예: 조율 실패

## 문제 사례: Widget 2.0 출시

### 무시된 위험 신호:
- 단일 책임자가 식별되지 않음
- 마케팅이 출시 1주 전에야 기능을 알게 됨
- 영업 교육이 출시 당일에야 진행됨
- 지원 문서를 엔지니어링이 작성함
- 정기 동기화 회의가 잡히지 않음
- 복도 대화에서 의사결정이 이루어짐

### 결과:
- 지원 티켓이 평소의 5배(교육받지 못한 팀)
- 영업이 고객 질문에 답하지 못함
- 마케팅 블로그 글에 잘못된 기능 설명이 들어감
- "진행" 결정 후 출시가 2주 지연됨
- 임원이 고객 불만을 뒤늦게 알게 됨

### 근본 원인: 조율 프레임워크 부재

의존성 추적

출시 의존성 지도
═══════════════════════

기능 완료(엔지니어링)
        │
        ├──► 문서 준비 완료(지원)
        │           │
        │           └──► 지원 교육 완료
        │
        ├──► 데모 환경 준비 완료(엔지니어링)
        │           │
        │           └──► 영업 지원 완료
        │
        └──► API 확정(엔지니어링)
                    │
                    └──► 통합 파트너 준비 완료

모든 경로가 진행/중단 결정 전에 완료되어야 함

인수인계 프로토콜

갈등 해결 프레임워크

갈등 유형              해결 경로
─────────────           ───────────────
일정 이견             → 제품 관리자가 중재, 임원이 승인
범위 이견             → 엔지니어링 의견을 반영해 제품 관리자가 결정
메시징 이견           → 제품 관리자 의견을 반영해 제품 마케팅이 결정
자원 충돌             → 임원 스폰서가 결정
품질 vs 속도          → 품질에 대해서는 엔지니어링 리드가 거부권 보유

조율 도구

안티패턴

• 단일 책임자 없음 - 공동 소유는 결국 무소유
• 사일로식 계획 - 팀들이 출시 시점에야 충돌을 발견
• 회의 과부하 - 하루 5시간 동기화 회의
• 비동기만 고집 - 일부 결정은 실시간 논의가 필요
• 에스컬레이션 경로 없음 - 충돌이 곪음
• 이해관계자 늦은 참여 - "이 출시를 몰랐어요"
• 위원회식 의사결정 - 끝없는 논쟁, 실행 없음
• 구두 합의 - 기록되지 않은 결정이 혼란을 만듦

---

title: 출시 당일 실행 impact: CRITICAL tags: execution, launch-day, war-room, operations

출시 당일 실행

영향도: 매우 높음

출시 당일은 몇 주간 준비한 결과가 모이는 순간입니다. 명확한 런북, 상황실, 실시간 조율로 정밀하게 실행하세요.

출시 당일 일정 템플릿

출시 당일 일정(1등급/2등급)
══════════════════════════════

06:00  상황실 개방, 모니터링 시작
06:30  엔지니어링: 최종 배포 검증
07:00  PR 엠바고 해제, 언론 보도 시작
08:00  블로그 글 공개
08:30  마케팅: 소셜 미디어 캠페인 시작
09:00  이메일 캠페인 발송
09:30  앱 내 알림 활성화
10:00  영업 팀에 연락 시작 알림
10:30  첫 상태 점검(모든 팀)
12:00  정오 상태 점검
14:00  오후 상태 점검
16:00  일과 종료 상태 점검
18:00  상황실 종료(또는 필요 시 연장)
T+1    오전 디브리프, 야간 모니터링 리뷰

상황실 설정

가상 상황실(Slack/Teams):

#launch-war-room
├── 목적: 실시간 조율
├── 참여자: 핵심 출시 팀 + 온콜
├── 규칙:
│   ├── 모든 이슈는 즉시 여기에 게시
│   ├── 논의는 스레드 사용
│   ├── 중요 업데이트는 고정
│   └── 별도 대화 금지
│
├── 고정 메시지:
│   ├── 출시 런북 링크
│   ├── 에스컬레이션 연락처
│   ├── 상태 페이지 링크
│   └── 롤백 명령

물리 상황실(해당되는 경우):

출시 런북 템플릿

# [기능] 출시 런북

## 출시 전 체크리스트(T-1시간)
□ 모든 배포 완료
□ 기능 플래그 활성화 준비
□ 모니터링 대시보드 열림
□ 온콜 엔지니어 확인
□ 지원 팀 브리핑 완료
□ 롤백 계획 검토

## 출시 순서
| 시간 | 조치 | 담당 | 검증 |
|------|--------|-------|--------|
| 08:00 | 기능 플래그 활성화 | @eng-lead | [링크] |
| 08:05 | 지표 기준선 확인 | @pm | [링크] |
| 08:10 | 블로그 글 게시 | @pmm | [링크] |
| 08:15 | 블로그 공개 확인 | @pmm | [링크] |
| 08:30 | 이메일 캠페인 발송 | @pmm | [링크] |
| 08:35 | 이메일 발송 확인 | @pmm | [링크] |
| 09:00 | 앱 내 알림 활성화 | @eng | [링크] |
| 09:05 | 소셜 채널 게시 | @pmm | [링크] |
| 09:30 | 첫 상태 점검 | @all | [체크리스트] |

## 상태 점검 프로토콜
2시간마다 확인:
□ 오류율 < 0.1%
□ p95 지연 시간 < 200ms
□ 지원 티켓 < 임계값
□ 소셜 감정 반응 중립/긍정
□ 기능 도입 추적 작동

## 에스컬레이션 매트릭스
| 이슈 유형 | 1차 연락 | 에스컬레이션 대상 | SLA |
|------------|---------------|-------------|-----|
| P0(시스템 중단) | @eng-oncall | @eng-lead | 5분 |
| P1(성능 저하) | @eng-oncall | @eng-lead | 15분 |
| 지원 급증 | @support-lead | @pm | 30분 |
| PR 이슈 | @pmm | @comms-lead | 15분 |
| 임원 에스컬레이션 | @pm | @exec-sponsor | 즉시 |

## 롤백 절차
롤백이 필요하면:
1. 제품 관리자가 #launch-war-room에 공지
2. 엔지니어링 리드가 "롤백 확인"으로 확인
3. 실행: `./scripts/rollback-feature.sh`
4. 롤백 완료 검증
5. 제품 관리자가 이해관계자에게 알림
6. 마케팅이 캠페인 일시 중지
7. 지원팀이 대기 응답 발송

## 비상 연락처
| 역할 | 이름 | 전화 | Slack |
|------|------|-------|-------|
| 제품 관리자 | [이름] | [전화] | @handle |
| 엔지니어링 리드 | [이름] | [전화] | @handle |
| 임원 스폰서 | [이름] | [전화] | @handle |

좋은 예: 매끄러운 출시 실행

## 출시 당일 로그: 엔터프라이즈 SSO

**08:00** - 기능 플래그 활성화. 모든 시스템 정상.
**08:05** - 기준 지표 수집. 오류율 0.02%.
**08:10** - 블로그 게시. [링크 확인]
**08:32** - 이메일 캠페인 시작. 수신자 50K명.
**09:00** - 앱 내 알림 공개.
**09:15** - 첫 지원 티켓: 사용자가 설정을 혼란스러워함.
           FAQ 업데이트. 에스컬레이션 없음.
**09:30** - 상태 점검: 모두 정상.
           - 오류율: 0.03%
           - 첫 SSO 설정 10건 성공
           - 소셜 감정 반응: 긍정
**10:30** - SSO 설정 47건 완료(목표: 30).
**12:00** - 정오 점검: 모두 정상.
           - 오류율: 0.02%
           - SSO 설정 89건
           - 지원 티켓 3건(모두 해결)
**14:00** - 언론 보도 등장 시작.
**16:00** - 하루 종료 점검:
           - SSO 설정 156건(목표: 100)
           - P0/P1 인시던트 0건
           - 지원 티켓 8건(모두 해결)
           - 초기 사용자 NPS: 62
**17:00** - 상황실 종료. 야간 모니터링 활성화.

**상태: 성공적인 출시**

나쁜 예: 혼란스러운 출시

## 출시 당일 재난: Widget 2.0

**08:00** - 기능이 출시될 예정이었으나 배포가 멈춤.
**08:15** - 블로그 글이 그대로 공개됨(너무 이른 공개).
**08:20** - 고객이 "기능을 찾을 수 없음" 오류를 봄.
**08:30** - Twitter 불만 시작.
**08:45** - 배포가 마침내 완료됨.
**09:00** - 이미 오류를 본 고객에게 이메일 발송.
**09:15** - 지원 대기열 50건, 팀 브리핑 없음.
**09:30** - 상태 점검 미수행. 제품 관리자는 회의 중.
**10:00** - 임원이 상태를 물음. 업데이트를 가진 사람이 없음.
**11:00** - 오류율 5% 발견(한도는 0.1%).
**11:30** - 롤백 결정을 30분 동안 논쟁.
**12:00** - 롤백 실행. 고객 혼란.
**12:30** - 블로그 글은 여전히 기능을 설명하며 공개 상태.
**14:00** - "실패한 출시"에 대한 언론 기사 게시.

**근본 원인:**
- 배포 검증 단계 없음
- 엔지니어링과 마케팅 간 조율 없음
- 상황실 또는 커뮤니케이션 채널 없음
- 상태 점검 프로토콜 없음
- 명확한 롤백 결정 권한 없음

실시간 의사결정 프레임워크

커뮤니케이션 템플릿

상황실 상태 업데이트:

🟢 상태 점검 [10:30]

지표:
- 오류율: 0.03%(한도: 0.1%)
- 도입: 설정 47건(목표: 30)
- 지원: 티켓 3건(모두 해결)

차단 요소 없음. 다음 점검: 12:00.

에스컬레이션 메시지:

🟡 에스컬레이션 [11:15]

이슈: 오류율 0.8%, 상승 추세
영향: 사용자 약 50명 영향
원인: 데이터베이스 연결 풀링
조치: 엔지니어링 조사 중, 예상 소요 15분
필요한 결정: 아직 없음

다음 업데이트: 11:30 또는 변화가 있으면 즉시

롤백 공지:

🔴 롤백 시작 [11:45]

결정: 오류율 2% 초과로 롤백
상태: 진행 중
예상 소요: 15분

조치:
- @marketing: 모든 캠페인 일시 중지
- @support: 대기 응답 템플릿 발송
- @eng: 롤백 실행
- @pm: 임원 스폰서에게 알림

완료되면 확인하겠습니다.

출시 당일 이후 체크리스트

하루 종료:
□ 최종 지표 수집
□ 모든 인시던트 문서화
□ 지원 대기열 정리 또는 인수인계
□ 마케팅 캠페인 평가
□ 야간 모니터링 확인
□ 핵심 성과/이슈를 임원용으로 요약
□ 상황실 종료 또는 전환

2일 차 오전:
□ 야간 알림 리뷰
□ 지표 추세 평가
□ 지원량 확인
□ 소셜 감정 반응 리뷰
□ 빠른 성과 식별
□ 후속 조치 배정

안티패턴

• 런북 없음 - 진행하면서 즉석에서 만듦
• 상황실 없음 - 커뮤니케이션이 여러 채널로 흩어짐
• 너무 이른 게시 - 엔지니어링 확인 전에 마케팅이 먼저 나감
• 상태 점검 없음 - 누군가 불평할 때까지 정상이라고 가정
• 불명확한 롤백 권한 - 위기 중에 논쟁
• 제품 관리자 부재 - 선장이 자리를 비움
• 에스컬레이션 경로 없음 - 이슈가 곪음
• 출시하고 떠남 - 상황실을 오후 5시에 딱 닫음

---

title: 롤백 및 비상 계획 impact: CRITICAL tags: execution, rollback, contingency, risk

롤백 및 비상 계획

영향도: 매우 높음

희망은 전략이 아닙니다. 모든 출시는 문제가 생길 때를 대비한 명확한 롤백 계획과 비상 대응책이 필요합니다.

롤백 결정 매트릭스

롤백 유형

롤백 준비 체크리스트

## 출시 전 롤백 검증

□ 기능 플래그 설정 및 테스트 완료
□ 롤백 명령 문서화
□ 스테이징에서 롤백 테스트 완료
□ 데이터베이스 롤백 테스트 완료(해당되는 경우)
□ 온콜이 롤백 런북 검토
□ 롤백 트리거용 모니터링 알림 설정
□ 커뮤니케이션 템플릿 준비
□ 결정 권한 명확화

## 롤백 명령
기능 플래그: `./scripts/toggle-feature.sh sso-launch off`
검증: 플래그 상태는 [대시보드 링크]에서 확인

## 예상 롤백 시간
- 기능 플래그: 1분 미만
- 전체 반영: 5분 미만
- 검증: 10분

좋은 예: 깔끔한 롤백

## 롤백 인시던트 보고서: 워크플로 자동화

**타임라인:**
- 09:15 - 기능 출시, 모두 정상
- 09:45 - 오류율 상승(0.2% → 0.8%)
- 10:00 - 원인 식별: EU 데이터 센터 예외 사례
- 10:05 - 결정: 핫픽스 시도, 제한 시간 15분
- 10:20 - 핫픽스 준비 안 됨, 오류율 1.5%
- 10:22 - 제품 관리자: "롤백을 시작합니다"
- 10:23 - 엔지니어링 리드: "롤백 확인"
- 10:24 - 기능 플래그 비활성화
- 10:25 - 마케팅 캠페인 일시 중지
- 10:27 - 지원 팀에 알림, 미리 작성된 답변 활성화
- 10:30 - 오류율이 기준선으로 복귀
- 10:35 - 롤백 완료 검증
- 10:40 - 고객 커뮤니케이션 발송

**잘된 점:**
- 명확한 결정 기준(1.5% > 1% 임계값)
- 빠른 롤백 실행(5분 미만)
- 전 과정에서 좋은 커뮤니케이션
- 고객에게 보이는 중단 없음

**근본 원인:**
- EU 데이터 센터 시간대 처리 예외 사례
- 베타에서 커버되지 않음(EU 베타 사용자 없음)

**재출시 계획:**
- 수정 사항 스테이징 배포: 10/15
- EU 전용 베타: 10/16-10/18
- 재출시: 10/19

나쁜 예: 롤백 혼란

## 롤백 재난: 보고서 빌더

**발생한 일:**
- 09:00 - 출시
- 10:00 - 오류율 3%, 상승 중
- 10:15 - 지원: "롤백해야 하나요?"
- 10:20 - 제품 관리자 회의 중, 응답 없음
- 10:30 - 엔지니어링: "롤백할 수는 있는데 승인이 필요합니다"
- 10:45 - 오류율 7%
- 11:00 - 임원: "왜 Twitter가 화가 났나요?"
- 11:10 - 제품 관리자: "누가 롤백 결정을 할 수 있나요?"
- 11:20 - 롤백 시도, 실패(테스트 안 됨)
- 11:45 - 마침내 롤백 성공
- 12:00 - 준비된 고객 커뮤니케이션 없음

**영향:**
- 2.5시간 동안 저하된 경험
- 화난 지원 티켓 47건
- 엔터프라이즈 고객 3곳이 임원에게 에스컬레이션
- 기술 언론 트윗 2개

**근본 원인:**
- 명확한 롤백 권한 없음
- 롤백을 테스트한 적 없음
- 미리 작성된 커뮤니케이션 없음
- 출시 중 제품 관리자 부재

비상 계획 매트릭스

비상 커뮤니케이션 템플릿

내부 롤백 공지:

🔴 롤백 완료

[기능] 출시는 [짧은 이유]로 롤백되었습니다.

발생한 일:
- [1-2문장 설명]

현재 조치:
- 엔지니어링이 근본 원인 조사 중
- 수정 평가 예상 시간: [시간]
- 재출시 목표: 수정 대기 중, 추후 결정

해야 할 일:
- 영업: [기능] 관련 연락 일시 중지
- 지원: 미리 작성된 답변 #rollback-[feature] 사용
- 마케팅: 캠페인 자동 일시 중지

다음 업데이트: [시간]

고객 커뮤니케이션(주요 이슈):

제목: [기능] 관련 업데이트 - 일시적 제공 중단

안녕하세요 [이름]님,

오늘 일찍 [기능]을 출시했습니다. 일부 사용자가
[짧은 이슈 설명]을 겪어, 문제를 바로잡는 동안 기능을
일시적으로 롤백했습니다.

고객님께 의미하는 바:
- [기능]은 일시적으로 사용할 수 없습니다
- 기존 데이터/설정은 영향을 받지 않습니다
- [기간] 내 재출시를 예상합니다

[기능]을 다시 사용할 수 있게 되면 알려드리겠습니다.
불편을 드려 죄송합니다.

[이름]
[직함]

점진적 롤백 전략

이슈가 감지되었지만 매우 심각하지 않은 경우:

1단계(즉시):
├── 신규 사용자 노출 일시 중지
└── 기존 사용자는 영향 없음

2단계(이슈 지속 시):
├── 사용자 50%로 축소
└── 30분 모니터링

3단계(개선 없을 시):
├── 사용자 10%로 축소
└── 30분 모니터링

4단계(여전히 문제일 시):
├── 전체 롤백
└── 근본 원인 분석

이점:
- 고객 중단 최소화
- 디버깅 기회 제공
- 일부 출시 추진력 유지

재출시 프로토콜

## 재출시 체크리스트: [기능]

### 재출시 일정 잡기 전
□ 근본 원인 식별 및 문서화
□ 수정 구현 및 코드 리뷰 완료
□ 스테이징 환경에서 수정 검증
□ 실패 시나리오에 대한 추가 테스트 케이스 추가
□ 롤백 다시 테스트

### 재출시 커뮤니케이션
□ 내부 팀에 새 날짜 알림
□ 고객 커뮤니케이션 초안 작성(필요 시)
□ 언론/애널리스트 업데이트(보도된 경우)
□ 영업 재활성화 및 업데이트 제공

### 재출시 실행
□ 동일 런북에 추가 모니터링 포함
□ 첫 24시간 동안 더 낮은 임계값 적용
□ 상황실 운영 시간 연장
□ 더 빠른 에스컬레이션 경로

안티패턴

• 롤백 계획 없음 - "필요하면 그때 알아보자"
• 테스트 안 된 롤백 - 필요할 때 실패하는 스크립트
• 불명확한 권한 - 위기 중 논쟁
• 기능 플래그 없음 - 롤백에 전체 배포가 필요
• 템플릿 없음 - 인시던트 중 커뮤니케이션 작성
• 낙관 편향 - "우리에게는 일어나지 않을 거야"
• 롤백 수치심 - 롤백을 전문성이 아니라 실패로 취급
• 재출시 계획 없음 - 롤백이 영구 중단이 됨

---

title: 출시 등급 전략 impact: CRITICAL tags: planning, tiers, strategy, prioritization

출시 등급 전략

영향도: 매우 높음

모든 출시가 키노트를 받을 필요는 없습니다. 등급화는 영향에 맞는 자원을 투입하게 해 줍니다.

네 가지 출시 등급

등급 결정 매트릭스

적절한 등급은 이 매트릭스로 판단합니다.

1등급: 대표 출시 체크리스트

□ 임원 스폰서 배정
□ 부서 간 출시 팀 구성
□ 12주 일정 수립
□ 보도/애널리스트 전략 정의
□ 이벤트 또는 주요 순간 식별
□ 전체 마케팅 캠페인 계획
□ 영업 지원 프로그램 설계
□ 고객 자문단 브리핑
□ 임원 정렬이 끝난 성공 지표
□ 출시 후 모니터링 계획

2등급: 주요 출시 체크리스트

□ 제품 마케팅 담당자 배정
□ 6주 일정 수립
□ 블로그 글 및 보조 콘텐츠
□ 관련 세그먼트 대상 이메일 캠페인
□ 소셜 미디어 캠페인
□ 영업용 1페이지 요약 및 대화 포인트
□ 지원 문서 업데이트
□ 앱 내 공지 계획
□ 성공 지표 정의

좋은 예: 적절한 등급화

## 출시 브리프: 엔터프라이즈 SSO

**제안 등급: 2(주요)**

**근거:**
- 매출: 엔터프라이즈 세그먼트에서 $500K 파이프라인 가능
- 사용자 영향: 엔터프라이즈 잠재고객이 가장 많이 요청한 기능
- 경쟁 영향: 시장 선도 제품과 동등성 확보
- 전략성: 엔터프라이즈 확장 전략의 핵심

**승인된 자원:**
- 6주 일정
- 전담 PMM 담당자
- 블로그 + 이메일 + 소셜 캠페인
- 영업 지원 세션
- 업데이트된 보안 백서
- 지원 팀 교육

나쁜 예: 과도하게 높은 등급

## 출시 브리프: 대시보드 다크 모드

**제안 등급: 1(대표)**  ← 잘못됨

**근거:**
- "사용자들이 수년간 요청했음"
- "정말 멋져 보임"
- "크게 알려야 함"

**실패하는 이유:**
- 다크 모드는 3등급 또는 4등급 기능
- 매출 영향이 매우 작음
- 경쟁 차별화가 없음
- 자원을 낭비하고 팀을 소진시킴
- 실제 1등급 출시의 영향력을 희석함

좋은 예: 낮게 잡은 등급을 재인식

## 출시 리뷰: API v2.0

**초기 등급: 3(표준)**
**수정 등급: 2(주요)**

**상향 이유:**
- 엔터프라이즈 파이프라인의 40%가 API 제한으로 막혀 있음을 발견
- 경쟁 분석상 차별화 역량으로 확인
- 개발자 커뮤니티 참여 기회
- 플랫폼 생태계 활성화

**추가 자원:**
- 개발자 대상 블로그 시리즈
- API 문서 개편
- 개발자 커뮤니티 이벤트
- 통합 파트너 연락

등급 상향/하향 트리거

다음 경우 등급을 올립니다.

• 임원 가시성이 높아짐
• 경쟁 환경이 바뀜
• 고객 수요가 예상보다 큼
• 전략 우선순위가 바뀜
• 파트너/언론 관심이 생김

다음 경우 등급을 낮춥니다.

• 범위가 크게 줄어듦
• 일정이 압축됨
• 자원이 제한됨
• 시장 기회를 놓침
• 기능이 기본 요구사항이 됨

안티패턴

• 모든 것이 1등급 - 출시 피로가 영향력을 무너뜨리고 팀을 소진시킴
• 등급 체계 없음 - 출시마다 바퀴를 다시 만듦
• 정치로 정하는 등급 - 임원 관심 과제가 과도한 자원을 받음
• 고정 등급 - 상황 변화에 맞춘 조정을 거부함
• 기준 없는 등급 - 구조화된 결정 대신 직감에 의존함
• 너무 늦은 등급화 - 작업 시작 후에야 자원을 결정함

---

title: 출시 성공 기준 impact: CRITICAL tags: planning, metrics, success, measurement

출시 성공 기준

영향도: 매우 높음

성공 기준은 출시 후가 아니라 출시 전에 정의합니다. 결과를 본 뒤 정하는 성공 기준은 측정이 아니라 합리화입니다.

성공 기준 프레임워크

모든 출시는 네 가지 차원의 지표가 필요합니다.

등급별 도입 지표

품질 지표(모든 등급)

오류율:            요청의 0.1% 미만
지연 시간:         p95 200ms 미만(또는 회귀 없음)
가용성:            99.9% 가동 시간
인시던트:          첫 48시간 동안 P0/P1 0건
롤백:              필요한 롤백 0건

좋은 예: 포괄적인 성공 기준

## 성공 기준: 엔터프라이즈 SSO 출시

### 도입(제품 담당)
| 지표 | 목표 | 측정 |
|--------|--------|-------------|
| SSO를 활성화한 엔터프라이즈 계정 | 30일 내 25% | 제품 분석 |
| SSO 설정까지 걸리는 시간 | 30분 미만 | 계측 |
| 설정 후 SSO 로그인율 | 90% 초과 | 인증 로그 |

### 품질(엔지니어링 담당)
| 지표 | 목표 | 측정 |
|--------|--------|-------------|
| SSO 인증 지연 시간 | p95 500ms 미만 | APM |
| 인증 오류율 | 0.01% 미만 | 오류 추적 |
| 가용성 | 99.99% | 가동 시간 모니터링 |

### 비즈니스(영업/제품 담당)
| 지표 | 목표 | 측정 |
|--------|--------|-------------|
| 영향을 준 파이프라인 | 90일 내 $500K | CRM 어트리뷰션 |
| 엔터프라이즈 성사율 | +5% 개선 | 영업 분석 |
| 경쟁 승률 | SSO 이의 제기 대비 +10% | 승패 분석 |

### 감정 반응(제품/지원 담당)
| 지표 | 목표 | 측정 |
|--------|--------|-------------|
| 설정 NPS | 50 초과 | 설정 후 설문 |
| 지원 티켓 | 활성화 건의 10% 미만 | Zendesk |
| 관리자 피드백 | 정성적으로 긍정 | 고객 통화 |

나쁜 예: 모호한 성공 기준

## 성공 기준: 새 대시보드

- 사용자가 좋아해야 함
- 빨라야 함
- 도입이 많으면 좋음
- 고객 피드백이 좋아야 함

**실패하는 이유:**
- 구체적인 숫자가 없음
- 측정 일정이 없음
- 담당자가 배정되지 않음
- 측정 방법이 정의되지 않음
- "많음"과 "좋음"은 지표가 아님

SMART 기준 테스트

모든 지표는 SMART를 통과해야 합니다.

기준선 요구사항

목표를 정하기 전에 기준선을 세웁니다.

현재 상태 분석:
┌─────────────────────────────────────────┐
│ 비교 가능한 기능 출시(6개월 전)           │
│ - 1일 차 도입: 2%                         │
│ - 1주 차 활성화: 8%                       │
│ - 1개월 차 유지: 18%                      │
│                                          │
│ 이번 출시 목표:                           │
│ - 1일 차 도입: 3% (+50%)                  │
│ - 1주 차 활성화: 10% (+25%)               │
│ - 1개월 차 유지: 25% (+38%)               │
└─────────────────────────────────────────┘

성공 기준 승인

출시 후 성공 리뷰 템플릿

## 출시 성공 리뷰: [기능 이름]

**출시일:** [날짜]
**리뷰일:** [날짜]

### 도입 결과
| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|
| [지표] | [목표] | [실제] | [달성/미달] |

### 품질 결과
| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|

### 비즈니스 결과
| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|

### 감정 반응 결과
| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|

### 전체 평가: [성공 / 부분 성공 / 미달]

### 핵심 학습:
1. [학습]
2. [학습]

### 후속 조치:
1. [조치] - 담당: [이름] - 기한: [날짜]

안티패턴

• 출시 후 지표 설정 - 결과를 본 뒤 성공의 의미를 정함
• 허영 지표만 사용 - 활성화 없는 페이지 조회수
• 기준선 없음 - 참고 기준 없는 목표
• 골대 옮기기 - 목표를 놓치자 목표 자체를 바꿈
• 단일 차원 - 도입만 보고 품질은 보지 않음
• 담당자 없음 - 책임자 없는 지표
• 측정 불가능한 목표 - "고객 만족도 개선"

---

title: 출시 일정 계획 impact: HIGH tags: planning, timeline, milestones, scheduling

출시 일정 계획

영향도: 높음

좋은 출시는 출시일에서 거꾸로 계획합니다. 잘 짜인 일정은 막판 혼란을 막고 모든 팀이 준비되게 합니다.

등급별 일정 템플릿

1등급: 대표 출시(12주)

12주 전: 킥오프
├── 출시 브리프 초안 작성
├── 이해관계자 정렬 회의
├── 임원 스폰서가 등급 확정
└── 핵심 팀 식별

10주 전: 전략
├── 메시징 프레임워크 완료
├── 경쟁 포지셔닝 정의
├── 보도/애널리스트 전략 확정
└── 이벤트/주요 순간 식별

8주 전: 베타 시작
├── 알파 완료, 비공개 베타 시작
├── 영업 지원 콘텐츠 초안 작성
├── PR 연락 시작
└── 성공 기준 확정

6주 전: 콘텐츠 개발
├── 모든 마케팅 콘텐츠 리뷰 중
├── 지원 문서 초안 작성
├── 데모 환경 준비
└── 베타 피드백 반영

4주 전: 내부 지원
├── 영업 교육 완료
├── 지원 교육 완료
├── CS 플레이북 준비
├── 최종 콘텐츠 승인
└── 진행/중단 체크포인트 #1

2주 전: 최종 준비
├── 모든 시스템 테스트 완료
├── 모니터링 설정
├── 런북 검토
├── 커뮤니케이션 예약
└── 상황실 설정
└── 진행/중단 체크포인트 #2

1주 전: 집중 관리 준비
├── 프로덕션 최종 배포
├── 온콜 일정 확정
├── 롤백 테스트 완료
└── 최종 점검

출시일

1주 후: 집중 관리
├── 일일 모니터링
├── 이슈 신속 대응
└── 빠른 성과 식별

2주 후: 회고
├── 성공 기준 리뷰
├── 출시 회고
└── 학습 기록

2등급: 주요 출시(6주)

6주 전: 킥오프 + 전략
├── 출시 브리프 승인
├── 메시징 완료
└── 팀 정렬

4주 전: 콘텐츠 + 베타
├── 베타 프로그램 진행 중
├── 콘텐츠 개발
├── 내부 지원 초안
└── 진행/중단 체크포인트

2주 전: 내부 지원 + 준비
├── 모든 교육 완료
├── 콘텐츠 승인
├── 시스템 테스트 완료
└── 최종 진행/중단 결정

1주 전: 최종 준비
├── 배포 준비 완료
├── 상황실 설정
└── 런북 검토

출시일

1주 후: 모니터링 + 회고
├── 모니터링
└── 회고

3등급: 표준 출시(3주)

3주 전: 계획
├── 출시 브리프
├── 콘텐츠 담당 배정
└── 성공 기준

2주 전: 개발
├── 콘텐츠 완료
├── 문서 준비
└── 진행/중단 결정

1주 전: 준비
├── 최종 리뷰
└── 배포 예약

출시일

1주 후: 모니터링
└── 빠른 점검

마일스톤 의존성

의존성 지도
══════════════

기능 완료
        │
        ├──► 베타 시작 가능
        │           │
        │           └──► 베타 피드백
        │                     │
        │                     └──► 최종 기능 조정
        │
        ├──► 문서 초안 작성
        │           │
        │           └──► 지원 교육
        │
        ├──► 데모 환경
        │           │
        │           └──► 영업 지원
        │
        └──► API 확정
                    │
                    └──► 파트너 통합


메시징 승인
        │
        ├──► 콘텐츠 제작
        │           │
        │           └──► 콘텐츠 리뷰
        │                     │
        │                     └──► 콘텐츠 게시
        │
        └──► PR 연락
                    │
                    └──► 언론 보도

좋은 예: 잘 계획된 일정

## 출시 일정: 엔터프라이즈 SSO

### 1단계: 기반 구축(8주 전부터 6주 전)
| 날짜 | 마일스톤 | 담당 | 의존성 |
|------|-----------|-------|--------------|
| 8월 15일 | 출시 브리프 승인 | Sarah | 없음 |
| 8월 17일 | 2등급 확정 | Sarah | 출시 브리프 |
| 8월 19일 | 핵심 팀 킥오프 | Sarah | 등급 결정 |
| 8월 22일 | 메시징 프레임워크 v1 | Mike | 출시 브리프 |
| 8월 26일 | 베타 코호트 선정 | Sarah | 기능 안정화 |
| 8월 29일 | 성공 기준 확정 | Sarah | 이해관계자 의견 |

### 2단계: 개발(5주 전부터 3주 전)
| 날짜 | 마일스톤 | 담당 | 의존성 |
|------|-----------|-------|--------------|
| 9월 1일 | 비공개 베타 시작 | Sarah | 베타 코호트, 기능 |
| 9월 5일 | 영업용 1페이지 요약 초안 | Mike | 메시징 |
| 9월 8일 | 지원 문서 초안 | Lisa | 기능 명세 |
| 9월 12일 | 데모 환경 준비 | Priya | 기능 안정화 |
| 9월 15일 | 메시징 승인 | Mike | 임원 리뷰 |
| 9월 19일 | 진행/중단 #1 | Sarah | 여러 항목 |

### 3단계: 내부 지원(2주 전부터 1주 전)
| 날짜 | 마일스톤 | 담당 | 의존성 |
|------|-----------|-------|--------------|
| 9월 22일 | 영업 교육 | Mike | 데모 환경, 자료 |
| 9월 24일 | 지원 교육 | Lisa | 문서, 데모 환경 |
| 9월 26일 | 모든 콘텐츠 승인 | Mike | 리뷰 완료 |
| 9월 28일 | CS 플레이북 준비 | CS 리드 | 교육 완료 |
| 9월 29일 | 모니터링 설정 | Priya | 기능 배포 |
| 9월 30일 | 진행/중단 #2 | Sarah | 모든 준비 완료 |

### 4단계: 출시(0주)
| 날짜 | 마일스톤 | 담당 | 의존성 |
|------|-----------|-------|--------------|
| 10월 1일 | 상황실 설정 | Sarah | 진행 승인 |
| 10월 2일 | 최종 배포 | Priya | 모든 항목 정상 |
| 10월 3일 | 출시일 | Sarah | 모든 준비 완료 |

### 5단계: 출시 후(1주 후부터 2주 후)
| 날짜 | 마일스톤 | 담당 | 의존성 |
|------|-----------|-------|--------------|
| 10월 3-6일 | 집중 관리 모니터링 | Sarah/Priya | 출시 |
| 10월 10일 | 안정화 점검 | Sarah | 집중 관리 종료 |
| 10월 17일 | 출시 회고 | Sarah | 지표 확보 |

나쁜 예: 비현실적인 일정

## 출시 일정: API v2(하지 말아야 할 방식)

2주 전:
- 출시하기로 결정
- 모든 작업을 동시에 시작

1주 전:
- 기능이 아직 개발 중
- 마케팅이 "무엇을 출시하나요?"라고 물음
- 영업은 Slack에서 소식을 접함
- 지원: "문서는 어디 있나요?"

0주:
- 출시 당일 아침 배포
- 마케팅이 급히 블로그 게시
- "정시" 출시

1주 후:
- 지원팀 과부하
- 영업이 질문에 답하지 못함
- 심각한 버그 3건 발견
- "왜 더 잘 계획하지 않았지?"

**잘못된 점:**
- 2등급 출시에 2주만 배정함(필요한 기간은 6주)
- 병렬 작업 흐름이 없음
- 체크포인트가 없음
- 의존성 지도가 없음
- 내부 지원 전에 기능이 완료되지 않음

진행/중단 체크포인트

체크포인트 1(2등급 기준 T-4주):

□ 기능 개발이 계획대로 진행 중
□ 베타 피드백이 긍정적
□ 메시징 승인
□ 주요 차단 요소 없음

결정: 계속 진행 / 지연 / 범위 축소

체크포인트 2(T-1주):

□ 기능 완료 및 테스트 완료
□ 모든 콘텐츠 승인 및 예약
□ 모든 내부 지원 완료
□ 모니터링 설정
□ 롤백 계획 준비
□ 온콜 일정 배정

결정: 진행 / 중단

일정 위험 관리

완충 시간 가이드라인

일정 커뮤니케이션

주간 상태 업데이트 템플릿:

## 출시 상태: [기능] - [날짜] 주

**전체 상태:** 🟢 계획대로 진행 / 🟡 위험 있음 / 🔴 차단됨

**이번 주:**
- [완료된 마일스톤]
- [완료된 마일스톤]

**다음 주:**
- [예정된 마일스톤]
- [예정된 마일스톤]

**위험/차단 요소:**
- [위험] - 완화책: [조치]

**필요한 결정:**
- [결정] - 결정자: [사람] - 기한: [날짜]

안티패턴

• 일정 없음 - "준비되면 출시하자"
• 비현실적 압축 - 1등급 출시를 2주 만에 진행
• 순차 계획 - 병렬 작업 흐름을 시작하지 않음
• 체크포인트 없음 - 출시 시점에 전부 아니면 전무
• 완충 없음 - 매일을 꽉 채워 예약
• 기능만 우선 - 코드가 끝난 뒤에야 마케팅 시작
• 의존성 없음 - 데모가 준비되기 전에 영업 활성화
• 날짜 고정, 범위 가변 - 날짜만 중요하고 품질은 중요하지 않음

---

title: 출시 후 모니터링 impact: HIGH tags: postlaunch, monitoring, metrics, operations

출시 후 모니터링

영향도: 높음

출시는 배포했다고 끝나지 않습니다. 체계적인 모니터링은 이슈를 조기에 잡고 성공을 검증합니다.

모니터링 단계

집중 관리 대시보드

출시 후 집중 관리 대시보드
═══════════════════════════════

시스템 상태
├── 오류율:        0.03% [✓] (임계값: 0.1%)
├── p95 지연 시간: 145ms [✓] (임계값: 200ms)
├── 가용성:        100%  [✓] (임계값: 99.9%)
└── 대기열 깊이:   12    [✓] (임계값: 1000)

도입(T+24시간)
├── 기능 조회:     2,847
├── 기능 사용:     1,203 (활성화 42%)
├── 고유 사용자:   891
└── 목표:          500   [✓] 초과 달성

품질
├── P0 인시던트:   0     [✓]
├── P1 인시던트:   0     [✓]
├── 버그 보고:     7     [!] (2건 조사 중)
└── 롤백:          0     [✓]

지원
├── 티켓(기능):          23
├── 평균 응답 시간:      12분 [✓]
├── 에스컬레이션:        1
└── CSAT:                4.2/5 [✓]

감정 반응
├── 소셜 언급:           47
├── 긍정:               38 (81%)
├── 중립:               7  (15%)
└── 부정:               2  (4%)

알림 설정

좋은 예: 효과적인 모니터링

## 출시 후 모니터링 보고서: 엔터프라이즈 SSO
### 3일 차 요약

**임원 요약:**
SSO 출시가 기대 이상으로 진행 중입니다. 심각한 이슈는 없습니다.
도입은 목표보다 40% 앞서 있습니다. 안정화 단계로 전환을 권장합니다.

**시스템 상태:**
| 지표 | 1일 차 | 2일 차 | 3일 차 | 목표 |
|--------|-------|-------|-------|--------|
| 오류율 | 0.05% | 0.03% | 0.02% | 0.1% 미만 |
| 지연 시간 | 180ms | 165ms | 155ms | 200ms 미만 |
| 가동 시간 | 100% | 100% | 100% | 99.9% |

**도입 지표:**
| 지표 | 1일 차 | 2일 차 | 3일 차 | 목표 |
|--------|-------|-------|-------|--------|
| SSO 설정 | 89 | 67 | 54 | 하루 50건 |
| 활성 SSO 사용자 | 2,340 | 4,120 | 5,890 | 3,000 |
| 설정 성공률 | 94% | 96% | 97% | 90% 초과 |

**식별된 이슈:**
1. 경미: Azure AD 설정 마법사가 혼란스러움(티켓 12건)
   - 조치: 다음 스프린트에 UX 개선 예약
   - 우회 방법: 문서 업데이트

2. 예외 사례: 사용자 500명 초과 조직의 SCIM 동기화 지연
   - 조치: 엔지니어링 조사 중
   - 영향: 고객 3곳, 모두 연락 완료

**지원 분석:**
- 총 티켓: 47건(예상 약 60건)
- 가장 흔한 항목: "어떻게 설정하나요?"(18건) - 문서 링크로 해결
- 주요 이슈: Azure AD 혼란(12건) - 위 조치 항목 참고

**권장:** 집중 관리 종료, 안정화 단계 진입

나쁜 예: 모니터링 없음

## 발생한 일: Reporting 2.0 출시

**1주 차:**
- 제품 관리자: "출시가 아주 잘됐어요!"
- 대시보드 없음, 추적 없음

**2주 차:**
- 지원: "보고서 관련 티켓이 많이 들어오고 있어요"
- 제품 관리자: "몇 건인가요?"
- 지원: "모르겠어요, 많아요"

**3주 차:**
- 임원: "고객 X가 보고서가 깨졌다고 합니다"
- 제품 관리자: "처음 듣는 이야기입니다"
- 발견: 2주 동안 오류율 15%
- 발견: 기능 관련 지원 티켓 340건
- 발견: 엔터프라이즈 고객 3곳이 이탈 고려

**근본 원인:**
- 오류 모니터링 설정 없음
- 기능별 대시보드 없음
- 지원 티켓 분류 없음
- 정기 리뷰 주기 없음

역할별 모니터링 체크리스트

엔지니어링:

매일(집중 관리):
□ 오류율 추세 리뷰
□ 지연 시간 백분위 확인
□ P0/P1 인시던트 없음 검증
□ 버그 보고 리뷰
□ 인프라 용량 확인

매주(안정화):
□ 성능 추세 분석
□ 예외 사례 식별
□ 기술 부채 평가
□ 확장 예측

제품:

매일(집중 관리):
□ 도입 지표 리뷰
□ 지원 추세 확인
□ 버그 보고 분류
□ 고객 피드백 리뷰

매주(안정화):
□ 도입 퍼널 분석
□ 성공 기준 평가
□ 기능 반복 계획
□ 이해관계자 업데이트

마케팅:

매일(집중 관리):
□ 소셜 감정 반응 모니터링
□ 언론 보도 추적
□ 캠페인 성과

매주(안정화):
□ 콘텐츠 성과 분석
□ 리드 어트리뷰션 리뷰
□ 캠페인 최적화

성공 기준 추적

## 성공 기준 대시보드: SSO 출시

### 도입(목표: 4주 차)
| 지표 | 목표 | 1주 차 | 2주 차 | 3주 차 | 4주 차 |
|--------|--------|--------|--------|--------|--------|
| 설정 | 200 | 210 ✓ | 285 ✓ | 340 ✓ | 390 ✓ |
| 활성 | 5,000 | 3,800 | 6,200 ✓ | 8,100 ✓ | 9,500 ✓ |
| 활성화 % | 30% | 25% | 32% ✓ | 35% ✓ | 38% ✓ |

### 품질(목표: 지속)
| 지표 | 목표 | 1주 차 | 2주 차 | 3주 차 | 4주 차 |
|--------|--------|--------|--------|--------|--------|
| 오류율 | 0.1% 미만 | 0.03% ✓ | 0.02% ✓ | 0.02% ✓ | 0.01% ✓ |
| P0 인시던트 | 0 | 0 ✓ | 0 ✓ | 0 ✓ | 0 ✓ |
| 설정 NPS | 50 초과 | 52 ✓ | 58 ✓ | 61 ✓ | 64 ✓ |

### 비즈니스(목표: 분기)
| 지표 | 목표 | 1개월 차 | 2개월 차 | 3개월 차 |
|--------|--------|---------|---------|---------|
| 파이프라인 | $500K | $180K | $380K | $620K ✓ |
| 성사 거래 | 5 | 2 | 4 | 7 ✓ |

**전체 상태: 성공 궤도**

에스컬레이션 트리거

전환 기준

집중 관리 → 안정화:

□ 48시간 동안 P0/P1 인시던트 0건
□ 48시간 동안 오류율이 임계값 미만
□ 지원량 감소 추세
□ 미해결 심각 버그 없음

안정화 → 정상 운영:

□ 2주 동안 인시던트 없음
□ 지원량이 정상 수준
□ 도입이 목표를 따라감
□ 모든 출시 버그가 해결되었거나 일정에 반영됨

안티패턴

• 모니터링 없음 - 누군가 불평할 때까지 작동한다고 가정
• 허영 대시보드 - 활성화가 아니라 페이지 조회수만 추적
• 알림 피로 - 알림이 너무 많아 실제 이슈를 무시
• 임계값 없음 - 목표 없이 숫자만 봄
• 제품 관리자 부재 - 엔지니어링만 모니터링
• 스냅샷만 확인 - 추세를 보지 않고 한 번만 확인
• 지원 통합 없음 - 티켓이 기능과 연결되지 않음
• 너무 짧은 집중 관리 - 24시간 후 모니터링 종료

---

title: 출시 회고 impact: HIGH tags: postlaunch, retrospective, learning, improvement

출시 회고

영향도: 높음

모든 출시는 학습 기회입니다. 구조화된 회고는 경험을 조직 지식으로 바꿉니다.

회고 일정

회고 프레임워크

4L 회고
════════════════════

┌─────────────────┬─────────────────┐
│    좋았던 점     │     배운 점      │
│                 │                 │
│  잘되어서        │  새로 얻은       │
│  반복해야 할 것  │  통찰과 지식     │
│                 │                 │
├─────────────────┼─────────────────┤
│   부족했던 점    │    바랐던 점     │
│                 │                 │
│  빠졌거나        │  다르게 했으면   │
│  충분하지        │  좋았을 것       │
│  않았던 것       │                 │
│                 │                 │
└─────────────────┴─────────────────┘

회고 진행 안건 템플릿

## 출시 회고: [기능 이름]

**날짜:** [날짜]
**진행자:** [이름]
**참석자:** [목록]

### 안건(60-90분)

1. **맥락 설정** (5분)
   - 출시 목표 요약
   - 성공 기준 요약
   - 핵심 지표 요약

2. **성공 기준 리뷰** (10분)
   - 목표를 달성했는가?
   - 숫자가 무엇을 말하는가?

3. **일정 리뷰** (10분)
   - 주요 마일스톤 점검
   - 어디에서 앞서거나 뒤처졌는가?

4. **4L 활동** (25분)
   - 5분 조용히 브레인스토밍
   - 20분 그룹 논의

5. **조치 항목** (15분)
   - 다음에는 무엇을 다르게 할 것인가?
   - 각 조치의 담당자는 누구인가?

6. **감사 인사** (5분)
   - 기여 인정

좋은 예: 포괄적인 회고

## 출시 회고: 엔터프라이즈 SSO

**날짜:** 2024년 10월 28일
**진행자:** Sarah Chen(제품 관리자)
**참석자:** Mike(제품 마케팅), Priya(엔지니어링), Tom(영업), Lisa(지원)

### 성공 기준 결과

| 지표 | 목표 | 실제 | 상태 |
|--------|--------|--------|--------|
| SSO 설정(30일) | 200 | 390 | 초과 달성 |
| 활성 SSO 사용자 | 5,000 | 9,500 | 초과 달성 |
| 오류율 | 0.1% 미만 | 0.02% | 달성 |
| 설정 NPS | 50 초과 | 64 | 초과 달성 |
| 영향을 준 파이프라인 | $500K | $620K | 초과 달성 |

**전체: 성공적인 출시**

### 좋았던 점

1. **부서 간 조율**
   - 주간 동기화가 모두를 정렬 상태로 유지
   - Slack 채널이 실시간 업데이트에 매우 유용
   - "제가 참여한 출시 중 가장 잘 조율된 출시였습니다" - Tom

2. **베타 프로그램**
   - 정식 출시(GA) 전에 Azure AD 이슈를 잡음
   - 출시일에 사용할 고객 인용 준비 완료
   - 내부 챔피언 생성

3. **내부 지원 자료**
   - 영업용 1페이지 요약이 "실제로 유용했음"(Tom의 말)
   - 지원 문제 해결 가이드가 에스컬레이션을 막음
   - 지원 티켓의 90%가 기존 문서로 해결됨

4. **출시 당일 실행**
   - 상황실이 매끄럽게 작동
   - 배포 이슈 없음
   - 마케팅 타이밍이 완벽했음

### 배운 점

1. **베타 코호트 다양성이 중요함**
   - Azure AD 예외 사례를 거의 놓칠 뻔함
   - 지역 + IdP 다양성을 보장해야 함

2. **영업 지원 타이밍**
   - 출시 2주 전이 적절했음
   - 너무 이르면 잊고, 너무 늦으면 준비가 안 됨

3. **앱 내 메시징 영향**
   - 앱 내 알림이 설정의 40%를 유도
   - 이메일(25%)이나 블로그(15%)보다 높았음

4. **엔터프라이즈 영업 주기**
   - 기능 공지 → 성사까지 45-60일 소요
   - 30일이 아니라 90일 파이프라인 목표를 설정해야 함

### 부족했던 점

1. **해외 준비도**
   - 출시 시 GDPR 전용 문서가 없음
   - EU 고객이 답할 수 없는 질문을 함

2. **파트너 지원**
   - Okta 파트너십 팀이 블로그 글로 알게 됨
   - 통합 파트너에게 미리 브리핑했어야 함

3. **영상 콘텐츠**
   - 설정 안내 영상 요청이 여러 번 있었음
   - 시각 학습자에게 마찰을 줌

4. **고객 성공 플레이북**
   - 고객 성공 팀이 갱신에서 SSO를 어떻게 포지셔닝할지 확신하지 못함
   - 출시 후 작성됨, 미리 준비됐어야 함

### 바랐던 점

1. **더 이른 임원 정렬**
   - 등급 결정을 2주 동안 논쟁함
   - 킥오프 때 확정했어야 함

2. **엔터프라이즈 기능에는 더 긴 베타**
   - 4주는 엔터프라이즈 IT 팀에 촉박하게 느껴졌음
   - 엔터프라이즈 중심 기능은 6-8주

3. **미리 작성된 FAQ 확장**
   - 첫 주 지원이 사후 대응적이었음
   - 더 많은 예외 사례 질문을 예상했어야 함

4. **경쟁 대응 계획**
   - 경쟁사가 2주 뒤 비슷한 기능을 출시
   - 포지셔닝에서 허를 찔림

### 조치 항목

| 조치 | 담당 | 기한 | 우선순위 |
|--------|-------|----------|----------|
| 출시 체크리스트에 GDPR 문서 추가 | Lisa | 11월 5일 | 높음 |
| 파트너 브리핑 템플릿 작성 | Mike | 11월 10일 | 높음 |
| 내부 지원 체크리스트에 영상 추가 | Mike | 11월 10일 | 중간 |
| 1-2등급에는 고객 성공 플레이북 필수 | Sarah | 11월 15일 | 높음 |
| 엔터프라이즈 베타 표준을 6주로 연장 | Sarah | 다음 출시 | 중간 |
| 출시 브리프에 경쟁 대응 추가 | Mike | 다음 출시 | 중간 |

### 감사 인사

- **Priya:** 완벽한 배포, 인시던트 0건
- **Tom:** 첫 SSO 거래를 3주 만에 성사
- **Lisa:** 출시 중 지원 NPS 역대 최고
- **Mike:** 블로그 글로 언론 보도 3건 확보
- **모두:** 2024년 최고의 부서 간 협업

나쁜 예: 피상적인 회고

## 회고: Widget 2.0

**날짜:** 금요일 오후 5시(30분 예정, 실제 15분)
**참석자:** 제품 관리자, 엔지니어 1명

### 발생한 일:
- 출시함
- 버그가 조금 있었음
- 고객이 불만을 제기함

### 배운 점:
- 더 많이 테스트하기
- 더 잘 커뮤니케이션하기

### 조치 항목:
- 배정 없음

**실패한 이유:**
- 급한 일정(금요일 오후 5시)
- 핵심 이해관계자 누락
- 지표 리뷰 없음
- 모호한 통찰("더 잘 커뮤니케이션하기")
- 조치의 소유권 없음
- 같은 실수를 반복할 것임

회고 진행 팁

전:

□ 2주 이상 전에 일정 예약(캘린더가 빨리 찹니다)
□ 사전 과제 발송: 지표 요약, 일정, 4L 템플릿
□ 넘칠 경우를 대비해 이후 30분 완충 시간 확보
□ 모든 핵심 역할 참석 가능 여부 확인
□ 지표 대시보드 준비

중:

□ 지표로 시작(대화를 데이터에 고정)
□ 조용한 브레인스토밍 사용(집단사고 방지)
□ 각 섹션 시간 제한
□ 모든 내용 기록(노트 담당자 배정)
□ 조치 항목 + 담당자 + 날짜로 마무리
□ 항상 감사 인사 포함

후:

□ 24시간 내 노트 발송
□ 조치 항목을 프로젝트 트래커에 추가
□ 다음 팀 회의에서 조치 항목 후속 확인
□ 향후 참고를 위해 회고 보관

리뷰할 회고 지표

조직 지식 캡처

## 출시 플레이북 업데이트: SSO 출시에서 배운 점

### 표준 체크리스트에 추가:
□ GDPR 문서(EU 대상 기능)
□ 파트너 브리핑(통합 기능)
□ 설정 영상(복잡한 기능)
□ 고객 성공 플레이북(1-2등급 출시)

### 업데이트된 표준:
- 엔터프라이즈 기능 베타: 6-8주(기존 4주)
- 파트너 알림: T-2주(기존 T-1주)
- 경쟁 대응 계획: 1-2등급에 필수

### 업데이트된 템플릿:
- 출시 브리프: 경쟁 섹션 추가
- 내부 지원 체크리스트: 영상 요구사항 추가
- 지원 준비: FAQ 템플릿 확장

안티패턴

• 회고 생략 - "다음 일 때문에 너무 바빠요"
• 책임 전가 - 무엇이 아니라 누가 문제였는지에 집중
• 지표 없음 - 데이터 없는 의견
• 너무 빠름 - 결과가 측정 가능해지기 전
• 너무 늦음 - 세부사항을 잊은 뒤
• 조치 없음 - 후속 실행 없는 인사이트
• 같은 실수 - 과거 회고를 참고하지 않음
• 이해관계자 누락 - 제품 관리자만 참석
• 성급한 시간 배정 - 금요일 오후 5시, 모두가 집중을 잃은 상태