아날로그 인시던트 분필 철도

대시보드를 하나라도 열기 전에 그려보는 일회용 위기 지도

요즘 인시던트는 수십 개의 대시보드, 로그, 메트릭, 채팅 창을 오가며 진행됩니다. 아이러니하게도, 위기의 첫 몇 분 동안 이런 도구들이 오히려 여러분을 더 느리게 만들 수 있습니다. 사람들은 탭을 옮겨 다니며 중복 작업을 하고, 서로 다른 얘기를 하며 엇갈립니다.

여기서 등장하는 개념이 바로 **아날로그 인시던트 분필 철도(Analog Incident Chalk Railway)**입니다.

대시보드를 하나도 열기 전에 그려 보는, 저기술·일회용 위기 지도라고 생각하면 됩니다. 장애가 났을 때 사람, 플레이북, 시스템이 어떻게 연결되는지 미리 설계해 두는 방식입니다. 그래서 실제 장애 시에는 달리는 기차 아래에 급히 선로를 까는 게 아니라, 이미 깔려 있는 선로를 따라가게 됩니다.

이 글에서는 효과적인 인시던트 대응이 왜 장애 훨씬 이전에 시작되는지, 조직에 맞는 ‘분필 철도’를 어떻게 만드는지, 그리고 SRE 원칙을 비상시에만 꺼내 쓰지 않고 평소 개발 업무 속에 어떻게 녹여 넣을 수 있는지 살펴봅니다.

사이렌이 울리기 한참 전에 시작되는 인시던트 대응

알람이 울렸을 때, 그제야 다음과 같은 질문에 답하고 있다면 늦은 겁니다.

• 누가 총괄 책임자(Incident Commander)인가?
• 누가 이 서비스를 재시작할 수 있는가?
• 누가 고객과 소통하는가?
• 누가 이 변경 사항을 롤백할 수 있는가?
• 누가 데이터베이스를 건드릴 수 있는가?

이걸 실시간으로 알아내고 있다면, 여러분은 인시던트 대응을 하는 게 아니라 압박 속에서 조직 설계를 하고 있는 것입니다.

고성과 SRE 팀은 이 사실을 잘 알고 있습니다. 그들의 속도는 영웅적인 개인 플레이에서 나오지 않습니다. 대부분 사전에 해 둔 계획과 설계에서 나옵니다.

• 무엇이 “나쁜 상태”인지 미리 합의합니다 (SLI/SLO, 알람 기준).
• 나쁜 상태일 때 무엇을 할지 정의합니다 (플레이북).
• 누가 무엇을 책임지는지 정합니다 (역할과 책임).
• 이 모든 동작을 연습합니다 (인시던트 드릴, 게임데이).

다시 말해, 인시던트는 장애 몇 주, 몇 달 전부터 시작됩니다. 실제 일은 선로를 까는 일입니다.

아날로그 인시던트 분필 철도는 이 준비 과정을 위한 정신적·물리적 모델입니다.

아날로그 인시던트 분필 철도란 무엇인가?

화이트보드, 종이 한 장, 혹은 진짜 칠판을 떠올려 보세요.

그 위에 다음을 그립니다.

• 선로(Tracks): 문제가 생겼을 때 밟게 될 행동의 순서
• 역(Stations): 핵심 의사결정 지점과 주요 시스템(API, 서비스, 큐, 데이터베이스 등)
• 분기기(Switches): 대체 경로 (롤백 vs 핫픽스, 페일오버 vs 트래픽 제한 등)
• 신호(Signals): 지금 무슨 일이 일어나는지 확인해 주는 알람, 대시보드, 로그

이것이 인시던트가 조직 안에서 어떻게 흘러가는지 보여주는 아날로그 지도입니다.

1. 누가 가장 먼저 페이지를 받는가?
2. 누가 인시던트 커맨더(IC)가 되는가?
3. 어떤 시스템을 어떤 순서로 점검하는가?
4. 누가 롤백·페일오버·외부 커뮤니케이션의 권한을 가지는가?
5. 어디서 “종료(올 클리어)”를 선언하고, 그 선언은 누가 책임지는가?

이 그림은 빠르게 그립니다. 마음껏 지우고 고칩니다. 일부러 일회용으로 만드는 이유는 사람들이 부담 없이 변경을 제안할 수 있게 하기 위해서입니다.

이 분필 지도가 충분히 말이 된다고 느껴진 다음에야 티켓, 런북(runbook), Slack 채널, 대시보드 등으로 옮겨 담습니다.

미리 정해 두는 플레이북: 당황하기 전에 결정하기

가장 빠르고 침착한 대응자들은 기초적인 것들을 즉흥으로 하지 않습니다. 그들은 사전에 정의된 플레이북에 의존합니다.

좋은 플레이북은 세 가지 질문에 답합니다.

1. 무엇을 할 것인가?
2. 누가 할 것인가?
3. 어떻게 협업·조율할 것인가?

분필 철도는 이 답을 위키 문서 한 줄 쓰기 전에 시각적으로 설계하도록 도와줍니다.

예시: 웹 장애를 위한 간단한 분필 철도

