포스트

뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계

Tech Blog Review
게시
By August
좋아요 조회 12 분 읽는 시간

엔지니어링 요약

Problem

뱅크샐러드의 앱테크 게임 재화 SAL은 원화로 바뀌는 실질 자산이다. 유저의 스킬 보상과 운영자의 보상 지급이 같은 잔액을 동시에 갱신하면 한쪽이 사라진다(Lost Update). parity-pay의 잔액 차감이 정확히 같은 문제였다.

Decision

원문의 대안 비교(비관적 락·분산 락·낙관적 락)와 낙관적 락을 고른 네 근거, 구현(update_version, CAS, numUpdated == 0), 운영 고려사항(Replication Lag, Fresh Read, 지터, 멱등 키)을 옮기고, parity-pay 2편의 조건부 원자 UPDATE와 10편의 분산락 실험에 대조했다.

Result

메커니즘은 같다. WHERE에 버전을 넣은 단일 UPDATE, 0행이면 충돌. 갈리는 곳은 충돌한 요청의 운명이다. 뱅크샐러드는 보상이 시간 차분(마지막 갱신 시각부터 지금까지 × 초당 비율)이라 실패한 요청의 보상이 다음 성공에 자동으로 포함되므로 재시도가 거의 필요 없다. parity-pay의 결제는 그 성질이 없어 충돌은 곧 실패 응답이고, 대신 '언제 읽었는가'를 묻지 않는 조건이 정합성을 지킨다. 원문이 '실제 운영 후 정합성 이슈 0건'이라고 적었는데, 0건을 어떻게 세었는지가 남는 질문이다.

원문: 뱅크샐러드가 게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락) — 뱅크샐러드 기술 블로그, 배지원(금융쇼핑 PA 백엔드), 2026-01-16

parity-pay 2편에서 잔액 차감을 WHERE available_amount >= :amount AND version = :v인 단일 UPDATE로 하기로 했고, 10편에서 그 결정을 분산락과 대조해 확정했다. 원문은 같은 메커니즘을 게임 재화에 적용한 글이다. 같은 도구를 다른 도메인에 쓰면 무엇이 같고 무엇이 다른지가 보인다.

원문이 말하는 것

‘일해라 김뱅샐’은 방치형 앱테크 게임이고, 재화 SAL은 원화로 전환되는 실질 자산이라 정합성 요구가 금융 수준이다. 문제는 Lost Update다. 유저 A가 스킬로 200 SAL을 얻으려는 순간(1,000 → 1,200) 운영자 B가 보상 500 SAL을 지급하면(1,000 → 1,500), 한쪽이 덮여 200이 사라진다.

대안 셋을 비교했다. 비관적 락(SELECT FOR UPDATE)은 충돌이 잦으면 확실하지만 대규모 트래픽에서 커넥션 병목. 분산 락(Redis)은 복잡한 동기화에 유리하지만 인프라 비용. 낙관적 락은 잠금 시간 최소·데드락 없음이지만 애플리케이션이 충돌을 처리해야 함. 낙관적 락을 고른 근거는 넷이다. 유저 데이터가 격리돼 있어 충돌 확률이 낮다, update_version 컬럼 하나로 끝나 인프라가 단순하다, 락 대기가 없어 게임 화면이 안 멈춘다, 그리고 재시도 복잡도가 최소다. 마지막이 핵심인데, 보상이 시간 차분(마지막 갱신 시각부터 지금까지 × 초당 비율)이라 충돌로 실패해도 갱신 시각이 안 바뀌었으므로 다음 성공에 그 기간의 보상이 포함된다. 유저의 수익이 누락되지 않는다.

구현은 character_state에 update_version, WHERE에 버전 조건, numUpdated == 0이면 ErrConcurrentStateUpdate. 운영 고려사항으로 Replication Lag 때문에 Primary에서 읽을 것, 재시도 시 Fresh Read, 지수 백오프와 지터, request_id 기반 멱등, 최대 재시도 제한을 적었다. 결과는 실제 운영 후 정합성 이슈 0건.

같은 곳: WHERE에 조건을 넣으면 DB가 판정한다

