> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Chapter 8 · 중요한 것을 측정하기

> 에이전틱 운영은 증거로 성패가 결정된다. 8개의 KPI 대시보드, ROI 계산, 단위 경제학, 그리고 평가 하네스.

*에이전틱 운영은 증거로 성패가 결정된다. 프로덕션 시스템처럼 프로그램을 계측하라.*

## 8.1 주요 성과

발표된 배포와 업계 연구에서, 규율 있게 에이전틱 인시던트 대응을 구현한 팀들에게 네 가지 성과 범위가 반복된다:

| 지표         | 문서화된 범위                    | 동인                                               |
| :--------- | :------------------------- | :----------------------------------------------- |
| MTTR 감소    | 40–70% (벤더 파일럿은 최대 75% 보고) | 자동화된 조사와 사전 승인된 해결이 인시던트 시간의 대부분을 차지하는 진단 단계를 압축 |
| 경고 볼륨 감소   | 80–90%                     | 인간이 페이지를 받기 전에 상관관계 분석, 중복 제거, 증상 억제             |
| 작업 감소      | L1/L2 운영 작업의 30–50%        | 트리아지, 일상적 해결, 증거 수집, 보고가 에이전트에 의해 흡수됨            |
| 클라우드 비용 절감 | 최적화 가능한 지출의 10–30%         | 분기별 검토 대신 지속적인 라이트사이징, 유휴 정리, 약정 관리              |

이것들을 가정할 약속이 아니라 검증할 벤치마크로 다루어라. MTTR 향상은 특히 구현 성숙도와 데이터 품질에 따라 다양하다 — 문서화된 패턴은 노이즈 감소가 먼저이자 가장 일관되게 이루어지고, 근본 원인 가속화가 두 번째, 자율 해결이 마지막이라는 것이다.

> *그림 8 — 규율 있는 배포에서의 문서화된 성과 범위, 2025–2026. 자체 기준선에 맞게 검증하라.*

범위 뒤의 명명된 데이터 포인트: AWS는 DevOps Agent의 프리뷰 고객들이 최대 75% 낮은 MTTR, 80% 빠른 조사, 94% 근본 원인 정확도를 보이고 있으며, WGU는 공개적으로 2시간 조사가 28분으로 단축되었다고 설명했다. Microsoft는 1,300개 이상의 SRE 에이전트를 자체 서비스에서 실행하면서 35,000개 이상의 인시던트를 완화하고 20,000개 이상의 엔지니어링 시간을 절약했다고 보고한다. 이것들은 벤더와 자체 수치다 — 현재 가장 강력하게 발표된 것들이며, 신뢰를 기반으로 수용하기보다 자체 파일럿에서 압박 테스트할 올바른 것들이다.

## 8.2 운영 대시보드

프로덕션 에이전틱 프로그램은 대략 8개의 KPI로 운영되며, 온콜 로테이션과 함께 월별로 검토된다:

1. **MTTD와 MTTR** — 감지와 복구 시간, 심각도별 트렌드, 에이전트가 처리한 인시던트와 인간이 처리한 인시던트 분리.

2. **자율 해결 비율** — 인간 액션 없이 해결된 인시던트의 비율. 단일 최고 성숙도 지표.

3. **권고 수락 비율** — 수정 없이 승인된 에이전트 제안의 비율. \~70% 미만이면 에이전트 판단 또는 정책을 조정해야 한다. \~95% 초과이면 승인 게이트가 형식적인 것이며 액션 클래스가 졸업해야 한다.

4. **롤백 / 개입 비율** — 역전하거나 재정의해야 했던 에이전트 액션. 자율성 성장에 대한 안전 카운터웨이트.

5. **반복 인시던트 비율** — 시스템이 학습하고 있는지 여부. 반복이 줄어든다는 것은 메모리와 문제 관리가 작동하고 있음을 의미한다.

6. **런북 / 커버리지 비율** — 에이전트 팀이 L2 이상에서 처리할 수 있는 인시던트 클래스의 비율.

7. **온콜 부하** — 주당 엔지니어당 페이지, 특히 업무 시간 외 페이지. 리더십이 느끼는 인간 경험 지표.

