데이터베이스는 정말 약속을 지킬까?
새 데이터베이스를 도입할 때 우리는 보통 공식 문서를 믿어요. '직렬성(Serializable) 보장', '강한 일관성', '장애가 나도 데이터 유실 없음' 같은 문구를 보고요. 그런데 네트워크가 끊기고, 노드가 죽고, 시계가 어긋나는 실제 상황에서도 이 약속이 지켜질까요? 이걸 집요하게 검증해온 곳이 Jepsen이에요. 이번에 Jepsen이 ParticleDB 1.1.4 버전 분석 보고서를 공개했어요. 오늘은 Jepsen이 뭔지, 어떻게 테스트하는지, 그리고 이런 보고서를 어떻게 읽고 실무에 써먹으면 좋은지 정리해볼게요.
Jepsen이 뭐냐면
Jepsen은 카일 킹스버리(Kyle Kingsbury, 'aphyr')가 만든 분산 시스템 테스트 도구이자, 그 도구로 데이터베이스를 분석해 결과를 공개하는 프로젝트예요. 2013년 무렵부터 MongoDB, Cassandra, Redis, Elasticsearch, etcd, CockroachDB, TiDB, PostgreSQL, MySQL 같은 수많은 시스템을 분석했고, 상당수에서 문서에 적힌 보장과 실제 동작이 다른 문제를 찾아냈어요. PostgreSQL처럼 성숙한 DB에서도 직렬성 격리 수준 버그를 발견한 적이 있을 정도예요. 그래서 개발자들 사이에서 Jepsen 분석 결과는 일종의 신뢰 지표처럼 여겨져요.
어떻게 테스트하나
방식은 단순하지만 집요해요. 크게 세 단계예요.
1) 부하 걸기: 여러 클라이언트가 동시에 읽기, 쓰기, 트랜잭션을 마구 보내요. 각 작업이 언제 시작해서 언제 끝났는지, 결과가 뭐였는지 전부 기록하는데, 이 기록을 히스토리라고 불러요.
2) 장애 주입: 테스트 중에 '네메시스(nemesis)'라는 장애 유발기가 네트워크를 쪼개거나(파티션), 프로세스를 죽이거나, 시계를 틀어지게 하거나, 노드를 일시 정지시켜요. 운영 환경에서 실제로 일어날 법한 나쁜 상황을 일부러 만드는 거예요.
3) 검증: 기록된 히스토리가 그 DB가 약속한 일관성 모델로 설명되는지 검사해요. 트랜잭션 분석에는 주로 Elle이라는 검사기를 쓰는데요, 트랜잭션 사이의 의존 관계를 그래프로 그린 다음 '있으면 안 되는 사이클'을 찾아요. 사이클이 있다면 트랜잭션을 어떤 순서로 줄 세워도 그 결과를 설명할 수 없다는 뜻이고, 곧 약속 위반이에요.
보고서 용어, 쉽게 풀어볼게요
Jepsen 보고서에는 낯선 약어가 많아서 처음엔 겁먹기 쉬운데요, 자주 나오는 것만 알아도 훨씬 편해요.
- Lost update(갱신 손실): 두 트랜잭션이 같은 값을 읽고 각자 고쳤는데 한쪽 수정이 사라지는 경우예요. 재고 10개에서 두 명이 동시에 1개씩 샀는데 재고가 9개로 남는 상황이죠.
- G1a(Aborted read): 롤백된 트랜잭션이 쓴 값을 다른 트랜잭션이 읽은 경우예요. 존재하지 않았어야 할 데이터를 본 거죠.
- G2-item(write skew 계열): 두 트랜잭션이 각자 조건을 확인하고 서로 다른 행을 고쳤는데, 합쳐보면 규칙이 깨지는 경우예요. 당직 의사가 최소 한 명은 있어야 하는데 두 명이 동시에 '다른 사람 있네' 하고 둘 다 퇴근해버리는 게 고전적인 예시예요.
- Stale read(오래된 읽기): 이미 커밋된 최신 값 대신 과거 값을 읽는 경우예요.
ParticleDB 보고서는 이렇게 읽어보세요
ParticleDB 1.1.4에서 어떤 이상 현상이 발견됐는지, 어떤 장애 조건에서 재현됐는지, 개발팀이 어떻게 대응했는지는 원문에 자세히 정리돼 있어요. 읽을 때는 이 순서를 추천해요. 먼저 요약(Summary)에서 핵심 발견을 확인하고, 다음으로 각 문제가 어떤 장애 조건에서 생겼는지 보세요. 장애 주입 없이도 생기는 문제라면 훨씬 심각하거든요. 마지막으로 이후 버전에서 고쳐졌는지, 문서가 바뀌었는지 확인하면 돼요. Jepsen 분석은 개발사와 협업해서 진행되는 경우가 많고, 보고서 끝부분에 수정 현황이 정리되곤 해요.
업계 맥락: 검증은 이제 기본값
분산 DB 시장이 커지면서 '우리 DB는 일관성을 보장한다'는 마케팅 문구는 넘쳐나요. 그래서 독립적인 검증의 가치가 점점 커지고 있죠. Jepsen 분석을 직접 의뢰해서 결과를 공개하는 회사도 있고, FoundationDB처럼 결정론적 시뮬레이션 테스트로 내부 검증 체계를 갖춘 곳도 있어요. 최근엔 Antithesis 같은 결정론적 시뮬레이션 테스트 플랫폼도 나왔고요. 신생 DB일수록 이런 공개 검증을 거치는 게 신뢰를 얻는 가장 빠른 길이에요.
한국 개발자에게 주는 시사점
DB를 고를 때 벤치마크 성능표만 보지 말고, 그 DB의 Jepsen 보고서가 있는지 꼭 찾아보세요. 결제, 재고, 포인트처럼 돈과 직결된 도메인이라면 더더욱이요. 보고서를 읽다 보면 '우리가 쓰는 DB의 기본 격리 수준이 생각보다 약하다'는 걸 깨닫게 될 수도 있어요. PostgreSQL이나 MySQL만 해도 기본 격리 수준이 직렬성이 아니거든요.
Jepsen은 오픈소스라 Clojure로 직접 테스트를 짜볼 수도 있어요. 진입장벽은 좀 있지만, 보고서 몇 편을 정독하는 것만으로도 분산 시스템과 트랜잭션을 보는 눈이 확 달라질 거예요.
마무리
한 줄 정리: DB의 일관성 보장은 문서가 아니라 검증 결과로 믿어야 하고, Jepsen 보고서는 그 검증을 배우기 좋은 교과서예요.
여러분이 쓰는 DB의 격리 수준, 정확히 알고 계신가요? 실무에서 동시성 이상 현상 때문에 고생했던 경험이 있다면 공유해주세요!
🔗 출처: Hacker News