장애 대응의 성패를 가르는 First Action: 우아한형제들의 장애 관리 라이프사이클

6 days ago 5

First Action에 따라 달라지는 장애 영향

우아한형제들의 2025년 장애를 돌아보면 인지는 비교적 빠른 편이었습니다.
그러나, 장애로 고객 경험의 악영향이 오래 이어진 사례들이 적지 않았습니다.

장애 대응 과정을 하나씩 다시 들여다보면 차이는 대부분 인지 이후 가장 먼저 어떤 조치를 취했는지, 즉 First Action(초동 조치)에서 시작됐습니다. 실제 내부적으로 약 70여 건 이상의 장애 사례를 분석한 결과, 첫 조치로 롤백(Rollback)을 선택한 경우와 핫픽스(Hotfix)로 대응한 경우 사이에는 장애가 이어지는 시간과 고객 영향에서 뚜렷한 차이가 있었습니다.

평균적으로 보면 First Action이 핫픽스였던 장애는 롤백으로 시작한 경우보다 거의 두 배 가까이 더 오래 지속되는 경향을 보였습니다.

이 차이는 대응 방식의 특성에서 비롯됩니다. 롤백은 문제가 된 변경을 즉시 되돌릴 수 있지만 핫픽스는 원인을 좁히고 코드를 수정한 뒤 다시 배포하기까지의 시간이 필요합니다. 문제는 그 시간 동안 서비스 상태는 그대로라는 점입니다.
원인을 정확히 파악하는 데 시간이 걸릴수록 고객 영향은 첫 조치가 실행되기 전까지 계속 쌓입니다.
이 경험을 여러 번 겪으면서 우리는 한 가지 질문에 도달했습니다.

장애 대응에서 정말 중요한 것은
‘얼마나 빨리 인지했는가’만큼이나
‘얼마나 빨리 의미 있는 첫 조치를 실행했는가’가
아닐까?

이 글에서는 이러한 질문에 대한 답을 찾기 위해 실제 장애 대응 경험을 바탕으로 First Action의 중요성과 이를 추적하기 위한 노력을 살펴보고 이를 체계적으로 관리하기 위한 장애 관리 라이프사이클과 핵심 메트릭을 정리합니다. 아울러 장애 대응을 개인의 역량이 아닌 시스템과 프로세스로 개선해 나가는 방향을 함께 소개합니다.

1. First Action을 관리 대상으로 보기까지

First Action이 장애 영향에 중요한 역할을 한다는 사실은 여러 사례를 통해 확인할 수 있었습니다.

하지만 개별 사례를 넘어 이를 전반적인 운영 개선으로 연결하기에는 또 하나의 한계가 있었습니다.
장애마다 상황과 맥락이 달라 First Action을 단순 비교하기 어려웠고 어떤 조치가 ‘빠른 First Action’이었는지를 공통된 기준으로 설명하기도 쉽지 않았기 때문입니다.

그래서 우아한형제들은 First Action을 단순한 인상이나 경험이 아니라 관찰하고, 비교하고, 관리할 수 있는 대상으로 바라보기 시작했습니다.

이를 위해 장애를 시간의 흐름에 따라 도식화하고 탐지 이후 실제로 첫 조치가 실행되기까지의 구간을 하나의 관찰 가능한 지점으로 분리했습니다. 이 과정에서 우리는 First Action이 단순히 ‘언제 실행되었는가’뿐만 아니라 무엇을 했는가 역시 중요하다는 점에 주목하게 되었습니다.

특히 롤백이나 스케일 조정과 같이 사전에 정의된 기계적인 완화 조치, 즉 추가 판단 없이 바로 실행할 수 있는 조치가 실행될수록 고객 영향을 효과적으로 줄일 수 있음을 확인했습니다. 이러한 시도는 First Action을 개인의 대응 선택이 아니라 ‘무엇을 했는지’와 ‘언제 실행했는지’를 함께 비교할 수 있는 운영 지표로 다루기 위한 첫 번째 단계였습니다.

위 그림에서 붉은색 말풍선으로 표시된 지점은 우아한형제들이 정의한 First Action의 기준 위치를 나타냅니다. 이는 장애를 인지한 이후 롤백이나 스케일 조정과 같이 사전 정의된 기계적 완화 조치가 최초로 실행되는 시점으로 장애 원인 분석보다 고객 영향을 빠르게 줄이는 데 초점을 둔 대응 지점입니다.

