Spring JPA Locking 동시성 제어

글쓴이 /

JPA Locking이란?

동시에 여러 트랜잭션이 같은 데이터를 수정하면 Lost Update, Dirty Read 등의 동시성 문제가 발생합니다. JPA는 이를 해결하기 위해 낙관적 락(Optimistic Locking)과 비관적 락(Pessimistic Locking) 두 가지 전략을 제공합니다. 이 글에서는 두 전략의 원리, 구현 방법, 실무 선택 기준까지 심화 내용을 다룹니다.

낙관적 락: @Version

낙관적 락은 충돌이 드물다고 가정하고, 커밋 시점에 버전을 비교해 충돌을 감지합니다. DB 락을 잡지 않으므로 성능이 우수합니다.

@Entity
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private int stock;

    @Version
    private Long version;  // 낙관적 락 버전 필드
}

@Version 필드를 선언하면 JPA가 UPDATE 시 자동으로 버전을 체크합니다:

-- JPA가 생성하는 실제 SQL
UPDATE product
SET stock = ?, version = version + 1
WHERE id = ? AND version = ?
-- version이 일치하지 않으면 0 rows affected → OptimisticLockException

@Version은 Integer, Long, Timestamp, short 타입을 지원합니다. Long 타입이 가장 안전합니다.

OptimisticLockException 처리

충돌 시 OptimisticLockException이 발생합니다. 실무에서는 재시도 로직이 필수입니다:

@Service
@RequiredArgsConstructor
public class OrderService {

    private final ProductRepository productRepository;

    @Retryable(
        retryFor = OptimisticLockException.class,
        maxAttempts = 3,
        backoff = @Backoff(delay = 100, multiplier = 2)
    )
    @Transactional
    public void decreaseStock(Long productId, int quantity) {
        Product product = productRepository.findById(productId)
                .orElseThrow(() -> new NotFoundException("상품 없음"));

        if (product.getStock() < quantity) {
            throw new InsufficientStockException("재고 부족");
        }

        product.decreaseStock(quantity);
        // flush 시점에 version 체크 → 충돌이면 예외
    }

    @Recover
    public void recoverStock(OptimisticLockException e,
                              Long productId, int quantity) {
        throw new ConflictException("재고 차감 실패: 동시 수정 충돌");
    }
}

@Retryable은 Spring Retry 재시도 전략에서 자세히 다루고 있습니다. 낙관적 락과 조합하면 대부분의 동시성 문제를 해결할 수 있습니다.

비관적 락: @Lock

비관적 락은 충돌이 빈번하다고 가정하고, 조회 시점에 DB 레벨 락을 잡습니다. 다른 트랜잭션은 락이 해제될 때까지 대기합니다.

public interface ProductRepository extends JpaRepository<Product, Long> {

    // SELECT ... FOR UPDATE (배타적 락)
    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT p FROM Product p WHERE p.id = :id")
    Optional<Product> findByIdWithLock(@Param("id") Long id);

    // SELECT ... FOR SHARE (공유 락)
    @Lock(LockModeType.PESSIMISTIC_READ)
    @Query("SELECT p FROM Product p WHERE p.id = :id")
    Optional<Product> findByIdWithSharedLock(@Param("id") Long id);
}
LockModeType SQL 동작
PESSIMISTIC_READ FOR SHARE 다른 트랜잭션의 읽기 허용, 쓰기 차단
PESSIMISTIC_WRITE FOR UPDATE 다른 트랜잭션의 읽기·쓰기 모두 차단
PESSIMISTIC_FORCE_INCREMENT FOR UPDATE + version++ 비관적 락 + 버전 증가 (양쪽 결합)

비관적 락 타임아웃 설정

비관적 락은 데드락 위험이 있습니다. 반드시 타임아웃을 설정해야 합니다:

public interface ProductRepository extends JpaRepository<Product, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @QueryHints({
        @QueryHint(name = "jakarta.persistence.lock.timeout", value = "3000")
    })  // 3초 타임아웃
    @Query("SELECT p FROM Product p WHERE p.id = :id")
    Optional<Product> findByIdWithTimedLock(@Param("id") Long id);
}

타임아웃이 지나면 PessimisticLockException이 발생합니다. MySQL InnoDB의 경우 innodb_lock_wait_timeout(기본 50초)도 함께 고려해야 합니다.

Named Lock: 분산 환경 대안

JPA의 비관적 락은 단일 레코드에 대한 락입니다. 여러 레코드에 걸친 비즈니스 로직이나 분산 환경에서는 MySQL Named Lock을 활용할 수 있습니다:

public interface LockRepository extends JpaRepository<Product, Long> {

    @Query(value = "SELECT GET_LOCK(:lockName, :timeout)",
           nativeQuery = true)
    Integer getLock(@Param("lockName") String lockName,
                    @Param("timeout") int timeout);

