필사 모드: 인시던트 커뮤니케이션: 장애 상황의 대화법

• 들어가며 — 복구는 절반의 일이다
• 인시던트 커맨더 — 고치지 않는 사람
• 상태 업데이트의 리듬 — 소식이 없어도 두드려라
• 세 가지 질문 — 모든 업데이트가 답해야 하는 것
• 비난 없는 포스트모템 — 사람이 아니라 시스템을 탓하라
• 5 Whys — 증상에서 근본 원인까지
• 고객 커뮤니케이션 vs 내부 커뮤니케이션
• 침착함 — 어조가 방의 공기를 정한다
• 마치며
• 참고 자료

들어가며 — 복구는 절반의 일이다

새벽 3시, 페이저가 울립니다. 결제 API가 5xx를 쏟아내고, 대시보드는 전부 빨간색입니다. 여러분은 로그를 파고, 원인을 좁히고, 롤백을 준비합니다. 여기까지가 여러분이 훈련받은 일입니다. 그런데 이것은 일의 절반에 불과합니다.

나머지 절반은 대화입니다. 지금 무슨 일이 벌어지고 있는지 팀에 알리고, 누가 무엇을 맡을지 정리하고, 고객에게 상황을 전하고, 경영진의 "지금 어떻게 돼 가?"라는 질문에 답하는 일. 이 절반을 못 하면, 기술적으로는 20분이면 끝났을 짧은 장애가 하루 종일 이어지는 신뢰의 위기로 번집니다. 사람들이 서로 다른 정보를 붙잡고 중복 작업을 하고, 고객은 침묵 속에서 최악을 상상하고, 복구가 끝난 뒤에도 "대체 무슨 일이 있었냐"는 질문이 며칠을 갑니다.

이 글은 그 나머지 절반을 다룹니다. 인시던트 커맨더라는 역할, 상태 업데이트의 리듬, 모든 업데이트가 답해야 할 세 가지 질문, 비난 없는 포스트모템과 5 Whys, 고객과 내부를 향한 서로 다른 커뮤니케이션, 그리고 이 모든 것을 지탱하는 침착함에 대해서 이야기하겠습니다.

인시던트 커맨더 — 고치지 않는 사람

혼란스러운 장애 대응에서 가장 먼저 필요한 것은 한 명의 조율자입니다. 이 사람을 인시던트 커맨더(Incident Commander, 이하 IC)라고 부릅니다. IC의 핵심은 역설적입니다.

IC의 일은 장애를 고치는 것이 아니라, 장애를 고치는 사람들을 조율하는 것이다.

IC가 직접 키보드를 잡고 디버깅에 뛰어드는 순간, 조율하는 사람이 사라집니다. 그러면 아무도 전체 그림을 보지 못하고, 여러 사람이 같은 가설을 중복해서 파고, 누구도 고객이나 경영진에게 상황을 전하지 못합니다. IC는 손을 비워 두어야 합니다. 그래야 결정을 내리고, 자원을 배분하고, 소통을 관장할 수 있습니다.

효과적인 대응은 역할을 명확히 나눕니다. 규모가 작은 장애라면 한 사람이 여러 역할을 겸할 수 있지만, 역할 자체는 개념적으로 분리되어 있어야 합니다.

• 인시던트 커맨더(IC): 전체를 조율하는 단일 지휘자. 결정을 내리고, 작업을 위임하고, 우선순위를 정합니다. 직접 고치지 않습니다.
• 커뮤니케이션 리드(comms lead): 외부와 상위로 향하는 소통을 담당합니다. 상태 페이지 업데이트, 고객 공지, 경영진 보고를 맡아 IC와 대응팀이 소통 부담에서 벗어나게 합니다.
• 운영/도메인 전문가(ops, subject-matter expert): 실제로 손을 움직여 문제를 진단하고 고치는 사람들입니다. 해당 시스템을 가장 잘 아는 엔지니어가 여기 들어갑니다.
• 스크라이브(scribe): 타임라인을 기록합니다. 몇 시 몇 분에 무슨 일이 있었고, 어떤 결정을 내렸고, 무엇을 시도했는지를 실시간으로 남깁니다. 이 기록이 나중에 포스트모템의 뼈대가 됩니다.

