atproto에는 인스턴스가 없다

“Bluesky 인스턴스가 어디 있냐”는 질문을 일부러 오해해서 ATProto를 띄우고 ActivityPub을 깎아내리는 식으로 보임
이렇게 하면 ATProto의 릴레이와 장단점, ActivityPub의 계정 이전과 장단점 같은 흥미로운 기술적 사실을 빼거나 비틀게 되고, 비슷한 문제를 푸는 두 플랫폼 사이에 불필요한 갈등을 만듦
“인스턴스”를 서버, 실행 중인 소프트웨어, 가상 머신, 컨테이너 같은 일반적인 의미로 쓰는 사람도 있을 텐데, 왜 굳이 Mastodon식 개념으로만 받아들이는지 모르겠음
다이어그램과 설명은 좋았지만, ActivityPub을 향한 은근한 찌르기는 정보 전달보다 적대감에서 나온 느낌이라 아쉬움

글의 톤은 일부러 약간 장난스럽게 썼지만, “Bluesky 인스턴스는 어디 있냐”는 질문이 앱 인스턴스 수를 탈중앙화의 척도로 보는 아키텍처 오해에서 자주 나온다고 봄
“Google Reader 인스턴스는 어디 있냐”와 비교하면 그 질문의 어색함이 잘 드러난다고 생각했고, 글 말미의 두 그림이 초기 atproto/ActivityPub 논의에서 자주 놓치던 부분을 꽤 잘 풀어준다고 봄
릴레이를 넣지 않은 이유는 여기에서 썼음: https://news.ycombinator.com/item?id=48600963
릴레이는 모델의 핵심이라기보다 성능 최적화에 가까워서, 글에서는 모델 자체에 집중하고 싶었음

맥락에 따라 다르지만 ATProto, ActivityPub, Mastodon 주변 논의에서는 “인스턴스”가 보통 사용자 데이터와 프로필 URL을 호스팅하는 ActivityPub 노드를 뜻하는 경우가 많고, 글도 그 맥락을 겨냥한 것 같음
단어에 특정 개념과 구조가 붙기 시작하니, “탈중앙 소셜미디어”를 보면 많은 사람이 ActivityPub식 연합 구조를 떠올리고, ATProto를 보며 “왜 사람들이 가입하는 Bluesky 인스턴스가 하나뿐이지?”라고 묻게 됨
완전히 새로운 관점은 아니어도, 이런 기존 연상이 머릿속에 굳어진 사람들에게 나중에 다시 링크할 만한 유용한 글로 보임

ATProto 대 ActivityPub은 Fediverse의 동서 교회 대분열처럼 보일지도 모르겠음
“filioque” 칙령 대신 “연합”의 정의를 두고 양쪽이 서로 다른 얘기를 하는 블로그 글이 오가는 셈임

Mastodon과 ATProto의 구분과 비교는 필요하다고 봄
Fediverse 모델은 기존 소셜 네트워크 관점에서 이해하기 쉽지만, ATProto는 사용자에게 데이터 주권을 주면서도 중앙화 소셜 네트워크의 확장성을 얻으려는 새로운 개념임

여기의 비유는 깨져 있다고 봄 RSS는 Google Reader에 전혀 의존하지 않았고, 전성기에도 지금 이메일이 Gmail에 의존하는 것보다 덜 의존했음
ATProto에서는 AppView가 유용해지려면 릴레이에 크게 의존하고, 릴레이 운영 비용도 꽤 큼
또 RSS 그림의 노란 원이 블로그를 뜻하는 것과 Facebook 게시물을 뜻하는 원은 성격이 다름. 블로그는 그 자체로 독립적임
ATProto가 나쁘다는 뜻은 아니지만, 이 글은 명확하게 하기보다 혼란을 더하는 느낌임

릴레이는 이제 실제로 꽤 저렴해졌음
예전에는 모든 트래픽을 보관해서 조금 더 비쌌지만, sync 1.1에서 그 부분이 빠졌고 지금은 월 20달러짜리 가상 머신에서도 꽤 쉽게 돌릴 수 있음

