▲

소셜 파일시스템

 (overreacted.io)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • 파일 중심 개인 컴퓨팅의 개념을 소셜 컴퓨팅으로 확장해, 사용자가 만든 모든 콘텐츠를 앱이 아닌 자신이 소유하는 구조로 설명
  • 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·컬렉션·레코드 키를 조합해 호스팅 변경에도 깨지지 않는 링크 제공

JSON 하이퍼링크와 관계 표현

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

저장소(Repository)와 데이터 흐름

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

Atmosphere 탐험과 실제 사례

  • 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자가 기능을 개선할 수 있음

결론

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

  • 앱은 사라질 수 있지만 파일은 남음
    swyx의 글을 보면, 오래 지속되는 작업은 결국 파일/데이터 형태로 존재함을 강조함
    데이터는 권한 없이도 파싱 가능하고, 일부 손상돼도 여전히 유용하지만, 경제적 인센티브는 여전히 코드를 중심으로 움직임
    표준이 등장해 코드가 데이터를 받아들이고 내보내게 되면 문명 전체에 큰 가치가 생김
    개발자 생태계가 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에 올린 건 영구 기록처럼 남으므로 신중해야 함

    • 글을 쓸 때 머릿속 구조를 그대로 옮기는 게 목표임
      유용하지만 길다면, 다른 사람이 필요한 부분만 가져가면 됨
      글 마지막의 데모 섹션에서 실제 파일 매니저 예시를 볼 수 있음
      “모두가 스크레이퍼가 되는 세상”이라는 표현이 본질임
    • pdsfs를 이용하면 FUSE로 PDS를 로컬에 읽기 전용으로 마운트할 수 있음
    • pdsls.dev가 그 역할을 잘함. 완전 클라이언트 사이드 앱이고 오픈소스임
    • atproto 암호화는 어떤 상태인지 궁금함. 단순히 sha256으로 암호화된 데이터만 게시하면 되는지?
    • ATProto는 아직 완성된 프로토콜이 아니며, 비공개 데이터 지원도 곧 추가될 예정임

  • “파일” 개념은 이미 구식이라 생각함
    모든 것을 해시 기반 blob 데이터로 취급하면 많은 문제가 사라짐
    사용자가 원하는 건 앱이 아니라 기능(capability) 임
    예를 들어 “요가 영상을 보는 능력”이나 “지인에게 근황을 공유하는 능력”이지, YouTube나 Bluesky 자체가 아님
    앱은 이런 기능들을 묶어놓은 형태일 뿐임
    메시징 앱에서 단어를 검색하고, 그 결과를 바로 대화창 안에서 공유할 수 있는 식의 맞춤형 워크플로우가 필요함
    PerKeep에서 영감을 받았음

    • 파일시스템은 비유적 표현임
      “앱과 파일 포맷의 다대다 관계”를 설명하기 위한 은유로 사용했음
      ATProto의 repository 구조 설명을 보면, Merkle-tree 기반의 콘텐츠 주소화 구조로 되어 있음
      Lexicon은 앱과 1:1이 아니므로, AT는 이미 포스트-앱(post-app) 시대를 향하고 있음

  • 나는 폐쇄형 플랫폼(walled garden) 이 소비자 선호의 결과라고 생각함
    인터넷이 모든 걸 열어버리자, 사람들은 특정 문화나 아이디어 중심의 작은 공간을 원하게 되었음
    IG나 Snap은 그런 세분화된 그룹 채팅 같은 존재임
    내 IG 게시물이 HN이나 Truth Social에 자동으로 공유되지 않는 게 오히려 좋음
    데이터 이식성의 가치가 잘 와닿지 않음. 맥락이 다른 플랫폼 간 교차는 의미가 없다고 느낌

    • ATProto 앱은 기본적으로 모든 “파일”을 자동 공유하지 않음
      내가 만든 Anisota는 Bluesky와 Leaflet의 파일을 모두 지원하도록 설계했음
      예시로 같은 포스트를 Bluesky와 Anisota에서 각각 볼 수 있음
      또 Aturi라는 프로젝트로 ATProto 기반 콘텐츠의 범용 링크를 제공함
    • Twitter가 인수되었을 때, 내 정체성과 게시물, 좋아요, 소셜 그래프를 그대로 옮길 수 있었다면 좋았을 것임
      ATProto에서는 같은 Lexicon을 사용하는 앱이라면 정체성과 데이터의 완전한 이동이 가능함
    • 나도 데이터 이식성의 필요성을 잘 모르겠음
      원본 이미지는 내 로컬에 있고, 각 플랫폼은 그저 다른 표현일 뿐임
      플랫폼 간의 의미 없는 통합은 원치 않음
    • Truth Social이 연합 코드(federation code)를 제거하지 않았다면, Mastodon 등에서 작성한 게시물이 그대로 나타났을 것임
    • 서로 다른 앱이 각자의 “분위기”를 유지하는 건 좋은 일임
      AT는 단지 상호운용성을 가능하게 할 뿐, 모든 걸 통합하지 않음
      예를 들어 Leaflet은 Bluesky 게시물을 인용 추적용으로 가져와 표시함
      이런 구조 덕분에 제품을 포크해도 네트워크와 완전히 호환되며, 경쟁이 활발해짐
      실제로 Blacksky는 Bluesky를 포크해 다른 모더레이션 정책을 적용한 사례임

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

    • 고마움 :)

  • 자기 기술형 데이터 모델(self-describing data model) 에 회의적임
    ATProto의 “Lexicon만 추가하면 클라이언트가 생긴다”는 주장은 과장된 느낌임
    실제로는 UI를 만들려면 데이터의 의미를 알아야 하고, Lexicon만으로는 부족함
    결국 문서 보고 직접 구현하는 것과 다를 바 없음
    표준화는 좋지만, 굳이 전 세계적으로 복제되는 DB 수준의 문제는 아님
    그래도 락인(lock-in) 을 줄이려는 시도는 높이 평가함
    다만 Twitter가 겪은 진짜 문제는 정치적 콘텐츠나 스팸 같은 사회적 요인이었음

    • 네가 든 예시는 단순히 관심이 없어서 클라이언트가 없는 경우임
      하지만 Bento처럼 사랑받던 서비스가 사라지면, 누군가는 그 데이터를 복원하려 할 것임
      예를 들어 Blento는 ATProto 기반 Bento 대체 서비스인데, 오픈소스로 누구나 다시 세울 수 있음
      이런 구조는 사용자 콘텐츠의 지속성을 보장하는 의미 있는 진전임

  • “The Unix Programming Environment”를 읽으며, 단순한 도구와 텍스트 파일만으로도 많은 걸 할 수 있음을 깨달음
    Slack이 파일 중심의 UNIX 스타일로 만들어졌다면 어땠을까 상상하게 됨
    단순하고 조합 가능한 시스템으로 돌아가고 싶음

    • Unix는 훌륭한 아키텍처 아이디어를 줬지만, 모든 데이터를 평문 텍스트로 다룬 건 한계였음
      사람이 읽기 쉬운 직렬화는 좋지만, 매번 파싱하고 재포맷하는 건 고통스러움

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

답변달기