'좋아요' 버튼의 비밀: 수만 명이 동시에 눌러도 데이터가 꼬이지 않는 이유

서론: 트래픽이 폭주해도 데이터는 꼬이지 않아야 한다

수강신청이나 티켓팅 같은 대규모 트래픽 상황에서 가장 흔한 문제는 '재고 불일치'입니다. 100개의 티켓이 있는데 105명이 예매에 성공한다면 그것은 비즈니스의 신뢰도를 무너뜨리는 치명적인 버그입니다. 이러한 동시성(Concurrency) 문제를 해결하기 위해 전통적으로는 데이터베이스 락(Lock)을 사용했지만, 이는 성능 저하의 주범이 되기도 합니다. 본 글에서는 락 없이도 데이터 정합성을 지키는 낙관적 락(Optimistic Lock)의 원리를 파헤치고, JPA와 Redis를 활용한 현대적인 구현 전략을 심층 분석합니다.

서버 트래픽 폭주 상황과 데이터베이스 처리 구조 — 락킹 전략은 시스템의 처리량(Throughput)을 결정짓는 핵심 요소입니다. Photo by Christina Morillo on Pexels

핵심 원리의 심화: 버전(Version) 관리와 CAS 알고리즘

낙관적 락의 핵심은 "충돌이 거의 일어나지 않을 것이다"라는 가정 하에 락을 걸지 않는 것입니다. 대신 버전(Version) 컬럼을 이용해 데이터 변경 시점에 정합성을 검증합니다.

JPA에서의 @Version 활용

Java의 JPA(Hibernate)에서는 엔티티에 @Version 어노테이션을 붙이는 것만으로 낙관적 락을 구현할 수 있습니다.
UPDATE table SET stock = stock - 1, version = version + 1 WHERE id = 1 AND version = 5
위 쿼리에서 만약 다른 트랜잭션이 먼저 수정하여 버전이 6으로 바뀌었다면, 해당 쿼리는 실패하고(affected row = 0) OptimisticLockException이 발생합니다. 개발자는 이 예외를 잡아 재시도(Retry) 로직만 구현하면 됩니다.

CAS(Compare-And-Swap) 알고리즘

낙관적 락은 하드웨어 레벨의 CAS 알고리즘과 원리가 같습니다. "내가 읽은 값(Expected)과 현재 메모리의 값(Actual)이 같을 때만 업데이트(Swap)한다"는 원칙을 통해 락-프리(Lock-Free) 동시성 제어를 가능하게 합니다.

2025 트렌드: 분산 환경과 NoSQL의 낙관적 락

2025년의 아키텍처는 마이크로서비스(MSA)가 표준이 되면서, 단일 DB의 락만으로는 해결할 수 없는 문제들이 늘어났습니다.

DynamoDB와 Elasticsearch 같은 NoSQL 데이터베이스도 낙관적 잠금을 지원합니다. DynamoDB의 'Conditional Write' 기능이나 Elasticsearch의 _seq_no와 _primary_term 필드는 분산 환경에서 데이터 덮어쓰기(Lost Update)를 방지하는 표준 패턴으로 자리 잡았습니다. 이제 낙관적 락은 RDBMS의 전유물이 아니라, 분산 시스템 전체의 데이터 무결성을 위한 기본 소양입니다.

데이터베이스 동시성 제어 알고리즘 코드 — 버전 관리는 데이터 충돌을 감지하는 가장 가벼운 방법입니다. Photo by Luis Gomes on Pexels

실무 적용 방안: '좋아요' 카운트와 재고 차감

실무에서 낙관적 락을 언제 써야 할까요? 충돌 빈도에 따라 전략이 달라집니다.

SNS 좋아요 (충돌 빈도 낮음): 동시에 1000명이 눌러도, 최종적으로 +1000만 되면 됩니다. 이때는 낙관적 락보다는 Redis의 Atomic 연산(INCR)을 사용하는 것이 훨씬 효율적입니다.
티켓 예매 (충돌 빈도 매우 높음): 남은 좌석 1개를 두고 수천 명이 경쟁합니다. 이때 낙관적 락을 쓰면 수천 번의 재시도(Retry)가 발생해 DB 부하가 폭증합니다. 이런 경우에는 비관적 락(Pessimistic Lock, SELECT FOR UPDATE)이나 Redis 분산 락(Redisson)을 쓰는 것이 정답입니다.
쇼핑몰 상품 수정 (충돌 빈도 중간): 관리자 A와 B가 동시에 상품 설명을 수정하는 경우, 낙관적 락이 가장 적합합니다. 늦게 저장한 사람에게 "누군가 먼저 수정했습니다"라고 알려주고 다시 읽어오게 하면 되기 때문입니다.

전문가 제언 (Expert Insight)

💡 Backend Engineer's Note

기술 도입 시 팁: 낙관적 락을 도입할 때는 반드시 '재시도(Retry) 정책'을 함께 설계해야 합니다. 충돌 시 사용자에게 에러를 띄울 것인지, 아니면 백그라운드에서 3회 자동 재시도를 할 것인지 결정하십시오. Resilience4j 같은 라이브러리를 활용하면 우아한 재시도 로직을 구현할 수 있습니다.

미래 전망: 앞으로는 애플리케이션 레벨의 락 구현보다, 데이터베이스 자체가 제공하는 'Conflict-free Replicated Data Types (CRDTs)' 기술이 주목받을 것입니다. 이는 물리적으로 떨어진 노드에서 동시에 수정이 일어나도 수학적으로 자동 병합(Merge)되는 기술로, 구글 독스 같은 실시간 협업 도구의 핵심입니다.

실시간 협업 도구와 데이터 동기화 기술 — CRDT와 같은 기술은 충돌 없는 실시간 협업을 가능하게 합니다. Photo by fauxels on Pexels

결론: 은탄환은 없다, 상황에 맞는 무기를 골라라

낙관적 락은 데이터베이스의 락 대기 시간을 없애 처리량을 획기적으로 높여주는 훌륭한 도구입니다. 하지만 충돌이 잦은 환경에서는 오히려 독이 될 수 있습니다. 내 서비스의 트래픽 패턴과 데이터 민감도를 분석하고, 낙관적 락과 비관적 락, 그리고 분산 락 사이에서 최적의 균형점을 찾는 것이 엔지니어의 핵심 역량입니다.