주제: 게임 테스트 자동화 5년의 기록
강연자 : 김종원 - 엔씨소프트 / NCSOFT
발표분야 : 프로그래밍 / 프로덕션&운영 / 사업마케팅&경영관리
권장 대상 : 프로그래머 , QA , PM
난이도 : 사전지식 불필요
[강연 주제] 2016년에 발표한 모바일 게임 테스트 자동화의 후속 강연으로
발표 이후 모바일 게임 자동테스트 시스템을 활용하여 '리니지M'과 '리니지2M'에 적용한 자동테스트의 결과들과 얻은 교훈을 공유함으로써 모바일 게임의 안정성 향상과 테스트 커버리지의 확대, 단순 반복적인 테스트에서 탈출할 방법들을 찾는 계기가 될 것입니다. 또한, 게임 개발 프로세스에 자동테스트를 도입함으로써 빌드 안정성과 이슈를 빠르게 찾을 수 있는 사례를 찾아보고자 합니다.
자동 로봇과 자동화에 대한 로망과 환상은 오랜 시절부터 있었다. 미리 입력한 글을 쓰는 자동인형 오토마톤을 시작으로 많은 이들이 자율 주행이나 인류의 노동을 대체하는 자동화는 오늘날, 나아가 미래의 모습이라 기대한다.
게임의 테스트 역시 이런 자동화가 도입되고 있다. 하지만 자동테스트 도입 초창기부터 이런 막연한 기대감과 기술적 한계를 이야기하며 너무 이른 이야기라고 생각한다. 하지만 사람이 하기 귀찮거나 하지 않아도 될법한 일들을 기계가 대신할 수 있다면 그만큼 효율적이고 더 나은 QA와 문제 개선이 이루어지지 않을까?
이 강연은 이런 게임 테스트에 대한 인식과 적용, 그리고 비전을 함께 담아냈다.
■ 적정기술과 자동테스트
김종원 개발자는 게임 테스트 자동화에 대한 사람들의 인식을 딸기를 수확에 빗대 설명했다. 사람들은 딸기 자동 수확 기계가 광활한 딸기밭을 돌아다니며 딸기를 따는 모습을 떠올릴지도 모른다. 하지만 실제로는 받침대를 트렉터에 붙이고 여기에 사람들이 엎드려 누워 딸기를 딸 뿐이다. 복잡한 기계도, 인공 지능도 없다.
우스꽝스럽게 보일지도 모르지만, 쪼그려 앉아 딸기를 수확하는 것과 비교하면 매우 효율적인 방식이다. 김종원 개발자는 이를 적정 기술이라고 부르며 적정 기술이라고 할 수 있는 시스템을 이용해 게임을 테스트하고 자동화하고자 했다.
2015년 당시 자동테스트 실현 주장에 많은 사람이 실패를 예견했다. 일부는 테스트는 인공지능이 할 수 없는 영역이라고 생각했고 괜한 일을 벌인다는 반응이 많았다.
하지만 김종원 개발자는 ▲사람을 대신 하지 않고 ▲사람이 하지 않아도 되는 일을 하고 ▲사람보다 정확하고 실수 없이 ▲가장 기본적이 반복적인 일을 자동화한다는 명확한 목표를 두고 자동화하고자 했다.
■ 적정기술과 자동테스트
2016년 유니티 게임의 자동테스트를 시작으로 2017년 리니지M의 출시와 함께 본격적으로 자동테스트가 운용되기 시작했다. 서비스 안정성 확보와 호환성 테스트에 자동 테스트가 적용되었고 2018년에는 테스트 워크벤치라고 부르는 테스트 시스템이 개발되어 여러 자동테스트를 수행할 수 있었다. 2019년에는 언리얼 플러그인 형태로 리니지2M에 자동테스트 시스템이 적용됐고 2020년에는 안드로이드뿐만 아니라 iOS 플랫폼의 자동테스트도 수행되기 시작했다. 플랫폼 확대에 이어 올해는 대만, 일본 버전의 리니지M에도 자동테스트가 수행되고 있다.
김종원 개발자는 테스트 시연 영상을 통해 리니지2M의 서버군 자동점검 테스트를 소개했다. 영상에서는 기기가 다른 13개의 스마트폰에서 동시에 테스트가 이루어지는데 각기 다른 타이밍에 테스트가 수행된다. 이들 기기를 동시에 컨트롤하는 게 아니라 게임의 상태에 맞춰 독립적으로 테스트를 진행하는 방식이다.
자동테스트는 웹 로그인을 한 후 게임에 로그인하고 진입할 월드를 선택한 후 서비스의 동작을 확인하는 점검을 15분가량 진행하고 최종 결과를 취합해 메일로 전달한다.
이 자동테스트 시스템은 크게 두 가지 목표를 가지고 개발됐다.
우선 게임 QA에게 일원화된 자동테스트 환경을 제공하는 것이 첫 목표였고 두 번째 목표는 게임 개발 프로젝트에서 자동테스트에 적합한 테스트 영역을 개발하여 테스트 커버리지 확장과 게임 퀄리티 향상을 함께 꾀하는 일이었다.
하지만 첫 프로토타입은 화면에 텍스트 로그만을 잔뜩 띄울 뿐이었다. 이에 개발진은 테스트 스트립트의 관리와 테스트 결과 리포트를 함께 제공하는 서비스를 만들기로 했다.
우선 예약시간에 반복적으로 테스트를 실행하거나 새로운 빌드가 나올 시 자동으로 실행되도록 했다. 이후 테스트마다 달라지는 테스트 스크립트나 데이터를 브라우저에서 바로 편집할 수 있도록 했고 테스트할 기기도 검색하거나 사용 중인지 판단하도록 했다. 이후 테스트 로그를 모두 남겨 실패 원인을 찾기 쉽게 하고 각각의 체크 항목마다 스크린샷과 과정을 영상으로 남겨 테스트 과정 전체를 확인할 수 있도록 하였다.
서비스 외에 테스트 환경도 하나로 통일하고자 했다.
여러 게임에 사용되는 테스트 스크립트를 한 곳에서 관리해 기기 및 네트워크 플랫폼이나 달라도 동일한 방식으로 사용할 수 있도록 했다. 게임마다 사용하는 엔진이 다를 수 있지만, 동일한 스크립트 언어와 개발툴을 사용할 수 있도록 해 학습 난이도도 낮췄다. 최대한 같은 형식의 리포트를 유지하도록 해 테스트 목적이 다르더라도 익숙한 포맷으로 제공하도록 했다.
개발진은 테스트 환경을 제공하기 위해 앞서 언급한 테스트워크벤치를 만들었다.
게임 QA나 스크립트 개발자가 테스트워크벤치의 주 사용자가 되는데 여기서 각기 다른 플랫폼을 관리하는 기기 관리 서버를 통해서 기기를 컨트롤하고 스크립트에 기술된 테스트 과정을 수행한다. 사용자는 생성된 결과리포트를 통해 테스트와 결과 해석에만 집중할 수 있다.
자동테스트를 통해 테스트 커버리지의 확장이 이루어졌다.
자동테스트가 새로운 게임 빌드가 배포될 때마다 이를 자동으로 설치하고 테스트하도록 설정되자 게임QA의 매뉴얼 테스트 이전에 기본적인 테스트는 이미 수행 완료 상태가 된다. 또한, 이런 변화로 최대 30개의 서버 점검이 가능해졌다. 정기 점검 시 한 사람이 기껏해야 서버 2개를 테스트하던 것과 양적 차이가 생긴 셈이다.
또한, 게임 내에서 중요 재화들을 사용하는 321개의 테스트 시나리오 5개 기기에서 1시간 동안 수행하기도 하고 단순 반복 테스트를 장시간 수행하고 아이템 상자를 수천 번씩 열어 기획한 확률로 아이템이 드롭되는지 확인하기도 한다.
테스트 영역도 확대됐다. 기존 기능이 잘 동작하는지 확인하는 리그레션 테스트를 시작으로 국가별 테스트가 이루어지게 됐고 다른 테스트가 없는 주말에는 별도의 장시간 테스트를 수행할 수 있다. 앱스토어 등록을 위한 심사 서버의 자동테스트도 가능해져 심사 과정을 빠르게 진행할 수 있게 됐다.
지금의 자동테스트만을 본다면 굉장히 훌륭하게 기존의 불편한 테스트 과정을 많이 보완한 것처럼 보이지만, 처음부터 순탄하게 자동테스트가 적용된 것은 아니다.
스크립트를 개발하는 중에도 게임 UI가 계속 바뀌었고 게임마다 적용된 엔진도 달랐다. 이에 개발진은 플러그인을 계속 새로 추가해야 했다. 변경 사항을 모든 스크립트에 적용해야 해 테스트 스크립트 수가 늘어날수록 수정해야 하는 양도 덩달아 늘었다. 자동테스트 개발자가 개발팀 빌드가 나오면 자동테스트 빌드를 별도로 만들고 배포하는 경우도 있었다.
이에 UI가 변경되더라고 검색에 실패하지 않도록 검색 방법을 다양하게 만들었고 공통 라이브러리를 만들어 변경 시 바꿀 부분을 최소화했다. 별도의 개발 빌드를 만들지 않도록 개발팀과 협업했고 이후에 남은 물리적 문제들은 하나하나 틀어막았다.
김종원 개발자는 자동테스트 도입 시 결과를 게임 QA들의 부정적인 의견을 들었다. 가장 걱정하는 부분은 신뢰도였다. 이에 게임 QA와 함께 테스트 영역을 선정하고 테스트 시나리오를 설계했고 확인하고자 하는 리포트 폼도 함께 만들었다. 또한, 테스트 판정의 정확도도 99.9% 이상으로 높여 시스템의 문제로 인한 테스트 실패가 발생하지 않도록 노력했다.
현재 자동테스트는 빌드 인수 테스트, 게임 영역별 기본 기능 테스트, 모바일 기기 호환성 테스트, 라이브 서버 자동점검과 임시점검, 반복 업무 테스트, 그리고 재화 관련 테스트와 변신 카드의 공격과 이동 속도 전수 테스트 등을 수행하고 있다.
플랫폼도 점차 확대되어 안드로이드뿐만 아니라 iOS 기기를 지원하고 윈도우 플랫폼도 기술개발 후 적용하고 있다. 빌드 역시 내부망과 외부 서비스 모두 지원하며 19세 버전과 12세 버전, 한국과 대만, 일본 등 연령별/국가별 테스트도 함께 수행하고 있다.
김종원 개발자는 자동 시스템이 구축되며 어떤 식으로 테스트 자동화를 해야할 지 확신이 든 이후에는 여러 테스트를 자동테스트로 적용하는 것이 한결 수월해졌다고 전했다.
배포된 빌드가 테스트 가능한 수준인지 확인하는 테스트가 빌드 인수 테스트다. 엔씨소프트의 자동테스트는 QA가 메뉴얼 테스트를 하기 전 10~15분 정도로 짧게 수행하고 있다. 다만, 배포 직후에 너무 빨리 수행하게 되면 게임 서버가 재시작하기 전에 미리 테스트가 진행되는 만큼 서버가 준비될 때까지 기다리는 코드를 추가했다.
김종원 개발자는 자사의 게임 UI를 웹 브라우저의 UI와 동일하게 취급해 파이선 스크립트로 웹 UI를 컨트롤하듯 게임 UI를 컨트롤한다고 시스템 구현 원리를 설명했다. 이에 xpath와 비슷하게 게임 UI의 식별자를 생성하는 플러그인을 만들어 클라이언트에 포함한 빌드를 만든다. 이후 모바일 자동테스트 시스템인 Appium에 기능을 추가하여 모바일 웹과 게임의 UI 오브젝트 모두를 컨트롤하여 원하는 테스트 동작을 수행하고 있다.
상세하게는 스크립트에서 시작한 명령이 중간에 있는 Appium 서버를 거쳐 게임 클라이언트에 들어있는 플러그인에 UI 정보를 요청한다. 이후 Appium이 안드로이드 OS에서 제공하는 시스템인 UI Automator의 기능을 사용하여 터치 이벤트를 발생하고 안드로이드가 게임 화면을 클릭하게 된다.
스크립트 작성자는 직접 제작한 게임 내의 플러그인을 통해 현재 화면에 보이는 게임 UI 구조를 파악할 수 있는 도구를 통해 게임 UI의 정보를 알아낸다. 해당 도구는 모바일 기기나 윈도우에서 실행하고 잇는 게임과 연결하여 현재 화면과 UI 구조를 추출, 파일 디렉토리와 같은 계층 구조 형태로 만들어 저장한다. 언리얼 엔진으로 만든 리니지2M의 경우 게임 내의 액터, 슬레이트, UMG로 이루어진 계층 구조를 모두 추출해 속성과 같이 볼 수 있도록 한다.
그렇다면 자동테스트는 게임 QA에서만 사용할 수 있을까? 콜 오브 듀티나 디비전2의 해외 사례처럼 게임 개발 과정에도 사용할 수 있다. 간단의 동작을 하는 스트립트를 만드는 것만으로도 게임 개발의 퀄리티를 쉽게 놓일 수 있다.
김종원 개발자는 자동테스트를 한다고 할 때 항상 BOT를 언급한다고 회고하며 BOT와 자동테스트의 차이를 언급했다. BOT는 특정 목적을 달성하기 위해 최적의 행동을 하여 보상을 극대화하는 것이 목표라면 자동테스트는 테스트 시나리오에 따라 일련의 동작을 수행하게 된다. 최대한 많은 체크리스트를 확인하는 것이 목표이며 의도적인 실패도 목표로 할 수 있다.
자동테스트를 위해 BOT AI도 사용할 수 있는 만큼 자동테스트가 좀 더 포괄적인 개념인 셈이다.
■ 게임QA와 함께하는 자동테스트
김종원 개발자는 자동화테스트를 통해 얻은 교훈과 비전을 이어나갔다.
기능이 변경된 내용은 사람이 직접 확인하고 변경되지 않은 기능은 자동테스트를 통해 보다 수월하게 점검할 수 있다. 지속적인 스크립트 관리의 필요성 역시 자동테스트의 특징이다. 대신 새벽, 주말 등에서도 테스트가 가능하며 시간의 제약이 사라지고 수 백 가지 항목을 반복할 수 있다. 간단한 검증이라도 이를 반복하면 중요한 검증이 되는데 이른바 양질전환인 셈이다. 또한, 단순/반복 테스트를 자동테스트로 전환하면 사람이 실수할 수 있는 여지를 없앨 수 있다.
그렇다면 이러한 자동 테스트를 위한 비용은 어떻게 될까? 우선 자동테스트 개발에는 자동 테스트 스크립트 작성보다 자동테스트 시스템을 개발하고 유지보수하는 데 더 많은 프로 그래머가 필요하다. 또한, 시스템의 안정적 운영과 개선에도 큰 개발비용이 들며 한 가지 방법으로 모든 테스트를 할 수 없는만큼 테스트 시스템도 계속 확장되어야 한다. 새 빌드, OS 업데이트, 새로운 모바일 기기 출시에 스크립트 검증과 유지 보수 비용도 새롭게 발생한다.
김종원 개발자는 이런 이유들 때문에 자동테스트에 대한 개발 비용과 운영 비용을 QA 비용과는 별도로 산정해 전체 게임 개발 비용에 편성해야 한다고 주장했다. 흔하게 하는 실수로 QA 비용을 줄이려 자동테스트를 도입하는 사례를 이야기한 그는 자동테스트를 통해 전체 QA 비용을 줄일 수는 없음을 분명히 했다.
자동테스트를 어렵게 만든 것도 이야기했다. 스크립트로 자동테스트를 진행하는 방식은 게임의 UI 변화에 취약하다. 또한, 오브젝트만을 식별하기에 시각적 문제점이나 소리가 제대로 나는지는 확인할 수 없다.
프로그래머가 자동 스크립트를 만들기도 하지만, 결국 게임 QA가 스크립트를 만들 수 있어야 한다. 하지만 게임QA는 현재의 스트립트 방식의 간단한 유지보수가 쉽지 않은 만큼 개선된 시스템이 필요하다.
상황에 따라서는 매뉴얼 테스트보다 자동테스트의 커버지리가 더 좁을 수 있다. 사람은 여러 개의 검증을 동시에 할 수 있지만, 자동테스트는 그렇게 하지 못하기 때문이다. 마지막으로 테스트가 실패한 경우에 나오는 에러 메시지만으로 문제의 원인 파악이 쉽지 않다.
김종원 개발자는 개발 빌드 파이프라인을 소개하며 빌드와 실행 환경 배포의 자동화, 개발팀에서 빌드 배포 전 빌드 동작 확인의 자동 수행이 마지막 QA 시간을 많이 절약할 수 있으리라 이야기했다.
그는 강연 시작 언급했던 자동테스트에 대한 부정적인 시각에 대한 인식 변화와 함께 자동테스트가 더 고도화될 수 있도록 많은 게임사가 이를 도입하길 바란다며 강연을 마쳤다.
Looa@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
