아날로그 인시던트 열차 시간표 벽화: 평온한 온콜 근무를 위한 벽 가득한 리듬 그리기

새벽 3시에 인시던트가 터지면, 온콜 시스템 설계의 품질이 그대로 드러납니다.

툴, 알람, 대시보드도 물론 중요합니다. 하지만 혼란 한가운데서 팀을 실제로 지탱해 주는 시스템은 온콜 스케줄 자체입니다. 누가 지금 담당인지, 누가 백업인지, 어떻게 에스컬레이션 되는지, 그리고 그 모든 것이 얼마나 공평하게 느껴지는지가 핵심입니다.

이 글에서는 그 시스템을 설계하고 이해하는 데 의외로 강력한 방법 하나를 소개합니다. 바로 벽 전체를 쓰는 아날로그 “인시던트 열차 시간표” 벽화입니다. 각 라인은 하나의 서비스, 각 “열차”는 하나의 온콜 로테이션이 되는, 거대한 시각적 리듬을 벽에 테이프로 붙이거나 그려 넣는 방식입니다.

SaaS 캘린더에 비하면 다소 촌스럽고 시대에 뒤떨어져 보일 수 있습니다. 하지만 바로 그게 이 방법의 포인트입니다.

온콜 툴보다 온콜 설계가 더 중요한 이유

잘 설계된 온콜 스케줄은 단순한 HR 문서가 아닙니다. 그것은 인시던트 대응 시스템의 핵심 구성 요소입니다.

좋은 온콜 설계는 다음을 보장합니다.

• 적절한 사람이 적절한 알람을 적절한 타이밍에 받는다.
• 스트레스가 가장 높은 순간에도 혼란과 선택 피로를 최소화한다.
• 고통을 공평하게 나눠, 수개월·수년 동안도 지속 가능한 시스템을 만든다.

반대로, 나쁜 온콜 설계는:

• “이거 누가 담당이죠? 누가 1차고, 누가 L2죠?” 같은 페이징 핀볼을 만든다.
• 히어로 문화와 조용한 번아웃을 키운다.
• 인시던트를 더 느리고, 시끄럽고, 정치적으로 만든다.

아날로그 벽화 이야기를 하기 전에, 먼저 필요한 세 가지 토대가 있습니다. 명확한 롤, 공정한 로테이션, **임베디드 트레이닝(학습 구조)**입니다.

명확한 역할, 에스컬레이션, 책임 범위

인시던트 중에는 애매함이 가장 큰 적입니다. 사람들은 압박을 받으면 익숙한 습관으로 돌아갑니다. 아무 채널이나 두드리거나, 일을 중복해서 하거나, 누군가가 알아서 하고 있을 거라 가정해 버립니다.

온콜 시스템은 언제든 다음 질문에 명확히 답할 수 있어야 합니다.

1. 이 서비스나 도메인의 1차 온콜은 누구인가?
2. 1차가 막히거나 과부하일 때, 누가 백업인가?
3. 에스컬레이션은 어떻게, 누구에게 이루어지는가?
4. 커뮤니케이션(상태 공유) vs. 완화/복구 vs. 조정/조율은 누가 책임지는가?

이를 위해 다음이 필요합니다.

• 역할 이름을 명시: Incident Commander, Communications Lead, Ops/Infra, Feature Owner 등 구체적인 롤을 런북과 스케줄에 명시합니다.
• 명시적인 에스컬레이션 경로: “1차가 5분 안에 응답하지 않으면 백업을 페이지한다. 30분 안에 해결되지 않으면 도메인 Tech Lead에게 에스컬레이션한다.” 즉흥적 판단이 필요 없도록 규칙을 적습니다.
• 책임 범위의 경계 설정: 각 온콜 엔지니어는 다음을 분명히 알아야 합니다. 내가 책임지는 것은 무엇인가? 내가 명시적으로 책임지지 않는 것은 무엇인가?

이런 명확성은 눈으로 직접 볼 수 있을 때 훨씬 설계하고 점검하기 쉽습니다. 캘린더 그리드는 관계를 숨기고, 큰 벽화는 관계를 드러냅니다.

공정성과 예측 가능성: 번아웃을 막는 가드레일

온콜은 감정 노동에 가깝습니다. 순수한 시간만이 아니라, 인지적·심리적 부담도 똑같이 중요합니다.

건강한 온콜 스케줄에는 공통된 특징이 있습니다.

• 예측 가능한 로테이션: 엔지니어가 온콜을 기준으로 삶을 계획할 수 있습니다. 보통 4–6주 전에 로테이션이 확정되는 패턴이 많습니다.
• 공정한 분배: 야간, 주말, 공휴일 근무가 팀 구성원 간에 대체로 균등하게 돌아갑니다.
• 회복 시간 보장: 큰 인시던트나 힘든 주간 이후에는 보호된 휴식 시간이 있습니다.
• 투명한 트레이드오프: 교대·대타·스왑이 DM이 아니라 모두가 볼 수 있는 곳에 드러나고, 합의 하에 이뤄집니다.

