Chiko IT
클라우드 & SaaS

Google $40B Anthropic 투자, 결국 클라우드 종속 비용이다

Chiko
10min read

목차

Vertex AI Claude는 Google Cloud의 모델 게이트웨이를 통해 Anthropic Claude를 호출하는 서비스다. 직접 Anthropic API를 부르는 것과 달리, GCP 프로젝트의 인증·청구·로깅 체계 안에서 동작한다. 사내 GCP 자산이 이미 있는 팀이 Claude를 도입할 때 가장 먼저 검토하는 경로다.

오늘 사내 챗봇 vendor 정리를 끝낸 직후 Google의 추가 투자 뉴스를 봤다. 두 가지가 머릿속에서 한 번에 묶이면서, "단순한 SDK 선택"으로 보였던 게 다르게 보였다. 그 메모를 남긴다.

오늘 한 것 — Vertex AI Claude vendor 결정

그러나, 사내 어시스턴트가 PoC를 졸업하고 정식 트래픽을 받기 시작했다. 기존엔 Anthropic 직접 API로 돌렸는데, 본격 운영으로 가면서 게이트웨이를 어디로 둘지 정리할 필요가 있었다. 트래픽이 작을 땐 직접 호출이 깔끔하지만, 사내 청구·감사 표준에 묶이는 순간 결이 달라진다.

세 가지 후보를 정리했다.

경로 인증 청구 신모델 도착 시차 비고
Anthropic Direct API Key 카드/송장 가장 빠름 자체 보안 검토 필요
Vertex AI Claude GCP IAM GCP 청구 통합 며칠 지연 GCP 자산과 결합
AWS Bedrock Claude IAM Role AWS 청구 통합 며칠 지연 AWS 자산과 결합

물론, 같은 리전 기준으로 직접 호출과 게이트웨이 호출의 레이턴시 차이는 체감상 수십 ms 수준이다. 부하 시간대마다 흔들려서 단정하기는 어렵다. 운영 안정성을 정량 비교하려면 분기 단위 모니터링이 필요한데, 그건 다음 분기에 붙일 일이다.

회의 결론은 Vertex AI였다. GCP 청구가 이미 잡혀 있고, IAM으로 사용량 제한 거는 게 운영팀에 익숙했다. 여기까지는 평범한 의사결정이다. 새로운 건 그다음에 나왔다.

새로 알게 된 것 — 투자가 아니라 컴퓨트 락인이다

한편, 회의 끝나고 Google 투자 보도를 다시 읽었다. 2026년 4월 기준 Google이 Anthropic에 $40B 규모의 추가 투자를 발표한 것으로 알려져 있다(공식 수치는 시점에 따라 갱신되니 원문 릴리즈를 함께 확인하는 게 안전하다). 핵심은 금액이 아니라 구조다. 현금에 컴퓨트 크레딧이 섞여 있다.

Amazon 사례를 참고하면 이 구조가 더 분명해진다. 보도들에 따르면 Amazon은 2023~2024년에 걸쳐 Anthropic에 총 $8B 수준을 약속했고, Anthropic은 그 이후 AWS Trainium·Inferentia 기반 컴퓨트에 큰 규모를 지출한 것으로 알려져 있다. 외부에서 자주 인용되는 "$100B 수준의 지출" 같은 숫자는 공식 수치가 아니라 추정치다. 자본 흐름의 방향을 보는 용도로만 참고하는 게 맞다.

핵심은 이거다. 모델 회사가 받는 자본의 상당 부분은 그 클라우드의 가속기 비용으로 다시 빠져나간다. 받는 쪽은 자본을, 주는 쪽은 락인을 가져간다는 게 이번에 새로 든 정리다.

그래서 사용자에게 무슨 일이 생기나

자본이 한쪽으로 깊게 묶이면, 그 클라우드 위 게이트웨이가 신모델 적용·가격 협상·SLA에서 우대받을 가능성이 있다. 반대편 게이트웨이는 모델 출시가 며칠 늦거나, 일부 인프라성 기능(컨텍스트 캐싱·배치 API·확장된 툴 사용 같은 것)이 시차를 두고 들어온다. 이 패턴은 Bedrock에 일부 신기능이 늦게 들어왔던 시기에도 관찰된 적이 있다.

지금은 이 차이가 작다. 신모델 도착 시차가 며칠 단위, 기능 시차도 분기 단위에 머문다. 다만 자본 흐름이 한쪽으로 더 치우치면 시차가 주 단위·분기 단위로 벌어질 가능성이 있다. 그때 가서 게이트웨이를 갈아끼우면 코드보다 주변부에서 시간이 흐른다.

프론트엔드 시절엔 가볍게 봤다

결국, 전환자 입장에서 비교해보면, 프론트엔드 라이브러리 락인은 보통 NPM 한 번 갈아끼우면 끝나는 수준이었다. 백엔드에 넘어와 LLM 인프라를 보니, 인증·청구·네트워크 규칙·감사 파이프라인까지 묶이는 락인은 결이 다르다. SDK가 아니라 주변부가 락인이다. 이거 왜 아무도 미리 안 알려주는지 좀 의아했다.

코드 — SDK는 비슷한데 주변부가 다르다

