원페이지 인시던트 플레이카드: 프로덕션 패닉을 차분한 루틴으로 바꾸는 작은 템플릿

프로덕션이 불이 났다. 페이저가 울린다. 로그는 시끄럽고, 고객은 불만을 터뜨린다. 팀의 절반은 회의 중이고, 누군가는 병가 중이다. 당신은 머릿속으로 애쓴다. “도대체 먼저 뭘 해야 하지? 누가 Slack에 적지? 누가 알람을 확인하지? 누가 지원팀이랑 이야기하지?”

5–10명 규모의 많은 엔지니어링 팀에게 이 순간은 완전히 즉흥극처럼 느껴진다.

대기업이 이런 상황을 다르게 처리한다는 건 알고 있을 것이다. 인시던트 커맨더(Incident Commander), 잘 다듬어진 런북(runbook), 워룸(war room), 포멀한 포스트모텀까지 다 있다. 하지만 이런 프로세스를 작은 팀에 그대로 복사하려 하면 금방 무너진다. 사람도, 시간도, 그만한 무게감의 플레이북을 유지할 여력이 없다.

그래서 등장한 것이 **원페이지 인시던트 플레이카드(One-Page Incident Playcard)**다.

아무도 읽지 않는 40페이지짜리 인시던트 매뉴얼 대신, 한 장짜리 작은 템플릿 하나로 혼란을 차분하고 반복 가능한 루틴으로 바꾼다.

작은 팀도 인시던트 매니지먼트는 필요하다 (하지만 오버헤드는 빼고)

소규모 엔지니어링 팀에서 자주 나오는 말이 있다.

“우린 아직 작은 팀이라 정식 인시던트 프로세스까진 필요 없어요. 그냥 다 같이 콜 들어가서 고치면 돼요.”

이 방식은 딱 한 번은 통한다. 그러다 곧 이런 상황을 맞는다.

• 동시에 두 개의 인시던트가 터진다
• “우리가 원래 이렇게 처리해”라고 알고 있는 단 한 사람이 자고 있거나, 휴가 중이거나, 번아웃 상태다
• 고객이 타임라인이나 설명을 요구하는데, 아무도 그걸 다시 재구성할 수 없다
• “누가 뭘 하고 있는지” 아무도 몰라서 장애가 쓸데없이 길어진다

결과는 뻔하다. MTTA와 MTTR이 늘어나고, 엔지니어는 지치고, 피할 수 있었던 혼란이 반복된다.

그렇다고 대기업 프로세스를 그대로 들여오는 것도 답이 아니다. “인시던트 커맨더”, “커뮤니케이션 리드”, “스크라이브” 같은 롤은 문서 상으론 그럴듯하지만, 6명짜리 팀에선 그게 전부… 한 사람일 수도 있다.

소규모 팀에 필요한 건 더 많은 의식과 형식이 아니라, 아주 얇은 수준의 구조다.

• 인시던트가 시작되었을 때, 처음에 뭘 해야 할지에 대한 명확한 가이드
• 일관된 커뮤니케이션 방식
• “이후에 어떤 순서로 진행되는지”에 대한 공통 기대치
• 인시던트로부터 배움을 얻을 수 있는 가벼운 메커니즘

원페이지 인시던트 플레이카드는 바로 이것을 위해 설계되었다.

원페이지 인시던트 플레이카드란?

원페이지 인시던트 플레이카드는 모든 온콜 엔지니어가 인시던트 동안 사용할 수 있는 단일 표준 템플릿이다.

한 화면 혹은 A4 한 장에 들어간다. 그리고 이렇게 알려준다.

• 처음에 뭘 해야 하는지 (첫 5–10분)
• 그다음에 뭘 해야 하는지 (조사하고 완화 조치를 하면서)
• 마지막에 뭘 해야 하는지 (인시던트를 종료하기 전에)

풀 런북이라기보다는 체크리스트 + 스크립트라고 생각하면 된다. 여러분의 깊은 기술 지식을 대체하는 게 아니라, 스트레스가 높은 순간에 그 지식이 예측 가능한 형태로 발휘되게 도와준다.

이 템플릿은 의도적으로 작게 만들어졌고, 다음과 같이 설계되어 있다.

