넘겨받는 커머스의 시스템 인수를 시작한 첫날, 메일로 보낸 요청은 코드가 아니라 클라우드 청구였다. 넘겨받을 시스템은 GCP 위에 있고, 기존 운영 쪽은 AWS 를 쓰고 있었다. 그날 리셀러와 먼저 전화로 이야기한 뒤, 그 내용을 메일로 정리해 GCP 쪽 요청을 다시 보냈다. 여기서 정한 것은 두 가지다. 넘겨받을 GCP 청구를 어느 통로로 받을지, 그리고 두 회사의 클라우드 비용을 한 화면에서 어떤 단위로 가를지다.
Table of contents
Open Table of contents
배경 — 소유가 바뀌는 동안 끊기면 안 되는 것
GCP 에서 프로젝트의 유료 리소스는 Cloud Billing 의 Billing Account 에 붙어 돈다. Billing Account 에 연결된 결제 수단이 끊기거나 계정이 닫히면, 그 계정에 붙은 프로젝트의 유료 리소스가 멈춘다. 넘겨받는 시스템은 고객 웹과 앱, 백오피스가 모두 GCP 와 Firebase 위에서 돈다. 소유가 바뀌는 동안 이 연결이 끊기지 않게 하는 것은 넘겨받는 쪽이 코드보다 먼저 잡아야 하는 일이다.
판단 — GCP 청구를 받을 통로
기존 운영 쪽은 AWS 사용료를 리셀러를 거치는 원화 통합 빌링으로 내고 있었다. 넘겨받을 GCP 청구도 같은 리셀러를 거쳐 같은 구조로 묶기로 했다. 이유는 계약 상대와 청구 형태를 이미 운영 중인 하나로 맞출 수 있기 때문이다. 새 통로를 따로 세우는 대신 이미 쓰는 통로에 묶으면, 계약·결제 수단·청구서를 받는 곳을 처음부터 다시 맞추지 않아도 된다.
대가는 청구 사이에 리셀러가 한 겹 더 들어온다는 점이다. 수수료와 계약 조건은 아직 정해지지 않았다. 리셀러는 이튿날 회신해 일정을 조율했고, 미팅은 다음 주로 잡혔다. 조건은 그 미팅에서 정한다.
판단 — 비용 화면을 가르는 단위
리셀러의 비용 관리 도구에는 두 회사의 클라우드가 함께 올라오게 된다. 요청 메일 초안에는 이것을 「GCP 리전은 넘겨받는 시스템, AWS 리전은 기존 시스템으로 관리한다」고 적으려 했다. 가르는 단위를 쓰는 방법은 두 가지였다.
- 리전 단위로 쓴다
- 클라우드 계정 연결 단위로 쓴다. GCP 는 프로젝트를, AWS 는 계정을 도구에 연결한다
2번으로 고쳐 쓴 뒤 보냈다. 그 도구의 공식 문서가 이 단위를 「클라우드 계정 연결」, GCP 의 경우 「GCP 프로젝트 연결」로 부르기 때문이다. 리전은 GCP 와 AWS 모두에서 데이터센터의 지리적 위치를 뜻하는 말이라, 요청서에 리전이라고 쓰면 상대가 리소스 배치 이야기로 읽을 수 있다. 반면 계정 연결로 쓰면 어느 쪽 비용인지가 연결 단위에서 바로 갈린다.
영향 범위 — 화면의 주인
같은 도구 안에 두 회사의 비용이 보이므로, 누가 어느 화면을 보는지를 처음부터 갈라 둔다. 넘겨받는 쪽 GCP 비용은 넘겨받는 법인이 받는 청구이고, 기존 운영 쪽 AWS 비용과 섞이면 어느 회사의 돈인지를 다시 가려야 한다. 연결 단위로 가르면 GCP 프로젝트 하나, AWS 계정 하나가 각각 한 회사에 속하므로 화면의 주인도 연결 단위로 정해진다.
결과 — 첫날 연 청구 통로
- 청구 통로. 넘겨받을 GCP 청구를 이미 운영 중인 리셀러 통합 빌링에 묶는 쪽으로 첫날 방향을 정했고, 다음 주 미팅으로 이어졌다
- 비용의 주인. 비용 화면을 계정 연결 단위로 갈라, 두 회사의 비용이 한 도구에서 섞이지 않게 할 기준을 세웠다
- 남은 것. 수수료와 계약 조건은 미팅에서 정한다. 그 전까지 지금 결제 수단이 끊기지 않는지는 계속 본다
정리
- 소유가 바뀌는 시스템은 청구 통로부터 잡는다. 결제 수단이 끊기면 서비스가 먼저 멈춘다
- 새 통로를 세우기 전에 이미 운영 중인 통로에 묶을 수 있는지 먼저 본다
- 남에게 보내는 요청서의 단위는 그 도구의 공식 용어로 쓴다. 리전과 계정 연결은 다른 것을 가리킨다
- 한 도구에 두 회사의 비용을 올릴 때는 화면의 주인을 처음부터 가른다