atproto에는 '인스턴스'가 없다: 블루스카이를 마스토돈식으로 보면 헷갈리는 이유

• atproto를 볼 때 '블루스카이 인스턴스는 어디 있냐'고 묻는 건 질문 자체가 틀렸다는 게 글의 핵심임

  • 마스토돈에서는 인스턴스가 기본 단위지만, atproto에는 그런 의미의 인스턴스가 없음
  • 글쓴이는 이걸 '마스토돈 뇌로 atproto를 보는 문제'라고 표현함. 꽤 직설적이지만 요지는 정확함

• 비유는 RSS와 구글 리더에서 시작함

  • 블로그 글은 각자의 블로그나 호스팅에 '살고', 구글 리더나 피들리 같은 앱은 그 글들을 모아 보여줬음
  • 중요한 포인트는 호스팅과 집계 앱이 분리돼 있었다는 것임
  • 글이 구글 리더 안에 사는 게 아니라, 구글 리더는 블로그스피어 전체를 비춰주는 투영체에 가까웠음

• 전통적인 소셜 미디어는 이 구조를 박스 하나로 묶어버린 쪽임

  • 페이스북식 모델에서는 데이터, 정체성, 앱, 광고, 네트워크 효과가 한 공간 안에 갇힘
  • 그래서 중앙화, 네트워크 효과 독점, 대체 앱 죽이기 같은 문제가 생김
  • 여기서 '그럼 탈중앙화하자'고 나온 대표적 형태가 마스토돈식 인스턴스 모델임

• 마스토돈 인스턴스는 작게 쪼갠 페이스북/트위터에 가까움

  • 각 커뮤니티가 자기만의 작은 소셜 네트워크를 운영하고, 사용자는 그 안에 들어가서 사는 구조임
  • 그래서 아이디도 단순히 alice가 아니라 alice@instance가 됨
  • 어느 인스턴스 출신인지가 정체성의 일부가 되고, 그 운영자를 신뢰해야 계정과 데이터를 맡길 수 있음

• 마스토돈식 연합에는 꽤 현실적인 함정이 있음

  • 친구가 다른 인스턴스에 있으면 두 인스턴스가 서로 게시물을 전달해야 함. 이게 연합(federation)임
  • 인스턴스 운영자끼리 충돌해서 연합을 끊으면, 갑자기 친구 글이 안 보일 수 있음
  • 내 인스턴스가 내려가면 내 정체성도 같이 흔들림. 팔로워들은 '추상적인 나'가 아니라 '그 인스턴스의 나'를 팔로우한 거라서임
  • 인스턴스 간 연결 화살표는 이론적으로 O(n²)로 늘어날 수 있음. 소규모일 땐 괜찮아도 커지면 신경 쓰이는 지점임

• atproto는 여기서 박스를 지우고 RSS 쪽으로 돌아감

  • 데이터가 사는 호스팅 계층과, 그 데이터를 모아 보여주는 앱 계층을 네트워크 수준에서 분리함
  • 그래서 블루스카이 앱 복제본을 여러 개 띄우는 게 atproto 탈중앙화의 본질이 아님
  • 구글 리더 복제본을 많이 띄운다고 블로그 생태계가 더 건강해지는 건 아닌 것과 같은 얘기임

sequenceDiagram
    participant 사용자
    participant 호스팅
    participant 앱
    participant 릴레이
    사용자->>호스팅: 게시물과 계정 데이터 저장
    앱->>릴레이: 여러 호스팅의 데이터 요청
    릴레이->>호스팅: 공개 데이터 수집
    호스팅-->>릴레이: 게시물과 상태 전달
    릴레이-->>앱: 집계된 데이터 제공
    앱-->>사용자: 피드와 인터페이스 표시

• atproto에서 탈중앙화는 두 가지 방향으로 일어남

  • 하나는 호스팅을 바꾸는 것임. 글쓴이는 실제로 같은 날 Eurosky로 옮겼고, UX 걸림돌 몇 개를 빼면 자동으로 처리됐다고 함
  • 더 과감하게는 Cloudflare에서 자기 데이터를 직접 호스팅하는 것도 가능하다고 말함
  • 다른 하나는 앱을 새로 만들거나 써보는 것임. Tangled, Semble처럼 블루스카이와 별개인 앱도 언급됨

• 그래서 '블루스카이 인스턴스가 몇 개냐'는 지표는 별로 쓸모가 없음

  • atproto에서 중요한 질문은 사람들이 대체 호스팅으로 옮기고 있는지, 새 앱을 만들고 써보고 있는지임
  • 전체 블루스카이 데이터베이스 서버를 여러 개 띄우는 것도 가능은 하지만, 그 자체가 탈중앙화의 핵심은 아님
  • Blacksky처럼 다른 모더레이션 철학 같은 구체적 필요가 있을 때 그런 구성이 생길 수 있음

기술 맥락

• 여기서 중요한 선택은 소셜 네트워크를 '서버 여러 개'로 쪼갤지, 아니면 '데이터 호스팅과 앱'으로 나눌지예요. 마스토돈은 전자에 가깝고, atproto는 후자에 가까워요. 왜냐면 사용자의 정체성과 데이터가 앱 운영자에게 묶이면, 대체 앱이 나와도 진짜 이동성이 생기기 어렵거든요.

• RSS 비유가 강력한 이유는 앱이 데이터를 소유하지 않아도 훌륭한 사용자 경험을 만들 수 있다는 걸 이미 보여줬기 때문이에요. 구글 리더는 블로그 글을 직접 호스팅하지 않았지만, 사용자 입장에서는 웹 전체를 읽는 앱처럼 동작했어요. atproto가 노리는 그림도 이쪽에 가까워요.

• 개발자 관점에서 보면 이건 백엔드 배포 토폴로지 문제가 아니라 API와 데이터 소유권 문제예요. 앱을 바꿔도 내 데이터가 남고, 호스팅을 옮겨도 앱 생태계에 계속 참여할 수 있어야 진짜 이동성이 생겨요.

• 다만 이 구조도 공짜는 아니에요. 릴레이, 캐시, 모더레이션, 인덱싱 같은 공유 인프라가 필요하고, 앱이 전체 네트워크를 빠르게 읽으려면 그 중간 계층의 품질이 중요해져요. 글에서 릴레이 운영 비용이 1년 동안 싸게 유지됐다고 말하는 것도 이 지점이 현실적인 병목인지 따져보는 맥락이에요.