AT Protocol이 Bluesky의 시스템이라 처음엔 ActivityPub의 기업 버전 같다고 생각했지만, 이번 글을 읽고 보니 데이터가 내가 선택한 '저장소(repository)'에 저장되는 방식이 꽤 마음에 듦. 내 일반적인 원칙과도 일치하는데, 읽기 쪽에서 필터링 등을 실행하는 게 글을 쓸 때보다 더 낫다고 믿음. 그래서 내가 원하는 모든 것을 내 저장소에 올리고, 다른 사람들이 그걸 읽고 이용할 수 있는 구조가 좋은 것임. 화살표가 댓글이 내 저장소에 들어가는 것처럼 보이긴 하지만, 아이디어를 표현하다 나타난 약간의 부정확성 같음. 전반적으로 매우 멋지고 분산화되어 있는 구조라고 느낌. 하지만 실제로 AT에서 별도의 PDS를 직접 운영해 보려 했더니, 꽤 매끄럽고 잘 포장되어 있지만 몇 가지 전제 조건이 있음을 알게 됨:
내가 화살표를 두 가지로 써서 혼란을 준 것 같음. 실선 화살표(@alice.com에서 내려가는)는 소유권을 나타냄. 색깔별 그룹핑과 동일함. 파란색은 전부 Alice 것이란 뜻임. 점선 화살표는 레코드 사이의 링크임. 이는 <a href>와 동일하게, 어떤 레코드든 어떤 저장소에 있더라도 자유롭게 연결 가능함. 누군가 내 포스트에 댓글을 달면, 그 댓글은 댓글 단 사람의 저장소에 들어가고, 원글과 연결고리가 생김. 데이터 모델을 이렇게 설계한 이유는, 인덱싱하는 사람이 두 레코드를 모두 갖고 있으면 관계를 쉽게 복원할 수 있도록 하기 위함임. 예시로 Bob이 Alice의 글에 댓글을 달면, Bob의 댓글은 Bob 저장소에, Alice 글은 Alice 저장소에 있음. 내 포스트에 누군가 댓글을 쓰면, 그 댓글은 항상 그 사람 저장소에 남음. 타인의 저장소에 레코드를 생성할 수 없다는 것이 핵심 전제임.
기본 PDS 패키징이 SSL 처리를 자동으로 지원하지만, 필수는 아니고 개발자가 쉽게 적용할 수 있도록 만들어 둔 것임. at:// URI는 at://DID/... 형태이고, 사람이 읽을 수 있는 핸들은 DNS TXT 레코드(_atproto.roshangeorge.dev)를 통해 DID에 매핑됨. DID는 서버 위치를 명시하는 문서로 연결되어 있어서, HTTPS/WSS 라우트도 어디든 둘 수 있음. 또한 내 포스트의 좋아요, 답글 등은 그 행동을 한 사람의 저장소에 들어가고 내 저장소엔 들어오지 않음. 이 부분의 직감이 맞았음.
ActivityPub이 더 나은 프로토콜이고 AT는 그저 저렴한 모작이라 생각했지만, 이 글을 보고 AT가 훨씬 낫다는 사실을 깨달음. 핵심은 여러 프로그램이 동일한 아이덴티티를 공유할 수 있는 점임. 이게 진짜 대단한 기능이고 정말 시야가 확장되는 경험이었음.
ATProto 관련 설명은 대부분 데이터 소유권에 초점을 맞추지만, 실제로는 데이터 처리 부분에서 ActivityPub이 더 강력함. ATProto는 전 세계를 공개적으로 바라보는 구조라, 모든 이벤트가 신뢰받는 글로벌 AppServer에서 보이고 직접 판단해야 하므로 피드 생성, 접근 권한 등을 모두 신뢰 중개자에게 의존해야 함. ActivityPub은 오히려 RSS나 이메일과 비슷하게, 내가 구독한 피드만 내 서버가 관리하고, 인박스는 내가 접근 가능한 포스트로 바로 구성됨. Bluesky에서는 트위터처럼 "비공개 좋아요"가 불가능한 이유도 이 때문임. AppView마다 네트워크 내 모든 포스트의 좋아요 수를 직접 추적해야 해서 엄청 번거로움. 장기적으론 ActivityPub 구조가 더 유리할 거라고 생각함. 그리고 “여러 프로그램이 동일 아이덴티티를 공유”하는 부분은 사실 초창기 ActivityPub 설계에도 있던 것임. 가장 대중적인 초기 구현체들이 기존 구조에 맞추기 위해서 그 기능을 뺀 것뿐임.
어떤 분산 프로토콜이 승리하든 상관없지만, ATProtocol이 이론적으로는 좋아 보여도 실전에서는 점점 ActivityPub 쪽이 더 매력적으로 느껴짐. 나는 Lemmy에서 자주 활동하는데, 상당히 활발하고 재미있음.
AT 사용자의 99.99%가 Bluesky에 몰려 있음. 이건 기업이 이끄는 서비스임. 그들이 프로토콜을 통제하지 않는다고 주장해도, 사실상 프로토콜의 지배적 인스턴스이기 때문에 자기들 입맛대로 바꿀 위험이 있음. 심지어 5년 후 이사가 불가능하다 결심할 수도 있다는 걱정도 있음. 이런 일이 이미 여러 소셜미디어에서 반복적으로 발생했음.
이용자들은 프로토콜 따위엔 관심 없고 관성, 사용자 기반이 훨씬 중요함. AP를 쓰는 여러 Reddit 대체 서비스에서도 유저 유입이 그렇게 어렵고, 다시 전환을 설득하기도 힘듦. 결국 이러한 시도들이 이미 작은 커뮤니티를 더 분열시키고, 결국 모두 메이저 플랫폼으로 포기하고 돌아가는 결과만 만들까 봐 두려움.
계정 이동이 쉽다는 점은 멋진 기능이긴 한데, 이미 설정 백업/복구 기능과 새 인스턴스 계정 만들기 과정이 충분히 간단함. 딱히 큰 변화점은 아님.
참고 사이트: https://arewedecentralizedyet.online/Lemmy, programming.dev, Piefed 등도 요즘 괜찮게 평가함
Mastodon과는 다르게 AT에서는 인스턴스 개념 자체가 다름. Bluesky 인프라 내에도 여러 PDS가 있고 구조적으로 계층적으로 다르게 동작함(관련 기사 참고). 단일한 지배적 인스턴스라고 표현하는 건 맞지 않음. 물론 기업이 프로토콜을 자기 입맛대로 좌지우지할 우려는 현실적인 고민임. 하지만 지금까지는 좋은 관리자 역할을 했다고 평가됨. 생태계가 성장하면서 점차 해결될 부분이라고 생각함. 그리고 Bluesky가 서비스 문을 닫고 이사가 불가능해질 우려도 있는데, Protocol 자체에 백업과 이사가 내장되어 있음. CAR 파일만 있으면 언제든 다른 호스트로 이전 가능함. Mastodon은 계정 이동 시 손실이 많지만, atproto는 100% 투명하게 이전 가능함.
결국 Bluesky든 Mastodon이든 들어가보면 미국 정치 얘기밖에 없음. 주간 정치 드라마를 별로 좋아하지 않아서 Tumblr나 Pinterest, 혹은 TikTok 같은 더 다양한 플랫폼이 나에게 맞는 듯함.
Mastodon이 ActivityPub과 완전히 동일하진 않지만, 답글이 갑자기 사라지는 점 때문에 신뢰가 안 감. 어떤 글은 남았다가 또 사라지고, 이 부분이 Mastodon을 떠난 두 가지 이유 중 하나였음.
앱마다 자체적인 컬렉션 타입을 쓰고, 그들끼리 컬렉션을 공유할 수 있어도, 결국 앱들이 서로 호환될지는 명확하지 않다는 점이 약간 아쉬움. ActivityPub의 아름다운 점 중 하나는 Mastodon 사용자가 Pixelfed 사용자를 특별히 신경쓸 것 없이 구독할 수 있다는 점임. 마치 트위터, 인스타그램, 레딧, 유튜브, Substack이 별다른 설정 없이 자동으로 다 연결되는 느낌임.
AP가 기본적으로 상태(Status)와 질문(Question) 타입에서는 여러 서비스가 잘 연동됨. Mastodon, Pixelfed, Misskey, Pleroma 등이 모두 이 체계를 중심으로 돌아감. 하지만 그 외 타입 지원은 매우 제한적이라, 다른 유형의 콘텐츠는 제대로 지원되지 않음. 표준 외확장에 대한 커뮤니티 조직이 부족한 것이 문제임. ATproto는 데이터 컬렉션의 lexicon/schema 정의를 반드시 따라야 하고, 레퍼런스와 서드파티 구현체들이 스키마 유효성 검사를 제공함. 그래서 기본적인 호환성이 더 명확하게 구조화되어 있지만, 오히려 일부 추가 필드 등에 선택적 지원도 가능하게 해서 좀 더 유연해질 필요가 있다고 생각함. Bridgy Fed처럼 APub에서 온 데이터를 원문 URL, 텍스트 등 메타데이터로 붙이는 예도 있음. (https://fed.brid.gy/docs#bluesky-fields 참고)
"차세대 트위터"를 외치는 프로젝트들이 문제 해결 방식이 조금씩 어긋난다고 느끼기 시작함. 트위터 기능 완벽 재현 후엔 유저, 콘텐츠 부족(치킨 앤 에그) 문제에서 막힐 뿐임. 결국 사람들은 사람이 많은 곳에 모이고, 그게 아직도 트위터임.
오히려 최근 오픈AI가 론칭한 타임라인처럼, 백그라운드에서 데이터를 우선 모은 뒤 사용자에게 전달하는 방향이 더 나아 보임. 구체적인 구현은 다를 수 있지만, 방향성은 옳다고 느낌.
대부분의 이용자가 트윗 작성 기능에 큰 가치를 두지 않고, 진짜 가치는 데이터 소비(콘텐츠 소싱)임. 이런 관점에서 다중 소셜 RSS 리더기 + P2P 옵션이 더 좋은 방향이라 생각함. 개인적 의견임.
기사에 설명된 것처럼, 초기 프레이밍엔 마이크로블로깅을 사용하지만 실제로는 트위터 류 뿐 아니라 다양한 형태가 가능함. 예시로 Tangled는 "Github on atproto", Leaflet은 "Medium on atproto" 구성임.
클라이언트 측 P2P 방식의 한계는 대규모 집계(aggregation)와 일관성을 보장하기 어렵다는 것이고, 대부분의 일반 사용자가 기대하는 소셜앱의 기본임.
오픈AI 예시도 atproto가 강점을 보이는 부분임. 네트워크에 이미 데이터가 존재하므로 크롤링, 인덱싱, 자동화 도구를 쉽게 붙일 수 있음. 초기 사례로 https://github.com/graze-social/iftta 참고 가능함.
소셜 네트워크는 “똑같은데 뭔가 추가!” 방식이 아니라, 이전 플랫폼에서는 불가능했던 새로운 방식이 나올 때 성장함.
무료 최상위 도메인(TLD)이 가능할까 궁금함. 실제 도메인 등록에 드는 비용이 뭘까? Let's Encrypt가 안전인증서를 무료로 푼 걸 떠올리면, 비영리 단체가 도메인도 무료로 제공하는 게 왜 불가능할지 의문임. 보기좋을 필요도 없음. UUID v7 여러 개를 쌓아도 상관없고, 전세계적으로 유니크하고 무료면 됨. 브라우저가 접속 후엔 기억할 테니 긴 주소도 문제 없음. 이런 아이디어가 정말 별로일까?
무료 TLD는 현실적으로 실현이 어려움. TLD와 public suffix list에는 여러 규칙과 비용, 관리상의 특수성이 따름 https://github.com/publicsuffix/list 참고. 단, TLD가 아닌 일반 도메인은 얼마든지 자유롭게 쓸 수 있고, 무료 서브도메인도 배포할 수는 있음. 하지만 실제 이런 서비스 운영하면 곧 스팸/피싱 등 다크 인터넷의 공격이 몰려와 운영을 후회하게 됨. 마치 누구나 URL 리다이렉터를 만들 수는 있어도 실제 운영은 별개의 문제인 것처럼, 제대로 운영하면 곧 문제에 봉착함. 안타까운 현실임.
사실상 IPv6 주소 배포와 비슷한 개념임. 요즘 대부분의 가정용 인터넷엔 /64 단위 public IPv6를 할당해 주지만, ISP가 대부분 포트 방화벽을 걸여서 실질적으로 활용이 막혀 있음. 게다가 ISP를 바꾸거나 하면 주소를 잃어버리기 쉬움. 이걸 정말 영구적이고 휴대 가능한 IPv6 주소로 만들려면, 개인 단위로 provider-independent 주소 공간을 무료로 배포하고, 이를 BGP로 글로벌 라우팅까지 연결해야 함. 이론상 가능하지만 아직 구현된 적은 없음(Let's Encrypt가 탄생하기 전 상태와 유사).
DNS 기반 네이밍이 왜 필요한지는 모르겠지만, 짧고 외우기 좋은 게 아니라면 DNS는 그리 적합하지 않음. 하지만 ngrok처럼 자체 gTLD로 도메인을 뽑아주는 방식은 해볼 만함. 실제 .me ccTLD가 과거에 이런 식으로 무료 도메인을 배포했고, 대가로 모든 트래픽에 중간 프록시 서버에서 광고를 삽입했었음.
.tk가 무료였고, 등록건수로 세계 최대 ccTLD였음. 주로 악용 사례가 많음. Facebook이 운영사(네덜란드 회사 Freenom)를 피싱에 연루시켰다는 이유로 소송하면서 이제 무료는 불가해짐.
Dan의 글이 보이면 클릭함. 오픈웹이 최초 진입자 프리미엄 덕분에 성공한 것 같아 조금은 걱정임. 반면 오픈소스가 성공하는 모습을 보면 희망을 느낌. atproto 같은 게 성공하는 세상을 보고 싶음. 네트워크 효과 때문에 더 나은 앱이 성공하지 못하는 게 정말 아쉬움.
HTML이 성공한 이유는 ‘무료’였기 때문임. 당시엔 유료 하이퍼미디어 표준이 많았지만, 그런 경쟁자들과 달리 접근성이 뛰어났음. 누구나 쉽게 브라우저나 서버를 만들 수 있었던 환경임.
ATProto가 네트워크 효과의 한계를 깰 수 있도록 설계된 것도 큰 장점임. 모두가 atproto 기반으로 이주하면, 더이상 소셜 네트워크를 “마지막으로 한 번만” 옮기면 되는 구조가 됨. 궁극적으로는 탈중앙, 자유로운 경쟁이 가능한 환경을 제공함.
현실적으로는 이런 시스템이 널리 퍼질 수 있을지 상상하기 어려움. 전통적인 소셜미디어 타깃과 탈중앙 지향 성향 이용자 층이 아예 다름. 대부분은 그냥 플랫폼이란 수단에만 관심이 있고, 시스템에는 신경 쓰지 않음. 결국 모두가 bluesky 계정만 만든다면, 기존과 마찬가지로 몇몇 대형 서비스에 집중돼 무의미해짐.
모두가 bsky.social에 모여도 기존 대비 엄청난 진보임. AWS에 많은 서버가 몰렸다고 해서 웹이 중앙집중화됐다고 말하지 않는 것처럼, 언제든 필요하면 옮길 수 있음.
실제로 bluesky는 아직 완전히 연동화(federation)가 구현되지 않았음. 모든 트래픽이 단일 "BGS" 라우터 서버에 의존함.
안타깝지만, 결국 문제의 원인은 '사람'임.
이 작업에 대해 복잡한 마음임. 한편으론 아이디어가 완전히 내 취향임. 모든 사람이 자신 소유의 컨텐츠를 갖는다는 Indie web 운동과 맥락이 맞고, 이 페이지와 글들의 완성도도 정말 인상적임. 한편, 이런 표준을 실제로 개인 블로그나 오픈소스 프로젝트에 적용하는 개발자는 거의 없고, 그냥 브이로그/블로그 운영자, 일반 이용자들에서도 채택이 저조함. 데이터 소유권, 개방성, 상호운용성에 무감한 사람이 많다는 사실이 걱정됨. 사람들은 TikTok, Instagram 릴스 같은 피드만 바라는 것 같음. 비전과 노력은 존경하지만, 과연 이게 미시적 취미가 아닌 주류가 될 수 있을지 고민임.
개발자 경험을 좀 더 쉽도록 개선하는 일이 남아 있음. 하지만 이 영역의 발전속도가 굉장히 빠르기에, 앞으로 6~12개월이 엄청 기대됨. 대부분의 사람들이 ATProto가 단순히 Bluesky뿐 아니라, 훨씬 다양한 분야에 적용 가능하다는 사실을 이해하지 못하고 있고, 이 점이 시장에 더 구체적으로 드러나는 데 시간이 필요함.
왜 '데이터 소유권' 개념이 그렇게까지 중요한지, 그리고 대중이 신경 쓰지 않는 것이 정말로 걱정스러운 이유가 무엇인지 궁금함. 과거에도 사람들은 TV, 책, 라디오처럼 소유권 없이 콘텐츠를 소비해 왔음. 지금은 자신이 뭔가를 올리고 주변이 볼 수 있는 기회가 주어졌을 뿐인데, 인스타그램 포스트의 실제 '소유' 여부가 그리 중요한가 하는 의문도 있음.
말씀에 동의함. 결국 우리가 주체적으로 이 기술을 전파하고, 대중화에 힘써야 성공할 수 있음. 언젠가 오픈 소셜에 매료된 창업자/CTO가 대중적인 성공 앱을 선보일지도 모르고, 아무것도 하지 않으면 절대 성공 못함.
Hacker News 의견
AT Protocol이 Bluesky의 시스템이라 처음엔 ActivityPub의 기업 버전 같다고 생각했지만, 이번 글을 읽고 보니 데이터가 내가 선택한 '저장소(repository)'에 저장되는 방식이 꽤 마음에 듦. 내 일반적인 원칙과도 일치하는데, 읽기 쪽에서 필터링 등을 실행하는 게 글을 쓸 때보다 더 낫다고 믿음. 그래서 내가 원하는 모든 것을 내 저장소에 올리고, 다른 사람들이 그걸 읽고 이용할 수 있는 구조가 좋은 것임. 화살표가 댓글이 내 저장소에 들어가는 것처럼 보이긴 하지만, 아이디어를 표현하다 나타난 약간의 부정확성 같음. 전반적으로 매우 멋지고 분산화되어 있는 구조라고 느낌. 하지만 실제로 AT에서 별도의 PDS를 직접 운영해 보려 했더니, 꽤 매끄럽고 잘 포장되어 있지만 몇 가지 전제 조건이 있음을 알게 됨:
내가 화살표를 두 가지로 써서 혼란을 준 것 같음. 실선 화살표(@alice.com에서 내려가는)는 소유권을 나타냄. 색깔별 그룹핑과 동일함. 파란색은 전부 Alice 것이란 뜻임. 점선 화살표는 레코드 사이의 링크임. 이는 <a href>와 동일하게, 어떤 레코드든 어떤 저장소에 있더라도 자유롭게 연결 가능함. 누군가 내 포스트에 댓글을 달면, 그 댓글은 댓글 단 사람의 저장소에 들어가고, 원글과 연결고리가 생김. 데이터 모델을 이렇게 설계한 이유는, 인덱싱하는 사람이 두 레코드를 모두 갖고 있으면 관계를 쉽게 복원할 수 있도록 하기 위함임. 예시로 Bob이 Alice의 글에 댓글을 달면, Bob의 댓글은 Bob 저장소에, Alice 글은 Alice 저장소에 있음. 내 포스트에 누군가 댓글을 쓰면, 그 댓글은 항상 그 사람 저장소에 남음. 타인의 저장소에 레코드를 생성할 수 없다는 것이 핵심 전제임.
기본 PDS 패키징이 SSL 처리를 자동으로 지원하지만, 필수는 아니고 개발자가 쉽게 적용할 수 있도록 만들어 둔 것임. at:// URI는 at://DID/... 형태이고, 사람이 읽을 수 있는 핸들은 DNS TXT 레코드(_atproto.roshangeorge.dev)를 통해 DID에 매핑됨. DID는 서버 위치를 명시하는 문서로 연결되어 있어서, HTTPS/WSS 라우트도 어디든 둘 수 있음. 또한 내 포스트의 좋아요, 답글 등은 그 행동을 한 사람의 저장소에 들어가고 내 저장소엔 들어오지 않음. 이 부분의 직감이 맞았음.
ActivityPub이 더 나은 프로토콜이고 AT는 그저 저렴한 모작이라 생각했지만, 이 글을 보고 AT가 훨씬 낫다는 사실을 깨달음. 핵심은 여러 프로그램이 동일한 아이덴티티를 공유할 수 있는 점임. 이게 진짜 대단한 기능이고 정말 시야가 확장되는 경험이었음.
ATProto 관련 설명은 대부분 데이터 소유권에 초점을 맞추지만, 실제로는 데이터 처리 부분에서 ActivityPub이 더 강력함. ATProto는 전 세계를 공개적으로 바라보는 구조라, 모든 이벤트가 신뢰받는 글로벌 AppServer에서 보이고 직접 판단해야 하므로 피드 생성, 접근 권한 등을 모두 신뢰 중개자에게 의존해야 함. ActivityPub은 오히려 RSS나 이메일과 비슷하게, 내가 구독한 피드만 내 서버가 관리하고, 인박스는 내가 접근 가능한 포스트로 바로 구성됨. Bluesky에서는 트위터처럼 "비공개 좋아요"가 불가능한 이유도 이 때문임. AppView마다 네트워크 내 모든 포스트의 좋아요 수를 직접 추적해야 해서 엄청 번거로움. 장기적으론 ActivityPub 구조가 더 유리할 거라고 생각함. 그리고 “여러 프로그램이 동일 아이덴티티를 공유”하는 부분은 사실 초창기 ActivityPub 설계에도 있던 것임. 가장 대중적인 초기 구현체들이 기존 구조에 맞추기 위해서 그 기능을 뺀 것뿐임.
AT 대 AP 논쟁이 워낙 복잡함. 우리 커뮤니티에서도 수차례 논의가 있었으니, 참고할 만한 스레드를 남김: https://github.com/bevyengine/bevy/discussions/18302
이런 부분이 마음에 와닿는다니 기쁨. 항상 AP와 비교하는 게 답답한데, 스코프 자체가 전혀 다름.
비슷한 시각을 분산 시스템 엔지니어의 관점에서 다룬 글도 재미있을 것임. https://atproto.com/articles/atproto-for-distsys-engineers
그러면 중앙화된 아이덴티티 서비스가 있다는 뜻인가 궁금함.
어떤 분산 프로토콜이 승리하든 상관없지만, ATProtocol이 이론적으로는 좋아 보여도 실전에서는 점점 ActivityPub 쪽이 더 매력적으로 느껴짐. 나는 Lemmy에서 자주 활동하는데, 상당히 활발하고 재미있음.
Mastodon과는 다르게 AT에서는 인스턴스 개념 자체가 다름. Bluesky 인프라 내에도 여러 PDS가 있고 구조적으로 계층적으로 다르게 동작함(관련 기사 참고). 단일한 지배적 인스턴스라고 표현하는 건 맞지 않음. 물론 기업이 프로토콜을 자기 입맛대로 좌지우지할 우려는 현실적인 고민임. 하지만 지금까지는 좋은 관리자 역할을 했다고 평가됨. 생태계가 성장하면서 점차 해결될 부분이라고 생각함. 그리고 Bluesky가 서비스 문을 닫고 이사가 불가능해질 우려도 있는데, Protocol 자체에 백업과 이사가 내장되어 있음. CAR 파일만 있으면 언제든 다른 호스트로 이전 가능함. Mastodon은 계정 이동 시 손실이 많지만, atproto는 100% 투명하게 이전 가능함.
결국 Bluesky든 Mastodon이든 들어가보면 미국 정치 얘기밖에 없음. 주간 정치 드라마를 별로 좋아하지 않아서 Tumblr나 Pinterest, 혹은 TikTok 같은 더 다양한 플랫폼이 나에게 맞는 듯함.
Mastodon이 ActivityPub과 완전히 동일하진 않지만, 답글이 갑자기 사라지는 점 때문에 신뢰가 안 감. 어떤 글은 남았다가 또 사라지고, 이 부분이 Mastodon을 떠난 두 가지 이유 중 하나였음.
앱마다 자체적인 컬렉션 타입을 쓰고, 그들끼리 컬렉션을 공유할 수 있어도, 결국 앱들이 서로 호환될지는 명확하지 않다는 점이 약간 아쉬움. ActivityPub의 아름다운 점 중 하나는 Mastodon 사용자가 Pixelfed 사용자를 특별히 신경쓸 것 없이 구독할 수 있다는 점임. 마치 트위터, 인스타그램, 레딧, 유튜브, Substack이 별다른 설정 없이 자동으로 다 연결되는 느낌임.
AP가 기본적으로 상태(Status)와 질문(Question) 타입에서는 여러 서비스가 잘 연동됨. Mastodon, Pixelfed, Misskey, Pleroma 등이 모두 이 체계를 중심으로 돌아감. 하지만 그 외 타입 지원은 매우 제한적이라, 다른 유형의 콘텐츠는 제대로 지원되지 않음. 표준 외확장에 대한 커뮤니티 조직이 부족한 것이 문제임. ATproto는 데이터 컬렉션의 lexicon/schema 정의를 반드시 따라야 하고, 레퍼런스와 서드파티 구현체들이 스키마 유효성 검사를 제공함. 그래서 기본적인 호환성이 더 명확하게 구조화되어 있지만, 오히려 일부 추가 필드 등에 선택적 지원도 가능하게 해서 좀 더 유연해질 필요가 있다고 생각함. Bridgy Fed처럼 APub에서 온 데이터를 원문 URL, 텍스트 등 메타데이터로 붙이는 예도 있음. (https://fed.brid.gy/docs#bluesky-fields 참고)
공통 lexicon 개선을 위한 노력이 진행 중임: https://github.com/lexicon-community
"차세대 트위터"를 외치는 프로젝트들이 문제 해결 방식이 조금씩 어긋난다고 느끼기 시작함. 트위터 기능 완벽 재현 후엔 유저, 콘텐츠 부족(치킨 앤 에그) 문제에서 막힐 뿐임. 결국 사람들은 사람이 많은 곳에 모이고, 그게 아직도 트위터임. 오히려 최근 오픈AI가 론칭한 타임라인처럼, 백그라운드에서 데이터를 우선 모은 뒤 사용자에게 전달하는 방향이 더 나아 보임. 구체적인 구현은 다를 수 있지만, 방향성은 옳다고 느낌. 대부분의 이용자가 트윗 작성 기능에 큰 가치를 두지 않고, 진짜 가치는 데이터 소비(콘텐츠 소싱)임. 이런 관점에서 다중 소셜 RSS 리더기 + P2P 옵션이 더 좋은 방향이라 생각함. 개인적 의견임.
기사에 설명된 것처럼, 초기 프레이밍엔 마이크로블로깅을 사용하지만 실제로는 트위터 류 뿐 아니라 다양한 형태가 가능함. 예시로 Tangled는 "Github on atproto", Leaflet은 "Medium on atproto" 구성임. 클라이언트 측 P2P 방식의 한계는 대규모 집계(aggregation)와 일관성을 보장하기 어렵다는 것이고, 대부분의 일반 사용자가 기대하는 소셜앱의 기본임. 오픈AI 예시도 atproto가 강점을 보이는 부분임. 네트워크에 이미 데이터가 존재하므로 크롤링, 인덱싱, 자동화 도구를 쉽게 붙일 수 있음. 초기 사례로 https://github.com/graze-social/iftta 참고 가능함.
소셜 네트워크는 “똑같은데 뭔가 추가!” 방식이 아니라, 이전 플랫폼에서는 불가능했던 새로운 방식이 나올 때 성장함.
그래서 Nostr가 다름! 블로그, 트위터류, 스트리밍 서비스, 메신저 등 뭐든 만들 수 있음. 예시 모음: https://nostrapps.com
무료 최상위 도메인(TLD)이 가능할까 궁금함. 실제 도메인 등록에 드는 비용이 뭘까? Let's Encrypt가 안전인증서를 무료로 푼 걸 떠올리면, 비영리 단체가 도메인도 무료로 제공하는 게 왜 불가능할지 의문임. 보기좋을 필요도 없음. UUID v7 여러 개를 쌓아도 상관없고, 전세계적으로 유니크하고 무료면 됨. 브라우저가 접속 후엔 기억할 테니 긴 주소도 문제 없음. 이런 아이디어가 정말 별로일까?
atproto에선 이런 걸 did:plc가 맡음. https://web.plc.directory/에서 무료 ID 발급 가능함. 예시로 내 ID는 https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr임. 도메인의 TXT 레코드로 해당 did:plc와 연동할 수 있음.
무료 TLD는 현실적으로 실현이 어려움. TLD와 public suffix list에는 여러 규칙과 비용, 관리상의 특수성이 따름 https://github.com/publicsuffix/list 참고. 단, TLD가 아닌 일반 도메인은 얼마든지 자유롭게 쓸 수 있고, 무료 서브도메인도 배포할 수는 있음. 하지만 실제 이런 서비스 운영하면 곧 스팸/피싱 등 다크 인터넷의 공격이 몰려와 운영을 후회하게 됨. 마치 누구나 URL 리다이렉터를 만들 수는 있어도 실제 운영은 별개의 문제인 것처럼, 제대로 운영하면 곧 문제에 봉착함. 안타까운 현실임.
사실상 IPv6 주소 배포와 비슷한 개념임. 요즘 대부분의 가정용 인터넷엔 /64 단위 public IPv6를 할당해 주지만, ISP가 대부분 포트 방화벽을 걸여서 실질적으로 활용이 막혀 있음. 게다가 ISP를 바꾸거나 하면 주소를 잃어버리기 쉬움. 이걸 정말 영구적이고 휴대 가능한 IPv6 주소로 만들려면, 개인 단위로 provider-independent 주소 공간을 무료로 배포하고, 이를 BGP로 글로벌 라우팅까지 연결해야 함. 이론상 가능하지만 아직 구현된 적은 없음(Let's Encrypt가 탄생하기 전 상태와 유사). DNS 기반 네이밍이 왜 필요한지는 모르겠지만, 짧고 외우기 좋은 게 아니라면 DNS는 그리 적합하지 않음. 하지만 ngrok처럼 자체 gTLD로 도메인을 뽑아주는 방식은 해볼 만함. 실제 .me ccTLD가 과거에 이런 식으로 무료 도메인을 배포했고, 대가로 모든 트래픽에 중간 프록시 서버에서 광고를 삽입했었음.
.tk가 무료였고, 등록건수로 세계 최대 ccTLD였음. 주로 악용 사례가 많음. Facebook이 운영사(네덜란드 회사 Freenom)를 피싱에 연루시켰다는 이유로 소송하면서 이제 무료는 불가해짐.
과거 .FREE TLD 이니셔티브가 있었으나, 실행 차질과 기한 미준수 등으로 지금은 흐지부지됨 https://icannwiki.org/.free
Dan의 글이 보이면 클릭함. 오픈웹이 최초 진입자 프리미엄 덕분에 성공한 것 같아 조금은 걱정임. 반면 오픈소스가 성공하는 모습을 보면 희망을 느낌. atproto 같은 게 성공하는 세상을 보고 싶음. 네트워크 효과 때문에 더 나은 앱이 성공하지 못하는 게 정말 아쉬움.
HTML이 성공한 이유는 ‘무료’였기 때문임. 당시엔 유료 하이퍼미디어 표준이 많았지만, 그런 경쟁자들과 달리 접근성이 뛰어났음. 누구나 쉽게 브라우저나 서버를 만들 수 있었던 환경임.
ATProto가 네트워크 효과의 한계를 깰 수 있도록 설계된 것도 큰 장점임. 모두가 atproto 기반으로 이주하면, 더이상 소셜 네트워크를 “마지막으로 한 번만” 옮기면 되는 구조가 됨. 궁극적으로는 탈중앙, 자유로운 경쟁이 가능한 환경을 제공함.
현실적으로는 이런 시스템이 널리 퍼질 수 있을지 상상하기 어려움. 전통적인 소셜미디어 타깃과 탈중앙 지향 성향 이용자 층이 아예 다름. 대부분은 그냥 플랫폼이란 수단에만 관심이 있고, 시스템에는 신경 쓰지 않음. 결국 모두가 bluesky 계정만 만든다면, 기존과 마찬가지로 몇몇 대형 서비스에 집중돼 무의미해짐.
모두가 bsky.social에 모여도 기존 대비 엄청난 진보임. AWS에 많은 서버가 몰렸다고 해서 웹이 중앙집중화됐다고 말하지 않는 것처럼, 언제든 필요하면 옮길 수 있음.
실제로 bluesky는 아직 완전히 연동화(federation)가 구현되지 않았음. 모든 트래픽이 단일 "BGS" 라우터 서버에 의존함.
안타깝지만, 결국 문제의 원인은 '사람'임.
이 작업에 대해 복잡한 마음임. 한편으론 아이디어가 완전히 내 취향임. 모든 사람이 자신 소유의 컨텐츠를 갖는다는 Indie web 운동과 맥락이 맞고, 이 페이지와 글들의 완성도도 정말 인상적임. 한편, 이런 표준을 실제로 개인 블로그나 오픈소스 프로젝트에 적용하는 개발자는 거의 없고, 그냥 브이로그/블로그 운영자, 일반 이용자들에서도 채택이 저조함. 데이터 소유권, 개방성, 상호운용성에 무감한 사람이 많다는 사실이 걱정됨. 사람들은 TikTok, Instagram 릴스 같은 피드만 바라는 것 같음. 비전과 노력은 존경하지만, 과연 이게 미시적 취미가 아닌 주류가 될 수 있을지 고민임.
개발자 경험을 좀 더 쉽도록 개선하는 일이 남아 있음. 하지만 이 영역의 발전속도가 굉장히 빠르기에, 앞으로 6~12개월이 엄청 기대됨. 대부분의 사람들이 ATProto가 단순히 Bluesky뿐 아니라, 훨씬 다양한 분야에 적용 가능하다는 사실을 이해하지 못하고 있고, 이 점이 시장에 더 구체적으로 드러나는 데 시간이 필요함.
왜 '데이터 소유권' 개념이 그렇게까지 중요한지, 그리고 대중이 신경 쓰지 않는 것이 정말로 걱정스러운 이유가 무엇인지 궁금함. 과거에도 사람들은 TV, 책, 라디오처럼 소유권 없이 콘텐츠를 소비해 왔음. 지금은 자신이 뭔가를 올리고 주변이 볼 수 있는 기회가 주어졌을 뿐인데, 인스타그램 포스트의 실제 '소유' 여부가 그리 중요한가 하는 의문도 있음.
말씀에 동의함. 결국 우리가 주체적으로 이 기술을 전파하고, 대중화에 힘써야 성공할 수 있음. 언젠가 오픈 소셜에 매료된 창업자/CTO가 대중적인 성공 앱을 선보일지도 모르고, 아무것도 하지 않으면 절대 성공 못함.