원격 서비스

출시 전마다 자신의 게임을 100번씩 플레이하지 마세요—지루한 작업은 로봇에게 맡기고, 재미있는 부분을 멋지게 만드는 데 집중하세요

우리가 잘못하고 있다는 사실을 깨달은 정확한 순간이 기억납니다. 새벽 2시였고, 같은 인벤토리 화면을 300번째 클릭하며 '사소한' 엔진 업데이트 후에도 검 아이콘이 제대로 보이는지 확인하고 있었습니다. 리드 개발자가 다가와서 말하길, "이거, 자동화된 게임 테스트가 처리해야 할 일이잖아, 그렇지?" 게임 체인저였습니다.

멋진 새 기능이 실수로 튜토리얼 깊숙한 곳에 숨겨진 무언가를 망가뜨릴 때의 그 난감한 느낌, 아시죠? 수동 QA는 필수적이지만, 사람은 피곤해지고, 엣지 케이스를 놓치며, 솔직히 말해 300개의 아이템이 여전히 올바르게 쌓이는지 확인하는 대신 이상한 플레이어 행동을 탐색해야 합니다. 그때 테스트 스크립트를 작성하는 것이 여러분의 정신을 지켜줍니다.

핵심 전환점은? 게임 코드를 견고한 게임 개발 테스트 도구가 필요한 다른 소프트웨어 프로젝트처럼 취급하는 것입니다. 대부분의 엔진에는 이제 내장 또는 커뮤니티 기반의 게임 테스트 프레임워크가 함께 제공되므로, 매 빌드를 맨손으로 테스트해야 한다는 변명은 통하지 않습니다. Unity든 Unreal이든, 커피를 마시는 동안 실행되는 테스트 스위트를 가질 수 있습니다. 이제 실제로 어떻게 하는지, 스크립트부터 지속적 통합까지, 창의적인 불꽃을 잃지 않으면서 이야기해 봅시다.

게임 테스트 스크립트 작성법의 첫걸음은 이상하게 격식 있어 보입니다. 여러분의 게임을 플레이하는 코드를 작성하는 것이니까요. 작게 시작하세요. 전체 드래곤 보스 전투를 테스트하는 대신, 메인 메뉴를 열고 '새 게임' 버튼이 존재하는지 확인한 후 누르는 스크립트를 작성하세요. Unity에서는 Test Framework를 사용한 플레이모드 테스트입니다. [UnityTest] 속성이 있는 메서드를 작성하고, SceneManager.LoadScene을 사용한 후 타이틀 화면을 로드한 후 올바른 태그를 가진 GameObject가 활성화되었는지 검증합니다. 짠, 첫 번째 자동화된 기본 점검입니다. 익숙해지면 사소한 검사에서 적 생성, 입력 시퀀스 시뮬레이션, 그리고 슬라임이 공격할 때 플레이어 체력이 정확히 얼마나 감소하는지 확인하는 단계로 나아갑니다.

Unity 자동화 테스트는 놀랍도록 접근하기 쉬워졌습니다. 패키지가 에디터에 포함되어 있으며, Edit Mode 테스트(로직, 씬 없음)와 Play Mode 테스트(런타임, 전체 시뮬레이션)를 만들 수 있습니다. 저는 주로 인벤토리 시스템을 Edit Mode에서 분리하여 시작합니다. 아이템 추가, 무게 확인, 중복 고유 아이템 추가 시도 등, 무거운 씬을 로드하지 않고 수행합니다. Play Mode 테스트는 시각적 피드백을 처리합니다. 일반적인 트릭은 테스트에서 UnityEngine.InputSystem 래퍼를 사용하여 게임패드나 키보드 이벤트를 시뮬레이션함으로써 프로그래밍 방식으로 진정으로 게임을 '플레이'하는 것입니다. 문 근처에서 'E'를 누르는 헬퍼를 작성한 후 플레이어의 변환이 새 방으로 변경되었는지 검증하세요. 이러한 패턴을 보여주는 게임 QA 자동화 튜토리얼을 많이 찾을 수 있습니다. 리듬을 타면 바로 감이 잡힙니다.

Unreal 엔진 테스트 자동화도 비슷한 길을 따르지만 고유한 특성이 있습니다. UE의 Automation System을 사용하면 에디터에서 직접 Functional Test를 작성할 수 있으며, 비주얼 스크립팅을 선호한다면 종종 블루프린트를 사용합니다. C++ 개발자라면 FAutomationTestBase 클래스가 있습니다. 저는 레벨에 "Functional Test Actor"를 배치하고, 일련의 동작(여기로 이동, 저기 보기, 발사)을 첨부한 후 성공 조건을 설정하는 것을 좋아합니다. 마치 매우 순종적인 배우를 연출하는 것과 같습니다. 그리고 Unreal 프로젝트는 방대하기 때문에 맵이나 태그로 필터링된 테스트를 실행할 수 있어, 사람 테스터가 자리 잡기 전에 물리나 복제에서의 회귀를 잡아냅니다. 제가 본 최고의 게임 테스트 모범 사례 중 일부는 이를 Gauntlet 자동화 프레임워크와 결합하여 멀티플레이어 스트레스 테스트를 수행하고, 수십 개의 더미 플레이어가 세션에 원활하게 참여하는 것을 시뮬레이션하는 것입니다.

이제 테스트를 많이 만들었다면, 수동으로만 실행하면 쓸모가 없습니다. 여기서 게임 개발 CI/CD 테스팅이 등장합니다. 테스트 스위트를 Jenkins, GitHub Actions 또는 TeamCity에 연결하세요. 모든 코드 푸시 시마다 CI 파이프라인이 게임을 빌드하고, 헤드리스 모드(또는 렌더 팜 사용)로 실행하며, 모든 테스트 카테고리를 실행하고 결과를 게시합니다. 저는 인벤토리 스태킹 테스트가 실패하면 개발자의 Slack에 실패 프레임의 스크린샷과 함께 자동으로 답장을 보내는 시스템을 설정한 적이 있습니다. 그 덕분에 플레이어가 전설의 검을 복제할 수 있는 버그를 출시하지 않았습니다. 모바일 게임의 경우 실제 하드웨어에서 테스트를 실행하기 위해 디바이스 팜을 통합할 수도 있지만, 비용이 더 많이 듭니다.

이렇게 생각할 수도 있습니다. "하지만 실제 재미를 어떻게 테스트하지? 알고리즘이 점프가 좋은 느낌인지 말해줄 수는 없잖아." 맞습니다. 그래서 자동화된 플레이