아날로그 인시던트 침대칸: 온콜 엔지니어가 진짜로 잘 수 있게 만드는 종이 플레이북 설계법

현대 인프라는 끝까지 디지털화되어 있습니다. 그런데 역설적으로, 온콜을 버티게 해주는 가장 강력한 도구는 또 하나의 대시보드나 봇, 알람 규칙이 아니라 종이 체크리스트에 가까운 것일 때가 많습니다.

온콜 시스템을 야간 열차라고 생각해 봅시다. "침대칸(sleeper car)"은 사람들이 정차 사이사이에 실제로 쉴 수 있는 공간입니다. 인시던트 프로세스가 엔지니어가 완전히 손을 떼고 자고 회복할 수 있도록 설계되어 있지 않으면, 자동화가 얼마나 똑똑하든 상관없이 결국 사람을 소진시키고 장기적으로는 안정성도 무너집니다.

이 글에서는 그런 "아날로그 침대칸"을 설계하는 방법을 다룹니다. 인시던트를 더 빨리 해결하는 것뿐 아니라, 온콜 엔지니어가 현실적으로 잘 수 있게 만들어 주는, 단순한 종이 스타일 플레이북을 만드는 방법입니다.

우리가 다룰 내용은 다음과 같습니다.

휴식이 설계에 포함되도록 온콜 스케줄을 짜는 방법
인시던트 부담을 제한해 온콜이 끝없는 두더지 잡기가 되지 않게 하기
맥락이 개인 머릿속에만 남지 않도록 핸드오프를 표준화하기
처음부터 방대한 라이브러리가 아니라, 소수의 고임팩트 런북부터 시작하기
런북을 문서가 아니라 코드처럼 다루기
정말 필요할 때 인지 부하를 줄여 주는 체크리스트 활용법
근무가 끝난 뒤 남는 "주의 잔여(attention residue)"를 의도적으로 최소화하기

1. 정말로 ‘잠’을 신경 쓰는 스케줄을 설계하라

엉망인 온콜 스케줄은 아무리 좋은 플레이북으로도 가릴 수 없습니다. 먼저 부담을 사람답게 만들기부터 시작해야 합니다.

주간 로테이션 또는 Follow‑the‑Sun을 우선 검토하라

수면을 지키는 데 특히 효과적인 패턴은 두 가지입니다.

주간(weekly) 로테이션: 한 명의 1차 온콜이 일주일 단위로 담당하고, 2차 온콜이 백업으로 서는 방식
- 장점: 책임이 명확하고, 핸드오프가 적으며, 개인 생활 계획 세우기 쉽다.
- 단점: 가드레일(예: 인시던트 수 제한, 적절한 에스컬레이션)이 없으면 그 주가 지옥주가 되기 쉽다.
Follow‑the‑Sun 로테이션: 각 리전 팀이 해당 지역의 주간(일반 근무시간)만 온콜을 담당하는 방식
- 장점: 새벽 3시 알람이 줄고, 이미 깨어 있는 시간대에 더 많은 인시던트를 처리할 수 있다.
- 단점: 글로벌 커버리지를 뒷받침할 인력이 필요하고, 깔끔한 핸드오프가 필수다.

하이브리드 모델도 가능합니다. 예를 들어, 비즈니스 크리티컬 서비스는 Follow‑the‑Sun으로, 그 외는 글로벌 백업 온콜을 두는 식입니다. 핵심은 “어딘가에 누군가는 깨어 있겠지”라고 막연히 기대하는 대신, 진짜 수면이 포함된 모델을 의도적으로 선택하는 것입니다.

한 번의 근무(shift)에서 처리할 인시던트 수에 상한을 두어라

로테이션이 아무리 좋아도, 한 사람이 알람에 파묻히면 그대로 무너집니다.

한 셰프트에서 감당 가능한 인시던트 최대치를 명시하세요. 예를 들어:

