[기술적 의사결정] Lock 전략 기술적 의사결정

프로젝트를 진행하다 보면, 단순히 기능 구현을 넘어
"어떤 기술을 선택할 것인가?"에 대한 중요한 고민을 하게 된다.
이번 글에서는 이커머스 프로젝트(EvoStyle)에서
선착순 할인 쿠폰 발급 기능을 구현하는 과정에서 어떤 Lock 전략을 선택했는지, 그리고 그 이유는 무엇인지 정리할 예정이다.

 

배경

이커머스 서비스에서는 이벤트 쿠폰처럼 다수 사용자가 동시에 발급 요청을 보낼 수 있는 상황이 자주 발생한다.
이번 프로젝트에서도 쿠폰 중복 발급 방지, 재고 초과 사용 방지, 요청 속도 관리와 같은 요구사항이 핵심 과제가 되었다.

현재는 단일 서버 환경이지만, 향후 수평 확장(멀티 서버)을 고려한 설계가 필요했다.

 

문제 정의

동일한 쿠폰을 여러 사용자가 동시에 요청했을 때, 별다른 동시성 제어 없이 처리하면 다음 문제가 발생할 수 있다.
👉  쿠폰 초과 발급
👉  재고 관리 실패
👉  데이터 정합성 문제 발생

따라서 다음 목표를 만족시키는 Lock 전략이 필요했다.
✅  동시성 제어
✅  데이터 정합성 보장
✅  성능 유지
✅  확장성 및 유지보수성 확보

 

고려한 대안

여러 Lock 전략을 정리하고, 각각 장단점을 비교해봤다.

전략	설명	장점	단점
비관적 락 (Pessimistic Lock)	DB SELECT ... FOR UPDATE 사용	트랜잭션 내 데이터 정합성 강력 보장 단일 서버 환경에서 빠름	확장성 낮음 DB 병목 가능성
낙관적 락 (Optimistic Lock)	버전 필드 기반 충돌 감지	락 없이 빠르게 처리 가능	충돌 발생 시 재시도 필요 실시간 처리에는 부적합
Redisson 분산 락	Redis를 이용한 글로벌 락 관리	분산 환경 대응 가능 실시간 제어 가능	네트워크 오버헤드 설정 복잡도 존재
메시지 큐 기반 처리	Kafka 등으로 선착순 큐 처리	대량 처리에 유리 장애 복원력 강함	실시간성 부족 시스템 설계 복잡

 

성능 테스트 결과

단일 서버 환경에서 500명의 동시 사용자 요청을 JMeter를 이용해 시뮬레이션했다.

전략	평균 응답 시간	중복 여부	비고
비관적 락	14ms	❌ 중복 없음	DB 트랜잭션 기반, 가장 빠름
Redisson 락	413ms	❌ 중복 없음	Redis 통신 오버헤드 발생

결과적으로 단일 서버 기준에서는 비관적 락이 성능과 정합성 모두 가장 우수했다.

 

최종 선택 : Redisson 분산 락

단일 서버 기준으로만 본다면, 비관적 락이 가장 빠르고 안정적인 선택이었다.
하지만, 이번 프로젝트는 향후 수평 확장(멀티 서버)을 염두에 두고 있었기 때문에, Redisson 분산 락을 최종 선택했다.

선택 이유 요약

고려사항	설명
수평 확장성 확보	다중 서버 환경에서도 락 일관성 유지 가능
실시간성 보장	메시지 큐 방식 대비 빠른 응답 시간
유지보수성	Redis 캐시 시스템과 락 관리 통합 가능
설계 유연성	DB 트랜잭션과 독립된 락 관리 → 시스템 확장에 유리

 

참고 : 비관적 락의 한계

비관적 락은 단일 서버에서는 좋은 성능을 보이지만, 다음과 같은 제약이 있다.
👉  DB 트랜잭션 범위 안에서만 락이 유효하다.
👉  서버가 여러 대일 경우, 트랜잭션 격리를 보장하기 어렵다.
👉  고부하 환경에서는 DB 락 경합이 심해질 수 있다.

이런 이유로 분산 시스템에 대비하려면 DB 락만으로는 부족했다.

 

이번 기술적 의사결정을 통해 얻은 교훈은 명확하다.
단기 성능만 보는 것이 아니라, 미래 확장성과 시스템 안정성까지 고려한 선택이 중요하다.

Redisson 분산 락을 선택함으로써, 당장 빠른 성능은 양보했지만 장기적인 서비스 확장성과 유지보수성을 확보할 수 있었다.