CIO들이 직면한 멀티클라우드 AI 함정

Google 뉴스는 CIO들에게 날카로운 경고를 제시했다. 멀티클라우드 AI는 유연성을 약속하지만, 비용이 큰 통합의 함정을 만들 수 있다. InformationWeek의 보도는 Google Cloud, Amazon Web Services, Microsoft Azure 및 전문 AI 벤더의 서비스를 결합하는 익숙한 전략에 의문을 제기한다.

매력은 쉽게 이해할 수 있다. 한 제공업체는 선호하는 모델을 제공하고, 다른 업체는 핵심 데이터를 보유하거나 더 나은 지역별 지원 범위를 제공할 수 있다. 세 번째 플랫폼은 이미 회사의 ID 관리, 분석 또는 애플리케이션 환경을 지원하고 있을 수 있다.

문제는 이러한 선택이 고립된 파일럿 단계를 넘어설 때 시작된다. 클라우드를 하나 추가할 때마다 또 다른 ID 시스템, 정책 모델, 데이터 경로, 모니터링 계층, 청구 구조가 도입된다. 그러면 CIO는 폭넓은 AI 서비스 접근성과 팀이 관리할 수 있는 아키텍처 사이에서 선택해야 한다.

이는 단순히 클라우드 지출에 대한 또 하나의 경고가 아니다. AI 애플리케이션은 모델, 프롬프트, 비공개 데이터, 벡터 인덱스, 도구, 자동화된 작업을 지속적으로 결합한다. 이러한 의존성은 기존 웹 애플리케이션보다 훨씬 더 자주 시스템 경계를 넘나든다.

Google Cloud, AWS, Microsoft는 모두 엔터프라이즈 AI 배포를 쉽게 만들기 위한 서비스를 홍보한다. 그러나 각 플랫폼은 모델 인터페이스, 권한, 관측성, 네트워킹, 관리형 데이터 서비스 측면에서 여전히 다르다. 이 차이는 이식성을 조달상의 약속에서 엔지니어링 프로젝트로 바꾼다.

따라서 핵심 경쟁 구도는 분명하다. 최고 수준의 멀티클라우드 선택권은 분절된 인프라의 운영 현실과 맞서고 있다. 기업이 더 많은 AI 구성요소를 분산할수록 정보가 어떻게 이동하고 각 의사결정을 누가 통제하는지 파악하기는 더 어려워진다.

Google 뉴스가 드러낸 클라우드 선택에서 AI 의존성으로의 전환

중요한 변화는 기업이 여러 클라우드를 사용한다는 사실이 아니다. 이제 AI가 지속적인 데이터 및 운영 의존성을 통해 이들 클라우드를 연결한다는 점이다.

수년간 기업은 멀티클라우드 도입을 협상력을 유지하고 적합한 서비스를 선택하는 수단으로 여겼다. 워크로드는 비교적 독립적으로 유지될 수 있었다. 한 팀은 AWS에서 하나의 애플리케이션을 호스팅하고, 다른 팀은 별도의 비즈니스 시스템에 Microsoft Azure를 사용할 수 있었다.

엔터프라이즈 AI는 이러한 분리를 약화시킨다. 하나의 애플리케이션이 한 환경에서 문서를 검색하고, 다른 환경의 모델을 호출한 뒤, 결과를 제3자 워크플로로 전송할 수 있다. 외부 평가 플랫폼과 별도의 보안 서비스를 함께 사용할 수도 있다.

각 상호작용은 애플리케이션의 프로덕션 경로 일부가 된다. ID 페더레이션, 데이터 동기화, 네트워킹 또는 모델 접근에서 발생한 장애는 최종 답변에 영향을 줄 수 있다. 기존 가동 시간 모니터링만으로는 어떤 구성요소가 부실하거나 안전하지 않은 응답을 초래했는지 항상 드러나지 않는다.

Google Cloud의 인프라 연구는 이러한 전환의 규모를 보여준다. 이 회사는 2026년 보고서를 위해 전 세계 IT 리더 1,402명을 조사했다. 응답 조직의 52%가 하이브리드 멀티클라우드 아키텍처를 사용한다고 밝혔다.

보고서는 또한 프로덕션급 자율 시스템을 지원하려면 83%가 인프라 업그레이드를 필요로 한다고 말한다. 응답자의 5명 중 4명은 보안, 거버넌스 또는 MLOps를 중요한 과제로 꼽았다. MLOps는 머신러닝 시스템을 배포, 모니터링, 관리하는 데 사용되는 프로세스를 포괄한다.

이 결과는 인프라 지출에 이해관계를 가진 클라우드 제공업체에서 나온 것이다. 모든 기업이 대규모 재구축을 해야 한다는 중립적 증거로 받아들여서는 안 된다. 다만 인프라 벤더가 프로덕션 도입의 장벽을 어떻게 규정하는지는 보여준다.

