1. 먼저 정한다 ― 게임을 만들 것인가, “이기는 연구소”를 만들 것인가
카드게임 시뮬레이터라고 하면 카드 이미지, 애니메이션, 보이스, 드래그 조작부터 떠올리기 쉽다.
하지만 “어떤 덱이 강한가”, “어떤 수가 더 잘 이기는가”를 연구하려면 대부분 필요 없다.
핵심은 다음 반복이다.
현재 상태
→ 합법 행동 생성
→ 행동 선택
→ 규칙대로 상태 갱신
→ 다음 상태
승패가 날 때까지 반복한다.
즉 필요한 것은 예쁜 게임 클라이언트가 아니라 숫자로 카드게임 세계를 움직이는 실험실이다.
좋은 기존 엔진이 있다면 재사용하고 연구층을 붙인다. 없다면 최소 규칙부터 만든다.
2. 코드보다 먼저 입력과 출력을 정한다
입력은 카드 DB, 40장 덱, 상대 덱, 선공/후공, seed, play policy, 환경 snapshot, 경기 수.
출력은 승패, turn 수, matchup 승률, 선후공 차이, 평균 승률, 최악 matchup, brick rate, key card 미획득 시 성능 저하, 자주 발생하는 실수, 카드 교체 결과.
이걸 먼저 정하지 않으면 “카드는 움직이는데 이 프로그램이 무슨 질문에 답하는지 모르는” 거대한 장난감이 된다.
시뮬레이터는 코드보다 질문에서 시작한다.
3. 카드 DB를 만든다 ― 카드 목록과 카드 행동은 다르다
카드에는 ID, 이름, 클래스, 비용, 타입, 공격력, 체력, 레어도, 세트, 텍스트, 진화 정보, 관련 카드, 태그를 구조화해서 저장한다.
JSON이나 SQLite면 충분하다.
하지만 “Fanfare: 4 damage”라는 텍스트를 저장했다고 해서 시뮬레이터가 완성된 것이 아니다.
누구를 대상으로 하는지, 대상이 없으면 어떻게 되는지, damage reduction은 어떻게 되는지, death trigger 순서는 무엇인지까지 구현해야 한다.
카드 DB 부서는 설명서를 모은다. 룰 엔진 부서는 설명서대로 세계를 움직인다.
직원 명부를 만들었다고 회사가 자동으로 일하지 않는다.
4. 화면이 아니라 게임 상태를 숫자로 표현한다
state에는 turn, active_player, leader_hp, PP, hand, deck, board, graveyard, Evolution, Super-Evolution, Crests, amulets, counters, temporary effects 같은 값을 저장한다.
화면에서 어디에 보이는지는 대부분 중요하지 않다.
공격 가능한지, Ward인지, 진화됐는지, 임시 효과가 언제 끝나는지가 중요하다.
좋은 상태 모델은 screenshot이 아니라 세계의 의미를 저장한다.
5. 룰 엔진은 “상태 A → 행동 → 상태 B” 기계다
카드 사용, 공격, Evolution, Super-Evolution, Act, target, turn end, draw, PP refresh, 승패 판정을 모두 state transition으로 처리한다.
엔진은 똑똑할 필요가 없다.
먼저 필요한 것은 바보가 합법적인 행동을 해도 세계가 정확히 움직이는 것이다.
룰과 AI를 섞지 않는다.
6. 카드 효과는 “공통 규칙 + 예외”로 만든다
공통 효과를 함수화한다: damage, heal, draw, buff, summon, destroy, banish, Ward, Storm.
대부분 카드를 공통 부품으로 표현하고, 정말 특수한 카드는 override로 처리한다.
unsupported, partial, runtime gap을 반드시 센다.
연구에서는 이상하게 대충 움직이는 것보다 미지원이라며 멈추는 것이 낫다.
7. 합법 행동 생성 ― 선택지에 없는 정답은 AI가 못 고른다
playable cards, targets, attacks, Evolution, Act, turn end를 생성한다.
필요하면 hold, draw-first, self-clear, board-slot-clearing도 후보가 되어야 한다.
평가기가 아무리 똑똑해도 정답이 candidate set에 없으면 선택할 수 없다.
먼저 묻는다.
정답 후보가 애초에 후보 목록에 있었나?
8. seed·replay·hash ― 같은 실험을 다시 만들 수 있어야 한다
seed를 고정하고 engine commit, card DB hash, deck hash, policy hash, environment hash, schedule hash, seed hash를 저장한다.
같은 조건이면 같은 경기를 재현해야 한다.
그렇지 않으면 “새 AI가 강해졌다”가 아니라 DB, 덱, 코드, 운이 바뀐 것일 수 있다.
연구에서 무서운 것은 무엇을 비교했는지 모르게 되는 것이다.
9. 첫 AI는 단순해도 된다 ― 기준 정책을 만든다
lethal 있음 → 끝낸다
곧 죽음 → 방어
저코스트/curve → 플레이
board 우세 → face
board 열세 → trade
이런 단순 policy를 reference policy로 고정한다.
목표는 완벽함이 아니라 비교 기준이다.
10. 인간 노하우는 절대명령이 아니라 prior로 넣는다
mulligan, hold, EP/SEP, combo setup, swing turn, hand cap, board slot, future lethal을 사용한다.
하지만 “항상 hold”로 만들면 필요한 순간에도 안 쓰고 죽는다.
hold_value, future_combo, survival, premature_spend 같은 점수 신호로 넣는다.
가이드는 답지가 아니라 탐색의 지도다.
11. 트리 탐색·빔 탐색·노드 예산
후보가 매 단계 10개면 10, 100, 1,000, 10,000으로 폭발한다.
그래서 depth, beam width, node budget, pruning을 쓴다.
지금 약하지만 두 턴 뒤 강한 setup line을 너무 일찍 버리면 combo deck이 망가진다.
immediate, future, survival, setup, lethal, resource value를 분리한다.
핵심은 중요한 미래를 너무 빨리 삭제하지 않는 것이다.
12. 상대 손패는 보지 않는다 ― belief·POMDP·Monte Carlo
상대 hidden hand를 policy에 직접 주면 치트다.
공개 정보로 AoE 30%, Ward 20%, 관련 카드 없음 50% 같은 가능한 세계를 만든다.
이것이 belief다.
숨은 정보가 있는 카드게임은 POMDP와 비슷하다.
여러 가상 손패를 sample하고 미래를 반복 시뮬레이션하면 Monte Carlo 접근이 된다.
13. 대량대전은 paired A/B 실험으로 설계한다
같은 덱, 상대, 선후공, seed를 주고 policy만 바꾼다.
quick → development → unseen holdout 순으로 진행한다.
대량 시뮬레이션의 목적은 공정한 비교에서 noise를 줄이는 것이다.
14. 승률만 보지 않는다
평균, meta-weighted, worst matchup, bottom average, variance, first/second gap, brick, key-card drop, average turn, confidence interval을 본다.
CVaR은 나쁜 쪽 결과를 본다.
Bootstrap과 McNemar는 paired A/B에 유용하다.
평균만 높은 학생이 아니라 필수과목에서 낙제하지 않는 학생을 찾는다.
15. 덱 최적화는 후보 공간을 압축하는 일이다
40장 모든 조합은 brute force할 수 없다.
실제 덱에서 시작해 1~3장 swap, role replacement, tech를 탐색한다.
Double Oracle은 강한 counter를 추가한다.
PSRO는 deck + policy를 전략으로 본다.
No-Regret는 regret을 줄인다.
Robust Optimization은 matchup floor를 지킨다.
16. 왜 졌는지 저장한다
action trace에 candidates, scores, choice, objective, EP/SEP reservation, early combo spend, missed lethal, hand burn, board lock을 저장한다.
Ablation은 component를 하나씩 끈다.
Counterfactual은 같은 public state에서 A와 B를 모두 시험한다.
이 과정을 통해 상관에서 인과에 가까운 증거로 간다.
17. 새 팩은 새 environment snapshot으로 관리한다
environment ID, format, legal sets, engine/DB/policy/deck/meta hash를 저장한다.
새 DB와 diff를 계산해서 바뀐 카드, 관련 덱, matchup을 찾는다.
한 장만 바뀌면 관련 구역만 다시 계산한다.
meta weight만 바뀌면 기존 결과를 재사용한다.
신팩마다 연구소를 철거하지 않는다.
18. 소프트웨어는 작고 CLI 중심으로 구성한다
upstream, deck, policy, simulation, diagnosis, statistics와 config, data, reports, docs, tests를 분리한다.
CLI는 status, doctor, db check, validate, simulate, experiment, optimize, diagnose, context 등으로 나눈다.
Git은 거대한 cache가 아니라 manifest와 압축된 결과를 저장한다.
GitHub는 연구소의 외부 기억이다.
19. 제로투원 구현 순서
1 card DB
2 최소 1경기 정확히 완주
3 legal actions/targets
4 seed/replay/hash
5 simple policy + 100 games
6 coverage
7 real decks + matrix
8 human prior
9 search + belief
10 paired A/B + holdout
11 deck optimization
12 diagnosis + expansion diff
처음부터 백만 게임과 모든 이론을 넣지 않는다.
1분에 1만 번 틀리는 기계를 만들지 마라.
20. 결론 ― 시뮬레이터는 연구공정을 만드는 일이다
DB는 기억, Rules Engine은 물리법칙, Policy는 두뇌, Search는 선읽기, Statistics는 성적표, Action Trace는 CCTV, Git은 연구노트, AI Agent는 연구원이다.
사람은 계속 묻는다.
“그 숫자, 진짜 믿어도 돼?”
처음엔 질주 한 방이 하고 싶었을 뿐이다.
끝에는 카드게임 AI 연구소가 생겼다.
마지막 행동은 그대로다.
Ward 치우고, 진화하고,
질주로 얼굴.
