Tailscale가 16년 된 SQLite 버그를 추적한 방법
Tailscale은 서비스 안정성 문제의 원인을 추적하다 SQLite에 16년간 잠재해 있던 WAL(Write-Ahead Logging) 리셋 버그를 발견했다. 이 사례는 단순한 버그 픽스 이야기가 아니라, 프로덕션 시스템에서 "검증된 기술"을 믿고 사용할 때도 깊은 레이어의 문제가 발생할 수 있다는 것을 잘 보여준다.
Tailscale의 SQLite 아키텍처
Tailscale의 컨트롤 플레인은 내부적으로 여러 샤드(coordination server)로 나뉘어 운영된다. 각 tailnet은 특정 샤드 위에 존재하며, 각 샤드는 독립된 SQLite 데이터베이스를 보유한다. 중요한 점은 단일 Go 프로세스만이 해당 데이터베이스에 접근한다는 것이다. 이는 SQLite가 설계된 방식 그대로 사용하는 single-writer 패턴이다.
controlplane.tailscale.com
│
┌────┴────┐
Shard A Shard B ...
(SQLite) (SQLite)
백업 파이프라인은 몇 분 간격으로 전체 SQLite 파일을 스냅샷해 S3에 업로드하는 방식이었다. 2022년부터 SQLite를 메인 데이터베이스로 채택한 배경에는 "boring technology"라는 선택 철학이 있었다. 검증된 기술, 단순한 운영, 넓은 생태계—이 세 가지가 선택 이유였다.
왜 이 버그가 실무적으로 중요한가
SQLite의 WAL 모드는 읽기 성능과 동시성을 높이기 위해 많이 사용된다. WAL 파일은 특정 조건에서 "리셋(reset)"되는데, 이 리셋 로직에 16년간 존재했던 버그가 특정 조건에서 데이터베이스 손상을 일으킬 수 있었다. 수개월간 산발적으로 발생하는 장애를 추적한 끝에야 SQLite 내부의 이 버그에 도달했다는 점이 핵심이다.
이 사례가 백엔드 개발자에게 주는 시사점은 명확하다:
- "믿을 수 있는 라이브러리"도 엣지 케이스에서 실패한다. SQLite처럼 전 세계적으로 검증된 소프트웨어도 특정 운영 조건에서 오래된 버그가 발현될 수 있다.
- 단일 프로세스 접근(single-writer) 패턴이어도 WAL 관련 버그는 발생할 수 있다. 단순한 아키텍처가 모든 문제를 막아주지는 않는다.
- 백업 전략과 스냅샷 방식이 버그 탐지와 복구의 핵심 자산이 된다. Tailscale은 주기적 전체 스냅샷 덕분에 손상 시점을 추적하고 복구할 수 있었다.
- 장애 원인이 애플리케이션 레이어가 아닌 인프라·라이브러리 레이어에 있을 때, 포렌식 기간이 수개월로 늘어날 수 있다.
실무 적용 관점
Java 백엔드 환경에서 SQLite를 직접 사용하는 경우는 드물지만, 이 사례는 RDB(MySQL, PostgreSQL 포함)를 사용하는 환경에서도 동일하게 적용되는 교훈을 담고 있다. WAL이나 redo log 기반의 복구 메커니즘을 가진 모든 데이터베이스는 이론적으로 유사한 리셋 버그에 노출될 수 있다.
// 주기적 스냅샷과 checksum 검증을 파이프라인에 포함하는 예시 개념
scheduler.scheduleAtFixedRate(() -> {
File snapshot = backupService.takeSnapshot();
integrityChecker.verify(snapshot); // 손상 감지 로직
storageService.upload(snapshot);
}, 0, 5, TimeUnit.MINUTES);
실무에서는 단순히 백업을 찍는 것에서 그치지 않고, 백업 파일의 무결성을 검증하는 단계를 파이프라인에 포함시켜야 한다. 손상된 채로 적재되는 백업은 복구 시점에 아무런 도움이 되지 않는다.
정리
- SQLite처럼 신뢰받는 오픈소스도 특정 운영 조건에서 수십 년 된 버그가 발현될 수 있으며, 이를 탐지하는 데 수개월의 포렌식이 필요할 수 있다.
- 단일 쓰기 프로세스(single-writer) 아키텍처도 WAL 레이어의 버그로부터 자유롭지 않으므로, 데이터베이스 내부 동작에 대한 이해가 필요하다.
- 백업 파이프라인에는 스냅샷 생성뿐 아니라 무결성 검증 단계를 반드시 포함해야 실제 장애 시 복구 수단으로 활용할 수 있다.