확장성을 가진 DevOps 툴체인 설정에 관한 AAA 베테랑들의 조언

Monster Closet Games는 규모는 작지만 커다란 포부를 갖고 있으며, 그에 걸맞은 경험을 갖춘 스튜디오입니다. 대부분의 핵심 팀원들이 20년 이상 업계에 종사해 왔으며 어쌔신 크리드, 페르시아의 왕자, 파 크라이, 헤일로 등에 이르는 다양한 대형 게임 프랜차이즈를 개발한 경험을 보유하고 있습니다. 현재는 Project Shrine이라는 이름의 온라인 멀티플레이어 타이틀을 개발 중이며, PC와 현세대 콘솔로 출시할 계획입니다.

Monster Closet CEO 그레이엄 제닝스는 이렇게 말합니다. “간단히 말하자면 3인칭 협동 던전 레이드 게임이라 할 수 있습니다. 친구들과 모여서 캐릭터 간의 시너지 효과를 높이고 던전 레이드를 통해 보물을 획득합니다. 한 팀이 되어 힘을 합치는 것이 중요하죠.”

Monster Closet은 게임 개발에서 팀워크를 가장 중요시 여기며, 앞으로도 팀원 간의 긴밀하고 목적 지향적인 관계를 유지하려 합니다. 제닝스는 이렇게 말합니다. “협업을 즐길 수 있고, 스튜디오의 작업 방식을 좋아하고, 이를 통해 훌륭한 게임을 만드는 40~50명의 개발자로 구성된 팀을 선호합니다. 훌륭한 팀이 올바른 툴을 사용하면 훌륭한 게임을 만들 수 있다고 진심으로 믿고 있습니다.”

Monster Closet의 아티스트와 개발자는 독점 솔루션으로 구성된 강력한 기술 스택으로 작업하는 데 익숙해져 있습니다. 모든 작업을 처음부터 다시 시작할 수는 없었기에, 이들은 처음 몇 달 동안 원대한 계획에 맞춰 확장할 수 있는 툴체인을 신중하게 선별했습니다.

Monster Closet은 소스 관리용 Unity Version Control과 오류 트래킹용 Backtrace처럼 모든 엔진을 지원하는 Unity DevOps 솔루션과 자동화를 통해 Project Shrine의 제작 속도를 높이고 있습니다. 유니티는 Monster Closet의 리드 온라인 프로그래머 파트리스 보베와 CTO 토마스 펠릭스를 인터뷰하여 어떤 작업을 진행 중이고 어떻게 확장 가능한 기술 스택을 구축할 수 있었는지 알아보았습니다.

기술 스택을 구축하기 시작했을 때 주로 어떤 점을 고려하셨나요?

토마스 펠릭스: 저희 팀원 중 일부는 라이브 게임과 관련해 서로 다른 경험을 보유하고 있었기 때문에, 그런 저희를 장기적으로 지원할 수 있는 탄탄한 DevOps 기반을 갖추고 싶었습니다. 저희 게임의 핵심이 GaaS(Games-as-a-Service)라 할 수는 없지만 빠른 릴리스와 반복 작업을 지원하는 강력한 기술 스택을 갖추고 싶었죠.

모든 팀원이 Perforce를 사용해 본 적이 있지만 그다지 선호하는 툴은 아니었습니다. 충분한 기능을 제공하긴 해도 저희가 하던 작업이 실질적으로 Perforce와 맞지 않았기 때문이죠. Git도 솔루션의 일환으로 검토하다가 Unity Version Control을 발견하게 되었습니다.

처음 봤을 때 Unity Version Control은 Git과 같은 뛰어난 접근 방식과 Perforce와 같은 훨씬 강력한 데이터 관리 기능을 모두 갖추고 있었죠. Unity Version Control의 작업 브랜치 워크플로가 무척 마음에 들어서 약 6개월의 평가 기간을 거쳐 사용을 결정했습니다. 당시 저희는 약 6~7명 정도의 소규모 팀이었습니다. 점진적인 성장을 거쳤기 때문에 팀이 순조롭게 커질 수 있었다고 봅니다. 지금은 약 43명의 팀원이 함께하고 있고 여전히 모든 것이 순조롭습니다.

