[AIOps 5] 도입 효과 평가하기: MTTD·MTTR와 원인 분석 품질

About this offer

이 글에서 다룰 주제 시간 지표 : 탐지·보고서 전달·복구·원인 확정을 어떻게 구분할까? 분석 품질 : 원인 후보가 맞았는지, 근거 없이 단정하지 않았는지 어떻게 평가할까? 비교 실험 : 합성 장애와 shadow 평가에서 무엇을 검증할 수 있을까? 주요 단어 · incident · MTTD · MTTR · Top-1 · Hit@3 · 판단 보류 · shadow · 평가 누수 · 429 Agent가 30초 만에 보고서를 만들었다면 AIOps 도입은 성공한 것일까? 운영자가 보고서를 받지 못했거나, 잘못된 원인을 믿고 조치를 시작했다면 생성 속도만으로 효과를 설명하기 어렵다. 이 글은 학습 자료를 바탕으로 만든 평가 설계안 이다. 아래 시간과 장애 수치는 모두 설명용 가상 사례이며, 실제 시스템의 측정 결과나 개선율이 아니다. 그림 1. 가상 사건의 시간축이다. 사용자 영향은 10:00, 탐지는 10:02, 분석 요청은 10:03, 보고서 전달은 10:05, 복구는 10:20이다. 원인 확정은 다음 날 이루어졌다고 가정하며, 시간축 밖에 따로 표시했다. 1. 측정 단위: 알림보다 사건을 먼저 정의하기 incident(사건) 는 함께 조사하고 대응하는 서비스 영향의 단위다. 하나의 사건에서 여러 메트릭 알림과 재알림이 발생할 수 있다. 알림 20개가 울렸다고 장애가 20건인 것은 아니다. 한 사건에 incident_id 를 부여하고 관련 알림을 연결해야 복구 시간을 중복 계산하지 않는다. 서로 다른 원인의 사건을 하나로 묶지 않도록 연결 기준과 검토 절차도 정한다. 다음 시각을 분리해서 기록한다. 시각 정의 impact_started_at 사용자 영향이 시작된 것으로 확인한 시각 detected_at 정한 관측 체계가 해당 사건을 최초로 감지한 시각 acknowledged_at 담당자가 사건을 인지하고 대응을 맡은 시각 analysis_requested_at Agent 분석을 요청한 시각 analysis_delivered_at 보고서가 운영자에게 이용 가능하게 전달된 시각 working_diagnosis_at 조사에 사용할 가설을 최초 채택한 시각 action_started_at 대응 조치를 시작한 시각 restored_at 유효한 관측으로 서비스 회복을 확인한 시각 cause_verified_at 사후 검토 등을 통해 원인을 확정한 시각 모든 사건이 이 순서대로 진행되는 것은 아니다. 분석 보고서보다 먼저 완화 조치를 할 수도 있고, 원인이 확정되기 전에 복구될 수도 있다. 그래서 시각을 한 개의 ‘처리 완료’로 합치지 않는다. 2. 시간 지표: 시작점과 끝점을 함께 쓰기 이 글의 정의는 다음과 같다. MTTR이라는 약어는 조직마다 repair·recovery·restore 등 의미와 기산점이 다를 수 있으므로 대시보드에도 구간을 적는다. $$ TTD_i = detected_i-impact_started_i $$ $$ MTTD = \frac{1}{N_{known}}\sum_{i=1}^{N_{known}}TTD_i $$ 영향 시작 시각을 모르는 사건은 MTTD의 해당 분모에 넣지 못한다. 0초로 채우지 말고 시작 시각 확인 가능 사건 / 전체 사건 도 함께 보여 준다. 이 글에서는 탐지 → 서비스 복구 의 평균을 MTTR_detected_to_restored 로 정의한다. 사용자 영향 시작 → 복구는 별도의 전체 영향 시간으로 기록한다. $$ T_{report}=analysis_delivered-analysis_requested $$ 보고서 시간은 모델 내부 생성 완료가 아니라 운영자가 받을 수 있게 된 시점을 끝으로 잡는다. 큐 대기, 도구 조회, 생성, 전송 시간을 분리하면 병목도 찾을 수 있다. 실패·시간 초과·전송 실패 건수를 함께 보고하지 않으면 성공한 빠른 사례만 남을 수 있다. 그림의 사건에서는 TTD가 2분, 보고서 전달이 2분, 탐지부터 복구까지 18분이다. 전체 사용자 영향은 20분이다. 단일 사건의 소요시간은 평균인 MTTD·MTTR 자체가 아니다. 평균 외에 중앙값과 충분한 표본이 있을 때의 상위 분위수, 표본 수, 미복구 사건 수를 함께 본다. 복구된 사건만 집계하면 오래 걸리는 진행 중 사건이 빠질 수 있다. 평균 하나로 사고 대응 품질을 판단하기 어렵다는 문제는 Google SRE의 incident metrics 자료에서도 다룬다. Incident Metrics in SRE 알림 이후에 실행되는 Agent는 같은 사건의 최초 탐지 시각을 앞당길 수 없다. 탐지 모델 개선과 조사 Agent 개선을 분리해야 효과를 올바르게 해석할 수 있다. 3. 분석 품질: 원인을 맞히는 것과 근거를 제시하는 것 Top-1 은 첫 번째 후보의 적중 여부, Hit@3 은 최대 세 후보 안에 정답이 포함됐는지를 보는 평가 방식이다. 여기서는 사건별 원인 후보를 평가한다. 정답은 모델 출력이 아니라 독립적으로 검토한 사건 기록에서 만든다. 직접 원인과 근본 원인은 따로 라벨링한다. “429 발생” 같은 증상 반복만으로 “재시도 정책 변경으로 시도 수가 증폭됨”을 맞혔다고 처리하지 않는다. 제안하는 검토 척도는 다음과 같다. 보편적인 표준 점수 체계가 아니라 이번 평가를 위한 정의다. 단계 해석 M0 근거와 맞지 않는 설명 M1 관측된 증상만 재진술 M2 직접 원인과 그 근거 설명 M3 근본 원인 후보와 증상으로 이어진 메커니즘 설명 후보 수는 세 개로 제한하고 사실상 같은 후보의 표현만 바꿔 넣지 않는다. 평가 전에 정한 시한 내 최초 보고서 를 채점하면, 여러 번 출력한 것 중 정답만 골라 성능을 높이는 문제를 줄일 수 있다. 예를 들어 ‘요청 후 3분’은 평가용 시한의 예시이며 공통 표준은 아니다. 충분한 증거와 확정 정답이 있는 평가 사건에서는 보고서 없음·시간 초과·잘못된 보류도 서비스 전체의 미적중으로 포함한다. 보고서를 낸 건만 대상으로 한 조건부 적중률은 별도 보조 지표로 분리한다. 반면 증거 부족을 의도한 사건 은 원인 적중 평가에서 분리하고, 적절히 보류했는지 채점한다. 사후 검토가 끝나지 않은 사건은 미확정으로 남겨 정답 라벨의 평가 가능 비율을 보고한다. 원인 이름을 우연히 맞혔어도 존재하지 않는 로그·설정·수치를 인용했다면 좋은 분석이 아니다. 원인 적중과 별개로 근거 추적 가능성·허위 근거·반대 증거 처리·불필요한 위험 조치 를 검토한다. 이 설계에서는 허위 근거가 있는 보고서를 통과로 처리하지 않는다. 4. 합성 장애: 같은 429라도 원인은 다르게 만들기 429 는 HTTP에서 요청 제한과 관련된 응답 상태다. 상태 코드만 보고 어떤 쿼터·주체·정책이 원인인지까지 확정할 수는 없다. RFC 6585, 429 Too Many Requests 다음은 학습 자료를 정리한 가상 테스트 시나리오 8종 이다. 실제 외부 API 제공자의 제한 규칙이나 실험 성능을 나타내지 않는다. 사례 숨겨 둔 차이 Agent가 확인할 증거 1 배치 동시 실행으로 신규 요청 급증 신규 작업량, 스케줄, 요청 수 2 요청 수는 비슷하지만 토큰 사용 증가 요청 수와 토큰량, 제한 종류 3 짧은 재시도로 요청 시도 수 증폭 시도/작업 비율, 대기시간, 설정 변경 4 다른 서비스가 공유 쿼터 사용 같은 쿼터 범위의 서비스별 사용량 5 내부 tenant 제한값 오류 내부 limiter 설정과 외부 응답의 구분 6 잘못된 프로젝트 자격증명 사용 민감값을 가린 프로젝트 식별·설정 이력 7 장애와 무관한 배포가 동시에 발생 배포와 실제 제한 초과를 잇는 증거 유무 8 구분에 필요한 자료 누락 보류와 필요한 추가 정보의 제시 사례 3을 구체화해 보자. 신규 작업은 분당 100건으로 그대로인데 호출 시도는 100회에서 430회로 늘었다고 가정한다. 가상 요청 제한은 분당 300회이며 429 응답이 증가했다. 직전 변경에서 최대 시도 수가 2회에서 5회로, 재시도 대기가 2초에서 100ms로 바뀌었고 초기 503 오류가 재시도를 촉발했다는 증거를 제공한다. 이 경우 분석은 층위를 나눌 수 있다. 증상 : 429와 작업 지연 증가 직접 원인 : 호출 시도 수가 가상 요청 제한을 초과 원인 후보 : 재시도 정책 변경이 일시 오류를 반복 호출로 증폭 추가 검증 : trace의 재시도 간격과 설정 diff, 정책 복원 후 시도/작업 비율 이 설명만으로 실제 실행 결과를 주장할 수는 없다. 시나리오별 증거 파일, 기대 판정, 허용 가능한 대안, 평가 시점까지 공개할 정보 범위를 먼저 만들어야 한다. 여덟 사례는 평가 파이프라인의 동작을 점검하는 작은 출발점이지 일반적인 원인 분석 성능을 증명하는 표본이 아니다. 외부 유료 API에 부하를 보내지 않고 mock 서버·로컬 limiter·작업 큐로 재현할 수도 있다. 이때 제한 창과 재시도 집계 규칙은 실험 자체의 정의다. 실제 제공자의 쿼터 동작으로 일반화하지 않는다. 이번 글에서는 이 하네스를 구현하거나 실행하지 않았다. 5. 비교 설계: baseline·shadow·assisted가 답하는 질문 방식 운영자에게 Agent 결과 제공 확인할 수 있는 것 baseline 없음 기존 조사 절차의 시간·품질 shadow 대응 중에는 숨김 같은 시점의 증거에서 Agent가 만드는 보고서 품질·지연 assisted 제공 운영자의 판단과 대응에 미치는 영향 shadow에서는 Agent의 보고서가 실제 대응에 영향을 주지 않는다. 따라서 같은 기간 MTTR이 낮아졌다고 Agent 덕분이라고 주장할 수 없다. assisted 비교에서는 사건 난이도와 담당자 숙련도를 맞춰야 한다. 같은 사람이 같은 문제를 두 번 풀면 두 번째에 기억 효과가 생긴다. 내용은 다르지만 난이도가 비슷한 변형 사례를 배정하고, 순서를 무작위화하거나 균형 있게 교차 배치할 수 있다. 가장 중요한 것은 미래 정보 누수 방지 다. 10:05 보고서를 평가하면서 10:20 복구 결과나 다음 날 사후 보고서를 Agent에게 보여 주면 실제 조사 조건이 아니다. 정답 작성자와 평가자는 사후 정보를 쓸 수 있지만, 평가 대상 Agent가 볼 수 있는 증거는 정한 시점까지로 제한한다. 작은 표본에서는 우연과 사건 구성의 영향을 크게 받는다. 단순한 ‘몇 % 개선’ 대신 사건 수, 제외 기준, 성공·실패·미복구·보류 분포, 개별 사건의 변화를 함께 남긴다. 6. 기록과 대시보드: 계산을 재현할 수 있게 만들기 사건 상태를 채팅 명령이나 버튼으로 기록한다면 /ops start , /ops adopt , /ops restore 같은 인터페이스를 생각할 수 있다. 명령 해석과 상태 변경은 결정적인 API 로직으로 처리하고, LLM의 자유 텍스트에서 시각을 추측하지 않는다. 저장 시에는 인증된 실행자, 사건 ID, 이벤트 시각과 수신 시각, 상태 버전, 중복 요청 방지 키를 기록한다. 동일 요청 재전송으로 최초 채택 시각이 바뀌지 않아야 한다. 가설 변경은 기존 이벤트를 덮어쓰기보다 이유를 포함한 새 이벤트로 남긴다. 제품이 특정 멱등성 헤더를 제공한다고 가정하지 말고 애플리케이션 계약으로 정의한다. Grafana용 평가 뷰는 사건당 한 행 으로 만드는 것이 이해하기 쉽다. 후보가 세 개라고 사건 행이 세 배로 늘어나면 평균과 분모가 왜곡될 수 있다. 후보별 검토는 별도 테이블에 보관하고 사건별 지표로 집계한다. 대시보드에는 다음을 함께 둔다. 전체 사건 수, 평가 가능 사건 수, 미확정·미복구·보고서 실패 수 정의가 표시된 시간 지표와 개별 사건 분포 직접 원인·근본 원인의 적중률과 각각의 분모 증거 부족 사례의 적절한 보류율, 허위 근거 건수 사건별 근거와 검토 결과로 이동하는 상세 링크 비율은 그룹별 퍼센트의 단순 평균보다 원래 분자·분모를 합쳐 계산한다. 모델 버전 필터를 적용할 때 Agent가 없는 baseline 사건이 사라지지 않도록 비교 집단 필터와 모델 전용 패널 필터도 구분한다. 7. 학습 정리: 탐지에서 평가까지 연결하기 1편의 IF는 피처 조합에 이상 점수를 부여한다. 2편은 데이터의 성격에 맞는 탐지 방법을 고르고, 3편은 결과를 신선도와 함께 운영 화면에 연결한다. 4편은 필요한 증거를 수집해 원인 후보를 만들고, 이 글에서는 그 결과가 실제로 유용한지 측정하는 방법을 정리했다. 도입 전에 먼저 답할 질문은 세 가지다. 무엇을 놓치고 있는가, 어떤 근거로 판단을 도울 것인가, 좋아졌다는 것을 무엇으로 확인할 것인가. 이 질문에 답할 수 있어야 모델과 Agent의 역할도 구체적으로 정할 수 있다. 학습 자료 기준 : 2026-10-03 AIOps Text2SQL·평가 학습 정리. 시간 정의·품질 척도·합성 사례는 본 시리즈의 제안이며, 실제 운영 성과·구현 완료를 의미하지 않는다. 이전 · 4편: 증거를 모으는 Agent와 Text2SQL 처음 · 1편: Isolation Forest 원리와 실습 전체 · AIOps 시리즈