IT 운영성과측정, 프레임워크보다 무엇을 재는지가 먼저다

IT 시스템에 문제가 생기기 전까지는 아무도 운영 성과에 관심을 갖지 않는다. 장애가 터진 뒤에야 "이게 얼마나 자주 이랬냐"는 질문이 나오고, 그때 가서 지표를 만들면 이미 늦다. 정보시스템 운영성과측정은 결국 이 질문에 미리 답을 준비해두는 작업이다—가용성, 성능, 보안, 비용 네 축에서 IT 서비스가 실제로 어떻게 돌아가고 있는지를 숫자로 남겨두는 일이다.

무엇을 위해 재는가

측정 자체가 목적이 아니다. 실무에서 성과측정이 쓰이는 맥락은 크게 네 가지다. 병목 지점을 찾아 자원 활용을 최적화하고 장애를 미리 막으려는 운영 효율성 관점, SLA 준수 여부와 사용자 만족도를 확인하려는 서비스 품질 관점, IT 투자 대비 효과(ROI)와 총소유비용(TCO)을 관리하려는 비용 관점, 그리고 경영진 보고나 투자 우선순위 결정에 근거를 대려는 의사결정 지원 관점이다. 어떤 지표를 고를지는 이 중 어느 쪽 질문에 답하려는지에 달려 있다—장애 예방이 목표라면 MTBF·MTTR을, 비용 절감이 목표라면 클라우드 마이그레이션 절감액을 봐야지 둘을 뒤섞으면 어느 쪽도 제대로 답하지 못한다.

측정을 하는 이유를 한 겹 더 파고들면 투명성과 책임성이 남는다. IT 운영이 블랙박스로 남으면 문제가 생겨도 원인을 특정하기 어렵고, 서비스 제공자와 사용자 어느 쪽도 책임 소재를 가리기 힘들다. 정기적으로 데이터를 쌓고 PDCA 사이클로 돌리는 것은 이 블랙박스를 걷어내는 과정이다.

프레임워크는 지표를 고르는 틀일 뿐이다

BSC(Balanced Scorecard)는 재무·고객·내부 프로세스·학습과 성장이라는 네 관점을 강제한다. IT 조직에 맞춘 IT-BSC는 이를 기업 기여도·사용자 지향·운영 우수성·미래 준비로 바꿔 쓴다. 두 프레임워크가 하는 일은 결국 하나다—재무 지표(ROI, 예산 준수율) 하나에만 몰두해 사용자 만족도나 기술 부채를 놓치는 일을 막는 것. IT 부서가 비용 절감 숫자만 경영진에게 보고하다가 정작 장애 복구 시간이 늘어나는 걸 놓치는 경우가 이 프레임워크가 막으려는 전형적인 실패다.

여기에 KPI(Key Performance Indicator)가 실제 측정 가능한 단위로 지표를 구체화한다. SMART 원칙—Specific, Measurable, Achievable, Relevant, Time-bound—은 뻔한 원칙처럼 보이지만, "시스템을 안정적으로 운영한다" 같은 목표를 "시스템 가용률 99.9% 이상"으로 바꾸는 실질적 기준이다. "평균 장애 복구 시간 30분 이내", "사용자 만족도 4.5/5.0 이상" 같은 구체적 수치가 KPI의 형태다.

가용성과 성능, 숫자 뒤의 의미

가용률은 다음 공식으로 계산하는 단순한 지표이지만, 목표 등급 사이의 격차는 생각보다 크다.

