SQLite의 창시자가 밝히는 26년간의 성공 비결은 자신만의 도구를 직접 만들고, 외부 기여를 최소화하며, 철저한 테스트를 통해 코드의 품질을 유지하는 것이다.

이는 복잡한 오픈소스 생태계에서 흔히 간과되는‘자유’의 본질을 보여준다.

목차

1. SQLite 창시자, 리처드 히프의 26년 코드 여정

SQLite의 창시자인 리처드 히프(Richard Hipp) 는 26년간의 코드 개발 여정을 통해 다음과 같은 철학을 실천해왔다.

• 자신에게 필요한 도구를 직접 개발한다.
• 외부의 코드 기여를 최소화한다.
• 철저한 테스트를 통해 코드 품질을 유지한다.
• 외부 의존성을 줄여 개발의 자유를 확보한다.

1.1. SQLite의 탄생: 군함에서 시작된 문제 해결

군함 프로젝트에서 시작된 SQLite

• SQLite는 군함
  USS Oscar Austin관련 계약 업무에서 시작되었다. - 당시 리처드 히프는 General Dynamics의 계약자로서 Bath Iron Works의
  DDG-79 함선 건조 프로젝트에 참여하고 있었다. - 함선의 손상 통제 정보 시스템 개발에 문제가 발생했다.
• 다른 회사가 수백만 달러를 투자했지만, 제대로 된 결과물을 내지 못한 상황이었다.

기존 데이터베이스 시스템의 한계

• 리처드 히프는 손상 통제 시스템의 문제를 해결하기 위해 빠른 휴리스틱 기반 소프트웨어를 개발했다.
• 그러나 데이터 저장에 사용하던
  Informix 데이터베이스 엔진이 중단되면 소프트웨어도 함께 작동하지 않는 문제가 있었다. - 시스템 관리자가 데이터베이스 엔진을 중단한 상태에서도 소프트웨어는 계속 작동해야 했다.
• 이에 따라 별도의 데이터베이스 프로세스 없이 애플리케이션이 디스크의 데이터를 직접 읽는 방식을 고민하게 되었다.
• 당시에는 이러한 요구사항을 충족하는 SQL 데이터베이스 엔진을 찾기 어려웠기 때문에 직접 개발해야 했다.

독학으로 시작한 관계형 데이터베이스 연구

• 당시에는 인터넷 검색이 지금처럼 보편화되지 않았다.
• 리처드 히프는 지역 대학 도서관에서 관련 자료를 찾아 관계형 데이터베이스 기술을 연구했다.
• 당시 MIT, 하버드, 버클리 등에서는 관계형 데이터베이스 연구가 활발하게 진행되고 있었다.
• 그러나 지리적인 제약 때문에 최신 연구 정보를 쉽게 얻을 수 없었다.
• 결국 필요한 데이터베이스 기술을 스스로 연구하고 구현하게 되었다.

1.2. SQLite의 성장과 상업적 성공

수익 목적 없이 시작된 프로젝트

• SQLite는 처음부터 수익화를 목적으로 개발된 소프트웨어가 아니었다.
• 초기 버전은 무료 소프트웨어로 공개되었다.
• 개발 당시에는 이를 통해 사업을 하거나 수익을 얻을 계획이 없었다.

모토로라와의 첫 상업 계약

• SQLite 공개 후 몇 년이 지나 휴대폰 제조사
  **모토로라(Motorola)**로부터 연락을 받았다. - 모토로라는 SQLite를 자사의 휴대폰에 탑재하고자 했다.
• 이를 계기로 SQLite의 첫 상업적 계약이 체결되었다.
• 계약은 사용량에 따른 라이선스 방식이 아닌 고정 가격 방식으로 진행되었다.

AOL과의 협력

• 이후
  **America Online(AOL)**도 CD-ROM 패키지에 SQLite를 포함하기 위한 계약을 체결했다. - 이 계약 역시 고정 가격 방식으로 이루어졌다.
