[번역] 1주일 안에 유니티 엔진을 테스트 하는 법

유니티 블로그에 올라온 How to test unity in a week? 를 번역했습니다. 

우연하게 접한 글의 제목이 제 호기심을 크게 자극했습니다. '유니티 엔진처럼 방대한 기능을 가진 앱을 어떻게 1주일만에 테스트할 수 있지?'라는 호기심어린 질문에 재미있는 답이 되었던 글입니다. 다만 유니티 내부에서 업무에 사용하는 단어들을 정확하게 알 수 없어 나름대로 최대한 독자들이 한 번에 이해할 수 있는 단어로 바꾸는데 오랜 시간이 걸렸습니다. 혹시라도 유니티 직원 분이 보신다면 적절한 단어를 알려주셔도 좋을 것 같네요. :) 

이 밖에도 유니티는 자사의 웹페이지를 통해 스스로의 QA 프로세스와 산출물, 이들을 통해 얻은 인사이트를 다양한 형태로 공유하고 있습니다. 여러모로 생각하고 배울 점이 많은 곳이니 한 번 시간내어 둘러보시기를 권해 드립니다. 

번역 및 블로그 공유에 대해서는 원 저자의 승인을 받았습니다. 

Happy Testing.  

SE(Sustained Engineering)분야에서 일하는 품질 전문가라면 지속적으로 마주할 수 밖에 없는 문제가 있다. 우리는 매주 버그 수정과 개선 사항이 반영된 마이너 버전의 유니티를 2번 배포한다. 우리가 수행하는 핵심 업무 중 하나는 이 빌드들의 품질을 평가하고, 발생 가능한 이슈들을 찾아내고, 개발팀에게 피드백을 제공해 업데이트를 배포해도 좋다는 그린 라이트를 밝혀주는 것이다. LTS(Long Term Support)버전에서는 이런 문제가 더 극명해진다. 어떻게 유니티처럼 복잡한 소프트웨어를 1주일만에 테스트할 것인가? 어떻게 수십만명의 사용자들이 다루는 물건을 엉망진창이 되지 않도록 유지할 것인가?

로봇을 활용하자

이 질문들의 첫 번째 대답은 이미 어느 정도 예측할 수 있을 것이다. 바로 자동화다. 실제로 수많은 자동화가 수행되고 있다! 우리가 배포하는 빌드는 58000개에 이르는 유니크한 테스트를 거쳐야 한다. ‘유니크(unique)’라는 표현을 사용했다는 것이 중요하다. 즉, 실제로 수행되는 테스트는 이보다 더 많다는 것을 의미한다. 수많은 테스트가 서로 다른 플랫폼과 설정 아래에서 수행된다. 

오래전에는 LTS 업데이트 배포를 하려면 빌드가 기대한 대로 움직인다는 것을 확인하기 위해 사람이 수행하는 테스트만 활용했다. 이런 테스트는 수행하는 사람에 따라 온갖 다른 스타일로 수행되었다. 자동화 테스트가 가장 많이 수행되는 부분은 에디터 테스트와 네이티브 테스트다. 에디터 테스트는 말 그대로 에디터의 기능성(functionality)을 테스트하는 것이다. 네이티브 테스트는 유니티 코드의 C++와 관련된 부분을 커버한다. 거의 대부분의 기능을 이 테스트를 통해 커버할 수 있다. 또한 플레이모드 테스트, 그래픽 테스트, 퍼포먼스 테스트와 같은 이름의 테스트들도 수행된다. 이 중 단 하나의 테스트만 실패해도 어떤 이유로 테스트가 실패했는지 다시 조사를 받아야 한다. 그 다음 이를 수정하고 다시 새로운 빌드를 생성한다.

