Bluesky 인스턴스는 어디 있나요? atproto에 인스턴스가 없는 이유
한 줄 요약
"Bluesky 인스턴스가 어디 있냐"는 질문은 사실 잘못된 질문입니다. Mastodon의 인스턴스 모델을 atproto에 그대로 끼워 맞춘 오해이기 때문이죠. atproto는 호스팅(데이터가 사는 곳)과 앱(데이터를 모아 보여주는 곳)을 아예 분리하도록 설계되어 있어서, 인스턴스라는 개념 자체가 존재하지 않습니다.
overreacted.io에 올라온 글을 바탕으로, 왜 이 차이가 중요한지 차근차근 풀어보겠습니다.
RSS와 Google Reader를 떠올려 보세요
가장 이해하기 쉬운 비유는 RSS 시대입니다.
- 글쓴이는 자기 블로그에 글을 올립니다.
- Google Reader나 Feedly 같은 앱은 여러 블로그의 글을 모아서(집계) 보여줍니다.
- 글은 Google Reader '안에' 사는 게 아니라, 각자의 블로그에 남아 있습니다.
여기서 핵심은 호스팅과 집계의 분리입니다.
- 호스팅: 콘텐츠가 실제로 존재하는 곳
- 집계 앱: 여러 출처의 콘텐츠를 모아 보여주는 '투영(projection)'
atproto는 바로 이 모델로 돌아갑니다. 그래서 "Google Reader 인스턴스는 어디 있냐"는 질문이 어색하듯, "Bluesky 인스턴스는 어디 있냐"는 질문도 어색해지는 것이죠.
Mastodon의 인스턴스는 모든 걸 한 상자에 묶습니다
반면 Mastodon의 인스턴스는 네 가지를 한꺼번에 묶어둡니다.
- 호스팅 (데이터 저장)
- 앱 (보여주는 화면)
- 정체성 (계정)
- 연합 관계 (다른 인스턴스와의 연결)
그래서 Mastodon 로그인 형식이 [email protected]인 데에는 이유가 있습니다. 정체성에 인스턴스가 포함되기 때문에, 사용자는 추상적인 'Alice'가 아니라 **'instance #1의 Alice'**가 됩니다.
서로 다른 인스턴스의 사용자가 소통하려면 인스턴스끼리 메시지를 주고받아야 하고, 이 전달 관계가 바로 **연합(federation)**입니다.
한 상자에 묶이면 생기는 제약
- 관리자끼리 갈등이 생기면 연합을 끊을 수 있고, 그러면 친구의 글이 더 이상 안 보일 수 있습니다.
- 인스턴스가 내려가면 거기 묶인 정체성도 함께 사라집니다. 팔로워가 따른 건 '그 인스턴스의 사용자'였으니까요.
- 인스턴스 간 연결은 **O(n²)**로 늘어납니다. 지금은 괜찮아도, 규모가 커지면 부담이 됩니다.
atproto의 핵심 차이
atproto는 이 묶음을 풀어버립니다.
- 데이터는 호스팅에 있고, 앱은 여러 사람의 호스팅에서 데이터를 집계합니다.
- 호스팅은 언제든 바꿀 수 있습니다.
- 그래서 '인스턴스'라는 묶음이 필요 없습니다.
이건 단순히 "앱을 여러 복사본으로 운영하는 것"보다 훨씬 풍부한 분산 구조입니다.
사용자가 직접 해볼 수 있는 분산화
- 호스팅 이전: 글쓴이는 자신의 atproto 데이터를 Eurosky로 옮겼고, 몇 가지 UX 문제를 빼면 거의 자동으로 진행됐다고 합니다. 적극적이라면 Cloudflare에서 무료로 직접 호스팅할 수도 있습니다.
- 새 앱 사용/제작: Tangled, Semble, Sidetrail 같은 앱은 Bluesky와 별개로 동작합니다. 직접 만들고 싶다면 Statusphere 튜토리얼도 마련되어 있습니다.
그래서 무엇을 봐야 할까
Mastodon에서는 분산성을 '인스턴스 수'로 재는 게 자연스럽습니다. 인스턴스를 더 많이 운영하고 서로 연결하는 게 거의 유일한 분산 방식이니까요.
하지만 atproto에서는 모든 앱이 전체 Atmosphere의 투영에 가깝습니다. Feedly가 전체 블로고스피어를 보여주는 것과 같죠. 그래서 분산성을 보려면 "Bluesky 인스턴스 수"가 아니라 이 두 가지를 봐야 합니다.
- 사람들이 대체 호스팅으로 이동하고 있는가?
- 사람들이 새 앱을 만들고 사용하고 있는가?
반론도 함께 읽어보면 좋습니다
Hacker News의 토론에서는 흥미로운 반론들이 나왔습니다.
- "비유가 깨져 있다": RSS는 Google Reader에 거의 의존하지 않았지만, atproto의 AppView는 **릴레이(Relay)**에 크게 의존한다는 지적입니다. 다만 릴레이 운영비는 sync 1.1 이후 월 20~30달러 수준으로 꽤 저렴해졌다는 반론이 따라붙었습니다.
- "디페더레이션 문제에 답하지 않는다": 인스턴스가 풀던 모더레이션 문제를 atproto는 어떻게 푸느냐는 질문입니다. 답은 "RSS 세계처럼"입니다. 호스팅 수준에서는 명백히 불법인 콘텐츠를 호스팅 업체가 차단하고, 앱 수준에서는 각 앱 운영자가 다른 웹서비스처럼 모더레이션을 붙입니다(Bluesky는 별도 모더레이션 서비스를 꽂는 방식).
- "ActivityPub을 깎아내리는 톤": 두 플랫폼이 비슷한 문제를 다른 방식으로 풀고 있는데, 불필요한 갈등 구도를 만든다는 아쉬움도 나왔습니다.
마무리
핵심은 단순합니다. 사용자의 데이터를 앱 밖에 두고, 앱은 그 데이터 위에서 집계한다. 이 구조 하나로 닫힌 소셜과 연합형 소셜 양쪽의 깨진 인센티브를 고치려는 것이 atproto의 설계 철학입니다. "인스턴스가 몇 개냐"가 아니라 "데이터 주권이 정말 사용자에게 있느냐"를 기준으로 본다면, atproto가 무엇을 하려는지 훨씬 또렷하게 보입니다.