[심층분석] SQLite를 Rust로 다시 쓴다고? 'Turso'가 그리는 in-process DB의 미래

SQLite를 처음부터 다시 쓴다니, 무슨 일이죠?

혹시 "세상에서 가장 많이 쓰이는 데이터베이스가 뭐냐"고 물으면 어떤 게 떠오르시나요? MySQL? PostgreSQL? 사실 정답은 SQLite예요. 우리가 매일 쓰는 스마트폰, 웹 브라우저, 비행기 안의 시스템, 심지어 우리 집 스마트 TV 안에도 SQLite가 조용히 돌아가고 있거든요. 전 세계에 깔려 있는 SQLite가 무려 1조 개가 넘는다는 추정도 있어요.

그런데 이 SQLite, 사실 한 가지 특징이 있어요. 오픈 소스이긴 한데 "오픈 컨트리뷰션"은 아니라는 점이에요. 무슨 말이냐면, 소스 코드는 누구나 볼 수 있고 마음대로 쓸 수 있지만, 외부 개발자가 "저 이 기능 고쳤어요, 넣어주세요" 하고 코드를 보내는 건 받지 않는다는 거예요. SQLite는 소수의 핵심 개발자들이 폐쇄적으로 관리하는 프로젝트거든요. 품질 관리 측면에선 이게 장점이지만, "내가 직접 기여하고 싶다", "이 기능 좀 빨리 넣어줬으면" 하는 사람들에겐 답답한 부분이기도 했죠.

그래서 등장한 게 바로 오늘 이야기할 Turso예요. Turso는 한마디로 "SQLite를 Rust 언어로 처음부터 완전히 다시 쓴" 프로젝트예요. 단순히 SQLite를 가져다 쓰는 게 아니라, 바닥부터 새로 만들면서 SQLite와 호환은 유지하되, 누구나 기여할 수 있는 진짜 오픈 소스 데이터베이스를 만들겠다는 거죠. 참고로 이 프로젝트는 예전에 'Limbo'라는 이름으로 알려졌었는데, 지금은 Turso로 통합됐어요.

'in-process 데이터베이스'가 뭐길래

본격적으로 들어가기 전에 용어 하나만 짚고 갈게요. Turso를 설명할 때 꼭 나오는 말이 "in-process SQL database"예요.

이게 뭐냐면, 보통 우리가 아는 데이터베이스(MySQL, PostgreSQL 같은)는 별도의 서버 프로그램으로 돌아가요. 내 앱이 데이터를 읽거나 쓰려면 그 DB 서버한테 네트워크로 "이거 좀 줘" 하고 요청을 보내고 답을 받아야 하죠. 마치 음식을 먹을 때마다 식당에 전화해서 배달시키는 느낌이에요.

반면 in-process 데이터베이스는 내 앱 안에 데이터베이스가 그냥 라이브러리로 들어와 있는 형태예요. 별도 서버도 없고, 네트워크 통신도 없어요. 그냥 함수 호출하듯이 데이터를 읽고 써요. 비유하자면 집에 냉장고를 두고 바로 꺼내 먹는 거랑 같아요. 배달 기다릴 필요가 없으니 엄청 빠르고, 설치도 간단하고, 운영할 서버도 없죠. SQLite가 그렇게 어마어마하게 많이 쓰이는 이유가 바로 이 "가볍고 간편함"에 있어요. Turso도 이 철학을 그대로 이어받았어요.

Turso가 내세우는 핵심 기능들

Turso는 단순히 SQLite를 똑같이 베낀 게 아니에요. SQLite의 한계로 지적되던 부분들을 적극적으로 개선하고 있어요. 하나씩 쉽게 풀어볼게요.

1. BEGIN CONCURRENT — 동시에 쓰기가 가능해졌어요

SQLite의 오래된 약점 중 하나가 "쓰기 작업"이에요. SQLite는 기본적으로 한 번에 한 명만 데이터를 쓸 수 있어요. 누군가 글을 쓰고 있으면 다른 사람은 줄 서서 기다려야 하죠. 사용자가 적을 땐 문제없지만, 동시에 여러 작업이 데이터를 쓰려고 하면 병목이 생겨요.

