애플리케이션 파일 형식으로서의 SQLite

정의된 스키마를 가진 SQLite 데이터베이스 파일은 훌륭한 애플리케이션 파일 형식이 되는 경우가 많아요. 이 글에서는 그 이유를 열두 가지로 정리해 설명해 드릴게요.

출처: SQLite As An Application File Format

본문

1. 요약 (Executive Summary)

정의된 스키마를 가진 SQLite 데이터베이스 파일은 훌륭한 애플리케이션 파일 형식이 되는 경우가 많아요. 그 이유를 열두 가지로 들자면 다음과 같아요:

단순화된 애플리케이션 개발 (Simplified Application Development)
단일 파일 문서 (Single-File Documents)
고수준 쿼리 언어 (High-Level Query Language)
접근 가능한 콘텐츠 (Accessible Content)
크로스 플랫폼 (Cross-Platform)
원자적 트랜잭션 (Atomic Transactions)
증분 및 연속 갱신 (Incremental And Continuous Updates)
쉽게 확장 가능 (Easily Extensible)
성능 (Performance)
여러 프로세스의 동시 사용 (Concurrent Use By Multiple Processes)
여러 프로그래밍 언어 (Multiple Programming Languages)
더 나은 애플리케이션 (Better Applications)

각 항목은 아래에서 더 자세히 설명해 드릴게요. 먼저 "애플리케이션 파일 형식"의 의미를 좀 더 자세히 살펴보고 나서요. 이 문서의 짧은 버전도 같이 보세요.

2. 애플리케이션 파일 형식이란 무엇인가?

"애플리케이션 파일 형식(application file format)"은 애플리케이션 상태를 디스크에 영속화하거나 프로그램 간에 정보를 교환하는 데 사용되는 파일 형식이에요. 오늘날 수천 가지의 애플리케이션 파일 형식이 사용되고 있어요. 몇 가지 예만 들자면:

DOC - Word Perfect와 Microsoft Office 문서
DXF - AutoCAD 도면
PDF - Adobe의 Portable Document Format
XLS - Microsoft Excel 스프레드시트
GIT - Git 소스 코드 저장소
EPUB - Kindle이 아닌 전자책에서 사용하는 Electronic Publication 형식
ODT - OpenOffice 등에서 사용하는 Open Document 형식
PPT - Microsoft PowerPoint 프레젠테이션
ODP - OpenOffice 등에서 사용하는 Open Document 프레젠테이션 형식

우리는 "파일 형식(file format)"과 "애플리케이션 형식(application format)"을 구분해요. 파일 형식은 단일 객체를 저장하는 데 사용돼요. 예를 들어 GIF나 JPEG 파일은 단일 이미지를 저장하고, XHTML 파일은 텍스트를 저장하므로 이것들은 "애플리케이션 형식"이 아니라 "파일 형식"이에요. 반면 EPUB 파일은 텍스트와 이미지(내장된 XHTML과 GIF/JPEG 파일로)를 모두 저장하므로 "애플리케이션 형식"으로 간주돼요. 이 글은 "애플리케이션 형식"에 관한 것이에요.

파일 형식과 애플리케이션 형식 사이의 경계는 모호해요. 이 글은 JPEG를 파일 형식이라고 부르지만, 이미지 편집기에게는 JPEG가 애플리케이션 형식으로 간주될 수 있어요. 상황에 많이 달려 있어요. 이 글에서는 파일 형식은 단일 객체를 저장하고, 애플리케이션 형식은 많은 서로 다른 객체와 그들 간의 관계를 저장한다고 합시다.

대부분의 애플리케이션 형식은 다음 세 범주 중 하나에 들어가요:

완전 커스텀 형식 (Fully Custom Formats). 커스텀 형식은 단일 애플리케이션을 위해 특별히 설계돼요. DOC, DXF, PDF, XLS, PPT가 커스텀 형식의 예시예요. 커스텀 형식은 보통 전달의 용이함을 위해 단일 파일에 담겨요. 또한 보통 이진 형식이지만, DXF 형식은 주목할 만한 예외예요. 커스텀 파일 형식은 읽고 쓰기 위한 특수한 애플리케이션 코드가 필요하며, 일반적으로 유닉스 명령줄 프로그램이나 텍스트 편집기 같은 흔히 사용되는 도구에서 접근할 수 없어요. 다시 말해 커스텀 형식은 보통 "불투명한 블롭(opaque blob)"이에요. 커스텀 애플리케이션 파일 형식의 콘텐츠에 접근하려면 그 형식을 읽고/쓰기 위해 특별히 제작된 도구가 필요해요.
파일 더미 형식 (Pile-of-Files Formats). 때때로 애플리케이션 상태는 파일의 계층 구조로 저장돼요. Git이 대표적인 예지만, 이 현상은 일회성·맞춤 애플리케이션에서 자주 발생해요. 파일 더미 형식은 기본적으로 파일시스템을 키/값 데이터베이스로 사용해서, 정보의 작은 덩어리를 개별 파일에 저장해요. 이는 텍스트 편집기나 "awk", "grep" 같은 일반 유틸리티 프로그램에 콘텐츠를 더 접근 가능하게 만드는 장점을 줘요. 하지만 파일 더미 형식의 많은 파일이 쉽게 읽을 수 있더라도, 보통 자신만의 커스텀 형식(예: Git "Packfiles")을 가진 파일들이 있어서 특수 도구 없이는 읽거나 쓸 수 없는 "불투명한 블롭"이 돼요. 파일 더미를 한 곳이나 머신에서 다른 곳으로 옮기는 것도 단일 파일을 옮기는 것보다 훨씬 불편해요. 그리고 파일 더미 문서를 이메일 첨부로 만드는 것도 어려워요. 마지막으로 파일 더미 형식은 "문서 은유(document metaphor)"를 깨뜨려요. 사용자가 "이것이 문서다"라고 가리킬 수 있는 파일이 하나도 없거든요.
포장된 파일 더미 형식 (Wrapped Pile-of-Files Formats). 일부 애플리케이션은 어느 한 종류의 단일 파일 컨테이너(보통 ZIP 아카이브)로 캡슐화된 파일 더미를 사용해요. EPUB, ODT, ODP가 이 접근의 예시예요. EPUB 책은 실제로는 책 장(chapter)의 텍스트를 위한 다양한 XHTML 파일, 삽화를 위한 GIF와 JPEG 이미지, 그리고 eBook 리더에게 모든 XML과 이미지 파일이 어떻게 맞물리는지 알려주는 특수 카탈로그 파일을 담은 ZIP 아카이브일 뿐이에요. OpenOffice 문서(ODT와 ODP)도 콘텐츠를 나타내는 XML과 이미지, 구성 요소 간의 상호 관계를 보여주는 "카탈로그" 파일을 담은 ZIP 아카이브예요.

포장된 파일 더미 형식은 완전 커스텀 파일 형식과 순수 파일 더미 형식 사이의 절충이에요. 포장된 파일 더미 형식은 구성 요소를 어떤 일반 ZIP 아카이버로도 접근할 수 있으므로 커스텀 형식과 같은 의미의 불투명한 블롭은 아니지만, ZIP 아카이버가 여전히 필요하고 파일 계층에 "find" 같은 명령줄 도구를 먼저 압축을 풀지 않고는 사용할 수 없으므로 순수 파일 더미 형식만큼 접근 가능하지는 않아요. 다른 한편으로 포장된 파일 더미 형식은 모든 콘텐츠를 단일 디스크 파일에 넣음으로써 문서 은유를 보존해요. 그리고 압축되어 있어서 포장된 파일 더미 형식은 더 컴팩트한 경향이 있어요.

커스텀 파일 형식과 마찬가지로, 순수 파일 더미 형식과 달리, 포장된 파일 더미 형식은 편집하기 쉽지 않아요. 어떤 구성 요소를 바꾸려면 보통 전체 파일을 다시 써야 하기 때문이에요.