AI 에이전트에서는 이 장벽이 더 중요해진다. 에이전트는 목표를 향해 행동을 선택하고 실행하기 위해 모델을 사용하는 소프트웨어다. 기록을 읽고, 비즈니스 애플리케이션을 호출하며, 문서를 생성하거나 운영 시스템을 업데이트할 수 있다.

챗봇은 도움이 되지 않는 답변을 내놓는 방식으로 실패할 수 있다. 에이전트는 연결된 시스템 전반에서 잘못된 작업을 수행하는 방식으로 실패할 수 있다. 따라서 참여하는 모든 클라우드에서 일관된 권한, 감사 기록, 정책 집행의 중요성이 커진다.

원래 멀티클라우드의 약속은 한 벤더에 대한 의존을 피하는 데 크게 초점이 맞춰져 있었다. AI는 의존성의 단위를 바꾼다. 조직은 단일 클라우드에만 의존하는 것은 피할 수 있지만, 호환되지 않는 서비스로 구성된 맞춤형 메시 구조에 의존하게 될 수 있다.

이 메시 구조는 단일 관리형 제품보다 교체하기 어렵다. 그 동작 방식이 커넥터, 변환, 접근 정책, 라우팅 규칙, 팀의 지식 전반에 걸쳐 존재하기 때문이다. 따라서 벤더 독립성은 아키텍처 의존성을 낳을 수 있다.

기업이 데모 단계에서 운영 워크플로로 이동하는 시점에 이러한 경고가 나온다는 점에서 Google 뉴스 보도는 중요하다. 파일럿은 수동 개입과 제한된 데이터세트를 감내할 수 있다. 프로덕션 시스템은 변화하는 권한, 모델 버전, 장애, 규정 준수 규칙, 예기치 않은 사용자 행동을 처리해야 한다.

더 이상 여러 모델이 유용한 답변을 낼 수 있는지의 문제가 아니다. CIO는 수백 개 팀이 각자의 데이터와 도구를 연결하기 시작한 뒤에도 전체 체인이 이해 가능한 상태로 유지되는지 판단해야 한다.

AI 압력은 CIO들에게 표준화보다 통합을 먼저 요구하고 있다

CIO들은 안전한 확장에 필요한 아키텍처 표준이 아직 정립되지 않은 상황에서, 눈에 보이는 AI 성과를 내야 한다는 압박을 받고 있다.

이사회와 비즈니스 리더들은 기술 경영진이 AI 투자를 측정 가능한 운영 개선으로 전환하기를 점점 더 기대하고 있다. 사업 부문은 수년에 걸친 데이터 현대화 프로그램을 기다리려 하지 않는다. 이미 모델 접근 권한과 자동화 도구를 직접 구매할 수 있기 때문이다.

이러한 압력은 지역 최적화를 부추긴다. 제품 팀은 자사 사용 사례에서 가장 좋은 성능을 내는 모델을 선택한다. 지역 조직은 현지 호스팅 요건을 충족하는 제공업체를 고른다. 인수된 기업은 기존에 운영하던 클라우드 스택을 유지한다.

각 결정은 그 자체로 합리적일 수 있다. 하지만 결합된 아키텍처는 여전히 관리 불가능해질 수 있다.

클라우드 전략에 관한 CIO 보도는 이 문제를 비슷한 방식으로 설명한다. 기술 리더들은 이제 AI 준비 상태와 사이버보안, 데이터 거버넌스, 주권, 엣지 컴퓨팅, 통합 아키텍처, 운영 복원력의 균형을 맞춰야 한다. 이 우려들은 분리된 계획 과제가 아니라 동일한 워크로드에 영향을 미친다.

AI는 클라우드 의사결정에 관여하는 이해관계자의 수도 늘린다. 보안 팀은 데이터 접근에 대한 명확한 통제가 필요하다. 법무 팀은 어떤 정보가 모델에 도달하고 어디서 처리가 이뤄지는지 알아야 한다.

재무 팀은 예측 가능한 사용량 및 전송 비용이 필요하다. 데이터 리더는 품질, 계보, 보존 규칙을 지켜야 한다. 애플리케이션 소유자는 여전히 수용 가능한 지연 시간과 안정성을 기대한다.

멀티클라우드 설계는 이러한 책임을 서로 다른 제어 영역에 분산한다. 제어 영역은 리소스, 권한, 정책, 운영을 구성하는 데 사용되는 시스템이다. 각 제공업체는 서로 다른 용어와 집행 지점을 제공한다.

