▲

Linear가 나를 로컬-퍼스트 rabbit hole로 이끌었음

 (bytemash.net)
1P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Linear를 사용하면서 웹 애플리케이션 개발 방식에 대한 시각이 크게 바뀌었음
  • Linear는 로컬-퍼스트 방식으로 동작해 즉각적인 반응과 네트워크 지연 없는 인터랙션을 제공함
  • 이 방식은 클라이언트가 독립적인 데이터베이스를 가지며, 변경사항은 비동기적으로 서버와 동기화함
  • 하지만 분산 환경에서의 동기화, 충돌 해결, 오프라인 처리 등 구현 난이도가 높음
  • Jazz, Electric SQL, Zero 등 로컬-퍼스트 생태계의 다양한 솔루션이 등장하고 있으며 개발자 경험도 점차 개선되고 있음

개요

Linear라는 프로젝트 관리 툴을 사용하며, 로컬-퍼스트 방식의 탁월한 속도와 사용자 경험에서 큰 영감을 받음. 기존 웹 앱에서 흔히 겪던 네트워크 지연, 로딩 상태, 페이지 리프레시 등이 전혀 느껴지지 않은 점이 인상적이었음. 이러한 경험을 통해 로컬-퍼스트(local-first) 패러다임의 기술적인 원리와 실제 적용 사례를 깊이 탐구하게 되었음.

Down the Rabbit Hole

Linear의 기술적 비밀을 파헤치면서, 그들은 브라우저의 IndexedDB를 실제 데이터베이스처럼 활용하고 있다는 사실을 알게 됨. 모든 변경은 로컬에서 먼저 즉시 처리되고, 이후 GraphQL과 Websockets를 이용해 백그라운드에서 동기화가 이루어짐.

  • local-first라는 용어는 UX 전략(즉각적 반응성) 또는 데이터 자체를 로컬에 보관하고 싱크하는 철학으로 다양하게 해석될 수 있음
  • 전통적인 웹 앱에서는 서버가 단일 진실의 원천이었지만, 로컬-퍼스트 구조에서는 각 클라이언트가 자체 데이터베이스를 가짐
  • 데이터베이스의 위치가 사용자 근처로 이동하면서, 사용자 인터랙션에서 네트워크 지연이 완전히 제거됨

The Challenge: This Is Not Trivial

Linear의 방식을 직접 구현하려 시도해보니 복잡도가 상당함을 깨달음.

  • 오프라인/온라인 전환 처리
  • 분산된 클라이언트 간 충돌 해결
  • 부분 동기화(전체 데이터를 내려받지 않기 위한 설계)
  • 캐시 데이터의 스키마 마이그레이션
  • 분산 환경에서의 보안 및 접근 제어
  • 이러한 기능들은 막대한 엔지니어링 시간과 노력이 필요한 영역임

The Local-First Ecosystem in 2025

2025년 기준, 로컬-퍼스트 생태계에서는 여러 강력한 솔루션이 등장함.

  • Electric SQL: Postgres를 기반으로 한 싱크 엔진
  • PowerSync: 엔터프라이즈 중심 솔루션
  • Jazz: 로컬-퍼스트 앱을 손쉽게 구축하게 해주는 도구
  • Replicache: 기존 주요 솔루션(개발 종료)
  • Zero: Replicache 팀의 새로운 방향성
  • Triplit: TripleStore 기반 싱크
  • Instant: 개발자 경험에 초점을 맞춤
  • LiveStore: 실시간 동기화 계층 제공

Deep Dive: Jazz

Jazz는 "로컬-퍼스트 앱을 상태 업데이트만큼 쉽게 만든다"는 고유한 약속으로 눈길을 끎.

The Mental Model

Jazz는 Collaborative Values(CoValues) 라는 실시간 협업 구조체를 도입함.

  • Jazz 및 Zod로 스키마를 정의: 이 정의는 단순 타입이 아니라 자동 동기화되는 라이브 객체로 동작
  • 별도의 API 라우트, 요청/응답 로직, DTO 등이 필요 없이 단순히 객체 상태를 바꾸면 자동으로 싱크가 이루어짐

How Jazz Achieves This

Jazz의 내부 구조는 다음과 같음:

  • 유일성 보장: 각 데이터에 고유 ID 자동 할당
  • 이벤트 소싱: 변경 이력을 이벤트로 저장, 실시간 동기화 효율화
  • 종단간 암호화: 동기화 전 클라이언트에서 데이터 암호화. 서버는 암호화된 블롭만 볼 수 있음
  • 그룹 기반 권한 설계: 전통적 ACL 대신 그룹 단위 권한, 소유권이 명확히 구분됨