이 구조의 힘은 인지 부하의 분산에 있습니다. 한 사람이 진단하면서 동시에 고객 공지를 쓰고 경영진 질문에 답하려 하면, 셋 다 엉성해집니다. 역할을 나누면 각자가 한 가지에 집중할 수 있습니다. 그리고 누가 IC인지 모두가 분명히 알아야 합니다. "지금 지휘는 내가 맡습니다"라는 명시적 선언 한마디가, 열 명이 우왕좌왕하던 채널을 한순간에 정렬시킵니다.

상태 업데이트의 리듬 — 소식이 없어도 두드려라

장애 중 침묵은 정보의 부재가 아니라 불안의 증폭기입니다. 상태 업데이트가 뜸해지면, 지켜보는 사람들은 "다들 손 놓은 건가?", "상황이 더 나빠졌나?"를 상상하기 시작합니다. 그래서 좋은 인시던트 커뮤니케이션의 핵심 원칙은 이것입니다.

새로운 소식이 없더라도, 규칙적인 리듬으로 업데이트하라.

이것을 흔히 **드럼비트(drumbeat)**라고 부릅니다. 심각도에 따라 15분, 30분, 60분 같은 주기를 정하고, 그 주기를 지킵니다. 진전이 없는 주기에도 "여전히 원인을 조사 중이며, 새로운 진전은 없습니다"라고 알립니다. 이 한 문장이 "우리는 여전히 여기 있고, 이 문제를 놓지 않았다"는 신호를 줍니다. 침묵보다 훨씬 안심되는 신호입니다.

여기서 결정적인 습관 하나가 다음 업데이트 시각을 명시하고 지키는 것입니다. 모든 업데이트를 이런 문장으로 끝내세요.

• "다음 업데이트는 14:30에 드리겠습니다."
• "추가 소식은 30분 뒤, 늦어도 15:00에 공유합니다."

이렇게 하면 지켜보는 사람들이 언제 다음 소식이 올지 알기 때문에, 그 사이에는 채널을 계속 새로고침하거나 담당자에게 "어떻게 됐어요?"를 반복해서 묻지 않습니다. 그리고 이것은 약속입니다. 14:30이라고 했으면 14:30에는 반드시 무언가를 올려야 합니다. 설령 그 내용이 "아직 조사 중이고, 다음 업데이트는 15:00입니다"뿐이더라도 말입니다. 명시한 시각을 어기는 순간, 여러분이 애써 쌓은 신뢰가 무너집니다.

세 가지 질문 — 모든 업데이트가 답해야 하는 것

상태 업데이트를 어떻게 쓰면 좋을지 막막할 때, 딱 세 가지 질문만 기억하면 됩니다. 좋은 업데이트는 언제나 이 셋에 답합니다.

