기업용 협업 도구를 새로 도입할 때, 관리자 대부분은 도메인을 입력하고 몇 단계를 거치는 가입 절차가 별다른 저항 없이 끝나리라 기대한다. 그러나 한 사용자는 회사용 구글 워크스페이스 계정을 만들려다 가입 첫 단계에서 막혔다. 자신의 도메인 이름을 입력하자 "이메일 제공업체 대신 유효한 도메인 이름을 입력하세요(Enter a valid domain name instead of an email provider)"라는 낯선 오류가 떴기 때문이다. 자신의 도메인은 이메일 서비스와 아무 관련이 없는데도 시스템은 이를 '이메일 사업자'로 취급하고 있었다.
처음에는 도메인이 과거에 이메일 서비스로 쓰였던 이력 때문일까 의심했지만, 도메인 히스토리를 확인해도 그런 흔적은 없었다. 구글의 공식 문서에도 이 오류에 대한 설명은 없었다. 다만 커뮤니티 게시판에는 같은 문제를 겪는 사람들이 있었고, 그중에는 우크라이나 경제부(me.gov.ua)도 있었다. 정부 기관마저 동일한 벽에 부딪힌 것이다. 커뮤니티의 이른바 '전문가'들이 내놓은 답변은 실질적인 해결에 도움이 되지 않았다.
지원팀도 원인을 몰랐다
결국 저자는 구글 워크스페이스 지원팀에 문의했다. 여러 상담원이 "다른 브라우저에서 시도해 봤느냐"고 반복해 물었고, 이미 시도했다고 설명했음에도 상위 지원 담당자에게 넘겨진 뒤에도 "다른 기기로 가입해 보라"는 같은 요청이 돌아왔다. 이후에는 화면을 녹화해 제품 엔지니어의 검토를 기다려 달라는 안내를 받았다. 몇 시간 뒤 재시도를 권하는 메일이 왔지만 문제는 그대로였다. 일주일 뒤 도착한 답변은 더 당혹스러웠다. 시스템이 정당한 도메인을 잘못 표시한 것 같으나 정확한 이유는 모르겠으니, 회사용으로 다른 도메인을 쓰는 편이 어떻겠냐는 제안이었다.
문제의 도메인은 높은 갱신 비용을 지불하는 프리미엄 도메인이었고, 남용 이력도 없었으며, 사용된 .one TLD 역시 정상적인 기업들이 쓰는 정식 최상위 도메인이었다. 자사 시스템의 오탐을 인정하면서도 원인 파악 대신 도메인 교체를 권하는 대응은, 사실상 제품 엔지니어들조차 원인 규명을 포기했다는 신호로 읽혔다.
원인은 프런트엔드 정규식 목록이었다
마이크로소프트로 갈아탈까 고민하던 저자는 마지막으로 직접 가입 페이지의 소스 코드를 뜯어봤다. 그 결과 오류가 서버가 아니라 브라우저에서 실행되는 로컬 입력 검증 함수에서 발생한다는 사실을 확인했다. 이 함수는 입력된 도메인을 이메일 제공업체로 추정되는 정규식(regex) 목록과 대조하고 있었는데, 목록에는 기이한 항목들이 섞여 있었다. 예컨대 web\.. 라는 패턴이 저자의 도메인을 막고 있었다. 즉 web으로 시작하는 모든 도메인을 이메일 사업자로 간주한 셈이다. 마찬가지로 me\.. 항목은 우크라이나 경제부의 me.gov.ua를 서브도메인이 me라는 이유만으로 걸러냈다. alice\..* 같은 용도가 불분명한 항목도 있었다.
저자가 시험 삼아 이 검증 함수를 비활성화하자 도메인 입력을 통과해 가입을 정상적으로 이어갈 수 있었다. 이는 해당 검증이 프런트엔드에만 존재할 뿐 서버 측에는 대응하는 검사가 없었음을 의미한다. 클라이언트 코드를 조작할 수 있는 사용자라면 우회가 가능하지만, 대부분의 일반 관리자에게는 사실상 넘을 수 없는 장벽이었다. 그리고 이 문제는 2026년 8월 기준으로도 여전히 남아 있다.
실무자가 얻을 교훈
이 사례는 협업 도구 도입을 준비하는 IT 실무자에게 몇 가지 시사점을 준다. 첫째, 가입이나 온보딩 단계에서 원인 불명의 도메인 거부를 만나면 즉시 도메인 자체의 문제로 단정하지 말고, 브라우저 개발자 도구로 클라이언트 측 검증 로직을 확인해 볼 가치가 있다. 겉으로는 계정이나 도메인 평판 문제처럼 보여도 실제 원인은 단순한 패턴 매칭 규칙일 수 있다. 둘째, 벤더의 1차 지원이 '다른 브라우저·다른 기기'식의 정형화된 응답만 반복한다면, 문제를 재현 가능한 최소 사례로 정리해 상위 채널로 신속히 에스컬레이션하는 편이 시간을 아낀다. 셋째, 이런 오탐은 도메인 명명 규칙을 정할 때도 참고가 된다. web, me, mail처럼 이메일이나 웹 인프라를 연상시키는 짧은 레이블은 외부 서비스의 휴리스틱에 걸릴 여지가 있으므로, 신규 도메인이나 서브도메인을 설계할 때 이런 마찰 가능성을 미리 염두에 두는 것이 안전하다.