화이트보드 위에 다음과 같이 그려 봅니다.

• 알람 발생: “5xx 에러율이 5분 이상 5% 초과”
• 역 1 – 온콜 SRE:
  • 알람이 실제인지 확인 (테스트·오탐 여부 확인).
  • 인시던트 채널에 인시던트 선언.
  • 본인이 IC가 되거나 IC를 지정.
• 역 2 – IC:
  • Technical Lead(기술 리드) 지정: “당신이 진단 책임자입니다.”
  • Comms Lead(커뮤니케이션 리드) 지정: “당신이 이해관계자 업데이트를 책임집니다.”
• 역 3 – Technical Lead:
  • 최근 3건의 배포 내역 확인.
  • 상위 의존 시스템 상태 확인 (DB, 인증, 결제 등).
  • 롤백을 할지, 더 깊은 디버깅을 할지 결정.
• 역 4 – Comms Lead:
  • 10분 이내 내부 공지.
  • 사용자 영향이 확인되면 15분 이내 상태 페이지(Status Page) 업데이트.

이렇게 보드에 그려 놓고 나면, 다음을 물어볼 수 있습니다.

• 빠진 것은 없는가?
• 책임이 겹치는 부분은 없는가?
• 누군가에게 일이 과도하게 몰리지는 않는가?
• 다음 분기쯤 자동화할 수 있는 단계는 어디인가?

사람들이 동의하면, 그제서야 이 흐름을 정식 플레이북으로 문서화합니다.

소유권: 혼란을 막는 해독제

인시던트는 기술 때문에 망하는 경우보다 모호함 때문에 망하는 경우가 훨씬 더 많습니다.

• 두 사람이 동시에 자기 자신이 IC라고 생각합니다.
• 아무도 리더십에게 상황을 보고해야 한다는 걸 모릅니다.
• 다섯 사람이 같은 증상을 서로 다른 다섯 개의 대시보드에서 디버깅합니다.

분필 철도는 이런 상황을 막기 위해 소유권을 명시적으로 강제해야 합니다.

• 각 “역(station)”에는 하나의 소유 역할만 둡니다 (IC, Tech Lead, Comms, SRE 온콜, DB 온콜 등).
• 소유권은 단순 행동이 아니라 **결정(decision)**에 대한 책임입니다.
• 당사자가 자고 있거나 휴가 중이거나 과부하일 때를 대비해 백업 역할까지 문서화합니다.

목표는 관료주의를 늘리는 것이 아닙니다. 뇌가 스트레스를 받는 순간에도 명료함을 유지하는 것입니다.

시간대와 기술 스택을 가로지르는 조율 설계

현대 시스템은 다음과 같은 특성을 갖습니다.

• 여러 리전·여러 시간대에 걸쳐 분산되어 있고,
• 이질적인 스택(Kubernetes, 서버리스, 레거시 VM, 매니지드 DB 등)으로 구성되어 있으며,
• 혼합된 팀 구성(SRE, 플랫폼 팀, 기능 개발 팀, 외부 벤더)이 지원합니다.

이 네트워크를 인시던트 도중에 즉흥적으로 맞춰 가는 것은 불가능합니다.

분필 철도를 이용해 다음을 설계해 보세요.

1. Follow-the-sun 소유권

   • APAC, EMEA, 미주 시간대 각각에서 누가 인시던트를 책임지는가?
   • 인시던트가 교대 시간을 넘길 때, 핸드오버(인수인계)는 어떻게 이뤄지는가?

2. 도메인별 에스컬레이션 경로

   • DB 레이어는 누가 책임지는가? 네트워크는? 인증? 결제? CI/CD는?
   • 해당 팀의 1차 온콜이 응답하지 않을 때는 어떻게 하는가?

3. 표준 커뮤니케이션 채널

   • 인시던트당 하나의 공식 인시던트 채널.
   • 상태에 대한 단일 소스 오브 트루스(상태 페이지나 내부 대시보드 등).

4. 벤더·파트너 연계

   • 각 벤더에 Sev-1 티켓을 열 권한을 가진 사람은 누구인가?
   • 벤더 SLA와 연락처 정보는 어디에 보관되는가?

이러한 팀 간 관계를 화살표와 라벨로 분필 철도에 그려 보세요. 보드 위에서 ‘그럴듯하다’고 느껴지면, 그때 온콜 로테이션과 인시던트 도구 설정에 반영합니다.

SRE 원칙을 일상 개발에 가져오기

핵심 SRE 개념인 자동화, 모니터링, 구조화된 인시던트 대응은 페이저가 울릴 때만 깨어나서는 안 됩니다. 새로운 기능을 설계할 때부터 영향을 미쳐야 합니다.

아날로그 철도 다이어그램을 평소 설계 작업의 입력으로 활용해 보세요.

• 모니터링: 모든 신규 서비스 설계 문서에는 이런 질문이 포함되어야 합니다.
  “이 서비스는 인시던트 철도 상 어디에 위치하는가? 이게 망가졌을 때 뭐가 신호가 되어 줄 것인가?”
