MTTR·MTBF를 넘어, 운영팀이 진짜 설득력을 갖추는 방법
1. "서버가 30분 다운됐습니다"라는 말이 경영진에게 전달되지 않는 이유
장애 보고서를 쓸 때마다 반복되는 장면이 있습니다.
- MTTR 28분
- 가용성 99.94%
- MTBF 720시간
운영팀은 충분히 설명했다고 생각합니다. 하지만 경영진의 반응은 미묘합니다. 고개는 끄덕이지만, 의사결정은 일어나지 않습니다. 이유는 단순합니다. 이 숫자들이 ‘비즈니스 문제’로 번역되지 않았기 때문입니다.
반대로 이렇게 말하면 어떨까요?
"오늘 오전 30분간의 결제 시스템 장애로 약 1,200건의 트랜잭션이 실패했으며, 추정 매출 손실은 3,600만원입니다(분당 평균 40건 x 거래당 평균 3만원 기준)."
같은 30분 다운타임을 다르게 표현할 것일 뿐입니다. 하지만 두 번째 문장은 즉각적인 대응과 의사결정을 이끌어냅니다. 기술 지표와 비즈니스 언어 사이의 간극, 이번 글에서는 그 간극을 좁히는 방법을 짚어봅니다.
2. 문제의 본질: IT 지표는 ‘내부 언어’다
이전 글에서 다룬 것처럼, 이 지표들은 운영 효율을 측정하는 데 매우 유효합니다. MTTR이 낮다는 건 팀이 빠르게 복구한다는 뜻이고, MTBF가 길다는 건 시스템이 안정적이라는 뜻입니다. 그런데 이 지표들에는 공통된 한계가 있습니다. 바로 운영팀 내부의 언어라는 점입니다.
기술 지표 | 의미 | 경영진의 관심사 |
MTTR 28분 | 평균 복구 시간 | 그래서 얼마나 손해 봤나? |
가용성 99.9% | 연간 약 8.7시간 다운 | 고객은 얼마나 이탈했나? |
MTBF 720시간 | 장애 간 평균 간격 | 장애는 얼마나 자주 발생하나? |
에러율 0.3% | 요청 실패 비율 | 어떤 서비스가 영향 받나? |
위의 표에서 알 수 있듯이 지표가 잘못된 것은 아닙니다. 오히려 번역이 없는 것이 문제죠. 그리고 이 번역이 없으면 경영진이 이해하지 못하는 지표로 인식되어 우선순위에서 밀리게 됩니다.
3. IT 지표를 비즈니스 언어로 바꾸는 3단계 프레임워크
1단계: 서비스별 비즈니스 가치 정의
모든 시스템이 동일한 중요도를 갖지 않습니다. 결재 서버와 사내 공지 게시판의 다운타임은 영향이 다르기 때문이죠. 따라서 먼저 정의해야 할 것은 다음 세 가지입니다:
- 초당 트랜잭션 수(TPS)
- 트랜잭션당 평균 수익
- 서비스 의존도(연쇄 영향 범위)
이 세 가지가 정리되면 장애 발생 시 손실 추정이 가능해집니다.
매출 손실 = 다운타임(초) × 초당 트랜잭션 수(TPS) × 트랜잭션당 수익
이 공식은 최대 손실 추정치입니다. 실제로는 장애 복구 후 재시도나 다른 채널 우회로 일부 거래가 복구될 수 있습니다. 중요한 건 근거 있는 범위(ex. 실제 손실률 30~50%)를 설정하고, 경영진과 합의하는 것입니다.
한편, 위 공식은 단일 서비스의 직접 손실만 계산합니다. 만약 결제 서버처럼 다른 서비스들이 의존하는 핵심 시스템이라면, 주문·배송·알림 서비스까지 연쇄적으로 영향을 받을 수 있습니다. 이런 경우 서비스 의존도를 고려해 손실을 2~3배로 추정하는 것이 현실적입니다.
2단계: SLO를 비즈니스 목표와 정렬하기
SLO(Service Level Objective)는 단순히 기술팀이 지켜야 할 목표가 아닙니다. 비즈니스와 운영팀이 함께 협의해서 정해야 하는 약속입니다. 예를 들어, 아래와 같이 연결할 수 있습니다.
비즈니스 목표 | SLO 설정 |
결제 전환율 유지 | 결제 API 가용성 99.95% 이상 |
고객 이탈 감소 | 주요 화면 응답시간 2초 이내 |
고객센터 비용 절감 | 로그인 오류율 0.1% 미만 |
이처럼 SLO 위반이 곧 비즈니스 목표 미달로 연결되는 구조를 만들면, “결제 API 가용성이 목표에 미달했습니다.’”가 아니라, “이번 달 결제 전환율 목표 달성이 어렵습니다.”와 같은 구체적인 대화로 바뀝니다. 자연스럽게 경영진도 IT 투자의 우선순위를 함께 판단할 수 있게 됩니다.
3단계: 에러 버짓으로 우선순위 결정
SLO를 정해도 한 가지 문제가 남습니다. "지금 새 기능을 배포해도 되나, 안정화에 집중해야 하나?"를 누가, 어떤 기준으로 판단할 것인가입니다. 이때 유용한 개념이 에러 버짓(Error Budget)입니다. 예를 들어 99.9% 가용성 SLO를 약속했다면, 한 달에 허용된 다운타임은 약 43분입니다. 이 43분이 ‘에러 버짓’입니다. 에러 버짓이 소진되면 새 기능 배포를 멈추고 안정화에 집중합니다. 반대로 버짓이 넉넉하면 개발팀은 더 과감하게 실험할 수 있습니다. 이 개념이 중요한 이유는 개발팀과 운영팀의 의사결정 기준을 하나로 통일하기 때문입니다. 이렇게 접근하면 ‘왜 배포를 막느냐’가 아니라 ‘현재 에러 버짓이 얼마 남았느냐’로 대화가 바뀝니다.
에러버짓은 운영팀만 보는 지표가 아닙니다. 경영진 대시보드에도 "에러 버짓 잔여율"로 표시되어, 현재 시스템이 얼마나 여유 있는지 한눈에 파악할 수 있어야 합니다. 실제로 운영팀과 경영진이 보는 대시보드는 같은 데이터에서 출발하되 관점이 달라야 합니다.
운영팀 대시보드 - 빠른 감지와 대응 | 경영진 대시보드 - 의사결정과 투자 근거 |
• CPU·메모리·디스크 사용률
• 실시간 응답시간 및 에러율
• 서비스 간 의존성 맵
• 알림 이력 및 현재 인시던트 상태 | • 서비스별 가용성(SLO 달성률)
• 주간·월간 장애 건수 및 비즈니스 영향(매출 손실·이탈률 등)
• 에러 버짓 잔여율
• 장애 원인 분류(인프라 / 코드 / 외부 의존성) |
위 표처럼 운영팀과 경영진이 각자 필요한 관점에서 데이터를 볼 수 있을 때, 두 조직은 비로소 같은 테이블에서 대화할 수 있습니다.
4. 통합 모니터링이 필요한 이유
서비스별 비즈니스 가치 정의 , SLO와 비즈니스 목표 정렬, 에러 버짓 기반 우선순위 결정 등 지금까지 설명한 3단계 프레임워크가 작동하려면 한 가지 전제가 필요합니다. IT 환경 전체의 데이터가 한 곳에 있어야 한다는 것입니다. 온프레미스 DB의 응답 지연이 클라우드 앱의 에러율로 이어지고, 그것이 사용자 경험 저하로 이어지는 흐름을 추적하려면 각 레이어의 데이터가 단절 없이 연결되어야 하기 때문입니다. 도구가 분산되어 있으면 원인 파악에 시간이 걸리고, 그 시간이 MTTR을 늘립니다.
exemONE(엑셈원)은 네트워크·서버·애플리케이션·사용자 경험까지 레이어 전체를 단일 플랫폼에서 모니터링할 수 있도록 설계되어 있습니다. 운영팀 대시보드와 경영진용 요약 뷰를 역할에 맞게 구성할 수 있으며, AI 기반 이상탐지로 비즈니스 영향이 발생하기 전에 선제 대응하는 것도 가능합니다.
이제는 운영 지표를 잘 수집하는 것을 넘어, 그 지표가 매출·이탈률·고객 만족도 같은 비즈니스 결과와 어떻게 연결되는지 보여주는 것이 IT 운영팀의 다음 과제입니다.
IT 인프라 및 비즈니스 KPI를 하나의 플랫폼에서 관리할 수 있는 옵저버빌리티
엑셈원 살펴보기 👉🏻
함께 보면 좋은 아티클
