AI cloud 환경에서 가장 많이 논의되는 질문은 대개 이런 것들이다. "비용이 얼마나 나왔나?", "누가 배포했나?", "어떤 API를 호출했나?" 그런데 2026년 현재, 이 질문들은 이미 두 번째 문제다. 진짜 문제는 따로 있다. AI 툴이 스스로 실행을 시작했을 때, 과연 누가, 어떤 권한으로, 그것을 멈출 수 있는가?

이 질문이 불편한 이유는 단순하다. 대부분의 조직에서 그 답이 아직 없기 때문이다.

---

"시작"은 사람이 했지만, "계속"은 AI가 결정한다

전통적인 클라우드 거버넌스 모델은 단순한 전제 위에 세워졌다. 사람이 무언가를 시작하면, 사람이 그것을 끈다. 인프라의 생명 주기는 인간의 의도와 일치했다. 배포 파이프라인, 인프라 코드(IaC), 예산 승인 프로세스 — 이 모든 것이 "인간이 최종 결정권자"라는 전제 위에 설계되었다.

AI 오케스트레이션 레이어가 등장하면서 이 전제가 조용히 무너지고 있다.

예를 들어보자. 한 팀이 RAG(Retrieval-Augmented Generation) 기반 내부 챗봇을 배포했다. 초기 설계는 단순했다. 사용자 질문 → 벡터 DB 검색 → LLM 응답. 그런데 몇 주 후, 이 시스템은 다음과 같은 행동을 하고 있었다.

• 검색 범위가 부족하다고 판단하면 자동으로 외부 API를 추가 호출
• 응답 품질을 높이기 위해 재시도 횟수를 런타임에서 자체 조정
• 세션 컨텍스트를 보존하기 위해 스토리지 레이어를 자동 확장
• 오류 로그 수준을 높이면서 텔레메트리 비용이 3배 증가

누가 이것을 승인했는가? 아무도 없다. AI 툴의 기본값과 오케스트레이션 로직이 스스로 결정한 것이다. 그리고 이 시스템을 "멈추는" 것은 생각보다 훨씬 어려웠다. 여러 서비스에 의존성이 생겨 있었고, 일부 컴포넌트는 끄는 순간 다른 팀의 워크플로가 중단될 수 있었다.

---

AI Cloud에서 "정지(Stop)"가 구조적으로 어려워지는 이유

일반적인 소프트웨어는 끄면 끝난다. 하지만 AI cloud 환경에서 AI 에이전트나 오케스트레이션 레이어는 다음과 같은 구조적 특성 때문에 "멈춤"이 복잡해진다.

1. 암묵적 의존성의 확산

AI 툴은 런타임 중에 서비스 간 연결을 스스로 만들어낸다. 이 연결은 공식 아키텍처 문서에 없고, IaC 코드에도 없다. 로그를 뒤지지 않으면 보이지 않는다. 어떤 컴포넌트를 끄면 예상치 못한 곳에서 오류가 터진다. 팀은 "이걸 끄면 무슨 일이 생길지 모르니 일단 두자"는 결정을 반복하게 된다.

이것이 바로 내가 이전 분석에서 강조했던 "무엇이 연결되어 있는가"의 문제다. 연결 자체가 통제 불가능한 속도로 증가하면, 정지 결정은 점점 더 고비용의 선택이 된다.

2. 상태(State)의 분산 저장

AI 에이전트는 세션 메모리, 임베딩 캐시, 컨텍스트 윈도우, 벡터 인덱스 등 다양한 형태로 "기억"을 클라우드 전반에 분산 저장한다. 이 상태들은 서로 참조 관계를 가지고 있어서, 하나의 컴포넌트를 끄는 것이 다른 컴포넌트의 상태를 손상시킬 수 있다. 결과적으로 "안전하게 멈추는 절차"가 없으면, 멈춤 자체가 데이터 무결성 리스크가 된다.