따라서 동일한 직원도 여러 ID 매핑을 통해 접근 권한을 받을 수 있다. 한 환경에서 민감한 데이터를 차단하는 정책이 다른 곳의 모델 엔드포인트까지 포괄하지 못할 수 있다. 로그는 동일한 사용자 또는 워크로드에 대해 서로 다른 식별자를 기록할 수 있다.

Google은 이전에 조사 대상 조직의 81%가 클라우드, 데이터센터, 엣지 위치 전반에서 애플리케이션 및 데이터 이식성 문제를 겪었다고 보고했다. Google의 멀티클라우드 설문조사는 또한 39%가 대체 제공업체를 사용하는 주요 이유로 AI 워크로드를 꼽았다고 밝혔다.

이 관계는 시사하는 바가 크다. AI는 조직을 추가 클라우드로 이끄는 데 기여하는 반면, 이식성은 여전히 아키텍처에서 가장 흔한 어려움 중 하나다. 기업을 두 번째 제공업체로 이끈 서비스가, 이를 사용하기 위해 필요한 통합 작업을 더 깊게 만들 수 있다.

사업 부문은 모델 엔드포인트만 볼 수 있다. 플랫폼 팀은 네트워크 경로, 자격 증명, 암호화 키, 데이터 형식, 사용 한도, 모니터링, 사고 대응을 관리해야 한다. 또한 모델 업데이트와 서비스 중단에 대응할 프로세스도 필요하다.

이러한 불균형은 CIO를 양방향에서 압박한다. 중앙 통제는 실험을 늦추고 승인되지 않은 도구 사용을 부추길 수 있다. 제한 없는 실험은 중복 플랫폼과 숨겨진 데이터 흐름을 만들어낼 수 있다.

필요한 대응은 단순히 지출을 늘리는 일이 아니다. CIO는 다양성이 비즈니스 가치를 만드는 지점과 표준화가 위험을 낮추는 지점을 정의해야 한다. 이를 위해 승인된 모델, 공용 데이터 계층, ID 패턴, 평가 방법, 소유권에 관한 결정이 필요하다.

시장이 계속 움직이기 때문에 이 선택은 어렵다. 오늘 성능 때문에 선택한 모델은 다음 릴리스 이후 우위를 잃을 수 있다. 개발 시간을 절약하는 관리형 기능은 해당 제공업체에 대한 더 깊은 의존성을 만들 수 있다.

그 결과 발생하는 불확실성은 제공업체를 상호 교체 가능하게 만들겠다고 약속하는 추상화 계층을 장려한다. 이 계층은 도움이 될 수 있지만, 팀이 운영해야 할 또 하나의 서비스를 추가하기도 한다. 기본 기능의 실질적 차이가 유지되는 한 추상화는 복잡성을 없애지 못한다.

압력은 즉각적이지만 영향은 장기적이다. 파일럿 통합은 몇 달 안에 프로덕션 의존성이 될 수 있다. 직원들이 이를 중심으로 워크플로를 구축하면, 교체는 프로세스와 교육, 과거 데이터에 영향을 미친다.

따라서 CIO들은 단지 클라우드 중에서 선택하는 것이 아니다. 조직이 지속적인 운영 의무로 떠안을 차이를 선택하고 있다.

최고 수준의 AI 선택은 통합세가 된다

멀티클라우드 AI는 각 전문 서비스의 이점이 이를 연결하고 관리하는 지속적인 비용을 초과할 때에만 가치를 창출한다.

최고 수준의 조달 전략은 기업이 모든 요구사항에 가장 강력한 구성요소를 선택할 수 있다고 가정한다. 한 클라우드는 적합한 가속기를 제공할 수 있다. 다른 클라우드는 다양한 후속 작업에 맞게 적용되는 범용 모델인 선호 기반 모델을 제공할 수 있다.

세 번째 제공업체는 조직의 데이터베이스를 호스팅할 수 있다. 독립 벤더는 검색, 모델 라우팅, 평가, 관측성, 보안을 제공할 수 있다. 문서상으로는 단일 벤더에 대한 타협이 줄어든 유연한 스택을 만든다.

그러나 실제로는 각 경계가 통합세를 발생시킨다. 이 비용에는 엔지니어링 시간, 데이터 이동, 중복 통제, 테스트, 사고 조율, 전문 지식이 포함된다. 첫 배포 이후에도 계속된다.

데이터는 가장 명확한 사례를 제공한다. 모델이 유용한 결과를 만들려면 관련 비즈니스 맥락이 필요하다. 그 맥락은 문서, 데이터베이스, 메시지, 티켓, 고객 시스템, 운영 기록에 존재할 수 있다.

이 모든 정보를 하나의 클라우드로 옮기면 거버넌스와 최신성 문제가 생긴다. 분산된 상태로 두면 소스 간 인증을 수행하고 접근 규칙을 유지할 수 있는 검색 시스템이 필요하다. 어느 선택이든 운영상 결과를 수반한다.