2. 장애 관리 라이프사이클을 정의한 이유

여기서 말하는 장애 관리 라이프사이클은
장애를 탐지 및 인지, 대응, 복구, 그리고 재발 방지를 위한 개선까지
하나의 흐름으로 정의해 관리하는 운영 기준을 의미합니다.

First Action을 관찰하고 비교하려는 시도는 곧 하나의 한계에 부딪혔습니다. 장애마다 맥락과 상황이 달랐고 “언제 First Action이 실행되었다”고 말하더라도 그 기준이 사람과 팀마다 조금씩 달랐기 때문입니다.

어떤 경우에는 장애 대응의 출발점을 장애 영향도를 인지한 시점으로 보았고
어떤 경우에는 이를 전사적으로 전파한 시점을 기준으로 삼고 있었습니다.

이처럼 기준이 서로 다르다 보니 First Action의 빠르고 느림을 전사적으로 같은 의미로 설명하기 어려운 상황이 반복되었습니다.

우리는 여기서 하나의 결론에 이르렀습니다.

First Action을 제대로 추적하려면 개별 장애의 특성보다 먼저 모두가 동일하게 합의한 시간의 흐름과 기준이 필요하다. 즉, First Action이라는 하나의 지점을 보기 위해서도 그 앞과 뒤를 포함한 전체 장애 대응 과정을 같은 구조와 언어로 정의할 필요가 있었습니다.

이러한 문제의식에서 우아한형제들은 장애를 탐지·인지, 대응, 복구, 그리고 재발 방지를 위한 개선까지 하나의 흐름으로 정리한 장애 관리 라이프사이클을 정의하게 되었습니다.

3. 우아한형제들의 장애관리 라이프사이클

First Action을 전사적으로 같은 기준에서 바라보기 위해 우리는 먼저 장애 대응 전 과정을 모두가 같은 구조와 언어로 설명할 수 있어야 한다고 판단했습니다. 이에 따라 우아한형제들은 장애를 잠재적인 장애 상태(Potential-Incident Lifecycle) 1단계와 실제 장애 상태(Incident Lifecycle) 6단계로 구성된 총 7개의 단계이며, 아래에서 각 단계를 순서대로 설명합니다.

각 단계는 ‘지금 우리가 어디에 있는지’를 조직 전체가 같은 언어로 인식하기 위한 기준이며 단계별로 측정되는 메트릭과 함께 연결됩니다. 이러한 구조를 통해 First Action 역시 ‘언제, 어떤 단계에서 실행되었는지’를 공통된 맥락 안에서 해석할 수 있게 됩니다.

이 라이프사이클은 다음과 같이 구성됩니다.

잠재적인 장애 상태(Potential-Incident Lifecycle)(1단계)
- 이상 탐지 단계(Anomaly)
실제 장애 상태(Incident Lifecycle)(6단계)
- 장애 인지 및 전파 단계(Open)
- 장애 분석 단계(Investigating)
- 장애 원인 확인 및 조치 단계(Identified)
- 조치 후 모니터링 단계(Monitoring)
- 해소 확인 및 전파 단계(Resolved)
- 예방 및 피해 최소화를 위한 이행 추적 단계(Closure Time)

아래 그림은 실제 운영에서 사용하는 장애 관리 라이프사이클의 전체 흐름을 개념적으로 표현한 것입니다.

3.1 Potential-Incident Lifecycle

1) 이상 탐지 단계(Anomaly)

서비스 담당자가 운영하는 서비스 또는 시스템의 이상 상태를 감지하고 이를 인지하는 단계입니다. 서비스 및 시스템 알림 체계를 통해 이상 징후가 탐지되고 담당자가 이를 인지하기까지가 이 단계에 포함됩니다.
여기서 ‘인지’란 객관적인 근거가 남는 것을 의미합니다. 온콜 알림 ACK, 고객센터 대응 코멘트, 알람 코멘트 등이 이에 해당합니다. 탐지 이후 다음 단계까지가 자동화된 경우에는 알람 발생 시점을 인지 시점으로 간주할 수 있으며, 이 경우 탐지와 인지는 사실상 동일한 의미를 갖습니다.

이후 실제 고객 영향이 없다고 판단되면 내부 조치 후 프로세스를 종료할 수 있으며, 주문 과정 중 일부라도 이용이 어려운 상태로 판단될 경우 실제 장애 상태(Incident Lifecycle)로 전환합니다.

