점진적 출시 계획
PRD에서 신호를 추론하고, 출시 경로를 분류하며, 링을 매핑하고, R3 코호트 계획을 수립하며, LaunchDarkly 설정 단계를 제공하는 Idira 점진적 출시 프레임워크를 따르는 구조화된 릴리스 계획을 생성합니다.
1단계 — PRD를 읽고 추론하기
PRD 전체를 읽으십시오. 내용에서 아래 모든 신호를 추론하십시오. 스스로 결정할 수 있는 사항에 대해 PM에게 묻지 마십시오.
| 신호 | 찾아야 할 내용 |
|---|---|
| NFI | "NFI" 레이블, "new feature", "not previously available", 이전 버전이 없는 순수 신규 기능 |
| 영향도 | 영향을 받는 사용자/테넌트 범위, "critical path" / "core workflow" 언어, 데이터 민감도, 데이터 손실 또는 서비스 중단 위험 |
| 롤백 복잡성 | 스키마 마이그레이션, 데이터 쓰기, 타사 종속성, 필요한 고객 커뮤니케이션, 되돌릴 수 없는 상태 → 조정(Coordinated) 또는 되돌릴 수 없음(Irreversible). 플래그 전환만 있음 → 쉬움(Easy). 전혀 언급되지 않은 경우 → 반드시 질문 |
| 지역 제약 | GDPR, FedRAMP, 데이터 상주, 지리별 요구사항, "[region]에서 시작", "[region]만", "[region] 우선", "[region]으로 제한" |
| 서비스 제약 | 기능이 의존하거나 수정하는 명명된 서비스, 통합 또는 구성 요소 |
| 초기 테스터 준비 | "QA 준비 완료", 스프린트 완료 날짜, 알파/베타 날짜 — 기능이 첫 번째 외부 노출에 충분히 안정적일 때 |
| 목표 GA | 확정된 출시일, OKR 마감일, 릴리스 마일스톤 |
읽은 후, 추론 결과를 제시하십시오. 열린 질문을 하지 마십시오. PRD에서 찾을 수 없는 신호는 ❓로 표시하고 마지막에 대상 질문을 하십시오:
PRD를 기반으로 이 릴리스를 다음과 같이 분석했습니다:
- NFI: [예 / 아니요 — 이유] 또는 ❓ PRD에서 명확하지 않음
- 영향도: [높음 / 중간 / 낮음 — 이유] 또는 ❓ PRD에서 명확하지 않음
- 롤백: [쉬움 / 조정 / 되돌릴 수 없음 — 이유] 또는 ❓ 언급되지 않음
- 지역 제약: [없음 / 목록 — 이유] 또는 ❓ 언급되지 않음
- 서비스 제약: [없음 / 목록 — 이유] 또는 ❓ 언급되지 않음
- 초기 테스터 준비: [날짜 — 이유] 또는 ❓ PRD에서 찾을 수 없음
- 목표 GA: [날짜 — 이유] 또는 ❓ PRD에서 찾을 수 없음
그런 다음 ❓ 질문만 정확히 이 형식으로 하십시오:
- 롤백이 언급되지 않은 경우 → "롤백 계획이 마련되어 있습니까? 옵션: (1) 쉬움 — 간단한 플래그 전환, 즉시 되돌림. (2) 조정 — 데이터 마이그레이션, 스크립트 또는 고객 커뮤니케이션 필요. (3) 아직 정의되지 않음 — 롤백 전략이 아직 설계되지 않음."
- 영향도가 명확하지 않은 경우 → "문제가 발생했을 때 고객 영향도를 어떻게 설명하시겠습니까? 높음(핵심 워크플로우 또는 많은 테넌트에 영향), 중간(특정 서비스 또는 하위 집합으로 제한), 낮음(미미한 영향 / 쉽게 되돌릴 수 있음)?"
- 초기 테스터 준비를 찾을 수 없는 경우 → "기능이 초기 테스터의 검증을 받을 준비가 되는 시점은 언제입니까?"
- 목표 GA를 찾을 수 없는 경우 → "목표 GA 날짜 또는 기간은 무엇입니까?"
- 지역이 언급되지 않은 경우 → "지역 제약이 있습니까? 예를 들어, 전 세계 확장 전에 특정 지역(EMEA, US, APAC)에서 시작합니까?"
어떤 값도 추정하지 마십시오. PRD에서 이미 확인한 신호에 대해 질문하지 마십시오.
2단계 — 출시 경로 분류
NFI = 예 → HIGH-TOUCH
또는 영향도 = 높음
또는 롤백 = 되돌릴 수 없음
영향도 = 중간 → STANDARD
또는 롤백 = 조정
그 외 모든 경우 → LIGHTWEIGHT
3단계 — 필수 링 매핑
| 경로 | 필수 링 | R&D 소유 | PM 소유 |
|---|---|---|---|
| LIGHTWEIGHT | R0 → R4 | R0 | R4 |
| STANDARD | R0 → R3 → R4 | R0 | R3, R4 |
| HIGH-TOUCH | R0 → R1 → R2 → R3 → R4 | R0, R1 | R2, R3, R4 |
- R0 내부 QA — 엔지니어링/QA 환경
- R1 Customer Zero / Dogfooding — 내부 팀
- R2 Customer One — 선정된 얼리 액세스 고객 (NFI 프로세스를 통해)
- R3 프로덕션 카나리 — 테스트 테넌트 → LaunchDarkly 플래그를 통한 라이브 코호트
- R4 일반 사용 가능 — 모든 적격 프로덕션 테넌트
4단계 — R3 코호트 계획 수립 (STANDARD 및 HIGH-TOUCH만 해당)
R3는 항상 테스트 테넌트로 시작합니다. 그런 다음 ARR별로 라이브 테넌트를 순서대로 정렬합니다:
| 웨이브 | 누적 % | 대상 |
|---|---|---|
| 0 | — | 테스트 테넌트 (고객이 구매한 샌드박스) |
| 1 | 5% | 최저 ARR, 소규모 테넌트 |
| 2 | 15% | 낮음~중간 ARR |
| 3 | 35% | 중간 ARR |
| 4 | 65% | 중간~높음 ARR |
| 5 | 100% | 나머지 모든 적격 테넌트 |
조정:
- 서비스 제약 → 웨이브별 서비스 필터 타겟팅 추가
- 지역 제약 → 초기 웨이브에 지역 필터 추가, 웨이브 4~5에서 제거
- 짧은 일정 → 웨이브 축소 (예: 5% → 35% → 100%)
- 높은 ARR 민감도 → 높은 ARR 테넌트를 웨이브 4로 유지하고 베이크 시간 연장
각 웨이브에 다음을 포함: %, 코호트 설명, go/no-go 게이트 (메트릭 + 베이크 시간), 소유자. go/no-go 게이트는 필수이며 절대 생략하지 마십시오. PRD에 성공 메트릭이 정의되어 있으면 사용하십시오. 그렇지 않으면 기본값을 적용하십시오: 로그인/기능 성공률 ≥99.5%, 오류율 델타 <0.1%, p99 지연 시간 회귀 <5%, 지원 티켓 급증 <테넌트 1,000개당 3개, 초기 웨이브의 경우 최소 베이크 시간 48시간, 높은 ARR 웨이브의 경우 1주일.
5단계 — 전체 릴리스 계획 출력
다음 템플릿을 사용하여 계획을 작성하십시오:
# 점진적 출시 계획 — [기능 이름]
**출시 경로:** [LIGHTWEIGHT / STANDARD / HIGH-TOUCH]
**가장 빠른 시작:** [날짜] | **목표 GA:** [날짜]
---
## 릴리스 분석
| 신호 | 값 | 근거 |
|--------|-------|-----------|
| NFI | 예/아니요 | [한 줄] |
| 영향도 | 높음/중간/낮음 | [한 줄] |
| 롤백 | 쉬움/조정/되돌릴 수 없음 | [한 줄] |
| 지역 제약 | 없음 / [목록] | [한 줄] |
| 서비스 제약 | 없음 / [목록] | [한 줄] |
---
## 필수 링
| 링 | 단계 | 소유자 | 진입 게이트 | 종료 게이트 |
|------|-------|-------|------------|-----------|
| R0 | 내부 QA | R&D | 메인에 병합 | QA 승인 |
| R1 | Dogfooding | R&D | R0 완료 | 내부 승인 *(HIGH-TOUCH만 해당)* |
| R2 | Customer One | PM | NFI 프로세스 완료 | 고객 피드백 검토 *(HIGH-TOUCH만 해당)* |
| R3 | 프로덕션 카나리 | PM | R2 완료 | 100% 웨이브 안정 |
| R4 | 일반 사용 가능 | PM | R3 100% 웨이브 완료 | PM go/no-go |
*(선택한 경로에 필요한 링만 포함)*
---
## R3 코호트 계획
**먼저:** 테스트 테넌트 — 라이브 테넌트 이전에 안전한 활성화 확인.
| 웨이브 | % | 대상 | 타겟팅 | Go/No-Go 게이트 |
|------|---|-----|-----------|---------------|
| 0 | — | 테스트 테넌트 | 외부 테스트 테넌트 | 48시간 동안 인시던트 없음 |
| 1 | 5% | 낮은 ARR | [기준] | [메트릭] [베이크 시간] 동안 안정 |
| 2 | 15% | 낮음~중간 ARR | [기준] | [메트릭] [베이크 시간] 동안 안정 |
| 3 | 35% | 중간 ARR | [기준] | [메트릭] [베이크 시간] 동안 안정 |
| 4 | 65% | 중간~높음 ARR | [기준] | [메트릭] [베이크 시간] 동안 안정 — 연장 |
| 5 | 100% | 모든 적격 대상 | 필터 제거 | [메트릭] [베이크 시간] 동안 안정 |
---
## LaunchDarkly 설정
**1. 기능 플래그 생성**
- 플래그 키: `[feature-name]-rollout` (소문자, 하이픈)
- 유형: Boolean
- 기본값 (꺼짐): 모든 환경에서 false
**2. 환경 구성**
- `internal-qa` → R0: R&D QA 팀에 대해 활성화
- `dogfooding` → R1: 내부 직원 테넌트에 대해 활성화 *(HIGH-TOUCH만 해당)*
- `early-access` → R2: 명명된 Customer One 테넌트에 대해 활성화 *(HIGH-TOUCH만 해당)*
- `production` → R3: 아래 타겟팅 규칙 적용
**3. 프로덕션 타겟팅 규칙 (R3 웨이브)**
웨이브 0 — 테스트 테넌트:
- 규칙: `tenant_type = "test"` → true 제공
웨이브 1 — 5%:
- 규칙: `tenant_type = "live" AND arr_tier = "low"` → 5% 롤아웃에 true 제공
웨이브 2 → 5: 롤아웃 비율을 증가시키고 웨이브별로 `arr_tier` 필터를 확장합니다.
웨이브 5(100%)에서 `arr_tier` 필터를 완전히 제거합니다.
서비스 제약이 적용되는 경우:
- 각 규칙에 `AND deployed_services CONTAINS "[service-name]"` 추가.
지역 제약이 적용되는 경우:
- 초기 웨이브에 `AND region IN ["[region]"]` 추가; 웨이브 4~5에서 제거.
**4. 웨이브 간 게이트**
- 베이크 기간 동안 오류율, 지연 시간(p99) 및 지원 티켓을 모니터링합니다.
- go/no-go 기준이 충족된 후에만 다음 웨이브로 확장합니다.
- 일시 중지 또는 롤백하려면: 프로덕션 플래그를 false로 설정 — 모든 테넌트가 즉시 되돌아갑니다.
**5. 단일 토글**
- R&D는 영향을 받는 모든 구성 요소에서 하나의 플래그 키를 구현해야 합니다.
- R3 시작 전에 모든 구성 요소가 동일한 플래그를 읽는지 R&D와 확인하십시오.
---
## 소유자 및 책임
- **R&D** — 플래그 구현, R0~R1 소유, 단일 토글 범위 검증
- **PM** — 고객 노출(R2~R4) 소유, 각 웨이브 게이트 서명, 코호트 계획 업데이트
- **Product Ops** — R3 시작 전에 필수 지침에 대한 계획 검토
## 미해결 질문 / 가정
- [R&D / BI와 확인했거나 아직 확인해야 할 사실 목록]
예시
완성된 코호트 테이블 및 LaunchDarkly 규칙이 포함된 작업 예제(NFI, 높은 영향도, 3개월 GA 목표)는 reference.md를 참조하십시오.