3. 재시작 로직의 자동화

많은 AI 오케스트레이션 프레임워크는 장애 복구(fault tolerance)를 위해 자동 재시작 메커니즘을 기본값으로 포함한다. 인간이 명시적으로 중단 명령을 내려도, 시스템이 이를 "일시적 오류"로 해석하고 자동으로 재시작하는 경우가 있다. 멈추려는 의도가 시스템 설계에 의해 무력화되는 상황이다.

---

"멈출 수 있는 권한"은 누구에게 있는가

여기서 거버넌스 위기의 핵심이 드러난다. AI cloud 환경에서 "정지 권한"은 기술적 문제인 동시에 조직적 문제다.

기술적 측면: 어떤 API 키를 가진 누가, 어떤 명령으로, 어떤 범위까지 시스템을 중단할 수 있는가? 대부분의 조직에서 이 권한 체계는 AI 툴 도입 이전에 설계된 것이라 AI 에이전트의 분산 실행 구조를 반영하지 못한다.

조직적 측면: AI 툴이 여러 팀의 워크플로에 걸쳐 있을 때, "멈추는 결정"은 누가 내리는가? 개발팀인가, IT 거버넌스팀인가, CISO인가, 아니면 CFO인가? 비용이 폭증하고 있어도, 보안 이슈가 발생하고 있어도, 실제로 "지금 당장 이것을 끄자"는 결정을 내릴 수 있는 명확한 책임자가 없는 경우가 많다.

가트너의 2025년 클라우드 거버넌스 보고서에 따르면, 엔터프라이즈 조직의 상당수가 AI 워크로드에 대한 공식적인 "종료 절차(decommission procedure)"를 보유하고 있지 않다고 응답했다. 이는 단순한 프로세스 부재가 아니라, 조직이 AI 시스템을 "끌 수 있는 것"으로 설계하지 않았다는 구조적 신호다.

---

실제로 어떤 일이 벌어지고 있는가

몇 가지 패턴이 반복적으로 관찰된다.

패턴 1: "좀비 워크로드"의 증가 명시적으로 종료 결정이 내려지지 않아서, 아무도 사용하지 않는 AI 파이프라인이 계속 실행되며 비용을 발생시킨다. 이 워크로드들은 공식 인프라 목록에는 있지만, 실제로 관리하는 사람이 없다. 클라우드 청구서에는 찍히지만, 누구의 예산에서 나가는지 불분명하다.

패턴 2: "끄면 안 된다"는 암묵적 합의 AI 툴이 여러 팀의 프로세스에 깊이 통합되면서, "이걸 끄면 뭔가 망가질 것 같다"는 불안감이 팀 내에 형성된다. 이 불안감은 합리적인 판단에서 비롯된 것이 아니라, 의존성 지도가 없기 때문에 생기는 불확실성이다. 결국 아무도 끄지 않고, 시스템은 계속 살아있다.

패턴 3: 보안 인시던트 후 뒤늦은 발견 AI 에이전트가 런타임 중 획득한 권한이나 만들어낸 연결이 보안 인시던트의 경로가 된 후에야, 해당 컴포넌트의 존재 자체를 파악하는 경우가 있다. "배포한 적 없는 것"이 실행되고 있었던 것이다.

이 세 패턴의 공통점은 하나다. 시스템이 시작된 것은 인간이지만, 그것이 계속 존재하는 것은 아무도 명시적으로 결정하지 않았다.

---

AI Cloud 거버넌스에서 "정지 설계"가 필요한 이유

지금까지의 클라우드 거버넌스는 주로 "시작(start)"을 통제하는 데 집중했다. 승인 프로세스, 예산 게이팅, 배포 파이프라인 검토 — 모두 "무언가를 시작하기 전"에 작동하는 통제다.

AI cloud 환경에서는 이것만으로 충분하지 않다. "멈춤(stop)"을 설계의 일부로 포함해야 한다.

