“OpenAI 모델이 Google Cloud에서 쓸 수 있게 됐다”는 제목만 보면 오늘부터 누구나 GPT-6를 Google Cloud에서 호출할 수 있을 것 같습니다. 실제 발표는 그보다 좁습니다. Google Cloud는 2026년 10월 21일, OpenAI의 GPT-6 Astra·GPT-6.1 Sol·GPT-6 Luna와 Codex agentic workflow를 Model Garden에 추가한다고 밝혔습니다. 다만 일반 제공이 아니라 선택된 enterprise 고객을 대상으로 한 private preview입니다. 일반 제공은 “향후 몇 주”로 예정돼 있습니다.
이 글에서 중요한 것은 모델 이름이 아닙니다. 모델을 어디서 사고, 어떤 계정과 감사 체계로 접근하고, 데이터가 어디를 지나며, 장애가 났을 때 누가 책임지는가입니다. 이번 발표는 그 질문의 일부만 답합니다.
확인된 사실
OpenAI와 Google Cloud의 발표를 교차하면 다음 범위가 확인됩니다.
| 항목 | 내용 | 출처 |
|---|---|---|
| 발표일 | 2026년 10월 21일 | 양사 발표 |
| 모델 | GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna | Google Cloud |
| 워크플로 | Codex agentic workflow | 양사 발표 |
| 제공 단계 | 선택된 enterprise 고객 대상 private preview | Google Cloud |
| 일반 제공 | “향후 몇 주” 예정, 구체 날짜 없음 | OpenAI |
| 과금 | Google Cloud Marketplace, GCP 약정 차감 | Google Cloud |
| 접근 경로 | Google Cloud API, 로컬 Codex CLI·Desktop에서 Gemini platform으로 추론 연결 | Google Cloud |
| 데이터 거버넌스 | 지정된 data perimeter, foundation model 학습에 미사용, ZDR 옵션은 “coming soon” | Google Cloud |
| 격리 | 전용 Google Cloud 인프라, isolated gateway, Confidential Compute는 “coming soon” | Google Cloud |
| 감사·신원 | 인증된 identity, VPC Service Controls, 통합 audit logging | Google Cloud |
| Microsoft 관계 | Microsoft는 OpenAI의 primary cloud partner | OpenAI |
Google Cloud는 “세계 주요 closed-source LLM 세 곳을 모두 제공하는 유일한 hyperscale cloud”라고 주장합니다. 이는 Google의 자기 평가입니다. 이 글에서는 모델 품질이나 시장 점유율을 독립적으로 검증하지 않았습니다.
private preview와 일반 제공은 다르다
이번 발표에서 가장 먼저 확인할 것은 “내 계정에서 실제로 사용할 수 있는가”입니다. Google Cloud는 private preview라고 명시합니다. OpenAI는 일반 제공이 몇 주 안에 예정돼 있다고 합니다. 두 문장을 합치면 “지금은 제한된 고객만, 곧 더 넓게”입니다.
여기에 더해 확인되지 않은 항목이 있습니다.
- 세 모델 모두가 모든 private preview 고객에게 제공되는지
- 리전과 데이터 상주 요구사항
- 가격, rate limit, quota, SLA
- Codex workflow의 기능 범위와 기존 OpenAI 직접 사용과의 차이
- Google Cloud API와 Codex CLI·Desktop 경로의 지원 주체
- 모델 deprecation 정책과 버전 고정 방식
- 장애 발생 시 Google Cloud와 OpenAI 사이의 support 경계
두 발표문에는 이 항목들이 없습니다. “일반 제공 예정”을 “오늘부터 전 세계 제공”으로 바꿔 읽으면 안 됩니다.
조달 구조가 바뀌는 지점
기술적으로는 같은 OpenAI 모델을 호출할 수 있습니다. 하지만 구매 경로가 Google Cloud Marketplace로 들어오면 enterprise의 예산과 승인 흐름이 달라집니다.
| 질문 | Google Cloud 경유 | 확인할 점 |
|---|---|---|
| 계약 | Google Cloud Marketplace | 기존 OpenAI 계약과 충돌하지 않는가 |
| 예산 | GCP 약정 차감, Flexible Savings Plans 적용 | 실제 할인율과 적용 범위 |
| 청구 | Google Cloud 청구서 | 비용 센터·태그·예산 알림 |
| 신원 | Google Cloud identity | 기존 IAM·SSO와 어떻게 매핑되는가 |
| 감사 | VPC-SC, audit logging | 기존 SIEM으로 어떤 형식으로 나오는가 |
| 데이터 | designated data perimeter | 리전, 보존, ZDR 옵션의 실제 제공 시점 |
| 지원 | Google Cloud 지원과 OpenAI 지원 | 장애·모델 문제의 책임 경계 |
약정 차감은 매력적이지만 공짜는 아닙니다. 이미 GCP에 약정을 쓰고 있다면 예산 회계가 단순해질 수 있습니다. 반대로 Azure나 다른 클라우드에 약정이 집중돼 있다면 새로운 거버넌스와 egress 경로를 하나 더 만드는 비용이 생깁니다. “한 장의 청구서”가 “한 개의 운영 체계”를 뜻하지는 않습니다.
데이터 경계는 발표문과 검증 사이가 있다
Google Cloud는 고객의 prompt, context, output이 지정된 data perimeter 안에 머물고 foundation model 학습에 사용되지 않는다고 설명합니다. 또한 OpenAI 모델이 전용 Google Cloud 인프라에서 실행되고, hardened isolated gateway를 통해 라우팅되며, 제3자 모델 제공자가 고객 클라우드 환경에 무단 접근하지 않는다고 합니다.
이는 중요한 설계 주장이지만, 도입 전에 확인할 질문이 남습니다.
- data perimeter의 실제 경계는 리전인가, VPC인가, 프로젝트인가.
- 로컬 Codex CLI·Desktop에서 Gemini platform으로 연결할 때 데이터는 어느 경로를 지나는가.
- ZDR이 “coming soon”인 동안 기본 보존 기간은 얼마인가.
- Confidential Compute가 “coming soon”인 동안 격리는 무엇으로 보장되는가.
- Google Cloud의 audit log와 OpenAI의 모델 로그가 어떻게 결합되는가.
- 모델 제공자의 인력이 고객 데이터에 접근할 수 있는 운영 절차가 있는가.
이 질문에 대한 답은 두 발표문만으로는 부족합니다. 계약서, 데이터 처리 부속서, 보안 문서, 실제 파일럿 로그를 함께 봐야 합니다.
비용을 비교하는 공식
가격이 공개되지 않았기 때문에 “Google Cloud가 더 싸다/비싸다”고 말할 수 없습니다. 대신 비교표를 다음 변수로 만들 수 있습니다.
effective_cost =
model_usage
+ data_egress
+ platform_operations
+ integration_engineering
+ compliance_review
- committed_spend_offset
committed_spend_offset은 GCP 약정을 이미 쓰고 있을 때만 의미가 있습니다. 약정이 없는데 “차감된다”는 이유로 새로운 약정을 만들면, 할인처럼 보이는 비용이 실제로는 추가 약속이 됩니다. 모델 사용료, egress, 운영 인력, 보안 검토를 같은 기간으로 놓고 비교해야 합니다.
또한 모델 단가만 비교하면 Codex workflow의 가치가 빠집니다. Codex가 기존 OpenAI 환경과 동일한 기능을 Google Cloud에서 제공하는지, 아니면 일부 기능이 빠지는지에 따라 실제 작업 비용이 달라집니다. 이 부분은 발표문에 기능 매트릭스가 없습니다.
아키텍처: 확인된 경로와 모호한 경로
공개된 설명을 최대한 보수적으로 그리면 다음과 같습니다.
개발자 / enterprise workload
│
├─ Google Cloud API
└─ 로컬 Codex CLI · Desktop
│
Google Cloud의 인증·감사·VPC 경계
│
Gemini platform / Model Garden
│
전용 Google Cloud 인프라의 OpenAI 모델
Google Cloud는 “OpenAI 모델이 전용 Google Cloud 인프라에서 실행된다”고 말합니다. 그러나 요청이 정확히 어떤 gateway를 거쳐 어느 리전에서 처리되는지, Codex CLI·Desktop 경로가 같은 감사 로그를 남기는지는 발표문에 자세히 나오지 않습니다. 다이어그램을 그릴 때 “확인된 경로”와 “확인되지 않은 경로”를 구분해야 하는 이유입니다.
도입 전 파일럿 체크리스트
- 민감하지 않은 워크로드 하나를 골라 기존 제공자와 같은 입력으로 품질·지연·비용을 비교합니다.
- Google Cloud 프로젝트, IAM, VPC-SC, audit sink를 기존 거버넌스에 연결합니다.
- 모델 버전과 API 엔드포인트를 고정할 수 있는지 확인합니다.
- Codex CLI·Desktop 경로에서 인증과 데이터 흐름을 점검합니다.
- ZDR과 Confidential Compute가 실제로 제공되기 전까지의 보존·격리 정책을 문서화합니다.
- rate limit, quota, 장애 대응, support escalation 경로를 확인합니다.
- 기존 OpenAI 직접 계약과 Google Cloud Marketplace 계약의 중복·충돌을 정리합니다.
- 특정 클라우드에 종속되지 않도록 모델 추상화 계층과 fallback 경로를 설계합니다.
특히 “모델을 바꿔도 아키텍처를 바꾸지 않아도 된다”는 말은 조심해야 합니다. 모델 API가 비슷해도 인증, 과금, 감사, 데이터 경계, 도구 호출 방식은 다를 수 있습니다. 추상화 계층은 편의를 주지만, 제공자별 기능 차이를 숨겨 장애 시 원인을 늦출 수도 있습니다.
결론: 모델 출시가 아니라 조달 옵션의 추가
OpenAI 모델의 Google Cloud 진입은 기업에게 새로운 구매 경로를 줍니다. GCP 약정을 이미 쓰는 조직에는 매력적일 수 있고, Microsoft를 primary partner로 유지하는 OpenAI의 구조 안에서 멀티클라우드 선택지를 넓히는 움직임입니다.
하지만 지금 단계에서 확인할 것은 “GPT-6를 Google Cloud에서 쓸 수 있나”가 아닙니다. private preview 대상인지, 일반 제공일이 언제인지, 가격과 리전과 SLA가 무엇인지, 데이터 경계가 계약서에 어떻게 반영되는지, Codex workflow가 기존 환경과 같은 기능을 제공하는지입니다.
이 질문에 답하기 전에는 “멀티클라우드 전략”이 아니라 “또 하나의 조달 채널”로 보는 편이 안전합니다. 파일럿은 작게 시작하고, 같은 워크로드로 비교하고, 계약과 감사 로그까지 확인한 뒤 확장하세요.
함께 읽으면 좋은 글
- Bedrock Managed Agents × OpenAI: 에이전트 하네스가 클라우드 인프라가 된다
- OpenAI Agents API란? Codex 하네스를 API로 쓰는 시대
- OpenAI CLI v1.40.0: 새 도구가 아니라 API 작업을 셸에 고정하는 방법
참고 자료
- OpenAI: OpenAI models are coming to Google Cloud (2026-10-21)
- Google Cloud: Google Cloud brings OpenAI models to customers (2026-10-21)
이 주제를 직접 따라가며 배우고 싶다면
클라우드에서 모델을 고르는 일은 결국 agentic workflow를 어떻게 설계하고 검증할지의 문제로 이어집니다. Codex 같은 실행 흐름을 직접 구성해 보고 싶다면 이 강의가 출발점이 될 수 있습니다.