Turso는 여기에 MVCC라는 기술을 넣었어요. MVCC는 'Multi-Version Concurrency Control'의 줄임말인데, 쉽게 말하면 데이터의 여러 버전을 동시에 관리해서 여러 명이 충돌 없이 동시에 작업하게 해주는 기술이에요. 도서관에서 책 한 권을 두고 다투는 게 아니라, 각자에게 복사본을 나눠주고 나중에 합치는 느낌이라고 보면 돼요. PostgreSQL 같은 큰 DB들이 쓰는 방식인데, 이걸 가벼운 in-process DB에 넣은 거죠. BEGIN CONCURRENT라는 명령으로 쓰기 처리량(throughput)을 크게 끌어올릴 수 있어요.

2. 비동기 I/O와 io_uring

Turso는 리눅스에서 io_uring이라는 최신 기술을 지원해요. 이게 뭐냐면, 디스크에서 데이터를 읽고 쓸 때 "다 될 때까지 멈춰서 기다리는" 게 아니라, "요청만 던져놓고 다른 일 하다가 끝나면 알림 받는" 방식이에요. 식당에서 진동벨 받아두고 자리에 앉아 있다가 음식 나오면 가지러 가는 거랑 똑같아요. 무작정 카운터 앞에 서서 기다리는 것보다 훨씬 효율적이죠. 이런 비동기(asynchronous) 처리 덕분에 같은 하드웨어에서도 더 많은 작업을 소화할 수 있어요.

3. 그 외에도 알찬 기능들

CDC (Change Data Capture): 데이터베이스에 어떤 변경이 일어났는지 실시간으로 추적해요. "누가 언제 뭘 바꿨는지"를 흘려보낼 수 있어서, 다른 시스템과 데이터를 동기화하거나 실시간 알림을 만들 때 유용해요.
벡터(Vector) 검색: 요즘 AI 시대에 꼭 필요한 기능이죠. 텍스트나 이미지를 숫자 배열로 바꿔서 "의미가 비슷한 것"을 찾는 검색이에요. 별도 벡터 DB를 안 깔아도 SQLite 호환 DB 안에서 처리할 수 있어요.
저장 시 암호화(Encryption at rest): 디스크에 저장될 때 데이터를 암호화해줘요. (아직 실험적 기능이에요.)
폭넓은 언어 지원: Go, JavaScript, Java, .NET, Python, Rust, 그리고 WebAssembly까지. WebAssembly 덕분에 브라우저 안에서도 돌아가요.
개선된 스키마 관리: SQLite가 약했던 ALTER TABLE(테이블 구조 변경) 지원이 확장됐고, 스키마 변경도 더 빨라졌어요.

왜 하필 Rust로 다시 썼을까?

여기서 "왜 굳이 Rust냐"는 질문이 나올 수 있어요. 기존 SQLite는 C언어로 작성됐거든요. C는 빠르고 강력하지만, 메모리 관리를 사람이 직접 해야 해서 작은 실수가 보안 취약점이나 충돌로 이어지기 쉬워요.

Rust는 컴파일 단계에서 메모리 오류를 거의 다 잡아주는 언어예요. 비유하자면, C는 안전벨트 없이 빠른 차를 모는 거고, Rust는 안전벨트와 에어백을 다 갖춘 채로 똑같이 빠르게 달리는 거예요. 데이터베이스처럼 안정성이 생명인 소프트웨어에는 이 "메모리 안전성"이 정말 큰 강점이에요. 게다가 Rust 생태계의 비동기 처리 도구들과도 자연스럽게 어울리니, io_uring 같은 최신 기술을 녹이기도 좋고요.

Turso 팀은 또 흥미로운 시도를 하고 있는데, 코드 곳곳에 AGENTS.md, CLAUDE.md 같은 AI 협업용 문서와 결정론적 시뮬레이션 테스트(DST) 같은 검증 기법을 적극 도입하고 있어요. 데이터베이스의 신뢰성을 끌어올리려고 테스트에 굉장히 공을 들이는 프로젝트라는 점도 눈여겨볼 만해요.

경쟁자들과 비교하면 어디쯤일까

비슷한 길을 가는 프로젝트들이 있어요. 쉽게 비교해볼게요.

