DevOps를 통한 멀티플랫폼 확장

멀티플랫폼 출시를 성공적으로 실행하기란 쉽지 않은 일이며 제작 비효율성으로 인한 병목 현상이 흔히 발생하곤 합니다. Cygnus Entertainment의 리드 아티스트 앰버 존슨과 리드 엔지니어 존 웨스트, 그리고 유니티의 테크니컬 프로덕트 매니지먼트 리드 마리-크리스틴 바빈, 테크니컬 프로덕트 매니지먼트 매니저 마크 넬슨을 한 자리에 모시고 이 주제에 관한 대화를 나누어 봤습니다. 각 분야의 전문가들이 멀티플랫폼 출시에 영향을 미칠 수 있는 일반적인 장애 요인에 대해 이야기를 나누고 성공적인 출시를 위한 DevOps 베스트 프랙티스 관련 팁을 공유했습니다.

그럼 기본적인 사항부터 살펴보겠습니다. Unity DevOps를 사용하려면 일반적인 DevOps 또는 CI/CD에 대한 사전 지식이 있어야 하나요?

존 웨스트: 저희가 Unity DevOps와 Unity Version Control을 채택한 이유는 인력 규모가 대략 30명에 이르기까지 빠르게 성장했기 때문입니다. 그런 상황에서 개발자 온보딩을 빠르고 쉽게 진행할 수 있으며 확장에 대한 안정성도 보장되는 솔루션이 필요했죠. 버전 관리와 DevOps의 일반적인 개념에 익숙하다면 당연히 좋겠지만, 그렇지 않다고 해서 아예 사용하지 못할 정도는 전혀 아닙니다. 한때는 저희 QA 담당 부서에서 자체적인 브랜치를 운영하기도 했습니다.

앰버 존슨: 아티스트의 관점에서 말씀드리자면 다른 버전 관리 도구에 비해 훨씬 직관적으로 작업할 수 있다는 이점이 있습니다. 변경 사항의 전체적인 ‘흐름’을 시각적으로 쉽게 확인할 수 있고 다른 작업자들의 작업 현황도 볼 수 있죠. 저희 아트 팀의 대부분은 버전 관리 도구를 사용해 본 적이 없고 다른 시스템에 대한 경험도 거의 없다시피 했는데, 제가 몇 번의 데모를 거쳐 모두 온보딩시킬 수 있었습니다.

마리-크리스틴 바빈: 유니티에서는 Unity Learn 튜토리얼을 제공하여 사전 경험이 없더라도 Unity DevOps를 시작할 수 있도록 지원합니다.

Unity Version Control은 다른 DevOps 툴과 어떤 차별점이 있나요?

존: LFS(대용량 파일)나 배시 터미널로 골머리를 썩힐 필요가 없다는 점에서 꽤나 간편하다고 할 수 있습니다. 프로젝트 규모에 맞춰 작업할 수도 있고, Unity에 곧바로 통합되는 덕분에 에디터 내에서 파일을 잠금 처리하여 병합 충돌을 방지할 수 있습니다.

앰버: 병합이 잘못돼서 파일이 손실된 경우에 문제를 해결하기가 더 쉬워졌어요. 프로젝트를 이전 버전으로 되돌리고, 필요한 파일이 포함된 Unity 패키지를 생성한 다음 최신 버전으로 돌아가는 과정이 무척 간단합니다. 테스트를 위해 다른 브랜치에서 작업할 수 있다는 점과 에셋 패키지 임포트 같은 ‘번거로운’ 작업이 가능하다는 점도 도움이 되었어요. 의도한 대로 진행되지 않을 때는 브랜치를 폐기하면 그만입니다.

저는 교수로도 일하고 있는데 아티스트들에게 Unity에서 코딩하는 법을 가르친 적이 있습니다. 아티스트도 곧잘 배울 수 있을 정도로 쉬웠죠. 그리고 중요한 정보를 참고할 수 있는 내부 위키 페이지를 활용했습니다.

