무엇인가
Ink & Switch 는 Heroku 공동창업자 Adam Wiggins 등이 세운 독립 산업 연구소다. 2019년 4월, Martin Kleppmann(Designing Data-Intensive Applications 저자)·Adam Wiggins·Peter van Hardenberg·Mark McGranaghan 이 함께 쓴 에세이 Local-first software: You own your data, in spite of the cloud 가 이 연구소에서 나왔고, 같은 해 ACM Onward! 에세이 트랙에도 실렸다. 문제의식은 단순하다 — 클라우드 앱(Google Docs 류)은 협업을 줬지만 그 대가로 데이터의 소유와 통제를 서버 운영사에 넘겼다. 파일은 내 기기에 없고, 서비스가 죽으면 기록도 죽는다.
에세이의 기여는 불평이 아니라 측정 가능한 이상 7개를 세운 것이다:
| # | 이상 (원문) | 뜻 |
|---|---|---|
| 1 | No spinners | 스피너 없음 — 조작이 로컬 데이터에 먼저 적용돼 즉각 반응한다 |
| 2 | Your work is not trapped on one device | 작업이 한 기기에 갇히지 않는다 — 여러 기기 동기화 |
| 3 | The network is optional | 네트워크는 선택 사항 — 오프라인이 정상 상태다 |
| 4 | Seamless collaboration | 실시간 협업 — 클라우드 앱의 장점을 포기하지 않는다 |
| 5 | The Long Now | 긴 지금 — 데이터가 수십 년 뒤에도 열린다(포맷·앱의 수명) |
| 6 | Security and privacy by default | 기본값으로서의 보안·프라이버시 — 종단간 암호화, 서버는 내용을 못 본다 |
| 7 | You retain ultimate ownership and control | 최종 소유권과 통제는 사용자에게 — 내보내기·삭제·이전의 자유 |
이 채점표로 기존 시스템(파일+이메일 첨부, Git+GitHub, Google Docs, Dropbox, 웹앱 …)을 하나씩 평가하는데, 7개를 다 만족하는 것은 없다. 가장 근접한 것이 Git+GitHub — 다만 개발자만 누리는 local-first 라는 진단이다. 유망한 돌파구로 지목한 기술이 CRDT(Conflict-free Replicated Data Type, Shapiro 외 2011)다 — 여러 복제본이 각자 오프라인으로 변경돼도 수학적으로 같은 상태로 수렴하는 자료구조로, "협업은 그 위에"를 중앙 서버 없이 가능하게 한다. 저자들은 CRDT 라이브러리 Automerge 를 만들고 Trello 클론(Trellis) 등 프로토타입으로 실증했다. 이후 이 에세이는 하나의 운동이 됐다 — Automerge·Yjs 같은 라이브러리 생태계와 개발자 커뮤니티가 'local-first' 를 장르 이름으로 굳혔다.
우리 모델과의 접점
우리의 개념 모델 §8과 오프라인 우선·보안(PD6)은 이 채점표에 항목별로 답할 수 있을 만큼 정확히 겹친다:
| 이상 | 우리 쪽 대응 | 비고 |
|---|---|---|
| 1 스피너 없음 | Native 앱 + 로컬 데이터(PD6) | 하이브리드 웹을 넘어서는 최종 목표로 명시 |
| 2 여러 기기 | 옵트인 동기화(PD6) | 기본이 아니라 사용자가 켤 때만 |
| 3 네트워크는 선택 | "기본값 = 완전한 단절"(PD6) | 우리가 더 급진적 — 설치 직후가 오프라인 |
| 4 협업 | 어긋남 — 단독 저자 도구 | 아래 참조 |
| 5 Long Now | 백업(zip) · 책자(md) 산출(§8) | 원인⑦ 회사 수명<기록 수명의 처방 |
| 6 프라이버시 기본 | 원칙 9 기본 비공개 + PD6 "무조건적 프라이버시" | 공개는 명시적 기록(Publication)으로만 |
| 7 소유·통제 | 원칙 9 "기록의 소유는 언제나 한 사람" | 언제든 밖으로 들고 나가는 백업-내보내기 |
어긋남이 하나 있고, 그것이 오히려 우리에게 유리하다. 이상 4(협업)는 local-first 의 기술적 최난점 — CRDT 가 필요한 이유의 대부분이 여기 있다. 그런데 인생 기록은 본질적으로 단일 저자다. 협업 요구를 빼면 동기화는 '여러 사람의 충돌'이 아니라 '한 사람의 여러 기기' 문제로 줄어들고, local-first 의 나머지 여섯 이상은 훨씬 낮은 비용으로 달성된다. 반대 방향의 어긋남도 정직하게 적어야 한다 — 현재 프로토타입은 Supabase 클라우드 DB 위에서 돈다. 개념 검증을 위한 의도된 우회지만, 헌장과 현실 사이의 이 거리가 곧 이행 과제다(생각할 거리 1).
생각할 거리
- 클라우드 프로토에서 local-first 본품으로 — 어느 층부터 뒤집나. 원칙 7(저장보다 파생)은 이행의 숨은 자산이다 — 시제·롤업·순자산 곡선이 전부 클라이언트 계산이라면, 서버가 하는 일은 저장뿐이고 저장소는 갈아끼울 수 있다. 지금 proto 가 파생 계산을 어디서 하는지가 사실상의 이행 가능성 검증이다. PD6 이 방향만 적어 둔 이행 경로(저장소 → 동기화 → 로컬 AI 순?)를 단계로 쪼갤 것.
- 우리에게 CRDT 가 필요한가, 언제부터인가. 단일 저자 + 기기 간 동기화만이라면 최신-쓰기-우선 같은 단순한 규칙으로도 버틴다. 그러나 대면 인터뷰 확장성(PD1 비전)과 대리 기록이 들어오는 순간 두 저자가 한 기록을 동시에 만진다. 사건이 append 중심이라 충돌면이 작다는 점은 이벤트 소싱 / 불변 로그와 같은 논리 — 도입 트리거를 "협업 기능이 생길 때"로 못 박아 둘 것.
- Long Now 는 포맷의 문제다 — zip 안에 무엇이 들어 있어야 하나. 백업(zip)이 있다는 것과 30년 뒤에 열린다는 것은 다르다. 책자가 md 인 것처럼 백업의 정본 포맷도 수명으로 골라야 한다 — 플레인텍스트 회계가 보여 준 플레인텍스트의 수명 대 구조화의 편의(JSON·SQLite) 사이에서. 원인⑦의 처방이 실효가 되는 지점은 바로 이 포맷 결정이다.
- 이상 6과 엔진의 충돌. 종단간 암호화가 기본이면 서버는 내용을 못 보고, 그러면 서버측 AI 가 인터뷰 질문을 고르는 구조(다섯 문법의 '엔진')는 성립하지 않는다. 가장 사적인 데이터인 성찰(§8)일수록 이 충돌이 날카롭다. PD6 의 로컬 AI 를 "있으면 좋은 것"이 아니라 이상 6을 지키기 위한 전제 조건으로 재규정할 것인가.
더 찾아보기
- Kleppmann · Wiggins · van Hardenberg · McGranaghan, Local-first software: You own your data, in spite of the cloud, Ink & Switch, 2019 — inkandswitch.com/local-first. 학술판은 Onward! 2019 에 실렸다.
- CRDT 원전: Shapiro 외, "Conflict-free Replicated Data Types", 2011 — 검색:
Shapiro CRDT 2011. 구현체는 automerge.org · 검색:Yjs CRDT. - 이후의 운동: 검색:
local-first software community·Local-First Conf— 에세이가 장르가 된 뒤의 생태계. - 같은 장의 이웃: Solid(같은 소유 사상의 웹 표준 진영 — 데이터 팟과 앱의 분리), 라이프로깅의 계보(수집의 계보 — 소유의 계보와 대비).
내 생각
이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.