S9 · REF제 7 장(산출) · 원칙 8·9 대응

Solid

Tim Berners-Lee

웹을 만든 사람이 웹의 중앙집중화를 되돌리려 내놓은 답 — 개인 데이터 팟(pod)과 앱의 분리. 데이터는 내가 고른 저장소에 살고, 앱은 허락을 받아 다녀가는 손님이 된다. "기록은 앱보다 오래 산다"는 소유 사상을 개별 제품이 아니라 웹 표준으로 만들려는 진영이다.

무엇인가

Tim Berners-Lee 는 1989년 웹을 제안한 당사자다. 그가 2010년대 중반 MIT CSAIL 에서 시작한 Solid(어원은 Social Linked Data)는, 자신이 만든 웹이 소수 플랫폼에 데이터가 갇히는 구조로 굳어진 데 대한 설계자 본인의 교정 시도다. 2016년 WWW 학회에서 플랫폼 데모 논문으로 공개됐고, 2018년에는 상용화를 위해 회사 Inrupt 를 공동 창업하며 "One Small Step for the Web…"이라는 글로 방향을 선언했다.

핵심 아이디어는 하나다. 지금의 앱은 코드와 데이터가 한 몸이라, 앱을 떠나면 데이터도 잃는다. 이 둘을 떼어 놓자. 사진·일정·글·건강 기록 같은 내 데이터는 내가 고른 팟에 저장되고(직접 호스팅하거나 팟 제공자를 골라 쓴다), 앱은 팟에 접근 권한을 요청하는 클라이언트일 뿐이다. 앱을 갈아타도 데이터는 제자리에 있고, 같은 데이터 위에 여러 앱이 공존한다. 앱은 데이터 인질이 아니라 UX 로 경쟁하게 된다는 논리다.

구성 요소비고
PodPersonal Online Datastore — 개인 데이터 저장소파일시스템처럼 리소스를 담는 내 웹 공간
WebIDURI 하나로 표현되는 전역 신원사람·조직이 웹 주소로 식별된다
Solid Protocol팟 읽기·쓰기 규약HTTP + Linked Data Platform 위에 얹힌 표준
WAC / ACP접근 제어 — 누가 어느 리소스를 읽고 쓰나공유·권한 회수가 팟 차원에서 이뤄진다
Linked Data (RDF)공유 어휘로 적힌 데이터앱들이 같은 데이터를 이해하기 위한 전제

현황은 두 갈래로 읽어야 한다. 표준화는 전진했다 — W3C Solid 커뮤니티 그룹을 거쳐 2024년 W3C 에 관련 워킹그룹(Linked Web Storage)이 발족했고, 공공 부문 파일럿(벨기에 플란데런 정부의 시민 데이터 인프라 등)이 이어졌다. 반면 대중 보급은 니치에 머문다. 여러 앱이 한 데이터를 이해하려면 공유 어휘(RDF 온톨로지)에 합의해야 하는데 이 비용이 크고, 데이터·앱·팟 제공자가 분리된 구조는 일반 사용자에게 설명하기 어렵다. 사상의 설득력과 채택의 어려움이 함께 있는 프로젝트다.

우리 모델과의 접점

우리의 개념 모델이 같은 요구에 둔 답은 원칙 9(기본 비공개 — 기록의 소유는 언제나 한 사람)와 §8 산출(책자 md · 백업 zip — 언제든 밖으로 들고 나갈 수 있다)이다. Solid 는 이 소유 사상의 웹 표준 진영이고, 이웃 항목 Local-first software는 같은 사상의 엔지니어링 진영이다. 세 답의 차이는 데이터의 거처에 있다:

물음SolidLocal-first우리(현재)
데이터는 어디에내가 고른 팟(내 서버)내 기기 — 서버는 동기화 보조운영 DB + 반출물(zip·md)
앱이 사라지면데이터는 팟에 남는다데이터는 기기에 남는다반출물이 남는다
소유의 보장 방식아키텍처 — 분리를 강제아키텍처 — 로컬을 원본으로약속 + 반출 — 구조 아닌 산출로
상호운용공유 어휘(RDF)로 여러 앱포맷별 — 표준 없음단일 앱 + 문서화된 반출 포맷

