모든 것을 위한 SQLite

김팔복 2026. 8. 25. 오후 10:57:13

조회 38 추천 0 댓글 0

첨부파일

출처: JoeCode (개인 기술 블로그)
원문: https://joecode.com/2026-08-19-sqlite3/
작성자: 팔복소프트-김팔복

한눈에 보기

해외 개발 블로그 JoeCode가 "PostgreSQL로 다 된다"는 유명 글에 화답하며, 그 자리를 SQLite가 채울 수 있다는 주장을 내놓았습니다.
핵심 논리는 SQLite가 RDBMS이면서 동시에 전문 검색 엔진(FTS5), JSON 문서 저장소, 큐, 캐시, 벡터 DB 역할까지 한다는 것입니다.
SQLite는 서버 프로세스가 아니라 애플리케이션에 링크되는 파일 + 라이브러리라서, 배포·모니터링·보안 패치 대상 시스템 수 자체가 줄어듭니다.
명확한 한계도 함께 짚습니다. 쓰기(write)는 한 번에 하나만 가능하고, 스케일아웃 구조와는 근본적으로 맞지 않습니다.
Litestream(S3로 실시간 백업), Turso·Cloudflare D1 같은 호스팅 서비스가 운영 측면의 약점을 보완해 주는 생태계로 소개됩니다.
편집자 판단: 국내 주류 B2C 서비스의 대체재는 아니지만, 사내 도구·SI 납품·RAG 프로토타입 영역에서는 진지하게 검토할 가치가 있습니다.

배경

SQLite는 별도 서버 없이 애플리케이션 프로세스 안에서 동작하는 임베디드 데이터베이스입니다. 국내에서는 주로 Android/iOS 앱의 로컬 저장소 정도로 인식되지만, 2000년 첫 릴리스 이후 사실상 모든 스마트폰과 브라우저에 탑재되면서 세계에서 가장 많이 배포된 DB 엔진이 됐습니다. 최근 몇 년 사이 Litestream, Turso 같은 도구가 나오면서 "서버 사이드에서 SQLite를 메인 DB로 쓰자"는 흐름이 해외에서 꾸준히 커지고 있고, 이 글은 그 흐름의 연장선에 있습니다.

주요 내용

왜 다시 SQLite인가

글쓴이가 꼽는 SQLite의 힘은 세 가지입니다. 안정성, 운영 부담 제로, 그리고 여러 시스템을 하나로 합치는 통합력입니다.

안정성 근거는 구체적입니다. 테스트 스위트가 항공 소프트웨어 기준(MC/DC)으로 100% 분기 커버리지를 달성했고, 테스트 코드가 라이브러리 코드의 약 500배에 달하며, 프로젝트 차원에서 2050년까지 지원을 공언하고 있습니다. 라이선스조차 없는 퍼블릭 도메인이라 벤더 리스크도 없습니다. 글쓴이는 이렇게 단언합니다.

"SQLite는 지금 여러분이 운영 중인 대부분의 것들보다 오래 살아남을 것이다." — JoeCode

운영 측면의 논리는 더 단순합니다. 설치할 게 없습니다. Python, Go, Rust 등 주요 런타임과 OS에 이미 들어 있고, 테스트는 Docker 컨테이너 대신 :memory: DB를 마이크로초 단위로 띄우면 됩니다. DB 접근이 네트워크 왕복이 아니라 함수 호출이라 커넥션 풀도, pgbouncer도 필요 없습니다.

무엇을 대체할 수 있다는 것인가

원문은 시스템별로 대체 시나리오를 하나씩 짚습니다. 표로 정리하면 이렇습니다.