8. **에이전트 단위 비용** — 해결된 인시던트당, 커버된 서비스당 모델 및 플랫폼 지출. 에이전트 경제학은 1급 아키텍처 관심사다. 첫날부터 추적하라.

## 8.3 비즈니스 케이스 구축

ROI 모델에는 세 가지 항목이 있다. 첫째, 피한 다운타임: 인시던트 빈도에 분당 다운타임 비용을 곱하고 파일럿에서 검증한 MTTR 감소를 곱한다. 비용 입력값의 경우, 자체 재무팀 수치가 있다면 그것을 사용하고, 없다면 챕터 1에서 인용된 Splunk/Oxford Economics 2026년 다운타임 벤치마크(결제 및 거래 시스템의 경우 상당히 높음)를 가장 방어 가능한 외부 기준으로 사용한다. 둘째, 변환된 작업: 에이전트에 의해 흡수된 L1/L2 작업 시간, 로드 엔지니어링 비용으로 평가 — 일반적으로 인재 제약 시장에서 가장 큰 항목. 셋째, 회수된 클라우드 낭비: 대부분의 조직이 낭비되고 있다고 인정하는 지출의 20-30%에 대한 지속적인 최적화. 이에 대해 플랫폼 구독, 모델 사용, 통합 및 거버넌스를 위한 엔지니어링 시간 — 자율성 정책 소유자의 시간을 포함하여 정직하게 — 을 계산한다. 규율 있는 배포는 일반적으로 2-3분기 내에 손익분기점에 도달하며, 작업 항목만으로도 종종 플랫폼 비용을 충당한다. 모델이 다운타임 항목이 필요하다면 파일럿 도메인이 잘못된 것이다. 작업 절감이 케이스를 지탱하고 다운타임이 추가 이익인 도메인을 선택하라.

## 8.4 에이전트의 단위 경제학

챕터 4는 2계층 감지가 24/7 에이전틱 커버리지를 경제적으로 실현 가능하게 만드는 것이라고 주장했다. 이 섹션은 그것을 구체화한다. "스스로 값을 치른다"는 말은 정확히 이 책이 구매자에게 거부하도록 말하는 종류의 손 흔들기이기 때문이다. 에이전틱 프로그램의 비용은 모델 추론에 의해 지배되며, 추론 비용은 비싼 추론이 실행되는 곳에 의해 지배된다. 원칙은 저렴한 감지를 상시 작동으로 유지하고, 트리아지를 통과한 소수의 신호에만 프론티어 추론을 사용하는 것이다.

단일 인시던트를 비용 객체로 읽어보자. 상시 작동 "pulse"는 모든 신호에서 저비용으로 경량 감지를 수행하고, 고중량 해결기는 pulse가 조사할 가치가 있는 것을 발견할 때만 다단계 추론을 수행한다. 대표적인 분할에서, 감지는 인시던트당 지출의 작은 부분을 차지하고, 트리아지가 약간 더, 딥 해결이 대부분 — 하지만 딥 해결은 트리아지를 통과한 소수의 신호에만 실행된다. 구체적인 예시: 하루에 약 50개의 신호를 발생시키는 환경에서, 대부분이 pulse 전용 감지에 의해 처리되고 소수만 전체 해결기 실행으로 에스컬레이션되면, 비싼 계층의 duty cycle을 낮게 유지하면서 모든 신호를 커버한다. 정확한 비율은 직접 측정해야 한다. 아키텍처가 비율을 유리하게 만드는 것이다.

> *그림 12 — 하나의 인시던트에서 토큰이 어디로 가는지: 저렴한 감지는 모든 신호에서 실행되고, 비싼 추론은 트리아지를 통과한 소수에만 실행된다. 첫날부터 해결된 인시던트당 비용을 추적하라.*

이것이 챕터 8 대시보드에서 "인시던트당 에이전트 비용"과 "커버된 서비스당 에이전트 비용"이 사후 고려가 아닌 1급 KPI인 이유다: 모든 잡음 있는 신호에서 프론티어 추론을 실행하는 아키텍처는 첫 번째 갱신 전에 자체 ROI를 지운다. 그리고 인시던트당 수치를 첫날부터 추적하지 않으면 이것이 일어나는 것을 볼 수 없다.