대응보다 유익한 어긋남 두 가지:

  • 사람의 지위. Solid 의 WebID 는 모든 사람을 전역 신원 — 사실상 계정 — 으로 만든다. 우리는 반대로 갔다: 등장인물(Person)은 계정이 아니라 내 기록 속 존재다(§2). 아버지의 동의나 가입 없이도 아버지와의 제주가 기록되는 것은, 기록 전체가 한 사람에게 귀속된다는 원칙 9의 직접 귀결이다. Solid 는 여러 주체의 데이터 주권을 동시에 푸는 대신 신원 인프라를 요구하고, 우리는 한 사람의 기록으로 범위를 좁혀 그 비용을 치르지 않는다.
  • 분리의 층위. Solid 는 데이터-앱 분리를 아키텍처로 강제하고, 그 대가로 공유 어휘와 UX 통합의 난제를 떠안았다. 우리의 렌즈 구조(§5)는 정확히 그 반대편에서 성립한다 — 중심 객체가 사건 하나라는 단일하고 의견이 강한 스키마이기에 여정·수첩·여비가 같은 데이터를 즉시 상호 반영한다. 우리는 분리 사상을 아키텍처가 아니라 반출 보장의 수준에서 취했다.
Solid 에서 가져올 것은 팟이 아니라 합격선이다. "기록은 앱보다 오래 산다"를 구조로 만든 진영이 있다는 사실은, 우리의 백업(zip)·책자(md)가 부가 기능이 아니라 소유 원칙의 이행 장치임을 못박는다. 판정 기준도 그들에게서 빌릴 수 있다 — 이 앱이 내일 사라져도, 반출물만으로 한 사람의 여정이 다른 도구에서 읽히는가.

생각할 거리

  1. 백업 포맷은 사실상의 팟이다. 팟 없는 우리 구조에서 소유 원칙(원칙 9)의 실체는 반출물이다. 그렇다면 백업 zip 의 내부 구조와 책자 md 는 앱과 독립적으로 문서화된 포맷 — 스키마 설명이 동봉되고, 범용 도구로 열리는 — 이어야 하지 않나. 산출(§8, 다섯 문법의 '산출')의 완성 기준을 "내보내진다"에서 "앱 없이 읽힌다"로 올릴지.
  2. 등장인물의 계정화 압력. 대면 인터뷰 확장성(비전 PD1)이 커지면 두 사람이 같은 사건을 각자 기록하는 날이 온다. Solid 라면 WebID 로 풀 문제를, 우리는 계정 연결 없이 — 각자의 기록 사이를 참조(Link, §4) 수준으로만 잇는 방식으로 — 풀 수 있는가. 원칙 9를 지키면서 상호 참조를 허용하는 최소 구조는 무엇인가.
  3. 반출물의 어휘. Solid 상호운용의 병목은 공유 어휘였다. 우리는 개념은 고정하되 호칭은 사용자의 것(원칙 8)이라 내부 일관성은 있지만, 반출된 사건·성분이 바깥 세계에서 의미를 가지려면 표준 어휘로의 매핑(예: schema.org 의 Event 류)이 필요한지 — 아니면 자체 스키마 문서로 충분한지. 족보 데이터 모델이 같은 문제를 도메인 표준으로 푼 선례다.
  4. 회사 수명보다 긴 기록. 원인⑦ 회사 수명<기록 수명에 대한 세 진영의 답 — Solid 는 "회사 밖에", Local-first는 "기기 안에", 우리는 "운영 DB + 반출". 우리의 답이 약속에 그치지 않으려면 어느 층까지 구조화해야 하나 — 자동 주기 백업, 반출 포맷의 버전 보장, 최소한의 로컬 사본 중 무엇이 먼저인가.

더 찾아보기

  • solidproject.org — 공식 사이트. 사상 요약과 프로토콜 명세의 입구.
  • Tim Berners-Lee, "One Small Step for the Web…"(2018) — Inrupt 창업과 함께 나온 방향 선언. 검색: Berners-Lee "One Small Step for the Web"
  • Mansour 외, WWW 2016 데모 논문 — 플랫폼 첫 공개. 검색: Solid platform social web applications WWW 2016
  • 표준화·공공 채택 현황 — 검색: W3C Linked Web Storage · Solid pod Flanders athumi
  • 같은 장의 이웃: Local-first software(같은 사상의 엔지니어링 진영), 라이프로깅의 계보(수집의 계보 — 소유와는 다른 축의 문제).

내 생각

이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.