런북 리플레이 게이트: 45분 만에 실행 가능한 실패 종료(Fail-Closed) 인수인계 체크리스트

서비스가 테스트를 통과했다고 해서 프로덕션 준비가 된 것은 아닙니다. 서비스가 프로덕션 준비가 되었다는 것은, 저장소(repo)를 한 번도 열어본 적 없는 사람이 커밋된 내용만을 사용하여 빈 기계에서 해당 서비스를 복원할 수 있을 때입니다.

이것이 바로 게이트(gate)입니다. 이 글의 나머지는 그 단 하나의 문장을 실행 가능한 형태로 만듭니다: 사전 비행 스크립트, 45분짜리 블라인드 드릴, 그리고 자체 파이프라인에 복사할 수 있는 실패 종료 기준을 갖춘 의사결정표입니다.

이 게이트가 포착하는 실패

대부분의 준비성 검토는 '해피 패스(happy path)'를 확인합니다. 배포가 작동하는지, 테스트가 녹색(green)인지, 상태 엔드포인트가 200을 반환하는지 등을 확인합니다. 하지만 이 모든 것은 밤샘 근무로 이어지는 실제 시나리오와 접촉하면 무너집니다:

• 서비스를 구축한 사람이 연락이 닿지 않고, 복원 방법에 대한 유일한 설명이 그 사람의 머릿속에만 존재할 때.
• 복구 단계가 아무도 내보내지 않은 채팅 스레드, DM 또는 어시스턴트 세션에 남아있을 때.
• 롤백(rollback) 명령이 한 번도 실행된 적이 없어, 첫 실행이 사고 발생 중에 이루어질 때.

리플레이 게이트는 이 세 가지 상황 모두를 3시의 새벽에 논쟁하는 대신 풀 리퀘스트(pull request)에서 논할 수 있는 이진 결과로 변환합니다.

일곱 개의 게이트

모든 행에는 증거가 첨부되어야 합니다. 증거가 없으면 통과할 수 없습니다. 이것이 바로 '실패 종료(fail-closed)'를 의미하는 바입니다.

게이트 2가 팀들이 가장 많이 논쟁하는 부분이므로, 규칙을 명확하게 진술합니다: 어떤 단계가 인간이 의도를 해석하도록 요구한다면, 그것은 '단계(step)'가 아니라 '메모(note)'입니다. 메모는 허용됩니다. 단지 통과 조건에 포함되지 않을 뿐입니다.

게이트 4에는 두 번째 규칙이 필요합니다: 타임스탬프는 최소한 한 번 크게 실패했던 명령에서 나와야 합니다. 아무도 고장 내본 적 없는 롤백은 아무것도 하지 않는 롤백과 구별할 수 없습니다.

아티팩트 1: 리플레이 사전 비행 스크립트

이것은 측정된 결과가 아닌 제안입니다. 이 스크립트를 여러분의 리포지토리에 실행해 보고 첫 번째 실행이 실패하는 것을 예상하세요. 그것이 요점입니다. 이를 scripts/replay_check.sh로 저장하고, docs/, deploy/, 또는 설정 디렉토리에서 변경 사항이 있을 때 CI(Continuous Integration)를 통해 호출하세요.

#!/usr/bin/env bash
# replay_check.sh — handoff 리플레이 드릴을 위한 fail-closed 사전 점검
set -uo pipefail
...

체크 자체보다 더 중요한 두 가지 속성이 있습니다. 바로 0이 아닌 값(non-zero)으로 종료되어 병합(merge)을 차단할 수 있다는 점과, 버그의 존재 여부가 아니라 증거의 부재 여부에서 실패한다는 점입니다. 이것이 체크리스트와 테스트 스위트의 차이점입니다.

아티팩트 2: 45분 블라인드 리플레이

이 스크립트는 서류 작업(paperwork)이 존재하는지 확인합니다. 그 서류가 작동하는지는 오직 인간만이 확인할 수 있습니다. 세 가지 역할과 엄격한 시간 제한을 두고 이 드릴을 실행하세요.

1. 서비스를 배포해 본 적 없는 담당자(runner)를 지정합니다. 순환 교대가 아닙니다. 진정으로 익숙하지 않은 사람이어야 합니다.
2. 그들에게 세 가지 것을 제공합니다: 리포지토리 URL, 빈 서버, 그리고 작동하는 인스턴스에 도달해야 한다는 요구사항입니다.
3. 빌더(builder)의 도움을 차단합니다. 담당자가 하는 모든 질문은 담당자에게 결함이 있는 것이 아니라 문서화(docs)에 결함이 있다는 의미입니다. 첫 번째 질문을 그대로 기록하세요.
4. 시간을 기록합니다. 그들이 실행 중인 인스턴스에 도달하는 데 얼마나 걸렸나요? 언제 처음 도움을 필요로 했나요?
5. 질문 내용과 실패한 명령어들을 포함하여 로그를 docs/replay/YYYY-MM-DD.md에 붙여넣습니다.
6. 담당자가 아닌 리포지토리를 수정합니다. 각 질문은 다음 드릴이 있기 전에 런북(runbook)의 한 줄이 됩니다.

