'SQLite는 장난감'이라는 편견
SQLite 하면 어떤 이미지가 떠오르세요? 모바일 앱 로컬 저장소, 개발할 때만 쓰는 임시 DB 정도로 생각하는 분이 많을 텐데요. 요즘 이 인식이 빠르게 바뀌고 있어요. 서버 한 대로 돌아가는 서비스라면 Postgres나 MySQL 대신 SQLite를 프로덕션 데이터베이스로 쓰는 사례가 늘고 있거든요. 별도의 DB 서버가 없으니 네트워크 왕복이 사라져서 쿼리가 마이크로초 단위로 끝나고, 운영할 것도 백업할 것도 파일 하나뿐이에요. 다만 제대로 쓰려면 알아야 할 것들이 있는데, 그 핵심이 WAL 모드, 동시성 처리, 그리고 VFS 계층이에요. 하나씩 풀어볼게요.
WAL 모드가 뭐냐면요
SQLite의 기본 동작은 '롤백 저널' 방식이에요. 데이터를 고치기 전에 원본을 저널 파일에 백업해두고, 본 파일을 직접 덮어쓰는 방식인데요. 문제는 쓰기가 진행되는 동안 읽기가 막힌다는 거예요. 웹 서버처럼 읽기와 쓰기가 뒤섞여 들어오는 환경에서는 치명적이죠.
WAL(Write-Ahead Logging)은 이 순서를 뒤집어요. 본 파일은 건드리지 않고, 변경 내용을 별도의 WAL 파일에 차곡차곡 '추가'만 하는 거예요. 읽는 쪽은 자기가 시작한 시점의 스냅샷을 보면 되니까, 누가 쓰고 있어도 기다릴 필요가 없어요. 읽기와 쓰기가 서로를 막지 않게 되는 거죠. 웹 서버에 SQLite를 쓴다면 WAL은 선택이 아니라 필수예요. PRAGMA journal_mode=WAL 한 줄이면 켜져요.
실전 튜닝 포인트들
그런데 WAL만 켠다고 끝이 아니거든요. 실전에서 중요한 설정 몇 가지를 볼게요. 먼저 PRAGMA synchronous=NORMAL이에요. 기본값인 FULL은 매 트랜잭션마다 디스크 동기화를 강제해서 안전하지만 느린데, WAL 모드에서는 NORMAL로 낮춰도 DB가 깨지지 않아요. 최악의 경우 마지막 몇 트랜잭션만 잃을 수 있는 정도라, 대부분의 서비스에서 합리적인 절충이에요.
다음은 동시성이에요. WAL에서도 '쓰기는 한 번에 하나'라는 원칙은 그대로거든요. 두 커넥션이 동시에 쓰려고 하면 한쪽이 SQLITE_BUSY 에러를 받는데, 이걸 우아하게 처리하는 방법이 busy_timeout 설정(락이 풀릴 때까지 지정 시간만큼 기다리기)과 BEGIN IMMEDIATE(트랜잭션 시작 시점에 미리 쓰기 락 잡기)예요. 실무에서 흔한 패턴은 쓰기 전용 커넥션 하나에 읽기 커넥션 여러 개를 두는 구조고요. WAL 파일이 무한정 커지지 않도록 주기적으로 wal_checkpoint를 실행해서 본 파일에 병합해주는 것도 잊으면 안 돼요.
VFS: SQLite의 숨은 확장 포인트
마지막으로 VFS(Virtual File System)인데요. 이게 뭐냐면, SQLite가 실제 파일시스템과 대화할 때 거치는 추상화 계층이에요. '파일을 읽어라, 써라, 잠가라' 같은 요청이 전부 이 계층을 통과하거든요. 그런데 이 계층을 내 코드로 갈아끼울 수 있어요. 이 지점에서 마법 같은 일들이 벌어져요. 디스크 쓰기를 가로채서 다른 서버로 복제하는 LiteFS, 브라우저 안에서 SQLite를 돌리는 WASM 구현들이 전부 커스텀 VFS를 활용한 사례예요. 암호화, 압축, 네트워크 스토리지 연동도 이 계층에서 해결할 수 있고요.
업계 맥락에서 보면
SQLite 프로덕션 활용은 확실한 흐름이 됐어요. 실시간 복제 백업을 제공하는 Litestream, SQLite를 포크해서 엣지 DB로 키우는 Turso(libSQL), Cloudflare의 D1까지, 'SQLite를 서버에서 진지하게 쓰기 위한' 생태계가 계속 자라고 있거든요. Rails 8이 프로덕션 SQLite 지원을 대폭 강화한 것도 같은 맥락이에요. '기본은 SQLite로 시작하고, 정말 필요해질 때 Postgres로 가라'는 조언이 더 이상 이상하게 들리지 않는 시대예요.
한국 개발자에게 주는 시사점
사이드 프로젝트나 초기 스타트업 서비스라면 SQLite는 진지하게 검토할 가치가 있어요. DB 서버 비용이 0원이고, 배포는 파일 복사고, 백업은 Litestream에 맡기면 되거든요. 트래픽이 서버 한 대를 넘어설 때 고민해도 늦지 않아요. 다만 쓰기가 매우 많은 워크로드나 여러 서버가 하나의 DB를 공유해야 하는 구조라면 여전히 Postgres가 맞고요. 중요한 건 '기본값이라서'가 아니라 워크로드를 보고 고르는 거예요.
한줄 정리: WAL 모드와 몇 가지 튜닝만 알면, SQLite는 서버 한 대 규모에서 가장 운영하기 쉬운 프로덕션 DB입니다.
여러분은 프로덕션에서 SQLite를 써본 경험이 있나요? 어느 규모까지 버티던가요?
🔗 출처: Hacker News