코드 중복 없이 다양한 포커 변형 게임을 지원하는 포커 게임 엔진 설계 방법

코드 중복 없이 다양한 변형 게임(Texas Hold'em, Omaha, Short Deck, OFC)을 지원하는 포커 게임 엔진을 설계하려면, 변형 게임별 로직을 위한 전략 패턴 (Strategy Pattern) 기반의 **컴포넌트 기반 아키텍처 (Component-Based Architecture)**를 채택해야 합니다. 핵심 엔진은 보편적인 게임 흐름(카드 배분, 베팅 라운드, 팟 관리, 사이드 팟)을 처리하며, 변형 게임별 규칙은 플러그인 가능한 모듈로서 주입됩니다.

핵심 아키텍처: "유니버설 엔진 (Universal Engine)" 패턴

근본적인 과제는 _게임 상태 (game state)_와 _게임 규칙 (game rules)_을 분리하는 것입니다. 엔진은 "핸드 (Hand)"를 액션과 카드의 일반적인 시퀀스로 취급해야 하며, "변형 컨트롤러 (Variant Controller)"는 특정 규칙에 따라 해당 액션들을 해석해야 합니다.

1. 도메인 모델 (공통 레이어)

이 레이어는 모든 포커 변형 게임에 공통적인 엔티티(Entities)를 포함합니다. 이는 변형 게임과 관계없이 절대 변하지 않는 불변 데이터 구조 또는 상태 머신(State Machines)입니다.

• Card: 랭크(Rank), 슈트(Suit).
• Player: ID, 스택(Stack), 좌석 위치(Seat position), 현재 베팅액(CurrentBet).
• Pot: 메인 팟(Main pot), 사이드 팟(Side pots), 기여도 맵(Contribution map).
• GameRound: 프리플랍(Pre-flop), 플랍(Flop), 턴(Turn), 리버(River), 쇼다운(Showdown).
• Action: 유형(Check, Call, Raise, Fold, All-in), 금액(Amount), 타임스탬프(Timestamp).

2. 전략 패턴 (변형 추상화)

모든 포커 변형 게임이 반드시 구현해야 하는 추상 인터페이스(Abstract Interfaces)를 정의합니다. 엔진은 특정 변형 게임이 무엇인지 알지 못한 채 이러한 인터페이스를 호출합니다.

// 인터페이스 정의
interface IPokerVariant {
  getInitialDealCount(): number;
...

3. 구현 워크플로우

A. 상태 머신 및 이벤트 소싱 (State Machine & Event Sourcing)
핵심 엔진은 결정론적 상태 머신(Deterministic State Machine)을 실행합니다. 엔진 내부에는 if (variant == 'Holdem')과 같은 로직이 포함되지 않습니다. 대신, 현재 상태를 기반으로 이벤트를 방출(Emit)합니다.

1. 초기화 (Initialization): 엔진이 IPokerVariant 구현체(예: HoldemVariant)를 로드합니다.
2. 딜 페이즈 (Deal Phase): 엔진이 variant.getInitialDealCount()를 호출합니다. 플레이어들에게 해당 수만큼의 카드를 분배합니다.
3. 커뮤니티 카드 분배 (Community Dealing): 엔진이 variant.getCommunityCardDistribution()을 순회합니다. 3장의 카드(Flop)를 분배하고 일시 중지한 뒤, 1장(Turn)을 분배하는 등의 과정을 거칩니다.
4. 베팅 로직 (Betting Logic): 엔진은 "액팅 플레이어 (Acting Player)"와 "베팅 금액 (Bet Amount)"을 관리하지만, 유효성 (validity) 검증은 변형(variant)에 위임합니다.
   • 엔진 (Engine): "플레이어 X가 레이즈(Raise)를 원합니다."
   • 변형 (Variant): validateActions()가 해당 레이즈가 최소 요건을 충족하는지 확인합니다 (예: Hold'em에서의 2배 빅 블라인드 vs OFC의 특정 규칙).
5. 쇼다운 (Showdown): 엔진이 variant.calculateWinners()를 호출합니다.

B. 핸드 평가 엔진 (Hand Evaluation Engine)
이 부분은 가장 복잡한 파트입니다. 모든 변형 게임에 대해 로직을 하드코딩하지 마십시오.

• Hold'em/Omaha: 미리 계산된 룩업 테이블 (Lookup table) 또는 SIMD 최적화된 평가기 (예: replay-js 또는 poker-eval)를 사용합니다.
• OFC (Open Face Chinese): 로직이 완전히 다릅니다 (행 점수 계산). 이는 별도의 평가기 모듈로 취급됩니다.
• Short Deck: 표준 평가기에 전달하기 전에 랭크 매핑(Rank mapping)을 조정(2-5 제거)하고 플러시(Flush)/스트레이트(Straight) 규칙을 수정합니다.

엔진 루프를 위한 의사코드 (Pseudocode):

class PokerEngine {
  constructor(variant: IPokerVariant, roomConfig) {
    this.variant = variant;
...

기술적 심층 분석: 중복 방지

1. JSON/스키마를 통한 규칙 설정 (Rule Configuration via JSON/Schema)

로직을 하드코딩하는 대신, 스키마에 변형 규칙을 정의하십시오.

• 덱 구성 (Deck Composition): ["A", "K", "Q", ...] (표준) vs ["A", "K", "Q", "J", "T", "9", "8", "7", "6", "A"] (Short Deck).
• 핸드 순위 (Hand Rankings): 페어(Pairs), 스트레이트(Straights) 등에 대한 가중치 점수.
• 베팅 구조 (Betting Structures): 노 리밋 (No-limit), 팟 리밋 (Pot-limit), 픽스드 리밋 (Fixed-limit) 로직.

이를 통해 엔진을 다시 작성할 필요 없이, 설정 파일과 작은 평가기 오버라이드 (Evaluator override)를 로드하는 것만으로 새로운 변형 게임(예: "6+ Hold'em")을 추가할 수 있습니다.

2. 평가기 패턴 (The Evaluator Pattern)

고성능 핸드 평가 (Hand Evaluation)를 위해 룩업 테이블 (Lookup Table) 방식을 사용하십시오.

• 특정 변형 게임에 대해 가능한 모든 핸드 조합을 생성합니다.
• 7장의 카드(홀 카드 2장 + 보드 카드 5장)를 하나의 정수(Integer)로 해싱 (Hash)합니다.
• 미리 계산된 배열에서 핸드 강도를 조회합니다.
• 최적화 (Optimization): OFC와 같은 변형 게임의 경우, 평가는 단순히 "최상의 5장"을 찾는 것이 아니라 점수 산정 알고리즘을 따릅니다. 이를 엔진에 주입되는 별도의 서비스로 구현하십시오.

3. 네트워킹 및 실시간 동기화 (Networking & Real-Time Sync)

• 프로토콜 (Protocol): 낮은 지연 시간 (Low Latency)을 위해 WebSockets (Node.js의 Socket.IO 또는 raw ws) 또는 gRPC-Web을 사용하십시오.
• 상태 동기화 (State Synchronization): 서버가 신뢰할 수 있는 단일 원천 (Source of Truth)입니다. 클라이언트는 상태 업데이트가 아닌 의도 (Intent) (예: "100 레이즈")를 전송합니다.
• 결정론 (Determinism): 서버가 충돌하더라도, 동일한 IPokerVariant 로직을 사용하여 이벤트 로그를 재생 (Replaying)함으로써 (이벤트 소싱 (Event Sourcing)) 게임 상태를 재구성할 수 있습니다. 이는 규정 준수 및 분쟁 해결에 매우 중요합니다.

확장성 및 성능 고려 사항 (Scalability & Performance Considerations)

1. 메모리 관리 (Memory Management):
   • 게임 상태 객체는 가벼워야 합니다.
   • Node.js나 Go에서 실시간 게임의 랙을 유발할 수 있는 가비지 컬렉션 (Garbage Collection (GC)) 일시 중단을 방지하기 위해 Card 및 Action 객체에 **객체 풀링 (Object Pooling)**을 사용하십시오.
2. 동시성 (Concurrency):
   • Node.js에서 CPU가 병목 지점인 경우 (예: 공정성 감사 또는 AI 학습을 위해 수천 개의 핸드를 평가할 때), 핸드 평가를 위해 worker_threads를 사용하십시오.
   • Go에서는 각 테이블에 대해 고루틴 (Goroutines)을 활용하십시오. 엔진 로직은 CPU 집약적이지만, 액션당 I/O는 최소한입니다.
3. 데이터베이스 설계 (Database Design):
   • 핫 패스 (Hot Path) (Redis): 현재 게임 상태, 플레이어 액션 및 활성 팟 (Pot)을 저장합니다. 액션 로깅에는 Redis Streams를 사용하십시오.
   • 콜드 패스 (Cold Path) (PostgreSQL): 확정된 핸드 히스토리, 플레이어 통계 및 트랜잭션 로그를 저장합니다.
   • 샤딩 (Sharding): 부하 분산을 위해 table_id 또는 region별로 샤딩하십시오.

보안 및 담합 방지 (Security & Anti-Collusion)

• RNG 인증 (RNG Certification): 난수 생성기 (RNG, Random Number Generator)는 암호학적으로 안전해야 합니다 (예: Node.js의 crypto.randomBytes, Go의 하드웨어 시드 기반 math/rand/v2). 또한 독립적인 인증(GLI-11, eCOGRA)을 받아야 합니다.
• 카드 분배 (Card Distribution): 홀 카드 (hole cards)를 다른 플레이어에게 절대 전송해서는 안 됩니다. 서버는 클라이언트와 관련된 카드_만_을 전송해야 합니다.
• 담합 탐지 (Collusion Detection):
  • "좌석 이력 (Seat History)" 추적: 플레이어 A와 플레이어 B가 플레이어 C가 레이즈 (raise)할 때 항상 폴드 (fold)한다면 이를 플래그(flag) 처리합니다.
  • "칩 이동 (Chip Transfer)" 분석: 계정 간의 비정상적인 칩 흐름을 탐지합니다.
  • 이벤트 스트림을 소비하고 이상 탐지 알고리즘 (예: 클러스터링 분석 (clustering analysis))을 실행하는 백그라운드 분석 서비스를 구현합니다.

예시: "쇼트 덱 (Short Deck)" (6+ Hold'em) 추가하기

1. 덱 정의 (Define Deck): 2, 3, 4, 5를 제거합니다.
2. 규칙 재정의 (Override Rules):
   • 플러시 (Flush)가 풀하우스 (Full House)를 이깁니다.
   • A-6-7-8-9는 스트레이트 (straight, 최하위)입니다.
   • 앤티 (Ante)는 보통 필수입니다.
3. 주입 (Inject):
   • IPokerVariant를 구현하는 ShortDeckVariant 클래스를 생성합니다.
   • 새로운 핸드 계층 구조 (hand hierarchy)를 사용하도록 평가기 (evaluator)를 업데이트합니다.
   • 코어 PokerEngine 클래스에는 변경 사항이 없습니다.

이러한 아키텍처는 변형 규칙이 모듈화되어 있는 동안 코어 로직의 안정성을 유지하도록 보장하며, 전체 플랫폼의 안정성을 해치지 않고도 새로운 포커 게임을 신속하게 반복 개발하고 배포할 수 있게 해줍니다.