우아한형제들의 서비스 이상 탐지 전략 정리
핵심 요약
우아한형제들은 시스템 지표 대신 고객 경험에 가까운 서비스 지표를 실시간으로 모니터링해 장애를 빠르게 탐지하고 있습니다. 중앙값 기반 예측, 임계값·연속 도달 횟수, 자동 알림·대응 프로세스를 결합해 탐지 정확도와 속도를 크게 끌어올렸습니다.
장애는 왜 피할 수 없는가
서비스는 끊임없이 바뀌고, 그 변화의 중심에는 사람이 있습니다.
새 기능 출시, 트래픽 증가 대응, 인프라 변경 등 수많은 작업이 매일 이뤄지기 때문에 실수나 예기치 못한 상호작용을 완전히 없애는 것은 사실상 불가능합니다.
그래서 우아한형제들은 "장애는 언젠가 반드시 난다"는 전제를 받아들이고, 장애 자체를 없애려 하기보다 얼마나 빨리 발견하고 피해를 줄일 수 있는지에 초점을 맞춥니다.
결국 핵심은 장애 발생 여부가 아니라, 장애가 났을 때 고객의 불편과 피해를 얼마나 최소화하느냐입니다.
전통적인 시스템 지표 모니터링의 한계
기존 방식은 CPU, 메모리, 네트워크 트래픽 같은 인프라 지표에 임계값을 걸고, 이를 넘으면 경보를 울리도록 설정하는 구조입니다.
이 방식의 문제는 두 가지입니다.
첫째, 모니터링해야 할 지표가 너무 많아 모든 지점을 감시하는 것이 불가능합니다.
둘째, 시스템 지표는 고객이 실제로 겪는 문제와 직접적으로 연결되지 않는 경우가 많습니다.
예를 들어 CPU는 정상인데 특정 API 오류로 주문만 실패하는 상황이라면, 시스템 지표만 본 관제에서는 이를 놓치기 쉽습니다.
결론적으로, 시스템 지표만으로는 "놓치는 장애"가 생기기 쉽고, 이건 곧바로 고객 피해로 이어집니다.
서비스 지표 기반 이상 탐지의 개념
우아한형제들은 장애를 더 잘 잡기 위해 "서비스 이상 탐지"를 도입했습니다.
서비스 지표란 로그인 수, 주문 건수, 결제 성공률처럼 고객 행동과 서비스 성과를 직접 반영하는 지표입니다.
이 지표들은 수가 상대적으로 적고, 고객 경험과 바로 연결되기 때문에 "이상한 변화 = 고객이 뭔가 불편을 겪고 있다"로 해석하기 좋습니다.
장애가 발생하면 당장은 원인을 모를 수 있어도, 결과적으로 서비스 지표는 비정상적인 움직임을 보이게 됩니다.
따라서 과거 패턴을 기준으로 "지금 값이 평소와 얼마나 다른지"를 계속 감시하면, 시스템 어디에서 문제가 생겼든 결과적으로 고객 영향을 빨리 감지할 수 있습니다.
서비스 이상 탐지 시스템의 핵심 요구사항
우아한형제들이 설계 시 세운 주요 요구사항은 세 가지입니다.
첫째, 실시간 또는 거의 실시간에 가깝게 탐지해야 합니다.
장애가 난 지 한참 뒤에 경보가 오면 의미가 없으므로, 감지부터 알림까지의 지연을 최소화하는 것이 필수였습니다.
둘째, 왜 경보가 울렸는지를 설명할 수 있어야 합니다.
완전한 AI 블랙박스보다는, 어떤 기준과 계산으로 이상으로 판단했는지 사람이 이해하고 튜닝할 수 있는 구조가 필요했습니다.
셋째, "알리는 것"에서 끝나지 않고, 그 이후의 대응 절차까지 함께 제공해야 합니다.
누가 대응할지, 어디서 소통할지, 어떻게 전파할지까지 자동화해 누구나 빠르게 움직일 수 있도록 하는 것을 목표로 했습니다.
중앙값 기반 예측과 임계값 설계
배달 서비스는 점심·저녁 피크처럼 일정한 패턴이 뚜렷합니다.
우아한형제들은 이 특성을 활용해 과거 동일 시간대 데이터의 중앙값을 이용해 "지금 시점의 정상적인 값"을 예측합니다.
중앙값을 사용한 이유는 직관적이고, 갑작스러운 이상치에 덜 흔들리며, 분석·튜닝이 쉽기 때문입니다.
이렇게 계산한 예측값과 실제 값을 비교해 차이가 어느 수준을 넘으면 이상으로 보고, 이를 임계값으로 설정합니다.
서비스 지표 그래프에서는 예측값 곡선과 실제값 곡선이 함께 그려지고, 임계선을 넘는 구간이 감지 포인트가 됩니다.
이 방식은 복잡한 AI 모델 대신 "빠르게 만들어 보고, 실제 장애 데이터로 바로 검증하고, 바로 개선"하기에 적합한 설계입니다.
이 그래프처럼 예측 경향선과 실제값을 비교해 이상 여부를 판단합니다.
연속 도달 횟수로 오탐 줄이기
실제 서비스 지표는 광고 캠페인, 이벤트, 날씨 등 다양한 요인으로 순간적인 출렁임이 자주 발생합니다.
이런 단발성 스파이크나 일시적 감소에 매번 경보가 울리면 피로도가 급격히 올라가고, 경보 신뢰도가 떨어집니다.
이를 막기 위해 우아한형제들은 "임계값에 연속으로 몇 번 도달했는가"를 추가 기준으로 사용합니다.
연속 횟수를 낮게 설정하면 장애를 더 빨리 잡지만 오탐이 늘 수 있습니다.
연속 횟수를 높이면 오탐은 줄지만, 탐지 속도가 느려질 수 있습니다.
각 서비스 지표마다 특성이 다르기 때문에, 과거 트렌드를 분석하며 임계값과 연속 도달 횟수를 조합해 가장 적절한 지점을 찾는 안정화 과정이 필요했습니다.
이 방식 덕분에 "한 번 튀었다가 바로 돌아온 값"과 "계속 비정상인 상태"를 구분해, 진짜 장애에만 집중할 수 있게 되었습니다.
알림 채널과 장애 대응 프로세스 자동화
임계 조건을 만족해 장애로 판단되면, 곧바로 대응 체인이 자동으로 작동합니다.
먼저 Slack 채널로 상세한 경보 메시지가 발송됩니다.
여기에는 어떤 지표가, 어느 정도로, 어느 임계 수준을 넘었는지 등의 정보가 포함되어 상황 파악을 돕습니다.
하지만 야간이나 회의 중에는 Slack만으로는 놓치기 쉽기 때문에, 우아한형제들은 Opsgenie 온콜 담당자 호출을 연동했습니다.
서비스 지표별로 담당자가 사전에 정의되어 있어, 사람을 수동으로 찾아 전화로 깨우는 과정이 필요 없습니다.
또한 장애가 발생했을 때 "어디서 모여서 어떻게 논의해야 하지?"를 고민하지 않도록, 장애 전파와 전용 커뮤니케이션 채널 생성도 자동으로 처리됩니다.
이 덕분에 담당자는 "지금 무엇을 해야 하는지 기억해내는 데" 시간을 쓰지 않고, 바로 원인 분석과 복구에 집중할 수 있습니다.
도입 이후 성과와 수치
서비스 이상 탐지를 도입한 뒤, 우아한형제들은 세 가지 목표 지표에서 의미 있는 개선을 얻었습니다.
첫째, 경보 정밀도가 약 11배 향상되었습니다.
과거에는 경보가 울리면 "이번에도 오탐 아닐까?"라는 의심이 컸지만, 이제는 대부분 실제 장애여서 경보에 대한 신뢰도가 크게 높아졌습니다.
이로 인해 불필요한 야간 호출이 줄어 구성원의 피로도도 줄었고, 경보가 오면 곧바로 "장애 모드"로 전환해 빠르게 대응하는 문화가 자리 잡았습니다.
둘째, 장애 탐지율이 약 70% 개선되었습니다.
이제는 대다수 장애를 서비스 이상 탐지가 먼저 포착해, 우리가 모르는 사이 고객 피해가 눈덩이처럼 불어나는 상황에 대한 불안이 큰 폭으로 줄었습니다.
셋째, 장애 전파 시간도 약 74% 단축되었습니다.
자동 전파·호출 체계 덕분에 장애를 인지한 뒤 관련 인력이 투입되기까지의 시간이 줄어, 그만큼 복구도 빨라지는 선순환이 만들어졌습니다.
서비스 지표 모니터링의 전사 통합 효과
서비스 이상 탐지 도입 전에도 각 서비스팀은 나름의 방식으로 서비스 지표를 모니터링하고 있었습니다.
그러나 팀마다 쓰는 지표, 정의, 알림 채널이 제각각이라 SRE팀이 전사적인 장애 관제와 정책 적용을 하기에는 매우 어려운 환경이었습니다.
이번 도입을 계기로 각 팀이 흩어서 운영하던 서비스 지표 모니터링을 서비스 이상 탐지 시스템으로 통합했습니다.
이제 SRE팀은 주요 서비스 지표 현황을 한곳에서 파악할 수 있고, 새로운 관제 정책이나 프로세스를 도입할 때도 공통 기반 위에서 일관되게 적용할 수 있게 되었습니다.
이는 단순히 기술적인 개선을 넘어, 조직 차원의 장애 대응 역량을 끌어올리는 기반이 됩니다.
앞으로의 방향: 원인 분석에 AI 활용
현재 시스템은 "장애가 났다"를 빠르고 정확하게 알려주는 역할에 상당히 성숙해졌습니다.
다음 단계는 "왜 장애가 났는가"를 더 빨리 찾아내는 것입니다.
SRE팀은 이미 전사적인 지표, 로그, 이벤트 데이터를 대량으로 보유하고 있으며, 지금은 주로 사람이 이를 보고 원인을 추적합니다.
하지만 장애 상황에서는 시간과 집중력이 모두 부족하기 때문에, 방대한 데이터 속에서 단서를 찾는 일을 자동화할 필요가 있습니다.
우아한형제들은 이 영역에서는 초기부터 AI 기반 접근을 적극 검토하고 있습니다.
서비스 이상 탐지처럼 규칙 기반·통계 기반으로 빠르게 시작했다가, 점차 데이터를 쌓으며 AI를 활용해 "어떤 지표 조합이 이 장애와 연관이 깊은지"를 제안해 주는 방향으로 확장하는 청사진을 그리고 있습니다.
인사이트
우아한형제들의 사례는 몇 가지 중요한 교훈을 줍니다.
첫째, 장애를 완전히 없애려 하기보다 "빠른 탐지와 대응"에 초점을 두는 것이 현실적이고 효과적입니다.
둘째, 고객 경험에 가까운 서비스 지표를 중심에 두면, 시스템 어디에서 문제가 생겨도 결과적으로 드러나는 이상을 잡아낼 수 있습니다.
셋째, 복잡한 AI 모델보다 이해 가능한 간단한 기법(중앙값, 임계값, 연속 도달 횟수)으로 시작해, 빠르게 돌려보고 개선하는 전략이 조직에 안착시키는 데 유리합니다.
마지막으로, 알림만 잘 만들어도 반쪽짜리입니다.
누가, 언제, 어디서, 어떻게 대응할지가 자동으로 이어져야 장애 대응 전체 리드타임이 줄어듭니다.
당신의 조직에서도:
가장 중요한 서비스 지표 몇 개를 선정해
과거 패턴과 비교하는 간단한 이상 탐지부터 시작하고
알림 이후의 온콜·커뮤니케이션 흐름까지 한 번에 설계해 보는 것
만으로도 장애 대응 수준을 눈에 띄게 끌어올릴 수 있을 것입니다.
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.