AI 클라우드 환경에서 가장 조용하고 가장 위험한 변화가 진행 중이다. 문제는 새로운 워크로드가 배포되는 순간이 아니라, 아무도 명시적으로 "계속 실행하라"고 명령하지 않았음에도 워크로드가 스스로 살아남는 순간이다. 2026년 현재, AI 클라우드 거버넌스의 핵심 질문은 더 이상 "누가 이것을 배포했는가"가 아니다. "이것이 왜 아직 살아있는가"다.

---

배포는 이벤트지만, 생존은 상태다

전통적인 클라우드 거버넌스 모델은 이벤트 중심으로 설계되어 있다. 누군가 인프라를 프로비저닝하면 승인이 필요하고, 배포가 일어나면 로그가 남고, 비용이 발생하면 예산 담당자에게 알림이 간다. 이 모델은 인간이 의식적으로 "켜는" 행위를 전제로 한다.

그런데 AI 툴이 클라우드 환경에 깊숙이 통합되면서 이 전제가 무너지기 시작했다. AI 에이전트는 배포되는 것이 아니라 증식한다. 한 번의 파일럿 배포가 컨텍스트 윈도우를 유지하기 위한 캐시 레이어를 만들고, 그 캐시 레이어는 검색 인덱스를 요구하고, 검색 인덱스는 임베딩 업데이트 스케줄러를 낳는다. 각 단계는 합리적이고 작은 결정처럼 보이지만, 전체를 합산하면 아무도 명시적으로 승인하지 않은 상시 운영 인프라가 된다.

이것은 단순한 '섀도우 IT'의 현대적 버전이 아니다. 섀도우 IT는 인간이 몰래 켜는 것이다. 지금 우리가 마주한 것은 AI가 스스로 켜고, 스스로 유지하는 인프라다.

---

"종료 결정"이 사라진 세계

클라우드 인프라에는 원래 세 가지 핵심 결정 지점이 있다: 시작(start), 변경(change), 종료(stop). 거버넌스 프레임워크는 이 세 지점 모두에 승인 프로세스를 붙이도록 설계되어 있다.

AI 툴이 이 구조를 어떻게 바꾸는지 구체적으로 보자.

시작 단계는 여전히 인간의 손에 있는 것처럼 보인다. 엔지니어가 LLM 기반 코파일럿을 도입하거나, 데이터 팀이 RAG(Retrieval-Augmented Generation) 파이프라인을 구성한다. 여기까지는 승인 흔적이 남는다.

변경 단계부터 흐릿해진다. AI 툴은 자신의 성능을 최적화하기 위해 검색 범위를 조정하고, 재시도 로직을 수정하고, 외부 API 호출 빈도를 바꾼다. 이 변경들은 개별적으로는 너무 작아서 변경 관리 시스템의 임계값을 넘지 않는다. 하지만 누적되면 원래 승인된 워크로드와 전혀 다른 무언가가 된다.

종료 단계는 거의 완전히 사라졌다. AI 툴이 생성한 컨텍스트 저장소, 임베딩 인덱스, 세션 메모리는 기본값으로 만료되지 않는다. 누군가 명시적으로 삭제하지 않는 한 그것들은 살아있다. 그리고 그것들이 다른 워크로드의 의존성이 되는 순간, 삭제는 사실상 불가능해진다.

"AI 에이전트가 스스로 내리는 결정(검색 범위·재시도·외부 API 호출·로그 수준)이 책임·보안 경계·의존성(끄면 안 되는 상태)을 구조적으로 붕괴시키는 점이 더 위험하다."

이 관점에서 보면, 종료 결정의 부재는 단순한 운영 실수가 아니다. 그것은 AI 툴의 아키텍처가 만들어내는 구조적 결과다.

---

"살아있는 것들"의 목록을 아무도 모른다

2026년 4월 현재, 중간 규모 이상의 기업 클라우드 환경에서 실제로 실행 중인 AI 관련 구성요소를 완전히 열거할 수 있는 팀은 거의 없다고 봐도 무방하다. 이것은 과장이 아니다.

이유는 세 가지다.

