SQLite 창시자 Richard Hipp 인터뷰: 26년, 자작 도구, 그리고 AI — Debug with Lewis 영상 정리

영상 정보

제목: Creator of SQLite on Turso, AI, and 26 Years of Code

채널: Debug with Lewis · 인터뷰 (진행: Lewis, 대상: Richard Hipp — SQLite 창시자)

업로드: 2026-05-05 · 길이 1시간 6분 22초 · 조회수 약 7,826회(정리 시점)

맥락: 같은 채널의 SQLite 다큐멘터리에 담기지 않은 대화 전체(라이선스·Turso 매니페스토·자작 도구 철학·AI에 대한 생각)

영상 링크: https://www.youtube.com/watch?v=x8_ZZhRL3YU

Articles 카테고리는 읽을 만한 외부 콘텐츠를 골라 핵심을 정리하고 내 관점으로 분석하는 공간이다. 이번엔 글이 아니라 66분짜리 인터뷰 영상을 영상용 article 형식으로 정리했다.

정리 방식 메모: 이 영상에는 사람이 만든 영어 자막(manual subtitle, en-CA) 이 있어 텍스트 정확도가 높다. 발화를 충실히 옮기되, 인터뷰 특성상 발언자가 분명한 경우에만 이름을 붙였다(대부분은 Richard Hipp의 답변). 챕터 구분은 영상 설명란의 16개 타임라인을 따랐다.

한 줄 요약 (TL;DR)

세상에서 가장 널리 배포된 소프트웨어 라이브러리 SQLite의 창시자가, 26년을 한 프로젝트에 바친 사람의 철학을 풀어낸다 — 의존성을 줄이는 것이 곧 자유이고, 풀 리퀘스트는 “공짜 강아지”이며, 코드는 “아직 태어나지 않은 사람도 이해할 수 있게” 쓰고, 무엇보다 “테스트하고, 테스트하고, 또 테스트하라.” AI는 유용하지만 “믿을 수는 없는” 도구로 본다.

왜 이 영상을 골랐나

SQLite는 우리가 매일(스마트폰·브라우저·항공기·자동차 안에서) 쓰면서도 거의 의식하지 못하는 인프라다. 그 창시자의 입에서 나오는 이야기는 데이터베이스 설계, 도구 자작의 철학, 테스트 강박, 오픈소스 기여 모델, 그리고 AI 시대의 장인정신을 한 번에 관통한다. 이 위키의 PostgreSQL Essential(데이터베이스), Testing-Refactoring Essential(테스트), 그리고 여러 AI Articles 사이를 잇기에 더없이 좋은 글감이라 골랐다.

핵심 내용

영상의 16개 챕터를 흐름에 따라 묶어 정리한다.

탄생 — 군함 USS Oscar Austin과 “왜 별도 프로세스가 필요한가”

SQLite의 씨앗은 군함 프로젝트였다. Hipp는 General Dynamics의 계약직으로, Bath Iron Works가 건조하던 구축함 DDG-79(USS Oscar Austin) 의 손상 통제 시스템(피격 시 밸브·차단기를 여닫아 피해를 격리하는 정보 시스템)을 맡았다. 앞서 다른 회사가 수백만 달러를 쓰고도 결과를 못 냈고, Hipp는 그 문제가 NP-complete 임을 증명한다(물론 의뢰인이 원한 건 “학술적 변명”이 아니라 해법이라, 빠른 휴리스틱으로 좋은 근사해를 냈다).

문제는 데이터였다. 모든 데이터가 Informix 데이터베이스에 저장됐는데, Informix 엔진이 내려가 있으면 그의 앱이 “database unavailable” 대화상자를 띄웠고, 사용자는 그의 소프트웨어가 고장 났다고 항의했다. 그는 생각한다 — “왜 데이터를 저장하는 데 별도 프로세스가 필요하지? 내가 디스크에서 직접 읽으면 안 되나?” 그런 SQL 엔진은 없었고, 구글 검색도 없던 시절이라 그는 동네 대학 도서관에서 관계형 DB 이론을 직접 공부했다(보스턴·샌프란시스코에 있었다면 오히려 정보를 못 찾았을 거라고 회고한다). 그렇게 만든 것이 입소문을 타고 퍼졌다 — “이걸로 돈을 벌 수 있으리라곤 상상도 못 했다.”