메커니즘은 parity-pay와 같다. “조회 → 계산 → 저장”이 아니라 조건을 WHERE에 넣은 단일 UPDATE. 0행이면 충돌. 10편에서 이 방식이 같은 300~500ms 멈춤 아래에서 여섯 번 전부 정확히 240건 승인·drift 0이었고, 같은 조건의 분산락은 초과 승인 340~350건이었다. 원문이 분산 락을 “인프라 비용”으로 뺀 것은 10편의 결과로 보면 비용보다 근본적이다. lease가 만료되면 락은 정합성을 지키지 못하고, 조건부 UPDATE는 “언제 읽었는가”를 묻지 않으므로 지킨다. 원문의 도메인(유저 vs 운영자의 드문 충돌)에서는 그 차이가 드러날 일이 거의 없겠지만, 고른 쪽이 맞다.

Replication Lag 항목도 같은 자리다. 낙관적 락은 읽은 버전과 쓰는 버전이 같은 소스여야 한다. 레플리카에서 읽은 낡은 버전으로 Primary에 쓰면 매번 충돌한다. 원문이 이것을 운영 고려사항 첫 줄에 둔 것이 실제로 겪었다는 뜻으로 읽힌다.

갈리는 곳: 충돌한 요청은 무엇이 되는가

원문의 네 번째 근거가 이 글의 실질이다. 보상이 시간 차분이라 충돌로 실패한 요청의 보상이 사라지지 않고 다음 성공에 이월된다. 그래서 재시도가 거의 필요 없다. 충돌은 “다음에 한꺼번에”로 흡수된다.

parity-pay의 결제는 그 성질이 없다. 결제 10,000원이 버전 충돌로 실패하면 그 결제는 실패다. 다음 결제가 그것을 포함하지 않는다. 그래서 2편에서는 충돌과 잔액 부족을 구분해 응답을 나눴고, 재시도는 클라이언트의 새 시도(새 멱등 키)다. 같은 메커니즘인데 충돌의 의미가 다르다. 게임 보상은 누적이라 충돌이 지연이고, 결제는 단건이라 충돌이 실패다.

이 차이가 낙관적 락의 적합성을 가른다. 원문의 도메인은 충돌이 드물고 충돌해도 손실이 없는 최상의 조건이다. parity-pay의 동일 지갑 경합 실험(2편)에서는 20 VU가 한 지갑에 몰리자 처리량이 5.8배 떨어졌는데, 그것은 낙관적 락이 나빠서가 아니라 잔액 행이 직렬화 지점이라 어떤 락을 써도 같았다. 낙관적 락은 충돌이 드물 때 가장 싸고, 충돌이 잦으면 재시도가 부하가 된다. 원문의 “낮은 충돌 확률”이 첫 번째 근거인 이유가 그것이다.

원문이 답하지 않는 것: 0건을 어떻게 세었는가

“실제 운영 후 데이터 정합성 이슈 0건”은 좋은 결과인데, 0건을 세는 방법이 없다. SAL은 원화로 바뀌는 자산이므로 어딘가에 원장이나 이력이 있어야 “잔액 = 이력의 합”을 검증할 수 있다. parity-pay 1편에서 INV-010(스냅샷 = 원장 계산값)을 두고 그 어긋남을 지표로 낸 이유가 이것이다. 정합성 이슈 0건은 검증 장치가 있을 때만 의미가 있고, 검증 장치가 없으면 “발견된 이슈 0건”이다. 10편의 실험 1에서 락이 깨졌을 때 스냅샷은 0에서 멈춰 정상처럼 보였고 원장만 음수였다. 세는 장치가 없으면 그 상태를 0건이라고 부르게 된다.

원문이 보상을 시간 차분으로 계산한다는 것 자체가 힌트다. 시간 차분은 재계산 가능하다. 마지막 갱신 시각과 초당 비율이 있으면 어느 시점의 잔액도 다시 만들 수 있고, 그것이 원문의 원장이다. 그렇다면 스냅샷(character_state)과 재계산값을 대조하는 배치가 있는지가 궁금하다.

원문이 잘한 것

충돌을 장애가 아니라 정상 흐름으로 정의한 것이다. 원문의 표현으로 “충돌은 시스템 장애가 아닌 정상적인 제어 흐름의 일부”이고, 그래서 모든 충돌에 무조건 재시도하지 않고 비즈니스 성격에 맞는 재시도 전략을 두라고 한다. 5편에서 at-least-once의 중복을 “버그가 아니라 전제”라고 적은 것과 같은 자세다. 실패 모드를 정상 조건으로 두면 그것을 다루는 코드가 예외 처리가 아니라 설계가 된다.

