요약

  • Google Cloud 프로젝트의 소속 조직을 바꿔도 기존 Cloud Billing 계정과의 연결은 유지된다.
  • Cloud Marketplace에서 직접 산 활성 주문을 다른 결제 계정으로 옮기려면 고객과 소프트웨어 공급업체의 승인이 필요하며 일주일 이상 걸릴 수 있다.
  • 이전 중 대상 결제 계정에서 같은 공급업체의 제품을 사면 주문 이전이 불가능해진다. 구매 권한만큼 구매 순서도 중요하다.

독립하는 회사가 자기 돈으로 소프트웨어를 사겠다는 데 무슨 문제가 있을까. Google Cloud Marketplace의 주문 이전 규정에는 꽤 구체적인 답이 있다. 이전이 진행되는 동안 새 결제 계정에서 같은 공급업체의 제품을 구매하면, 진행하던 이전이 불가능해진다. 열심히 독립을 준비한 구매 담당자의 주문이 독립 절차를 막을 수 있다.

이 규칙은 클라우드 사업 분리의 성격을 잘 드러낸다. 시스템의 관리 위치를 바꾸는 일과, 기존 계약에 따라 쓸 수 있는 것을 넘기는 일은 서로 다른 결정이다. 관리자에게 권한을 더 준다고 공급업체의 동의가 생기지는 않는다. 조직도에 그은 선이 청구서와 주문서에도 저절로 그어지는 것은 더더욱 아니다.

프로젝트 주소만 먼저 바뀐다

Google의 프로젝트 이전 문서에 따르면 조직 간 이전은 프로젝트의 상위 리소스를 가리키는 메타데이터를 변경한다. 프로젝트 ID와 번호, 데이터와 리소스는 유지된다. 프로젝트에 직접 부여한 IAM 역할도 남는다. 연결된 결제 계정 역시 원래 계정이다.

새 조직 아래 나타난 프로젝트가 옛 조직 쪽 계정의 돈으로 계속 작동할 수 있다는 뜻이다. Cloud Billing 계정은 조직의 경계를 넘어 프로젝트에 비용을 댈 수 있다. 조직 이전을 완료했다는 화면은 관리상 위치를 보여준다. 누가 비용을 인수했는지는 별도로 봐야 한다.

권한도 그대로 한 덩어리로 이동하지 않는다. 원래 조직에서 상속받던 IAM 권한은 사라지고 새 조직의 정책이 적용된다. 데이터가 제자리에 있다는 사실과 애플리케이션이 의존하던 모든 접근 경로가 유효하다는 사실은 다르다. 남아 있는 직접 권한, 사라진 상속 권한, 새 정책을 구분해야 실제 운영 주체가 보인다.

이전 작업의 역할 안내도 프로젝트 이동에 필요한 권한과 결제 변경에 필요한 권한을 따로 다룬다. 결제 변경에는 대상 계정의 Billing Account User와 프로젝트의 Project Billing Manager 같은 역할이 등장한다. 전용 결제 문서는 조회, 연결 해제, 새 연결에 필요한 권한을 더 자세히 제시한다. 프로젝트를 옮길 수 있는 사람에게 새 계정으로 비용을 청구할 권한까지 자동으로 생기는 구조가 아니다.

옛 계정은 운영 조건으로 남는다

프로젝트 결제 설정 문서는 결제가 활성화되려면 연결된 계정이 유효하고 정상 상태여야 한다고 명시한다. 계정이 폐쇄되거나 정지되면 활성화된 서비스를 사용할 수 없다. 무료 사용 요건을 충족하는 서비스도 여기에 포함된다.

분리 후에도 옛 계정을 쓰는 경우, 새 회사가 프로젝트를 관리하면서 운영에 필요한 자금 조건은 옛 계정에 의존하는 상황이 성립한다. 돈을 낸다는 이유만으로 프로젝트의 IAM 권한을 갖는 것은 아니다. 관리 권한과 자금 공급이라는 서로 다른 고리가 동시에 운영을 지탱한다.

이 상태를 무조건 실수로 취급하면 거래의 경제성을 놓친다. Google이 2023년 5월 2일 내놓은 사업 분리 시 리소스 계층 전략은 가상의 RemainCo와 NewCo를 놓고 기존 약정 계약 때문에 원래 결제 계정의 자금 지원을 유지하는 방안을 설명한다. 프로모션 크레딧과 지원 패키지가 새 회사나 새 계정에 자동으로 따라가는 것도 아니다.

