이미지: blog.elis.cc 화면 갈무리
요약
- 구글 워크스페이스 가입 화면이 정상 도메인을 '이메일 제공업체'로 오인해 가입을 막는 오류가 2025년부터 2026년 8월까지 계속되고 있어요.
- 우크라이나 경제부의 me.gov.ua 도메인도 같은 오류를 겪어 구글 지원 커뮤니티에 도움을 요청했어요.
- 블로거가 가입 페이지 소스코드를 뜯어본 결과 web\..*, me\..*, alice\..* 같은 정규식 목록이 원인이었고, 이 검증은 프런트엔드에서만 작동해 비활성화하면 가입이 됐어요.
- 오류 메시지
- "Enter a valid domain name instead of an email provider"
- 보고자
- 블로거 el1s7, .one TLD 도메인 사용
- 동일 피해 사례
- 우크라이나 경제부 도메인 me.gov.ua
- 원인 규정
- 가입 페이지 프런트엔드의 이메일업체 판별 정규식 목록 (web\..*, me\..*, alice\..* 등)
- 검증 위치
- 클라이언트 사이드(프런트엔드)만 검증, 서버 사이드 검증 없음
- 구글 대응
- 정확한 원인을 파악하지 못한 채 다른 도메인 사용을 권유
- 게시 시점
- 원문 2025년 작성, 2026년 8월 업데이트로 문제 지속 확인
"당신의 도메인은 이메일 제공업체입니다"
구글 워크스페이스에 가입하려던 블로거 el1s7 씨는 자신의 도메인 이름을 입력하자마자 낯선 오류를 만났어요. 화면에는 "Enter a valid domain name instead of an email provider"(이메일 제공업체 대신 올바른 도메인 이름을 입력하세요)라는 문구가 떴는데요, 정작 이 도메인은 프리미엄 갱신료를 내는 정상 도메인이었고 악용 이력도 없었어요. .one이라는 정식 최상위 도메인(TLD)을 쓰고 있었는데도 구글은 이 주소를 이메일 서비스 업체로 오인했어요.
구글 공식 문서 어디에도 이 오류에 대한 설명은 없었고, 검색해 보니 같은 문제를 겪은 사람들이 커뮤니티에 도움을 요청한 글이 여럿 있었어요. 그중에는 우크라이나 경제부가 자신들의 도메인 me.gov.ua로 워크스페이스에 가입하려다 같은 오류를 겪었다며 남긴 구글 지원 커뮤니티 글타래도 있었어요.
지원팀 상담원 세 명, 그리고 "다른 브라우저 써보셨나요"
블로거는 결국 구글 워크스페이스 고객지원에 문의했는데요. 여러 상담원이 "다른 브라우저로 시도해 보셨나요"를 반복해서 물었고, 이미 시도했다고 여러 번 설명한 뒤에야 고급 지원 담당자 캐런에게 연결됐어요. 캐런 역시 다른 기기로 시도해 보라는 같은 질문을 반복했고요. 이후 제품 엔지니어 검토를 위해 화면 녹화 영상을 요청받아 제출했지만, 며칠 뒤 다시 시도해도 오류는 그대로였어요. 일주일 뒤 받은 답변은 정확한 원인을 모르니 다른 도메인을 써보라는 내용이었어요.
소스코드에 숨어 있던 정규식 목록
구글을 떠나 마이크로소프트로 갈아탈까 고민하던 블로거는 마지막으로 가입 페이지의 소스코드를 직접 열어봤어요. 그리고 오류가 로컬 입력 검증 함수에서 발생한다는 걸 확인했는데요. 이 함수는 입력한 도메인을 이메일 제공업체로 추정되는 정규식 목록과 대조하고 있었고, 목록에는 이해하기 어려운 항목이 여럿 있었어요.
| 정규식 | 걸러지는 도메인 예시 | 비고 |
|---|---|---|
web\..* | web.으로 시작하는 모든 TLD | 블로거의 .one 도메인이 이 규칙에 걸려 가입이 막혔어요 |
me\..* | me.으로 시작하는 도메인·하위 도메인 | 우크라이나 경제부의 me.gov.ua가 여기 걸렸어요 |
alice\..* | alice.으로 시작하는 도메인 | 왜 목록에 있는지 근거를 찾지 못했다고 밝혔어요 |
web\..* 규칙은 web.으로 시작하는 도메인을 통째로 이메일 서비스로 분류하고 있었어요. me\..* 규칙은 하위 도메인이 me인 주소까지 걸렀고, 그 바람에 me.gov.ua 도메인을 쓰는 우크라이나 경제부까지 같은 오류를 만난 셈이에요.
서버는 안 막는데, 화면만 막았다
블로거는 브라우저 개발자 도구에서 이 검증 함수를 강제로 비활성화해 봤어요. 결과는 예상대로였는데요, 검증 함수를 끄자 도메인 입력 단계를 무사히 통과해 가입을 마칠 수 있었어요. 이 오류는 서버가 아니라 화면(프런트엔드)에서만 걸러지는 검증이었고, 그 검증 로직 자체가 도메인을 이메일 업체로 잘못 분류하고 있었던 거예요. 블로거는 우크라이나 경제부가 이 문제를 겪은 뒤 마이크로소프트 365로 넘어갔을 것으로 추정했는데, 이는 확인된 사실이 아니라 블로거 개인의 짐작이에요.
에디터의 시선
이 사례가 흥미로운 건 버그 자체보다 그 버그가 만들어진 방식이에요. web.de, gmx, mail.ru처럼 무료 이메일을 파는 도메인을 기업 계정으로 오인해 걸러내려던 목적으로 만들어졌을 규칙이, 세월이 지나면서 web.[모든 TLD], me.[모든 TLD]처럼 지나치게 넓은 그물이 돼버린 거예요. alice..* 항목은 블로거조차 이유를 찾지 못했다고 했는데, 이건 누군가 한 번 추가한 규칙을 아무도 다시 들여다보지 않았다는 뜻이기도 해요.
SaaS 가입 폼을 오래 운영해 본 사람이라면 이 패턴이 낯설지 않을 거예요. 초기에 몇 줄짜리 블랙리스트로 시작한 검증 로직이 담당자가 바뀌고 몇 년이 지나면서 아무도 감사하지 않는 채로 방치되는 경우가 흔하거든요. 문제는 이게 대기업의 핵심 가입 흐름에서 벌어졌다는 점이에요. 정부 기관 도메인까지 걸러낼 정도로 광범위한 영향을 주는 로직이 프런트엔드 자바스크립트 한 줄로만 존재했고, 서버 쪽 검증은 아예 없었다는 점도 눈에 띄어요. 검증이 클라이언트에만 있으면 개발자 도구로 우회할 수 있다는 건 보안 관점에서도 허술한 설계예요.
국내에서 워크스페이스나 유사 SaaS에 회사 도메인을 등록하다 비슷한 오류를 만난다면, 지원팀에 문의하며 몇 주를 기다리기보다 브라우저 개발자 도구로 가입 페이지의 스크립트를 확인해 보는 편이 더 빠른 해법일 수 있어요. 물론 모든 사용자에게 권할 방법은 아니고, 이런 우회가 필요하다는 사실 자체가 서비스 쪽의 문제라는 점은 분명해요. 이번 건이 해커뉴스에서 화제가 된 만큼 구글이 정규식 목록을 손볼 가능성은 있지만, 서버 사이드 검증까지 새로 갖출지는 지켜봐야 할 부분이에요.
댓글