SQLite (원조): 가장 안정적이고 검증됐어요. 하지만 외부 기여를 안 받고, 동시 쓰기나 비동기 I/O 같은 현대적 기능엔 보수적이에요. "검증된 클래식"이죠.
libSQL: 사실 Turso를 만든 같은 회사가 먼저 시작한 프로젝트인데, 이건 SQLite의 C 코드를 포크(복사해서 갈라져 나옴)해서 기능을 추가하는 방식이었어요. 즉 SQLite 위에 덧붙이는 접근이에요. 반면 Turso는 아예 백지에서 Rust로 새로 쓰는 접근이라 더 과감해요.
DuckDB: 똑같은 in-process DB지만 성격이 달라요. DuckDB는 분석(OLAP)에 특화돼 있어요. 대량의 데이터를 모아놓고 통계 내고 집계하는 데 강하죠. 반면 SQLite와 Turso는 일반적인 거래성 작업(OLTP), 즉 하나씩 읽고 쓰는 데 강해요. "엑셀 피벗테이블 전문가(DuckDB)"와 "현금출납 장부 담당(SQLite/Turso)"의 차이라고 보면 돼요.

포지셔닝을 정리하면, Turso는 "SQLite의 간편함과 호환성은 그대로 두되, 동시성·비동기·AI 기능을 더한 차세대 버전"을 노리고 있어요. 다만 잊지 말아야 할 게, 공식적으로 아직 BETA라는 점이에요. 프로덕션 데이터에 바로 쓰기엔 이르고, 반드시 백업을 챙기라고 안내하고 있어요.

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

자, 그럼 우리는 이걸 어떻게 활용하면 좋을까요? 몇 가지 현실적인 시나리오를 들어볼게요.

1) 엣지/로컬 우선 앱을 만든다면. 요즘 "로컬 퍼스트(local-first)" 앱이 뜨고 있어요. 인터넷 없이도 동작하다가 연결되면 동기화하는 방식이죠. Turso의 CDC와 동기화(sync) 기능, 그리고 WebAssembly 지원은 이런 앱을 만들기에 잘 맞아요. 노트 앱이나 할 일 관리 앱처럼 "오프라인에서도 잘 되어야 하는" 서비스에 어울려요.

2) AI 기능을 가볍게 붙이고 싶다면. 벡터 검색이 내장돼 있으니, 별도의 벡터 DB 인프라 없이도 간단한 의미 기반 검색이나 추천 기능을 프로토타입으로 만들어볼 수 있어요. 사이드 프로젝트나 MVP(최소 기능 제품) 단계에서 특히 매력적이죠.

3) 당장 도입은 신중하게. 다만 BETA라는 점 때문에, 회사의 핵심 서비스 DB를 지금 당장 Turso로 바꾸는 건 추천하기 어려워요. 대신 개인 프로젝트, 학습용, 내부 도구부터 가볍게 써보면서 감을 익히는 걸 권해요. SQLite 호환이라 기존 SQLite 지식이 거의 그대로 통하거든요.

학습 로드맵을 제안하자면 이래요. 먼저 SQLite 자체에 익숙하지 않다면 SQLite 기본 SQL부터 다지세요. 그다음 Turso의 CLI를 깔아서 직접 만져보고, 본인이 쓰는 언어(Python이든 JS든)의 바인딩으로 간단한 토이 앱을 붙여보세요. MVCC나 io_uring 같은 개념은 "왜 필요한가"라는 맥락 위주로 이해하면 충분해요. Rust를 모른다고 못 쓰는 게 아니에요. Rust로 쓰여 있을 뿐, 우리는 라이브러리로 가져다 쓰면 되니까요.

마무리하며

Turso의 등장은 단순히 "SQLite 클론 하나 더 나왔네"가 아니에요. 가장 검증된 데이터베이스를, 현대적인 언어와 설계로, 그리고 누구나 기여할 수 있는 진짜 열린 방식으로 다시 만들겠다는 시도거든요. 이게 성공한다면, 우리가 앞으로 만들 작은 앱부터 엣지 디바이스, AI 서비스까지 데이터를 다루는 기본 도구가 한 단계 진화하는 셈이에요.

물론 아직은 BETA고, 원조 SQLite의 30년 가까운 안정성을 따라잡으려면 시간이 필요해요. 하지만 방향성만큼은 분명히 흥미롭죠.

여러분은 어떠세요? 지금 SQLite를 쓰고 있다면, Turso의 어떤 기능이 가장 끌리시나요? 동시 쓰기 성능일까요, 아니면 벡터 검색이나 브라우저 지원일까요? 혹시 "이건 우리 프로젝트에 바로 써보고 싶다" 싶은 시나리오가 있다면 댓글로 같이 이야기 나눠봐요. 여러분의 경험이 다른 분들에게 큰 힌트가 될 거예요.

🔗 출처: GitHub

이 글도 읽어보세요