연필로 그린 장애 컴퍼스 트롤리: 한 장짜리 종이 지도를 모든 온콜 인수인계에 굴리는 법

당신의 장애 대응 프로세스를, 온콜 엔지니어들 사이를 오가는 작고 낡은 종이 지도 한 장이라고 상상해 보자. 누가 새벽 2시에 그 지도를 들고 있든, 같은 길, 같은 랜드마크, 같은 “당신은 여기 있습니다(You are here)” 마커가 보인다.

이게 바로 연필로 그린 장애 컴퍼스 트롤리다. 장애를 탐색하는 방식을 중앙에서 공유하는, 하나의 공용 “지도”에 대한 은유다. 각 엔지니어가 입사 선배의 구전 지식, 여기저기 흩어진 대시보드, 어렴풋이 기억나는 Slack 스레드에 의존하는 대신, 팀 전체가 같은 일관된 “지도”를 공유하며 대응하는 것이다.

이 글에서는 다음을 다룬다:

• 명확한 커버리지 모델과 에스컬레이션 경로를 갖춘, 지속 가능한 온콜 로테이션 설계하기
• 실제로 쓰이게 되는 표준화된 실전형 인시던트 런북 만들기
• 온콜 인수인계 시 코디네이션 비용과 컨텍스트 스위칭 최소화하기
• 안정성을 해치지 않으면서 온콜을 더 인간적으로 만드는 방법

1. 지도부터 만든다: 지속 가능한 온콜 커버리지 모델 고르기

런북, 대시보드, 툴링을 고민하기 전에, 사람들이 실제로 버틸 수 있는 커버리지 모델이 먼저 필요하다.

1.1 흔히 쓰이는 커버리지 패턴

여러 조직에서 잘 동작하는 패턴 몇 가지:

• 팔로 더 선(Follow‑the‑sun): 서로 다른 타임존의 팀이 각 지역의 주간 시간을 담당한다.

  • 장점: 수면 방해가 적고 장기적으로 지속 가능성이 높다.
  • 단점: 다수 리전/팀이 필요하고, 리전 간 커뮤니케이션 품질이 매우 중요하다.

• Primary / Secondary 로테이션:

  • Primary: 알람 대응, 트리아지, 고객 영향 이슈 처리.
  • Secondary: 백업 역할, 에스컬레이션 처리, 복잡한 인시던트 지원.
  • 장점: 사람 한 명이 단일 실패 지점이 되는 것을 피하고, 부하를 분산시킨다.
  • 단점: Primary에서 Secondary로 언제 에스컬레이트해야 하는지에 대한 명확한 규칙이 필요하다.

• 팀 전체 로테이션 (팀원 전원이 돌아가며 온콜):

  • 장점: 소유권이 분산되고, 시스템 전반에 대한 이해가 넓어진다.
  • 단점: 로테이션 주기가 너무 짧거나 인시던트 양이 많으면 과부하 risk가 크다.

어떤 모델이 맞는지는 인원 수, 타임존, 인시던트 빈도에 따라 달라지지만, 예측 가능성만큼은 반드시 지켜야 한다. 사람들은 다음을 알고 있어야 한다:

• 언제 자신이 온콜인지
• 무엇에 책임이 있는지
• 자신의 근무가 끝날 때, 이슈를 어떻게 인수인계할 수 있는지

1.2 에스컬레이션 경로는 ‘아플 만큼’ 명확하게

위기 상황에서 애매함은 곧 비용이다.

최소한 다음을 정의하고 문서화해야 한다:

• 언제든 누가 온포인트(on point) 인지 (Primary 온콜)
• 누가 백업인지 (Secondary, 매니저, Incident Commander 온콜 등)
• 무엇이 에스컬레이션 트리거인지, 예를 들어:
  • MTTA(Mean Time To Acknowledge, 평균 인지 시간) > X분
  • 특정 기준 이상의 고객 영향도 (Severity 수준)
  • X분 이상 지나도 명확한 완화 조치가 없는 경우

이 에스컬레이션 경로는 팀이 의존하는 그 “종이 지도”—공유 인시던트 문서—안에 명시되어 있어야 한다. 누군가가 “트롤리를 굴려” 다음 근무자로 넘기는 순간에도, 이 경로는 바뀌지 않는다.

2. 런북은 지도 범례: 표준화된, 현실적인 가이드 만들기

시스템이 다운됐는데 최고의 엔지니어가 휴가 중이라고 하자. 그때, 어느 정도 경험이 있는 다른 동료가 여전히 장애를 헤쳐 나갈 수 있는가?

이게 바로 표준화된 인시던트 대응 런북의 핵심 목적이다.

2.1 좋은 런북의 요건

모든 런북은 다음 네 가지 질문에 명확히 답해야 한다:

1. 이 런북은 무엇을 위한 것인가?

   • 범위(예: “서비스 X의 API 레이턴시 알람” 또는 “DB Read Replica 상태 불량”)

2. 문제를 어떻게 인지하는가?

   • 관련 알람, 대시보드, 로그 위치
   • 고객이 보게 되는 전형적인 증상

3. 첫 단계는 무엇인가?

   • 단순한 번호 매긴 체크리스트:
     1. 알람이 실제 이슈인지 확인한다 (대시보드 A, B 확인).
     2. 인시던트 채널에 알린다.
     3. 인시던트 Severity 매트릭스에 따라 심각도를 선언한다.

4. 주요 완화(mitigation) 방법은 무엇인가?

   • 구체적인 명령어, 참조할 다른 런북, 토글/플래그 등
   • “만약 X라면 Y를 하라” 형태의 분기

복사‑붙여넣기 가능한 명령어, 스크린샷, Observability 대시보드 링크를 포함하라. 마찰을 줄이면 줄일수록, 스트레스 상황에서 런북이 실제로 사용될 확률이 높아진다.

2.2 실제 인시던트로 런북을 개선하기

의미 있는 인시던트가 있을 때마다, 다음을 자문해 보자:

• 어디서 ‘감’으로 때웠는가?
• 다음 스텝을 두고 어디서 논쟁이 있었는가?
• 어디서 필요한 데이터를 찾느라 시간을 썼는가?

이 갭들이 바로 런북 개선 포인트다.

예를 들어, DB Failover 인시던트에 완화까지 60분이 걸렸다고 하자:

• 세 명의 엔지니어가 서로 다른 대시보드를 따로따로 확인했다.
• 누가 Failover를 승인할 수 있는지 아무도 확신하지 못했다.
• 올바른 명령어는 있었지만, 오래된 위키 페이지에만 있었다.

이를 더 나은 런북으로 바꿔 보자:

• 맨 위에 “골든 대시보드(Golden Dashboard)” 섹션을 추가하고 직접 링크를 넣는다.
• 권한 규칙을 명시한다: “SEV‑1인 경우 온콜 SRE는 추가 승인 없이 Failover를 수행할 수 있다.”
• 정확한 Failover 명령어와 안전 체크리스트를 런북에 그대로 복사해 넣는다.

이렇게 하면 MTTA(Mean Time To Acknowledge)와 MTTR(Mean Time To Recovery)을 모두 줄일 수 있다. 이유는:

• 데이터를 찾느라 낭비되는 시간이 줄어들고,
• 기억이나 ‘권한에 대한 소문’에 의존해야 하는 의사결정이 줄어들기 때문이다.

3. 트롤리 자체: 정보와 책임을 중앙화하기

“종이 지도가 실린 트롤리”는 단순한 은유 그 이상이다. 이건 하나의 원칙이다: 한 곳, 한 오너, 한 플로우.

3.1 인시던트 정보를 중앙에 모으기

인시던트 도중에는, 사람들이 다음과 같은 질문을 할 일이 없어야 한다:

• “최신 상태 업데이트는 어디 있지?”
• “어느 문서가 진짜지?”
• “지금 누가 총괄하고 있는 거야?”

당신의 트롤리 역할을 할, 단일 인시던트 공간을 만들자:

