역할과 선언

한 줄 요약

큰 사고에서 가장 먼저 무너지는 것은 서버가 아니라 「지금 누가 무엇을 하고 있는가」 입니다. 역할을 나누고, 일찍 선언하고, 결정마다 주인을 정하는 것이 그 질서를 지킵니다.

왜 이게 필요했나

새벽에 결제 오류 경보가 울렸다고 해 봅시다. 채널에 다섯 명이 들어오고, 모두 유능하고, 모두 옳은 일을 합니다. 한 사람은 롤백을 시작하고, 다른 사람은 같은 순간 같은 서버를 재시작하고, 세 번째 사람은 캐시를 비울지 묻는데 아무도 대답하지 않습니다. 고객센터는 무슨 일인지 몰라 「확인 중입니다」 만 반복합니다. Google SRE 책 14장(Managing Incidents)은 바로 이런 「관리되지 않는 사고」 를 첫 장면으로 보여 줍니다 — 개인의 실력이 아니라 조정의 부재가 사고를 키운다는 것이죠.

선언을 미루는 것도 같은 뿌리입니다. 「별일 아닐 수도 있는데 괜히 크게 만들까 봐」 미룹니다. 하지만 선언의 비용은 채널 하나와 역할 세 개이고, 늦은 선언의 비용은 그동안 아무도 공지하지 않고 아무도 지휘하지 않은 시간 전체입니다.

어떻게 동작하나

역할은 셋이 기본입니다(규모가 커지면 계획·기록 담당을 더합니다).

역할	하는 일	하지 않는 일
IC(지휘)	우선순위·결정·역할 배정, 상황 파악	직접 손으로 고치기 — 손이 바쁘면 지휘가 빈다
Ops(운영)	시스템을 실제로 바꾸는 손	혼자 판단해 범위 넓히기
Comms(공지)	정해진 간격으로 바깥에 상황 공지	추측 숫자 내보내기

규칙 몇 가지가 이 표를 지탱합니다. 역할은 명시적으로 넘깁니다 — 「IC 넘깁니다」 와 함께 기록이 남아야 다음 사람이 압니다. 결정에는 주인이 있습니다 — 주인 없는 결정은 두 사람이 동시에 하거나 아무도 안 합니다. 손을 대기 전에 「지금 이걸 하고 있다」 를 알리면 겹치는 작업이 사라집니다. 많은 팀이 채팅 봇 명령(/declare, /role, /own 같은)으로 이것을 기록에 남깁니다.

선언 기준은 미리 정해 둡니다. 사용자 영향이 보인다, 혼자 30분 안에 끝낼 자신이 없다, 둘 이상의 팀이 필요하다 — 이 중 하나면 선언합니다. 그리고 시간을 잽니다: 첫 경보 → 첫 응답(ack) → 선언 → 완화 → 종료. 이 간격들이 다음 개선의 출발점입니다.

상황 공지는 형식이 있습니다. 무엇이 얼마나(숫자) 언제부터 영향을 받는지, 누가 지휘하는지, 다음 공지는 언제인지. 숫자는 「많이」 가 아니라 데이터에서 센 값이어야 하고, 다음 공지 시각은 심각도별 간격을 지킵니다. 간격을 지키는 것이 숫자보다 중요할 때도 있습니다 — 「아직 원인을 모릅니다, 30분 뒤 다시 알리겠습니다」 도 공지이고, 침묵은 공지가 아닙니다.

채널 기록은 이렇게 남습니다. 봇 명령이 있으면 나중에 누가 언제 무엇을 맡았는지를 기계적으로 다시 셀 수 있습니다.

13:04:47 jun     결제 오류 경보 받았습니다. 보는 중이에요
13:17:12 jun     /declare sev2 결제 실패 증가        ← 첫 경보에서 13분
13:17:54 alex    /role ic @alex
13:18:56 alex    /role comms @blake
13:27:05 alex    /decide D1 결제 v2 기능 플래그 끄기  ← 주인(/own)이 없다
13:28:05 casey   /doing D1
13:29:04 drew    /doing D1                         ← 앞사람이 끝내기 전 — 겹쳤다
13:35:52 alex    /role ic @erin                    ← IC 를 넘겼다. 이 뒤의 alex 는 손이다

마지막으로 호출입니다. 지휘는 호출이 사람에게 닿아야 시작됩니다. 호출 서비스는 경보 이름을 경로 규칙으로 팀에 잇고, 그 팀의 에스컬레이션 정책을 단계별로 따라가며, 단계마다 그 시각의 당번(교대 표가 당번표보다 먼저)을 찾아 그 사람의 연락 수단으로 부릅니다. 이 사슬의 고리 하나만 끊겨도 첫 단계는 조용히 실패하고, 다음 단계(대개 팀장)는 15분이나 20분 뒤에야 울립니다. 에스컬레이션은 안전망이지 첫 응답이 아닙니다.

현장에서 만나는 모습

가장 흔한 실패는 IC 가 손을 대는 것입니다. 롤백을 제일 잘 아는 사람이 IC 를 맡고, 롤백을 직접 하느라 30분 동안 아무도 공지하지 않고 다른 결정이 멈춥니다. 그래서 IC 를 넘긴 뒤에 손을 대는 것은 괜찮지만, IC 인 채로 손을 대는 것은 기록으로 드러나야 합니다. 두 번째로 흔한 것은 호출이 아예 닿지 않는 것입니다. 새로 온 사람의 연락처가 비어 있거나, 휴가 교대가 퇴사자를 가리키거나, 경보 이름이 바뀌어 경로 규칙과 안 맞으면 지휘는 시작조차 못 합니다. 지휘는 호출이 닿는 데서 시작합니다.

이런 결함은 사고가 나야 드러나기 때문에, 성숙한 팀은 사고 사이에 확인합니다. 일주일 당번표를 모의기에 넣어 「아무 시각에나 울리면 누가 받는가」 를 미리 돌려 보고, 선언까지 걸린 시간과 IC 가 손댄 횟수를 분기마다 세어 봅니다. 숫자가 있어야 다음 분기에 나아졌는지 말할 수 있습니다.

다음 실습에서 할 것

결제 사고 채널 기록(채팅·호출·주문)을 펼쳐 선언까지 걸린 시간, 역할이 넘어간 흐름, IC 가 손댄 결정, 주인 없는 결정과 겹친 작업을 데이터로 찾고, 정해진 형식의 상황 공지를 계산한 숫자로 씁니다. 마지막에는 세 팀의 호출이 왜 20분 동안 아무에게도 닿지 않았는지 호출 설정에서 찾아 고칩니다.