블루스카이(Bluesky)가 만든 AT 프로토콜(ATProto)은 소셜 네트워크를 위한 개방형 기술이다. 그러나 이 기술을 이해하는 가장 좋은 방법은 '탈중앙화'라는 이념보다 대규모 백엔드 엔지니어링의 관점에서 접근하는 것이다. 블루스카이 팀이 공개한 해설 글은 흔한 웹 아키텍처가 어떤 단계를 거쳐 스트림 프로세싱 구조로 진화하는지 되짚은 뒤, 그 구조의 내부를 외부로 개방한 것이 곧 AT 프로토콜이라고 설명한다.
단일 데이터베이스에서 스트림 프로세싱까지
출발점은 익숙하다. 앱 서버 뒤에 커다란 SQL 데이터베이스 하나를 두는 전형적인 구조다. 트래픽이 늘면 캐시를 붙여 성능을 보완한다. 하지만 수억 명 규모의 소셜 네트워크에서는 SQL이 유지하는 '강한 일관성'이 병목이 된다. 시스템 전체의 상태를 균일하게 동기화하는 비용이 확장을 가로막기 때문이다.
해법은 일관성 요구를 '최종적 일관성'으로 완화하고 NoSQL 클러스터로 옮겨가는 것이다. 대신 대가가 따른다. JOIN이나 집계 같은 SQL의 강력한 질의 기능을 잃고, NoSQL은 사실상 키-값 저장소로 단순해진다. 그래서 데이터셋의 미리 계산된 뷰, 즉 캐시된 쿼리 결과를 만들어 두는 별도의 프로그램이 필요해진다. 이렇게 빠른 응답을 담당하는 서버를 뷰 서버(View server)라 부른다.
문제는 기본 데이터와 뷰 서버의 동기화다. 뷰 서버가 잠시 다운되면 업데이트를 놓칠 수 있다. 이를 막기 위해 카프카(Kafka) 같은 이벤트 로그를 도입한다. NoSQL 클러스터의 모든 변경을 기록하고 방송하면, 뷰 서버는 이 로그를 구독하고 재생(replay)하면서 상태를 안정적으로 따라잡는다. 여기까지 오면 완성되는 것이 스트림 프로세싱 아키텍처다. 강한 일관성을 포기한 대가로 읽기 결과가 최신 상태와 다소 어긋날 수 있지만, 쓰기가 누락되거나 잘못된 상태로 빠지는 일은 없다. 저장소를 NoSQL로 단순화하고 뷰 서버로 자체 질의 엔진을 만든 이 방식을 원문은 '데이터베이스를 거꾸로 뒤집었다(inside-out)'고 표현한다. 구축은 번거롭지만 확장성은 탁월하다.
내부 서비스를 공개 API로
AT 프로토콜의 핵심 발상은 여기서 나온다. 위 구조에서 외부에 노출되는 것은 앱 서버뿐이고 NoSQL 클러스터, 이벤트 로그, 뷰 서버는 모두 격리돼 있다. AT 프로토콜은 이 격리를 허물어 내부 서비스를 전부 공개 API로 바꾼다. 누구나 각 서비스의 인스턴스를 세우고 이 탈중앙화 백엔드에 참여할 수 있게 만드는 것이 목표다.
이를 위해 공통 데이터 모델인 '사용자 데이터 레포지토리'를 정의한다. 각 레포지토리는 레코드(record)라 불리는 JSON 문서를 담고, 레코드는 컬렉션(collection)으로 분류된다. 본질은 여전히 NoSQL 저장소지만 체계적으로 구조화된 셈이다. 레포지토리는 누구나 호스팅할 수 있으므로 각각에 URL을 부여하고, 인터넷을 넘나들며 동기화되는 레코드가 위조되지 않았음을 확인하기 위해 암호학적으로 서명한다.
앱뷰와 순환하는 데이터 흐름
실제 앱은 API와 프론트엔드를 담당하는 앱 서버, 네트워크 데이터를 수집하는 뷰 서버를 함께 묶은 앱뷰(Appview)로 동작한다. 사용자는 OAuth로 로그인하며 이 과정에서 자신의 데이터 레포지토리 호스트에 대한 읽기·쓰기 권한을 앱에 부여한다. 그러면 앱은 사용자의 JSON 문서를 읽고 쓸 수 있고, 프로필처럼 다른 앱에서 이미 만들어진 데이터도 그대로 불러올 수 있다. 단일 사용자용 앱이라면 이것으로 충분하다.
쓰기가 일어날 때의 흐름이 이 구조의 성격을 잘 보여준다. 문서를 레포지토리에 커밋하면 이벤트 로그에 기록이 발생하고, 그 이벤트는 이를 구독하는 모든 뷰 서비스로 전파된다. 자신이 쓴 쓰기조차 이벤트 스트림으로 되돌려 받는 이유는, 쓰기 주체가 나 하나가 아니기 때문이다. 수많은 사용자 레포지토리에서 이벤트가 발생하고 여러 앱이 그 위에 기록을 남긴다. 쓰기가 레포지토리에 커밋되고, 이벤트 로그를 거쳐 뷰 서버로 퍼지며, 최종적으로 애플리케이션에서 읽히는 순환적 데이터 흐름이 네트워크 전체를 관통한다.
실무자가 눈여겨볼 지점
이 설계의 뿌리에는 P2P 기술이 있다. 블루스카이의 창립 엔지니어들은 IPFS와 Dat 분야에 밝았고, 『데이터 중심 애플리케이션 설계』의 저자 마틴 클레프만이 기술 자문으로 참여하고 있다. 팀은 프로젝트 초기에 '한 걸음도 뒤로 물러서지 않는다'는 요구를 내걸었다. 기존 소셜 앱만큼 편리하고 전 세계적으로 쓸 수 있으면서도 개방형이어야 한다는 조건이다. 연합(federation)이나 블록체인이 그 기준에서 한계를 드러냈고, 결국 고확장 백엔드의 표준 기법에 P2P 기술을 접목하는 길을 택했다.
실무 관점에서 AT 프로토콜은 완전히 새로운 발명이 아니라, 대규모 서비스라면 이미 익숙한 이벤트 소싱과 CQRS 계열의 패턴을 조직 경계 밖으로 확장한 결과에 가깝다. 그래서 스트림 프로세싱을 다뤄본 엔지니어에게는 낯설지 않다. 다만 개방화에는 명백한 비용이 따른다. 최종적 일관성 아래에서 뷰가 지연될 수 있고, 서명 검증과 레포지토리 동기화라는 부담이 더해지며, 뷰 서버를 통해 질의 계층을 직접 구축해야 하는 번거로움도 그대로 남는다. AT 프로토콜은 이러한 트레이드오프를 감수하는 대신, 단일 사업자의 용량 확장을 넘어 서로 다른 애플리케이션들이 같은 데이터 위에서 공존하도록 만드는 것을 지향한다. 이 그림이 실제 생태계에서 얼마나 매끄럽게 작동할지는 앞으로 참여하는 앱들이 증명해야 할 몫이다.