TigerBeetle은 세계에서 가장 흥미로운 데이터베이스임

• 금융 거래 데이터베이스 TigerBeetle은 차변(debit) 과 대변(credit) 을 네이티브 지원하는 새로운 데이터베이스로, 기존 SQL 데이터베이스가 한 건의 거래에 10~20회의 쿼리를 필요로 하던 것과 달리 단일 라운드트립으로 8,190건의 거래를 처리
• 수많은 시스템이 빠른 코딩과 의존성 확장을 택하는 반면, 이 프로젝트는 코드를 천천히 쓰기, 결정적 시뮬레이션 테스트(DST), 제로 디펜던시 같은 반(反)상식 전략을 고수함
• 단일 노드 아키텍처에 의존하는 기존 OLTP 데이터베이스와 차별화하여 분산 기본값, 시계 고장 허용(cluster time), 스토리지 결함 허용을 설계에 내재화했으며, Viewstamped Replication과 Zig 선택으로 구현 단순성과 가시성을 확보
• NASA의 Power of Ten에서 영감을 받은 TigerStyle 방법론을 적용하여 함수당 평균 2개 이상의 assertion 사용, 정적 메모리 할당 강제, 프로덕션 환경에서도 assertion 활성화 등 엄격한 코딩 표준 준수
• 실시간 결제·게이밍·에너지 과금 등 초거래화 시대에 맞춘 구조로, 차세대 OLTP의 성능·정확성 기준점을 제시하고 기존 20~30년 된 SQL 데이터베이스를 대체할 차세대 트랜잭션 처리 시스템으로 부상

---

차변/대변 중심 데이터베이스의 필요성

• TigerBeetle은 "금융 거래 데이터베이스"로 차변(debit)과 대변(credit)을 핵심 프리미티브로 사용
  • 1985년 Jim Gray가 정의한 트랜잭션의 본질은 SQL 트랜잭션이 아닌 비즈니스 트랜잭션(차변/대변) 이었음
  • Gray는 20년 후에도 표준 트랜잭션 처리를 "DebitCredit"으로 정의: 은행 계좌에서 차변 처리하고 복식부기를 수행한 뒤 터미널에 응답
  • 차변/대변은 단순히 회계나 은행만을 위한 것이 아니라 거래의 본질을 나타내는 공통 언어이며, ACID 같은 보장을 제공하는 이유
• 기존 SQL 데이터베이스로 차변/대변 구현 시 문제점
  • 하나의 차변/대변 처리를 위해 계좌 잔액 조회, 행 잠금, 코드 내 의사결정 대기, 차변/대변 기록 등 10~20회의 SQL 쿼리가 필요
  • 네트워크 왕복 시간 동안 행 잠금을 유지해야 하며, 많은 거래가 동일한 "하우스 계좌"에 접근하는 핫 로우 문제 악화
  • 인도, 브라질의 월간 수십억 건 즉시 결제, 미국 FedNow, 에너지/게임/클라우드의 실시간 빌링 등으로 세계는 10년 내 최소 3자릿수 규모로 더 트랜잭션 중심이 되었으나 현재 사용하는 SQL 데이터베이스는 20~30년 전 기술
• TigerBeetle의 차별화 포인트
  • 차변/대변을 1급 프리미티브로 설계하여 단일 1MiB 쿼리에 8,190건의 거래를 하나의 라운드트립으로 처리
  • 창립자 Joran은 이를 "1000x 성능 아이디어"라 부르지만 "특별한 것 아님"이라고 표현
  • 일반적으로 데이터베이스는 구축에 10년이 걸리지만, TigerBeetle은 3.5년 만에 완성되어 Jepsen 테스트를 통과
  • 2025년 6월 Kyle Kingsbury는 모든 머신에서 다양한 위치를 손상시키면서도 TigerBeetle의 기반을 깨뜨릴 수 없었음 (내구성에 영향을 주지 않는 읽기 쿼리 엔진에서 1건의 정확성 버그만 발견)

