ATProto: 왜 인스턴스가 없는가

ATProto와 Mastodon과 같은 연합 네트워크의 근본적인 차이점은 ATProto가 "인스턴스"를 사용하지 않는다는 점입니다. 연합 소셜 네트워크가 결합된 호스팅 및 애플리케이션 로직에 의존하는 반면, ATProto는 이러한 기능을 분리하여 사용자가 자신의 정체성이나 소셜 그래프를 잃지 않고 호스팅 제공업체를 교체할 수 있도록 합니다.

호스팅과 집계의 분리

ATProto는 호스팅과 집계가 두 개의 별개 네트워크 수준 기능으로 설계된 시스템입니다. 전통적인 연합 시스템에서 "인스턴스"는 호스팅과 애플리케이션 자체의 묶음입니다. 대조적으로, ATProto는 데이터 호스팅을 앱이 집계하는 기초 레이어로 취급합니다.

이 아키텍처는 초기 웹의 RSS 및 Google Reader 모델을 반영합니다. 사용자는 자신의 블로그(호스팅)에 콘텐츠를 게시하고, 집계 앱(Google Reader와 같은)을 사용하여 해당 콘텐츠의 결합된 피드를 봅니다. ATProto에서 애플리케이션은 데이터가 거주하는 장소가 아니라 네트워크 전체에 호스팅된 데이터의 "투영(projection)"입니다.

비교: 연합 vs. ATProto

연합 인스턴스 (예: Mastodon/ActivityPub)

연합 모델에서 사용자는 특정 인스턴스에 "속해" 있습니다. 정체성은 그들이 가입한 서버에 연결되어 있으며, 이는 여러 구조적 의존성을 생성합니다:

정체성 결합: 사용자의 정체성은 종종 불변하며 서버에 연결되어 있습니다 (예: user@instance.com).
관리자 정책에 대한 의존성: 두 인스턴스 관리자가 연합을 중단하기로(defederation) 결정하면, 사용자들이 개인적인 선호도와 관계없이 해당 인스턴스에서 더 이상 통신할 수 없습니다.
단일 장애점: 인스턴스가 종료되면, 수동으로 마이그레이션하지 않는 한 사용자의 정체성과 데이터는 일반적으로 존재를 멈춥니다.
확장 복잡성: 인스턴스들이 서로 간에 포스트를 전달하기 위해 합의를 구축해야 하므로 네트워크 토폴로지는 $O(n^2)$로 확장됩니다.

ATProto 모델

ATProto는 호스팅과 애플리케이션이 독립적으로 존재할 수 있도록 함으로써 "인스턴스" 개념을 제거합니다. 이는 사용자에게 데이터에 대한 더 큰 주도권을 제공합니다:

이동 가능한 정체성: 사용자는 자신의 정체성이나 팔로워를 잃지 않고 호스팅(Personal Data Servers 또는 PDS)을 마이그레이션할 수 있습니다.
앱 다양성: 앱은 단지 데이터의 투영일 뿐이므로, 사용자는 Bluesky 애플리케이션에 묶이지 않고 동일한 데이터를 보기 위해 다양한 클라이언트(Tangled 또는 Semble과 같은)를 사용할 수 있습니다.
유연한 인프라: 사용자는 자신의 PDS를 직접 실행하거나 성능을 위해 커뮤니티가 운영하는 캐시 또는 릴레이를 사용하여 데이터를 집계할 수 있습니다.

기술적 구현 및 커뮤니티 관점

아키텍처는 개념적으로 우아하지만, 커뮤니티 논의는 몇 가지 기술적 트레이드오프와 구현 세부 사항을 강조합니다:

릴레이와 AppViews의 역할

릴레이는 ATProto를 성능이 뛰어나게 만드는 "접착제" 역할을 합니다. 릴레이는 PDS에서 AppViews로 데이터를 전달하며, 집계자가 쿼리해야 하는 서비스의 수를 줄여줍니다. 일부 비판론자들은 이것이 시스템을 고비용 인프라에 의존하게 만든다고 주장하며, RSS 비유가 불완전하다고 지적합니다. 왜냐하면 RSS 피드는 일반적으로 ATProto 데이터 피드보다 더 자급자족적이기 때문입니다.

일관성 vs. 탈중앙화

일부 사용자는 ATProto가 "진정한" 탈중앙화보다는 일관성과 데이터 소유권을 우선시한다고 주장합니다. 콘텐츠 릴레이를 실행하는 것이 Mastodon 노드를 실행하는 것보다 더 많은 리소스가를 요구하기 때문에, 네트워크의 탈중앙화는 네트워크 인프라의 집합적 소유권보다는 개별 데이터의 소유권에 초집점을 맞춥니다.

PDS를 "관습적(De Facto)" 인스턴스로 보는 관점

Personal Data Server (PDS)가 단순히 이름이 바뀐 인스턴스인지에 대한 논쟁이 있습니다. 일부는 사용자가 정준적인(canonical) PDS에 쓰고, DNS를 통해 발견이 이루어지기 때문에 아키텍처가 피어-투-피어 분산 데이터베이스보다는 클라이언트-서버 모델로 남는다고 주장합니다.

"만약 그것이 오리처럼 꽥꽥거린다면... 계정은 단일 Personal Data Server (PDS)를 가집니다, 맞죠? DID가 PDS에 연결되며, PDS는 사용자의 정준적인 데이터 피드입니다... PDS를 인스턴스라고 부르고 릴레이를 미러로 부르는 것이 무리한 주장은 아니라고 생각합니다."

ATProto Approach의 요약

ATProto의 핵심 목표는 사용자 데이터를 애플리케이션 외부로 유지하는 것입니다. 데이터를 호스팅하는 것과 소셜 경험을 집계하는 것을 분리함으로써, ATProto는 폐쇄형 플랫폼과 연합 인스턴스의 고유한 인재물(incentives)과 제한 사항을 문제를 해결하는 것을 목표로 합니다.