손글씨 런북 난간: 모든 배포 위에 놓이는 한 장짜리 아날로그 안전망 만들기

요즘 배포 도구는 매끄럽고, 자동화되어 있고, 빠릅니다. 하지만 문제가 터지는 순간, 아무도 당신의 CI/CD YAML 파일을 열어보지 않습니다. 사람들이 찾는 건 단순하고, 눈에 잘 들어오고, 사람 냄새 나는 무언가입니다.

그게 바로 손글씨 한 장짜리 배포 런북입니다. 이걸 모든 배포 위에 설치된 **발코니 난간(balcony rail)**이라고 생각해 보세요. 떨어지기 전에 잡을 수 있는 물리적인 안전망이자, 프로덕션 장애의 첫 몇 분을 팀이 어떻게 헤쳐 나갈지 안내해 주는 가이드입니다.

이 글에서는 이 한 장짜리 아날로그 런북을 어떻게 설계하고, 배포 전 체크리스트와 짝지어 사용하며, 기존 온콜·인시던트 대응 프로세스와 어떻게 촘촘히 연결할지 살펴봅니다.

왜 한 장짜리 아날로그 안전망이 필요한가

디지털 문서는 중요합니다. 하지만 스트레스 상황에서는 우리를 종종 배신합니다.

• 지금 최신 내용이 적힌 Confluence 페이지가 어느 건지 기억이 안 납니다.
• 대시보드와 위키는 이미 어디를 봐야 하는지 알고 있다는 전제를 깔고 있습니다.
• 당황하면 검색어조차 제대로 떠오르지 않습니다.

손글씨, 인쇄된, 한 장짜리 런북은 이런 걸 그냥 뚫고 들어갑니다.

• 항상 눈에 보입니다: 팀 자리 옆 벽, 모니터 옆, 화이트보드에 붙여둘 수 있습니다.
• 스트레스 상황에서도 바로 훑어볼 수 있습니다: 큰 제목, 짧은 불릿, 스크롤 없음.
• 의도적으로 제한적입니다: 가장 핵심적인 단계와 연락처만 담습니다.

이 한 장은 전체 문서를 대체하기 위한 게 아닙니다. 최악의 순간, 즉

“뭔가 망가졌다. 지금 당장 뭘 해야 하지?”

라고 말하게 되는 바로 그 시점을 위한 출발 지도입니다.

1. 강력하고 직관적인 ‘랜딩 섹션’부터 만들기

페이지 상단 1/3은 양보할 수 없는 핵심 영역입니다. 비상구 안내도에서 "당신은 여기 있습니다(You are here)"라고 표시된 부분이라고 생각하세요.

맨 위에는, 크게, 손으로 이렇게 적습니다.

"이 배포가 잘못되면, 지금 즉시 이렇게 하세요"

그 아래에는 극도로 명확한 세 개의 소섹션을 둡니다.

a) 누구에게, 어떻게 연락할 것인가

돌려 말할 여지 없는 사람 연락 경로를 적습니다.

• 1차 온콜 엔지니어: 이름 / 전화번호 / Slack 핸들
• 백업 온콜 / 에스컬레이션 대상: 이름 / 연락처
• 인시던트 커맨더(사용 중인 경우): 어떻게 호출·할당하는지

“온콜 스케줄 참조” 같은 말 대신, 실제 사람 이름과 직접적인 연락 수단을 적어야 합니다. 아드레날린이 치솟는 상황에서는 캘린더를 탐색하는 것조차 부담입니다.

b) 가장 먼저 어디를 볼 것인가

도구 목록을 나열하지 마세요. 출발점이 될 3~5개만 우선순위로 정합니다.

• 주요 모니터링 대시보드 URL
• 에러 로그 조회 시작점 (예: 미리 저장해 둔 쿼리 링크)
• 피처 플래그 콘솔 (플래그로 롤백하는 경우)
• 현재 배포 상태를 보는 릴리즈 대시보드

각 항목에는 목적을 함께 적습니다.

• “1단계: API 에러율 확인 – Grafana: api-prod 대시보드”
• “2단계: 사용자 영향도 있는 장애 확인 – 내부 Statuspage 뷰”

c) 불이 났을 때 바로 실행할 첫 3단계

이 부분은 이분법적이고, 행동 지향적이어야 합니다.

1. 추가 배포를 중단한다 (방법 예: 파이프라인 비활성화 / 해당 릴리즈 ‘blocked’로 표시)
2. 사용자 경험을 안정화한다 (예: 롤백, 플래그 오프, 트래픽을 안정 버전으로 우회)
3. 표준 인시던트 채널에 사고를 공지한다 (링크 또는 채널 이름 명시)

