Google Workspace의 Microsoft 사용자 가져오기: 중소기업이 이전 전에 나눌 세 단계

Google은 2026년 5월 13일, Google Workspace를 처음 설정하는 소규모 조직이 Microsoft 계정의 사용자를 가져올 수 있는 베타 기능을 발표했다.[1] 결론부터 말하면 전환 화면은 짧아졌지만, 이전 계획까지 한 번에 끝나는 것은 아니다. 국내 중소기업은 계정 생성, 업무 데이터 복사, 메일 전환을 세 단계로 나누고 각 단계의 완료 기준을 따로 잡는 편이 안전하다.

5월 13일 발표에서 실제로 바뀐 것

확인된 사실부터 보자. 새 기능은 Workspace 초기 설정 중 Microsoft 비즈니스 계정을 연결하면 기존 사용자를 찾아 새 Workspace 계정으로 복사할 후보를 만든다. Flexible Plan에서는 최대 10명을 가져올 수 있고, Annual 또는 Fixed-Term Plan은 필요한 라이선스를 먼저 확보해야 한다.[1][2]

이 과정은 Microsoft 쪽 사용자를 삭제하거나 수정하지 않는다. 이름과 계정 정보를 Workspace로 복사하며, 관리자는 대상 사용자를 검토한 뒤 이메일, 일정, 연락처, 파일, 작업 가운데 가져올 항목을 선택할 수 있다.[2]

발표문은 이 기능을 베타로 명시했고, 2026년 4월 28일부터 점진적으로 제공한다고 밝혔다.[1] 따라서 관리자 화면에 아직 보이지 않는다고 해서 설정이 잘못됐다고 단정할 수는 없다. 지원 플랜과 도메인 확인 상태, 실제 기능 노출 여부를 먼저 확인해야 한다.

확인된 변화: 소규모 조직의 첫 사용자 생성과 초기 데이터 복사를 한 화면에서 시작할 수 있게 됐다.

POEMORA의 해석: 이전 프로젝트의 성패를 가르는 DNS 전환, 권한 재설계, 누락 검수까지 자동화됐다는 뜻은 아니다.

계정 복사와 데이터 이전을 같은 일로 보면 안 된다

새 화면이 편리해도 사용자를 만들었다는 사실과 업무 자료가 온전히 옮겨졌다는 사실은 다르다. Google의 관리자 문서는 가져오기를 중단해도 이미 복사된 데이터가 자동으로 되돌아가지 않으며, 같은 내용을 다시 가져오면 중복이 생길 수 있다고 경고한다.[2]

기본 데이터 마이그레이션 서비스도 별도의 관리 작업이다. Exchange Online을 연결하면 관리자 콘솔에 승인된 API 클라이언트가 생기고, 관리자는 원본과 대상 사용자를 매핑한 뒤 이전을 시작하고 진행 상태를 확인한다.[3] 10명을 넘거나 초기 설정 뒤 추가 이전이 필요하면 이 경로를 따로 계획해야 한다.

실무에서는 아래 세 장부를 분리해 두는 편이 낫다.

계정 수가 적다고 이 표를 생략하면 문제가 늦게 보인다. 특히 공용 메일함, 퇴사자 보관 계정, 자동 발송 주소는 일반 사용자 목록만 봐서는 빠지기 쉽다.

전환 전에 먼저 정할 다섯 가지

1. 이전 대상 사용자를 확정한다. 재직자뿐 아니라 공용 주소와 업무상 보존이 필요한 계정을 따로 적는다.
2. 라이선스 수를 먼저 맞춘다. Workspace는 각 사용자에게 계정과 라이선스가 필요하며, 연간 요금제는 계정을 추가하기 전에 좌석을 확보해야 한다.[4]
3. 도메인 확인과 메일 전환을 분리한다. 사용자 가져오기는 도메인 확인 뒤 진행하지만, 실제 메일 수신 경로 변경은 별도의 전환 시점으로 잡는다.[1]
4. 자료별 표본 검사를 만든다. 최근 메일, 반복 일정, 외부 연락처, 공유 파일처럼 업무에 영향이 큰 항목을 사용자별로 고른다.
5. 되돌림 조건을 문서로 남긴다. 가져오기 중단은 이미 복사된 자료를 지우지 않으므로, 무작정 재실행하지 말고 중복 범위와 정리 책임자를 정한다.[2]