현대적 데이터베이스 설계

기본 분산 아키텍처

• Postgres와 MySQL이 구축된 시대에는 단일 노드 패러다임이 지배적이었으나, 현재 공유 클라우드 하드웨어 시대에는 분산 패러다임이 주류
  • 현대 데이터베이스는 엄격한 직렬화 가능성을 제공하며 머신 간 트랜잭션을 복제하여 중복성, 장애 허용성, 고가용성 확보 필요
  • 현재 가장 인기 있는 OLTP 데이터베이스 중 일부는 여전히 단일 노드 아키텍처에 크게 의존하며, 자동 페일오버가 기본적으로 내장되지 않은 경우 존재
• TigerBeetle의 분산 설계
  • 기본적으로 분산되도록 구축되어 클러스터 내 원하는 수의 머신에 바이너리만 설치하면 됨
  • 비동기 복제, Zookeeper 등이 불필요하며, MIT의 선구적인 Viewstamped Replication 합의 프로토콜 구현에 투자
  • Zig 툴체인을 제외하고 제로 디펜던시를 유지하며, 모든 핵심 의존성에 직접 투자

클럭 장애 허용성

• TigerBeetle은 트랜잭션 데이터베이스로서 물리적 타임스탬프의 정확성이 감사 및 규정 준수를 위해 중요
  • Linux에는 여러 클럭이 있음: CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC, CLOCK_BOOTTIME
  • 하드웨어 클럭의 물리적 불완전성으로 클럭이 다른 속도로 작동하여 "drift" 오류 발생, 짧은 시간 내 "skew" 오류로 누적
  • 일반적으로 NTP가 이러한 오류를 수정하지만, 부분적 네트워크 장애로 NTP가 조용히 중단되면 고가용성 합의 클러스터가 어둠 속에서 실행될 수 있음
• 클러스터 타임 구현
  • 클러스터 내 대다수 클럭을 결합하여 장애 허용 클럭인 "클러스터 타임" 구성
  • 필요시 서버의 시스템 시간을 다시 정렬하거나, 결함 있는 클럭이 너무 많으면 안전하게 종료
  • Chrony, PTP, NTP가 작동을 멈춘 경우를 실제로 감지하고 운영자에게 경고
  • 서버 간 오프셋 클럭 시간을 추적하고 샘플링한 뒤 Marzullo 알고리듬을 통해 가장 정확한 간격 추정

스토리지 장애 처리

• 기존 데이터베이스의 가정

  • 디스크 장애 시 오류 메시지와 함께 예측 가능하게 실패한다고 가정
  • SQLite 문서: "SQLite는 손상이나 I/O 오류 감지를 위해 데이터베이스 파일에 중복성을 추가하지 않으며, 읽은 데이터가 이전에 쓴 데이터와 정확히 동일하다고 가정"

• 실제 스토리지 장애 시나리오

  • 디스크가 조용히 손상된 데이터 반환, I/O 잘못된 방향 전달(읽기/쓰기 경로), 오류 코드 없이 갑자기 느려지는 gray failure 등 발생 가능

• TigerBeetle의 스토리지 장애 허용성

  • Protocol Aware Recovery 사용으로 모든 복제본에서 데이터 복사본이 손상되지 않는 한 가용성 유지
  • 모든 데이터가 불변이며, 체크섬 및 해시 체인으로 손상이나 변조가 없음을 강력히 보장
  • 자체 페이지 캐시, O_DIRECT로 디스크에 데이터 쓰기, 원시 블록 디바이스에서 직접 실행(파일시스템 불필요)으로 디스크와 소프트웨어 사이 레이어 최소화
  • 기성 LSM 대신 자체 구현한 LSM Forest(약 20개의 LSM 트리) 사용
  • 스토리지 장애 허용을 주장할 뿐 아니라 Jepsen에 의해 검증된 유일한 분산 데이터베이스
  • 로컬 머신 장애 시 디스크 섹터만 실패해도 스토리지 엔진이 글로벌 합의에 연결되어 클러스터를 통해 자가 치유