소규모 팀에서 더욱 빠르게 게임을 만들기 위해서는 프로젝트를 어떤 식으로 관리해야 하나요?

마크 넬슨: 게임을 빠르게 만드는 방법은 형태와 규모에 따라 다양합니다. 제가 권장하는 바는 유니티의 클라우드 전환 서비스 Unity Build Automation으로 빌드 작업을 신속히 진행하여 최종 제품을 테스트하고 전 세계 사용자에게 빠르게 배포하는 것입니다.

마리-크리스틴: 1인 프로젝트를 진행하는 경우에도 버전 관리와 관련된 베스트 프랙티스를 적용하면 체계를 확립하고 시간을 절약하는 데 도움이 됩니다. 올해 진행된 한 GDC 강연에서는 프로젝트 구성과 버전 관리를 집중 조명했으며, 작업 효율을 높이기 위해 프로젝트에 적용할 수 있는 몇 가지 베스트 프랙티스를 소개했습니다. 이 주제를 더 깊게 다루는 전자책도 참고하실 수 있습니다.

현재 사용 중인 프로세스를 도입하는 데 어떤 부분이 가장 어려웠나요?

존: 도입 과정은 매우 원활하게 진행됐습니다. 해결해야 하는 문제는 대부분 프로젝트 초기 단계부터 명확했습니다. 저희는 버전 관리의 표준 절차를 따랐고 아트, 핵심 개발, 모든 주요 플랫폼 브랜치를 아우르는 지휘 체계를 수립했습니다. 권한이 있는 인원만 푸시할 수 있었습니다. 그 덕분에 버전 관리 시스템을 깔끔하게 유지할 수 있었고, 프로젝트에 참여하는 개발자끼리 질서가 뒤엉키는 것을 방지하는 특정한 방식을 도입했습니다.

예를 들어 프로그래머가 기본 씬에서 작업하는 동안 별개의 씬에 포함된 아트를 비동기적으로 로드할 수 있습니다. 씬을 직접 편집하는 대신 프리팹을 활용한 덕분에 대응하기 힘든 병합 충돌을 방지하는 데 큰 도움이 되기도 했습니다. 새로운 장애물을 발견하면 모두가 빠르게 적응하고 방향을 틀 수 있었죠. 당시 Unity DevOps의 완성도가 이미 상당했기 때문에 큰 문제를 방지하는 데 필요한 모든 툴을 활용할 수 있었던 것은 저희가 운이 좋았다고 할 수 있겠습니다.

앰버: 저희에겐 지휘 체계가 제일 중요했습니다. 지휘 체계를 수립하고 나니 파일 처리와 관련된 거의 모든 문제가 해결되었습니다. 프로세스에 약간의 병목 현상이 발생했지만 지속적으로 빌드하려던 마지막 과정에 생긴 문제였을 뿐입니다.

새로운 인원을 온보딩할 때 DevOps 사용을 숙달하는 과정에서 흔히 발생하는 어려움은 어떤 것이 있었나요?

존: 저희 팀의 구조와 푸시 담당 및 시기를 정한 지휘 체계 덕분에 이러한 상황에서 발생할 수 있는 어려움을 방지할 수 있었습니다. Unity Version Control은 저장소에 액세스할 수 있는 두 가지 방법을 제공합니다. 첫 번째는 온라인 저장소에서 푸시하고 풀할 수 있는 로컬 버전입니다. 두 번째는 체크인할 때마다 온라인 저장소로 곧바로 이동하는 클라우드 버전입니다. 이 방식 덕분에 언제든 동기화되지 않을 수 있는 로컬 버전 저장소를 관리하기가 한층 더 간단해집니다.

테스트를 자동화했는지 아니면 대부분의 테스트를 수동으로 진행했는지 궁금합니다.

존: 사내 QA 부서가 있어서 주기적으로 테스트용 빌드를 만들어 해당 부서에 제공했습니다. 소량의 테스트를 외부에서 진행한 적이 있지만 대부분은 내부에서 수동으로 진행했습니다.

