릴리스 프로세스 — 버전, 노트, SDK/스펙 마이그레이션, feature flags, 롤백

1. 왜 ChatGPT App의 릴리스 프로세스가 일반 배포보다 더 어려운가

이전 파트에서는 App의 품질과 안정성을 관찰하는 방법(로그, 메트릭, SLO)을 이야기했습니다. 이제 릴리스 프로세스 자체를 어떻게 구성하면 매 배포 때마다 이 메트릭이 무너지지 않게 할 수 있는지 살펴보겠습니다.

일반적인 웹 애플리케이션에서는 비교적 단순합니다. 백엔드와 프런트엔드의 새 버전을 배포하면 — 사용자가 페이지를 새로고침하고 새 버전을 사용하게 됩니다. 문제가 생기면 배포를 바로 롤백하는 일도 자주 가능합니다.

하지만 ChatGPT App의 스택은 더 까다롭습니다. 최소한 서로 다른 생명주기를 가진 네 가지 레이어가 있습니다:

• 매니페스트와 도구 스키마(MCP tools / OpenAPI);
• 인프라: Next.js 애플리케이션과 MCP/Agents/ACP 서버;
• 시스템 프롬프트(System prompt) 및 기타 프롬프트;
• 데이터: product feed, 설정, 구성.

문제는 모델이 자기만의 ‘인지적 세계’에 산다는 점입니다. 채팅 컨텍스트는 몇 시간, 며칠씩 이어질 수 있습니다. 매니페스트와 tools 설명은 OpenAI 쪽에서 로딩되고 캐시되며, 기존 대화 모두에 즉시 업데이트되지 않습니다. 만약 여러분이 도구의 시그니처를 바꾸었다면(예: input‑schema에서 필드를 삭제), 오래된 대화에서는 모델이 계속 예전 payload를 보낼 것이고, 새로운 백엔드는 그것을 거부할 것입니다. 결과적으로 400 오류, 이상한 채팅 응답, 매우 슬픈 사용자들이 생깁니다.

따라서 ChatGPT App의 ‘릴리스’는 단순히 ‘새 Docker를 배포’하는 일이 아닙니다. 여러 레이어를 조정해 변경하고, 버전과 기능 플래그를 세심하게 관리하며, 되돌릴 수 있는 상태를 유지하는 일입니다.

2. 버전 매트릭스: 무엇을 버저닝할 것인가

“App 버전 1.3”만 보지 말고, 레이어별 버전 매트릭스로 한꺼번에 보는 것이 좋습니다. GiftGenius 기준으로는 대략 다음과 같습니다.

giftgenius-app 1.4.2

tools-schema v1.7

prompt v3.1

feed v2, acp v1.3

이것들은 서로 다른 축입니다. 애플리케이션 1.4.2 버전을 릴리스해도, tools 스키마는 여전히 v1.7이고 prompt는 v3.2로 넘어갈 수 있습니다. 로그에 이 정보가 보이도록 하세요. 그래야 나중에 “왜 prompt v3.2 이후에 갑자기 체크아웃 전환율이 떨어졌지?”를 쉽게 추적할 수 있습니다.

코드에는 시맨틱 버저닝(SemVer) MAJOR.MINOR.PATCH를 쓰는 것이 편리합니다. MAJOR — 호환성 깨짐, MINOR — 호환성 유지한 기능 추가, PATCH — 버그 수정. 인터페이스 버전(schema, prompts)도 비슷한 논리로 MAJOR가 breaking change를 의미하도록 합니다.

특히 tools 인터페이스 버전을 따로 관리하세요. LLM에겐 매우 중요합니다. 도구의 컨트랙트를 바꾸었는데 모델이 ‘예전 컨트랙트’를 안다고 생각하면 난리가 납니다. 보통 정책은 이렇습니다: MINOR 릴리스에서는 새 선택(옵션) 필드만 추가하고 기존 필드는 이름 변경/삭제하지 않습니다. breaking change는 suggest_gifts_v2처럼 새 도구로만 내보냅니다.

이제 레이어들을 버전으로 나눴으니, 이 버전들이 dev부터 prod까지 릴리스 사이클에서 어떻게 ‘살아가는지’를 봅시다.

3. GiftGenius의 기본 릴리스 플로우

먼저 단계부터 합의합시다. 배포 모듈에서 이미 환경을 만들었겠지만, 이제 릴리스 관점으로 다시 봅니다.

