NC

게임을 제작할 때는 수많은 검증 테스트가 필요하다. 이는 수많은 시간과 인력을 필요로 하며 게임 내용이 조금이라도 바뀔 때마다 다시 해야하는 고강도의 작업이다. 이를테면, 아이템이 1,000개일 경우 1,000개 모두가 잘 동작하는지 사람이 직접 하나씩 테스트해봐야 하는 것이다. 이러한 테스트는 비효율적이기도 하지만 휴먼 에러가 발생하기도 쉽다. 엔씨 게임의 테스트를 담당하는 공통 QA실 SET팀 김종원 팀장은 조금 더 효율적인 방법을 찾고자 했다. 바로 스크립트가 사람 대신 자동적으로 테스트를 수행하는 방법이었다.

김종원 팀장은 우선 게임 자동화 시스템 개발을 위해 크게 두 가지 목표를 설정했다. 첫 번째는 게임 QA에 일원화된 자동 테스트 환경을 제공하는 것이고, 두 번째는 게임 개발 과정에서 자동화에 적합한 테스트 영역을 개발해서 테스트 커버리지를 확장하고 궁극적으로 게임의 퀄리티 향상에 기여하는 것이었다.

자동테스트의 첫 프로토타입을 본 사람들은 테스트 로그만 잔뜩 나오다 ’성공’이라는 결과만 뜨는 걸 보고 당황했다. 그래서 자동 테스트 결과를 확인하기 쉬운 리포트 형태로 제공하기 위해 테스트 스크립트 관리와 테스트 결과 리포트 제공 서비스를 만들기로 했다. 테스트마다 달라지는 스크립트나 데이터를 브라우저에서 바로 편집할 수 있게 한 것이다. 기기 검색과 현재 사용 여부도 확인하기 쉽게 했다. 여러 테스트를 순서대로 시행하거나 여러 기기에 나누어 할 수도 있게 했다. 테스트 로그를 모두 남겨 테스트 실패 원인을 찾을 수 있게 만들고 체크 항목마다 스크린 숏과 전 과정을 녹화해 테스트 과정을 확인해 볼 수 있게 만들었다. 테스트 환경도 최대한 하나로 통일했다. 모든 테스트 스크립트 관리를 일원화하고 기기나 네트워크 플랫폼이 달라도 동일한 방식으로 사용할 수 있게 했다. 플랫폼이 달라도 서비스하는 게임의 버전이 같으면 원칙적으로 가급적 동일한 테스트 스크립트를 적용하고 게임 엔진이 달라도 동일한 스크립트 언어와 개발 툴을 사용하게 했다. 리포트 형식을 최대한 동일하게 유지해서 테스트 목적이 달라도 리포트를 보는 사람들이 익숙한 포맷으로 제공했다. 이런 테스트 환경의 일원화를 위해 ’테스트 워크벤치’를 만들었다.

모든 개발 과정이 그렇듯 해결해야 할 문제는 끊임없이 나왔다. 스크립트를 개발하는 도중에도 게임의 UI가 계속 바뀌었고, 게임마다 적용된 게임 엔진이 달라서 새로운 게임이 출시되거나 엔진 버전이 업데이트될 때마다 새로운 플러그인을 만들어야 했다. 테스트 스크립트가 늘어날수록 변경 사항들도 늘어났다. 테스트 기기 수가 늘어나면서 배터리 방전 등 물리적인 문제도 발생했다.  또한 게임 개발팀이 여유가 없어 자동 테스트 빌드를 나중에 주겠다고 하는 경우도 있어 자동 테스트용 빌드를 직접 빌드하고 테스트하기 위해서 배포하기도 했다.

이런 문제들은 장애물을 하나씩 넘듯 해결해 나가야 했다. 우선 UI가 변화하더라도 검색할 수 있도록 게임 내 오브젝트 검색 방법을 다양하게 했다. 추가로 테스트마다 공통적인 스크립트를 따로 모은 공통 라이브러리를 만들어 하나의 라이브러리에서 여러 스크립트가 공통적인 부분을 활용하도록 했다. 물리적인 문제는 하나하나 시행착오를 겪으면서 해결했다. 모니터링 시스템을 도입하고, 원격 재부팅을 하고, 무선랜 AP를 추가했다. 개발팀의 사내 배포는 개발팀에서 사내 빌드에 디폴트로 포함해서 자동 테스트 빌드를 따로 만들지 않도록 바꾸었다.

자동 테스트를 개발하는 과정에서 게임 QA가 던진 질문은 아이러니하게도 ‘QA가 자동 테스트의 결과를 신뢰할 수 있느냐’였다. QA 입장에서 보면 단지 PASS라고 찍힌 결과지를 쉽게 신뢰하고 그냥 받아들이기가 어려운 것이 당연했다. 그래서 시행착오를 거치면서 게임 QA와 함께 테스트 영역 선정과 테스트 시나리오 설계를 했고, 확인하고자 하는 항목이 포함된 리포트 양식도 함께 설계했다. 그 결과 최근에는 2,600회 정도의 테스트를 연속적으로 시행하면서도 네트워크 오류 외에는 거의 테스트 오류가 발생하지 않는 높은 신뢰도를 확보했다.

