MVCC는 읽기와 쓰기 동시성을 어떻게 개선하나요?

MVCC(Multi-Version Concurrency Control)는 데이터를 수정할 때 기존 row를 즉시 덮어쓰지 않고 여러 버전을 관리하여 읽기와 쓰기의 충돌을 줄이는 방식입니다. 읽는 트랜잭션은 자신이 볼 수 있는 시점의 스냅샷을 보고, 쓰는 트랜잭션은 새 버전을 만듭니다.

기본 아이디어

row id=1 balance=100  (version A, committed)
T2 UPDATE balance=80  -> version B 생성
T1은 시작 시점 snapshot 기준 version A를 계속 읽음
T2 COMMIT 후 새 트랜잭션은 version B를 읽음

읽기가 쓰기를 막지 않고, 쓰기가 읽기를 막지 않는 경우가 많아 동시성이 좋아집니다.

장점

• 긴 조회가 짧은 update를 불필요하게 막지 않습니다.
• 일관된 스냅샷을 제공해 리포트 쿼리가 중간 변경을 섞어 보지 않습니다.
• lock 기반 구현보다 읽기 중심 워크로드에서 확장성이 좋습니다.

비용과 부작용

MVCC는 오래된 버전을 보관해야 하므로 청소가 필요합니다. PostgreSQL의 vacuum, MySQL InnoDB의 undo log purge가 대표적입니다. 긴 트랜잭션이 오래 열려 있으면 오래된 버전을 지우지 못해 테이블/undo log가 커질 수 있습니다.

-- 실수 예: 트랜잭션을 열어둔 채 사용자 입력 대기
BEGIN;
SELECT * FROM reports WHERE ...;
-- 몇 분 동안 방치
COMMIT;

충돌은 완전히 사라지지 않습니다

같은 row를 동시에 수정하면 여전히 write-write conflict가 발생합니다. 또한 snapshot isolation에서는 write skew 같은 문제가 생길 수 있어, 필요한 경우 explicit lock이나 serializable isolation을 사용해야 합니다.

실무 체크

• 트랜잭션을 짧게 유지합니다.
• 배치 조회는 커서/페이지 크기를 조절하고 idle in transaction을 감시합니다.
• vacuum/purge 지표, dead tuple, undo log 증가를 모니터링합니다.
• 정합성이 중요한 갱신에는 SELECT ... FOR UPDATE, optimistic lock, unique constraint를 함께 사용합니다.

면접 답변 포인트

MVCC는 여러 버전의 row를 유지해 읽기 작업이 쓰기 lock을 기다리지 않도록 하는 동시성 제어입니다. 성능상 이점이 있지만 오래된 버전 관리 비용과 긴 트랜잭션 문제가 있으므로 운영 관점까지 언급하면 좋습니다.