grep

Engineering

뱅크샐러드가 게임을 만들 때 데이터 정합성을 유지하는 법 (feat. 낙관적 락)

뱅크샐러드

2026년 1월 16일

원문에서 보기 ↗

안녕하세요 금융쇼핑 PA 백앤드 개발자 배지원입니다.

최근 뱅크샐러드는 단순한 자산 관리를 넘어, 유저에게 즐거운 금융 경험을 제공하기 위해 게이미피케이션 요소를 적극적으로 도입하고 있습니다. 오늘 소개해 드릴 일해라 김뱅샐은 뱅크샐러드 유저들이 캐릭터를 육성하며 즐겁게 자산을 관리할 수 있도록 돕는 대표적인 방치형 앱테크 게임입니다.

오늘은 금융 플랫폼 내에서 앱테크 서비스를 구현하며 마주했던 데이터 정합성 에 대한 고민, 그리고 이를 해결하기 위해 채택한 재시도 로직 없는 낙관적 락 설계에 대해 공유하고자 합니다.

일해라 김뱅샐: 금융 경험을 확장하는 앱테크 서비스

일해라 김뱅샐은 유저가 회사원 김뱅샐을 승진시키며 즐거움을 느끼고, 그 과정에서 실질적인 혜택을 얻는 서비스입니다. 유저는 에너지를 관리하며 책상의 쓰레기를 치우거나 스킬을 사용하여 게임 내 재화인 샐(SAL)을 획득합니다.

이때 획득하는 샐(SAL) 은 단순한 게임 재화가 아니라, 실제 원화(KRW)로 전환 가능한 실질적인 자산 입니다. 따라서 일해라김뱅샐 팀은 게임이 주는 즐거움은 유지 하면서도, 금융 서비스 도메인에 걸맞게 유저의 자산이 정확하게 계산될 수 있는 서비스 설계에 집중했습니다.

01

일해라 김뱅샐 메인 화면

02

일해라 김뱅샐의 서비스 사이클

우리는 왜 동시성 제어에 신경을 써야 했나

‘일해라 김뱅샐’ 의 핵심 데이터인 character_state(레벨, SAL, 에너지 등)는 다양한 경로를 통해 실시간으로 업데이트됩니다. 시스템을 설계하며 저희가 정의한 데이터 수정 트리거는 다음과 같습니다.

영상 보기

⚠️ 데이터 정합성을 위협하는 ‘갱신 손실(Lost Update)’

만약 적절한 동시성 제어가 없다면, 동일한 데이터에 대해 서로 다른 수정 요청 과정에서 갱신 손실(Lost Update) 현상이 발생할 수 있습니다. 갱신손실이란 두 개 이상의 트랜잭션이 동일한 데이터를 동시에 수정할 때, 한 트랜잭션의 변경 내용이 다른 트랜잭션에 의해 덮어쓰여져서 원래의 변경 결과가 사라지는 문제를 의미합니다.

실제 발생 가능한 시나리오:

  1. 유저(A)의 요청: 스킬을 사용해 200 SAL을 획득하려고 시도합니다. 시스템은 유저의 현재 잔액인 1,000 SAL을 조회합니다.
  2. 운영자(B)의 요청: 동일한 찰나에 CS 보상으로 500 SAL을 지급합니다. 시스템은 역시 현재 잔액인 1,000 SAL을 조회합니다.
  3. 유저(A)의 반영: 스킬 보상을 더한 1,200 SAL로 데이터 업데이트를 완료합니다.
  4. 운영자(B)의 반영: 자신의 조회 결과에 보상을 더한 1,500 SAL로 데이터 업데이트를 완료합니다.

결과: 유저가 스킬사용을 통해 얻은 200SAL은 최종 결과에 반영되지 못하고 누락됩니다. 최종 잔액은 유저의 활동 기록이 무시된 채 1,500SAL로 남게 되는 것입니다.

데이터 정합성이 무너진다는 것의 의미

이런 레이스 컨디션(Race Condition)은 단순히 데이터가 꼬이는 문제를 넘어, 서비스 전반에 기술적 부채와 운영 리스크를 남깁니다. 내가 열심히 스킬을 쓰고 쓰레기를 치웠는데 정작 보상이 제대로 들어오지 않는다면, 유저는 금세 서비스에 대한 신뢰를 잃게 될 것입니다. 특히 현금성 재화가 오가는 시스템에서 데이터 정합성은 결코 타협할 수 없는 기본 중의 기본입니다. 결국 저희 팀에게 동시성 제어는 단순한 성능 최적화가 아니라, 유저의 소중한 활동 내역을 데이터로 온전하게 지켜내기 위한 필수적인 안전장치였습니다.

