[인벤게임컨퍼런스(IGC) 발표자 소개] 엔씨소프트 김종원 팀장은 前 리니지 이터널 테크니컬 디렉터로 6년 간 일했으며 현 NC소프트 SET팀에서 모바일 테스트 자동화 시스템 개발에 힘쓰고 있다.
발매 전 테스트는 아무리 강조해도 지나치지 않다. 비단 게임에만 국한된 것이 아니라 이 세상에서 생산되는 모든 제품, 컨텐츠는 정교한 점검과 테스트 과정을 거친 후에 비로소 세상에 나타난다. 테스트가 부실하면 개발 과정에서 미처 잡지 못한 오류가 사람들을 괴롭히고, 이는 개발자에게 부메랑이 되어 날아온다.
하지만 테스트를 해야 할 제품은 많은데, 사람은 한정되어 있고 출시일은 점점 다가온다. 그렇다면 테스트 과정 자체를 자동화 시스템에 맡길 수는 없는 것일까? 게임의 자동 테스트 시스템은 가능한 것인가? NC소프트 SET팀에서 모바일 테스트 자동화 시스템을 맡고 있는 김종원 팀장이 여기에 대한 해답을 주러 나섰다.
■ 강연주제: 모바일 테스트 자동화 시스템
⊙ 방심은 금물! 테스트의 중요성
가장 먼저 우리에게 익숙한 영화 포스터가 눈에 띄었다. '마션'. 화성에 고립된 남자가 살아남기 위해 혼자 악전고투하는 내용을 담은 원작 소설 기반으로 제작된 영화다. 김종원 팀장은 곧이어 "화성에 사람이 살아있다는 걸 안 지구 측에서 어떻게 행동했는지 기억하느냐"고 물었다.
물자 탑재에 3일, 점검과 시험 과정에 10일. 인간의 생존 시간을 고려한 지구에서는 시간에 쫓기며 점검과 시험 과정을 통째로 생략하고 보급선 발사 일정을 당기기로 했다. 그리고 보급선은 발사 과정의 결함 때문에 발사대에서 폭발했다. 김종원 팀장이 말한대로 '테스트의 중요성'이 부각된 장면이었다.
개발자들의 상황도 '마션'과 크게 다르지 않다. 출시 일자는 다가왔는데 아직 테스트는 못했고, 윗선에게 쪼이면서 이벤트 일정에 맞춰 출시했더니 테스트의 부재 때문에 발생한 책임은 윗 사람이 아닌 다른 누군가가 책임진다는 것이다. 그리고 화면에는 최근 뉴스를 본 사람이라면 모를 수가 없는 한 핸드폰 기종이 나타났다.
김종원 팀장은 "갤럭시 노트7입니다. 더 이상 자세한 설명은 안 드리겠습니다"라고 말했고, 장내에 웃음이 터졌다. 노트7 역시 같은 상황이다. 아이폰 출시 일정과 겹치지 않기 위해 출시 일정을 1개월을 당겨버렸고, 그 과정에서 생겨난 테스팅의 부재가 어떤 결과로 나타났는지 모두가 알고 있다.
테스팅하면 유명한 곳 중 하나가 바로 구글이다. 구글은 테스팅 전문 인력 100여 명을 모아 SET팀을 만들었다. SET팀은 직접 테스트를 치르는 것이 아니라 완벽한 테스팅 인프라를 구축하는 역할을 맡는다. 그렇기에 SET팀은 시니어만이 들어갈 수 있다. 어차피 경험이 적으면 SET팀에서 제대로 직무를 수행할 수 없다는 이유에서다.
또, 사장 직속인 생산성 혁신팀을 만들어 개발에 필요한 도구, 테스팅 환경을 조성한다. 마찬가지로 테스팅을 해주는 것이 아니라 테스팅을 하는 데 있어 문제가 생기지 않도록 원인을 파악하고 예방하는 게 주 목적이다. 테스트 코드는 개발자에게 짜게 시키고 SET팀은 여러 프로그램이 엮인 중급 규모의 테스트를 하게 되고 실제 사용자들이 하는 테스트는 테스트 엔지니어가 맡는다. 사장이 직접 속도가 아니라 퀄리티가 중요하다고 못을 박았기에 조성된, 극상의 퀄리티를 추구하는 환경이다.
⊙ 게임 테스트의 자동화, 실현 가능한가?
모바일 게임을 만들고 나면 여러 이슈가 발생한다. 그중 유저 측면에서 보면 모바일 게임은 PC게임에 비해 브랜드 충성 고객이 적고 유저 이탈이 쉽게 일어난다. 게임을 하는 중 두어 번만 충돌이 일어나도 이를 해결하려고 애쓰기보다 그냥 게임을 지워버리는 쪽을 택하는 이들이 상당히 많다. 하물며 게임이 단 하나일 때도 유저 이탈이 잦은데, 한 회사에서 게임을 2개, 3개 출시하면 어떻게 될까? 개발할 때는 몰랐지만 막상 출시를 하게 되면 전혀 다른 형태로 접근할 수밖에 없다.
그렇다면 테스트 자동화 시스템은 가능한 것일까? 많은 개발자들은 '테스팅은 사람이 해야지 어떻게 기계가 하느냐'는 얘기를 한다. 김종원 팀장 역시 이에 동의하며 사람이 하는 것만큼은 할 수 없다고 말했다. 다만 자동 테스트로 커버할 수 있는 범위가 사람이 할 수 있는 범위를 넘어서고 있다고 언급하기도 했다. 과거에 '운전은 사람이 해야지 어떻게 자동으로 운전을 하느냐'는 얘기가 나왔지만 현재 자동주행 시스템이 장착된 테슬라의 예를 들며.
다만 게임이라는 특성이 지닌 명확한 한계도 함께 언급했다. 게임 내 렌더링 엔진에서 UI를 만들더라도 그것이 표준화된 형태를 따르지 않기 때문에 테스트 자동화 영역에서도 게임이 가장 뒤처져있다는 것이다. 자동화 테스트는 대부분 좌표를 기반으로 하는데, 당장 테스트 기기가 달라 해상도가 바뀌거나 OS가 달라지면 그 좌표가 어긋나기 때문이다.
그럼에도 불구하고 자동화 테스트는 필요함을 어필했다. 테스트 가능 인원은 한정되어 있고 테스트를 할 기기는 많은데 시간은 없기 때문이다.
모바일 자동 테스트 방법 중 하나로 가장 먼저 언급된 것은 '몽키테스트(Monkey Test)'였다. 말 그대로 원숭이에게 기기를 던져주고 반응을 지켜보듯이 랜덤하게 화면을 터치하거나 버튼을 눌러보는 등의 방식으로 일정 시간 동안 테스트를 하는 방법이다. 몽키테스트를 30분 가량 하면 웬만한 데이터는 수집이 된다는 조건이 있지만 문제는 몽키테스트가 게임에는 어울리지 않는다는 것이다. 게임은 특정 상황에서 특정 스킬을 눌러야 진행이 되는 등 여러 상황이 있기 때문에 몽키테스트처럼 마구잡이로 터치를 해서는 의미가 없기 때문이다.
두 번째는 애피움(Appium)이다. 본래 웹 브라우저를 테스트하기 위해 개발된 웹드라이버 API를 그대로 가져와 쓰기 때문에 자바, 파이썬 등 기존의 언어를 그대로 스크립트로 쓸 수 있다는 장점이 있다. 김종원 팀장은 계속해서 안드로이드 앱의 테스트 과정을 설명했다. 디바이스를 연결해 애피움 서버를 실행한 뒤 테스트 스크립트를 실행시키면 애피움이 부트스트랩 앱을 다운받는다. 부트스트랩이 애피움 서버와 연결된 후 UI오토매이터 API로 서버 명령을 전달하면 그것을 애피움 서버가 받아 UI오토매이터를 이용해 앱의 동작을 제어한다는 것이다.
⊙ 아직 머나먼 길, 그러나 진보한다
다만 애피움만으로는 여전히 해결이 되지 않는다고도 말했다. 이에 테스트 자동화를 위한 모듈을 개발, 화면상 좌표로만 테스트를 하던 기존의 방식에서 벗어나 게임 내 UI 오브젝트 정보를 제공하는 유니티3D 플러그인을 정착시켰다. 화면 배치가 바뀌어도 동작이 되도록 좌표가 아니라 문자열을 사용했고, 오브젝트 기반 테스트 스크립트가 작성되면서 오브젝트ID까지 생성됐다. 이렇게 문자열ID 기반의 스크립트를 한 번 작성하면 해상도가 바뀌어도 재사용이 가능하기 때문에 테스트 속도가 향상되고 정확도가 올라갔다.
하지만 NC정도 되는 규모의 회사가 아니라 중소규모 회사라면 어떻게 되는 것일까? 김종원 팀장은 테스트를 위한 툴을 직접 개발할 수 없는 상황이라면 애피움의 이미지 비교 방식을 사용해 볼 수 있다고 전했다. 또, 클라이언트 프로그래머의 지원을 받을 수 있다면 애피움을 건너뛰고 프로그래머와 테스터가 직접 붙어서 테스팅을 하는 것이 좋다고 말했다.
오브젝트 기반 테스트를 할 때는 ID를 명명하는 것도 중요한 과정 중 하나다. ID는 중복 없이 컨텐츠마다 이름 규칙을 부여하고 반복 사용하는 오브젝트는 ID가 짧을수록 좋다. 또, 연속된 동작에서 같은 ID를 사용한 UI오브젝트를 넣는 것은 피해야 한다. 예를 들어 재사용되는 팝업 윈도우의 경우 어느 화면에서 열린 윈도우인지 파악이 힘들어지기 때문에 스크립트 작성 단계에서부터 혼동을 피할 수 있게 미리 구분을 지어놔야 하는 것이다. 특히 화면에서 동시에 여러 객체를 같은 이름으로 생성하는 것은 스크립트에서 구별할 수 없기 때문에 반드시 피해야만 한다.
오브젝트 기반 테스트 덕분에 자동화 테스트에 큰 발전이 있었지만 아직 갈 길은 멀다. 자바 코드를 짜는 것보다 조금 더 직관적인 스크립트 명령어를 남겨야 한다. 또, 현재 스크립트 중간부터 재실행을 할 수 있는 방법이 없어 매번 처음부터 스크립트를 돌려야하기 때문에 여기에 대한 보완도 필요하다. 애피움도 계속 수정 중이기 때문에 그때마다 머지를 해야 하는 번거로움도 남아있다. 유니티3D 외에 언리얼 등 다른 게임 엔진을 지원하는 플러그인의 개발도 필수적이다.
게임의 자체적인 특성상 자동화 테스트는 아직도 걸음마 단계에 있다. 그러나 자동화 테스트는 분명 조금씩이지만 진보하고 있고, 앞으로 어떤 일이 펼쳐질지는 아무도 모른다. 테스트 자동화가 불가능한 꿈이 아니라 충분히 실현 가능한 목표란 생각을 갖고 앞으로 나아가는 사람들이 더 생긴다면, 우리는 그 날을 조금 더 빨리 보게 되지 않을까.
■ 질의응답
맵에서 크래쉬가 나면 어떻게 해결하는지?
= 크래쉬가 나면 크래쉬용 덤프를 분석하는 앱을 쓸 수 있다. 그런 앱을 통해서 보기도 하는데 테스팅 과정 중에는 일단 스크립트에서 그걸 찾아낼 수 있다. 크래쉬 분석 툴은 테스트보다 훨씬 중요하다. 단 한 번이라도 나온 건 100% 다시 나온다. 무조건 원인을 찾아서 다 잡아야 한다. 테스트 과정 중에 테스트 모듈 때문에 발생한 크래쉬라고 할 수도 있겠지만 사실 모듈이 하는 일은 별로 없다. 근본적으로 해결할 문제라고 생각을 하고 반드시 처리해야만 한다.
호환성 테스트를 할 때 UI가 깨지거나 안의 글자가 삐져나가더라도 테스트가 가능한지?
= 시각적인 검증 여부를 물은 것 같다. 해결책 중 하나는 레퍼런스가 가능한 정답지를 만들어놓고 그걸 비교하는 것이다. 지난 번에는 제대로 됐다고 하더라도 이번에 되지 않았다면 화면이 바뀌었는지 확인을 해보고, 그게 아니라면 그건 버그라고 볼 수 있다. 우리는 별도의 시스템을 계속 고민하고 있다. 다만 이 자리 뿐만 아니라 당장 답이 나올 문제는 아니라고 생각한다. 사람의 시각으로 판단 가능한 문제를 컴퓨터가 어떻게 해결하느냐는 앞으로 논문이 여러 장 나올 수도 있는 문제다. 지금으로선 레퍼런스를 비교하는 게 가장 현실적인 해결 방안이라고 생각한다.
용량이 큰 앱을 다운받았을 때는 초기화 시간이 생각보다 오래 걸리는데 어떻게 해결하면 되는지?
= 매번 다운로드 용량이 1GB씩 되면 그럴 수도 있겠지만, 대부분 애피움 자체는 큰 문제가 되지 않고 adb를 통해 디바이스에 다운받아 설치하는 과정에서 시간이 소요된다. 설치하는 과정을 스킵하게 한다거나 이미 설치됐을 때 재실행할 경우엔 다시 설치하지 않게 옵션을 줘야 한다.
안드로이드는 배터리 부족 등 팝업이 뜨는데, 그 팝업 때문에 테스팅에 방해가 될 때는 어떻게 하는지?
= 기본적으로 제어할 수는 없다. 그것 역시 인식을 해 줘야 한다. 버튼을 눌러야 하는데 다른 화면이 떠있으면 그걸 닫고 진행을 하는 등 예외 상황에 대한 코딩을 해 줘야 한다. 아니면 문자나 통신 이벤트 등을 다 끄도록 설정을 할 수도 있다.
desk@inven.co.kr