내가 보기엔 릴레이가 ATProto를 성능 좋게 작동시키는 접착제임
콘텐츠에는 무관하게 데이터를 운반하고, 각 AppView가 알아야 하는 서비스 수를 줄이는 역할로 보임
글에서도 말하듯 Mastodon 대비 큰 개선점은 릴레이, AppView, PDS가 서로 다른 확장 요구를 가진 별도 서비스라는 점이고, 시스템 설계 문제에 대한 꽤 아름다운 해법임
[1] https://atproto.com/guides/glossary

맞음, 릴레이는 그걸 하는 한 방법임
다만 보이지 않는 최적화이고 다른 전략도 있어서 글에서는 대부분 생략했음
예를 들어 오늘날 많은 작은 앱은 자체 데이터베이스 색인을 만들지 않고 Constellation(https://constellation.microcosm.blue/)에 의존하므로 릴레이를 전혀 쓰지 않음

두 방식의 차이를 설명한 점은 좋았음
다만 “인스턴스가 해결하는 문제를 ATProto는 어떻게 해결하느냐”는 질문에는 답하지 않아서 답답했음
예를 들어 글이 디페더레이션을 친구 글이 안 보일 수 있는 알 수 없는 이유 정도로 치부하면, “그럼 atproto는 디페더레이션이 해결하는 문제를 어떻게 해결하느냐”에 답하지 못함
이 프레이밍에서 자연스럽게 나오는 기본 답은 “해결하지 않는다”임

모더레이션을 묻는 거라면, 모든 것이 RSS인 세계에서 기대할 법한 방식과 비슷하게 작동함
호스팅 수준에서는 blogspot.com이나 Cloudflare가 특정 사안에서 차단하듯, 명백히 불법인 것 때문에 호스팅 업체가 계정을 막을 수 있음
애플리케이션 수준에서는 앱 관리자와 모더레이터가 사용자 생성 콘텐츠를 다루는 다른 웹서비스처럼 조정함
앱 개발자가 선택할 문제이고, Reddit처럼 사용자 영역 모더레이션 기본 요소를 제공하거나 Bluesky처럼 별도의 모더레이션 서비스를 꽂을 수도 있음
서로 싸울 수 있는 “커뮤니티 인스턴스”에 해당하는 것이 없기 때문에 디페더레이션도 없음. 호스팅, 앱, 앱 개발자의 선택에 따른 앱 수준 모더레이션이 있을 뿐임

더 나은 질문은 “ActivityPub은 디페더레이션이 만드는 문제를 어떻게 해결하느냐”라고 봄
이는 Microsoft가 이메일에서 하는 일과 본질적으로 비슷함. 가장 큰 제공자들 말고는 메시지를 버리고, 기본적으로 디페더레이션해서 사용자가 메시지를 전달하려면 Microsoft나 다른 대형 기존 사업자를 쓰게 만듦
그러면 새 인스턴스는 메시지를 전달하지 못하고 사용자를 얻지 못함. 대형 기존 사업자에게 새 인스턴스와 연합하지 않을 왜곡된 유인이 생김
이런 아키텍처 선택은 장기적으로 과점을 굳히는 효과가 있음
스팸 방지에 필요하다고 하지만, DKIM과 역방향 DNS 등을 제대로 설정하면 Gmail에는 보통 전달 가능한 것처럼 그렇게 하지 않는 제공자도 있고, 그들이 스팸 문제를 더 많이 겪는 것도 아님
명백한 대안은 클라이언트에서 필터링하는 것임. Microsoft 같은 운영자가 아니라 uBlock 같은 성격의 필터 목록 제공자가 필터를 공급하면, 특정 인스턴스를 운영하지 않기 때문에 모두를 자기 인스턴스로 몰아갈 유인이 없음

그런 문제를 해결하지 못함
전체 firehose를 소비할 수 있는 AppView가 아주 많고, 그 사이를 자유롭게 고를 수 있으며, 직접 저렴하게 운영할 수 있는 대체 우주라면 모를까
ATProto는 데스크톱이나 모바일 RSS 리더 없이 Google Reader 또는 같은 규모의 복제 서비스로만 RSS를 읽을 수 있는 세계의 RSS에 가까움

오리처럼 꽥꽥거리면 오리임
계정에는 단일 PDS가 있고, DID는 사용자의 정식 데이터 피드이자 쓰기 대상인 PDS를 가리킴
데이터는 복제될 수 있지만 PDS가 정본으로 취급됨
이는 분산 아키텍처보다 클라이언트/서버 아키텍처에 훨씬 가까움
P2P 데이터베이스도 없고, DHT나 피어에 쓰는 것도 아님. PDS에 쓰고, 그 쓰기가 선택적으로 미러링됨
발견도 DNS로 이뤄지니 피어에게 데이터를 묻지도 않음
릴레이에는 피어가 아니라, PDS에 정본으로 호스팅된 데이터 사본을 요청하는 클라이언트로 연결함
PDS를 인스턴스, 릴레이를 미러라고 부르는 것이 무리라고 생각하지 않음

그렇게 표현해도 괜찮음
다만 Mastodon을 말하는 사람들이 “인스턴스”라고 할 때 보통 뜻하는 것과는 다름
Mastodon에서 인스턴스는 데이터 호스팅, 앱, 커뮤니티, 모더레이션이 결합된 분리 불가능한 묶음임

ATproto는 일관성을 위해 진짜 탈중앙화를 희생하고, Mastodon과 ActivityPub은 더 접근 가능한 탈중앙화를 위해 진짜 일관성을 희생한다고 이해함
ActivityPub 노드를 운영하는 편이 일반 자가 호스팅 사용자에게 AT의 콘텐츠 릴레이 운영보다 훨씬 접근 가능하기 때문임
AT에서 “탈중앙화”할 수 있는 것은 결국 자기 데이터뿐이고, 네트워크의 일부를 공동으로 소유한다기보다 자기 데이터 소유에 더 가까움
HN에서 이미 여러 번 반복된 얘기이기도 함

흥미로운 관점이지만, 내 현재 이해로는 AtProto가 더 접근 가능하고 더 탈중앙화된 것처럼 느껴짐
ActivityPub에서는 인스턴스 운영이 데이터, 애플리케이션, 이후의 확장 문제까지 모두 맡는 것이어서, 운영 책임을 직접 지거나 남의 인스턴스에 묶이는 것 중 하나를 골라야 함
고른 인스턴스가 마음에 들지 않아 옮기려 해도, 아직 바뀌지 않았다면 거의 새로 시작해야 하는 상태임
AtProto에서는 같은 정체성을 유지한 채 다른 애플리케이션 플랫폼으로 옮기기가 쉽고, 플랫폼에서 데이터를 내보내 자가 호스팅하는 것도 사용자 경험은 어렵지만 최소한 가능함
예를 들어 최근 Tangled를 처음 써봤는데 기존 bsky 기반 도메인(h14h.com)으로 로그인할 수 있었음. 새 계정이나 새 사용자명을 만들 필요 없이 이미 거기 있던 것 같았음
VPS에서 git 저장소를 자가 호스팅하는 설정도 길어야 오후 한나절 일이었고, 거의 신경 쓸 필요 없는 백엔드 서비스로 돌아감
최악의 경우 tangled.org에 “저장소가 오래되어 최신 Tangled와 호환되지 않을 수 있다” 같은 배너가 뜨고, 최신 버전으로 Docker 이미지를 다시 빌드해 배포하면 해결됨
아키텍처로는 AtProto가 확실히 머리에 넣기 더 어렵지만, 실제 사용자와 접하게 만드는 것은 훨씬 단순하다고 봄

“진짜” 탈중앙화라는 게 있는지 잘 모르겠음
내 머릿속에서는 하나의 슬라이더라기보다 트레이드오프의 뷔페에 가까움
참고로 AP 세계에서도 개인과 작은 팀들이 릴레이, 미러, 캐시, AppView 등을 운영하고 있음. 다만 규모가 커질수록 더 비싸질 수 있다는 점은 맞음

그 말도 일부지만 전체를 다 설명하진 못함
AT는 일관성뿐 아니라 앱 전반의 공유 데이터 모델도 제공함
그래서 앱들이 다른 앱의 콘텐츠를 참조하고 렌더링할 수 있음. 타입 있는 JSON의 웹 같은 형태이고, 서로 다른 앱은 같은 네트워크를 보는 렌즈임
누구나 기존 데이터 위에 새로운 경험을 만들 수 있고, AP에는 이에 해당하는 것이 거의 없음
AP는 데이터를 앱에 결합하지만, AT에서는 전 세계 데이터가 들어 있는 하나의 전역 데이터베이스를 모든 앱이 질의하는 것에 더 가까움
왜 논의가 항상 릴레이에서 막히는지 모르겠음. 요즘은 원하면 릴레이를 대략 월 30달러로 돌릴 수 있고, Bluesky나 커뮤니티 릴레이를 무료로 쓸 수도 있음
많은 앱은 릴레이를 전혀 쓰지 않고 Constellation(https://constellation.microcosm.blue/) 같은 커뮤니티 색인에 의존함. 자체 서버나 데이터베이스조차 안 돌리는 앱도 있음

Mastodon에도 콘텐츠 릴레이가 있음
하지만 오히려 반대로, ATproto가 더 탈중앙화되어 있거나 적어도 그렇게 되려 한다고 주장하고 싶음
ActivityPub 세계에서는 정체성, 애플리케이션, 호스팅이 본질적으로 연결돼 있음
Lemmy를 쓰려면 그 Lemmy 인스턴스에 두 번째 영구 분리 ActivityPub 계정을 만들거나, 내 Mastodon 인스턴스가 Lemmy가 이해하는 메시지를 보낼 줄 아는 범위에서만 Lemmy를 써야 함
모든 새 ActivityPub 앱은 새 상호운용성 문제를 만든다. 각 앱이 자기 정체성과 호스팅을 소유하기 때문임
내가 자가 호스팅한 Mastodon 인스턴스가 Lemmy 서버에 정체성을 제공하고, 그 Lemmy 서버가 내 인스턴스에 내 대신 콘텐츠를 호스팅하라고 시킬 방법이 없음
ATProto가 말하는 수준에 맞추려면 최소한 그 정도는 필요함. 다만 실제 존재하는 ATProto에 얼마나 해당하는지는 모르겠고, 실제 존재하는 ActivityPub도 지지자들이 말하는 만큼 상호운용되지는 않음

이 블로그는 아키텍처를 잘 설명함
하지만 실제로는 Bluesky 회사가 주 앱을 운영하고 사용자 데이터 대부분을 호스팅한다는 것이 “문제”라고 생각했음
프로토콜 수준에서는 탈중앙화되어 있지만, 실제 시스템은 통제 주체 관점에서 여전히 매우 중앙화되어 있음
꼭 Bluesky의 잘못이라는 뜻은 아니지만, 지금까지는 그렇게 흘러온 것 아닌가 싶음

“문제”는 사람들이 문제를 찾고 있다는 데 있음
이 문제는 Bluesky나 ATProto에 특유한 게 아니고, 영리 조직이든 비영리든 자원봉사자 그룹이든 누군가는 항상 문제 삼을 대상을 찾아냄
투자자도 아니고 초기 사용자였다는 것 외에 Bluesky와 이해상충도 없음. 내 한계 안에서 프로토콜, 회사, 웹사이트도 이해하고 있음
사이트와 앱은 잘 작동함. 사람들은 더 크고 나은 해법을 만들기보다 문제 찾기에 너무 집중함
대다수는 Lemmy나 Mastodon 같은 임시적인 P2P 해법을 원하지 않음. 콘텐츠가 한곳에 있기를 원하고, 그 주체에게 책임을 물을 수 있기를 원함
그래서 P2P 소셜 네트워크는 결코 대중화되지 않을 거라고 봄. Lemmy와 Mastodon 주변의 드라마가 Twitter, Reddit, Facebook 등을 합친 것보다 더 많았음
내 2센트이고, 배우자와 친구들도 같은 생각인 듯함

다른 앱, 다른 사용자 데이터 호스팅, 개인 호스팅, 다른 백엔드 서비스가 있음
이론과 실제 모두에서 탈중앙화되어 있음
다만 Bluesky가 가장 큰 부분을 운영하므로 커뮤니티나 마인드셰어 수준에서는 탈중앙화되지 않았다고 말할 수는 있지만, 그 점도 바뀌고 있음

정말 잘 설명한 걸까?
“인스턴스가 없다”고 말할 뿐, 그 아키텍처가 인증, 동기화, 발견 같은 문제를 어떻게 우회하는지는 설명하지 않음

Google Reader를 비유로 고른 건 불길하게 느껴짐
RSS는 Google Reader 종료 후에도 살아남았지만, RSS를 쓰던 모든 커뮤니티가 살아남은 건 아니고, 그중 다수는 지금도 RSS가 뭔지 모름
탈중앙화된 것이라고 주장하면서, 탈중앙 생태계의 거대한 사회적 중앙화를 좋은 사례처럼 계속 가리키는 건 거의 프로이트식처럼 느껴짐
특히 우리는 그 결말을 이미 알고 있음
Google Reader는 많은 RSS 집을 하나로 묶고, 소셜 그래프와 댓글 같은 가치를 더했지만, Google 임원들의 변덕으로 무너지며 RSS를 거의 죽이고 인상적인 소셜 그래프를 파괴했음
그런 비유라면 ATProto에 큰 신뢰가 생기지 않음

atproto의 핵심은 소셜 그래프도 “블로그/RSS” 쪽에 산다는 것임
앱은 그걸 색인할 뿐임
그래서 이 비유에서는 누구든 같은 그래프를 사용해 Google Reader를 되살리거나 경쟁할 수 있음
궁금하다면 지금 http://leaflet.pub가 실제로 그런 식으로 작동함

불길하지만 정확함
데스크톱이나 모바일 RSS 리더를 못 쓰고, Google Reader나 비슷한 규모의 복제 서비스로만 RSS를 읽을 수 있다고 상상하면 됨

그 대신 지금은 훌륭한 RSS 리더가 많음
최근에도 누군가 NetNewsWire를 이야기했음

중요한 차이는 블로그에는 자기 웹사이트가 있고, RSS 피드에 전체 글을 반드시 실을 필요가 없다는 것임
Bluesky는 보통 그렇게 작동하지 않음. PDS에 있는 모든 것이 복제됨
또 쉬운 복제를 위해 전체 블로그 글을 PDS에 넣도록 장려하고 있음
그러면 색인하려는 누구나 사본을 가져가고, 그들이 뭘 하든 통제할 수 없음
꼭 그렇게 해야 하는 건 아님. 자기 웹사이트에 블로그를 올리고 Bluesky에는 링크만 올릴 수도 있음

그게 블로그를 직접 긁어가는 스크래퍼와 어떻게 다른가?

솔직히 그건 atproto가 원시 데이터 프로토콜이기 때문이기도 함
atproto 계정 위에 HTTP 프런트엔드를 얹는 건 권장하는 방식이고, 실제로 많이들 그렇게 함
나도 pfrazee.com에서 그렇게 하고 있고, 정본은 atproto에 있는 내 leaflet 블로그 글도 내 블로그에서 렌더링됨

RSS 비교는 오해를 부름
Atproto 앱은 사용자 컴퓨터에서 실행되며 콘텐츠 출처에 직접 연결하는 RSS 리더와 다름
Atproto 앱은 독자에게 제공할 콘텐츠를 통제하고, 필터링하고, 형태를 만드는 서버임
Atproto 앱은 검열, 섀도밴, 광고 노출, 알고리즘 피드화를 원하는 대로 할 수 있음
사용자는 무력하고, 창작자는 울부짖는 것 말고 할 수 없는 피해자가 됨
누구나 데이터를 어디에든 호스팅할 수 있다는 사실은, 그 데이터를 배포할 방법이 없다면 완전히 무의미함

그건 사실이 아님
우선 그런 일을 하지 않는 다른 AppView를 쓸 수 있음
피드는 사용자가 원하는 방식으로 알고리즘화될 수 있고, 여러 앱이 있으면 한 중앙 제작자가 원하는 알고리즘에 묶이지 않음