공식 참고 자료: Best Practices · Review · Automations
커리큘럼 흐름
- Codex 시작하기 — 설치, 첫 작업, 체크포인트까지 — 입문 루프
- Codex 지시문 — AGENTS.md를 진짜 쓸모 있게 만드는 법 — 저장소 규칙
- Codex 샌드박싱 — 권한, 승인, 클라우드 환경 이해하기 — 권한과 승인
- Codex 작업 설계 — 소원 말고 이슈처럼 프롬프트 쓰기 — 좋은 task shape 만들기
- Codex Skills — 반복 프롬프트를 재사용 가능한 워크플로우로 바꾸기 — 반복 워크플로우를 재사용 자산으로 만들기
- Codex 서브에이전트 — 병렬 실행과 위임 패턴 — 병렬 실행과 위임
- Codex MCP — 외부 컨텍스트를 복붙 대신 연결하기 — 외부 시스템 연결
- Codex 리뷰와 자동화 — /review, worktree, 반복 엔지니어링 운영하기 — 반복 작업 운영
- Codex Worktrees — 브랜치 충돌 없이 병렬 실행하기
- Codex 핸드오프 — 병렬 레인을 머지 가능한 결과로 연결하기
- Codex 검증 루프 — 머지 전에 동작을 증명하기
- Codex 릴리스 준비도 — 프로덕션 전 최종 게이트 ← 현재 문서
- Codex 첫날 안전 루프 — 초반 실수를 줄이는 입문 워크플로우
- Codex 팀 딜리버리 플레이북 — 중급 레인 운영
- Codex 고위험 변경 거버넌스 — 크리티컬 릴리스를 위한 고급 통제
- Codex 운영 매뉴얼 — 팀의 일/주/릴리스 리듬 정렬하기
- Codex 사고 복구 플레이북 — 프로덕션 압박 상황에서의 결정론적 대응
- Codex 사고 후 하드닝 루프 — 복구를 내구성 있는 통제로 전환하기
- Codex 카오스 복원력 드릴 — 실패가 오기 전에 리허설하기
- Codex 복원력 지표와 SLO — 실패 전에 신뢰성을 측정하기
- Codex Ralph 지속 루프 — 긴 작업을 검증 가능한 완료까지 가져가기
이 문서에서 참고한 공식 문서
- 명시적 done criteria와 리스크 기반 실행 원칙 — Best Practices
- 머지/배포 전 최종 diff 범위 점검 — Review
- 반복 가능한 사전 점검 자동화 — Automations
왜 릴리스 준비도를 별도 단계로 둬야 하는가
많은 팀이 릴리스를 "검증을 한 번 더 하는 일"로 취급합니다. 하지만 운영 관점 질문이 빠지기 쉽습니다.
- 최종 go/no-go 오너는 누구인가?
- 아직 남은 리스크는 무엇인가?
- 롤백 트리거는 무엇인가?
- 배포 중단 시 누가 커뮤니케이션을 담당하는가?
릴리스 준비도는 테스트 통과 여부만이 아닙니다. 오너십 + 근거 + 비상계획을 갖춘 의사결정 단계입니다.
릴리스 게이트 스택
실무적으로는 5개 레이어를 권장합니다.
- 코드 게이트 — lint/tests/build 및 필수 품질 체크
- 리뷰 게이트 — diff 범위 검토 및 승인
- 운영 게이트 — 롤백 경로, 온콜 오너, 배포 윈도우
- 커뮤니케이션 게이트 — 릴리스 노트 + 이해관계자 공지 계획
- 의사결정 게이트 — 명시적 go/no-go 서명과 책임자
코드 품질이 좋아도 한 레이어를 건너뛰면 사고 가능성이 크게 높아집니다.
리스크 클래스별 릴리스 매트릭스
| 리스크 클래스 | 대표 변경 | 필요한 게이트 깊이 |
|---|---|---|
| Low | 문서, copy, 비핵심 UI 폴리시 | 표준 코드 + 리뷰 게이트 |
| Medium | 핵심 플로우 동작 변경 | 코드 + 리뷰 + 롤백 오너 지정 |
| High | auth, billing, 권한, migration | 5개 게이트 전부 + 리허설 + 명시적 go/no-go 패널 |
최종 검증 전에 리스크 클래스를 먼저 고정해야, 막판에 게이트 강도로 소모적 논쟁이 생기지 않습니다.
릴리스 의사결정 템플릿(복붙용)
### Release Decision
- Release scope: <services/modules/features>
- Risk class: low | medium | high
- Gate results:
- code gates: pass | fail
- review gates: pass | fail
- operational gates: pass | fail
- communication gates: pass | fail
- decision gate: pass | fail
- Residual risks:
- <list or none>
- Rollback trigger:
- <clear condition>
- Rollback owner:
- <person/role>
- Final decision owner:
- <person/role>
- Decision:
- GO | NO-GO
- Decision timestamp:
- <iso datetime>짧아도 명시적인 결정 기록이 릴리스 책임 공백을 막아줍니다.
배포 전 드릴 체크리스트
고위험 배포 윈도우 전에는 dry drill을 권장합니다.
- 현재 브랜치 기준 핵심 커맨드 정상 동작 확인
- feature flag/default 값 확인
- 롤백 커맨드/절차 유효성 확인
- 변경 영향 지표를 감시할 대시보드/알림 확인
- pager 1차/2차 담당자 가용성 확인
드릴은 "복구할 수 있을 것"을 "복구 가능함을 증명함"으로 바꿉니다.
롤백 리허설 패턴
중간/고위험 변경은 비프로덕션에서 롤백 리허설을 수행하세요.
- 후보 빌드 반영
- 롤백 트리거 상황 모의
- 롤백 절차 실행
- 서비스 회복/알림 정상화 확인
- 복구 시간과 마찰 포인트 기록
리허설에서 느리거나 복잡한 롤백은, 실제 사고에서는 더 나쁩니다.
최소 릴리스 커뮤니케이션 패키지
모든 릴리스 패키지에는 아래 항목이 있어야 합니다.
- 무엇이 바뀌었는지(사용자 영향/내부 영향)
- 알려진 제한사항
- 첫 30~60분 모니터링 포인트
- 롤백 트리거 조건
- 에스컬레이션 채널 및 책임자
좋은 커뮤니케이션은 공지 의식이 아니라 제어 장치입니다.
실패 모드 예시
"테스트는 다 통과"인데 롤백 트리거가 없음
사고 중 임계값 논쟁으로 롤백이 늦어집니다.
최종 결정 오너가 없음
누군가 결정했겠지라는 가정만 남습니다.
diff는 검토했지만 운영은 검토하지 않음
배포는 성공해도 runbook 불일치로 운영에서 실패합니다.
릴리스 준비도 10분 감사
배포 전에 질문:
- 리스크 클래스가 명시되었는가?
- 게이트 레이어별 pass/fail이 기록되었는가?
- 최종 결정 오너가 지정되었는가?
- 롤백 트리거가 구체적이고 테스트 가능한가?
- 커뮤니케이션 패키지가 준비되었는가?
하나라도 아니오면 아직 릴리스 준비가 아닙니다.
빠른 체크리스트
go/no-go 전에:
- 리스크 클래스 선언
- 5개 게이트 레이어 평가
- 롤백 트리거 + 오너 기록
프로덕션 배포 전에:
- 최종 결정 + 타임스탬프 기록
- 릴리스 커뮤니케이션 패키지 준비
- 에스컬레이션 오너 연락 가능 상태 확인
Codex는 구현 속도를 높여줍니다. 릴리스 준비도는 그 구현이 실제 트래픽을 만났을 때 비즈니스를 보호합니다.