공통 전제

같은 행을 동시에 바꾸려 할 때 충돌을 언제 처리할까?

두 방식 모두 정합성은 지키지만, 충돌을 미리 막을지 아니면 마지막 쓰기 순간에 검출할지 에서 차이가 납니다.

공유 데이터 products.id = 1

동시 요청 Tx A · Tx B

낙관적 먼저 읽고, 저장할 때 버전을 확인

읽는 동안 잠금을 오래 잡지 않습니다.

비관적 먼저 잠그고, 끝날 때까지 순서를 강제

충돌 가능성이 높다고 보고 대기를 허용합니다.

충돌 처리

UPDATE ... WHERE version = 5

커밋 직전 검사

버전이 바뀌었으면 반영하지 않고 재시도합니다.

SELECT ... FOR UPDATE

작업 시작 전에 차단

같은 행에 접근한 다른 트랜잭션은 잠금 해제까지 대기합니다.

다른 Tx

읽기와 작업 준비는 계속 가능

마지막 저장 순간에만 충돌 여부가 드러납니다.

즉시 끼어들지 못함

정합성은 단순하지만, 대기열이 길어지면 처리량이 떨어집니다.

잘 맞는 상황

충돌이 드문 수정

게시글 수정, 설정 변경처럼 대부분 바로 성공하는 흐름.

충돌이 잦은 갱신

재고 차감, 계좌 잔액 변경처럼 같은 행을 자주 건드리는 흐름.

비용

실패 후 재시도 로직 필요

대기 시간은 적지만, 충돌 순간에는 사용자나 서비스가 다시 처리해야 합니다.

동시성 저하와 데드락 위험

실패를 줄이는 대신, 잠금 시간이 길면 전체 흐름이 막힐 수 있습니다.

한 줄 판단

충돌이 드물면 낙관적 으로 동시성을 살리고, 충돌이 자주 나면 비관적 으로 순서를 강제해 일관성을 단순하게 관리합니다.