긴 조회와 갱신이 동시에 실행되는 DB에서 MVCC를 사용합니다. 읽는 데이터의 시점은 어떻게 정해지며, 읽기와 쓰기의 대기나 유지 비용이 모두 사라지나요?

MVCC는 한 행의 현재 값만 덮어쓰는 대신 여러 버전과 각 버전의 가시성 정보를 유지해, 읽는 트랜잭션이 자신의 스냅샷에 보이는 버전을 선택하게 하는 방식입니다. 그래서 일반적인 읽기와 쓰기가 같은 행의 현재 값을 두고 오래 기다리는 일을 줄일 수 있지만, 모든 잠금과 충돌이 사라지는 것은 아닙니다. 쓰기끼리의 충돌, 스키마 변경, 인덱스·페이지 작업, 버전 저장과 정리 비용은 남습니다.

스냅샷의 시점을 계약으로 정합니다

오래 실행되는 보고서 중 주문이 계속 수정되는 상황에서 스냅샷 읽기는 보고서 안의 여러 조회가 서로 다른 시점의 데이터를 섞는 문제를 줄일 수 있습니다. 그러나 문장 시작 시점의 스냅샷인지 트랜잭션 시작 시점의 스냅샷인지는 DBMS와 격리 설정에 따라 다릅니다. PostgreSQL의 MVCC 격리, SQL Server의 RCSI와 SNAPSHOT, MySQL/InnoDB의 일관된 읽기는 이름과 세부 보장이 같지 않습니다. 같은 트랜잭션에서 두 번 읽어야 하는지, 자기 변경을 어떻게 보아야 하는지 실제 설정으로 실험하겠습니다.

스냅샷은 ‘그 순간의 모든 테이블을 물리적으로 복사했다’는 뜻도 아닙니다. 읽기는 트랜잭션 ID나 타임스탬프 조건으로 가시 버전을 선택하며, 쓰기 커밋과 읽기 가시성은 별도의 규칙을 가질 수 있습니다. 스냅샷 격리에서도 두 트랜잭션이 서로 다른 행을 읽고 각각 바꾸면 애플리케이션 불변식이 깨지는 쓰기 편향이 생길 수 있습니다. 마지막 좌석 수량처럼 전역 조건이 필요하면 조건부 UPDATE, 명시적 잠금, 더 강한 직렬화 또는 제약을 검토해야 합니다.

버전 유지 비용을 운영 지표로 봅니다

긴 읽기 트랜잭션이 오래된 버전을 계속 필요로 하면 정리 작업이 그 버전을 지우지 못하고 버전 저장소·테이블 공간·로그가 커질 수 있습니다. PostgreSQL에서는 오래된 트랜잭션이 vacuum 정리를 지연시킬 수 있고, SQL Server의 row version store와 MySQL의 undo 보존도 각각 다른 지표와 한계를 가집니다. 따라서 ‘읽기 전용이므로 비용이 없다’고 하지 않고 가장 오래된 트랜잭션, 버전 공간, 정리 지연, 임시 파일·I/O를 함께 관찰하겠습니다.

일관된 전체 보고서가 꼭 필요하면 짧은 데이터 추출 후 별도 분석 저장소나 기준 시각을 사용하고, 필요하지 않으면 페이지·기간 단위로 트랜잭션을 나누겠습니다. 격리 수준을 올리는 것도 무료가 아니며 충돌과 재시도 비용을 키울 수 있습니다. 검증에서는 두 세션의 읽기·쓰기 순서를 통제해 문장·트랜잭션 스냅샷, write skew, 장기 트랜잭션 정리 지연을 각각 재현합니다. MVCC는 락을 없애는 마법이 아니라 읽기 일관성과 동시성을 버전 관리 비용과 교환하는 선택입니다.

읽기와 쓰기의 충돌을 줄이는 것이 곧 업무 규칙의 직렬 실행을 뜻하지도 않습니다. 재고 총량, 계정 잔액, 좌석 수처럼 여러 행의 관계가 규칙이라면 한 행 버전만 읽는 것으로 충분하지 않을 수 있습니다. 조건부 UPDATE의 영향 행 수를 확인하거나 명시적 잠금·직렬화된 처리 단위를 사용하고, 충돌 시 재시도 횟수와 사용자 오류를 제한하겠습니다. 이 판단은 격리 수준 이름보다 실제 변경 순서를 재현해 결정합니다.