Pessimistic Lock (비관적 락)

1. 개요

웹 애플리케이션에서 다수의 사용자가 동시에 동일한 데이터(예: 수강권 잔여 횟수, 상품 재고, 좌석 예약)를 수정하려고 할 때, 갱신 손실(Lost Update) 문제가 발생할 수 있습니다. 이러한 동시성 문제를 데이터베이스 레벨에서 강력하게 제어하는 방법 중 하나가 바로 **비관적 락(Pessimistic Lock)**입니다.

---

2. 비관적 락(Pessimistic Lock)이란?

이름에서 알 수 있듯이, 비관적 락은 **“트랜잭션 간에 반드시 충돌이 발생할 것이다”**라고 비관적으로 가정하고 데이터를 읽는 순간부터 DB 자체의 락을 걸어버리는 방식입니다.

RDBMS의 SELECT ... FOR UPDATE 쿼리를 활용하여 **배타 락(Exclusive Lock, X-Lock)**을 획득합니다. 락이 걸린 레코드는 락을 획득한 트랜잭션이 커밋(Commit)되거나 롤백(Rollback)될 때까지 다른 트랜잭션이 수정할 수 없으며, 심지어 다른 트랜잭션이 해당 레코드에 대해 비관적 락을 획득하려고 하면 락이 풀릴 때까지 **대기(Blocking)**하게 됩니다.

2-1. 낙관적 락(Optimistic Lock)과의 차이

• 낙관적 락: “충돌이 거의 발생하지 않을 것”이라 가정하고 락을 걸지 않습니다. 대신 @Version 컬럼 등을 두어 커밋 시점에 버전이 일치하는지 확인합니다. 충돌이 잦으면 롤백과 재시도 비용이 커집니다.
• 비관적 락: 충돌이 잦을 것으로 예상될 때 사용합니다. 무조건 락을 걸기 때문에 데이터 정합성은 완벽히 보장되나 대기 시간으로 인해 성능 저하가 발생할 수 있습니다.

---

3. 동작 방식 시나리오

콘서트 티켓 예매나 센터 스케줄 예약을 생각해보겠습니다. 잔여 좌석이 1개 남았을 때 사용자 A와 B가 동시에 예약을 시도합니다.

sequenceDiagram
    participant TxA as 트랜잭션 A
    participant TxB as 트랜잭션 B
    participant DB as Database (잔여: 1)

    TxA->>DB: SELECT FOR UPDATE (잔여: 1 읽음, 락 획득)
    TxB->>DB: SELECT FOR UPDATE (TxA가 락을 해제할 때까지 대기 ⏳)
    Note over TxA: 잔여 = 잔여 - 1 (0으로 연산)
    TxA->>DB: UPDATE 잔여 = 0
    TxA->>DB: COMMIT (락 해제)
    
    Note over TxB: 대기 해제 및 최신 상태(잔여: 0) 읽음
    TxB->>DB: 락 획득
    Note over TxB: 잔여 좌석이 0이므로 비즈니스 예외 발생 (예약 실패)
    TxB->>DB: ROLLBACK

비관적 락 덕분에 동시에 접근하더라도 순차적으로(직렬화되어) 처리되므로, 초과 예약이라는 치명적인 버그를 완벽하게 차단할 수 있습니다.

---

4. Spring Data JPA에서의 활용

Spring Data JPA에서는 @Lock 어노테이션을 사용하여 매우 쉽게 비관적 락을 적용할 수 있습니다.

import jakarta.persistence.LockModeType;
import org.springframework.data.jpa.repository.Lock;
import org.springframework.data.jpa.repository.Query;
 
public interface TicketRepository extends JpaRepository<TicketEntity, Long> {
 
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT t FROM TicketEntity t WHERE t.uuid = :uuid")
    Optional<TicketEntity> findByUuidWithPessimisticLock(@Param("uuid") String uuid);
}

• PESSIMISTIC_WRITE: 배타 락(Exclusive Lock)을 겁니다. 다른 트랜잭션에서 읽기/쓰기 모두 대기합니다. (일반적으로 동시성 제어에 가장 많이 사용됨)
• PESSIMISTIC_READ: 공유 락(Shared Lock)을 겁니다. 다른 트랜잭션에서 읽을 수는 있지만 쓸 수는 없습니다. (DB 방언에 따라 동작이 조금 다를 수 있음)

주의사항

비관적 락은 데이터를 확실하게 보호하지만, 남용하면 병목 현상이 생겨 시스템 처리량(Throughput)이 크게 떨어지고 **데드락(Deadlock)**의 원인이 될 수 있습니다. 따라서 락을 잡는 트랜잭션의 크기를 최대한 작게 유지하고, 여러 테이블에 락을 걸어야 할 때는 반드시 일관된 락 획득 순서를 유지하여 데드락을 예방해야 합니다.

---