AI툴이 클라우드 컴퓨팅을 "두 개의 시장"으로 쪼개고 있다

2026년 4월 현재, 기업의 클라우드 인프라를 들여다보면 이상한 현상이 보인다. 공식 조달 목록에 등록된 클라우드 서비스와, 실제로 워크로드를 처리하고 있는 클라우드 서비스가 점점 달라지고 있다는 것이다. 그리고 이 균열을 만드는 주범은 다름 아닌 AI툴이다.

"우리 회사는 AWS를 씁니다"라고 말하는 기업의 실제 인프라를 추적해보면, Azure OpenAI 엔드포인트, Pinecone 벡터 DB, Langchain 오케스트레이터, Anthropic API 호출이 뒤섞여 있다. 이것들은 누군가가 "AI툴 도입 검토"를 하면서 파일럿으로 붙인 것들이다. 그런데 파일럿은 끝났고, 인프라는 남았다.

이 글은 AI툴이 어떻게 클라우드 컴퓨팅 시장을 "공식 시장"과 "실질 시장"으로 분리하고 있는지, 그리고 그 분리가 기업에게 어떤 구조적 문제를 만드는지를 다룬다.

"공식 클라우드"와 "실질 클라우드"의 분리

전통적인 클라우드 거버넌스 모델은 단순했다. IT팀이 벤더를 선정하고, 계약을 맺고, 예산을 배정하면 그 범위 안에서 인프라가 운영됐다. 비용은 하나의 청구서로 왔고, 책임 소재는 명확했다.

AI툴이 등장하면서 이 모델이 무너졌다. 그런데 흥미로운 점은, 무너지는 방식이 극적이지 않다는 것이다. 조용하고, 단계적이고, 각각의 결정은 합리적으로 보인다.

한 팀이 GPT-4 API를 연결한다. 다른 팀이 RAG 파이프라인을 위해 벡터 DB를 붙인다. 데이터 팀이 임베딩 생성을 위해 별도 배치 잡을 돌린다. 각각의 결정은 "소규모 실험"이었다. 그런데 어느 순간 이것들이 서로 연결되어 하나의 생산 워크로드를 구성한다.

이때 공식 클라우드 계약서에는 이 구성요소들이 없다. 승인된 것은 기본 컴퓨트뿐이다. 실제로 작동 중인 것은 여러 벤더의 API, 스토리지, 오케스트레이션 레이어가 뒤엉킨 복합 시스템이다.

이것이 "두 개의 시장"이다. 하나는 CTO가 이사회에 보고하는 공식 클라우드 전략이고, 다른 하나는 실제 엔지니어들이 매일 사용하는 AI툴 기반의 실질 인프라다.

AI툴이 만드는 "보이지 않는 클라우드 레이어"

AI툴이 클라우드 인프라에 추가하는 레이어는 크게 다섯 가지다.

1. 추론 레이어 (Inference Layer) LLM API 호출이 발생하는 지점이다. GPT-4o, Claude 3.5, Gemini Pro 등 외부 모델 API를 호출하면 토큰 단위로 과금된다. 문제는 이 호출이 사용자의 명시적 요청 한 번에 그치지 않는다는 것이다. 에이전트 루프, 재시도 로직, 컨텍스트 확장이 추가 호출을 만든다. 사용자가 버튼을 한 번 눌렀지만, 백엔드에서는 7번의 API 호출이 발생했을 수 있다.

2. 검색 레이어 (Retrieval Layer) RAG 구조를 쓰는 AI툴은 반드시 벡터 검색 인프라를 필요로 한다. Pinecone, Weaviate, pgvector 등이 여기 해당된다. 이 레이어는 쿼리마다 과금되고, 인덱스 크기에 따라 스토리지 비용도 발생한다. 그리고 대부분의 경우, 이 인프라는 메인 클라우드 계약 밖에 있다.

3. 오케스트레이션 레이어 (Orchestration Layer) LangChain, LlamaIndex, Semantic Kernel 같은 프레임워크가 여러 AI 서비스를 연결한다. 이 오케스트레이션 자체는 컴퓨트를 소비하고, 각 연결 지점마다 데이터 이그레스(egress) 비용이 발생한다. 멀티 에이전트 시스템에서는 이 비용이 기하급수적으로 늘어날 수 있다.

