동시성 이슈 해결을 위한 JPA 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock) 실무 적용 가이드

수많은 사용자가 동시에 동일한 수량의 티켓을 예매하거나 재고를 주문할 때, 여러분의 데이터베이스는 안전합니까? 동시성 제어(Concurrency Control)는 대규모 트래픽을 처리하는 백엔드 아키텍처에서 데이터의 정합성을 보장하기 위해 반드시 해결해야 할 핵심 과제입니다. 이 글에서는 JPA(Java Persistence API) 환경에서 널리 쓰이는 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock)의 원리를 살펴보고, 어떤 상황에 어떤 방식을 적용해야 하는지 명확한 가이드를 제공합니다.

1. 동시성 문제와 데이터 무결성

다중 스레드 또는 분산 환경에서 여러 트랜잭션이 동일한 데이터에 동시에 접근하여 수정할 때 '두 번의 갱신 분실 문제(Lost Update Problem)'가 발생할 수 있습니다. 예를 들어, 재고가 1개 남은 상품을 두 명의 사용자가 동시에 구매하려고 할 때, 적절한 격리나 잠금 장치가 없다면 마이너스 재고가 되거나 데이터의 정합성이 깨지게 됩니다. 이를 방지하기 위한 두 가지 핵심 전략이 바로 낙관적 락과 비관적 락입니다.

2. 낙관적 락(Optimistic Lock): 데이터 충돌이 적을 때

낙관적 락은 말 그대로 '데이터 충돌이 자주 발생하지 않을 것'이라고 낙관적으로 가정하는 방식입니다. 데이터베이스 자체의 물리적인 락을 사용하는 대신, 애플리케이션 레벨에서 버전 관리 기능을 통해 동시성을 제어합니다.

낙관적 락 구현 방법

JPA에서는 엔티티 클래스 내부에 @Version 어노테이션이 붙은 필드를 추가하여 이를 간단히 구현합니다. 트랜잭션을 커밋할 때 최초 조회 시점의 버전과 현재 DB의 버전을 비교하여, 버전이 일치하면 업데이트를 수행하고 버전을 1 증가시킵니다. 만약 그 사이에 다른 트랜잭션이 버전을 변경했다면, OptimisticLockException 예외가 발생하여 롤백이 수행됩니다. 이 방식은 DB 자체의 락 리소스를 사용하지 않아 성능상 이점이 크지만, 예외 발생 시 애플리케이션에서 직접 재시도(Retry) 로직을 개발해 주어야 한다는 단점이 있습니다.

3. 비관적 락(Pessimistic Lock): 데이터 충돌이 빈번할 때

비관적 락은 '동일한 데이터에 대한 충돌이 언제든 일어날 수 있다'고 비관적으로 가정하고 시작합니다. 데이터베이스의 물리적인 락 메커니즘을 사용하여 데이터 조회 시점부터 다른 트랜잭션의 접근을 강력히 제한합니다.

비관적 락 구현 방법

JPA에서는 LockModeType을 PESSIMISTIC_WRITE 또는 PESSIMISTIC_READ로 설정하여 구현할 수 있습니다. 예를 들어 PESSIMISTIC_WRITE를 사용하면 SQL 실행 시 'SELECT ... FOR UPDATE' 구문이 생성되며, 트랜잭션이 완료될 때까지 다른 트랜잭션이 해당 행(Row)을 수정하거나 읽지 못하도록 배타적 잠금(Exclusive Lock)을 획득합니다. 이는 동시 수정을 원천 차단하여 확실하게 데이터 정합성을 보장하지만, 대기 시간이 길어질 경우 시스템 성능 저하 및 데드락(Deadlock) 위험성이 존재합니다.

4. 낙관적 락 vs 비관적 락: 실무 선택 기준

두 기법 중 최선의 해결책은 비즈니스 특성에 따라 다릅니다. 아래의 핵심 기준을 참고하여 선택하세요.

• 트래픽과 충돌 빈도: 충돌 빈도가 낮고 읽기 요청이 지배적이라면 낙관적 락이 유리합니다. 반면, 홈쇼핑 선착순 구매처럼 충돌이 상시 발생하는 경우에는 처음부터 트랜잭션을 순차 대기시키는 비관적 락이 적합합니다.

• 트랜잭션 생명 주기: 외부 API를 호출하는 등 트랜잭션 유지 시간이 길다면 비관적 락은 DB 커넥션 풀을 고갈시킬 수 있으므로 피해야 합니다.

• 재시도 복잡성: 충돌 발생 시 사용자에게 단순히 '다시 시도해 주세요'라는 에러 메시지를 보여주는 것만으로도 충분하다면 낙관적 락을, 백그라운드에서 반드시 완전한 처리를 보장해야 한다면 비관적 락이나 별도의 분산 락(Redis 등)을 고려해야 합니다.

결론적으로 데이터 동시성 처리에 은탄환은 없습니다. 트래픽의 규모, 데이터의 민감도, 그리고 시스템 아키텍처의 한계를 명확히 인지하고 상황에 맞춰 두 전략을 적절히 혼합하여 설계하는 것이 중요합니다. 비즈니스 요건에 최적화된 락킹 전략을 적용하여 시스템의 안정성과 성능을 모두 잡아보시기 바랍니다.