TigerBeetle이 1조 건 트랜잭션을 처리한 비결: 금융 DB의 재발명

왜 금융 트랜잭션은 기존 DB로 힘들까

TigerBeetle이라는 이름을 들어보셨나요? 호주에서 시작된 오픈소스 프로젝트인데, 금융 거래 전용 데이터베이스예요. 최근 공개된 영상에서 "1조 건의 트랜잭션 처리"라는 벤치마크 얘기가 나오면서 다시 주목받고 있습니다.

먼저 왜 이런 게 필요한지부터 얘기해볼게요. 은행 송금, 결제, 증권 거래, 게임 머니 이동 같은 금융성 트랜잭션은 일반적인 CRUD 작업이랑 성격이 달라요. 한 번의 거래가 최소 두 계정의 잔액을 동시에 바꿔야 하고(복식부기), 절대로 중복 처리되면 안 되고, 장애가 나도 절대 돈이 증발하거나 복제되면 안 됩니다. 이걸 Postgres나 MySQL 같은 범용 DB로 구현하려면 락을 걸고, 트랜잭션을 감싸고, 멱등성(같은 요청을 여러 번 보내도 한 번만 처리되는 성질이에요)을 보장하는 로직을 층층이 쌓아야 해요. 그러다 보면 초당 수천 건 수준에서 병목이 생깁니다.

그런데 핀테크, 게임 경제, 암호화폐 같은 분야에선 초당 수만, 수십만 건의 금융 트랜잭션이 필요해요. 그래서 TigerBeetle이 "범용이 아니라 금융 전용으로, 처음부터 다시 설계하자"는 문제의식으로 만들어진 겁니다.

어떻게 그렇게 빠른가

TigerBeetle의 빠름은 몇 가지 과감한 설계 선택에서 나와요. 첫째, 스키마를 고정했어요. 계정(account)과 거래(transfer)라는 딱 두 가지 개념만 존재하고, 필드 구성도 미리 정해져 있습니다. 사용자가 테이블을 만들거나 컬럼을 추가할 수 없어요. 제약이 심해 보이지만, 이 덕분에 데이터 레이아웃을 CPU 캐시 친화적으로 극단적으로 최적화할 수 있어요.

둘째, 배치 처리를 기본으로 삼았어요. 거래를 하나씩 처리하지 않고, 8천 건 정도를 한 묶음으로 받아서 한꺼번에 검증하고 반영합니다. 네트워크 왕복과 디스크 fsync 비용을 수천 건이 나눠 갖게 되니 건당 오버헤드가 극단적으로 줄어들죠. 이게 "1조 트랜잭션" 벤치마크의 핵심 비결 중 하나예요.

셋째, Zig라는 언어로 작성됐어요. Zig는 C와 비슷한 저수준 언어인데, 메모리 할당을 프로그래머가 명시적으로 통제할 수 있어서 예측 가능한 성능을 뽑기 좋아요. TigerBeetle은 실행 중에 힙 할당을 거의 하지 않도록 짜여 있습니다. 시작할 때 메모리를 다 잡아놓고, 그 안에서만 돌아가요. 이러면 GC 지연이나 메모리 단편화 같은 변수가 사라집니다.

넷째, Viewstamped Replication (VSR) 이라는 합의 프로토콜을 씁니다. Raft나 Paxos랑 비슷한 분산 합의 알고리즘인데, TigerBeetle은 이걸 구현하면서 "deterministic simulation testing"이라는 기법을 도입했어요. 이게 뭐냐면, 네트워크 장애·디스크 깨짐·노드 크래시 같은 온갖 최악의 상황을 시뮬레이터에서 수조 번 돌려보면서 버그를 잡는 방식이에요. 실제 프로덕션에서 발생하기 힘든 엣지 케이스를 개발 단계에서 때려잡는 거죠.

다른 옵션들과 비교하면

금융 DB 영역에서 경쟁군을 보면, 전통적으로는 Oracle이나 DB2 같은 엔터프라이즈 RDBMS가 버텨왔어요. 견고하지만 라이선스가 비싸고 확장성이 제한적이죠. 최근엔 CockroachDB, YugabyteDB 같은 분산 SQL DB들이 금융 쪽에도 도전하고 있고, 이벤트 소싱 + Kafka + 전용 계정 엔진을 조합하는 수제 아키텍처도 흔합니다.

TigerBeetle의 포지션은 독특해요. 범용성을 포기하는 대신 금융 한 분야에서 압도적 성능을 내는 전략이거든요. SQL도 없고, 조인도 없고, 커스텀 스키마도 없어요. 대신 "계정 만들기, 이체하기, 잔액 조회하기"를 초당 수십만 건씩 처리해요. 그래서 TigerBeetle만 단독으로 쓰는 게 아니라, 원장(ledger) 역할을 TigerBeetle에 맡기고, 사용자 정보나 메타데이터는 Postgres 같은 범용 DB에 두는 하이브리드 구성이 일반적입니다.

이런 접근을 "도메인 특화 데이터베이스"라고 부르는데, 최근 ClickHouse(분석용), QuestDB(시계열), Neo4j(그래프)처럼 특정 워크로드에 극단적으로 최적화된 DB가 각광받는 흐름의 연장선이에요.

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

국내에서 핀테크나 결제·정산 시스템을 다루는 분들한테는 꽤 매력적인 옵션이에요. 토스나 카카오페이 같은 서비스가 겪는 "초당 수만 건의 이체" 문제를 TigerBeetle 같은 전용 엔진으로 풀면 아키텍처가 훨씬 단순해지거든요. 게임 회사의 인게임 재화 시스템, 포인트·마일리지 시스템에도 비슷한 적합성이 있어요.

다만 당장 프로덕션에 도입하려면 몇 가지 허들이 있어요. 첫째는 운영 경험의 희소성이에요. 국내에 TigerBeetle을 실전 투입해본 팀이 아직 많지 않아서, 장애 대응 노하우가 부족합니다. 둘째는 스키마 제약에 맞춘 도메인 모델링이 필요해요. 기존 RDBMS에 익숙한 팀에겐 사고 전환이 꽤 큰 일이에요.

그래도 공부 대상으로는 강력 추천이에요. TigerBeetle의 설계 철학(제약을 수용해서 성능을 뽑는다, 결정론적 시뮬레이션으로 검증한다)은 꼭 이 DB를 쓰지 않더라도 내가 만드는 시스템에 적용할 수 있는 교훈이 많거든요. 특히 시뮬레이션 기반 테스트는 일반 서버 코드에도 응용 가치가 큽니다.

마무리

한 줄로 정리하면, TigerBeetle은 "범용 DB의 관성을 거부하고, 금융 워크로드 하나에 올인한 결과물"입니다. 1조 트랜잭션이라는 숫자는 결국 "스키마 고정 + 배치 + Zig + 결정론적 테스트"라는 조합이 만들어낸 복리 효과인 셈이에요.

여러분 팀의 시스템에도 "이 부분은 범용 DB로는 한계다" 싶은 영역이 있나요? 그럴 때 도메인 전용 엔진을 도입할 만한 가치가 있을까요, 아니면 그냥 Postgres 튜닝으로 버티는 게 실용적일까요?