ATProto vs 마스토돈: '인스턴스' 개념의 근본적 차이

글에서는 ATProto가 마스토돈의 '인스턴스' 개념을 따르지 않는다고 주장하며, 이는 데이터 호스팅(Data Hosting)과 앱 집계(App Aggregation)를 분리한 설계 덕분이라고 설명합니다. 하지만 댓글에서는 이 주장이 ATProto를 위한 의도적인 왜곡이며, 개인 데이터 서버(Personal Data Server, PDS)와 릴레이(Relay)의 존재가 사실상 인스턴스와 유사하다는 비판이 제기됩니다. 특히 PDS가 고유 데이터의 원천(Canonical Data Source)으로 간주된다는 점에서 클라이언트-서버 아키텍처와 유사하다는 지적이 있습니다.

마스토돈의 '인스턴스' 중심 연합 모델은 각 인스턴스가 독립적인 커뮤니티 역할을 하지만, 계정 종속성(Account Dependency), 인스턴스 간 분쟁 시 통신 단절(Defederation), O(n²) 확장성 문제(Scalability Issues) 등의 단점을 가진다고 지적됩니다. 사용자는 특정 인스턴스에 귀속되며, 데이터와 정체성이 해당 인스턴스에 좌우된다는 점이 비판의 핵심입니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 강조하는 ATProto와 대조됩니다.

ATProto는 데이터 호스팅(PDS)과 앱(AppViews), 릴레이(Relays)를 분리하여 설계되었습니다. 릴레이는 여러 PDS의 데이터를 집계하여 앱에 제공하는 역할을 하며, 이는 마스토돈의 연합 방식과 다르다고 설명됩니다. 그러나 일부 댓글에서는 릴레이가 사실상 중앙 집중화된 구성 요소(Centralized Component)로 작용하며, 특히 Bluesky의 검열/모더레이션 결정(Censorship/Moderation Decisions)을 반영한다는 점에서 진정한 탈중앙화인지 의문을 제기합니다. 릴레이 운영 비용 문제도 언급됩니다.

글에서는 ATProto를 RSS와 구글 리더에 비유하며 호스팅과 집계의 분리를 강조하지만, 댓글에서는 이 비유가 부적절하다는 의견이 많습니다. RSS는 구글 리더에 종속되지 않았던 반면, ATProto의 앱(AppViews)은 릴레이에 대한 높은 의존성(High Dependency on Relays)을 가지며, 릴레이 운영 비용이 상당하다는 지적입니다. 또한 구글 리더의 실패 사례를 들며 ATProto의 미래에 대한 우려를 표하는 시각도 있습니다.

ATProto는 사용자가 자신의 데이터를 직접 호스팅(PDS)하고 통제할 수 있다는 점에서 데이터 소유권(Data Ownership)을 강조합니다. 반면 마스토돈은 인스턴스 운영 주체와 함께 네트워크의 일부를 공동 소유(Collectively Owning)하는 형태에 가깝다는 분석입니다. INTPenis는 ATProto가 '데이터 소유'에 집중하는 반면 마스토돈은 '접근성 높은 탈중앙화'를 추구한다고 요약하며, ATProto의 탈중앙화는 주로 개인 데이터 관리에 국한된다고 평가합니다.

timbray는 ATProto의 기술적 측면보다 재정적 지속 가능성(Financial Sustainability)을 더 큰 우려 사항으로 지적합니다. ATProto는 벤처 캐피털(VC)의 투자를 받은 Bluesky PBC에 크게 의존하고 있으며, 명확한 비즈니스 모델이 부재하다는 점을 비판합니다. 이는 마스토돈이 VC 없이 Patreon, 비영리 단체 등을 통해 운영되는 것과 대조되며, 장기적인 탈중앙화된 생태계 유지(Decentralized Ecosystem Maintenance)에 대한 의문을 제기합니다.