1. 우리가 무엇을 아는가 (what do we know) — 지금까지 파악한 사실. 무엇이 영향을 받았고, 그 범위는 어디까지인가. 사실과 추측을 섞지 말고, 확인된 것만 사실로 말하세요.
2. 우리가 무엇을 하고 있는가 (what are we doing) — 현재 진행 중인 조치. 어떤 가설을 검증 중이고, 어떤 완화책을 적용했으며, 다음 단계는 무엇인가.
3. 다음 업데이트는 언제인가 (when's the next update) — 앞서 강조한 그 약속. 명시적인 시각을 반드시 포함합니다.

이 세 질문의 틀이 훌륭한 이유는, 그것이 곧 지켜보는 사람이 진짜로 알고 싶어 하는 전부이기 때문입니다. 사람들은 스택 트레이스나 내부 논쟁을 원하지 않습니다. 지금 상황이 어떤지, 무언가 조치되고 있는지, 언제 다시 들을 수 있는지 — 그것만 알면 안심합니다.

트리아지 초반에는 특히 "무엇을 아는가"를 빠르게 세우는 것이 중요합니다. 예를 들어 5xx 에러가 급증했는지 4xx가 급증했는지만 구분해도 문제가 서버 쪽인지 클라이언트 쪽인지 방향이 잡힙니다. 상태 코드의 의미가 헷갈릴 때는 HTTP 상태 코드 같은 참조를 옆에 두고 빠르게 확인하면, 잘못된 방향으로 30분을 허비하는 일을 막을 수 있습니다.

실제 내부 슬랙 업데이트는 이런 모습입니다. 세 질문에 모두 답하고, 다음 업데이트 시각을 못 박습니다.

[인시던트 #4021] 결제 API 장애 — 업데이트 3 (14:05 KST)

무엇을 아는가:
  - 14:00부터 결제 승인 API의 약 40%가 5xx로 실패 중.
  - 원인은 오늘 13:50 배포된 결제 서비스 v2.7.3으로 좁혀짐.
  - 조회/장바구니 등 다른 기능은 정상.

무엇을 하고 있는가:
  - v2.7.2로 롤백 진행 중 (배포 파이프라인 실행됨, 완료 예상 ~14:15).
  - 롤백 후 승인 성공률 회복 여부를 모니터링 예정.

영향:
  - 신규 결제 시도가 실패 또는 지연. 데이터 유실은 확인되지 않음.

다음 업데이트: 14:20, 또는 롤백 완료 즉시 (더 빠른 쪽).
IC: 김영주 / Comms: 이서준

이 형식이 몸에 배면, 새벽 3시에 머리가 멍한 상태에서도 빈칸을 채우듯 업데이트를 쓸 수 있습니다.

비난 없는 포스트모템 — 사람이 아니라 시스템을 탓하라

장애가 끝나면 포스트모템(사후 분석)을 씁니다. 여기서 가장 중요한 원칙은 **비난 없음(blameless)**입니다.

비난 없는 포스트모템의 요지는, 잘못을 저지른 사람을 찾는 것이 아니라 그런 잘못이 가능했던 시스템과 프로세스를 탓하는 것입니다. 엔지니어가 설정 파일을 잘못 배포해 장애가 났다면, 질문은 "누가 그랬는가"가 아니라 "왜 우리 시스템은 한 사람의 실수 하나가 전체를 무너뜨리도록 허용했는가"가 되어야 합니다. 왜 검증 단계가 그것을 잡아내지 못했는가? 왜 잘못된 설정이 그렇게 쉽게 프로덕션까지 갈 수 있었는가? 왜 롤백이 그렇게 오래 걸렸는가?

이 원칙이 실용적인 이유는 도덕이 아니라 정보의 질 때문입니다. 사람을 탓하는 문화에서는 아무도 진실을 말하지 않습니다. 자기 실수를 인정하면 처벌받을 것을 아는 사람은, 타임라인을 흐리고, 자신이 무엇을 눌렀는지 감추고, 방어적으로 변합니다. 그러면 정작 시스템의 진짜 약점은 영원히 드러나지 않고, 똑같은 장애가 다른 사람의 손에서 반복됩니다.

반대로 **심리적 안전(psychological safety)**이 있으면, 사람들은 정직하게 말합니다. "제가 이 명령을 실행했고, 이 경고를 무시했고, 이 부분을 확인 안 했습니다"라고 솔직하게 밝힐 수 있어야, 그 지점에 가드레일을 세울 수 있습니다. 정직한 타임라인은 심리적 안전에서만 나오고, 정직한 타임라인 없이는 진짜 교훈도 없습니다.

비난 없는 포스트모템이 답해야 할 것들은 대략 이렇습니다.

• 무슨 일이 있었나: 사실에 근거한 타임라인 (스크라이브의 기록이 여기서 빛납니다).
• 영향은 무엇이었나: 얼마나 오래, 얼마나 많은 사용자/요청에, 어떤 형태로.
• 왜 일어났나: 근본 원인(들). 사람이 아니라 조건과 시스템.
• 어떻게 탐지/대응했나: 무엇이 잘 됐고 무엇이 느렸나.
• 재발을 어떻게 막을 것인가: 구체적이고 담당자와 기한이 있는 액션 아이템.

5 Whys — 증상에서 근본 원인까지

근본 원인을 파고드는 고전적 기법이 **5 Whys(다섯 번의 왜)**입니다. 도요타 생산 시스템에서 유래한 이 방법은 단순합니다. 표면의 증상에서 시작해 "왜?"를 반복해서 물으며 더 깊은 원인으로 내려가는 것입니다.

예를 들어 봅시다.

1. 결제 API가 실패했다. 왜? — 결제 서비스가 데이터베이스 연결을 다 써버려서.
2. 왜 연결을 다 써버렸나? — 느린 쿼리가 연결을 오래 붙잡고 놓지 않아서.
3. 왜 쿼리가 느렸나? — 새로 추가된 조회가 인덱스 없는 컬럼을 스캔해서.
4. 왜 인덱스 없이 배포됐나? — 코드 리뷰에서 쿼리 실행 계획을 확인하지 않아서.
5. 왜 리뷰가 그것을 놓쳤나? — 실행 계획을 검토하는 체크리스트나 자동 검사가 없어서.

다섯 번째 "왜"에 이르면, 처음의 "API가 실패했다"와는 전혀 다른 지점에 도착합니다. 진짜 고쳐야 할 것은 결제 서비스가 아니라, 위험한 쿼리를 걸러내지 못한 리뷰 프로세스입니다. 이것이 5 Whys의 힘입니다. 증상을 땜질하는 대신, 그 증상을 낳은 조건까지 내려가게 합니다.

다만 5 Whys에는 분명한 한계가 있으니 맹신하지 마세요.

• 원인은 대개 하나가 아니다. 현실의 장애는 여러 원인이 겹쳐 일어납니다. "왜"를 한 줄기로만 따라 내려가면 나머지 기여 요인들을 놓칩니다. 실제로는 하나의 "왜"에 여러 갈래의 답이 있을 수 있고, 그래서 5 Whys보다 원인을 나무처럼 펼치는 방식이 더 정확할 때가 많습니다.
• "5"는 마법의 숫자가 아니다. 세 번 만에 도달할 수도, 일곱 번이 필요할 수도 있습니다. 횟수에 집착하지 마세요.
• 답이 사람에서 멈추면 잘못 파고든 것이다. "왜? 그가 실수해서"에서 멈추면 비난으로 미끄러집니다. 한 걸음 더 나아가 "왜 그 실수가 가능했나"를 물어야 시스템에 닿습니다.

5 Whys는 사고를 구조화하는 좋은 출발점이지만, 유일한 도구는 아닙니다. 복잡한 장애에는 여러 원인의 상호작용을 함께 보는 넓은 시야가 필요합니다.

고객 커뮤니케이션 vs 내부 커뮤니케이션

장애 중 소통에서 흔한 실수는, 서로 다른 청중에게 같은 말을 하는 것입니다. 고객을 향한 소통과 내부를 향한 소통은 목적도, 원하는 정보도, 어조도 다릅니다.

고객이 원하는 것은 세 가지입니다. 영향(무엇이 안 되는가), 예상 복구 시점(ETA), 그리고 **인정과 사과(우리가 알고 있고 대응 중이라는 확인)**입니다. 고객은 여러분의 내부 아키텍처나 어느 마이크로서비스의 연결 풀이 고갈됐는지에 관심이 없습니다. 오히려 그런 내부 디테일은 혼란과 불필요한 우려만 낳습니다. 고객 공지는 명확하고, 담백하고, 공감적이어야 합니다.

내부는 정반대입니다. 대응팀과 경영진은 기술적 진실을 원합니다. 정확한 오류율, 의심되는 원인, 시도한 것과 실패한 것, 롤백에 걸리는 시간. 여기서는 불확실성마저 솔직하게 공유해야 합니다. "원인일 가능성이 높지만 아직 확증은 없습니다" 같은 뉘앙스가 내부에서는 유용한 정보입니다. 반대로 이런 날것의 디테일을 고객에게 던지면 신뢰가 아니라 불안을 삽니다.

두 소통을 나란히 비교하면 이렇습니다.

핵심은 번역입니다. 커뮤니케이션 리드는 내부 채널에서 오가는 날것의 기술적 진실을, 고객이 필요로 하는 영향과 ETA와 사과로 번역해 내보냅니다. 같은 사건이지만, 청중에 따라 완전히 다른 문장이 되어야 합니다.

침착함 — 어조가 방의 공기를 정한다

마지막으로, 기법 이전의 태도에 대해 이야기하겠습니다. 장애 대응에서 IC의 침착함은 전염됩니다. 그리고 그 반대, 즉 당황도 똑같이 전염됩니다.

IC가 다급하게 타이핑하고, 목소리가 높아지고, "큰일 났다"는 기운을 뿜으면, 대응팀 전체가 그 긴장을 흡수합니다. 긴장한 사람은 성급한 결정을 내리고, 확인 없이 명령을 실행하고, 실수를 저지릅니다. 반대로 IC가 차분한 목소리로 "좋습니다, 하나씩 봅시다. 먼저 영향 범위를 확정하죠"라고 말하면, 방 전체의 심박수가 내려갑니다. 사람들은 다시 생각할 여유를 찾고, 그 여유에서 더 나은 판단이 나옵니다.

어조는 말투만의 문제가 아니라 대응의 질을 좌우하는 실질적 변수입니다. 위기 대응 현장에서 오래 통용되는 격언이 이를 잘 담고 있습니다.

느린 것이 부드럽고, 부드러운 것이 빠르다. (Slow is smooth, smooth is fast.)

역설처럼 들리지만 진실입니다. 서두르면 실수가 나고, 실수는 되돌리는 데 더 많은 시간을 씁니다. 차라리 한 박자 늦춰 정확하게 움직이면, 그 부드러움이 결과적으로 가장 빠른 길이 됩니다. 급할수록 한 호흡 고르고, 다음 행동을 소리 내어 말하고("지금 v2.7.2로 롤백을 시작합니다"), 되돌릴 수 없는 조치는 한 번 더 확인하는 것 — 이것이 IC가 방에 심어야 할 리듬입니다.

침착함은 감정을 억누르는 것이 아니라, 팀에게 사고할 공간을 주는 리더십의 도구입니다. 여러분이 차분하면, 팀도 차분해집니다. 그리고 차분한 팀이 장애를 더 빨리, 더 안전하게 끝냅니다.

마치며

장애가 터졌을 때 우리는 본능적으로 코드로 달려갑니다. 하지만 이 글에서 본 것처럼, 기술적 복구는 일의 절반일 뿐입니다. 나머지 절반은 대화입니다. 손을 비운 인시던트 커맨더가 역할을 나누고, 소식이 없어도 규칙적으로 두드리는 상태 업데이트가 불안을 잠재우고, 세 가지 질문이 모든 업데이트를 명료하게 하고, 비난 없는 포스트모템이 정직한 교훈을 남기고, 고객과 내부를 향한 서로 다른 번역이 각 청중을 안심시킵니다. 그리고 이 모든 것 밑에 IC의 침착함이 깔려 있습니다.

좋은 인시던트 커뮤니케이션은 장애를 막지는 못합니다. 장애는 언젠가 반드시 일어납니다. 하지만 그것이 20분짜리 기술적 문제로 끝날지, 아니면 하루 종일 이어지는 신뢰의 위기로 번질지는 대화가 결정합니다. 복구는 절반의 일입니다. 나머지 절반을 잘 해내는 팀이, 장애 뒤에 오히려 더 강해집니다.

참고 자료

• Google SRE Book — Managing Incidents: https://sre.google/sre-book/managing-incidents/
• Google SRE Book — Postmortem Culture: Learning from Failure: https://sre.google/sre-book/postmortem-culture/
• PagerDuty Incident Response Documentation: https://response.pagerduty.com/
• Atlassian Incident Management Handbook: https://www.atlassian.com/incident-management
• Five whys (개념 정리): https://en.wikipedia.org/wiki/Five_whys