ITSM을 도입했는데 왜 운영은 느릴까? AIOps가 필요한 진짜 이유

많은 기업들이 ITSM을 도입한다.
서비스데스크가 있고, 장애 프로세스도 있고, 변경관리 체계도 있다.

 

그런데도 이런 말이 나온다.

• “IT가 왜 이렇게 느리죠?”
• “요청하면 왜 이렇게 오래 걸리나요?”
• “장애 나면 왜 항상 전화부터 돌죠?”

이 질문을 이해해야
IT운영 문제의 본질이 보인다.

---

1️⃣ 기업 IT운영 As-Is의 본질: 프로세스는 있지만 실행은 사람 중심

대부분 기업의 IT운영 흐름은 정돈되어 있다.

• SR 접수 → 배정 → 처리 → 종료
• Incident 접수 → 1차 → 2차 → 3차 대응
• Change 요청 → 영향도 분석 → 개발 → 배포

문제는 이것이다.

이 흐름이 데이터 기반으로 자동 연결되느냐
아니면 사람과 메신저로 이어지느냐다.

 

실제 운영은 이렇게 흘러간다.

 

현업 문의
→ IT/운영부서 정리
→ ITO 수행사 전달
→ 외주·벤더 전달
→ 전화·메신저로 진행 확인
→ 기록은 여기저기 흩어짐

 

겉은 ITSM 프로세스,
속은 사람 의존 구조다.

 

시간이 갈수록 더 무거워진다.

---

2️⃣ SR이 길어질수록 IT부서가 병목이 된다

가장 흔한 구조:

 

현업 → IT운영 → ITO → 벤더

 

SR 하나가 들어올 때마다
IT부서는 “조율자” 역할을 한다.

• 요구 재정리
• 범위 판단
• 담당자 지정
• 결과 재전달

이게 쌓이면 어떻게 될까?

 

IT부서는 전략 조직이 아니라
에스컬레이션 처리 조직이 된다.

---

📌 이력(히스토리)이 흩어지는 구조

SR이 여러 단계를 거치면서

• 메일
• 메신저
• 회의록
• 별도 문서

여기에 기록이 나뉜다.

 

그래서 이런 질문이 반복된다.

• “그때 왜 그렇게 결정했죠?”
• “이건 장애였나요, 변경이었나요?”
• “유사 사례 없었나요?”

운영이 쌓일수록
조직은 기억 의존형 구조가 된다.

---

3️⃣ Silo가 생기면 기술보다 조율이 더 오래 걸린다

운영 지연의 핵심은 기술이 아니다.

누가 할 것인지 정하는 시간이 가장 오래 걸린다.

• 이슈가 어느 영역인지 판단
• 원인 논쟁
• 책임 협의
• 일정 승인

운영은 점점 “조율의 게임”이 된다.

 

Silo가 깊어질수록
운영은 느려진다.

---

4️⃣ 해외 운영은 구조적으로 더 느리다

해외 법인이 있는 기업은 더 복잡하다.

• 시차
• 야간 대응
• 언어 차이
• 원격 제약

결국 이런 일이 벌어진다.

• 수행사는 근무시간에만 대응
• IT부서가 직접 야간 대응
• 결산 시즌에 업무 폭증

 

문제는 인력 부족이 아니다.

정보 부족 + 시간 제약 + 원격 제약이 동시에 발생하는 구조

 

그래서 해외 조직이 더 빠르게 느낀다.

 

“요청해도 늦다.”

---

5️⃣ 역량이 사람에게 붙으면 품질은 흔들린다

또 다른 구조적 문제는 지식 관리다.

• 표준 Runbook 부재
• 유사 사례 재사용 부족
• 지식 자산화 실패

결국 이런 말이 나온다.

• “저 사람이 있어야 된다.”
• “경험자 아니면 못 한다.”

운영 품질이 특정 인력에 종속되면
조직은 항상 리스크 상태다.

---

6️⃣ 공수 산정 불신이 관계를 깨뜨린다

많은 기업이 민감하게 느끼는 지점:

개선 요청 → 추가 계약 요구
그런데 공수 산정 기준은 불명확

 

왜 이런 일이 반복될까?

• 유사 변경 이력 데이터 없음
• 영향도 분석 체계화 부족
• SR / Incident / Change 경계 불명확

그래서 항상 이런 논쟁이 나온다.

• “이건 운영 범위인가?”
• “이건 추가 개발인가?”

결국 기업은 이렇게 느낀다.

기준이 없다.

---

7️⃣ 정리: 기업 IT운영 As-Is의 구조적 특징

• 사람 중심 판단 구조
• SR–Incident–Change 단절
• CMDB와 실제 운영 데이터 분리
• Visibility 부족
• 해외 대응 취약
• 지식 축적 실패
• 공수 산정 불신

이건 노력 부족이 아니다.

구조의 문제다.

---

8️⃣ 그래서 AIOps가 등장한다

여기서 오해가 하나 있다.

AIOps는 모니터링 고도화 기술이 아니다.

 

진짜 목적은 이것이다.

• 이벤트 자동 분류
• 원인 추정
• 표준 Runbook 자동 실행
• 티켓과 지식 연결
• 1선에서 대부분 해결

즉,

운영의 중심을
사람에서 데이터와 자동화로 옮기는 것

---

AIOps의 핵심 구조

진짜 AIOps는 이렇게 연결된다.

 

Observability 데이터
→ 이벤트 상관분석
→ CMDB 연계 영향도 판단
→ 자동 조치 (Runbook 실행)
→ 티켓 자동 생성 및 분류

 

SR·Incident·Change가
하나의 데이터 흐름으로 연결된다.

 

이게 되면 무엇이 달라질까?

• 1선 해결률 상승
• 장애 평균 대응시간(MTTR) 단축
• 공수 산정 기준 명확화
• 야간 대응 자동화
• 지식 자동 축적

---

ITSM은 시작일 뿐이다

많은 기업이 말한다.

 

“우리는 ITSM이 있다.”

 

하지만 ITSM은 프로세스 프레임일 뿐이다.

 

실행을 자동화하지 않으면
결국 사람 중심 구조로 돌아간다.

 

AIOps의 본질은 이것이다.

프로세스를 시스템으로 실행하는 구조

 

2편에서는

• AIOps 적용 후 To-Be 운영 프로세스
• SR·Incident·Change에 AI가 들어가는 지점
• CMDB·Observability·Automation Engine 연결 구조
• 실제 아키텍처 설계 방식

을 기술적으로 풀어보겠다.

 

여기서부터가 진짜 이야기다.