Zig 프로그래밍 언어 선택

• 기존 데이터베이스의 언어

  • Postgres는 C(1970년대), MySQL은 C와 C++(1979), MSSQL도 C와 C++로 작성
  • 프로그래밍 언어는 지난 40년간 크게 발전했으며, 현대적으로 구축한다면 Rust나 Zig 선택 가능

• TigerBeetle이 Zig를 선택한 이유

  • 전체 C 에코시스템 활용 가능, 뛰어난 툴체인과 컴파일러 제공
  • 작성이 쉽고 특히 읽기가 쉬우며, 경우에 따라 TypeScript만큼 쉬우면서 훨씬 빠름
  • 정적 메모리 할당 가능, TigerBeetle의 핵심 원칙
  • 우수한 개발자 경험, 빠른 학습 가능(따라서 TigerBeetle 소스 코드에 빠르게 진입 가능)
  • 초기 Rust 팀 멤버인 Matklad(Rust Analyzer 창시자), Brian Anderson(Graydon과 함께 Rust 공동 창시자) 등이 TigerBeetle에서 근무
  • Rust에서 동적 메모리 할당을 사용하지 않는 것은 "하드 모드"이지만 Zig에서는 쉬움

Deterministic Simulation Testing과 VOPR

DST의 기본 개념

• Deterministic Simulation Testing (DST) 는 FoundationDB 팀(현재 Apple 소유)이 대중화한 혁신적 테스트 기법

  • 더 안전하고 버그 없는 분산 데이터베이스를 이전보다 짧은 시간에 개발하는 데 활용
  • 분산 시스템에는 무한한 동시성 문제 조합 존재: 메시지 손실, 예측 불가능한 스레드 실행 순서 등
  • 기존 단위 테스트와 통합 테스트로는 불충분하며, 형식 검증(formal verification)은 비용이 많이 들고 느림

• DST 작동 원리

  • 특정 시간선에서 시스템이 직면할 거의 모든 가능한 시나리오를 결정론적으로 실행하는 시뮬레이터
  • OS, 네트워크, 디스크 문제나 다양한 지연 같은 외부 요인도 고려
  • 짧은 시간에 수년 분량의 테스트 제공(시간 자체가 결정론적이 되어 while true 루프 가능)
  • 데이터베이스(I/O 집약적, 컴퓨팅 비집약적)에 특히 적합
  • Jepsen 테스트는 DST가 할 수 있는 것의 부분집합

TigerBeetle의 VOPR

• VOPR(Viewstamped Operation Replicator) 개요

  • 영화 WarGames의 WOPR 시뮬레이터에서 이름을 따온 자체 개발 테스트 클러스터
  • 노드가 리더를 선출하는 방식부터 개별 상태 및 네트워크 장애까지 무수히 다른 조건에서 TigerBeetle을 지속적으로 테스트
  • 단일 스레드에서 전체 분산 클러스터를 가상으로 시뮬레이션 가능

• VOPR의 규모

  • 지구상에서 가장 큰 DST 클러스터로 1,000개 CPU 코어에서 실행
  • Hetzner가 그렇게 많은 코어를 원하는지 확인하는 특별 이메일을 보낼 정도로 비정상적으로 큰 규모
  • VOPR-1000은 24x7x365 실행되어 프로덕션 전 가능한 한 희귀한 조건 포착
  • 시뮬레이터에서 시간이 결정론적으로 추상화되고 약 700배 가속되어, 하루에 약 2천 년의 시뮬레이션 런타임 축적

DST 게임화