4. 관찰성 레이어 (Observability Layer) AI툴의 동작을 추적하기 위한 로깅, 트레이싱, 모니터링 인프라다. LangSmith, Helicone, Weights & Biases 같은 도구들이 여기 해당된다. 이 레이어는 "AI툴을 제대로 쓰려면 필요하다"는 명목으로 도입되지만, 그 자체로 또 다른 SaaS 구독과 데이터 전송 비용을 만든다.

5. 재시도 및 폴백 레이어 (Retry & Fallback Layer) AI 에이전트는 실패하면 재시도한다. 이것은 기능이다. 그런데 재시도는 곧 추가 API 호출이고, 추가 토큰 소비이며, 추가 이그레스다. 특히 복잡한 에이전트 파이프라인에서 재시도 루프가 잘못 설계되면, 단일 실패가 수십 번의 청구 이벤트를 만들 수 있다.

이 다섯 레이어가 합쳐지면, 사용자가 경험하는 "AI툴 하나"의 실제 인프라 풋프린트는 훨씬 넓고 복잡하다. 그리고 이 풋프린트의 상당 부분은 공식 클라우드 계약 바깥에 있다.

## AI툴이 클라우드 시장 구조 자체를 바꾸는 방식

여기서 한 발 더 나아가 보자. AI툴이 만드는 이 분리는 단순히 기업 내부의 거버넌스 문제가 아니다. 클라우드 컴퓨팅 시장의 구조 자체를 바꾸고 있다.

전통적 클라우드 시장의 구조: 대형 하이퍼스케일러(AWS, Azure, GCP) → 기업 IT팀 → 내부 사용자

AI툴 시대의 실질 클라우드 구조: 하이퍼스케일러 + AI API 벤더 + 벡터 DB 벤더 + 오케스트레이션 SaaS + 관찰성 도구 → 개별 팀/개발자 → 내부 사용자

중간의 "기업 IT팀"이 조달과 거버넌스의 게이트키퍼 역할을 잃어버렸다. AI툴은 신용카드 하나로 즉시 연결 가능하고, 개발자가 직접 온보딩할 수 있도록 설계되어 있다. 이것은 의도된 제품 설계다.

네이버 검색시장 63.8%의 역설: AI 시대에 강해진 공룡의 진짜 약점에서도 다뤘듯, 기존 강자들이 AI 전환기에 오히려 구조적 취약성을 드러내는 패턴이 있다. 클라우드 시장도 마찬가지다. 하이퍼스케일러들은 AI 인프라 투자에서 앞서 있지만, 실제 기업의 AI툴 스택은 이미 멀티벤더·탈중앙화 방향으로 이동하고 있다.

Gartner의 2025년 클라우드 전략 보고서에 따르면, 기업의 멀티클라우드 채택률은 지속적으로 높아지고 있으며, 이 중 상당 부분이 계획된 전략이 아닌 AI툴 도입의 부산물로 발생하고 있다는 분석이 나오고 있다.

기업이 직면한 세 가지 구조적 균열

Computer screen displaying code with a context menu.

Photo by Daniil Komov on Unsplash

균열 1: 계약과 실제 사용의 불일치

기업이 클라우드 벤더와 맺은 계약은 예상 사용량을 기반으로 협상된다. 그런데 AI툴이 만드는 추가 인프라는 이 협상 테이블에 없었다. 결과적으로 약정 할인을 받지 못하는 온디맨드 과금이 늘어나고, 전체 클라우드 비용에서 "계약 외 지출"의 비중이 커진다.

이것이 내가 이전부터 강조해온 "계약 표류(Contract Drift)" 현상이다. 처음 서명한 계약서가 현재 인프라를 대표하지 못하게 되는 것이다.

균열 2: 보안 경계의 확장

공식 클라우드 계약에는 보안 요구사항, 데이터 처리 지역, 컴플라이언스 조건이 명시되어 있다. 그런데 AI툴이 연결하는 외부 API들은 이 경계 밖에 있다. 기업 데이터가 어떤 경로로 외부 LLM API에 전달되고, 그 과정에서 어떤 로그가 남는지 추적하지 못하는 경우가 많다.

GDPR, 국내 개인정보보호법 관점에서 이것은 단순한 기술 문제가 아니라 법적 리스크다.

균열 3: 비용 책임의 공백

AI툴이 생성하는 클라우드 비용은 특정 팀, 특정 프로젝트, 특정 의사결정자에게 귀속되지 않는다. 에이전트 재시도가 만든 API 호출 비용은 누구의 예산에서 나가야 하는가? 이 질문에 답할 수 있는 기업이 많지 않다.

