트위터의 대안으로 자리 잡은 SNS 블루스카이(Bluesky), 다들 한 번쯤 들어보셨을 텐데요. 이 서비스의 밑바닥에는 AT 프로토콜(ATProto)이라는 오픈 프로토콜이 깔려 있어요. 그런데 '탈중앙 SNS'라는 말은 많이 들어봤어도 실제로 어떻게 동작하는지는 감이 잘 안 오잖아요. 오늘 소개할 글은 AT 프로토콜 공식 문서 중에서도 분산 시스템 엔지니어를 대상으로 쓴 설명인데, 이념이나 마케팅 언어를 걷어내고 순수하게 아키텍처 관점으로 풀어낸 게 백미거든요. 결론부터 말하면, AT 프로토콜은 '한 회사의 백엔드를 뒤집어서 인터넷 전체에 펼쳐놓은 스트림 처리 시스템'이에요.
백엔드를 뒤집는다는 것
전통적인 웹 서비스 구조를 떠올려 볼게요. 앱 서버가 있고, 그 뒤에 데이터베이스가 있고, 사용자의 글과 팔로우 관계는 전부 그 회사의 DB에 저장돼요. 회사가 문을 닫으면 데이터도 같이 사라지고, 회사가 정책을 바꾸면 사용자는 따를 수밖에 없죠. AT 프로토콜은 이 구조를 분해해서 각 부분을 서로 다른 주체가 운영할 수 있게 만들었어요.
구성 요소는 크게 셋이에요. 첫째, PDS(개인 데이터 서버)예요. 내가 쓴 글, 좋아요, 팔로우 기록이 전부 내 소유의 데이터 저장소(repo)에 기록되는데, 이 저장소가 git과 비슷하게 서명된 커밋의 연쇄로 되어 있거든요. 그래서 데이터가 어느 서버에 있든 위변조 여부를 암호학적으로 검증할 수 있어요. 둘째, 릴레이(Relay)예요. 전 세계에 흩어진 수많은 PDS의 변경 사항을 실시간으로 긁어모아서 '파이어호스(firehose)'라는 하나의 거대한 이벤트 스트림으로 합쳐줘요. 셋째, 앱뷰(App View)인데요, 이 스트림을 구독하면서 좋아요 수 집계, 팔로워 목록, 타임라인 같은 인덱스를 구축하는 역할이에요. 우리가 블루스카이 앱에서 보는 화면은 이 앱뷰가 만들어낸 결과물이죠.
이게 뭐냐면, 백엔드 개발자에게 익숙한 그림이에요. Kafka 같은 메시지 스트림에 이벤트를 흘리고, 컨슈머들이 그걸 구독해서 각자의 목적에 맞는 뷰를 만들어내는 이벤트 소싱 아키텍처요. 쓰기 경로(내 PDS에 기록)와 읽기 경로(앱뷰가 만든 인덱스 조회)가 분리된 것도 CQRS 패턴과 똑 닮았어요. 차이가 있다면, 보통은 이 파이프라인 전체가 한 회사 인프라 안에 있는데 AT 프로토콜은 각 단계를 서로 다른 조직이 운영할 수 있도록 인터넷 규모로 펼쳐놨다는 거예요.
계정을 들고 이사 갈 수 있는 이유
또 하나 재미있는 설계가 신원 처리예요. 사용자의 정체성이 DID(탈중앙 식별자)라는 서버 주소와 무관한 ID로 관리되거든요. 덕분에 지금 쓰는 PDS가 마음에 안 들면 데이터 저장소를 통째로 들고 다른 서버로 이사할 수 있고, 팔로워 관계도 그대로 유지돼요. 이메일 주소를 바꿔도 나라는 사람은 그대로인 것처럼, 서버와 정체성을 분리해 놓은 거죠.
ActivityPub과는 뭐가 다를까
탈중앙 SNS 하면 마스토돈이 쓰는 ActivityPub 프로토콜이 먼저 떠오르실 텐데요, 두 방식은 철학이 꽤 달라요. ActivityPub은 서버 중심 연합이에요. 내 계정과 데이터가 특정 서버에 종속돼 있어서, 그 서버가 사라지면 내 계정도 같이 사라지고, 네트워크 전체를 아우르는 검색이나 글로벌 피드를 만들기가 구조적으로 어렵거든요. 반면 AT 프로토콜은 데이터 중심이에요. 전체 네트워크의 이벤트가 파이어호스로 모이니까 전역 검색이나 통합 타임라인 같은 기능이 자연스럽게 가능해요. 물론 공짜는 아니에요. 네트워크 전체를 받아서 처리하는 릴레이와 앱뷰는 운영 비용이 만만치 않아서, '누구나 모든 걸 운영할 수 있지만 현실적으로는 자원이 있는 조직이 큰 부분을 맡게 되는' 트레이드오프가 있어요. 완전한 탈중앙보다는 '이사 갈 자유가 보장된 구조적 개방성'에 가깝다고 보는 게 정확할 거예요.
한국 개발자에게는
실용적인 포인트가 두 가지 있어요. 첫째, 파이어호스가 공개되어 있다는 것. 누구나 이 스트림을 구독해서 커스텀 피드, 통계 대시보드, 검색 서비스 같은 걸 만들 수 있거든요. 예를 들어 한국어 게시글만 골라 보여주는 피드나 특정 주제 트렌드 분석기 같은 사이드 프로젝트를 실제 대규모 실시간 데이터로 만들어볼 수 있는 거예요. 둘째, 이벤트 소싱과 CQRS를 살아있는 대규모 사례로 공부할 수 있다는 것. 면접이나 아키텍처 설계에서 자주 나오는 패턴인데, 교과서 예제가 아니라 실제로 돌아가는 전 지구적 시스템으로 뜯어볼 수 있는 기회는 흔치 않거든요.
정리하면, AT 프로토콜은 이벤트 소싱 아키텍처를 회사 담장 밖으로 꺼내 인터넷 규모로 구현한 실험이에요. 여러분은 어떻게 보세요? 데이터 소유권을 위해 이 정도의 아키텍처 복잡도와 운영 비용을 감수할 가치가 있을까요, 아니면 잘 만든 중앙화 서비스가 결국 이길까요?
🔗 출처: Hacker News