첫 상업 계약 — Motorola, AOL, 그리고 Symbian bake-off

수년 뒤 Motorola(플립폰 시대의 세계 1위 휴대폰 제조사)가 전화를 걸어 “모든 폰에 SQLite를 넣고 싶다”며 기능 개선 계약을 맺는다(약 $80,000 규모, 그 돈으로 세 명을 더 고용). 이어 AOL(CD-ROM을 우편으로 보내던 그 회사)도 비슷한 계약을. Hipp는 “사업 감각이 없어 둘 다 한참 싸게 불렀다”고 웃는다.

결정적 사건은 Symbian(노키아폰 OS) bake-off 다. 10개 데이터베이스 엔진을 두고 경쟁시켰는데(7개는 폐쇄형, SQLite 포함 3개가 오픈소스), SQLite가 우승했다 — 본인은 그런 일이 벌어지는지도 몰랐다. Symbian은 그를 런던으로 불러 후원을 약속하며 컨소시엄을 만들라고 했다. 이유는 bus factor(“당신이 버스에 치이면 어떻게 되나”)가 너무 낮다는 것. 이 과정에서 Mozilla의 Mitchell Baker가 전화를 걸어 “당신 지금 잘못하고 있어요”라며 사실상 컨소시엄 협정서를 대신 써 줬다. 그렇게 SQLite는 풀타임 직업이 됐다.

(2010년 Airbus 가 A350 항공전자에 SQLite를 쓰려고 “기체 수명만큼 지원해 달라”고 했고 — “40년”이라기에 “그러죠”라고 답했다. 여기서 2050년 지원 약속이 나왔다: 최초 코드 작성일 + 50년. 참고로 날짜·시간 로직은 서기 9999년까지 동작한다.)

라이선스 대신 기도문 — public domain과 “blessing”

SQLite v1은 저장소로 GDBM(GPL)을 썼기에 강제로 GPL이었다. 하지만 범위 질의(range query)를 하려면 해시가 아니라 B-tree가 필요했고, Berkeley DB 를 보니 문서가 너무 부실해 “이해하려면 테스트 프로그램을 짜야 할 판”이었다. 그래서 “남의 코드를 이해하려고 테스트를 짤 바엔 내 걸 짜자” — 직접 백엔드를 만들며 GDBM 의존을 떼어내자(SQLite v2) 비로소 라이선스를 자유롭게 고를 수 있었다.

당시 선택지는 GPL·Berkeley·MIT뿐(“오늘날처럼 50억 개 라이선스가 있던 시절이 아니다”). 법률 문구가 거추장스러웠던 그는 “그냥 public domain이라고 하면 안 되나? 모든 줄을 내가 직접 썼는데.” 그래서 public domain으로 풀었다(public domain이 영미법 개념이라 다른 나라에선 통하지 않는다는 걸 그땐 몰랐다고). 헤더 주석에 넣을 게 필요해 “치즈 같은(cheesy) 축복문” 을 써 넣었는데 — 그게 그 유명한 blessing(기도문) 이다. SQLite가 세계 최다 사용 라이브러리가 되면서 이 blessing은 정식 오픈소스 라이선스로 인정받는다. 라이선스 전쟁에 대한 그의 한마디 — “세상엔 진짜 심각한 문제가 이렇게 많은데, 왜?”

풀 리퀘스트는 “공짜 강아지”

SQLite는 외부 기여를 받지 않는다(불가능은 아니지만 진입 장벽이 매우 높다). 그 이유를 Hipp는 명쾌하게 설명한다. 풀 리퀘스트는 공짜가 아니다 — “당신은 내게 이 기능을 앞으로 25년간 문서화하고, 테스트하고, 유지보수해 달라고 부탁하는 것이다.” Linus Torvalds의 “free as in beer / free as in speech”를 비틀어, 그는 또 다른 자유를 든다 — “free as in puppies(공짜 강아지처럼).”