패턴이 보이지 않거나, 이해하기 어렵게 되면 번아웃과 이탈은 서서히 스며듭니다. 예를 들어:

• 특정 사람이 반복해서 공휴일 주말을 맡는다.
• 신입이 조용히 가장 안 좋은 타임존을 떠맡는다.
• 어떤 서비스는 야간 페이지가 훨씬 많은데, 로테이션은 다른 서비스와 동일하게 운영된다.

페이지 시스템에서 공정성 지표를 계산할 수도 있습니다. 하지만 벽에서는 불공정함이 눈에 보입니다. 특정 이름 아래에 야간 시프트가 유난히 조밀하게 몰려 있다거나, 회복 시간 없이 이어지는 구간이 긴 사람, 소수의 인원만 계속해서 무거운 로드를 지는 모습이 한눈에 들어옵니다.

아날로그 시간표가 빛을 발하는 지점이 바로 이 부분입니다.

섀도 로테이션을 통한 학습과 성장

온콜 스케줄이 아무리 좋아도, 사람들에게 “페이저 울리면 무섭다”는 공포심이 남아 있으면 결국 실패합니다.

온콜 설계에 섀도(Shadow) 로테이션을 포함시키면 자신감과 회복력을 키울 수 있습니다.

• Shadow Primary: 경험이 적은 엔지니어가 메인 온콜과 함께 “동승”합니다. 알람을 같이 받고, 트리아지와 완화 과정을 따라가지만, 공식적인 책임은 여전히 메인 온콜에게 있습니다.
• 명확한 성장 경로: observer → shadow → 주간 전용 primary → 풀타임 primary 같은 단계가 정의되어 있고, 모두가 자신이 어디에 있고 다음 단계가 무엇인지 압니다.
• 구조화된 회고: 인시던트 후에는 섀도들이 자신이 본 것과, 본인이었다면 어떻게 했을지 공유합니다. 이렇게 경험을 팀 전체의 학습으로 전환합니다.

벽 스케줄에서는 섀도를 시각적으로 표현할 수 있습니다. 연한 색을 쓰거나, 1차 온콜 라인 옆에 얇은 ‘평행선’을 추가하는 방식입니다. 그러면 누가 지금 램프업 중인지, 숙련자들이 모두 적절히 후배를 키우고 있는지 단번에 보입니다.

자동화는 대체제가 아니라, 인간을 돕는 보조 시스템

자동화는 종종 온콜 스트레스의 만능 해결책처럼 포장되곤 합니다. 잘 만든 자동화는 압박 상황의 사람들을 돕는 보조 장치이지, 인간 시스템 자체를 무시하게 만드는 도구가 아닙니다.

핵심적인 자동화 영역은 다음과 같습니다.

• 페이징 및 라우팅: 벽 스케줄의 “소스 오브 트루스”(궁극의 기준)가 무엇이든, 실제로는 도구 안에 정식 스케줄이 존재해야 합니다. 알람 시스템은 누구를, 어떤 순서로 호출해야 할지 알아야 합니다.
• 에스컬레이션 타이머: Acknowledgement(응답)가 없을 경우, 정책에 따라 자동으로 에스컬레이션합니다.
• 런북·플레이북 연동: 알람에서 바로 명확한 단계별 트리아지·복구 가이드로 링크합니다.
• 인시던트 툴링: 인시던트 채널 자동 생성, 역할 할당 프롬프트("Incident Commander를 지정하세요"), 로그 수집, 티켓 생성 등을 자동화합니다.

아날로그 벽화와 디지털 자동화는 서로를 보완합니다.

• 벽은 시스템을 설계하고 리뷰하는 데 도움을 줍니다.
• 툴링은 새벽 3시에 그 설계를 정확하게 실행해 줍니다.

왜 ‘벽 크기 열차 시간표’인가? 역처럼 생각하기

디지털 캘린더는 하나하나 떨어진 박스를 보여 줍니다. 반면 열차는 리듬으로 운행합니다. 예측 가능한 패턴, 교차하는 노선, 피크 타임에 더 자주 운행되는 서비스 같은 개념이 있죠.

벽을 가득 채운 “인시던트 열차 시간표” 벽화는 이 메타포를 그대로 가져옵니다.

• 시간은 가로축으로 흐르며(일 단위 혹은 주 단위),
• 서비스 또는 팀은 세로축으로 배치됩니다.
• 각 온콜 로테이션은 시간 위를 달리는 하나의 컬러 “열차 노선”입니다.
• 에스컬레이션 경로는 위아래로 이어진 관계로 표현됩니다.
• 섀도 로테이션은 주 노선 옆이나 아래에 놓인 “평행 선로”입니다.

이렇게 하면 흩어진 캘린더 이벤트 모음 대신 연속적인 이야기를 얻게 됩니다.

• 몇 달에 걸쳐 책임이 어디에 놓여 있는가?
• 어디에서 열차(로테이션)가 교차하는가?
• 어디가 환승역(공동 소유 구간)이며, 어디가 단일 실패 지점인가?

