---
title: "atproto에는 '인스턴스'가 없다: 블루스카이를 마스토돈식으로 보면 헷갈리는 이유"
published: 2026-06-19T15:10:02.000Z
canonical: https://jeff.news/article/4126
---
# atproto에는 '인스턴스'가 없다: 블루스카이를 마스토돈식으로 보면 헷갈리는 이유

atproto를 마스토돈처럼 '인스턴스가 몇 개냐'로 평가하면 출발점부터 틀렸다는 글이다. 핵심은 호스팅과 앱을 분리해, 데이터는 앱 밖에 두고 여러 앱이 그 위를 읽는 RSS/구글 리더식 구조에 가깝다는 점이다.

- atproto를 볼 때 '블루스카이 인스턴스는 어디 있냐'고 묻는 건 질문 자체가 틀렸다는 게 글의 핵심임
  - 마스토돈에서는 인스턴스가 기본 단위지만, atproto에는 그런 의미의 인스턴스가 없음
  - 글쓴이는 이걸 '마스토돈 뇌로 atproto를 보는 문제'라고 표현함. 꽤 직설적이지만 요지는 정확함

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

- 전통적인 소셜 미디어는 이 구조를 박스 하나로 묶어버린 쪽임
  - 페이스북식 모델에서는 데이터, 정체성, 앱, 광고, 네트워크 효과가 한 공간 안에 갇힘
  - 그래서 중앙화, 네트워크 효과 독점, 대체 앱 죽이기 같은 문제가 생김
  - 여기서 '그럼 탈중앙화하자'고 나온 대표적 형태가 마스토돈식 인스턴스 모델임

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

> [!NOTE]
> 글쓴이가 말하는 핵심은 '마스토돈이 나쁘다'가 아니라, 마스토돈식 개념으로 atproto를 재단하면 구조를 놓친다는 쪽에 가까움.

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

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

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

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

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

> [!IMPORTANT]
> 이 글의 결론은 단순함. '내 데이터는 앱 밖에 두고, 앱은 그 데이터를 모아 보여주게 하자'는 것임.

---

## 기술 맥락

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

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

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

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

## 핵심 포인트

- atproto는 마스토돈식 인스턴스 모델이 아니라 호스팅과 앱을 네트워크 레벨에서 분리한 구조다.
- 마스토돈에서는 사용자의 정체성이 특정 인스턴스에 묶이고, 인스턴스 간 연합이 끊기면 친구 글도 안 보일 수 있다.
- atproto에서는 호스팅을 옮기거나 새 앱을 만들고 써보는 것이 탈중앙화의 핵심 행동이다.
- '블루스카이 인스턴스 수'를 세는 건 구글 리더 복제본 수를 세며 블로그 생태계를 평가하는 것과 비슷하게 빗나간 질문이다.

## 인사이트

탈중앙화 소셜 논쟁에서 자주 섞이는 '데이터가 어디 사느냐'와 '앱이 무엇을 보여주느냐'를 깔끔하게 분리해주는 글이다. 개발자 입장에서는 atproto를 서버 복제 문제가 아니라 데이터 소유권과 앱 생태계 설계 문제로 보는 게 더 정확함.