가용률(%) = (전체 시간 - 장애 시간) / 전체 시간 × 100
``` 일반 시스템의 99%는 연간 3.65일의 다운타임을 허용한다는 뜻이고, 중요 시스템의 99.9%는 8.76시간, 미션 크리티컬 시스템의 99.99%는 52.56분으로 줄어든다. 이 등급을 시스템마다 다르게 매기는 게 핵심이다—모든 시스템에 99.99%를 요구하면 그만큼 비용과 복잡도가 따라오고, 반대로 미션 크리티컬 시스템에 99%를 적용하면 연 사흘 넘는 장애를 감수해야 한다. Uptime, Downtime과 함께 MTBF(평균 고장 간격), MTTR(평균 복구 시간)을 같이 보는 이유는 "얼마나 안 죽는가"와 "죽었을 때 얼마나 빨리 살리는가"가 서로 다른 문제이기 때문이다.

성능 지표는 응답 시간(웹 페이지 2~3초, API 호출 100~500ms, DB 쿼리 10~100ms)과 처리량(TPS, RPS, 동시 사용자 수), 자원 사용률(CPU 평균 50~70%, 메모리 70~80%)로 나뉜다. 이 수치들은 시스템 유형에 따라 기준선이 다르므로 절대값보다는 추세를 보는 편이 실무에 가깝다—어제보다 응답 시간이 늘었는지, 자원 사용률이 임계치에 다가가는지가 알람의 실제 기준이 된다.

보안과 비용 효율성도 같은 축에 들어간다. 보안은 침해 사고 건수, 취약점 발견·조치, 보안 패치 적용률, 비인가 접근 시도 건수, 백업 성공률, 암호화 적용률로 측정하고, 비용은 TCO(하드웨어·소프트웨어 라이선스·유지보수·인건비)와 ROI로 잡는다.

ROI(%) = (이익 - 투자 비용) / 투자 비용 × 100

## SLA는 숫자를 계약으로 바꾸는 장치

SLA(Service Level Agreement)는 서비스 제공자와 고객이 합의한 서비스 수준 약정이다. 서비스 범위(제공 서비스 목록, 24x7 또는 업무 시간, 지원 범위), 성과 목표(가용률 99.9% 이상, 평균 응답 시간 2초 이내, 장애 복구 30분 이내), 책임과 의무, 보고 및 검토 주기로 구성된다. 앞서 살펴본 가용성·성능 지표를 실제로 문서화해 "이 숫자를 못 지키면 어떻게 할지"까지 정해두는 게 SLA의 역할이다.

관리 프로세스는 수립 → 모니터링 → 보고 → 검토/개선의 순환 구조를 갖는다. 서비스 요구사항을 분석해 측정 가능한 지표를 정의하고 목표 수준을 협의해 문서화하는 것이 수립 단계, 실시간 모니터링 도구로 목표 대비 실적을 비교하는 것이 모니터링 단계다. 정기 성과 리포트와 위반 사항·원인 분석이 보고 단계로 이어지고, 정기 검토 회의를 통해 목표 수준을 조정하거나 서비스 개선을 반영하는 것으로 순환이 다시 시작된다.

![diagram 1](img/diagram-01-1f4d356a57e23e30.svg)

## 도구는 계층이 다르다

모니터링·APM·로그 분석은 서로 대체재가 아니라 각기 다른 레이어를 본다. Prometheus+Grafana, Nagios, Zabbix, Datadog 같은 인프라 모니터링 도구는 CPU·메모리·디스크 사용률, 네트워크 트래픽을 추적하고 임계값 알람을 띄운다. New Relic, Dynatrace, AppDynamics, Elastic APM 같은 APM은 한 단계 위에서 사용자 경험과 트랜잭션을 추적해 End-to-End 응답 시간, 오류율, 코드 레벨 성능까지 잡아낸다. ELK Stack, Splunk, Graylog 같은 로그 분석 도구는 장애 원인 분석, 보안 이벤트 탐지, 사용 패턴 분석에 쓰인다. 인프라 모니터링만으로는 "서버는 멀쩡한데 사용자 응답은 느린" 상황을 못 잡고, APM만으로는 왜 그 시점에 그런 일이 벌어졌는지 로그 없이는 재구성하기 어렵다—세 계층을 같이 봐야 하는 이유다.

## 데이터를 쌓은 다음이 진짜 일이다

수집한 데이터는 추세 분석, 이상 탐지, 근본 원인 분석으로 이어진다. 내부 벤치마킹(시스템 간 비교, 기간별 성과 비교)과 외부 벤치마킹(동종 업계 평균, 업계 선도 기업)을 거쳐 개선 기회를 찾고, PDCA 사이클(Plan-Do-Check-Act)로 개선 활동을 표준화한다. CI/CD와 자동화, 피드백 루프 같은 DevOps 문화는 이 사이클을 짧게 돌리기 위한 실천 방식이다.

## 누구에게 보여줄지가 지표 설계를 바꾼다

같은 데이터라도 보는 사람에 따라 필요한 형태가 다르다. 경영진에게는 비즈니스 영향 중심의 간결한 대시보드가, IT 운영팀에게는 상세 기술 지표와 실시간 알람이, 사용자에게는 서비스 품질 정보와 공지사항이 필요하다. 측정 대상을 고를 때도 비즈니스 중요도·고객 영향도·장애 빈도로 우선순위를 매기고, 전사 시스템을 다 볼지 핵심 시스템만 볼지, End-to-End로 볼지 구간별로 쪼갤지를 정해야 한다. 측정 주기도 마찬가지다—중요 시스템은 24x7 실시간 모니터링과 알람이 필요하지만, 경영진 보고는 일일 요약보다 월간·분기 단위가 맞다. 지표 하나를 정하기 전에 "이걸 누가 보고 무슨 결정을 내릴 것인가"를 먼저 물어야 하는 이유다.