릴리스 준비 상태를 설명하는 발표에서는 승인 권한자가 세 가지에 답할 수 있어야 합니다. 정확히 무엇을 배포하는지, 어떤 근거가 그 변경을 뒷받침하는지, 실패하면 어떻게 대응하는지입니다. 요청하는 결정부터 말하고, 근거 옆에 미해결 조건을 표시한 뒤, 누가 무엇을 승인했는지 기록하며 마무리하세요. 초록색 상태 아이콘만 나열해서는 부족합니다.
검토가 끝난 릴리스 자료부터 준비하세요. 이후 Presenti로 텍스트를 편집 가능한 발표 초안으로 바꾸면서 근거 참조와 승인 조건을 슬라이드에 남길 수 있습니다. 아래에서는 가상의 예약 서비스로 Go/No-go 회의를 설명합니다. 기록과 시각, 기준값은 학습용 예시이며 실제 배포 결과가 아닙니다.
진척도보다 먼저 릴리스와 결정 범위 밝히기
팀은 고객의 예약 생성과 취소 방식을 바꾸는 버전 2.4를 배포하려고 합니다. 요금, 계정 이전, 모바일 앱은 이번 범위 밖입니다. 검토 대상은 빌드 2.4-rc3와 설정 묶음 C17이며, 새 데이터베이스 마이그레이션이 포함됩니다. 우선 내부 테스트 계정 10개에만 공개하고, 고객 공개는 별도로 판단하자는 제안입니다.
회의 시점에 예약 테스트는 통과했습니다. 알림 지연은 아직 조사 중입니다. 롤백 리허설은 이전 후보에서 진행했으며 rc3와 그 마이그레이션을 포함하지 않았습니다. 따라서 첫 슬라이드는 이렇게 말해야 합니다.
권고: rc3 시범 배포를 보류합니다.예약 동작을 뒷받침하는 테스트 근거는 있지만, 이 후보에서 복구할 수 있는지는 입증되지 않았습니다. 복구 조건을 충족하고 알림 지연을 파악한 뒤 시범 배포 승인을 요청합니다.
이는 “릴리스 2.4는 95% 준비됐습니다”보다 유용합니다. 백분율은 결과의 중요도가 다른 항목을 섞습니다. 문서 작업을 여러 개 완료했다고 복구 결과가 없다는 문제가 상쇄되지는 않습니다.
첫 슬라이드에 빌드, 설정, 검토 시각, 요청하는 공개 범위를 넣으세요. 회의 중 빌드나 설정이 바뀌면 어떤 근거가 여전히 적용되는지 알아야 합니다. 이전 후보에 대한 승인을 새 산출물에 조용히 넘기지 마세요.
각 결과가 실제로 뒷받침하는 범위 보여주기
근거는 짧은 표로 정리하고 상세 기록은 별도로 볼 수 있게 합니다. 각 행에서 주장과 적용 범위, 남은 공백을 연결하세요. 내부 계정이나 결제 경로 하나만 테스트했다면 “테스트 통과”라는 말은 너무 넓습니다.
| 영역 | 가상 검토의 근거 | 결정에 미치는 의미 |
|---|---|---|
| 예약 동작 | QA-42에 사전 검증 환경의 rc3/C17에서 실행한 생성, 취소, 동시 예약 테스트가 기록돼 있습니다. | 테스트한 경로를 뒷받침합니다. 모든 고객 부하에서의 동작을 입증하지는 않습니다. |
| 알림 | MAIL-9에 재시도 테스트 중 확인 메시지가 지연된 기록이 있습니다. 최대 지연과 원인은 미해결입니다. | 예외를 계속 표시합니다. 알림 준비가 끝났다고 하거나 지연이 무해하다고 가정하지 않습니다. |
| 복구 | RB-14는 이전 후보를 대상으로 했습니다. rc3와 해당 마이그레이션의 리허설 기록은 없습니다. | 합의한 복구 조건을 충족하지 못했습니다. 현재 권고는 보류입니다. |
| 지원 인력 | OPS-6에 주 담당자, 대체 담당자, 시범 운영 시간대, 상위 보고 경로가 있습니다. | 그 시간대에만 지원 체계가 마련됐습니다. 무기한 운영이나 확대 공개까지 포함하지 않습니다. |
QA-42 등의 명칭은 예시 기록 ID입니다. 실제 발표에서는 환경, 후보, 시각을 포함한 실제 결과로 연결하세요. 개인정보와 운영 기밀은 적절히 접근이 제한된 기록에 두고, 널리 공유할 발표 자료에 복사하지 마세요.
Google의 안정적인 제품 출시에 관한 설명(영문)은 서비스에 맞춘 구체적이고 실용적인 확인을 강조합니다. 과거 출시 점검표(영문)에는 장애 시 동작, 모니터링, 복구, 단계적 배포가 포함됩니다. 우리 서비스에 맞게 적용할 질문으로 활용하되, 보편적인 승인 기준이나 우리 서비스가 통과했다는 근거로 삼지 마세요.
배포 중단 조건과 수용한 예외 구분하기
어떤 조건이면 보류하고, 어떤 조건은 명시적으로 제한된 배포에서 검토할 수 있는지 회의 전에 합의하세요. 그렇지 않으면 “주의” 상태가 노출 범위의 판단이 아니라 표시 색상을 둘러싼 협상이 됩니다.
이 예시의 합의된 규칙은 모든 시범 배포에 앞서 해당 후보의 복구 경로를 입증해야 한다는 것입니다. 따라서 rc3 리허설이 없는 것은 배포 중단 조건입니다. 회의 진행자가 고객 대신 직원 10명으로 대상을 줄인다는 이유만으로 이를 수용 가능한 예외로 바꿀 수는 없습니다.
이메일 지연은 별개의 질문입니다. 그 제약을 안고 좁은 범위의 시범 배포를 진행할 수 있을까요? 먼저 관측된 지연, 예약 상태의 정확성, 참여자에게 보일 내용, 시범 운영을 멈출 권한자가 누구인지 알아야 합니다. “우회 방법이 있습니다”라는 말만으로는 답이 되지 않습니다.
각 예외 제안은 제약, 영향을 받는 사용자, 근거, 임시 통제, 책임 역할, 종료 시점 또는 재검토 시점으로 간단히 기록하세요. 대상과 종료 시점이 없는 예외는 릴리스에 대한 약속을 기한 없이 바꾸는 셈입니다.
세 결과를 구별해야 합니다. Go는 합의한 조건 아래 명시된 범위를 승인합니다. 제한적 Go는 더 작고 정확히 정의된 범위를 승인합니다. No-go는 지정한 근거와 결정을 다시 검토할 때까지 제안된 변경을 승인하지 않습니다. 어느 명칭도 발표자에게 원래 없던 권한을 주지는 않습니다.
복구까지 포함한 배포 경로 그리기
“배포”에서 끝나는 일정표는 승인에 필요한 작업을 숨깁니다. 단계 사이에 판단이나 중단 조건을 넣어 짧은 흐름으로 그리세요.
- 공개 전: rc3 복구 리허설을 완료하고 MAIL-9를 파악합니다. 기록을 새 검토에 첨부합니다.
- 승인: 지정된 릴리스 승인권자가 해당 후보를 10개 계정 시범 운영에 투입해도 되는지 판단합니다.
- 제한된 관찰: 지명된 담당자가 시범 시간대에 예약 정확성, 알림, 합의한 모니터링 신호를 확인합니다.
- 다음 결정: 제한 상태를 유지하거나, 중단하고 복구하거나, 공개 확대를 요청합니다. 첫 승인이 마지막 선택까지 자동으로 허용하지는 않습니다.
이후 검토에서 확인된 이중 예약, 5분을 넘는 확인 메시지 지연, 또는 둘 중 하나를 관찰하는 데 필요한 모니터링 상실을 중단 조건으로 정했다고 가정해 보겠습니다. 이 값들은 예시 서비스에만 해당하며 권장 기본값이 아닙니다. 제한적 시범 운영에 30분의 관찰 시간을 둘 수는 있지만, 더 큰 규모에서의 안정성이 입증되는 것은 아닙니다.
중단 조건 옆에 중단 권한을 표시하세요. 이 예시에서는 당직 책임자가 시범 운영을 멈출 수 있고, 재개 여부는 릴리스 승인권자가 판단합니다. 복구 경로는 승인된 운영 절차서로 연결하세요. 발표를 실행 가능한 배포 명령서로 만들려고 하지는 마세요.
마이그레이션에서는 “되돌린다”는 뜻을 확인해야 합니다. 이전 애플리케이션이 새 버전에서 작성한 기록을 읽을 수 있나요? 시범 운영 중 생긴 예약을 대조하고 정리해야 하나요? 확인된 답이나 부족한 근거를 보여주세요. 애플리케이션 버전만 바꿨다고 데이터가 사용할 수 있는 상태로 돌아왔다는 뜻은 아닙니다.
팀별 현황 보고 대신 여섯 장으로 결정 흐름 만들기
각 팀의 주간 보고를 되풀이하지 않고도 짧은 검토 자료로 결정을 진행할 수 있습니다.
- “복구가 입증될 때까지 rc3 시범 배포를 보류합니다.” 후보, 범위, 권고, 승인 역할을 밝힙니다.
- “예약 테스트는 검증한 경로를 뒷받침하지만 두 조건이 남아 있습니다.” 근거 표와 한계를 보여줍니다.
- “이전 롤백 결과는 이번 마이그레이션을 포함하지 않습니다.” 배포를 막는 공백과 필요한 결과를 설명합니다.
- “첫 승인은 계정 10개만 대상으로 합니다.” 단계별 경로, 관찰 시간대, 중단 권한을 표시합니다.
- “제안한 시간대의 지원 인력이 확보돼 있습니다.” 담당 역할, 대체 인력, 시간대 이후의 인계를 적습니다.
- “결정과 다음 검토 조건을 기록합니다.” 구체적인 결론을 남기고 회의를 마칩니다.
첫 슬라이드는 권고이고 마지막 슬라이드는 실제 결정입니다. 둘은 다를 수 있습니다. 회의에서 요청 범위가 바뀌면 그 변경을 기록하세요. 나중에 첫 슬라이드만 고쳐 무엇을 검토했는지 사라지게 해서는 안 됩니다.
초안에는 여섯 제목과 그 아래에 검토한 근거를 붙여 넣습니다. “rc3/C17을 바꾸지 마세요. 보류 권고와 미해결 복구 조건을 유지하세요. 근거, 향후 단계의 제안, 승인을 구분하세요. 테스트 결과, 승인자 이름, 배포 날짜, 성능 개선을 만들지 마세요”라는 지시가 유용합니다. 최종 디자인 전에 생성 문장을 읽고, 깔끔한 배치 때문에 제안 단계가 승인된 단계처럼 바뀌지 않았는지 확인하세요.
완성된 결정 기록을 남기고 마무리하기
다음은 가상의 회의 기록입니다. 참석자들이 떠나기 전에 읽어 줄 수 있을 만큼 짧게 정리했습니다.
결정: 14:00 검토에서 rc3/C17의 10개 계정 시범 배포를 No-go로 기록했습니다. 고객 공개는 승인하지 않았습니다.
이유: 복구 근거에 후보의 마이그레이션이 포함돼 있지 않습니다. 알림 지연도 아직 파악하지 못했습니다.
다음 근거: 개발 책임자가 새로 생성된 예약의 처리를 포함한 후보별 복구 결과를 제출합니다. 알림 담당자는 지연 조사 결과와 시범 운영 제한안을 제출합니다.
결정 책임자: 지정된 릴리스 승인권자가 기록이 준비되면 검토를 다시 엽니다. 제안된 16:00 확인은 현황 보고이며 16:00에 배포하라는 허가가 아닙니다.
변경되지 않은 범위: 고객 확대 공개, 모바일 앱, 요금, 계정 이전은 이번 결정에서 제외됩니다.
발표 자료와 근거 참조에 이 기록을 함께 보내세요. 다음 회의에서 다른 결정이 나면 그때 검토한 후보와 조건을 새 항목으로 추가합니다. 회의에 참석하지 않은 사람도 무엇이 승인됐고 무엇이 보류됐으며 다음에 무엇을 해야 하는지 알 수 있다면 발표가 역할을 한 것입니다.
