📚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

BuyFeature 티켓 & 시나리오 스핀 구현

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

BuyFeature 티켓 & 시나리오 스핀 구현

진행 기간: 2024.12


배경

두 가지 플랫폼 공통 기능을 같은 시기에 개발했다. 둘 다 개별 슬롯이 아닌 슬롯 플랫폼 레벨에서 동작하는 기능이다.


BuyFeature 티켓

기능 개요

BuyFeature는 유저가 재화를 내고 보너스 라운드(피처)를 즉시 구매하는 기능이다. 여기에 티켓 기반 진입을 추가했다. 이벤트 등으로 티켓을 획득한 유저는 재화 없이 피처에 진입할 수 있다.

베팅 인덱스 상태 관리

티켓 기반 BuyFeature에서 가장 설계 고민이 필요했던 부분이다.

슬롯의 베팅 인덱스는 유저가 어떤 금액으로 배팅할지 결정하는 값이다. BuyFeature는 특정 베팅 인덱스 기준으로 피처에 진입한다. 문제는 피처가 끝나고 베이스로 복귀할 때 어떤 베팅 인덱스를 사용할지였다.

시나리오를 생각해보면:

유저 현재 베팅: 인덱스 3
→ 티켓으로 BuyFeature 진입 (인덱스 5 기준)
→ 피처 진행 중 ...
→ 피처 종료 → 베이스 복귀

Q: 복귀 시 베팅 인덱스는 3인가, 5인가?

처음에는 명확한 스펙이 없었다. 구현 방향을 결정해야 했다.

클라이언트가 BuyFeature를 요청할 때 넘긴 베팅 인덱스를 피처 진행 내내 유지하고, 복귀 시에도 그 값을 반환하도록 했다. 이유는 두 가지다.

첫째, 피처 보상은 진입 당시의 베팅 인덱스 기준으로 계산된다. 이 베팅 인덱스를 복귀 시에도 맞춰야 클라이언트가 "피처 결과 요약"을 정확하게 표시할 수 있다.

둘째, 유저가 어떤 베팅으로 돌아올지 예상하기 어렵게 만들면 혼란이 생긴다. 요청한 인덱스로 그대로 돌아오는 게 가장 일관성 있다.

// BuyFeature 진입 시 베팅 인덱스 저장
personalData.setBuyFeatureBetIndex(requestedBetIndex);

// 피처 종료 후 복귀
SpinResult result = baseResult.toBuilder()
    .betIndex(personalData.getBuyFeatureBetIndex())  // 진입 시 인덱스 유지
    .build();

지원하지 않는 슬롯에서의 요청

BuyFeature를 지원하지 않는 슬롯에 티켓 요청이 오면 명확한 에러코드를 반환했다. 이전에는 에러 처리가 불명확해서 클라이언트가 원인을 파악하기 어려웠다. 슬롯이 BuyFeature 옵션을 정의하지 않은 경우와 티켓 자체가 없는 경우를 구분해서 에러코드를 분리했다.


시나리오 스핀

기능 개요

미리 정의된 스핀 결과를 순서대로 재생하는 기능이다. 튜토리얼에서 특정 당첨 흐름을 보여주거나, 빅윈을 시연할 때 사용한다.

시나리오 정의:
  1번째 스핀: [A][A][A] → 소액 당첨
  2번째 스핀: [B][B][B] → 보너스 진입
  3번째 스핀: (보너스 스핀 결과)

실행 시: 유저의 스핀 요청 → 정의된 순서대로 결과 반환

슬롯별 구현 → 플랫폼 통합

기존에는 각 슬롯이 시나리오를 직접 처리하고 있었다.

[기존]
Slot-A: 자체 시나리오 로직
Slot-B: 자체 시나리오 로직
Slot-C: 자체 시나리오 로직
...

중복이 문제이기도 했지만 더 큰 문제는 일관성이었다. 슬롯마다 시나리오를 다르게 처리하면 튜토리얼 흐름에서 예측 불가한 동작이 나올 수 있다.

시나리오 스핀을 플랫폼 레벨로 끌어올렸다.

[통합 후]
ScenarioSpinHandler (플랫폼 공통)
  → 현재 시나리오 인덱스 관리
  → 다음 스핀 결과 반환
  → 완료 시 일반 스핀으로 전환
       ↑
각 슬롯은 시나리오 정의만 제공, 실행은 핸들러에게 위임

설계에서 주의한 것: buyFeature → free 변환

슬롯에 따라 시나리오 스핀이 BuyFeature 진입으로 정의된 경우가 있다. 실제 BuyFeature는 재화를 소모하는데, 튜토리얼/시나리오에서는 재화 소모 없이 처리해야 한다.

시나리오 실행 컨텍스트에서 BuyFeature 요청을 free 진입으로 변환하는 처리를 추가했다. 이 변환이 없으면 튜토리얼 중에 유저 재화가 차감되는 버그가 발생한다.

// 시나리오 스핀 컨텍스트에서의 BuyFeature 요청
if (context.isScenarioSpin() && spinType == BUY_FEATURE) {
    spinType = FREE_ENTRY; // 재화 차감 없이 피처 진입
}

튜토리얼 첫 요청 검증

통합 과정에서 엣지 케이스를 하나 발견했다. 유저가 이미 게임을 진행 중인 상태에서 잘못 튜토리얼이 시작되면 어떻게 되는가.

프리스핀 중이거나 링크게임 진행 중에 튜토리얼 요청이 오면 시나리오가 현재 게임 상태와 충돌한다.

튜토리얼 첫 요청 시 반드시 베이스 스테이지인지 검증하도록 추가했다. 진행 중인 게임이 있으면 명확한 에러로 거절한다.

// 튜토리얼 시작 전 상태 검증
if (currentStage != SlotStageType.BASE) {
    throw new SlotException(ErrorCode.TUTORIAL_NOT_ALLOWED_IN_PROGRESS);
}

배운 것

플랫폼 공통 기능은 일관성이 목적이다. 시나리오 스핀을 각 슬롯에서 직접 처리하면 구현은 쉽지만 동작이 슬롯마다 달라진다. 플랫폼으로 올리는 비용을 치르면 이후 슬롯에서는 시나리오 정의만 하면 된다.

상태 검증은 진입점에서. 튜토리얼 첫 요청 검증처럼, 어떤 흐름이 시작되는 지점에서 선제적으로 상태를 확인하면 내부 로직에서 예외 상황을 방어하는 코드를 줄일 수 있다.


사용 기술

  • Java 17, Spring Boot 3.x
  • JUnit 5
task 카테고리의 다른 글 보기수정 제안하기

댓글

댓글을 불러오는 중...
목차
  • BuyFeature 티켓 & 시나리오 스핀 구현
  • 배경
  • BuyFeature 티켓
  • 기능 개요
  • 베팅 인덱스 상태 관리
  • 지원하지 않는 슬롯에서의 요청
  • 시나리오 스핀
  • 기능 개요
  • 슬롯별 구현 → 플랫폼 통합
  • 설계에서 주의한 것: buyFeature → free 변환
  • 튜토리얼 첫 요청 검증
  • 배운 것
  • 사용 기술