GCP Billing(이하 빌링)에 대해서 알아보자.
목차는 다음과 같다.
목차
- GCP의 Billing은 무엇인가?
- GCP의 Billing에서 파트너 모델은 어떻게 구성이 되는가?
- Sub Account 의 모델은 무엇인가?
- 셀프서비스와 인보이스?
- 메가존의 수익 모델은?
- GCP에서 Billing Account는 무엇인가?
- GCP에서 Billing 변경 프로세스는 어떻게 되는가?
1. GCP의 Billing은 무엇인가?
요약하자면 Google Cloud 리소스 사용에 대한 비용을 추적 및 파악 그리고 최적화를 할 수 있도록 지원하는 서비스 및 도구 모음이다.
2. GCP Billing에서 파트너 모델은 어떻게 구성이 되는가?
우선 파트너 모델에 들어가기 앞서, 아래 다이어그램으로 GCP의 결제 시스템이 기본적으로 어떻게 두 가지 역할로 분리(Decoupling)되어 있는지 살펴보았다.
'계산서'와 '실제 지갑'의 관계로 생각하면 이해하기 쉽다.
다이어그램의 의미: 계산서와 지갑의 분리
- 왼쪽 초록색 박스 (Cloud Billing Account): '계산서' 역할
- GCP 내부(Google Cloud)에 존재하는 리소스이다.
- 아래에 연결된 Project 1, Project 2에서 리소스를 얼마나 썼는지 요금을 추적하고 합산하는 역할을 한다. 하지만 여기에는 신용카드 정보가 없다
- 오른쪽 노란색 박스 (Payments Profile): '실제 지갑' 역할
- GCP가 아닌 구글 전체의 결제 센터(Google payments center)에서 관리되는 리소스이다.
- 실제 돈이 빠져나가는 신용카드 번호, 은행 계좌, 세무 정보(사업자 번호 등)가 저장되는 곳이다.
메가존(파트너) 모델에서는 이 그림이 어떻게 적용될까?
메가존을 통한 결제(Sub Account 모델)에 있어서 해당 구조가 파트너사 위주로 돌아가게 된다.
- 메가존이 자신들의 법인 카드나 은행 계좌를 구글의 Payments Profile(지갑)에 등록
- 이 지갑에 메가존 소유의 최상위 마스터 Cloud Billing Account(부모 계정)를 연결
- 그리고 고객사에게는 마스터 계정 산하에 Sub Account(하위 결제 계정)를 만들어 제공
여기서 “Sub Account” 에 대해서 알아보자.
2.1 Sub Account 의 모델이란?
리셀러 파트너(예: 메가존소프트)에서 만들어 둔 최상위 계정(부모) 산하에 Sub Account(하위 결제 계정)을 각 고객사 별로 만들어서 제공하게 된다.
아래는 하위계정(Sub Account)에 대한 구글 결제 흐름 다이어그램이다.
- 구글 ➔ 메가존 (비용 청구 및 지불)
구글 입장에서는 개별 고객사에게 돈을 받지 않고, 오직 마스터 계정을 소유한 메가존에게만 전체 요금을 청구하며 이를 구글에 납부 - 메가존 ➔ 고객사 (비용 재청구 및 회수)
메가존은 구글에 요금을 지불한 뒤(혹은 인보이스 정산 과정에서), 각 Sub Account별로 고객사가 얼마나 리소스를 썼는지 계산하고 고객사에게 해당 비용을 다시 청구
여기서 청구 방식에 대해 좀 더 알아보았다.
2.2 셀프서비스와 인보이스?
셀프 서비스(카드 결제) = 온라인으로 카드 등록하고 바로 시작. 자동 결제
인보이스(은행 송금) = Google이 청구서를 보내면 계좌이체로 납부. 자격 심사 필요
여기서 중요한 점은, “리셀러의 부모 결제 계정은 반드시 인보이스 결제”여야 한다는 점이다.
이유는 다음과 같다.
- 리셀러는 고객사 수십~수백 곳의 사용료를 한 번에 대납해야 함
- 그 금액을 카드로 긁는 건 비현실적 (한도, 규모, 회계 처리 전부 안 맞음)
- 게다가 subaccount별 소계를 찍은 통합 청구서를 받아야 chargeback이 돌아감
인보이스 방식이 아니면 구조 자체가 성립 안 함
이렇게 찾다 보니, 메가존의 수익 모델에 대해 예상해보았다.
2.3 메가존의 수익 모델은?
내가 이해한 바로는, ‘구글 서비스를 대신 판매하는 중개인’ 역할이 사업 모델인 것 같았다.
→ MSP(Managed Service Provider, 관리형 서비스 제공자) 또는 퍼블릭 클라우드 리셀러(Reseller)라고도 부른다.
-
파트너 마진
구글로부터 클라우드 리소스를 일반 고객보다 저렴한 도매가(할인가)에 대량으로 공급 받은 후, 고객사에게는 할인가로 제공하여 차액을 수익화 -
부가 가치 서비스 (Value-Added Services) 제공
고객사들에게 단순히 결제 대행만 하는것이 아닌, 메가존은 클라우드를 중개하면서 다음과 같은 필수 '부가 서비스'를 제공하고 수익화- 재무/회계 지원: 한국 기업에 필수적인 원화(KRW) 세금계산서 발행, 자체 빌링 포털(대시보드) 제공, 복잡한 부서별 비용 분배(Chargeback) 기능 지원
- 기술 지원 및 컨설팅: 클라우드 도입 초기 아키텍처 설계, 서버 이전(마이그레이션), 24시간 장애 대응(운영 대행), 보안 설정 등 구글이 직접 해주기 어려운 밀착 기술 지원
3. GCP에서 Billing Account는 무엇인가?
"이 프로젝트들의 요금을 누가, 어떻게 낼 것인가"를 정의하는 객체이다.
특히, 리소스는 하나도 없다. 오로지 결제수단, 비용 데이터만 들어있다.
왜 굳이 별도 객체로 뺐나?
여기가 설계 의도인데, "누가 소유하는가"와 "누가 돈을 내는가"가 현실에서 자주 다르기 때문이다.
- 본사가 계열사 프로젝트 비용을 대납
- 리셀러가 고객사 비용을 대납
- 하나의 예산으로 여러 조직에 걸친 프로젝트를 운영
이걸 조직 계층에 묶기엔 책임이 너무 커져서 별도 객체로 만든 것이다.
4. GCP에서 Billing 변경 프로세스는 어떻게 되는가?
결제 계정 변경은 특정 프로젝트에 연결된 기존 A 결제 계정을 B 결제 계정으로 교체하는 작업이다.
앞서 말한 프로젝트 권한과 결제 권한이 분리됨에 따라, GCP에서 Billing 변경또한 각 권한을 가지고 있어야 맵핑이 가능하다.
프로젝트 측면의 권한 (기존 선을 끊고 새 선을 연결할 권한)
- 필요 권한:
프로젝트 소유자(Owner)또는프로젝트 결제 관리자(Billing Project Manager) - 의미: "이 프로젝트의 비용 청구처를 다른 곳으로 바꾸겠다"라고 설정할 수 있는 프로젝트 내부의 관리자 권한 (이 권한이 있으면 기존 결제 계정에 대한 관리자 권한은 없어도 기존 연결을 끊을 수 있음)
새로운 결제 계정 측면의 권한 (내 지갑을 열어줄 권한)
- 필요 권한: 대상 결제 계정의
결제 계정 사용자(Billing Account User)또는결제 계정 관리자(Administrator) - 의미: "이 결제 계정(지갑)으로 저 프로젝트의 비용을 내주겠다"라고 허락할 수 있는 지갑 주인의 권한
즉, 아무리 프로젝트의 최고 관리자(Owner)라고 해도 돈을 내줄 새로운 결제 계정의 사용 권한(Billing Account User)이 본인에게 없다면 결제를 마음대로 가져와서 붙일 수 없다.
양쪽 모두에 권한을 가진 사용자만이 콘솔에서 두 개를 매핑(연결)할 수 있다.
관리자가 콘솔에서 수동으로 변경하는 것 외에도, 대규모 조직에서는 Cloud Billing API를 활용하여 프로그래매틱(자동화) 방식으로 결제 계정을 연결하거나 변경할 수 있다.
해당 내용은 다음 주제(APIs & Services) 에서 다루겠다.
