오픈 소셜

(overreacted.io)

2P by GN⁺ 8시간전 | ★ favorite | 댓글 2개

오픈 소스가 소프트웨어 인프라의 표준이 된 것처럼, 소셜 앱에도 '오픈 소셜' 패러다임이 등장함
AT Protocol은 사용자가 소셜 데이터를 직접 소유 및 제어할 수 있게 하여, 기존 소셜 플랫폼과 차별화된 개념을 제시함
소셜 데이터가 더 이상 특정 서비스 안에 가두어지지 않고, 사용자가 직접 관리하는 개인 저장소에 저장됨
이를 통해 앱 간 데이터 재사용 및 리믹스가 가능해지고, 서비스 종료 시에도 데이터가 사라지지 않고 지속됨
오픈 소셜의 확산으로 사용자 주도 데이터 소유권과 유연한 확장성이 핵심 가치로 부상할 전망임

서론: 오픈 소스의 성공과 새로운 흐름

오픈 소스는 과거 많은 저항에도 불구하고 오늘날 공통 인프라의 기반으로 자리 잡음
과거와 달리 지금은 오픈 소스를 선택해도 문제가 되지 않으며, 중요한 소프트웨어 분야에서 오픈 소스가 기본값으로 정착함
지금은 소셜 앱 분야에서 35년 전 오픈 소스와 유사한 전환점에 직면하고 있음
새로운 흐름인 '오픈 소셜' 이 등장하였으며, Bluesky의 AT Protocol은 가장 설득력 있는 구현으로 평가됨

웹의 기본 구조와 개인 데이터 소유

과거 웹에서는 alice.com, bob.com 같은 개인 주소가 있었고, 각 사용자가 자신만의 공간을 소유하며 그 위에 각자 자유롭게 콘텐츠를 올렸음
호스팅이 맘에 안 들면 다른 곳으로 옮겨도 주소는 그대로 유지되었고, 기존 링크도 끊기지 않았음
이 때문에 사용자는 특정 호스팅 업체에 얽매이지 않았고, 업체는 경쟁을 해야 했음
즉, 웹의 탈중앙화 설계 덕분에 사용자가 데이터를 쥐고, 업체는 단순한 제공자 역할을 했음

현대 소셜 네트워크: 데이터의 소유권 상실

오늘날 사람들은 자기 사이트를 운영하기보다, 회사가 준 @alice, @bob 같은 아이디를 받아 소셜 미디어 앱에 게시하는 방식이 일반화됨
게시물, 댓글, 좋아요 등의 데이터가 특정 소셜 회사의 데이터베이스에 저장됨
이러한 구조 덕분에 검색, 피드, 추천, 알림 등 사회적 집계 기능이 탄생함
그러나 핵심 데이터가 우리의 소유가 아니게 되는 부작용이 발생함
사용자는 자신이 만든 데이터와 관계를 자유롭게 들고 나가지 못하는 상황에 놓임

문제점: 플랫폼에 갇힌 사용자

사용자가 떠나면 자기가 만든 연결고리 전체를 두고 가야 함
호스팅 업체를 쉽게 바꿀 수 없고, 플랫폼을 떠나면 연결과 데이터도 함께 잃어버리는 문제가 생김
플랫폼은 이를 알고 있기 때문에 사용자에게 불리한 변경(광고 남발, 알고리듬 왜곡, 기능 삭제 등) 을 해도 견뎌야 하는 상황이 됨
데이터 백업이나 내보내기를 하더라도, 그것은 사회적 맥락이 사라진 '죽은 데이터' 에 불과해 다른 곳에서 다시 살리기 어려움

오픈 소셜: 데이터 소유권과 네트워크의 회복