The Trade-offs

이 구조는 프로토타이핑 및 빠른 UI 개발에 매우 생산적임. 하지만 몇 가지 특성상 고려해야 할 부분이 있음:

Your Server Is Blind

종단간 암호화로 인해 서버는 사용자의 데이터를 읽을 수 없음. 사전에 서버가 접근이 필요한 데이터를 명확히 정의하지 않으면, 감시나 악성 저장 방지 등 관리에 제한이 발생함

Time Travel Is Mandatory

이벤트 소싱으로 인해 모든 변경 이력이 영구 저장됨. 덕분에 Undo/Redo가 매우 편리하지만, GDPR 등 법적 요구사항 고려시 삭제가 어렵다는 단점이 있음

Storage Goes Brrr

삭제가 이루어지지 않아 저장공간 사용량이 점점 증가함. 소규모 프로젝트는 괜찮지만, 대규모 SaaS에서는 저장 비용이 크게 증가할 수 있음

Local Dev Still Has Quirks

Passkeys를 중심으로 한 인증 방식이 기본인데, 자체 개발이나 로컬 환경에서는 HTTPS, 인증서 관리, 키 이전 등 개발 초기에 번거로움이 존재함. 다만 Better Auth 통합 등 개선 예정임

But Honestly? Still Worth It

이러한 제약에도 불구하고, Jazz의 개발 경험과 생산성은 매우 인상적임. 아직 초기 버전이나, 앞으로 다양한 문제들이 점차 해결될 전망임

Exploring: Electric SQL and Zero

Jazz와 달리, Electric SQL과 Zero는 점진적 접근 방식을 취함.

  • 기존 Postgres 테이블 그대로 활용 가능
  • Electric SQL은 테이블의 일부분을 reactive query(Shape)로 구독해 UI에 동기화할 수 있음
  • 변경(뮤테이션) 처리 방법이 Jazz에 비해 다르고, LiveStore 통합 등 다양한 옵션 존재
  • Zero는 Electric과 유사하지만, 변경사항 동기화 지원이 내장됨

When Does Local-First Make Sense?

로컬-퍼스트 패러다임이 적합한 상황과 도전적인 상황을 다음과 같이 정리함

적합함:

  • 창작 도구(디자인, 글쓰기, 음악 등)
  • 협업 지원 애플리케이션
  • 오프라인 지원이 필요한 모바일 앱
  • 개발자 도구
  • 개인 생산성 앱

도전적임:

  • 대규모 서버 측 비즈니스 로직
  • 엄격한 감사(Audit) 요구사항
  • 대용량 분석 시스템
  • 깊이 통합된 기존 시스템
  • 서버에서 요청을 자주 거부하는 시스템

Looking Forward

로컬-퍼스트는 웹 개발의 패러다임 전환을 의미함. Linear는 이미 사용자 경험에서 큰 효과를 증명함. 개발자는 이러한 구조적 트레이드오프가 자신의 프로젝트에 적합한지 판단해야 함.

Jazz로 직접 퍼스널 앱을 제작하며 실제 장단점과 추상화의 한계를 체험 중임. 생태계는 아직 초기 단계로, 향후 도구와 패턴이 성숙하며 개선될 것임. 그러나 데이터를 로컬에 두는 방식의 이점은 명확하며, 이는 사라지지 않을 전망임.

새로운 프로젝트에서 제약을 수용할 수 있다면 로컬-퍼스트를 경험해볼 가치가 충분함. 최악의 경우 새로운 아키텍처 패턴을 학습하게 되고, 최선의 경우 불가능할 정도로 빠른 사용자 경험을 구현할 수 있음. 300ms 응답 경쟁에서 이는 중요한 이점이 됨.

