소개

대부분의 팀은 런북을 가지고 있습니다. 하지만 알림이 뜨고 60초 안에 실제로 쓰이는 런북을 가진 팀은 거의 없습니다.

새벽 3시 17분, 온콜 근무 중이고, 수많은 링크와 대시보드, 위키 페이지에 파묻혀 있을 때 당신이 원하는 건 도서관이 아니라 지도입니다. 한 장. 한 번의 시선. 다음에 뭘 해야 할지가 단번에 보이는 것.

그게 바로 아날로그 런북 철도 노선도(railway map) 입니다. 시스템, 알림, 대응 경로를 한눈에 보여주는 단일 페이지 시각 가이드죠. 인프라를 위한 지하철 노선도라고 생각하면 됩니다. 땅 속에 깔린 모든 전선을 보여주는 게 아니라, 사고가 났을 때 어떤 노선을 따라 움직여야 하는지를 보여주는 지도입니다.

이 글에서는 이 지도를 어떻게 설계하고, 실제 온콜에서 어떻게 활용하며, 왜 상자와 화살표보다 문화와 사람에 더 가까운 이야기인지 설명합니다.

"철도 노선도" 런북이란?

철도 노선도(runbook railway map) 런북은 종이든 디지털이든 한 장짜리 다이어그램으로:

• 온콜 엔지니어가 마주칠 수 있는 모든 알림을 나열하고
• **심각도(severity)**와 즉각적인 다음 조치를 보여주며
• 시스템 간 의존성을 시각화하고
• 누구에게, 어떻게, 언제 연락해야 하는지를 담습니다.

이는 대중교통 노선도의 디자인 패턴을 차용합니다:

• 노선(line) 은 시스템이나 서비스 영역을 나타내고
• 역(station) 은 알림, 장애 유형, 의사결정 포인트를 의미하며
• 환승 지점(transfer) 은 의존성과 에스컬레이션 경로를 표현합니다.

모든 디테일을 담으려는 게 아닙니다. 목표는 빠른 방향 감각을 주는 도구를 만드는 것:

“지금 나는 어디에 있고, 뭐가 망가졌고, 무엇이 중요하며, 지금 당장 무엇을 해야 하지?”

를 답할 수 있는 지도입니다.

원칙 #1: 한 장, 한 번에 보이게

제약이 곧 특징입니다. 반드시 한 페이지에 들어가야 합니다.

이 제약이 우선순위를 강제합니다:

• 알림 이름 (페이저/알림 시스템에 뜨는 정확한 이름)
• 얼마나 심각한지 (색상이나 라벨로 뚜렷하게 표현된 심각도)
• 처음 1–3개의 액션

위키에는 여전히 상세한 런북이 있을 수 있습니다. 하지만 철도 노선도는 그 모든 것의 진입점(entry point) 이 됩니다:

• “빨강: checkout-latency-high → SRE 호출, 트래픽을 B 리전으로 전환, 그 다음 전체 런북: 링크 참고.”
• “노랑: reporting-lagging → 배치 큐 상태 확인, 워커 수 조정, 30분 이상 지속 시 #incidents에서 Support에 알림.”

온콜 엔지니어가 뭘 해야 할지 알기 전에 스크롤을 여러 번 하고, 줌인/줌아웃하고, 다섯 개를 클릭해야 한다면 이미 타이밍을 놓친 겁니다. 지도는 다음 질문에 곧바로 답해야 합니다:

이 알림이 떴다. 이게 뭔데, 지금 당장 뭘 해야 하지?

원칙 #2: 의존성이 보이게 만들기

사건(incident)은 거의 한 서비스 안에서만 얌전히 머물지 않습니다. 느려진 데이터베이스가 API에 영향을 주고, API는 프론트엔드에 영향을 주고, 결국 고객이 아픔을 느낍니다.

철도 노선도는 이런 블라스트 반경(blast radius) 을 눈에 띄게 만들어야 합니다. 간단한 접근법은 다음과 같습니다:

• 핵심 도메인별 노선을 그립니다 (예: Authentication, Payments, Content, Internal Tools)
• 그 위에 각 시스템을 역으로 배치합니다 (예: auth-api, payments-service, reporting-jobs)
• 여러 노선이 공유하는 공통 의존성(예: user-db, redis-session-store)은 선을 겹치거나 커넥터로 표시합니다.

각 알림에 대해 다음을 보여줍니다:

• 어디에 속해 있는지 (어떤 시스템/어떤 노선)
• 무엇에 영향을 미칠 가능성이 있는지 (다운스트림 노선/역)

예시:

• user-db-write-errors (치명적, 빨강)이 Database 노선 위에 있고, Authentication, Payments, Content 노선에 모두 연결돼 있습니다.
• 지도에는 작은 콜아웃을 넣습니다: "로그인 실패, 결제 실패, 콘텐츠 누락이 발생할 수 있습니다. 2차 증상 디버깅보다 페일오버를 우선하세요."