• TigerBeetle은 DST를 게임으로 전환하여 시스템 반응에서 다양한 장애 시나리오를 플레이 가능
  • 게임은 sim.tigerbeetle.com에서 플레이 가능
  • 브라우저에서 실제 VOPR 인스턴스를 실행하여 TigerBeetle 시뮬레이션
  • WebAssembly로 컴파일되었으며, TigerBeetle 엔지니어들이 실제 시스템을 시각화하기 위해 게임 프론트엔드 구축

TigerStyle과 Power of Ten

TigerStyle 방법론

• TigerStyle은 TigerBeetle의 엔지니어링 방법론으로 GitHub에 공개

  • "엔지니어링과 예술, 숫자와 인간 직관, 이성과 경험, 1차 원리와 지식, 정밀함과 시의 교차점에서 진화하는 집단적 주고받기"
  • 영화 Tron: Legacy의 "Biodigital Jazz" 개념 채택: 인간과 디지털 요소의 얽힘, "Grid"의 혼돈적이면서도 구조화된 특성, 기술 내에서 인간 잠재력의 즉흥적 정신 표현
  • TigerBeetle에서는 과학뿐 아니라 예술도 주입하는 코드 정신

• TigerStyle의 영향

  • NASA의 완벽한 코드 작성 원칙인 Power of Ten에서 파생된 엔지니어링 및 코드 원칙 제시
  • 단순성과 우아함 같은 주제부터 명명 방법 같은 응용까지 다룸
  • Resonate, Turso 같은 다른 기업에도 영향을 미치기 시작
  • Lex Fridman 팟캐스트에서도 논의됨

Assertion 사용

• Power of Ten의 규칙 5: Assertion

  • 코드 동작에 대한 기대를 작성하는 동시에 명시적으로 인코딩하는 개념(사후가 아님)
  • 단일 라인으로 불리언으로 작성: assert(a > b)

• TigerStyle의 assertion 규칙

  • 모든 함수 인수, 반환 값, 전제조건, 불변성 assert, 함수당 평균 최소 2개의 assertion
  • assertion이 중요하고 놀라운 경우 주석 대신 assertion 사용
  • 프로그램이 실행되기 전에 설계 무결성을 확인하도록 컴파일 타임 상수 간 관계 assert
  • 발생해야 하는 것뿐만 아니라 기대하지 않는 부정적 공간도 assert(흥미로운 버그가 나타날 수 있는 곳)

성능에 대한 사고

• 코드 작성보다 코드에 대한 추론 및 설계가 더 중요

  • 성능을 해결하고 거대한 1000배 승리를 얻는 최적의 시기는 설계 단계이며, 이는 측정이나 프로파일링이 불가능한 정확한 시점

• TigerStyle의 성능 원칙

  • "네 가지 기본 색상"(네트워크, 스토리지, 메모리, CPU)과 "두 가지 질감"(대역폭과 지연)에 대한 기본적인 냅킨 수학 수행
  • 제어 평면과 데이터 평면 구분, 액세스 일괄 처리, 핫 루프를 독립 실행형 함수로 추출하여 컴파일러 의존성 감소 등 전술적 팁 제공

직접 체험

• TigerBeetle은 현대 연구를 오래된 형식에 적용하여 전례 없는 성능과 안정성 보장 제공
• 대변/차변 네이티브 모델링, 분산 기본값, 스토리지·시계 결함 허용, DST 기반 품질 보증을 결합한 현대적 OLTP 엔진
• 시스템 및 스토리지 엔지니어링에 대한 예술 형식 개발, 그 과정에서 재미를 잊지 않음
• DST의 영리한 활용 덕분에 단 몇 년 만에 Jepsen 표준으로 구축
• 설치는 단일 바이너리로 간단하며, 공식 사이트의 간단 설치 스크립트로 curl 명령만으로 빠르게 시작해서 체험 가능

[happing94]

db 가 왜 분산노드를 안쓸까를 생각하면 postgres 가 왜 단일노드인가를 이해 가능하다
성능보다 중요한게 뭘까 생각해봐라