어떤 과정을 통해 버전 관리 시스템을 테스트했나요?

파트리스 보베: 프로젝트 절반을 Git에서 관리하고 나머지 절반은 Perforce에서 관리하는 것은 기술적인 이유로 바람직하지 않은 상황이었어요. 저희는 두 개의 서로 다른 소스 코드 관리 툴을 사용하고 유지 관리하는 작업이 얼마나 부담스러운지 알고 있어요. 온라인 시스템과 게임 데이터가 완전히 통합되지 않은 라이브 서비스 게임에서 흔히 발생하는 상황이죠.

Monster Closet 규모의 팀에서는 이러한 방식을 지원하기 어렵죠. Unity Version Control이 두 가지 워크플로를 모두 지원할 수 있다는 점이 도움이 되었나요?

파트리스 보베: 물론이죠.

이전에 두 개의 서로 다른 버전 관리 시스템을 사용하면서 어떤 문제가 있었나요?

토마스 펠릭스: 게임을 개발하는 과정에서는 아무리 좋은 툴이더라도 항상 커스터마이즈해서 사용해야 해요. Unity Version Control이 좋은 예시입니다. 기본적으로도 잘 작동했지만 저희 워크플로에 맞게 조정할 수 있는 방법을 발견했죠. 두 개의 소스 관리 시스템을 지원하려면 작업량이 두 배로 늘어나므로 항상 어려움이 따르기 마련입니다. 누구는 Git에 익숙하지만 Perforce엔 익숙지 않을 수 있고, 그 반대일 수도 있습니다. 직원 교육에 시간이 두 배로 소요되죠.

파트리스 보베: 개인적으로 두 개의 서로 다른 버전 관리 시스템의 데이터를 통합하는 작업이 가장 어려웠어요. Perforce를 사용하고 있지만 데이터 라이브러리가 Git에 저장되어 있다면 해당 데이터를 다시 Perforce로 옮겨야 하므로 둘을 연동할 방법도 필요합니다. 관련 솔루션이 많이 있지만 이런 종류의 상호 작용은 처음부터 의도된 것이 아니기 때문에 종종 프로젝트 이력을 잃어 버리기도 하죠. 더 큰 규모의 팀이라면 어떻게든 할 수 있겠지만, 저는 Git에서 Perforce로 데이터를 마이그레이션하는 솔루션을 구축하느라 6개월을 낭비하고 싶지 않아요.

팀에서 수년 동안 다양한 버전 관리 시스템을 사용하신 것 같네요. 지금까지 사용해 본 솔루션의 장점과 단점은 무엇인가요?

토마스 펠릭스: Perforce부터 이야기하자면 매우 탄력적이고 데이터 관리 기능이 뛰어나며 기술직이 아닌 팀원도 그리 복잡하지 않게 사용할 수 있습니다. Unity Version Control을 제외하면 이런 기능을 갖춘 솔루션은 찾아보기 어려워요. 반면 Perforce의 대규모 모노리포(monorepo)는 빠른 통합, 다중 브랜치 등의 측면에서 게임 개발에는 적합하지 않습니다. Perforce로도 관리가 가능하겠지만 권장하지 않으며, 특히 견고한 CI/CD 파이프라인을 구축하려 한다면 더욱 그렇죠.

파트리스 보베: Git의 UI는 프로그래머에겐 적합해도 아티스트에겐 그다지 적합하지 않아요. 대용량 파일과 데이터를 관리하는 데 적합하지 않고, 아직 제대로 된 잠금 기능을 기본적으로 지원하지 않습니다.

토마스 펠릭스: Unity Version Control은 여러 측면에서 더 나은 솔루션입니다. UI가 콘텐츠 크리에이터에게 적합하도록 구현되어 사용성이 뛰어나거든요. Unity Version Control은 Git과 Perforce의 완벽한 결합이라고 생각합니다.

프로그래머는 보통 Git을 사용하고 싶어 하는데 Unity Version Control에서도 거의 동일한 워크플로를 사용할 수 있어요. 기술 역량이 없는 콘텐츠 크리에이터도 데이터를 쉽게 제출할 수 있으므로 팀이 소스 관리 측면에서 마주하는 가장 큰 문제를 해결할 수 있죠.

