이미 Google Cloud billing 을 가지고 있었습니다. 다른 API 키, 다른 할당량 표 (quota surface), 그리고 팀에게 코딩 도구 청구서가 어디에 표시되는지 설명해야 하는 또 다른 장소는 원하지 않았습니다. 귀찮은 점은 Claude Code 가 Anthropic 의 Messages API 를 사용하지만, 사용하고 싶은 예산이 Vertex AI 에 놓아 있다는 점입니다. 그래서 저는 두 가지를 로컬 게이트웨이 (local gateway) 를 통해 연결했습니다. 불일치 (mismatch) 직접 Vertex AI 에 Claude Code 를 연결하려고 하면, 형식이 깔끔하게 맞지 않습니다. Claude Code 는 다음과 같은 세계를 기대합니다: POST /v1/messages Anthropic 헤더 Anthropic 콘텐츠 블록 Anthropic 스트리밍 의미론 (semantics) Vertex AI 는 다른 세계입니다. Vertex 의 Claude 모델의 경우 요청은 다음과 같은 퍼블리셔 엔드포인트로 가집니다: .../publishers/anthropic/models/claude-sonnet-4-6:rawPredict Vertex 의 Gemini 모델의 경우 다음과 같습니다: .../publishers/google/models/gemini-2.5-pro:generateContent 이는 중간에 Claude Code 를 그대로 받아들이고, 다른 쪽에서 Vertex 와 어떻게 대화할지 결정해야 하는 것을 의미했습니다. 제가 사용한 것 저는 CliGate 를 사용했습니다. 이미 Claude Code, Codex CLI, Gemini CLI, 그리고 여러 상위 제공자 (upstream providers) 사이에 위치한 로컬 게이트웨이입니다. 이 설정에 유용한 부분은 Vertex AI 가 동일한 라우팅 레이어 내의 다른 API 키 기반的上游 (API-key-backed upstream) 임이라는 점입니다. 이 프로젝트에서 Vertex 키는 세 가지 중요한 것을 저장합니다: type: vertex-ai projectId location 그리고 apiKey 필드는 전체 Google 서비스 계정 JSON 을 포함할 수 있습니다. 5 분 설정 1. 게이트웨이 시작 npx cligate@latest start 기본 대시보드: http://localhost:8081 2. Vertex AI 를 API 키 제공자로 추가 대시보드에서 할 수 있거나 직접 POST 하세요: curl -X POST http://localhost:8081/api/keys \ -H "Content-Type: application/json" \ -d '{ "type": "vertex-ai", "name": "vertex-work", "apiKey": "{"type":"service_account","project_id":"my-project", ... }", "projectId": "my-project", "location": "us-central1" }' 이 API 키 값은 이상해 보일 수 있습니다. 이는 일반적인 API 키 문자열이 아니기 때문입니다. CliGate 에서 Vertex AI 에서는 전체 서비스 계정 JSON blob 일 수 있습니다. 3. Claude Code 를 localhost 로 지시 export ANTHROPIC_BASE_URL = http://localhost:8081 export ANTHROPIC_API_KEY = any-key claude 이제 Claude Code 는 Anthropic 호환 서버와 대화하고 있다고 생각합니다. 맞습니다. 그 서버는 실제로 Vertex AI 가 상위 제공자 (upstream) 라고 결정합니다. 이를 수행하게 만든 부분 이 설정의 좋은 점은 Claude Code 자체를 패치할 필요가 없었습니다. Claude Code 는 A 를 계속 보냅니다.
Anthropic 스타일의 요청을 POST /v1/messages CliGate 는 모델과 선택된 제공자를 검사한 후 두 가지 경로 중 하나를 따릅니다: Claude Code -> /v1/messages -> CliGate -> Vertex Claude rawPredict 또는: Claude Code -> /v1/messages -> CliGate -> Vertex 에 대한 Anthropic-to-Gemini 브리지
두 번째 경로는 흥미로운 부분입니다. 제공자 코드는 모델 가족에 따라 Vertex 를 다르게 처리합니다: claude-* 모델은 Vertex 에서 Anthropic 스타일의 경로를 유지하며, gemini-* 모델은 Gemini generateContent 로 번역됩니다.
따라서 하나의 로컬 진입점은 Claude-on-Vertex 와 Gemini-on-Vertex 사이를 전환할 수 있으며, Claude Code 는 새로운 프로토콜을 학습할 필요가 없습니다. 프로젝트가 처리한 미묘한 디테일은 여기 있습니다: 위치 . Vertex AI 는 모든 모델 가족을 동일하게 취급하지 않습니다. CliGate 의 제공자 구현에서 Gemini 는 Google publisher 엔드포인트를 사용할 수 있지만, Vertex 상의 Claude 모델은 여전히 Anthropic publisher 경로를 필요로 하며 지역별 처리도 중요합니다.
따라서 저장된 설정은 두 가지 모두 보유합니다: projectId location
저에게 이는 "도식에서 작동" 과 "CLI 가 답변할 때 11 시에 작동하는 것" 사이의 차이였습니다. 왜 다른 직접 통합보다 이 방식을 선호했는지 저는 Claude Code + Vertex AI 전용 일회용 래퍼를 구축할 수 있었습니다. 그것은 오늘의 문제를 해결하고 내일의 혼란을 만들었을 것입니다.
로컬 게이트웨이 접근 방식이 더 좋았으며, 동일한 컨트롤 플랜은 이미 다음을 처리합니다: Claude Code Codex CLI Gemini CLI API 키 라우팅 계정 풀 사용량 및 가격 보기
따라서 Claude Code 를 GCP 크레딧에 이동시키면 별도의 설정 경로를 생성하지 않습니다. 이는 이미 사용하고 있는 시스템 내의 하나의 라우팅 규칙이 되었습니다.
이 설정이 실제적으로 무엇을 얻어내는지 프록시가就位한 후 워크플로우가 가장 좋은 방식에서 지루해집니다: Claude Code 는 여전히 http://localhost:8081 을 가리킵니다. Vertex AI 는 실제 청구 표면을 보유하며, 대시보드에는 요청 로그, 사용량 및 제공자 가시성이 유지됩니다.
나중에 모델이나 제공자를 교체할 수 있으며 CLI 를 다시 연결할 필요가 없습니다. 마지막 부분은 들리는 것보다 더 중요합니다. 저는 도구가 돈이 어디서 오는지 알고 싶지 않습니다. 저는 도구가 게이트웨이 위치를 알고 싶어합니다.
이미 GCP 크레딧을 가지고 있다면, 이것이 제가 찾은 가장 쉬운 방법입니다. 팀이 이미 Google Cloud 를 실행 중이라면 Claude Code 가 다른 독립적인 Anthropic 키 대신 Vertex AI 를 소비하는 것은 거의 프로토콜 번역 문제입니다. 이 번역이 localhost 에 자리 잡으면 나머지 설정
작아집니다. 리포지토리: GitHub 의 CliGate
이 분할을 어떻게 처리하는지에 대해 다른 사람들이 어떻게 접근하고 있는지 궁금합니다:
Claude Code 를 Vertex 에 직접 연결하시나요?
또는 하나의 로컬 게이트웨이 뒤에 제공자 전환을 숨기시나요?