• 전용 인시던트 채널 템플릿 (예: #inc-sev1-*)
• 표준 인시던트 문서 템플릿 (Google Docs, Notion, 사내 툴 등)
• 문서 상단에 다음 링크를 모아두기:
  • 현재 Incident Commander
  • Status Page
  • 관련 런북들

목표는 하나다: 인시던트 중간에 합류한 사람도 60초 안에 상황 파악을 할 수 있게 하는 것.

3.2 “코디네이션 택스” 줄이기

코디네이션 택스란, 다음과 같은 데 쓰이는 오버헤드를 말한다:

• 누가 무엇을 하고 있는지 파악하기
• 같은 상태 업데이트를 반복해서 공유하기
• 서로 다른 정보들을 맞춰 보는 일

이를 줄이려면:

• 역할을 초기에 명확히 할당한다:

  • Incident Commander: 의사결정과 흐름 관리
  • Communications Lead: 상태 업데이트 게시
  • Operations Lead(들): 명령 실행, 메트릭 점검

• 짧고 일관된 상태 업데이트를 사용한다 (예: 15분마다):

  • 현재 영향도(Impact)
  • 현재 가설(Hypothesis)
  • 다음 액션(Next steps)

명확한 역할과 단일 소스 오브 트루스(Single Source of Truth)가 있으면, 우왕좌왕하는 군중이 아니라 잘 조율된 대응 팀이 된다.

4. 집중력 보호: 배칭과 컨텍스트 스위칭 줄이기

온콜 업무는 쉽게 끝없는 ‘작은 컨텍스트 스위치’의 연속이 된다. 낮은 우선순위 알람 하나, 문서 질문 하나, 그 사이에 끼워 넣은 툴링 수정 작업 하나 등등.

시간이 지나면, 이는 생산성과 사기를 모두 망가뜨린다.

4.1 온콜 엔지니어의 일을 유사한 작업끼리 묶기

온콜 엔지니어에게 “모든 걸 조금씩 동시에 하라”고 요구하는 대신, 역할을 배칭하라:

• 인시던트 대응: 실시간 이슈에 대한 1순위 책임

• 포스트 인시던트 개선 작업: 근무 시간 중 인시던트가 적을 때는 다음에 집중:

  • 런북 업데이트 또는 신규 작성
  • 알람/임계값(threshold) 개선
  • 반복되는 수동 작업 자동화

• 툴링·SRE 관련 작업: 인시던트 사이에 잠시 멈췄다가 다시 이어갈 수 있는 프로젝트를 배정하되, 깊은 아키텍처 설계처럼 긴 집중이 필요한 일은 피한다.

이처럼 작업의 종류를 정렬하면, 계속해서 컨텍스트를 바꾸는 데 드는 인지 부담이 줄어든다.

4.2 온콜 중 비긴급 업무에 대한 가드레일

온콜 엔지니어가 자신의 근무 시간 동안 비긴급 요청에 거절 의사를 밝혀도 괜찮다는 점을 명확히 하라. 예를 들어:

• 코드 리뷰는 필요한 경우 늦춰도 된다.
• 신규 기능 개발은 필수가 아니다.
• 애드혹 미팅 초대는 거절해도 된다.

이건 게으름이 아니다. 진짜 폭풍이 몰아칠 때, “항해사”가 또렷한 정신을 유지하도록 하는 방식이다.

5. 더 인간적이고 회복력 있는 온콜 만들기

높은 안정성을 위해 사람을 소모시킬 필요는 없다. 사실, 번아웃된 팀은 더 불안정하다.

5.1 예측 가능한 스케줄과 공정한 로테이션

다음과 같은 방향을 지향하라:

• 충분히 여유를 두고 공개되는 스케줄 (예: 1–3개월 전)
• 사람이 버틸 수 있는 로테이션 길이:
  • 너무 자주 교대하지 않을 정도로 길되(예: 1주일 단위),
  • 한 사람이 한 달 내내 24/7로 붙잡혀 있는 식의 장기적인 수면 방해는 피할 것
• 무거운 온콜 주기 이후의 회복 시간 예:
  • 다음 주 월요일 오전에는 회의 없음
  • 스프린트 커밋을 가볍게 조정

5.2 장애 시 명시적인 오너십

오너십이 애매하면 스트레스가 커진다. 소유권을 명확히 선언하라:

• “이 인시던트의 오너는 결제(Payments) 온콜 엔지니어다.”
• “이 API는 전용 온콜 로테이션이 있고, 그들이 리드를 맡는다.”

여기에 심리적 안전장치를 더하라:

• Blameless Postmortem
• 처벌보다 학습을 중시하는 문화

사람들이 “내가 걸리면 끝장이다”라는 공포에 떨지 않을 때, 기꺼이 오너십을 갖고 시스템을 개선하려 한다.

6. 모두를 하나로 묶는 것: 한 장의 지도, 많은 손

연필로 그린 장애 컴퍼스 트롤리는 단순한 아이디어다:

• 하나의 공유 지도: 표준화된 런북, 일관된 문서
• 명확한 길과 범례: 커버리지 모델, 에스컬레이션 경로, 역할 정의
• 튼튼한 트롤리: 교대 간에 매끄럽게 이어지는 중앙화된 커뮤니케이션 채널과 인시던트 문서

인시던트 프로세스를 ‘영웅의 예술’이 아니라, 모두가 함께 쓰는 내비게이션 도구로 대할 때, 다음과 같은 효과를 얻는다:

• 추측을 줄여 MTTA와 MTTR을 낮춘다.
• 역할을 명확히 하고 정보를 중앙화해 코디네이션 택스를 줄인다.
• 예측 가능하고 공정한 로테이션을 설계해, 온콜을 지속 가능하고 인간적으로 만든다.

시스템은 언제나 실패한다. 중요한 것은, 팀이 그 실패를 공유된, 잘 표시된 지도로 맞이하느냐, 아니면 여기저기 흩어진 반쪽짜리 스케치 더미로 맞이하느냐다.

지도에 투자하라. 언젠가 새벽 2시, 당신의 미래 온콜 담당자가 연필을 손에 쥔 채, 침착하게 장애 트롤리를 다음 안전한 지점으로 굴리며 과거의 당신에게 고마워할 것이다.