저희에게 있어 최악의 상황은 데이터 손실입니다. 코드는 어떤 소스 관리 솔루션에서도 쉽게 처리할 수 있지만 데이터는 항상 까다로워요. 작업물을 잃어서는 안 되고, 데이터와 관련된 실수는 나중에 수천 배의 비용으로 돌아오기 마련이거든요. 그래서 최대한 조심스럽게 데이터를 다룹니다. Unity Version Control을 사용하면 프로그래머와 콘텐츠 크리에이터 모두 이점을 얻을 수 있습니다.

빌드의 무결성을 유지하기 위해 추천할 만한 베스트 프랙티스가 있을까요?

토마스 펠릭스: 저희처럼 새로 시작하는 작은 스튜디오에서는 잘못된 데이터나 코드를 메인 브랜치에 제출해서 빌드가 손상되는 일이 발생하면 안 됩니다.

Unity Version Control을 사용하면 메인 브랜치에서 작업할 일이 없죠. 메인 브랜치를 항상 안정적으로 제어할 수 있으며 실질적으로 Mergebot이 대부분의 작업을 대신 수행합니다. Unity Version Control을 테스트할 때 이러한 기능이 매우 마음에 들었고, 메인 빌드에서 작업하는 팀원이 5명뿐이었을 때도 우선적으로 도입한 기능 중 하나입니다. 정말 유용한 기능이에요. 거의 2년이 지났음에도 메인 브랜치가 다운된 적이 거의 없거든요.

대용량 파일에서 작업하거나 브랜치와 워크스페이스를 오갈 때 Unity Version Control의 처리 속도는 어떤가요?

토마스 펠릭스: 작업 브랜치와 워크스페이스 전환도 매우 원활하죠. 이 워크플로에 익숙해지는 데 어느 정도 시간이 걸릴 수는 있어요. 작업 브랜치는 많은 사람에게 생소한 개념이고, 아티스트는 프로그래머와 달리 곧바로 익숙하게 사용하기 어려울 수 있으니까요.

그리고 매일까진 아니어도 매주 Mergebot과 CI/CD 프로세스에서 작은 문제가 발견되긴 하지만, 메인 브랜치로 문제가 전이되거나 빌드가 손상되는 일은 없습니다. 익숙해지려면 다소 시간이 걸리지만, 당연히 한 브랜치에서 작업하는 것이 두 브랜치에서 작업하는 것보다 더 빠르죠. 큰 차이는 아니더라도 파이프라인을 전체적으로 살펴보면 훨씬 더 나은 작업 방식이라는 사실을 알 수 있습니다. 적어도 저희와 같은 중소 규모의 기업에는 완벽한 솔루션이에요.

지속적인 배포로 전환하려면 팀 문화와 학습 과정에 변화를 주어야 하지만, 많은 버그나 기타 잠재적인 문제가 메인 브랜치에 적용되기 전에 수정할 수 있었다는 이야기로군요.

토마스 펠릭스: 맞습니다. 다시는 단일 브랜치 개발 환경으로 돌아가지 않을 거예요. 저희 같은 팀은 메인 브랜치에 발생한 문제를 디버깅하거나 수정하느라 며칠을 소비할 여유가 없거든요. 

Apocalypse Studios와 인터뷰했을 때 작업 브랜치 워크플로에 필요할 수 있는 ‘문화 변화’에 대해 이야기를 나눴습니다. Apocalypse Studios는 Unity Version Control 전에 Perforce를 사용했고 브랜치와 스트림을 비교하며 많은 이야기를 했는데요. 이에 대해 어떻게 생각하시나요?

토마스 펠릭스: 브랜치와 스트림은 완전히 다르다고 생각합니다. Unity Version Control이 없었다면 스트림을 중심으로 게임을 빌드하고 비슷한 작업을 시도했을 수 있었겠지만 그 과정이 복잡하고 오류에 취약했을 거예요. Unity Version Control은 브랜치를 기본 기능으로 제공하므로 훨씬 쉽고 안전하게 작업할 수 있습니다.

