장애 터졌을 때, 첫 수가 전부다 — 우아한형제들의 First Action 전략

화재 현장에서 원인 조사부터 하는 사람은 없다

 

건물에 불이 났다. 이때 가장 먼저 해야 할 일은 무엇인가? 화재 원인을 조사하는 것이 아니다. 스프링클러를 켜고, 사람을 대피시키고, 119에 신고하는 것이다. 원인은 불을 끈 다음에 조사해도 늦지 않는다. 서비스 장애도 마찬가지다. 장애가 발생했을 때 가장 중요한 것은 원인을 파악하는 것이 아니라, 피해를 최소화하는 최초의 조치를 취하는 것이다.

 

우아한형제들(배달의민족)은 약 70건의 장애 사례를 분석한 결과, 장애의 영향 범위와 복구 시간을 결정짓는 가장 큰 변수가 "최초 조치의 종류와 속도"라는 결론에 도달했다. 이를 First Action이라 부른다.

 

---

 

장애 관리 라이프사이클

 

장애는 갑자기 터지는 것처럼 보이지만, 일정한 생명주기를 갖는다. 우아한형제들이 정의한 장애 관리 라이프사이클은 다음과 같다.

 

1. 감지(Detection) — 모니터링 시스템이 이상 징후를 포착한다. 알림이 울리거나, 에러율 그래프가 치솟는다.
2. 인지(Acknowledgment) — 담당자가 "지금 장애 상황이다"라고 인식하고, 대응 채널에 모인다.
3. 초동 조치(First Action) — 장애 인지 후 최초로 취하는 구체적 행동. 이 단계가 핵심이다.
4. 원인 분석(Root Cause Analysis) — 초동 조치로 출혈을 멈춘 뒤, 근본 원인을 파고든다.
5. 복구(Recovery) — 서비스를 정상 상태로 되돌린다.
6. 후속(Post-mortem) — 장애의 타임라인, 원인, 재발 방지책을 문서화한다.

 

여기서 주목할 것은 3번과 4번의 순서다. 초동 조치가 원인 분석보다 먼저 온다. 이것이 우아한형제들이 70건의 장애에서 얻은 가장 중요한 교훈이다.

 

용어: Post-mortem(포스트모템): 라틴어로 "사후"라는 뜻이다. IT에서는 장애가 종료된 후 원인, 타임라인, 재발 방지책을 기록하는 회고 문서를 말한다.

 

---

 

First Action이란 무엇인가

 

First Action은 장애를 인지한 후 가장 먼저 실행하는 구체적 조치다. 원인을 완벽히 파악하기 전에, 사용자에게 가는 피해를 줄이기 위해 취하는 행동이다. 비유하면 수도관이 터졌을 때 원인(동파인지, 노후인지)을 분석하기 전에 일단 밸브부터 잠그는 것과 같다.

 

First Action의 대표적인 유형은 다음과 같다.

 

First Action 유형	설명	적합한 상황
롤백	최근 배포를 이전 버전으로 되돌린다	배포 직후 장애 발생
트래픽 차단	특정 API나 서비스로의 트래픽을 끊는다	특정 엔드포인트에서 장애가 격리됨
기능 토글 OFF	Feature Flag를 꺼서 문제 기능을 비활성화한다	새로 추가한 기능이 원인으로 의심됨
수동 우회	장애 구간을 건너뛰는 임시 경로를 만든다	외부 의존성 장애
스케일 아웃	서버 인스턴스를 늘려 부하를 분산한다	트래픽 급증으로 인한 과부하

 

---

 

좋은 First Action의 3가지 조건

 

모든 First Action이 다 좋은 것은 아니다. 우아한형제들의 분석에 따르면, 빠르고, 가역적이고, 범위가 좁은 조치일수록 효과적이다.

 

1. 빠르다

 

실행까지 걸리는 시간이 짧아야 한다. 롤백 명령어 한 줄이면 되는 것과, 핫픽스 코드를 작성하고 코드 리뷰를 받고 배포 파이프라인을 태우는 것은 차원이 다르다. 장애 상황에서 매 분이 사용자 이탈과 매출 손실로 직결된다. 배달의민족처럼 분당 수만 건의 주문이 발생하는 서비스에서 10분의 차이는 수십억 원의 피해 차이를 만든다.

 

2. 가역적이다

 

조치 자체가 되돌릴 수 있어야 한다. "일단 해보고, 효과 없으면 원래대로 돌리자"가 가능해야 한다는 뜻이다. Feature Flag를 끄는 것은 다시 켤 수 있으니 가역적이다. 반면 데이터베이스 스키마를 변경하는 것은 되돌리기 어렵다. 가역적이지 않은 조치는 First Action으로 부적합하다. 장애 위에 장애를 쌓는 결과를 초래할 수 있기 때문이다.

 

3. 범위가 좁다

 

영향 범위를 최소화하는 조치여야 한다. 문제가 결제 모듈에 있는데 전체 서비스를 내리는 것은 과잉 대응이다. 비유하면 손가락을 다쳤는데 팔 전체에 깁스를 하는 것과 같다. 문제 지점만 정확히 격리하는 것이 좋은 First Action이다.

 