[onestone]

위 글의 내용과는 별개로, TigerBeetle의 웹사이트 자체도 꽤 인상적입니다.

뭔가 굉장히 빠르다는 느낌을 주고, 무거운 기술이 아닌 유쾌하게 풀어내려고 하는 디자인이 보여서 재밌게 느꼈네요.

링크: https://tigerbeetle.com

[onestone]

정정합니다. 다시 보니 무거운 느낌은 있네요. 다만 심미적으로 인상깊게 느껴서 공유해요 :)

[GN⁺]

Hacker News 의견

• TigerBeetle가 훌륭하긴 하지만, 이 글은 TigerBeetle에 투자한 투자사가 쓴 글임을 알아두길 바람 관련 링크

  • 앞으로 몇 달 동안 내가 쓴 이런 포스트들이 계속 나올 예정임, 사람들이 더 활발하게 논의하면 좋겠음, 상단에 디스클레이머를 추가하는 게 나을지 궁금함, 추가하는 거 어렵지 않음

  • 해당 글은 투자사 사이트에 “Portfolio Spotlight”로 분명하게 올라와 있으니, 기대치를 조정할 필요가 있음

  • 글의 작성 방식에 대해 굳이 언급하지는 않겠지만, 투자사 글이라는 건 굉장히 쉽게 티가 남

• TigerBeetle의 올바름 추구, 코딩 관행, 하이퍼 스페셜라이즈된 방향성에는 팬임 하지만, 포스트 내 몇몇 점은 비판하고 싶음

  • 멀티 노드에 대한 설명이 다소 오해의 소지가 있음. 클라우드 네이티브 사람들이 뭐라 하든, 잘 튜닝된 단일 DB와 커넥션 풀러만 있어도 엄청난 QPS 처리 가능함. 예전 회사에서 유지보수 중 실수로 모든 트래픽을 하나의 MySQL 8 RDS 인스턴스로 몰아도 80~90K QPS는 무리 없이 소화함. 인스턴스도 크지 않았고 스키마와 쿼리, ProxySQL/MySQL 튜닝만 잘 했음. 피크시엔 writer와 read replica 두 대로 120K QPS도 거뜬했음

  • 서버에 node-local NVMe 사용하면 CPU 한계가 먼저 닿을 확률이 높음

  • 중복성 문제는, 네트워크 환경에 맞게 설계된 RDBMS라면 결국 다들 페일오버, 핫스탠바이 기능을 가짐

  • TigerBeetle의 합의(Consensus) 시스템은 clever하고 외부 의존성이 없으나, 큰 row 처리를 시도하지 않음. 1MiB 패킷 한 번에 수천 개 트랜잭션을 처리한다면, 전통적 RDBMS에선 불가능한 일을 가능하게 할 수 있음

  • 이 비판들이 그들의 업적을 폄하하려는 의도는 아니며, 이 제품에 대해 여전히 크게 감명 받고 있음

    • 합의 프로토콜의 한계 지적이 바로 핵심 포인트임. TigerBeetle은 트랜잭션 전용 작업만 분리하여 처리하려는 것이고, 모든 OLGP db를 대체하겠다는 게 아님. 중요한 데이터만 별도 트랜잭션 DB로 옮기라는 의도임. 이런 방식은 TurboPuffer에서도 유사하게 볼 수 있음

    • 최신 RDBMS가 충분히 빠른 건 맞지만, TigerBeetle의 사용 사례는 높은 컨텐션이라는 특수한 환경임. 실제로, 여러 트랜잭션이 하나의 계정을 건드릴 때 클러스터 전체 처리량이 극적으로 하락함을 직접 테스트에서 입증한 바 있음. (참고: 관련 HN 코멘트)