플랫폼별 편차가 큰 UI 프리팹 및 컴포넌트의 구조화는 어떤 방식으로 접근하는 것이 좋을까요?

존: 프리팹 수준에서는 주요 요소마다 하나의 프리팹을 두고, 기본적으로 비활성화된 각 플랫폼을 자식으로 배치합니다. 스크립트 수준에서는 커스텀 지시문을 포함한 프리 프로세서 지시문을 사용하여 자식 오브젝트를 활성화하거나 비활성화합니다(예: #if UNITY_ANDROID, #if UNITY_PS5). 대부분의 UI 요소는 모든 플랫폼에 공유되었습니다.

‘시프트 레프트로 오류 줄이기(Shift left to reduce failure)’라는 DevOps 개념에 대해 설명해 주시겠어요?

존: 알려지지 않은 요인을 최대한 많이 파악하는 것은 게임을 성공적으로 출시하는 데 핵심적인 부분입니다. DevOps를 활용하면 신속하게 프로토타입을 만들고 여러 플랫폼을 위한 빌드를 병렬화하여 플레이어에게 게임을 빠르게 제공하고 가설을 검증할 수 있습니다. 제작 측면과 인게임 프로세스를 각 단계별로 진행할 수 있으면 추후에 크고 복잡해질 문제를 발견하지 못하는 사태를 방지할 수 있습니다.

앰버: 아트 파이프라인에도 이러한 부분이 활용되어 왔기에 아티스트의 관점에서도 흥미로운 아이디어입니다. 저희는 레벨을 블로킹하여 테스트하고, 기초 아트를 배치하여 테스트하고, 기본 조명을 배치하여 테스트하고, 캐릭터를 배치하여 테스트하죠. 프로세스가 어떻게 진행될지 테스트하기도 전에 아트 관련 요소를 프로젝트에 죄다 집어넣는 것은 상상할 수 없는 일입니다. 먼저 스케치를 블로킹한 다음에 문제를 수정하고 조금씩 조정해 나가야 하죠.

마크: 시프트 레프트의 목적은 문제를 식별하고 해결하는 데 걸리는 시간을 단축하는 것입니다. 개발 주기의 초기 단계에서 테스트, 품질 관리, 성능 평가를 같이 진행해야 한다는 의미죠.

‘제대로 하기 위해 멈추기(stop to do it right)’라는 DevOps 시나리오에 관해 조언해 주신다면요?

존: 프로세스의 방향을 전환할 수 있다는 것은 매우 중요합니다. 워크플로의 기반 프로세스를 근본적으로 변경할 수 없는 경우에는 엔트로피와 기술 부채를 감당하기 위해 DevOps의 일부 측면을 통합할 수 있습니다. 예를 들어 클라우드 빌드를 사용하면 장비와 개발 시간 측면에서 여유가 생깁니다. 그리고 본인의 업무에 베스트 프랙티스를 개별적으로 활용할 수 있으면 프로젝트에 안정성을 더하고, 규모를 확장하여 다른 사람들과 협업하는 데 마찰을 줄일 수 있습니다. 버전 관리는 어떤 형태로든 반드시 이루어져야 하며, 버전 관리 및 엔진과 관련된 작업 운영 방식은 언제나 최적화할 수 있습니다. 변경할 사람이 본인뿐인 경우에도 말이죠.

DevOps 숙련도에 상관없이 프로젝트를 성공시키기 위해서는 필요에 따라 작업 방식과 툴을 맞춰 나가는 것이 핵심입니다. DevOps는 계속 진화하고 있으므로 변화와 새로운 프로세스 및 툴에 유동적으로 대처하여 게임 개발 프로세스를 최적화하는 것이 중요합니다.

더 자세히 알고 싶으신가요? 버전 관리의 베스트 프랙티스에 관해 유니티가 발행한 전자책과 2023 유니티 게임 업계 보고서를 읽어 보세요. 또한 Made with Unity 포럼에서 자신만의 성공 팁을 공유해 주세요.