# SQLite의 창시자, 리처드 힙과 함께하는 Turso, AI, 그리고 26년간의 코드 이야기 [유튜브] > Clean Markdown view of GeekNews topic #30621. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30621](https://news.hada.io/topic?id=30621) - GeekNews Markdown: [https://news.hada.io/topic/30621.md](https://news.hada.io/topic/30621.md) - Type: news - Author: [baeba](https://news.hada.io/@baeba) - Published: 2026-06-19T09:18:32+09:00 - Updated: 2026-06-19T09:18:32+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=x8_ZZhRL3YU&t=1733s) - Points: 8 - Comments: 4 ## Topic Body > SQLite의 창시자가 밝히는 26년간의 성공 비결은 자신만의 도구를 직접 만들고, 외부 기여를 최소화하며, 철저한 테스트를 통해 코드의 품질을 유지하는 것이다. > 이는 복잡한 오픈소스 생태계에서 흔히 간과되는 **‘자유’의 본질**을 보여준다. --- #### 목차 1. [SQLite 창시자, 리처드 히프의 26년 코드 여정](#1-sqlite-창시자-리처드-히프의-26년-코드-여정) * [1.1. SQLite의 탄생: 군함에서 시작된 문제 해결](#11-sqlite의-탄생-군함에서-시작된-문제-해결) * [1.2. SQLite의 성장과 상업적 성공](#12-sqlite의-성장과-상업적-성공) * [1.3. 라이선스, 오픈소스 철학, 그리고 자체 도구 개발](#13-라이선스-오픈소스-철학-그리고-자체-도구-개발) * [1.4. 철저한 테스트와 AI 시대의 소프트웨어 개발](#14-철저한-테스트와-ai-시대의-소프트웨어-개발) * [1.5. SQLite의 지속 가능성과 인간적인 측면](#15-sqlite의-지속-가능성과-인간적인-측면) --- ### 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년 이상 성공적으로 유지될 수 있었던 이유는 단순히 뛰어난 기술력 때문만은 아니다. 핵심 성공 요인은 다음과 같이 정리할 수 있다. 1. **실제 문제를 해결하기 위해 필요한 기술을 직접 개발했다.** 2. **외부 의존성을 줄이고 프로젝트의 통제권을 유지했다.** 3. **외부 기여보다 장기적인 유지보수 책임을 중요하게 생각했다.** 4. **Fossil과 Lemon 등 자신에게 필요한 도구를 직접 만들었다.** 5. **항공 소프트웨어 수준의 철저한 테스트를 적용했다.** 6. **AI와 새로운 개발 기술을 활용하되 결과물을 맹신하지 않았다.** 7. **작은 팀과 인간적인 관계를 바탕으로 프로젝트를 운영했다.** 8. **하나의 주제에 장기간 집요하게 몰입했다.** SQLite의 사례가 보여주는 핵심은 **자유는 아무런 제약이 없는 상태가 아니라, 자신이 사용하는 도구와 코드에 대해 스스로 책임지고 통제할 수 있는 상태**라는 점이다. 외부 의존성을 줄이고, 필요한 도구를 직접 만들며, 철저하게 검증하는 SQLite의 개발 방식은 빠르게 변화하는 AI 시대에도 지속 가능한 소프트웨어 개발이 무엇인지 보여주는 중요한 사례이다. ## Comments ### Comment 59923 - Author: regentag - Created: 2026-06-19T11:06:56+09:00 - Points: 2 RTCA의 Do-178은 진짜로 읽어보고 적용해보는게 가능할만큼 짧은 지침서입니다. 항공업계에 널리 적용돠구요. https://studylib.net/doc/27132454/rtca-do-178b ### Comment 59922 - Author: hmmhmmhm - Created: 2026-06-19T10:36:08+09:00 - Points: 1 "25년 이상의 지속적인 개발" 와 진짜 멋지네요... ### Comment 59921 - Author: cnaa97 - Created: 2026-06-19T10:23:07+09:00 - Points: 1 멋지네요.. 영화같기도하고 ### Comment 59916 - Author: toida - Created: 2026-06-19T09:47:08+09:00 - Points: 1 마인드가 너무 멋있네요