SQLite란? 서버 없이 쓰는 임베디드 SQL 데이터베이스

SQLite는 프로그램 안에 들어가는 데이터베이스입니다

흔히 들어본 MySQL, Postgres, SQL Server 같은 데이터베이스는 대부분 별도의 프로그램으로 실행됩니다. 서버를 띄우고, 특정 포트에서 요청을 기다리면, 애플리케이션이 네트워크를 통해 접속해서 쿼리를 던지는 구조죠. SQLite는 이 방식을 완전히 뒤엎습니다.

SQLite는 라이브러리입니다. 프로그램에 함께 묶어서 빌드하면, 디스크의 파일 하나에 통째로 담기는 SQL 데이터베이스가 생깁니다. 서버도 없고, 포트도 없고, 데몬 프로세스도 없으며, pg_ctl start 같은 명령도 필요 없습니다. 애플리케이션이 파일 하나를 열면, 그 파일이 곧 데이터베이스입니다.

sqlite3 mydata.db

이 명령을 실행하면 mydata.db 파일이 열리거나(없다면 새로 만들어짐) SQL 프롬프트가 뜹니다. 테이블이든 행이든 인덱스든, 여러분이 작업하는 모든 것이 이 파일 하나에 저장돼요. 다른 컴퓨터로 파일을 복사하면 데이터베이스도 그대로 따라가고, 파일을 지우면 데이터베이스도 같이 사라집니다.

SQL 문법 살펴보기

SQLite의 SQL 문법은 다른 데이터베이스와 거의 똑같습니다. 다른 DBMS를 다뤄본 적이 있다면 대부분 익숙하게 느껴질 거예요:

CREATE TABLE books (
    id     INTEGER PRIMARY KEY,
    title  TEXT NOT NULL,
    author TEXT NOT NULL,
    year   INTEGER
);

INSERT INTO books (title, author, year) VALUES
    ('The Left Hand of Darkness', 'Ursula K. Le Guin', 1969),
    ('Project Hail Mary',         'Andy Weir',         2021),
    ('Piranesi',                  'Susanna Clarke',    2020);

SELECT title, year FROM books ORDER BY year DESC;

표준 SQL — CREATE TABLE, INSERT, SELECT, ORDER BY. 실무에서 매일 쓰는 SQL 표준 기능은 SQLite도 거의 다 지원하고, 거기에 CTE나 윈도우 함수, JSON 함수 같은 요즘 기능까지 갖추고 있습니다. PostgreSQL이나 MySQL과 다른 점은 주로 타입 처리와 약간의 문법 차이 정도인데, 이건 뒤에서 따로 다루겠습니다.

"임베디드"와 "서버리스"가 실제로 뜻하는 것

SQLite를 이야기할 때 빠지지 않고 등장하는 두 단어입니다. 정확히 짚고 넘어가는 게 좋습니다.

임베디드 데이터베이스라는 건, SQLite가 여러분의 애플리케이션과 같은 프로세스 안에서 동작한다는 뜻입니다. 별도의 DB 프로세스가 따로 돌지 않습니다. 파이썬 스크립트에서 sqlite3.connect("data.db")를 호출하면, SQL 엔진이 파이썬 프로세스 내부에서 직접 돌면서 파일을 읽고 씁니다.

서버리스 데이터베이스라는 건, 설치하고 설정하고 띄우고 보안 챙기고 백업해야 할 서버 자체가 없다는 뜻입니다. 데이터베이스를 쓰기까지의 절차를 비교해 보면 차이가 확 와닿습니다.

• PostgreSQL: PostgreSQL 설치 → 서비스 시작 → 사용자 생성 → 데이터베이스 생성 → pg_hba.conf 설정 → TCP로 접속.
• SQLite: 파일 하나 열기.

차이는 딱 그만큼입니다. 쓸 수 있는 기능은 좀 줄어들지만, 번거로움도 비교가 안 될 정도로 줄어듭니다.

데이터베이스 전체가 파일 하나

이 부분이 처음 접하는 분들을 가장 놀라게 하는 지점입니다. 파일 포맷이 공개돼 있고 안정적이라, .db(혹은 .sqlite, .sqlite3 — 확장자는 그냥 관습일 뿐입니다) 파일 하나를 다음처럼 다룰 수 있습니다.

• 동료에게 이메일로 보내기.
• git에 커밋하기 (용량이 작다면요).
• cp 명령어로 복사해서 즉석 백업 만들기.
• 어떤 OS에서든 SQLite 도구로 열어 보기.

ls -lh mydata.db
# -rw-r--r--  1 you  staff   28K  Apr 23 14:02 mydata.db