대체 대상	SQLite 쪽 대응	짚어둘 조건
Elasticsearch / Solr	내장 FTS5 (BM25 랭킹, 구문 검색, 하이라이트)	다국어 분석기·분산 샤딩은 없음. 한국어 형태소 분석이 필요하면 별도 토크나이저 고민 필요
MongoDB	JSON 함수 + `jsonb`(3.45부터) + JSON 경로 기반 생성 컬럼 인덱스	스키마리스 쓰기 + 인덱스 읽기가 한 파일에서 가능
Kafka / RabbitMQ	`BEGIN IMMEDIATE` + `RETURNING`으로 잡 테이블을 큐로 사용	단일 쓰기 락에 컨슈머가 직렬화됨. 초당 수만 건 유입이면 한계 체감
ClickHouse	일/테넌트 단위 파일 파티셔닝 + DuckDB로 동일 파일 OLAP 분석	초당 100만 포인트급 인제스트면 전문 시스템으로
Redis	`synchronous=OFF`, `:memory:` 등 내구성 트레이드오프 옵션	localhost Redis GET(약 100μs)보다 웜 캐시 조회(약 1μs)가 빠르다고 주장
벡터 DB	`sqlite-vec` 확장. 임베딩·원문·메타데이터·전문 검색이 한 파일	하이브리드 검색이 분산 쿼리가 아니라 JOIN 한 번
파일 시스템	약 100KB 이하 blob은 개별 파일보다 빠르고 공간도 약 20% 절약(SQLite 공식 벤치마크)	원자적 다중 blob 갱신, 백업이 파일 하나

특히 검색 쪽 논리가 눈에 띕니다. 검색 인덱스가 데이터와 같은 트랜잭션에서 갱신되므로, 별도 검색 서버를 쓸 때 겪는 "인덱스 동기화가 밀리는" 문제 자체가 구조적으로 사라진다는 것입니다.

솔직한 한계

원문 스스로 인정하는 천장이 있습니다. 쓰기는 한 시점에 하나, 머신도 하나입니다. 글쓴이의 조언은 "일단 SQLite로 시작하고, 한계에 부딪히면 그때는 감이 아니라 실측 수치를 들고 Kafka든 PostgreSQL이든 사러 가라"는 것입니다.

팔복소프트 관점

국내 웹 서비스의 표준 구성은 대체로 MySQL/MariaDB(RDS) + Redis(ElastiCache) + 필요 시 OpenSearch입니다. 이 조합의 월 비용과 관리 포인트가 초기 팀에 부담이라는 점에서, "시스템 수를 줄이자"는 이 글의 문제의식 자체는 국내에도 유효합니다.

다만 결정적인 궁합 문제가 있습니다. 국내에서 흔한 배포 방식은 Kubernetes나 오토스케일링 그룹에서 인스턴스를 여러 개 띄우는 구조인데, 파일 기반 DB는 애플리케이션이 2개 이상 뜨는 순간 전제가 무너집니다. 즉 이 글의 제안은 "서버 1대 아키텍처를 받아들일 수 있는가"라는 질문과 사실상 같은 질문입니다.

그래서 현실적인 적용처는 따로 있다고 봅니다. 사내 어드민·백오피스, 배치 파이프라인의 중간 저장소, 그리고 고객사 서버에 설치해 주는 SI 납품 소프트웨어입니다. 특히 SI 쪽은 "DB 설치·계정·방화벽 협의" 절차가 통째로 사라지는 게 실무적으로 꽤 큽니다. sqlite-vec 기반 RAG 프로토타입도 인덱스 전체가 파일 하나라 오프라인 데모·PoC 전달에 유리합니다.

주의할 함정도 있습니다. 한국어 전문 검색은 FTS5 기본 토크나이저로는 품질이 나오지 않아 형태소 분석 처리를 직접 얹어야 하고, "나중에 PostgreSQL로 옮기면 된다"는 말은 쉽지만 마이그레이션 비용은 실제로 발생합니다. 팀에 SQLite 서버 운영 경험이 없다는 점도 숨은 비용입니다.

정리

이 글에서 기억할 것은 "SQLite가 만능"이라는 결론이 아니라, 새 요구사항이 나올 때마다 서버형 시스템을 하나씩 추가하는 습관에 대한 반문입니다. 검색, 큐, 캐시가 필요하다고 해서 반드시 Elasticsearch, Kafka, Redis가 필요한 것은 아닙니다. 규모가 서버 1대 안에 들어오는 문제라면, 이미 설치되어 있는 도구부터 검토해 볼 이유가 충분합니다.

SQLite
데이터베이스
아키텍처
인프라비용
백엔드