• 기존 온콜 로테이션에 그대로 꽂아서 쓸 수 있고
• 이미 사용 중인 도구들(Slack, 인시던트 채널, 티켓 시스템, 상태 페이지 등)을 그대로 활용하며
• 심지어 한 사람이 전체 일의 90%를 수행하는 상황에서도 동작한다.

왜 40페이지 플레이북보다 1페이지 템플릿이 더 나은가

원페이지 플레이카드는 너무 단순해 보일 수 있다. 하지만 압박이 큰 상황에선, 단순함이 곧 장점이다.

1. MTTA와 MTTR을 줄여준다

알람이 떴을 때, 우리는 어떻게 생각해야 할지를 고민하고 싶지 않다. 필요한 것은:

• 한 번만 보면 되는 단일 참조 지점
• **"먼저, 그다음, 마지막"**으로 이어지는 명확한 순서
• 프로세스에 대한 최소한의 의사결정

표준화된 플레이카드는 다음을 줄여준다.

• MTTA(Mean Time to Acknowledge, 평균 인지 시간): 누가 인시던트를 소유하는지, 그리고 “acknowledged”가 정확히 무엇을 의미하는지 명확하게 해준다.
• MTTR(Mean Time to Resolve, 평균 복구 시간): 조율 실패와 중복 작업을 줄여준다.

4명이 같은 대시보드를 말없이 들여다보는 대신, 플레이카드는 이런 것들을 상기시킨다.

• 역할을 지정하라
• 무엇을 시도했는지 기록하라
• 침묵 상태를 피하라

2. 작은 팀의 실제 일하는 방식에 잘 맞는다

복잡한 멀티 롤 인시던트 커맨드 시스템이 필요한 게 아니다. 필요한 것은:

• 온콜 담당자가 기본적으로 인시던트를 소유한다
• 필요할 때 다른 사람이 합류한다
• 역할은 한 사람이 여러 개를 맡거나, 여러 사람이 나눠 가질 수 있다

플레이카드는 이런 상황을 전제로 작성되어 있다.

• **한 명의 주요 대응자(온콜)**가 있고
• 한두 명의 헬퍼가 있을 수도 있고
• 모두가 여전히 개발, 테스트, 배포 등 다른 업무를 병행하고 있다

엄격한 구조 대신, 규모에 맞게 늘리거나 줄일 수 있는 최소한의 루틴을 제공한다.

3. 스트레스를 낮추고 예측 가능성을 만든다

인시던트가 스트레스인 이유 중 하나는 모호함 때문이다.

• “지금 누가 책임자지?”
• “어디에서 얘기해야 하지?”
• “누가 지원팀에 알려줬지?”

팀 전체가 같은 원페이지 템플릿을 공유하고 있으면, 모두가 “원래 이렇게 흘러가야 한다”는 공통된 그림을 갖게 된다. 이 공유된 스크립트 덕분에, 영향도는 크더라도 인시던트는 훨씬 차분하게 느껴진다.

원페이지 인시던트 플레이카드 안에는 무엇이 들어가나

바로 가져다 쓸 수 있는 간단한 구조 예시를 살펴보자.

섹션 1: 인시던트 헤더 (빠르게 채우기)

• 인시던트 이름/ID:
• 시작 시간(UTC):
• 리포터 / 알람 소스: (페이저, 고객, 내부 등)
• 온콜 오너: (당신의 이름 – 기본적으로 당신이 소유자)
• 심각도(Severity, S1–S4): (레벨을 하나 선택; 필요하면 정의는 나중에 정리)

이 정보가 이후 모든 것의 기준점이 된다.

섹션 2: 첫 10분 — "안정화하고 드러내기(Stabilize and Surface)"

목표: 인시던트를 인지하고, 눈에 보이는 피해를 최대한 빨리 줄이며, 상황을 투명하게 드러낸다.

체크리스트:

