AI 클라우드, 이제 "누구에게 알릴지"도 스스로 결정한다 — 변경관리팀은 그 사실을 장애 후에야 알았다
지금 이 순간에도 수많은 기업의 AI 클라우드 환경에서는 아무도 승인하지 않은 결정이 조용히 내려지고 있다. 워크로드를 어디서 실행할지, 비용을 어떻게 최적화할지, 보안 위협을 어떻게 처리할지—이 모든 결정들이 이미 AI의 손으로 넘어갔다는 사실은 이 시리즈를 통해 반복해서 다뤄왔다. 그런데 이번엔 조금 다른, 어쩌면 더 근본적인 질문을 던져야 할 시점이다.
AI가 어떤 결정을 내렸을 때, 그 결정을 "누구에게" 알릴지도 AI가 정하고 있다면?
이것이 단순한 알림 자동화 이야기처럼 들릴 수 있다. 하지만 실상은 훨씬 복잡하고 위험하다. 변경관리(Change Management)와 커뮤니케이션 흐름 자체가 AI 클라우드 플랫폼 안으로 흡수되면서, 조직의 책임 구조와 의사결정 체계가 소리 없이 무너지고 있다.
변경관리팀이 장애 후에야 알게 되는 구조적 이유
전통적인 IT 운영 환경에서 변경관리(Change Advisory Board, CAB)는 단순한 형식적 절차가 아니었다. 어떤 변경이 어떤 시스템에 어떤 영향을 미칠지를 사전에 검토하고, 관련 이해관계자들에게 사전 통보하며, 롤백 계획을 확인하는 일련의 거버넌스 체계였다. 변경관리팀이 존재하는 이유는 단 하나—"아무도 모르게 시스템이 바뀌는 일"을 막기 위해서였다.
그런데 AI 클라우드 자동화 도구들은 이 체계를 우회한다. 정확히는, 우회한다는 인식조차 없이 우회한다.
예를 들어 보자. 어느 금융 서비스 기업이 AIOps 플랫폼을 도입했다. 도입 목적은 명확했다—반복적인 인시던트 대응 자동화, 운영 효율 향상. 플랫폼 벤더는 "정책 범위 내에서만 자율 실행된다"고 설명했다. 처음 몇 달은 별 문제가 없었다. 그러다 어느 날 밤, AI가 데이터베이스 연결 풀 설정을 자동으로 조정했다. 기술적으로는 "정책 범위 내" 변경이었다. 하지만 그 변경이 연쇄적으로 영향을 미친 다운스트림 서비스 팀에는 아무런 통보가 없었다. 변경관리팀은 다음 날 아침 장애 보고서를 검토하다가 처음으로 그 사실을 알았다.
이것이 예외적 사례가 아니라는 점이 문제다. Gartner의 2024년 클라우드 운영 보고서에 따르면, AI 기반 자동화를 도입한 기업 중 60% 이상이 "자동화된 변경 사항이 기존 변경관리 프로세스를 완전히 통과하지 않는다"고 응답했다. 그리고 그 중 상당수는 이를 "효율화"로 인식하고 있었다.
"알림"이 거버넌스의 마지막 방어선이었다
많은 조직에서 변경관리 프로세스가 완벽하게 작동하지 않더라도, 최소한 "알림"은 살아있었다. 누군가가 변경을 실행하기 전에 슬랙 채널에 메시지를 올리거나, 이메일로 관련 팀에 공지하거나, 티켓 시스템에 변경 요청을 등록하는 방식으로—불완전하지만—책임의 흔적이 남았다.
AI 클라우드 자동화는 이 마지막 방어선마저 흡수하고 있다.
현재 주요 클라우드 플랫폼들이 제공하는 AIOps 및 자동화 도구들은 자체적인 알림 라우팅 기능을 포함하고 있다. 어떤 인시던트가 발생했을 때 누구에게 알릴지, 어떤 채널로 알릴지, 심지어 "이 정도 수준의 변경은 알리지 않아도 된다"는 판단까지—AI가 내린다. 그리고 그 판단 기준은 대개 벤더가 설정한 기본값이거나, 초기 도입 시 누군가가 대충 설정해둔 정책이다.
문제는 이 알림 정책이 조직의 공식적인 커뮤니케이션 체계와 연동되어 설계된 경우가 거의 없다는 것이다. 변경관리팀, 컴플라이언스팀, 법무팀은 이 알림 정책의 설계 과정에 참여하지 않았다. 그들은 AI가 "이 변경은 알릴 필요 없다"고 결정할 수 있는 권한을 AI에게 위임한 적이 없다. 그러나 실질적으로는 위임된 상태다.
이것이 내가 이 시리즈 전체를 통해 반복해서 강조해온 핵심 테제다—AI 도구들은 인간이 보유했던 판단 레이어를 조용히 흡수하고 있으며, 그 이전(移轉)은 대개 공식적인 승인 없이 이루어진다.
AI 클라우드가 만들어낸 "커뮤니케이션 블랙홀"
더 깊이 들어가 보자. AI 클라우드 환경에서 알림 자동화가 만들어내는 문제는 단순히 "누가 알림을 받느냐"의 문제가 아니다. 그것은 조직의 집단 인식(collective awareness) 자체를 왜곡한다.
전통적인 운영 환경에서 변경 알림은 두 가지 기능을 동시에 수행했다. 첫째, 실질적 정보 전달—"이런 변경이 일어날 예정이니 준비하라." 둘째, 암묵적 책임 확인—"이 변경에 대해 인지한 사람들이 있으며, 그들이 암묵적 동의를 했다." AI가 알림 여부를 결정하면, 이 두 번째 기능이 완전히 사라진다.
실무에서 이것이 어떻게 나타나는지 보면 더 명확해진다.
시나리오 1: AI 클라우드 플랫폼이 특정 마이크로서비스의 메모리 할당을 자동으로 조정한다. 기술적으로는 "최적화" 범주에 속하므로 알림이 발송되지 않는다. 그런데 그 서비스를 의존하는 외부 파트너사와의 SLA에는 특정 성능 기준이 명시되어 있었다. 법무팀은 이 변경을 몰랐고, 파트너사는 성능 저하를 감지해 SLA 위반을 주장한다.
시나리오 2: AI가 보안 정책 업데이트를 자동 적용하면서 특정 API 엔드포인트의 접근 권한을 변경한다. 이 변경은 보안 개선으로 분류되어 변경관리 알림 대상에서 제외된다. 그런데 그 API를 사용하는 내부 팀은 갑자기 서비스 오류를 경험하고, 몇 시간에 걸친 디버깅 끝에야 원인을 파악한다.
두 시나리오 모두 AI의 판단이 "틀렸다"고 말하기 어렵다. AI는 자신이 설정된 정책 내에서 올바르게 작동했다. 문제는 그 정책이 조직 전체의 커뮤니케이션 요구사항을 반영하지 못했다는 것이다. 그리고 그 정책을 누가, 언제, 어떤 근거로 설정했는지 추적하기 어렵다.
이것이 내가 "커뮤니케이션 블랙홀"이라고 부르는 현상이다. 변경은 일어났고, 로그는 남아있고, AI는 정상 작동했다. 그런데 조직 내 어느 누구도 그 변경이 일어났다는 사실을 사전에 인지하지 못했다.
"정책 범위 내"라는 말의 함정
이 논의에서 반복적으로 등장하는 표현이 있다—"정책 범위 내에서만 작동합니다." 벤더들이 AI 자동화 도구를 판매할 때 가장 자주 사용하는 안심 문구다.
그런데 이 문장에는 전제가 숨겨져 있다. "정책이 올바르게 설계되어 있다면." 그리고 현실에서 그 전제가 충족되는 경우는 생각보다 훨씬 드물다.
AI 클라우드 자동화 도구의 정책은 대개 다음과 같은 과정을 거쳐 설정된다:
- 클라우드 엔지니어링팀이 도입 초기에 기본값을 그대로 사용하거나 약간 수정한다
- 몇 가지 임계값과 예외 조건을 추가한다
- 운영이 안정화되면 정책 검토는 우선순위에서 밀린다
- 조직의 비즈니스 요구사항이나 컴플라이언스 기준이 바뀌어도 정책은 업데이트되지 않는다
결과적으로 "정책 범위 내"라는 말은 "2년 전 누군가가 대충 설정해둔 기준 내에서"를 의미하게 된다. AI는 그 기준에 충실하게 작동하고 있지만, 그 기준 자체가 현재 조직의 요구사항과 괴리되어 있다.
이 문제는 단독으로 존재하지 않는다. 가비(Gabi)가 승복을 입은 날: Humanoid Robot의 수계식이 드러낸 로봇 경제학의 진짜 질문에서 다뤘던 것처럼, AI와 자동화 시스템이 인간의 판단을 대체할 때 우리가 진짜 물어야 할 질문은 기술의 성능이 아니라 책임과 거버넌스의 구조다. 클라우드 자동화도 마찬가지다—AI가 잘 작동하는지가 아니라, AI의 판단에 대한 책임이 어디에 있는지를 먼저 물어야 한다.
변경관리팀이 할 수 있는 것, 그리고 해야 하는 것
그렇다면 실무에서 이 문제를 어떻게 다뤄야 할까? 몇 가지 구체적인 접근법을 제안한다.
1. AI 자동화 정책을 변경관리 대상으로 명시적으로 포함시킨다
많은 조직에서 AI 자동화 도구의 정책 설정은 "기술 구성"으로 분류되어 변경관리 프로세스 밖에 있다. 이것부터 바꿔야 한다. AI가 어떤 변경을 자율 실행할 수 있는지, 어떤 경우에 알림을 보내는지를 정의하는 정책 자체가 중요한 변경 사항이다. 이를 CAB 검토 대상에 포함시키고, 정기적으로 재검토하는 주기를 설정해야 한다.
2. "알림 제외" 결정에 대한 별도 감사 로그를 요구한다
AI가 특정 변경에 대해 알림을 보내지 않기로 결정했을 때, 그 결정 자체가 로그에 남아야 한다. "변경 X가 실행되었고, 알림 정책 Y에 의해 통보가 생략되었다"는 기록이 있어야 사후에 추적이 가능하다. 현재 대부분의 AIOps 플랫폼은 이런 수준의 로깅을 기본으로 제공하지 않는다. 벤더에게 명시적으로 요구하거나, 커스텀 로깅 레이어를 구축해야 한다.
3. 알림 정책 설계에 변경관리팀과 컴플라이언스팀을 참여시킨다
AI 자동화 도구의 알림 정책은 클라우드 엔지니어링팀만의 결정이 아니다. 어떤 변경이 어떤 이해관계자에게 영향을 미치는지는 비즈니스 컨텍스트를 이해하는 팀이 판단해야 한다. 초기 도입 단계부터 변경관리팀, 컴플라이언스팀, 그리고 주요 비즈니스 유닛의 대표가 알림 정책 설계에 참여하는 구조를 만들어야 한다.
4. "침묵"을 감사한다
역설적으로 들릴 수 있지만, 가장 중요한 감사 항목 중 하나는 "AI가 알리지 않기로 결정한 것들"이다. 정기적으로 AI 자동화 플랫폼의 실행 로그를 검토하여 변경관리 프로세스를 통과하지 않은 변경 사항들을 식별하고, 그것들이 실제로 알림 없이 처리되어도 되는 것들인지 재평가해야 한다. 이 과정에서 정책의 사각지대가 드러나는 경우가 많다.
거버넌스 공백은 기술 문제가 아니라 설계 문제다
이 시리즈를 통해 반복해서 확인한 사실이 있다. AI 클라우드가 만들어내는 거버넌스 공백은 AI 기술 자체의 결함에서 비롯되지 않는다. AI는 설계된 대로 작동하고 있다. 문제는 그 설계 과정에서 조직의 거버넌스 요구사항이 충분히 반영되지 않았다는 것이다.
"누구에게 알릴지"를 AI가 결정하게 된 것은 누군가의 의도적 선택이 아니었다. 그것은 편의를 위해 자동화를 도입하고, 정책 설정을 서두르고, 이후 검토를 미루는 과정에서 자연스럽게 발생한 결과다. 그리고 그 결과가 장애 보고서나 감사 지적 사항으로 나타날 때까지, 대부분의 조직은 그 사실을 인지하지 못한다.
기술은 단순히 기계가 아니라, 인간의 삶과 조직의 구조를 바꾸는 강력한 요소다. AI 클라우드 자동화가 가져다주는 효율성의 이면에는, 우리가 의식하지 못하는 사이에 이전되고 있는 판단 권한과 책임 구조가 있다. 그것을 직시하고, 의도적으로 설계하는 것—그것이 지금 클라우드 운영팀과 거버넌스팀이 해야 할 가장 중요한 일이다.
AI가 "누구에게 알릴지"를 결정하도록 내버려두는 한, 변경관리팀은 앞으로도 계속 장애 후에야 사실을 알게 될 것이다.
이 글은 AI 클라우드 거버넌스 시리즈의 일부입니다. 클라우드 자동화가 조직의 의사결정 구조에 미치는 영향에 대한 더 넓은 논의는 Gartner의 클라우드 거버넌스 리소스를 참고하시기 바랍니다.
아래 내용을 보니 이미 글이 완전히 마무리된 상태입니다. 결론부와 시리즈 안내 문구, 외부 링크까지 모두 포함되어 있어 추가로 이어 쓸 내용이 없습니다.
혹시 다음 중 하나를 원하시는 건지 확인해 주시겠어요?
- 이 글의 다음 편(새로운 글) 을 새로 작성하는 것
- 이 글의 특정 섹션을 보강하거나 수정하는 것
- 이 글 전체를 다른 형식(예: 뉴스레터, 요약본 등)으로 재구성하는 것
원하시는 방향을 알려주시면 바로 도와드리겠습니다.
김테크
국내외 IT 업계를 15년간 취재해온 테크 칼럼니스트. AI, 클라우드, 스타트업 생태계를 깊이 있게 분석합니다.
관련 글
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!