SQLite가 C 언어로 작성된 이유

• SQLite는 성능, 호환성, 적은 의존성, 안정성 때문에 초기부터 C 언어로 개발되었음
• C는 거의 모든 OS와 언어에서 사용할 수 있으며, 특히 저수준 라이브러리로 빠른 동작을 지원함
• 객체지향 언어 대신 C를 택한 이유는 확장성, 다양한 언어에서의 호출, 그리고 개발 당시 C++과 Java의 미성숙 때문임
• Rust와 Go와 같은 "안전한 언어" 에서 재작성 논의가 있으나, 퀄리티 관리, 성능, 라이브러리 호출성 등에서 여전히 C가 우위임
• 미래에 Rust로 옮길 가능성을 열어두었으나, Rust가 더 성숙하고 여러 조건을 만족해야 함

1. C 언어가 최선인 이유

SQLite는 2000년 5월 29일 처음 출시된 이래로 일반적인 C 언어로 구현되어 왔음
소프트웨어 라이브러리로서 SQLite에 C가 최적이라는 점은 변하지 않고 있으며, 다른 언어로 바꿀 계획은 없음
성능, 호환성, 낮은 의존성, 안정성이 이 선택의 핵심 이유임

1.1. 성능

• SQLite 같은 저수준 라이브러리는 매우 빠르게 동작해야 하는 요구가 있음
• C 언어는 빠른 코드를 작성하는 데 적합하며, 이식성이 높으면서도 하드웨어에 밀접하게 접근 가능함
• 다른 현대 언어들도 ‘C만큼 빠르다’고 주장하지만, 범용 프로그래밍에서는 C보다 빠르다고 확신하는 언어는 없음

1.2. 호환성

• 거의 모든 시스템이 C로 작성된 라이브러리를 호출할 수 있는 환경임
• 예를 들어, Android(Java 기반)에서도 adaptor를 통해 SQLite를 사용할 수 있음
• 만약 Java로 작성했다면 iPhone(Objective-C, Swift)에선 사용 불가하여 범용성이 크게 떨어짐

1.3. 낮은 의존성

• C 라이브러리로 개발했기 때문에 런타임 의존성이 매우 적음
• 최소 구성에서는 표준 C 라이브러리의 아주 기본 함수(memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp())만 필요함
• 보다 완전한 빌드에서도 malloc(), free(), 파일 입출력 등 소수의 의존성만 가짐
• 현대 언어들은 다수의 대형 런타임과 수천 개의 인터페이스가 요구되는 경우가 많음

1.4. 안정성

• C는 오래되고 변화가 적은 언어임
• SQLite처럼 작은, 빠른, 신뢰할 수 있는 데이터베이스 엔진을 만들 때는 규격이 자주 바뀌지 않는 언어가 적합함
• 언어의 사양이나 구현이 빈번히 바뀌면 SQLite 안정성에 불리함

2. 왜 객체지향 언어로 작성되지 않았는가

• 일부 개발자들은 객체지향이 아니라면 복잡한 시스템 SQLite를 구현하기 어렵다고 생각하지만, C에 비해 C++나 Java로 라이브러리를 만들면 다른 언어에서 부르기 어려움
• Haskell, Java 등 다양한 언어 지원을 위해 C 라이브러리 선택이 타당함
• 객체지향은 설계 패턴일 뿐 특정 언어에 한정되지 않음
• C에서도 객체지향적 설계를 구현 가능함
• 객체지향이 항상 최적의 구조는 아니며, 절차적 코드가 더 명확하고 관리가 쉬우며, 더 빠른 결과를 얻을 때도 있음
• SQLite 개발 초기, Java는 미성숙했고, C++는 컴파일러 호환성 문제 등 불안정함이 심각했음
• 현재도 SQLite를 재작성할 만한 이점은 부족함

3. 왜 "안전한 언어"로 작성되지 않았는가

• 최근 Rust, Go와 같은 안전한 프로그래밍 언어에 대한 관심이 높지만, SQLite가 처음 개발될 당시(처음 10년간)는 존재하지 않았음
• Go나 Rust로 다시 작성할 경우 버그가 더 많이 발생하거나, 성능이 저하될 가능성 있음
• 이러한 언어들은 메모리 체크 등 추가 분기(branch) 코드를 삽입하는데, SQLite의 품질 전략상 100% 브랜치 커버리지가 중요한데 이 부분이 충족되지 않음
• 안전한 언어들은 out-of-memory 상황에서 주로 프로그램을 중단시키나, SQLite는 복구 가능한 구조를 염두에 두고 설계됨
• Rust, Go 등은 여전히 신생 언어이며 지속적인 개발이 필요함
• 그러므로 SQLite 개발진은 안전한 언어 발전을 응원하지만, SQLite 구현에선 여전히 검증된 C의 안정성을 중시함

미래의 가능성

• Rust로 재작성 가능성은 존재

• 조건:

  • Rust가 더 성숙하고, 변화 주기가 느려져야 함
  • 여러 언어에서 호출 가능한 범용 라이브러리를 만들 수 있음이 입증되어야 함
  • 임베디드 등 OS 없는 장치에서도 동작하는 오브젝트 코드를 생산 가능해야 함
  • 컴파일된 바이너리에 대해 100% 브랜치 커버리지 테스트 도구가 마련되어야 함
  • OOM(메모리 부족) 오류에서 복구 가능해야 함
  • SQLite에서 C가 처리하는 모든 작업을 성능 저하 없이 Rust가 수행할 수 있어야 함

• 만약 Rust 애호가(rustacean)가 위의 조건들이 이미 갖춰졌다고 본다면, SQLite 개발자에게 직접 의견 제시를 환영함

본 페이지는 2025-05-09에 마지막으로 수정됨