AI 클라우드, 이제 "누가 온콜을 받을지"도 스스로 결정한다 — 인사팀은 그 사실을 직원이 번아웃된 이후에야 알았다

2026년 현재, AI 클라우드 운영 환경에서 조용히 진행 중인 권력 이동이 있다. 서버를 언제 늘릴지, 패치를 언제 적용할지, 어떤 벤더와 계약할지를 AI가 결정하는 것은 이미 여러 차례 다뤄진 주제다. 그런데 최근 들어 더 민감한 영역이 수면 위로 떠오르고 있다. "누가 이 알림을 받을 것인가", 그리고 더 나아가 "누가 이 알림을 받지 않을 것인가"를 AI가 결정하기 시작했다는 점이다.

AIOps, ITSM 자동화, 옵저버빌리티 플랫폼이 결합된 AI 클라우드 운영 도구들은 이제 단순히 이상을 탐지하고 사람에게 알리는 것을 넘어, 누구에게 알릴지 자체를 자율적으로 라우팅한다. 그리고 그 과정에서 어떤 사람은 알림을 너무 많이 받고, 어떤 사람은 아무것도 받지 못한다. 문제는 그 판단이 어떤 기준으로 내려졌는지 아무도 모른다는 것이다.

AI가 "알림 라우팅"을 결정하기 시작한 배경

전통적인 온콜(On-Call) 체계는 단순했다. PagerDuty, OpsGenie 같은 도구에서 팀이 직접 일정과 에스컬레이션 규칙을 설정하고, 특정 알림이 발생하면 정해진 순서대로 담당자에게 연락이 갔다. 거버넌스 관점에서 보면 투명하고 감사 가능한 구조였다.

그런데 AI 클라우드 운영 플랫폼들이 이 구조 안으로 침투하기 시작했다. Dynatrace, Datadog, New Relic, PagerDuty AIOps 같은 도구들은 이제 단순한 임계값 기반 알림을 넘어, 과거 응답 패턴, 담당자 역량 추론, 현재 업무 부하 추정, 사고 유형 분류를 종합해 "이 알림은 A에게, 저 알림은 B에게, 이건 굳이 아무에게도 안 보내도 된다"는 판단을 자동으로 내린다.

Datadog의 공식 문서에서도 확인할 수 있듯, 라우팅 로직은 점점 조건 기반 자동화에서 AI 추론 기반 자동화로 이동하고 있다. 표면적으로는 "알림 피로(Alert Fatigue)"를 줄이기 위한 기능이다. 실제로 알림 피로는 심각한 문제다. 클라우드 운영팀이 하루에 수백, 수천 건의 알림을 받으면서 정작 중요한 신호를 놓치는 사례는 업계에서 흔하다.

하지만 여기서 핵심적인 질문이 발생한다. "어떤 알림을 누구에게 보낼지"를 결정하는 것이 과연 AI가 단독으로 해야 할 판단인가?

조용히 사라지는 인간 거버넌스 레이어

알림 억제(Suppression)가 만드는 블라인드 스팟

AI 클라우드 운영 도구의 알림 라우팅에서 가장 위험한 기능은 역설적으로 가장 유용해 보이는 기능이다. 바로 알림 억제(Noise Suppression)다.

AI는 "이 알림은 반복적으로 발생하지만 실제 서비스 영향이 없었다"는 패턴을 학습해 자동으로 억제한다. 엔지니어링 관점에서는 훌륭한 기능이다. 그런데 문제는 그 억제 판단이 과거 데이터를 기반으로 하기 때문에, 새로운 위협이나 변화된 맥락을 반영하지 못한다는 점이다.

실제로 이런 시나리오가 가능하다. 특정 서비스의 메모리 사용률이 반복적으로 80%를 넘겼지만 항상 자동 해소됐다. AI는 이 패턴을 학습해 관련 알림을 억제하기 시작한다. 그런데 어느 날 인프라 구성이 바뀌면서 같은 패턴이 실제 장애의 전조가 된다. AI는 여전히 억제한다. 팀은 아무것도 받지 못한다. 장애는 고객이 먼저 발견한다.

이 과정에서 컴플라이언스팀은? 아무것도 모른다. 감사 로그에는 "알림 억제됨"이라고만 기록될 뿐, 왜 억제됐는지, 그 결정이 적절했는지를 사후에 검증하기 어렵다.

