새벽 3시에 PagerDuty 알림이 울리는 것보다 더 무서운 게 뭔지 아십니까.
서버는 멀쩡한데, 도메인이 사라지는 겁니다.
방금 섀도우 라이브러리계의 거물, Anna’s Archive의 메인 도메인(annas-archive.org)이 날아갔습니다.
단순 접속 장애가 아닙니다.
WHOIS 정보를 까보니 'serverHold' 상태가 찍혔더군요.
엔지니어 생활 15년 하면서 이 코드를 볼 일은 거의 없습니다.
이건 사용자가 도메인 비용을 안 내서 생기는 'clientHold'와는 차원이 다릅니다.
도메인 최상위 등록기관(Registry)이 직접 개입해서 "이 도메인은 인터넷에서 지워버리겠다"고 스위치를 내린 겁니다.
오늘은 이 '디지털 사형 선고'에 대해 이야기해 보려 합니다.
보통 .org 도메인을 관리하는 PIR(Public Interest Registry)은 이런 조치를 잘 취하지 않습니다.
그 악명 높은 'The Pirate Bay' 시절에도 자발적인 정지는 거부했던 곳입니다.
그런데 이번엔 달랐습니다.
아마도 강력한 법원 명령(Court Order)이 있었을 겁니다.
Anna’s Archive가 최근 Spotify의 300TB 분량 데이터를 백업해서 공개하겠다고 선언했거든요.
저작권 진영에서는 이 친구들이 단순히 책을 공유하는 게 아니라, 거대 언어 모델(LLM) 학습용 데이터의 허브가 되는 걸 두려워하는 눈치입니다.
단순한 불법 사이트가 아니라 'AI 학습 데이터의 블랙마켓'이 되어버렸으니까요.
재미있는 건 이들의 대응 방식입니다.
일반적인 기업이었다면 CEO가 사과문을 올리고 서비스 종료를 알렸을 겁니다.
하지만 이들은 SRE(Site Reliability Engineering) 관점에서 보면 아주 흥미로운 회복 탄력성(Resiliency)을 보여줍니다.
메인 도메인이 죽자마자 트래픽을 .li, .se, .in, .pm 같은 대체 도메인으로 우회시켰습니다.
마치 넷플릭스가 AWS 리전(Region) 하나가 죽었을 때 다른 리전으로 트래픽을 넘기듯 자연스럽습니다.
이들은 이미 학습이 되어 있습니다.
과거 WorldCat 데이터 스크래핑 건으로 소송을 당했을 때도 .GS 도메인으로 피신했다가 정지당한 이력이 있거든요.
결국 이들에게 도메인은 영구적인 주소가 아니라, 언제든 버릴 수 있는 '일회용 진입점'에 불과한 겁니다.
많은 주니어 개발자들이 시스템 설계를 할 때 '서버가 죽지 않는 법'만 고민합니다.
오토스케일링(Auto-scaling)을 걸고, 데이터베이스를 이중화하죠.
하지만 DNS(Domain Name System) 레벨에서의 가용성은 간과합니다.
우리가 아무리 백엔드를 튼튼하게 지어놔도, 도메인 등록기관이 serverHold를 걸어버리면 접속 가능한 가용성은 0%가 됩니다.
Anna’s Archive 사례는 극단적이지만, 엔지니어링 관점에서는 시사하는 바가 큽니다.
진정한 고가용성(High Availability)은 특정 벤더나 특정 TLD(Top Level Domain)에 종속되지 않는 것에서 시작한다는 점입니다.
물론 여러분이 불법 사이트를 운영할 일은 없겠지만요.
하지만 기업 환경에서도 비슷한 일은 일어납니다.
결제 모듈이 터지거나, 서드파티 API가 먹통이 되거나, 심지어 클라우드 계정이 잠길 수도 있습니다.
그때 "우리 서버는 멀쩡한데요?"라고 말하는 건 아마추어입니다.
사용자 입장에서는 서비스가 죽은 거랑 똑같으니까요.
Anna’s Archive 운영자는 레딧에 "이런 일은 자주 발생한다"며 담담하게 대체 주소를 공지했습니다.
이 정도의 '무덤덤함'이 있어야 이 바닥에서 살아남습니다.
시스템을 설계할 때 항상 SPOF(Single Point of Failure)가 어디인지 의심하십시오.
그게 서버가 아니라, 도메인 주소 그 자체일 수도 있다는 사실을 잊지 마세요.
범인을 찾지 말고(Blaming), 시스템의 취약점을 찾으십시오.
그래야 새벽 3시에 잠을 잘 수 있습니다.
