관리자 메모의 동시 수정 시 덮어쓰기(Lost Update) 문제 해결

동시성 제어: Lost Update 문제의 본질과 비즈니스적 영향

데이터베이스에서 ‘Lost Update’는 둘 이상의 트랜잭션이 동일한 데이터 항목을 동시에 읽고, 각자 수정한 후 다시 쓰는 과정에서 발생하는 고전적인 동시성 제어 문제입니다. 핵심은 ‘읽기-수정-쓰기’라는 비원자적(non-atomic) 작업 흐름에 있습니다. 예를 들어, 두 관리자가 동시에 동일한 상품 재고 수량(현재 값: 100)을 조회합니다. A 관리자는 10개를 출고하여 90으로 수정하려 하고, B 관리자는 5개를 반품하여 105로 수정하려 합니다. 두 작업이 겹치면, 나중에 커밋된 트랜잭션의 결과가 먼저 커밋된 결과를 완전히 덮어쓰게 되어, 재고가 90 또는 105 중 하나로만 설정됩니다. 다른 하나의 수정 사항은 영구적으로 손실됩니다, 이는 단순한 기술적 버그가 아닌, 재무 데이터의 오류, 재고 관리의 혼란, 고객 주문의 중복 처리 등 직접적인 금전적 손실과 운영 신뢰도 하락으로 이어지는 심각한 비즈니스 리스크입니다.

해결 방안 1: 비관적 락(Pessimistic Locking) – 선점적 접근 제어

비관적 락은 충돌이 빈번하게 발생할 것이라고 ‘비관적으로’ 가정하고, 데이터를 읽는 시점부터 배타적 잠금(Exclusive Lock)을 걸어 다른 트랜잭션이 해당 데이터를 읽거나 쓰지 못하게 차단하는 방식입니다. 주로 `SELECT … 이와 같은 fOR UPDATE` 구문을 사용합니다. 이 방식은 데이터 일관성을 철저히 보장하지만, 락을 획득한 트랜잭션이 완료될 때까지 다른 모든 트랜잭션이 대기해야 하므로 시스템의 전체 처리량(Throughput)과 응답성에 부정적 영향을 미칩니다. 가령 장시간 실행되는 트랜잭션이 많거나, 사용자가 많아지는 경우 병목 현상이 두드러집니다.

비관적 락의 실전 구현과 비용

재고 관리 시스템에서 특정 상품의 수량을 감소시키는 로직을 비관적 락으로 구현한다면, 트랜잭션 시작 시점에 해당 재고 레코드에 대한 배타적 락을 즉시 획득합니다. 이 상태에서 다른 모든 관리자의 해당 재고 조회/수정 요청은 락이 해제될 때까지 대기 큐에 머무르게 됩니다. 이로 인해 발생하는 대기 시간은 사용자 경험을 저하시키고, 데드락(Deadlock) 발생 가능성도 상승시킵니다. 따라서 이 방법은 데이터 무결성이 최우선이며, 충돌이 거의 확실한 ‘핫 스팟(Hot Spot)’ 데이터를 다룰 때 선택적으로 적용하는 전략이 되어야 합니다.

해결 방안 2: 낙관적 락(Optimistic Locking) – 충돌 감지 및 후처리

낙관적 락은 충돌이 드물게 발생할 것이라고 ‘낙관적으로’ 가정합니다. 데이터를 읽을 때는 별도의 락을 걸지 않으며, 수정을 시도하는 시점에 자신이 읽은 데이터가 그동안 변경되지 않았는지 확인합니다. 일반적으로 버전 번호(Version Number)나 타임스탬프(Timestamp) 컬럼을 사용하여 이를 검증합니다. 트랜잭션은 데이터를 읽을 당시의 버전 값을 기억하고, 업데이트 시 `WHERE` 절에 원래의 버전 조건을 추가합니다. 업데이트가 성공하면 버전을 증가시키고, 실패하면(다른 트랜잭션이 이미 수정했음을 의미) 애플리케이션 레벨에서 예외를 처리하여 사용자에게 알리거나 재시도 로직을 수행합니다.

낙관적 락의 경제적 효용성

낙관적 락은 락 대기 시간이 없으므로 시스템 자원 활용도와 확장성(Scalability)이 뛰어납니다. 이는 클라우드 기반의 분산 시스템이나 사용자 동시 접속이 많은 웹 애플리케이션에서 매우 효율적입니다. 그러나 충돌이 일례로 발생했을 때의 처리 비용(사용자 재입력, 트랜잭션 재시도)을 애플리케이션 로직으로 떠안게 됩니다. 따라서 ‘충돌 빈도’와 ‘충돌 시 처리 비용’을 정량적으로 평가하여 적용 여부를 결정해야 합니다. 대부분의 웹 기반 관리자 시스템에서는 낙관적 락이 더 합리적인 선택입니다.

비관적 락 vs 낙관적 락: 전략적 선택을 위한 데이터 기반 비교

두 방식의 선택은 기술 선호도가 아닌, 비즈니스 시나리오에 대한 정량적 분석에 기반해야 합니다. 아래 표는 핵심 비교 요소를 정리한 것입니다.

