한 핸드의 승패 판정이 맞아도 지급액은 틀릴 수 있습니다. Baccarat payout calculation audit의 핵심은 카드 결과를 다시 예측하거나 플레이 전략을 찾는 것이 아니라, 이미 확정된 outcome에 대해 정해진 배당표, 커미션, push, refund, 사이드베트 규칙이 정산 엔진에 정확히 적용되었는지 독립적으로 재계산하는 것입니다.
이 글은 카지노 게임 분석가, iGaming QA 담당자, 컴플라이언스 검토자, 데이터 감사자가 바카라 정산 무결성을 검토할 때 사용할 수 있는 절차 중심의 가이드입니다. 실제 운영 시스템마다 필드명과 원장 구조는 다를 수 있으므로, 아래 내용은 특정 사이트의 내부 구조가 아니라 일반적인 감사 설계 기준으로 이해하는 것이 적절합니다.
Baccarat payout calculation audit가 실제로 확인하는 것
바카라 정산 감사는 “Banker가 이겼는가, Player가 이겼는가”를 판정하는 감사와 다릅니다. 결과 판정은 이미 game result log에 확정되어 있다고 보고, 감사자는 각 bet record가 해당 결과와 rule configuration에 따라 올바른 settlement로 변환되었는지 확인합니다.
감사 범위에는 bet type, stake, outcome, payout odds, Banker commission, Tie 발생 시 push 또는 refund, side-bet paytable, rounding, currency precision, settlement timestamp가 포함됩니다. 특히 payout이라는 필드가 순이익만 의미하는지, 반환 원금을 포함한 총 credit인지 시스템별로 다르기 때문에 감사 시작 전에 데이터 사전을 고정해야 합니다.
감사 기준이 되는 기본 바카라 정산 규칙
Player bet 정산
일반적인 바카라에서 Player bet은 Player가 승리하면 1:1, 즉 even money로 지급됩니다. 예를 들어 stake가 50이고 Player가 이기면 net win은 50이며, 반환 원금 50을 포함한 total credit은 100이 됩니다. Banker가 이기면 stake는 손실 처리되고, Tie가 나오면 Player bet은 대개 push 또는 refund로 처리됩니다.
Banker bet과 5% 커미션
Banker bet은 일반적으로 Banker 승리 시 1:1 gross win에서 5% commission을 차감합니다. stake 100, Banker 승리, commission rate 5%라면 gross win은 100, commission은 5, net win은 95입니다. 반환 원금까지 포함하면 total credit은 195가 됩니다. Tie가 발생하면 Banker bet도 일반적으로 push/refund 처리되어 반환 원금 100, net win 0으로 정산됩니다.
다만 commission-free baccarat에서는 “무커미션”이라는 명칭만 보고 같은 수식을 적용하면 안 됩니다. 일부 변형은 Banker total 6 등 특정 조건에서 reduced payout을 적용할 수 있으므로, commission-free 여부를 단일 플래그로만 보지 말고 variant, table_id, paytable_id, conditional payout rule을 별도 기준으로 감사해야 합니다.
Tie bet 정산
Tie bet은 Tie 결과 자체에 베팅한 항목입니다. 일반적으로 8:1 또는 9:1처럼 테이블 설정에 따라 배당이 달라질 수 있으며, 감사에서는 Tie payout을 항상 8:1로 하드코딩하면 안 됩니다. Banker/Player bet에서 Tie가 push인 것과 Tie bet이 winning payout 대상인 것은 반드시 분리해야 합니다. 기본 규칙과 odds 참고에는 Wizard of Odds의 바카라 자료처럼 공개된 확률·배당 레퍼런스를 보조 기준으로 활용할 수 있지만, 최종 기준은 운영 테이블의 configuration이어야 합니다.
Bet record에서 expected settlement를 만드는 수식
정산 감사는 운영 시스템의 settlement output을 그대로 신뢰하지 않고, 감사자가 독립 계산 엔진이나 스크립트로 expected value를 다시 산출한 뒤 actual settlement와 비교하는 방식으로 진행합니다. 기본 개념은 다음과 같습니다.
commission = banker_win_gross * commission_rate
expected_net = gross_win - commission - lost_stake_adjustment
expected_total_credit = returned_stake + expected_net여기서 gross_win은 배당률을 적용한 승리 금액이고, returned_stake는 push 또는 winning bet에서 원금이 반환되는 금액입니다. losing bet에서는 returned_stake가 0일 수 있습니다. free bet, promotional chip, bonus credit은 원금 반환 규칙이 다를 수 있으므로 별도 product rule로 분리해야 합니다.
신뢰할 수 있는 감사를 위한 최소 로그 필드
Bet log
Bet log에는 bet_id, player_id_hash, round_id, table_id, shoe_id, bet_type, stake, currency, odds 또는 paytable_id, bet timestamp가 필요합니다. 감사 관점에서는 player_id 원문보다 해시값이 적절할 수 있지만, 동일 플레이어의 balance reconciliation을 할 수 있을 정도의 일관성은 유지되어야 합니다.
Game result log
Result log에는 round_id, player_total, banker_total, winning_side, tie_flag, natural_flag, card_count, side-bet triggering condition이 포함되어야 합니다. 사이드베트 감사에서는 단순 winning_side만으로 충분하지 않습니다. 예를 들어 margin of victory, pair 여부, 특정 숫자 합계, natural win 여부가 payout condition이 될 수 있습니다.
Settlement log
Settlement log에는 settlement_id, bet_id, gross_win, commission, returned_stake, net_credit, balance_before, balance_after, settlement_status, void/refund flag가 필요합니다. balance_after가 balance_before와 transaction amount의 합으로 설명되지 않으면 payout 계산 오류가 아니라 원장 처리 오류일 수도 있으므로 transaction-level reconciliation이 필요합니다.
반드시 포함해야 할 테스트 케이스
기본 테스트는 Player win with Player bet, Banker win with Banker bet and 5% commission, Tie result with Player/Banker push, Tie bet win under 8:1 configuration, Tie bet win under 9:1 configuration, losing bet with no returned stake를 포함해야 합니다. 이 조합만으로도 가장 흔한 하드코딩 오류와 push 처리 오류를 상당수 발견할 수 있습니다.
실무에서는 edge case가 더 중요합니다. 5% commission을 소수 통화 단위에서 어떻게 반올림하는지, display currency와 ledger currency가 다른지, cancelled round가 settlement로 남는지, betting close 이후 late bet이 거절되었는지, duplicate settlement attempt가 있었는지 확인해야 합니다. corrected result 이후 re-settlement가 발생했다면 기존 settlement를 reverse한 뒤 새 거래를 생성했는지도 감사해야 합니다.
사이드베트는 paytable별로 따로 감사해야 합니다
바카라 사이드베트는 core Banker/Player/Tie 정산 로직과 분리해야 합니다. Dragon Bonus, Big/Small, Either Pair, Perfect Pair, Super 6, Dragon 7, Panda 8 같은 항목은 triggering condition과 payout odds가 서로 다릅니다. Wizard of Odds의 바카라 사이드베트 자료에서도 다양한 이벤트 조건과 paytable 차이를 확인할 수 있습니다.
따라서 감사 키는 side_bet_type + paytable_version + triggering_condition 조합으로 설계하는 것이 안전합니다. Dragon Bonus처럼 승리 마진이나 natural win 여부에 따라 payout이 달라지는 항목은 winning_side만으로 검증할 수 없습니다. 내부적으로는 바카라 사이드베트 구조를 별도 문서로 관리하고, paytable 변경 시점과 적용 round_id 범위를 함께 보관하는 방식이 좋습니다.
RNG 감사와 셔플 감사, 정산 감사는 증거가 다릅니다
RNG audit은 랜덤 결과 생성 또는 카드 순서 생성의 무작위성, 인증, 시드, 엔트로피를 검토합니다. Shuffle integrity audit은 shoe, card order, dealing sequence가 조작 없이 유지되었는지 확인합니다. 반면 payout calculation audit은 outcome이 확정된 뒤 정산 엔진이 paytable을 정확히 적용했는지 보는 산술·데이터 감사입니다.
세 감사는 서로 연결되어 있지만 테스트 케이스와 증거 자료가 다릅니다. RNG나 셔플 무결성이 적합하더라도 commission rounding이 틀리면 정산 오류가 발생할 수 있습니다. 반대로 payout audit이 깨끗하다고 해서 랜덤성 자체가 검증된 것은 아닙니다. 관련 검토 범위는 RNG 인증 관점과 셔플 무결성 검토로 분리해 문서화하는 것이 좋습니다.
실무 감사 워크플로
첫째, rule configuration을 동결합니다. table_id, jurisdiction, baccarat variant, commission rate, Tie odds, side-bet paytable version, rounding policy, currency precision을 특정 기간과 연결해야 합니다. 같은 테이블이라도 설정 변경 전후를 하나의 기준으로 섞으면 감사 결과가 왜곡됩니다.
둘째, 모든 bet을 독립적으로 재계산합니다. 운영 settlement table을 참조하지 않는 별도 계산 스크립트로 expected gross_win, commission, returned_stake, net_credit, total_credit을 생성합니다. 감사 로직 자체의 재현성을 위해 rule snapshot과 코드 버전도 보관해야 합니다.
셋째, expected와 actual을 비교합니다. 차이 금액, 차이 유형, bet_type, table_id, paytable_id, timestamp를 집계하고, 허용 오차는 문서화된 rounding policy가 있을 때만 인정해야 합니다. 넷째, aggregate보다 transaction-level exception을 먼저 조사합니다. 전체 합계가 우연히 맞아도 특정 플레이어에게 과소 또는 과대 정산이 발생할 수 있기 때문입니다.
간단한 바카라 정산 감사 계산 예시
| 케이스 | 기대 정산 |
|---|---|
| Player bet 50, Player wins | net win 50, returned stake 50, total credit 100 |
| Banker bet 100, Banker wins, 5% commission | gross win 100, commission 5, net win 95, returned stake 100, total credit 195 |
| Banker bet 100, Tie | returned stake 100, net win 0 |
| Tie bet 10, Tie pays 8:1 | net win 80, returned stake 10, total credit 90 |
위 표는 설명용 예시입니다. 실제 시스템에서 payout 필드가 net win인지 total credit인지에 따라 화면 표시와 ledger posting 방식은 달라질 수 있습니다. 감사자는 먼저 필드 정의를 확정한 뒤 같은 정의로 모든 테스트 케이스를 비교해야 합니다.
감사 중 자주 보이는 위험 신호
- Banker commission이 일부 hand에만 적용되거나 특정 통화에서 누락됩니다.
- Tie 결과에서 Banker/Player stake를 push가 아니라 손실로 처리합니다.
- Tie payout odds가 table configuration 또는 paytable_id와 다릅니다.
- side-bet paytable version이 round timestamp와 맞지 않습니다.
- commission rounding 방식이 table, currency, platform별로 일관되지 않습니다.
- 취소된 round가 유효 settlement로 남아 balance_after를 변경합니다.
- 재정산 시 기존 거래를 reverse하지 않고 중복 credit 또는 debit이 발생합니다.
핵심 정리
Baccarat payout calculation audit의 목적은 승패 예측이 아니라, 확정된 결과에 대해 계약된 payout rule이 정확히 적용되었는지 독립적으로 재계산하는 것입니다. Banker, Player, Tie의 기본 정산뿐 아니라 Banker 5% commission, Tie push, commission-free 변형, 사이드베트 paytable, rounding, void, re-settlement까지 포함해야 신뢰 가능한 감사가 됩니다.
좋은 감사는 단순히 “총 지급액이 맞다”에서 멈추지 않습니다. 각 bet_id 단위로 expected settlement와 actual settlement를 대조하고, 차이가 발생한 규칙·테이블·시간·통화·paytable version을 추적할 수 있어야 합니다. 이것이 바카라 정산 무결성을 데이터와 수식으로 입증하는 가장 실용적인 방법입니다.