이 문서의 목적은 애플리케이션 파일 형식의 네 번째 새로운 범주, 즉 SQLite 데이터베이스 파일을 주장하는 것이에요.

3. 애플리케이션 파일 형식으로서의 SQLite

파일 더미에 기록할 수 있는 어떤 애플리케이션 상태든, 다음과 같은 단순한 키/값 스키마를 가진 SQLite 데이터베이스에도 기록할 수 있어요:

CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);

콘텐츠가 압축된다면, 이런 SQLite Archive 데이터베이스는 동등한 ZIP 아카이브와 같은 크기(±1%)이며, 전체 문서를 다시 쓰지 않고 개별 "파일"을 갱신할 수 있다는 장점이 있어요.

하지만 SQLite 데이터베이스는 파일 더미 데이터베이스 같은 단순한 키/값 구조로 제한되지 않아요. SQLite 데이터베이스는 수십, 수백, 수천 개의 서로 다른 테이블을 가질 수 있고, 테이블마다 수십, 수백, 수천 개의 필드가 있으며, 각각 서로 다른 데이터 타입과 제약 조건과 특정한 의미를 갖고, 모두 서로 교차 참조하며, 빠른 검색을 위해 적절하고 자동으로 인덱싱되고, 모두 단일 디스크 파일에 효율적이고 컴팩트하게 저장돼요. 그리고 이 모든 구조가 SQL 스키마에 의해 사람에게 간결하게 문서화돼요.

다시 말해 SQLite 데이터베이스는 파일 더미나 포장된 파일 더미 형식이 할 수 있는 모든 것을 할 수 있고, 훨씬 더 많은 것을 더 큰 명료함으로 할 수 있어요. SQLite 데이터베이스는 키/값 파일시스템이나 ZIP 아카이브보다 더 다재다능한 컨테이너예요. (자세한 예는 OpenOffice 사례 연구 수필을 참고해 주세요.)

SQLite 데이터베이스의 힘은 이론적으로 커스텀 파일 형식으로도 달성할 수 있어요. 하지만 관계형 데이터베이스만큼 표현력이 있는 어떤 커스텀 파일 형식이라도 방대한 설계 명세와 수만~수십만 줄의 구현 코드가 필요할 거예요. 그리고 최종 결과는 특수 도구 없이는 접근할 수 없는 "불투명한 블롭"이 될 거예요.

따라서 다른 접근들과 비교할 때, SQLite 데이터베이스를 애플리케이션 파일 형식으로 사용하는 것은 설득력 있는 장점이 있어요. 그 장점 몇 가지를 나열하고 설명하면:

단순화된 애플리케이션 개발 (Simplified Application Development). 애플리케이션 파일을 읽거나 쓰기 위한 새 코드가 필요 없어요. SQLite 라이브러리에 링크하거나, 단일 "sqlite3.c" 소스 파일을 나머지 애플리케이션 C 코드와 함께 포함하기만 하면, SQLite가 모든 애플리케이션 파일 I/O를 처리해 줘요. 이는 애플리케이션 코드 크기를 수천 줄 줄일 수 있고, 개발·유지보수 비용을 그만큼 절약해 줘요.

SQLite는 세계에서 가장 많이 사용되는 소프트웨어 라이브러리 중 하나예요. 스마트폰과 가젯, 데스크톱 애플리케이션에서 매일 문자 그대로 수백억 개의 SQLite 데이터베이스 파일이 사용돼요. SQLite는 신중하게 테스트되고 신뢰성이 입증되어 있어요. 많은 튜닝이나 디버깅이 필요 없는 구성 요소라서 개발자는 애플리케이션 로직에 집중할 수 있어요.

단일 파일 문서 (Single-File Documents). SQLite 데이터베이스는 단일 파일에 담겨 있어서 쉽게 복사하거나 옮기거나 첨부할 수 있어요. "문서" 은유가 보존돼요.