3.2 Incident Lifecycle

2) 장애 인지 및 전파 단계(Open)

장애로 인지한 서비스 담당자는 전사 전파와 함께 장애 대응 채널을 생성하고 기술 대응 조직을 중심으로 관련 조직을 초대해 동시에 대응할 수 있는 상태를 만드는 단계입니다.

3) 장애 분석 단계(Investigating)

각 서비스 담당자는 장애 영향도를 파악하고 완화를 위한 기술적 분석을 진행합니다. 최근 배포나 설정 변경 여부 외부 의존성 장애 등 외부 요인을 우선적으로 점검합니다.

4) 장애 원인 확인 및 조치 단계(Identified)

고객 영향을 최소화하기 위한 조치를 수행하는 단계입니다. 초기에는 롤백이나 스케일 조정과 같은 First Action으로 사전 정의된 1차 완화 조치를 우선 적용합니다.

이후 하나의 원인 규명에 집중하기보다 여러 완화 조치를 병렬로 검토·적용하며 고객 영향을 빠르게 줄이는 데 집중합니다.

5) 조치 후 모니터링 단계(Monitoring)

취해진 조치가 실제로 고객 영향을 완화하고 있는지 확인합니다. 완화되지 않는 경우 다시 3번 장애 분석 단계와 4번 장애 원인 확인 및 조치 단계로 돌아가 다음 대응을 시도합니다.

6) 해소 확인 및 전파 단계(Resolved)

고객 영향이 모두 완화되고 장애가 해소된 상태입니다. 확인된 사항과 조치 내용은 정해진 프로세스에 따라 전사적으로 전파합니다.

7) 예방 및 피해 최소화를 위한 이행 추적 단계(Closure Time)

장애 해소 이후 RCA(Root Cause Analysis, 근본 원인 분석)를 문서화하고 재발 방지를 위한 후속 조치를 정의·실행하는 단계입니다.

우아한형제들은 이 단계를 장애 보고서 프로세스와 후속대책 실행 프로세스로 분리해 운영합니다. 이는 장애가 단순히 “해소”로 끝나지 않고 실제 운영 개선으로 이어졌는지를 확인하기 위함입니다.

4. 라이프사이클 내 추적 메트릭의 의미

앞에서 정의한 장애 관리 라이프사이클은 장애 대응을 단계별로 설명하기 위한 구조이지만 이 구조가 실제로 의미를 가지기 위해서는 각 단계가 측정 가능해야 합니다.

특히 우리가 주목한 First Action은 단순한 대응 선택이 아니라 장애 대응 흐름 안에서 특정 시점에 실행되는 조치이기 때문에 라이프사이클과 연결된 메트릭 없이는 그 빠르고 느림을 일관되게 설명할 수 없습니다.

우아한형제들은 이를 위해 라이프사이클의 각 단계에 시간 기반 메트릭을 연결했고 이를 통해 First Action이 언제 실행되었는지, 그리고 그 이후 지표와 고객 영향이 어떻게 변화했는지를 하나의 흐름으로 관찰할 수 있도록 했습니다.

라이프사이클의 각 단계는 모두 측정 대상이지만 전사적으로 추적하는 메트릭은 장애 대응 흐름을 설명하는 데 핵심이 되는 지표로 한정했습니다. 이를 통해 세부 상황은 각 팀이 해석하되 조직 전체에서는 같은 언어로 장애 대응의 속도와 병목을 바라볼 수 있도록 했습니다.

이러한 메트릭 추적의 목적은 측정 그 자체에 있지 않습니다. 같은 기준으로 보고, 같은 언어로 회고하며, 그 결과를 다시 대응 방식에 반영하는 운영 개선의 선순환을 만들어가는 데 있습니다.

라이프사이클이 지도라면 메트릭은 속도계입니다.
우리는 각 단계에서 시간을 측정해 어디에서 지연이 발생하고 있는지 어떤 구간이 고객 영향에 가장 크게 작용하는지를 확인합니다.

숫자 자체가 목적은 아닙니다. 어디가 느린지 알고 운영에서 무엇을 바꿔야 할지를 결정하는 것이 목적입니다.

4.1 MTTD(Mean Time to Detect)
평균 탐지 및 인지 시간

