# LiveStore - 반응형 SQLite 와 내장 동기화 엔진을 사용하는 상태 관리 솔루션 > Clean Markdown view of GeekNews topic #21266. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21266](https://news.hada.io/topic?id=21266) - GeekNews Markdown: [https://news.hada.io/topic/21266.md](https://news.hada.io/topic/21266.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2025-06-04T09:31:02+09:00 - Updated: 2025-06-04T09:31:02+09:00 - Original source: [livestore.dev](https://livestore.dev) - Points: 27 - Comments: 2 ## Summary Prisma를 만들었던 개발자가 만든 것으로 **상태 관리 데이터 계층**과 **내장 동기화 엔진**을 결합하여 고성능 애플리케이션 개발을 지원하는 솔루션입니다. **반응형 SQLite**와 **로컬 우선(Local-first)** 아키텍처로 오프라인 환경에서도 신속한 데이터 연산과 자동 동기화를 지원합니다. ## Topic Body - **동기화 로직 개발**에 대한 부담없이, 고성능 애플리케이션 개발이 가능하도록 설계된 **상태 관리 데이터 계층** - 반응형(reactive) **SQLite**와 내장 동기화 엔진을 사용하는 것이 특징 - **로컬 우선(Local-first)** 으로 오프라인에서도 높은 성능을 제공하며, 네트워크 복구 시 자동 동기화 지원 - 모든 상태 관리 연산이 로컬 SQLite 데이터베이스 위에서 빠르게 수행됨 - **반응형 데이터 스트림**: 데이터 변경 시 즉시 UI와 연결된 리스너에 이벤트 발생, 상태 변화에 대한 실시간 반영 가능 - 다양한 환경(웹, 모바일, 데스크톱 등)에 적용할 수 있음 - 기존 **상태 관리 도구** 대비, 네이티브 성능 및 데이터 일관성에서 우수한 결과를 제공 ## Comments ### Comment 39716 - Author: laeyoung - Created: 2025-06-04T12:10:49+09:00 - Points: 2 홈페이지 메인에 있는 Demo 진짜 잘 만들었네요. Demo 클릭 좀 하다보니, 써보고 싶어질 만큼. ### Comment 39701 - Author: neo - Created: 2025-06-04T09:32:01+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44105412) * 안녕하세요, LiveStore의 **코파운더**임 (이전에는 Prisma를 만들었음). 지난 4년간 Overtone이라는 네이티브급 **고성능 뮤직 클라이언트**를 만들면서 스스로 사용하려고 LiveStore를 개발하게 되었음. LiveStore는 SQLite에 **반응형 신호 레이어**를 추가하고, **이벤트 소싱 기반 싱크**(Git과 유사)를 결합함 * 로컬 퍼스트 환경을 다양하게 평가해봤는데, LiveStore만큼 깔끔하게 해결하는 솔루션은 거의 없었음 유사하게 성숙된 툴로는 tinyBase도 있지만, 그건 구조가 다름(CRDTs vs 이벤트 소싱) 궁금한 점이 있는데, 왜 데이터 용량을 1GB로 제한했는지, 더 큰 데이터를 **SQLite에 저장**하고 디스크에 남길 수 있도록 옵션을 둘 순 없는지 묻고 싶음 단순히 설정만으로 퍼시스턴스 모드를 바꿀 수 있지 않을까? **멀티 테넌시**도 흥미로운 시나리오가 될 수 있다고 생각함 JIRA처럼 각 조직이 별개 네임스페이스를 요구할 때, 각 사용자도 전체 티켓이 아니라 자신의 팀/부서만 받도록 할 수 있으면 좋겠음 기본적으로 로컬 데이터베이스가 전체 데이터의 **서브셋**이 되는 구조임 Bun/Node에서 바로 실행 가능한 싱크 서버(Cloudflare 필요 없음)가 박스에 들어있다면 정말 멋질 듯 현재 내가 검토 중인 프로젝트 아이디어에도 잘 맞을 것 같음 특히 **멀티 테넌시**가 반드시 필요하기 때문임 * 지난달에 LiveStore를 취미 프로젝트에 써볼까 해서 확인해봤는데, 베타 프리뷰라 접근이 어려웠음 곧 더 깊이 살펴볼 수 있기를 희망함 로컬 퍼스트 관련 논의를 **적극적으로 이끄는** 모습이 인상적임 오프라인 동기화 가능한 웹앱을 만들어본 사람이라면 **싱크 엔진의 유용함**을 바로 깨닫게 됨 * 오늘 Local-First Conf에서 발표 정말 잘 들었음 **이벤트 소싱을 SQLite로 구현하는** 구조에 대한 설명이 명확하고 설득력 있었음 SQLite, 특히 **OPFS Wasm SQLite**를 웹에서 적극적으로 홍보해 줘서 고마움 PowerSync도 SQLite를 강력히 지지하는 입장이라, LiveStore 같은 성공사례가 반갑게 느껴짐 * LiveStore가 이벤트 소싱 모델을 글로벌하게 확장할 때 모든 클라이언트에 보통 **중앙 싱크 백엔드**를 두고 동기화하는데, 이게 필수 요건인지 궁금함 혹시 **연합형 노드(federated nodes)** 또는 완전한 **P2P 모드**도 가능한지 묻고 싶음 분산 SNS 사례에 대한 적용도 고려 중임 * React, WASM과 조합해서 LiveStore가 대부분의 뮤직앱들이 쓰는 **Juce 프레임워크**를 대체할 수 있을지 궁금함 나는 비트메이커인데, Juce랑 C++ 조합은 항상 어렵고 두려웠음 음악앱 개발에 진입하려는 사람에게 LiveStore가 좋은 대안이 될 수 있을지 알고 싶음 * Local-first Conf에서 발표를 봤는데, 요즘 정말 다양한 **싱크 엔진**이 등장하고 있음 LiveStore는 이벤트 소싱과 싱크 엔진을 조합하는 흥미로운 영역을 깊이 파고드는 중임 벌써 이렇게 **견고한 시스템**이 되었다는 점에 놀랐음 최근 몇 주간 새로운 프로젝트에 직접 써봤는데, 정말 **매끄럽게 동작**하고 있음 * 런칭을 축하함! 이 시스템이 여기에 설명된 **"[1. Serialization](https://mattweidner.com/2024/06/04/server-architectures.html#1-serialization)"** 전략에 들어맞는지 궁금함 ProseMirror-collab에서 언급된 것처럼, 자주 업데이트하는 **저지연 클라이언트**가 고지연 클라이언트의 업데이트를 **가로막게 되는 문제**가 LiveStore에도 나타날지 묻고 싶음 * LiveStore가 **wa-sqlite**을 쓰는 것 같음 오프라인 데이터 영속성 전략을 자세히 듣고 싶음 구체적으로 OPFS(AccessHandlePoolVFS 같은 변종)나 IndexedDB 중 어떤 쪽을 사용하는지, 혹은 둘 다인지 궁금함 또한 OPFS의 브라우저 간 **불안정성**과 Safari IndexedDB의 **7일 보관 정책**에는 어떻게 대응하고 있는지 궁금함 SQLite에서 공식 WASM 빌드를 제공하는데도 wa-sqlite를 쓴 이유가 있는지 알고 싶음 * 최근 LocalFirst.fm 팟캐스트에서 LiveStore를 간단히 소개했음 (https://www.localfirst.fm/24 링크 참고) * 에피소드 공유 고마움, 곧 LiveStore 단독 에피소드도 준비할 예정임 * 매우 기대되는 프로젝트로 보임 하지만 **과도한 기대감(하이프 트랩)** 에 빠지지 않을까 살짝 조심스럽기도 함 비슷하게 **로컬 퍼스트 앱**을 커스텀으로 만들면서 멀티 디바이스 지원을 실험 중임 **E2E 암호화**를 선택적으로 추가하는 것도 가능할지 궁금함 문서상으로 이벤트 페이로드 단위로 **암호화**를 추가하면 될 것 같은데, 서버 로그 압축이 어려워지는 점만 빼면 거의 가능할 듯함 * "하이프 트랩"에 대한 의견에 동의함 나는 Overtone 작업하면서 생긴 필요를 바탕으로 LiveStore를 직접 만들고 있음 LiveStore/Overtone 모두 **장기적인 지속성**을 목표로 제작 중임 E2E 암호화는 **이미 구현 가능**한 구조임 내가 직접 해보진 않았지만, 문제 있으면 언제든 도움을 줄 수 있음 **클라이언트 측**에서만 압축(log compaction)을 시도하는 것도 하나의 방법이 될 것 같음 엔지니어링하면서 이 유스케이스도 꼭 염두에 둘 예정임 * 크로스 플랫폼 지원이라는 주장에 **회의적**임, 가장 처음에 보인 게 안드로이드 웹 미지원임 * 좋은 지적임 안드로이드/크롬 팀과 **기술적 이슈**에 대해 계속 소통 중임 3년 전쯤부터 원인을 파악했지만 여전히 해결되지 않고 있어서, LiveStore가 **별도 우회책**을 마련해야 할 것으로 보임 진행 상황은 공식 깃허브(https://github.com/livestorejs/livestore/issues/321)에서 확인 가능함 웹 API 지원이 플랫폼마다 달라서, 이런 **야심찬 시스템**을 만들려면 굉장히 많은 노력과 시간이 필요함을 이해해주길 바람 * 데모 영상에서 흥미로운 점 하나! 1분 7초 부분에서 **오디오가 좌측으로 몰림** 현상이 있었음 사소하지만 참고하면 좋을 것 같아서 알려드림 * 개발자 도구를 같이 제공하는 게 인상적임, 상당기간 **자체 프로젝트**에서 테스트해온 것 같음 궁금한 점은, **장기적으로 실행되는 앱/페이지의 compaction**을 어떻게 처리할 생각인지, 그리고 **이벤트 소싱**은 멋진 개념이지만 애플리케이션 레이어가 발전할수록 **코드 관리**(구버전 클라이언트, 스키마 마이그레이션 등)가 어려워질 수 있음 Overtone은 여러 소스를 지원하는 것 같은데, **오프라인 재생**도 제공할지 궁금함 특히 Spotify UI가 불편해서 대체제가 절실함 * 좋은 질문임! compaction에 대해선 많은 문의가 있었고, 곧 해결책을 공개할 예정임 핵심 아이디어는 각 이벤트에 더 많은 **의미 정보를 부여**해 이벤트 간 겹침을 정의할 수 있게 만드는 것임 예를 들어 todo 앱에서는 동일 작업 ID에 대한 "todoCompleted" 이벤트가 해당 작업의 "todoCompleted"/"todoUncompleted" 이벤트들을 **압축**시킬 수 있다는 원리임 진행 상황은 깃허브(https://github.com/livestorejs/livestore/issues/254)에서 확인 가능함 이벤트 소싱은 확실히 **규율과 설계**가 중요함 데이터에는 "공짜 점심"이 없기 때문에 트레이드오프가 핵심임 Overtone 등 내 주요 용도에선 이벤트 소싱의 트레이드오프가 더 낫다고 느끼고 있음 구버전 지원 등은 **간단한 방법**이 여러 가지 존재함, 결국엔 각 애플리케이션 특성과 트레이드오프에 달려 있음 Overtone에 흥미 가져줘서 고마움. 나도 Spotify의 불만족 때문에 이 프로젝트를 시작했음 오프라인 재생의 경우 **음원 제공처**에 따라 달라짐 예를 들어 Dropbox 등 본인 소장 앨범은 지원할 수 있지만 Spotify 등 스트리밍 서비스는 **정책**에 따라 다를 수 있음 * 이 아키텍처가 마음에 듦, 특히 **이벤트 소싱**이 좋음 하지만 이벤트 소싱에는 주의가 필요함 원하는 뷰에 따라 **머티리얼라이즈**(view materialization)가 느릴 수 있고, 데이터가 커질수록 점점 더 느려짐 이에 대한 해결책은 트리거 등으로 **트랜잭션 내에 머티리얼라이즈 갱신**을 직접 관리해야 함 복제 또는 싱크할 때도 고려해야 하고, **충돌 해결**에 대해서도 CRDT 개념을 반드시 익혀둘 필요가 있음 **Postgres 언어 기능이 있는 SQLite3 비슷한 데이터베이스**가 있으면 local-first와 remote-first를 그냥 설정만 바꿔가며 쓸 수 있어 정말 좋겠음 * 마지막 의견 관련 pglite.dev(https://pglite.dev)를 참고하면 좋음 머티리얼라이즈 비용에 대한 본론에서는, compaction은 앞으로 더 개선할 예정이고, LiveStore 전체가 **성능 최적화**를 목표로 세심하게 설계된 프레임워크임