그렇다면 자동 테스트 시스템은 과연 어떤 방식으로 구현했을까? 우선 게임의 UI를 웹 브라우저의 UI와 동일한 방식으로 다룬다. 파이썬 스크립트로 웹 UI를 컨트롤하듯이, 게임 UI를 컨트롤해서 전체적인 테스트를 수행한다. 스크립트 입장에서는 웹 화면의 구성 요소를 식별하는 방식인 XPath와 비슷하게 게임 UI의 식별자를 생성한다. 게임 클라이언트에 이런 역할을 하는 플러그인을 포함하는 빌드를 따로 만든다. 모바일 자동 테스트 시스템인 Appium에 이 플러그인과 통신하는 기능을 추가하고 모바일 웹과 게임 UI들을 모두 컨트롤해서 원하는 테스트 동작을 수행한다.

스크립트를 이용해서 게임을 제어하는 순서는 다음과 같다. 스크립트 명령은 Appium 서버를 거쳐 ‘게임 오브젝트 인스펙터’라고 부르는 게임 클라이언트에 들어 있는 플러그인에 UI 정보를 요청한다. 요청한 UI가 화면 표시 여부나 표시된 위치 또는 표시하고 있는 텍스트들과 정보를 전달하면, Appium이 안드로이드 OS에서 제공하는 UI Automator라는 기능을 이용해 터치 이벤트를 발생시켜 마치 사람이 터치한 것과 동일한 형태로 게임에 이벤트를 준다. 실제로 플러그인은 정보를 전달하고 있을 뿐 별다른 액션을 취하고 않으며 모든 것은 바깥에서 컨트롤 된다.

스크립트 작성자는 어떤 식으로 게임의 UI 정보를 알아낼 수 있을까? 바로 ‘게임 오브젝트 뷰어’라고 불리는, 게임 내 플러그인을 통해서 할 수 있다. 현재 화면에 보이는 게임 UI 구조의 스냅숏을 파악하는 툴을 이용하는 것이다. 화면 왼쪽에는 저장한 게임 화면들을 보여주는 스냅숏 히스토리가 나열되어 있고, 오른쪽에는 현재 화면의 UI 구조를 파일 디렉터리처럼 보여준다. 왼쪽에서 원하는 화면을 선택하면 그 화면에 속해 있는 UI 구조의 전체 스냅숏이 오른쪽에 보인다. 그 안에 있는 각각의 UI를 선택하면 해당 UI의 ID, 텍스트, 표시 여부, 좌표, 크기 등의 정보 여부를 확인할 수 있다. 리니지2M을 만든 언리얼 엔진 같은 경우, 언리얼 엔진의 요소인 액터, 슬레이트, UMG를 모두 다 UI 요소로 간주하고 이를 추출해서 요소의 특성을 같이 볼 수 있다. 또 화면 중앙을 클릭하면 커서 위치를 중심으로 오브젝트들을 검색을 해서 화면 중앙 하단에 그 오브젝트들에 대한 리스트를 표시한다. 스크립트 작성자가 이 리스트를 보고 실제 스크립트에서 어느 오브젝트를 사용해야 할지 결정한다.

자동 테스트 결과 리포트의 실제 예시와 테스트 워크벤치의 사용 과정을 한번 살펴보자. QA에 배포된 빌드가 테스트 가능한 수준인지 확인하는 테스트를 BAT라고 한다. 빌드가 올라오면 자동으로 실행되며 QA가 매뉴얼 테스트를 하기 전에 최대한 빠르게 자동 테스트를 수행한다. 이런 테스트는 테스트 워크벤치를 통해서 생성하고 실행하게 된다.

자동 테스트는 어떤 변화를 가져왔을까? 게임 개발 시 기능이 변경되면 업데이트된 내용만 사람이 직접 확인하고 변경되지 않은 기능은 자동 테스트를 통해 보다 수월하게 점검할 수 있다. 테스트가 정확할수록 작은 변화에도 취약하기 때문에 스크립트의 지속적인 관리는 필수다. 대신 테스트가 가능한 시간의 제약이 사라졌고 수백, 수천 가지 항목을 반복해서 테스트할 수 있다. 간단한 검증이라도 이를 반복하면 중요한 검증이 되는데 이른바 검증의 양질 전환을 이루어 낸 셈이다. 또한, 단순/반복 테스트를 자동테스트로 전환하면 사람이 실수할 수 있는 여지를 없앨 수 있다. 이러한 자동테스트의 진화는 궁극적으로 보다 양질의 게임을 만든다.

물속에서 자맥질하는 백조의 발처럼 보이지 않는 곳에서 양질의 게임을 만들기 위한 끊임없는 기술적 도전이 계속되고 있다. 물리적인 시공간의 제약을 넘어 모두가 즐거움으로 연결되는 무한한 가능성의 세계. 엔씨가 꿈꾸는 미래를 위해 엔씨인들의 새로운 도전은 앞으로도 계속될 것이다.