"엔지니어 1인당 12시간 셰프트에 P1/P2 인시던트는 최대 3건까지"
"야간에 발생하는 모든 알람(심각도 무관)은 10회 페이지를 넘기지 않도록"

누군가 이 임계치를 넘기면 다음을 수행합니다.

해당 인시던트를 자동으로 다른 엔지니어 또는 온듀티 매니저에게 에스컬레이션
가능하다면 우선순위가 낮은 인시던트를 재할당
왜 부하가 급증했는지 사후 분석 티켓을 생성

이런 상한은 "이론상으로는 잘 수 있다"가 아니라, 실제로 인시던트 사이에 잠깐이라도 잘 수 있게 만들어 줍니다.

2. 핸드오프를 표준화해 맥락이 머릿속에만 남지 않게 하라

온콜이 고통스러운 가장 큰 원인 중 하나는 어설프게 기억나는 맥락 때문입니다.

"롤백은 이미 시도했었나? 왜 이 플래그는 꺼져 있지? APAC 팀은 전에 뭐 했지?"

새벽 3시에 기억력에 의존하는 건 감당할 수 없는 세금입니다.

단순하고 반복 가능한 핸드오프 의식을 만들어라

셰프트 교대마다 항상 같은 패턴을 따르도록 합니다. 예를 들어:

필수: 서면 업데이트
- 진행 중인 인시던트, 현재 상태, 담당자
- 알려진 워크어라운드 또는 임시 완화 조치
- 시도했던 것과 효과 없었던 것
- 시간에 민감한 후속 작업
가급적 필수: 짧은 구두 싱크
- 10–15분 정도 서면 업데이트를 함께 훑으며 설명
- 애매한 부분 명확히 하기
단일 소스 오브 트루스(Single Source of Truth)
- 핸드오프 메모를 남길 공식 채널(런북, 문서, 인시던트 툴 중 하나)을 정합니다.
- Slack, 이메일, 개인 노트 등 여러 군데에 맥락이 흩어지지 않게 합니다.

템플릿을 사용하라

프리폼으로 쓰게 두지 마세요. 구조화된 핸드오프 템플릿은 마찰과 추측을 줄여 줍니다.

예시 필드:

인시던트 ID / 링크
현재 상태 (Degraded / Mitigated / Investigating / Resolved 등)
다음에 할 구체적인 액션
다음 액션 담당자
Known unknowns (아직 이해되지 않은 것들)
리스크 / 주의할 포인트

표준화를 많이 할수록, 해당 시점에 누가 근무 중인지, 얼마나 피곤한지에 프로세스 품질이 덜 의존하게 됩니다.

3. 처음부터 거대한 런북 라이브러리를 만들려고 하지 말고, 2–3개부터 시작하라

모든 것에 런북을 달고 싶을 수 있습니다. 에러 코드 하나하나, 엣지 케이스마다, 알람마다. 하지만 그렇게 하면 아무도 믿지 않고 쓰지도 않는 거대한 위키만 남게 됩니다.

대신 의도적으로 작게 시작하세요.

처음 만들 2–3개의 플레이북을 고르기

다음 중에서 선택합니다.

가장 자주 발생하는 인시던트 유형 (예: 캐시 포화, 디스크 풀, 메모리 누수 등)
가장 영향도가 큰 인시던트 유형 (예: 결제/체크아웃 장애, 인증 시스템 장애 등)

각 유형마다, 플레이북이 다음 세 가지 질문에 답하도록 작성합니다.

이게 발생하면 어떻게 보이는가?
어떤 증상과 알람이 나는지, 자주 보는 대시보드는 무엇인지.
가장 안전한 첫 액션은 무엇인가?
어느 정도 훈련된 엔지니어라면 사태를 악화시키지 않고 시도할 수 있는 상위 3–5가지 조치.
언제 에스컬레이션해야 하는가?
언제 더 많은 사람을 깨워야 하는지, 혹은 특정 도메인 전문가를 호출해야 하는지에 대한 명확한 기준.

