C가 최고다 (2025)

• SQLite는 2000년부터 C 언어로 구현된 경량 데이터베이스 엔진으로, 다른 언어로 다시 작성할 계획이 없음
• C는 성능, 호환성, 의존성 최소화, 안정성 측면에서 SQLite에 가장 적합한 언어로 평가됨
• 객체지향 언어(C++, Java 등)는 언어 간 호출 제약이 크고, 절차적 접근이 오히려 단순하고 빠를 수 있음
• Rust나 Go 같은 ‘안전한 언어’ 는 아직 성숙하지 않았고, SQLite의 품질 전략(예: 100% 분기 테스트, OOM 복구)에 부합하지 않음
• 향후 Rust로의 이식 가능성은 열려 있으나, 성숙도·호환성·성능·도구 지원 등 여러 조건이 충족되어야 함

1. C가 최선인 이유

• SQLite는 2000년 5월 29일 처음부터 일반 C 언어로 구현되었으며, 현재까지도 다른 언어로의 전환 계획이 없음
• C가 SQLite 구현에 적합한 이유로 성능, 호환성, 저의존성, 안정성을 제시

1.1 성능

• SQLite는 집약적으로 사용되는 저수준 라이브러리로서 빠른 속도가 필수
  • 예시로 “Internal Versus External BLOBs”, “35% Faster Than The Filesystem” 문서에서 성능 입증
• C는 ‘이식 가능한 어셈블리 언어’ 로 불릴 만큼 하드웨어에 가까운 제어를 제공하면서도 플랫폼 간 이식성 유지
• 다른 언어들이 “C만큼 빠르다”고 주장하지만, C보다 빠르다고 주장하는 언어는 없음

1.2 호환성

• 거의 모든 시스템이 C로 작성된 라이브러리 호출 기능을 제공
• 예를 들어 Android는 Java 애플리케이션에서 SQLite를 어댑터를 통해 호출 가능
• 만약 SQLite가 Java로 작성되었다면, Objective-C나 Swift 기반 iPhone 앱에서는 사용 불가했을 것

1.3 저의존성

• C로 작성된 라이브러리는 런타임 의존성이 매우 적음
• 최소 구성에서 SQLite는 표준 C 라이브러리의 다음 함수만 필요
  • memcmp(), memcpy(), memmove(), memset(), strcmp(), strlen(), strncmp()
• 완전 빌드에서도 malloc(), free(), 파일 입출력 정도만 사용
• 반면 현대 언어들은 수 MB 규모의 런타임과 수천 개 인터페이스를 요구

1.4 안정성

• C는 오래되고 변화가 적은 언어로, 명확하고 예측 가능한 동작을 제공
• SQLite처럼 작고 빠르며 신뢰성 있는 데이터베이스 엔진을 개발할 때, 언어 사양이 자주 바뀌지 않는 것이 중요

2. 객체지향 언어로 작성되지 않은 이유

• 일부 개발자는 복잡한 시스템을 객체지향 언어로만 구현할 수 있다고 생각하지만, SQLite는 그렇지 않음

• C++이나 Java로 작성된 라이브러리는 동일 언어로 작성된 애플리케이션에서만 사용 가능

  • 반면 C 라이브러리는 거의 모든 언어에서 호출 가능

• 객체지향은 디자인 패턴이지 언어 자체가 아님, C에서도 객체지향적 구조 구현 가능

• 객체지향이 항상 최선은 아니며, 절차적 코드가 더 단순하고 유지보수 및 성능 면에서 유리한 경우도 있음

• SQLite 개발 초기(2000년대 초)에는 Java가 미성숙했고, C++은 컴파일러 간 호환성 문제가 심각했음

  • 당시 C가 명백히 더 나은 선택이었으며, 현재도 재작성 이점이 거의 없음

3. ‘안전한 언어’로 작성되지 않은 이유

• 최근 Rust, Go 같은 ‘안전한 언어’ 가 주목받지만, SQLite는 여전히 C로 유지됨

1. SQLite 초기 10년 동안 안전한 언어가 존재하지 않았음
   • Go나 Rust로 다시 작성할 수는 있으나, 새로운 버그 발생과 속도 저하 위험 존재
2. 안전한 언어는 배열 경계 검사 등 추가 분기(branch) 를 삽입
   • 올바른 코드에서는 해당 분기가 실행되지 않아, 100% 분기 테스트 불가능
3. 대부분의 안전한 언어는 메모리 부족(OOM) 시 프로그램을 중단
   • SQLite는 OOM에서도 정상 복구하도록 설계되어 있어, 이 동작과 충돌
4. 기존 안전 언어들은 모두 새롭고 빠르게 변화 중
   • SQLite는 오래되고 안정적인 언어를 선호

4. Rust로의 이식 가능성

• SQLite가 Rust로 재작성될 가능성은 존재하지만, Go로의 이식은 거의 불가능
  • 이유: Go는 assert()를 싫어함
• Rust로 이식되기 위한 전제 조건
  1. Rust가 더 성숙해지고, 변화 속도가 느려져 ‘오래되고 안정적인 언어’ 가 될 것
  2. Rust가 모든 언어에서 호출 가능한 범용 라이브러리를 생성할 수 있을 것
  3. 운영체제가 없는 임베디드 장치에서도 동작 가능한 객체 코드를 생성할 것
  4. 100% 분기 커버리지 테스트를 지원하는 도구 체계를 갖출 것
  5. OOM 복구 메커니즘을 제공할 것
  6. C 수준의 성능 손실 없는 구현을 입증할 것
• Rust가 위 조건을 충족한다고 생각하는 개발자는 SQLite 팀에 직접 연락해 논의 가능

5. 결론

• SQLite는 작고, 빠르고, 신뢰성 있는 데이터베이스 엔진으로, C 언어의 특성이 그 목표에 부합
• 객체지향이나 안전한 언어로의 전환은 호환성, 성능, 품질 관리 측면에서 실익이 없음
• C의 단순함과 안정성이 SQLite의 장기적 유지보수와 신뢰성을 뒷받침함