일반적으로 RAG라고 불리는 검색 증강 생성은 모델이 답변하기 전에 선별된 정보를 제공한다. RAG 파이프라인은 데모에서는 단순해 보일 수 있다. 프로덕션 사용에는 문서 파싱, 인덱싱, 권한, 업데이트, 삭제 처리, 순위 지정, 평가, 모니터링이 필요하다.

이러한 구성요소를 제공업체 전반에 분산하면 근본 원인 분석이 더 어려워진다. 부실한 답변은 모델, 오래된 인덱스, 실패한 커넥터, 누락된 권한 또는 순위 지정 변경에서 비롯될 수 있다. 각 팀은 한 구간만 소유할 수 있다.

조직들은 AI 외부에서도 이미 이러한 파편화로 어려움을 겪고 있습니다. Gartner는 설문에 참여한 조직의 85%가 여러 클라우드에 걸쳐 데이터 및 분석 애플리케이션을 배포했다고 보고했습니다. 그중 고급 클라우드 간 데이터 및 분석 역량을 갖췄다고 답한 비율은 30%에 불과했습니다.

Gartner 조사 결과는 현재의 프로덕션 AI 에이전트 확산 이전에 실시된 설문에서 나온 것입니다. 이는 많은 기업이 통합 성숙도를 이미 넘어선 멀티클라우드 환경을 갖춘 상태에서 AI 확장에 진입했음을 시사합니다.

AI는 애플리케이션의 동작이 데이터 품질과 모델 출력에 함께 좌우되기 때문에 위험도를 높입니다. 기존 통합은 대체로 시스템 간 알려진 필드를 매핑합니다. AI 파이프라인은 확률적 응답을 도입하므로 동일한 요청도 서로 다른 결과를 낼 수 있습니다.

팀은 인프라와 출력 품질을 모두 평가해야 합니다. 요청이 의도한 모델에 도달했는지, 올바른 데이터를 사용했는지, 정책을 따랐는지, 허용 가능한 답변을 생성했는지를 알아야 합니다. 이러한 근거는 공급자 경계를 넘어 유지되어야 합니다.

모델 라우팅은 또 다른 복잡성을 더합니다. 라우터는 비용, 속도, 가용성 또는 작업 유형에 따라 요청을 서로 다른 모델로 보낼 수 있습니다. 이 접근 방식은 단일 모델에 대한 의존도를 낮추지만, 테스트와 책임 추적을 복잡하게 만듭니다.

서로 다른 모델은 프롬프트를 다르게 해석합니다. 도구 호출 형식, 컨텍스트 제한, 안전 제어, 지역별 가용성도 각기 다릅니다. 폴백 모델은 애플리케이션을 계속 운영할 수 있게 하지만, 응답의 품질이나 규정 준수 특성을 바꿀 수 있습니다.

따라서 진정한 이식성에는 API 주소를 바꾸는 것 이상이 필요합니다. 팀은 프롬프트, 도구, 평가, 콘텐츠 제어, 로깅, 오류 처리를 표준화해야 합니다. 공급자가 인터페이스나 모델 동작을 변경할 때마다 이 작업을 반복해야 합니다.

데이터 전송 아키텍처도 중요합니다. 대규모 데이터세트나 반복적인 추론 컨텍스트를 클라우드 간에 이동하면 지연 시간과 사용량 비용이 늘어날 수 있습니다. 테스트 중에는 이러한 비용이 수용 가능해 보이더라도, 직원 전반의 도입 이후 사용량은 빠르게 증가할 수 있습니다.

좁은 범위의 베스트 오브 브리드 선택도 여전히 가치가 있을 수 있습니다. 특화 모델은 코딩, 문서 분석, 과학 업무에서 의미 있는 이점을 제공할 수 있습니다. 지역 서비스는 단일 공급자가 충족하지 못하는 데이터 상주 또는 지연 시간 요구 사항도 만족시킬 수 있습니다.

함정은 조직이 선택권을 무료로 상호 교환할 수 있는 능력으로 착각할 때 나타납니다. 여러 클라우드에 접근할 수 있다는 것은 워크로드를 그 사이에서 안전하게 이동할 수 있다는 것과 다릅니다. 추가되는 모든 경로에는 책임 주체와 가치에 대한 근거가 필요합니다.

CIO는 공급자 다양성을 제한된 자원으로 다뤄야 합니다. 새로운 서비스는 즉각적인 기능뿐 아니라 새로 만드는 통합 접점도 정당화해야 합니다. 서비스의 신선함이 사라진 뒤에도 그 접점은 남습니다.