MTTD는 장애 발생 시점부터 이를 탐지하고 담당자 또는 시스템이 실제로 인지할 때까지의 평균 시간을 의미합니다.
일반적으로 탐지는 알람 발생 시점을 기준으로 해석되지만 우아한형제들은 ‘인지했다는 근거가 남은 시점 MTTA(Mean Time to Acknowledge)’까지를 MTTD에 포함해 정의합니다. 이는 알람 발생만으로는 실제 대응이 시작되지 않기 때문입니다. 운영 관점에서의 탐지는 의사결정이 실제로 시작되는 시점을 의미하며 자동 대응의 경우 탐지와 인지가 동시에 이뤄집니다.

MTTD가 길다면 다음 지점을 점검해야 합니다.

모니터링 커버리지 및 임곗값 적절성
알람 노이즈로 인한 신호 누락 여부
온콜 담당자의 인지 근거(ACK 등) 기록 여부

이 지표는 탐지·인지 체계의 신뢰도를 점검하기 위한 핵심 지표입니다.

4.2 MTTR(Mean Time to Repair)
평균 복구 시간

우아한형제들은 탐지·인지 체계의 상태를 MTTD로 이후의 대응·복구 체계의 성능을 MTTR로 구분해 관리합니다. 여기서 MTTR은 담당자가 장애를 인지한 시점부터 서비스가 정상 상태로 복구될 때까지의 평균 시간을 의미합니다.

MTTR이 길다면 다음과 같은 병목을 의심할 수 있습니다.

First Action 준비 상태의 부족
서비스 가시화 수준의 미흡
복구 작업 자체의 복잡성
의사결정 지연 또는 커뮤니케이션 병목

MTTR 지표는 ‘자동화 고도화’, ‘표준 대응 절차 개선’, ‘초기 대응을 지연 없이 수행할 수 있는 의사결정 구조’와 같은 구조적 개선 필요성을 드러냅니다.

4.3 MTTA(Mean Time to Action)
평균 조치 시간

MTTA는 조치 단계의 시간을 측정하는 지표입니다. 이는 장애 관리 메트릭 가이드에서 일반적으로 정의되는 지표는 아닙니다. 하지만 운영 경험상 고객 영향도를 결정짓는 가장 큰 변수는 ‘어떤 유효 조치가 언제 진행되었는가’였습니다.

그래서 MTTA는 ‘조치를 잘했는가’를 평가하기 위한 지표가 아니라 표준화된 대응이 제때 작동하고 있는지를 확인하기 위한 지표입니다. 이런 문제의식에서 우아한형제들은 First Action을 중심으로 한 조치 속도를 명확히 관찰하기 위해 MTTA를 MTTFA와 MTTEA라는 두 개의 하위 메트릭으로 나누어 관리합니다.

4.3.1 MTTFA(Mean Time to First Action)
평균 초동 조치 시간

MTTFA는 장애 발생 이후 사전 정의된 최초의 기계적 조치, 즉 First Action이 실행될 때까지의 평균 시간을 의미합니다.

우아한형제들에서 정의한 First Action은 롤백이나 스케일 조정과 같은 1차 완화 조치입니다.

MTTFA가 길다면 다음과 같은 신호일 수 있습니다.

롤백 경로가 복잡한 경우
스케일 조정이 수동 작업에 의존하는 경우
실행 전 추가 판단이나 준비가 필요한 경우

개선의 핵심은 자동화와 실행 절차의 단순화를 통해 First Action 속도를 구조적으로 줄이는 것입니다.

4.3.2 MTTEA(Mean Time to Effective Action)
평균 유효 조치 시간

MTTEA는 장애 발생 시점부터 First Action을 포함한 유효 조치가 실행된 이후 비정상적인 지표가 실제로 개선되기 시작하는 시점까지의 평균 시간을 의미합니다.

이는 단순히 “조치를 했는가”가 아니라 그 조치가 실제로 효과를 발휘했는지를 관찰하기 위한 지표입니다.

MTTFA와 MTTEA의 관계로 해석할 수 있는 신호

MTTEA ≈ MTTFA
First Action이 즉시 실행되었고 효과도 바로 나타난 이상적인 상태
MTTEA > MTTFA
First Action만으로는 충분하지 않아 추가 대응이 필요했던 상태
MTTEA만 존재(MTTFA 없음)
롤백이나 스케일 아웃과 같은 기계적인 초기 조치가 적용 불가능하거나 외부 요인으로 인한 경우를 제외하면 핫픽스 등으로 직접 대응했음을 의미하며, 운영 리스크가 높은 신호입니다.
MTTEA가 점점 길어지는 추세
표준 대응 시나리오와 자동화에 개선 포인트가 존재

