로컬-퍼스트 소프트웨어: 클라우드 시대에도 내 데이터 소유하기 (2019)

 (inkandswitch.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 클라우드 앱은 협업과 다중 기기 접근성을 크게 개선했지만, 데이터의 권위 있는 사본이 서버에 있어 사용자의 소유권과 통제권이 약해짐
  • 로컬-퍼스트 소프트웨어는 노트북·태블릿·휴대폰의 로컬 저장소를 주된 데이터 사본으로 두고, 서버는 동기화·백업을 돕는 보조 역할로 제한함
  • 이 접근은 빠른 응답, 오프라인 작업, 여러 기기 동기화, 실시간 협업, 장기 보존, 기본 보안·프라이버시를 동시에 추구함
  • 파일, 이메일, 웹 앱, 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 네트워킹의 제품화가 더 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 완전 동의함. 모든 서비스가 내 데이터를 자기들 클라우드로 가져가고, 제대로 쓰려면 구독료를 내게 만드는 흐름에 질렸음
    지금 만드는 피트니스 추적 앱은 “한 번 구매하면 X년 동안 업데이트를 받고, 모든 기기와 동기화하며, 이후에도 영구 사용”하는 모델로 가려 함. X년 뒤 업데이트가 필요하면 새 버전을 다시 사면 되고, 지금 기능으로 충분하면 계속 쓰면 됨
    대부분의 소프트웨어가 이렇게 적정 가격에 구매 가능하고, 제품 자체가 좋으며, 클라우드 없이는 못 쓰게 묶이지 않았으면 함. 로컬 우선 소프트웨어의 가장 좋은 점은 광고·추적·참여도 극대화가 아니라 제품 품질로 돈을 받는 건강한 인센티브를 되살린다는 점임

    • Obsidian도 참고하기 좋은 모델임. 클라이언트는 완전히 무료이고, 선택형 동기화 서비스만 판매함
      노트는 모두 Markdown 파일이라 클라이언트 자체도 선택 사항이 됨
    • 클라우드 인프라 없이 동기화를 어떻게 할 계획인지 궁금함
    • “X년 업데이트 + 기기 동기화 + 영구 사용”은 좋아 보이지만, 이 방식이면 1~2년치 구독 총비용을 한 번에 받아야 함
      동기화 서버도 계속 운영해야 하고, 사용자가 1년치 데이터를 하루에 몰아서 동기화하는 경우도 고려해야 함. 미래 개발을 맡을 인력도 계속 급여를 줘야 하니, 개발자 관점만으로 보면 빠지는 부분이 있음
    • 몇 년 전 지역 공장이 IT 공급사의 서버 장애로 이틀간 생산을 멈춘 뒤 최악의 상황을 생각하며 비슷한 생각을 했음
      https://rodyne.com/?p=1439
    • 백엔드가 실시간 협업이나 동기화처럼 기능의 일부일 수는 있음. 다만 클라우드에서 탈출 가능(ejectable) 하고 언제든 셀프 호스팅으로 바꾸거나 되돌릴 수 있으면, 데이터와 서비스 양쪽에 대한 소유권과 장기성을 보장할 수 있음
      우리가 만드는 노트/작업 IDE도 이런 방식임: https://thymer.com/local-first-ejectable

  • Berlin에는 Ink and Switch가 주최하는 연례 Local-first Software Conference가 있고, 올해 11월 SF에서는 Sync Conf라는 파생 행사도 열림
    https://www.localfirstconf.com/
    https://syncconf.dev/
    올해는 원 논문의 공동 저자들이 개발 도구 맥락에서 로컬 우선 소프트웨어가 무엇인지, 원 논문 이후 무엇을 배웠는지 다룬 패널이 좋았음: https://youtu.be/86NmEerklTs?si=Kodd7kD39337CTbf
    커뮤니티는 “동기화”를 로컬 우선의 구성 요소이지만 훨씬 더 넓게 적용 가능한 기술로 보는 쪽으로 정리되는 중임. 로컬 우선은 최종 사용자 소프트웨어의 특성이고, 동기화 엔진 같은 개발 도구는 이를 가능하게 하는 도구이지 그 자체가 반드시 로컬 우선인 것은 아님
    지난 몇 년간의 전체 발표는 여기 있음: https://youtube.com/@localfirstconf?si=uHHi5Tsy60ewhQTQ
    로컬 우선/동기화 엔진 커뮤니티에는 흥미로운 시기임. 실시간 협업과 비동기 협업 경험을 가능하게 하는 도구를 만들어 왔고, AI가 등장하면서 이 시장이 커지고 있음. 모든 AI 앱은 본질적으로 에이전트가 행위자로 참여하는 다중 사용자 협업 시스템이라 동기화 엔진 커뮤니티가 다뤄 온 기술이 필요함

    • 로컬 우선 앱과 인프라를 만드는 엔지니어들을 인터뷰하는 훌륭한 Local First 팟캐스트도 있음
      https://www.localfirst.fm/

  • 읽어볼 만하고, 과거에도 활발한 논의가 여러 번 있었음
    https://news.ycombinator.com/item?id=19804478 - 2019년 5월, 댓글 191개
    https://news.ycombinator.com/item?id=21581444 - 2019년 11월, 댓글 241개
    https://news.ycombinator.com/item?id=23985816 - 2020년 7월, 댓글 9개
    https://news.ycombinator.com/item?id=24027663 - 2020년 8월, 댓글 134개
    https://news.ycombinator.com/item?id=26266881 - 2021년 2월, 댓글 90개
    https://news.ycombinator.com/item?id=31594613 - 2022년 6월, 댓글 30개
    https://news.ycombinator.com/item?id=37743517 - 2023년 10월, 댓글 50개

  • 온라인 의존성이 있는 것은 필연적으로 지속적인 유지보수와 비용이 듦. 시스템이 로컬 우선, 가능하면 로컬 전용이 아니라면 장기 신뢰성을 위해 설계된 게 아님
    연결된 가전과 자동차는 실용적 관점에서 가장 어리석은 엔지니어링에 가까움

    • 전부 구독 매출 때문임
      구독 매출을 얻는 회사는 매출도 많고 밸류에이션도 높아 추가 자금 조달이 쉬워지며, 이 모델을 따르지 않는 회사를 이김. 이런 자기강화 구조 때문에 로컬 우선 소프트웨어가 죽었다고 봄
    • Dropbox나 Apple 같은 곳의 무료/유료 스토리지를 보면 실제 비용이 보임. 대략 2TB에 월 10달러 수준임
      Cloudflare는 정적 파일 호스팅을 거의 무료로 해주고, 비용은 반올림 오차에 가까움. 로컬 우선 앱 1000개가 Dropbox에 동기화해도 월 10달러 스토리지로 돌아갈 수 있음. 이 스토리지는 S3 같은 저수준 원시 도구가 아니라 인증, 지원, 동기화 프로그램까지 갖춘 소비자용 서비스임. 대부분의 클라우드 비용은 사실 필요하지 않음
    • Stop Killing Games 이니셔티브에 반대하는 사람이라면 이 댓글을 읽어야 함
      누구도 게임이 온라인 서비스에만 의존하도록 강요하지 않음. 법적 요구도, 규제 요구도 아님. 소프트웨어의 많은 것처럼 선택일 뿐임. 온라인 서비스에 의존하도록 선택해 놓고 나중에 “이걸 되돌리려면 돈이 든다”고 말하는 건 근시안적이고 한심하며 받아들여서는 안 됨

  • 더 많은 앱이 로컬 우선이어야 함. 사용자가 데이터를 클라우드에 동기화하고 싶지 않다면 그 선택지가 있어야 함
    한동안 오프라인 우선 또는 로컬 우선 앱 Brisqi를 만들고 있으며, 처음부터 오프라인 우선 철학으로 설계했음
    https://brisqi.com
    로컬 우선 앱은 무기한 완전 오프라인으로 동작하도록 설계되어야 함. 로컬 경험이 기반이지 대체 수단이 아니며, 클라우드 동기화는 요구사항이 아니라 보조 기능이어야 함
    임시 캐시에 의존하는 앱은 오프라인 우선이라고 보지 않음. 진짜 오프라인 우선 앱은 로컬 데이터베이스로 데이터를 영속화해야 함. “오프라인 우선”이라고 부르는 많은 앱은 실제로는 제한된 오프라인 기능만 제공하고 결국 인터넷 재연결에 의존하는 오프라인 허용형에 가까움
    오프라인 우선 앱은 온라인 전용 웹 앱보다 확실히 만들기 어렵고, 오프라인/온라인 전환 중에도 데이터가 일관되게 클라우드로 동기화되며 손실되지 않도록 동기화 메커니즘이 충분히 신뢰할 수 있어야 함. 접근 방식은 블로그에 더 적어 두었음: https://blog.brisqi.com/posts/how-i-designed-an-offline-first-app-an-outline

    • 이 모델이 사업으로 지속 가능할지 더 어렵지 않을까 걱정되는데, 실제로는 어떻게 진행되고 있는지 궁금함

  • 이 원칙을 소비자 영역에 맞춰 설명한 점은 흥미롭지만, 우리는 현재 산업 자산/산업 데이터 쪽에서 같은 일을 하고 있음
    www.sentineldevices.com 에서 학습, 분석, 의사결정 전체가 고객 장비 위에서 이루어짐. 데이터를 보낼 서버조차 없고, 명시적으로 모든 것이 장치 내부에서 돌아가는 모델임
    SCADA/산업 자동화에서는 데이터를 외부로 가져갈 수 없는 사용 사례가 많음. 고객이 있는 곳에서 서비스를 제공하기 어렵다는 이유로 데이터/AI 회사들이 거대한 고객층과 사용 사례를 무시하고, 대신 데이터를 자기들에게 가져오며 공급업체 종속을 유지하려 함
    고객과 이야기할 때 오히려 “아니요, 이건 로컬이고 외부 연결이 없습니다”를 매우 강조해야 함. 이런 말을 거의 들어본 적이 없어 단계별로 설명해야 모든 것이 로컬에서 일어난다는 걸 이해하는 경우가 많고, 소프트웨어 공급업체들은 이 개념을 잘 받아들이지 못함. 소비자 영역에서 로컬 우선 소프트웨어가 더 자리 잡아 산업 영역에서도 익숙해지면 좋겠음

    • 모든 SCADA 공급업체가 클라우드 유행에 올라타서 그 방향으로 밀어붙이는 것도 도움이 안 됨
      “스마트폰으로 공장을 운영하세요!”라니, 이제 제로데이 하나만 터져도 스크립트 키디가 내 펌프를 가지고 놀 수 있게 됨
    • 흥미로운 영역이고 이 일을 하고 있다니 반가움
      채용 페이지를 보니 모든 포지션이 비원격이던데, 로컬 우선 소프트웨어를 만들려면 직접 대면해야 하는 한계 때문인지, 아니면 주로 관리상의 이유인지 궁금함

  • 이 접근에는 개인적으로 동의하지 않음. “클라우드 공급자를 믿을 수 없다”는 비즈니스 문제를 “중앙집중 아키텍처를 피한다”는 기술적 절충으로 풀려는 시도처럼 보임
    폐쇄형 소프트웨어의 통제력 부족과 신뢰성 부족은 오픈소스 개발이라는 새 비즈니스 모델, 새 라이선스, 라이선스 비용 대신 유지보수 계약 같은 수익 방식으로 해결됐음
    마찬가지로 클라우드 공급업체의 문제에도 비즈니스 모델 차원의 해법이 필요함. 예를 들어 사용자가 클라우드 공급업체와의 관계를 신뢰할 수 있도록 권리를 정의하는 표준 계약/라이선스를 만들 수 있음. 시간이 지나면 사용자가 이런 라이선스를 가진 공급업체와만 거래할 수도 있음
    여기에는 수명 종료 계약, 데이터 이동성 보장, 데이터 접근을 감사하고 누가/무엇이/언제 읽었는지 알려주는 데이터 프라이버시 투명성 같은 조항이 들어갈 수 있음. 문제는 채택임. 클라우드 공급업체가 왜 받아들여야 하느냐가 핵심이고, 이탈률을 두려워한다면 이런 계약을 연간 구독에만 제공하거나 더 높은 가격을 받을 수도 있음

    • 비즈니스 문제나 정치적 문제를 기술적 해법으로 풀 수 있다면 대개 강한 접근임. 그런 문제는 적대적 주체가 일으키고, 기술적 해법은 그 주체가 배신할 능력을 제거하기 때문임
      클라우드 서비스를 쓸 때 암호화가 좋은 예임. 개인정보 보호정책과 관료적 규칙으로 데이터를 보호하려는 건 헛수고에 가깝음. 데이터는 가치가 있고, 고객이나 정부가 회사가 몰래 팔고 있는지 알기 어렵고, 보안에 돈을 아꼈는지도 너무 늦기 전엔 알기 어려움
      하지만 클라이언트 장치에서 암호화되고 서버가 평문에 접근할 수 없음을 수학적으로 증명할 수 있다면 그런 걱정을 하지 않아도 됨. 문제는 서버가 데이터를 저장만 하는 게 아니라 처리해야 할 때이고, 그때 기술적 해법은 자기 서버를 쓰는 쪽이 됨
    • 그런 계약이 정말 문제를 해결하는지는 의문임. 클라우드 서비스가 종료 전에 X개월 통지하고 데이터 내보내기를 허용한다고 문서화했다고 해도, 실제 종료 뒤 손에 남는 건 사실상 쓸모없는 거대한 JSON 파일일 수 있음
      직접 앱을 만들거나 친절한 누군가가 만들어 주지 않으면 활용하기 어렵다. 아무것도 없는 것보다는 낫지만, 회사가 문을 닫거나 지원을 중단한 뒤에도 수년 또는 수십 년 돌아갈 수 있는 로컬 앱만큼 좋지는 않음
    • 이 모델은 클라우드 공급업체를 은행처럼 만들 수 있음. 클라우드 공급업체가 사용자 계정 안에 일종의 재산을 보관하고, 사용자는 그 재산에 대한 명확한 권리와 계정에서 회수할 법적 능력을 갖게 됨
      회수는 금융에서는 돈이나 재산을 인도받는 것에 해당하고, 클라우드에서는 계정 전체 내용을 담은 큰 Zip 파일을 받는 것일 수 있음
      하지만 인도받는 것이 항상 실용적이거나 바람직한 건 아님. 금융에서는 계좌를 다른 업체로 이전할 수 있고, 클라우드 서비스에서도 많은 경우 계정 이전이 훨씬 유용할 가능성이 큼
      여기서 어려운 점은 이식성임. 클라우드 계정에 대한 사용자의 재산권과 권리를 잘 정의하더라도, Facebook 친구를 인도받는다는 것은 무슨 뜻인지, Facebook 계정을 다른 곳으로 이전한다는 것은 무엇을 의미하는지 애매함
    • 저 해석은 정확하지 않다고 봄. 저자들은 로컬 우선의 비즈니스 사례가 완전히 해결되지 않았고 밀접한 관련 문제라는 점을 충분히 인정함
      이 문제에는 비즈니스 해법과 기술 해법이 모두 필요하고, 논문은 해법이 어떤 특성을 가져야 하는지를 제안함
      로컬 우선이 탈중앙화를 주장한다는 것도 맞지 않음. Martin Kleppmann은 탈중앙화 기술이 대중 시장으로 갈 수 있는 방식으로 이 문제를 해결한다고 보지 않는다고 명시했음. 그는 로컬 우선의 이상을 가능하게 하는 중앙화된 표준 동기화 엔진을 지지함
      작년 Local-first conf 발표 참고: https://youtu.be/NMq0vncHJvU?si=ilsQqIAncq0sBW95
    • 데이터 이동성 보장은 어느 정도 규모가 있는 데이터에는 실용적이지 않음. 운영 환경 데이터베이스를 새 데이터베이스로 이관하는 일은 원활하게 하려면 몇 달에서 몇 년이 걸릴 수 있음
      위기 상황에서는 몇 주 만에도 가능하지만 매우 지저분해질 수 있음. 같은 버전의 오픈소스 데이터베이스 사이를 옮겨도 클라우드 서비스마다 차이가 많아 마찬가지임
      가장 좋은 해법은 애초에 데이터를 자기 환경에 두고 필요하면 연결을 끊는 것임. BYOC 관리와 오픈소스를 결합하면 가능함. 우리 회사도 BYOC 데이터 제품을 운영하므로 이 접근에 경제적 이해관계가 있지만, 실제로 작동하는 걸 봤기 때문에 가능하다고 앎

  • 내 프로젝트 https://github.com/ibizaman/selfhostblocks와 https://github.com/ibizaman/skarabox로 바로 그걸 널리 가능하게 만들려 함
    공통 목표는 셀프 호스팅을 대중에게 더 접근 가능하게 만드는 것임
    NixOS 기반으로 https, SSO, LDAP, 백업, 스냅샷이 있는 ZFS 등을 최대한 선언적으로 기본 제공하려 함
    Vaultwarden과 Nextcloud를 패키징해 대부분의 데이터를 저장할 수 있으므로 클라우드 호스팅의 경쟁자이고, Home Assistant 같은 서비스도 제공함
    YUNoHost의 경쟁자이기도 하지만, SelfHostBlocks가 제공하는 구성 요소로 원하는 패키지를 직접 셀프 호스팅할 수 있어 더 낫거나 그렇게 되려 함. 프레임워크라기보다 라이브러리에 가까움
    NAS와도 경쟁하지만 모든 것이 오픈소스라는 점에서 더 낫다고 봄. 아직 사용자가 기술적이어야 하지만 그 제약을 없애는 중이고, 목표 중 하나는 Nix를 알거나 명령줄을 만지지 않아도 자기 하드웨어에 설치할 수 있게 하는 것임

    • 정말 좋음. 요즘 이 생각을 많이 하고 있음. 훌륭한 자유 오픈소스 대안이 이렇게 많은데, 기술자에게는 “docker compose up” 정도로 비교적 쉬워도 비기술자에게는 여전히 닿기 어려운 게 이상함
      셀프 호스팅 가능한 앱 상당수는 데이터베이스, 서버, 프런트엔드를 가진 웹 애플리케이션이지만, 많은 사용 사례에서는 한 컴퓨터에서만 쓰고 호스팅 버전이나 다른 기기 동기화가 필요 없기도 함. 예를 들어 개인 회계는 한 달에 한 번 컴퓨터에서 하면 되니, 어딘가에서 24시간 웹 앱을 돌릴 필요가 없음. 프로그램을 켜고 일한 뒤 끄면 됨
      고품질 셀프 호스팅 가능 자유 오픈소스 대안의 수와 실제로 그것을 쓸 수 있는 사람 수 사이에 큰 불일치가 있음. 그 간극을 줄이는 프로젝트가 더 필요함. selfhostblocks를 몇 가지에 써보고 기여해 보려 함
    • hledger를 포함한 점이 좋음. 평문 회계에 익숙하지 않은 사람에게는 조금 낯설 수 있지만 정말 훌륭한 소프트웨어임

  • 모든 애플리케이션이 자기만의 동기화 플랫폼을 가질 이유는 없음. 이런 프레이밍은 프로그램 간 조합성이나 모듈성이 없는 모바일 앱에서 나온 것 같음
    “로컬 우선”을 진지하게 받아들인다면 그냥 파일 시스템을 쓰면 되고, 사용자는 git, Box 등 여러 해법 중 고를 수 있음
    자체 동기화 가입을 요구하는 건 다른 SaaS만큼 싫고, 오히려 더 불투명하며 깨지기 쉬움

    • 모든 앱에 자체 동기화 엔진이 필요하지 않다는 데는 동의하지만, 파일 시스템이 로컬 우선을 받아들이는 보편적 방법이라는 프레이밍에는 동의하지 않음
      첫째, 로컬 우선도 원하지만 동시성도 원함. 단순 로컬 우선이라면 아무 동기화나 괜찮지만 그 이상을 원함. Dropbox처럼 신경 쓰지 않아도 매끄럽게 돌아가고, 통신이 안 되는 지역에서도 나와 아내가 각자 휴대폰에서 따로 수정할 수 있기를 원함
      둘째, 동기화는 데이터 구조와 의미를 깊이 알 때 훨씬 잘 작동함. git과 Box는 둘 다 상당한 한계가 있고, 동시성 요구가 있으면 그 한계가 더 커짐
    • 대체로 동의하지만 실제로는 항상 그렇게 단순하지 않음. 정확히 그렇게 동작하는 앱을 만들었는데, 언제 어떤 클라이언트가 파일 편집을 허용받아야 하는지 조율할 수 없어 결국 파일 충돌이 피할 수 없이 생겼음

  • 이론적으로는 로컬 우선 방식의 개발을 좋아함. 프라이버시와 데이터 소유권을 기본으로 보는 스몰 테크 철학과 잘 맞음
    하지만 실제로는 어렵다. 사실상 동기화 엔진을 만들고, 충돌 해결을 처리하고, 스키마 마이그레이션을 관리해야 함
    그래도 지난 몇 년간 로컬 우선 소프트웨어 개발 도구는 좋아진 듯함. jazz.tools, electric-sql, Rocicorp의 Zero를 지켜보고 있는데 다른 것도 있는지 궁금함

    • 서버의 CouchDB와 클라이언트의 PouchDB가 그런 환경을 만들려던 시도였음
      https://couchdb.apache.org/
      https://pouchdb.com/
      약 10년 전 로컬 우선 애플리케이션 개발에 대한 더 많은 고민은 여기에서도 볼 수 있음: https://unhosted.org/
    • 지난 한 달 정도 개인 예산 앱 사이드 프로젝트에 instantdb를 꽤 진지하게 써봤음
      블로그 글을 써야겠지만, 이전에는 PowerSync, electricSQL, LiveStore, PowerSync를 조사했고 jazz.tools도 잠깐 봤지만 좀 더 구조화된 것을 원했음
      지금까지는 꽤 인상적임. Vue와 커뮤니티 라이브러리로 작성 중이고, 권한은 조금 까다로웠지만 이해하고 나니 단순했음. 매직 이메일 로그인도 마음에 들고, 대시보드/응답 기능도 좋지만 덜 번거롭게 만들려면 몇 가지 큰 변경이 필요해 보임
      오픈소스이고 원하면 셀프 호스팅할 수 있다는 점이 좋음. jazz는 구조가 부족했고, LiveStore는 이벤트 저장소가 너무 번거로워 보였지만 매력은 있었음. 개발 도구가 유료 장벽 뒤에 있는 건 아쉬웠지만 이해는 됨. electricSQL은 해법의 절반, 즉 읽기만 제공하고 쓰기 모델은 부족했음. CouchDB/PouchDB도 내게는 구조가 부족했고, 문서 간 지원이 더 명확하게 내장되기를 원했음. Zero는 제대로 조사하지 않았음
    • 이 사이트를 알고 있는지 궁금함: https://www.localfirst.fm
      사실 상단 메뉴의 “landscape” 링크를 가리키려 했는데 URL이 꽤 불편함
    • 얼마 전 누군가 Automerge를 언급한 걸 봤음
      https://automerge.org/
      Rust와 JavaScript 구현이 있고, 몇 가지 네트워크 전략도 제공함. jazz.tools처럼 무료/유료 제품 구성이 딸려 오지는 않지만 꽤 괜찮음
    • Ditto도 볼 만함
      https://www.ditto.com
      CRDT를 핵심으로 실시간 동기화를 지원하는 로컬 우선 플랫폼이라 충돌 해결 관리가 훨씬 쉬워짐. 오프라인 우선 사용 사례와 피어 투 피어 동기화를 기본으로 처리하도록 설계되어 있어 직접 동기화 엔진을 처음부터 만들 필요가 없음
      Swift, Kotlin(Android), Flutter/Dart, React Native, JavaScript(Web/Node), .NET(C#), C++, Java, Rust 등 다양한 플랫폼을 지원함. 문서는 여기에서 더 볼 수 있음: https://docs.ditto.live/home/about-ditto
답변달기