OpenAI 모델도 Google Cloud 청구서로, 구매 전에 확인할 것

이미 Google Cloud를 쓰는 기업이라면 OpenAI 모델을 도입할 때 구매 절차를 줄일 여지가 생겼습니다. OpenAI와 Google Cloud가 10월 21일 발표한 협력에 따라, Model Garden에서 OpenAI 모델을 선택하고 Marketplace를 통해 구매하는 경로가 마련됩니다. 사용료는 Google Cloud 청구서에 모이고 기존 클라우드 지출 약정에도 반영됩니다. OpenAI 공식 발표

다만 지금 누구나 쓸 수 있는 서비스는 아닙니다. 현재는 일부 기업을 대상으로 한 비공개 프리뷰입니다. OpenAI는 발표 시점 기준 향후 몇 주 안에 일반 제공할 계획이라고 밝혔지만, 구체적인 날짜는 제시하지 않았습니다.

OpenAI 공식 발표의 날짜·제목 부분을 직접 캡처했습니다. 발표일은 10월 21일, 화면 확인일은 10월 23일입니다. 원문

기존 예산을 쓸 수 있어도, 더 싼지는 따져봐야 합니다

Google이 소개한 대상 모델은 GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna입니다. 이미 Google Cloud 예산을 확보한 팀에는 그 예산으로 OpenAI 모델까지 검토할 수 있다는 점이 중요합니다. 별도 구매 절차의 부담을 줄일 수 있을지는 회사의 계약과 내부 승인 방식에 달려 있습니다. Google Cloud 발표

비용을 계산할 때는 ‘약정에 반영되는 금액’과 ‘할인받는 금액’을 구분해야 합니다. Google은 이번 모델 사용이 Flexible Savings Plans(FSP)에도 산입된다고 설명합니다. 하지만 FSP 공식 문서는 제3자 제품에 FSP 추가 할인이 적용되지 않는다고 명시합니다. 기업 지출 약정에 반영되는 범위에도 Marketplace 규칙과 개별 계약의 한도가 적용됩니다. FSP 공식 문서

구매 담당자에게는 우리 계약에서 어느 약정에 얼마나 반영되는지, 적용 한도와 실제 단가는 무엇인지 따로 확인하는 편이 좋습니다. 확인한 발표에는 세 모델의 구체적인 가격과 지원 리전, SLA가 나와 있지 않습니다. OpenAI 직접 API의 가격을 그대로 대입하면 이번 구매 경로의 비용을 잘못 계산할 수 있습니다.

예산이 남은 고객지원팀이라면

가상의 상황을 하나 보겠습니다. Google Cloud 약정 예산이 남은 고객지원팀이 문의 분류에 OpenAI 모델을 써보려 합니다. 이 경우 먼저 확인할 것은 남은 예산으로 해당 사용료를 처리할 수 있는지입니다. 가능하다면 별도 구매 예산을 마련하는 부담이 줄어들 수 있습니다. 다만 남은 예산이 있다는 이유만으로 이 경로가 가장 저렴하다고 결론 내릴 수는 없습니다.

프리뷰 접근 권한을 받았다면, 민감정보가 없는 샘플 문의로 기존 방식과 비교할 수 있습니다. 같은 입력과 분류 기준을 쓰고 정답률, 재시도 횟수, 응답 시간, 사람이 수정한 건수를 함께 기록합니다. 분류 정확도가 높아져도 재시도나 수작업이 늘면 실제 업무 부담은 기대만큼 줄지 않을 수 있습니다. 평가 기록을 실제 견적과 함께 봐야 구매 판단에 도움이 됩니다.

이는 평가 방법을 설명하기 위한 가상 예시입니다. 이번 프리뷰의 성능이나 비용을 직접 검증한 결과는 아닙니다. OpenAI의 신청 안내도 초청형 프리뷰의 용도를 개발과 내부 평가로 설명합니다. 신청이 곧 접근 권한을 보장하거나 운영 서비스 투입을 허용하는 것은 아닙니다. 프리뷰 신청 안내

데이터 조건은 청구서와 별도로 확인해야 합니다

Google은 지정된 데이터 경계, 고객 프롬프트·문맥·출력을 파운데이션 모델 학습에 사용하지 않는다는 방침, 접근 통제와 감사 기능을 설명했습니다. 다만 데이터를 보관하지 않는 ZDR 옵션은 향후 제공 예정이라고 밝혔습니다. 현재 모든 요청이 무보관 처리된다고 가정해서는 안 됩니다. 필요한 보관 기간과 예외, 로그에 남는 범위는 실제 이용 조건에서 확인해야 합니다. Google의 데이터 관리 설명

청구서를 합칠 수 있어도 보안 검토와 업무별 품질 평가는 남습니다. 계정과 권한 관리가 왜 별도 검토 대상인지는 Gemini 에이전트의 회사 계정과 권한 관리에서도 다뤘습니다.

지금은 기존 계약을 급히 바꾸기보다 비교할 업무 하나를 정해두면 좋겠습니다. 구매 담당자는 약정과 견적을, 보안 담당자는 보관·로그·접근 조건을, 개발 담당자는 지원 기능과 운영 전환 조건을 확인할 수 있습니다. 평가 결과와 정식 제공 조건이 모이면, 비용과 관리 부담을 함께 놓고 구매 경로를 고를 수 있습니다.

저는 개인적으로 이번 변화를 모델 성능 순위보다 기업의 구매·예산 관리 경로가 넓어진다는 관점으로 보고 있습니다. 청구 통합이 도입 부담을 줄일 가능성은 있지만, 실제 비용과 보안 조건, 업무 품질은 별도로 비교해야 합니다.