보통 다음을 둡니다:

• dev — 로컬 개발, ChatGPT의 Dev Mode, 터널;
• staging — prod와 최대한 유사: 같은 유형의 DB, 같은 MCP/ACP 유형, 단 테스트 데이터와 결제는 sandbox;
• prod — 실운영 환경, 실제 ChatGPT App / Store 리스팅이 연결된 곳.

프로세스는 다음처럼 보일 수 있습니다:

flowchart TD
  A[Dev: feature/* 브랜치] --> B[PR → main]
  B --> C[CI: unit + contract + lint]
  C --> D[Deploy to Staging]
  D --> E[Smoke/E2E + 수동 점검]
  E --> F[Deploy to Prod]
  F --> G[지표와 로그 모니터링]

각 단계에 ‘퓨즈’를 더합니다. dev 환경에서는 개발자가 무엇이든 시도할 수 있지만, main으로의 각 머지는 unit/contract 테스트를 돌리는 CI를 트리거합니다. 모두 통과하면 자동으로 staging에 배포합니다. staging에서는 짧은 E2E/스모크 시나리오를 실행합니다. 예를 들어 선물 추천의 전체 플로우 하나와 테스트 결제에서의 ‘가짜’ 체크아웃 같은 것들입니다.

그 후에야 prod 배포 버튼을 누릅니다. 가급적 버전 표시와 CHANGELOG 링크를 함께 남기세요. prod에서도 p95, 오류율, 그리고 비즈니스 메트릭(추천 → 체크아웃 전환)을 계속 관찰합니다. 릴리스 이후 무언가가 떨어지면 — 곧 이야기할 분명한 롤백 계획이 있어야 합니다.

4. Release notes와 changelog: 무엇을 기록할까

릴리스 노트가 없다면, 한 달 뒤 그래프를 보며 “왜 3주 전에 우리 체크아웃 p95가 2배나 늘었지?”라고 묻게 되고, “모르겠지만 큰 릴리스가 있었던 것 같은데…”라고 답하게 됩니다. 최악의 전략입니다.

최소 두 가지 종류의 노트가 있습니다.

내부 changelog — 기술용. 개발자, SRE, 코드 파는 사람들이 봅니다. 어떤 기능이 추가되었는지, 어떤 버그를 고쳤는지, breaking changes가 있었는지 씁니다. 형식은 Keep a Changelog의 정석을 따르세요: Added, Changed, Fixed, Removed 섹션.

외부 release notes — 사용자와 Store를 위한 사람 친화적 노트. 여기서는 “MCP SDK를 0.4에서 0.5로 마이그레이션” 같은 이야기는 필요 없습니다. 대신 “Thanksgiving 추천을 추가했습니다”, “일부 선물이 장바구니에 담기지 않던 드문 버그를 수정했습니다”처럼 쓰는 것이 낫습니다.

GiftGenius의 CHANGELOG.md 일부 예시:

## [1.4.0] - 2025-11-20
### Added
- 새로운 도구 `suggest_gifts_v2`: 관심사 태그 지원.
- 새 system-prompt A/B 테스트(플래그: GG_PROMPT_V3).

### Changed
- ACP checkout 오류 처리 개선(더 친절한 메시지).

### Fixed
- 이미지가 없는 상품이 추천에서 숨겨지던 버그 수정.

프롬프트 버전도 어딘가 함께 보관하는 것이 좋습니다. 예를 들어 system‑prompt 파일의 커밋 해시만 기록해도 나중에 “아하, b3f9c2d 프롬프트 이후에 사용자가 ‘구매’를 덜 누르기 시작했네”라고 회고할 수 있습니다.

5. SDK와 스펙 마이그레이션: 빠르게 변하는 생태계에서 살아남기

Apps SDK, MCP, Agents 주변 생태계는 빠르게 발전합니다. 새로운 SDK 버전, MCP 프로토콜 변경, ACP 업데이트 등. 좋은 점(기회가 늘어남)이지만 고통스럽기도 합니다(금방 깨질 수 있음).

버전 고정과 ‘릴리스 당일 업데이트 금지’

첫 번째 간단한 권장사항: 의존성 버전을 고정하세요. ^0.4.0이 아니라 0.4.0. API를 자주 깨뜨리는 SDK(MCP/Agents/Apps SDK)에는 특히 중요합니다. 이 주제의 연구들을 보면, ‘SDK fatigue’ — 호환되지 않는 업데이트가 계속되는 피로감 — 를 특히 부동 버전(^0.4.0 같은)을 놔둔 팀이 더 크게 느꼈고, 어느 날 npm install만으로 갑자기 오류를 잔뜩 맞는 일이 생긴다고 지적합니다.

작은 예:

// package.json (발췌)
{
  "dependencies": {
    "@modelcontextprotocol/sdk": "0.4.2",
    "@openai/applications-sdk": "0.3.1"
  }
}

두 번째 권장사항: 하나의 릴리스에 비즈니스 기능과 대규모 SDK 마이그레이션을 함께 묶지 마세요. MCP SDK를 0.3.x에서 0.4.x로 올려야 한다면 기술 릴리스를 따로 만드세요. 즉, 먼저 SDK 업데이트와 테스트·안정화, 그 다음에 새 체크아웃 플로우를 진행합니다.

SDK 마이그레이션 전략

합리적인 계획은 보통 다음과 같습니다.

dev 환경에서 upgrade/mcp-sdk-0.4라는 별도 브랜치를 만듭니다. 의존성을 올리고, 코드를 수정하고, 모든 unit/contract 테스트를 돌리고, Dev Mode로 GiftGenius의 주요 플로우를 로컬에서 돌려봅니다.

그 다음 이 브랜치를 별도의 staging URL에 배포하고 E2E/스모크 테스트를 실행합니다. 간단한 부하 테스트를 해도 좋습니다: 50–100회 연속 suggest_gifts 호출 등.

모든 것이 괜찮다면 main에 머지하고, 기본 staging에 배포한 뒤 스모크를 다시 한 번 돌리고, 그 다음에 prod로 갑니다.

아니라면 — 명확한 롤백이 있습니다. 이 브랜치를 머지하지 않거나 되돌리면 됩니다. SDK 마이그레이션과 제품 릴리스를 분리하는 요점이 바로 여기에 있습니다.

툴과 API 스키마 마이그레이션

가장 까다로운 부분은 인터페이스 변경입니다. 모델은 그것을 즉시 알지 못합니다. 이 주제의 연구들은 특히 중요한 규칙을 강조합니다: “확장하되, 부수지 말라”(additive‑only). suggest_gifts에 새 인자 interests: string[]를 추가해야 한다면, 필수값이 아닌 옵션으로 만드세요. 그러면 기존 시나리오가 계속 동작합니다.

Zod 기반 입력 데이터 스키마의 진화 예:

// v1
const suggestGiftsInputV1 = z.object({
  recipientName: z.string(),
  budget: z.number()
});

// v1.1 (옵션 필드 추가)
const suggestGiftsInputV1_1 = suggestGiftsInputV1.extend({
  interests: z.array(z.string()).optional(),
  occasion: z.string().optional()
});

주의할 점: 기존 필드는 건드리지 않고 확장만 합니다.

정말로 컨트랙트를 바꿔야 한다면(예: budget를 minBudget + maxBudget으로 대체), suggest_gifts_v2처럼 새 도구를 만들고 개선 버전임을 설명에 명시하세요. 모델과 사용자가 이전을 마쳤다고 확신할 때까지 기존 API는 deprecated로 남겨 두고 점진적으로 끕니다.

데이터 마이그레이션: product feed와 ACP

이미 SDK와 tools 스키마 마이그레이션을 이야기했습니다. Product feed 역시 컨트랙트입니다. SKU, 통화, 현지화 형식을 바꾼다면 조정이 필요합니다. feed 스키마, MCP/ACP 처리, 전처리기를 함께 업데이트해야 합니다. ChatGPT App의 커머스 문서에서도, feed의 오류(깨진 필드, 중복, 이상한 가격)는 코드가 완벽해도 추천 품질을 망칠 수 있다고 강조합니다.

전형적인 접근:

1. 먼저 feed 스키마에 새 필드를 옵션으로 추가하고, GiftGenius가 존재할 경우 이를 활용하도록 학습시킵니다.
2. 그 다음 feed를 생성하는 파이프라인을 업데이트해 이 필드를 채우기 시작합니다.
3. feed 검증기(데이터 contract 테스트)를 돌리고, 그 후에야 로직이 이 필드에 의존하도록 전환합니다.

6. Feature flags: 배포와 릴리스를 분리하기

기능 플래그(feature flags)는 ChatGPT App 세계에서 생존을 돕는 핵심 도구입니다. 핵심 아이디어는 간단합니다. 코드는 배포하되, 새 기능을 즉시 켤 필요는 없습니다. 처음에는 ‘플래그 아래’에서 — 개발자만, 또는 1% 사용자만, 아니면 아예 꺼둔 상태로 — 운영합니다.

특히 다음과 같은 경우에 중요합니다:

• 새 추천 알고리즘을 배포할 때;
• system‑prompt를 변경할 때(모델의 행동이 급격히 바뀔 수 있음);
• 비싸거나 느린 도구를 연결할 때;
• 새 체크아웃 플로우를 실험할 때.

env 변수로 구현하는 간단한 플래그

최소 구성의 기능 플래그는 환경 변수로 만들 수 있습니다:

// lib/features.ts
export const isNewRecoEnabled =
  process.env.NEXT_PUBLIC_GG_NEW_RECO === "1";

그 다음 MCP 도구 코드에서 다음처럼 사용할 수 있습니다:

if (isNewRecoEnabled) {
  return runNewRecoAlgorithm(input);
}
return runOldRecoAlgorithm(input);

장점은 단순함입니다. 단점은 런타임에서 플래그를 전환하기가 어렵다는 점입니다. 새 환경을 배포하거나 최소한 재초기화가 필요합니다.

컨텍스트를 고려하는 중앙 헬퍼

조금 더 성숙한 방식은 글로벌 플래그뿐 아니라 사용자 컨텍스트(테넌트, 세그먼트, A/B 그룹)까지 고려하는 중앙 헬퍼를 두는 것입니다.

// lib/featureFlags.ts
type Feature = "new-reco" | "checkout-v2";

type Context = { userId: string; tenantId?: string };

export function isFeatureEnabled(
  feature: Feature,
  ctx: Context
): boolean {
  // 여기에는 env, DB, 외부 플래그 서비스 등이 들어갈 수 있습니다
  if (feature === "new-reco") {
    return process.env.GG_NEW_RECO === "1";
  }
  return false;
}

MCP 핸들러에서:

const enabled = isFeatureEnabled("new-reco", { userId });
const result = enabled
  ? await runNewReco(input)
  : await runOldReco(input);

나중에 LaunchDarkly, Statsig 같은 외부 플래그 서비스를 연결하더라도, isFeatureEnabled 구현만 바꾸면 되고 전체 코드를 바꿀 필요는 없습니다.

GiftGenius 시나리오 예시

system‑prompt A/B 테스트. PROMPT_V2를 만들고 특정 목록에 있는 tenantId의 사용자 10%에게만 켭니다. MCP 도구와 위젯은 바뀌지 않고, 전환율만 비교합니다.

비싼 도구를 위한 킬 스위치. 외부의 비용이 큰(예: 비싼 ML 추천 모델) 복잡한 요청을 보내는 도구를 만들었다고 합시다. 외부 서비스가 다운되거나 갑자기 비용이 치솟는다면, GiftGenius 전체를 멈추지 않고도 이 도구만 1초 만에 끄고 싶을 겁니다. 기능 플래그가 가장 쉬운 방법입니다.

새 체크아웃 플로우의 점진적 롤아웃. Checkout v2는 우선 사내 직원과 신뢰하는 일부 고객에게만 켭니다. 메트릭이 괜찮으면 점차 대상을 넓혀 모두에게 켭니다.

7. 롤백: 모든 것이 불타오를 때 신속히 되돌리기

아무리 완벽한 테스트와 플래그가 있어도 언젠가는 무언가가 망가집니다. 중요한 것은 명확한 전략을 갖는 것입니다. 오류가 폭증하거나 메트릭이 급락한 것을 본 후 처음 5–15분에 무엇을 할지요.

코드 빠른 롤백

문제가 순수 기술적 버그(NPE, 잘못된 변수, 외부 서비스 URL 오기 등)라면 보통 직전 버전으로 배포를 되돌리는 것만으로 충분합니다. 예를 들어 Vercel에는 직전 배포로 즉시 롤백하는 기능이 있습니다.

여러분의 과제는 어떤 배포가 어떤 버전에 대응하는지, 그리고 어떻게 롤백하는지를 항상 알고 있는 것입니다. 이상적으로는 온콜을 위한 README에 “만약 1.4.0 릴리스 이후 모든 것이 불타면 deployment X로 롤백”처럼 적혀 있어야 합니다.

두 번째 빠른 지렛대는 기능 플래그입니다. 새 기능(checkout-v2)만 깨진 경우, 전체 릴리스를 곧장 롤백하는 것보다 해당 기능 플래그만 끄는 편이 쉽습니다.

위험한 변경: 매니페스트와 스키마

매니페스트와 스키마는 더 까다롭습니다. Store에 잘못된 도구 스키마가 있는 새 매니페스트를 올리고 OpenAI의 승인이 이미 떨어졌다면, 롤백에는 며칠이 걸릴 수 있습니다. 이유는 간단합니다. 매니페스트의 각 변경도 OpenAI의 리뷰를 거치기 때문입니다. 여러 Store의 분석에서 매니페스트와 스키마 변경을 ‘위험한’ 릴리스로 분류하며, 특히 신중하게 준비하고 테스트해야 한다고 합니다.

따라서 다음을 구분하세요:

• 안전한 릴리스: MCP/Next.js 코드 변경, 프롬프트 수정, 기능 플래그 뒤에 숨겨진 새 기능;
• 위험한 릴리스: tools 목록, input/output 스키마, ACP 컨트랙트 변경.

‘위험한’ 릴리스는 별도로, 추가 점검과 함께, 가능하다면 먼저 Dev Mode와 staging App에서만(Store 공개 없이) 진행하는 것이 좋습니다.

데이터와 feed 롤백

데이터는 더 복잡(그리고 더 고통스럽)합니다. 새 스키마로 product feed를 마이그레이션하면서 기존 필드를 삭제했다면, 되돌리는 것이 언제나 쉽지는 않습니다. 따라서 데이터 마이그레이션은 멱등적이고 되돌릴 수 있어야 합니다. 예전 복사본을 보관하거나, 두 단계로 마이그레이션(먼저 데이터를 복제, 그 다음 읽기 전환)하세요.

간단한 접근은 일정 기간 동안 구(旧) 필드와 신(新) 필드를 병행해 보관하고, 기능 플래그로 그 사이를 전환할 수 있게 하는 것입니다. 무언가가 망가지면 — 그냥 예전 읽기로 돌아가면 됩니다.

8. GiftGenius를 위한 미니 릴리스 프로세스 설계

위에서 이야기한 내용(버전, SDK 마이그레이션, 기능 플래그, 롤백)을 하나의 실전 시나리오로 묶어 봅시다.

1.4.0 릴리스를 준비한다고 가정합니다. 이 릴리스에서는:

• 확장된 입력을 가진 새 도구 suggest_gifts_v2를 추가하고,
• 일부 사용자에게만 새 system‑prompt를 켜며,
• MCP SDK를 0.3 → 0.4로 업데이트하고,
• product feed 형식을 변경합니다(tags 필드 추가).

합리적인 계획은 다음과 같을 것입니다.

먼저 별도의 기술 릴리스 1.3.1을 진행합니다: MCP SDK 업데이트 + 최소한의 코드 수정, 스키마와 기능 변경 없음. CI, staging, 스모크 테스트를 실행합니다. 안정적이면 며칠간 이 상태로 운영합니다.

그 다음 feature/reco-v2 브랜치를 만듭니다. 여기서 suggest_gifts_v2를 새 도구로 추가합니다(기존 suggest_gifts는 유지). 입력 스키마는 옵션 필드 추가만으로 확장합니다. 새 system‑prompt를 준비하지만 GG_PROMPT_V3 플래그로 감춥니다. ACP/피드에는 새 tags 필드를 비필수로 추가하고, 이 필드가 없어도 동작하도록 읽기 로직을 작성합니다.

CI에는 몇 가지 새 contract 테스트를 추가합니다. suggest_gifts_v2가 예전과 새 payload를 모두 받는지, tags가 있는 feed가 유효한지, 그리고 tags가 없는 기존 레코드도 서버를 깨지 않는지 등을 확인합니다.

main에 머지한 후:

• CI가 unit/contract를 실행하고,
• staging에서 새 도구를 통과하는 E2E 시나리오 1–2개를 돌리며,
• 기능 플래그를 통해 테스트 테넌트에만 새 프롬프트와 도구를 켭니다.

메트릭을 봅니다. 도구의 p95, 오류율, 체크아웃 전환율 등. 모두 괜찮으면 대상 사용자를 넓힙니다. 그리고 안정성이 확인되면(필요하다면) Store용 매니페스트를 업데이트하고 앱의 프로모 설명을 갱신합니다.

중간에 무언가가 부러지면 — 어떻게 되돌릴지 알고 있습니다. 플래그를 바로 끄거나, 배포를 롤백하거나, 최후의 수단으로 매니페스트 버전을 되돌립니다(다만 이 경우는 애초에 만들지 않는 편이 가장 좋습니다).

9. ChatGPT App 릴리스 프로세스에서 흔한 실수

실수 1: 추상적인 ‘App 한 벌의 버전’만 있고, 버전 매트릭스가 없음.
“GiftGenius v1.4”만 있고 tools 스키마, 프롬프트, product feed 버전이 어딘가에 고정되어 있지 않다면, “정확히 어떤 변경 이후 체크아웃이 떨어졌지?”에 답할 수 없습니다. 레이어별로 버전을 분리하고, 구조화된 로그에 기록하세요.

실수 2: 새 이름/버전 없이 tools에 breaking change를 가함.
가장 아픈 유형입니다. input 스키마의 필드 이름을 바꾸거나 삭제했는데 도구 이름은 그대로인 경우. 오래된 채팅에서 모델은 예전 payload를 계속 보내고, 백엔드는 400을 반환하며, GPT는 ‘환각’ 응답을 하기 시작하고, 사용자는 이해하지 못합니다. 모든 호환성 깨짐 변경은 새 도구(foo_v2) 또는 새 API 버전을 통해 하고, 기존 인터페이스는 전환 기간 동안 유지하세요.

실수 3: 기능 개발 중에 SDK를 ‘겸사겸사’ 업데이트.
고전 사례입니다. 새 비즈니스 기능을 추가하면서 @modelcontextprotocol/sdk를 0.3에서 0.5로 “그냥 최신으로” 올립니다. 무언가가 깨지면, 새 코드 때문인지, 새 스키마 때문인지, 새 SDK 때문인지 알 수 없습니다. SDK 마이그레이션은 명확한 테스트 계획과 롤백 가능성을 갖춘 별도의 기술 릴리스로 하세요.

실수 4: 기능 플래그와 즉시 킬 스위치 부재.
새 추천 알고리즘을 사용자 100%에게 한 번에 배포하는 일은, 그것이 이상한 결과를 내거나 외부 서비스를 다운시킬 때까지는 ‘재밌을’ 수 있습니다. 기능 플래그가 없으면 유일한 지렛대는 릴리스 전체 롤백이며, 이는 새 기능뿐 아니라 수많은 무해한 개선까지 함께 되돌릴 수 있습니다. 최소한 env나 작은 설정 파일로라도 간단한 플래그를 만드세요.

실수 5: 매니페스트가 ‘즉시’ 업데이트된다고 믿음.
tools나 openapi.yaml을 바꾸면 모델이 곧바로 새 스키마를 안다고 생각하는 오해가 흔합니다. 실제로 매니페스트와 tools 설명은 캐시되며, 이미 열려 있는 채팅에서는 오래 살 수 있습니다. 이를 무시하면 기묘한 버그가 생깁니다. 새 채팅에서는 동작하고, 오래된 채팅에서는 실패합니다. 이러한 동작을 고려해 스키마 변경을 계획하고, Store에 올리기 전에 Dev Mode와 staging에서 테스트하세요.

실수 6: 명확한 롤백 계획과 릴리스 문서가 없음.
팀에서 누구도 “5분 안에 어떻게 롤백하죠?”, “어떤 버전으로 롤백하죠?”, “예전 feed 스키마로 어떻게 돌아가죠?”에 답하지 못한다면, 롤백이 없는 것이나 다름없습니다. 온콜 담당자는 짧지만 구체적인 시나리오를 가져야 합니다. 어떤 버튼을 누르고, 어떤 변수를 바꾸며, 어디서 롤백 성공을 확인하는지요.

실수 7: release notes와 메트릭 연계 없는 ‘무성의한’ 릴리스.
최소한의 changelog 없이 릴리스한다는 것은 몇 달 후 추측 모드로 살겠다는 뜻입니다. p95가 갑자기 늘고 전환율이 떨어지면 “그때 대체 뭐가 바뀌었지?”라고 추측하게 됩니다. 최소한의 릴리스 노트를 쓰고, 배포 날짜와 버전과 연결하는 습관은 품질 감사뿐 아니라 팀 전체의 삶을 더 편하게 만듭니다.