# Bluesky를 경계하라 > Clean Markdown view of GeekNews topic #26891. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26891](https://news.hada.io/topic?id=26891) - GeekNews Markdown: [https://news.hada.io/topic/26891.md](https://news.hada.io/topic/26891.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-22T19:33:13+09:00 - Updated: 2026-02-22T19:33:13+09:00 - Original source: [kevinak.se](https://kevinak.se/blog/be-wary-of-bluesky) - Points: 1 - Comments: 1 ## Topic Body - **ATProto 기반의 Bluesky**는 탈중앙화를 약속하지만, 실제로 대부분의 사용자 데이터가 **Bluesky 서버에 집중**되어 있음 - 사용자는 개인 데이터 서버(PDS)를 직접 운영할 수 있지만, **편의성과 호환성** 때문에 거의 모두 Bluesky의 기본 서버를 이용함 - 새로운 ATProto 앱이 나올수록 데이터가 Bluesky 인프라에 더 쌓이며, **중앙 집중화가 강화되는 구조**임 - Bluesky는 프로토콜, 릴레이, AppView, DID 디렉터리 등 **핵심 계층을 직접 통제**하고 있어, 인수나 정책 변경 시 사용자 통제가 어려움 - 기술적으로는 탈퇴와 자가 호스팅이 가능하지만, **현실적으로는 ‘기본값이 승리’** 하며, 투자 구조상 **수익 압박이 중앙화 유인을 강화**함 --- ### Bluesky의 약속과 현실 - Bluesky는 **ATProto라는 개방형 프로토콜** 위에 구축되어, 사용자가 자신의 데이터와 정체성을 소유할 수 있다고 주장함 - Tangled, Grain, Leaflet 등 다양한 앱이 같은 계정으로 연동 가능 - “원하면 언제든 떠날 수 있다”는 점을 핵심 가치로 내세움 - 그러나 실제로는 대부분의 데이터가 **Bluesky가 운영하는 PDS**에 저장됨 - 자가 호스팅은 가능하지만, 설정과 유지 관리가 복잡하고 실질적 이점이 거의 없음 - Bluesky의 기본 PDS는 즉시 사용 가능하며 모든 앱과 호환되어 사용자들이 이를 선호함 ### 데이터 집중의 구조 - ATProto 앱은 모두 사용자의 PDS에 데이터를 기록하며, **대부분의 사용자가 Bluesky의 PDS를 이용**함 - 게시물, 사진, 이슈 등 모든 데이터가 동일한 서버에 저장됨 - 마이그레이션 도구가 존재하지만, **이용률이 낮고 사전 조치가 필요**함 - 인수 후 데이터 내보내기가 차단되면 이전 도구는 무용지물이 됨 - 역사적으로 대부분의 사용자는 사전에 데이터를 보호하지 않음 ### 중앙화의 가속 메커니즘 - 새로운 ATProto 앱이 등장할수록 **Bluesky 인프라 의존도가 증가**함 - “Bluesky 계정으로 로그인” 구조가 Bluesky 서버에 더 많은 데이터를 쌓게 함 - 개발자들은 Bluesky 인프라 위에서 기능을 구축하며, 결과적으로 Bluesky의 필수성을 강화함 - 프로토콜은 네트워크 전반에 가치를 분산시키지 않고, **Bluesky에 집중시키는 경향**을 보임 - Bluesky는 “열려 있고 탈중앙화되어 있다”고 주장하지만, **실질적 전환 비용은 계속 상승**함 ### 통제 지점(Chokepoints) - **Relay**: 모든 데이터 흐름이 통과하는 핵심 계층으로, Bluesky가 주요 릴레이를 운영 - 제3자가 릴레이를 운영할 수 있지만, 사용자 기반이 없으면 의미 없음 - **AppView**: 타임라인, 스레드, 알림을 구성하는 계층으로, Bluesky의 메인 AppView에 의존 - 해당 계층이 중단되거나 적대적으로 변하면 모든 클라이언트가 영향을 받음 - **DID Directory**: ATProto의 정체성 해석을 담당하며, Bluesky가 중앙에서 관리 - 2023년부터 분산화를 예고했으나 **구체적 일정 없음** - 각 계층마다 “누구나 직접 운영 가능”하지만, **실제로 그렇게 하는 사람은 거의 없음** ### 이메일과의 비교 - 이메일도 개방형 프로토콜이지만, **대부분의 사용자가 Gmail을 이용**하며 중앙화됨 - ATProto는 이보다 더 심각할 수 있음 - 이메일은 각 앱이 개별 서버에 연결되지만, ATProto는 **모든 앱이 동일한 PDS에 데이터 추가** - 결과적으로 “개방형 프로토콜이 중앙화의 가속기 역할”을 함 ### 인수 시 발생 가능한 문제 - Bluesky가 인수될 경우, 인수자는 다음을 통제하게 됨 - 거의 모든 사용자의 PDS - 주요 Relay - 주요 AppView - 모든 정체성을 해석하는 DID Directory - 인수자는 **데이터 내보내기 차단, 서드파티 앱 차단, 연합 기능 중단, 광고 삽입, 콘텐츠 검열** 등을 수행할 수 있음 - 피해 범위는 Bluesky 소셜 네트워크뿐 아니라 Tangled, Leaflet, Grain 등 **전체 생태계로 확산**됨 - 프로토콜상 떠날 수 있다고 해도, **인수 기업은 이를 허용할 유인이 없음** ### 투자 구조와 인센티브 - Bluesky는 **7억 달러 가치 평가와 1억2천만 달러 투자**를 받은 기업 구조 - 투자자는 수익을 요구하며, 이는 **사용자 통제 강화나 중앙화 압력**으로 이어질 가능성 있음 - PBC(공익기업) 구조가 보호 장치로 제시되지만, **법적 효력과 구속력은 불명확**함 - “프로토콜이 인센티브를 구제할 수 없다(The protocol can't save you from incentives)”는 결론으로, **기술적 탈중앙화보다 경제적 유인이 더 강력한 통제 요인**임 ## Comments ### Comment 51581 - Author: neo - Created: 2026-02-22T19:33:13+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47095597) - 모든 계층에서 “누구나 직접 운영할 수 있음”이 정답이지만, 실제로 그렇게 하는 사람은 거의 없음 PLC 디렉토리를 제외하면 **아무도 막지 않는 구조**라서, 이론적으로는 누구나 참여 가능함 이런 유연함 덕분에 ATproto는 다른 **연합형 시스템**보다 훨씬 유리한 출발점을 가짐 - 문제의 원인은 VC 자금으로 운영되는 **중앙집중형 가입 절차의 편리함**임 Bluesky는 탈중앙화를 위한 진입로를 제공하지만, 대부분의 사용자는 비용과 마찰을 감수하지 않음 Mastodon은 완전한 탈중앙형이라 가입 단계부터 마찰이 크고, 그래서 대중적 확산이 어려움 나는 회의적이지만, **대중에게 탈중앙화를 전파**하려면 Bluesky 같은 모델이 최선이라 생각함 - “아무도 막지 않는다”는 말은 현실적으로 **무언가가 막고 있음**을 의미함 기술적 불가능이 아니라 **관성이나 습관**일 수도 있음 해결책이 존재한다고 해서 문제가 자동으로 해결된다고 보는 건 순진한 생각임 모든 해결책에는 **비용과 실행 가능성의 차이**가 존재함 - 문제를 해결하려면 **지식과 자금**이 필요함 안전하게 실행할 기술력과 여유 자금이 있어야 PDS를 직접 운영할 수 있음 HN 사용자조차 모든 디지털 자산을 자가 호스팅하기는 어려움 결국 어딘가에서는 VC 자금으로 운영되는 **무료 서비스**를 이용하게 됨 - 진짜 문제는 **기본값(defaults)** 임 누구나 바꿀 수 있다고 하지만, 실제로는 기본값을 바꾸는 게 불가능한 경우가 많음 - “어떻게 고칠 수 있나?”라는 질문이 남음 - 나는 기사 서두에 인용된 사람임 **Bluesky를 경계해야 함**이 핵심 요지임 인프라는 직접 운영하고, 별도의 회사를 세워야 함 대부분의 불만은 **규모 확장 비용** 문제임 네트워크 전체와 기록을 가져오는 데 시간과 돈이 들기 때문임 구조적으로 중앙화된 부분은 PLC뿐이며, 이는 독립 조직으로 분리 중임 - Bluesky가 불안하다면 예전 프로젝트 **Secure-Scuttlebot(SSB)** 을 살펴보길 권함 콘텐츠 주소 지정과 **서명 키 암호화**로 Bluesky의 문제를 대부분 해결했었음 원본 SSB 코드는 2020년 이후 깨졌지만, 내가 유지 중인 [포크 버전](https://github.com/evbogue/ssbc)이 있음 함께 실험해보고 싶다면 초대도 제공 가능함 - Bluesky 인스턴스를 직접 운영하기가 여전히 어렵기 때문에, 결과적으로 **중앙화로 귀결**됨 사용자 97%가 한 인스턴스에 몰리면 분산 플랫폼이라 보기 어려움 Mastodon.social이 전체의 40%를 넘는다면 문제로 여길 것과 같음 - PLC를 독립 조직으로 옮긴다고 해서 **탈중앙화가 실현되는 것은 아님** - Bluesky의 구조를 논할 때는 반드시 **Blacksky**를 언급해야 함 그렇지 않다면 AT 프로토콜 생태계에 대한 이해가 부족한 글일 가능성이 높음 Blacksky는 ATproto의 각 계층을 **대체 구현**하려는 프로젝트임 - Blacksky를 잘 알고 있지만, **큰 그림에서는 변화가 없음** 바뀌길 바라지만 현실적으로 영향이 미미함 - 탈중앙화를 표방했지만, 결국 **중앙집중형 서비스**를 다시 운영하는 셈임 이럴 바엔 Movim 같은 XMPP 기반 서비스를 쓰는 게 낫다고 생각함 - 실제로는 [활성 기여자 1명짜리 저장소](https://github.com/blacksky-algorithms/rsky/graphs/contributors)에 불과함 그래서 글에서 생략된 듯함 - 기본값을 바꿔야 한다면 99%의 사용자는 시도하지 않음 시스템은 결국 **가장 쉬운 사용자 여정**이 표준이 됨 미래의 위험 대비 같은 **가상의 가치**로는 사용자를 움직일 수 없음 - “트위터가 망하면 떠나면 된다”는 말은 예전에도 들었음 하지만 실제로는 대부분 떠나지 않았음 Bluesky가 트위터의 대안이라면, 사람들이 **정말로 이동할지**가 핵심임 UI도 거의 동일하고, 전제 자체가 “트위터가 나빠지면 떠난다”는 것이었음 - 이 말은 사람들이 X에서 Bluesky로 **탈중앙화를 위해 이동**하지만, 결국 **비슷한 락인(lock-in)** 을 겪는다는 뜻으로 보임 - 내 주변은 실제로 트위터를 떠났음 지금은 친구들이 **Bluesky 링크**를 공유함으로써 소통함 - 나는 Bluesky에 아는 사람이 없음 여전히 X에서 친구들과 활동 중이며, 트위터 시절의 경험을 좋아함 - ATproto에서는 언제든 데이터를 **내보내기(export)** 할 수 있음 앱이 PDS와 상호작용할 때 이미 데이터를 읽기 때문임 만약 이를 막는다면 ATproto 기능 자체를 막는 셈임 - 하지만 트위터도 API를 없앴고, 구글도 XMPP 연합을 중단했음 Bluesky가 프로토콜을 끊더라도 대부분의 사용자는 **크게 반발하지 않을 것**임 참고: [Google XMPP 지원 종료 안내](https://support.google.com/code/answer/55703?hl=en) - 백업 서비스를 이용하면 **데이터 접근 차단**을 피할 수 있음 - Bluesky는 언제든 자신의 데이터를 다른 인프라로 옮길 수 있게 설계됨 실제로 **Blacksky** 같은 그룹이 그렇게 하고 있음 대부분이 이동하지 않는 건, 현재 Bluesky의 운영 방식에 만족하기 때문임 그래서 “문제가 뭐냐”는 질문이 나옴 - 하지만 트위터 때도 **대부분은 만족**했었음 - “문제가 뭐냐”는 질문은 핵심을 놓침 대부분의 사용자는 **기본값을 바꾸지 않기 때문에**, 결국 중앙집중으로 귀결된다는 게 문제의 요지임 - 일부는 이미 직접 운영 중이며, **Bluesky의 개방성**을 긍정적으로 평가함 왜 이런 구조를 경계해야 하는지 이해하기 어렵다고 말함 - 하지만 글의 요지는 “**문제가 생기면 이미 늦다**”는 경고임 - 진정한 탈중앙화는 결국 **모두가 자신의 서버를 운영**해야 함 비용과 유지보수의 부담이 있지만, 그게 대가임 ATproto는 최소한 **데이터 이동성**을 보장함 트위터나 인스타그램에서는 불가능한 일임 - 이 **이동성(portability)** 은 ActivityPub의 한계를 보완하려는 시도였음 AP 진영도 ATproto의 장점을 일부 도입하려 함 Nostr 쪽은 다소 다른 분위기라, 이번 논의가 그 커뮤니티 전체를 대표하는지는 모르겠음 - “트위터가 망하면 떠난다”는 말에 나는 실제로 **떠났음** 지금은 모든 소셜미디어를 경계하는 입장임 - 결과적으로 **데이터와 사회적 연결**을 잃었고, 그 경험이 나를 조심스럽게 만들었음