팀에는 아키텍처 결정에 대한 지속적인 기록도 필요합니다. 검색 가능한 기술 지식 베이스는 책임 주체, 종속성, 운영 맥락을 보존할 수 있습니다. 문서화만으로 파편화를 해결할 수는 없지만, 맥락이 부족하면 모든 인시던트 대응이 느려집니다.

공유 플랫폼은 복잡성을 줄이지만 클라우드 간 차이를 없애지는 못한다

공통 운영 계층은 인프라 다양성을 통제할 수 있지만, 독점 AI 서비스를 진정으로 상호 교환 가능하게 만들 수는 없습니다.

플랫폼 엔지니어링은 멀티클라우드 AI에 대한 하나의 대응책을 제공합니다. 중앙 팀은 배포 템플릿, ID 패턴, 모니터링, 정책 제어를 포함해 애플리케이션 팀이 사용할 승인된 경로를 만듭니다. 개발자는 모든 연결을 각각 독립적으로 구성하는 대신 이러한 경로를 사용합니다.

Kubernetes는 이 전략을 뒷받침하는 경우가 많습니다. 이는 여러 인프라 환경에서 컨테이너화된 애플리케이션을 오케스트레이션합니다. Cloud Native Computing Foundation은 2026년 설문에서 컨테이너 사용자의 82%가 프로덕션에서 Kubernetes를 실행한다고 보고했습니다.

CNCF 설문은 Kubernetes를 클라우드 네이티브 및 AI 시스템을 위한 공통 운영 계층으로 설명합니다. 이러한 위치는 실질적인 이점을 반영합니다. 컨테이너는 애플리케이션의 일부를 클라우드와 프라이빗 인프라 전반에서 더 일관되게 만들 수 있습니다.

그러나 Kubernetes가 모든 관리형 AI 기능을 표준화하지는 않습니다. 독점 모델 서비스, 벡터 데이터베이스, ID 제품, 데이터 웨어하우스는 여전히 공급자별 동작을 노출합니다. 애플리케이션 코드를 옮긴다고 해서 데이터와 운영 제어까지 자동으로 이전되는 것은 아닙니다.

오픈 모델 인터페이스는 일부 마찰을 줄일 수 있습니다. 표준화된 API는 애플리케이션이 공통 요청 패턴을 통해 여러 모델을 호출할 수 있게 합니다. 오픈소스 추론 소프트웨어 역시 서로 다른 인프라에서 동일한 모델 가중치를 실행할 수 있습니다.

이러한 접근 방식은 선택지를 만들지만, 책임을 기업 쪽으로 이전합니다. 팀은 용량, 업그레이드, 보안 수정, 성능 튜닝, 모델 거버넌스를 운영해야 합니다. 이식성은 구매하는 기능이 아니라 내부 역량이 됩니다.

공유 데이터 계층은 또 다른 선택지입니다. 기업은 개별 모델 공급자와 독립적으로 정보에 대한 거버넌스된 접근을 유지할 수 있습니다. 그러면 애플리케이션은 승인된 모델을 동일한 정책 인식형 데이터 서비스에 연결합니다.

이 아키텍처는 통제되지 않은 복제를 제한합니다. 동시에 위험을 공유 계층에 집중시킵니다. 부실한 메타데이터, 누락된 권한, 사용할 수 없는 게이트웨이는 이에 의존하는 모든 AI 애플리케이션에 영향을 줄 수 있습니다.

중앙화된 ID 및 정책 집행도 마찬가지로 중요합니다. SANS는 2023년 멀티클라우드 설문에서 응답자의 55%가 여러 단일 로그인 솔루션을 사용한다고 밝혔습니다. 단일 솔루션으로 통합하는 방향으로 작업 중이라고 답한 비율은 14%에 불과했습니다.

SANS 분석은 상당한 계정 확산도 확인했습니다. 응답자의 16%는 100개가 넘는 AWS 계정을 사용했고, 12%는 100개가 넘는 Azure 구독 및 Google Cloud 계정을 사용했습니다.

그러한 환경 전반에 구축된 AI 서비스는 일관되지 않은 권한을 물려받을 수 있습니다. 서비스 ID가 기존 사용자 권한과 깔끔하게 매핑되지 않아 모델이 광범위한 접근 권한을 받을 수 있습니다. 직원이 역할을 바꾼 뒤에도 커넥터가 접근 권한을 유지할 수도 있습니다.

따라서 중앙 거버넌스는 클라우드 계정만이 아니라 사용자, 데이터, 모델, 작업을 따라야 합니다. 팀에는 각 AI 사용 사례를 책임자, 승인된 데이터, 배포된 모델, 평가 결과, 운영 제어와 연결하는 인벤토리가 필요합니다.

이 인벤토리는 정적인 스프레드시트로 남아서는 안 됩니다. AI 구성은 너무 자주 바뀌고, 인프라 리소스는 자동화를 통해 나타납니다. 거버넌스에는 기계 판독 가능한 정책과 지속적으로 수집되는 근거가 필요합니다.