오픈 소셜에서는 @alice.com과 같은 도메인 기반 핸들을 통해, 소셜 데이터의 실질적 소유권을 사용자에게 부여함
- 이름이 @alice.com처럼 내가 가진 도메인과 연결됨
사용자는 개인 저장소(repository) 를 통해 자신이 생성하는 모든 소셜 데이터를 직접 관리함
- 글, 댓글, 팔로우 같은 활동은 개인 저장소(repo) 에 기록됨
- 저장소는 단순한 웹 서버이며, JSON 형식의 기록을 보관함
- 주소는 at://alice.com/">at://alice.com/... 형태라 서로 연결할 수 있음
AT Protocol 기반 저장소는 DNS, HTTP, JSON 위에서 작동하며, 각 데이터가 하이퍼링크된 JSON 형태로 저장됨
기술을 모르는 사람도 앱 가입 시 자동으로 저장소가 만들어져, 데이터는 앱과 상관없이 사용자 소유로 남음
데이터는 사용자의 저장소에 소유되며, 서비스 사업자가 변경되어도 데이터 소유권과 연결성이 유지됨

오픈 소셜 앱의 구조와 응용

각 오픈 소셜 앱은 CMS처럼 사용자의 소셜 저장소 일부를 관리하며, 앱은 이제 사용자의 저장소에 쓰고 읽는 도구에 불과함
예를 들어 Bluesky, Tangled, Leaflet 등 서로 다른 앱의 데이터가 한 사용자의 저장소에서 공존하게 됨
- Bluesky에 글을 쓰면 내 저장소에 기록이 남고, Tangled에서 프로젝트를 별표하면 그것도 내 저장소에 들어감
- 데이터 형식은 충돌을 방지하기 위해 네임스페이스(예: app.bsky.post, sh.tangled.star 등)로 구분됨
- 시간이 지나면 내 저장소는 여러 앱에서 모인 데이터의 모음이 됨

데이터 개방이 가져오는 생태계 변화

데이터가 개방적으로 저장되기 때문에 앱 간 통합, 새로운 서비스 개발, 서로의 데이터를 자유롭게 참조, 재사용, 리믹스 등이 쉬워짐
앱이 종료되어도 데이터는 사용자의 저장소에 남아 다른 서비스에서 재활용 가능
새로운 앱은 기존 네트워크의 관계/데이터를 활용하여 '콜드 스타트'(초기 네트워크 구축 문제)를 극복할 수 있음
이 데이터는 누구나 읽을 수 있기 때문에, 다른 앱이 가져와서 프로필 사진을 불러오거나, 기존 팔로우 관계를 그대로 활용할 수 있음
앱이 문을 닫아도 데이터는 사용자 저장소에 남아, 다른 앱이 다시 꺼내 쓸 수 있음

집계(aggregation)와 기술적 과제

사용자의 데이터가 각자 저장소에 분산되어 있으나, 웹소켓 구독을 통해 데이터 변경 이벤트 스트림을 받아 로컬 데이터베이스에 반영
대형 릴레이(중계 서버)를 통해 전체 네트워크의 이벤트를 수신하고 필요한 이벤트만 필터링함
데이터 레코드는 암호화 서명되어 신뢰성과 정합성 보장
예를 들어 Graze, Slices 같은 인프라가 오픈 소셜 집계를 지원

집계 기능은 어떻게?

각 사용자의 저장소는 따로 존재하지만, 앱은 사용자 저장소에서 나오는 실시간 이벤트 스트림을 받아 자신의 데이터베이스에 기록함
블루스카이와 같은 중계 서버(릴레이)가 전체 스트림을 모아 전달해 주고, 앱은 관심 있는 이벤트만 골라 저장함
이렇게 쌓은 데이터베이스는 검색, 피드, 추천 같은 기능을 빠르게 제공할 수 있음
데이터 레코드는 암호화 서명되어 신뢰성과 정합성 보장 : 중계를 믿지 않아도 데이터의 진위를 확인할 수 있음
Graze, Slices 같은 인프라가 오픈 소셜 집계를 지원

큰 그림

과거 웹: 사용자가 자신의 콘텐츠와 주소를 쥐었음
오늘날 소셜앱: 집계 기능은 있지만, 데이터는 회사 소유 데이터베이스 안에 묶여 있음
오픈 소셜: 집계 기능을 유지하면서도 데이터는 사용자 손에 남음
앱은 단지 사용자의 데이터를 모아 보여주는 창으로 바뀜
서비스가 없어져도 데이터는 남아, 다른 앱이 새로운 맥락으로 다시 보여줄 수 있음

결론

