SQLite 파일 설명: 구조, 사용 사례 및 주요 제한 사항

SQLite 파일은 테이블, 인덱스, 스키마를 모두 포함하여 전체 관계형 데이터베이스를 담고 있는 단일 디스크 파일입니다. SQLite 자체 문서에서는 이를 "메인 데이터베이스 파일"이라고 부르며, "SQLite 데이터베이스의 완전한 상태는 보통" 이 파일에 포함된다고 설명합니다. 이 문장에서 '보통(usually)'이라는 단어는 매우 중요한 역할을 하고 있습니다.

누군가로부터 .db, .sqlite 또는 .sqlite3 파일을 전달받고 데이터가 모두 제대로 들어있는지 궁금했던 적이 있다면, 이 포맷을 제대로 이해해 둘 필요가 있습니다.

SQLite 파일의 실제 정의

SQLite는 스스로를 "독립형, 서버리스, 설정 제로, 트랜잭션 SQL 데이터베이스 엔진을 구현하는 인프로세스 라이브러리"라고 설명합니다. 같은 페이지에서 SQLite는 "별도의 서버 프로세스가 없다"고 명시하고 있습니다. 애플리케이션이 이 라이브러리를 링크하여 파일을 직접 읽는 방식입니다.

이로 인해 두 가지 결과가 따릅니다. 첫째, 데이터베이스가 하나의 아티팩트로 이동하므로 수많은 애플리케이션이 데이터를 이 방식으로 배포합니다. 둘째, 파일이 이를 작성한 소프트웨어보다 더 오래 살아남기 때문에 포맷이 극도로 안정적이어야 합니다. SQLite는 주요 특징 중 하나로 "안정적이고 지속적인 파일 포맷"을 꼽습니다. 또한 코드가 퍼블릭 도메인에 속해 있어 "상업적이든 개인적이든 어떤 목적으로든 자유롭게 사용할 수 있다"고 명시하고 있습니다.

그 규모는 쉽게 과소평가되기 마련입니다. SQLite의 공식 소개 페이지에 따르면, 이는 "셀 수 없이 많은 애플리케이션에서 사용되는 세계에서 가장 널리 배포된 데이터베이스"입니다.

파일 내부 들여다보기

100바이트 헤더

첫 번째 바이트들이 포맷을 식별합니다. 오프셋 0에서 파일은 16바이트 헤더 문자열인 SQLite format 3\000을 가집니다. 이 시그니처 덕분에 도구들은 확장자에 관계없이 파일을 인식할 수 있습니다.

다음 필드는 보기보다 더 중요합니다. 오프셋 16에는 "바이트 단위의 데이터베이스 페이지 크기"를 담고 있는 2바이트 정수가 위치합니다. 문서에 따르면 이 값은 "512에서 32768 사이의 2의 거듭제곱이거나, 페이지 크기 65536을 나타내는 값 1이어야 합니다." 헤더의 모든 멀티바이트 필드는 가장 중요한 바이트가 먼저 저장되는 방식으로 저장됩니다.

오프셋 18과 19에는 두 바이트가 더 이어집니다. 바로 파일 포맷 쓰기 버전과 읽기 버전입니다. 문서에서는 이 값이 "레거시의 경우 1, WAL의 경우 2"라고 명시하고 있습니다.

행이 아닌 페이지 단위

헤더 아래로 파일은 고정된 크기의 페이지들이 쌓여 있는 구조입니다. 사양서에는 다음과 같이 명시되어 있습니다. "메인 데이터베이스 파일은 하나 이상의 페이지로 구성됩니다. 페이지 크기는 512에서 65536 사이의 2의 거듭제곱입니다. 동일한 데이터베이스 내의 모든 페이지는 크기가 같습니다."

페이지 번호는 1부터 시작하며, 최대 페이지 번호는 4,294,967,294입니다. 테이블과 인덱스는 이러한 페이지 내부에서 B-tree 구조로 존재하기 때문에, 텍스트 에디터로 열었을 때 거의 아무것도 보이지 않는 것입니다.

아무도 언급하지 않는 사이드카 파일

이 부분이 사람들이 흔히 놓치는 지점입니다. 문서에서는 완전한 상태가 "보통" 하나의 파일에 있다고 말한 뒤, 예외를 언급합니다. 트랜잭션 중에 SQLite는 "'롤백 저널(rollback journal)'이라고 불리는 두 번째 파일에 추가 정보를 저장"합니다. WAL 모드에서 이 두 번째 파일은 쓰기 전행 로그(write-ahead log)가 됩니다.

따라서 애플리케이션이 쓰기 작업을 수행하는 도중에 복사본을 만들면, 사이드카 파일에 여전히 남아 있는 커밋된 데이터가 누락될 수 있습니다. 동료가 다른 파일 없이 오직 .db 파일만 보냈는데 데이터 수치가 약간 맞지 않는 것 같다면, 가장 먼저 이 부분을 확인해야 합니다.