어떤 방식을 고려했고, 왜 ‘낙관적 락’이었나요?

우리는 뱅크샐러드의 MSA 환경에서 선택 가능한 세 가지 주요 잠금 방식을 검토했습니다.

후보 1: 비관적 락 (Pessimistic Lock)

DB 레벨에서 SELECT ... FOR UPDATE를 통해 행을 선점하는 방식입니다.

후보 2: 분산 락 (Distributed Lock)

Redis(Redlock)나 ZooKeeper 같은 외부 인프라를 활용하여 서버 인스턴스 간 자원 접근을 제어합니다.

후보 3: 낙관적 락 (Optimistic Lock)

버전 번호(update_version)를 통해 수정 시점에 데이터가 변했는지 확인합니다.

💡 잠깐, 이 외에도 다른 락 방식이 있을까요?

위 방식 외에 특수한 상황에서 사용되는 기술들도 짧게 언급하자면 다음과 같습니다.

우리의 최종 선택: “낙관적 락”

‘일해라 김뱅샐’ 팀은 수많은 방식 중 낙관적 락을 최종 선택했습니다. 그 이유는 서비스의 구체적인 ‘데이터 액세스 패턴’과 ‘도메인 특성’에 있었습니다.

1. 낮은 충돌 확률

2. 인프라 복잡도 최소화

별도의 Redis 인프라를 구축하고 관리해야 하는 분산 락에 비해, 낙관적 락은 기존 DB 스키마에 update_version 컬럼 하나를 추가하는 것만으로 구현이 가능합니다. 시스템 복잡도를 낮게 유지하면서도 정합성을 챙길 수 있는 가장 효율적인 방법이었습니다.

3. 게임다운 ‘매끄러운 경험’을 위한 반응성 확보

게임에서 가장 중요한 것은 유저의 흐름이 끊기지 않는 것입니다. 수많은 유저가 동시에 접속하더라도, DB Lock 대기 때문에 화면이 멈칫하거나 반응이 늦어지는 일은 없어야 한다고 생각했습니다. 보상을 획득하는 즐거운 순간에 유저의 경험을 해치지 않도록, 낙관적 락을 통해 반응성을 유지하며 유저가 캐릭터의 성장에만 몰입할 수 있는 환경을 만들고 싶었습니다.

4. 복잡한 ‘재시도’ 로직이 필요 없는 서비스 구조

낙관적 락 도입을 망설이게 하는 가장 큰 요인은 보통 ‘충돌 시 어떻게 처리 할 것인가’ 에 대한 결정과 복잡도 관리입니다. 자칫하면 코드가 복잡해지고, 관리포인트가 늘어나기 때문이죠. 하지만 ‘일해라 김뱅샐’은 서비스 특성상 이러한 부담이 매우 낮았습니다.

1. 시간 차분(Time-delta)을 활용한 보상 이월 구조

유저가 벌어들인 수익 계산 로직은 개별 클릭 이벤트에 의존하는 ‘이벤트 적립’ 방식이 아니라, 마지막 업데이트 시점과 현재 시점 사이의 시간 간격(Time-delta)을 계산해 보상을 합산하는 상태 기반 정산 방식을 사용합니다.

💡 \text{Reward} = (T_{\text{current}} - T_{\text{last\_update}}) \times \text{Rate}_{\text{per\_second}}

2. 자기 수정(Self-correcting) 아키텍처를 통한 리소스 최적화

모든 요청을 성공시키기 위해 서버에서 복잡한 재시도 루프를 돌리는 것은 DB 커넥션과 CPU 자원 낭비일 수 있습니다. 저희는 이를 억지로 해결하기보다 시스템이 스스로 수렴하도록 설계했습니다.

결론

결국 저희는 복잡한 락 메커니즘을 도입하기보다, 도메인의 흐름을 이용해 기술적 문제를 우회한

“가장 단순하면서도 서비스 특성에 딱 맞는” 낙관적 락을 통해 성능과 정합성을 보장할 수 있도록했습니다.

어떻게 구현했나요?

우리는 DB 스키마에 update_version 이라는 필드를 추가하고, 애플리케이션 레이어에서 이를 검증하도록 구현했습니다.

1. Lock 의 범위를 최소화하는 스키마 설계