AI툴 시대의 클라우드 거버넌스: 실무 적용 가능한 접근법

이 문제를 해결하기 위한 완벽한 솔루션은 아직 없다. 다만, 지금 당장 적용할 수 있는 접근법은 있다.

1. "AI툴 인벤토리"를 별도로 만들어라

공식 소프트웨어 자산 목록과 별개로, 현재 사용 중인 AI툴과 그것이 연결하는 외부 서비스를 목록화해야 한다. 이 목록은 IT팀이 아니라 각 팀의 실제 개발자들과 함께 만들어야 현실을 반영할 수 있다.

2. 비용 태깅을 AI툴 단위로 적용하라

AWS Cost Explorer, Azure Cost Management, GCP Billing의 태깅 기능을 활용해 각 AI툴 또는 AI 파이프라인에서 발생하는 비용을 추적해야 한다. 이때 컴퓨트, API 호출, 이그레스, 스토리지를 모두 포함해야 실제 비용이 보인다.

3. 에이전트 재시도 로직에 비용 한도를 설정하라

AI 에이전트의 재시도 횟수와 폴백 경로에 명시적인 비용 한도를 설정하는 것이 필요하다. 기술적으로는 간단하지만, 대부분의 팀이 이것을 "나중에 할 일"로 미룬다. 지금 해야 한다.

4. 외부 AI API 연결에 대한 보안 리뷰 프로세스를 만들어라

새로운 AI툴이나 외부 API 연결이 생길 때마다 최소한의 보안 체크리스트를 통과하도록 해야 한다. 데이터 처리 지역, 로그 보존 정책, 데이터 공유 조건을 확인하는 것이 핵심이다.

5. 분기별 "AI 인프라 리뷰"를 제도화하라

AI툴 스택은 빠르게 변한다. 분기에 한 번, 현재 사용 중인 AI 인프라 전체를 검토하고, 더 이상 필요하지 않은 연결을 정리하는 프로세스가 필요하다. 이것은 비용 최적화이기도 하고, 보안 위생이기도 하다.

두 개의 시장이 하나로 합쳐지려면

블룸하우스 창업자가 Meta와 손잡고 "뭇매"를 맞은 뒤 내린 결론: AI Hollywood의 진짜 전쟁터는 극장이 아니다에서도 볼 수 있듯, AI가 기존 산업의 경계를 허무는 방식은 종종 예상치 못한 곳에서 시작된다. 클라우드 컴퓨팅도 마찬가지다. AI툴이 만든 "두 개의 시장"은 결국 하나로 통합될 것으로 보인다. 다만 그 통합이 기업이 원하는 방향으로 이루어지려면, 지금부터 실질 인프라를 가시화하는 작업이 선행되어야 한다.

현재 클라우드 벤더들도 이 문제를 인식하고 있는 것으로 보인다. AWS의 Bedrock, Azure의 AI Foundry, GCP의 Vertex AI는 모두 "AI툴 인프라를 하이퍼스케일러 안으로 끌어들이려는" 전략으로 읽힌다. AI API, 벡터 DB, 오케스트레이션, 관찰성 도구를 하나의 플랫폼 안에 통합함으로써, 흩어진 AI 인프라를 다시 공식 계약 안으로 가져오려는 시도다.

이 전략이 성공할지는 아직 불분명하다. 개발자들은 특정 벤더에 종속되는 것을 꺼리고, AI툴 생태계는 오픈소스와 멀티벤더 방향으로 계속 진화하고 있기 때문이다.

결국 기업이 해야 할 일은 하나다. 지금 이 순간에도 조용히 확장되고 있는 "실질 클라우드"를 직시하고, 그것을 거버넌스 안으로 끌어들이는 작업을 시작하는 것이다. AI툴은 강력하고 유용하다. 그러나 그 유용함이 지속되려면, 우리가 그것을 제대로 볼 수 있어야 한다.

보이지 않는 인프라는 관리할 수 없다. 관리할 수 없는 인프라는 결국 비용이 되고, 리스크가 되고, 책임 공백이 된다. 지금 당신의 클라우드 청구서 안에 몇 개의 AI툴이 숨어 있는지 아는가? 그 질문에 답하는 것이 시작이다.

NOCODE TECH STACKER