SQLite가 미국 의회도서관 추천 보존 포맷에 오른 이유

• SQLite가 미국 의회도서관의 데이터셋 추천 저장 포맷으로 올라가 있음

  • 원문 기준 시점인 2018년 5월 29일에는 데이터셋 추천 포맷이 XML, JSON, CSV, SQLite뿐이었음
  • SQLite를 그냥 “앱에 끼워 넣는 작은 DB”로만 보면 꽤 과소평가한 셈임

• 여기서 말하는 추천 저장 포맷은 “멋진 표준”이 아니라 “오래 살아남을 확률이 높은 형식”에 가까움

  • 보존 전문가들이 디지털 콘텐츠가 미래에도 계속 접근 가능할지 보고 고른 포맷이라는 뜻임
  • 즉, 새 기능이 많냐보다 문서화가 잘 되어 있고, 도구가 있고, 특정 회사나 환경에 덜 묶여 있는지가 중요함

• 미국 의회도서관이 보는 기준은 꽤 현실적임

  • 공개성은 완전한 명세와 검증 도구가 있는지를 봄. 공식 표준 기관 승인보다 “제대로 된 문서가 있냐”가 더 중요하다는 게 재밌는 포인트임
  • 채택률은 실제 생산자, 배포자, 사용자들이 이미 쓰고 있는지를 봄. 마스터 포맷, 사용자 전달용, 시스템 간 교환용 사용 사례가 모두 포함됨
  • 투명성은 텍스트 편집기 같은 기본 도구로 직접 분석 가능한지까지 따짐. CSV나 JSON이 강한 이유가 여기 있음

• SQLite가 유리한 건 파일 하나에 데이터와 구조를 같이 담을 수 있다는 점임

  • 자기 설명성 측면에서 테이블 구조, 타입 정보, 인덱스 같은 기술적 맥락을 파일 내부에 담을 수 있음
  • CSV처럼 가볍지만 스키마가 밖으로 빠져나가 유실되는 문제를 어느 정도 줄일 수 있음

• 외부 의존성, 특허, 암호화 같은 요소도 평가 대상임
  • 특정 하드웨어, 운영체제, 소프트웨어가 있어야만 열리는 포맷은 미래 보존 리스크가 커짐
  • 특허 때문에 보존 기관이 유지보수나 변환을 못 하게 되는지도 따짐
  • 암호화나 기술적 보호장치가 보존을 막는지도 중요한 기준임

---

기술 맥락

• SQLite가 여기서 흥미로운 이유는 데이터베이스이면서 동시에 파일 포맷이기 때문이에요. 보통 DB는 서버, 버전, 운영 환경까지 같이 떠올리는데 SQLite는 데이터셋을 파일 하나로 들고 다닐 수 있어서 장기 보관 시나리오에 잘 맞아요.

• XML, JSON, CSV는 사람이 읽거나 도구로 파싱하기 쉬운 대신, 복잡한 관계형 구조나 제약 조건을 온전히 담기엔 한계가 있어요. SQLite는 테이블, 인덱스, 일부 메타데이터를 파일 안에 같이 넣을 수 있으니 데이터의 모양을 잃어버릴 가능성이 줄어들어요.

• 미국 의회도서관의 기준이 개발자에게도 의미 있는 건 “미래의 나”가 결국 보존 담당자와 비슷한 문제를 겪기 때문이에요. 지금 만든 데이터 파일을 몇 년 뒤 다른 런타임, 다른 팀, 다른 운영체제에서 열어야 할 수 있거든요.

• 그래서 SQLite 선택은 단순히 가볍고 빠른 로컬 DB를 고르는 문제가 아니에요. 배포 없이 읽히는 명세, 넓은 채택률, 낮은 외부 의존성까지 같이 가져가는 선택이라서 아카이브와 제품 개발 양쪽에서 꽤 실용적인 카드가 돼요.