백엔드 커리큘럼 심화: 인시던트 커맨드와 Severity 운영 플레이북

장애 대응이 어려운 이유는 기술 문제만 풀면 끝나지 않기 때문입니다. DB 락 경합, 배포 회귀, 외부 API 장애, Kafka lag, 캐시 장애처럼 원인은 다양하지만, 실제 현장에서는 더 기본적인 문제가 먼저 터집니다. 누가 지휘하는지 불분명하고, 누가 고객 공지를 쓰는지 모르며, 롤백할지 완화할지 회의가 길어지고, 같은 사람이 로그도 보고 커뮤니케이션도 하고 배포도 만지다가 판단이 흐려집니다.

그래서 일정 규모 이상 백엔드 팀에는 Incident Command가 필요합니다. 이는 거창한 조직 체계가 아니라, 장애 순간 역할과 의사결정 순서를 미리 고정하는 운영 방식입니다. 알람 전략이 “언제 깨울 것인가"를 다루고, SLO/Error Budget이 “얼마나 심각한가"를 숫자로 표현한다면, 인시던트 커맨드는 “깨어난 뒤 누가 어떤 순서로 복구할 것인가"를 닫아 주는 실행 체계입니다.

이 글에서 얻는 것

• 장애 상황에서 Incident Commander, technical lead, communication owner를 어떻게 나눌지 기준을 잡을 수 있습니다.
• Severity를 감정이 아니라 사용자 영향, 데이터 위험, 복구 시간, error budget burn으로 분류할 수 있습니다.
• 완화, 롤백, 원인 분석, 고객 커뮤니케이션의 우선순위를 숫자와 조건으로 운영할 수 있습니다.
• 사후 회고가 비난 문서가 아니라 다음 장애의 MTTR을 줄이는 학습 루프가 되도록 체크리스트를 만들 수 있습니다.

핵심 개념/이슈

1) 인시던트는 “원인 분석 회의"가 아니라 “피해 축소 작전"이다

장애 초반에 가장 흔한 실수는 원인을 완벽히 찾으려는 것입니다. 물론 원인은 중요합니다. 하지만 사용자가 이미 결제 실패, 로그인 실패, 주문 지연을 겪고 있다면 첫 목표는 원인 규명이 아니라 피해 축소입니다.

의사결정 우선순위는 아래처럼 잡는 편이 안전합니다.

1. 고객 영향 중단 또는 축소
2. 데이터 손상, 중복 결제, 권한 오염 같은 비가역 피해 차단
3. 복구 경로 확보와 상태 안정화
4. 원인 후보 축소
5. 영구 수정과 회고

즉, 장애 중에는 “왜 깨졌나"보다 “지금 더 나빠지는가"가 먼저입니다. 배포 런북에서 말하는 중단/완화/롤백 기준도 같은 이유로 필요합니다. 롤백으로 10분 안에 사용자 영향이 줄어든다면, 근본 원인은 롤백 뒤에 찾아도 됩니다. 반대로 데이터 정합성이 깨지는 상황이면 롤백보다 쓰기 차단이 먼저일 수 있습니다.

2) Severity는 큰 소리 낸 사람이 정하는 것이 아니다

Severity는 감정이나 직급이 아니라 영향 범위로 정해야 합니다. 초반에 과소평가하면 대응이 늦고, 과대평가가 반복되면 조직이 알람을 믿지 않습니다. 최소 분류는 아래 4단계면 충분합니다.

SLO가 있는 서비스라면 숫자 기준도 붙입니다.

• 5xx 비율이 5분 이상 3% 초과: 최소 SEV2 후보
• 핵심 API p99가 SLO 목표의 3배를 10분 이상 초과: SEV2 후보
• 결제/권한/개인정보 정합성 의심: 영향 범위가 작아도 SEV1 후보
• 1시간 burn rate 14.4x 초과: 즉시 page 기준
• 단일 테넌트 영향이라도 매출 상위 10% 고객이면 한 단계 상향

중요한 것은 최초 Severity가 틀릴 수 있다는 점입니다. 그래서 15분마다 “현재 등급 유지/상향/하향"을 명시적으로 확인해야 합니다.

3) Incident Commander는 제일 잘 고치는 사람이 아니다

초기 팀에서는 가장 실력 좋은 개발자가 모든 것을 맡습니다. 하지만 규모가 커질수록 이 방식은 위험합니다. 기술적으로 가장 깊이 보는 사람은 로그, 메트릭, 코드, 롤백 경로에 집중해야 합니다. 동시에 커뮤니케이션, 우선순위 조정, 의사결정 기록까지 맡으면 병목이 됩니다.