• 리처드 히프는 당시 계약 금액이 SQLite의 가치에 비해 상대적으로 저렴했다고 평가했다.

Symbian OS의 SQLite 선택

• 노키아 등의 휴대폰에 사용되던
  Symbian OS는 데이터베이스 엔진을 선정하기 위해 블라인드 테스트를 진행했다. - 총 10개의 데이터베이스 엔진이 평가 대상에 포함되었다.
• 테스트 결과 SQLite가 최종적으로 선택되었다.
• 이 과정에서 SQLite가 한 명의 핵심 개발자에게 지나치게 의존한다는 문제가 제기되었다.
• 이른바
  **버스 팩터(bus factor)**를 높이기 위해 컨소시엄을 구성하라는 제안을 받았다.

버스 팩터

프로젝트의 핵심 인력 몇 명이 갑작스럽게 업무를 수행할 수 없게 되었을 때 프로젝트가 유지될 수 있는지를 나타내는 지표이다.

버스 팩터가 1이라는 것은 핵심 개발자 한 명이 빠질 경우 프로젝트 유지가 어려워질 수 있다는 의미이다.

컨소시엄 설립과 전업 개발

• Mozilla의
  **미첼 베이커(Mitchell Baker)**가 컨소시엄 설립에 대해 조언했다. - 이를 바탕으로 SQLite 컨소시엄이 설립되었다.
• 컨소시엄 설립 이후 리처드 히프는 SQLite 개발을 전업으로 수행하게 되었다.
• 여러 명의 직원을 고용하면서 소규모이지만 지속 가능한 개발 조직을 운영하게 되었다.

2050년까지의 장기 지원 계획

• 2010년 에어버스는
  A350 항공기 프로젝트의 항공전자장비에 SQLite를 사용하고자 했다. - 에어버스는 SQLite가 장기간 유지·지원될 수 있는지를 문의했다.
• 항공기 동체 수명이 약 40년이라는 점을 고려해 장기 지원을 약속했다.
• 이러한 약속은 법적인 의무라기보다 SQLite 프로젝트가 추구하는 장기적인 목표에 가까웠다.
• 현재 리처드 히프는 SQLite의 개인적인 지원 종료 목표를
  2050년으로 설정하고 있다. - 이는 데이터의 예상 수명보다 코드를 더 오래 유지한다는 이른바
  ‘데이터 우선 코드’에 50년을 더하는 방식으로 정한 목표이다.

1.3. 라이선스, 오픈소스 철학, 그리고 자체 도구 개발

‘기도’ 라이선스의 탄생

• SQLite 버전 1은
  GDBM 라이브러리에 의존했다. - GDBM이 GPL 라이선스를 사용했기 때문에 SQLite 역시 GPL의 영향을 받을 수밖에 없었다.
• 이후 레인지 쿼리를 지원하기 위해 B-tree 기반의 자체 저장소 백엔드를 개발했다.
• 외부 라이브러리 의존성이 제거되면서 라이선스를 자유롭게 선택할 수 있게 되었다.

퍼블릭 도메인의 선택

• 당시 널리 알려진 라이선스는 MIT와 Berkeley 라이선스 정도였다.
• 리처드 히프는 복잡한 법률 조항을 포함한 라이선스를 사용하는 대신 SQLite를
  **퍼블릭 도메인(Public Domain)**으로 공개했다. - 이후 퍼블릭 도메인 개념이 모든 국가에서 동일하게 인정되는 것은 아니라는 사실을 알게 되었다.
• 그럼에도 SQLite의 공개 방침은 결과적으로 오픈소스 라이선스와 유사한 방식으로 받아들여지고 있다.

‘기도문’ 문구

SQLite 소스 코드의 헤더에는 일반적인 법률 문구 대신 축복 또는 기도에 가까운 문구가 포함되었다.

May you do good and not evil.

May you find forgiveness for yourself and forgive others.