Perforce에서 스트림은 작업과 동등하다고 볼 수 있어요. 전문적인 기술을 지닌 사람이라면 할 수 있지만 아티스트에겐 어려운 일이죠. 현재 저희는 Unity Version Control에서 1,000개가 넘는 브랜치를 사용하고 있고, 대부분 보관되어 있지만 10~15개의 브랜치가 항상 열려 있습니다. Perforce에서 1,000개의 프로젝트 브랜치를 만들고 싶지는 않을 것 같네요.

개발을 계속 진행하면서 어떤 어려움이 있을 것으로 예상하시나요? 지금까지 마주한 어려움에는 어떤 것이 있나요?

파트리스 보베: 앞서 말씀드렸지만 작업 브랜치 방식에 곧바로 익숙해지기는 어려워요. 아티스트에게는 매우 생소한 기능이므로 작동 방식과 사용 이유에 대해 매우 세심하게 설명하고 있습니다.

토마스 펠릭스: 그렇습니다. 거부감을 느끼는 사람은 없지만 확실히 문화적 전환이 필요한 일이죠. 저희 팀처럼 Unity Version Control로 전환하려는 경우 이러한 점을 고려해야 해요. 더 나은 작업 방식이라 해도 기꺼이 틀에서 벗어나 사고할 준비가 되어 있어야 합니다. 저희는 사무실도 없고 인프라도 없이 거의 아무것도 없는 상태에서 매우 작은 팀으로 새롭게 시작했기 때문에 다른 스튜디오에 비하면 약간 수월한 편이었죠. 클라우드에 인프라를 구축하는 편이 더 좋아 보이기는 해도 반복 작업 시간, 비용, 설정, 보안 등의 측면에서는 어려움이 따릅니다. 결국 성공하긴 했으나 저희도 안정적인 워크플로를 구축하고 실행하는 데 어느 정도 시간이 걸렸어요.

현재 모든 엔진을 지원하는 유니티의 또 다른 솔루션이자 검증된 솔루션 파트너인 Backtrace도 사용 중이신데, 어떤 오류 트래킹 파이프라인을 사용하고 있는지 설명해 주세요.

토마스 펠릭스: Backtrace를 사용해 대부분의 애플리케이션에서 모든 버그를 트래킹하고 있습니다. 물론 게임과 에디터에 우선적으로 사용하고 있죠. 앞서 Unity Version Control을 중심으로 몇 가지 툴을 구축했다고 말씀드렸는데, 여기에 Backtrace도 통합되어 있습니다.

설정에 오랜 시간을 소모하지 않고도 최고 수준의 툴, 대시보드, 워크플로를 사용할 수 있었어요. 이전 회사에서 사용하던 많은 기능을 매우 쉽게 설정하고 실행할 수 있었죠. 약 6개월 동안 사용해 보니 게임, 에디터, 툴의 모든 크래시에 대한 가시성을 확보할 수 있었습니다. 솔직히 새 스튜디오를 시작할 때 이렇게 일찍 가시성을 확보할 것이라고는 예상하지 못했어요.

파트리스 보베: 정말 좋은 툴입니다. Ubisoft에 있을 때 Backtrace와 비슷한 독점 솔루션을 2~3년 동안 개발한 적이 있는데요. Backtrace는 상당히 뛰어난 기능을 갖추고 있어요. 제가 개발하던 솔루션보다 훨씬 빠르고 구현하기도 쉽습니다. 다시 말하지만 저희는 커스텀 데이터를 위한 자체 커스터마이징을 추가했고 Linux에 있는 서버와 통합하는 작업을 진행했습니다.

토마스 펠릭스: Backtrace를 상당히 빨리 설정할 수 있어서 정말 놀랐어요. 2~3일 만에 이미 크래시 기록을 받아볼 수 있었기 때문에 완전히 Backtrace로 전환하기로 했죠.

Unity Version Control 구현 프로세스를 원활하게 진행하기 위해 어떤 노력을 하셨나요?

많은 대형 게임을 출시한 경험을 바탕으로 새로운 상황에 이 프로세스를 어떻게 적용할지 고민했습니다. 그 결과 Unity Version Control과 Backtrace를 사용하게 되었죠. 없는 문제를 만들어 내지 않는 것이 가장 까다로운 부분이에요. 더 이상 1,000명이 넘는 규모의 스튜디오가 아니니까요.

