# 소셜 파일시스템

> Clean Markdown view of GeekNews topic #25952. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25952](https://news.hada.io/topic?id=25952)
- GeekNews Markdown: [https://news.hada.io/topic/25952.md](https://news.hada.io/topic/25952.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-19T10:33:06+09:00
- Updated: 2026-01-19T10:33:06+09:00
- Original source: [overreacted.io](https://overreacted.io/a-social-filesystem/)
- Points: 1
- Comments: 1

## Topic Body

- **파일 중심 개인 컴퓨팅**의 개념을 **소셜 컴퓨팅**으로 확장해, 사용자가 만든 모든 콘텐츠를 앱이 아닌 자신이 소유하는 구조로 설명  
- AT 프로토콜을 기반으로, **앱 간 데이터 상호운용**을 가능하게 하는 **분산형 소셜 파일시스템** 개념을 제시  
- 각 사용자는 자신의 ‘everything folder’ 또는 **저장소(repository)** 를 가지며, 게시물·좋아요·팔로우 등이 **JSON 기반 파일(record)** 로 저장  
- **DID(Decentralized Identifier)** 와 `at://` URI 체계를 통해, 호스팅 변경이나 핸들 교체에도 **영구적으로 식별 가능한 링크**를 유지  
- 이 구조는 **앱이 아닌 데이터 중심의 소셜 생태계**를 형성해, 누구나 새로운 앱을 만들어 기존 데이터 위에서 작동시킬 수 있게 함  

---

### 파일 패러다임과 사회적 확장
- 파일은 원래 앱 내부가 아닌 사용자가 제어하는 공간에 존재하며, **앱은 파일을 읽고 쓰는 도구** 역할만 수행  
  - `.svg` 같은 **개방형 파일 포맷**은 여러 앱이 동일한 데이터를 공유하도록 함  
  - “파일 포맷이 곧 API”라는 원칙 아래, 앱 간 상호운용이 가능  
- 이 개념을 소셜 앱에 적용하면, **게시물·팔로우·좋아요** 같은 행위도 파일처럼 다룰 수 있음  
  - 사용자의 모든 온라인 활동을 담은 **‘everything folder’** 가 존재  
  - 앱은 이 폴더의 데이터를 반영하며, 폴더가 **단일 진실의 원천(source of truth)** 역할 수행  

### AT 프로토콜과 소셜 파일시스템
- AT 프로토콜은 이러한 구조를 실제로 구현한 기술로, **Bluesky**, **Leaflet**, **Tangled**, **Semble**, **Wisp** 등이 이를 기반으로 작동  
- 앱은 사용자 데이터를 소유하지 않고, **파일 단위의 분리된 데이터 저장**을 통해 새로운 앱이 기존 데이터를 재활용 가능  
- 모든 사용자의 폴더가 모여 **분산형 소셜 파일시스템**을 구성  

### 레코드와 컬렉션 구조
- 각 게시물은 **JSON 파일(record)** 로 표현되며, 작성자 정보나 파생 데이터(좋아요 수 등)는 포함하지 않음  
  - 예시: `{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }`  
- 파일명은 **타임스탬프 기반 키(record key)** 로 생성되어 충돌을 방지  
- 파일 구조는 **lexicon**이라 불리는 스키마로 정의되며, 각 앱은 자신만의 lexicon을 설계 가능  
  - 예: `com.twitter.post`, `fm.last.scrobble`, `io.letterboxd.review`  
- 동일한 개념이라도 앱마다 다른 lexicon을 가질 수 있으며, **도메인 기반 네임스페이스**로 충돌을 피함  

### 검증과 신뢰
- **Lexicon Police는 존재하지 않음** — 어떤 앱도 다른 앱의 데이터를 강제할 수 없음  
  - 앱은 입력된 데이터를 **검증(validate on read)** 하며, 유효하지 않으면 무시  
- lexicon 변경 시에는 **하위 호환성 유지**가 필수이며, 깨지는 변경은 새 lexicon으로 분리  
- lexicon은 공개적으로 배포 가능하며, DNS를 통해 **도메인 소유 증명**을 수행  

### 링크와 정체성(Identity)
- 사용자가 만든 ‘좋아요’나 ‘답글’은 다른 레코드를 참조해야 하므로, **영구적 링크 체계**가 필요  
- 여러 시도 끝에 **DID(Decentralized Identifier)** 를 사용해 정체성을 확립  
  - `did:plc:6wpkkitfdkgthatfvspcfmjo` 같은 식별자는 변경 불가  
  - 각 DID는 현재 **호스팅, 핸들, 공개키** 정보를 담은 문서로 해석됨  
- `at://` URI는 DID·컬렉션·레코드 키를 조합해 **호스팅 변경에도 깨지지 않는 링크** 제공  
  - 예: `at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5`  

### JSON 하이퍼링크와 관계 표현
- 각 ‘좋아요’, ‘리포스트’, ‘답글’은 다른 레코드를 참조하는 **하이퍼링크형 JSON** 구조  
  - 예: `parent` 필드가 다른 게시물의 `at://` URI를 참조  
- UI의 모든 정보(작성자, 텍스트, 좋아요 수 등)는 **이러한 파일 간 연결**로부터 계산 가능  

### 저장소(Repository)와 데이터 흐름
- 사용자의 ‘everything folder’는 **저장소(repository)** 로 불리며, DID로 식별  
  - 내부에는 여러 **컬렉션(collection)** 과 **레코드(record)** 가 존재  
- 저장소는 어디서나 호스팅 가능하며, 이동해도 링크가 유지  
- 앱은 저장소를 **파일시스템처럼 읽거나**, **스트림(WebSocket)** 으로 구독해 실시간 동기화 가능  
  - 각 커밋은 **서명된 해시 트리(Merkle tree)** 로 검증되어 **데이터 위조 방지**  
  - 중계(relay) 서버는 단순히 이벤트를 재전송하며, 검증 가능한 구조로 신뢰 확보  

### Atmosphere 탐험과 실제 사례
- [pdsls.dev](https://pdsls.dev/)는 DID나 핸들을 입력해 **소셜 파일시스템 탐색기**처럼 작동  
  - 각 컬렉션과 레코드를 직접 조회 가능  
- 예시 앱 **Sidetrail** 은 사용자의 레코드 변경을 실시간 반영하며, 데이터가 **앱이 아닌 저장소에 존재함**을 보여줌  
- **teal.fm Relay** 데모는 실제 API 없이도 `fm.teal.alpha.feed.play` 레코드를 인덱싱해 **음악 재생 기록(scrobble)** 을 시각화  
  - `lex-gql` 도구를 이용해 **Lexicon 기반 GraphQL 쿼리** 실행 가능  
- **Bluesky** 에서는 사용자들이 직접 만든 **커스텀 피드 알고리듬**을 배포 가능  
  - 예: `@spacecowboy17.bsky.social`의 “For You” 피드는 독립적으로 작동하며, **공유 데이터 위에서 제3자가 기능을 개선**할 수 있음  

### 결론
- 소셜 파일시스템은 **앱 중심이 아닌 데이터 중심의 인터넷 구조**를 제시  
- 사용자는 자신의 데이터 저장소를 소유하고, 앱은 그 위에서 반응적으로 작동  
- **“모든 것을 하는 앱”이 아니라, “모든 것이 가능한 생태계”** 로의 전환을 목표로 함

## Comments



### Comment 49461

- Author: neo
- Created: 2026-01-19T10:33:06+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46665839) 
- 앱은 사라질 수 있지만 **파일은 남음**  
  [swyx의 글](https://www.swyx.io/data-outlasts-code-but)을 보면, 오래 지속되는 작업은 결국 파일/데이터 형태로 존재함을 강조함  
  데이터는 권한 없이도 파싱 가능하고, 일부 손상돼도 여전히 유용하지만, 경제적 인센티브는 여전히 코드를 중심으로 움직임  
  표준이 등장해 코드가 데이터를 받아들이고 내보내게 되면 문명 전체에 큰 가치가 생김  
  개발자 생태계가 Google, Microsoft, OpenAI, Anthropic 같은 기업들이 **데이터 표준화에 자발적으로 참여**하도록 유도하는 것이 우리가 가진 가장 강력한 레버 중 하나라고 생각함  
  - “파일이 진실의 원천”이라는 말에 공감함  
    하지만 지금의 앱은 광고 수익에 의존하는 웹사이트 형태라, 그런 구조로 동작할 **유인이 전혀 없음**  
  - Google이나 MS, OpenAI, Anthropic이 원하는 걸 준다고 해서 반드시 보상이 돌아오진 않음  
    Apple만 봐도 표준이 세상을 바꾸지 못하는 경우가 많음  
  - 반가움 :) “indirection 법칙”은 처음 들어봤는데 꽤 재밌는 개념임  

- createdAt 필드가 임의 값이라면, 내가 원하는 대로 **기록을 소급 수정**할 수도 있지 않음?  
  서명(signing)을 통해 생성 시점과 이후 수정 여부를 검증할 방법이 있는지 궁금함  

- POSSE와 AT Protocol은 **상호운용 가능한 마켓플레이스**로 이해할 수 있음  
  Reddit이나 Instagram처럼 사용자 콘텐츠가 상품이고, 주의(attention)가 화폐이며, 플랫폼은 광고나 행동 데이터로 수익을 얻는 구조임  
  하지만 이런 구조는 필연적이지 않음.  
  사용자가 자신의 **소셜 데이터 소유권**을 가지면, 앱은 데이터를 읽는 인터페이스로 전환됨  
  나도 비슷한 모델을 커머스에 적용 중임 — 판매자가 자신의 주문·결제 로직을 직접 호스팅하고, 마켓플레이스는 판매자 API와 직접 통합하는 구조임  
  이렇게 하면 플랫폼 수수료를 줄이고, **가치 창출 주체에게 소유권을 돌려줌**  
  - 프로필에서 openship을 보고 궁금했는데, 직접 확인해보겠음  

- 글이 너무 자세해서 핵심 전달에는 과한 느낌이 있었음  
  그래도 **비유가 훌륭함**. PDS용 파일 브라우저가 있으면 직접 체험해볼 수 있을 듯  
  Bluesky의 PDS는 기본적으로 **공개 파일시스템**이며, Git처럼 복제(replication)가 설계에 포함되어 있음  
  복제는 통제 불가능하지만 자동 백업의 장점도 있음  
  결국 PDS에 올린 건 영구 기록처럼 남으므로 신중해야 함  
  - 글을 쓸 때 머릿속 구조를 그대로 옮기는 게 목표임  
    유용하지만 길다면, 다른 사람이 필요한 부분만 가져가면 됨  
    글 마지막의 [데모 섹션](https://overreacted.io/a-social-filesystem/#up-in-the-atmosphere)에서 실제 파일 매니저 예시를 볼 수 있음  
    “모두가 스크레이퍼가 되는 세상”이라는 표현이 본질임  
  - [pdsfs](https://tangled.org/oppi.li/pdsfs)를 이용하면 FUSE로 PDS를 로컬에 읽기 전용으로 마운트할 수 있음  
  - [pdsls.dev](https://pdsls.dev/)가 그 역할을 잘함. 완전 클라이언트 사이드 앱이고 오픈소스임  
  - atproto 암호화는 어떤 상태인지 궁금함. 단순히 sha256으로 암호화된 데이터만 게시하면 되는지?  
  - ATProto는 아직 완성된 프로토콜이 아니며, **비공개 데이터 지원**도 곧 추가될 예정임  

- “파일” 개념은 이미 구식이라 생각함  
  모든 것을 **해시 기반 blob 데이터**로 취급하면 많은 문제가 사라짐  
  사용자가 원하는 건 앱이 아니라 **기능(capability)** 임  
  예를 들어 “요가 영상을 보는 능력”이나 “지인에게 근황을 공유하는 능력”이지, YouTube나 Bluesky 자체가 아님  
  앱은 이런 기능들을 묶어놓은 형태일 뿐임  
  메시징 앱에서 단어를 검색하고, 그 결과를 바로 대화창 안에서 공유할 수 있는 식의 **맞춤형 워크플로우**가 필요함  
  [PerKeep](https://perkeep.org/)에서 영감을 받았음  
  - 파일시스템은 비유적 표현임  
    “앱과 파일 포맷의 다대다 관계”를 설명하기 위한 은유로 사용했음  
    ATProto의 [repository 구조 설명](https://atproto.com/specs/repository)을 보면, Merkle-tree 기반의 **콘텐츠 주소화 구조**로 되어 있음  
    Lexicon은 앱과 1:1이 아니므로, AT는 이미 **포스트-앱(post-app)** 시대를 향하고 있음  

- 나는 **폐쇄형 플랫폼(walled garden)** 이 소비자 선호의 결과라고 생각함  
  인터넷이 모든 걸 열어버리자, 사람들은 특정 문화나 아이디어 중심의 작은 공간을 원하게 되었음  
  IG나 Snap은 그런 세분화된 그룹 채팅 같은 존재임  
  내 IG 게시물이 HN이나 Truth Social에 자동으로 공유되지 않는 게 오히려 좋음  
  데이터 이식성의 가치가 잘 와닿지 않음. 맥락이 다른 플랫폼 간 교차는 의미가 없다고 느낌  
  - ATProto 앱은 기본적으로 모든 “파일”을 자동 공유하지 않음  
    내가 만든 [Anisota](https://anisota.net)는 Bluesky와 Leaflet의 파일을 모두 지원하도록 설계했음  
    예시로 같은 포스트를 [Bluesky](https://bsky.app/profile/dame.is/post/3m36cqrwfsm24)와 [Anisota](https://anisota.net/profile/dame.is/post/3m36cqrwfsm24)에서 각각 볼 수 있음  
    또 [Aturi](https://aturi.to/anisota.net)라는 프로젝트로 **ATProto 기반 콘텐츠의 범용 링크**를 제공함  
  - Twitter가 인수되었을 때, 내 정체성과 게시물, 좋아요, 소셜 그래프를 그대로 옮길 수 있었다면 좋았을 것임  
    ATProto에서는 같은 Lexicon을 사용하는 앱이라면 **정체성과 데이터의 완전한 이동**이 가능함  
  - 나도 데이터 이식성의 필요성을 잘 모르겠음  
    원본 이미지는 내 로컬에 있고, 각 플랫폼은 그저 다른 표현일 뿐임  
    플랫폼 간의 **의미 없는 통합**은 원치 않음  
  - Truth Social이 연합 코드(federation code)를 제거하지 않았다면, Mastodon 등에서 작성한 게시물이 그대로 나타났을 것임  
  - 서로 다른 앱이 각자의 “분위기”를 유지하는 건 좋은 일임  
    AT는 단지 **상호운용성을 가능하게** 할 뿐, 모든 걸 통합하지 않음  
    예를 들어 Leaflet은 Bluesky 게시물을 인용 추적용으로 가져와 표시함  
    이런 구조 덕분에 제품을 **포크해도 네트워크와 완전히 호환**되며, 경쟁이 활발해짐  
    실제로 [Blacksky](https://bsky.app/profile/rude1.blacksky.team/post/3mcozwdhjos2b)는 Bluesky를 포크해 다른 **모더레이션 정책**을 적용한 사례임  

- Dan이 쓴 글은 항상 흥미로움. 읽다 보면 결국 그가 저자였다는 걸 깨닫게 됨  
  - 고마움 :)  

- **자기 기술형 데이터 모델(self-describing data model)** 에 회의적임  
  ATProto의 “Lexicon만 추가하면 클라이언트가 생긴다”는 주장은 과장된 느낌임  
  실제로는 UI를 만들려면 데이터의 의미를 알아야 하고, Lexicon만으로는 부족함  
  결국 문서 보고 직접 구현하는 것과 다를 바 없음  
  표준화는 좋지만, 굳이 전 세계적으로 복제되는 DB 수준의 문제는 아님  
  그래도 **락인(lock-in)** 을 줄이려는 시도는 높이 평가함  
  다만 Twitter가 겪은 진짜 문제는 정치적 콘텐츠나 스팸 같은 **사회적 요인**이었음  
  - 네가 든 예시는 단순히 관심이 없어서 클라이언트가 없는 경우임  
    하지만 Bento처럼 사랑받던 서비스가 사라지면, 누군가는 그 데이터를 복원하려 할 것임  
    예를 들어 [Blento](https://blento.app/)는 ATProto 기반 Bento 대체 서비스인데, 오픈소스로 누구나 다시 세울 수 있음  
    이런 구조는 **사용자 콘텐츠의 지속성**을 보장하는 의미 있는 진전임  

- “The Unix Programming Environment”를 읽으며, 단순한 도구와 텍스트 파일만으로도 많은 걸 할 수 있음을 깨달음  
  Slack이 파일 중심의 UNIX 스타일로 만들어졌다면 어땠을까 상상하게 됨  
  **단순하고 조합 가능한 시스템**으로 돌아가고 싶음  
  - Unix는 훌륭한 아키텍처 아이디어를 줬지만, 모든 데이터를 **평문 텍스트**로 다룬 건 한계였음  
    사람이 읽기 쉬운 직렬화는 좋지만, 매번 파싱하고 재포맷하는 건 고통스러움  

- 새로운 소셜 플랫폼들이 **분산·연합 환경**에서 공통 프로토콜과 데이터 포맷을 공유하는 개념은 흥미로움  
  하지만 기존 상업 플랫폼을 설득하기는 어려울 것 같음  
  이런 표준이 자리 잡으면 **소셜 마케팅 도구**들이 여러 네트워크를 통합 관리하기 쉬워질 것임  
  다만 현실은 여전히 Facebook, Instagram, TikTok 같은 **폐쇄형 생태계**가 지배하고 있음