Symbian OS의 블라인드 테스트를 통한 데이터베이스 엔진 선정

오픈소스 프로젝트에 기여하고 코드 리뷰를 거쳐 기능을 추가하는 과정은 현대 개발자에게 당연한 문화다. SQLite의 선정 과정은 달랐다. Symbian OS(심비안 OS, 모바일 운영체제)는 데이터베이스 엔진을 선정하기 위해 총 10개의 엔진을 대상으로 블라인드 테스트를 진행했다. 성능과 안정성을 검증한 결과, SQLite가 최종적으로 선택되었다.

선정 과정에서 핵심 개발자 1인에 대한 높은 의존성인 버스 팩터(Bus Factor, 핵심 인력이 갑자기 부재할 때 프로젝트가 중단될 위험) 문제가 제기되었다. 특정 개인의 역량과 유지보수 능력에만 의존하는 구조는 상용 제품에 도입하기에 리스크가 컸다. 이를 해결하기 위해 SQLite 컨소시엄이 설립되며 개발 및 관리 체계가 조직화되었다.

2010년 에어버스는 A350 항공기 프로젝트의 항공전자장비에 SQLite를 도입했다. 항공기 동체 수명이 약 40년에 달한다는 점을 고려해 제조사는 초장기 지원을 요청했다. 리처드 히프(Richard Hipp)는 이러한 실무적 요구사항에 맞춰 SQLite의 지원 종료 목표를 2050년으로 설정하며, 하드웨어 수명에 맞춘 소프트웨어 지원 기준을 제시했다.

외부 기여를 최소화하고 핵심 개발팀이 직접 관리하는 개발 체계

대다수 오픈소스 프로젝트가 풀 리퀘스트(PR, 외부 개발자가 코드 변경을 제안하는 요청)를 통한 커뮤니티 확장을 당연하게 여기지만, SQLite는 외부 기여를 최소화하는 길을 택했다. 리처드 히프는 외부 코드를 수용하는 행위를 무료 강아지를 입양하는 것에 비유했다. 강아지를 받는 순간은 즐겁지만, 이후 수반되는 먹이 주기와 훈련 같은 유지보수, 테스트, 문서화 작업은 고스란히 관리자의 몫이 되기 때문이다. 외부 기여자가 떠난 뒤에도 남겨진 코드의 품질을 책임져야 하는 관리 부담을 제거하기 위해, 핵심 개발팀이 직접 모든 코드를 작성하고 관리하며 일관성을 유지했다.

안정성 확보를 위해 항공기 소프트웨어 개발 표준인 DO-178B 방식을 테스트에 적용했다. DO-178B는 항공기 시스템의 치명적 오류를 방지하기 위해 설계된 엄격한 소프트웨어 인증 표준이다. 안드로이드 개발 초기 단계에서 이 표준에 준하는 테스트 커버리지를 달성한 결과, 실제 사용자로부터 접수되는 버그 보고가 거의 사라졌다. 이후 개발팀은 프로그램의 실행 경로 정보를 활용해 무작위 데이터를 입력함으로써 숨은 버그를 찾는 프로파일 기반 퍼징(profile-guided fuzzing) 기술을 도입해 소프트웨어의 무결성을 확보했다.

이러한 철저한 품질 관리는 특정 환경의 제약 사항을 해결하기 위한 독자적인 아키텍처 설계로 이어졌다.

USS Oscar Austin 프로젝트에서 도출한 서버리스 구조와 자체 도구 전략

대부분의 데이터베이스 시스템은 서버 프로세스가 상주하며 데이터를 관리하는 구조를 전제로 설계된다. 리처드 히프는 군함 USS Oscar Austin 관련 계약 업무를 수행하며 이러한 표준 구조가 현장의 제약 사항과 충돌한다는 점을 확인했다. 시스템 관리자가 데이터베이스 엔진을 중단한 상태에서도 소프트웨어는 중단 없이 계속 작동해야 하는 환경이었다. 그는 별도의 데이터베이스 프로세스 없이 애플리케이션이 디스크의 데이터를 직접 읽는 방식의 SQL 데이터베이스 엔진을 개발하여 시스템 가용성을 확보했다.

외부 라이브러리에 의존하는 개발 방식은 타사의 정책 변경이나 외부 프로젝트의 방향 전환에 시스템 전체가 영향을 받는 리스크를 수반한다. SQLite는 외부 영향 없이 기능을 수정할 수 있는 환경을 구축하기 위해 외부 의존성을 최소화했다. 버전 관리와 이슈 추적을 위해 자체 제작한 Fossil(포실)과 SQL 파서(구문 분석기) 생성을 위해 개발한 Lemon(레몬)이 그 핵심 도구다. 외부 도구를 사용하는 대신 프로젝트 전용 툴체인을 구축함으로써 다른 기업의 결정에 영향을 덜 받게 되었으며, 요구사항에 맞춰 기능을 자유롭게 개선했다. 이러한 의존성 제거 전략은 외부 환경의 변화와 무관하게 소프트웨어를 장기적으로 유지할 수 있게 했다.

현대 개발 문화는 외부 기여를 통한 확장을 지향하지만, SQLite는 핵심 팀의 직접 관리와 의존성 제거로 정반대의 경로를 택했다. DO-178B 표준 적용과 Fossil, Lemon 같은 자체 도구 활용은 외부 환경의 변화로부터 소프트웨어를 격리하는 실무적 장치가 되었다.

지속 가능한 소프트웨어의 실무적 기준은 커뮤니티의 규모가 아닌, 철저한 의존성 관리와 테스트 커버리지 확보를 통한 무결성 유지에 있다. 외부 라이브러리에 대한 의존도를 낮추고 자체 검증 체계를 구축하는 것이 장기 생존을 위한 유일한 전략이다.