동시성 문제를 해결하기 위해 데이터베이스에서 락(Lock)을 사용하는 방법은 크게 낙관적 락(Optimistic Lock)과 비관적 락(Pessimistic Lock) 두 가지로 나눠진다. 각각의 방식은 데이터 충돌을 처리하는 방식이 다르며, 사용하는 상황에 따라 성능과 효율성이 크게 달라질 수 있다.
낙관적 락 (Optimistic Lock)
낙관적 락은 기본적으로 '충돌이 발생할 확률은 낮다' 라고 낙관하는 방식이다. 즉, 데이터 수정 시 충돌을 미리 방지하지 않고, 수정이 끝난 후 충돌 여부를 검사하는 방식이다. 데이터의 버전(version)을 통해 트랜잭션이 충돌하는지 여부를 체크한다.
동작 원리
- 데이터를 조회할 때 버전 번호를 함께 가져온다.
- 데이터를 수정하려면 DB에서 가져온 버전 번호를 확인하고, 변경된 버전 번호와 일치하는지 비교한다.
- 버전 번호가 일치하면 수정을 진행하고, 다르면 충돌이 발생한 것으로 간주하여 예외를 던진다.
ex) 게시판의 조회수 증가, 사용자 정보 수정 등 동시에 수정이 거의 발생하지 않는 경우
비관적 락 (Pessimistic Lock)
비관적 락은 '충돌이 발생할 확률이 높다' 라고 비관하고, 데이터를 수정하기 전에 잠금을 걸어 다른 트랜잭션이 접근하지 못하도록 하는 방식이다. 즉, 데이터를 조회하는 순간부터 잠금 상태로 유지하여 다른 트랜잭션의 접근을 차단한다.
동작 원리
- 데이터를 조회하면서 즉시 잠금을 걸고, 다른 트랜잭션은 이 데이터를 수정할 수 없다.
- 수정이 완료될 때까지 다른 트랜잭션은 해당 데이터를 읽거나 수정할 수 없다.
- 작업이 끝나면 잠금을 해제한다.
ex) 재고 관리 시스템, 은행 계좌 이체 등 동시에 데이터 수정이 자주 발생하는 경우
낙관적 락 vs 비관적 락
| 특징 | 낙관적 락 (Optimistic Lock) | 비관적 락 (Pessimistic Lock) |
|---|---|---|
| 접근 방식 | 충돌이 없을 거라고 가정하고 진행 | 충돌 가능성이 높으므로 미리 잠금 |
| 동작 원리 | 버전 필드 비교로 충돌 감지 | 데이터 조회 시 바로 DB에 잠금 설정 |
| 성능 | 빠름 (락을 걸지 않음) | 느림 (락을 걸고 해제까지 대기) |
| 충돌 발생 시 | 예외(OptimisticLockException) 발생 | 대기(Blocking) 후 처리 |
| 사용 예시 | 읽기 중심, 충돌이 드문 시스템 (게시판 조회수) | 쓰기 중심, 충돌 위험 높은 시스템 (재고, 결제) |
| 구현 방식 (JPA) | @Version | @Lock(LockModeType.PESSIMISTIC_WRITE) |
- 낙관적 락은 충돌이 드물고 성능이 중요한 경우에 유리하며, 비관적 락은 데이터 정합성이 중요한 상황에서 유리하다.
- 시스템의 동시성과 충돌 가능성에 따라 적절한 락 방식을 선택하는 것이 중요 !!