SQLite 파일을 여는 방법

세 가지 방법이 있으며, 다음 단계에서 무엇을 하려는지에 따라 적절한 방법을 선택하면 됩니다.

뷰어로 읽기. 데스크톱 및 브라우저 기반 SQLite 뷰어는 파일을 열고 테이블 목록을 보여주며, 행을 클릭하며 살펴볼 수 있게 해줍니다. 이는 "여기에 도대체 무엇이 들어있는가"에 대한 답을 얻는 가장 빠른 방법이며, 대개 첫 확인용으로 충분합니다.

명령줄이나 라이브러리로 쿼리하기. sqlite3 셸과 Python, Node 및 대부분의 다른 언어에 내장된 표준 라이브러리 바인딩은 이 포맷을 직접 읽을 수 있습니다. 스키마를 이미 알고 있고 특정 데이터 값을 얻고자 할 때 이 방법을 사용합니다.

테이블을 내보내어 다른 곳에서 분석하기. 테이블을 CSV로 덤프하여 팀에서 이미 사용 중인 도구로 가져갑니다. 이 경우 포맷이 보호하고 있던 유일한 요소인 테이블 간의 관계가 손실됩니다. 가능하면 원본 테이블보다는 조인된 결과를 내보내는 것이 좋습니다.

도구에서 파일이 데이터베이스가 아니라고 표시하는 이유

사양서에서 이 이유를 설명해 줍니다. 유효한 모든 파일은 16바이트 헤더 문자열인 SQLite format 3\000으로 시작합니다. 파일을 열었을 때 오프셋 0에서 이 시그니처를 찾지 못하는 리더기는 전달받은 파일이 SQLite 데이터베이스가 아니라고 판단합니다.

대부분의 경우는 세 가지 일반적인 원인에 해당합니다. 파일 전송이 불완전하게 완료되어 헤더는 존재하지만 나머지 부분이 잘린 경우, 파일이 암호화되었거나 특정 애플리케이션에 의해 래핑되어 첫 바이트가 다른 값으로 채워진 경우, 또는 확장자가 잘못 지정되어 실제로는 일반 내보내기 파일인데 누군가 도움을 주려고 이름을 바꾼 경우입니다.

SQLite 파일은 얼마나 커질 수 있는가

보통 이 질문이 암시하는 것보다 훨씬 더 커질 수 있습니다. SQLite의 제한 사항 페이지에 따르면 데이터베이스 파일의 최대 크기는 4,294,967,294페이지입니다. 최대 페이지 크기인 65,536바이트를 기준으로 하면, 최대 데이터베이스 크기는 약 281테라바이트에 달합니다.

해당 페이지는 이 수치에 대해 놀라울 정도로 솔직하게 기술하고 있습니다. 개발진은 "이 제한에 도달할 수 있는 하드웨어를 보유하고 있지 않기 때문에" 이 상한선은 테스트되지 않았다고 언급합니다.

행 수 역시 동일한 장벽에 가로막힙니다. 이론적인 최대치는 한 테이블당 2^64개의 행입니다. 문서에서는 "최대 데이터베이스 크기인 281테라바이트에 먼저 도달하기 때문에 이 제한에는 도달할 수 없다"고 지적합니다.

실무에서 유용한 교훈은 제한의 존재보다는 그 반대편에 있습니다. 누군가 .db 파일을 건네며 크기가 크다고 경고하더라도, 포맷 자체 때문에 작업이 막힐 일은 거의 없습니다. 파일이 생성될 때 선택된 페이지 크기와 인덱스 포함 여부가 작업 경험에 훨씬 더 큰 영향을 미칩니다.

SQLite 파일을 접하게 되는 곳

• 애플리케이션 내보내기. 데스크톱 및 모바일 앱은 종종 사용 기록, 설정, 메시지 로그를 복사해 낼 수 있는 SQLite 파일에 저장합니다.
• 분석 데이터 전달. 엔지니어들은 데이터베이스 접근 권한을 부여하는 대신 스냅샷을 단일 파일로 전달합니다.
• 기기 및 텔레메트리. 임베디드 시스템은 통신할 서버가 없기 때문에 로컬에 데이터를 기록합니다.
• 아카이브. 이 포맷의 장기적인 안정성 덕분에 수년 동안 읽기 가능한 상태를 유지해야 하는 데이터 세트에 자주 선택됩니다.
• 브라우저 및 도구 내부. 많은 로컬 도구가 이 방식으로 상태를 유지하므로, 지원 티켓에 이 확장자가 자주 등장하게 됩니다.

WAL 및 저널 파일의 용도