이 단일 파일 하나에 테이블, 인덱스, 스키마, 데이터까지 전부 담깁니다. SQLite 데이터베이스 파일은 Windows, macOS, Linux, iOS, Android 어디서든 바이트 단위까지 똑같습니다. 포맷이 워낙 안정적이라 미국 의회도서관(Library of Congress)이 장기 데이터 보존용 포맷으로 권장할 정도죠.

이미 곳곳에서 쓰고 있는 SQLite

지금 이 글을 읽고 있는 기기 안에도 SQLite 데이터베이스가 수백 개는 들어 있을 겁니다. SQLite가 돌아가는 곳을 살펴보면 이렇습니다:

• iOS와 Android의 시스템 저장소, 그리고 양쪽 플랫폼의 수많은 앱
• Firefox, Chrome, Safari (방문 기록, 북마크, 쿠키)
• macOS (메일, 사진, Dock)
• 로컬 저장소가 필요한 대부분의 Linux 데스크톱 앱
• Skype, WhatsApp, Signal — 채팅 기록
• Adobe Lightroom 카탈로그, Dropbox 메타데이터, Steam 라이브러리

세상에서 가장 널리 배포된 데이터베이스 엔진이라는 평을 듣는데, 실제로 그럴 가능성이 높습니다. 이유는 단순합니다. 애플리케이션에 구조화된 로컬 저장소가 필요할 때, SQLite는 가장 저항이 적은 길이거든요.

SQLite가 아닌 것

SQLite는 클라이언트-서버 데이터베이스가 아닙니다. 서로 다른 머신에 있는 두 프로그램이 네트워크로 같은 SQLite 데이터베이스에 동시 접속할 수 없습니다 — 애초에 붙을 네트워크 계층이 없거든요. 그런 환경이 필요하다면 Postgres나 MySQL을 써야 합니다.

쓰기 동시성이 높은 워크로드용도 아닙니다. SQLite는 파일 단위 잠금을 사용하기 때문에(WAL 모드에서는 몇 가지 영리한 최적화가 들어가지만) 읽기는 여럿이 동시에 가능해도 쓰기는 한 번에 한 명만 커밋할 수 있습니다. 1인용 앱이나 트래픽이 적은 웹사이트라면 신경 쓸 일이 거의 없습니다. 반대로 초당 수천 건의 쓰기가 발생하는 멀티테넌트 SaaS라면 적절한 선택이 아닙니다.

사용자 계정이나 권한 관리도 하지 않습니다. 데이터베이스 접근 = 파일 접근입니다. 파일을 읽을 수 있는 사람은 데이터도 읽을 수 있죠. 자기 데이터베이스 파일을 직접 소유한 앱이라면 문제없지만, 여러 사용자가 공유하는 멀티테넌트 환경에는 맞지 않습니다.

그래도 SQLite를 고르는 이유

요약하자면, "어쩌면 평생 쓸 일 없을 확장성"을 내주고 단순함을 얻는 거래입니다:

• 설정 제로. 띄울 서비스도 없고, 개발/운영 간 버전 불일치도 없고, 데이터베이스 서버 자체가 없으니 "DB가 죽었다"는 상황도 없습니다.
• 빠릅니다. 대부분의 워크로드, 특히 읽기 위주 작업에서는 네트워크 데이터베이스보다 SQLite가 더 빠릅니다. 쿼리마다 소켓 왕복이 없으니까요.
• 신뢰성. 테스트가 정말 집요할 정도로 잘 되어 있습니다. SQLite 프로젝트는 소스 코드보다 테스트 코드가 압도적으로 많고, 파일 포맷은 2004년부터 호환을 유지해 왔습니다.
• 퍼블릭 도메인. 상업적 이용을 포함해 어떤 용도로도 무료입니다. 라이선스 문구를 읽을 일조차 없습니다.
• 이식성. 파일 하나, 모든 플랫폼.

로컬 앱, 프로토타입, 임베디드 기기, CLI 도구, 테스트 스위트, 데이터 분석 스크립트, 그리고 중소 규모 웹사이트라면 SQLite는 "진짜 데이터베이스로 가기 전 임시방편"이 아니라 올바른 기본 선택지인 경우가 많습니다.

다음 글: SQLite vs MySQL

자연스럽게 떠오르는 다음 질문은, 더 자주 들어봤을 데이터베이스 서버들과 SQLite가 어떻게 비교되느냐는 것입니다. 먼저 MySQL부터 살펴보겠습니다 — 어느 쪽이 어디서 강점을 가지는지, 그리고 지금 진행 중인 프로젝트에는 어느 쪽이 맞는지 판단하는 법을 함께 짚어보죠.