진행 기간: 2025.08 ~ 2025.10
슬롯 게임에서 시뮬레이터는 RTP(Return to Player)를 검증하는 도구다. 수십만~수백만 번의 스핀을 자동으로 돌려서 이론 RTP와 실제 RTP가 일치하는지 확인한다. 새 슬롯을 출시하기 전에 반드시 돌려야 한다.
문제는 슬롯이 늘어날수록 시뮬레이터 코드가 슬롯별로 각각 구현되면서 중복이 쌓였다는 점이다.
SlotXxxSimulator
- 스핀 루프
- RTP 누적 로직
- 잭팟풀 관리
- 결과 집계
↓ 슬롯마다 이 코드가 거의 동일하게 존재
SlotYyySimulator
- 스핀 루프 (동일)
- RTP 누적 로직 (동일)
...
공통 부분을 템플릿으로 뽑아서 슬롯별로 다른 부분만 구현하도록 바꿨다.
ReactiveSimulator (공통 템플릿)
├─ 스핀 실행 루프 (멀티스레드)
├─ RTP 누적 및 집계
├─ 잭팟풀 공유 관리
└─ 결과 리포트 생성
↑ (추상 메서드로 위임)
SlotXxxSimulator (슬롯별 구현)
├─ 초기 개인화 데이터 설정
├─ 특수 결과 집계 항목 정의
└─ 슬롯 특화 치트/시나리오 설정
ReactiveSimulator는 Reactor 기반의 비동기 스핀 루프를 제공한다. 슬롯은 AbstractSlotSimulator를 상속해서 게임별 로직만 구현하면 된다.
3, 5, 19, 21, 22, 25, 36, 47번
시뮬레이터를 멀티스레드로 돌리면 RTP가 이론값과 크게 다르게 나오는 현상이 있었다.
원인을 찾는 데 시간이 걸렸다. 스핀 로직 자체는 정상인데 집계 결과가 이상했다.
알고 보니 잭팟풀이 스레드별로 따로 생성되고 있었다.
// 문제: 스레드마다 새 잭팟풀 생성
Flux.range(0, spinCount)
.parallel()
.runOn(Schedulers.parallel())
.map(i -> {
JackpotPool pool = new JackpotPool(); // ← 스레드마다 별도 풀
return spin(pool);
})
// 수정: 공유 잭팟풀 사용
JackpotPool sharedPool = new JackpotPool(); // 공유
Flux.range(0, spinCount)
.parallel()
.runOn(Schedulers.parallel())
.map(i -> spin(sharedPool)) // ← 모든 스레드가 같은 풀 사용
잭팟은 전체 스핀에서 확률적으로 발생해야 하는데, 풀이 스레드별로 격리되면 각 스레드가 독립적으로 잭팟 카운터를 쌓는다. 잭팟 당첨이 실제보다 훨씬 자주 나오거나 적게 나오는 결과가 됐다.
공유 풀은 AtomicLong 등으로 스레드 안전하게 접근하도록 수정했다.
시뮬레이터 빈 등록이 안 되는 케이스가 있었다.
@ComponentScan 범위가 공통 템플릿 패키지를 포함하지 않아서 일부 시뮬레이터가 Spring 컨텍스트에 올라오지 않았다. 스캔 범위를 수정해서 해결했다.
바이피처(Buy Feature) 모드로 시뮬레이터를 돌릴 때 특정 상태에서 멈추는 현상이 있었다.
바이피처는 유저가 돈을 내고 즉시 피처(보너스 라운드)로 진입하는 기능이다. 시뮬레이터에서 이 상태를 처리하는 조건 검사에 바이피처 케이스가 누락되어 있었다.
// 수정 전: 기본 스핀만 처리
if (stage == SlotStageType.BASE) { ... }
// 수정 후: 바이피처 진입 케이스 포함
if (stage == SlotStageType.BASE || stage == SlotStageType.BUY_FEATURE_ENTRY) { ... }
RTP 검증 신뢰도 향상. 공통 집계 로직을 한 곳에서 관리하니 슬롯별로 집계 방식이 다른 문제가 없어졌다.
신규 슬롯 시뮬레이터 작성 시간 단축. 슬롯 특화 로직만 구현하면 되기 때문에 기존 대비 절반 이하 시간에 작성할 수 있게 됐다.
버그 발견이 빨라졌다. 시뮬레이터를 함께 만들면 게임 로직의 엣지 케이스가 스핀 루프를 돌리는 과정에서 드러난다. 특히 극저확률 이벤트(잭팟, 특수 피처)는 단위 테스트로 잡기 어렵고 시뮬레이터로 먼저 발견하는 경우가 많다.
Flux, Mono, Schedulers.parallel())