프론트엔드에서 데이터를 다루는 일은 여전히 불편합니다. localStorage는 5MB짜리 문자열 창고이고, IndexedDB는 JOIN 한 번 하려면 커서를 돌려야 하며, 진짜 데이터베이스는 늘 서버 너머에 있습니다.
이 발표에서는 브라우저 안에 숨어 있는 파일시스템(OPFS) 위에 오픈소스 Rust 임베디드 DB를 얹어, 프론트엔드를 위한 SQL 데이터베이스를 만든 과정을 공유합니다. GlueSQL.js에 기여하며 실제로 배포까지 마친 이야기입니다. 쓰는 쪽에서는 import 한 줄과 SQL이 전부입니다.
다루는 내용
오프닝 — 일단 보여드립니다 (3분)
- 발표를 데모로 시작합니다. 브라우저에서 SQL로 테이블을 만들고, 새로고침과 브라우저 재시작 후에도 데이터가 남아 있는 것을 보여드립니다. 서버는 없습니다.
Sector 1 — 왜 만들었나 (4분)
- localStorage와 IndexedDB로 데이터를 다루면서 아쉬웠던 점들을 짚어봅니다. 데이터에 관계가 생기는 순간 조회 코드가 금방 복잡해집니다.
- 같은 일을 SQL로 하면
GROUP BY한 줄이면 됩니다. WASM으로 브라우저 SQL이 부활하고 있는 흐름도 짧게 소개합니다.
Sector 2— GlueSQL.js로 할 수 있는 것들 (12분)
gluesql/opfs— 오프닝에서 본 영속성입니다. import 한 줄이면 되고, 용량은 GB 단위, 쿼리는 Worker에서 돌아 UI를 막지 않습니다. namespace 옵션으로 앱마다 DB 파일을 분리할 수도 있습니다.gluesql/opfs/shared— 탭을 몇 개 열어도 하나의 DB입니다. 내부에서는 리더 선출과 failover가 돌아가지만, 코드는 import 한 줄만 바꾸면 됩니다.- 라이브 데모: 탭 3개가 하나의 DB에 쓰다가 리더 탭을 강제 종료해도, 옆 탭이 이어받아 계속 동작합니다.
- 스토리지 선택 가이드 — 데이터 성격에 따라 memory / localStorage / opfs / opfs/shared를 골라 쓰고, 서로 다른 스토리지의 테이블을 JOIN으로 묶을 수도 있습니다. SQL은 전부 동일합니다.
- 백엔드가 생겨도 같은 파일 포맷이라 파일 복사로 옮길 수 있습니다. Node.js에서도 같은 SQL이 돌아 테스트 코드에 그대로 쓸 수 있습니다.
npm install gluesql로 바로 시작할 수 있습니다.
Sector 3 — 어떻게 만들었나 (8분)
- OPFS는 동기 API인데 Worker에서만 쓸 수 있습니다. 이 제약을 Worker 프록시 구조로 풀어낸 과정을 설명합니다.
- 스토리지 엔진을 직접 구현했다가 걷어낸 이야기도 합니다. 로그 포맷과 리플레이 복구까지 만들었지만, 유지 비용을 생각해 Rust 임베디드 DB(redb)를 조합하는 쪽으로 바꿨습니다. 어댑터는 메서드 5개면 충분했습니다.
대상 청중
- localStorage와 IndexedDB가 아쉬웠던 프론트엔드·웹 개발자
- 서버 없이 사이드 프로젝트나 프로토타입, 사내 도구를 만들고 싶은 개발자
- OPFS와 WASM 기반 브라우저 DB가 궁금한 개발자
- SQL 기초만 있으면 충분합니다. Rust나 WASM 지식은 필요 없습니다.
