▲

Bluesky를 경계하라

 (kevinak.se)
1P by GN⁺ 12시간전 | ★ favorite | 댓글 1개
  • 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)”는 결론으로,
    기술적 탈중앙화보다 경제적 유인이 더 강력한 통제 요인임
▲
GN⁺ 12시간전  [-]
Hacker News 의견들

  • 모든 계층에서 “누구나 직접 운영할 수 있음”이 정답이지만, 실제로 그렇게 하는 사람은 거의 없음
    PLC 디렉토리를 제외하면 아무도 막지 않는 구조라서, 이론적으로는 누구나 참여 가능함
    이런 유연함 덕분에 ATproto는 다른 연합형 시스템보다 훨씬 유리한 출발점을 가짐

    • 문제의 원인은 VC 자금으로 운영되는 중앙집중형 가입 절차의 편리함임
      Bluesky는 탈중앙화를 위한 진입로를 제공하지만, 대부분의 사용자는 비용과 마찰을 감수하지 않음
      Mastodon은 완전한 탈중앙형이라 가입 단계부터 마찰이 크고, 그래서 대중적 확산이 어려움
      나는 회의적이지만, 대중에게 탈중앙화를 전파하려면 Bluesky 같은 모델이 최선이라 생각함
    • “아무도 막지 않는다”는 말은 현실적으로 무언가가 막고 있음을 의미함
      기술적 불가능이 아니라 관성이나 습관일 수도 있음
      해결책이 존재한다고 해서 문제가 자동으로 해결된다고 보는 건 순진한 생각임
      모든 해결책에는 비용과 실행 가능성의 차이가 존재함
    • 문제를 해결하려면 지식과 자금이 필요함
      안전하게 실행할 기술력과 여유 자금이 있어야 PDS를 직접 운영할 수 있음
      HN 사용자조차 모든 디지털 자산을 자가 호스팅하기는 어려움
      결국 어딘가에서는 VC 자금으로 운영되는 무료 서비스를 이용하게 됨
    • 진짜 문제는 기본값(defaults) 임
      누구나 바꿀 수 있다고 하지만, 실제로는 기본값을 바꾸는 게 불가능한 경우가 많음
    • “어떻게 고칠 수 있나?”라는 질문이 남음

  • 나는 기사 서두에 인용된 사람임
    Bluesky를 경계해야 함이 핵심 요지임
    인프라는 직접 운영하고, 별도의 회사를 세워야 함
    대부분의 불만은 규모 확장 비용 문제임
    네트워크 전체와 기록을 가져오는 데 시간과 돈이 들기 때문임
    구조적으로 중앙화된 부분은 PLC뿐이며, 이는 독립 조직으로 분리 중임

    • Bluesky가 불안하다면 예전 프로젝트 Secure-Scuttlebot(SSB) 을 살펴보길 권함
      콘텐츠 주소 지정과 서명 키 암호화로 Bluesky의 문제를 대부분 해결했었음
      원본 SSB 코드는 2020년 이후 깨졌지만, 내가 유지 중인 포크 버전이 있음
      함께 실험해보고 싶다면 초대도 제공 가능함
    • Bluesky 인스턴스를 직접 운영하기가 여전히 어렵기 때문에, 결과적으로 중앙화로 귀결됨
      사용자 97%가 한 인스턴스에 몰리면 분산 플랫폼이라 보기 어려움
      Mastodon.social이 전체의 40%를 넘는다면 문제로 여길 것과 같음
    • PLC를 독립 조직으로 옮긴다고 해서 탈중앙화가 실현되는 것은 아님

  • Bluesky의 구조를 논할 때는 반드시 Blacksky를 언급해야 함
    그렇지 않다면 AT 프로토콜 생태계에 대한 이해가 부족한 글일 가능성이 높음
    Blacksky는 ATproto의 각 계층을 대체 구현하려는 프로젝트임

    • Blacksky를 잘 알고 있지만, 큰 그림에서는 변화가 없음
      바뀌길 바라지만 현실적으로 영향이 미미함
    • 탈중앙화를 표방했지만, 결국 중앙집중형 서비스를 다시 운영하는 셈임
      이럴 바엔 Movim 같은 XMPP 기반 서비스를 쓰는 게 낫다고 생각함
    • 실제로는 활성 기여자 1명짜리 저장소에 불과함
      그래서 글에서 생략된 듯함
    • 기본값을 바꿔야 한다면 99%의 사용자는 시도하지 않음
      시스템은 결국 가장 쉬운 사용자 여정이 표준이 됨
      미래의 위험 대비 같은 가상의 가치로는 사용자를 움직일 수 없음

  • “트위터가 망하면 떠나면 된다”는 말은 예전에도 들었음
    하지만 실제로는 대부분 떠나지 않았음
    Bluesky가 트위터의 대안이라면, 사람들이 정말로 이동할지가 핵심임
    UI도 거의 동일하고, 전제 자체가 “트위터가 나빠지면 떠난다”는 것이었음

    • 이 말은 사람들이 X에서 Bluesky로 탈중앙화를 위해 이동하지만, 결국 비슷한 락인(lock-in) 을 겪는다는 뜻으로 보임

  • 내 주변은 실제로 트위터를 떠났음
    지금은 친구들이 Bluesky 링크를 공유함으로써 소통함

    • 나는 Bluesky에 아는 사람이 없음
      여전히 X에서 친구들과 활동 중이며, 트위터 시절의 경험을 좋아함

  • ATproto에서는 언제든 데이터를 내보내기(export) 할 수 있음
    앱이 PDS와 상호작용할 때 이미 데이터를 읽기 때문임
    만약 이를 막는다면 ATproto 기능 자체를 막는 셈임

    • 하지만 트위터도 API를 없앴고, 구글도 XMPP 연합을 중단했음
      Bluesky가 프로토콜을 끊더라도 대부분의 사용자는 크게 반발하지 않을 것임
      참고: Google XMPP 지원 종료 안내
    • 백업 서비스를 이용하면 데이터 접근 차단을 피할 수 있음

  • Bluesky는 언제든 자신의 데이터를 다른 인프라로 옮길 수 있게 설계됨
    실제로 Blacksky 같은 그룹이 그렇게 하고 있음
    대부분이 이동하지 않는 건, 현재 Bluesky의 운영 방식에 만족하기 때문임
    그래서 “문제가 뭐냐”는 질문이 나옴

    • 하지만 트위터 때도 대부분은 만족했었음
    • “문제가 뭐냐”는 질문은 핵심을 놓침
      대부분의 사용자는 기본값을 바꾸지 않기 때문에, 결국 중앙집중으로 귀결된다는 게 문제의 요지임

  • 일부는 이미 직접 운영 중이며, Bluesky의 개방성을 긍정적으로 평가함
    왜 이런 구조를 경계해야 하는지 이해하기 어렵다고 말함

    • 하지만 글의 요지는 “문제가 생기면 이미 늦다”는 경고임

  • 진정한 탈중앙화는 결국 모두가 자신의 서버를 운영해야 함
    비용과 유지보수의 부담이 있지만, 그게 대가임
    ATproto는 최소한 데이터 이동성을 보장함
    트위터나 인스타그램에서는 불가능한 일임

    • 이 이동성(portability) 은 ActivityPub의 한계를 보완하려는 시도였음
      AP 진영도 ATproto의 장점을 일부 도입하려 함
      Nostr 쪽은 다소 다른 분위기라, 이번 논의가 그 커뮤니티 전체를 대표하는지는 모르겠음

  • “트위터가 망하면 떠난다”는 말에 나는 실제로 떠났음
    지금은 모든 소셜미디어를 경계하는 입장임

    • 결과적으로 데이터와 사회적 연결을 잃었고, 그 경험이 나를 조심스럽게 만들었음
답변달기