온콜 배정이 "업무 부하 추론"에 의해 바뀔 때

더 미묘한 문제는 온콜 배정의 동적 변경이다. 일부 AIOps 플랫폼은 담당자의 현재 업무 부하를 추론해 알림을 다른 사람에게 자동으로 재라우팅하는 기능을 제공한다. 예를 들어 "A는 지금 다른 인시던트를 처리 중이니 이 알림은 B에게 보낸다"는 식이다.

표면적으로는 합리적이다. 하지만 이 기능이 지속적으로 작동하면 어떤 일이 생길까?

특정 엔지니어에게 알림이 집중되는 현상이 발생한다. AI가 "A는 항상 빠르게 응답하므로 신뢰할 수 있다"고 학습하면, A는 점점 더 많은 알림을 받게 된다.
다른 엔지니어는 알림에서 배제된다. 학습 기회를 잃고, 숙련도 격차가 벌어진다.
인사팀과 관리자는 이 패턴을 모른다. 온콜 일정표상으로는 균등하게 배정되어 있지만, 실제 알림 수신량은 극도로 불균형하다.

이것이 번아웃의 구조적 원인이 될 수 있다. 그리고 그 원인이 AI의 라우팅 결정이었다는 사실은, 해당 엔지니어가 퇴사한 이후에야 누군가 로그를 뒤지면서 발견하게 될 가능성이 높다.

AI 클라우드 알림 거버넌스의 실제 공백

컴플라이언스는 "누가 알림을 받지 못했는지"를 감사하지 않는다

현재 대부분의 클라우드 보안 감사와 컴플라이언스 체계는 "알림이 발생했는가"와 "알림에 대응했는가"를 확인한다. 하지만 "알림이 올바른 사람에게 갔는가", 그리고 "억제된 알림 중 실제로 중요했던 것은 없는가"를 체계적으로 감사하는 조직은 거의 없다.

이는 SOC 2, ISO 27001, ISMS-P 등 주요 보안 인증 체계에서도 아직 명시적으로 다루지 않는 영역이다. AI가 알림 라우팅을 결정하는 시대에 맞는 감사 기준이 아직 마련되지 않은 것이다.

결과적으로 AI 클라우드 운영 도구가 내린 라우팅 결정이 잘못됐더라도, 그 잘못을 발견하는 시점은 대개 사고 이후, 또는 감사 이후다.

"정책 범위 내 실행"이라는 면피 논리의 한계

AI 클라우드 도구 벤더들은 흔히 "모든 자동화는 사용자가 설정한 정책 범위 내에서만 실행된다"고 말한다. 맞는 말이다. 하지만 그 정책을 최초에 설정한 것은 엔지니어링팀이고, 그 정책이 인사팀, 법무팀, 컴플라이언스팀의 검토를 거쳤을 가능성은 낮다.

"알림 피로를 줄이기 위해 반복 알림을 억제한다"는 정책은 엔지니어링 관점에서 완전히 합리적이다. 하지만 그 정책이 특정 보안 이벤트의 알림까지 억제할 수 있다는 사실, 그리고 그 억제 결정이 AI의 학습 결과에 따라 동적으로 변한다는 사실은 초기 정책 설정 시점에 충분히 검토되지 않는 경우가 많다.

냉장고에 Gemini를 심으면 무슨 일이 생기나: Samsung Bespoke AI Fridge가 던진 진짜 질문에서 다뤘듯, AI가 일상의 결정 구조 안으로 들어올 때 우리가 진짜 질문해야 할 것은 기능의 편리함이 아니라 그 결정의 책임 소재다. 클라우드 운영도 다르지 않다.

실무에서 바로 적용할 수 있는 대응 방안

1. 알림 라우팅 결정을 "감사 가능한 로그"로 분리하라

AI 클라우드 운영 도구의 알림 라우팅 결정 로그는 단순한 시스템 로그와 분리해서 관리해야 한다. 특히 다음 세 가지 항목은 별도로 추적해야 한다.

억제된 알림 목록: 어떤 알림이 억제됐고, AI가 억제를 결정한 근거는 무엇인가
재라우팅 이력: 원래 수신자가 아닌 다른 사람에게 알림이 전달된 경우, 그 이유는 무엇인가
알림 수신 분포: 팀원별 실제 알림 수신량이 온콜 일정과 얼마나 일치하는가