• Joran과 팀의 DST, 분산 시스템 인식, 성능 테스트에 관한 작업이 정말 맘에 듦 특히 의존성 최소화에 대한 집착은 인상적임(물론 OS를 의존성으로 취급할 수도 있을 것 같음)

  • 하지만 일반 OLTP(팀에서는 OLGP라 부르는)를 다루는 방식에는 항상 불공평하단 느낌을 받음. 예를 들어, 금융 트랜잭션에서 행 잠금만 사용하는 것처럼 저성능 SQL 트랜잭션만 사례로 비교해서 마치 50년 전 OLTP 설계 방식을 고수하는 듯이 설명함

  • 공식 성능 페이지에서 컨텐션을 1%까지밖에 내릴 수 없게 되어 있음. Stripe 같은 곳이 OLTP DB에서 1% 컨텐션이라 생각하지 않음

  • 컨텐션을 예측하고, 우아하게 처리하며 극한의 트랜잭션 처리량을 구현하는 시스템을 만들 수 있음. 이런 시스템들은 DB를 컨텐션으로부터 보호해서 계속 확장 가능하게 해줌. 실제로 대규모 결제 시스템의 처리량 수치는 공식 성능비교보다 훨씬 큼

  • 마케팅 내용이 이런 점을 주로 무시하고, 모든 개발자가 미숙한 트랜잭션만 쏟아붓는 것처럼 다루는데, 실제로는 대부분 훨씬 똑똑한 엔지니어임. 결제 업계엔 'payments engineer'라는 직업군도 있음

  • TigerBeetle은 대단하지만, 다른 OLTP를 오해하게끔 유도하는 마케팅 패턴이 불편함

    • 칭찬 고마움

      • OLTP 워크로드가 정말로 0% 컨텐션이라고 하는 게 더 정당하다 생각하는지 궁금함. 실제로 고객들은 각국의 대형 증권사, 자산운용사, 거래소 출신이고 수십 년간 Postgres를 다뤄온 전문가임. 엔지니어들은 stored procedure 등 다 알지만, 동시성과 관련된 문제는 더 깊이 storage engine까지 내려감. OLTP 컨텐션은 실제로 치명적임
      • DBMS 외부 확장이나 복잡한 reconciliation system 문제에 지쳤고, 이로 인해 Chief Architect들이 TB 관련 스타트업까지 차릴 정도임
      • 우리가 강조하려는 메시지는, 컨텐션과 Amdahl’s Law 같은 실체적 이슈를 알려주려는 의도임

    • Stripe의 OLTP DB에서 1% 컨텐션은 아니라고 하셨는데, Stripe는 MongoDB 기반임. RDBMS와의 비교는 사과와 오렌지 비교임

    • underlying OS를 의존성으로 볼 수 있는지에 대해, 완전히 in-memory로 돌고 kexec 중에도 지속되는 시스템을 다룬 경험이 있음. syscalls조차 못 하는 상황에서 OS도 충분히 의존성이 될 수 있음

    • 락 기반 트랜잭션과 커밋 타임에서 조건 체크로 처리하는 최적화 방식의 예시를 들어줄 수 있는지 궁금함

• 우리는 TigerBeetle을 고려했으나, 아래와 같은 장애물이 있었음

  • 우리는 Cloudflare Workers를 사용하는데 TigerBeetle 클라이언트 앱이 지원되지 않음. 이슈 링크 Cloudflare Containers에서라면 될 수도 있겠지만, 우리의 워크플로우는 Workers 중심임

  • 인증(auth) 기능이 없음. 서버(VPS 등)에서 IP 제한만 가능한데, 서버리스 환경에선 고정 IP가 없음 관련 이슈

    • Wireguard로 IP를 ECC키로 인증하는 방식도 해결책이 될 수 있음

    • 실제로 Cloudflare Workers나 AWS Lambda 환경에서 1000개 워커가 모두 DB에 커넥션을 열면 문제가 발생함. 그래서 보통은 DB 앞에 프록시나 서비스 계층을 두는 식으로 해결함. 프록시는 DB에 접근 방법을 알고 있으니, 사설 네트워크에서 auth 문제를 신경쓰지 않음

    • TigerBeetle 솔루션 팀과 상의하면 end-to-end 암호화를 통한 논리적 수준의 인증 등 커스텀 해결책을 제안받을 수 있음

    • 2025년에 인증 기능 없는 DB라니 믿기 어려움. 금융 DB라면 최소한 인증 프록시/레이어 추가 방법 가이드라도 홈페이지에 올려야 함. HTTP를 사용하지 않는다면(문서만으로 명확하지 않음), HTTP 없이 어떻게 인증 프록시를 붙여야 하는지 모두 궁금해할 것임. 그 상태로 인터넷에 노출하면 매우 위험함

