SQLite는 어떻게 망가지는가 — 공식 문서가 알려주는 DB 손상의 모든 원인

왜 이걸 알아야 하냐면요

SQLite는 세상에서 가장 많이 쓰이는 데이터베이스예요. 스마트폰 앱, 브라우저, 임베디드 기기 안에 거의 다 들어 있거든요. 그런데 SQLite 공식 사이트에는 좀 독특한 문서가 하나 있어요. 제목이 "데이터베이스를 손상시키는 방법(How To Corrupt An SQLite Database File)"이에요.

이게 무슨 "파괴 매뉴얼"이냐면, 정반대예요. "이런 짓을 하면 DB가 깨지니까, 거꾸로 이걸 피하면 안전하다"는 걸 알려주는 방어용 문서거든요. SQLite는 정상적으로 쓰면 굉장히 견고하지만, 사람들이 잘못 쓰는 패턴이 워낙 정형화돼 있어서 아예 그걸 한데 모아 정리해둔 거예요. 데이터 안정성을 고민하는 개발자라면 한 번쯤 꼭 읽어볼 가치가 있어요.

SQLite가 깨지는 대표적인 원인들

1. 파일을 몰래 가로채는 동기화/백업 도구

가장 흔한 사고예요. SQLite가 한창 데이터를 쓰는 도중에, Dropbox나 iCloud 같은 동기화 프로그램, 혹은 백업 스크립트가 그 파일을 복사해가면 문제가 생겨요. SQLite는 본체 파일(.db)과 함께 변경 내용을 임시로 적어두는 저널 파일(journal/WAL)을 같이 쓰는데요. 둘은 한 쌍으로 움직여야 정합성이 맞아요. 그런데 백업 도구가 본체만 복사하고 저널은 안 가져가거나, 둘을 서로 다른 시점에 복사하면 짝이 안 맞아서 손상된 사본이 만들어져요. 그래서 "실행 중인 DB 파일은 절대 일반 파일 복사로 백업하지 말라"고 하는 거예요. 백업하려면 .backup 명령이나 안전한 API를 써야 해요.

2. fsync를 무시하거나 거짓말하는 저장장치

SQLite는 데이터를 디스크에 확실히 기록하려고 fsync()라는 시스템 호출을 해요. "방금 쓴 거 진짜로 디스크에 박았지?"라고 확인하는 명령이죠. 그런데 일부 싸구려 저장장치나 가상화 환경, 잘못 설정된 파일시스템은 실제로는 캐시에만 들고 있으면서 "응, 다 썼어"라고 거짓말을 해요. 이 상태에서 갑자기 정전이 되면 아직 디스크에 안 박힌 데이터가 날아가고, DB가 어중간하게 깨진 상태로 남아요. 하드웨어가 약속을 안 지키면 소프트웨어가 아무리 잘해도 막을 수가 없는 부분이에요.

3. 네트워크 파일시스템(NFS 등)에서의 파일 락 문제

SQLite는 여러 프로세스가 동시에 건드리지 못하게 파일 잠금(file lock)을 걸어요. 그런데 NFS 같은 네트워크 공유 폴더에서는 이 잠금 기능이 제대로 동작하지 않는 경우가 많아요. 그래서 두 프로세스가 "나만 쓰고 있다"고 착각하며 동시에 쓰면 데이터가 뒤섞여 깨져요. 네트워크 드라이브 위에 SQLite를 두는 건 위험하다는 게 핵심 교훈이에요.

4. 핫 저널을 함부로 지우기

프로그램이 쓰다가 비정상 종료되면 저널 파일이 남아요. 이걸 "핫 저널(hot journal)"이라고 하는데요. 다음에 SQLite가 열릴 때 이 저널을 보고 "아, 중간에 끊겼구나" 하며 자동으로 복구(롤백)해요. 그런데 사람이 "이 임시 파일 뭐지?" 하고 저널만 지워버리면, SQLite는 복구 단서를 잃어서 본체 DB가 어정쩡하게 망가진 상태로 남아요. .db 파일 옆에 생기는 동반 파일들을 멋대로 건드리면 안 돼요.

5. 같은 DB를 두 연결이 따로 mmap으로 만지거나, 파일을 직접 수정하는 경우

메모리 매핑(mmap)으로 파일을 다룰 때의 미묘한 버그, 또는 외부 도구로 DB 파일의 바이트를 직접 손대는 행위도 손상 원인으로 꼽혀요. SQLite의 내부 규칙을 무시하고 파일을 건드리면 당연히 깨지겠죠.

한국 개발자에게 주는 시사점

이 문서의 진짜 메시지는 "SQLite가 약하다"가 아니에요. 오히려 "손상의 원인은 거의 다 SQLite 바깥(하드웨어, 파일시스템, 운영 실수)에 있다"는 거예요. 실무에서 바로 적용할 점을 추려보면요.

• 모바일 앱에서 SQLite를 쓴다면, DB 파일을 클라우드 동기화 폴더에 두지 마세요. 동기화 충돌로 사용자 데이터가 깨지는 사고가 실제로 잦아요.
• 백업은 반드시 SQLite가 제공하는 백업 API나 .backup 명령을 쓰세요. cp로 복사하는 습관은 위험합니다.
• 서버에서 쓴다면 NFS 같은 공유 스토리지를 피하고, 가능하면 로컬 디스크에 두고 WAL 모드를 활용하세요.
• 동반 파일(-wal, -journal, -shm)을 정리 스크립트가 멋대로 지우지 않도록 주의하세요.

마무리

결국 핵심은 "SQLite를 깨뜨리는 건 대부분 우리의 운영 방식"이라는 거예요. 이 손상 패턴들을 거꾸로 뒤집으면 그대로 안전 수칙이 됩니다.

혹시 여러분도 SQLite 파일이 알 수 없이 깨진 경험이 있으신가요? 그때 원인이 이 다섯 가지 중 하나는 아니었을까요?