모든 경우의 수를 망라한 완벽한 트리 구조는 필요 없습니다. 지금 필요한 건 우왕좌왕과 패닉을 막아 주는, 안전하고 신뢰할 수 있는 출발점입니다.

4. 런북을 정적인 문서가 아니라 코드처럼 다뤄라

죽은 문서는 없는 것만 못합니다. 사람들은 곧 믿지 않게 됩니다.

런북은 코드처럼 관리해야 합니다.

버전 관리 시스템(Git 등, 이미 쓰고 있는 것)을 사용합니다.
코드 리뷰처럼, 변경에는 리뷰를 필수로 붙입니다.
작성자와 변경 이력을 추적해 궁금한 점이 생기면 누구에게 물어봐야 하는지 알 수 있게 합니다.

실제 인시던트에 기반해 계속 개선하라

큰 인시던트 하나가 끝나면, 최소한 다음 중 하나는 반드시 남아야 합니다.

새롭게 관찰한 패턴에 대한 새 런북 추가
기존 런북의 업데이트:
- 더 빠른 진단 명령 추가
- 애매한 문구를 명확하게 수정
- 새로운 완화책이나 안전한 롤백 절차 문서화

인시던트 리뷰 템플릿에 “플레이북/런북 업데이트”를 필수 항목으로 넣으세요. 리뷰가 런북 개선으로 이어지지 않는다면, 배운 것 중 일부를 그냥 버린 셈입니다.

5. 아날로그로 돌아가라: 고위험 작업에는 종이 스타일 체크리스트를 써라

파일럿과 외과의사가 체크리스트를 쓰는 이유는 미숙해서가 아니라, 스트레스 상황에서 작업 기억(working memory)이 매우 취약하기 때문입니다.

대형 인시던트 중에는:

잠이 부족하고,
Slack, 대시보드, 커맨드, 이해관계자 커뮤니케이션을 동시에 처리해야 하며,
불완전한 정보 속에서 시간에 쫓겨 결정을 내려야 합니다.

바로 이런 상황에서 "아날로그" 체크리스트가 빛을 발합니다.

좋은 인시던트 체크리스트의 모습

간단하고, 시각적이며, 실전 위주여야 합니다. 예를 들어:

P1 인시던트 트리아지 체크리스트 (처음 10분)

알람이 진짜인지 확인한다 (주요 SLO / 핵심 지표를 확인).
인시던트를 인시던트 관리 도구에 공식 선언한다.
역할을 할당한다: 인시던트 커맨더, 커뮤니케이션 담당, 서기(scribe).
#incidents 채널에 현재 상태를 포스트한다:
- 영향 범위(impact)
- 영향 대상(누가 / 무엇이 영향 받는지)
- 시작 시점(또는 최초 감지 시간)
관련 런북에서 가장 리스크가 낮은 완화 조치를 시도한다.
계속 완화할지, 롤백할지, 추가 에스컬레이션할지 결정한다.

이걸 실제로 프린트해서 책상 근처에 붙여 두거나, 한 페이지짜리 문서로 만들어 바로 띄울 수 있게 해도 좋습니다. 핵심은, 절차를 기억하는 부담을 체크리스트가 대신 지게 하고, 엔지니어는 판단력과 상황 인식에 집중하게 만드는 것입니다.

체크리스트를 적용하기 좋은 영역

P1/P2 인시던트 트리아지
데이터베이스 페일오버 또는 롤백
하이리스크 릴리스에 대한 피처 플래그 롤백
법적/규제적 의미가 있는 데이터 보존·삭제 작업

반복되면서도 실수가 치명적인 작업이라면, 체크리스트 후보입니다.

6. 분리를 전제로 설계하라: 근무 후 ‘주의 잔여’를 최소화하라