SQLite는 파일 이름 요구 사항이 없으므로 애플리케이션은 원하는 어떤 커스텀 파일 접미사를 사용해서 파일이 애플리케이션에 "속함"을 식별하는 데 도움을 줄 수 있어요. SQLite 데이터베이스 파일은 헤더에 4바이트 Application ID를 담고 있어서, 이를 애플리케이션 정의 값으로 설정한 다음 file(1) 같은 유틸리티 프로그램이 문서의 "타입"을 식별하는 데 사용할 수 있어요. 이로써 문서 은유가 더욱 강화돼요.

고수준 쿼리 언어 (High-Level Query Language). SQLite는 완전한 관계형 데이터베이스 엔진이라서, 애플리케이션은 고수준 쿼리로 콘텐츠에 접근할 수 있어요. 애플리케이션 개발자는 문서에서 필요한 정보를 "어떻게" 검색할지 고민할 필요가 없어요. 개발자는 "무엇"을 원하는지 표현하는 SQL을 작성하고, 데이터베이스 엔진이 그 콘텐츠를 가장 잘 검색할 방법을 알아내게 하면 돼요. 이는 개발자가 "고개를 들고" 작동하며 사용자의 문제 해결에 집중하고, "고개를 숙여" 저수준 파일 형식 세부사항을 만지작거리는 데 시간을 허비하지 않게 해 줘요.

파일 더미 형식은 키/값 데이터베이스로 볼 수 있어요. 키/값 데이터베이스는 데이터베이스가 전혀 없는 것보다는 나아요. 하지만 트랜잭션, 인덱스, 고수준 쿼리 언어, 적절한 스키마가 없다면, 키/값 데이터베이스를 사용하는 것은 관계형 데이터베이스보다 훨씬 어렵고 오류가 발생하기 쉬워요.

접근 가능한 콘텐츠 (Accessible Content). SQLite 데이터베이스 파일에 담긴 정보는 흔히 사용되는 오픈소스 명령줄 도구로 접근할 수 있어요 — Mac과 Linux 시스템에 기본 설치되어 있고 Windows에서는 자체 포함 EXE 파일로 무료로 제공되는 도구들이죠. 커스텀 파일 형식과 달리, SQLite 데이터베이스의 콘텐츠를 읽거나 쓰기 위해 애플리케이션 전용 프로그램이 필요하지 않아요. SQLite 데이터베이스 파일은 불투명한 블롭이 아니에요. 텍스트 편집기나 "grep", "awk" 같은 명령줄 도구가 SQLite 데이터베이스에는 쓸모없다는 것은 사실이지만, SQL 쿼리 언어가 콘텐츠를 검사하는 훨씬 더 강력하고 편리한 방법이므로 "grep"과 "awk"를 사용할 수 없다는 것은 손실로 여겨지지 않아요.

SQLite 데이터베이스는 잘 정의되고 잘 문서화된 파일 형식이며, 문자 그대로 수백만 개의 애플리케이션이 널리 사용하고, 2004년 시작 때부터 하위 호환되며, 앞으로 수십 년간 계속 호환될 것을 약속해요. SQLite 데이터베이스 파일의 장수(longevity)는 맞춤 애플리케이션에게 특히 중요해요. 원래 애플리케이션의 흔적이 모두 사라진 훨씬 먼 미래에도 문서 콘텐츠에 접근할 수 있게 해 주기 때문이에요. 데이터는 코드보다 오래 삽니다. SQLite 데이터베이스는 디지털 콘텐츠의 장기 보존을 위한 저장 형식으로 미국 의회도서관이 권장 해요.