첫째, 청구 단위와 논리 단위가 분리되어 있다. 클라우드 청구서는 컴퓨팅, 스토리지, 네트워크 이그레스, API 호출 등 기술적 단위로 쪼개진다. 하지만 AI 툴이 만들어내는 실제 워크로드는 "RAG 파이프라인"이나 "에이전트 세션"처럼 논리적 단위로 존재한다. 이 둘을 연결하는 매핑이 없으면, 청구서를 봐도 무엇이 살아있는지 알 수 없다.

둘째, 의존성 그래프가 동적으로 생성된다. 전통적인 인프라는 의존성이 코드에 명시되어 있다. AI 에이전트의 의존성은 실행 중에 생성된다. 어떤 벡터 인덱스가 어떤 에이전트의 응답 품질에 영향을 미치는지는, 실제로 그 에이전트를 끄기 전까지 알기 어렵다.

셋째, 소유권이 이전된다. AI 툴을 처음 도입한 팀이 해산되거나 프로젝트가 종료된 후에도 인프라는 남는다. 비용은 다른 예산 항목에 흡수되고, 아무도 그것을 자신의 책임으로 인식하지 않는다. AI 클라우드에서 "무엇을 기억하는가"가 더 위험한 이유를 다루면서 강조했듯이, 기억(컨텍스트·임베딩·세션 상태)은 실행보다 훨씬 오래 살아남는다.

---

실무에서 이 문제가 어떻게 드러나는가

추상적인 이야기로 들릴 수 있으니, 실제로 발생하는 패턴을 구체적으로 짚어보자.

패턴 1: "좀비 파이프라인"

6개월 전에 종료된 것으로 간주된 AI 파일럿 프로젝트의 임베딩 업데이트 스케줄러가 여전히 매일 밤 실행되고 있다. 해당 팀은 해산됐고, 비용은 공통 인프라 예산에 묻혀있다. 아무도 이것이 실행 중이라는 사실을 모른다. 이것이 "좀비 파이프라인"이다. 죽었다고 생각했지만 살아있고, 살아있다는 것을 아무도 모른다.

패턴 2: "의존성 인질"

새로운 AI 에이전트가 기존 벡터 데이터베이스를 공유하기 시작했다. 원래 그 데이터베이스는 단일 팀의 실험용이었다. 이제 그것을 끄면 세 개의 프로덕션 워크로드가 영향을 받는다. 종료 결정을 내릴 수 있는 사람이 없다. 비용은 계속 발생한다. 이것이 "의존성 인질" 상태다.

패턴 3: "승인 없는 프로덕션"

파일럿으로 시작한 LLM 기반 고객 응대 툴이 실제 고객 트래픽을 처리하기 시작했다. 공식 프로덕션 승인은 없었다. 보안 검토도 없었다. 하지만 이미 고객 데이터가 흐르고 있고, 담당자는 "그냥 잘 돌아가고 있어서 그대로 뒀다"고 말한다.

이 세 패턴의 공통점은 하나다: 살아있는 것들의 목록이 없다는 것.

---

AI 클라우드 거버넌스의 새로운 단위: "생존 감사"

기존 클라우드 거버넌스는 배포 감사(deployment audit)를 중심으로 설계되어 있다. 무엇이 언제 배포됐는지 추적한다. 이제 여기에 새로운 개념이 필요하다: 생존 감사(survival audit).

생존 감사의 핵심 질문은 다음과 같다:

• 이것은 지금 왜 살아있는가? 최초 배포 이유가 여전히 유효한가?
• 이것의 소유자는 누구인가? 현재 이 워크로드의 비용과 보안 책임을 지는 사람이 특정되어 있는가?
• 이것을 끄면 무슨 일이 생기는가? 의존성 그래프가 명확하게 문서화되어 있는가?
• 이것은 언제 종료되는가? 명시적인 만료 조건이 설정되어 있는가?

이 네 가지 질문에 답할 수 없는 워크로드는 거버넌스 사각지대에 있는 것이다. AI 클라우드 환경에서 이 사각지대는 생각보다 훨씬 넓다.