빌드가 이 모든 테스트를 통과하면 그제서야 테스트를 수행하는 ‘사람’들에게 인계된다. 사람이 수행하는 QA 프로세스가 시작되는 것이다.  이 프로세스는 크게 2개의 단계로 구별된다. 케이스 검증(Case verification) 단계는 우리가 수정되었다고 알고 있는 버그들이 실제로 수정되었는지 확인하는 단계다. 그 다음 “노 리그레션(no regression)” 단계는 이런 수정을 통해 새로운 버그가 발생하지 않았는지 확인하는 단계다. LTS와 테크 릴리즈 모두에 동일하게 이 과정이 적용된다는 것을 미리 알려주는 게 좋을 것 같다. 이를 통해 두 버전 모두 동일하게 일정 수준 이상의 품질을 유지할 수 있게 된다. 

케이스 검증

업데이트에 포함된 모든 버그 수정이 이 버그와 관련있는 사람에 의해 검증되는 과정이다. 유니티 조직에 속해있는 모든 사람이 이 과정을 수행할 수 있다. 그래픽이나 2D 분야처럼 특정 분야에 특화되어 있는 임베디드 퀄러티 엔지니어, 고객으로부터 피드백을 받아 버그를 재현하고 수정하는 필드 엔지니어, 유니티 사용자들로부터 쏟아지는 수백개의 보고서를 버그 리포트로 바꿔주는 역할을 수행하면서 유니티 QA의 최일선에 서 있는 QA 스튜던트 워커 팀 모두가 이 과정을 수행할 수 있다. 

앞서 이야기한 모든 사람들이 버그가 수정되었는지를 확인할 책임을 가지고 있다. 일반적으로 이 단계에서 버그 수정을 검증하는 것은 이미 두 번째 혹은 세 번째 중복해서 검증하는 것이다. 이미 누군가가 특정 배포 버전에 포함되기 전에 개발 브랜치에서 이 수정을 확인했을 것이기 때문이다. 

앞에서 설명한 과정들은 우리가 무언가 수정되었다고 말하는 것이 얼마나 힘든 과정을 거쳐서 말할 수 있는지를 잘 보여주는 것이다. 그리고 그렇게 말할 수 있다는 것은 실제로 수정되었다는 것을 의미한다. 만일 버그 수정이 제대로 수행되지 않았다면, 버그는 최초로 수정했던 개발자에게 다시 할당된다.  

이 과정의 긍정적인 사이드 이펙트는 빌드를 여러 번에 걸쳐서 검증할 수 있다는 것이다. 서로 다른 영역의 서로 다른 사람들이 빌드를 검증하고 각각의 품질 기준으로 빌드를 평가할 수 있는 것이다. 

배포 인수 테스트(Release Acceptance Test) 

우리가 수행하는 여러 테스트 단계들 중에서도 베이스라인이 되는 테스트라고 할 수 있다. 모든 것이 수동으로 진행되는 테스팅 단계이며 이를 통해 유니티의 다양한 부분을 검증하고 기본적인 부분들이 정상적으로 동작한다는 것을 확인하게 된다. 3D, 2D, 애니메이션, XR을 비롯한 주요 영역을 커버한다. 가장 대중적인 플랫폼들에서 빌드의 모든 기능이 제대로 수행되는 것을 테스트한다. 윈도우, 맥OS, 안드로이드, iOS 그리고 지원하는 콘솔에서 테스트를 수행한다. 

집중 탐색적 테스팅(Targeted Exploratory Testing)

앞서 언급한 배포 인수 테스트는 “중요한 것이 손상되지 않은” 단계다. 매번 다른 빌드에서도 거의 동일하게 수행되며 배포에 포함될 수정이 어떤 유형이라고 하더라도 크게 영향받지 않는다.  