완료 기준은 "버튼을 눌렀다"가 아니라 "누가 무엇을 확인했는가"여야 한다. 관리자는 이전 도구의 완료 표시와 별도로 실제 사용자의 로그인, 검색, 공유, 메일 송수신을 확인해야 한다.

10명 이하 조직에 맞는 현실적인 이전 순서

작은 조직은 전사 전환을 한 번에 하기보다 대표 사용자 1~2명으로 먼저 흐름을 확인하는 편이 부담이 적다. 예를 들어 관리자와 실무자 한 명을 골라 계정을 만들고, 데이터 표본과 외부 공유 문서를 확인한 뒤 나머지 사용자를 가져온다. 이는 Google의 공식 절차가 아니라 POEMORA가 권하는 운영 방식이다.

• 준비일: 사용자·별칭·그룹·라이선스 목록을 고정한다.
• 시험일: 대표 사용자로 로그인과 데이터 표본을 확인한다.
• 전환일: 나머지 사용자를 가져오고 메일 흐름을 바꾼다.
• 확인일: 누락, 중복, 외부 공유 권한, 모바일 로그인을 점검한다.

같은 데이터를 초기 설정 도구와 별도 마이그레이션 서비스에서 겹쳐 실행하지 않는다. 공식 문서도 중복 가져오기가 중복 데이터를 만들 수 있다고 명시한다.[2] 어느 도구가 어떤 사용자와 기간을 담당하는지 한 줄로 적어 두면 재실행 사고를 줄일 수 있다.

국내 중소기업이 놓치기 쉬운 운영 경계

이번 변화는 전환의 입구를 단순하게 만든다. 그러나 직원 안내, 공용 주소 처리, 외부 협력사 공유, 퇴사자 자료 보관은 조직이 결정해야 한다. 이 부분은 Google 발표에서 보장한 기능이 아니라 국내 실무에 적용할 때 필요한 운영 해석이다.

특히 메일 도메인을 바꾸는 날에는 두 시스템을 동시에 열어 두는 기간과 지원 창구가 필요하다. 새 계정 로그인 안내 메일은 사용자가 접근할 수 있는 보조 주소로 전달해야 한다는 공식 안내도 있다.[2] 안내 메일이 이전 Microsoft 사서함 안에만 남으면 정작 전환 당일 새 계정에 들어가지 못할 수 있다.

업무 도구 전환을 계정 생성에서 끝내지 않고 권한·데이터·안내까지 함께 설계하려면 POEMORA 자동화 서비스처럼 전체 흐름을 기준으로 검토하는 방법이 맞다. 도구 선택보다 먼저 "전환 뒤 첫 업무가 정상으로 끝나는가"를 테스트해야 한다.

지금 할 일은 기능을 켜는 것이 아니라 범위를 그리는 것

Microsoft 사용자 가져오기 베타는 소규모 조직의 첫 설정을 분명히 줄여 준다. 다만 최대 10명이라는 범위, 플랜별 라이선스 조건, 중단 후 자동 롤백이 없다는 제약을 함께 봐야 한다.[1][2]

도입을 검토한다면 관리자 콘솔에서 기능 노출 여부를 확인하고, 사용자·데이터·메일 전환 장부부터 만든다. 그다음 대표 사용자로 한 번 검증한 뒤 전체 전환으로 넓히면 된다. 짧아진 설정 화면을 믿되, 완료 판단은 실제 업무 흐름으로 해야 한다.