대형 스튜디오에서 배운 경험을 활용하면서도, 더 이상 차세대 대형 AAA 게임을 제작하는 대형 스튜디오가 아니라는 점을 잊지 않고 그 사이에서 균형을 찾기 위해 노력하고 있습니다. 하지만 여전히 멋진 게임을 만들고 싶고 그러기 위해선 최고의 워크플로가 필요해요. 이 목표를 위한 완벽한 솔루션이 바로 Unity Version Control입니다.

어떤 과정을 통해 버전 관리 시스템을 테스트했나요?

토마스 펠릭스: 가장 까다로운 문제는 UX와 데이터 무결성 측면에서 아티스트도 사용할 수 있도록 하는 것이었어요. 여러 아티스트 팀원들과 함께 작업하며 사용 방법에 대해 교육했죠. 프로젝트에서 데이터 관리를 확실하게 하는 것이 정말 중요했습니다. 팀에 더 많은 사람들이 합류하며 더 좋은 피드백을 받았어요. 사람들은 만족스러워했고 프로젝트가 제대로 진행된다는 것을 느낄 수 있었습니다.

Unity Version Control의 아티스트용 Gluon 워크플로는 어떤 식으로 사용하시나요?

토마스 펠릭스: Gluon도 사용하지만 엔진에 연결되지 않은 데이터인 원시 데이터에 사용하고 있어요. 예를 들어 아티스트로서 메시를 모델링한다고 가정하면 Blender와 같은 프로그램에서 원시 데이터, 즉 소스 파일을 사용할 것입니다. 이 소스 파일은 엔진에 연결할 필요가 없고 여기에서 익스포트한 데이터만 엔진에 연결합니다. 이 데이터는 작업 브랜치에서 관리하지만 소스 파일은 Gluon에서 관리하죠.

소스 파일은 매우 무거워질 수 있습니다. Zbrush 같은 툴을 사용하는 캐릭터 아티스트라면 에셋당 2~4GB에 이르는 파일을 생성하게 되니까요. 프로그래머가 1TB에 달하는 원본 캐릭터 메시를 동기화할 수는 없기 때문에 부분 워크스페이스를 사용하여 Gluon에서 이를 관리합니다. 캐릭터 아티스트는 캐릭터 파일만 동기화하고, 모델러는 모델 파일만 동기화하고, 오디오와 텍스처 등도 마찬가지예요. 모두 작업 브랜치 워크플로와는 동떨어진 별도의 저장소에 저장됩니다.

요약하면 대용량 파일로 작업하는 경우 Gluon을 사용하면 전체 저장소를 다운로드할 필요 없이 일부 워크스페이스만 사용할 수 있다는 말씀이시죠?

토마스 펠릭스: 맞습니다. 원본 데이터가 보관된 버전이므로 작업 브랜치를 사용하지 않아요. 크리에이터가 가끔 최신 작업물을 제출하기만 한다면 해당 머티리얼을 위한 작업 브랜치가 필요하지 않죠.

지금 여러분처럼 규모를 확장하고 원대한 프로젝트에 도전하려는 소규모 스튜디오에 어떤 조언을 하고 싶으신가요?

토마스 펠릭스: 좋은 질문입니다. 1일차부터 방향을 확실하게 설정해야 해요. 저희는 소규모 팀으로 시작했고 성장에 대한 목표가 있기는 했지만 1,000명 규모의 회사가 되고 싶지는 않았습니다. 사실 200명도 많다고 여겼죠. 지금까지 매우 만족스러운 결정을 다수 내릴 수 있었지만, 다른 방향을 지향했다면 그런 결정을 내리지 못했을 거예요.

클라우드에 인프라를 구축하면 쉽게 확장할 수 있겠으나 비용이 많이 들 수 있기 때문에 주의해야 합니다. 항상 워크플로를 제어할 수 있도록 노력해야 하고, 무언가 제대로 되지 않는다면 그 이유를 파악해야 합니다. 기본적으로 기초가 탄탄해야 하죠.

게임 개발 파이프라인을 최적화하고 싶으신가요? 어느 엔진에서나 사용할 수 있도록 설계된 Unity DevOps를 시작하세요.