낙관적 락을 고른 근거 넷을 도메인에서 끌어온 것도 좋다. “낙관적 락이 좋다”가 아니라 “이 도메인은 충돌이 드물고, 충돌해도 이월되고, 화면이 멈추면 안 되고, 인프라를 늘리고 싶지 않다”에서 나온 결정이다. 다른 도메인이면 다른 답이 나온다는 것을 근거가 말해 준다.

가져갈 것

  • WHERE에 조건과 버전을 넣은 단일 UPDATE는 “언제 읽었는가”를 묻지 않는다. 분산락이 못 지키는 것을 지킨다.
  • 같은 메커니즘이라도 충돌의 의미는 도메인이 정한다. 누적 보상에서는 지연, 단건 결제에서는 실패.
  • 낙관적 락의 첫 조건은 낮은 충돌률이다. 충돌이 잦으면 재시도가 부하이고, 그때는 어떤 락을 써도 직렬화 지점은 남는다.
  • “정합성 이슈 0건”에는 세는 장치가 따라와야 한다. 없으면 “발견된 이슈 0건”이다.
시리즈

빅테크 기술 블로그 리뷰

31편 중 12편

이전 시리즈 글 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다 다음 시리즈 글 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  1. 1 카카오 「실시간 메시징 시스템 개발기」(3편) 리뷰 — Redis에 몰린 부하를 서버로 옮기고, 그 서버를 pprof로 세 번 깎은 이야기
  2. 2 카카오 「추가배포 없이 API의 case 통일시키기」 리뷰 — 받는 쪽이 자기 케이스에 맞춰 알아서 읽게 하면 배포 순서가 사라진다
  3. 3 카카오 「MySQL DATETIME, TIMESTAMP 데이터 타입에 대한 분석」 리뷰 — 바이트 단위 저장 구조부터 아직 안 고쳐진 Y2K38까지
  4. 4 네이버 D2 「6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기」 리뷰 — 복제·검증·복구를 셋으로 나누고, 옛 도구와 새 도구를 서로 모르게 같이 돌린 전환
  5. 5 카카오 「MySQL ALTER DDL 수행 방식에 대한 이해」 리뷰 — Copy·In-Place·Instant는 '무엇을 복사하느냐'보다 '언제 Exclusive 메타 락을 잡느냐'로 구분된다
  6. 6 카카오 「MySQL Orchestrator 기반의 새로운 HA 표준 개발기」 리뷰 — 10년 멈춘 Perl 도구를 떠나 Raft 클러스터로, 그리고 slave_net_timeout 한 줄
  7. 7 카카오 「MySQL Ver. 8.0 New Feature: Instant DDL Algorithm에 대한 이해」 리뷰 — 컬럼을 0.01초에 추가하는 대가는 '읽을 때마다 버전을 대조하는 것'이다
  8. 8 네이버 D2 「CDC 복제 이후 오라클이 느려졌다? child cursor 폭증이 만든 예상치 못한 문제」 리뷰 — 같은 SQL인데 바인딩 타입이 다르면 Oracle은 다른 쿼리로 본다
  9. 9 카카오 「MySQL InnoDB Log에 대한 이해 - (1)」 리뷰 — 트랜잭션 하나가 어떻게 MTR 여러 개로 쪼개져 Redo Log Buffer에 들어가는가
  10. 10 카카오 「PostgreSQL to ES: Kafka Connect CDC 파이프라인」 1·2편 리뷰 — 변경이 없어서 디스크가 차고, LSN이 사라져서 스냅샷을 다시 짜야 했던 CDC의 실제 운영 비용
  11. 11 LINE 「기획서 없이 내재화하기: 검증 로직으로 동일함을 증명하다」 리뷰 — 블랙박스는 입력과 출력만 정의하면 통계로 같음을 증명할 수 있다
  12. 12 뱅크샐러드 「게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)」 리뷰 — 같은 WHERE version 조건인데, 충돌한 요청을 어떻게 하는가에서 갈리는 두 설계
  13. 13 우아한형제들 「Spring Batch와 Querydsl」 리뷰 — offset을 버린 Reader가 21분을 4분으로 만든 이유, 그리고 그 Reader가 답하지 않는 두 가지
  14. 14 네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호
  15. 15 당근 「QR을 찍으면 무슨 일이 벌어질까? 당근페이 현장 결제의 모든 것」 리뷰 — 카드망을 빌려 7주 만에 낸 결제와, 그 글이 다루지 않은 승인 응답이 사라지는 순간
  16. 16 네이버 D2 「스마트스토어센터 Oracle에서 MySQL로의 무중단 전환기」 리뷰 — 두 DB에 동시에 쓰되 한쪽 실패는 무시하고, 읽기 트래픽을 복제해 성능을 재고, 6개월간 불일치를 0으로 만든 과정
  17. 17 야놀자 「RESTful API validation 자동화 하기」 리뷰 — 인터페이스 하나에서 검증·문서·타입을 뽑는 이유, 그리고 자동화가 없으면 누락이 필연이라는 문장
  18. 18 카카오 「MySQL Json 데이터 타입의 저장 구조와 성능 비교」 리뷰 — 통째로 넣고 통째로 꺼내면 TEXT, 키로 파고들면 JSON
  19. 19 LINE 「도메인에 의존하지 않는 채팅 플랫폼은 어떻게 만들었을까?」 리뷰 — 사용자를 모르는 채팅 플랫폼, 웹으로 만든 클라이언트, SOFT STOP으로 갈아 끼우는 챗봇 시나리오
  20. 20 카카오페이 「MSA 환경에서 네트워크 예외를 잘 다루는 방법」 리뷰 — Unknown을 타입으로 만든 글과, Unknown을 상태로 저장한 프로젝트가 갈리는 지점
  21. 21 카카오 「메시징 서버의 스트레스 테스트 노하우와 AI가 덜어 준 부분」 리뷰 — 지표를 네 층으로 내려가 읽는 법, 그리고 LLM에게 맡긴 것과 맡기지 못한 것
  22. 22 네이버 D2 「일 3,000만 건의 네이버페이 주문 메시지를 처리하는 Kafka 시스템의 무중단 전환 사례」 리뷰 — 두 벌로 발행해 대조한 검증기와, 발행 제어 키를 파티션 키와 같게 둔 이유
  23. 23 카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다
  24. 24 컬리 「컬리의 입고 시스템이 외부 인입 데이터를 안전하게 동기화하는 방법」 리뷰 — 145회 재시도가 맞는 도메인과 재시도를 금지한 도메인, 그리고 발행부와 수신부가 각자 책임지는 구조
  25. 25 네이버 D2 「@RequestCache: HTTP 요청 범위 캐싱을 위한 커스텀 애너테이션 개발기」 리뷰 — 캐시의 수명을 '요청 하나'로 맞추면 TTL 고민이 사라진다, 그리고 @RequestScope가 안 되는 이유
  26. 26 무신사 「Kafka와 Strimzi를 이용하여 6개의 도메인을 하나의 도메인으로 합쳐보았습니다」 리뷰 — 배치 없이 CDC와 Kafka Streams로 옮긴 결정, 그리고 통합 모델이 원본과 같다는 것을 누가 확인하는가
  27. 27 쿠팡 「대용량 트래픽 처리를 위한 쿠팡의 백엔드 전략」 리뷰 — 캐시 두 겹과 '분 단위 99.99% 동일'이라는 문장, 그리고 그 0.01%를 누가 어떻게 세는가
  28. 28 LINE 「LINE에서 Kafka를 사용하는 방법 - 1편」 리뷰 — 초당 4GB 클러스터가 바이트가 아니라 요청 수를 제한하는 이유, 그리고 2,000틱짜리 파이프라인에서 같은 것을 본 기록
  29. 29 카카오 「MySQL 인증 플러그인 caching_sha2_password에 대한 이해」 리뷰 — 비밀번호 해시가 바뀌는 것보다 '평문이 서버까지 가야 한다'는 점이 전환의 진짜 비용
  30. 30 LINE 「초당 100만 건, LINE 앱에 Apache Kafka 종단 간 암호화 적용기」 리뷰 — 인터셉터와 시리얼라이저만으로 브로커에 평문을 남기지 않는 법
  31. 31 카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제
TechBlog, Banksalad
Tech Blog Review Banksalad Optimistic Lock Lost Update Concurrency Compare-and-Set Replication Lag
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.

댓글

아직 댓글이 없습니다