크로스 플랫폼 (Cross-Platform). SQLite 데이터베이스 파일은 32-bit와 64-bit 머신 사이, 빅-엔디언과 리틀-엔디언 아키텍처 사이, 다양한 종류의 Windows와 Unix 계열 운영 체제 사이에서 이식 가능해요. SQLite 애플리케이션 파일 형식을 사용하는 애플리케이션은 정수나 부동소수점 숫자의 바이트 순서에 대해 걱정할 필요 없이 이진 숫자 데이터를 저장할 수 있어요. 텍스트 콘텐츠는 UTF-8, UTF-16LE, UTF-16BE로 읽거나 쓸 수 있고, SQLite는 필요한 변환을 자동으로 즉시 수행해 줘요.
원자적 트랜잭션 (Atomic Transactions). SQLite 데이터베이스에 대한 쓰기는 원자적이에요. 시스템 크래시나 정전 중에도 완전히 일어나거나 전혀 일어나지 않아요. 그래서 변경 사항이 디스크에 쓰이는 찰나에 우연히 전원이 꺼졌다고 해서 문서가 손상될 위험이 없어요.

SQLite는 트랜잭션적이라서, 여러 변경을 함께 묶어 모두 발생하거나 아무것도 발생하지 않게 할 수 있고, 커밋 전에 문제가 발견되면 변경을 롤백할 수 있어요. 이는 애플리케이션이 변경을 증분적으로 수행한 다음, 변경을 디스크에 커밋하기 전에 결과 데이터에 대해 다양한 정합성·일관성 검사를 실행할 수 있게 해 줘요. Fossil DVCS는 이 기법을 사용하여 각 변경 전에 저장소 이력이 손실되지 않았는지 검증해요.

증분 및 연속 갱신 (Incremental And Continuous Updates). SQLite 데이터베이스 파일에 쓸 때는 실제로 변경된 파일 부분만 디스크에 쓰여져요. 이는 쓰기를 더 빠르게 하고 SSD의 마모를 줄여 줘요. 이것은 커스텀 및 포장된 파일 더미 형식에 비해 엄청난 장점인데, 둘 다 한 바이트를 바꾸기 위해 보통 전체 문서를 다시 써야 하거든요. 순수 파일 더미 형식도 어느 정도 증분 갱신을 할 수 있지만, 쓰기 단위가 보통 SQLite(단일 페이지)보다 파일 더미 형식(단일 파일)에서 더 커요.

SQLite는 연속 갱신도 지원해요. 변경을 메모리에 모아서 File/Save 동작에서만 디스크에 쓰는 대신, 변경이 발생할 때마다 디스크로 다시 쓸 수 있어요. 이는 시스템 크래시나 정전 시 작업 손실을 피하게 해 줘요. 트리거로 관리되는 자동화된 undo/redo 스택을 온-디스크 데이터베이스에 유지할 수 있어서, undo/redo가 세션 경계를 넘어 발생할 수 있어요.

쉽게 확장 가능 (Easily Extensible). 애플리케이션이 성장함에 따라, 스키마에 새 테이블을 추가하거나 기존 테이블에 새 컬럼을 추가하는 것만으로 SQLite 애플리케이션 파일 형식에 새 기능을 추가할 수 있어요. 컬럼이나 테이블을 추가해도 이전 쿼리의 의미는 바뀌지 않으므로, 레거시 컬럼과 테이블의 의미가 보존되도록 조금만 주의하면 하위 호환성이 유지돼요.

커스텀이나 파일 더미 형식도 물론 확장할 수 있지만, 그렇게 하는 것이 훨씬 어려운 경우가 많아요. 인덱스를 추가하면 해당 테이블을 변경하는 모든 애플리케이션 코드를 찾아 그 인덱스를 최신 상태로 유지하도록 수정해야 해요. 컬럼을 추가하면 해당 테이블에 접근하는 모든 애플리케이션 코드를 찾아 새 컬럼을 고려하도록 수정해야 해요.

