관계사 Workspace 에 묶인 메일 도메인을 떼어 오며 메일 공백을 Email Routing 으로 메웠다

넘겨받는 서비스의 업무 메일 도메인은 독립된 Google Workspace 가 아니라, 관계사 Workspace 안에 보조 도메인으로 들어 있었다. 기본 도메인은 관계사 것이고, 같은 계정 안에 넘겨받는 서비스의 도메인 둘이 함께 있었다. 양수도가 끝나면 이 도메인을 새 법인의 Workspace 로 떼어 와야 한다. 그런데 Google Workspace 는 같은 도메인을 두 계정에 동시에 올릴 수 없다. 옮기는 동안 메일이 어딘가에서는 끊긴다는 뜻이다.

Table of contents

배경 — 계정이 바뀌면 끊기는 것들

메일 도메인은 메일만의 문제가 아니다. 지금 쓰는 업무 계정은 GCP 조직, Firebase, Google Play Console, Google Analytics, 그리고 「Google 로 로그인」으로 들어가는 여러 서비스의 권한을 쥐고 있다. 도메인을 옮기는 방식에 따라 이 계정들이 그대로 넘어가기도 하고, 이름만 같은 새 계정이 되기도 한다. 후자라면 권한을 전부 새 계정으로 다시 옮겨야 한다. Play 개발자 계정은 연결이 끊길 수 있다는 공식 경고도 있었다.

판단 — 분리 방식 두 가지

Google 공식 문서와 리셀러의 가이드를 대조하니 방식은 두 가지였다.

권한이 끊기지 않는다는 점에서 A 가 낫다. 반면 A 는 공식 문구가 「같은 조직의 Workspace 계정 사이」를 전제로 하고 있어, 양수도처럼 다른 법인으로 옮기는 데 되는지가 불확실했다. 그리고 도메인을 원래 계정에서 한 번 빼면 A 는 더 고를 수 없다. 그래서 A 가 되는지 답을 먼저 받고, 그 전에는 도메인을 빼지 않기로 했다. 이 순서를 고른 이유는 B 를 고른 뒤에는 A 로 돌아올 수 없지만, A 를 기다린 뒤에는 B 로 갈 수 있기 때문이다. 답은 「A 는 불가」였고, B 로 갔다. B 의 대가는 그룹이 이관되지 않아 공용 주소를 새로 만들어야 하고, 업무 계정마다 권한을 다시 옮겨야 한다는 점이다.

B 로 가더라도 도메인을 빼는 단계에 함정이 하나 있었다. 사용자의 주 주소를 계정 안의 다른 도메인으로 옮긴 뒤에야 원래 도메인을 지울 수 있는데, 옮겨 갈 도메인이 「사용자 별칭 도메인」이면 그 주소로는 로그인할 수 없다. 별칭 도메인 주소는 주 주소가 될 수 없기 때문이다. 그래서 그 도메인의 유형이 보조 도메인인지 관리 콘솔에서 먼저 확인하는 단계를 절차의 맨 앞에 두었다.

해결 — 두 시간의 공백을 Email Routing 으로

도메인을 원래 계정에서 지우고 새 계정에 올리는 사이에는 그 도메인으로 오는 메일을 받을 곳이 없다. 그 공백을 메우려고 새 계정의 준비를 기다리는 대신 DNS 를 쥔 Cloudflare 쪽에서 받기로 했다.

18:20  MX → Cloudflare Email Routing, catch-all → 운영용 Gmail 한 곳 (받기만 한다)
       … 원래 계정에서 도메인 제거 · 새 Workspace 등록 · 사용자·그룹 생성 …
20:14  MX → Google 로 되돌림. 이후 새 Workspace 가 직접 받는다

약 두 시간 동안 모든 주소의 메일이 Gmail 한 곳으로 들어왔다. 받는 주소별로 가르는 데는 To·Cc 헤더로 라벨을 붙였고, Delivered-To 는 Gmail 주소라 쓸 수 없었다. 숨은 참조(Bcc)로 온 메일은 이 방법으로 갈리지 않아 원본 헤더를 따로 봐야 했다. 이 기간의 메일은 다음 날 오전에 받는 사람마다 새 주소로 전달하기로 정했다. 새 Workspace 에는 사용자 10명과 공용 그룹을 만들었고, 메일 가져오기는 그날 밤 시작해 다음 날 오전에 끝나는 일정으로 걸었다.

SPF 레코드는 덮어쓰지 않고 병합해야 했다. 기존 값에는 Amazon SES 등 다른 발송 서비스가 이미 들어 있었고 Google 은 없었다. 새 Google 값으로 덮으면 다른 서비스가 보낸 메일이 SPF 실패로 떨어진다.

영향 범위 — 남은 일

MX 를 되돌린 직후 시험 메일 2통이 받는 쪽에서 스팸으로 분류됐다. 새 그룹 회원에게는 받은편지함과 함께 스팸함을 보라고 안내하고, 우회 규칙은 따로 정하기로 했다. 새 계정이 이름만 같은 다른 계정이므로, GCP·Firebase·Play Console·Analytics 의 권한을 새 계정으로 옮기는 작업표를 서비스별로 따로 만들어 돌려야 한다. 드라이브·캘린더·연락처는 메일 가져오기에 포함되지 않아, 직원 개인이 옮기도록 하는 안내문 초안을 따로 만들었다.

결과 — 메일 공백 없이 떼어 온 도메인

• 되돌릴 수 없는 선택의 순서. 되돌릴 수 없는 방식(A)의 가능 여부를 먼저 받고 나서 도메인을 뺐기 때문에, 선택지를 스스로 닫지 않았다
• 업무 공백. 메일 수신 공백을 MX 를 잠시 돌린 약 두 시간으로 한정했고, 그 사이 메일은 다음 날 받는 사람마다 전달했다
• 조직 비용. 계정이 이름만 같은 새 계정이 됐으므로 GCP·Firebase·Play Console 등 권한 이전이 서비스별 작업으로 남았다

정리

• 메일 도메인을 옮기는 방식은 「계정이 그대로 가는가」로 먼저 가른다. 계정이 바뀌면 그 계정이 쥔 권한이 전부 따라 움직여야 한다
• 되돌릴 수 없는 선택지가 있으면, 그것이 되는지 답을 받기 전에는 그 선택지를 닫는 동작(도메인 빼기)을 하지 않는다
• 옮겨 갈 도메인의 유형을 먼저 확인한다. 별칭 도메인 주소로는 로그인할 수 없다
• 공백은 DNS 를 쥔 쪽에서 메운다. MX 를 잠시 다른 수신처로 돌리고, 끝나면 되돌린다