“공짜 강아지 받으실래요? 그렇게 하나둘 받다 보면 강아지로 가득 찬 켄넬이 된다. 그런데 내다 버릴 수도 없다 — 평생 돌볼 도덕적 의무가 생기니까. 나는 공짜 강아지를 원하지 않는다.”

“이게 더 나은 방식이면 증명해 보라(prove me wrong). 나는 수없이 틀려 왔다.” 하지만 지금까지 SQLite의 방식이 잘 작동해 왔다는 것이 그의 입장이다.

26년을 버틴 이유 — 작은 팀, 그리고 “섭리”

“두 달 뒤면 26년”이 되는 SQLite가 왜 아직 건재한가. Hipp의 첫 대답은 의외로 “신의 섭리(divine providence) 말고는 설명할 길이 없다” 이다. 부차적 요인으로 그는 “나는 괜찮은 프로그래머지만 세계 최고는 아니다(내 밑에 더 나은 사람도 있다). 다만 매우 고집스럽고, 통념을 의심한다”를 든다.

가장 실용적인 요인은 작은 팀이다 — 작게 유지했기에 “아니오”를 말할 수 있었다. 그는 자신의 한계도 인정한다: “나를 컴퓨터 있는 방에 넣고 문틈으로 피자나 밀어 넣어 달라. 문제를 풀게 두고 날 내버려 두라.” 사람을, 특히 프로그래머를 다루는 일은 그에게 맞지 않았다(그래서 그 일을 오래 해낸 Linus를 진심으로 칭송한다). SQLite의 첫 “긱 크레드(geek cred)” 순간은 누군가 PalmPilot에서 SQLite를 돌렸다는 글을 봤을 때였다 — 그 “ego boo(ego boost)”가 그를 계속 만들게 했다.

자기 도구를 만든다 — Fossil과 Lemon, “자유란 스스로를 돌보는 것”

Hipp는 Git을 쓰지 않는다. 그는 자기 버전 관리 시스템 Fossil 을 직접 만들었다(Git과 거의 같은 시기에). 파서 생성기도 YACC·Bison이 아니라 대학원 시절 만든 Lemon 을 쓴다(SQLite 말고는 아무도 안 쓰지만 상관없다 — 남의 도구의 한계에 묶이지 않으니까). 그의 원칙은 “가장 좋은 도구는 당신이 직접 만든 것” 이다. Fossil은 SQLite 위에 지어져 베타 테스트 플랫폼이 되고, 그를 애플리케이션 개발자의 시점에 세워 제품을 개선하게 한다. 그는 Git을 폄하하지 않는다 — “Git은 Linux 커널의 방법론에 완벽하다. 하지만 모든 프로젝트가 Linux 커널은 아니다.” 작은 “담장 안 정원” 프로젝트엔 Fossil이 더 낫다는 것.

이 모든 것의 뿌리는 자유다. “자유란 스스로를 돌보는 것이다” — 배낭 하나 메고 숲을 걷는 사람이 말하는 그 자유. 물론 “누구도 완전히 자유롭지 않다. 우리는 서로에게 의존한다”(그는 운영체제를 Linus에게, 식량을 동네 식료품점에 의존한다고 농담한다). 다만 의존성을 줄일수록 더 자유로워진다. 코드 철학도 같은 결이다 — 약 1/3이 주석(보일러플레이트가 아니라 “왜 이렇게 동작하는가”를 설명하는 주석), 그리고 “아직 태어나지 않은 사람도 이해할 수 있는, 나보다 오래 살 코드를 쓰고 싶다.”

SQLite를 살린 항공우주 테스트 표준 — DO-178B, 퍼징, 그리고 AI가 찾는 버그

그의 한 문장 — “테스트하고, 테스트하고, 또 테스트하라. 테스트는 아무리 많아도 지나치지 않다.” SQLite를 오래 유지할 수 있었던 비결은 극도로 철저한 테스트 다. 계기는 항공 표준 DO-178B(“비행기 10야드 안에 들어가는 건 뭐든 극한까지 테스트해야 한다”). 그는 DO-178B 테스트 산출물을 팔아 돈을 벌려다 실패했지만, 정작 그 수준으로 테스트하자 “버그가 그냥 대부분 사라졌다.” 이 작업은 Android 개발기와 겹쳤는데(구글이 매일 버그 리포트를 보내던 시절), 100% MC/DC 테스트 커버리지에 도달하자 Android발 버그 보고가 뚝 끊겼다.