성능 (Performance). 많은 경우 SQLite 애플리케이션 파일 형식은 파일 더미 형식이나 커스텀 형식보다 빠를 거예요. 원시 읽기·쓰기가 빠른 것에 더해, SQLite는 전체 문서를 메모리로 읽고 파싱하는 대신 초기 화면에 필요한 정보만 추출하는 쿼리를 할 수 있어서 시작 시간을 극적으로 개선하는 경우가 많아요. 애플리케이션이 진행됨에 따라 다음 화면을 그리는 데 필요한 만큼만 불러오고, 더 이상 사용하지 않는 이전 화면의 정보는 버릴 수 있어요. 이는 애플리케이션의 메모리 사용량을 통제하는 데 도움이 돼요.

파일 더미 형식도 SQLite처럼 증분적으로 읽을 수 있어요. 하지만 많은 개발자들이 놀라는 점은, SQLite가 더 작은 BLOB(약 100KB 미만)을 파일시스템에서 별도 파일로 읽거나 쓰는 것보다 데이터베이스에서 더 빠르게 읽고 쓸 수 있다는 사실이에요. (자세한 내용은 35% Faster Than The Filesystem과 Internal Versus External BLOBs를 참고해 주세요.) 관계형 데이터베이스 엔진을 운영하는 데는 오버헤드가 있지만, 직접 파일 I/O가 SQLite 데이터베이스 I/O보다 항상 빠르다고 가정해서는 안 돼요. 종종 그렇지 않거든요.

어느 쪽이든 SQLite 애플리케이션에서 성능 문제가 발생한다면, 스키마에 CREATE INDEX 문 하나나 둘을 추가하거나 ANALYZE를 한 번 실행하는 것으로 해결되는 경우가 많아요. 애플리케이션 코드는 한 줄도 건드릴 필요 없이요. 하지만 커스텀이나 파일 더미 형식에서 성능 문제가 발생하면, 해결책은 종종 새 인덱스를 추가·유지하거나 다른 알고리즘으로 정보를 추출하기 위해 애플리케이션 코드를 광범위하게 변경해야 해요.

여러 프로세스의 동시 사용 (Concurrent Use By Multiple Processes). SQLite는 여러 스레드 및/또는 프로세스의 같은 문서에 대한 동시 접근을 자동으로 조정해요. 둘 이상의 애플리케이션이 같은 문서에 연결해 동시에 읽을 수 있어요. 쓰기는 직렬화되지만, 쓰기는 보통 밀리초만 걸리므로 애플리케이션들은 그냥 번갈아 쓰게 돼요. SQLite는 문서의 저수준 형식이 손상되지 않도록 자동으로 보장해요. 반면 커스텀이나 파일 더미 형식으로 같은 것을 달성하려면 애플리케이션에 광범위한 지원이 필요해요. 그리고 동시성을 지원하는 데 필요한 애플리케이션 로직은 악명 높은 버그 자석이에요.
여러 프로그래밍 언어 (Multiple Programming Languages). SQLite 자체는 ANSI-C로 작성되었지만, 생각할 수 있는 거의 모든 다른 프로그래밍 언어용 인터페이스가 존재해요: C++, C#, Objective-C, Java, Tcl, Perl, Python, Ruby, Erlang, JavaScript 등등. 그래서 프로그래머는 가장 편안한 언어이자 프로젝트의 요구에 가장 잘 맞는 언어로 개발할 수 있어요.

SQLite 애플리케이션 파일 형식은 종종 다른 언어와 다른 개발 팀이 작성한 별도 프로그램들의 모음 또는 "연합(federation)"이 있는 경우에 훌륭한 선택이에요. 이는 데이터 수집을 책임지는 한 팀과 분석의 여러 단계를 책임지는 다른 팀들이 있는 연구나 실험실 환경에서 흔히 발생해요. 각 팀은 가장 편안한 하드웨어, 운영 체제, 프로그래밍 언어, 개발 방법론을 사용할 수 있고, 모든 프로그램이 공통 스키마의 SQLite 데이터베이스를 사용하기만 하면 모두 함께 상호 운용할 수 있어요.

