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은 오히려 테스트에 몰두했었음. 물론 진짜로 존재하는 요구사항에 맞춰야 하고, 엔지니어들은 종종 너무 많은 가상의 요구사항을 만들어 비효율을 초래함. 실제 유저에게 제품을 빨리 전달하고 피드백을 받아 반영하는 게 ‘버블 속에서’ 무한히 제품을 다듬는 것보다 훨씬 가치 있음
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를 오해하게끔 유도하는 마케팅 패턴이 불편함
칭찬 고마움
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팀의 동영상과 문서 덕분임
“프로덕션에서 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은 오히려 테스트에 몰두했었음. 물론 진짜로 존재하는 요구사항에 맞춰야 하고, 엔지니어들은 종종 너무 많은 가상의 요구사항을 만들어 비효율을 초래함. 실제 유저에게 제품을 빨리 전달하고 피드백을 받아 반영하는 게 ‘버블 속에서’ 무한히 제품을 다듬는 것보다 훨씬 가치 있음