이제 2차 알림(예: checkout-failure-rate-high)이 떴을 때, 온콜은 빠르게 파악할 수 있습니다. 이건 payments 서비스의 버그라기보다 user-db 문제의 다운스트림 증상일 수 있다고요.

이렇게 하면 트리아지가 빨라지고, 쓸데없는 토끼굴(불필요한 추적)을 줄일 수 있습니다.

원칙 #3: 기술 단계만 말고, 커뮤니케이션을 코드화하기

기술적인 복구는 일의 절반에 불과합니다. 나머지 절반은 사람들을 조율하는 일입니다.

철도 노선도에는 각 심각도와 사건 유형별로 커뮤니케이션 프로토콜이 분명하게 드러나야 합니다.

각 알림 또는 알림 묶음에 대해 다음을 명시합니다:

• 누구를 호출할지:
  • 1차 온콜 역할/팀
  • 2차 백업 또는 특정 도메인 스페셜리스트
• 언제 에스컬레이션할지:
  • 시간 기준 (예: “15분 내 해결 안 되면 Incident Commander 호출”)
  • 영향 기준 (예: “트래픽의 5% 이상 영향 시 리더십에 알림”)
• 어떤 채널을 쓸지:
  • #incidents Slack 채널
  • 전용 Zoom 브리지
  • 상태 페이지 또는 고객 커뮤니케이션 도구

지도 위에서는 이것을 작은 범례(legend)로 표현할 수 있습니다:

• 빨강 (SEV‑1): @primary-oncall과 @incident-commander를 즉시 호출. #sev1-live 채널 오픈. 15분 이내 상태 페이지 업데이트.
• 주황 (SEV‑2): @primary-oncall 호출. 세부 내용은 #incidents에 공유. 30분 시점에 고객 영향 평가.
• 노랑 (SEV‑3): 근무 시간 중에는 1차 온콜이 처리, 반복 발생 시 #reliability에 비동기 코멘트.

암묵적인 팀 내 지식에 기대지 마세요. 이 지도만 봐도 새로 합류한 팀원조차 어떤 식으로 조율해야 하는지 알 수 있어야 합니다.

원칙 #4: 소유권을 분명하게, 그리고 함께 나누기

효과적인 온콜은 “운영팀 일”이 아닙니다. 다음과 같은 공유된 소유 문화 위에 서 있습니다:

• 엔지니어링
• 프로덕트 매니지먼트
• Support / Customer Success
• 리더십

철도 노선도는 다음과 같은 방식으로 그 문화를 강화할 수 있습니다:

• 각 서비스/알림에 오너십 라벨을 붙입니다 (예: “Owner: Payments 팀 + SRE”)
• 특정 사건에서 알림을 받아야 할 비(非)엔지니어링 이해관계자를 표시합니다 (예: “대규모 결제 실패 → Support 리더 + Payments 프로덕트 담당자에 알림”)
• 프로덕트 우선순위와 안정성(reliability) 이 어떻게 연결되는지를 보여줍니다 (예: 지도 위에 ‘비즈니스 크리티컬 경로’를 따로 강조)

이렇게 하면 안정성은 SRE 팀만의 문제가 아니라는 게 분명해집니다. 예를 들어 프론트엔드 노선에 핵심 “Homepage” 역이 있다면, 이 영역에 해당하는 프로덕트/서포트 파트너가 누구인지 바로 드러나야 합니다.

원칙 #5: 살아 있는 문서로 만들기

변하지 않는 지도는 결국 사실과 어긋나게 됩니다.

시스템은 바뀌고, 프로덕트 플로우도 변하고, 새 알림이 생기고, 옛 알림은 사라집니다. 지도가 최신 상태로 유지되지 않으면, 온콜 엔지니어는 곧 그 지도를 믿지 않게 됩니다.

사건 라이프사이클 안에 지도 유지보수를 녹여 넣으세요:

1. 사건 진행 중: 빠르게 메모할 수 있을 정도로, 보이는 “지도 갭(map gap)”을 적어 둡니다 (없는 알림, 잘못된 심각도, 애매한 오너 등).
2. 사건 후/포스트모템: 반드시 질문하세요, “이번 일로 철도 노선도에 무엇을 바꿔야 할까?”
   • 새 역(알림)을 추가해야 할까요?
   • 심각도/색상을 조정해야 할까요?
   • 예상 못 했던 블라스트 반경을 보여주기 위한 새 의존성 화살표가 필요할까요?
   • 더 단순한 우회/완화(mitigation) 경로를 배웠나요?
3. 빠르게 업데이트: 지도의 오너(또는 로테이션)를 정해, SEV‑1/SEV‑2 사건 후 48시간 안에 아티팩트를 업데이트하도록 합니다.

이 한 장짜리를 코드처럼 다루세요: 버전 관리하고, 리뷰하고, 계속 개선하세요.

원칙 #6: 불이 났을 때만 말고, 연습용 드릴에 활용하기

온콜 지도는 사람들의 익숙함(familiarity) 만큼만 유용합니다. 그 익숙함은 위험이 낮은 환경에서 만들어져야 합니다.

