MVCC와 락 기반의 차이를 이해하는 데서 그치는지, 아니면 두 방식이 한 엔진 안에서 어떻게 섞여 쓰이는지까지 실무 감각으로 풀 수 있는지를 가른다.
MVCC는 한 데이터의 여러 버전을 동시에 유지해 "읽기는 쓰기를 막지 않는다"는 스냅샷 일관성을 제공한다. 락 기반은 공유/배타 락으로 같은 자원에 접근하는 트랜잭션을 직렬화해 정합성을 보장하지만 경합과 데드락이 따라온다. 실제 엔진은 둘을 섞어 쓴다 — InnoDB·PostgreSQL은 기본을 MVCC로 두면서 갱신 충돌·범위 잠금이 필요한 구간엔 락을 함께 쓴다. 즉 "무엇을 골랐는가"가 아니라 "어디서 무엇을 섞었는가"가 운영 관점에서 더 중요하다.
lock wait timeout이나 데드락 로그를 추적해 본 경험이 있다면 "역순 락 획득" 같은 구체적 원인 패턴으로 풀어낼 수 있다
SELECT FOR UPDATE를 도입해 동시 갱신 사고를 막은 경험이 있다면 MVCC 위에 락을 얹는 사례로 보여 줄 수 있다
긴 트랜잭션이 vacuum/undo 부담을 키운 경험이 있다면 MVCC의 비용을 운영 지표로 풀어낼 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.