상업적 구조는 이 현실과 싸우기보다 맞춰질 수 있다. 성과 기반 옵션 — 검증된 절감의 일정 비율로 설정된 수수료, 절감이 없으면 아무것도 빚지지 않음 — 은 벤더의 수익을 고객의 실현된 혜택에 연결하고 그 자체를 위해 추론 비용을 증가시킬 인센티브를 제거한다. 구체적인 예시: 검증된 연간 절감의 50%로 가격 책정된 비용 최적화 참여, 아무것도 찾지 못하면 0 청구, 이해 관계 정렬을 완전하게 만든다. 어떤 구조이든, 비즈니스 케이스에 포함되어야 할 수치는 챕터 9의 90일 기준선에 맞서 자체 환경에서 측정한 것이다 — 이 책을 포함하여 누구의 슬라이드에서 나온 헤드라인이 아니다.

## 8.5 신뢰하기 전에 운영 에이전트 평가하기

이 책은 챕터 3부터 에이전틱 운영을 "자기 검증"이라고 불렀지만, 검증 단계가 구체적으로 무엇을 확인하는지, 또는 자신감 있게 틀린 해결이 프로덕션에 도달하기 전에 어떻게 잡을 수 있는지를 보여주지 않았다. 이 섹션은 그 간격을 좁힌다. 왜냐하면 서문이 섬기겠다고 약속한 엔지니어들이 정확히 이 하네스를 구축하고 실행해야 할 사람들이기 때문이다.

에이전트 평가 하네스에는 네 가지 부분이 있다. 첫째, 시나리오 라이브러리: 기록된 실제 인시던트와 의도적으로 주입된 장애로, 각각 알려진 올바른 결과 — 올바른 근본 원인, 안전한 액션, 깔끔한 롤백 — 를 가진다. 둘째, 섀도우 실행: 에이전트가 프로덕션 자체가 아닌 프로덕션의 샌드박스 미러에 대해 행동하므로, 결과 없이 제안된 액션을 관찰할 수 있다. 셋째, 정답 대비 채점: 올바른 근본 원인에 도달했는가, 안전한 액션을 선택했는가, 롤백이 작동했을까? 넷째, 회귀 게이트: 이전 에이전트 버전 대비 동작 변경은 출시 전에 라이브러리를 통과해야 한다 — 팀이 다른 프로덕션 코드에 적용하는 것과 동일한 규율이다.

> *그림 13 — 에이전트 평가 하네스: 시나리오 라이브러리, 샌드박스 미러에 대한 섀도우 실행, 정답 대비 채점, 버전이 출시되기 전 회귀 게이트.*

비결정성은 결정론적 자동화에서 온 팀들을 놀라게 하는 부분이다: 동일한 시나리오가 다른 실행에서 다른 에이전트 동작을 산출할 수 있다. 하네스는 각 시나리오를 여러 번 실행하고 단일 통과가 아닌 결과의 분포를 채점하여 이를 처리한다 — 70%의 시간에 올바른 수정은 99%의 시간에 올바른 수정과 다른 위험 프로필을 가지며, 분포만이 어느 것을 가지고 있는지 드러낸다. 구체적인 검증 확인이 이를 구체화한다: 데이터베이스 연결 고갈 시나리오에 대해, 하네스는 에이전트가 연결 풀 고갈을 근본 원인으로 식별하고, 액션이 단순히 서비스를 재시작하는 것이 아니라 올바른 연결 제한을 복원하며, 액션 후 연결 수가 기준선으로 돌아와 유지된다는 것을 검증한다 — 에이전트가 프로덕션에서 실행하는 동일한 DARV "검증" 단계를, 알려진 답에 대해 실행한다. 하네스에서 자체 검증 확인을 통과하지 못하는 에이전트는 프로덕션에서 무감독으로 이를 실행할 자격이 없다.

<Tip>
  **측정 원칙**

  배포하기 전에 기준선을 잡아라. 가장 일반적인 비즈니스 케이스 실패는 신뢰할 수 있는 "이전" 수치가 없는 것이다: 첫 번째 에이전트가 프로덕션에 닿기 전에 90일의 MTTR, 경고 볼륨, 페이지 수, 작업 시간을 캡처하라. 그렇지 않으면 영원히 일화에 기반하여 주장하게 될 것이다.
</Tip>