그 뒤로도 버그의 “새로운 물결”이 두 번 더 왔다 — 하나는 American Fuzzy Lop(AFL) 의 profile-guided fuzzing(DO-178B로는 못 잡는 종류의 버그를 찾아냈다), 그리고 지금은 AI가 찾는 버그다.

Turso·libSQL 포크와 매니페스토에 대한 반응

2022년 Turso가 SQLite를 포크해 libSQL 을 만들고 매니페스토를 냈다(지금은 전체를 Rust로 재작성 중). Hipp의 반응은 담담하다 — “5년쯤마다 누군가 벤처 투자를 받아 제품을 밀어붙인다. 그리고 다들 같은 슬로건을 들고 온다: ‘SQLite보다 10배 빠르다.’” 지금 SQLite가 “언덕의 왕(king of the hill)”, 즉 쓰러뜨릴 대상이라는 것. “어쩌면 내일 모두가 Turso를 쓰기 시작하고 이 여정이 끝날지도 모른다. 모르겠다. 하지만 나는 할 수 있는 한 계속할 것이다.”

매니페스토가 “GitHub 모델로, 특정 라이선스로, 특정 행동강령으로 하라”고 규정하는 데 대해선 — “그렇게 하고 싶으면 그렇게 하라. 나는 그렇게 하고 싶지 않다. 내 소프트웨어를 어떻게 쓸지는 내가 정한다. 어느 쪽이 더 낫다고 말하는 게 아니다.”

AI와 코딩 에이전트에 대한 생각

Hipp는 신중하다 — “AI에 대해 오늘 한 말을 내일은 다르게 답할지도 모른다.” 그는 AI 챗을 늘 쓰고 매우 유용하다고 본다(ChatGPT에 SQL 엔진들의 short-circuit 평가를 물었더니, SQLite 대목에서 “당신이 SQLite를 만들었으니 아시겠죠”라고 해서 섬뜩했다는 일화). 다만 핵심 경고 — “무언가를 찾는 데는 훌륭한 자원이지만, 그들이 하는 말을 믿어선 안 된다. 맞을 때도 많지만, 완전히 틀리면서도 매우 설득력 있게 들린다.” 한 평론가의 말을 빌려 — “우리는 수천 년 전부터 AI를 가지고 있었다. 그저 그것을 ‘궤변(sophistry)’이라 불러 왔을 뿐이다.”

코딩 에이전트는 전용 도구를 쓰진 않지만, 챗에 “opcode 없는 머신에서 128비트 부호 없는 정수 곱셈 코드를 짜 달라” 같은 걸 묻는다 — “리눅스에선 잘 돌았는데 윈도우에선 박살 났다. 결국 직접 다시 짰지만, 생각을 집중시켜 주는 데는 유용했다.” 포크를 꿈꾸는 젊은 개발자에겐 — “해 보라. 다만 그 시기는 지났다고 본다. 25년과 광적인 헌신이 필요하다. 주말에 침실에서 할 수 있는 일이 아니다.”

분석과 인사이트

여기서부터는 영상 요약이 아니라 내 관점이다.

