Snapshot Isolation이란?
Snapshot Isolation(스냅샷 격리)은 트랜잭션이 시작되는 시점의 데이터베이스 상태를 하나의 ‘스냅샷’처럼 고정해두고, 그 스냅샷을 기준으로 모든 읽기 작업을 수행하는 격리 수준입니다. 트랜잭션이 진행되는 동안 다른 트랜잭션이 데이터를 변경해도, 내가 보는 데이터는 처음 시작할 때 찍어둔 사진처럼 변하지 않습니다. 그래서 이름 그대로 ‘스냅샷’이라는 표현을 씁니다.
도서관에서 책을 대출하기 전에 서가 상태를 사진으로 찍어두고, 그 사진만 보면서 어떤 책이 있는지 확인한다고 생각하면 이해가 쉽습니다. 사진을 찍은 이후 다른 사람이 책을 빌려가거나 반납해도 내가 보는 사진 속 서가는 그대로입니다.
동작 원리와 예시
Snapshot Isolation은 보통 MVCC(Multi-Version Concurrency Control)라는 메커니즘으로 구현됩니다. 데이터를 수정할 때 기존 값을 덮어쓰지 않고 새로운 버전으로 저장해두는 방식입니다. 각 트랜잭션은 시작 시점의 트랜잭션 ID(또는 타임스탬프)를 기준으로 자신이 볼 수 있는 버전만 읽습니다.
예를 들어 트랜잭션 A가 SELECT * FROM accounts WHERE id = 1을 실행해 잔액 1000원을 읽었다고 합시다. 이후 트랜잭션 B가 같은 행을 500원으로 변경하고 커밋해도, A가 다시 같은 쿼리를 실행하면 여전히 1000원이 조회됩니다. A 입장에서는 트랜잭션이 끝날 때까지 일관된 스냅샷을 보장받는 것입니다.
다만 두 트랜잭션이 같은 데이터를 동시에 수정하려고 하면 ‘쓰기 충돌(write-write conflict)’이 발생할 수 있습니다. 이 경우 먼저 커밋한 트랜잭션은 성공하지만, 나중에 커밋하려는 트랜잭션은 실패 처리되어 재시도해야 합니다. PostgreSQL의 REPEATABLE READ가 대표적인 Snapshot Isolation 구현체입니다.
실무에서 왜 쓰는가
Snapshot Isolation의 가장 큰 장점은 읽기 작업이 쓰기 작업을 기다리지 않는다는 점입니다. 읽는 쪽은 락을 걸지 않고 과거 버전을 참조하기 때문에, 읽기와 쓰기가 서로 블로킹되지 않아 동시성 처리 성능이 크게 향상됩니다.
- 정합성이 중요한 정산, 결제 시스템에서 일관된 조회 결과 보장
- 긴 리포트성 쿼리가 실행 중인 테이블에 대한 쓰기 작업 지연 방지
- PostgreSQL, Oracle, SQL Server 등 주요 DBMS에서 폭넓게 지원
다만 완벽한 직렬화(Serializable) 수준의 격리는 아니기 때문에, 서로 다른 행을 각각 수정하지만 비즈니스 로직상 충돌이 발생하는 ‘쓰기 스큐(write skew)’ 현상은 여전히 주의해야 합니다. 격리 수준을 선택할 때는 성능과 정합성 사이의 트레이드오프를 항상 고려해야 합니다.