이 3단계는 막 온콜을 시작한 신입 엔지니어도 토를 달 필요 없이 그대로 따라 할 수 있게 적어야 합니다.

2. 온콜·인시던트 대응 도구와 통합하기

이 아날로그 런북은 따로 노는 문서가 아닙니다. 디지털 도구들로 들어가는 **정문(front door)**입니다.

페이지 위에 다음을 명확히 적어둡니다.

• 온콜 호출 방법: “PagerDuty 사용: #incidents 채널에서 /pd assign 사용”
• 인시던트 기록 위치: “Slack에서 /incident로 Incident.io 인시던트 생성”
• 인시던트 타임라인이 저장되는 곳: “모든 업데이트는 #incidents Slack 채널에 기록”

목표는 에스컬레이션에 대한 모호성을 없애는 것입니다. 이 런북은 다음 질문에 답해 줄 수 있어야 합니다.

• “이 정도면 인시던트를 열어야 하나?” → 페이지에 단순한 기준(임계치) 규칙 명시.
• “내가 하고 있는 일을 어디에 적지?” → 한 곳, 이름이 명확한 시스템과 채널을 지정.
• “롤백 여부를 누가 결정하지?” → “인시던트 커맨더” 또는 “온콜 SRE”처럼 역할을 분명히 명시.

도구가 바뀌면(PagerDuty → Opsgenie 등) 반드시 페이지를 수정하고 다시 출력해야 합니다. 이 아날로그 한 장은 항상 현재 운영 현실을 반영해야 합니다.

3. 간결한 배포 전 체크리스트와 짝지어 쓰기

페이지 하단(또는 뒷면)은 배포 체크리스트, 즉 비행 전 점검표입니다.

이건 그럴듯한 할 일 목록이 아닙니다. 이것은 게이트입니다. 체크박스에 표시가 없으면, 배포도 없습니다.

구조는 세 부분으로 나눕니다.

a) 릴리즈 준비 상태

• 변경 내용 검토 완료: “무엇이 왜 나가는지 이해했다.”
• 블라스트 레디우스(영향 범위) 검토: “최악의 경우 무엇이 일어나며, 누가 영향을 받는가?”
• 롤백 전략 명확: “안전하게 되돌릴 수 있으며, 소요 시간도 알고 있다.”

b) 운영 환경 점검

• 모니터링 준비 완료: 신규·변경 컴포넌트에 대한 메트릭과 로그가 구성되어 있다.
• 알람 튜닝 완료: 배포가 잘못되면 실제로 그걸 감지할 수 있다.
• 피처 플래그(사용하는 경우) 설정 완료: 안전하게 토글할 수 있는 상태.

c) 사람·커뮤니케이션

• 온콜 담당자 인지 완료: 문제가 생기면 받을 사람에게 미리 공유했다.
• 적절한 변경 윈도우 선택: 피크 트래픽, 대형 이벤트 등 위험 시간이 아님.
• 고위험 배포 시 이해관계자 사전 공지: 예: 고객 지원, PO(프로덕트 오너).

체크리스트는 1분 안에 다 읽을 수 있을 정도로 짧게 유지해야 합니다. 길어지면 사람들은 형식적으로만 체크하게 됩니다.

4. 품질 보증(QA) 게이트를 체크리스트에 녹여 넣기

일반적인 항목 외에, 체크리스트에는 명시적인 QA 게이트도 포함해야 합니다.

a) 스테이징 검증

• 스테이징 배포 완료 및 성공 확인.
• 핵심 플로우 스테이징 테스트 완료 (3~5개 핵심 플로우를 이름으로 명시: “회원가입”, “결제”, “비밀번호 재설정” 등).
• 스테이징 환경이 프로덕션과 충분히 유사함 (특히 변경된 컴포넌트에 대해: 피처 플래그, 설정 값 등).

스테이징 환경이 없다면, 그 사실을 명시합니다. 예: “스테이징 없음; 위험이 낮은 테스트 계정으로 프로덕션에서 스모크 테스트 진행.” 모호하게 두지 마세요.

b) 동료 검토(Peer Review)

• 코드 동료 리뷰 완료 (리뷰어 이름 또는 이니셜 작성).
• 위험한 마이그레이션·스키마 변경은 시니어 엔지니어가 재검토 완료.

