2026년 5월 현재, AI cloud 거버넌스 논쟁의 전선은 조용히 새로운 영역으로 이동하고 있다. 스케일링, 장애 복구, 알림 라우팅 같은 운영 결정이 AI 손으로 넘어간 것은 이미 업계가 인지하기 시작한 문제다. 그런데 최근 들어 더 민감한 영역에서 같은 패턴이 반복되고 있다는 보고가 늘고 있다. 바로 벤더 선택과 클라우드 서비스 조달이다.

AI cloud 플랫폼에 내장된 자동화 도구들이 멀티클라우드 환경에서 "어떤 벤더의 어떤 서비스를 사용할지"를 추론하고 실행하기 시작했다. 구매팀, 법무팀, 최고조달책임자(CPO)는 그 결정이 이미 실행된 뒤에야 청구서나 이용약관 알림을 통해 사실을 인지하는 경우가 생기고 있다.

---

AI가 조달 결정에 개입하는 경로: 생각보다 훨씬 조용하다

처음에는 사소해 보이는 자동화에서 시작된다.

멀티클라우드 관리 플랫폼(예: Spot by NetApp, CloudHealth, Apptio Cloudability 등)은 비용 최적화를 명목으로 워크로드를 AWS에서 Azure로, 혹은 GCP의 특정 리전으로 이동시키는 권고를 자동 실행하도록 설정할 수 있다. 여기까지는 많은 팀이 알고 있다.

문제는 그다음 단계다.

최근 세대의 AI 기반 FinOps 도구들은 단순 리전 이동을 넘어, 서드파티 SaaS 서비스 자동 프로비저닝, 마켓플레이스 구독 자동 갱신, 새로운 관리형 서비스(Managed Service) 자동 활성화까지 정책 범위 안에서 실행한다. AWS Marketplace, Azure Marketplace, Google Cloud Marketplace는 모두 API를 통한 자동 구독 및 갱신을 지원하며, AI 도구들은 이 API를 활용해 "비용 효율적인 대안"을 조용히 선택한다.

Gartner의 2025년 클라우드 조달 보고서에 따르면, 멀티클라우드 환경을 운영하는 기업의 41%가 자동화 도구에 의해 예상치 못한 서드파티 서비스가 활성화된 경험이 있다고 응답했다. 그 중 절반 이상은 법무팀이나 구매팀의 사전 검토 없이 진행됐다고 밝혔다.

---

"정책 범위 내 실행"이라는 말의 함정

AI 도구 벤더들은 항상 같은 말을 한다. "저희 시스템은 고객이 정의한 정책 범위 내에서만 작동합니다."

이 말은 기술적으로 사실이다. 그러나 실무에서 그 "정책"이 어떻게 정의되는지를 보면 이야기가 달라진다.

대부분의 조직에서 초기 정책 설정은 클라우드 엔지니어링팀이 담당한다. 그들은 비용 임계값, 허용 리전, 인스턴스 유형 같은 기술적 파라미터를 입력한다. 그런데 "AWS Marketplace에서 월 $500 미만의 서비스는 자동 구독 허용"이라는 정책이 구매팀의 공식 조달 프로세스를 우회한다는 사실을 엔지니어링팀이 인지하고 설정했을까? 법무팀이 그 약관을 검토했을까?

현실에서는 그렇지 않은 경우가 많다.

더 큰 문제는 정책 자체가 AI에 의해 점진적으로 확장되는 경우다. 일부 플랫폼은 "추천 정책 업데이트"를 제안하고, 담당자가 별다른 검토 없이 "승인" 버튼을 누르면 조달 범위가 조용히 넓어진다. 이 과정에서 어떤 공식 승인 워크플로우도, CAB(변경자문위원회) 검토도 개입하지 않는다.

---

AI cloud가 벤더 선택에 개입하는 세 가지 실제 시나리오

시나리오 1: 데이터베이스 관리형 서비스 자동 전환

한 핀테크 기업의 사례를 생각해보자. 클라우드 비용 최적화 AI가 자사 운영 중인 PostgreSQL 인스턴스의 비용이 AWS RDS 대비 23% 높다고 판단했다. 정책 범위 내에서 AI는 Aurora Serverless v2로의 마이그레이션을 실행했다. 기술적으로는 합리적인 결정이었다.

