https://corecursive.com/066-sqlite-with-richard-hipp/ - SQLite 개발자 Richard Hipp의 인터뷰 팟캐스트 요약(38분, 스크립트 있음) - 본업은 미국 해군의 구축함에 들어가는 소프트웨어 개발자 ㅤ→ 함선 내부에서 사용하는 Informix가 에러가 잦고, 서버가 죽고 연결이 끊어지곤 했음 ㅤ→ 전함이기 때문에 전투중에 피해를 입어도 “DB에 연결할 수 없습니다” 팝업 안보이고 튼튼하게 잘 동작해야 함. ㅤㅤ트랜잭션도 필요 없고, 어떤 상황에서도 데이터를 램에 읽어들여야 했음 ㅤ→ 서버 없이 실행되는 SQL DB 엔진을 찾아봤는데 없어서, 직접 만들기로 함
SQLite V1 (2000년) - SQL문을 프로그램으로 생각해서 쿼리를 컴파일하고 실행하는 바이트 코드 엔진을 작성 - 실제로 프로젝트에서 사용되지는 않음 (고객이 Informix를 쓰기 원함) - 개발 용도로 쓰면서, 인터넷에 공개했고 그걸 사람들이 쓰기 시작 - "Palm Pilot에서 SQL DB를 실행했어요" 같은 말들을 보게 되고 사람들의 주목을 끌었음. 그래서 더 작업을 진행하도록 격려받음.
Motorola - 2001~2002년 사이, 모토로라가 자신들의 새로운 전화 OS에 SQLite를 넣겠다고 전화가 옴 - 필요한 기능을 지원해주면 비용을 내겠다는 것 - 오픈소스로 돈을 벌 수 있다는 사실을 그때 처음 알게 됨 - 약 $80,000로 요즘에 비하면 많지 않은 돈이었지만, 본인한테는 굉장히 놀라운 금액이었음. - 같이 일하던 세명과 함께 프로젝트를 진행했고 그게 시작이었음
America Online Phones - 그 다음으로 연락이 온 것은 AOL 이었음 - CD를 우편으로 보내던 시절이었는데, 그 CD 안에는 Database 가 필요했음 - 즉 CD 안에 SQLite를 넣기를 원했고 새로운 기능을 필요로 했음
Symbian OS 와 Nokia - 추수감사절에 런던으로 가서 미팅을 진행(영국은 추수감사절이 없으니까) - Symbian OS를 위한 DB를 원했고, 다른 DB들과 경쟁을 벌임(2개의 오픈소스,7개의 상용) - 다른 9개 DB에 튜닝할 기회를 주었지만, SQLite가 최종 승리
Bus Factor [1] 와 콘소시엄 - 버스팩터는 몇명이 버스에 치이면 개발이 중단되는 지를 의미하는 지표 - 본인은 풀타임으로 여럿과 함께 일을 하고 있었지만, Symbian 쪽에서 버스 팩터를 높여야 한다고 얘기가 나왔음 - SQLite 컨소시엄을 시작해서 프로젝트에 자금을 지원하고 더 많은 사람들이 장기적으로 참여하도록 하자는 것 - 모든 컨소시엄 멤버들이 투표권을 가지게 하는 것 같은 미친 아이디어를 내었음 - 모질라 재단의 Mitchell Backer가 이걸 어디선가 듣고 전화를 걸어옴 ㅤ→ "리차드, 당신은 완전히 잘못하고 있어요. 컨소시엄을 만드는 법을 알려줄께요" ㅤ→ 그녀가 규칙을 만들기 시작 ㅤ→ "개발자들이 통제권을 가져야 해요. 그들의 결정이 최종입니다. 들어간다는 것 만으로 투표권을 가지면 안돼요." ㅤ→ "이걸 이용하는 회사들은 돈을 기부하는 명예를 얻지만, 최종 결정은 당신이 해야합니다." ㅤ→ 그녀는 매우 단호했고, 모든 걸 정리했음. 그녀는 변호사임 - 리차드는 "어떻게 사람들이 참여하게 하죠? 인센티브는 뭐구요?" 라고 얘기하자, ㅤ→ "걱정하지 마세요. 그들은 참여할 겁니다. 그리고, 실제로 이렇게 하면 Mozilla가 창립 멤버가 될 겁니다." - Mozilla, Symbian 및 Adobe의 지원을 받고, 세 회사와 컨소시엄을 시작 ㅤ→ 처음에 심비안이 콘소시엄이 필요하다고 얘기했을 때 어찌 해야 할지 몰랐음. 어떻게 미첼베이커가 이걸 듣고 전화했는지는 모르지만, 이 모든게 놀라운 여정.
Enter Android : 안드로이드의 시작 - 모든 스마트폰이 SQLite를 사용하고 있기 때문에, 리차드는 초기 스마트폰 개발을 모든 측면에서 볼 수 있었음 - 2005년에 안드로이드와 회의를 진행. 그때는 안드로이드도, 아이폰도 나오기 전 - 상단에 작은 디스플레이와 풀 QWERTY 키보드를 가진 블랙베리와 비슷한 폰에 연결해서 SQLite를 디버깅 했음 - 실제 동작하는 전화망에 붙은 폰에서 GDB로 디버깅하는 것은 놀라운 경험이었음 - 그때는 모토로라, 심비안, 노키아의 누구도 그런 걸 하지 않았을 때였고, 이때 안드로이드가 거대해질 것이라는 걸 알았음
Guy, This Is Important : 여러분, 이게 정말 중요해요 - 그 시절 다른 업체들은 하드웨어와 소프트웨어 업데이트 주기가 30일 정도로 굉장히 길었는데, Android는 실제 망에 붙은 전화기에 하루에 몇 번씩 새로운 OS를 넣었음. - NDA 하에 받은 프로토타입 안드로이드 폰은 3D 프린트 된 것 같은 케이스였지만, 휴대는 가능할 정도 였음. ㅤ→ 다른 회사의 것들은 큰 브레드보드 & 프로토타입에, 망에도 붙어 있지 않아서 폰으로 쓸 수도 없었음 - 모토로라, 심비안 사람들에게 "이거 중요하니까 이걸 해결해야 한다고 말하고 싶었지만 말할 수 없었음" (NDA 때문에) 그리고 그게 차이를 만듦
Testing and Aviation Standards : 테스팅과 항법 표준 - Adam(인터뷰어) : "지금 리차드의 DB는 정말 활기찬 상태임. 재능 있고 팀도 능력 있지만, 모든 안드로이드폰에 들어가는 DB를 지원하는 1~4명의 소프트웨어 컨설팅 회사임. 개발자들은 DB에 굉장히 열심이고, 데이터에 문제가 생기는 걸 싫어합니다" - 우리는 모든 사람에게 Naive하게 SQLite 는 버그가 없다고 자랑하고 있었지만, 안드로이드는 확실히 우리가 틀렸다는 것을 증명했음. - 버그없이 소프트웨어를 만들수 있을거라 생각했지만, 소프트웨어가 수백만개의 장비에 설치될 때 얼마나 버그가 많이 날 수 있는지 놀라울 정도임. - 그때쯤에 항공전자공학(Avionics) 회사인 Rockwell Collins와 일을 하고 있었는데, 그들이 DO-178B [2] 개념을 소개해줬음. ㅤ→ DO-178B는 안전이 중요한 항공 제품들의 품질 표준에 관한 것인데, 다른 품질 표준과 달리 "읽을 수 있음(readable)" ㅤ→ 몇백달러 쯤 하는데 얇으니까 꼭 읽어보기를 권함 - 실제로 DO-178B의 프로세스를 따르기 시작했고, 그중 하나가 100% MCDC Test Coverage - MCDC(Modified Condition / Decision Coverage) [3] 는 테스트가 개별 분기를 적어도 한번 이상 통과해야 하는 것 - SQLite 가 MCDC 100% 가 되는데 주당 60시간 기준으로 1년이 걸렸음. 정말 정말 어려웠음. 매일 12시간을 해야 했고 정말 피곤. - 90~95% 의 테스트 커버리지는 쉬운데 나머지 5%가 정말 어려움. 하지만 1년간 그렇게 해서 최종적으로 100%에 도달하자 Android 에서 버그리포트가 오지 않게 되었음 - 그때부터 작동하기 시작했고, 큰 차이를 내었음. 그 이후 8~-9년동안 버그가 없었음.
수십억개의 테스트 - 첫번째는 TCL(Tool Command Language)로 작성되었고, 일반적인 개발자 테스트 였음 - 아직도 첫번째 TCL테스트는 유지 보수하고 있고 공개되어 있음. 100%는 아니지만 SQLite 의 모든 기능을 상세 테스트 함. - MCDC 100% 커버리지는 TH3 라고 부르고 공개하지 않음 (proprietary) - 이걸 항공회사에 팔아서 돈을 벌어보려고 했지만 한개도 못팔았으니 효과는 없었음.. - 하지만 우리 제품을 정말 견고하게 유지하고 새로운 기능 과 버그 수정을 빠르게 해볼 수 있게 해줌 - 테스트 갯수를 세기는 어렵지만 10만개의 개별테스트가 매개 변수화 되어서 수십억개의 테스트가 실행 됨 - 체크리스트가 있고, 릴리즈전 최소 3일 동안 테스트를 진행함 - 의도적으로 여러 개의 OS에서 테스트를 진행함 ㅤ→ 요즘은 모든 장비들이 리틀 엔디안이지만 예전엔 빅엔디안들도 많았음. 그래서 PowerPC iBook 에서 빅엔디안 테스트를 진행 ㅤ→ 32비트 플랫폼과 ARM 과 Intel, 64 Bit 플랫폼, 윈도우, 리눅스, 맥, OpenBSD 등 우리가 할수 있는 모든 플랫폼과 OS에서 테스트를 진행 ㅤ→ 여러개의 다른 테스트 스윗이 있고, 원래 TCL도 있고, TH3도 있음. 지속적으로 실행되는 Fuzzer(퍼지 테스팅)도 있음. - SQL Logic 테스트도 있음 ㅤ→ 10년전에 Shane Harrelson 이 만든 엄청난 더미의 SQL 문장 ㅤ→ 손댈 수 있는 모든 DB에서 테스트 했는데 모든 DB엔진이 답을 못내고, 세그멘테이션 폴트를 내었음. SQLite 포함. 단, Postgres 만 빼고. ㅤ→ Postgres 만 항상 결과를 내었고 결점을 찾을수 없었음. Postgres 개발자들은 우리가 충분히 노력하지 않은거라고 했지만.. Postgres에 에러를 내는 것은 가능은 했겠지만, 우린 매우 감동했음 ㅤ→ 상용 버전 Oracle도 크래시 내었고, DB2도 크래시 냄 ㅤ→ 중요한 포인트는 SQLite가 이 모든 쿼리들에 대해서 동일한 답을 내도록 했다는 것
Building From First Principles - 처음에 작성을 시작했을 때, 어떻게 SQL DB 엔진을 만드는지 레퍼런스가 있는지 찾아보려고 했는데 없었음. 그래서 직접 만들어야 했고, 완전히 독립적인 임무였음. - 많은 이론들이 MIT, 하바드, 버클리에서 일어나고 있었지만 그 학교들에 가지 않으면 이론이 존재한다는 사실조차 몰랐고, 찾는 방법도 없었음. - Postgres 가 사용하는 Volcano 모델과 SQLite 가 사용하는 Byte Code 모델은 살펴보면 우린 모두 같은 아이디어로 수렴됨 - 위에서 보면 매우 다른 곳에서 시작하지만, 우린 어떻게 그걸 더 빠르게 하는가에서 같은 영역에 수렴함 - 이게 이론적으로 일종의 검증이라고 생각함. 두개의 독립적인 개발라인이 동일한 답을 내놓는 것 - 예를 들어서, 나는 Covering Index에 대해서는 전혀 몰랐는데, 독일에서 열린 PHP 컨퍼런스에 참석했을 때, MySQL의 David Axmark도 참여해서 강연을 했음 ㅤ→ 그 강연에서 MysQL 이 어떻게 Covering Index를 만들었는지 설명함 ㅤ→ DB의 인덱스에 어러개 컬럼이 있을때, 인덱스의 앞쪽 컬럼에 대해서만 쿼리하고 답이 나머지 컬럼에 있다면 DB는 원본 테이블 조회없이 인덱스만으로도 사용 가능해서 작업이 빨라짐 ㅤ→ 그래서 집으로 돌아오는 비행기에서 사람이 별로 없길래, 랩탑을 열고 대서양 상공에서 SQLite 의 커버링 인덱스를 구현했음
B-Trees and The Art of Computer Programming - 많은걸 직접 만들어야 했음. 아무도 나에게 B Tree를 가르쳐 준적이 없음. 그냥 들어봤을뿐. - 직접 B트리를 개발하려고 할때, 책장에서 Don Knuth의 TAOCP 가 있어서 B트리를 찾았고 그가 알고리듬을 설명해줬음 - 재미난건, 책에는 B트리 검색과 삽입 알고리듬은 자세히 설명하지만, 삭제하는 알고리듬은 제공하지 않음. 그건 챕터 끝 연습문제에 있어서, 나만의 B 트리를 만들기 전에 문제를 풀어야 했음. "고마워요 Don, 정말 감사해요." - 현 시대의 사람들은 적어도 TAOCP 를 읽거나 훑어보기라도 해야함
Freedom to Build It Yourself : 직접 만들 수 있는 자유 - SQLite 는 Richard 가 직접 만든 것 외에는 아무것에도 의존성이 없음 (C 컴파일러와 libc 제외하고). 직접 버전관리 시스템도 만들고 버그 트래커도 만듬. 이게 리차드에게 자유를 줌 - 자유(Freedom)라는 것은 자신을 스스로 돌보는 것을 의미 - 배낭여행 가는 사람들이 필요한 모든 것을 등에 지고 가면서 자유롭다고 하는 것은 그들이 직접 자신을 케어하기 때문 - 모든 것을 직접 만든다면 누군가에게 묶여있지 않기 때문에 그 안에 자유가 있음 - 만약 SQLite 2의 스토리지 엔진으로 Berkeley DB를 선택했다고 가정해보면 ㅤ→ 그 당시엔 Berkeley DB는 오픈소스 였지만 나중에 Oracle 에 매각되어서 듀얼 소스 독점 모델이 되어서 라이선스 비용을 내지 않고는 최신 버전의 소스코드를 얻지 못하게 되었음 - 지금 SQLite 의 Parser Generator는 Yak 나 Bison 을 사용하지 않고 Lemon 이라 불리는 직접 작성한 것인데, 그래서 새로운 언어 기능이 필요할 때 그것들에 묶이지 않고 수정할 수 있었음 - 2000년대 초에는 모든 프로젝트 CVS를 사용하기에 그걸 썼지만, 2000년대 중반이 되면서 분산 버전 관리 아이디어가 나오기 시작
Fossil 구축 - Git 과 Mercurial 을 보고 요구사항을 정리한뒤 직접 버전관리 시스템을 개발하기로 함 - 이제 Fossil 은 잘 동작해서, 자체 프로젝트가 되었음 - 토발즈가 Linux Kernel 개발을 지원하기 위해 Git을 만들었기에, Linux Kernel 관련 일을 한다면 Git 이 완벽한 버전관리 시스템 - Fossil 은 SQLite 작업을 하기위해 딱 맞는 버전 관리 시스템임. 내가 직접 만들었기에 내 요구사항을 정확히 충족 - 직접 개발함으로써, 자신의 운명을 통제하고, 더 많은 자유를 가지고, 제3자에게 의존하지 않게 됨
자급자족하기 - 도시를 벗어나서 직접 식량을 키우고 사는 사람을 뭐라고 할까요? Survivalist (생존주의자) ? 또는 Prepper (준비자) "당신과 연락하는 동안에도 봤듯이 제 Gmail 이 조금 이상해요. 메일이 자꾸 리턴됩니다. 그래서 내 메일 서버를 만들려고 해요. 우리가 이 미팅을 셋업하는 중에도 관련 노트를 작성하고 있었어요. DB 엔진을 작성하는 것보다 어렵지는 않겠지만 Gmail 에 얽매이고 싶지는 않아요. 그들이 내 운명을 통제하는 것을 원하지 않아요. 그들이 내 모든 대화의 기록을 제어하는 것을 원하지 않아요. 내가 직접 통제하고 싶고, 그래서 고통스럽고 할일이 많겠지만 직접 통제할 해결책을 찾기위해 노력하려고 합니다. 클라우드에서 가상머신을 임대해서 실행해서 제3자에 의존하지 않아도 됩니다." - 누군가 찾아와서 당신의 문제를 해결해 주겠어요 한다면, 그들이 당신의 자유를 빼앗아 갈거라는 것을 알아야 합니다. "자유롭고 싶다면 직접 해야 해요"
다른 사람을 위한 조언 - 저는 서버가 필요없이 직접 디스크에서 읽고 쓰는 DB 엔진을 만들겟다는 미친 아이디어로 시작했습니다. - 전문가들에게 물어보면 "그건 불가능해요. 절대 동작하지 않을꺼에요. 멍청한 아이디어 입니다."라고 할겁니다. - 다행스럽게도 난 그런 전문가들을 몰라서 그냥 했고, 이런 일들이 일어났습니다. - 전문가들의 말을 많이 듣지 말고, 말이 되는 일을 하세요. 당신의 문제를 해결하세요
--
[1] Bus Factor : 팀원이 버스에 치어서 팀이 위기에 빠질 수 있는 위험도. - 팀 멤버 간에 정보 및 기능들이 공유되지 않아서 생길수 있는 위험을 말하는 지표. - 이 지수를 높여야 정보가 공유되고, 특정인에게 업무가 집중되지 않음.
[2] DO-178B : 항공기 시스템과 장비 인증에 관한 소프트웨어 고려사항 (Software Considerations in Airborne Systems and Equipment Certification ) - 미연방항공국(FAA)에 의해 항공용 소프트웨어 인증을 위한 적합성 입증 방법으로 채택
[3] MCDC : Modified Condition / Decision Coverage - 여러 개의 조건식이 있을 때, 각 개별 조건식이 다른 조건식에 영향을 받지 않고 전체 조건식의 결과에 독립적으로 영향을 주도록 테스트 케이스를 설계하는 방법 음성 기능은 200자로 제한됨 | 
