자동 복구가 아무리 정교해도 모든 인시던트를 처리하지는 못한다. 어떤 장애는 코드가 결정할 수 없는 판단을 요구하고("이 결제 불일치를 롤백할 것인가 수동 보정할 것인가"), 어떤 장애는 여러 팀이 동시에 모여야 풀리며, 어떤 장애는 고객·법무·경영진에게 보고가 필요하다. 이 지점에서 자동화는 끝나고 사람 조직의 협응(coordination)이 시작된다. 그리고 여기서 가장 비싼 자원은 컴퓨팅이 아니라 사람의 주의(attention)와 협응 대역폭이다. 새벽 3시에 페이지를 받은 엔지니어가 무슨 일인지 파악하고, 누구를 더 불러야 하는지 판단하고, 흩어진 도구(콘솔·로그·티켓·전화)를 오가며 컨텍스트를 재구성하는 데 드는 시간 — 이것이 자동 복구가 닿지 못한 영역의 MTTR을 지배한다.
오늘은 ChatOps와 Incident Manager를 "Slack 알림 붙이는 법"으로 보지 않고, 그 밑에 깔린 조직 사회학과 인시던트 커맨드 이론을 판다. ChatOps가 어떤 운영 철학에서 나왔는지(GitHub의 Hubot, 2013), 왜 "채팅 채널을 단일 진실의 공간으로 만드는 것"이 협응 비용을 줄이는지, AWS Incident Manager의 Response Plan·Escalation·Timeline이 어떤 비상 대응 표준(ICS)을 빌렸는지, 비난 없는 포스트모템(blameless postmortem)이 왜 안전 문화의 핵심인지를 본다