May you share freely, never taking more than you give.

SQLite가 세계에서 가장 널리 사용되는 소프트웨어 라이브러리 가운데 하나가 되면서 이 문구 역시 SQLite의 독특한 라이선스 철학을 상징하게 되었다.

외부 기여를 최소화하는 개발 방식

• SQLite는 일반적인 오픈소스 프로젝트처럼 풀 리퀘스트를 적극적으로 받지 않는다.

• 외부 기여를 최소화하고, 핵심 개발팀이 직접 코드를 작성하고 관리하는 방식을 유지한다.

• 리처드 히프는 풀 리퀘스트를
  **‘무료 강아지(free puppy)’**에 비유한다. - 강아지를 무료로 받더라도 이후 돌봄과 관리 책임이 발생하는 것처럼, 외부 코드를 받으면 다음과 같은 장기적인 책임이 뒤따르기 때문이다.

• 코드 유지보수

• 테스트

• 문서화

• 오류 수정

• 다른 플랫폼과의 호환성 관리

• 장기간의 기술적 책임

• 외부 기여를 제한하는 방식은 SQLite가 26년 이상 일관된 품질과 방향성을 유지할 수 있었던 요인 중 하나이다.

자체 도구 개발 사례

Fossil

Fossil은 SQLite 프로젝트를 관리하기 위해 만든 자체 버전 관리 시스템이다.- Git과 비슷한 시기에 개발되었다.

• 소스 코드 관리뿐만 아니라 다음 기능을 통합적으로 제공한다.

• 버전 관리

• 이슈 추적

• 위키

• 포럼

• 웹 인터페이스

• Fossil 자체가 SQLite를 기반으로 만들어졌다.

• 따라서 Fossil은 SQLite의 실질적인 베타 테스트 플랫폼 역할도 한다.

• Fossil을 개발하고 운영하는 과정에서 애플리케이션 개발자의 관점으로 SQLite의 문제점을 발견하고 개선할 수 있었다.

• 리처드 히프는 Git이 리눅스 커널과 같은 대규모 분산 프로젝트에 적합한 반면, SQLite와 같은 소규모 프로젝트에는 Fossil이 더 적합하다고 평가한다.

Lemon

Lemon은 SQLite의 SQL 파서를 생성하기 위해 개발한 도구이다.- 기존의 Yacc나 Bison을 사용하는 대신 직접 제작했다.

• 자체 도구이기 때문에 SQLite의 요구사항에 맞게 파서 생성 방식을 자유롭게 개선할 수 있었다.

자체 도구와 자유의 철학

• 리처드 히프에게 자체 도구 개발은 단순한 기술적 취향이 아니다.
• 자신에게 필요한 도구를 직접 만드는 것은 스스로를 돌보는 행위라고 본다.
• 외부 의존성을 줄이면 다른 프로젝트나 기업의 결정에 영향을 덜 받게 된다.
• 이러한 독립성이 곧 개발자의 자유를 확대한다고 판단한다.
• 다만 SQLite가 세계의 수많은 시스템에서 핵심 의존성으로 사용되는 상황에 대해서는 부담과 우려도 가지고 있다.

1.4. 철저한 테스트와 AI 시대의 소프트웨어 개발

SQLite 성공의 핵심인 테스트

• SQLite가 오랫동안 안정성을 유지할 수 있었던 핵심 요인 중 하나는 극도로 철저한 테스트이다.
• SQLite 개발팀은 단순히 기능이 작동하는지를 확인하는 수준을 넘어 다양한 예외 상황과 플랫폼을 검증한다.
• 실제 제품 코드보다 테스트 코드의 양이 훨씬 많을 정도로 테스트를 중요하게 다룬다.

DO-178B 표준의 적용

• SQLite 개발팀은 항공기 소프트웨어 개발 표준인
  DO-178B방식을 테스트에 적용했다. - 이를 통해 테스트 커버리지를 체계적으로 높였다.