“공짜 강아지”는 오픈소스 기여를 보는 가장 정직한 렌즈다. 우리는 풀 리퀘스트를 “기여=선물”로만 보지만, Hipp는 그것이 앞으로 수십 년의 유지보수 부채라는 비용 측면을 드러낸다. 이는 SQLite만의 괴벽이 아니라 모든 메인테이너가 매일 마주하는 현실이다 — 받은 코드는 누군가 문서화·테스트·유지해야 하고, 그 누군가는 보통 메인테이너다. 기여를 “받을지 말지”의 기준이 인기가 아니라 총소유비용이어야 한다는 통찰은 팀 코드베이스에도 그대로 적용된다.
“테스트하고, 테스트하고, 또 테스트하라”는 SQLite의 진짜 해자다. 화려한 알고리즘이 아니라 100% MC/DC 커버리지 + 퍼징 + (이제) AI 버그 헌팅이라는 다층 방어가 26년을 지탱했다. “DO-178B 수준으로 테스트하니 버그가 그냥 사라졌다”는 말은, 품질이 영감이 아니라 규율에서 온다는 Testing-Refactoring Essential의 메시지와 정확히 같다. 세상에서 가장 신뢰받는 라이브러리의 비결이 “테스트 강박”이라는 사실은 곱씹을 만하다.
“의존성을 줄이는 것이 자유”라는 명제는 양날의 검이다. Fossil·Lemon을 직접 만든 결정은 SQLite를 남의 도구의 한계에서 해방시켰고, 베타 테스트 플랫폼이라는 부수 효과까지 낳았다. 하지만 이건 26년을 한 프로젝트에 바칠 수 있는 사람의 사치이기도 하다. Hipp 자신도 “모든 프로젝트가 Linux 커널은 아니다”라고 했듯, 자작 대 채택의 트레이드오프는 프로젝트의 수명·규모·인력에 달려 있다. 대부분의 팀에게 교훈은 “다 직접 만들라”가 아니라 “핵심 의존성이 당신의 자유를 얼마나 제약하는지 의식하라”이다.
AI에 대한 그의 균형 감각이 인상적이다 — “유용하지만 믿을 수 없다.” “AI를 우리는 늘 궤변이라 불러 왔다”는 비유는, 설득력과 정확성이 별개라는 LLM의 본질을 한 칼에 베어낸다. 이는 이 위키의 그것들은 가중치로 만들어졌다가 말한 “그럴듯하게 들리지만 거기 누가 있는 건 아니다”와, AI는 왜 엔지니어를 대체하지 못했나의 “검증은 사람의 몫”과 같은 자리에 선다. “리눅스에선 됐는데 윈도우에선 박살 났다 → 결국 직접 짰다”는 일화가 그 검증 책임을 생생하게 보여 준다.
“포크할 시기는 지났다”는 말은 겸손이자 냉정한 진단이다. 25년의 누적된 테스트·문서·신뢰는 자본이나 더 빠른 벤치마크로 단번에 복제되지 않는다. 이는 소프트웨어는 죽는 게 아니라 재평가된다가 말한 “진짜 해자는 속도가 아니라 누적된 신뢰”라는 명제의 살아 있는 사례다. “10배 빠르다”는 슬로건이 5년마다 반복돼도 SQLite가 흔들리지 않는 이유가 여기 있다.

적용 포인트

외부 기여(또는 새 의존성)를 받을 때 “이걸 25년간 누가 유지하나” 를 먼저 묻는다. 기여는 선물이자 부채다.
신뢰가 핵심인 컴포넌트라면 커버리지·퍼징 등 다층 테스트에 투자한다. 품질은 규율에서 온다 — “테스트는 아무리 많아도 지나치지 않다.”
핵심 의존성이 당신의 선택을 얼마나 제약하는지 점검한다. 전부 자작할 필요는 없지만, 어디에 묶여 있는지는 알아야 한다.
코드에 “왜”를 설명하는 주석을 남긴다 — “아직 태어나지 않은 사람도 이해할 코드”가 목표다.
AI 출력은 “설득력 ≠ 정확성” 으로 다룬다. 찾는 데는 쓰되, 검증 없이 믿지 않는다(특히 플랫폼 이식성처럼 경계 조건이 많은 영역).

마무리

이 인터뷰의 매력은 기술이 아니라 태도에 있다. 억만장자도, 벤처 투자도, 거대한 팀도 없이, 한 사람이 군함 계약에서 시작한 작은 라이브러리를 세상 절반이 매일 쓰는 인프라로 키웠다. 그 비결로 그가 꼽는 건 천재성이 아니라 — 작게 유지하고, 의존성을 줄이고, 집요하게 테스트하고, 아직 태어나지 않은 사람을 위해 코드를 쓰는, 지루할 만큼 꾸준한 장인의 규율이다. 지역에선 사람들이 그를 “Ginger(아내)의 남편”으로만 안다지만, 그가 만든 데이터베이스는 지금 당신의 주머니 속에서 돌아가고 있다.