이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 장애 초기에는 왜 역할과 업데이트 주기를 먼저 정해야 하는가?
- 내부 커뮤니케이션에는 어떤 사실을 남겨야 하는가?
- 백엔드 개발자는 초기 대응에서 어떤 정보를 제공해야 하는가?
개요
초기 대응은 장애가 확인된 직후 혼선을 줄이는 절차다.
이 단계에서 모든 원인을 알 필요는 없다.
대신 누가 의사결정을 하는지, 누가 기술 조사를 맡는지, 누가 사용자 공지와 내부 공유를 맡는지 정해야 한다.
역할이 없으면 같은 로그를 여러 사람이 보고, 같은 질문이 반복되고, 실제 완화 조치가 늦어진다.
초기 커뮤니케이션의 목표는 빠른 결론이 아니라 같은 사실 위에서 움직이게 만드는 것이다.
역할 분리
장애 대응에서는 최소한 다음 역할이 필요하다.
- Incident Commander: 우선순위, 역할, 다음 업데이트 시각을 정한다.
- Technical Lead: 원인 후보를 줄이고 완화 조치를 제안한다.
- Communications Lead: 내부 공유와 고객 공지 초안을 관리한다.
- Scribe: 타임라인, 결정, 실행 결과를 기록한다.
- Domain Owner: 주문, 결제, 인증처럼 영향 기능의 도메인 판단을 제공한다.
작은 팀에서는 한 사람이 여러 역할을 맡을 수 있다.
그래도 역할 이름을 적어야 누가 무엇을 결정하는지 분명해진다.
첫 메시지
장애 채널의 첫 메시지는 짧고 구체적이어야 한다.
[Incident Open]
- 시각: 2026-07-01 10:18 KST
- 임시 Severity: SEV-2
- 영향: 모바일 주문 생성 실패율 증가, 웹 주문은 아직 정상
- 현재 조치: 주문 API 오류율 확인, 최근 배포와 DB connection 상태 확인 중
- 담당: IC 김민수, TL 이지현, 기록 박서연
- 다음 업데이트: 10:30 KST첫 메시지에는 추측을 길게 쓰지 않는다.
확인된 사실, 현재 판단, 다음 업데이트 시간만 명확히 한다.
업데이트 주기
장애 중 침묵은 혼선을 만든다.
원인이 아직 없어도 정해진 시간에 업데이트해야 한다.
업데이트에는 다음이 들어간다.
- 새로 확인한 사실
- 바뀐 영향 범위
- 실행한 조치와 결과
- 다음으로 확인할 항목
- 다음 업데이트 시각
문제가 해결되지 않았다는 사실도 중요한 정보다.
“조사 중”만 반복하지 말고 무엇을 확인했고 무엇이 배제되었는지 적어야 한다.
백엔드 개발자가 제공할 정보
Spring 백엔드 개발자는 초기 대응에서 다음 정보를 빠르게 제공해야 한다.
- 영향 endpoint와 controller, service 이름
- 최근 배포 버전과 변경된 기능
- feature flag나 설정으로 끌 수 있는 기능
- 관련 DB table과 transaction 범위
- 외부 API client와 timeout, retry 설정
- batch, 스케줄 작업, consumer 실행 여부
- 요청 ID, 사용자 ID, 주문 ID 같은 샘플 식별자
이 정보는 인프라 담당자가 네트워크나 DB 지표를 볼 때 기준점이 된다.
사용자 공지와 내부 공유
내부 공유와 외부 공지는 목적이 다르다.
내부 공유는 판단과 실행을 위한 정보가 필요하다.
외부 공지는 사용자 영향, 현재 상태, 임시 우회, 다음 안내 시각이 필요하다.
외부 공지에는 확정되지 않은 원인이나 내부 시스템명을 과하게 쓰지 않는다.
예시는 다음과 같다.
현재 일부 모바일 주문 생성이 실패하는 문제가 확인되어 조치 중입니다.
이미 결제가 완료된 주문의 상태를 확인하고 있으며, 다음 업데이트는 10:45에 안내하겠습니다.불확실성을 숨기지 않되 확인되지 않은 내용을 단정하지 않는다.
운영 체크리스트
- 장애 채널을 하나로 정한다.
- Incident Commander와 기록 담당자를 지정한다.
- 임시 Severity와 사용자 영향을 첫 메시지에 남긴다.
- 다음 업데이트 시간을 정하고 지킨다.
- 실행한 조치와 결과를 같은 스레드에 기록한다.
- 외부 공지에는 사용자 영향과 다음 안내 시각을 포함한다.
- 복구 선언 전에 어떤 신호가 회복되어야 하는지 합의한다.
장애 신호
- 여러 채널에서 서로 다른 결론이 나온다.
- 장애 중 누가 최종 결정을 하는지 모른다.
- 같은 질문이 반복되어 대응자가 로그를 볼 시간이 없다.
- 고객 공지와 내부 타임라인의 영향 범위가 다르다.
- 복구 선언 후에도 고객 문의가 계속 증가한다.
- 실행한 완화 조치의 결과가 기록되지 않는다.
이 신호는 기술 문제가 아니라 대응 체계 문제를 함께 보여 준다.
안전한 완화 조치
- 커뮤니케이션이 흔들리면 채널과 역할을 다시 고정한다.
- 잘못된 공지가 나갔다면 정정 시각과 수정 내용을 남긴다.
- 결정권자가 없으면 임시 IC를 지정하고 추후 교체한다.
- 조사자가 너무 많으면 담당 영역을 endpoint, DB, 외부 의존성처럼 나눈다.
- 복구 판단 전에는 핵심 신호와 사용자 신고 추이를 같이 확인한다.
초기 대응의 품질은 기술 해결 속도에도 직접 영향을 준다.
하지 말아야 할 대응
- 원인 추측을 첫 공지에 단정적으로 쓰지 않는다.
- 담당자 없이 모두가 동시에 같은 로그를 보지 않는다.
- 다음 업데이트 시간을 정하지 않고 “확인 중”으로 남기지 않는다.
- 사용자가 겪는 문제를 내부 시스템 용어로만 설명하지 않는다.
- 복구 신호가 확인되기 전에 해결 완료라고 공지하지 않는다.
인프라 담당자와 공유할 자료
- 장애 채널 링크와 현재 역할
- 임시 Severity, 영향 기능, 사용자 범위
- 최근 배포 버전과 변경 요약
- 확인해야 할 endpoint, DB, queue, 외부 의존성
- 이미 실행한 완화 조치와 결과
- 다음 업데이트 시각과 복구 판단 기준
공유 자료는 대응자를 늘리는 것이 아니라 혼선을 줄이는 방향이어야 한다.
확인 질문
확인 질문
- 장애 초기 역할을 먼저 정해야 하는 이유는 무엇인가?
- 의사결정, 기술 조사, 공지, 기록이 섞이면 조치가 늦어지고 정보가 충돌하기 때문이다.
- 좋은 초기 업데이트에는 무엇이 들어가는가?
- 확인된 사실, 영향 범위, 실행한 조치, 결과, 다음 확인 항목, 다음 업데이트 시각이다.
- 백엔드 개발자가 초기 대응에서 제공해야 할 핵심 정보는 무엇인가?
- 영향 endpoint, 최근 배포, 데이터 범위, 외부 의존성, 샘플 식별자, 끌 수 있는 기능이다.
리뷰 체크포인트
- 장애 채널과 역할 지정 방식이 문서화되어 있는가?
- 첫 메시지 템플릿이 사용자 영향 중심으로 되어 있는가?
- 업데이트 주기와 다음 업데이트 시각을 남기는가?
- 외부 공지와 내부 공유의 목적이 분리되어 있는가?
- 복구 선언 기준이 사전에 합의되어 있는가?