atproto에는 인스턴스가 없다

8 hours ago 2

“Bluesky 인스턴스”를 찾는 질문은 Mastodon의 인스턴스 모델을 atproto에 그대로 대입한 것으로, atproto는 호스팅과 앱 집계를 분리해 설계됨
RSS와 Google Reader처럼 데이터는 앱 안에 갇히지 않고 호스팅된 저장소에 있으며, 여러 앱이 그 데이터를 가져와 보여주는 방식으로 동작함
Mastodon 인스턴스는 호스팅·앱·정체성·연합 관계가 한 상자에 묶인 구조라, 관리자 결정이나 인스턴스 장애가 사용자 경험에 직접 영향을 줌
atproto에서는 사용자가 호스팅을 옮기거나 새 앱을 만들고 써볼 수 있으며, Tangled, Semble, Sidetrail 같은 앱은 Bluesky와 별개로 동작함
atproto의 분산성을 보려면 “Bluesky 인스턴스 수”보다 대체 호스팅 이동과 새 앱 생태계가 실제로 작동하는지를 봐야 함

RSS와 Google Reader에 가까운 모델

RSS 시대에는 사용자가 자기 블로그에 글을 올리고, Google Reader나 Feedly 같은 앱이 여러 블로그의 글을 집계했음
글은 Google Reader 안에 “사는” 것이 아니라 각자의 블로그나 호스팅 위치에 남아 있음
핵심은 호스팅과 집계의 분리임
- 호스팅은 실제 콘텐츠가 존재하는 곳임
- 집계 앱은 여러 출처의 콘텐츠를 보여주는 투영(projection)에 가까움

전통적 소셜 미디어는 모든 사용자를 하나의 앱과 공간 안에 모으는 방식으로 운영됨
이 구조에서는 중앙화와 강한 네트워크 효과가 생기며, 분산형 소셜 네트워크 논의는 이 문제를 어떻게 나눌지에서 출발함
Mastodon식 접근은 각 커뮤니티가 자기만의 “작은 Facebook” 또는 “작은 Twitter”를 운영하는 방식이고, 이 상자가 인스턴스임

사용자는 특정 인스턴스 “안에” 속하게 됨
- Mastodon 로그인 형식이 [email protected]인 이유도 정체성에 인스턴스가 포함되기 때문임
- 사용자는 추상적인 “Alice”가 아니라 “instance #1의 Alice”가 됨
서로 다른 인스턴스의 사용자가 소통하려면 인스턴스들이 메시지를 주고받아야 함
- Alice가 instance #1에 있고 Bree가 instance #2에 있을 때, Alice가 Bree를 팔로우하면 Bree의 글이 instance #1로 전달됨
- 이런 전달 관계가 연합(federation) 임
호스팅과 앱이 함께 묶여 있어 사용자는 인스턴스에 강하게 의존하게 됨

인스턴스 관리자 간 갈등이 생기면 서로 연합을 중단할 수 있음
- 이 경우 사용자는 친구의 글을 더 이상 보지 못할 수 있음
사용자의 인스턴스가 내려가면 해당 인스턴스에 묶인 정체성도 사라짐
- 팔로워가 따른 것은 “그 인스턴스의 사용자”이기 때문임
인스턴스 사이의 연결 화살표는 O(n²) 로 증가함
- 현재는 큰 문제가 아닐 수 있지만, 이 방식의 소셜 네트워크가 인기를 얻으면 중요해질 수 있음

사용자는 호스팅을 교체할 수 있음
- 글쓴이는 자신의 atproto 데이터를 Eurosky로 옮겼고, 몇 가지 UX 문제를 제외하면 자동으로 진행됐다고 밝힘
- 더 적극적이라면 Cloudflare에서 무료로 직접 호스팅할 수도 있음
새 앱을 시도하거나 직접 만들 수도 있음
- Tangled와 Semble은 Bluesky와 무관한 atproto 앱 사례임
- 글쓴이는 Sidetrail이라는 앱을 만들었고, 이 앱은 오픈소스임
- atproto에는 앱 제작을 위한 Statusphere 튜토리얼도 있음

Mastodon에서는 분산성을 인스턴스 수로 재는 방식이 자연스러움
- Mastodon에서 할 수 있는 주된 분산 방식이 호스팅과 앱이 결합된 상자를 더 많이 운영하고 서로 말하게 하는 것이기 때문임
atproto에서는 모든 앱이 전체 Atmosphere의 투영에 가까움
- Feedly와 Google Reader가 전체 Blogosphere를 보여주는 것과 같은 구조임
Bluesky 데이터베이스 서버 전체 복사본을 여러 개 운영하는 것은 가능하지만, Google Reader 복사본을 많이 운영하는 것만큼 일반적으로 유용하지 않음
일부 복사본은 특정 필요를 위해 존재함
- Blacksky는 다른 모더레이션 철학 같은 특정 요구를 위한 사례임
- reddwarf.app 클라이언트는 전용 데이터베이스 없이, 커뮤니티가 운영하는 무료 캐시인 constellation을 사용함
Relay 같은 공유 네트워크 인프라는 1년 동안 저렴하게 운영돼 왔다고 함

atproto의 분산성을 보려면 “Bluesky 인스턴스 수”가 아니라 다음을 봐야 함
- 사람들이 대체 호스팅으로 이동하고 있는가
- 사람들이 새 앱을 만들고 사용하고 있는가
호스팅과 앱을 분리하면 닫힌 소셜과 연합형 소셜 모두에서 깨진 인센티브를 고칠 수 있음
사용자의 데이터는 앱 밖에 두고, 앱은 그 데이터 위에서 집계하는 구조가 atproto의 핵심임