관측 가능성도 클라우드를 가로질러야 합니다. 팀은 애플리케이션 추적, 모델 요청, 검색 이벤트, 도구 호출, 정책 결정, 비즈니스 결과를 연결해야 합니다. 추적은 하나의 요청이 분산 시스템을 어떻게 이동했는지 보여 주는 연결된 기록입니다.

이 연결이 없으면 인프라 대시보드는 부분적인 답만 제공합니다. 한 공급자는 전체 워크플로가 오래된 정보를 반환했는데도 성공적인 모델 요청을 표시할 수 있습니다. 다른 공급자는 상류 프롬프트를 설명하지 않은 채 차단된 도구 호출을 기록할 수 있습니다.

공통 플랫폼은 팀이 지원해야 하는 패턴의 수를 줄입니다. 승인된 작업을 즉흥적인 작업보다 쉽게 만들 때 성공합니다. 유용한 자동화 없이 양식과 지연만 추가하는 플랫폼은 개발자를 직접적인 공급자 접근으로 몰아갈 것입니다.

목표는 모든 곳에서 동일한 인프라가 아닙니다. 명시적인 책임자를 둔 통제 가능한 수의 차이입니다. CIO는 측정 가능한 이점을 만드는 경우에만 공급자별 서비스를 유지해야 합니다.

이 접근 방식은 일부 종속을 받아들입니다. 이는 모든 AI 워크로드가 이식성을 유지한다고 주장하는 것보다 대개 더 정직합니다. 핵심 질문은 그 종속성이 의도적이고, 가시적이며, 수용 가능한 비용으로 되돌릴 수 있는지입니다.

보안 및 거버넌스 격차는 테스트하기 가장 어려운 부분이다

멀티클라우드 AI의 가장 큰 위험은 극적인 장애가 아닙니다. 어떤 데이터, 모델, ID, 정책이 작업을 형성했는지 설명할 능력을 잃는 것입니다.

보안 팀은 오랫동안 클라우드 권한, 네트워크, 로그의 차이를 관리해 왔습니다. AI는 프롬프트, 검색된 컨텍스트, 모델 생성 콘텐츠, 자율적 도구 호출을 도입합니다. 각 요소는 시스템 경계를 넘어 민감한 정보를 전달할 수 있습니다.

프롬프트에는 고객 기록이나 내부 전략이 포함될 수 있습니다. 검색 서비스는 여러 저장소에서 발췌문을 조합할 수 있습니다. 모델 공급자는 해당 컨텍스트를 다른 지역에서 처리하거나 별도의 보존 조건에 따라 처리할 수 있습니다.

이후 애플리케이션은 응답을 이메일, 소스 제어, 재무 소프트웨어 또는 고객 시스템으로 보낼 수 있습니다. 최종 결과를 누군가 보기 전에 단일 요청이 여러 관리 도메인을 넘을 수 있습니다.

기존 접근 제어는 ID가 리소스를 호출할 수 있는지 확인합니다. AI 거버넌스는 특정 사용 사례가 특정 데이터와 모델을 결합해야 하는지도 고려해야 합니다. 또한 모델이 어떤 작업을 권고하거나 실행할 수 있는지도 평가해야 합니다.

이러한 차이는 정책 변환을 어렵게 만듭니다. Google Cloud, AWS, Azure, 프라이빗 환경은 각각 별도의 정책 엔진을 제공합니다. 한 플랫폼용으로 작성된 제한은 다른 곳의 동등한 서비스를 자동으로 포괄하지 않습니다.

같은 불일치는 감사 근거에도 영향을 줍니다. 규제 기관과 내부 검토자는 어떤 모델 버전이 기록을 처리했는지, 어떤 컨텍스트를 받았는지, 왜 도구가 실행됐는지를 물을 수 있습니다. 이러한 이력을 제시하려면 호환되는 식별자와 보존 기간을 갖춘 조정된 로그가 필요합니다.

모델 평가는 또 다른 격차를 만듭니다. 팀은 정의된 작업에 대해 모델이 정확하고 안전하며 신뢰할 수 있는지 테스트합니다. 통과 결과는 프롬프트, 검색 설정, 도구, 모델 버전을 포함한 특정 구성에만 적용됩니다.

공급자나 폴백 모델을 바꾸면 그 근거가 무효화될 수 있습니다. 공급자 측 모델 업데이트만으로도 주변 애플리케이션을 바꾸지 않고 동작이 달라질 수 있습니다. 멀티클라우드 라우팅은 평가가 필요한 구성의 수를 늘립니다.