.db 파일을 복사할 때 그 옆에 -wal 또는 -journal 파일이 있는 것을 본 적이 있을 것입니다. 이것들이 바로 사양서에서 설명하는 사이드카 파일이며, 이를 삭제하면 데이터를 잃게 됩니다.

롤백 저널은 더 오래된 메커니즘입니다. 페이지를 변경하기 전에 SQLite는 해당 페이지의 원본 버전을 저널에 기록합니다. 쓰기 작업이 중단되면 원본을 다시 되돌릴 수 있으며, 이를 통해 트랜잭션이 충돌 상황에서도 안전하게 유지됩니다.

쓰기 전행 로그는 이 구조를 뒤집은 것입니다. 변경 사항이 로그에 먼저 기록되고 메인 파일은 나중에 업데이트됩니다. 헤더는 데이터베이스가 어떤 모드에 있는지 표시합니다. 오프셋 18의 파일 포맷 쓰기 버전은 "레거시의 경우 1, WAL의 경우 2"입니다.

실무적인 규칙은 완전한 상태에 관한 문장에서 바로 도출됩니다. 데이터베이스가 WAL 모드이고 누군가 메인 파일만 건넸다고 가정해 보겠습니다. 가장 최근에 커밋된 변경 사항은 여러분이 받지 못한 로그 파일에 여전히 남아 있을 수 있습니다.

따라서 데이터베이스 파일을 받을 때는 두 가지 질문을 던져야 합니다. 복사본을 만들 때 애플리케이션이 정상적으로 종료되었는지, 그리고 함께 제공된 다른 파일이 있는지 여부입니다. 대개 두 질문 모두 '예'가 답이겠지만, 그렇지 않은 단 한 번의 예외가 발생할 때 운영 환경의 데이터 수치와 조용히 어긋나게 됩니다.

SQLite 파일 vs CSV vs Parquet

	SQLite 파일	CSV	Parquet
형태	여러 테이블, 단일 파일	단일 테이블, 단일 파일	단일 테이블, 단일 파일 또는 폴더
타입	데이터와 함께 저장됨	리더기에 의해 추론됨	데이터와 함께 저장됨
관계	키와 인덱스를 통해 유지됨	손실됨	손실됨
사람이 읽을 수 있는지 여부	아니요	예	아니요
쿼리 작성을 위해 설계됨	예, SQL 사용	아니요	예, 분석 엔진에 의해 사용됨
흔한 실패 원인	저널 또는 WAL 사이드카 파일 누락	타입 및 구분자 추측 오류	툴체인 지원 문제

이러한 포맷을 자주 다루신다면, Parquet 파일 및 TSV 파일에 대한 설명서에서 해당 포맷들에 대해 동일하게 자세한 내용을 확인하실 수 있습니다.

팀들이 이 포맷을 선택하는 이유

실행할 서버가 필요 없음. SQLite는 "별도의 서버 프로세스가 없기" 때문에, 데이터를 전달할 때 프로비저닝 티켓을 발행할 필요 없이 단순히 파일을 복사하기만 하면 됩니다.

타입이 그대로 유지됨. 날짜 열은 날짜 타입 그대로 전달됩니다. CSV 리더기가 식별자 번호를 지수 표기법으로 변환해 버리는 것을 겪어본 사람이라면 이것이 얼마나 가치 있는지 이해할 것입니다.

관계도 그대로 유지됨. 여러 관련 테이블이 하나의 아티팩트에 함께 유지되므로, 데이터에 의미를 부여하는 조인 관계를 그대로 사용할 수 있습니다.

내구성이 설계 단계부터 반영됨. SQLite는 핵심 기능 중 하나로 "전원 손실 후에도" 유지되는 트랜잭션을 꼽으며, 이것이 수많은 임베디드 소프트웨어가 이에 의존하는 이유입니다.

알아두어야 할 제한 사항

한 번에 하나의 파일, 하나의 쓰기 작업만 가능. 엔진이 서버 형태가 아닌 내장형으로 동작하므로, 동시성 모델이 클라이언트-서버 데이터베이스와 다릅니다. 이는 결함이 아닌 설계상의 선택이지만, 이 파일이 어떤 용도에 적합한지를 결정짓는 요인입니다.

페이지 크기는 생성 시 고정됨. 데이터베이스의 모든 페이지는 크기가 동일하며, 이 크기는 헤더에 기록됩니다. 생성할 때 한 번만 선택할 수 있습니다.

다시 한번 강조하는 사이드카 규칙. 메인 파일만 가져오는 복사, 백업 또는 업로드 루틴은 저널이나 쓰기 전행 로그에 있던 데이터를 누락할 수 있습니다.

불투명성. SQLite 파일은 CSV처럼 훑어볼 수 없습니다. 파일을 읽으려면 도구가 필요하며, 이는 많은 분석 작업을 지연시키는 걸림돌이 되기도 합니다.

