복잡한 게임에서 자동화 테스트를 가로막는 것은 정해진 동작을 반복하는 기술 자체가 아니다. 계단과 점프대가 뒤섞인 지형, 한꺼번에 몰려드는 수십 마리의 적, 업데이트 과정에서 조금씩 달라지는 데이터처럼 예측하기 어려운 변수가 테스트 봇을 멈춰 세운다.
'퍼스트 디센던트' 엔진팀은 이러한 환경에서 매번 동일한 플레이를 완벽하게 재현하는 대신, 문제가 발생하더라도 테스트를 중단하지 않고 끝까지 데이터를 수집하는 방향을 선택했다.
강장훈 넥슨게임즈 퍼스트 디센던트 프로그램실 엔진팀 개발자는 17일 넥슨 사옥에서 열린 넥슨 개발자 콘퍼런스 2026 둘째 날 발표 세션에서 '복잡한 게임에 자동화 테스트 하기 - 퍼스트 디센던트 맞춤 Auto Play Test tool 제작기'를 주제로 무대에 올랐다.
강 개발자는 PC와 플레이스테이션5, 엑스박스 시리즈 X|S에서 게임 로그인부터 필드 이동, 전투와 미션 수행, 성능 데이터 수집까지 자동으로 처리하는 언리얼 엔진 플러그인 'M1 AutoPlayTest'를 소개했다.
◇ 30개에 달하는 테스트 조합, 사람이 반복하기에는 한계
성능 최적화는 일반적으로 문제 구간을 찾고, 개선 작업을 진행한 뒤, 같은 조건에서 결과를 다시 측정하는 과정으로 이뤄진다. 정확한 비교를 위해서는 동일한 경로와 상황을 여러 차례 반복해야 한다.
'퍼스트 디센던트'는 여러 플랫폼과 그래픽 설정을 지원한다. 플레이스테이션5에서 7개, 두 종류의 엑스박스 기기에서 총 14개 설정을 확인해야 하며 PC의 주요 옵션까지 더하면 테스트해야 할 조합은 약 30개에 이른다.
엔진팀이 기존 업무와 함께 매 빌드마다 모든 플랫폼과 그래픽 옵션을 직접 플레이하며 성능을 측정하기는 어려웠다. 설정 조합의 수가 자동화를 요구한 첫 번째 이유였다.
두 번째 이유는 콘솔 플랫폼의 제약이었다.
PC에서는 외부 스크립트나 자동화 도구를 연결할 수 있지만, 콘솔은 운영체제와 보안 구조가 다르기 때문에 외부 프로그램을 자유롭게 붙이기 어렵다. 이에 따라 자동화 기능을 게임 패키지 내부에 직접 탑재해야 했다.
강 개발자는 "내가 주 업무를 하는 동안 이 도구가 대신 테스트하게 만들자"는 필요에서 M1 AutoPlayTest 개발을 시작했다고 설명했다.
M1 AutoPlayTest는 봇이 게임을 직접 플레이하며 성능을 측정하고, 외부 제어가 제한된 콘솔에서도 작동할 수 있도록 게임 애플리케이션에 포함되는 구조로 제작됐다.
◇ 완벽한 재현보다 중요한 것은 '멈추지 않는 것'
개발 초기에는 사람이 플레이한 것처럼 동일한 상황을 반복하는 것이 목표였다. 그러나 실제 게임은 자동화 테스트가 전제하는 고정된 환경과 거리가 멀었다.
플레이어와 몬스터의 위치가 매번 달라지고 전투 상황도 일정하지 않다. 이동 경로에는 좁은 틈과 턱, 계단, 점프 구간이 섞여 있다. 미션 데이터에 작은 오타가 생기는 것만으로도 봇이 다음 행동을 판단하지 못할 수 있었다.
강 개발자는 변수가 많은 게임에서 완벽한 재현을 고집하는 것은 현실적인 해법이 아니라고 판단했다.
대신 어떤 문제가 발생하더라도 봇이 멈추지 않고 다음 행동을 선택하며, 필요한 성능 데이터를 계속 모으는 것을 설계의 최우선 원칙으로 삼았다.
이 원칙은 경로 탐색과 전투 대상 탐색, 미션 판별, 전체 시스템 구조와 예외 처리까지 M1 AutoPlayTest의 모든 기능을 관통한다.
◇ 길을 찾지 못하면 우회하고, 끼었을 때는 스스로 탈출한다
자동 플레이의 첫 번째 과제는 목적지까지 이동하는 것이다.
일반적인 내비게이션 메시 기반 탐색만으로는 복잡한 지형을 항상 통과할 수 없었다. 경로상으로는 이동 가능한 것으로 판정돼도 캐릭터가 좁은 틈이나 구조물 사이에 끼거나, 특정 구간을 통과하지 못하는 일이 발생했다.
M1 AutoPlayTest는 이를 해결하기 위해 3단계 폴백 구조를 도입했다.
우선 표준 경로 탐색을 시도하고, 실패하면 봇이 자주 막히는 경로의 비용을 높여 다른 길을 선택하도록 한다. 이후에도 이동할 수 없으면 탐색 조건을 다시 조정해 가능한 경로를 찾는다. 모든 방식이 실패하면 최종적으로 텔레포트를 통해 다음 지점으로 이동한다.
문제는 봇이 실제로 지형에 끼었는지 정확하게 판단하는 일이었다.
캐릭터가 공격 기술이나 상호작용을 수행하기 위해 의도적으로 멈춰 있을 수도 있기 때문이다. 이동 속도가 낮다는 이유만으로 즉시 텔레포트하면 정상적인 플레이까지 오류로 처리하게 된다.
개발진은 캐릭터가 이동 입력을 받고 있는지를 보여주는 가속도 값과 실제 평면 이동 속도를 함께 확인했다. 이동하려는 입력은 존재하지만 속도가 초당 10cm 미만이라면 물리적으로 끼었을 가능성이 있다고 봤다.
여기에 캐릭터가 움직이고 있지만 목적지까지의 거리가 줄어들지 않는 시간도 별도로 측정했다. 벽을 향해 계속 걷거나 제자리에서 움직이는 상황까지 감지하기 위해서다.
두 조건이 모두 일정 시간 이상 유지될 때만 실제 이동 불능 상태로 판단하고 텔레포트를 실행했다. 하나의 수치에 의존하지 않고 두 개의 시간 조건이 겹치는 순간을 기준으로 삼아 잘못된 판정을 줄였다.
◇ 수십 마리의 적을 매 프레임 검색하지 않는다
이동 이후에는 전투가 이어진다. 전투 자동화에서 가장 먼저 필요한 일은 공격할 적을 찾는 것이다.
모든 프레임마다 게임 안의 전체 액터를 검색하는 방식은 구현 자체는 간단하지만, '퍼스트 디센던트'처럼 동시에 수십 마리의 몬스터가 등장하는 게임에서는 CPU 부하와 프레임 저하를 일으킬 수 있다.
성능을 측정하기 위해 만든 도구가 측정 대상의 성능을 떨어뜨린다면 결과의 신뢰성도 확보하기 어렵다.
강 개발자는 몬스터들이 어그로에 따라 플레이어 주변으로 이동한다는 점을 활용했다. 멀리 떨어진 모든 적을 계속 확인할 필요 없이, 실제 전투 범위에 들어온 일부 대상만 관리할 수 있다고 판단했다.
이를 바탕으로 가장 가까운 K개의 대상을 저장하는 'K-Closest 스마트 캐싱'을 적용했다.
필요한 시점에만 전체 몬스터를 검색하고, 그중 봇과 가까운 일부 대상의 포인터를 캐시에 저장한다. 이후에는 전체 액터가 아닌 캐시 안의 대상만 대상으로 거리와 공격 우선순위를 갱신한다.
가까운 몬스터가 처치되거나 캐시가 갱신돼야 할 때만 다시 전체 탐색을 수행한다. 이를 통해 다수의 몬스터와 이펙트가 등장하는 상황에서도 자동 전투 로직이 성능에 미치는 영향을 낮췄다.
◇ 오타가 생겨도 미션을 포기하지 않는 판별 방식
봇이 미션을 수행하려면 현재 미션이 거점 방어인지, 적 처치인지, 상호작용 중심 임무인지 먼저 판단해야 한다.
초기에는 게임 데이터에서 전달된 미션 타입 문자열과 봇 내부에 정의된 이름을 직접 비교했다. 그러나 데이터 입력 과정에서 철자 하나가 달라지거나 미세한 오타가 생기면 문자열 비교가 실패했다.
사람이라면 의미를 알아볼 수 있는 차이지만, 봇은 전혀 다른 미션으로 인식하거나 행동을 선택하지 못해 테스트를 중단할 수 있었다.
M1 AutoPlayTest는 이를 해결하기 위해 레벤슈타인 거리 기반의 유사도 매칭을 도입했다.
게임 데이터의 문자열과 봇이 알고 있는 미션 타입 사이에 몇 번의 문자 삽입과 삭제, 교체가 필요한지 계산한 뒤, 유사도가 75% 이상이면 같은 미션으로 판정한다.
이를 통해 '어세시네이션', '디펜스', '인터랙션'과 같은 미션 이름에 작은 오타가 포함돼도 정상적인 행동을 수행할 수 있었다. 반면 의미가 전혀 다른 미션은 낮은 유사도로 구분해 잘못된 명령이 실행되는 것을 막았다.
◇ 커맨드라인 한 줄로 플랫폼과 그래픽 설정까지 자동화
게임 플레이를 자동화하더라도 매번 사람이 직접 그래픽 옵션을 바꾸고 테스트를 실행해야 한다면 30개에 달하는 조합의 부담은 사라지지 않는다.
개발진은 프리셋과 프레임 생성, 레이트레이싱 등 주요 그래픽 옵션을 커맨드라인 인자로 전달할 수 있도록 만들었다.
PC에서는 세부 스케일러빌리티 설정과 업스케일러를 비롯한 주요 옵션도 한 줄의 명령어에 담아 실행할 수 있게 했다. 콘솔과 PC 모두 게임 실행 단계부터 원하는 테스트 환경을 자동으로 구성하는 방식이다.
질의응답에서 강 개발자는 로그인 정보 역시 커맨드라인으로 전달할 수 있도록 지원했다고 설명했다. 로그인 이후 허브에 진입하고, 테스트할 필드로 이동하는 과정도 자동화 범위에 포함됐다.
사람이 게임을 실행해 캐릭터를 직접 이동시키지 않아도 테스트 환경 설정부터 콘텐츠 진입까지 이어질 수 있도록 한 것이다.
◇ 네 개의 서브 매니저를 지휘하는 오케스트레이터
경로 탐색과 전투, 미션 수행, 성능 측정 기능이 하나의 클래스에 모두 들어가면 기능이 늘어날수록 유지보수가 어려워진다.
M1 AutoPlayTest는 최상위 모듈을 오케스트레이터로 두고, 그 아래에 네 개의 서브 매니저가 각자의 역할을 담당하는 구조로 설계됐다.
로그인과 필드 이동, 미션 수행, 메모리 및 성능 데이터 측정 등 각 매니저는 자신에게 주어진 작업만 처리한다. 서브 매니저끼리 직접 통신하지 않고, 모든 상태 변화와 명령은 상위 오케스트레이터를 거치도록 했다.
각 테스트 사이클이 끝난 뒤에는 공통 인터페이스를 통해 이전 테스트의 상태와 데이터를 초기화한다. 앞선 플레이에서 남은 값이 다음 테스트 결과에 영향을 주는 일을 막기 위한 장치다.
강 개발자는 무인 자동화 시스템에서는 기능 자체보다 모든 실패 상황에서 빠져나갈 수 있는 비상구를 마련하는 일이 중요하다고 강조했다.
각 단계가 시작될 때 시간을 기록하고, 정해진 시간 안에 다음 상태로 넘어가지 못하면 상황에 맞는 복구 행동을 실행한다.
로그인이나 필드 진입이 실패한 경우처럼 테스트 자체를 이어가기 어려운 문제는 게임을 종료한다. 특정 미션의 세부 작업을 완료하지 못한 경우에는 해당 임무를 건너뛰고 다음 테스트로 이동한다.
경로 탐색에 실패하거나 캐릭터가 지형에 끼었을 때 실행되는 텔레포트도 이 타임아웃 구조와 연결된다.
봇이 무기한 같은 행동을 반복하도록 내버려 두지 않고, 실패의 크기에 따라 종료와 재시도, 스킵, 강제 이동 가운데 하나를 선택하게 한 것이다.
◇ 성능 수치에 위치와 방향을 함께 기록한 이유
자동화의 최종 목적은 성능 데이터를 수집하는 것이다.
M1 AutoPlayTest는 테스트 과정에서 메모리와 프레임 시간 등 핵심 성능 지표를 기록한다. 여기에 캐릭터의 위치 좌표와 바라보는 방향도 함께 저장한다.
프레임 시간이 특정 순간에 증가했다는 정보만으로는 실제 게임의 어느 장소에서 문제가 발생했는지 알기 어렵다. 같은 상황을 사람이 다시 찾아가 재현하는 과정에도 시간이 든다.
위치와 방향을 함께 기록하면 성능 저하가 발생한 장소와 당시 카메라가 바라본 영역을 추적할 수 있다.
수집된 데이터는 맵 위에 시각화된다. 정상 범위는 초록색, 성능 문제가 발생한 구간은 노란색과 빨간색 등으로 표시해 필드의 어느 지점이 무거운지 한눈에 확인할 수 있도록 했다.
미션 내부의 구간별 성능을 확인할 수 있는 별도의 시각화 도구도 제작했다.
테스트가 완료되면 주요 지표를 정리한 메시지가 사내에 공유되고, 함께 제공된 링크를 통해 봇의 이동 경로와 성능 수치를 담은 HTML 리포트를 열 수 있다.
게임 실행과 플레이, 데이터 수집, 결과 시각화와 공유까지 사람이 개입하지 않는 파이프라인을 구축한 셈이다.
◇ 측정 도구의 오버헤드부터 검증했다
성능 테스트 도구가 게임 실행에 큰 부하를 일으키면 측정 결과가 왜곡될 수 있다.
개발진은 플레이스테이션5의 피델리티 설정을 기준으로 M1 AutoPlayTest 자체의 오버헤드를 측정했다. 메모리 측정과 미션 수행 등 주요 기능은 평균 약 0.1~0.3ms 수준을 기록했으며, 부하가 큰 상황에서도 최대 약 1.2ms로 나타났다.
전투 캐싱과 제한적인 전체 검색, 기능별 모듈 분리 등을 통해 테스트 도구가 성능에 미치는 영향을 억제했다는 설명이다.
수집된 원본 데이터에는 성능 수치뿐 아니라 플랫폼과 그래픽 옵션, 플레이어 좌표와 방향이 함께 기록됐다.
이를 통해 단순히 "프레임이 떨어졌다"는 결과가 아니라, 특정 플랫폼의 특정 그래픽 설정에서 필드의 어느 구간을 통과할 때 병목이 발생했는지 역추적할 수 있게 됐다.
◇ 평균 18.84ms에서 9.64ms로...실제 최적화에 활용
강 개발자는 M1 AutoPlayTest를 실제 최적화 작업에 활용한 사례도 공개했다.
동일한 그래픽 옵션과 이동 경로에서 최적화 전후 빌드를 자동으로 순회한 결과, 최적화 전에는 경로 대부분이 목표 성능을 벗어난 색상으로 표시됐다. 이후 병목 구간을 개선한 빌드에서는 같은 경로가 대부분 안정 범위를 의미하는 초록색으로 바뀌었다.
60fps를 유지하기 위해 한 프레임에 사용할 수 있는 시간은 약 16.67ms다. 이 기준을 초과하는 구간을 시각적으로 구분해 최적화 대상을 선정했다.
시간 축으로 비교한 결과에서는 전 구간에 걸쳐 약 9~10ms의 성능 개선이 확인됐다.
평균 렌더 스레드 시간은 18.84ms에서 9.64ms로 감소했다. 최악의 스파이크 구간을 나타내는 지표도 약 20ms에서 12ms 수준으로 낮아졌다.
일부 구간의 평균값만 좋아진 것이 아니라, 플레이 경험을 크게 해칠 수 있는 최악의 순간까지 함께 개선했다는 의미다.
지속적으로 축적된 자동 측정 데이터를 통해 반복되는 패턴을 찾고, 이를 엔진팀과 유관 부서의 최적화 작업에 활용했다. 자동화 도구가 데이터를 기록하는 측정기를 넘어 협업의 근거를 제공한 사례였다.
◇ 자동화의 목표는 사람을 대체하는 것이 아니다
M1 AutoPlayTest 도입 이후 반복 플레이와 장기 테스트, 여러 플랫폼의 성능 데이터 수집에 필요한 사람의 시간이 줄었다.
반면 봇이 모든 문제를 찾아낼 수 있는 것은 아니다.
라이팅이 깨지거나 텍스처가 늦게 불러와지는 등 시각적인 오류가 발생해도, 봇은 미션을 수행하고 수치를 수집했다면 테스트를 정상으로 판단할 수 있다.
강 개발자는 자동화 테스트의 지향점이 사람을 대체하는 것이 아니라 보완하는 데 있다고 설명했다.
봇은 반복적인 검색과 데이터 수집을 맡고, 개발자와 QA 인력은 시각적 품질과 플레이 감각처럼 더 높은 수준의 판단이 필요한 문제에 집중하는 구조다.
M1 AutoPlayTest가 엔진팀에 가져온 가장 큰 변화도 테스트 인력을 줄인 것보다 데이터에 기반한 최적화 체계를 마련했다는 점이었다.
개발진은 자동으로 축적된 객관적인 수치를 바탕으로 문제의 위치를 특정하고, 유관 부서와 최적화 필요성을 공유할 수 있게 됐다.
강 개발자는 완벽한 설계가 완성될 때까지 기다리지 않고 작은 기능부터 구현한 태도를 이번 개발 과정에서 얻은 중요한 경험으로 꼽았다.
처음부터 복잡한 자동화 시스템 전체를 설계하려 하기보다 간단한 의사 코드를 실제 코드로 옮기고, 테스트와 수정을 반복한 결과 봇이 스스로 맵을 이동하며 데이터를 안정적으로 수집하는 단계에 도달했다는 설명이다.
복잡한 게임에서 자동화 테스트를 성공시킨 기준은 사람이 하던 플레이를 완벽하게 흉내 내는 데 있지 않았다.
길을 잃으면 다른 경로를 찾고, 움직일 수 없으면 탈출하며, 미션 하나를 실패해도 다음 테스트를 이어가는 것. M1 AutoPlayTest는 멈추지 않는 구조를 통해 변수가 많은 라이브 게임에서도 자동화가 실질적인 최적화 수단이 될 수 있음을 보여줬다.
Copyright ⓒ 게임와이 무단 전재 및 재배포 금지
본 콘텐츠는 뉴스픽 파트너스에서 공유된 콘텐츠입니다.