드릴을 논의하기 전에 로그를 작성하세요. 토론은 좋은 의도 쪽으로 수렴하지만, 로그는 그렇지 않습니다.

통과로 간주되는 것

• 성공(Pass): 실행자가 막히는 질문 없이 작동하는 인스턴스에 도달했고, 경로의 모든 명령이 커밋되었다.
• 조건부 성공(Conditional pass): 도움이 필요했지만, 누락된 단계가 훈련 과정(drill) 중에 레포지토리(repo)에 추가되었고 재실행하여 성공했다.
• 실패(Fail): 도움이 필요했고 수정 사항이 레포지토리를 벗어난 곳 어딘가에 존재한다.
• 성공 아님(Not a pass): 빌더가 화면 공유를 하며 설명하는 경우. 그것은 데모이며, 데모는 런북을 부패하게 만든다.

AI 지원 런북이 새로운 실패 모드가 되다

어시스턴트(Assistant)는 레포지토리 증거로부터 복구 단계를 초안 작성하는 데 능숙하다: 설정을 읽고, 마이그레이션(migration)을 읽고, 순서를 제안한다. 또한 자신들이 생성된 세션 내에서만 작동하는 단계를 만드는 것도 잘 한다.

이 과정을 정직하게 유지하는 규칙은 지루하다. 생성된 모든 명령은 한 번 실행되며, 그 실제 출력 결과는 명령어 아래에 붙여넣어져야 한다. "어시스턴트를 사용하여 설정을 재생성하라"라는 단계는 단계가 아니다. 왜냐하면 다음 사람은 어시스턴트 상태도, 컨텍스트(context)도, 그것을 신뢰할 이유도 없기 때문이다.

만약 단계가 런타임(runtime)에서 모델 호출에 의존한다면, 게이트 5(gate 5)를 적용해야 한다: 명령 옆의 런북에 폴백(fallback)과 타임아웃(timeout)을 명시하라.

일회용 박스와 무료 모델 접근이 들어갈 자리

이 훈련(drill)은 나중에 삭제해도 괜찮은 머신, 즉 스테이징 서버도 아니고, 프로덕션 환경도 아니며, 가지고 놀고 싶은 유혹을 느낄 만한 것도 아닌 박스가 필요하다. 그것이 바로 폐기 가능한 환경(throwaway environment)의 정확한 형태이며, 전체 과정에서 가장 매력적이지 않은 부분이다.

MonkeyCode의 무료 모델 접근 및 무료 서버 옵션은 여기서 두 가지 제한적인 방식으로 유용하다: 서버는 공유 인프라를 건드리지 않고 블라인드 리플레이(blind replay)를 실행할 장소를 제공하며, 무료 모델 접근은 레포지토리로부터 docs/runbook.md의 첫 버전을 초안 작성해 줄 수 있고, 사용자는 이를 커밋하기 전에 한 줄씩 실행할 수 있다. 어느 것도 훈련을 대체하지 않는다. 훈련은 사람, 시계, 그리고 로그이다.

공개 고지: 이 기사는 MonkeyCode의 제품 홍보(product outreach)의 일환으로 작성되었습니다.

모든 가용성 및 허용량 주장(availability and allowance claim) — 이 시스템을 포함한 모든 공급업체의 것 — 은 날짜가 찍힌 스냅샷으로 취급하세요. 의존성을 구축하기 전에 현재 약관을 직접 확인하고, 그 확인 사항을 게이트 7의 신선도 일정에 포함시키세요.

제한 사항 및 건너뛰어도 되는 경우

• 이 스크립트는 정확성(correctness)이 아닌 존재 여부(presence)를 검증합니다. 잘못된 명령어로 가득 찬 런북은 사전 비행(pre-flight)에는 통과하지만 실습(drill)에서는 실패하게 됩니다. 따라서 둘 다 필요합니다.
• 아무 준비 없이 재현하는 것(blind replay)은 엔지니어 한 명의 반나절을 비용으로 지불하게 합니다. 만약 일주일에 여러 서비스를 배포한다면, 매번 병합(merge)할 때마다 게이트를 거는 대신 월별 단일 슬롯에 배치하세요.
• 이 게이트는 아예 레포지토리에서 재구축될 수 없는 서비스(예: 수동으로 튜닝된 데이터가 있는 상태 저장 박스, stateful box)에는 적합하지 않습니다. 그러한 경우는 런북 검토가 아닌 스냅샷 및 복원 테스트가 필요합니다.
• 팀원이 한 명이고 아직 사용자가 없는 서비스라면 건너뛰세요. 그래도 런북은 작성하되, 실습이 진행된 것처럼 가장만 하지 마세요.

핵심 요약

게이트를 문서로 작성하고, 스크립트를 실행하며, 45분 시간을 예약하고, 로그를 보관하세요. 무료 서버 옵션이 스테이징 환경에서 리허설하는 것을 막아준다면, 그것만을 위해 사용하고 그 이상은 사용하지 마세요.

그리고 가장 중요한 질문 하나만 하세요. 이 시스템을 복원할 다음 사람은 누구이며, 당신 없이도 할 수 있는가?

답변에 대화가 필요하다면, 게이트는 닫힌 것입니다.