Bluesky, 하루 가까운 DDoS 공격에 시달리다: 탈중앙 SNS의 현실 체크

하루 종일 이어진 공격

탈중앙 SNS로 주목받아온 Bluesky가 약 하루 동안 이어진 DDoS 공격을 받아 서비스 접속이 불안정한 상황이 발생했어요. 앱이 느려지거나 로그인이 안 되고, 타임라인이 제대로 갱신되지 않는 현상이 전 세계 사용자들에게서 보고됐죠.

DDoS가 뭐냐면, Distributed Denial of Service의 줄임말이에요. 수많은 컴퓨터(보통은 해커가 장악한 봇넷)에서 한꺼번에 엄청난 양의 요청을 특정 서버로 보내, 정상 사용자의 접속을 막아버리는 공격이에요. 서버는 멀쩡한데 전화선이 계속 울려서 진짜 손님 전화를 못 받는 상황이라고 보시면 돼요. 공격 자체는 데이터를 훔치거나 서비스를 망가뜨리는 게 아니지만, 서비스 중단으로 인한 신뢰도 손상이 만만치 않죠.

Bluesky는 어떤 서비스인가

배경을 잠깐 짚고 갈게요. Bluesky는 트위터 공동창업자 Jack Dorsey가 트위터 내부 프로젝트로 시작했다가 독립시킨 SNS예요. 핵심 차이점은 AT Protocol이라는 개방형 프로토콜 위에 세워졌다는 점이에요. 이게 뭐냐면, 사용자 데이터(게시물, 팔로우 관계, 좋아요)가 특정 회사 서버에 묶이지 않고, 원한다면 본인의 서버(PDS, Personal Data Server)에 두고 다른 앱에서도 불러올 수 있는 구조예요. "하나의 계정으로 여러 앱을 넘나들 수 있다"는 철학이죠.

경쟁자로는 Mastodon과 Threads가 있어요. Mastodon은 ActivityPub 프로토콜을 쓰는 완전 연합형(federated)이고, Threads는 메타(Meta)의 중앙 집중형인데 ActivityPub과 부분 연동을 시작했어요. Bluesky는 이 사이 어딘가에 위치하는 독특한 포지션이에요.

탈중앙인데 왜 한 번에 다운될 수 있나

여기서 흥미로운 질문이 생겨요. 탈중앙이라면서 왜 중앙 서비스처럼 한 번에 멈추지? 이게 Bluesky의 현재 구조적 특징을 드러내는 지점이에요.

AT Protocol은 이론상 분산 가능하지만, 실제로는 Bluesky 회사가 운영하는 중앙 인프라에 대부분의 사용자가 몰려 있어요. 구체적으로는 Relay(모든 PDS의 게시물을 모아주는 허브), AppView(타임라인과 검색 등을 제공하는 서비스), 그리고 기본 PDS까지 전부 Bluesky Inc.가 호스팅하고 있죠. 이 중 어느 하나라도 공격받아 다운되면, 사실상 전체 서비스가 멈추는 것처럼 보여요.

이번 DDoS는 그런 집중 지점을 정확히 건드린 사례로 해석할 수 있어요. Mastodon처럼 완전한 연합형이라면 한 서버가 다운돼도 다른 서버 사용자들은 정상 이용할 수 있지만, Bluesky는 아직 그 수준의 분산에 도달하지 못한 상태거든요. 커뮤니티에서도 이번 사건을 두고 "Bluesky는 탈중앙이라기보단 '탈중앙이 가능한 중앙형'에 가깝다"는 비판이 다시 제기됐어요.

업계 맥락: SNS와 DDoS의 오래된 악연

DDoS는 SNS에게 낯선 일이 아니에요. 트위터, 깃허브, 심지어 클라우드플레어 자체도 대규모 공격을 받은 적이 있어요. 2016년 Mirai 봇넷이 DNS 업체 Dyn을 공격해 트위터, 넷플릭스, 레딧이 한꺼번에 마비된 사건은 업계의 상징적인 사고였죠.

방어 기법도 그만큼 발전했어요. Anycast 기반 트래픽 분산, L7 방화벽, AI 기반 이상 탐지, 트래픽 스크러빙 서비스(Cloudflare, Akamai 같은) 같은 것들이 대표적이에요. 그럼에도 공격 규모가 테라비트급으로 커지면서, 방어 측도 쉽지 않은 군비 경쟁이 이어지고 있어요. 스타트업 규모의 Bluesky가 트위터급 방어 인프라를 처음부터 갖추기는 어렵다는 현실이 이번에 드러난 거죠.

한국 개발자에게 주는 시사점

몇 가지 실무적인 교훈이 있어요. 첫째, 아키텍처와 실운영은 다르다는 점이에요. 시스템이 이론상 분산 가능하게 설계돼 있어도, 실제 배포가 한 리전, 한 업체에 몰려 있으면 가용성은 중앙 시스템과 다를 게 없어요. 본인의 프로젝트에서 "다중화"를 이야기할 때 정말 독립적인 실패 단위로 나눠져 있는지 점검해볼 필요가 있어요.

둘째, DDoS 방어는 처음부터 계획에 넣어야 한다는 거예요. Cloudflare, AWS Shield, GCP Cloud Armor 같은 서비스의 기본 플랜만 붙여둬도 상당한 방어가 가능해요. 특히 공개 API를 운영하거나 사용자 콘텐츠를 다루는 서비스라면 필수에 가까워요.

셋째, 프로토콜 개방성과 운영 분산은 별개라는 거예요. AT Protocol처럼 기술 표준을 공개하는 것과, 실제로 여러 독립 운영자가 생태계를 굴리는 것은 다른 단계의 성숙도예요. 탈중앙 시스템을 기획하거나 참여할 때 이 차이를 분명히 이해하고 있어야 기대와 현실의 간극에 덜 실망하죠.