역할은 최소 3개로 나눕니다.

팀이 작으면 한 사람이 두 역할을 겸할 수는 있습니다. 그래도 “지금 나는 어떤 역할로 말하는가"를 분리해야 합니다. Incident Commander의 핵심 질문은 매번 같습니다.

• 지금 사용자가 더 나빠지고 있는가?
• 완화 수단 중 가장 빠르고 되돌릴 수 있는 것은 무엇인가?
• 다음 15분 안에 누가 무엇을 끝내야 하는가?
• 아직 확인되지 않은 가정은 무엇인가?
• 외부 공유가 필요한가?

4) 타임라인은 사후 문서가 아니라 실시간 도구다

장애 중에는 기억이 왜곡됩니다. 10분 전에 누가 무엇을 실행했는지, 어떤 알람이 먼저 울렸는지, 롤백 전후 지표가 어떻게 바뀌었는지 나중에 맞추려 하면 시간이 많이 듭니다. 그래서 타임라인은 실시간으로 남겨야 합니다.

최소 형식은 단순해도 됩니다.

10:06 alert: checkout 5xx 4.2%, p99 3.1s
10:08 SEV2 declared, IC=Jin, Tech=Min, Comms=Hana
10:11 candidate: payment-client timeout regression after deploy 2026.05.24.3
10:14 action: rollback checkout-api to 2026.05.24.2
10:19 signal: 5xx down to 0.8%, p99 900ms
10:25 decision: keep incident open 30m, inspect duplicate payment risk

여기서 중요한 것은 문장이 예쁜지가 아니라 재구성 가능성입니다. 구조화 로깅과 관측성 베이스라인이 서비스 내부의 증거라면, 인시던트 타임라인은 사람과 시스템 액션의 증거입니다.

5) 완화와 원인 수정은 분리한다

장애 중에 바로 완벽한 패치를 만들고 싶은 유혹이 큽니다. 하지만 대부분의 SEV1/SEV2에서는 완화가 먼저입니다.

완화 수단의 우선순위는 아래처럼 둡니다.

1. 잘못된 배포 롤백
2. feature flag 또는 kill switch 비활성화
3. 트래픽 제한, brownout, degraded mode
4. 읽기 전용 모드 또는 특정 쓰기 차단
5. hotfix 배포
6. 데이터 복구/보정 작업

hotfix는 다섯 번째입니다. 이유는 간단합니다. 장애 중에는 검증 시간이 짧고, 새 코드는 새로운 회귀를 만들 수 있습니다. 롤백이나 flag off로 사용자 영향이 줄어든다면 그것이 먼저입니다. 단, 데이터 손상이나 보안 사고처럼 롤백만으로 피해가 멈추지 않는 경우에는 쓰기 차단과 권한 회수가 더 우선입니다.

실무 적용

1) SEV 선언 템플릿을 고정한다

장애 채널에서 처음 선언할 때는 아래 6개를 한 번에 적습니다.

SEV: SEV2
Impact: checkout API 5xx 4%, p99 3s, 한국 리전 일부 사용자
Started: 2026-05-24 10:06 KST
IC: @jin
Tech Lead: @min
Next update: 10:20 KST
Current plan: 최근 배포 rollback 가능성 확인, payment timeout 지표 대조

이 형식을 쓰면 이해관계자는 “지금 누구에게 물어봐야 하는지"와 “다음 업데이트가 언제인지"를 압니다. 장애 대응에서 침묵은 불안을 키웁니다. 완벽한 답이 없어도, 다음 업데이트 시각은 지켜야 합니다.

2) 15분 단위 운영 루프를 만든다

SEV1/SEV2에서는 15분 루프가 적당합니다. 너무 짧으면 분석이 안 되고, 너무 길면 상태가 흩어집니다.

1. 현재 사용자 영향 수치 확인
2. 진행 중 액션 완료/미완료 확인
3. Severity 유지/상향/하향 결정
4. 다음 15분 목표 1~3개 지정
5. 내부/외부 업데이트 필요 여부 결정

이 루프의 핵심은 병렬 작업을 줄이는 것입니다. 장애 중에는 많은 사람이 동시에 여러 가정을 파고들면서 채널을 어지럽히기 쉽습니다. IC는 최대 2~3개의 작업 흐름만 열어두고, 나머지는 보류해야 합니다.

3) 데이터 위험 체크를 별도 단계로 둔다

사용자 요청 실패가 줄어들어도 인시던트가 끝난 것은 아닙니다. 결제, 포인트, 권한, 재고, 메시지 발송처럼 부작용이 남는 시스템은 데이터 위험을 따로 봐야 합니다.