철도 노선도를 중심 아티팩트로 삼아 연습 드릴을 진행하세요. 예를 들면:

• “Wheel of Misfortune” 스타일의 연습:
  • 임의의 장애 시나리오를 하나 선택합니다.
  • 온콜(또는 자원자)에게 지도를 주고, 알림이 떴다고 가정합니다.
  • 그들이 무엇을 확인하고, 누구를 호출하고, 고객에게 뭐라고 말할지 지도를 따라가며 말로 풀도록 합니다.
• 크로스팀 인시던트 리허설:
  • 프로덕트와 Support도 초대해 지도가 어떻게 쓰이는지 직접 보게 합니다.
  • 커뮤니케이션 프로토콜을 실제처럼 연습합니다.

이 드릴의 목표는:

• 실제 사건 발생 시 인지 부하를 줄이고
• 지도에서 빠진 부분이나 헷갈리는 부분을 드러내며
• 지도를 “잊혀진 PDF”가 아닌, 제일 먼저 찾는 도구로 만드는 것입니다.

시간이 지나면 사람들은 노선과 역을 거의 근육 기억(muscle memory) 수준으로 익히게 됩니다.

원칙 #7: 인간의 한계를 존중하기 – 스케줄과 휴식

어떤 런북도 기진맥진한 온콜 엔지니어를 완전히 보완해 주지는 못합니다.

철도 노선도는 다음과 같은 요소를 갖춘 지속 가능한 온콜 시스템 안에 존재해야 합니다:

• 합리적인 로테이션 길이와 빈도
• 명확한 인수인계 의식/의식(ritual) (예: 각 로테이션 시작 시 지도를 함께 훑어보기)
• 휴가와 수면 시간을 고려한 백업 커버리지

이 중 일부는 지도나 동반 문서에 바로 녹여 넣을 수도 있습니다:

• 어떤 역할은 24/7 상시 대기가 필요하고, 어떤 역할은 비즈니스 아워만 커버하면 되는지 강조
• 리전별 커버리지 명시 (“APAC 온콜은 00:00–08:00 UTC 동안 이 시스템의 SEV‑1 처리” 등)
• “중단 조건(stop condition)” 문서화 (예: 심야에는 비필수 기능을 과감히 디그레이드(degrade)하고, 무리해서 패치하지 않아도 되는 기준)

고가용성과 안전한 운영은 충분히 쉰 대응자와 현실적인 기대치에서 나옵니다. 지도는 영웅적인 소방전보다, 인간적인 지속 가능성을 뒷받침해야 합니다.

철도 노선도 만들기, 이렇게 시작하세요

대단한 툴링 프로젝트가 없어도 됩니다. 처음에는 거칠게, 작게 시작하세요:

1. 스코프를 좁게 잡기: 한 개의 프로덕트 영역이나, 한 개의 고객 크리티컬 플로우(예: 회원가입, 결제)를 고릅니다.
2. 그 플로우에서 발생할 수 있는 알림 목록을 만들고 심각도를 붙입니다.
3. 관련된 주요 시스템을 몇 개 노선과 역으로 그립니다.
4. 블라스트 반경에 의미 있는 의존성에 화살표/연결선을 추가합니다.
5. 각 알림에 대해 다음을 적습니다:
   • 처음 1–3개의 액션
   • 누구를 호출할지
   • 언제/어떻게 에스컬레이션할지
6. 출력해서 책상 위에 두거나, 모두가 볼 수 있는 단일 페이지 대시보드로 고정합니다.
7. 다음 사건과 포스트모템에서 실제로 사용해 보고, 업데이트합니다.

이후 점차 더 많은 플로우와 시스템으로 범위를 넓혀가면 됩니다.

결론

좋은 온콜 경험은 문서가 얼마나 자세한지가 아니라, 가장 필요할 때, 얼마나 적절한 추상화 수준의 정보를 한 번에 얻을 수 있는지에 달려 있습니다.

아날로그 런북 철도 노선도는 온콜 엔지니어에게 다음을 제공하는, 하나의 신뢰할 수 있는 한 장짜리 지도입니다:

• 모든 알림을 명확한 다음 액션에 매핑하고
• 의존성과 블라스트 반경을 시각화하며
• 누구에게 연락하고, 언제 에스컬레이션하며, 어떤 채널을 쓸지를 코드화하고
• 엔지니어링, 프로덕트, Support, 리더십에 걸친 공유 오너십을 녹여 넣고
• 사건과 포스트모템을 거치며 계속 진화하고
• 자신감을 쌓는 드릴의 중심 아티팩트가 되며
• 인간적인, 지속 가능한 온콜 문화 안에 자리 잡게 합니다.

작게 시작하고, 반드시 한 페이지로 유지하며, 살아 있는 시스템처럼 다루세요. 다음 번 새벽 3시 17분 알림이 울릴 때, 또 하나의 위키 탭이 아니라 지도를 들고 있게 될 겁니다.