AT Protocol: 소셜 네트워킹을 넘어선 분산 앱 프레임워크
AT Protocol은 Bluesky 소셜 네트워크의 기반 기술로 널리 알려져 있지만, 그 설계 철학은 훨씬 더 넓은 범위의 분산 애플리케이션에 적용할 수 있다. 핵심 아이디어는 로컬 퍼스트(Local-First) 아키텍처다. 사용자 데이터를 중앙화된 서버가 아닌 개인 데이터 서버(PDS, Personal Data Server)에 보관하고, 공유 인프라를 통해 동기화하는 구조를 취한다. 4년차 이상의 백엔드 개발자라면 이 구조가 기존의 중앙집중식 백엔드 설계와 어떻게 다른지 주목할 필요가 있다.
전통적인 웹 애플리케이션은 앱별로 전용 백엔드를 구성하고, 모든 데이터를 해당 서비스의 데이터베이스에 집중시킨다. 이 방식은 서비스 장애나 운영사의 정책 변경에 사용자 데이터가 고스란히 종속되는 문제를 안고 있다. AT Protocol은 이 의존성을 구조적으로 끊어낸다. 사용자는 자신의 PDS를 소유하고, 애플리케이션은 해당 PDS와 상호작용하는 클라이언트 역할로 분리된다.
PDS 기반 설계가 백엔드 아키텍처에 주는 시사점
AT Protocol에서 PDS는 사용자 데이터의 단일 진실 공급원(Single Source of Truth) 역할을 한다. 애플리케이션 서버는 데이터를 직접 소유하는 대신, PDS로부터 데이터를 읽고 쓰는 인터페이스로 동작한다. 이는 백엔드 개발자 관점에서 몇 가지 설계 전환을 요구한다.
- 데이터 소유권 분리: 앱 서버는 비즈니스 로직만 담당하고, 퍼시스턴스 책임은 PDS로 위임된다.
- 공유 인프라 재사용: 여러 애플리케이션이 동일한 PDS 인프라 위에서 동작하므로, 협업 도구나 메모 앱 등 다양한 서비스를 별도 백엔드 없이 구성할 수 있다.
- 오프라인 내성: 로컬 퍼스트 특성상, 네트워크 단절 상황에서도 로컬 PDS의 데이터를 기반으로 애플리케이션이 동작하고, 연결 복구 시 동기화된다.
// 개념적 예시: AT Protocol 레코드 구조
public record AtRecord(
String repo, // PDS 식별자 (DID)
String collection, // 레코드 타입 (예: app.bsky.feed.post)
String rkey, // 레코드 키
Map<String, Object> value
) {}
이처럼 데이터 구조 자체가 "어느 PDS의 어느 컬렉션에 속한 레코드인지"를 명시적으로 표현하므로, 분산 환경에서의 추적과 동기화가 프로토콜 레벨에서 지원된다.
협업 도구에 적용했을 때의 실제 이점
AT Protocol을 활용한 실험적 협업 도구 사례에서, 여러 사용자가 각자의 PDS에 데이터를 보유하면서도 공유 인프라(릴레이, 앱뷰)를 통해 실시간에 가까운 협업이 가능함이 확인됐다. 기존의 협업 도구들이 중앙 서버에서 모든 상태를 관리하던 방식과 달리, 각 사용자의 변경 사항이 PDS에 먼저 기록되고 이후 동기화되는 흐름을 취한다.
백엔드 관점에서 주목할 부분은 앱별 전용 백엔드 의존성 감소다. 새로운 기능이나 서비스를 추가할 때, 전용 데이터 저장소와 인증 시스템을 매번 새로 구축하는 대신 AT Protocol 인프라를 재사용할 수 있다. 운영 비용과 아키텍처 복잡도를 동시에 줄일 수 있는 접근이다.
[사용자 클라이언트]
↕ (읽기/쓰기)
[PDS - Personal Data Server]
↕ (동기화)
[Relay - 공유 이벤트 스트림]
↕
[AppView - 앱별 집계/렌더링 레이어]
정리
- AT Protocol의 PDS 기반 로컬 퍼스트 아키텍처는 데이터 소유권을 사용자에게 돌려주고, 앱 서버의 역할을 비즈니스 로직 레이어로 축소한다.
- 공유 인프라(릴레이, 앱뷰)를 재사용함으로써 서비스마다 전용 백엔드를 구축하는 비용과 복잡도를 낮출 수 있다.
- 협업 도구 등 동기화가 중요한 애플리케이션에서 네트워크 내성과 데이터 일관성을 동시에 확보하는 설계 패턴으로 주목할 만하다.