이 데이터를 월간으로 리뷰하는 것만으로도 AI의 라우팅 결정이 만들어내는 편향을 조기에 발견할 수 있다.

2. "억제 정책"은 엔지니어링팀 단독으로 설정하지 마라

알림 억제 정책은 단순한 기술 설정이 아니다. 어떤 이벤트를 알리지 않을지를 결정하는 것은 보안, 컴플라이언스, 운영 리스크 전반에 영향을 미친다. 최소한 다음 절차를 거쳐야 한다.

억제 대상 알림 유형에 대한 보안팀 리뷰
규제 관련 이벤트(접근 실패, 권한 변경 등)는 억제 대상에서 명시적으로 제외
억제 정책 변경 시 변경 관리(Change Management) 프로세스 적용

3. 온콜 배정의 "실제 부하"를 주기적으로 검증하라

공식 온콜 일정과 실제 알림 수신량을 비교하는 리포트를 분기별로 생성하라. 특정 엔지니어에게 알림이 집중되고 있다면, 그것이 AI의 라우팅 결정 때문인지 확인해야 한다. 이는 단순한 운영 효율의 문제가 아니라 팀 문화와 인력 유지(Retention)에 직결되는 문제다.

4. "Human-in-the-Loop"를 알림 억제 결정에 재도입하라

AI가 새로운 억제 패턴을 학습하거나, 기존 억제 규칙을 변경하려 할 때 자동 승인 대신 인간 검토 단계를 삽입하는 것을 고려해야 한다. 모든 알림 억제 결정을 사람이 검토할 수는 없지만, 최소한 "새로운 유형의 알림을 처음 억제하려 할 때"는 담당자의 확인을 받는 구조가 필요하다.

이 문제가 앞으로 더 커질 수밖에 없는 이유

AI 클라우드 운영 도구의 자율성은 앞으로 더 높아질 가능성이 크다. 벤더들은 "더 적은 알림 피로, 더 정확한 라우팅"을 경쟁적으로 내세우며 AI의 자율 결정 범위를 확장하고 있다. 그리고 조직은 그 편리함을 쉽게 거부하기 어렵다.

하지만 알림 라우팅은 단순한 운영 효율의 문제가 아니다. 이것은 "누가 무엇을 알아야 하는가"라는 조직의 정보 흐름 구조, 책임 체계, 그리고 궁극적으로 사람의 문제다. AI가 이 결정을 조용히 가져가도록 내버려 두면, 조직은 어느 순간 "왜 우리는 그것을 몰랐는가"라는 질문에 답하지 못하는 상황에 처하게 된다.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그 도구가 "누가 무엇을 알아야 하는가"를 결정하기 시작한다면, 우리는 도구를 더 잘 쓰는 것이 아니라 도구에 의해 관리되는 것이다.

AI 클라우드 운영의 자동화는 계속될 것이다. 그렇다면 그 자동화가 만들어내는 정보의 흐름을, 그리고 그 흐름에서 배제되는 사람을, 우리가 의식적으로 설계해야 한다. 그것이 기술 거버넌스의 본질이고, 지금 클라우드 운영팀이 가장 먼저 물어야 할 질문이다.

관련 주제: AI 클라우드 자동화 거버넌스, AIOps, ITSM 자동화, 온콜 관리, 알림 피로, 클라우드 운영 책임 체계

결론: AI가 "침묵"을 선택할 때, 조직은 무엇을 잃는가

알림 라우팅의 AI 자동화가 만들어내는 가장 위험한 결과는 시스템 장애나 보안 사고가 아니다. 그것은 조직이 자신이 무엇을 모르는지조차 모르게 되는 상태다.

패치 관리, 네트워크 설정, 데이터 파이프라인, 재해 복구—이 시리즈에서 다뤄온 모든 영역에서 AI의 자율 결정이 만들어내는 거버넌스 공백의 공통점이 하나 있었다. 바로 "사후 인지(Post-facto Awareness)"다. 팀은 항상 무언가가 이미 일어난 뒤에야 알게 된다.

