[유나이트 서울 2018 발표자 소개] 안현석 디렉터는 현재 에이스프로젝트 개발팀에서 디렉터로 재직 중이며, 과거 넥슨에서 팀장, 실장을 거쳐 10년 가량 개발팀에서 재직했다. 대표작으로는 모바일 메이플스토리 시리즈가 있다.
게임 개발 과정에서 여러 가지 고려해야 할 사항이 있지만, 가장 먼저 고려해야 할 부분은 디바이스에서 구동이 가능해야 한다는 것이다. 실제 게임의 재미 유무를 떠나서, 실행조차 되지 않으면 게임이라고 할 수가 없기 때문이다.
제작 과정에서 개발자들은 구동 여부를 테스트하기 위해서 빌드라는 과정을 거친다. 자신들이 제작한 프로젝트들을 구동 가능한 형태로 바꾸고, 이를 직접 기기 혹은 시뮬레이터에 돌리면서 제대로 작동 가능한지, 혹은 구동 간에 어떤 버그나 문제가 발생하는지 테스트하는 것이다.
이렇듯 빌드는 게임 개발에서 꼭 필요한 것이다. 그렇지만 이 과정은 상당히 많은 시간이 소요될 뿐더러, 빌드가 이루어지는 동안에는 해당 프로젝트나 잡에 손을 댈 수 없어 사람이 하나하나 처리하기엔 비효율적인 과정이다. 특히나 모바일 빌드는 별도의 기기에서 직접 빌드를 구동해봐야 하기 때문에 다운로드 과정도 필요하다. 이에 개발자들은 이런 일련의 과정을 자동화해서 효율을 높이는 방법을 고민해보고는 한다.
에이스프로젝트의 안현석 디렉터는 이번 유나이트 서울 2018 강연을 통해서 유니티 모바일 빌드 자동화를 어떻게 하는지 파이프라인을 설명하고자 한다. 뿐만 아니라 빌드를 더 효율적으로 자동화하기 위해서, 어떤 점을 고려해야 하는지에 대한 고민도 공유했다.
모바일 빌드를 구현할 때 주로 사용하는 프로젝트로 엑스코드와 이클립스, 안드로이드 스튜디오 등이 있다. iOS는 엑스코드를 사용해서 IPA 파일로 만들어내고, 안드로이드는 이클립스나 안드로이드 스튜디오, 글래드 등을 활용해서 APK로 만들어낸다는 것이 통상적으로 알고 있는 모바일 빌드 과정이다.
안현석 디렉터는 이 과정을 한 번 더 되짚으면서, 빌드 과정에서 유의할 점을 먼저 설명했다. 우선 통상적으로 빌드를 만들려면 스위치 플랫폼창을 클릭하고, 플레이어 세팅을 들어간다. 그리고는 안드로이드나 iOS 등 각 플랫폼별로 특화된 세팅을 지정하는 과정을 거치게 된다.
iOS의 경우는 엑스코드로 iOS용 빌드를 만들어낸다. 유니티에서 바로 IPA 빌드를 만들어낼 수 없기 때문이다. 여기서 리플레이스 모드와 어펜드 모드가 있는데, 리플레이스 모드는 프로젝트 설정을 빌드 때마다 계속 신규 설정으로 바꾸는 방식이고, 어펜드 모드는 새로 추가된 것을 기존의 것에 덧붙이는 방식이다. 또한 iOS의 경우 시뮬레이터에서 잘 안 돌아가는 경우가 있어서 시뮬레이터 SDK와 디바이스용 SDK가 따로 지정되어있다. 업데이트와 빠른 다운로드를 제공하기 위한 비트 코드의 경우, 계속 사용할 경우 앱 용량이 커지고 써드파티 라이브러리에서 충돌이 발생하기 때문에 보통은 No로 설정해두는 것이 편하다. 그렇지 않으면 충돌로 인해서 빌드 오류가 일어나는 경우가 있고, 이를 처리하는 과정도 번거롭기 때문이다.
안드로이드는 흔히 ADT, 그래들 두 방식을 활용한다. ADT는 이클립스나 앤트로 빌드가 가능하고, 그래들은 안드로이드 스튜디오 또는 그래들로 빌드를 한다. iOS보다 더 간편한 점은, 유니티에서 바로 APK 빌드가 가능하다는 점이다. 다만 APK 빌드에서도 안드로이드 SDK, NDK, JDK 설정을 할 필요가 있다. 또 어펜드 모드가 없기 때문에, 빌드를 만들 때마다 새로운 프로젝트가 적용된다는 점을 유의해야 한다.
또한 구글에서는 더 이상 ADT를 지원하지 않기 때문에, 그래들을 활용해야 한다는 점도 강조했다. 안현석 디렉터는 여기에서 자신이 겪은 사례를 언급했다. 자체 서비스했던 게임이 있었는데, 여기에 모듈을 계속 추가해나가다가 오류가 발생했던 것이다. ADT를 사용해서 빌드했는데 ADT는 64K의 참조 제한이 걸려있었다. 즉 6만 4천 개 이상의 모듈이 붙게 되면 빌드가 제대로 안 되는 일이 발생하는데, 그 때문에 게임이 오류가 발생했던 것이다. 그 외에도 ADT에서는 멀티덱스 문제가 해결이 안 되는 등 다양한 이슈가 존재한다.
또한 안현석 디렉터는 APK 빌드를 사용하는 것을 권장하기도 했다. ADT나 그래들은 유니티 빌드를 한 이후, 별도로 나온 ADT나 그래들 프로젝트를 다시 컴파일해야 하는 과정을 거치지만 APK는 그런 것 없이 바로 유니티에서 나오기 때문에 빠르다는 이점이 있다. 또한 키스토어 생성 및 사이닝이 유니티에서 자체적으로 다 하므로 더 편리하다
빌드를 하면서 플레이어 세팅 과정도 빼놓을 수 없는 만큼, 안현석 디렉터는 이 부분도 짚고 넘어갔다. 보통 세팅은 스크립트를 통해서 진행되는데, 특히나 iOS의 경우에는 플레이어 세팅을 할 때 빌드를 할 때마다 값을 바꾸거나 하는 등의 번거로운 과정을 거칠 때가 많다. 그보다는 스크립트 빌드를 사용해서 스크립트를 고쳐서 적용하는 게 더 편한 만큼, 스크립트 빌드를 주로 활용하게 된다.
여기서 어펜드 모드의 문제가 발생하게 된다고 안현석 디렉터는 덧붙였다. 어펜드 모드는 말 그대로 '추가하는' 방식이다. 이 말은 기존의 것은 건드리지 않고, 새롭게 바뀐 부분만 더한다는 의미다. 따라서 유니티 버전이 업데이트되거나, 엑스코드 프로젝트 생성 방식이 바뀌어도 기존의 내용을 변화시키거나 하지 않아서 빌드가 꼬이는 일이 발생한다. 그래서 최근에는 리플레이스 모드를 활용하는 추세다.
스크립트로 빌드를 하게 되면 코드에 포스트프로세스 빌드를 어트리뷰트하고, 프로세스 프로젝트를 로딩하는 과정을 스크립트로 적어두게 된다. 여기서 포스트프로세스 빌드는 유니티 빌드가 끝나고 나서 포스트빌드가 달린 함수를 호출하고, 엑스코드를 통해서 수정하고 다시 적용하는 방식으로 짜게 된다.
이렇게 빌드가 이루어지는 과정을 설명한 뒤, 안현석 디렉터는 왜 빌드가 자동화되어야 하는가에 대해서 언급했다. 앞서 말한 과정뿐만 아니라, 유니티 모바일 빌드 과정은 사실 번거로운 과정이다. 스위치 플랫폼에 들어가서, 유니티 빌드를 하고 이것을 또 iOS와 안드로이드에 맞춰서 빌드를 해야 한다. 프로젝트와 잡의 양이 적으면 바로바로 빌드가 이루어지지만, 그 양이 많을수록 이 과정에서 소요되는 시간이 상당하다.
뿐만 아니라 빌드 중에는 프로젝트에 손을 댈 수가 없기 때문에, 그와 관련된 작업을 할 수 없다. 뿐만 아니라 컴파일/빌드 작업의 시스템 점유율이 가장 높기 때문에 다른 프로그램을 사용하는 작업을 하기도 어렵다는 것도 문제다.
그리고 빌드 과정은 익숙해지면 단순한 반복 작업이라는 것을 알 수 있다. 똑같은 패턴으로 계속 반복되는 작업이기 때문이다. 이런 작업을 자동화하지 않을 이유가 없다고 안현석 디렉터는 역설했다. 또한 이런 단순 반복 작업을 계속 하다보면, 사람은 실수를 할 수 있다. 테스트용 빌드를 배포해버리거나, 혹은 패치 중인 빌드를 배포해버리는 등의 실수가 나올 수도 있기 때문이다. 이런 실수를 줄이기 위해서는 자동화된 과정이 필요하다고 강조했다.
또한 빌드를 하다보면 빌드 환경의 차이도 상당히 중요한 요소다. 유니티 버전 차이, iOS, 안드로이드 SDK 버전 차이, 엑스코드, 앤트, 그래들 등의 버전 차이 등은 빌드에서 큰 영향을 주기 때문이다. 이런 걸 하나하나 체크하는 과정은 어렵진 않지만, 번거로운 과정이다. 이 과정을 자동으로 체크하고 적용하는 과정을 통해서 더 효율적으로 빌드를 만들 수 있다고 안현석 디렉터는 역설했다.
유니티에서 빌드 자동화를 할 때 주로 사용하는 것이 무엇이 있을까? 안현석 디렉터는 젠킨스와 유니티 클라우드 빌드를 대표적인 CI툴로 들었다. 그러면서 젠킨스와 유니티 클라우드 빌드의 각각 특징에 대해서 설명하고, 장단점에 대해서 언급했다.
우선 젠킨스는 무료 오픈 소스라는 장점이 있다. 다양한 버전 관리 시스템과 빌드를 지원하는 데다가, 유니티뿐만 아니라 코코스, 언리얼, 자바 등에도 활용이 가능하기 때문에 사용자의 수가 많다. 그런 만큼 레퍼런스도 풍부하고, 플러그인도 많다는 장점도 있다. 게다가 오픈소스인데도 홈페이지를 통해서 유지보수가 잘 되고 있기도 하다. 다만 젠킨스는 빌드에 관련해서 지식이 필요하다는 단점이 있다.
유니티 클라우드 빌드는 매달 9달러 가량을 지불해야 하지만, 유니티 전용 빌드 자동화 서비스가 구축이 되어있다. 즉 빌드 전용 맥이나 피씨가 필요 없이 간단하고 쉽게 빌드 자동화 세팅이 된다는 장점이 있다. 그만큼 빌드 세팅에 소요되는 시간이 단축된다는 장점이 있지만, 젠킨스처럼 세세한 설정이 어렵다는 단점도 있다.
그렇다면 이 둘을 활용해서 유니티 모바일 빌드 자동화는 어떻게 할 수 있을까? 우선 안현석 디렉터는 젠킨스를 활용한 모바일 빌드 자동화 과정에 대해서 설명했다. 젠킨스를 잘 보면 잡마다 빌드 성공 시각, 실패 시각, 소요 시간도 나와있다. 빌드는 아이콘을 누르면 바로 실행할 수 있으며, 왼쪽에 뜬 아이콘의 색을 통해서 빌드의 성공과 실패도 확인할 수 있다.
왼쪽 하단의 바를 통해서 빌드 실행 상태가 나오고, 노드별 빌드 진행 상황을 알 수 있다. 콘솔 아웃풋으로 빌드 상황 및 실패 사유를 체크할 수 있기 때문에 빌드가 안 됐을 때는 이 부분을 체크해서 문제를 파악할 수 있다.
이런 기본적인 사항을 한 번 짚고 넘어간 뒤, 안현석 디렉터는 필수적인 플러그인에 대해서 설명했다. 유니티 프로젝트를 먼저 빌드하기 위해서는 유니티 3D 플러그인이 필요하고, iOS 빌드를 작성하기 위해서는 엑스코드 플러그인이 필요하다. 안드로이드 빌드를 위해서는 앤트와 그래들 플러그인을 설치해야 한다.
이렇게 빌드 전에 기본적인 구성을 갖추고 나면, 빌드 전 단계와 빌드 단계, 빌드 후 조치라는 세 단계를 거쳐서 빌드를 만들게 된다. 빌드 전 단계는 빌드를 하기 전 소스코드에서 소스를 받고, 빌드를 어느 시점에서 유발하고, 어떤 환경에서 빌드를 만들어낼 것인지 설계하는 단계다.
그 단계가 끝난 뒤에 빌드 단계를 통해서 실제 구동 가능한 빌드를 작성해나가게 되고, 이후 조치 과정을 거친다. 여기에는 테스트 및 배포, 알림 과정을 포함하고 있다.
빌드 과정에 대해서 더 자세하게 파고들면, 처음에는 프로젝트 설정을 거치게 된다. 이 과정에서 빌드 프로세스를 실행할 노드와 프로젝트가 저장될 폴더를 지정하게 된다. 그 뒤에는 소스코드를 관리하는 과정인데, 이는 저장소에서 소스코드를 가져오는 단계다. 여기에서 빌드할 브랜치를 설정해야 하는데, 안현석 디렉터는 Git을 주로 활용하고 있다고 덧붙였다.
그 뒤에 체크아웃 폴더를 지정하고 빌드 유발하는 과정을 거치게 되는데, 박스 부분은 스케쥴을 기록해서 정기적으로 진행하도록 설정하는 것이다. 윈도우 위쪽에 명시된 트리거는 어떤 조건이 끝나면 빌드를 돌리겠다고 설정하는 부분이다. 즉 새로운 커밋이 있거나, 변동 사항이 있을 때 돌리겠다는 세팅을 할 수 있는 것이다.
이후에 빌드 과정으로 넘어가게 되는데, 각 빌드는 앞서 말한 플러그인을 활용해서 빌드할 수 있다. 우선 유니티 빌드를 작성해야 하기 때문에 유니티 플러그인을 활용해서 빌드를 만드는데, 그 과정은 앞서 언급한 것처럼 스크립트로 진행하게 된다. 그 스크립트를 젠킨스에서도 노출, 적용할 수 있기 때문에 이 부분은 쉽게 진행할 수 있다고 안현석 디렉터는 설명했다. 이후 엑스코드 빌드 프로젝트나, 안드로이드용 빌드 프로젝트로 만드는 과정을 거치게 된다.
다만 엑스코드 빌드의 경우, 엑스코드 9 버전의 이슈로 인해서 플러그인은 아카이브까지만 하고, 아카이브 이후에 엑스코드 빌드를 익스포트하고 IPA 빌드를 만드는 과정이 필요하다고 덧붙였다. 그 뒤에 빌드를 업로드하고, 메일이나 슬랙 등으로 알리는 과정을 거치면 빌드 과정은 일단락된다.
유니티 클라우드의 경우는 대시 보드 형태로 메뉴가 있기 때문에 이를 한 눈에 볼 수 있다는 장점이 있다. 원래는 따로 있던 콜라보레이터나 버그리포트도 대시 보드에 같이 붙어있기 때문에 이를 한꺼번에 처리할 수 있다는 이점도 있다고 덧붙였다.
유니티 클라우드로 빌드하기 위해서는 우선 소스 컨트롤 설정 컨피그에 들어가서 소스 컨트롤을 설정하고, 프로젝트와 빌드를 저장할 곳을 지정해야 한다. 그 후에 플랫폼을 설정하는 창이 나오고, 빌드의 기본 정보를 설정하는 창이 나온다.
이때 다른 부분보다 브랜치의 설정과 유니티의 버전 설정이 가장 중요하다고 안현석 디렉터는 강조했다. 이 부분에 따라서 빌드가 달라질 수 있기 때문이다. 유니티 클라우드에서는 유니티 버전이 다양하게 갖춰져 있고, 심지어 세부 패치 버전까지 다 나뉘어서 제공하고 있기 때문에, 이를 선택할 때 유의할 필요가 있다고 다시 한 번 강조했다.
대신 유니티 클라우드는 인증서 및 프로비져닝 설정이 젠킨스보다 더 간단하다는 장점이 있다고 안현석 디렉터는 설명했다. 엑스코드 버전을 선택하고, 인증서를 집어넣으면 바로 세팅이 완료되기 때문이다. 그리고 빌드 목록도 바로 나오는데, 이를 스타트 뉴 빌드 버튼을 클릭하면 바로 적용할 수 있으며, 빌드 로그 및 서머리가 확인 가능하다는 점에서 보다 간단하게 빌드를 할 수 있다는 이점도 있다.
이후에 기타 설정을 통해서 에셋 번들을 적용하거나, 유닛 테스트를 하는 등의 추가적인 작업도 가능하며, 이런 과정에 소요되는 시간이 획기적으로 짧다는 것도 유니티 클라우드만의 강점이다. 안현석 디렉터는 다만 유니티 클라우드는 앞서 말했듯, 젠킨스 같은 다양한 레퍼런스나 플러그인 등을 갖추지 않았다는 단점이 있다는 것도 다시 한 번 짚고 넘어갔다.
실제로 에이스 프로젝트에서는 맥에 젠킨스를 활용하는 방식으로 빌드 자동화를 하고 있다. 맥을 활용하는 이유는 iOS 빌드를 만들기 위해서이며, 완전 자동화를 위해서는 커스터마이징이 쉬운 젠킨스를 활용하는 것이다. 아울러 자동 빌드를 위해서는 SSD나 퓨전드라이브도 중요한 요소라고 강조했다. 빌드를 작성할 때 읽는 속도가 달라지기 때문이다. 프라이빗 저장소로 깃허브를 사용하고 있는데, 브랜치를 사용하기 쉽고 향후 코드 리뷰나 풀 리퀘스트 활용에도 편하기 때문이라고 언급했다.
또한 에이스 프로젝트에서는 잡 하나에 프로젝트를 다 묶어서 관리하지 않고, 플랫폼과 빌드 형태에 따라서 잡을 분리했다고 밝혔다. 왜냐하면 특정 플랫폼, 혹은 특정 종류의 빌드만 필요할 때가 있는데 이를 한 곳에 묶어놓는 것은 비효율적이기 때문이다. 따라서 빌드 형태 단위를 분리해두고, 필요한 단위를 따로따로 팀에게 전달하는 것이 더 효율적으로 업무를 할 수 있는 방법이라고 안현석 디렉터는 조언했다. 이 방식에 대해서 여러 잡을 한 번에 돌리기 어려울 것이라는 우려도 있다. 하지만 트리거를 활용해서 잡을 연계하면 한 번에 다수의 잡을 돌릴 수 있기 때문에 이런 점은 걱정하지 않아도 된다고 덧붙였다.
물론 프로젝트가 많아지면 빌드 서버를 분산해야 하고, 동시 다발적으로 빌드 작업을 해야 한다. 이때는 빌드 속도가 현저히 느려지는 만큼, 빌드 머신을 1대만으로 운용하기엔 힘들어진다. 그래서 에이스 프로젝트에서는 슬레이브 노드를 통한 분산 구성을 갖췄다. 젠킨스에서는 쉽게 빌드 머신을 분산하고 확장이 가능한데, 노드를 확장한 다음에 어느 잡에서 어느 노드를 활용할 수 있을지 세팅이 가능하기 때문에 분산하고 나서도 연계 작업이 쉽기 때문이다. 현재 에이스 프로젝트에서는 세 대의 빌드 머신과 여섯 개의 프로젝트, 48개의 잡으로 분산해서 작업을 하고 있다고 덧붙였다.
안현석 디렉터는 이 과정을 설계할 때 가장 명심해야 할 부분은, 모든 것이 자동화가 되어야 한다는 점이었다. 게임 개발 과정에서 빌드 외에도 해야 할 것들이 많으며, 빌드 과정에서도 사실 빌드 자체에 연관이 있는 작업 외에도 다른 작업들이 비중을 차지하기도 한다. 예를 들자면 빌드 배포 및 백업, 에셋 번들 배포, 다른 팀원들에게 빌드를 배포하는 과정 등은 빌드 작업이 끝난 다음에 일어나는 일이다. 이런 작업은 사실 굳이 수동으로 하지 않아도 되는 일이다. 이미 알림이나 배포 등은 자동으로 진행하고 있는 부분이고, 그 외에도 빌드 작업도 되도록이면 자동화를 통해서 사람의 손을 타지 않고 빠르게 진행할 수 있도록 하는 것이 중요하다. 시간을 단축해줄 뿐만 아니라, 실수를 최대한 줄일 수 있기 때문이다.
빌드 자동화를 위해서 자신과 에이스 프로젝트에서 기울인 노력에 대해 발표를 마친 안현석 디렉터는 자신이 빌드 자동화를 위해서 앞으로 시도해볼 수 있는 부분에 대해서 공유했다. 예를 들면 코드 분석 및 성능 테스트도 자동화가 가능한 부분이다. 정적 분석으로 코드 퀄리티 유지하는 것이 대표적인데, 코드의 상태를 보고 리포트를 내주거나 하는 오픈소스 플러그인이 이미 다양하게 인터넷상에 올라와있는 상태이기 때문이다. 빌드가 끝난 뒤에, 소스콘트롤하면서 코드를 합치는 작업에서 코드에 위험 요소나 버그를 미리 체크하면서 퀄리티 유지에 도움이 될 것이라고 안현석 디렉터는 전망했다.
그리고 빌드가 끝난 뒤에 테스트 과정을 자동화하는 것도 고려할 수 있다고 덧붙였다. 통상 빌드가 끝난 뒤에 QA 팀에서 테스트를 거치게 되는데, 보통 모바일 게임에서는 해당 빌드를 다운로드 받고 실행하는 과정을 거쳐야 한다. 이런 과정을 자동으로 하면 시간을 더 효과적으로 사용할 수 있다는 것이다. 이미 구글에서는 몽키러너라는 것을 개발해서, 자동화 테스트를 실행하고 있다. 파이선을 자바처럼 사용하는 스크립트 언어인 자이선 기반의 이 툴은, APK 설치 및 화면 캡쳐, 로그 트래킹, 화면 분석, 터치 이벤트 입력 등을 자동으로 실행하는 툴이다.
물론 자동화에도 맹점은 있다. 설정해두지 않은 범위에서 오류가 생겼을 때, 이를 체크하고 대처하기 어렵다는 단점이 있기 때문이다. 또한 이를 구축하기 위해서 처음에 다방면으로 고민을 해야 하고, 그 과정에서 많은 시간이 소요되기도 한다. 그렇다고 하더라도 안현석 디렉터는 자동화 과정을 계속 궁리할 가치가 있다고 강조했다. 일단 한 번 구축해두면, 작업에 드는 코스트가 획기적으로 줄 뿐만 아니라 돌이킬 수 없는 실수를 하는 경우도 최소화할 수 있기 때문이다. 또한 이런 고민을 계속 함으로써 발전해나갈 수 있다고 덧붙이면서 안현석 디렉터는 강연을 마쳤다.
Ruudi@inven.co.kr