📚FOS Study
홈카테고리
홈카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • agents 페이지로 이동
    • custom-agents 페이지로 이동
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • 멀티모달 LLM (Multimodal Large Language Model)
  • architecture 페이지로 이동
    • 디자인 패턴
    • 분산 트랜잭션
    • 슬롯 게임 엔진 고도화 — 2025년 회고
  • css 페이지로 이동
    • FlexBox 페이지로 이동
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야할까?
    • 인덱스 - DB 성능 최적화의 핵심
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • monitoring 페이지로 이동
  • go 페이지로 이동
    • Go 언어 기본 학습
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • 210812 페이지로 이동
    • 뱅크샐러드 AI Native Server Engineer
    • CJ 올리브영 지원 문항
    • CJ 올리브영 커머스플랫폼유닛 Back-End 개발 지원 자료
    • 마이리얼트립 - Platform Solutions실 회원주문개발 Product Engineer
    • NHN 서비스개발센터 AI서비스개발팀
    • nhn gameenvil console backend 직무 인터뷰 준비
    • 면접을 대비해봅시다
    • Tossplace Node.js Developer
    • 토스플레이스 Node.js 백엔드 컬처핏
  • java 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • OpenTelemetry 란 무엇인가?
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • Data_Structures_and_Algorithms 페이지로 이동
    • Heap 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node.js
    • npm vs pnpm 선택기준은 무엇인가요?
    • `setImmediate()`
  • kafka 페이지로 이동
    • Kafka 기본
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • 메시지 전송 신뢰성
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • react 페이지로 이동
    • JSX 페이지로 이동
    • VirtualDOM 페이지로 이동
    • v16 페이지로 이동
  • redis 페이지로 이동
    • Redis
    • Redis Hash와 Lua 스크립트로 잭팟 누적 구현하기
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
📚FOS Study

개발 학습 기록을 정리하는 블로그입니다.

바로가기

  • 홈
  • 카테고리

소셜

  • GitHub
  • Source Repository

© 2025 FOS Study. Built with Next.js & Tailwind CSS

목록으로 돌아가기
📁task/ nsc-slot

전역 개인화 데이터 (Global Personal Data) 구조 설계

약 3분
2026년 3월 22일
2026년 3월 22일 수정
GitHub에서 보기

전역 개인화 데이터 (Global Personal Data) 구조 설계

진행 기간: 2025.09


배경

슬롯 게임에서 개인화 데이터(Personal Data) 는 유저가 게임을 플레이하면서 쌓이는 상태 정보다. 예를 들어 "코인을 몇 개 모았는지", "현재 어떤 피처가 진행 중인지" 같은 것들이다.

기존 구조는 개인화 데이터를 베팅 인덱스별로 저장했다.

SlotPersonalData (기존)
  game_id: 36
  user_id: xxx
  bet_index: 2     ← 베팅 단계별로 데이터가 따로 존재
  data: { coinCount: 15 }

베팅을 바꾸면 해당 베팅 인덱스의 데이터를 새로 만든다. 이전 베팅의 데이터는 건드리지 않는다.

이 방식이 맞지 않는 케이스가 생겼다. 특정 슬롯에서 베팅이 바뀌어도 유지되어야 하는 상태가 있었다. 코인 레벨 같은 것은 유저가 어떤 베팅으로 게임하든 하나여야 한다.


설계

베팅 인덱스에 종속되지 않는 전역 개인화 데이터 구조를 기존과 별개로 만들었다.

GlobalPersonalData (신규)
  game_id: 36
  user_id: xxx
  ← bet_index 없음
  data: { coinLevel: 3, totalCoinCount: 1240 }

기존 SlotPersonalData는 그대로 두고, 슬롯이 두 가지를 선택해서 쓸 수 있도록 했다.

// 슬롯별로 어떤 데이터를 전역으로 관리할지 직접 정의
public interface GlobalPersonalDataProvider {
    GlobalPersonalData createInitial(UserId userId);
    GlobalPersonalData migrate(SlotPersonalData legacyData); // 기존 데이터 마이그레이션용
}

마이그레이션이 핵심이었다

새 구조를 도입하면서 가장 신경 쓴 부분이 기존 유저 처리다.

이미 게임을 플레이해서 베팅 인덱스별 데이터가 있는 유저들이 있다. 이들이 처음 전역 데이터를 요청할 때 어떻게 처리할 것인가.

처음에는 "기존 데이터 없으면 초기값으로 생성"으로 단순하게 짰는데, 두 가지 케이스를 분리해야 했다.

첫 접근 케이스 1: 기존 베팅별 데이터가 있는 유저
  → 가장 최근 베팅 인덱스 데이터를 기준으로 전역 데이터 생성 (마이그레이션)

첫 접근 케이스 2: 아예 처음 플레이하는 신규 유저
  → 초기값으로 생성

케이스 2를 놓쳤다가 신규 유저가 게임에 진입할 때 오류가 났다. "기존 데이터가 없으면 마이그레이션 대상"으로 잘못 분류하면서 NPE가 발생했다. 신규 유저 분기를 명시적으로 처리하면서 해결했다.

// 분기 처리
if (hasLegacyData(userId, gameId)) {
    return migrate(legacyPersonalData);  // 케이스 1
} else {
    return createInitial(userId);        // 케이스 2
}

적용 슬롯

슬롯전역으로 관리한 데이터특이사항
2, 7번개인화 데이터 전반RCC 대응을 위한 접근 방식 변경 병행
24번개인화 데이터 전반타입 정의 오류 수정
36번코인 레벨 관련 데이터신규 구조로 직접 구현

24번에서 타입 정의 오류가 있었다. 전역 데이터에서 Long이어야 할 필드가 Integer로 정의되어 있어서, 큰 값이 들어오면 오버플로우가 났다.


시뮬레이터 대응

시뮬레이터는 매 실행마다 초기 상태에서 시작해야 한다. 스핀을 수만 번 돌리는데 이전 실행의 개인화 데이터가 남아 있으면 RTP 계산이 틀린다.

기존 베팅별 개인화 데이터는 시뮬레이터에서 초기화하고 있었는데, 전역 개인화 데이터 초기화 코드가 빠져 있었다. 시뮬레이터 실행 전 초기화 로직에 전역 데이터도 포함시켰다.


배운 것

상태 구조를 바꿀 때 마이그레이션은 기능과 동시에 설계해야 한다. 나중에 붙이려 하면 기존 유저 케이스를 빠뜨리기 쉽다. 특히 "데이터가 없는 유저"가 신규인지 마이그레이션 전 유저인지를 명확히 구분하는 게 중요하다.

사용 기술

  • Java 17, Spring Boot 3.x
  • MySQL 8.x (JPA)
  • Flyway (스키마 마이그레이션)
task 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • 전역 개인화 데이터 (Global Personal Data) 구조 설계
  • 배경
  • 설계
  • 마이그레이션이 핵심이었다
  • 적용 슬롯
  • 시뮬레이터 대응
  • 배운 것