그런데 Aurora Serverless v2는 AWS의 독점 관리형 서비스다. 이 전환은 사실상 특정 벤더에 대한 기술적 락인(lock-in)을 심화시키는 결정이었다. 구매팀이 이 사실을 인지한 것은 다음 분기 벤더 다변화 전략 회의에서였다. 이미 데이터와 애플리케이션이 Aurora에 최적화된 상태로.

시나리오 2: 보안 도구 마켓플레이스 자동 구독

보안 운영팀이 SIEM 도구를 평가하는 동안, AI 기반 클라우드 보안 자동화 도구가 "위협 감지 공백"을 식별하고 Azure Marketplace에서 서드파티 위협 인텔리전스 피드를 자동 구독했다. 월 $400짜리 구독이었다.

문제는 그 서드파티 벤더의 데이터 처리 약관이 GDPR 요건과 충돌할 소지가 있었다는 점이다. 법무팀은 6개월 후 감사 과정에서 이 구독의 존재를 알았다.

시나리오 3: AI 추론 서비스 자동 선택

이것이 가장 최근, 그리고 가장 빠르게 확산되는 패턴이다.

AI 워크로드 오케스트레이션 플랫폼들은 이제 "어떤 AI 모델 API를 호출할지"도 비용과 성능을 기준으로 자동 선택한다. OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI — 이 중 어느 벤더의 API를 호출할지를 AI가 실시간으로 결정하는 것이다.

각 벤더는 서로 다른 데이터 보존 정책, 학습 데이터 활용 약관, 지역 데이터 처리 규정을 가지고 있다. AI가 "비용 최적"을 기준으로 벤더를 선택하는 순간, 그 데이터가 어느 나라 서버에서 어떤 약관 하에 처리되는지는 조직의 통제 밖으로 나간다.

AI 도구, 이제 "언제 스케일을 올리고 내릴지"도 스스로 결정한다에서 다룬 것처럼, 이 자동화의 공통된 패턴은 결정의 실행 속도가 인간의 검토 속도를 압도한다는 점이다. 벤더 선택도 예외가 아니다.

---

왜 이것이 단순한 "비용 초과" 문제가 아닌가

클라우드 비용이 예상보다 많이 나오는 것은 불편한 일이다. 그러나 AI가 자율적으로 벤더를 선택하는 문제는 차원이 다르다.

첫째, 계약 책임의 문제다. 기업이 특정 클라우드 마켓플레이스 서비스를 구독하면, 그 서비스의 이용약관에 자동으로 동의한 것으로 간주된다. AI가 그 구독을 실행했더라도 법적 책임은 기업에 귀속된다. "AI가 한 일"이라는 변명은 법원에서 통하지 않는다.

둘째, 공급망 보안(Supply Chain Security)의 문제다. AI가 자동 선택한 서드파티 서비스가 악의적이거나 취약한 소프트웨어를 포함하고 있을 경우, 그것은 단순한 비용 문제가 아니라 보안 침해로 이어진다. CISA와 ENISA 모두 2025년 이후 클라우드 마켓플레이스를 통한 공급망 공격이 증가하고 있다고 경고하고 있다.

셋째, 벤더 락인 심화의 문제다. AI는 현재 비용 최적화를 기준으로 결정하지만, 그 결정의 누적 효과는 특정 벤더 생태계에 대한 기술적·데이터적 의존도를 높인다. 이것은 3~5년 후 협상력과 전환 비용에 직접적인 영향을 미친다.

넷째, 규제 컴플라이언스의 문제다. 금융, 의료, 공공 분야에서는 사용하는 클라우드 서비스와 벤더가 규제 당국의 승인 대상이 되는 경우가 있다. AI가 승인되지 않은 서비스를 자동 활성화하면, 이는 즉각적인 컴플라이언스 위반으로 이어질 수 있다.

---

AI cloud 거버넌스의 새로운 공백: 조달 레이어

지금까지 AI cloud 거버넌스 논의는 주로 운영 레이어(누가 고치는가, 언제 스케일하는가, 누구에게 알리는가)에 집중되어 있었다. 그러나 조달 레이어는 더 오랫동안, 더 조용히 방치되어 왔다.

그 이유는 구조적이다.

클라우드 운영 자동화는 엔지니어링팀의 영역이기 때문에 거버넌스 논의가 비교적 빨리 시작됐다. 반면 조달 자동화는 엔지니어링팀과 구매팀 사이의 경계 영역에 있다. 엔지니어링팀은 "이건 구매팀 문제"라고 생각하고, 구매팀은 "이건 기술적인 결정"이라고 생각한다. 이 틈새에서 AI는 조용히 계약을 맺고, 서비스를 활성화하고, 벤더를 선택한다.

