Serializable과 Snapshot, 분산 환경에서 무엇을 다르게 맞추나?
Serializable은 읽기까지 조정 범위에 넣어 모든 트랜잭션을 하나의 순서로 직렬화하고, Snapshot 계열은 쓰기 충돌만 조정 대상으로 삼아 읽기는 과거 시점 스냅샷에서 자유롭게 처리한다. 이 차이가 곧 지연 꼬리와 abort rate의 차이로 이어진다. 결론부터 말하면, 읽기 비중이 높은 워크로드일수록 두 격리 수준의 격차가 커지고, 구현 방식(스케줄링·읽기 승격)에 따라 그 격차는 상당 부분 좁혀질 수 있다.
이 글은 분산 데이터베이스 계층에서 Serializable과 Snapshot Isolation(및 그 변형인 Repeatable Read, Serializable Snapshot Isolation)이 내부적으로 무엇을 조정하는지, 그리고 그 조정 비용이 실측 지연·처리량에 어떻게 나타나는지까지만 다룬다. 특정 벤더의 가격 구조나 도입 의사결정 프로세스는 다루지 않는다.
핵심 정리
- Serializable은 읽기까지 조정 범위에 포함되어 읽기 중심 워크로드에서 충돌 비용이 커지고, Snapshot 계열은 주로 쓰기 충돌에 비용이 집중된다출처.
- 8-16 shards, 64-128 concurrent clients 조건에서 Serializable의 99퍼센타일 읽기 지연은 약 42ms, Read Committed는 9.2ms로 보고됐다(2차 참고 자료).
- Snapshot Isolation은 write skew 같은 이상현상을 허용할 수 있고, SSI는 이를 런타임에서 탐지해 막는 방식으로 절충한다출처.
- 혼합 격리 + 읽기 승격, 혹은 TxnSails류 스케줄링 최적화는 SmallBank/TPC-C/YCSB+T 조건에서 Serializable의 성능 손실을 상당 부분 회수한다출처.
- 격리 수준을 낮출수록 애플리케이션이 의미 보존 책임을 더 많이 떠안는다.
Serializable은 내부에서 어떻게 충돌을 잡아내나?
Serializable은 읽은 데이터와 쓴 데이터 모두를 충돌 검사 대상에 넣어, 트랜잭션 집합 전체가 어떤 순차 실행과 동일한 결과를 내도록 강제한다. AWS re:Invent 2025 세션 요약은 이를 "serializability coordination scales with reads"로 요약한다. 즉 읽기 트랜잭션도 다른 트랜잭션과의 충돌 그래프에 포함되므로, 읽기 비율이 높아질수록 조정 대상이 함께 늘어난다출처. 같은 요약은 PostgreSQL에서 충돌이 늘어날수록 serializable의 처리량이 크게 떨어지는 사례를 든다. 이는 낙관적 동시성 제어 방식(SSI)의 특성과 맞닿아 있다. SSI는 트랜잭션을 실행 시점에는 스냅샷 기준으로 보내되, 커밋 직전에 "위험한 구조(rw-antidependency 사이클)"가 있었는지를 런타임에서 확인해 하나를 abort시킨다. 검사 자체가 커밋 경로에 추가되므로, 경합이 심한 구간에서는 abort와 재시도가 함께 늘어난다. 2025년 벤치마크 소개 자료는 피크 구간에서 Serializable의 abort rate가 SI 기반 구성보다 1.7-2.3배 높고, 재시도로 평균 지연이 12-28% 증가했다고 적는다(2차 참고 자료, ccsit2025.org).
Snapshot Isolation은 왜 쓰기 충돌만 신경 쓰나?
Snapshot Isolation은 트랜잭션 시작 시점의 일관된 스냅샷을 읽기 전용으로 고정하고, 쓰기끼리의 충돌(같은 로우를 동시에 갱신하는 경우)만 검사한다. 읽기는 스냅샷에서 이미 확정된 데이터를 가져오므로 다른 트랜잭션의 진행 상황과 조정할 필요가 없다. AWS 세션 요약이 정리한 대로 "snapshot coordination only scales with writes"이며, 이것이 읽기 중심 워크로드에서 SI 계열이 유리한 이유다출처. Google Cloud Spanner 문서도 repeatable read가 강한 스냅샷(strong snapshot)을 제공하면서 더 엄격한 serializable의 성능 영향을 피한다고 설명한다출처. 다만 이 절충에는 대가가 있다. SI는 write skew라 불리는 이상현상을 막지 못한다 — 두 트랜잭션이 서로 다른 로우를 각자의 스냅샷 기준으로 읽고 갱신하면, 개별로는 충돌이 없어 보이지만 합쳐서 보면 불변식이 깨질 수 있다. arXiv 계열 자료는 SI가 committed execution 집합이 serializability보다 넓은 더 느슨한 성질이라는 점을 재확인한다출처. 이 여유분을 어떻게 다룰지는 격리 수준이 아니라 애플리케이션 설계의 몫이 된다.
혼합 격리와 읽기 승격은 격차를 얼마나 좁히나?
읽기 승격(read promotion)과 혼합 격리를 결합하면 SmallBank류 워크로드에서 안전하지 않은 기본 Read Committed와 비슷한 처리량을 유지하면서도 serializable 실행을 달성할 수 있다는 결과가 PVLDB 2025에 보고됐다출처. 이 접근은 모든 트랜잭션을 균일하게 가장 강한 격리 수준으로 묶는 대신, 충돌 위험이 있는 일부 읽기만 선택적으로 "승격"시켜 검사 비용을 국소화한다. 같은 방향에서 TxnSails 논문은 SmallBank, TPC-C, YCSB+T 세 벤치마크에서 스케줄링·검사 전략을 재설계해 최대 26.7배 성능 향상, PostgreSQL의 SER 대비 최대 4.8배 성능 향상을 보고한다출처. 이 결과가 주는 메시지는 명확하다 — serializability 자체가 근본적으로 느린 것이 아니라, 스케줄링 전략과 충돌 패턴에 따라 실제 처리량이 크게 갈린다는 것이다. 다만 이 수치들은 특정 벤치마크 조건에서 재현된 결과이므로, 다른 충돌 밀도나 트랜잭션 크기 분포에서 동일한 배율이 나온다고 단정하기는 어렵다.
실측 수치는 어떤 조건에서 나왔나?
2025년 소개된 벤치마크는 8-16 shards, 64-128 concurrent clients 조건의 분산 스토어에서 Read Committed의 읽기 지연 중앙값 1.8ms, 99퍼센타일 9.2ms를 보고했고, Serializable은 99퍼센타일이 약 42ms까지 올라갔다고 적는다(ccsit2025.org 소개 자료). 같은 자료는 3개 클라우드 제공자에 걸친 cross-region 배포에서 Serializable이 Read Committed보다 평균 1.8배 높은 end-to-end latency를 보였고, 경합이 가장 심한 경우 99퍼센타일 지연이 120ms를 넘었다고 밝힌다출처. 이 자료는 학회지 원문이 아니라 소개 페이지 형태이므로 검증용 2차 참고로 다루는 것이 적절하다. 반면 PVLDB 2025의 읽기 승격 논문과 TxnSails 논문은 SmallBank, TPC-C, YCSB+T라는 명시된 벤치마크 조건에서 실험 코드를 공개하며 재현 가능한 형태로 결과를 제시한다. 2026년 기준으로 이 계열 결과를 인용할 때는 "어떤 shard 수, 어떤 동시성, 어떤 벤치마크였는가"를 함께 붙이는 것이 수치의 재사용성을 지킨다.
무엇을 얻고 무엇을 잃는가?
Serializable을 선택하면 애플리케이션 코드에서 write skew 같은 이상현상을 직접 방어할 필요가 없어진다 — 정합성 검증 책임이 데이터베이스 내부로 넘어간다. 그 대가는 읽기까지 조정 범위에 들어가면서 생기는 지연 꼬리와 abort/재시도 비용이다. 앞서 인용한 자료 기준으로 피크 구간 abort rate가 SI 대비 1.7-2.3배, cross-region 99퍼센타일 지연이 120ms를 넘는 사례가 관측됐다. 반대로 Snapshot Isolation을 선택하면 쓰기 충돌만 조정하므로 읽기 중심 워크로드에서 지연이 크게 줄지만, write skew급 이상현상이 발생했을 때 이를 막을 책임이 애플리케이션 쪽 잠금 설계나 명시적 제약 조건으로 넘어간다. 즉 이 트레이드오프는 "지연 비용을 데이터베이스가 지느냐, 정합성 검증 복잡도를 애플리케이션이 지느냐"의 문제로 요약된다. 혼합 격리·읽기 승격 같은 최적화는 이 축의 양쪽을 동시에 완화하려는 시도이지만, 특정 벤치마크 조건 밖에서도 동일하게 작동한다는 보장은 아직 일반화되지 않았다.
언제 Serializable을 쓰고 언제 Snapshot으로 충분한가?
읽기 비중이 높고 write skew류 이상현상이 비즈니스 로직에서 자연히 배제되는 워크로드(예: 단일 로우 중심의 카운터 갱신, append-only 로그)라면 Snapshot Isolation 계열로도 충분한 경우가 많다. 반대로 여러 로우에 걸친 불변식(잔고 합계, 재고-주문 정합성 등)을 데이터베이스 계층에서 보장해야 하고, 애플리케이션 쪽에서 별도의 검증 로직을 추가하기 어려운 상황이라면 Serializable, 혹은 SSI 계열이 안전판 역할을 한다. Google Cloud Spanner처럼 전역 분산 환경에서 강한 스냅샷을 기본으로 제공하는 구성은 이 절충의 한 형태로 볼 수 있다 — serializable 수준의 정확성을 목표로 하되 조정 비용을 스냅샷 방식으로 낮춘다출처. 충돌 밀도가 낮은 워크로드에서는 두 격리 수준의 실측 차이 자체가 작아질 수 있으므로, 격리 수준을 정하기 전에 실제 충돌 패턴을 측정하는 편이 이론적 격리 등급만 보고 결정하는 것보다 신뢰할 만하다.
자주 묻는 질문
Serializable Snapshot Isolation(SSI)은 두 격리 수준의 절충안인가?
SSI는 실행 경로에서는 스냅샷 기반으로 동작하되, 커밋 직전 런타임 검사로 write skew급 위험 구조를 탐지해 차단하는 방식이다. 즉 SI의 낮은 조정 비용과 Serializable의 정확성 보장을 결합하려는 시도이며, 검사 비용은 커밋 경로에 추가로 붙는다출처.
읽기 승격 전략은 모든 데이터베이스에 적용 가능한가?
현재 보고된 결과는 SmallBank, TPC-C, YCSB+T 같은 명시된 벤치마크 조건에서 재현된 것이며, 이 전략이 요구하는 충돌 추적 구조를 기존 엔진에 이식하는 난이도는 벤치마크 논문 범위 밖의 문제다. 도입 전에는 대상 워크로드의 충돌 밀도와 트랜잭션 구조가 실험 조건과 얼마나 유사한지 확인이 필요하다.
abort rate가 높아지면 어떤 지표를 먼저 봐야 하나?
평균 지연보다 99퍼센타일 지연과 재시도로 인한 지연 증가폭을 함께 봐야 한다. 인용한 벤치마크에서도 재시도로 평균 지연이 12-28% 증가한 것으로 나타나, abort rate 자체보다 재시도가 누적되는 구간의 꼬리 지연이 실질적인 병목으로 이어졌다.
cross-region 배포에서는 격리 수준 선택이 더 민감해지나?
그렇다. 인용한 자료에서 cross-region 조건의 Serializable 99퍼센타일 지연이 120ms를 넘은 사례가 나온 것처럼, 물리적 거리가 늘어날수록 조정 범위가 넓은 격리 수준의 지연 꼬리가 더 크게 벌어진다. 리전 간 배포에서는 격리 수준과 별개로 조정이 필요한 노드 수 자체를 줄이는 설계도 함께 고려할 필요가 있다.
더 알아보기
분산 일관성과 합의: 시스템 설계의 기본 축 — 이 주제의 종합 가이드