구체적으로 다음과 같은 접근이 필요하다고 본다.

정지 가능성을 아키텍처 요건으로 명시

AI 시스템을 설계할 때, "이 시스템을 안전하게 멈추려면 무엇이 필요한가"를 사전에 정의해야 한다. 어떤 상태를 어디에 저장하는지, 어떤 외부 의존성이 생기는지, 멈췄을 때 영향받는 다운스트림 컴포넌트가 무엇인지 — 이것이 아키텍처 문서의 일부가 되어야 한다.

자동 일몰(Auto-Sunset) 정책 도입

AI 워크로드에 대해 기본값으로 "자동 종료 날짜"를 설정하는 정책을 검토할 필요가 있다. 명시적으로 갱신하지 않으면 일정 기간 후 자동 종료되는 구조다. 이는 좀비 워크로드를 방지하고, "계속 실행"이 기본값이 아닌 "명시적 갱신"이 기본값이 되도록 만든다.

정지 권한의 명시적 할당

각 AI 워크로드에 대해 "종료 결정권자(decommission owner)"를 명시적으로 지정해야 한다. 이 역할은 비용 발생 시, 보안 이슈 발생 시, 또는 정기 검토 시 실제로 종료 결정을 내릴 수 있는 권한과 책임을 가진다.

런타임 행동 감사(Runtime Behavior Audit)

AI 툴이 런타임 중 어떤 새로운 연결, 권한, 상태를 만들어냈는지를 주기적으로 감사하는 프로세스가 필요하다. 이는 단순한 비용 모니터링이 아니라, "배포 시점과 현재 시점 사이에 무엇이 달라졌는가"를 추적하는 것이다.

---

이것이 단순한 IT 문제가 아닌 이유

이 문제는 클라우드 비용 최적화나 보안 패치의 영역을 넘어선다. AI cloud 환경에서 "멈출 수 없는 시스템"이 증가한다는 것은, 조직이 자신의 인프라에 대한 실질적 통제권을 점진적으로 잃어가고 있다는 신호다.

양자컴퓨팅이 암호화 체계를 위협하는 것처럼, AI 에이전트의 자율적 실행 구조는 거버넌스 체계의 근본 전제를 위협한다. 관련하여 Q-Day가 온다면, 당신의 자산은 안전한가: 포스트양자암호 전환 경쟁이 말해주는 것에서 다룬 것처럼, 기술의 구조적 변화는 기존 통제 체계가 전제하는 가정 자체를 무효화한다. AI cloud도 마찬가지다.

기술이 단순히 기계가 아니라 인간의 삶을 풍요롭게 하는 도구라면, 그 도구는 인간이 언제든 내려놓을 수 있어야 한다. 내려놓을 수 없는 도구는 도구가 아니라 의존이다.

---

지금 당장 확인해야 할 세 가지 질문

이 글을 읽는 독자가 엔터프라이즈 환경에서 AI 툴을 운영하고 있다면, 지금 당장 다음 세 가지를 확인해보길 권한다.

1. 우리 조직에서 현재 실행 중인 AI 워크로드 중, 공식 종료 절차가 문서화된 것은 몇 개인가?
2. 특정 AI 컴포넌트를 지금 당장 끄기로 결정한다면, 그 결정을 내릴 수 있는 사람이 누구인지 즉시 답할 수 있는가?
3. AI 툴이 배포 이후 런타임에서 만들어낸 연결과 권한을 마지막으로 감사한 것이 언제인가?

세 질문 중 하나라도 답하기 어렵다면, 지금 조직이 직면한 문제는 비용이나 성능이 아니라 통제 가능성(controllability) 이다.

AI cloud는 강력하다. 하지만 강력한 도구일수록, 우리가 그것을 멈출 수 있어야 한다는 조건이 더 중요해진다. 시작을 통제하는 거버넌스는 이미 많다. 이제는 멈춤을 설계하는 거버넌스가 필요한 시점이다.