▲
GN⁺ 2일전  [-]
Hacker News 의견

  • Zero 또한 Electric과 유사한 기능을 제공하며, 변이 처리를 직접 지원함 Zero의 핵심 차별점은 쿼리 중심 동기화임 앱을 쿼리 단위로 설계할 수 있고, 무엇을 동기화할지 미리 결정하거나 설정할 필요 없이, 쿼리만 실행하면 필요한 만큼 혹은 적은 양만 동기화 가능함 클라이언트에 필요한 데이터가 없으면 쿼리가 자동으로 서버로 넘어가고, 해당 데이터가 동기화돼 이후 쿼리에 바로 사용 가능함 이 방식은 상당히 실용적임

    • 모든 규모의 앱에 적합함(모든 데이터를 클라이언트로 동기화할 수 없음)
    • 빠른 시작 화면 구성에 유리함(공개 페이지의 빠른 로딩)
    • 권한 처리도 별도 시스템 없이 쿼리만으로 해결 가능함 그래서 Zero 사용 경험은 Convex나 RethinkDB 같이 반응형 데이터베이스에 가까움 하지만 표준 Postgres를 쓰기 때문에 동기화 엔진의 즉각적인 상호작용성도 누릴 수 있음

  • 나는 SSR을 선호함 클라이언트는 세션 토큰, 현재 URL, 그리고 DOM만 상태로 가져야 한다고 봄 네트워크와 서버는 계속 빨라지고 있음 빛의 속도는 고정이지만 아직 완전히 활용하지 못하는 단계임 Hollow core fiber 등으로 인터넷 전체의 레이턴시를 30%까지 낮출 수 있는 기술도 등장할 예정임 이미 RTT가 500ms라 해도 SSR로 16ms 안에 렌더링된 페이지라면, 오늘날 온라인의 대부분의 웹사이트보다 훨씬 즉각적으로 느껴질 것임 서버에서 60Hz 프레임보다 더 오래 HTML 응답을 렌더링하는 건 말이 안 된다고 생각함 Zen5 코어로 30~40MB의 JSON 직렬화를 그 시간 안에 할 수 있음 서버 입장에선 그냥 fancy한 UTF-8 문자열일 뿐임 이런 부분은 ms가 아니라 μs 단위로 측정해야 한다고 봄 전송 지연이 높다는 건 CPU 시간을 lazy하게 써도 된다는 변명거리가 아님 나는 SQLite를 사용해서 millisecond jail에서 벗어남 호스팅 SQL 서비스는 1ms 이하 레이턴시를 노릴 때 족쇄 같은 존재임 브라우저 표준도 일부 내비게이션 지연 문제를 해소할 수 있음 Speculation Rules API 참고

    • 네트워크와 서버가 빨라질 거라는 점은 SSR의 보편적 근거가 못됨 특정 서버에 컴퓨팅 파워가 더 많거나, 로직 분리가 어려운 케이스에 SSR이 필요하다는 예외적 상황을 들고 있는 셈임 실제로는 클라이언트 렌더링이 더 빠른 경우도 많음 렌더링 로직이 데이터 크기에 비해 훨씬 복잡할 때가 많고, 모든 클라이언트 리소스를 합치면 서버보다 클 수도 있음 SSR만이 유일한 옵션이었다면 Web Assembly에 대한 요즘의 열정이 설명이 안 됨 local computation에 대한 글도 참고할 만함 결국 어느 쪽이 더 나은지는 미리 알 수 없는 일이고, 요청 시점에 선택 가능해야 함

    • Right Tool For The Right Job! 예를 들어 Google Docs, Sheets 같은 협업 문서를 단순히 서버 사이드 렌더링만으로 작업할 수 있을까? SSR만 고집하면 사용자가 중간 편집 중 다른 사람이 컨텐츠를 바꿔버릴 수밖에 없다는 상황 발생함 이런 툴들은 변경사항 영향이 작고, 사용자가 협력 중임을 바로 인지하고 실시간 업데이트를 받기 때문에 잘 동작함 반면 호텔 예약 같은 서비스는 실시간 동기화가 필요 없음 또, 중간에 흔들리는 싱크나, 미리 설계가 부족한 엔터프라이즈 앱은 나중에 도메인, 시스템 복잡도로 인해 정합성 맞추기가 꽤 힘들어짐

    • 기존 SSR 앱에 아래와 같은 라이브러리를 쉽게 추가할 수 있다면 사용할 것임:

      • 50kb(gzipped) 크기
      • 지금이나 미래에 코드 변경 불필요
      • 오프라인/저대역폭 환경에서도 UX 저하 없이 자동 동기화 지원 그런게 있다면 바로 쓸 것임 SSR 옹호자들이 간과하는 문제는 오프라인/저대역폭 환경에서의 경험을 개발자 행복과 좋은 UX를 위해 희생할 필요가 있다고 가정하는 것임 심지어 미래 네트워크 개선까지 근거로 내세우기도 함 실제로 저대역폭 요구사항은 항상 중요한 장점임 특히 인터넷이 느린 지역, 외딴 곳, 혹은 Comcast 같은 환경에선 더욱 그렇다고 생각함

    • 이건 진짜 해피패스 엔지니어링임 현실은 해피패스에 있지 않은 사람들에겐 꽤나 좌절스러운 부분임

    • SSR의 현재와 미래의 주요 용도는 첫 페이지 로딩, 특히 모바일임 이후로는 클라이언트에서 상태 업데이트만 필요하니 모든 게 더 빨라야 함 엔지니어링 실력이 부족하면 SSR이 있어도 별 의미 없는 상황임

  • 나는 CRDT 기반, local-first 아키텍처의 오픈소스 태스크 관리 소프트웨어를 개발함 개발 동기는 협업 기능이 필요 없고, Linear 같은 툴은 내 사용 목적엔 지나치게 복잡했기 때문임 이런 아키텍처의 장점은 다음과 같음:

    1. 데이터를 로컬에 저장해서 반응 속도가 매우 빠름
    2. 전체 데이터베이스의 내보내기/불러오기가 매우 간편함
    3. 서버 로직이 경량화되어 성능 오버헤드와 개발 복잡도가 낮고, 모든 비즈니스 로직을 클라이언트에서 구현함
    4. 기능 개발이 단순해짐(로컬 로직만 작성하면 됨) 단점 또한 존재함:
    5. 텍스트 데이터만 적합하고, 이미지나 대용량 파일은 오브젝트 스토리지 등 별도 서비스 활용 권장
    6. 동기화 관련 코드는 개발 시 신중함이 매우 필요함(버그 시 심각한 문제 발생 가능)
    7. E2E 암호화와 협업 기능은 상대적으로 복잡함 기술 구성은 다음과 같음:
    8. Loro CRDT 오픈소스 라이브러리 기반으로, 나는 비즈니스 로직에만 집중함
    9. 데이터 처리 플로우: 사용자의 조작이 CRDT 모델을 갱신하고, 그 상태를 JSON으로 내보내 UI를 업데이트함 동시에 데이터를 로컬 DB에 저장하고 서버와 동기화함
    10. 로컬 저장소 계층은 list/save/read 세 가지 공통 인터페이스로 추상화했고, 플랫폼별로 IndexedDB(브라우저), 파일시스템(Electron), Capacitor Filesystem(iOS/Android) 이용함
    11. E2E 암호화 및 증분 동기화 구현함 서버·클라이언트 버전 기준으로 차이점을 산출하고, AES로 암호화 후 업로드함 서버는 base version + 증분 패치를 유지함 패치 누적량이 커지면 전체 DB를 암호화해서 새로운 base version으로 업로드해 이후 패치는 경량화 유지함 프로젝트에 관심 있다면, Hamsterbase Tasks 저장소를 참고 바람

  • Jazz에 매우 깊은 인상을 받음 DX가 엄청 좋아서 거의 동기적, 명령형 코드 작성이라 개발이 즐거움 뭐든 즉각적으로 느껴지고, 오프라인 작업도 가능해서 UX도 훌륭함 가장 큰 문제는 배포 및 장기 유지성인데, 데이터가 계속 커지는 점(대부분 클라이언트가 그걸 다 볼 필요는 없어서 별로 신경은 안 씀) 가장 큰 이슈는 자주 바뀌는 public index에 대해 좋은 솔루션이 부족하다는 점임 이론적으로 public readable list of ids는 가능한데, 최근 Anselm과 얘기해보니 해결 중이라고 함 전반적으로 local-first도 비용이 적지 않지만, Jazz가 전통적인 중앙 서버 방식의 주요 약점을 해결한다면 Firestore를 거의 모든 면에서 대체할 수 있을 거라 봄

    • Jazz는 정말 멋지다고 생각함 DX도 독보적임 내가 썼을 땐 passkey 기반 암호화만 제대로 지원돼서, Windows에선 잘 작동하지 않아 사실상 쓸 수 없었음 전통적 인증 방식도 곧 지원할 거라 생각함 무엇보다 E2E 암호화가 좋고, 사용 경험이 너무 재밌음

  • ElectricSQL과 TanStack DB 모두 훌륭하지만, 왜 웹에서 local first에 그토록 집중하는지 궁금함 모바일에서 오프라인 환경 때문에 local first가 훨씬 더 필요하다 생각함 웹 브라우저 사용하는 경우에는 어차피 인터넷이 대부분 연결된 상황임 게다가 이런 local-first 기술들은 이론상으로는 그럴싸하지만, 컨플릭트 해소가 따르지 않으면 실제론 쉽게 깨짐 모바일 앱을 local-first로 만드는 과정에서 겪은 교훈이고, 그래서 나는 CRDT를 쓰게 됨

    • 웹 기술로 local-first 앱을 만드는 건 네이티브와 비교하면 무한대로 더 어려움 네이티브 앱은 설치만 해도 오프라인 사용 가능이 기본값임 웹은 AppManifest, ServiceWorker 등 이상한 꼼수로 겨우 오프라인 지원을 얹어야 함 네이티브에선 30년 된 C 코드로 디스크에 파일을 자유롭게 읽고 쓰면 그게 다임 웹에선 IndexedDB는 진짜 악몽이고, localStorage는 규모가 커지면 쓸 수 없음, OriginPrivateFileSystem도 제한적임 사용자가 한 달에 한 번이라도 사이트에 방문하지 않으면 Safari가 로컬 브라우저 상태를 삭제해버림 JavaScript나 Emscripten으로 wasm 빌드 등 별 시도를 해도, async web API를 어떻게든 돌려가며 겨우 처리해야 함 Apple은 2015년부터 CoreData + CloudKit 조합으로 local+sync 완성판 솔루션을 제공함 구글 쪽은 Firebase가 아마 그나마 비슷하다 생각함

    • 나는 Replicache와 Zero 개발자로서, 왜 웹에 집중하는지 고민을 많이 해 봄 정답은 아직 모르겠지만 내 의견을 나누자면:

      • 웹의 장점: 빠른 피드백 루프, 게이트키퍼 없음 등, 전체적으로 난 웹이 더 좋음
      • 데스크톱/생산성 소프트웨어는 대부분 웹에서 이뤄짐, 나는 즉각적인 상호작용성을 생산성 앱에서 원함 하지만 모두가 클라이언트/서버 구조로 가면서 레이턴시가 여기저기 눈에 띔, 이걸 바꾸고 싶음
      • 이런 시스템들은 클라이언트 측에 고도의 분산 데이터베이스 로직이 필요함 언어 선택부터가 고민임 C++이나 Rust를 wasm으로 포팅하면 될 것 같지만 실제로는 JS가 가장 범용적이고, 웹과 모바일 모두에서 접근성이 가장 좋음(RN 등)
      • 실제로 복잡한 생산성 앱은 클라이언트 시스템이 복잡해서 대부분 웹기술을 쓰고, 하나의 언어(JS)로 구현함

    • 모바일은 웹보다 오프라인 원시 기능이 훨씬 강함 하지만 진짜 많은 생산성/협업은 웹에서 일어나고, 웹은 더 적대적인 환경임 탭간 상태 동기화, 저장소 삭제 등 복잡한 이슈가 있음 그래서 local first가 주로 웹 중심으로 발전함

    • 동기화 엔진들이 웹을 먼저 겨냥하는 건, 이 기술들이 아직 젊고, 업데이트가 많기 때문임 모바일 앱 업데이트는 정말 고통스럽지만 웹앱 업데이트는 훨씬 쉽기 때문임 PWA 역량도 이제 꽤 괜찮아졌다 생각함 iOS PWA도 푸시 알림이 되고, 나는 모바일 앱처럼 보이는 웹앱만으로도 충분히 만족함

    • 여기서 포인트는 ‘어떤 기능을 쓸 수 있느냐’가 아니라, 믿을 수 없을 만큼 빠르고 반응성 뛰어난 프로덕트에서 느끼는 ‘즐거움’임 그래서 local-first를 지향함

  • Local first/sync 엔진의 협업 측면이 많이 안 다뤄진 느낌임 나는 Zero를 활용해 친구의 비즈니스용 구글시트를 대체하는 프로젝트를 만들고 있음 Google Meet에서 실시간 같이 Sheet를 열어 데이터 다루는 상황임 이런 경험을 예전에는 웹앱으로 구현할 생각 못 했음 웹소켓으로 라이브 UI를 많이 만들어봤지만, 들어오는 데이터를 맞는 위치에 제대로 반영하고 관리하는 게 엄청 복잡함 데이터 셀이 수백, 수천 개면 그 혼란은 상상도 안 됨 Zero로는 쿼리로 데이터 선택, mutator로 데이터 변경하면 모두가 동일하게 바로 동기화됨 덕분에 정말 개발 자체가 즐거움

  • 나는 Google Docs가 처음 출시될 때(12살 때였음) 실시간 동기화와 협업 커서가 들어간 걸 보고, ‘앞으로 웹 경험은 저렇게 모두 협업형이 될 거구나’라고 생각함 당시 클라우드 컴퓨팅이 유행어였고, 나는 잘못된 생각이었지만 실시간 협업이 클라우드 컴퓨팅의 정의라고 믿기도 했음 근데 결국 그런 미래는 현실이 되지 않음 20년이 지났지만, 대부분 웹 제품은 여전히 CRUD 경험임(이 사이트조차 그렇고) 매번 혁신이 임박한 줄 알았음; Meteor.js, React, 등등 기대했는데 아직도 기본값이 아님 이런 게 정말로 메인스트림이 되길 계속 기대함, 언젠가는 결국 현실화될 것 같음 다만 생각보다 더 어렵고, 모든 상황에 쓸 만큼 툴링이 싸지지 않았을 뿐임

    • 실시간 협업의 예로는 Discord(본질적으로는 90년대 IRC와 그리 다르지 않음), Zoom(모든 화상회의) 등이 있음 HN 같은 사이트가 CRUD 앱이라는 건 장점임 실시간 업데이트가 오히려 산만해서 원치 않음

    • 빛의 속도가 실제로 한계임 지구 반 바퀴를 도는 데 빛이 56ms 걸림, 실제 신호는 더 우회하며, 변환과 추가 장벽(로드밸런서, DDOS 보호 등)에 의해 더 느려짐 레이턴시는 오히려 옛날보다 못한 경우도 많음

    • 나도 그 실시간성의 초반 마법을 느꼈지만, 그 미래는 아직도 어딘가에 남아있는 듯한 기분임 그럼에도 불구하고, 진짜 구글 Docs 스타일(입력창/전송 버튼 없는) 실시간 메시징 툴을 만들고 있음: kraa.io/hackernews

  • Local-First, Sync-Engines의 미래를 믿음 local-first 프레임워크 랜드스케이프의 다양한 테이블 정리가 정말 유익함 개인적으로 Triplit.dev가 가장 좋았고, 이걸 TanStack DB랑도 결합할 수 있음 PowerSync, NextGraph도 탐구하고 싶은 옵션임 최근 LocalFirst Conf 영상 중 NextGraph 관련 발표도 재미있게 보고 있음: YouTube 영상

    • 이런 툴들의 데이터베이스 마이그레이션 지원은 어떤지 궁금함 장기적으로 서버 접속이 없는 클라이언트를 지원해야 할 때, 아주 오래된 스키마 상태에서 롤포워드 마이그레이션하는 게 큰 장애가 아닐까 생각함 실제로 단일 사용자 프런트엔드 버그 트러블슈팅도 힘든데, 스키마 상태까지 고려해야 하면 복잡함이 상상 이상일 듯함

    • Meteor를 떠올리게 됨

    • 이런 접근법들 또한 과거의 방식들이기도 함

    • Triplit 꼭 써봐야겠음, InstantDB 써본 적 있는지 궁금함 나도 관심 있었는데 아직 못 써봄

  • 내가 Electric의 접근법을 꽤 좋아해서 오랫동안 주시해 왔음 Electric은 작성 복잡도를 개발자와 API에게 맡겨서 오히려 깔끔함 양방향 동기화 솔루션들은 대개 간단한 Todo 앱 수준에서만 잘 작동함 권한, 비즈니스 로직 진화, 마이그레이션, 제품 성장 등이 가미되면 내구성에 의문이 생김 Electric은 읽기 동기화만 view로 지원하고, 쓰기는 기존 API/rest/rpc에서 그대로 처리하니, 기존 프로젝트에 도입하기도 쉬움

  • 왜 couchdb / pouchdb는 목록에 없는지 의아함 여전히 꽤 잘 작동하는 도구임

    • ‘잘 작동한다’만으론 과소평가임 대부분의 local-first 솔루션들은 충돌 상황에서 언젠간 데이터를 잃음 그와 달리 couchdb/pouchdb는 충돌 해결에 최종적 권한을 개발자가 가짐 CRDT 진영 사람들은 데이터 안전성보다는 개발자 편의를 더 우선한다고 보임 이는 개인이 자신의 취향과 목적에 따라 선택할 수 있는 트레이드오프임 하지만 이런 데이터 안전성 이야기가 왜 항상 언급되지 않는지 이해가 잘 안 됨
답변달기