---

 

나쁜 First Action: 흔한 실수들

 

원인 분석부터 시작한다

 

가장 흔하고 가장 치명적인 실수다. "왜 이런 일이 생겼지?"부터 파고드는 것이다. 로그를 뒤지고, 코드를 읽고, 쿼리를 날리며 30분이 흘러간다. 그 사이 사용자는 주문을 못 하고, 매출은 빠져나간다. 원인 분석은 출혈을 멈춘 이후에 해도 된다.

 

핫픽스를 즉석에서 작성한다

 

"코드 한 줄만 바꾸면 될 것 같은데?"라는 판단으로 장애 상황에서 코드를 수정하고 긴급 배포를 시도한다. 문제는 장애 상황의 압박감 속에서 작성한 코드는 새로운 버그를 만들 확률이 높다는 것이다. 핫픽스가 오히려 장애를 확대시킨 사례는 업계에서 셀 수 없이 많다.

 

여러 조치를 동시에 실행한다

 

"다 해보자"는 식으로 롤백, 스케일 아웃, 설정 변경을 동시에 실행하면, 어떤 조치가 효과를 낸 건지 알 수 없다. 이후 Post-mortem에서도 정확한 원인-해결 매핑이 불가능해진다. 한 번에 하나씩, 효과를 확인하며 진행하는 것이 원칙이다.

 

---

 

실전 체크리스트: 장애 전에 준비할 것

 

First Action의 핵심은 장애가 터지기 전에 준비되어 있어야 한다는 것이다. 불이 나면 소화기 위치를 찾을 시간이 없다. 미리 알고 있어야 한다.

 

incident-first-action-checklist.yaml

사전_준비:
  - 롤백_절차: "1분 이내에 이전 버전으로 되돌릴 수 있는가?"
  - 기능_토글: "Feature Flag가 주요 기능에 적용되어 있는가?"
  - 트래픽_제어: "특정 API의 트래픽을 즉시 차단할 수 있는가?"
  - 스케일_아웃: "인스턴스 추가가 자동화되어 있는가?"
  - 런북: "각 장애 유형별 First Action이 문서화되어 있는가?"

장애_발생_시:
  - step_1: "장애 인지 → 대응 채널 집결 (Slack, War Room)"
  - step_2: "증상 확인 → 가장 가능성 높은 원인 카테고리 판단"
  - step_3: "런북에서 해당 카테고리의 First Action 실행"
  - step_4: "효과 확인 (메트릭 변화 관찰, 최소 2~3분)"
  - step_5: "효과 없으면 다음 First Action으로 전환"
  - step_6: "출혈 멈춘 후 → 원인 분석 시작"

 

특히 런북(Runbook)의 존재가 중요하다. 런북이란 특정 장애 상황에서 어떤 순서로 무엇을 실행해야 하는지 적어둔 매뉴얼이다. 장애 상황에서 사람의 판단력은 평소의 50~60% 수준으로 떨어진다는 연구 결과가 있다. 미리 적어둔 런북이 있으면 판단력 저하의 영향을 최소화할 수 있다.

 

---

 

Post-mortem 문화와의 연결

 

First Action이 장애 중의 전략이라면, Post-mortem은 장애 후의 전략이다. 이 둘은 순환 관계에 있다. Post-mortem에서 "이번 장애의 First Action은 적절했는가?"를 반드시 점검하고, 부적절했다면 런북을 업데이트한다. 이 과정이 반복되면서 팀의 장애 대응 역량이 축적된다.

 

우아한형제들이 70건의 장애에서 패턴을 추출할 수 있었던 것도 Post-mortem 문화가 정착되어 있었기 때문이다. Post-mortem 없이는 First Action의 품질을 개선할 수 없고, 좋은 First Action 없이는 Post-mortem에 기록할 만한 성공적 대응 사례가 쌓이지 않는다.

 

중요한 것은 Post-mortem이 비난의 도구가 아니라 학습의 도구여야 한다는 점이다. "누가 잘못했나"가 아니라 "시스템에 어떤 취약점이 있었나"를 찾는 것이 목적이다. 이것을 Blameless Post-mortem이라 부른다.

 

---

 

마무리

 

장애는 막을 수 없다. 충분히 복잡한 시스템에서는 언제든 장애가 발생한다. 중요한 것은 장애가 발생했을 때 얼마나 빨리, 얼마나 적은 피해로 복구하느냐다. 그리고 그 복구 속도를 결정하는 가장 큰 변수가 First Action이다.

 

화재 대응의 원칙을 떠올려보면 된다. 불 끄는 게 먼저다. 원인 조사는 그 다음이다. 롤백할 수 있으면 롤백하고, Feature Flag를 끌 수 있으면 끄고, 트래픽을 차단할 수 있으면 차단한다. 빠르고, 가역적이고, 범위가 좁은 조치. 이것이 장애 대응의 첫 번째 원칙이다.