갑자기 챗GPT가 먹통이 되고 유튜브 접속이 안 돼서 당황하셨죠. 해킹이라도 당한 건가 싶었지만, 알고 보니 범인은 엉뚱한 곳에 있었습니다. 바로 전 세계 인터넷의 연결 고리 역할을 하는 클라우드플레어 였습니다.
도대체 왜 한 회사의 실수가 전 세계를 마비시켰을까요. 그 속사정을 파헤쳐 보았습니다.
첫 번째 의문, 왜 다 같이 멈췄을까 이유는 간단했습니다.
수많은 글로벌 서비스들이 보안과 전송 속도를 위해 클라우드플레어라는 단일 업체의 시스템을 빌려 쓰고 있었기 때문입니다.
연결 통로가 막히니 서비스도 당연히 올스톱될 수밖에 없었습니다.
두 번째, 그럼 거기는 왜 고장 났을까 외부의 거창한 사이버 공격이 아니었습니다.
내부에서 데이터베이스 권한을 변경하다가 발생한 단순한 설정 오류였습니다.
사소한 실수 하나가 나비효과처럼 번져 전 세계 네트워크를 강타한 셈입니다.
세 번째, 왜 파급력이 이렇게 컸을까 이게 바로 이번 사태의 핵심입니다.
요즘 기업들은 직접 서버를 관리하기보다는, 효율성을 위해 소수의 거대 클라우드 기업에 인프라를 빌려 쓰는 것을 선호합니다.
편하자고 선택한 방식이 오히려 모든 서비스가 한 번에 무너지는 도미노 구조를 만든 것입니다.
네 번째, 왜 기업들은 위험을 알면서도 한곳으로 몰릴까 아마존, 마이크로소프트, 구글 같은 빅테크 기업들이 시장의 80% 이상을 꽉 잡고 있습니다.
이들이 제공하는 압도적인 속도와 편의성을 기업 입장에서 포기하기란 쉽지 않습니다.
결국 너도나도 이들을 쓰다 보니 인프라 쏠림 현상이 걷잡을 수 없이 심각해졌습니다.
마지막으로, 진짜 근본적인 문제는 무엇일까 결국 효율성만 쫓다가 다양성을 잃어버린 것이 화근입니다.
계란을 한 바구니에 담지 말라는 격언처럼 인프라를 여러 곳에 분산시켜야 하는데, 지금의 인터넷 환경은 거대 기업 몇 곳에 목숨을 맡긴 기형적인 구조가 고착화되었습니다.
하나의 점이 실패하면 전체가 무너지는 구조적 취약점이 드러난 것입니다.
요약하자면 이번 사태는 단순한 기계적 결함이라기보다, 독과점된 IT 생태계가 우리에게 보낸 경고장과 같습니다.
편한 것도 좋지만, 이제는 위험을 분산하는 멀티 클라우드 전략이 선택이 아닌 생존의 필수 조건이 되어가고 있다는 사실을 기억해야 할 것 같습니다.
기술적으로
Multi-CDN 전략을 사용하면 되는데요.
이 전략은 클라우드플레어 하나만 믿는 것이 아니라, AWS의 클라우드프론트(CloudFront)나 아카마이(Akamai) 같은 다른 회사의 전송망을 함께 준비해 두는 방식입니다.
평소에는 트래픽을 분산해서 받거나 클라우드플레어를 주로 쓰다가, 이번 사태처럼 클라우드플레어가 멈추면 즉시 대기하고 있던 다른 회사의 망으로 접속 경로를 돌려버리는 것입니다.
이렇게 하면 사용자는 서비스가 멈춘 줄 모르고 계속 이용할 수 있습니다.
하지만 이 방법이 생각보다 도입하기 어려운 현실적인 이유가 두 가지 있습니다.
첫째는 비용 문제입니다.
말 그대로 집을 두 채 빌리는 것과 같아서 인프라 비용이 크게 증가합니다.
대기업이나 금융사가 아니면 섣불리 도입하기 부담스러운 구조입니다.
둘째는 기술적 복잡성입니다.
클라우드플레어는 단순한 서버가 아니라 인터넷의 네비게이션 역할을 하는 DNS 기능까지 담당하는 경우가 많습니다.
네비게이션 자체가 고장 나면 우회 도로를 안내해 줄 방법이 사라지기 때문에, DNS 서버까지 이중으로 구성해야 하는 매우 까다로운 기술적 설정이 필요합니다.
비용과 관리의 어려움 때문에 보통은 사고가 났을 때의 손실액이 이중화 비용보다 훨씬 큰 대형 서비스들이 사용할 수 있습니다.
