진행 기간: 2025.07 2025.10 --- 슬롯 게임에서 RTP(Return to Player) 는 유저가 베팅한 금액 대비 돌려받는 비율이다. 법적·서비스적으로 일정 RTP를 보장해야 하는데, 순수 확률 기반 슬롯은 짧은 세션에서 RTP 편차가 크다. 운이 나쁜 유저는 오랫동안 보상을 못 받을 수 있다. RCC(RTP Cache Control) 는...
진행 기간: 2025.07 ~ 2025.10
슬롯 게임에서 RTP(Return to Player) 는 유저가 베팅한 금액 대비 돌려받는 비율이다. 법적·서비스적으로 일정 RTP를 보장해야 하는데, 순수 확률 기반 슬롯은 짧은 세션에서 RTP 편차가 크다. 운이 나쁜 유저는 오랫동안 보상을 못 받을 수 있다.
RCC(RTP Cache Control) 는 이 문제를 해결하기 위해 설계한 시스템이다. 핵심 아이디어는 다음과 같다.
백그라운드에서 "좋은 결과"를 미리 생성해서 DB에 캐시해두고, 유저가 RTP 보장이 필요한 시점에 캐시에서 꺼내 제공한다.
유저 입장에서는 일반 스핀과 완전히 동일하게 보인다.
유저 스핀 요청
│
▼
RccHandler
├─ [튜토리얼/치트 스핀] → 패스 (RCC 발동 안 함)
├─ [시뮬레이터 실행 중] → 패스
│
├─ [일반 스핀, 캐시 있음] → 캐시된 결과 반환
│ └─ 비동기: 다음 캐시 생성 트리거
│
└─ [일반 스핀, 캐시 없음] → 일반 스핀 결과 반환
└─ 비동기: 캐시 생성 트리거
RccCacheGenerator (백그라운드)
├─ RccSpinResultAnalyzer → 어떤 결과를 캐시할지 판단
└─ 스핀 시뮬레이션 → 조건 충족 결과만 DB 저장com.nhn.slot.rcc/
├── application/
│ ├── RccCacheGenerator.java # 캐시 생성 담당
│ └── RccCacheQueryService.java # 캐시 조회/사용
├── domain/
│ ├── RccSpinResult.java # 캐시된 스핀 결과 도메인 객체
│ ├── RccCacheType.java # 캐시 타입 열거형
│ └── RccSpinResultAnalyzer.java # 슬롯별 캐시 조건 판단 (인터페이스)
└── infrastructure/
├── RccCacheQueryRepository.java # 캐시 조회 + 소비
└── RccCacheManagementRepository.java # 캐시 저장/관리슬롯별로 어떤 결과를 캐시할지 기준이 다르기 때문에 RccSpinResultAnalyzer를 인터페이스로 추상화했다. 슬롯마다 구현체를 만들어 주입한다.
슬롯 내부 구조가 달라서 일괄 적용이 안 됐다. 하나씩 확인하면서 붙여야 했다.
| 슬롯 | 특이사항 |
|---|---|
| 3, 22번 | 가장 먼저 대응. 표준 구조라 기준이 됐다 |
| 8, 25번 | 구조는 동일, 설정값 차이만 있었다 |
| 2, 7번 | 특수 개인화 데이터 구조를 써서 캐시 생성 시 개인화 데이터 접근 방식을 별도 처리했다 |
| 33번 | 개인화 데이터 슬롯이라 RccSpinResultAnalyzer 구현체를 따로 만들었다 |
RCC 스핀 중 잭팟이 당첨되는 케이스를 처음엔 고려하지 못했다.
캐시된 스핀 결과를 사용할 때 잭팟 당첨이 포함되어 있으면, 어떤 잭팟 서비스를 써야 하는지가 문제였다. 게임 모드(일반/특수 등)마다 다른 잭팟 서비스를 써야 했다.
캐시 사용 시: GameMode에 맞는 JackpotService를 가져와서 처리
→ EPIC_WIN이 쌓이지 않는 슬롯: NoOpJackpotService 사용NoOpJackpotService는 잭팟 처리를 아무것도 하지 않는 구현체다. 처음에는 이게 필요한 슬롯이 있다는 걸 몰라서 예외가 났다.
"지금 얼마나 더 캐시를 만들어야 하는가"를 판단하는 쿼리가 인덱스를 타지 않고 있었다.
-- 문제: game_id, bet_index, cache_type 복합 조건인데 인덱스 없음
SELECT COUNT(*) FROM rcc_cache WHERE game_id = ? AND bet_index = ? AND cache_type = ? AND used = false쿼리를 다듬고 복합 인덱스를 추가했다. 캐시 생성은 백그라운드에서 계속 돌기 때문에 이 쿼리가 느리면 CPU를 잡아먹는다.
시뮬레이터를 돌릴 때 RCC 캐시가 같이 생성되고 있었다. 시뮬레이터는 수만 번 스핀을 돌리는데, 그동안 쓸모없는 캐시가 계속 쌓였다.
RccHandler에 시뮬레이터 실행 여부를 판단하는 분기를 추가했다.
보너스 스테이지로 진입하는 결과를 어떤 조건으로 캐시할지가 명확하지 않았다.
결국 winLevel에 해당하는 캐시 중 다음 상태가 BASE인 것이라는 조건으로 정리했다. 보너스에서 보너스로 이어지는 결과는 캐시하지 않는다.
RTP-FREE 진행 중에 다른 타입으로 치환 요청이 오면 RTP-FREE 상태를 유지해야 한다. 이 케이스를 처음에 놓쳐서 버그가 났다. 상태 전이 조건에 분기를 추가했다.
log_slot_play 테이블에 RCC 관련 컬럼을 추가해서 어떤 스핀이 캐시를 사용했는지 추적할 수 있게 했다.
RccCacheStatisticsService를 만들어 캐시 부족이 발생하는 슬롯/베팅 인덱스 조합을 모니터링할 수 있게 했다. 캐시 생성 속도가 소진 속도를 못 따라가는 상황을 감지하기 위해서다.
비동기 설계가 핵심이다. 캐시 생성을 동기로 하면 스핀 응답 시간에 직접 영향을 준다. 백그라운드 비동기 생성이어야 유저 경험에 영향 없이 캐시를 미리 준비할 수 있다.
슬롯별 추상화는 나중에 하면 늦다. RccSpinResultAnalyzer를 처음부터 인터페이스로 만들어둔 덕분에 슬롯마다 다른 로직을 조건 분기 없이 깔끔하게 처리할 수 있었다.
동시성은 DB로 막는다. 캐시 생성이 여러 인스턴스에서 동시에 일어날 수 있다. 낙관적 락을 고려했지만, 생성 빈도 특성상 충돌이 드물어 DB 유니크 키 + 예외 처리 조합으로 충분했다.
@Async, 스레드풀 설정