4.4 MTTIR(Mean Time to Incident Report)
평균 보고 완료 시간

MTTIR는 장애 발생 시점부터 장애 보고서가 작성·완료될 때까지의 평균 시간을 의미합니다.

이 지표의 목적은 단순한 속도가 아니라 보고서 품질과 일관성입니다.

이를 위해 장애 종료 후 작성된 보고서는 SRE팀의 추가 리뷰를 거치며 분석의 근거와 논리, 재발 방지 등 아래 관점에서 한 번 더 점검됩니다.

RCA가 검증 가능한 근거를 기반으로 작성되었는가
후속 조치가 실제 재발 방지로 이어질 수 있는가
다른 원인으로 재발하더라도 더 빠르게 대응할 준비가 되었는가

MTTIR이 길다면 작성 부담, 템플릿 복잡도, 리뷰 프로세스를 함께 점검해야 합니다.

4.5 MTTPM(Mean Time to Postmortem)
평균 후속 조치 완료 시간

MTTPM은 장애회고 이후 정의된 모든 후속 조치가 완료될 때까지의 평균 시간을 의미합니다. 이는 재발 방지의 실행력을 측정하기 위한 지표입니다.

우아한형제들은 후속 조치를 단기·중기·장기로 나누어 SLA(Service Level Agreement)를 정의하고 추적합니다.

지연이 발생할 경우 단순히 책임을 묻기보다 우선순위 합의와 지원 구조부터 재점검합니다.

4.6 추가 검토 중인 지표

MTBF(Mean Time Between Failures): 장애 간격을 통해 장기적 안정성 추세를 판단합니다.
MTTF(Mean Time To Failure): 장애 발생까지의 평균 시간을 통해 예방 단계 개선 효과 측정합니다.

현재 운영 중인 대응 중심 지표 외에도 장기적인 서비스 안정성과 사전 예방 활동의 효과를 함께 살펴보기 위해 위와 같은 지표들을 추가로 검토하고 있습니다.

5. 메트릭을 운영 개선으로 연결하는 방식

앞에서 살펴본 메트릭들은 단순히 ‘얼마나 빨랐는지’를 기록하기 위한 수치가 아닙니다.
우아한형제들이 추적하는 시간 기반 메트릭은 장애 대응 과정에서 어느 단계가 병목이 되고 있는지 식별하고 어디에 리소스를 투입해야 하는지를 판단하기 위한 운영 도구입니다.
그래서 메트릭을 바라볼 때 우리가 던지는 질문은 언제나 같습니다.

“어느 단계가 느리고,
그 시간을 줄이기 위해 무엇을 바꿔야 하는가.”

예를 들어 MTTFA가 길다면 First Action을 더 빠르게 실행할 수 있는 구조가 충분히 준비되어 있는지 MTTEA가 길다면 표준 완화 조치만으로는 부족한 장애 유형이 반복되고 있는 것은 아닌지를 점검하게 됩니다.

즉, 메트릭은 결과를 평가하기 위한 지표가 아니라 다음 개선 행동을 결정하기 위한 출발점입니다.

이러한 관점에서 SRE팀이 지향하는 방향은 명확합니다.

장애 대응의 성패를
개인의 역량이나 경험에 맡기지 않고
시스템과 프로세스로 결정되게 만든다.

추가적으로 팀에서는 장애 대응 간 병목을 식별하고 개선 대상을 구조화해 온 경험을 바탕으로 탐지·조치·복구·이행 추적 과정에서 축적되는 데이터를 활용해 데이터 중심의 AI Observability 체계를 단계적으로 구축하고 있습니다.

목표는 알람을 더 많이 만드는 것이 아닙니다.
신뢰할 수 있는 신호를 바탕으로 이상 원인 후보를 빠르게 좁히고 필요한 조치를 더 빠르게 추천하는 것입니다. 이를 통해 사람이 모든 상황을 직접 해석하고 판단해야 하는 부담을 줄이고 안전한 영역부터 자동화를 확장해 나가고 있습니다.

장기적으로는 완화 조치와 복구까지 자동으로 연결되는 운영 자동화, 즉 AIOps로의 확장을 점진적으로 지향하고 있습니다.