알림 라우팅은 그 공백의 가장 상류(upstream)에 위치한다. 다른 모든 자동화 결정들이 인간에게 도달하는 통로가 바로 알림이기 때문이다. AI가 패치를 자율 적용했을 때, 그것을 운영팀에게 알리는 것도 알림 시스템이다. AI가 보안 정책을 수정했을 때, 보안팀이 인지하는 경로도 알림이다. 그런데 그 알림 자체를 AI가 "필요 없다"고 판단해 억제해버린다면, 다른 모든 거버넌스 장치는 사실상 작동하지 않는 것과 같다.

이것은 단순한 기술 문제가 아니다. AI가 조직의 신경계를 재배선하고 있는 것이다.

지금 당장 물어야 할 세 가지 질문

이 글을 읽는 독자가 클라우드 운영팀의 리더든, CTO든, 아니면 온콜 일정을 직접 소화하는 엔지니어든 간에, 오늘 당장 다음 세 가지를 확인해보길 권한다.

첫째, 우리 조직의 AIOps/ITSM 도구는 지난 30일간 몇 건의 알림을 억제했는가? 이 숫자를 모른다면, 그것 자체가 이미 거버넌스 공백이다. 억제된 알림의 목록을 뽑아보는 것이 출발점이다. 놀랍게도 많은 조직에서 이 숫자를 정기적으로 추적하지 않는다.

둘째, 억제된 알림 중 보안 또는 컴플라이언스 관련 이벤트가 포함되어 있는가? 접근 실패, 권한 변경, 정책 위반 시도—이런 이벤트들은 "노이즈"처럼 보여도 억제해서는 안 된다. AI가 이것들을 "반복적이고 낮은 우선순위"로 분류해 조용히 묻어버리고 있다면, 다음 감사에서 그 청구서가 날아올 것이다.

셋째, 온콜 담당자가 아닌 사람에게 라우팅된 알림이 있는가? 혹은 아무에게도 가지 않은 알림이 있는가? "아무도 받지 않은 알림"은 시스템 로그에는 존재하지만 조직의 인식에는 존재하지 않는다. 그것이 쌓이는 곳에 다음 인시던트가 자라고 있다.

자동화는 계속된다. 거버넌스 설계도 함께 진화해야 한다

2026년 현재, 클라우드 운영의 자동화는 되돌릴 수 없는 방향으로 흘러가고 있다. AIOps 플랫폼 시장은 매년 두 자릿수 성장을 이어가고 있고, 벤더들은 경쟁적으로 "더 적은 알림, 더 스마트한 라우팅, 더 빠른 자동 해결"을 약속하고 있다. 그 방향 자체를 막을 수도 없고, 막아야 할 이유도 없다.

하지만 자동화가 빨라질수록, 거버넌스 설계는 더 의식적으로 이루어져야 한다. 도구가 스스로 결정하는 범위가 넓어질수록, 인간이 설계해야 하는 경계선도 더 명확해져야 한다. 이것은 AI를 불신하자는 이야기가 아니다. AI가 더 잘 작동하도록, 그리고 그 작동의 결과가 조직 전체에 투명하게 보이도록, 우리가 더 잘 설계해야 한다는 이야기다.

우리가 직면한 문제를 해결하는 것은 결국 기술이 아니라 그 기술을 어떻게 설계하고 운영하는가에 달려 있다. AI가 "누가 무엇을 알아야 하는가"를 결정하는 시대에, 그 결정의 구조를 설계하는 것은 여전히 인간의 몫이다.

그리고 그 설계를 지금 시작하지 않는다면, 다음 감사에서, 다음 장애에서, 다음 보안 사고에서—우리는 또 한 번 같은 질문을 받게 될 것이다.

"왜 아무도 몰랐습니까?"

그때 가서 "AI가 알림을 억제했습니다"라는 답변이 면죄부가 되지 않는다는 것을, 지금 우리는 이미 알고 있다.

이 글은 AI 클라우드 자동화가 조직의 거버넌스 구조에 미치는 영향을 다루는 시리즈의 일환입니다. 이전 글에서는 패치 관리, 네트워크 설정, 데이터 파이프라인, 재해 복구, 용량 계획, 데이터 수명주기 관리 영역에서의 거버넌스 공백을 다루었습니다.

태그: AI 클라우드 자동화, AIOps, ITSM, 알림 라우팅, 온콜 거버넌스, 클라우드 운영, 알림 피로, 인시던트 관리, 컴플라이언스

NOCODE TECH STACKER