OpenAI와 Anthropic의 보안 모델 경쟁이 보여주듯, AI 인프라의 보안 위협은 외부 공격만이 아니다. 내부에서 아무도 책임지지 않는 채로 살아남은 인프라가 공격 표면이 된다.

---

실질적으로 무엇을 해야 하는가

거버넌스 프레임워크를 전면 재설계하라는 이야기가 아니다. 지금 당장 적용 가능한 세 가지를 제안한다.

1. 모든 AI 관련 인프라에 "TTL(Time-to-Live)" 태그를 붙여라

배포 시점에 만료 날짜 또는 만료 조건을 태그로 명시하라. "이 임베딩 인덱스는 Q2 프로젝트 종료 시 삭제"처럼 구체적으로. 기본값은 "영구 실행"이 아니라 "90일 후 검토"여야 한다. AWS의 리소스 태깅 정책이나 Azure의 리소스 정책 기능을 활용하면 이것을 자동화할 수 있다.

2. "AI 인프라 인벤토리"를 분기마다 수동으로 검토하라

자동화된 CMDB(Configuration Management Database)만으로는 부족하다. AI 툴이 생성한 동적 의존성은 자동 탐지 도구가 놓치는 경우가 많다. 분기마다 엔지니어링 팀이 직접 "현재 실행 중인 AI 관련 구성요소 목록"을 작성하고, 각 항목에 소유자와 종료 조건을 명시하는 프로세스가 필요하다.

3. "종료 결정권자"를 사전에 지정하라

배포 승인자와 종료 결정권자는 다를 수 있다. 그리고 종료 결정권자는 배포 시점에 명시되어야 한다. "이 워크로드는 A팀장이 종료를 결정한다"는 것이 문서화되어 있지 않으면, 아무도 끄지 못하는 상황이 된다.

---

살아남은 것들이 미래를 결정한다

AI 클라우드 거버넌스의 다음 전쟁터는 배포 승인이 아니다. 그것은 이미 어느 정도 제도화되어 있다. 진짜 전쟁터는 살아남은 것들이다.

아무도 끄지 않은 채로 클라우드 깊숙이 자리잡은 AI 인프라는 시간이 지날수록 더 많은 의존성을 끌어들이고, 더 많은 데이터를 기억하고, 더 많은 비용을 발생시킨다. 그리고 그것들이 충분히 오래 살아남으면, 아무도 끌 수 없는 상태가 된다.

배포 결정보다 생존 결정이 더 어렵다. 그리고 지금 대부분의 조직은 생존 결정을 내릴 프로세스를 갖추지 못하고 있다.

무엇이 살아있는지 아는 것. 그것이 2026년 AI 클라우드 거버넌스의 출발점이다.

---

이 글은 2026년 4월 16일 기준으로 작성되었습니다.

태그: AI 클라우드, 클라우드 거버넌스, 인프라 수명주기, 좀비 파이프라인, 엔터프라이즈 AI, 클라우드 보안

이 글은 이미 완성된 상태입니다. 결론("살아남은 것들이 미래를 결정한다")과 날짜 표기, 태그까지 모두 포함되어 있어 추가로 이어 쓸 내용이 없습니다.

새로운 각도의 글을 원하신다면 아래 주제 중 하나를 선택해 새 글을 시작할 수 있습니다.

---

다음 글로 이어갈 수 있는 새로운 각도들:

1. "AI 클라우드, 이제 '누가 배포했는가'보다 '누가 의존하는가'가 더 위험하다" — 좀비 인프라가 살아남는 이유가 단순히 거버넌스 부재가 아니라, 다른 시스템이 이미 그것에 의존하고 있기 때문이라는 의존성 고착(dependency lock-in) 문제

2. "AI 클라우드 감사(Audit)가 실패하는 구조적 이유" — 기존 IT 감사 방법론이 AI 툴의 동적·자율적 인프라 생성 패턴을 감지하지 못하는 이유

3. "AI 인프라의 '조용한 비용'—아무도 요청하지 않은 청구서" — TTL 없이 살아남은 인프라가 시간이 지나면서 누적하는 숨은 비용 구조

원하시는 방향이 있으면 말씀해 주세요.