Rust로 만든 SQL 엔진 'Rocky' — 데이터에도 Git처럼 브랜치를 만들 수 있다면

코드는 브랜치 따는데, 왜 데이터는 못 따나요?

코드 작업할 때 우리는 Git에 너무 익숙해져 있잖아요. 새 기능 만들 때 브랜치 따고, 실험하고, 잘 되면 머지하고, 아니면 그냥 버리고. 그런데 데이터베이스는 어떤가요? 프로덕션 데이터를 한 번 잘못 건드리면 백업에서 복구해야 하고, 분석가가 "이 컬럼을 이렇게 변형해 보면 어떨까?" 하고 실험하고 싶어도 결국 별도 환경을 통째로 만들어야 했죠. 코드와 데이터 사이에 큰 격차가 있었던 거예요.

Rocky는 바로 그 격차를 메우려는 새로운 SQL 엔진입니다. Rust로 작성됐고, 세 가지를 큰 무기로 내세워요. 첫째는 브랜치(branch) — 데이터에도 Git처럼 갈래를 만들 수 있어요. 둘째는 리플레이(replay) — 모든 변경을 시간 순서대로 다시 재생할 수 있고요. 셋째는 컬럼 리니지(column lineage), 즉 어떤 결과 컬럼이 원본 어떤 컬럼에서 어떻게 만들어졌는지 계보를 추적합니다.

어떻게 동작할까요?

브랜치 기능부터 들여다볼게요. 우리가 깃에서 git checkout -b feature-x 하듯이, Rocky에서는 데이터셋에 새 브랜치를 만들고 그 안에서 INSERT, UPDATE, DELETE를 마음껏 돌릴 수 있어요. 메인 브랜치 데이터는 안 건드리고요. 이게 어떻게 가능하냐면, 내부적으로 데이터를 불변(immutable) 스냅샷 형태로 관리하기 때문이에요. 변경이 일어나면 원본을 덮어쓰는 게 아니라 새 버전을 추가하는 식이죠. 그래서 어떤 시점으로든 시간 여행이 가능해집니다.

리플레이는 여기서 한 발 더 나아가요. 데이터베이스에 가해진 모든 작업을 로그로 남겨두고, 필요하면 그 로그를 처음부터 다시 실행할 수 있어요. 디버깅할 때 정말 강력한 무기예요. 프로덕션에서 "어제 밤 11시쯤 이상한 값이 들어왔는데 어떻게 된 거지?" 같은 질문에 답하기가 훨씬 쉬워지거든요. 그 시점까지의 작업만 다시 재생해보면 되니까요.

컬럼 리니지는 데이터 거버넌스(데이터를 어떻게 관리·통제할지에 대한 규칙) 관점에서 빛납니다. 예를 들어 revenue라는 컬럼이 대시보드에 뜬다고 해봐요. 이 값이 도대체 어디서 어떻게 계산된 건지, 원천 테이블의 어떤 컬럼들을 어떤 함수로 조합한 건지 추적해야 할 때가 있죠. GDPR 같은 개인정보 규제에 대응할 땐 "이 사용자의 이메일이 파생된 컬럼들 어디까지 퍼져 있는가"를 봐야 하고요. Rocky는 SQL 쿼리를 실행할 때 자동으로 이 의존 관계를 그래프로 만들어 둡니다.

Rust로 만든 점도 중요해요. 메모리 안전성을 컴파일 타임에 보장하니까 메모리 누수나 데이터 레이스(여러 스레드가 동시에 같은 메모리를 건드려서 생기는 버그) 걱정이 줄어들어요. 가비지 컬렉터가 없어서 응답 지연도 예측 가능합니다.

비슷한 친구들과 비교하면

같은 길을 가는 프로젝트들이 있긴 해요. Dolt는 "Git for Data"를 표방하는 MySQL 호환 데이터베이스고, lakeFS는 데이터 레이크 위에 Git 같은 인터페이스를 얹어주는 오픈소스죠. Iceberg, Delta Lake, Apache Hudi 같은 테이블 포맷들도 시간 여행과 스냅샷 격리를 지원해요. 그러니까 "데이터 버전 관리"라는 흐름은 이미 진행 중이에요.

Rocky가 차별화되는 지점은 브랜치, 리플레이, 리니지를 한 엔진에 통합했다는 것과, 무거운 분산 인프라 없이도 가벼운 단일 바이너리로 돌릴 수 있다는 점이에요. Dolt는 MySQL 호환에 집중하고, lakeFS는 객체 스토리지 게이트웨이 성격이 강한데, Rocky는 SQL 엔진 자체가 이런 기능을 일급 시민으로 다룬다는 거죠.

한국 개발자에게는 어떤 의미일까요?

당장 프로덕션에 쓰기엔 이르긴 해요. 아직 초기 프로젝트니까요. 하지만 다음 같은 상황이라면 한 번 손에 익혀둘 만합니다. 데이터 파이프라인을 운영하면서 변경 이력 추적과 롤백이 자주 필요한 분, 머신러닝 실험 환경에서 학습 데이터 버전 관리가 중요한 분, 사내 데이터 거버넌스 도구를 만드는 분이라면요. Rust 학습 자료로도 좋은 코드베이스가 될 거예요. 실제 시스템 소프트웨어가 어떻게 비동기 IO와 동시성을 다루는지 들여다볼 수 있거든요.

마무리

데이터베이스도 결국엔 코드처럼 다뤄지는 시대로 가고 있어요. Rocky는 그 흐름의 흥미로운 한 점입니다. 여러분의 팀에서 데이터 변경을 어떻게 관리하고 계신가요? 백업과 복구로 충분하다고 느끼시나요, 아니면 Git 같은 브랜치 모델이 진짜로 필요하다고 느낀 적이 있으신가요?