이 문제는 AI가 의료 불평등을 해결할 수 있을까? 그 낙관론이 숨기는 경제적 진실에서 다룬 AI 자동화의 더 넓은 패턴과도 맞닿아 있다. AI 시스템은 최적화 목표를 달성하는 데는 탁월하지만, 그 과정에서 발생하는 부수적 결과(법적 책임, 장기 의존성, 규제 리스크)를 스스로 평가하지 못한다.

---

지금 당장 할 수 있는 것: 조달 거버넌스 체크리스트

이론적 논의보다 실무에서 바로 적용할 수 있는 접근을 제안한다.

1. 자동화 도구의 "조달 권한" 감사

현재 사용 중인 클라우드 비용 최적화, AIOps, 보안 자동화 도구들이 어떤 마켓플레이스 권한을 갖고 있는지 즉시 점검해야 한다. AWS IAM, Azure RBAC, GCP IAM에서 서드파티 도구에 부여된 marketplace:Subscribe, marketplace:CreateSubscription 같은 권한을 확인하라. 이 권한이 필요 이상으로 광범위하게 부여되어 있을 가능성이 높다.

2. 마켓플레이스 구독에 승인 워크플로우 추가

AWS Organizations의 마켓플레이스 구독 정책, Azure의 Marketplace 구매 승인 설정을 활용해 모든 신규 서비스 구독에 인간 승인 단계를 추가하라. 자동화 도구가 구독을 "추천"할 수는 있지만, 실행은 반드시 지정된 승인자(구매팀 또는 법무팀 포함)를 거치도록 설정해야 한다.

3. 벤더 선택 결정 로그 의무화

AI 도구가 어떤 기준으로 어떤 벤더/서비스를 선택했는지에 대한 결정 로그를 중앙 집중식으로 기록하고, 이를 정기적으로 구매팀과 공유하는 프로세스를 만들어야 한다. 이것이 없으면 감사 시 "AI가 한 일"을 소급해서 설명할 방법이 없다.

4. AI 모델 API 라우팅 정책 명문화

AI 추론 서비스를 사용하는 조직이라면, 어떤 벤더의 AI API를 사용할 수 있는지를 명시적으로 허용 목록(allowlist)으로 정의하고, 그 외 벤더로의 자동 라우팅을 차단해야 한다. 특히 개인정보나 기업 기밀이 포함될 수 있는 데이터가 처리되는 경우라면 이것은 선택이 아닌 필수다.

5. "정책 업데이트 추천"에 대한 별도 승인 체계

AI 도구가 제안하는 정책 변경은 운영 결정과 동일한 승인 체계를 적용해서는 안 된다. 정책 변경은 조달, 법무, 보안팀이 함께 검토하는 별도 워크플로우를 거쳐야 한다.

---

거버넌스의 경계를 다시 그려야 할 때

AI cloud 자동화가 가져오는 효율성은 실재한다. 비용을 줄이고, 운영 부담을 낮추고, 인간이 놓치는 최적화 기회를 포착한다. 이것을 부정하는 것은 현실적이지 않다.

그러나 효율성의 이면에는 책임의 공백이 자라고 있다. AI가 벤더를 선택하고, 계약을 맺고, 서비스를 활성화하는 동안, 그 결정에 대한 법적·규제적·전략적 책임은 여전히 인간 조직에 귀속된다. 그런데 그 책임을 질 사람이 결정의 존재조차 모르는 상황이 반복되고 있다.

이것은 기술의 실패가 아니다. 거버넌스 설계의 실패다.

AI가 "정책 범위 내에서만" 작동한다고 해서 그 정책이 조직의 모든 이해관계자 — 엔지니어링, 구매, 법무, 보안, 재무 — 의 합의를 반영하고 있다는 의미는 아니다. 지금까지 클라우드 거버넌스 논의가 운영 레이어에 집중되는 동안, 조달 레이어는 사각지대로 남아 있었다.

AI cloud 시대의 거버넌스는 운영 결정뿐만 아니라 조달 결정까지 포함하도록 경계를 다시 그려야 한다. 그리고 그 작업은 엔지니어링팀 혼자가 아니라, 구매팀·법무팀·보안팀이 함께 테이블에 앉아야만 가능하다.

청구서를 받고 나서 "AI가 그랬어요"라고 말할 수 있는 시간은 이미 지나가고 있다.