AI 에이전트, 도입보다 운영이 더 어려운 이유
최근 다양한 산업에서 'AI 에이전트' 도입 검토가 빠르게 늘고 있습니다. IT 운영 분야도 예외가 아닙니다. 단순한 사내 챗봇을 넘어, 알림을 분류하고 인시던트 원인을 추적하며 복구 절차까지 제안하는 형태의 에이전트가 본격적으로 등장하고 있습니다. 이 변화와 함께 운영팀 안에서는 새로운 질문이 생기고 있습니다. 자동화가 잘못 작동했을 때 책임은 누가 지는가. 이 질문에 대한 기준이 명확하지 않은 상태에서 도입이 먼저 이뤄지는 경우도 적지 않기 때문입니다.
주요 모니터링·옵저버빌리티 솔루션과 ITSM 도구는 알림 분류, 인시던트 원인 분석, 자동 복구 루프까지 AI 에이전트 기능을 차례로 추가하고 있습니다. 운영 업무의 어느 지점에 에이전트를 활용할 수 있는지 참고할 사례도 빠르게 쌓이고 있습니다. 그러나 정작 어려운 부분은 그다음 단계입니다. 사람이 직접 챙겨야 하는 영역과 에이전트에 맡길 수 있는 영역을 어떻게 나눌지가 도입 결과를 좌우하기 때문입니다.
Gartner는 에이전트형 AI 프로젝트의 40% 이상이 2027년 말까지 시범 운영을 넘기지 못하고 무산될 것이라고 분석했습니다. 프로젝트가 무산되는 이유가 기술 문제만은 아니라는 점은 DORA 2025 보고서에서도 확인됩니다. 운영 체계가 잘 잡힌 팀은 AI로 더 큰 효과를 보지만, 그렇지 않은 팀은 AI 때문에 약점이 더 빨리 드러난다는 것이 보고서의 결론입니다. 도입 자체보다 도입 이후의 운영이 결과를 가른다는 의미입니다.
이 글에서는 AI 에이전트가 IT 운영에서 자동화할 수 있는 영역과 사람이 직접 챙겨야 하는 영역의 경계를 정리합니다. AI 에이전트 도입을 검토 중이거나 이미 운영 중인 팀이라면, 이 경계를 먼저 그려 두는 것이 시행착오를 줄이는 출발점이 될 수 있습니다. 최근 공식 발표된 자료를 기준으로 함께 살펴보겠습니다.
1. AI 에이전트로 자리 잡은 자동화 영역
IT 운영 솔루션 기업들이 올해 공개한 자료를 모아 보면, AI 에이전트가 실제 운영에서 다루는 업무는 크게 세 가지로 좁혀집니다.
1. 알림 분류와 우선순위 조정 - 노이즈가 많은 알림을 묶고 우선순위를 매기는 영역
2. 인시던트 원인 분석과 가설 도출 - 텔레메트리·변경 이력·토폴로지를 함께 보고 후보 원인을 추리는 영역
3. 사람 검토를 거치는 자동 복구 루프 - 운영 매뉴얼 실행과 수정 코드 제안, 승인 후 적용 영역
세 영역은 자동화 정도가 다르고, 운영팀이 직접 챙겨야 하는 비중도 다릅니다.
1-1. 알림 분류와 우선순위 조정
알림 분류는 운영팀이 매일 가장 많은 시간을 쓰는 영역이지만, 알림 자체에는 반복적이고 규칙적인 패턴이 많습니다. 같은 유형의 이벤트가 반복되거나, 하나의 장애가 여러 알림으로 쪼개져 발생하는 경우가 많기 때문입니다. 이런 특성 때문에 알림 분류와 우선순위 조정은 AI 에이전트가 IT 운영 자동화에서 가장 먼저 자리를 잡은 영역입니다.
주요 ITSM 솔루션의 AI 에이전트는 알림을 평문으로 요약해 운영자가 맥락을 곧바로 파악하도록 돕는 구조를 갖췄습니다. 솔루션 기업들의 자체 발표에 따르면, 특정 환경에서는 알림 노이즈를 최대 99%까지 줄이고 평균 해결 시간(MTTR)을 약 40% 단축한 사례도 보고되고 있습니다. 다만 이러한 수치는 최적화된 운영 환경을 전제한 것으로, 도입 초기나 알림 정책이 정비되지 않은 환경에서는 체감 효과가 다를 수 있습니다.
옵저버빌리티 영역에서도 알림 상관 분석을 자동화하고, 여러 알림을 하나의 그룹으로 묶어 영향 범위와 추정 원인을 함께 보여주는 기능이 빠르게 확산되고 있습니다. 결국 알림 분류 자동화의 핵심은 단순히 알림 개수를 줄이는 데 있지 않습니다. 운영자가 지금 어떤 알림을 먼저 봐야 하는지, 어떤 알림이 같은 원인에서 나온 것인지, 어떤 상황이 실제 서비스 영향으로 이어질 수 있는지를 더 빨리 판단하도록 돕는 데 있습니다.
1-2. 인시던트 원인 분석과 가설 도출
원인 분석은 알림 분류보다 한 단계 어려운 영역입니다. 메트릭·로그·트레이스 같은 여러 종류의 텔레메트리에 변경 이력과 서비스 토폴로지까지 함께 봐야 비로소 의미 있는 가설이 나오기 때문입니다.
주요 옵저버빌리티 솔루션은 수천 건의 실제 인시던트를 기반으로 개발·평가된 AI 에이전트가 근본 원인 식별 시간을 크게 줄일 수 있다고 설명합니다. 일부 솔루션은 근본 원인을 90% 더 빠르게 찾는다는 자체 검증 수치를 제시하고 있으며, 인시던트 관리 도구 영역에서도 자동 진단과 맥락 수집을 통해 수동 조사에 쓰이는 시간을 줄이는 방향으로 기능이 고도화되고 있습니다. APM과 옵저버빌리티 클라우드 영역 역시 같은 흐름에서 AI 트러블슈팅 에이전트를 추가하고 있으며, 이는 원인 분석에서 에이전트가 보조 역할을 맡는 비중이 빠르게 늘고 있는 것을 의미하기도 합니다.
다만 원인 분석 영역에서 에이전트의 역할은 정답을 확정하는 것이 아니라, 가능한 원인과 그 근거를 빠르게 제시하는 데 가깝습니다. 어떤 가설을 채택할지, 어떤 조치로 옮길지, 해당 조치가 서비스에 미칠 영향은 무엇인지는 여전히 운영자가 판단해야 합니다. 결국 이 영역의 핵심은 사람을 대체하는 것이 아니라, 사람이 더 빠르고 일관되게 판단할 수 있도록 조사 범위와 가설을 좁혀주는 데 있습니다.
1-3. 사람 검토를 거치는 자동 복구 루프
복구 영역은 자동화가 가장 조심스럽게 다뤄지는 부분입니다. 주요 클라우드 사업자가 공개한 SRE 에이전트의 워크플로우가 현재의 표준 구조를 잘 보여줍니다. 에이전트가 인시던트를 분석하면 결과가 이슈 트래커로 자동 등록되고, 코드 어시스턴트가 그 이슈에 수정 코드 후보를 제안합니다. 사람이 코드를 검토하고 승인한 다음에야 운영 환경에 반영되는 구성입니다.
인시던트 관리 도구 영역에서 공개된 SRE 에이전트도 흐름은 같습니다. 진단·맥락 수집·조치 제안까지는 자동으로 진행되지만, 실제 실행은 사람 승인을 거친 뒤에 이뤄지도록 기본 설정되어 있습니다.
자동화된 부분은 가설과 절차입니다. 결정과 책임은 여전히 사람이 가지고 있습니다. 자동화 범위를 어디까지 열어둘지는 도입 초기에 가장 먼저 정해야 하는 기준입니다.
자동화를 설계할 때 참고할 원칙
처음부터 사람 검토 없이 완전 자동화로 구성하면, 사고 발생 시 책임 추적이 어려워집니다. 도입 초기에는 가설 도출까지만 자동화하고 실행은 사람 승인으로 유지한 뒤, 에이전트의 판단 정확도가 안정된 다음 단계적으로 자동화 범위를 넓혀가는 방식이 실제 운영에서 검증된 접근입니다.
2. 운영팀이 직접 다뤄야 하는 영역
AI 에이전트가 자동화로 다루지 못하는 영역도 함께 드러나고 있습니다. Gartner는 수천 개의 벤더가 에이전트형 AI 기능을 표방하고 있지만, 실제 에이전트 기능을 갖춘 곳은 약 130곳에 그친다고 분석했습니다. Gartner가 이 현상을 설명할 때 사용한 표현이 “agent washing”입니다. 기존 챗봇이나 RPA, AI 어시스턴트를 에이전트라는 이름으로 다시 포장하는 시장 흐름이 도입 기업의 판단을 어렵게 만들고 있다는 진단입니다.
도입 속도와 신뢰 사이의 격차도 수치로 확인됩니다. DORA 2025 보고서에 따르면 기술 전문가의 90%가 업무에 AI를 사용하고, 80% 이상이 생산성 향상을 느낀다고 답했습니다. 반면 AI가 생성한 코드에 대해 신뢰가 낮거나 거의 없다고 답한 비율도 30%에 달했습니다. 도입은 빠르게 늘고 있지만, 결과를 검증하는 책임은 여전히 사람에게 남아 있다는 뜻입니다.
운영팀이 직접 다뤄야 하는 일은 대체로 다음 네 가지 영역에 모입니다.
운영팀이 직접 다루는 영역 | 이유 |
비즈니스 맥락 판단 | 같은 장애라도 영향받는 고객 세그먼트, 매출 시점, 계약 SLA에 따라 우선순위가 달라집니다.
에이전트는 텔레메트리는 잘 보지만, 비즈니스 맥락은 조직이 직접 정의해야 합니다. |
권한과 책임 | 운영 권한 변경, 보안 정책 적용, 외부 시스템에 영향을 주는 변경은 책임 추적이 필요합니다.
에이전트가 직접 수행할 경우 승인 절차와 책임 구조가 명확해야 합니다. |
처음 보는 장애 패턴 | 에이전트는 학습 데이터에 있는 패턴에 강합니다. 신규 아키텍처 도입이나
새로운 연동 추가 이후처럼 장애 이력이 없는 영역에서는 사람이 가설을 처음부터 잡아야 합니다. |
에이전트 자체의 신뢰성 | 에이전트가 잘못 판단하거나 환각을 일으키는 빈도는 0이 아닙니다.
에이전트의 결정을 다시 검증할 수 있는 절차가 운영 체계 안에 있어야 합니다. |
자동화가 빠르게 늘어난다고 해서 자율 운영이 곧바로 가능해지는 것은 아닙니다. 오히려 에이전트가 다루는 영역과 사람이 직접 책임져야 하는 영역의 경계가 더 중요해지고 있으며, 그 경계를 정하는 일이 운영팀의 새로운 역할로 떠오르고 있습니다.
3. IT 운영팀이 새롭게 신경 써야 하는 일
그렇다면 운영팀의 일이 줄어드는 것일까요? 결론부터 말하면, 줄어든다기보다 종류가 바뀌는 흐름에 가깝습니다. 에이전트가 알림 분류와 1차 가설 도출을 자동으로 처리하는 만큼, 사람은 가설을 검증하고 자동화의 안전 범위를 설계하는 쪽으로 일의 무게중심이 옮겨가는 구조입니다. Google이 공개한 SRE 운영 표준 지침에서도 SRE의 역할이 장애가 난 뒤 수습하는 일에서, 장애가 생기더라도 서비스가 빠르게 정상으로 돌아오도록 미리 준비하는 일로 바뀌고 있다는 겁니다.
AI 에이전트가 일상이 된 운영 환경에서, 운영팀이 새롭게 신경 써야 하는 일은 크게 세 가지입니다. 에이전트가 만든 결과를 검증하는 일, 에이전트가 참고할 자료를 준비하는 일, 그리고 자동화의 안전 기준을 정하는 일입니다.
3-1. 에이전트가 만든 결과를 검증하는 일
에이전트가 자동으로 만든 가설과 조치 제안이 실제로 맞는지 검증하는 책임은 사람의 몫으로 남습니다. 앞서 살펴본 SRE 에이전트의 검증 흐름이 대표적인 사례입니다. 에이전트가 만든 수정 코드 후보가 이슈 트래커로 올라오면, 사람이 검토하고 승인한 다음에야 실제 코드에 반영됩니다. 검증이 빠지면 에이전트의 잘못된 판단이 그대로 운영에 들어갈 수 있어, 사람의 확인이 자동화의 안전장치 역할을 합니다.
검증 단계에서 운영팀은 주로 다음 항목을 확인합니다. 에이전트가 참고한 텔레메트리가 충분한지, 가설이 다른 가능성을 충분히 배제했는지, 조치가 미치는 영향 범위가 분명한지, 비슷한 변경이 과거에 어떤 결과를 냈는지를 함께 살펴봐야 합니다.
3-2. 에이전트가 참고할 자료를 준비하는 일
에이전트가 만든 결과 검증이 마무리 되었다면, 이번엔 그 결과의 품질을 결정하는 자료를 준비해야 합니다. 즉 에이전트가 좋은 가설을 내놓으려면, 에이전트가 참고할 수 있는 자료가 잘 정리되어 있어야 합니다. 어떤 운영 데이터를 에이전트에 보여줄지, 어떤 매뉴얼을 검색 가능한 형태로 정리할지, 어떤 과거 장애 이력을 참고 자료로 제공할지 결정하는 일이 운영팀이 새로 신경 써야 하는 부분입니다.
이 작업은 운영팀이 평소에 해 오던 일과 맞닿아 있습니다. 운영 매뉴얼(런북) 작성, 장애 사후 보고서 정리, 자산 관리 데이터(CMDB) 정비, 서비스 구조도 문서화는 IT 운영의 기본 업무로 이미 자리 잡은 항목입니다. 달라진 부분은 이 자료가 사람만 보는 형태에서 그치지 않고, 에이전트가 읽고 활용할 수 있는 구조로 다듬어져야 한다는 데 있습니다. 문서를 어디에 보관할지, 어떤 태그를 붙여 분류할지, 누구에게 접근 권한을 줄지를 함께 정해야 합니다. 특히 에이전트가 민감한 운영 데이터에 어디까지 접근할 수 있도록 할지 범위를 정하는 일은 보안 관점에서도 중요합니다.
핵심은 에이전트가 알아서 똑똑해지지 않는다는 점입니다. 운영팀이 축적해 온 도메인 지식과 장애 이력이 곧 에이전트의 답변 품질을 좌우합니다. 자료가 정리되지 않은 환경에서는 어떤 도구를 들여놓아도 같은 한계에 부딪힐 수밖에 없습니다.
3-3. 자동화 안전 기준을 정하는 일
자동화에는 잘못된 설정, 통제되지 않은 자동 복구, 검증되지 않은 변경이 운영 환경에 그대로 반영될 수 있다는 위험이 함께 따라옵니다. SRE 관점에서 보더라도 자동화는 반복 작업을 줄이는 중요한 수단이지만, 모든 운영 절차를 완전히 대체할 수는 없습니다. 장애 상황의 맥락을 해석하고 조치의 영향 범위를 판단하며 최종 실행 여부를 결정하는 일은 여전히 사람의 몫으로 남습니다.
따라서 운영팀은 에이전트가 어떤 조건에서 어디까지 자동으로 실행할 수 있는지 안전 기준을 미리 정해야 합니다. 기준은 크게 세 가지로 나눌 수 있습니다.
- 자동 복구를 실행할 수 있는 시간대: 대규모 트래픽 시간대나 주요 배포 직후에는 사람 승인 없이 자동 조치가 실행되지 않도록 제약을 둡니다.
- 자동 변경이 가능한 자원의 범위: 어떤 서버, 서비스, 설정, 정책까지 자동으로 변경할 수 있는지 범위를 명확히 규정합니다.
- 사람 승인 없이 진행할 수 있는 변경 유형의 한계: 멱등성, 즉 같은 동작을 여러 번 실행해도 결과가 같도록 보장되는 변경과 그렇지 않은 변경을 구분해 기준을 정합니다.
이 기준을 미리 정해 두는 일은 운영팀의 새로운 역할로 들어왔습니다. 결국 운영팀의 일은 줄어든 것이 아니라, 가설 검증과 안전 기준 설계로 한 단계 위로 올라갔다고 봐야 합니다.
4. 국내 IT 운영 환경의 변화
여기까지가 글로벌 솔루션 자료를 기준으로 본 흐름이라면, 국내 IT 운영 환경에서도 같은 방향의 움직임이 이어지고 있습니다. AI 에이전트 도입을 검토하는 국내 IT 운영팀 입장에서는 기술 흐름만큼 제도 변화도 함께 파악해 두어야 합니다. 특히 제도·정책 영역의 변화가 두드러집니다.
- AI 기본법(인공지능 발전과 신뢰 기반 조성 등에 관한 기본법) 시행: 2026년 1월부터 시행된 AI 기본법은 고영향 AI 사업자의 의무, 영향 평가, 투명성 확보 등을 규정하고 있습니다. IT 운영에 활용하는 에이전트가 고영향 AI 범주에 해당하는지, 운영 데이터와 의사결정 과정에 어떤 책임 기준을 적용해야 하는지 미리 확인해 둘 필요가 있습니다.
- 행정망 AI 도입: 보안 우려로 인터넷망 중심에 머물렀던 AI 활용이 행정 내부망으로 확대되고 있습니다. 공공 IT 운영팀은 내부망에서의 AI 활용 범위, 운영 데이터 취급 기준, 접근 권한 관리 방식을 별도로 정비해야 하는 시점입니다.
- 금융권 AI 가이드라인: 금융위원회가 제시한 원칙 중 IT 운영팀에 특히 시사하는 부분은 “현 단계에서 AI는 업무의 보조수단이며, 최종 의사결정과 책임은 임직원이 수행해야 한다”는 항목입니다. 금융기관 IT 운영팀은 AI 활용 결과에 대한 감사 추적 체계와 책임 소재를 미리 정리해 두어야 합니다.
세 가지 변화가 가리키는 방향은 같습니다. AI 에이전트 도입 자체보다 운영 절차, 데이터 통합, 접근 권한, 책임 추적을 먼저 정리해 두는 쪽이 결국 성과로 이어진다는 결론입니다.
5. 도입 검토를 시작하기 전에
지금까지 살펴본 알림 분류·원인 분석·복구 루프 자동화는 AI 에이전트가 IT 운영에 들어오는 첫 시작입니다. 동시에 운영팀이 직접 다뤄야 하는 영역과 새롭게 신경 써야 하는 일도 함께 늘어나고 있습니다. AI 에이전트 도입을 검토 중이라면, 어느 영역부터 자동화를 적용할지, 어느 영역은 사람이 검증할지 먼저 정리해 두는 것이 시행착오를 줄여 줍니다.
도입 검토 단계에서 빠지기 쉬운 부분이 운영 데이터의 통합입니다. AI 에이전트가 좋은 가설을 내려면 DB·APM·인프라·로그 데이터가 한곳에 모여 있어야 하기 때문입니다. 모니터링 도구가 영역별로 흩어져 있는 환경에서는, 에이전트 도입에 앞서 통합 관제 구조부터 먼저 정리해 두는 작업이 필요합니다. 다만 데이터를 한곳에 모으는 것만으로 충분하지는 않습니다. 앞서 살펴본 것처럼 런북, 장애 이력, 서비스 구조도 같은 자료가 에이전트가 읽고 활용할 수 있는 형태로 정리되어 있어야 통합의 효과가 살아납니다.
도입 검토에 앞서 다음 항목을 점검해 두면 시행착오를 줄이는 데 도움이 됩니다.
- 알림 노이즈가 줄지 않고 운영팀의 시간을 소모하고 있는가?
- 인시던트 원인 분석이 특정 담당자에게 의존하여, 담당자가 자리를 비우면 분석이 멈추는가?
- DB·APM·인프라·로그 모니터링이 분산되어 통합 관제가 어려운가?
- 장애 이력과 운영 매뉴얼이 정리되지 않아, 에이전트가 참고할 자료가 부족한가?
해당되는 항목이 있다면, 자동화 도구 비교에 앞서 자동화 범위 설계와 운영 데이터 통합 구조를 먼저 검토 일정에 넣어두는 것이 좋습니다. 도입보다 운영이 더 어렵다는 것은 이미 글로벌 사례와 국내 제도 변화가 함께 가리키는 방향입니다.
출처
"Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027" - Gartner (2025.06.25) 2025 DORA State of AI-assisted Software Development - Google Cloud / DORA (2025) Now Assist for IT Operations Management 데이터시트 - ServiceNow Datadog Launches Bits AI SRE Agent to Resolve Incidents Faster - Datadog (2025.12.02) Agentic DevOps: Evolving software development with GitHub Copilot and Microsoft Azure - Microsoft Azure Introducing Event iQ: Smarter Event Correlation in Splunk IT Service Intelligence (ITSI) - Splunk 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 - 국가법령정보센터 정부 행정망에서도 'AI 챗서비스' 사용 가능해진다 - 대한민국 정책브리핑
함께 보면 좋은 아티클
