- 클라우드 앱은 협업과 다중 기기 접근성을 크게 개선했지만, 데이터의 권위 있는 사본이 서버에 있어 사용자의 소유권과 통제권이 약해짐
- 로컬-퍼스트 소프트웨어는 노트북·태블릿·휴대폰의 로컬 저장소를 주된 데이터 사본으로 두고, 서버는 동기화·백업을 돕는 보조 역할로 제한함
- 이 접근은 빠른 응답, 오프라인 작업, 여러 기기 동기화, 실시간 협업, 장기 보존, 기본 보안·프라이버시를 동시에 추구함
- 파일, 이메일, 웹 앱, Dropbox류 동기화, Git, Firebase, CloudKit, Realm, CouchDB는 각각 일부 장점이 있지만 협업과 데이터 소유권을 모두 만족시키지는 못함
- CRDT와 Automerge 기반 프로토타입은 가능성을 보였지만, 성능, 네트워크 통신, P2P 안정성, 분산 문서 UI 같은 과제가 남아 있음
클라우드 협업과 데이터 소유권의 충돌
- Google Docs, Figma, Slack, Trello 같은 클라우드 앱은 브라우저나 모바일 앱으로 접근하고 데이터를 서버에 저장함
- 이 모델은 실시간 협업과 어디서나 접근 가능한 장점을 제공하지만, 모든 데이터 접근이 서버를 거쳐야 함
- 서버가 허용하는 작업만 가능함
- 서비스가 중단되면 소프트웨어뿐 아니라 그 소프트웨어로 만든 데이터 접근도 막힐 수 있음
- 데이터를 내보낼 수 있어도 서버 없이 같은 소프트웨어를 계속 실행하기 어려움
- 반대로 오래된 로컬 앱은 로컬 디스크의 파일을 읽고 쓰기 때문에 사용자가 백업, 장기 보관, 다른 프로그램으로 조작, 삭제를 직접 통제할 수 있음
- 핵심 긴장은 클라우드는 협업을 주고, 로컬 앱은 소유권을 준다는 점이며, 로컬-퍼스트는 둘을 함께 얻으려는 설계 방향임
로컬-퍼스트 소프트웨어의 기본 모델
- 로컬-퍼스트 소프트웨어는 원격 데이터센터의 서버보다 로컬 저장소와 로컬 네트워크를 우선함
- 클라우드 앱에서는 서버 데이터가 권위 있는 원본이고, 클라이언트의 데이터는 서버에 종속된 캐시에 가까움
- 로컬-퍼스트 앱에서는 각 기기의 로컬 데이터가 주된 사본이며, 서버는 여러 기기 접근과 백업을 돕는 보조 사본을 가짐
- 이 관점 전환은 성능, 오프라인 사용, 장기 보존, 프라이버시, 사용자 통제권에 직접 영향을 줌
로컬-퍼스트의 7가지 이상
-
1. 스피너 없는 즉각적인 작업
- 클라우드 앱은 데이터 수정과 많은 조회가 서버 왕복을 필요로 하므로 지연이 생김
- Optimistic UI는 요청이 끝난 것처럼 보여 지연을 숨기지만, 네트워크 오류가 나면 다시 지연이 드러남
- 로컬-퍼스트 앱은 주된 데이터가 로컬 기기에 있어 사용자 입력이 서버 응답을 기다릴 필요가 줄어듦
- 동기화는 백그라운드에서 진행되고, 앱은 입력에 거의 즉각 반응할 수 있음
-
2. 한 기기에 갇히지 않는 작업
- 사용자는 스마트폰에서 아이디어를 캡처하고, 태블릿에서 정리하고, 노트북에서 문서화하는 식으로 여러 기기를 오감
- 로컬-퍼스트 앱도 각 기기에 데이터를 두면서 모든 작업 기기 간 동기화가 필요함
- 대부분의 기기 간 동기화 서비스는 서버에도 사본을 저장해 오프사이트 백업 역할을 함
- 여러 사람이 같은 파일을 동시에 편집하면 충돌이 생길 수 있어 협업 설계가 중요해짐
-
3. 선택 사항인 네트워크
- 비행기, 터널, 엘리베이터, 주차장, 불안정한 WiFi, 로밍 비용, 개발도상국·농촌의 불완전한 인터넷 환경은 오프라인 작업 필요성을 만듦
- 클라우드 앱은 일반적으로 오프라인에서 약하고, 서버 중심 모델에 오프라인 지원을 뒤늦게 붙이는 일도 어려움
- 로컬-퍼스트 앱은 각 기기의 로컬 파일시스템에 주된 데이터를 저장하므로 오프라인에서도 읽고 쓸 수 있음
- 이후 네트워크가 가능할 때 다른 기기와 동기화하며, 동기화는 인터넷뿐 아니라 Bluetooth나 로컬 WiFi로도 가능함
- 좋은 오프라인 경험에는 브라우저 탭보다 로컬에 설치된 실행 파일이 더 적합함
-
4. 동료와의 원활한 협업
- 오래된 로컬 파일 기반 소프트웨어는 여러 사람이 동시에 같은 파일을 편집하면 충돌이 생기기 쉬움
- Google Docs 같은 클라우드 앱은 여러 사용자가 동시에 문서를 편집하고 충돌을 신경 쓰지 않는 경험을 대중화함
- 로컬-퍼스트의 이상은 오늘날 최고의 클라우드 앱과 같거나 더 나은 실시간 협업을 지원하는 것임
- 한 사용자가 변경을 제안하고 다른 사용자가 검토해 선택적으로 반영하는 흐름도 중요함
- Google Docs의 suggesting mode
- GitHub의 pull request
-
5. Long Now: 장기 접근성
- 데이터 소유권의 중요한 측면은 미래에도 오랫동안 접근할 수 있어야 한다는 점임
- 오래된 로컬 앱은 데이터와 실행 가능한 소프트웨어 사본이 있으면 계속 사용할 수 있고, 오래된 운영체제나 컴퓨터도 가상머신·에뮬레이터로 실행할 수 있음
- 저장 매체가 바뀌어도 파일을 새 매체로 복사할 수 있음
- 클라우드 앱은 서비스가 계속 제공된다는 전제에 의존하며, 서비스 종료, 데이터 손실, 가격·기능 변경, 원치 않는 강제 업그레이드에 취약함
- 로컬-퍼스트 소프트웨어는 데이터와 그 데이터를 읽고 수정하는 소프트웨어가 로컬에 저장되므로 장기 보존 가능성이 커짐
- plain text, JPEG, PDF는 오래 읽힐 가능성이 높고, 미국 의회도서관은 데이터셋 보존 형식으로 XML, JSON, SQLite를 권장함
-
6. 기본값으로서의 보안과 프라이버시
- 클라우드 앱은 모든 사용자의 데이터를 중앙 데이터베이스에 모으므로 공격자에게 매력적인 표적이 됨
- 내부 직원이나 서버에 접근한 해커가 데이터를 읽거나 조작할 수 있고, 데이터 침해도 흔한 위험으로 남음
- Google Drive 약관은 자동화 시스템이 맞춤 검색 결과, 스팸·멀웨어 탐지를 위해 사용자 콘텐츠를 분석한다고 밝힘
- 의료인, 탐사보도 기자, 정부·외교 관계자처럼 민감한 데이터를 다루는 사용자는 클라우드 앱 사용이 규제·기밀 의무와 충돌할 수 있음
- 로컬-퍼스트 앱은 각 로컬 기기에 사용자 자신의 데이터만 저장하고, 서버에는 종단 간 암호화된 사본만 둘 수 있음
- iMessage, WhatsApp, Signal, Keybase, Tarsnap은 종단 간 암호화나 암호화된 파일 공유·백업의 사례로 제시됨
-
7. 최종 소유권과 통제권
- 클라우드 앱에서는 서비스 제공자가 사용자 접근을 제한할 수 있음
- 2017년 10월 일부 Google Docs 사용자는 자동 시스템이 문서를 악성으로 잘못 표시해 문서 접근이 차단됨
- 여기서 소유권은 지식재산권이 아니라 사용자 행위성, 자율성, 데이터 통제권을 뜻함
- 로컬-퍼스트 소프트웨어에서는 데이터를 구성하는 바이트가 사용자의 기기에 있으므로 임의 방식으로 처리할 자유가 있음
- 데이터 소유권에는 백업 유지, 데이터 손실 방지, 랜섬웨어 대응, 파일 아카이브 관리 책임도 따름
- 로컬-퍼스트가 반드시 오픈소스여야 하는 것은 아니며, 상용·폐쇄형 소프트웨어도 파일 사용을 인위적으로 제한하지 않으면 이상에 가까워질 수 있음
- 인위적 제한의 예로 인쇄를 막는 PDF, 복사·붙여넣기를 방해하는 eBook 리더, 미디어 파일 DRM이 제시됨
기존 저장·공유 모델의 한계
-
파일과 이메일 첨부
- 전통적인 파일은 오프라인 보기·편집, 사용자 통제, 백업, 장기 보존, 빠른 접근에 강함
- 여러 기기 접근에는 이메일, USB, NAS/NFS/FTP/rsync, Dropbox류 파일 동기화, Git 같은 방식이 필요함
- 이메일 첨부는 이해하기 쉽고 신뢰 가능하며, 6개월 뒤에도 첨부파일이 원래 형태로 남아 있음
- 약점은 협업임
- 보통 한 번에 한 사람만 파일을 수정할 수 있음
- 여러 사람이 편집하면 수동 병합이 필요함
Budget draft 2 (Jane's version) final final 3.xls같은 파일명 혼란이 생김
- 로컬-퍼스트 아이디어를 적용하려는 앱은 plain text, PDF, PNG, JPEG처럼 널리 지원되는 형식으로 내보내기부터 제공할 수 있음
-
웹 앱
- Google Docs, Trello, Figma, Pinterest 같은 웹 앱은 브라우저나 모바일 앱이 얇은 클라이언트이고 데이터 저장소가 서버에 있음
- 웹 앱은 실시간 협업의 표준을 세웠고, 팀 작업에서 최신 버전을 어디서나 볼 수 있다는 장점이 큼
- 반대로 소유권과 통제권은 크게 줄어듦
- 서버 데이터가 기준이고 클라이언트 데이터는 캐시에 가까움
- 네트워크가 잠깐 끊겨도 작업 중간에 접근이 막힐 수 있음
- Google Docs offline plugin 같은 제한적 오프라인 지원은 서버 중심 아키텍처에 사후적으로 붙인 형태에 가까움
- Milanote와 Figma 같은 설치형 데스크톱 클라이언트도 본질적으로 재포장된 브라우저라 네트워크 장애·서버 중단·서비스 종료 상황에서 한계가 드러남
-
Dropbox, Google Drive, Box, OneDrive
- Dropbox, Google Drive, Box, OneDrive는 데스크톱에서 지정 폴더를 감시하고 변경된 파일을 다른 컴퓨터로 복사함
- 로컬 파일시스템을 사용하므로 빠르고 오프라인 작업이 가능하며, 동기화 서비스가 종료돼도 로컬 디스크의 파일은 남음
- 하드디스크 장애가 생기면 앱을 설치하고 동기화를 기다려 복원할 수 있어 장기성·통제권 측면에서 장점이 있음
- 모바일 iOS·Android에서는 전체 폴더를 동기화하지 않고 서버에서 파일을 하나씩 가져오는 얇은 클라이언트 모델에 가까움
- “Make available offline” 옵션은 미리 지정해야 하고, 번거로우며, 앱이 열려 있을 때만 동작함
- 가장 약한 지점은 실시간 협업임
- 같은 파일이 두 기기에서 수정되면 수동 병합이 필요한 충돌이 생김
- 임의 파일 형식을 동기화할 수 있다는 점은 호환성 장점이지만, 형식별 병합을 할 수 없다는 약점도 됨
-
Git과 GitHub
- Git과 GitHub는 소스 코드 협업에 주로 쓰이며, 현재 로컬-퍼스트에 가장 가까운 소프트웨어 패키지로 평가됨
- Git 저장소는 로컬 파일시스템의 주된 데이터 사본이며 서버에 종속되지 않음
- 완전한 오프라인 작업, 빠른 동작, 사용자 통제, 장기 보존 적합성을 제공함
- GitHub는 협업, 여러 기기 접근, 백업과 아카이브 위치를 제공하지만 저장소를 암호화하지 않음
- Git의 큰 약점은 두 가지임
- Google Docs, Trello, Figma처럼 세밀한 실시간 자동 병합 협업이 없음
- 코드와 줄 기반 텍스트에 최적화되어 있고, 다른 파일 형식은 의미 있게 편집·병합하기 어려운 바이너리 blob으로 다뤄짐
- 많은 소프트웨어 엔지니어가 Cloud9, Repl.it, Colaboratory 같은 클라우드 기반 편집기·실행환경을 꺼리는 이유로 “느리다”, “신뢰하지 않는다”, “코드를 로컬 시스템에 두고 싶다”를 든다는 점은 로컬-퍼스트 동기와 맞닿아 있음
개발자 인프라 관점의 선택지
-
얇은 클라이언트 웹 앱
- Rails, Django, PHP, Node.js 서버가 SQL 또는 NoSQL 데이터베이스에 데이터를 저장하고 HTTPS로 웹 페이지를 제공하는 모델임
- 설치가 필요 없고 사용자는 URL만 방문하면 되며, 데이터 관리 책임은 배포한 엔지니어링·DevOps 팀에 있음
- Meteor, ShareDB, Pusher, Ably, WebSocket은 웹 앱에 실시간 협업 기능을 더 쉽게 넣게 해줌
- 사용자 행동마다 서버 요청이 필요하면 느려지고, 클라이언트 JavaScript로 왕복 시간을 숨겨도 불안정한 인터넷에서는 쉽게 깨짐
- manifest, localStorage, service worker, Progressive Web Apps 같은 노력에도 웹 앱 아키텍처는 근본적으로 서버 중심임
- 브라우저에서 쿠키를 지우면 로컬 저장소 데이터도 함께 삭제되는 경우가 많아 장기적으로 중요한 데이터를 저장하기에 적합하지 않음
- 오픈소스 웹 앱을 사용자가 직접 호스팅하면 일부 특성을 개선할 수 있지만, 대부분의 사용자가 시스템 관리자가 되기를 원하지 않으므로 자가 호스팅은 대다수에게 현실적 선택지가 아님
-
로컬 저장소를 쓰는 모바일 앱
- iOS와 Android 앱은 바이너리를 다운로드해 로컬에 설치하지만, Twitter, Yelp, Facebook 같은 많은 앱은 서버가 있어야 동작하는 얇은 클라이언트임
- SQLite, Core Data, 일반 파일 같은 지속성 계층으로 먼저 로컬 기기에 데이터를 저장하는 앱은 로컬-퍼스트 이상에 더 가까움
- Clue와 Things는 단일 사용자 앱으로 시작한 뒤 기기 간 동기화나 공유를 위해 클라우드 백엔드를 추가한 사례임
- 이런 두꺼운 클라이언트 앱은 서버 동기화가 백그라운드에서 이뤄지므로 빠르고 오프라인에서도 동작함
- 여러 기기나 여러 협업 사용자가 데이터를 수정하면 난도가 올라감
- 모바일 앱 개발자는 보통 최종 사용자 앱 개발 전문가이지 분산 시스템 전문가는 아님
- 임시 diff·merge·충돌 해결 알고리듬은 신뢰성이 낮고 취약한 경우가 많음
-
Firebase, CloudKit, Realm
- Firebase는 로컬 기기 데이터베이스, 클라우드 데이터베이스 서비스, 양쪽 동기화를 결합한 모바일 BaaS임
- Firebase는 여러 기기 공유와 오프라인 사용을 지원하지만, 독점 호스팅 서비스라 프라이버시와 장기성 점수가 낮음
- Parse는 Facebook에 인수된 뒤 2017년에 종료되어, 이에 의존하던 앱들이 다른 백엔드로 이동해야 했음
- Firebase 콘솔은 개발자에게 데이터를 보고 수정·삭제하는 좋은 경험을 제공하지만, 사용자는 그에 상응하는 데이터 접근·조작·관리 수단을 갖지 못함
- Apple CloudKit은 iOS와 Mac에 한정할 수 있는 앱에 Firebase와 비슷한 경험을 제공함
- 키-값 저장소와 동기화
- 좋은 오프라인 기능
- 플랫폼 내장으로 계정 생성·로그인 번거로움 감소
- Realm은 iOS 로컬 지속성 라이브러리로 인기를 얻었고, Realm Object Server는 오픈소스·자가 호스팅이 가능해 서비스 종속 위험을 줄임
-
CouchDB
- CouchDB는 여러 머신이 완전한 데이터베이스 사본을 가지고 각 복제본이 독립적으로 변경을 만들 수 있는 multi-master replication 접근으로 주목받음
- Cloudant는 호스팅 버전이고, PouchDB와 Hoodie는 같은 동기화 프로토콜을 쓰면서 최종 사용자 기기에서 실행되도록 설계됨
- 철학적으로 CouchDB는 로컬-퍼스트 원칙과 가깝지만, 동시에 변경된 데이터는 애플리케이션 코드가 명시적으로 충돌 해결해야 함
- Google Docs처럼 모든 키 입력이 개별 변경이 될 수 있는 세밀한 협업 앱에서는 올바른 충돌 해결 코드를 작성하기 어려움
- 널리 채택되지 못한 이유로 사용자별 별도 DB 확장성, iOS·Android 네이티브 앱 내 JavaScript 클라이언트 임베딩, 충돌 해결, MapReduce 쿼리 모델의 낯섦이 제시됨
CRDT와 더 나은 기반 기술
- 기존 애플리케이션 개발용 데이터 계층은 로컬-퍼스트 이상을 모두 만족하지 못함
- Ink & Switch는 해결책을 찾기 위해 3년 전부터 연구했고, 유망한 기반으로 Conflict-free Replicated Data Types 또는 CRDT를 제시함
- CRDT는 2011년 학술 컴퓨터과학 연구에서 등장한 범용 데이터 구조임
- 해시맵, 리스트 같은 데이터 구조처럼 문서 상태를 저장하지만, 처음부터 다중 사용자 환경을 고려함
- 텍스트 편집기, 스프레드시트, 벡터 그래픽 앱은 각자의 문서 상태를 데이터 구조로 유지하며, 협업 다중 사용자 앱에서는 이를 CRDT로 대체할 수 있음
-
CRDT의 병합 방식
- 사용자는 오프라인 상태에서도 로컬 기기에서 애플리케이션 상태를 보고 수정할 수 있음
- CRDT는 변경을 추적하고, 네트워크가 가능할 때 백그라운드에서 다른 기기와 동기화함
- 서로 다른 기기에서 동시에 새 할 일을 추가하면 병합된 상태에는 추가된 모든 항목이 일관된 순서로 포함됨
- 다른 객체에 대한 동시 변경은 쉽게 병합될 수 있음
- 자동 해결이 어려운 경우는 여러 사용자가 같은 객체의 같은 속성을 동시에 업데이트하는 경우이며, CRDT는 충돌 값을 추적하고 앱이나 사용자가 해결하도록 남김
- CRDT는 Git과 비슷하지만 텍스트 파일보다 풍부한 데이터 타입에 작동함
- 동기화 채널은 서버, P2P 연결, Bluetooth, USB 스틱 등 무엇이든 가능함
- 변경 단위는 단일 키 입력만큼 작을 수 있어 Google Docs식 실시간 협업이 가능하고, Git pull request처럼 큰 묶음으로 보낼 수도 있음
-
Automerge와 Hypermerge
- Ink & Switch는 오픈소스 JavaScript CRDT 구현체 Automerge를 개발함
- Automerge는 JSON CRDT 연구를 기반으로 함
- Automerge와 Dat networking stack을 결합해 Hypermerge를 만들었음
- 이 라이브러리들이 로컬-퍼스트 이상을 완전히 실현한다고 보기는 어렵고, 아직 더 많은 작업이 필요함
- CRDT는 인터넷의 packet switching이나 스마트폰의 capacitive touchscreen처럼, 사용자가 데이터 소유권을 가지는 협업 소프트웨어의 기반 기술이 될 잠재력이 있음
Ink & Switch 프로토타입
- CRDT 알고리듬과 이론 검증은 학계에서 진전이 있었지만, 산업적 사용은 아직 적고 대부분 서버 중심 컴퓨팅에서 사용됨
- CRDT를 쓰는 서버 중심 시스템의 예로 Azure Cosmos DB, Redis, Riak, Weave Mesh, SoundCloud Roshi, Facebook OpenR이 제시됨
- Ink & Switch는 최종 사용자 기기에서 CRDT를 사용하는 창작 작업용 로컬-퍼스트 협업 앱 프로토타입을 만들었음
- 실험은 세 가지 질문을 다룸
- 기술 가능성: CRDT가 실제 소프트웨어에 얼마나 가까운가
- 사용자 경험: 중앙 권위 서버 없이 Google Docs 같은 실시간 협업과 Git 같은 오프라인 친화적 비동기 협업이 가능한가
- 개발자 경험: CRDT 데이터 계층이 SQL DB, 파일시스템, Core Data와 어떻게 다른가
- 세 프로토타입은 Electron, JavaScript, React로 만들어졌으며, 다운로드·설치 가능한 소프트웨어라는 점이 소유감에 중요하다고 봄
-
Trellis
- Trellis는 Trello를 모델로 한 Kanban board임
- 네트워크 통신 계층으로 WebRTC를 실험함
- Git과 Google Docs의 “See New Changes”에서 영감을 받은 변경 이력을 설계함
- 사용자는 Kanban board의 작업을 보고 문서의 이전 상태로 되돌아가 볼 수 있음
-
Pixelpusher
- Pixelpusher는 Javier Valencia의 Pixel Art to CSS에 Figma 같은 실시간 협업 경험을 더한 협업 드로잉 프로그램임
- Dat 프로젝트의 P2P 라이브러리로 네트워크 통신을 실험함
- 문서 공유 URL, Git에서 영감을 받은 시각적 branch/merge, 충돌 픽셀을 빨간색으로 강조하는 충돌 해결, 사용자가 그린 아바타 기반 기본 사용자 식별을 실험함
-
PushPin
- PushPin은 Miro나 Milanote와 비슷한 mixed media canvas workspace임
- Automerge 기반 세 번째 프로젝트로, 세 프로토타입 중 가장 완성도가 높았음
- 팀과 외부 테스트 사용자의 실제 사용은 underlying data layer에 더 큰 부담을 줌
- 중첩·연결된 공유 문서, CRDT 문서용 다양한 렌더러, outbox 모델을 포함한 더 발전된 신원 시스템, 선택 강조 같은 일시적 데이터 공유를 실험함
프로토타입에서 얻은 결과
- 세 프로토타입의 목표는 로컬-퍼스트 소프트웨어와 CRDT의 기술 가능성, 사용자 경험, 개발자 경험을 평가하는 것이었음
- 개발팀 5명이 정기적으로 사용했고, 약 10명의 외부 사용자와 개별 사용성 테스트를 진행함
- 외부 사용자는 전문 디자이너, 제품 관리자, 소프트웨어 엔지니어를 포함함
- 공식 평가 방법론이 아니라 탐색적 접근을 사용함
-
CRDT 기술은 작동함
- Automerge의 신뢰성은 예상보다 좋았음
- 팀의 앱 개발자는 라이브러리를 비교적 쉽게 통합할 수 있었고, 데이터 자동 병합은 거의 항상 직관적이고 매끄러웠음
-
오프라인 사용자 경험은 좋았음
- 오프라인으로 전환해 원하는 만큼 작업하고, 다시 연결한 뒤 동료의 변경과 병합하는 흐름이 잘 작동함
- 다른 앱이 “offline” 경고와 오류를 띄우며 작업을 막을 때도 로컬-퍼스트 프로토타입은 네트워크 상태와 무관하게 정상 동작함
- 브라우저 기반 시스템과 달리 앱이 동작할지, 데이터가 있을지 불안해할 필요가 줄었고, 도구와 작업물에 대한 소유감을 줌
-
React의 FRP 모델과 잘 맞음
- React의 Functional Reactive Programming 모델은 CRDT와 잘 맞음
- CRDT 기반 데이터 계층에서는 문서가 로컬 사용자 입력과 네트워크에서 온 다른 사용자·기기의 변경을 동시에 받음
- FRP 모델은 보이는 애플리케이션 상태를 공유 문서의 underlying state와 안정적으로 동기화함
- 개발자는 다른 사용자에게서 온 변경을 추적하고 현재 화면과 조정하는 번거로운 작업에서 벗어남
- 모든 상태 변경을 단일 reducer 함수로 통과시키면 관련 로컬 변경을 다른 사용자에게 보내는 것도 쉬워짐
-
충돌은 예상보다 덜 심각했음
- 사용자는 협업 중 충돌을 드물게 만났고, 일반적 해결 메커니즘이 잘 동작함
- Automerge는 세밀한 수준에서 변경을 추적하고 데이터 타입 의미를 고려함
- 두 사용자가 배열의 같은 위치에 항목을 동시에 삽입하면 두 항목을 결정적 순서로 결합함
- Git 같은 텍스트 버전 관리 시스템은 이를 수동 해결이 필요한 충돌로 볼 수 있음
- 사용자는 협업에 대한 직관을 갖고 있어 같은 섹션을 동시에 수정하지 않도록 작업 영역을 암묵적으로 나누는 경우가 있음
- Kanban 앱에서는 한 사용자가 카드에 댓글을 달고 다른 사용자가 카드를 다른 컬럼으로 옮기면 두 변경이 모두 반영됨
- 충돌은 같은 객체의 같은 속성을 동시에 수정할 때만 발생하며, 예로 두 사용자가 같은 이미지 객체 위치를 동시에 바꾸는 경우가 제시됨
- 프로토타입에서는 Automerge의 기본 병합 의미론만으로 충분했고, 맞춤형 의미론이 필요한 사례는 찾지 못함
-
문서 이력 시각화가 중요함
- 분산 협업 시스템에서는 다른 사용자의 변경이 언제든 다수 도착할 수 있음
- 중앙 서버가 변경을 매개하지 않기 때문에 문서가 현재 상태가 된 경로, 존재하는 버전, 기여 출처를 이해하기 위한 도구가 필요함
- Trellis는 사용자가 병합된 문서의 과거 상태로 이동해 볼 수 있는 “time travel” 인터페이스를 실험함
- 새로 받은 변경 요소를 자동 강조하는 방식도 실험함
-
URL 공유는 자연스러움
- 여러 문서 공유 메커니즘 중 웹에서 영감을 받은 URL 모델이 사용자와 개발자에게 가장 자연스러웠음
- URL은 복사·붙여넣기 할 수 있고 이메일이나 채팅 같은 통신 채널로 공유할 수 있음
- 비밀 URL을 넘어선 문서 접근 권한은 아직 열린 연구 질문으로 남음
-
P2P 시스템은 단순한 온라인·오프라인으로 나뉘지 않음
- 중앙집중 시스템은 보통 서버와의 안정적 연결 여부로 “up” 또는 “down” 상태를 정의함
- 분산 시스템에서는 각 사용자가 어떤 데이터를 가지고, 공유하고, 받아들이는지에 따라 서로 다른 관점을 가질 수 있음
- 비행기 안 노트북에 있던 편집 내용은 착륙 후 연결되면 다른 사용자에게 배포될 수 있음
- 다른 사용자는 그 변경 전부, 일부, 또는 아무것도 자신의 문서 버전에 받아들이지 않을 수 있음
- Git 저장소처럼 특정 사용자의 “master”는 마지막으로 다른 사용자와 통신한 시점의 함수가 됨
- 분산 문서는 데이터 통제권을 사용자에게 주지만, 실제 UI 관점에서 무엇을 의미하는지는 더 연구가 필요함
-
긴 변경 이력은 성능 문제를 만듦
- PushPin을 스프린트 계획 같은 실제 문서에 사용하자 성능과 메모리·디스크 사용량이 빠르게 문제가 됨
- CRDT는 문자 단위 텍스트 편집을 포함해 전체 이력을 저장함
- 6개월 뒤 누군가 다시 문서에 연결해 그 시점부터 변경을 병합해야 할 수 있으므로 이력을 쉽게 잘라낼 수 없음
- Automerge 최적화는 계속되고 있으며, 주요 진행 중 작업 영역으로 남아 있음
-
네트워크 통신은 아직 해결되지 않음
- CRDT 알고리듬은 데이터 병합만 다루며, 다른 사용자의 편집이 물리적으로 같은 컴퓨터에 도착하는 방법은 다루지 않음
- 실험에서는 WebRTC, Dropbox와 USB 키로 파일을 복사하는 sneakernet 구현, IPFS 프로토콜 가능성, Dat의 Hypercore P2P 라이브러리를 시도함
- CRDT는 반드시 P2P 네트워크 계층을 요구하지 않으며, 서버를 통한 통신도 가능함
- 로컬-퍼스트의 장기성 목표를 완전히 실현하려면 벤더의 백엔드 서비스보다 오래 살아남는 탈중앙 해법이 논리적 최종 목표임
- P2P 기술은 프로덕션 준비가 부족했고, 특히 NAT traversal은 라우터나 네트워크 토폴로지에 따라 신뢰성이 낮았음
- 인터넷 접근 없이 컴퓨터끼리 직접 실시간 협업하는 경험은 중앙 API에 의존하는 세계에서 큰 가능성을 보여줌
-
클라우드 서버는 보조 역할로 남음
- PushPin 같은 실시간 협업 프로토타입은 중개 서버 없이 문서를 공유할 수 있어 프라이버시와 소유권에 좋음
- 그러나 사용자가 문서를 공유한 뒤 상대가 연결하기 전에 노트북을 닫으면, 두 사용자가 동시에 온라인이 아니어서 연결할 수 없음
- 서버는 로컬-퍼스트 세계에서 중앙 권위가 아니라 cloud peer로 역할을 할 수 있음
- 문서 사본을 저장했다가 다른 피어가 온라인이 되면 전달
- 아카이브·백업 위치 제공
- 날씨 예보나 주가 같은 전통적 서버 API로의 브리지
- 강력한 GPU로 비디오 렌더링 같은 burst computing 제공
- 전통 시스템과 로컬-퍼스트 시스템의 차이는 서버의 존재 여부가 아니라, 서버가 진실의 원천이 아니라 지원 역할을 맡는다는 점임
앞으로 필요한 작업
-
분산 시스템·프로그래밍 언어 연구자
- CRDT와 P2P 기술 연구는 로컬-퍼스트 소프트웨어에 크게 기여할 수 있음
- 현재 CRDT 연구는 보통 모든 협업자가 단일 문서 버전에 편집을 즉시 적용하는 모델을 가정함
- 실제 로컬-퍼스트 앱은 다른 협업자의 편집을 거부하거나, 공유하지 않는 문서 버전에 비공개 변경을 만들 수 있어야 함
- branch, fork, rebase 같은 분산 소스 제어 개념을 여러 문서 버전과 branch가 나란히 존재하는 협업 모델로 확장하는 연구가 부족함
- 타입, 스키마 마이그레이션, 호환성도 중요한 문제임
- 협업자마다 다른 앱 버전과 기능을 사용할 수 있음
- 중앙 DB 서버가 없으므로 데이터의 권위 있는 “현재” 스키마가 없음
- 데이터 형식이 진화하는 동안 여러 앱 버전이 안전하게 상호운용되어야 함
-
HCI 연구자
- 중앙집중 시스템에는 서버와의 동기화 상태를 표시하는 사례가 많지만, 탈중앙 시스템은 새로운 UI 문제를 가짐
- 모든 사용자가 데이터의 다른 사본을 가질 수 있는 시스템에서 온라인·오프라인, 사용 가능·불가능 상태를 어떻게 전달할지 연구가 필요함
- 넓은 인터넷 없이 다른 노드와 직접 협업할 수 있을 때 “온라인”이 무엇을 뜻하는지도 달라짐
- 모든 문서가 일상적 사용만으로 복잡한 버전 이력을 가질 수 있으므로, 사용자가 버전·변경 수락·문서 형성 과정을 이해하는 UI가 필요함
- 현재 변경 관리는 소스 코드식 diff·patch 모델과 Google Docs식 suggestion·comment 모델이 주류임
- 텍스트가 아닌 데이터 형식으로 이 아이디어를 일반화하는 방법은 열린 문제임
- 로컬-퍼스트에서는 데이터를 가진 사용자가 로컬에서 수정하는 것을 막을 수 없고, 다른 사용자가 그 변경을 구독할지 선택하는 식으로 권한 개념이 달라짐
-
실무자
- 프로덕션 소프트웨어를 만드는 엔지니어, 디자이너, 제품 관리자, 독립 개발자는 로컬-퍼스트 미래로 가는 점진적 단계를 취할 수 있음
- 빠른 앱을 위해 적극적 캐싱과 사전 다운로드로 문서 열 때 스피너를 줄이고, 기본적으로 로컬 캐시를 신뢰할 수 있음
- 다중 기기는 Firebase와 iCloud 같은 동기화 인프라로 비교적 쉽게 지원할 수 있지만, 장기성과 프라이버시 우려가 있음
- 오프라인은 웹에서는 Progressive Web Apps, Service Workers, app manifest가 도움을 줄 수 있음
- 앱 테스트는 WiFi를 끄거나 Chrome DevTools network condition simulator, iOS network link conditioner 같은 도구로 네트워크 조건을 바꿔 수행할 수 있음
- 협업에는 CRDT 외에도 ShareDB 등에 구현된 Operational Transformation이 더 확립된 기술임
- 장기 보존을 위해 JSON, PDF 같은 안정적 형식으로 쉽게 내보낼 수 있어야 함
- Google Takeout 같은 대량 내보내기
- GoodNotes의 안정적 파일 형식 지속 백업
- Trello의 JSON 문서 다운로드
- 프라이버시 측면에서는 데이터가 기기에만 저장되는지, 백엔드로 전송되는지 사용자에게 명확히 알려야 함
- 사용자 통제권을 위해 앱 안에서 문서 백업, 복제, 삭제가 쉬워야 하며, Google Docs가 Google Drive로 기본 파일시스템 작업을 다시 구현한 사례가 제시됨
스타트업 기회와 결론
- 개발자 인프라를 만들려는 창업자에게 “Firebase for CRDTs”는 흥미로운 시장 기회로 제시됨
- 그런 스타트업은 좋은 개발자 경험과 SQLite나 Realm 같은 로컬 지속성 라이브러리를 제공해야 함
- iOS, Android, Windows, Mac, Linux, Electron, Progressive Web Apps를 지원해야 함
- 사용자 통제권, 프라이버시, 다중 기기 지원, 협업이 기본으로 포함되어야 함
- 성공 여부의 리트머스 테스트는 모든 서버가 종료되어도 고객 앱이 영구히 계속 작동하는지임
- 클라우드 소프트웨어는 협업과 어디서나 접근 가능한 최신 앱을 제공했지만, 데이터 소유권을 서버에 두면서 사용자를 자기 데이터의 임차인처럼 만들었음
- 로컬-퍼스트 접근은 사용자가 데이터 소유권과 통제권을 유지하면서도 클라우드식 협업과 접근성을 얻을 수 있음을 보여줌
- 실제 구현을 위해서는 오프라인 지원, 온디바이스 저장소 활용, 알고리듬·프로그래밍 모델·사용자 인터페이스 개선, CRDT와 P2P 네트워킹의 제품화가 더 필요함