게이트웨이를 바꾸면 코드가 얼마나 바뀌는지 실제로 비교해봤다.

# Vertex AI Claude 호출
from anthropic import AnthropicVertex

client = AnthropicVertex(
    region="asia-northeast3",
    project_id="my-proj",
)

resp = client.messages.create(
    model="claude-sonnet-4-5@20250929",  # Vertex 모델 ID는 버전 suffix가 붙는다
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}],
)

예를 들어, 직접 API로 옮기면 인증·리전·모델 ID가 한꺼번에 바뀐다.

# Anthropic Direct 호출
from anthropic import Anthropic

client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

resp = client.messages.create(
    model="claude-sonnet-4-5",  # 표준 모델 ID
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}],
)

코드만 보면 import 한 줄과 모델 ID 표기 차이로 보인다. 그런데 실제 이전에는 IAM에서 API Key 관리로 옮기는 보안 검토, GCP 청구에서 카드 청구로 옮기는 재무 검토, VPC Service Controls처럼 GCP에 결합된 네트워크 규칙 분리, 로그·감사 파이프라인 재배선이 따라붙는다. 의존성 트리도 달라진다. Vertex 경로는 google-auth·google-cloud-aiplatform 계열이 같이 깔리고, 직접 경로는 그 계열이 빠진다. 컨테이너 이미지 크기와 콜드 스타트가 달라진다는 뜻이다.

게다가, 체감상 PoC 코드 마이그레이션은 반나절이지만, 운영 전환은 몇 주 단위로 보는 게 맞다(환경마다 편차가 크다). 이게 진짜 락인 비용이다. SDK가 아니라 주변부다.

메모 — 지금 할 수 있는 것

게다가, 세 가지가 떠올랐다.

먼저, 모델 ID와 클라이언트 인증을 한 군데로 모으는 얇은 어댑터다. SDK 자체는 비슷해도 모델 ID 표기 규칙이 게이트웨이마다 다르고, 인증 객체도 다르다. 한 군데로 모아두면 게이트웨이 갈아끼우는 비용이 SDK 한 줄 수준으로 떨어진다.

# adapters/llm.py
import os

def get_client(provider: str):
    if provider == "vertex":
        from anthropic import AnthropicVertex
        return AnthropicVertex(
            region=os.environ["VERTEX_REGION"],
            project_id=os.environ["GCP_PROJECT"],
        )
    if provider == "direct":
        from anthropic import Anthropic
        return Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
    if provider == "bedrock":
        from anthropic import AnthropicBedrock
        return AnthropicBedrock(aws_region=os.environ["AWS_REGION"])
    raise ValueError(provider)

# 게이트웨이별 모델 ID 표기 차이를 한 장에 모아둔다
MODEL_MAP = {
    "vertex":  "claude-sonnet-4-5@20250929",
    "direct":  "claude-sonnet-4-5",
    "bedrock": "anthropic.claude-sonnet-4-5-v1:0",
}

실제로, 두 번째는 신규 기능 의존도 점검이다. 컨텍스트 캐싱, 배치 API, 툴 사용 같은 비교적 신규 기능들은 게이트웨이별로 시차가 있다. 우리 서비스가 이 기능에 강하게 묶여 있으면, 그 게이트웨이 종속이 더 깊어진다는 뜻이다. 종이 한 장으로 정리해두면 다음 분기 검토가 훨씬 빠르다.

또한, 세 번째는 청구 라벨 분리다. GCP 청구에 LLM 비용이 일반 컴퓨트와 섞이면 나중에 게이트웨이 비교가 어렵다. 라벨/태그로 분리해두는 것만으로도 다음 의사결정의 근거 데이터가 쌓인다. 분기 결산에서 "Vertex로 옮긴 뒤 토큰당 단가가 어떻게 바뀌었나"를 추적하려면 이 라벨이 있어야 한다.

게다가, :::tip 어댑터·기능 매트릭스·청구 라벨, 셋 중 가장 먼저 손댈 곳은 어댑터다. 코드 변경 한 번이면 끝나고, 나머지 둘이 늦어지더라도 어댑터만 있으면 출구는 일단 열어둔 셈이다. :::

예를 들어, 여담이지만, 프론트엔드 라이브러리 락인은 잘못 들어가도 회사 단위로는 큰 사고가 잘 안 났다. 백엔드에 와서 보면 청구·보안·네트워크가 한꺼번에 묶여서, "락인 비용"이라는 말이 단순한 비유가 아니라 진짜 청구서로 찍히는 게 보인다.

따라서, 다만 이번 투자 구조의 영향이 실제 게이트웨이별 기능·가격 격차로 드러나려면 시간이 더 필요해 보인다. 작성 시점(2026-04-29) 기준으로는 모델 출시 시차가 며칠 단위라 지금 당장의 비용은 크지 않다. 자본 흐름이 더 치우친 다음에 어댑터를 만들면 늦으니, 지금 시점엔 어댑터 한 장 끼워두는 게 합리적인 액션으로 보인다. 영향이 어디까지 번질지는 더 지켜봐야 한다.

참고: Anthropic Vertex AI 공식 문서, Google Cloud Vertex AI Model Garden 릴리즈 노트.

관련 글

More posts