• 안드로이드 개발 초기 단계에서 DO-178B 수준의 테스트 커버리지를 달성한 이후 버그 보고가 거의 사라지는 결과를 경험했다.
• 이 경험을 통해 철저한 테스트가 실제 소프트웨어 안정성 향상에 직접적인 영향을 미친다는 사실을 확인했다.

퍼징을 통한 새로운 버그 발견

• 이후
  **프로파일 기반 퍼징(profile-guided fuzzing)**기술이 등장했다. - 퍼징은 무작위 또는 변형된 데이터를 프로그램에 입력하여 예상하지 못한 오류를 찾는 방식이다.
• 기존의 DO-178C 수준 테스트로도 발견하기 어려운 새로운 유형의 버그가 퍼징을 통해 발견되었다.
• 이는 높은 테스트 커버리지만으로 모든 오류를 찾을 수 있는 것은 아니라는 사실을 보여준다.

AI가 발견하는 버그

• 최근에는 AI를 활용해 버그를 탐색하거나 버그 보고서를 작성하는 사례도 등장하고 있다.
• SQLite 프로젝트에도 AI가 생성한 것으로 의심되는 버그 보고가 접수된 적이 있다.
• AI는 기존 테스트와 퍼징을 보완하는 새로운 소프트웨어 검증 도구가 될 가능성이 있다.

AI에 대한 리처드 히프의 평가

• 리처드 히프는 AI에 대한 생각이 매일 달라질 수 있다고 말한다.
• 현재는 AI를 매우 유용한 도구로 활용하고 있다.
• ChatGPT에 SQLite 코드에 관한 질문을 했을 때 AI가 자신에게 다음과 같은 방식으로 답변한 경험을 소개했다.

“물론 당신도 알고 있겠지만…”

• 자신이 작성한 코드에 대해 AI가 마치 자신보다 더 잘 아는 것처럼 말하는 모습에서 다소 소름 끼치는 느낌을 받았다고 설명했다.
• AI는 정보를 탐색하고 아이디어를 얻는 데 유용하다.
• 그러나 항상 정확하지는 않으며, 매우 설득력 있는 표현으로 잘못된 정보를 제공할 수 있다.
• AI가 생성한 코드는 특정 운영체제에서는 작동하지만 다른 운영체제에서는 작동하지 않는 등 호환성 문제가 발생하기도 했다.
• 따라서 AI가 만든 결과물도 사람이 직접 검토하고 수정해야 한다.

젊은 개발자에게 전하는 조언

• 리처드 히프는 SQLite를 포크하여 더 나은 데이터베이스를 만들려는 시도를 환영한다.

• 다만 SQLite와 같은 수준에 도달하려면 다음 요소가 필요하다고 강조한다.

• 25년 이상의 지속적인 개발

• 하나의 주제에 대한 집요한 헌신

• 장기간의 테스트와 개선

• 사용자 요구에 대한 지속적인 관찰

• 실패를 반복하며 축적한 경험

• 뛰어난 소프트웨어는 단기간에 만들어지는 것이 아니다.

• AI로 인해 소프트웨어 개발 방식이 크게 달라질 가능성이 있지만, 미래가 어떤 모습이 될지는 쉽게 예측하기 어렵다고 평가한다.

1.5. SQLite의 지속 가능성과 인간적인 측면

26년 동안 지속될 수 있었던 이유

• 리처드 히프는 SQLite의 성공을 자신의 능력보다는
  신성한 섭리와 행운으로 설명한다. - 자신이 특별히 뛰어난 프로그래머라고 생각하지는 않는다고 말한다.

• 다만 다음과 같은 성향이 SQLite의 발전에 도움이 되었다고 분석한다.

• 완고하게 자신의 방식을 유지하는 태도

• 기존의 통념에 의문을 제기하는 태도

• 필요한 도구를 직접 만드는 습관

• 장기간 하나의 문제에 집중하는 성향