이 관점에서 팀은 벽에서 한 발짝 물러서 전체 온콜 생태계를 물리적으로 내려다볼 수 있습니다.

툴이 자주 숨기는 것들을, 벽은 드러나게 만든다

잘 설계된 벽화를 몇 미터 떨어져서 바라보면 패턴이 눈에 확 들어옵니다.

1. 온콜 부담의 불균형
   어떤 사람의 이름이 유난히 야간이 많은 서비스에 자주 등장하나요? 특정 인물이 블랙 프라이데이나 대형 런칭 기간처럼 리스크가 큰 시기에 반복해서 나타나나요?

2. 병목과 단일 실패 지점
   어떤 서비스는 한 분기 내내 1차 온콜이 한두 명밖에 없나요? 에스컬레이션이 항상 같은 시니어 엔지니어에게만 올라가나요?

3. 삐뚤어진 트레이닝 구조
   섀도들이 특정 멘토에게만 몰려 있나요? 어떤 서비스는 아예 백업을 키우지 않고 있나요?

4. 묶여 있는 리스크
   여러 개의 크리티컬 서비스가 예상 인시던트 구간(배포일, 트래픽 피크 등)에 같은 온콜 엔지니어를 공유하고 있나요?

5. 회복의 불모지(Recovery Desert)
   특정 엔지니어에게 온콜이 전혀 없는 주나 주말이 거의 없는, 메마른 구간이 있나요?

이 모든 것을 리포트나 대시보드로도 찾아낼 수는 있습니다. 하지만 벽 위에서는 인간의 시각 인지 속도가 압도적입니다. 패턴이 SQL 쿼리가 아니라, 색과 형태로 곧장 눈에 들어옵니다.

나만의 인시던트 열차 시간표 벽화 만들기

화가일 필요는 없습니다. 필요한 건 테이프, 마커, 그리고 빈 벽 한 면입니다.

1. 시간 범위를 정한다
   대표적인 선택지는:

   • 1분기(12–13주)
   • 작은 팀이라면 6–8주

2. 축을 정의한다

   • 가로축: 일(day) 또는 주(week)
   • 세로축: 서비스, 팀, 혹은 도메인

3. 역할과 레벨을 매핑한다
   각 세로 레인에 무엇을 그릴지 결정합니다.

   • 1차 온콜(Primary)
   • 2차/백업(Secondary/Backup)
   • Incident Commander 로테이션
   • 섀도/트레이니(Shadow/Trainee)

4. 색과 선 스타일을 정한다

   • 역할별로 색을 나눕니다(예: 파란색 = 1차, 초록색 = 백업, 주황색 = IC).
   • 섀도는 점선이나 더 얇은 선으로 표현합니다.

5. 에스컬레이션 표시를 추가한다

   • 다른 팀이나 역할로 에스컬레이션되는 지점을 작은 화살표나 아이콘으로 표시합니다.

6. 팀이 직접 주석을 달게 한다

   • 부담이 큰 주간을 동그라미로 표시합니다.
   • 큰 릴리즈, 계절적 피크 등 리스크가 큰 날짜를 표시합니다.
   • 명백한 문제에 메모를 붙입니다(“여기 1차 한 명뿐”, “이 서비스는 섀도가 없음”).

7. 정기적으로 리뷰하고 개선한다
   벽을 다음 자리에서 적극 활용합니다.

   • 분기 계획 회의
   • 인시던트 포스트모템
   • 팀 회고

   그리고 이렇게 물어봅니다. 누가 과도하게 노출되어 있지 않은가? 어디에 중복성이 부족한가? 다음 로테이션에서는 이 리듬을 어떻게 더 좋게 만들 수 있을까?

혼돈 속에 평정을: 왜 여전히 아날로그가 중요한가

벽화는 인시던트 툴이나 정식 스케줄링 시스템을 대체하지 않습니다. 대신 더 미묘하지만 중요한 일을 합니다.

• 온콜 스케줄을 모두가 볼 수 있고, 질문하고, 개선할 수 있는 공유 아티팩트로 바꿔 줍니다.
• 온콜을 단순한 당번표가 아니라, 살아 움직이는 리듬으로 보는 시스템적 사고를 촉진합니다.
• 단순 커버리지를 넘어 **평정(차분함)**을 설계하게 돕습니다. 놀라움은 줄이고, 부담은 공정하게 나누며, 기대치는 명확해집니다.

디지털이 지배하는 세상에서, 벽 전체에 인시던트 시간표를 그리는 일은 다소 급진적으로 느껴질 수 있습니다. 하지만 다음 대형 장애가 터졌을 때, 단순히 캘린더만 채워 넣은 팀과, 온콜 시스템을 설계해 둔 팀의 차이는 분명하게 드러납니다. 후자는 더 높은 자신감과 더 나은 공조, 훨씬 적은 공황 속에서 인시던트를 처리하게 될 것입니다.

고신뢰의 하이테크 시스템을 만들고 싶다면, 때로는 테이프와 마커, 그리고 빈 벽 한 면에서 시작해야 합니다.