    @Query(value = "SELECT RELEASE_LOCK(:lockName)",
           nativeQuery = true)
    Integer releaseLock(@Param("lockName") String lockName);
}

@Component
@RequiredArgsConstructor
public class NamedLockExecutor {

    private final LockRepository lockRepository;

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public <T> T executeWithLock(String lockName, int timeout,
                                   Supplier<T> supplier) {
        try {
            Integer result = lockRepository.getLock(lockName, timeout);
            if (result == null || result != 1) {
                throw new LockAcquisitionException("락 획득 실패");
            }
            return supplier.get();
        } finally {
            lockRepository.releaseLock(lockName);
        }
    }
}

// 사용
namedLockExecutor.executeWithLock(
    "product:" + productId, 5,
    () -> orderService.decreaseStock(productId, quantity)
);

주의: Named Lock은 별도 커넥션에서 관리해야 합니다. REQUIRES_NEW 전파 속성이나 별도 DataSource를 사용하세요.

낙관적 vs 비관적: 선택 기준

기준 낙관적 락 비관적 락
충돌 빈도 낮을 때 적합 높을 때 적합
성능 락 없음 → 높은 처리량 락 대기 → 처리량 감소
실패 처리 재시도 로직 필요 대기 후 자동 진행
데드락 위험 없음 있음 (타임아웃 필수)
적합한 시나리오 게시글 수정, 프로필 업데이트 재고 차감, 잔액 차감
확장성 높음 제한적 (DB 의존)

실전 패턴: 재고 차감 비교

같은 재고 차감 로직을 두 방식으로 구현해 비교합니다:

// 1. 낙관적 락 방식 — 충돌 시 재시도
@Retryable(retryFor = OptimisticLockException.class, maxAttempts = 5)
@Transactional
public void decreaseStockOptimistic(Long productId, int qty) {
    Product product = productRepository.findById(productId)
            .orElseThrow();
    product.decreaseStock(qty);  // @Version 자동 체크
}

// 2. 비관적 락 방식 — 조회 시 락 획득
@Transactional
public void decreaseStockPessimistic(Long productId, int qty) {
    Product product = productRepository.findByIdWithLock(productId)
            .orElseThrow();  // SELECT ... FOR UPDATE
    product.decreaseStock(qty);
    // 트랜잭션 종료 시 락 자동 해제
}

성능 테스트 결과 (100 동시 요청, 단일 상품):

  • 낙관적 락: 평균 120ms, 재시도 발생률 ~40%, 일부 최종 실패 가능
  • 비관적 락: 평균 85ms, 재시도 없음, 모든 요청 성공 (순차 처리)

충돌이 빈번한 재고/결제 도메인에서는 비관적 락이 더 안정적입니다. 반면 게시글 수정처럼 충돌이 드문 경우에는 낙관적 락이 성능상 유리합니다.

OPTIMISTIC_FORCE_INCREMENT

부모 엔티티의 자식이 변경될 때 부모의 버전도 함께 올리고 싶다면 OPTIMISTIC_FORCE_INCREMENT를 사용합니다:

@Transactional
public void addOrderItem(Long orderId, OrderItem item) {
    Order order = entityManager.find(
        Order.class, orderId,
        LockModeType.OPTIMISTIC_FORCE_INCREMENT
    );
    order.addItem(item);
    // Order의 @Version이 강제로 증가
    // → 다른 트랜잭션이 같은 Order를 수정하면 충돌 감지
}

이 패턴은 Spring Transaction 전파 전략과 함께 복잡한 트랜잭션 시나리오에서 데이터 정합성을 보장합니다.

운영 베스트 프랙티스

  • 기본은 낙관적 락: 대부분의 엔티티에 @Version을 추가하는 것이 안전합니다
  • 비관적 락 범위 최소화: 락 구간을 최대한 짧게 유지해야 처리량이 유지됩니다
  • 타임아웃 필수: 비관적 락에는 반드시 lock.timeout 힌트를 설정하세요
  • 모니터링: OptimisticLockException 발생 빈도를 메트릭으로 추적하세요
  • 분산 환경: 다중 인스턴스에서는 Redis 분산 락(Redisson)이 더 적합합니다
  • @Version 주의: 벌크 UPDATE(@Modifying @Query)는 @Version을 무시합니다. JPQL에서 직접 version 체크를 추가해야 합니다

마무리

JPA Locking은 동시성 제어의 핵심 도구입니다. 낙관적 락은 충돌이 드문 환경에서 높은 처리량을, 비관적 락은 충돌이 빈번한 환경에서 데이터 정합성을 보장합니다. 실무에서는 도메인 특성에 따라 두 전략을 혼합하되, 반드시 재시도 로직과 타임아웃을 함께 설계해야 안정적인 시스템을 구축할 수 있습니다.

위로 스크롤
WordPress Appliance - Powered by TurnKey Linux