fos-blog/study
01 / 홈02 / 카테고리
01 / 홈02 / 카테고리

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • langgraph 페이지로 이동
    • agents.md
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • AI 에이전트와 디자인의 새 컨벤션 — DESIGN.md, Google Stitch, Claude Design
    • 하네스 엔지니어링 실전 — 4인 에이전트 팀으로 코딩 파이프라인 구축하기
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
  • ai 페이지로 이동
    • agent 페이지로 이동
  • algorithm 페이지로 이동
    • live-coding 페이지로 이동
    • 분산 계산을 위한 알고리즘
  • architecture 페이지로 이동
    • [초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략
    • [초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리
    • 캐시 설계 전략 총정리
    • [초안] CJ푸드빌 커머스/F&B 도메인 설계 면접 대비 — 슬롯 경험을 주문·결제·쿠폰·매장 상태 설계로 번역하기
    • [초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기
    • [초안] 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비
    • [초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구
    • [초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드
    • [초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식
    • 디자인 패턴
    • [초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드
    • [초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가
    • 분산 트랜잭션
    • [초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리
    • [초안] F&B 쿠폰·프로모션·멤버십·포인트 설계
    • [초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비
    • [초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] F&B 이커머스 결제·환불·정산 운영 가이드
    • [초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기
    • [초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계
    • [초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략
    • [초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계
    • [초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • [초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기
    • [초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기
    • [초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure
    • [초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴
    • [초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩
    • [초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴
    • [초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • [초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
    • [초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • [초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • observability 페이지로 이동
    • [초안] 커머스/F&B 채널 장애 첫 5분과 관측성 기본기
    • Envoy Proxy
    • [초안] F&B / e-Commerce 운영 장애 대응과 모니터링 — 백엔드 관점 정리
    • Graceful Shutdown
  • finance 페이지로 이동
    • industry-cycle 페이지로 이동
    • investing 페이지로 이동
    • stock-notes 페이지로 이동
  • http 페이지로 이동
    • HTTP Connection Pool
  • interview 페이지로 이동
    • [초안] AI 서비스 팀 경험 기반 시니어 백엔드 면접 질문 뱅크 — Spring Batch RAG / gRPC graceful shutdown / 전략 패턴 / 12일 AI 웹툰 MVP
    • [초안] CJ푸드빌 디지털 채널 Back-end 개발자 직무 분석
    • [초안] CJ푸드빌 디지털 채널 Back-end 면접 답변집 — 슬롯 도메인 경험을 커머스/F&B 설계로 번역하기
    • [초안] F&B / e-Commerce 운영 모니터링과 장애 대응 인터뷰 정리
    • Observability — 면접 답변 프레임
    • [초안] 시니어 Java 백엔드 면접 마스터 플레이북 — 김병태
    • [초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • [초안] Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • [초안] JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • npm vs pnpm — 어떤 기준으로 선택했나
    • `setImmediate()`
  • kafka 페이지로 이동
    • [초안] Kafka 기본 개념 — 토픽, 파티션, 오프셋, 복제
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • [초안] Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • 메시지 전송 신뢰성
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • rabbitmq 페이지로 이동
    • [초안] RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • [초안] RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • security 페이지로 이동
    • [초안] 시니어 백엔드를 위한 보안 / 인증 스터디 팩 — Spring Security, JWT, OAuth2, OWASP Top 10
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • testing 페이지로 이동
    • [초안] 시니어 Java 백엔드를 위한 테스트 전략 완전 정리 — 피라미드부터 TestContainers, 마이크로벤치, Contract까지
  • travel 페이지로 이동
    • 오사카 3박 4일 일정표: 우메다 쇼핑, USJ, 난바·도톤보리, 오사카성
  • web 페이지로 이동
    • [초안] HTTP / Cookie / Session / Token 인증 기본기 — 레거시 JSP와 모바일 API가 공존하는 백엔드 관점
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/task/Slot 33 — 링크게임 + 디스크 배수 …
system

Slot 33 — 링크게임 + 디스크 배수 + 홀드&스핀 구현기

진행 기간: 2024.10 2024.12 --- 이 슬롯은 링크게임(Link Game) + 홀드&스핀(Hold & Spin) 이 핵심이다. 베이스 스핀에서 링크 심볼을 모아서 윈도우를 채우면 링크게임에 진입하고, 링크게임에서 추가 심볼을 모아 최종 보상을 결정한다. 윈도우가 완전히 링크 심볼로 채워지면 Grand Jackpot이 발생한다. 여기에 텀블링 메...

2026.04.19·5 min read·58 views

진행 기간: 2024.10 ~ 2024.12


어떤 슬롯인가

이 슬롯은 링크게임(Link Game) + 홀드&스핀(Hold & Spin) 이 핵심이다.

베이스 스핀에서 링크 심볼을 모아서 윈도우를 채우면 링크게임에 진입하고, 링크게임에서 추가 심볼을 모아 최종 보상을 결정한다. 윈도우가 완전히 링크 심볼로 채워지면 Grand Jackpot이 발생한다.

여기에 텀블링 메커니즘(당첨 심볼 제거 후 새 심볼 낙하)까지 더해진다. 두 가지 메커니즘이 섞이면서 구현 복잡도가 올라갔다.


1. 링크게임의 상태 관리

두 가지 심볼이 공존한다

링크게임의 핵심 난점은 고정된 심볼과 새로 생성된 심볼이 같은 윈도우에 공존한다는 점이다.

plaintext
[링크게임 진입 시점]
  위치 (0,0): 링크 심볼 ← 베이스에서 모은 것, 고정
  위치 (1,2): 링크 심볼 ← 베이스에서 모은 것, 고정
  나머지: BLANK ← 링크게임에서 새로 채워질 자리
 
[링크게임 스핀 후]
  위치 (0,0): 링크 심볼 (기존, 고정)
  위치 (1,2): 링크 심볼 (기존, 고정)
  위치 (2,1): 링크 심볼 ← 이번 스핀에서 새로 등장
  나머지: BLANK

이 구분이 중요한 이유가 있다. 링크게임 종료 조건은 이번 스핀에서 새로 등장한 링크 심볼이 없는 것이다. 고정 심볼과 새 심볼을 구분하지 않으면 기존 심볼을 매 스핀마다 새 심볼로 오인해서 종료 조건을 만족할 수 없다.

코드에서는 이걸 addedLinkSymbolCount로 처리한다. 이번 스핀에 새로 생긴 링크 심볼과 하이 심볼만 따로 집계하고, 그 합이 0이면 리트리거 없이 종료된다.

java
Triggers checkTriggers(int addedLinkSymbolCount, int totalReelSize, int currentLinkSymbolCount) {
    if (totalReelSize == currentLinkSymbolCount) {
        triggers.satisfyConditions(LINK_SYMBOL_IS_FULL);  // Grand Jackpot
    }
    if (addedLinkSymbolCount > 0) {
        triggers.satisfyConditions(LINK_RE_TRIGGER_KEY);  // 새 심볼 있으면 계속
    }
    return triggers;
}

초기 윈도우 처리

베이스에서 링크게임으로 진입할 때 윈도우 설정도 주의해야 한다.

링크게임 진입 시 링크 심볼이 없는 자리는 BLANK로 채워야 한다. 처음 구현에서는 링크 심볼 위치를 제외하지 않고 전체를 BLANK로 초기화해버렸다. 베이스에서 모은 링크 심볼이 사라지는 버그였다.

java
// 잘못된 초기화
window.fillAll(BLANK);
 
// 올바른 초기화: 링크 심볼 위치는 유지
for (Position pos : window.allPositions()) {
    if (!fixedLinkPositions.contains(pos)) {
        window.set(pos, BLANK);
    }
}

2. 종료 조건 검사 순서

링크 심볼이 윈도우를 가득 채우면 즉시 Grand Jackpot이 발생한다. 이 검사를 보상 계산 이후에 하면 문제가 생긴다.

스핀 결과를 반영한 뒤 보상을 누적하고, 그 다음에 Grand Jackpot 여부를 판단하면 일반 보상과 잭팟 보상이 중복으로 계산될 수 있다.

종료 조건 검사를 보상 계산보다 먼저 실행하도록 순서를 앞당겼다.

java
// 새 링크 심볼 반영
fixedLinkPositions.addAll(newLinkPositions);
 
// 먼저 종료 조건 검사 (check-before-mutate)
if (isFullyFilled(window, fixedLinkPositions)) {
    return LinkGameResult.grandJackpot(fixedLinkPositions);
}
 
// 그 다음에 보상 계산
accumulateRewards(newLinkPositions);

3. 텀블링 중 링크 심볼 위치 추적 — 이벤트 리스너 패턴

베이스 스핀에서 텀블링이 일어나면 심볼이 아래로 낙하(캐스케이딩)한다. 링크 심볼도 예외가 아니다. 링크 심볼이 이동하면, 나중에 링크게임으로 가져갈 위치 정보도 함께 업데이트해야 한다.

처음에는 캐스케이딩이 끝난 뒤 전체 윈도우를 다시 스캔해서 링크 심볼 위치를 재수집했다. 동작은 했지만, 캐스케이딩 로직과 링크 심볼 추적 로직이 타이밍으로 결합되어 있었다.

이를 이벤트 리스너로 분리했다.

java
final CascadingEventListener cascadingEventListener =
    (currentX, currentY, nextY, symbolCode) -> {
        if (SymbolEnum.isLinkSymbol(symbolCode, BASE.getCode())) {
            final LinkSymbol linkSymbol = resultLinkSymbols.getLinkSymbol(currentPosition);
            resultLinkSymbols.remove(currentPosition);
            resultLinkSymbols.add(cascadingPosition, linkSymbol);  // 위치 변경 추적
        }
    };

캐스케이딩 로직은 심볼이 어디서 어디로 이동했는지 이벤트를 발행하고, 링크 심볼 추적은 그 이벤트를 구독해서 위치를 갱신한다. 캐스케이딩 로직이 링크 심볼의 존재를 알 필요가 없다.


4. 하이 심볼 개수 제한 — 밸런싱을 코드로 강제하기

링크게임에서 하이 심볼(H01, H02, H03)은 디스크 배수를 크게 올리는 고가치 심볼이다. 확률 테이블만으로 이를 조절하면 기댓값은 맞출 수 있지만, 특정 스핀에서 하이 심볼이 몰려 나오는 극단적인 경우를 막을 수 없다.

하드 캡(hard cap) 을 추가했다.

java
if (SymbolEnum.isHighSymbol(decidedSymbol)) {
    final int current = currentHighSymbolCounts.getOrDefault(decidedSymbol, 0);
    final int max = linkHighSymbolMaxCounts.getOrDefault(decidedSymbol, Integer.MAX_VALUE);
 
    // 최대 개수 초과 시 링크 심볼로 강제 치환
    if (current >= max) {
        decidedSymbol = SymbolEnum.LINK.getCode();
    }
}

확률로 조절하기 어려운 극단값을 코드 레벨 상한선으로 막는다. 밸런싱 의도가 런타임에서 보장된다.


5. 뱃지 심볼별 디스크 배수 증가 방식

베이스 스핀에서 H01, H02, H03 심볼이 나오면 디스크 배수가 올라간다. 세 심볼의 증가 방식이 서로 다르다.

  • H01: 고정값으로 증가. 예측 가능한 안정적인 상승.
  • H02: 알리아스 테이블에서 랜덤으로 증가량을 결정.
  • H03: 어느 릴(열)에서 나왔느냐에 따라 올라가는 디스크가 다르다.
java
switch (symbolEnum) {
    case H01 -> increments = personalData.incrementByH01(diskMaxMultiplier);
    case H02 -> {
        final int count = h02DiskIncrementAliasTable.pickToInt();
        increments = personalData.incrementByH02(randomUtil, count, diskMaxMultiplier);
    }
    case H03 -> {
        final int reelIndex = visibleWindowPosition.x();
        increments = personalData.incrementByH03(reelIndex, diskMaxMultiplier);
    }
}

심볼마다 다른 증가 방식은 게임 내 전략 요소다. 동일한 목적(디스크 배수 증가) 뒤에 다른 전략을 두는 구조다.


6. 바이피처 진입 조건 처리

일반적으로 링크게임 진입에는 최소 디스크 배수 조건이 있다. 바이피처(BuyFeature)는 유저가 직접 돈을 내고 링크게임에 바로 진입하는 것이기 때문에, 이 조건을 완화해야 했다.

바이피처 진입 시 디스크 테이블을 최소 배수값으로 초기화하는 방식으로 처리했다.

java
void handleBuyFeatureOption1(final int totalDiskValue, final int minimumDiskValue, ...) {
    // 모든 릴을 최소 배수로 초기화 → 조건 자동 충족
    Arrays.fill(buyFeatureDiskTable, minimumDiskValue);
}

바이피처와 일반 스핀의 분기를 한 곳에서 처리해서 조건이 흩어지지 않도록 했다.


7. 시뮬레이터

링크게임은 베이스 스핀과 별도 루프로 진행된다. 시뮬레이터도 이 구조를 따라야 한다.

plaintext
베이스 스핀 루프
  → 링크게임 진입 조건 충족
  → 링크게임 루프 (별도)
  → 결과 집계 (링크게임 보상 포함)
  → 다시 베이스 스핀 루프

처음에 베이스 스핀 RTP만 집계했다가 링크게임 보상이 누락됐다. 링크게임 결과를 베이스 루프에서 합산하도록 수정했다.

릴별 평균 디스크 배수도 시뮬레이터 항목으로 추가했다. 어떤 릴에서 디스크 배수가 높게 나오는지 분포를 파악하는 게 밸런싱에 필요한 데이터였다.


배운 것

스테이지 간 상태가 이어지는 구조는 심볼의 출처를 명시적으로 관리해야 한다. 고정된 심볼과 새로운 심볼을 구분하지 않으면 종료 조건, 보상 계산, 윈도우 초기화 모든 곳에서 버그가 생긴다.

상태를 바꾸기 전에 조건을 먼저 확인해야 한다. 종료 조건 검사를 보상 계산 이후로 미루면 중복 계산이 생긴다. check-before-mutate 순서가 여기서 중요하다.

확률 테이블만으로는 극단값을 막을 수 없다. 기댓값은 확률로 조절하되, 허용할 수 없는 극단값은 코드 레벨 상한선으로 보장하는 것이 안전하다.

로직 간 결합은 이벤트로 끊는다. 캐스케이딩 로직이 링크 심볼을 직접 알 필요가 없다. 이벤트 리스너로 분리하면 각 로직이 자기 책임에만 집중할 수 있다.


사용 기술

  • Java 17, Spring Boot 3.x
  • JUnit 5
on this page
  • 01어떤 슬롯인가
  • 021. 링크게임의 상태 관리
  • 두 가지 심볼이 공존한다
  • 초기 윈도우 처리
  • 032. 종료 조건 검사 순서
  • 043. 텀블링 중 링크 심볼 위치 추적 — 이벤트 리스너 패턴
  • 054. 하이 심볼 개수 제한 — 밸런싱을 코드로 강제하기
  • 065. 뱃지 심볼별 디스크 배수 증가 방식
  • 076. 바이피처 진입 조건 처리
  • 087. 시뮬레이터
  • 09배운 것
  • 10사용 기술

댓글 (0)