Bluesky와 페디버스(fediverse)의 비교
(hackers.pub)핵심 아키텍처 차이: 메시지 전달 vs 공유 힙
-
페디버스: 이메일과 유사한 “메시지 전달” 방식 사용
- 특정 수신자에게 직접 메시지 전달
- 필요한 서버에만 메시지가 전송되어 효율적
- 개인이 저렴한 하드웨어로도 노드 운영 가능
-
Bluesky: “공유 힙” 방식 사용
- 모든 메시지가 중앙 “릴레이”에 저장됨
- 사용자는 릴레이에서 관련 정보를 필터링
- 대규모 중앙화된 인프라 필요
- 릴레이 운영 비용이 급격히 증가 (4개월만에 1TB→5TB)
전역 뷰와 중앙화 문제
-
Bluesky: 일관된 네트워크 전체 뷰 유지에 집중
- 모든 앱뷰가 전체 차단 정보 등 필요
- 차단 목록이 공개되어 프라이버시 문제 발생
- 중앙 집권적 통제 없이는 구현 어려움
-
페디버스: 각 서버가 독립적으로 정책 시행
- 사용자에게 더 많은 자율성 제공
- 차단 정보는 공개되지 않도록 설계됨
프로토콜 개방성 비교
-
페디버스/ActivityPub: W3C 채택 개방형 표준
- 누구나 자유롭게 구현 가능
- 다양한 소프트웨어 간 상호운용성 보장
- FEP를 통한 커뮤니티 주도 발전
-
Bluesky/AT Protocol: 기업 주도 프로토콜
- 아직 개방형 표준으로서의 지위 미확립
- 확장성과 지속가능성 제한적
개인 메시지(DM)의 중앙화
-
Bluesky: 모든 DM은 중앙 서버 통과
- 사용자 PDS나 릴레이와 무관하게 Bluesky 회사를 통해 전송
- Bluesky 회사가 모든 DM에 접근 가능
- "신뢰할 수 있는 이탈" 개념과 모순됨
-
페디버스: 서버 간 직접 전달 메커니즘
- 자신의 서버 관리자만 메시지 접근 가능
이동 가능한 아이덴티티 구현 문제
-
Bluesky: DID를 사용하지만 여전히 중앙화에 의존
-
did:web과did:plc는 DNS와 중앙 레지스트리에 의존 - 초기에는 모든 계정이 동일한 rotationKeys 사용
- 사용자 키가 Bluesky에 의해 관리됨
-
-
페디버스: 노마딕 아이덴티티 개념 발전 중
- Zot 프로토콜 등 더 포괄적인 이동성 제공
- FEP-ef61 등을 통한 지속적 개선
상업적 압력과 지속가능성
-
Bluesky: 벤처 캐피털 자금에 의존
- “조직은 미래의 적이다”라는 인식
- 유료 계정과 광고 도입으로 인한 상업적 압력
- 투자자 수익 압박이 탈중앙화를 저해할 가능성
-
페디버스: 다양한 운영 주체와 자금 모델
- 상업적, 비상업적, 개인적 노드의 생태계 구성
- 단일 실패 지점 없음
결론
- Bluesky는 사용자 친화적 인터페이스와 Twitter 유사 경험으로 X의 훌륭한 대안이 될 수 있음
- 그러나 중앙화된 설계, 운영 비용, 개인정보 취약성, 기업 의존성 등으로 인해 페디버스의 대안은 아님
- 두 시스템은 근본적으로 다른 목표와 디자인 철학을 가지고 있으며, 이상적으로는 서로 보완하는 방향으로 발전할 수 있음