SQLite 파일에서 원하는 답을 얻는 방법

전통적인 방법은 클라이언트를 설치하고, 파일을 열고, 스키마를 파악한 다음 SQL을 작성하기 시작하는 것입니다. 테이블 구조를 이미 알고 있다면 괜찮은 방법입니다. 하지만 오늘 아침에 파일을 받았는데 오후에 회의가 있다면 이 방법은 너무 느립니다.

더 빠른 방법은 질문을 직접 던지는 것입니다. Powerdrill Bloom을 사용하면 자연어로 데이터를 다룰 수 있으며, 출처가 첨부된 답변을 받을 수 있습니다. 홈페이지에서는 "모든 숫자가 해당 페이지, 행, 그리고 그 뒤에 있는 수치와 함께 제공된다"고 약속합니다. 거기서부터 동일한 워크스페이스를 통해 차트, 시트 또는 간단한 프레젠테이션 자료를 만들어낼 수 있습니다.

이것이 일상적인 워크플로우라면 관련된 두 페이지를 알아두는 것이 좋습니다. Chat with Database는 구조화된 데이터에 대화형으로 접근하는 방법을 다루며, Text to SQL은 쿼리 자체를 얻고자 하는 경우를 다룹니다. 만약 전달받은 데이터가 단순한 내보내기 파일 형태라면, CSV AI assistant 페이지에서 해당 해결 방법을 확인하실 수 있습니다.

헤더가 알려주는 또 한 가지 사실

페이지 크기가 고정된 오프셋에 위치하기 때문에, 파일을 제대로 열기 전에도 유용한 정보를 얻을 수 있습니다. 4,096바이트 페이지로 생성된 데이터베이스는 65,536바이트 페이지로 생성된 데이터베이스와 다르게 작동합니다. 이 선택은 파일이 생성될 때 단 한 번 이루어집니다.

이는 나중에 쉽게 변경할 수 있는 숫자가 아닙니다. 단순한 설정이라기보다는 스키마 결정과 같은 범주로 생각해야 합니다.

결론

SQLite 파일은 하나의 아티팩트에 담긴 전체 데이터베이스입니다. 16바이트 시그니처, 오프셋 16에 기록된 페이지 크기, 그리고 테이블과 인덱스를 담고 있는 고정 크기 페이지들의 스택으로 구성됩니다. 이동이 편리하고, 타입을 유지하며, 수년 동안 읽기 가능한 상태를 유지합니다.

사양서에서 주의 깊게 다루는 한 가지 경고 사항을 기억하세요. 완전한 상태는 보통 그 파일에 있습니다. 하지만 트랜잭션 중에는 그 일부가 파일 옆에 있는 롤백 저널이나 쓰기 전행 로그에 존재합니다. 복사본을 신뢰하기 전에 사이드카 파일이 있는지 확인하십시오.

파일을 가지고 있고 스키마가 아닌 답변이 필요할 때는, Powerdrill Bloom을 사용하여 데이터에 직접 질문을 던져보세요.

자주 묻는 질문

.db, .sqlite, .sqlite3의 차이점은 무엇인가요?

구조적인 차이는 없습니다. 세 가지 모두 동일한 포맷에 사용되는 관례적인 확장자이며, 실제 식별자는 파일 시작 부분에 있는 16바이트 헤더 문자열인 SQLite format 3\000입니다.

SQLite 파일이 어떤 페이지 크기를 사용하는지 어떻게 알 수 있나요?

헤더에 기록되어 있습니다. 오프셋 16에 있는 2바이트 정수가 바이트 단위의 페이지 크기를 나타냅니다. 이 값은 512에서 32768 사이의 2의 거듭제곱이거나, 65536을 나타내는 값 1이어야 합니다.

SQLite 파일이 완전한 데이터베이스인가요?

보통은 그렇지만 항상 그런 것은 아닙니다. 문서에 따르면 트랜잭션 중에 SQLite는 추가 정보를 롤백 저널에 보관합니다. WAL 모드에서는 이 정보가 대신 쓰기 전행 로그로 이동합니다.

Excel에서 SQLite 파일을 열 수 있나요?

직접 열 수는 없습니다. 파일이 텍스트 행이 아닌 B-tree 페이지를 저장하기 때문입니다. 일반적인 방법은 먼저 테이블을 CSV로 내보내거나, 데이터베이스 포맷을 읽고 결과를 반환하는 도구를 사용하는 것입니다.

SQLite는 상업적으로 무료로 사용할 수 있나요?

네, 그렇습니다. SQLite는 자사 코드가 퍼블릭 도메인에 속해 있으며 "상업적이든 개인적이든 어떤 목적으로든 자유롭게 사용할 수 있다"고 밝히고 있습니다.