더 나은 애플리케이션 (Better Applications). 애플리케이션 파일 형식이 SQLite 데이터베이스라면, 그 파일 형식의 완전한 문서는 데이터베이스 스키마로 구성되고, 각 테이블과 컬럼이 무엇을 나타내는지에 대한 몇 마디 추가 설명이 더해질 뿐이에요. 반면 커스텀 파일 형식의 설명은 보통 수백 페이지에 달해요. 파일 더미 형식은 완전 커스텀 형식보다 훨씬 단순하고 설명하기 쉽지만, 개별 파일의 이름과 형식을 여전히 설명해야 하므로 SQL 스키마 덤프보다 훨씬 크고 복잡한 경향이 있어요.

이것은 하찮은 지점이 아니에요. 명확하고 간결하며 이해하기 쉬운 파일 형식은 어떤 애플리케이션 설계의 핵심적인 부분이에요. Fred Brooks는 그의 역대 베스트셀러 컴퓨터 과학 교재 The Mythical Man-Month에서 이렇게 말해요:

표현(Representation)은 컴퓨터 프로그래밍의 본질이다.... 당신의 순서도를 보여주고 당신의 테이블을 숨겨라, 그러면 나는 계속 미스터리하게 남을 것이다. 당신의 테이블을 보여줘라, 그러면 나는 보통 당신의 순서도가 필요 없을 것이다; 그것들은 명백할 것이다.

Rob Pike는 그의 Rules of Programming에서 같은 생각을 이렇게 표현해요:

데이터가 지배한다. 올바른 데이터 구조를 선택하고 잘 조직했다면, 알고리즘은 거의 항상 자명할 것이다. 알고리즘이 아니라 데이터 구조가 프로그래밍의 중심이다.

Linus Torvalds는 2006-06-27에 Git 메일링 리스트에서 거의 같은 말을 다른 말로 했어요:

나쁜 프로그래머는 코드에 대해 걱정한다. 좋은 프로그래머는 데이터 구조와 그 관계에 대해 걱정한다.

요점은 이거예요: SQL 데이터베이스 스키마는 거의 항상 테이블과 데이터 구조 및 그 관계를 정의하고 조직하는 훨씬 더 좋은 역할을 해요. 그리고 명확하고 간결하며 잘 정의된 표현을 갖는 것은 거의 항상 더 잘 수행되고, 문제가 더 적고, 개발·유지보수가 더 쉬운 애플리케이션을 낳아요.

4. 보안 고려 사항 (Security Considerations)

SQLite는 악의적으로 잘못 만들어진 데이터베이스 파일과 SQL 입력에 대해 견고해요. 공격자는 애플리케이션 파일로 사용되는 SQLite 데이터베이스를 손상시켜 메모리 오류를 유발할 수 없어요.

SQLite 데이터베이스인 애플리케이션 파일을 사용자가 열도록 속여, 교묘한 공격자가 애플리케이션에 대해 수행할 수 있는 공격이 있어요. 하지만 몇 가지 간단한 예방 조치로 심각한 침투나 손상을 막을 수 있어요. SQLite(또는 어쨌든 관계형 데이터베이스)를 애플리케이션 파일 형식으로 사용하기로 선택한다면, defense against dark arts 문서, 특히 untrusted database files 섹션을 검토해서 신중한 방어 조치를 갖추고 실수로 보안 허점을 열지 않았는지 확인해 주세요.

5. 결론 (Conclusion)

SQLite는 모든 상황에 완벽한 애플리케이션 파일 형식은 아니에요. 하지만 많은 경우 SQLite는 커스텀 파일 형식, 파일 더미, 포장된 파일 더미보다 훨씬 더 나은 선택이에요. SQLite는 고수준이고, 안정적이고, 신뢰할 수 있고, 크로스 플랫폼이고, 널리 배포되고, 확장 가능하고, 성능이 좋고, 접근 가능하고, 동시성 있는 파일 형식이에요. 다음 애플리케이션 설계의 표준 파일 형식으로 고려할 가치가 있어요.

애플리케이션 파일 형식으로서의 SQLite