• “10년 만에 트랜잭션량이 1000배 이상 늘었고, 사용하는 DB는 20-30년 된 SQL이다. 버틸 수 있을까?”라는 질문이 있었는데, 충분히 가능하다고 봄.

  • 30년 된 소프트웨어라도 계속 업데이트됐고, 당시 튼튼하게 설계된 기반임

    • Joran(TigerBeetle)임. 일반 워크로드에서는 문제 없지만, 트랜잭션 처리에서는 power law 컨텐션 때문에 SQL row lock 문제가 생김(Amdahl's Law 참고). 이론적으로 최대 성능 한계를 계산할 수 있는 contention calculator를 홈페이지에 올려두었으니 참고 바람 contetion calculator

    • DNS 역시 1983년에 공개되어 아직도 인터넷의 근간이 되는 점을 봐도, 기본이 잘 되어 있다면 30년 넘은 시스템도 충분히 버틸힘이 있음. SQL이 대부분 워크로드에서는 충분히 좋음

    • 항상 새롭고 세련된 기술이 기존의 다 써본, 검증된 기술보다 좋을 거라는 법은 없음. 어떤 때엔 소프트웨어 엔지니어들이 업계에서 가장 ‘기억력 없는’ 엔지니어같이 느껴짐

    • 분산 시스템으로 수십 개 DB를 다룰 때는 분산 트랜잭션(Sagas 등)이 꼭 필요함. 싱글 머신 상황에선 관계형 DB가 여전히 훌륭함

    • 예전 하드웨어에서는 성능이 부족했지만, 지금은 기술이 발전해서 오히려 더 빨리 잘 돌아감

• FoundationDB도 TigerBeetle 논의와 상당 부분 공통점이 있음

  • 코드 작성이 느리고, DST, 의존성 없음, 프로덕션에서 기본 분산 환경, 낙관적 락킹으로 시계 오차 허용, Jepsen의 혹독한 테스트, 새로운 언어(Flow)로 테스트 등. FDB로도 비슷한 문제를 다 풀 수 있고 TigerBeetle은 사용 사례에 더 최적화되었을 거라 생각함

  • FDB가 대중적이지 않은 유일한 이유는 잘 만든 레이어가 별로 없음. 다만 몇몇 분이 SQS, DynamoDB, SQLite레이어를 따로 개발하는 중임

    • FDB가 대중적이지 않은 진짜 이유는 Apple임. 2013년 출시되고 제품이 너무 마음에 들어서 회사를 인수한 후, 기존 유저들은 모조리 서비스 중단됨. 독점 종료 후에도 신뢰가 회복되지 않음

    • FDB팀과 협업하며 DST 관련 포스트도 준비 중임

    • 인수 후 어떻게 됐는지 궁금하긴 함

    • 그야말로 'the one true database'라 생각함

    • “왜 모든 hyperscaler가 FDB를 안 쓰는가” 질문하면서 github 검색해보니 결국 Apple 산하로 들어가 있음

• 최근 TigerBeetle 개발 스타일을 Rust, Go 등에 적용해봤는데, 정말 강력하게 추천하고 싶음

  • 단일 엔트리 포인트, 거의 0에 가까운 의존성

  • 로컬에서 CI, 단일 명령어로 테스트/커버리지/린트 등 실행

  • property/snapshot/swarm 테스트로 시뮬레이션 도입하는 것에 흥미를 느끼게 됨

  • 빠름/느림 구분, 모든 테스트는 deterministic하게 seed 사용

  • 명시적인 upper bound + 리소스 풀 운영, 동적 할당도 코드가 이해하기 쉬워짐

  • TB팀의 동영상과 문서 덕분임

    • TigerStyle이 실제로 도움 되고 있다니 기쁨, 피드백 고마움

• “프로덕션에서 assertion을 켜둔다”는 내용 인상적임

  • 왜 assertion을 꺼왔는지 이해 못하겠었음. 운영에서 assert가 실패하면 바로 알아야 함(수사적 표현임)

    • 역사적으로는 assertion을 꺼야 성능 향상이 있었음. 하지만 요즘엔 비교 몇 번 더 하는 게 큰 영향 없음

    • 원래 assertion은 개발자 API 오용 차단 목적의 체크임. 유저 입력 단계에선 제대로 된 에러 메시지 등 비즈니스 로직으로 바꾸는 게 더 합리적임

    • 체크가 쉽지 않은 것도 assertion으로 하고 싶을 때가 있음. 예를 들어, 리스트가 정렬되어 있다는 걸 확인하는 식

    • assertion 본래 목적은 컴파일/테스트 타임 체크임. prod 사용하려면 if문으로 바꾸면 됨. assert가 편리한 설탕 문법에 불과한지 생각해봐야 함

• TB팀이 double-entry 모델(이중부기)을 금융이 아닌 다른 시나리오에도 더 널리 알렸으면 함. 주식, 공연 티켓 등에서도 매우 유용함. API 개선은 다 끝났으니, 이제 활용법을 알릴 때임

  • 분석가로서 SQL은 많이 쓰지만 코드 개발자는 아님. 대체로 개요 설명 및 성능 이점은 이해함. 궁금한 점이 있음 a) TigerBeetle 데이터 구조는 실제로 어떤 모양인지? 일반 테이블 형태는 아닐 것 같음 b) SQL 쿼리를 못 쓴다면 어떻게 사용하게 되는지 c) 더블엔트리 모델을 주식, 티켓 등에 적용하면 어떻게 되는지? 예를 들어 공연장에 티켓 1000장을 보유하고 있다가 하나 팔면 인벤토리에서 현금으로, 이연수익에서 이행책임으로 처리? 아니면 티켓 팔기 전엔 아무런 엔트리가 없는지?

  • Postgres에서도 비슷한 double-entry 구현이 가능함

• “대부분 팀은 코드를 빠르게, 테스트는 고역으로, 의존성은 잔뜩 쌓으며 만든다”는 말은 25년 전엔 오히려 표준이었음. Google, Facebook이 “move fast and break things” 문화를 도입하기 전까지는 모두 칼같이 느리게 만들고 잘 테스트하며 개발했음. TigerBeetle이 더 많은 인정을 받기를 희망함. Jepsen 리포트도 읽을 가치가 있음 Jepsen report

  • 25년 기다려보고 TigerBeetle이 구글이 될지, 느리지만 완벽한 제품이 더 빠른 경쟁자에게 먹힐지 지켜볼 만함

  • “Move fast and break things”는 Facebook의 모토였음. Google은 오히려 테스트에 몰두했었음. 물론 진짜로 존재하는 요구사항에 맞춰야 하고, 엔지니어들은 종종 너무 많은 가상의 요구사항을 만들어 비효율을 초래함. 실제 유저에게 제품을 빨리 전달하고 피드백을 받아 반영하는 게 ‘버블 속에서’ 무한히 제품을 다듬는 것보다 훨씬 가치 있음