D&D 전투 시스템을 테스트하는 방법: 모델 기반 테스트(MBT) 실전 가이드

던전 앤 드래곤에 소프트웨어 테스트를 적용한다고?

테스트 코드를 작성하는 건 개발자라면 누구나 하는 일인데요, 보통은 "이 함수에 A를 넣으면 B가 나와야 해"라는 식으로 케이스를 하나하나 짜잖아요. 그런데 만약 테스트해야 할 시스템이 너무 복잡해서 모든 경우의 수를 사람이 직접 나열하기 어렵다면 어떻게 할까요?

바로 이런 상황에서 등장하는 게 모델 기반 테스트(Model-Based Testing, MBT)예요. 최근 한 개발자가 이 기법을 던전 앤 드래곤(D&D)의 전투 시스템에 적용한 사례를 공개했는데, 테스트 방법론을 이해하는 데 정말 훌륭한 예시라서 소개해 드릴게요.

모델 기반 테스트가 뭔가요?

먼저 모델 기반 테스트가 뭔지부터 짚고 넘어갈게요. 일반적인 단위 테스트는 개발자가 "입력값 → 기대 결과"를 직접 작성하는 방식이에요. 그런데 MBT는 접근이 달라요. 시스템이 어떻게 동작해야 하는지를 "모델"로 먼저 정의하고, 그 모델에서 테스트 케이스를 자동으로 생성하는 거예요.

이게 뭐냐면, 쉽게 비유하자면 이래요. 일반 테스트가 "시험 문제를 선생님이 하나하나 손으로 만드는 것"이라면, 모델 기반 테스트는 "출제 규칙을 정해놓고 컴퓨터가 무한히 문제를 찍어내는 것"에 가까워요. 덕분에 사람이 미처 생각하지 못한 엣지 케이스도 잡아낼 수 있거든요.

D&D 전투 시스템, 왜 MBT가 필요할까

D&D의 전투 시스템은 겉보기엔 주사위 굴려서 때리는 단순한 게임 같지만, 실제로는 상태(state)가 굉장히 복잡해요. 캐릭터의 HP, 행동 순서(이니셔티브), 각종 버프와 디버프, 집중(Concentration) 상태, 반응(Reaction) 사용 여부 등이 서로 얽혀 있거든요.

이 프로젝트에서는 D&D 전투 규칙을 디지털로 구현한 뒤, 그 구현이 실제 D&D 규칙책(PHB, Player's Handbook)과 일치하는지를 검증하려고 했어요. 문제는 전투 한 라운드만 해도 가능한 상태 조합이 수천, 수만 가지라는 거예요. 이걸 사람이 일일이 테스트 케이스로 만드는 건 사실상 불가능하죠.

실제 구현 방식

이 개발자가 사용한 접근은 상태 머신(State Machine)을 모델로 활용하는 방식이에요. 상태 머신이란, 시스템이 가질 수 있는 모든 "상태"와 그 상태 사이의 "전이(transition)"를 정의한 모델인데요, D&D 전투를 예로 들면 이렇게 돼요.

전투의 각 단계가 상태가 되고, 플레이어나 몬스터의 행동이 전이가 되는 거예요. "내 턴 시작 → 이동 → 공격 → 턴 종료 → 다음 캐릭터 턴 시작" 이런 흐름이 하나의 경로가 되는 거죠. MBT 도구는 이 상태 머신을 탐색하면서 가능한 모든 경로를 자동으로 만들어내고, 각 경로마다 시스템이 올바르게 동작하는지 검증해요.

특히 재미있는 부분은 불변 조건(invariant)을 설정하는 방식이에요. 예를 들어 "HP는 절대 최대값을 초과할 수 없다", "죽은 캐릭터는 행동할 수 없다", "집중 상태에서 피해를 입으면 집중 판정을 해야 한다" 같은 규칙을 불변 조건으로 걸어놓으면, 어떤 시나리오에서든 이 규칙이 깨지는 순간을 자동으로 잡아내요.

기존 테스트 방식과 뭐가 다른가

전통적인 테스트와 비교하면 MBT의 강점이 확실해져요. 단위 테스트로 "파이어볼을 맞으면 8d6 데미지를 입는다"를 검증할 수는 있지만, "파이어볼을 맞은 캐릭터가 집중 중이었고, 내성 굴림에 실패하면 집중이 풀리고, 그로 인해 유지 중이던 주문도 해제된다"는 시나리오는 테스터가 직접 떠올려야 해요. MBT는 이런 연쇄 효과를 상태 탐색을 통해 자동으로 발견해 주거든요.

이 방식은 게임뿐만 아니라, 복잡한 비즈니스 로직이 있는 시스템에서도 똑같이 적용돼요. 쇼핑몰의 주문-결제-배송-환불 플로우, 금융 거래 시스템의 상태 관리 등 상태 전이가 복잡한 모든 곳에서 MBT가 위력을 발휘할 수 있어요.

업계에서의 MBT 위치

MBT는 사실 새로운 개념은 아니에요. 항공우주, 자동차, 의료기기 같은 안전이 중요한(mission-critical) 분야에서는 오래전부터 쓰이고 있었거든요. 다만 웹·앱 개발 쪽에서는 아직 많이 알려지지 않았어요. 이유는 간단한데, 모델을 만드는 초기 비용이 크기 때문이에요.

하지만 최근에는 XState 같은 상태 머신 라이브러리가 프론트엔드에서도 인기를 얻고 있고, Hypothesis(Python)나 fast-check(JavaScript) 같은 속성 기반 테스트(Property-Based Testing) 도구들도 MBT의 아이디어를 부분적으로 차용하고 있어요. MBT의 핵심 아이디어가 점점 주류 개발 문화에 스며들고 있는 셈이에요.

한국 개발자에게 주는 시사점

당장 프로덕션에 MBT를 도입하기는 쉽지 않을 수 있지만, 이 사례에서 가져갈 수 있는 인사이트는 분명해요. 첫째, 상태 머신으로 시스템을 모델링하는 습관 자체가 버그를 줄여줘요. 복잡한 비즈니스 로직을 상태 다이어그램으로 그려보는 것만으로도 빠진 케이스를 발견할 수 있거든요. 둘째, Hypothesis나 fast-check 같은 도구로 속성 기반 테스트부터 시작하면 MBT의 이점을 가볍게 맛볼 수 있어요. "이 함수의 결과는 항상 양수여야 한다" 같은 속성을 정의하고 랜덤 입력을 쏟아붓는 것만으로도 예상치 못한 버그를 잡아낼 수 있죠.

핵심 정리

복잡한 시스템일수록 "내가 생각한 케이스"만으로는 충분하지 않아요. 모델을 정의하고 기계에게 탐색을 맡기는 접근이 점점 더 중요해지고 있죠. 여러분의 프로젝트에서 상태 전이가 복잡한 부분이 있다면, 상태 머신 다이어그램부터 한번 그려보는 건 어떨까요?