SQLite 하나로 쇼핑몰을 운영할 수 있을까? — 프로덕션 실전 경험기

데이터베이스 하나가 파일 하나라고?

보통 프로덕션 서비스를 만들 때 데이터베이스로 PostgreSQL이나 MySQL을 떠올리죠. 서버를 설치하고, 접속 정보를 설정하고, 커넥션 풀을 관리하고… 꽤 복잡한 작업이에요. 그런데 만약 데이터베이스가 그냥 파일 하나라면 어떨까요?

SQLite가 바로 그런 데이터베이스예요. 별도의 서버 프로세스 없이, 하나의 .db 파일이 곧 데이터베이스인 거죠. 모바일 앱이나 로컬 도구에서는 이미 널리 쓰이고 있는데, 최근에는 이 SQLite를 프로덕션 웹 서비스에 쓰는 사례가 하나둘 나오고 있어요. 이번에 소개할 글은 실제로 SQLite로 온라인 스토어를 운영하면서 배운 교훈들을 정리한 내용이에요.

SQLite를 프로덕션에 쓸 수 있는 이유

예전에는 "SQLite는 프로덕션에서 쓰면 안 돼"라는 게 거의 상식이었어요. 이유가 있었죠. 동시 쓰기(concurrent writes)를 잘 처리하지 못하고, 네트워크를 통한 접속이 안 되고, 대규모 트래픽을 감당하기 어렵다는 거였어요.

그런데 상황이 많이 바뀌었어요. 먼저 SQLite에 WAL(Write-Ahead Logging) 모드라는 게 추가됐는데요, 이게 뭐냐면, 데이터를 바로 원본 파일에 쓰는 대신 별도의 로그 파일에 먼저 기록하는 방식이에요. 이렇게 하면 읽기 작업과 쓰기 작업이 서로를 블로킹하지 않아서, 동시성이 크게 개선돼요. 여러 사람이 동시에 사이트를 보면서(읽기) 누군가 주문을 넣는(쓰기) 상황에서도 문제없이 동작하는 거죠.

그리고 Litestream이라는 도구가 나오면서 백업 문제도 해결됐어요. Litestream은 SQLite 데이터베이스의 변경사항을 실시간으로 S3 같은 외부 저장소에 스트리밍해주는 도구예요. 이걸 쓰면 서버가 갑자기 죽어도 데이터를 복구할 수 있게 돼요.

실전에서 부딪힌 문제들

이 글의 저자는 SQLite로 실제 스토어를 운영하면서 몇 가지 중요한 교훈을 얻었어요.

첫 번째는 쓰기 잠금(write lock) 문제예요. SQLite는 한 번에 하나의 쓰기만 허용해요. 이건 WAL 모드에서도 마찬가지예요. 읽기는 여러 개가 동시에 가능하지만, 쓰기는 줄을 서서 하나씩 처리되는 거죠. 트래픽이 적을 때는 괜찮지만, 주문이 한꺼번에 몰리면 쓰기 대기 시간이 길어질 수 있어요. 이 문제를 완화하려면 쓰기 트랜잭션을 최대한 짧게 가져가는 게 핵심이에요.

두 번째는 마이그레이션 관리예요. PostgreSQL에서는 ALTER TABLE이 꽤 유연한데, SQLite에서는 제약이 많아요. 예를 들어 컬럼의 타입을 변경하거나, 컬럼을 삭제하는 게 예전 버전에서는 아예 안 됐어요. 새 테이블을 만들고 데이터를 옮기는 방식으로 우회해야 했죠. 최신 SQLite에서는 많이 개선됐지만, ORM이나 마이그레이션 도구가 이를 완벽하게 지원하지 않는 경우가 있으니 주의가 필요해요.

세 번째는 모니터링과 관측성이에요. PostgreSQL이나 MySQL은 슬로우 쿼리 로그, 커넥션 모니터링 같은 도구가 성숙해있는데, SQLite는 이런 생태계가 상대적으로 부족해요. 직접 쿼리 실행 시간을 측정하거나, 파일 크기 증가를 모니터링하는 등의 자체 솔루션이 필요할 수 있어요.

업계 맥락: 왜 지금 SQLite가 다시 주목받나

SQLite 프로덕션 사용이 주목받는 데는 몇 가지 업계 흐름이 있어요. 엣지 컴퓨팅의 부상이 큰 역할을 했는데요, Cloudflare Workers나 Fly.io 같은 플랫폼은 전 세계 여러 지역에서 애플리케이션을 실행해요. 각 지역에 PostgreSQL 서버를 두기는 비용도 크고 복잡한데, SQLite 파일 하나를 각 엣지에 배포하면 훨씬 간단하죠. Cloudflare의 D1이나 Turso(libSQL 기반) 같은 서비스가 바로 이 접근법을 상용화한 거예요.

반면 한계도 분명해요. 수평 확장(여러 서버에 분산)이 필요한 규모라면 SQLite는 적합하지 않아요. 결국 "내 서비스 규모에 SQLite가 맞는가"를 냉정하게 판단하는 게 중요해요. 월 방문자 수만 명 이하의 서비스라면 충분히 고려할 만하고, 그 이상이라면 전통적인 클라이언트-서버 데이터베이스가 더 안전한 선택이에요.

한국 개발자에게 주는 시사점

사이드 프로젝트나 MVP(최소 기능 제품)를 빠르게 만들 때 SQLite는 정말 매력적인 선택이에요. 데이터베이스 서버를 따로 관리할 필요가 없으니 인프라 비용이 거의 0에 가깝고, 배포도 간단하거든요. 특히 1인 개발이나 소규모 팀에서 운영 부담을 줄이고 싶을 때 좋아요.

이미 Django나 Rails로 사이드 프로젝트를 하고 있다면, ORM 설정에서 데이터베이스만 SQLite로 바꿔보는 것부터 시작해볼 수 있어요. 프레임워크가 SQL 차이를 대부분 추상화해주니까요.