비교 항목	비관적 락 (Pessimistic Locking)	낙관적 락 (Optimistic Locking)
기본 가정	충돌이 빈번할 것이다.	충돌이 드물 것이다.
작동 시점	데이터 읽기 시점 (조회 시 락 획득)	데이터 쓰기 시점 (저장 전 충돌 검증)
구현 방식	DBMS 락 메커니즘 (e.g., SELECT FOR UPDATE)	버전 컬럼 또는 타임스탬프 비교
성능 특성	락 대기 시간 발생, 데드락 가능성, 낮은 동시성	락 대기 없음, 높은 동시성과 처리량
데이터 일관성	매우 높음 (선점적 보장)	쓰기 시점에 검증 (충돌 시 롤백)
적합한 시나리오	충돌이 매우 빈번한 핵심 데이터 (예: 좌석 예매의 마지막 한 자리, 초고빈도 주문 체결)	읽기 작업이 많고, 쓰기 충돌 가능성이 비교적 낮은 데이터 (예: 대부분의 CRUD 기반 관리자 기능, 사용자 프로필 수정)
충돌 시 처리	DB 레벨에서 대기 (애플리케이션 투명)	애플리케이션 레벨에서 예외 처리 및 재시도 필요

이 표를 기준으로, 관리자 메모 수정과 같은 기능은 일반적으로 여러 관리자가 동시에 정확히 같은 레코드를 수정할 확률이 높지 않으므로, 낙관적 락이 시스템 전체의 효율성과 응답성 측면에서 더 유리한 선택입니다. 반면, 재고에서 마지막 한 개의 물품을 두 고객이 동시에 결제하려는 시나리오에서는 비관적 락이 데이터 정합성을 확실히 보호할 수 있습니다.

고급 해결 방안 및 하이브리드 접근법

기본적인 두 락킹 전략 외에도 상황에 따라 더 세밀한 제어가 필요할 수 있습니다.

자동 재시도 메커니즘 (Optimistic Lock Retry)

낙관적 락에서 충돌이 감지되었을 때, 사용자에게 직접 에러를 보여주는 대신 애플리케이션 백엔드에서 제한된 횟수 내에서 자동으로 작업을 재시도하는 패턴입니다. 재시도 시 최신 버전의 데이터를 다시 읽어 사용자의 수정 의도를 반영하여 갱신을 시도합니다. 이는 사용자 경험을 크게 향상시키지만, 재시도 로직이 복잡해지고 ‘원자성’을 보장하기 어려운 비즈니스 로직에서는 적용이 제한될 수 있습니다.

하이브리드 접근: 상황에 따른 락 전략 선택

하나의 시스템 내에서도 데이터의 특성에 따라 다른 락 전략을 혼용할 수 있습니다. 예를 들어, 대부분의 일반 게시글 수정에는 낙관적 락을 적용하면서, 특정 핵심 설정 값이나 금융 카운터 값의 업데이트에는 비관적 락을 적용하여 안정성을 확보하는 방식입니다.

데이터베이스의 다중 버전 동시성 제어(MVCC) 모델을 활용하면 기본적인 읽기-쓰기 충돌을 상당 부분 완화할 수 있으나, 대규모 데이터를 다루는 환경에서는 이것만으로 충분하지 않습니다. 특히 정산 시스템처럼 총판 정산 상세 내역 조회 시 수억 건의 베팅 데이터를 조인하는 쿼리 튜닝이 필수적인 영역에서는, 적절한 락 전략과 함께 인덱스 최적화 및 물리적 파티셔닝이 병행되어야만 병목 현상 없는 고성능 조회가 가능해집니다.

나아가 분산 환경에서는 Redis 등을 이용한 분산 락(Distributed Lock) 도입을 고려하여, 여러 WAS 인스턴스 간의 자원 경합을 효율적으로 관리하고 시스템 전체의 처리량을 극대화하는 방향으로 설계해야 합니다.

리스크 관리: Lost Update 방지 전략의 함정과 주의사항

Lost Update를 방지하는 기술을 도입할 때 발생할 수 있는 새로운 리스크를 인지하고 관리해야 합니다.

비관적 락의 데드락 리스크: 여러 트랜잭션이 서로 다른 순서로 리소스에 락을 걸 때 발생하는 데드락은 시스템 성능을 급격히 저하시킵니다. 이를 방지하기 위해 락 획득 순서를 일관되게 정의하거나. 락 타임아웃을 설정하는 전략이 필수적입니다.

낙관적 락의 사용자 경험 리스크: “방금 다른 사용자가 내용을 수정했습니다. 현재 내용을 보여드리겠습니다.”와 같은 메시지 처리가 미비할 경우, 사용자는 자신의 작업이 무시당했다고 느낄 수 있습니다. 충돌 감지 시 어떻게 최신 데이터를 보여주고, 사용자의 입력을 어떻게 보존할지(예: 병합 제안)에 대한 UX 설계가 동반되어야 합니다.

성능 오버헤드 평가: 낙관적 락을 위한 버전 컬럼 관리나, 비관적 락을 위한 연결 세션 유지는 미미하지만 지속적인 오버헤드를 발생시킵니다. 대규모 트래픽 환경에서는 이러한 오버헤드의 누적 효과를 모니터링해야 합니다.

결론적으로, Lost Update 문제에 대한 최선의 해결책은 존재하지 않습니다. 애플리케이션의 동시 접근 패턴, 데이터의 중요도, 비즈니스에서 허용 가능한 충돌 처리 비용을 정량적으로 분석한 후, 위에 제시된 도구들 중 가장 비용 대비 효과가 높은 조합을 선택하는 것이 핵심입니다. 대부분의 현대 웹 애플리케이션에서는 낙관적 락이 기본 골격을 이루며, 극소수의 특수 케이스에 비관적 락이 보완재로 사용되는 하이브리드 모델이 가장 실용적인 해법입니다.