CIO는 통합 제어에 관한 공급자 주장도 검증해야 합니다. 대시보드는 동일한 정책을 집행하지 않은 채 리소스를 집계할 수 있습니다. 커넥터는 중요한 모델 또는 데이터 컨텍스트를 누락한 채 활동을 표시할 수 있습니다.

독립적인 검증은 여전히 필수적입니다. 팀은 제어가 금지된 데이터 경로와 작업을 실제로 차단하는지 테스트해야 합니다. 또한 만료된 자격 증명, 사용할 수 없는 모델, 손상된 인덱스, 불완전한 로그와 관련된 장애도 리허설해야 합니다.

보안 복잡성은 조직 복잡성과 함께 증가합니다. 인수합병은 기존 클라우드 계정, ID 시스템, 데이터 분류 체계를 가져옵니다. SANS는 조직이 추가 클라우드 공급자를 도입한 주요 이유로 인수합병을 꼽았습니다.

AI 프로젝트가 통합된 회사 전체의 데이터를 찾는 경우가 많기 때문에 이러한 이력은 중요합니다. 새로운 어시스턴트는 시스템이 별도 부서를 지원하는 동안 숨겨져 있던 불일치를 드러낼 수 있습니다. 검색은 거버넌스 팀이 정책을 조율하는 속도보다 더 빠르게 저장소를 연결할 수 있습니다.

데이터 주권은 비슷한 긴장을 만듭니다. 기업은 필요한 관할권 내에 데이터를 유지하기 위해 지역별 클라우드를 사용할 수 있습니다. 그러나 AI 워크플로는 프롬프트, 텔레메트리 또는 평가 샘플을 의도한 경계 밖의 서비스로 라우팅할 수 있습니다.

계약과 아키텍처는 일치해야 합니다. 정책 문서는 문서화되지 않은 네트워크 경로를 보완할 수 없습니다. 마찬가지로 기술적으로 지역에 배포된 환경도 모델, 지원 접근, 하위 처리자에 관한 모든 법적 문제를 해결하지는 못합니다.

회의적인 결론은 현재 어떤 플랫폼도 이 작업을 없애지 못한다는 것입니다. 공급자는 제어, 로그, 통합 제품을 제공할 수 있습니다. 기업은 여전히 이러한 요소를 자사의 비즈니스 프로세스와 의무에 부합하는 근거로 결합할 책임이 있습니다.

표준화에도 한계는 있다. 기업은 모델 액세스를 위한 단일 게이트웨이를 요구할 수 있지만, 사용자는 외부 도구에 정보를 붙여 넣을 수 있다. 여러 모델을 승인할 수는 있지만, 제품 팀은 승인된 인터페이스로는 사용할 수 없는 기능을 발견할 수 있다.

따라서 거버넌스는 기술적 통제와 조달, 교육, 책임성을 결합해야 한다. 모든 실험을 차단하는 것은 비현실적이다. 모든 실험이 프로덕션 인프라가 되도록 허용하는 것 역시 똑같이 위험하다.

CIO는 파일럿을 위한 측정 가능한 종료 기준이 필요하다. 확장에 앞서 시스템에는 지정된 책임자, 승인된 데이터 범위, 문서화된 종속성, 평가 결과, 사고 대응 절차, 사용량 모니터링이 갖춰져야 한다. 또한 명확한 종료 경로도 마련돼야 한다.

이러한 요건은 일부 배포를 늦출 것이다. 그러나 나중에 어떤 팀도 영향력이 큰 의사결정이 어떻게 이뤄졌는지 재구성할 수 없다는 사실을 발견하는 것보다 그 지연의 비용은 적다.

Google News 경고 이후 CIO가 주시해야 할 사항

다음 단계에서는 멀티클라우드 AI가 거버넌스가 적용된 아키텍처가 될지, 아니면 관리되지 않는 엔터프라이즈 확산의 또 다른 층이 될지가 드러날 것이다.

첫 번째 신호는 표준화된 모델 및 에이전트 인터페이스의 확산이다. 기술적 호환성은 텍스트 생성 이상을 포괄해야 한다. 여기에는 도구 호출, ID 컨텍스트, 정책 결정, 추적, 평가, 오류 동작이 포함돼야 한다.

제공업체와 오픈소스 프로젝트가 유용한 표준으로 수렴한다면, 기업은 맞춤형 어댑터를 줄일 수 있다. 이는 신중한 멀티클라우드 AI의 근거를 강화할 것이다. 피상적인 API 호환성으로는 핵심 통합 문제가 그대로 남는다.

CIO는 벤더의 상호운용성 발표가 아니라 실제 워크로드 이동을 주시해야 한다. 신뢰할 수 있는 이식성 테스트는 권한, 품질 임계값, 로그, 복구 절차를 유지한 채 프로덕션과 유사한 애플리케이션을 제공업체 간에 이동시킨다.