수정으로 인해 이번 빌드에서 발생할 가능성이 있는 리그레션 이슈를 파악하기 위해 집중 탐색적 테스팅 단계를 수행하고 있다. 매주 업데이트에 포함되어 우리가 검증해야 하는 다양한 형태의 수정을 검토하는 회의를 가지고 있다. 이 검토 결과에 따라 어느 부분을 더 집중해서 살펴야 하는지가 결정된다. 만일 광범위한 부분에 영향을 미치는 주요 2D 수정 사항이 있다면 2D 기능과 관련된 광범위한 탐색적 테스팅을 수행한다. 좀 더 집중적으로 테스트를 수행하기 위해 특정 영역을 테스트하는 사람은 해당 영역의 수정 사항과 코드까지 살펴본다. 이를 통해 테스팅을 좀 더 집중적으로 수행할 수 있게 된다. 

프로젝트 테스팅

유니티를 사용하는 다양한 게임과 애플리케이션 프로젝트가 존재한다. 우리는 버전을 업그레이드할 때 이들 게임이나 애플리케이션에 문제가 없는지 확인하는 테스트를 수행한다. 새로운 빌드로 이들 프로젝트를 임포트하고 이들을 에디터에서 불러와 에러가 없는지 확인한다. 대부분의 경우 유니티 파이프라인에서 이상이 없는지 확인하기 위한 별도의 빌드를 생성한다. 

애셋 스토어에서 인기있는 패키지들 역시 테스트 대상에 포함된다. 우리 콘텐츠 팀이 만든 3D 게임 킷이나 타워 디펜스 템플릿,  파티클이나 2D 물리와  같은 특별한 영역을 테스트하기 위해 그 밖에 내부 조직이 만든 패키지들도 테스트 된다. 

미래

앞서 이야기한 모든 내용들이 최대한 LTS를 안정적으로 만들고, LTS를 거치는 산출물에서 이슈가 발견되어 사용자에게까지 전달되지 않기 위해 수행되는 작업들이다. 이런 작업들을 현재도 훌륭하게 수행하고 있으며 또한 더 잘 하려고 노력하고 있다.  이런 이유로 앞서 언급한 모든 내용들이 3개월 뒤에는 정확하게 일치하지 않을 수도 있다. 우리는 항상 우리가 무엇을 하는지 조사하고 그 결과에 따라 프로세스를 조정하는 작업을 수행하고 있다. 

가능한 빨리 문제를 포작하고, 가능하다면 문제가 될 수 있는 원인을 제거하는 것이 바로 우리의 철학이다. 우리의 최종 목표는 LTS 릴리즈에서 “거의 제로에 가까운” 리그레션을 수행하는 것이다. 아무리 많은 수정이 수행된다고 해도 상관없다. 

이 목표를 달성하기 위해 우리가 하고 있는 일의 하나는 바로 근본 원인 분석(Root Cause Analysis)이다. 우리가 놓쳤던 크리티컬 이슈들을 식별하고, 왜 우리가 이 이슈들을 놓쳤는지 분석한다. 그리고 무엇보다 중요한 것은 처음에 어떻게 이 이슈가 생겨날 수 있었는지 분석하는 것이다. 우리가 발견해 낸 것에 근거해 향후에 비슷한 이슈들을 더 잘 처리할 수 있도록 프로세스를 최적화한다. 

유니티의 전반적인 품질을 향상시킬 수 있는 툴을 제작하고 찾아내는 데도 상당한 시간이 할애된다. 개발자가 코드를 커밋했을 때 유용한 피드백을 남기는 툴에서부터, 좀 더 쉽게 코드에서 위험한 부분을 식별해 내고 테스팅을 최적화할 수 있는 데이터 분석 툴에 이르기까지 광범위한 툴이 그 대상에 포함된다. 이미 사용중인 툴도 있으며 일부는 프로토타이핑을 진행 중이고 일부는 아직 구상 중에 있다. 

유니티는 수 백만의 사용자가 흥미롭고 창조적인 방법으로 사용하는 매우 복잡한 소프트웨어 구성품이다. 이런 소프트웨어의 일부를 1주일 안에 테스트하고 어떤 수정 사항도 리그레션 이슈를 만들지 않았다고 확인하는 것이 가능할까? 정말 풀고 싶은 어려운 문제다.