• 개발 과정 자체를 즐기는 자세

• SQLite를 개발하면서 어떻게 하면 더 잘 만들 수 있을지를 끊임없이 고민하는 과정 자체가 중요했다고 말한다.

작은 팀의 장점

• 리처드 히프는 자신이 많은 사람과 어울리거나 조직 내 정치적 관계를 관리하는 데 능숙하지 않다고 말한다.
• 이러한 성격 때문에 SQLite 개발팀을 소규모로 유지해왔다.
• 결과적으로 작은 팀 구조가 SQLite의 일관된 방향성과 빠른 의사결정에 도움이 되었다고 평가한다.
• 리눅스의 리누스 토르발스처럼 수많은 개발자와 관계를 조율하는 능력은 자신에게 없다고 인정한다.

아내 진저와의 회사 운영

• 리처드 히프는 아내인
  **진저(Ginger)**와 함께 회사를 운영한다. - 두 사람은 상황에 따라 서로의 직책을 바꾸는 등 유연한 팀워크를 유지하고 있다.
• 진저는 음악가이면서 컴퓨터 문제로 어려움을 겪는 다른 음악가들을 돕는 데 능숙하다.
• 리처드 히프는 진저가 자신보다 지역 사회에서 더 유명하다고 이야기한다.

소프트웨어 개발의 인간적인 측면

• 리처드 히프는 소프트웨어를 단순한 코드나 기술의 집합으로만 보지 않는다.
• 개발자의 감정, 협업 관계, 집착, 실패, 성취감 등 인간적인 요소가 소프트웨어 개발에서 중요하다고 강조한다.
• 소프트웨어는 복잡하고 추상적인 결과물이지만, 그 이면에는 이를 만든 사람들의 이야기가 존재한다.

추천 도서: 《The Soul of a New Machine》

• 리처드 히프는 소프트웨어와 컴퓨터 개발의 인간적인 측면을 이해할 수 있는 책으로
  **《The Soul of a New Machine》**을 추천한다. - 이 책은 단순히 컴퓨터 기술만을 설명하는 것이 아니다.

• 새로운 컴퓨터를 개발하는 과정에서 나타나는 다음과 같은 요소를 다룬다.

• 개발자들의 열정

• 조직 내부의 갈등

• 기술적 도전

• 실패와 좌절

• 협업과 경쟁

• 창조 과정에서의 감정

• 복잡한 기술을 깊이 이해하면서도 이를 인간적인 이야기로 전달할 수 있는 능력이 중요하다고 강조한다.

결론

SQLite가 26년 이상 성공적으로 유지될 수 있었던 이유는 단순히 뛰어난 기술력 때문만은 아니다.

핵심 성공 요인은 다음과 같이 정리할 수 있다.

**실제 문제를 해결하기 위해 필요한 기술을 직접 개발했다.****외부 의존성을 줄이고 프로젝트의 통제권을 유지했다.****외부 기여보다 장기적인 유지보수 책임을 중요하게 생각했다.****Fossil과 Lemon 등 자신에게 필요한 도구를 직접 만들었다.****항공 소프트웨어 수준의 철저한 테스트를 적용했다.****AI와 새로운 개발 기술을 활용하되 결과물을 맹신하지 않았다.****작은 팀과 인간적인 관계를 바탕으로 프로젝트를 운영했다.**하나의 주제에 장기간 집요하게 몰입했다.

SQLite의 사례가 보여주는 핵심은 자유는 아무런 제약이 없는 상태가 아니라, 자신이 사용하는 도구와 코드에 대해 스스로 책임지고 통제할 수 있는 상태라는 점이다.

외부 의존성을 줄이고, 필요한 도구를 직접 만들며, 철저하게 검증하는 SQLite의 개발 방식은 빠르게 변화하는 AI 시대에도 지속 가능한 소프트웨어 개발이 무엇인지 보여주는 중요한 사례이다.