두 번째 신호는 기업이 AI 제어 계층을 통합하는지 여부다. 관련 근거로는 줄어든 모델 게이트웨이 수, 공유 평가 서비스, 통합 인벤토리, 사업부 전반의 일관된 정책 집행 등이 있다.

통합은 조직이 실험을 관리형 플랫폼으로 전환하고 있음을 시사한다. 중복되는 게이트웨이, 벡터 스토어, 관측성 제품이 계속 증가한다면 ‘통합 지옥’이라는 주장을 뒷받침하게 된다.

지표는 도구의 수만이 되어서는 안 된다. 대규모 조직에는 여러 제품이 합리적으로 필요할 수 있다. 리더는 중복 기능, 지원되지 않는 연결, 정책 예외, 단일 AI 트랜잭션을 추적하는 데 필요한 시간을 측정해야 한다.

세 번째 신호는 에이전트 배포의 프로덕션 신뢰성과 비용 보고다. 제공업체는 계속해서 도입 설문조사를 발표하겠지만, CIO에게 필요한 것은 운영 지표다. 여기에는 사고 빈도, 응답 품질, 지연 시간, 개입 비율, 데이터 전송 사용량, 완료된 비즈니스 작업당 비용이 포함된다.

제공업체 다양성이 증가하는 동안 이러한 지표가 개선된다면, 공유 플랫폼이 복잡성을 억제하고 있는 것이다. 도입보다 비용과 사고가 더 빠르게 증가한다면, 멀티클라우드 선택은 가치보다 더 큰 부담을 만들고 있다.

Google News는 새로운 모델, 클라우드 파트너십, 상호운용성 기능에 관한 주장을 계속 노출할 것이다. CIO는 각 발표를 완전한 아키텍처 전략이 아니라 하나의 구성요소 결정으로 다뤄야 한다.

벤치마크 성능이 더 나은 모델도 또 하나의 ID 브리지와 평가 프로세스를 요구한다면 잘못된 추가 선택일 수 있다. 더 저렴한 엔드포인트도 데이터 이동, 엔지니어링, 모니터링, 컴플라이언스 작업을 계산에 넣으면 비용이 더 커질 수 있다.

기업은 복원력과 중복도 구분해야 한다. 여러 제공업체에서 동등한 워크로드를 실행하면 한 번의 장애에 대한 노출을 줄일 수 있다. 그러나 팀이 정기적으로 페일오버를 테스트하고 보조 경로가 허용 가능한 수준으로 작동하는지 검증할 때에만 복원력이 향상된다.

사용되지 않는 대체 경로는 복원력이 아니다. 검증되지 않은 종속성일 뿐이다. 같은 원칙은 모델 라우터, 백업 인덱스, 복제된 데이터 파이프라인에도 적용된다.

조달 과정에서는 서비스 승인과 함께 통합 예산을 요구해야 한다. 이 예산에는 인력, 테스트, 보안 검토, 관측성, 문서화, 최종 마이그레이션이 포함된다. 이는 도입이 서비스를 유지해야 한다는 내부 압력을 만들기 전에 지속 비용을 가시화한다.

아키텍처 검토에서는 제공업체가 모델을 변경하거나 기능을 중단할 때 어떤 일이 발생하는지도 물어야 한다. 팀은 어떤 프롬프트, 평가, 워크플로, 사용자가 영향을 받을지 식별해야 한다. 이러한 종속성 맵은 추상적인 종속 위험을 실행 가능한 리스크로 바꾼다.

적절한 전략은 워크로드마다 다를 것이다. 고가치 연구나 엔지니어링 작업은 여러 전문 모델에 대한 액세스를 정당화할 수 있다. 일상적인 직원 지원은 일관된 통제를 갖춘 좁고 표준화된 플랫폼에서 더 큰 이점을 얻을 수 있다.

CIO가 멀티클라우드 AI를 거부할 필요는 없다. 다만 이를 종속성에 대한 자동적 헤지로 취급하는 일을 멈춰야 한다. 다양성은 조직이 그 결과물인 시스템을 운영하고, 보호하고, 설명할 수 있을 때만 도움이 된다.

Google News를 통해 부각된 InformationWeek의 경고는 실질적인 선택을 가리킨다. 기업은 가장 강력해 보이는 곳마다 AI 서비스를 계속 추가할 수도 있고, 미래 운영을 보호하는 통합 경계를 정의할 수도 있다.

또 다른 제공업체를 승인하기 전에 리더는 한 가지 직접적인 질문을 던져야 한다. 이 서비스는 또 하나의 영구적인 제어 표면을 정당화할 만큼 측정 가능한 가치를 창출하는가? 답이 여전히 불분명하다면, 다음 통합은 미뤄야 한다.