금요일 오후 4시, 결제가 멈췄습니다.
처음엔 평소 인시던트처럼 보였습니다. 한 엔지니어가 조용히 로그를 뒤지기 시작합니다. 10분 뒤, 고객센터에 문의가 쏟아지고, 영업팀이 "지금 결제 안 되냐"고 메신저로 묻고, 임원이 직접 전화를 겁니다. 엔지니어는 복구를 하랴, 질문에 답하랴, 양쪽 다 제대로 못 합니다. 30분이 지나도 누가 무엇을 하는지 아무도 모릅니다. 같은 질문이 다섯 번 들어오고, 서로 다른 두 사람이 같은 서버를 동시에 만지다 상황을 더 악화시킵니다.
옆 회사도 같은 시각 같은 장애가 났습니다. 그런데 거기서는 5분 만에 한 사람이 "이건 메이저 인시던트입니다. 제가 IC를 맡겠습니다"라고 선언합니다. 채널 하나가 열리고, 복구할 사람과 보고할 사람이 갈립니다. 30분마다 "지금 상황은 이렇습니다"가 또박또박 나갑니다. 임원도, 고객도 같은 메시지를 봅니다.
두 회사의 차이는 기술이 아니라 지휘 체계였습니다. 이 모듈은 큰불이 났을 때 누가 지휘하고, 어떻게 채널을 모으고, 어떻게 일관되게 알리는지 — 메이저 인시던트와 워룸을 다룹니다.
- 1일반 인시던트와 메이저 인시던트(MI)를 영향 규모·매출·평판·다수 서비스 기준으로 구분해 선언할 수 있다
- 2인시던트 커맨더(IC)·커뮤니케이션 담당(Comms)·기술 대응(Ops)의 역할을 나누고, 평시에 미리 정의해야 하는 이유를 설명할 수 있다
- 3워룸을 단일 채널·타임라인 기록·역할 분리 원칙으로 운영할 수 있다
- 4내부·경영·고객 대상별 상태 업데이트 주기와 공지 템플릿을 설계할 수 있다
- 5MI 종료 기준을 판단하고, 근본 원인과 재발 방지를 포스트모템으로 넘기는 흐름을 그릴 수 있다
무엇이 '메이저' 인시던트인가
크기는 기술 난이도가 아니라 '영향'으로 정한다
모든 인시던트가 워룸을 열 만큼 큰 것은 아닙니다. 대부분은 평소 절차 — 접수, 우선순위, 담당자 배정 — 로 충분히 처리됩니다. 그런데 어떤 장애는 한 사람, 한 팀의 평소 방식으로는 감당이 안 됩니다. 그때 **메이저 인시던트(Major Incident, MI)**로 격을 올려, 다른 지휘 체계를 가동합니다.
핵심은 **'기술적으로 어려운가'가 아니라 '서비스와 비즈니스에 얼마나 큰 영향을 주는가'**입니다. 고치기 까다로운 버그라도 영향이 작으면 일반 인시던트고, 고치는 법은 간단해도 전 고객이 결제를 못 하면 메이저입니다.
MI를 선언하는 대표적인 신호:
- 영향 규모 — 다수 고객·전사·핵심 서비스가 동시에 중단·저하된다.
- 매출·거래 — 결제·주문·정산처럼 돈이 직접 멈춘다.
- 평판·신뢰 — 외부에 노출되어 고객 이탈·언론·소셜 확산 위험이 있다.
- 규제·안전·데이터 — 개인정보 유출, 규제 위반, 안전 위협이 얽힌다.
- 수습 난도 — 한 팀의 평소 절차로는 안 되고, 여러 팀의 동시 대응과 지휘·조율이 필요하다.
이 신호 중 몇 개가 동시에 켜지면, 망설이지 말고 MI로 선언하는 편이 낫습니다. '과하게 선언했다 내리는 비용'보다 '늦게 선언해 30분을 허비하는 비용'이 훨씬 큽니다.
누가 무엇을 맡는가 — IC·Comms·Ops
불 끄는 사람과 보고하는 사람을 갈라야 한다
큰불에서 가장 흔한 실패는 한 사람이 복구도 하고 보고도 하려는 것입니다. 복구에 몰입하면 보고가 끊기고, 보고에 끌려가면 복구가 느려집니다. 그래서 메이저 인시던트는 역할을 명확히 나눕니다.
| 역할 | 한 줄 정의 | 하는 일 | 하지 말아야 할 일 |
|---|---|---|---|
| 인시던트 커맨더(IC) | 지휘·결정의 단일 책임자 | 상황 종합, 우선순위·다음 행동 결정, 역할 배정, 종료 선언 | 직접 키보드를 잡고 복구에 매달리는 것 |
| 커뮤니케이션 담당(Comms) | 안팎으로 나가는 메시지의 단일 창구 | 주기적 상태 업데이트 작성·발송, 내부·경영·고객 대상 메시지 조율 | 미확정 원인·추측을 외부에 흘리는 것 |
| 기술 대응(Ops) | 실제로 불을 끄는 사람(들) | 원인 조사, 임시 복구, 영구 조치 시도 | 외부 질문에 일일이 직접 답하느라 손이 멈추는 것 |
핵심 원칙 세 가지:
- IC는 지휘에 전념한다. IC가 직접 복구에 들어가면 전체를 보는 눈이 사라집니다. IC의 손은 키보드가 아니라 '결정'에 쓰여야 합니다.
- 모든 외부 소통은 Comms를 통한다. 임원이 Ops에게 직접 물어도, Ops는 "Comms가 곧 업데이트 드립니다"로 돌려 손을 지킵니다.
- 이 역할들은 평시에 미리 정의한다. 불이 난 뒤에 "누가 IC지?"를 정하면 이미 늦습니다. 누가 IC를 맡을 수 있는지, 시간대별 당번(온콜)은 누구인지, 어떻게 호출하는지를 평소에 정해 문서로 둬야 합니다.
규모가 작으면 한 사람이 IC와 Comms를 겸할 수도 있습니다. 중요한 것은 직책 수가 아니라 '지휘·소통·복구'라는 세 가지 일이 서로를 잡아먹지 않게 분리되는 것입니다.
그림: 워룸의 역할 분리 — 지휘(IC)·소통(Comms)·복구(Ops)가 서로를 잡아먹지 않게 나눈다.
워룸은 어떻게 굴러가는가
단일 채널·타임라인·역할 분리
워룸(war room)은 물리적인 회의실일 수도, 화상회의·전용 채팅 채널일 수도 있습니다. 형태보다 중요한 건 운영 규칙입니다.
- 단일 채널(single source of truth). 대응에 관한 모든 대화는 한 채널로 모읍니다. 여기저기 흩어진 DM과 메신저는 정보를 쪼개고 같은 질문을 반복하게 만듭니다. "이 장애 이야기는 전부 이 채널에서"가 원칙입니다.
- 타임라인 기록. 무슨 일이 몇 시 몇 분에 일어났는지, 어떤 조치를 했고 결과가 어땠는지를 시간순으로 남깁니다. 이 기록은 (1) 지금 들어온 사람이 빠르게 따라잡게 하고, (2) 나중에 포스트모템의 1차 자료가 됩니다. 기록은 보통 IC가 지정한 한 사람(서기/Scribe)이 맡습니다.
- 역할 분리의 실천. 채널 상단에 "IC: OOO / Comms: OOO / Ops: OOO"를 고정해 두면 누구에게 무엇을 물어야 할지 한눈에 보입니다. 불 끄는 사람과 보고하는 사람이 섞이지 않게 하는 가장 단순한 장치입니다.
- 들어오고 나가는 규칙. 워룸에는 필요한 사람만 들이고, 구경꾼은 별도 공지 채널로 보냅니다. 사람이 많을수록 잡음이 늘고 IC의 지휘가 흐려집니다.
워룸의 목표는 '많이 모이는 것'이 아니라 **'결정과 행동이 한 줄기로 흐르게 하는 것'**입니다.
워룸은 즉흥적으로 굴러가지 않고 정해진 박자를 탑니다. ① 선언·소집에서 역할을 지정하고 첫 공지를 내보낸 뒤, ② 안정화에서 영향을 먼저 차단하고 주기적으로 업데이트하며, ③ 복구·확인에서 정상화를 모니터링으로 검증하고, ④ 해제·인계에서 IC가 종료를 선언하며 원인 규명을 문제관리·포스트모템으로 넘깁니다. 국면마다 IC가 던지는 한 문장(예: 안정화 때 "지금 영향을 멈출 가장 빠른 방법은?")이 팀의 초점을 한 방향으로 모읍니다. 여기서도 원칙은 같습니다 — 워룸은 복구까지, 원인 규명과 재발방지는 별도로 인계합니다.
안팎으로 어떻게 알릴 것인가
정해진 주기·정해진 템플릿·단일 창구
큰 장애일수록 사람들을 불안하게 만드는 건 장애 자체보다 **'아무 소식이 없는 것'**입니다. 그래서 메이저 인시던트의 커뮤니케이션은 세 가지 규칙을 따릅니다.
- 정해진 주기로 보낸다. 새로운 사실이 없어도 정해진 간격(예: 30분 간격)으로 "아직 원인 조사 중입니다"라도 보냅니다. 침묵은 "방치되고 있다"는 신호로 읽힙니다.
- 대상별로 메시지를 맞춘다. 같은 사건이라도 받는 사람에 따라 알고 싶은 게 다릅니다.
- 단일 창구(Comms)에서 일관되게 나간다. 서로 다른 사람이 제각각 보내면 메시지가 충돌하고 신뢰가 무너집니다.
| 대상 | 알고 싶은 것 | 톤·내용 |
|---|---|---|
| 내부 대응팀 | 지금 무엇이 사실이고 다음에 뭘 하나 | 기술적·구체적, 타임라인 중심 |
| 경영진 | 영향 범위·매출 영향·예상 복구 시점·결정이 필요한가 | 간결한 요약, 비즈니스 언어 |
| 고객·외부 | 무엇이 영향받았고 우리가 대응 중인가 | 사과·공감, 확정된 사실만, 추측 금지 |
고객 공지에서 특히 중요한 것: 확정되지 않은 원인이나 복구 시점을 함부로 약속하지 않습니다. "오후 5시까지 복구"라고 했다가 어기면 한 번 더 신뢰를 잃습니다. "최대한 빠르게 복구 중이며 다음 업데이트는 30분 내"가 안전합니다.
직접 해보기 — 타임라인과 고객 공지문 만들기
워룸에서 서기(Scribe)가 남기는 타임라인은 사후 포스트모템의 1차 자료가 됩니다. 아래처럼 시각 · 사실/조치 · 담당 · 다음 행동 네 칸으로, 추측이 아니라 일어난 일만 기록합니다. 결제 장애를 가정한 예시입니다.
시각 | 사실 / 조치 | 담당 | 다음 행동
16:02 | 결제 성공률 급락 감지(알림 발생) | Ops | 영향 범위 확인
16:05 | 전 고객 결제 실패 확인 → MI 선언, IC 지정 | IC | 워룸 채널 개설
16:08 | 결제 게이트웨이 응답 지연으로 1차 추정 | Ops | 게이트웨이 상태 점검
16:10 | 1차 내부·고객 공지 발송(발생 인지 단계) | Comms | 30분 후 업데이트 예약
16:25 | 최근 배포 롤백 시작 | Ops | 롤백 후 성공률 관찰
16:40 | 롤백 완료, 결제 성공률 정상 회복 관찰 | Ops | 5분간 안정성 확인
16:47 | 정상 확인 → IC가 복구·MI 종료 선언 | IC | 포스트모템 일정 예약
이 표를 직접 채워 보며, 모든 칸을 '확정된 사실'로 채울 수 있는지 점검하세요. 비어 있거나 추측으로 채워지는 칸이 있다면, 그건 아직 모르는 것입니다 — 외부 공지에 넣으면 안 되는 부분입니다.
시각 / 사실·조치 / 담당 / 다음 행동 4열로 기록고객 공지는 사건 단계마다 톤과 내용이 달라집니다. 아래 네 단계 템플릿을 채워 보세요. 공통 규칙: 확정된 사실만, 다음 업데이트 시점은 항상 명시.
[1단계: 발생 인지]
현재 (서비스명) 이용에 일부 지장이 발생하고 있음을 확인했습니다.
원인을 파악하고 있으며, 다음 안내는 (시각) 또는 30분 내 드리겠습니다.
불편을 드려 죄송합니다.
[2단계: 영향 안내]
(서비스명)의 (결제/로그인 등) 기능이 정상 작동하지 않고 있습니다.
영향 범위: (전체/일부 고객). 데이터 손실은 (확인되지 않았습니다/조사 중입니다).
복구를 위해 대응 중이며, 다음 안내는 30분 내 드리겠습니다.
[3단계: 조치중]
현재 (조치 내용, 예: 최근 변경 사항 롤백)을 진행하고 있습니다.
서비스가 점진적으로 회복되는 것을 확인하고 있으며,
안정성 확인 후 정상화를 안내드리겠습니다. 다음 안내는 30분 내.
[4단계: 복구]
(시각) 기준 (서비스명)이 정상 복구되었음을 확인했습니다.
장애 시간 동안 불편을 드려 죄송합니다.
원인과 재발 방지 대책은 별도로 정리해 공유드리겠습니다.
발생 인지 → 영향 → 조치중 → 복구 4단계 템플릿- 타임라인 표의 모든 칸이 "확정된 사실"로 채워졌는가 — 추측 칸이 있으면 외부 공지에서 빼야 한다
- 타임라인에 MI 선언 시각·IC 지정 시각·종료 선언 시각이 명확히 찍혀 있는가
- 공지문 1~3단계마다 "다음 안내는 30분 내" 같은 다음 업데이트 시점이 빠짐없이 들어갔는가
- 복구 단계(4단계) 공지가 "원인·재발 방지는 별도 공유"로 포스트모템과 연결되어 있는가
- 내부용·경영용·고객용 메시지의 톤과 정보량이 대상에 맞게 달라졌는가(고객용엔 추측·미확정 원인이 없는가)
- 핵심 감각: 침묵이 가장 나쁜 공지다 — 새 사실이 없어도 "아직 조사 중"이라도 주기적으로 나가야 한다
현장에서 자주 보는 함정
증상: 가장 실력 있는 사람이 IC로 지정됩니다. 그런데 그 사람이 문제를 보자마자 직접 복구에 뛰어듭니다. 30분 뒤, 누가 무엇을 하는지 아무도 모르고, 고객 공지는 한 번도 안 나갔으며, 임원의 질문은 답 없이 쌓입니다. IC는 화면에 코를 박은 채 "거의 다 됐어요"만 반복합니다.
원인: '가장 잘 고치는 사람'과 '가장 잘 지휘하는 사람'을 같은 사람으로 본 것입니다. 복구에 몰입하면 시야가 좁아져 전체 상황·우선순위·소통이 모두 멈춥니다. 지휘 공백은 큰불을 더 키웁니다.
해결 방향:
- IC는 지휘에 전념하고, 복구는 Ops가 맡도록 처음부터 손을 뗀다. 에이스가 꼭 직접 고쳐야 한다면, 그 사람은 Ops로 들어가고 IC는 다른 사람이 맡는다.
- 채널 상단에 IC·Comms·Ops를 고정 표기해 역할을 시각화한다.
- Comms는 IC와 별개로 두어, 새 사실이 없어도 30분 간격으로 상태 업데이트가 나가게 한다.
- 평시 훈련(게임데이)에서 'IC는 키보드를 잡지 않는다'를 반복 연습한다 — 실전에서 처음 해보면 반드시 키보드로 손이 간다.
워룸의 IC는 '가장 잘 고치는 사람'이 아니라 '전체를 보고 결정하는 사람'입니다.
국내 SI·SM 현장에서 메이저 인시던트는 단순한 기술 사건이 아니라 계약·책임의 사건이 됩니다. 발주사(고객사)의 핵심 서비스가 멈추면, 운영(SM) 담당과 PM은 SLA(서비스 수준 협약) 위반 여부, 패널티, 보고 의무를 동시에 떠안습니다. 이때 협력사(하도급) 엔지니어가 실제 복구를 하더라도, **"언제 인지했고, 누가 지휘했고, 고객에 어떻게 알렸는가"**를 설계·통제하는 책임은 관리자에게 있습니다.
그래서 현장에서 관리자는 평소에 (1) MI 선언 기준과 IC 당번, (2) 발주사 보고 라인과 보고 주기(예: 30분 간격), (3) 단계별 공지 템플릿을 문서로 준비해 둡니다. 장애가 터진 그 순간에 "누가 고객사에 전화하지?"를 정하기 시작하면, 이미 신뢰는 깎이고 있습니다. 잘 정리된 타임라인은 사후에 발주사와 책임 범위를 다툴 때도 결정적 근거가 됩니다 — "우리는 16시 5분에 인지해 16시 47분에 복구했고, 매 30분 보고했다"는 기록이 곧 관리 역량의 증거입니다.
기술을 아는 관리자는 워룸에서 Ops의 추정과 사실을 구분할 줄 알고, 확정되지 않은 원인이 고객 공지로 새어 나가는 것을 막습니다. 이 판단이 평판을 지킵니다.
관련 모듈로 더 깊이:
- 우선순위와 에스컬레이션 — MI 선언의 전 단계인 우선순위 판정과 에스컬레이션 발동 기준
- 포스트모템 — 워룸 종료 후 책임 추궁 없이 재발을 막는 포스트모템으로 넘기는 흐름
다음 모듈에서는 큰불이 아닌 평상시의 첫 접점 — 사용자의 신고와 요청이 가장 먼저 닿는 **서비스 데스크(Service Desk)**가 어떻게 구성되고, 어떤 기준으로 접수·분류·1차 대응을 하는지를 다룹니다.