체크박스 옆에 실제로 이니셜을 적는 행위 자체가, 리뷰를 건너뛰는 것에 대한 사회적 마찰을 만들어 줍니다.

c) 릴리즈 후보(Release Candidate) 확인

이번 배포에 포함되는 내용을 명시적으로 적습니다.

• 포함 티켓: PROJ-123, PROJ-456, BUG-789 등.
• 검토되지 않은 티켓이 끼어들지 않음: (예: 메인 브랜치에 슬쩍 섞인 예상치 못한 커밋 금지).

이 과정은 이번 배포가 단순히 “지금 메인 브랜치에 올라와 있는 것 전부”가 아니라, 의도적으로 구성된 릴리즈 후보임을 확인하는 절차입니다.

5. 아날로그, 손글씨, 그리고 ‘눈에 띄게’ 유지하기

이 런북의 힘은 상당 부분 손에 잡히는 실물이고 항상 눈에 띈다는 점에서 나옵니다.

손글씨가 중요한 이유

• 의도적인 편집을 강제합니다. 손으로 쓰다 보면 자연스럽게 정말 필요한 것만 남깁니다.
• 더 “진짜” 같고, 사람 손이 닿은 느낌이라 사람들이 더 신뢰하고 사용하게 됩니다.
• 아무도 손으로 5페이지 에세이를 쓰고 그걸 벽에 붙이지 않습니다. 과도한 최적화를 억제합니다.

어디에 붙일 것인가

• 팀이 주로 일하는 공용 공간 근처 벽에 인쇄해서 붙입니다.
• 온콜용 노트북 옆에 테이프로 붙여 둡니다.
• 인시던트 발생 시 모이는 워룸·회의실에도 몇 부 비치합니다.

TIP: 굵은 매직, 큰 제목, 넉넉한 여백을 사용하세요. 이건 시각적인 아티팩트이지, 빽빽한 소설책이 아닙니다.

6. 모든 인시던트·포스트모템마다 개정하기

첫 버전은 분명히 어딘가 틀릴 겁니다. 그건 자연스러운 일입니다. 이 런북은 실패를 거치며 계속 진화할 때 비로소 가치가 생깁니다.

인시던트나 아슬아슬한 배포가 끝난 뒤에는 이렇게 물어보세요.

• “우리가 페이지에 있었으면 좋았을 것이라고 느낀 건 무엇인가?”
• “페이지의 어느 부분을 무시했는지, 그리고 왜 그랬는지?”
• “어디에서 여전히 시간을 낭비하거나 막혔는지?”

그리고 다음을 실행합니다.

1. 페이지를 손으로 업데이트한다.
2. 날짜를 명확히 적는다: 예: “Version: 2026-02-25.”
3. 다시 인쇄해 기존 버전을 교체한다.

포스트모템에서는 다음도 꼭 확인합니다.

• 이 배포 전에 체크리스트를 실제로 따라 했는가?
• 인시던트 중에 런북의 랜딩 섹션을 사용했는가?
• 연락처·도구 정보가 오래되진 않았는가?

이 런북은 팀이 겪는 실제 실패 패턴의 살아 있는 아티팩트입니다. 시간이 지날수록, 시스템이 실제로 어떻게 고장 나고, 팀이 실제로 어떻게 효과적으로 대응하는지에 대한 가장 솔직한 기록이 됩니다.

마무리: 전부 한데 모아보기

강력한 한 장짜리 배포 런북은 다음 특징을 가집니다.

• 모든 배포 위에 물리적으로 놓여, 항상 눈에 보이는 프롬프트 역할을 한다.
• 모든 게 망가졌을 때 사용할 명확한 랜딩 섹션을 제공한다.
• 온콜·인시던트 도구와 직접 연결되어 혼란을 줄인다.
• 구체적인 QA 게이트를 포함한 배포 전 체크리스트를 강제한다.
• 짧고, 손글씨이고, 스트레스 상황에서도 쉽게 쓸 수 있게 유지된다.
• 실제 인시던트·포스트모템을 통해 지속적으로 개정된다.

배포 안정성을 높이기 위해 복잡한 새 플랫폼이 꼭 필요한 건 아닙니다. 필요한 건 펜 한 자루, 프린터 한 대, 그리고 인시던트마다 이렇게 자문하는 습관입니다.

“그때 우리 눈앞에 뭐가 있었으면 좋았을까?”

그걸 적으세요. 벽에 붙이세요. 다음 배포가 흔들릴 때 팀이 붙잡을 수 있는 발코니 난간으로 만드세요.