점검 기준은 아래가 출발점입니다.

• 중복 결제/중복 지급 가능성: 0건으로 확인 전까지 종료 금지
• 실패한 주문/예약/정산 이벤트 backlog: 전체 0.1% 초과면 보정 계획 필요
• DLQ 유입이 평소 대비 3배 이상이면 replay 승인 전 원인 확인
• 외부 전송 중복 가능성이 있으면 message id 기준 dedupe 확인
• 권한 변경 장애라면 권한 회수와 감사 로그 검증을 먼저 수행

이 부분은 Reconciliation Ledger Pipeline과 Poison Message Quarantine을 같이 봐야 합니다. 서비스가 다시 200을 반환해도, 내부 상태가 틀리면 장애는 아직 끝나지 않았습니다.

4) 종료 기준을 숫자로 말한다

“괜찮아진 것 같다"로 인시던트를 닫으면 재발이 잦습니다. 종료 기준은 선언 기준만큼 구체적이어야 합니다.

권장 종료 기준:

• 핵심 SLI가 30분 이상 정상 범위 유지
• error budget burn rate가 page 기준 아래로 하락
• backlog 또는 DLQ가 정해진 복구 계획 안에 있음
• 데이터 손상/중복 처리 여부를 점검했거나 별도 보정 티켓 생성
• 고객/CS/내부 이해관계자에게 현재 상태와 후속 조치 공유
• 임시 완화가 남아 있으면 owner와 만료 시각 지정

완화 상태로 닫을 수도 있습니다. 다만 “완전히 고침"과 “사용자 영향은 줄였지만 임시 조치가 남음"은 다르게 기록해야 합니다.

트레이드오프/주의점

첫째, Severity를 너무 쉽게 올리면 피로가 생깁니다. 하지만 초반에는 낮게 잡는 것보다 높게 잡고 빠르게 하향하는 편이 안전합니다. 특히 결제, 권한, 개인정보, 데이터 손상 가능성은 영향 범위가 작아 보여도 보수적으로 봐야 합니다.

둘째, Incident Commander가 기술 판단을 완전히 몰라도 된다는 뜻은 아닙니다. 최소한 SLO, 배포 흐름, 주요 의존성, 데이터 위험을 이해해야 좋은 질문을 할 수 있습니다. 다만 직접 모든 명령을 실행하는 역할은 아닙니다.

셋째, 커뮤니케이션을 너무 늦추면 기술 복구가 빨라도 신뢰를 잃습니다. 고객 영향이 명확하면 30분 안에 첫 외부 문안을 준비하는 기준이 좋습니다. 원인이 확정되지 않았으면 원인을 추측하지 말고, 영향과 현재 완화 액션을 말하면 됩니다.

넷째, 회고가 사람 탓으로 흐르면 다음 장애에서 더 적은 정보가 공유됩니다. 회고의 목적은 “누가 실수했나"가 아니라 “어떤 시스템 기본값과 절차가 같은 실수를 가능하게 했나"입니다.

체크리스트 또는 연습

실무 체크리스트

• SEV1~SEV4 기준이 사용자 영향, 데이터 위험, SLO 숫자로 정의돼 있다.
• Incident Commander, Technical Lead, Communication Owner 역할이 문서화돼 있다.
• SEV1/SEV2 선언 템플릿과 15분 업데이트 규칙이 있다.
• 롤백, kill switch, brownout, read-only mode 중 최소 2개 완화 수단이 준비돼 있다.
• 인시던트 종료 기준에 SLI 안정화, backlog, 데이터 위험 점검이 포함돼 있다.
• 회고 액션은 owner와 due date를 갖고, 30일 안에 완료율을 추적한다.

연습 과제

1. 최근 장애 또는 가상의 checkout 장애를 하나 골라 SEV 등급, IC, Tech Lead, Comms Owner를 지정해 보세요.
2. 30분짜리 타임라인을 작성하고, 15분마다 어떤 의사결정을 했어야 하는지 표시해 보세요.
3. 롤백이 불가능한 장애를 가정하고, feature flag, 트래픽 제한, read-only mode 중 어떤 완화를 먼저 쓸지 기준을 정리해 보세요.
4. 회고 액션을 5개 작성하되, “주의한다” 같은 문장을 금지하고 코드/알람/런북/테스트 변경으로만 표현해 보세요.

관련 글

• 알람 전략: 에러율/레이턴시/자원지표 설계
• SLO/SLI/Error Budget
• 배포 런북: 안전한 배포와 롤백
• 관측성 베이스라인
• Reconciliation Ledger Pipeline