바이브코딩으로 간단한 MVP 하나를 만들고 싶은데, PostgreSQL까지 설치하고 관리하기는 부담스러울 때가 있습니다.
그럴 때 많이 선택하는 데이터베이스가 SQLite3입니다. 저도 몇몇 개인 프로젝트에서 사용해 봤고, 지금도 간단한 서비스에는 SQLite3를 사용하고 있습니다.
SQLite3는 별도의 DB 서버 없이 파일 하나로 사용하는 관계형 데이터베이스입니다. 서버 주소, 포트, 계정을 설정하지 않아도 테이블, 관계, 인덱스, 외래 키, 트랜잭션 같은 기본 기능을 충분히 사용할 수 있습니다.
그렇다고 검증되지 않은 간이 DB는 아닙니다.
SQLite는 2000년 미국의 개발자 D. Richard Hipp가 만들기 시작했으며, 현재도 꾸준히 관리되고 있는 오픈소스 데이터베이스입니다. 안드로이드와 아이폰의 여러 앱, Chrome, Firefox, Windows, Adobe 제품을 비롯해 수많은 기기와 소프트웨어에서 사용되고 있습니다.
즉, SQLite의 Lite는 기능이나 신뢰성이 부족하다는 뜻이 아니라 설치와 운영이 가볍다는 의미에 가깝습니다. 이름 뒤의 3은 현재 널리 사용되는 세 번째 주요 버전을 뜻합니다.
SQLite3는 이런 경우에 좋습니다
- 아이디어를 빠르게 검증하는 MVP
- 개인 프로젝트나 소규모 웹서비스
- 내부 관리 도구
- CLI 및 자동화 프로그램
- 데스크톱·모바일 앱
- 조회가 많고 데이터 저장은 자주 발생하지 않는 서비스
SQLite3를 선택할 때는 단순한 사용자 수보다 동시에 발생하는 쓰기 작업의 양이 더 중요합니다.
방문자가 많아도 대부분 조회만 한다면 충분히 사용할 수 있습니다. 반대로 사용자는 적더라도 주문, 결제, 댓글, 채팅처럼 여러 요청이 동시에 데이터를 저장한다면 잠금 문제가 발생할 수 있습니다.
AI에게는 WAL 모드까지 요청하세요
AI에게 단순히 “SQLite3로 만들어줘”라고만 하지 말고 다음과 같이 요청하는 것이 좋습니다.
SQLite3를 사용하고 WAL 모드와 busy_timeout을 설정해 주세요. 외래 키 검사를 활성화하고, DB 파일은 웹 공개 경로 밖의 영구 저장소에 보관해 주세요.
대표적인 설정은 다음과 같습니다.
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA foreign_keys = ON;
WAL 모드를 사용하면 데이터를 쓰는 중에도 다른 요청이 기존 데이터를 읽을 수 있어 읽기와 쓰기의 동시성이 좋아집니다.
busy_timeout은 DB가 잠겼을 때 바로 오류를 발생시키지 않고 일정 시간 기다리게 해줍니다.
다만 WAL 모드가 SQLite3를 PostgreSQL처럼 만들어주는 것은 아닙니다. SQLite3는 WAL 모드에서도 실제 쓰기 작업을 기본적으로 한 번에 하나씩 처리합니다.
나중에 PostgreSQL로 옮길 수 있을까요?
pgloader 같은 도구를 이용하면 SQLite3의 스키마와 데이터를 PostgreSQL로 옮길 수 있습니다.
하지만 완전한 원클릭 이전은 아닙니다.
날짜와 시간, 데이터 타입, 자동 증가 ID, 외래 키, SQLite 전용 쿼리 등을 직접 확인해야 합니다. 서비스가 커지고 데이터가 많이 쌓인 뒤에는 이전 테스트와 데이터 검증까지 필요해 생각보다 복잡해질 수 있습니다.
향후 이전 가능성이 있다면 AI에게 다음 조건도 함께 요청하는 편이 좋습니다.
향후 PostgreSQL 이전을 고려해 공통 데이터 타입과 ORM을 사용하고, SQLite 전용 문법에는 과도하게 의존하지 마세요. 스키마 변경은 마이그레이션 파일로 관리해 주세요.
그래도 기능과 사용자를 계속 늘리며 본격적으로 발전시킬 서비스라면 SQLite3로 시작했다가 이전하는 것보다 처음부터 PostgreSQL을 선택하는 편이 낫습니다.
사용할 때 주의할 점과 그 이유
-
DB 파일을 웹에서 접근할 수 있는 경로에 두지 마세요.
파일 하나에 모든 데이터가 들어 있기 때문에 파일이 노출되면 서비스 데이터 전체가 유출될 수 있습니다. -
Docker나 Podman에서는 영구 볼륨에 저장하세요.
컨테이너 내부에만 저장하면 재배포하거나 컨테이너를 삭제할 때 DB 파일도 함께 사라질 수 있습니다. -
NFS 같은 네트워크 파일시스템은 피하세요.
SQLite3는 파일 잠금에 의존하기 때문에 네트워크 환경에서는 오류나 데이터 손상이 발생할 수 있으며, 특히 WAL 모드와 잘 맞지 않습니다. -
실행 중인 DB 파일을 무작정 복사하지 마세요.
쓰기가 진행되는 순간 복사하면 불완전한 백업이 만들어질 수 있으므로 SQLite 백업 기능을 사용하는 것이 안전합니다. -
-wal,-shm파일을 임의로 삭제하지 마세요.
아직 원본 DB에 반영되지 않은 최신 데이터가 들어 있을 수 있어 삭제하면 데이터가 유실될 수 있습니다. -
DB 파일이 저장된 폴더에도 쓰기 권한을 주세요.
SQLite3는 DB 파일 옆에 WAL과 임시 파일을 생성하기 때문에 폴더 권한이 없으면 정상적으로 저장하지 못할 수 있습니다.
결론은 간단합니다.
빠르게 만들고 작게 운영할 프로젝트라면 SQLite3.
향후 기능과 사용자를 계속 늘릴 서비스라면 처음부터 PostgreSQL.
SQLite3는 장난감 데이터베이스가 아닙니다. 충분히 검증되고 신뢰할 수 있지만, 구조적인 한계는 분명합니다.
가장 좋은 데이터베이스는 가장 유명한 데이터베이스가 아니라, 지금 만드는 서비스의 목적과 성장 계획에 맞는 데이터베이스입니다.