본 글은 2026년 4월 18일부터 22일까지 미국에서 발생한 도메인 강제 양도 사고를 정리하고, 한국 운영자가 자기 인프라에 즉시 적용할 수 있는 도메인 자산 보호 절차를 제시합니다. 도메인 탈취가 외부 공격이 아니라 레지스트라 내부 절차에서도 발생할 수 있다는 점이 이번 사고의 핵심입니다.
분석 시점은 2026년 4월 26일 기준이며, 인용 원본은 Anchor Hosting의 사고 보고서입니다. 표준 참조는 ICANN Transfer Policy 2016-06-01 개정본과 RFC 5731 EPP 표준을 따릅니다.
1. 4분 만에 사라진 27년 도메인
Anchor Hosting의 보고에 따르면 미국 펜실베이니아의 IT 회사 Flagstream Technologies는 2026년 4월 18일 토요일 오후, 한 클라이언트가 27년간 운영해 온 도메인이 GoDaddy 계정에서 사라진 것을 확인했습니다. 보고 기준 계정 복구 요청 시각은 13시 39분, 양도 완료는 13시 43분으로 단 4분이 소요되었습니다.
해당 GoDaddy 계정에는 이메일 코드와 인증 앱 코드를 함께 요구하는 이중 2단계 인증이 적용되어 있었고, 도메인 자체에도 GoDaddy가 판매하는 “Full Domain Privacy and Protection” 보호 상품이 활성화되어 있었습니다. Anchor Hosting의 정리 기준 양도 감사 로그에는 “Internal User에 의한 양도, Change Validated: No”가 기록되었습니다.
도메인이 새 계정으로 옮겨지자 GoDaddy는 DNS 영역을 기본값으로 초기화했고, 그 결과 해당 도메인을 부모로 사용하던 비영리 단체 산하 20개 지부의 웹과 이메일이 모두 정지되었습니다. 사고 원본 기록은 Anchor Hosting 블로그의 사고 보고서에서 확인할 수 있습니다.
2. 핵심 타임라인 정리
Anchor Hosting의 보고서를 시간 순서로 정리하면 다음과 같습니다. 모든 시각은 미국 동부 시간 기준이며, 회사·도메인 명은 보고서 내 가명을 그대로 따릅니다.
- 4월 18일 13시 39분 — GoDaddy가 계정 복구 요청 알림 발송.
- 4월 18일 13시 42분 — 내부 직원 권한으로 양도 절차 시작.
- 4월 18일 13시 43분 — 양도 완료, “Change Validated: No” 기록.
- 4월 19~21일 — Flagstream의 통화·이메일 시도. 안내 받는 응대 이메일 주소가 매일 변경됨 (undo, transferdisputes, artreview 등 generic 주소).
- 4월 21일 — GoDaddy가 “수령자가 필요 서류를 제출했다”며 사건 종결을 통보.
- 4월 22일 — 도메인을 우연히 받은 수령자 본인이 이상함을 인지하고, 계정 간 이전으로 도메인 복구.
Anchor Hosting의 집계 기준 사고 대응 통화는 총 32회, 누적 통화 시간 9.6시간, 발신 이메일 17건이며, GoDaddy 측 콜백은 0건이었습니다. 보고서는 동일 사건에 대해 발급된 케이스 번호가 7개 이상이었으며 서로 연결되지 않은 채 매번 처음부터 사실 관계를 다시 설명해야 했다고 적습니다.
3. 무력화된 보호 장치들
이번 사고에서 주목할 부분은 일반적으로 도메인 보안 강화의 정석으로 여겨지는 항목들이 모두 적용되어 있었음에도 도메인 탈취를 막지 못했다는 점입니다.
3-1. 계정 측 2단계 인증
이메일 코드와 인증 앱 코드를 모두 요구하는 이중 2단계 인증은 외부 공격자의 계정 탈취를 막는 데 유효합니다. 그러나 이번 사례는 외부 로그인이 아니라 레지스트라 내부 절차에서 발생한 양도였습니다. Anchor Hosting의 보고에 따르면 양도 시점에 사용자 측 2단계 인증 입력은 요구되지 않았습니다.
3-2. Domain Ownership Protection
GoDaddy의 “Full Domain Privacy and Protection”은 양도와 DNS 변경에 대해 추가 본인 확인을 약속하는 유료 상품입니다. 보고 기준 이번 사고 도메인은 해당 보호가 활성화되어 있었지만 내부 절차에서는 무시되었습니다. 즉 보호 상품이 보장하는 “추가 검증”이 모든 양도 경로에 일관되게 적용되지 않는다는 점이 사건으로 노출되었습니다.
3-3. ICANN Transfer Policy의 사각지대
ICANN의 Transfer Policy는 다른 레지스트라 사이의 양도(inter-registrar transfer)에 대해 5일 대기 기간과 EPP 인증 코드 검증을 강제합니다. 그러나 같은 레지스트라 내부의 계정 간 이전은 동일한 표준의 적용 대상이 아닙니다. 이번 사고는 정확히 이 사각지대에서 발생했습니다.
4. 인시던트 대응 구조의 문제
Anchor Hosting의 정리에 따르면 사고 후 4일간 GoDaddy 측 응대는 다음 패턴을 반복했습니다. 운영 관점에서 시사점이 큰 부분입니다.
- 응대 채널이 일관되지 않음. 매일 다른 generic 이메일 주소가 안내됨
- 케이스 번호가 단일 인시던트로 통합되지 않고 매 통화마다 신규 발급
- 에스컬레이션 시 새 담당자가 처음부터 사실 관계를 다시 청취
- 외부 보안 제보용 이메일 주소가 차단 자동 응답으로 막혀 있어 정상 채널이 작동하지 않음
Anchor Hosting의 작성자는 결국 HackerOne 공개 신고를 통해서야 GoDaddy 보안팀에 도달할 수 있었다고 적습니다. 즉 공식 채널이 사실상 작동하지 않는 상태였으며, “신고를 통해 공개되지 않으면 사고가 알려지지 않는” 구조였습니다.
5. 한국 운영자 관점에서 본 시사점
이번 사고는 미국 레지스트라에서 발생했지만 한국 운영자에게도 동일한 도메인 탈취 위험이 존재합니다. 가비아·후이즈·카페24·AWS Route 53 같은 국내·해외 레지스트라 모두 자체 내부 양도 절차를 가지고 있고, ICANN Transfer Policy의 외부 양도 보호와는 별개로 동작하기 때문입니다.
특히 다수의 지부·계열사 도메인이 하나의 부모 도메인 아래 운영되는 경우, 부모 도메인 한 곳의 사고가 전체 조직의 다운으로 이어집니다. 이번 사고도 보고서가 가명 처리한 부모 도메인 아래 20개 지부 서브도메인이 동시에 정지된 사례입니다. 다중 레지스트라 분산보다 부모 도메인의 무결성이 우선 점검 대상입니다.
또 한 가지 고려할 점은 인시던트 발생 시 “어디로 어떻게 신고해야 하는지”가 사전에 문서화되어 있는지 여부입니다. 사고 발생 후 24시간 안에 레지스트라의 정확한 분쟁 채널을 찾아낼 수 있는 운영자는 의외로 많지 않습니다.
6. 도메인 자산 보호 체크리스트
이번 사고를 토대로 한국 운영자가 즉시 점검할 수 있는 항목을 정리했습니다. ICANN Transfer Policy 및 RFC 5731 EPP 표준 기준이며, 레지스트라마다 지원 여부가 상이하므로 사전 확인이 필요합니다.
- Registry Lock 활성화: 레지스트라 내부 양도까지 막는 상위 보호. 모든 레지스트라가 제공하지는 않으므로 계약 시 명시 확인이 필요합니다.
- 관리자 이메일 분리: 도메인 등록 정보의 관리자 이메일은 운영 도메인 자체와 다른 도메인을 사용하도록 합니다. 운영 도메인 다운 시 본인 인증이 막히지 않도록 합니다.
- EPP 인증 코드 보관: 외부 양도용 EPP 인증 코드는 별도 비밀 저장소에 보관하고 분기별 재발급을 검토합니다.
- 분쟁 채널 사전 문서화: 레지스트라별 transfer dispute 양식 URL, 보안 제보 채널, ICANN UDRP 분쟁 신청 절차를 운영 위키에 미리 명시합니다.
- WHOIS 모니터링: 일일 또는 시간 단위 WHOIS 차이 감지 도구를 도입해 무단 변경을 즉시 인지합니다.
- DNSSEC 적용: DNS 영역 자체의 무결성 서명을 강제해 영역 초기화 사고에 대비합니다.
7. 정리
Anchor Hosting의 보고서는 결과적으로 도메인이 회복된 이유로 “수령자가 정직하게 이상함을 알아차린 것”을 꼽습니다. 즉 운영자가 통제 가능한 영역에서 회복된 사고가 아니었습니다. 이는 도메인이라는 자산이 외부 신뢰 체인에 깊게 의존한다는 사실을 다시 한 번 확인시켜 줍니다.
2026년 4월 시점 기준 가장 현실적인 도메인 탈취 대응은 다중 레지스트라 분산 자체보다 “단일 부모 도메인의 보호 강도”를 끌어올리는 것입니다. Registry Lock·DNSSEC·관리자 이메일 분리는 ICANN과 RFC 차원에서 정의된 표준 기능이므로 즉시 적용을 시작할 수 있습니다.
관련 글
외부 도구·플랫폼 의존성을 다른 각도에서 다룬 글들도 함께 참고할 수 있습니다.
- 외부 도구 도입 시 점검할 사고방식과 트레이드오프는 Claude의 디자인 철학, 개발자는 무엇을 읽어야 하는가 글에서 정리했습니다. 외부 의존을 결정하기 전 점검할 관점을 보강하는 데 도움이 됩니다.
- 외부 LLM API 도입 시 비용·운영 리스크 점검 방법은 DeepSeek v4 API 공개, flash·pro 모델과 thinking mode 정리에서 다뤘습니다. 도메인과 마찬가지로 외부 서비스 잠금 비용을 산정하는 데 참고할 수 있습니다.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요