따라서 옛 계정이 계속 돈을 내는 모습은 합의된 과도기일 수도 있다. 차이는 화면이 아니라 합의 내용에 있다. 누가 얼마의 책임을 인수하는지, 어떤 조건이 충족되면 연결을 바꿀지 정해져 있다면 다리를 놓은 것이다. 그 질문을 하지 않았다면 다리 위에 사무실을 차린 셈이다.

주문 이전에는 공급업체도 서명한다

Marketplace 구매는 이 분리 작업에 별도의 이해관계자를 끌어들인다. 프로젝트 결제 안내는 프로젝트에 연결된 Marketplace 구매를 먼저 이전하도록 요구한다. Marketplace 결제 관리 문서는 새 계정에 필요한 리소스의 구매가 있어야 한다고 설명하며, 빠진 구매가 있으면 콘솔이 경고한다고 밝힌다. 프로젝트 하나가 동시에 연결할 수 있는 결제 계정은 하나다.

활성 주문의 결제 계정 변경 절차는 Cloud Marketplace에서 직접 구매한 제품을 대상으로 한다. Billing Account Administrator 역할을 가진 고객이 독립 소프트웨어 공급업체에 요청한다. 공급업체가 동의하면 Google에 전달하고, Google은 처리 후 승인 이메일을 보낸다. 관계자 모두의 승인 답신을 받아야 이전을 마무리하고 완료 사실을 통지한다.

Google은 이 과정에 일주일 이상 걸릴 수 있다고 적었다. 일주일은 보장된 처리 기한이 아니다. 이전 가능 여부도 충족해야 한다. 기술팀의 작업 시간이 짧더라도 공급업체와 고객의 승인 순서까지 같은 속도로 압축할 수는 없다.

여기에 처음의 구매 제한이 붙는다. 대상 계정이 이전 중 같은 공급업체에서 제품을 사면 이전이 불가능해진다. 같은 제품만 조심하면 되는 좁은 규칙이 아니다. 구매 조직이 전체 공급업체 관계를 보고 움직여야 하는 이유다. 새 회사가 이미 사용할 소프트웨어를 확보했다고 안도하는 순간, 옛 주문을 넘기는 경로는 달라질 수 있다.

비용은 마지막에 한 번 더 갈라진다

결제 계정을 바꿔도 변경 전에 발생한 비용은 옛 계정으로 청구된다. 아직 보고되지 않은 사용량도 포함된다. 서비스에 따라 보고가 최대 이틀 늦어질 수 있다. 이 지연을 변경 후 이틀간의 새 사용량까지 옛 계정이 부담한다는 뜻으로 읽으면 정산 기준이 틀어진다.

프로젝트 밖의 계정 비용도 있다. Support처럼 특정 프로젝트에 배정되지 않는 지출은 프로젝트 이전 완료 여부만으로 정리되지 않는다. 비용을 떠나보냈다는 보고서와 실제 계정 잔여 비용 사이에 이런 항목이 남는다.

할인 역시 옮긴 프로젝트만의 이야기가 아니다. 결제 계정을 바꾸는 프로젝트에 속한 Compute Engine 리소스 기반 약정의 할인은 대상 계정에서 적용되며, 옛 계정의 프로젝트들은 더 이상 그 약정의 혜택을 받지 못한다. 새 계정에서 어느 프로젝트에 혜택을 공유할지는 그쪽 설정에 달려 있다. 떠나는 사업의 정리가 남는 사업의 예산을 바꿀 수 있다.

Cloud Armor Enterprise Annual을 사용하던 프로젝트도 대상 계정에 해당 연간 구독이 없으면 Standard로 돌아간다. 서버가 그대로라는 말만으로는 이런 상품 조건의 변화를 설명할 수 없다.

개별 기업의 이전을 판단하려면 실제 IAM 설정, 결제 연결, 구매 내역과 승인 기록이 필요하다. 공개 문서가 확정해 주는 것은 절차의 구조다. 그 구조에서 인수 완료를 선언할 사람은 클라우드 관리자 한 명으로 충분하지 않다. 돈을 인수하는 사람과 주문을 넘기는 공급업체까지 동의해야 새 조직의 이름값을 할 수 있다.