Local‑First 로 가는 길: Supabase에서 Electron + IndexedDB 스택으로 이동
Source: Dev.to
나는 기업의 “C# 샵” 분위기에서 벗어나 나만을 위한 무언가를 만들기로 했습니다: 곧 시작할 프리랜스 경력을 위한 작업 로그 및 청구 도구. 도구가 형태를 갖추면서, 다른 프리랜서들도 간단한 로컬‑퍼스트 솔루션을 원할 수도 있겠다는 생각이 들어 공개 릴리스를 위해 다듬었습니다.
단순한 “학습 프로젝트”로 시작했지만 16개월에 걸친 아키텍처 여정이 되었습니다. 6개월 동안 앱을 세 번이나 재구축하면서 “현대적인” 클라우드 복잡성을 차례로 없애 결국 진정으로 중요한 것, 신뢰성에 도달했습니다.
Phase 1: The Cloud Liability (Supabase)
표준 현대 스택인 SvelteKit + Supabase 로 시작했습니다. 처음엔 기분이 좋았지만… 그렇지 않았습니다.
The Friction
프리랜서로서 내 데이터는 절대 양보할 수 없는 자산입니다. Row Level Security (RLS) 정책을 다루는 것이 개인 도구에 필요 없는 “추가” 세금처럼 느껴졌습니다.
The “Wake Up” Call
Supabase가 비활성 상태(무료 티어의 현실) 때문에 프로젝트가 “잠들 것”이라는 메일을 계속 보내왔습니다. 또한 고객의 비공개 프로젝트 데이터가 아무리 안전하다고 주장하더라도 누군가의 클라우드에 남는 것이 싫다는 것을 깨달았습니다.
The Pivot
로컬‑퍼스트 로 전환하기로 결정했습니다.
Phase 2: The Persistence Puzzle (Dexie & IndexedDB)
클라우드를 IndexedDB 로 교체하고 Dexie.js 를 사용해 직접 SQL 쿼리에서 반응형 클라이언트‑사이드 데이터 레이어로 전환했습니다.
The Win
- 100 % 프라이버시
- 지연 시간 제로
- “잠자는 주기” 없음
The Lesson
프라이버시는 단순한 기능이 아니라 아키텍처 선택입니다. 서버를 제거함으로써 가장 큰 실패 지점을 없앴습니다.
Phase 3: The Distribution Dilemma (PWA vs. Electron)
로컬‑퍼스트 앱을 어떻게 배포할까요?
- The PWA Attempt – “Service Worker Wall” 은 실재합니다. 브라우저가 기록을 지우거나 캐시를 삭제할 수 있다는 점은 재무(청구) 데이터에 너무 위험합니다. 100 % 오프라인 기능을 보장할 수 없으면 배포할 수 없습니다.
- The Tauri Wall – Rust/Tauri 가 마음에 들었지만 내 개발 환경은 완전히 컨테이너화돼 있습니다. Tauri 가 호스트 OS의 그래픽 라이브러리에 연결해야 하는 점이 감당하기 어려운 마찰을 만들었습니다.
- The Electron Solution – 결국 Electron 으로 결정했습니다. 번들 크기가 크고 자체 Chromium 을 포함하지만 작동합니다. 데이터가 머신에 남고 브라우저 상태와 무관하게 앱이 동작하는 자체 포함된 보장된 환경을 제공합니다.
Reflections of a “Legacy” Dev in a Modern World
이 여정을 통해 .NET 에서 18 년간 “논리 구축”을 해온 경험이 Svelte 와 Electron 같은 현대 스택에도 적용될 수 있다는 것을 배웠습니다. 기업의 “마음‑세금” 패턴을 포기하고 내가 실제로 제어할 수 있는 스택으로 전환했습니다.
Explore the Project
- Grab the Free Portable .exe – 로컬‑퍼스트 성능을 직접 확인해 보세요.
- Technical Showcase & Specs – 아키텍처와 사양에 대한 추가 정보.