개인 웹의 장점(데이터 소유, 호스팅 자유, 링크 유지)과 폐쇄형 소셜 네트워크의 강점(집계, 확장성)을 결합하는 것이 오픈 소셜의 핵심
오픈 소셜은 사용자 주도의 데이터 소유권, 앱 간 자유로운 데이터 이동성, 서비스 지속성을 보장
- 오픈소스가 “코드는 사용자 것이어야 한다”고 했던 것처럼, “** 데이터는 사용자 것이어야 한다**”
- 폐쇄형 플랫폼에서 사용자가 데이터와 연결성을 잃는 문제를 해결함
더 많은 오픈 소셜 제품이 등장하면, 앱 간 경계가 희미해지고, 데이터가 자연스럽게 흘러 다니는 생태계로 진화
- 결국 사용자가 실질적으로 데이터와 네트워크를 통제할 수 있는 미래가 도래할 가능성이 있음
초창기에는 소수의 열성적인 개발자와 사용자들이 이끌겠지만, 공유된 기반이 쌓이면 언젠가는 열린 방식이 이길 가능성이 큼
- 기술적 개념(탈중앙화, 연방화)을 몰라도 실질적 효익(데이터 연동, 손쉬운 이전, 지속성) 을 체감할 수 있음
- 오픈 소셜은 열정적인 커뮤니티 기반의 장기적인 노력과 누적 효과로 점차 확대될 것

카톡... ㅆ

GN⁺ 8시간전 [-]

Hacker News 의견

AT Protocol이 Bluesky의 시스템이라 처음엔 ActivityPub의 기업 버전 같다고 생각했지만, 이번 글을 읽고 보니 데이터가 내가 선택한 '저장소(repository)'에 저장되는 방식이 꽤 마음에 듦. 내 일반적인 원칙과도 일치하는데, 읽기 쪽에서 필터링 등을 실행하는 게 글을 쓸 때보다 더 낫다고 믿음. 그래서 내가 원하는 모든 것을 내 저장소에 올리고, 다른 사람들이 그걸 읽고 이용할 수 있는 구조가 좋은 것임. 화살표가 댓글이 내 저장소에 들어가는 것처럼 보이긴 하지만, 아이디어를 표현하다 나타난 약간의 부정확성 같음. 전반적으로 매우 멋지고 분산화되어 있는 구조라고 느낌. 하지만 실제로 AT에서 별도의 PDS를 직접 운영해 보려 했더니, 꽤 매끄럽고 잘 포장되어 있지만 몇 가지 전제 조건이 있음을 알게 됨:
1. SSL 같은 것을 자동으로 처리해줌
2. HTTPS/WSS 서버를 띄워 여러 RPC 처리를 지원함 이 때문에 실질적으로 https://roshangeorge.dev과 at://roshangeorge.dev를 모두 쓰고 싶더라도, 후자의 경우 https://roshangeorge.dev/xrpc와 wss://roshangeorge.dev가 필요함. 그래서 결론적으로 https://roshangeorge.dev과 at://at.roshangeorge.dev, 그리고 https://at.roshangeorge.dev, wss://at.roshangeorge.dev로 운영하게 됨. 물론 이건 사소한 부분이고 전체 방향성엔 문제가 안 됨. 그래도 짚고 싶은 내용임.
- 내가 화살표를 두 가지로 써서 혼란을 준 것 같음. 실선 화살표(@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에서 자주 활동하는데, 상당히 활발하고 재미있음.
1. AT 사용자의 99.99%가 Bluesky에 몰려 있음. 이건 기업이 이끄는 서비스임. 그들이 프로토콜을 통제하지 않는다고 주장해도, 사실상 프로토콜의 지배적 인스턴스이기 때문에 자기들 입맛대로 바꿀 위험이 있음. 심지어 5년 후 이사가 불가능하다 결심할 수도 있다는 걱정도 있음. 이런 일이 이미 여러 소셜미디어에서 반복적으로 발생했음.
2. 이용자들은 프로토콜 따위엔 관심 없고 관성, 사용자 기반이 훨씬 중요함. 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 참고)
- 공통 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가 대중적인 성공 앱을 선보일지도 모르고, 아무것도 하지 않으면 절대 성공 못함.

답변달기