• 자동화: 여러 인시던트 흐름에서 반복해서 등장하는 같은 “역”은 자동화 후보입니다. (예: 헬스 체크 실패 시 자동 롤백)
• 런북: 분필 다이어그램을 짧고 실용적인 런북으로 변환합니다. 복사·붙여넣기 가능한 명령어, 쿼리, 링크 등을 포함해서요.
• 테스트 & 게임데이: 주기적으로 철도를 따라가는 드릴을 실행합니다. 스테이징 환경에서 일부러 문제를 일으키고, 맵을 따라가 보세요.

이렇게 하면 신뢰성의 자세가 “사건이 나면 대응한다”에서 “애초에 우아하게 실패하도록 설계한다”로 바뀝니다.

SRE와 개발자의 ‘공동 설계’ 철도

최고의 인시던트 대응은 SRE만의 작품이 아닙니다. SRE와 개발자가 하나의 시스템처럼 함께 만들 때 나옵니다.

• SRE는 인시던트 역할, 에스컬레이션 경로, 메트릭, SLO, 포스트모템 같은 패턴을 가져옵니다.
• 개발자는 시스템 깊숙한 지식—엣지 케이스, 성능 제약, 도메인 동작—을 가져옵니다.

분필 세션을 공동 워크숍으로 활용해 보세요.

1. 현실적인 장애 시나리오를 하나 고릅니다. (예: “결제 지연이 3초로 치솟는다.”)
2. 화이트보드에 그 장애가 시스템을 통해 어떻게 전파되는지 여정을 그립니다.
3. 언제, 왜 누가 호출되는지 표시합니다.
4. 부족한 부분을 찾습니다: 누락된 메트릭, 모호한 소유권, 롤백 계획 부재 등.
5. 개선된 다이어그램을 플레이북으로 정리하고, 기술 태스크(알람 추가, 롤백 자동화, 대시보드 생성 등)로 쪼갭니다.

시간이 지나면 양쪽 모두 다음을 얻게 됩니다.

• 더 나은 신뢰성: 인시던트는 더 적고, 짧고, 덜 치명적이 됩니다.
• 더 나은 성능: 선로를 그리는 동안 병목과 블라인드 스팟을 발견합니다.
• 더 나은 대비 태세: 실제 상황이 왔을 때 모두가 자신의 역할을 알고 있습니다.

시작하는 방법: 실천용 체크리스트

분필 철도에서 가치를 얻기 위해 거창한 프로그램이 필요한 것은 아닙니다. 작게 시작하세요.

1. 60분짜리 분필 세션을 연다

   • SRE 1명, 개발자 몇 명, 팀 리드 1명, 인시던트 커맨더 경험자가 있다면 그 사람까지 부릅니다.
   • 웹 장애, DB 성능 저하 등 중요한 인시던트 유형 하나를 고릅니다.

2. 현재 현실을 그린다

   • 지금은 누가 페이지를 받는가? 그 사람은 먼저 무엇을 하는가? 어디를 보는가? 누구에게 연락하는가?
   • 있는 그대로 그립니다. 혼란, 우왕좌왕, 찍어 보는 행위까지 포함해서요.

3. 맵을 리팩터링한다

   • 불필요한 핸드오프와 병렬 혼란을 줄입니다.
   • 역할과 의사결정 지점을 명확히 합니다.
   • 더 나은 도구나 자동화가 도움이 될 곳에 표시를 해 둡니다.

4. 가볍게 제도화한다

   • 플레이북을 만들거나 업데이트합니다.
   • 온콜 로테이션에 빠진 오너를 추가합니다.
   • 인시던트 리포트/템플릿을 만들거나 조정합니다.

5. 연습한다

   • 새 맵을 기반으로 테이블톱(tabletop) 연습을 합니다.
   • 실제로 벌어지는 일에 따라 다시 조정합니다.

이 과정을 주요 장애 유형마다 반복하세요. 몇 번만 돌려도, 즉흥 대응이 점점 ‘연습된 공연’처럼 보이기 시작할 것입니다.

결론: 달리기 전에 먼저 그려라

강력한 대시보드와 자동화가 넘쳐나는 세상에서, 마커와 화이트보드를 먼저 찾는 일은 직관에 반할 수 있습니다.

하지만 아날로그 인시던트 분필 철도는 바로, 도구들이 대신해 줄 수 없는 부분에 대한 이야기입니다.

• 스트레스 상황에서 누가 무엇을 책임지는지 결정하는 일.
• 서로 다른 시간대와 스택에 있는 팀들이 어떻게 조율하는지 설계하는 일.
• SRE 모범 사례를 위기 때만이 아니라 일상 업무 속에 심어 넣는 일.

대시보드를 하나라도 열기 전에 일회용 위기 지도를 그려 둠으로써, 여러분은 언젠가 울릴 알람에 의지해야 할 선로를 지금 미리 깔아 두는 셈입니다.

먼저 그리세요. 그다음 자동화하세요. 다음 인시던트가 닥쳤을 때, 기차가 출발하기 훨씬 전에 철로를 깔아 두었다는 사실에 분명히 감사하게 될 것입니다.