웹앱 하나 만드는 데 왜 이렇게 많은 게 필요할까요
요즘 간단한 도구 하나 만들려고 해도 준비할 게 참 많죠. 프론트엔드 프로젝트 세팅하고, 데이터 저장하려면 백엔드 서버에 데이터베이스까지 붙여야 하고, 어디엔가 배포도 해야 하고요. 나 혼자 쓸 가계부나 독서 기록 앱인데도 말이에요. Capsule은 바로 이 지점을 파고든 프로젝트예요. 핵심 아이디어는 딱 하나예요. "웹앱은 파일 하나로 충분하고, 데이터는 SQLite에 저장한다."
이게 왜 흥미로운 접근인지, 그리고 기술적으로 어떻게 가능한지 차근차근 풀어볼게요.
단일 파일 웹앱이 뭐냐면
보통 웹앱은 HTML, CSS, JavaScript 파일이 여러 개로 나뉘어 있고, 서버가 그걸 브라우저에 내려주는 구조거든요. 단일 파일 웹앱은 이 모든 걸 HTML 파일 하나에 몽땅 집어넣은 거예요. 스타일도 <style> 태그 안에, 로직도 <script> 태그 안에 다 들어 있어요. 그래서 그 파일을 더블클릭하면 브라우저에서 그냥 열리고, 앱이 바로 실행돼요. 서버가 필요 없죠.
이 방식은 사실 꽤 오래된 전통이 있어요. TiddlyWiki라는 개인 위키 도구가 2000년대 중반부터 이 방식으로 유명했거든요. HTML 파일 하나가 위키 전체이고, 내용을 수정하면 그 파일 자체를 다시 저장하는 식이었어요. 문제는 "데이터를 어디에 어떻게 저장하느냐"였어요. 브라우저의 localStorage는 용량이 몇 MB 수준으로 작고, 문자열밖에 못 넣어서 구조화된 데이터를 다루기엔 불편하거든요.
그래서 SQLite가 등장해요
SQLite가 뭐냐면, 서버 없이 파일 하나로 동작하는 관계형 데이터베이스예요. 여러분 스마트폰 안에도 수십 개가 돌아가고 있을 만큼 세상에서 가장 많이 배포된 데이터베이스이기도 하고요. 원래는 C로 짜인 라이브러리라 브라우저에서 못 썼는데, WebAssembly(웹어셈블리, 브라우저에서 C 같은 언어로 짠 코드를 거의 네이티브 속도로 돌리는 기술) 덕분에 지금은 브라우저 안에서도 진짜 SQLite가 돌아가요. SQLite 공식 팀이 직접 관리하는 sqlite-wasm 빌드도 있고, 그보다 먼저 나온 sql.js도 있어요.
그런데 브라우저 안에서 SQLite를 돌리는 것과, 그 데이터를 "영구히 보관"하는 건 또 다른 얘기예요. 여기서 두 가지 길이 있어요.
첫째는 OPFS(Origin Private File System)예요. 브라우저가 사이트별로 마련해주는 비공개 저장 공간인데, 여기에 SQLite 파일을 통째로 두고 읽고 쓰는 방식이에요. 성능이 꽤 좋아서 사실상 로컬 데이터베이스처럼 쓸 수 있어요. 둘째는 File System Access API로 사용자의 실제 디스크에 있는 .sqlite 파일을 직접 열고 저장하는 방식이에요. 이 경우엔 데이터가 진짜 파일로 남아서, 다른 SQLite 도구로 열어보거나 복사해서 백업하는 게 자연스러워져요.
Capsule은 이 조합을 "앱을 만드는 기본 틀"로 제시한 셈이에요. 세부적으로 어떤 저장 방식을 택했는지, 앱을 어떤 형식으로 작성하게 하는지는 공식 사이트에서 직접 확인해보시는 게 정확할 텐데요. 중요한 건 방향성이에요. 앱 코드도 파일 하나, 데이터도 파일 하나. 서버는 없음.
이 접근이 주는 실질적인 이점
이렇게 하면 뭐가 좋을까요? 우선 배포가 사라져요. 파일을 메일로 보내거나 USB에 담아 넘기면 그게 곧 배포예요. 백업도 파일 복사가 전부고요. 그리고 데이터가 SQLite라는 표준 포맷이라서, 앱이 없어지거나 개발이 중단되어도 데이터는 살아남아요. DB Browser for SQLite 같은 도구로 언제든 열어볼 수 있으니까요. 이건 "내 데이터는 내가 소유한다"는 로컬 퍼스트 철학과 정확히 맞닿아 있어요.
또 하나, SQL을 그대로 쓸 수 있다는 점이에요. localStorage에 JSON을 통째로 넣고 빼면서 직접 필터링하던 걸 SELECT ... WHERE ... ORDER BY로 처리할 수 있으니, 데이터가 수만 건으로 늘어나도 감당이 돼요.
업계 흐름에서 보면
최근 몇 년 사이 "로컬 퍼스트(local-first)"라는 흐름이 꽤 커졌어요. 연구 그룹 Ink & Switch가 이 개념을 정리한 뒤로, 데이터는 사용자 기기에 먼저 두고 서버는 동기화 보조 역할만 하자는 도구들이 많이 나왔거든요. PostgreSQL을 WASM으로 브라우저에서 돌리는 PGlite, 클라이언트 쪽 SQLite와 서버를 동기화해주는 ElectricSQL, SQLite를 클라우드 에지에서 서비스하는 Turso 같은 것들이요.
Capsule은 이 스펙트럼에서 가장 단순한 끝에 있어요. 동기화도, 협업도, 계정도 없이 "일단 내 컴퓨터에서 파일 하나로 완결되는 앱"에 집중한 거예요. 마크다운 파일이 곧 데이터인 Obsidian이 노트 앱에서 그런 위치라면, Capsule은 그걸 범용 웹앱 쪽으로 가져온 느낌이라고 보시면 돼요.
한국 개발자에게는
당장 써볼 만한 곳이 꽤 있어요. 팀 내부용 작은 도구, 예를 들어 온콜 로테이션 관리나 회의실 예약 같은 것들은 굳이 서버 띄울 필요 없이 이런 식으로 만들면 운영 부담이 확 줄어요. 개인 프로젝트나 해커톤 프로토타입에도 딱이고요. SQL을 배우는 주니어라면, 브라우저에서 바로 쿼리 결과를 보면서 연습하는 교재로도 좋아요.
다만 조심할 점도 있어요. OPFS나 File System Access API는 브라우저마다 지원 시점과 범위가 달라서, 특히 Safari나 모바일 브라우저에서는 동작이 다를 수 있어요. 그리고 "서버가 없다"는 건 "여러 기기에서 동기화가 안 된다"는 뜻이기도 해요. 혼자 한 기기에서 쓰는 용도로 시작하되, 나중에 동기화가 필요해지면 그때 ElectricSQL 같은 걸 얹는 식으로 단계적으로 가는 게 현실적이에요.
정리하면
웹앱 코드도 파일 하나, 데이터도 SQLite 파일 하나, 서버는 없음. 이 단순함이 Capsule의 전부이자 핵심이에요.
여러분은 어떠세요? 사내 도구나 개인 프로젝트 중에 "이건 굳이 서버가 필요 없었는데" 싶은 게 있었나요? 그리고 브라우저 안의 SQLite를 실제 프로젝트에서 써보신 분 계시면 성능이나 호환성 경험도 나눠주세요.
🔗 출처: Hacker News