데이터베이스의 I/O 효율을 높이고 Lock 범위를 좁히기 위해 정적 데이터(character)와 동적 데이터(character_state)를 분리했습니다. 이는 단순히 테이블 수의 증가가 아니라, 인덱스 리프 노드의 경합을 줄이는 설계적 장치입니다.

// 업데이트가 빈번한 데이터들을 분리
CREATE TABLE `character_state` (
  `character_state_id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '캐릭터 상태 ID',
  `character_id` BIGINT NOT NULL,
  `current_sal` BIGINT NOT NULL COMMENT '경험치이자 자산인 SAL',
  `current_energy` BIGINT NOT NULL COMMENT '캐릭터가 돈을 벌어들일 수 있는 에너지(초 단위)',
  `update_version` BIGINT NOT NULL COMMENT '동시성 제어를 위한 버전 필드',
  `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`character_state_id`),
  UNIQUE KEY `idx_character_u1` (`character_id`)
) ENGINE = InnoDB;

2. 원자적 CAS(Compare-And-Swap) 구현

func (u *stateUpdater) UpdateState(ctx context.Context, exec boil.ContextExecutor, characterID int64, updateVersion int64, state *State) (int64, error) {
    newUpdateVersion := updateVersion + 1
    // ... 업데이트 필드 설정 ...

    numUpdated, err := mysql.CharacterStates(
        mysql.CharacterStateWhere.CharacterID.EQ(characterID),
        mysql.CharacterStateWhere.UpdateVersion.EQ(updateVersion), // 버전 체크!
    ).UpdateAll(ctx, exec, m)

    if numUpdated == 0 {
        return 0, ErrConcurrentStateUpdate // 충돌 감지
    }
    return newUpdateVersion, nil
}

🧐 [Tip] updated_at을 버전 필드로 쓰면 안 될까? 실무에서는 반드시 정수형 버전 필드를 따로 써야 합니다.

시간 정밀도의 한계 : DB 타임스탬프가 밀리초(ms) 단위일 경우, 동일 밀리초 내 두 번의 업데이트가 발생하면 충돌을 감지하지 못합니다.

클럭 스큐(Clock Skew): 분산 환경의 서버 간 미세한 시간 차이는 논리적 선후 관계를 보장하기 어렵게 만듭니다.

실전 운영 가이드

낙관적 락은 구현이 간단해 보이지만, 실제 분산 환경에서 운영하다 보면 예상치 못한 데이터 정합성 이슈나 성능 저하를 마주하게 됩니다. ‘일해라 김뱅샐’ 서비스의 안정성을 담보하기 위해 반드시 고려해야 할 실무 포인트들을 정리했습니다.

1) 복제 지연(Replication Lag)과 Stale Read 대응

분산 DB 아키텍처에서 Master(Primary)의 데이터 업데이트가 Replica(Secondary)로 전파되는 데에는 불가피한 시차가 발생합니다. 만약 낡은 데이터(Stale Data)를 읽어 수정을 시도하면 버전 충돌률이 급격히 높아집니다.

2) 재시도 전략: 충돌은 ‘에러’가 아닌 ‘제어 흐름’

낙관적 락에서 충돌(Conflict)은 시스템 장애가 아닌 정상적인 제어 흐름의 일부입니다. 따라서 모든 충돌에 무조건적인 재시도를 수행하기보다, 비즈니스 성격에 맞는 정교한 재시도 전략이 필요합니다.

💡 재시도 구현 시 검토해야 할 4원칙

마치며

지금까지 일해라 김뱅샐 팀이 데이터 무결성을 위해 낙관적 락을 도입한 배경과 실무적인 구현 과정을 살펴보았습니다.

실제 서비스 운영 이후, 다양한 환경의 유저들로부터 수많은 요청이 발생했지만 데이터 정합성 이슈는 단 0건이었습니다. 유저들은 게임의 재미에 몰입하면서도 자신의 활동에 따른 보상을 1원(SAL)의 오차도 없이 정확하게 받아보고있습니다.

비즈니스 요구사항은 언제나 변합니다. 저희 팀은 일해라 김뱅샐 의 성장 가능성과 범위가 무한하다는 것을 알기에 항상 ‘그때는 맞고, 지금은 틀리다’ 라는 마음가짐으로 지금 기획에 가장 최적화된 구현을 하지만 나중에 수정된 요구사항에도 유연하게 대응할 수 있는 구조를 고민하고있습니다.