Local‑First 로 가는 길: Supabase에서 Electron + IndexedDB 스택으로 이동

발행: (2026년 4월 9일 오후 06:39 GMT+9)
5 분 소요
원문: Dev.to

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

0 조회
Back to Blog

관련 글

더 보기 »

Web Component UI Kit를 만들었습니다.

배경: 나는 어느 날 갑자기 UI kit을 만들기로 결심한 것이 아니다. 내가 만든 대부분의 것들처럼, 이것도 내가 겪은 문제에 대한 해결책으로 시작되었으며, 아무도 사용하지 않을 프로젝트를 위해서였다.