야간 알람을 줄이고, 런북을 개선해서 당장의 수면 문제를 해결했다 해도, 더 미묘한 문제가 남아 있습니다. 바로 **주의 잔여(attention residue)**입니다.

이는 셰프트가 끝난 뒤에도 남는 정신적 끌림입니다. 예를 들어:

방금 있었던 인시던트를 계속 머릿속에서 되감기
뭔가 빼먹은 건 아닌지 걱정
또 터지면 어떻게 하지 하는 불안

진짜로 회복하려면, 엔지니어가 **정신적으로 퇴근(clock out)**할 수 있어야 합니다. 침대칸 플레이북은 이것까지 지원해야 합니다.

“셰프트 랜딩(shift landing) 체크리스트”를 만들어라

간단한 근무 종료 체크리스트가, 머릿속에서 열린 루프를 닫는 데 큰 도움이 됩니다.

모든 진행 중인 인시던트에는 명시된 담당자(owner)가 있다.
핸드오프 메모가 공식 채널에 작성·공유되었다.
"이건 기억해 둬야겠다" 싶은 잔여 메모는 모두 티켓이나 문서에 옮겨 적었다.
개인 메모(스크래치 노트, 노트북 등)는
- 시스템으로 옮겼거나,
- 더 이상 신경 쓰지 않아도 괜찮다고 명시적으로 표시했다.
간단한 셀프 체크: 아직 마음에 걸리는 게 있는가? 있다면, 글로 남기고 핸드오프한다.

목표는 엔지니어가 이렇게 말할 수 있게 만드는 것입니다.
“내가 아는 건 다 어딘가 안전한 곳에 적혀 있고, 누군가가 책임지고 있다. 이제 놓아도 된다.”

경계(boundary)를 문화로 정착시켜라

이걸 문화와 정책으로 뒷받침하세요.

셰프트가 끝난 사람의 인시던트 채널 눈팅(lurking)을 오히려 말리기
매니저가 근무를 마친 온콜 엔지니어에게 “딱 하나만 물어볼게요” DM을 보내지 않게 하기
영웅적인 밤샘보다는, 프로세스를 잘 따르고 제대로 연결을 끊는 사람을 인정하고 칭찬하기

휴식은 사치가 아니라, 신뢰성과 품질을 위한 필수 요건입니다.

마무리: 모든 조각을 한데 모으면

"아날로그 인시던트 침대칸"을 설계한다는 건 종이가 좋다는 향수의 문제가 아닙니다. 인간의 한계를 전제로 한 인시던트 시스템을 설계하는 일입니다.

사람은 자야 한다는 전제를 둔 스케줄
한 명의 엔지니어가 갈려 나가지 않도록 하는 인시던트 상한
새벽 3시의 기억력에 의존하지 않는 핸드오프
실제로 사용되는, 작고 집중된 런북 세트
먼지 쌓인 매뉴얼이 아닌, 살아 있는 코드처럼 다루는 런북
스트레스 상황에서 작업 기억을 비워 주는 단순한 체크리스트
사람들로 하여금 진짜로 머리를 비우고 퇴근하게 해 주는 셰프트 종료 의식

이 조각들을 제대로 쌓으면, 더 행복한 엔지니어만 얻는 게 아닙니다. 더 나은 인시던트 대응을 얻게 됩니다. 스트레스 환경에서도 더 명료한 사고, 더 빠른 완화, 각 장애에서 더 많은 학습을 끌어낼 수 있습니다.

인프라는 복잡하고 디지털일지 몰라도, 온콜 경험은 여전히 아날로그 마인드셋의 혜택을 크게 볼 수 있습니다. 영웅담은 줄이고, 체크리스트는 늘리고, 페이지 사이에 사람답게 잘 수 있는 조용한 시간을 확보하는 것입니다.

그게 인시던트 대응에서의 진짜 침대칸이며, 의도적으로 설계할 가치가 충분히 있습니다.