1. 페이징 도구에서 알람을 Acknowledge한다. (여기서 MTTA가 시작된다.)
2. 인시던트 채널을 생성하거나 연결한다. (예: #inc-2025-01-api-latency)
3. 2–3문장짜리 인시던트 요약을 채널에 남긴다.
   • 무엇이 깨졌는가?
   • 누가/무엇이 영향을 받는가?
   • 현재 추정되는 영향 범위는?
4. 임시 역할을 지정한다 (본인이 전부 맡더라도 형식은 유지):
   • 오너(Owner): 의사결정을 내리고, 플레이카드를 업데이트한다
   • 조사자(Investigator): 로그/메트릭을 깊이 파고든다
   • 커뮤니케이션(Comms, 선택): 고객/내부 공지를 작성한다
5. 명백하고 안전한 완화 조치를 적용한다. (예: 마지막 배포 롤백, 서비스 스케일 아웃, 기능 플래그 끄기 등)

섹션 3: 조사와 완화 — "열린 상태로 일하기(Work in the Open)"

목표: 무슨 일이 일어나는지 이해하고, 영향을 최대한 빨리 줄인다.

체크리스트:

1. 주요 액션을 모두 인시던트 채널에 기록한다.
   • 무엇을 시도했는지
   • 무엇을 관찰했는지
   • 가능하면 타임스탬프까지
2. 조용한 디버깅을 피한다. 어떤 발견이든 채널에 공유한다.
3. 초반에는 되돌릴 수 있는 변경을 우선한다. (기능 플래그, 롤백, 특정 컴포넌트만 재시작 등)
4. 실험에 시간 제한(Time-box)을 둔다. X분 안에 효과가 없으면 원복하고 다음 옵션으로 넘어간다.
5. 채널에 **간단한 상태 라인(Status Line)**을 고정해 둔다. 예:
   • "Status: API 지연 시간 증가; v2025.01.01 롤백 중; 다음 업데이트 10분 후"

섹션 4: 커뮤니케이션 — "모두를 같은 그림 위에 올려두기"

목표: 불필요한 소음, 공포, 중복 질문을 줄인다.

체크리스트:

1. 내부 업데이트: 주기를 정한다(예: 15–30분마다) 그리고 반드시 지킨다.
2. 대외(고객) 공지(영향이 실제/가시적인 경우):
   • 누가 상태 페이지(Status Page)에 글을 올리거나 공지를 보낼 것인가?
   • 가장 단순하고 솔직하며, 과도하게 기술적이지 않은 설명은 무엇인가?
3. 단일 정보 출처(Single Source of Truth)를 유지한다. 지원, 프로덕트, 리더십 모두를 개별 DM이 아니라 인시던트 채널 또는 상태 페이지로 안내한다.

섹션 5: 해결 및 종료 — "루프를 닫기"

목표: 인시던트를 명확히 끝내고, 학습을 위한 준비를 한다.

체크리스트:

1. “해결됨(Resolved)”의 기준을 정의한다.
   • 예: 오류율이 15분 이상 기준선으로 회복, 큐가 비워짐, SLO 복구 등
2. 인시던트 채널에 종료 메시지를 남긴다.
   • 무슨 일이 있었는지 (짧게)
   • 무엇이 문제를 해결했는지 (짧게)
   • 후속 작업이 필요한지 여부
3. 후속 티켓을 생성한다.
   • 근본 원인 분석(RCA) / 포스트모텀
   • 영구적인 수정 작업
   • 모니터링/알람 개선
4. 아티팩트에 태그를 단다.
   • 인시던트 채널, 대시보드, PR, 로그 등을 티켓과 링크로 묶어둔다.

이게 전부다. 한 장으로 시작부터 끝까지.

라이브 가이드에서 더 나은 포스트모텀으로

플레이카드는 인시던트 도중에만 도움 되는 것이 아니다. **포스트모텀의 뼈대(scaffold)**로도 그대로 활용된다.

모두가 무엇을 언제 했는지 기록해 두었기 때문에, 포스트모텀에는 자연스럽게 다음이 담긴다.

• 주요 액션의 타임라인
• 무엇이 잘 먹혔고, 무엇이 소용없었는지에 대한 근거
• 빠졌던 알람, 약했던 대시보드, 위험한 배포 패턴에 대한 신호

사실상 플레이카드를 그대로 포스트모텀 아웃라인으로 재사용할 수 있다.

• 처음 무엇을 보았는지 (섹션 1 + 초기 노트)
• 어떻게 대응했는지 (섹션 2–3의 액션)
• 커뮤니케이션이 어떻게 흘렀는지 (섹션 4)
• 무엇이 문제를 해결했는지, 그리고 무엇을 개선할 것인지 (섹션 5 + 후속 작업)

시간이 지날수록 팀은 다음과 같은 변화를 겪는다.

• 완화 패턴을 다듬고
• 알람을 추가/개선하고
• 반복적으로 나타나는 실패 모드를 파악한다

이 모든 것을, 무거운 프로세스를 들이지 않고 해낼 수 있다.

작은 팀에서 원페이지 플레이카드 도입하기

거창한 롤아웃은 필요 없다. 이번 주 안에 시작할 수 있다.

1. 팀 버전의 초안을 만든다. 위 섹션 구조를 사용하되, 사용하는 도구에 맞게 문구를 조정한다.
2. 온콜이 있는 곳에 붙여둔다. 예를 들어:
   • 온콜 런북 최상단
   • #oncall Slack 채널에 고정 메시지
   • PagerDuty / Opsgenie 스케줄 페이지에 링크
3. 짧게 한 번 연습해 본다. 30분짜리 테이블탑(Tabletop) 연습:
   • 가상의 인시던트를 하나 만든다
   • 온콜 담당자가 플레이카드 체크리스트를 따라가며 진행해 본다
   • 헷갈리거나 빠진 부분을 메모하고 수정한다
4. 다음 실제 인시던트에서 바로 써본다. 완벽하지 않게 쓰더라도, 완전한 즉흥 대응보다는 훨씬 낫다.
5. 리뷰하고 다듬는다. 몇 번의 인시던트 후에, 아무도 쓰지 않는 항목은 빼고, 애매한 부분은 명확히 해서 진짜로 한 페이지에 맞춘다.

기억해야 할 것:

목표는 최소하면서도 반복 가능한 구조이지, 모든 것을 다 담은 문서가 아니다.

실제 팀에서 보이는 사용 패턴

원페이지 플레이카드를 잘 정착시킨 팀은 보통 다음과 같이 쓴다.

• 항상 눈에 띄게 둔다 (채널 고정, 인쇄, 북마크 등)
• 크고 작은 모든 인시던트에서 **기본(default)**으로 사용한다
• 온콜 로테이션에 새로 합류한 엔지니어를 위한 교육 자료로 활용한다
• 한 번 만들고 끝내지 않고, 실제 인시던트를 겪으면서 살아 있는 문서로 계속 진화시킨다

이런 팀들이 공통적으로 이야기하는 변화는 다음과 같다.

• “누가 뭘 하고 있지?”라는 순간이 줄어든다
• 알람이 떴을 때 인지가 더 빨라진다
• 인시던트 콜이 더 차분하고, 집중력이 좋아진다
• 포스트모텀을 쓸 때 실제로 무슨 일이 있었는지 더 잘 기억해 낸다

그리고 이 모든 것이, 거의 추가 프로세스 오버헤드 없이 이루어진다.

결론: 관료주의 없는 디시플린

대기업이 아니어도 인시던트를 진지하게 다룰 수 있다. 사실, 소규모 팀일수록 더 높은 수준의 디시플린이 필요하다. 왜냐하면:

• 사람이 적고
• 중복 인력도 거의 없고
• 일정은 더 빡빡하기 때문이다.

실수는, 디시플린이 곧 관료주의라고 가정하는 데서 나온다.

원페이지 인시던트 플레이카드는 다음을 제공한다.

• 즉흥적인 혼돈 대신 작고 반복 가능한 루틴
• MTTA와 MTTR을 낮춰 주는 명확한 단계
• 기존 온콜 로테이션에 자연스럽게 녹아드는 공유된 멘탈 모델
• 더 나은 포스트모텀과 지속적인 개선을 위한 기본 골격

현재 프로세스가 “그때그때 알아서 하는 방식”이라면, 바로 다음 인시던트가 다른 방식을 시도해 볼 완벽한 기회다. 한 장짜리 플레이카드를 도입해, 실제 인시던트 상황에서 함께 따라가 보라. 그러면 대응이 얼마나 더 차분하고 예측 가능해지는지 직접 느끼게 될 것이다.

복잡함은 언제든지 나중에 추가할 수 있다. 하지만 대부분의 팀은 곧 깨닫게 된다. 잘 설계된 1장짜리 문서 하나면, 프로덕션 패닉을 차분하고 자신감 있는 루틴으로 바꾸기에 충분하다는 사실을.