공통 목표

결과는 순차 실행처럼 보장하되, 충돌을 드러내는 타이밍은 DBMS마다 다릅니다

SERIALIZABLE은 가장 강한 정합성을 보장합니다. 차이는 읽는 순간부터 먼저 막는지, 아니면 스냅샷으로 진행한 뒤 나중에 실패시키는지에 있습니다.

이 그림에서 봐야 할 것

세 DBMS 모두 목표는 같지만, MySQL은 실행 중 대기, PostgreSQL과 Oracle은 나중에 오류 쪽으로 충돌을 보여 줍니다.

비교 축 무엇으로 보장하고, 운영에서 어떤 비용으로 체감되는지

MySQL 락 기반

PostgreSQL SSI 검증

Oracle 스냅샷 + 충돌 감지

무엇으로 보장?

읽기부터 공유 락

일반 SELECT도 공유 락처럼 동작해 뒤따르는 쓰기를 미리 막습니다.

직렬화 위반 가능성 추적

SSI로 읽기-쓰기 관계를 추적하고, 실제 직렬화가 깨질 때만 실패시킵니다.

SCN 스냅샷 유지

읽기는 일관된 스냅샷으로 진행하고, 충돌은 쓰기 시점에 오류로 드러냅니다.

충돌은 언제 보이나?

실행 중 바로 대기

공유 락 때문에 다른 트랜잭션의 쓰기가 즉시 막혀, 충돌이 대기로 먼저 보입니다.

커밋 순간 실패

끝까지 진행한 뒤 커밋 시점에 serialization failure가 발생할 수 있습니다.

쓰기 충돌에서 오류

경쟁 쓰기가 겹치면 ORA-08177이 발생해 재시도나 잠금 전략이 필요합니다.

운영에서 느끼는 비용

동시성이 먼저 줄어듦

충돌을 빨리 차단하는 대신 읽기까지 잠금에 묶여 가장 보수적으로 동작합니다.

재시도 로직이 핵심

평소 읽기 차단은 적지만, 커밋 실패가 생기면 애플리케이션이 재시도해야 합니다.

실무에선 조합 선택

직렬화 가능은 하지만, 운영에서는 더 낮은 격리 수준과 명시적 잠금을 섞어 쓰는 경우가 많습니다.