주제: PUBG가 심쉽(PC, Console)으로 개발하는 방법
강연자 : 김상기 - 크래프톤 펍지 / KRAFTON PUBG
발표 분야 : 프로덕션&운영
권장 대상 : 콘솔 개발 및 프로덕션 운영 관심있는 모든 분들
난이도 : 기본적인 사전지식 필요
[강연 주제] 멀티 플랫폼 글로벌 라이브 서비스를 하기 위해서는 어떤 것을 신경 써야 하는지 알아보자.
과거에는 PC면 PC만, 콘솔이면 콘솔만 서비스하는 경우가 대부분이었다. 특히, 온라인 게임이 강세였던 국내의 경우엔 대부분의 게임이 PC를 기준으로 출시됐다.
하지만, 최근에는 하나의 플랫폼만을 고집하기보단 멀티 플랫폼을 고려해 서비스를 제공하는 게임들이 점차 늘어나는 추세다. 펍지에서 서비스 중인 '플레이어언노운스 배틀그라운드(이하 배그)'가 대표적인 예다.
현재 배그는 스팀과 카카오게임즈, Xbox, PS4, Stadia 등 다양한 플랫폼에서 서비스를 제공할 만큼 멀티 플랫폼 서비스에 강세를 보인다. 다양한 플랫폼에서 균일한 게임 서비스를 제공하기 위해 펍지는 어떤 노력을 했고 또 어떻게 작업했을까? 펍지의 김상기 엔지니어&프로젝트 매니저의 강연을 통해 세부적인 작업 비결에 대해 들어볼 수 있었다.
■ PART #1 멀티 플랫폼(코솔) 런칭의 현실
콘솔 확장은 굉장히 멋지고 훌륭한 일이지만, 사실 그 안에 엄청 힘든 런칭 과정이 숨어져 있다. 보통 라이브 중인 게임 프로젝트에서 새로운 플래폼으로 확장 런칭을 시작하면 엔지니어(엔진, 그래픽, 시스템)와 PM으로 구성된 콘솔 포팅 TFT가 결성된다.
이후 런칭 시점에서 플랫폼마다 서비스를 분리할 것인지와 특정 시점을 기준으로 빌드 프리징을 진행할 것인지를 결정하게 된다. 서비스 분리의 경우, 프로젝트 특성에 따라 결정이 달라질 수 있는데 플랫폼마다 유저 타겟과 타겟 지역이 다른데다 컨트롤러 차이로 인한 게임의 밸런스 이슈가 있기 때문이다. 배그는 밸런스가 중요하기에 서비스를 분리하는 방향으로 진행됐다.
서비스 방향이 결정된 뒤에는 특정 시점을 기준으로 빌드 프리징을 진행하는데 엔진과 미들웨어 등의 버전을 픽스하여 포팅하게 되고 콘텐츠 포팅 또한 진행하게 된다. 이후 플랫폼 정책과 최적화 과정을 거치고 나면 라이브 서비스 단계로 돌입하면서 TFT팀은 기존 개발팀으로 합류되거나 또 다른 콘솔 팀이 신설되기도 한다.
여기까지가 일반적으로 알고 있는 멀티 플랫폼 확장 런칭의 일면이고 콘솔 포팅 직후 세부적으로 살펴보면 현실적으로 부딪히는 다양한 일이 존재한다.
간단한 예시로 PC 1월을 기준으로 2월에 Xbox를 런칭한다고 가정해보자. 런칭을 해도 끝이 아닌 이유는 서비스가 라이브로 진행된다는 점에 있다. 펍지는 한달 단위로 패치를 진행하며, 콘솔 런칭이 준비 중인 기간에도 PC는 지속적인 패치가 이뤄졌을 것이다.
따라서 런칭 이후에 곧바로 3월 패치를 준비해야 한다. 이때의 기간은 한달이지만 QA과정이 있으니 실제 작업 기간은 2주 정도로 보면 된다. 이 과정이 매달 반복되며, 업데이트가 많은 달에는 헬파티가 열릴 수밖에 없다고 설명했다.
개발자 입장에서는 어쩔 수 없는 선택이다. PC와 콘솔의 안정적인 런칭을 위해 한달 늦은 버전을 바탕으로 런칭을 진행한 것인데, 콘솔 유저 입장에서는 항상 PC 유저보다 한달 뒤에 콘텐츠를 즐겨야 한다는 점이 불만으로 다가온다.
또한, 이 과정이 계속 반복되면 개발팀에서도 유지보수에 큰 문제가 발생하게 된다. 개발 과정에서 콘솔을 미리 고려하지 못하니 끊임없이 기술 부채가 발생하며, 업데이트 과정에서 문제가 발생할 경우 메인 담당 개발자의 대응이 쉽지 않다는 점, 불필요한 추가 개발 리소스 발생과 플랫폼 간 개발 경험 공유 오류, 마지막으로 PC에서 이미 공개된 콘텐츠가 콘솔로 나오다보니 마케팅 효과도 크지 않았다.
따라서 펍지는 라이브 유지보수가 점점 늘어나는 것을 방지하기 위한 작업을 시작했다.
■ PART #2 심쉽의 시작 : 콘솔 서비스 통합
Xbox 런칭 이후 PS4까지 플랫폼 확장을 진행하려니 유지 보수의 압박이 커짐을 느꼈고 이를 해결하고자 콘솔 서비스의 통합에 대한 고민이 시작됐다.
앞서 언급했듯 PC와 콘솔은 많은 부분에서 차이가 있지만, 반대로 콘솔과 콘솔 간에는 그리 큰 차이가 없다. 똑같이 제한적인 성능과 컨트롤러를 사용하기 때문이다.
펍지는 콘솔 서비스를 통합하기 위해 첫번째로 아웃 게임에서 콘솔끼리 인프라는 나누는 것이 아니라 하나의 인프라에 접속하는 형태로 변경했다. 또한, 인게임 데디케이티드 서버도 모든 플랫폼에서 접근할 수 있도록 구성했다.
두번째로 콘솔 개발 가이드라인을 만들었다. 하나의 콘솔 플랫폼이 아닌 여러 콘솔 플랫폼에 서비스되기 때문에 동일한 기준을 만드는 것이 중요했다. 따라서 플랫폼마다 어떤 식으로 밸런스를 잡고 업데이트를 진행할 것인지를 정하고 이후 업데이트 방향에 적용하는 방식을 사용했다.
세번째로 콘솔 플랫폼 서비스를 위한 운영 방침을 정했다. 콘솔 플랫폼마다 라이브 서비스 과정에서 문제가 발생할 수 있으며, 펍지의 경우 하나의 플랫폼에서 문제가 발생해 점검을 연장할 경우 모든 플랫폼에서 서비스 연장을 진행한다. 이런 일이 자주 발생하진 않지만, 멀티 플랫폼을 운영함에 있어서 반드시 필요하다고 생각해 이런 결정을 내리게 됐다.
콘솔 인프라를 합치고나니 플랫폼끼리 함께 플레이를 할 수 있었고 내부적으로 생각보다 이점이 많은 것 같은데 실제로 이렇게 서비스를 할 수 없을까라는 생각이 들게 된다. 그래서 나온 것이 펍지 콘솔 크로스 플레이다.
콘솔 크로스 플레이를 진행하면서 가장 기대한 것은 매치 메이킹이었다. 콘솔 서비스가 확장되면 플랫폼마다 즐기는 유저 수에 차이가 발생하는데 배그처럼 멀티 플레이가 중요한 게임의 경우, 즐기는 플레이어 수에 큰 영향을 받게 된다. 따라 장기적인 라이브서비스 헬스를 위해 크로스 플레이를 적용해보기로 결정한다.
콘솔 크로스 플레이를 적용하기 위해선 먼저 콘솔 유저 데이터를 모두 통합 관리할 필요가 있다. 또한, 각 플랫폼마다 정책이 다르기 때문에 라이브 사양과 플랫폼별 정책의 교집합을 모두 정리해야 한다. 이외에도 콘솔 매칭 플로우 및 UX, 리더보드 개편 등 다양한 작업을 진행해야 한다.
콘솔 크로스 플레이 적용 이후 결과적으로 기대했던 것 이상의 성과를 달성할 수 있었다. 하지만, 이 부분은 콘솔 확장 과정을 개선한 것일뿐 PC와 콘솔 간 업데이트 일정에서 한달 정도의 차이가 발생하는 문제는 여전히 남아있었다.
펍지는 이러한 문제도 해결하기 위한 고민을 하던 중, 모두가 같이 개발하면 되지 않을까라는 생각을 떠올리게 되고 멀티플랫폼을 대응하여 함께 개발하고 동시에 업데이트를 진행할 수 있는 '심쉽 개발'을 진행하기에 이르렀다.
심쉽 개발은 개발팀 모두가 PC와 콘솔을 따로 두는 것이 아니라 함께 개발하는 조직으로 변화한다는 의미를 담고 있다. 심쉽을 함으로써 콘솔 업데이트 일정을 당길 수 있으며, 프로덕션 단계에서 전체 플랫폼 개발 비용을 산정할 수 있고 불필요한 PM, QA 추가 리소스가 없어지는 등의 다양한 장점을 가지고 있다.
물론 장점만 있는 것은 아니다. 가장 근본적인 문제로 이것이 정말 가능한 것인지가 의문이었다. 왜냐하면 콘솔 개발팀 인원은 기존 구성원보다 규모가 작았으며, 기존에 갖추고 있는 개발 파이프라인과 프로세스를 바꿔야하는 일이기 때문이다.
펍지는 장기적으로 봤을때 심쉽 개발로 전환하는 것이 도움이 될 것이라 생각했고 라이브 도중에 심쉽 개발을 해보기로 결정한다.
■ PART #3 심쉽 개발 파이프라인
심쉽을 진행하기에 앞서 가장 먼저 문화를 형성하는 것이 중요했다. 상위 리더가 위와 같은 결정을 하더라도 실무자들이 같이 움직여주지 않으면 절대 이뤄질 수 없는 개념이었기 때문이다. 다행히 모두 오픈 마인드로 함께 하자는 문화가 있었기에 함께 노력해 조금씩 변할 수 있었다.
PC 구성원은 콘솔 개발도 함께 신경쓰면서 개발을 진행했다. 콘솔 개발에 어려움이 생길 경우 기존 콘솔 구성원들의 서포트를 받으며, 팀내 개발 지식의 내재화를 이뤄냈다. 반대로 콘솔 구성원도 PC를 함께 고려해서 개발했다. 콘텐츠를 개발하거나 포팅을 할 때 확장성을 고려했다.
또한, 심쉽 전에는 개발 프로덕션 회의가 따로 진행되었지만, 심쉽을 진행하면서 개발 프로덕션, 퍼블리싱 회의를 함께 진행했고 결과적으로 함께 개발한다는 문화를 만들어갈 수 있었다.
한편, 진정한 심쉽 개발을 진행하기 위해선 QA 프로세스를 개편해야 한다고 밝혔다. 기존에는 모든 피쳐에 대해서 플랫폼마다 확인을 해야 했지만, 개편 이후 프로덕션 QA와 라이브 QA로 나눠 신규 업데이트 스펙은 프로덕션 QA에서 모든 플랫폼을 대상으로 체크하고 실제 라이브 서버에 적용되기 전에 라이브 QA팀에서 서비스별로 최종 검수를 진행했다.
본격적인 심쉽 전략에 앞서 펍지의 브랜치 전략에 대한 이야기도 오갔다. 펍지 개발팀은 PC, 콘솔 뿐만 아니라 세계 각지에 존재하는 글로벌지사와 함께 개발을 진행하고 있다. 따라서 브랜치 전략을 굉장히 중요하게 생각하며, 펍지는 모든 지사와 플랫폼 할 것 없이 하나의 브랜치에서 모든 개발을 함께 진행하고 있다. 이 부분은 십쉽 이전부터 진행하던 개발 방식이며, 중간에 변경된 것은 아니다.
만약 펍지가 통합된 브랜치 전략을 쓰지 않았다면 사실상 심쉽 개발은 진행하기 어려웠을 것이라고 전했다. 이전부터 모든 개발을 하나의 저장공간에서 했기 때문에 심쉽이라는 것도 시도해볼 수 있었다.
심쉽으로 전환 이후 브랜치 전략의 상당 부분이 이전과 크게 달라졌다. 기존에는 런칭부터 QA 진행 등의 과정이 모두 개별 브랜치 환경에서 이뤄졌다면 심쉽 전환 이후에는 PC와 콘솔의 QA가 같은 브랜치에서 진행되고 라이브로 넘어갈 때 PC와 콘솔로 나누게 된다.
다만, 심쉽 이후에도 PC와 콘솔은 동일한 날에 업데이트를 진행하지 않는데 몇 가지 이유가 존재한다. 사실상 서비스가 나눠져 있기 때문에 동일한 날에 업데이트를 할 필요는 없다. 펍지는 의도적으로 1주일이라는 간격을 두고 있는데, 콘솔 업데이트를 동시에 하기 위해 버퍼 기간을 두고 테스트 서버에서 발생하는 문제를 해결한 뒤 서비스를 오픈하기 위해서다.
마지막으로 콘솔은 비교적 복잡한 빌드 플랫폼 제출과정이 존재하기 때문이다. 빌드 서브미션과 플랫폼 QA과정이라고 생각하면 된다. 모바일 게임과 마찬가지로 빌드를 제출하고 유효성을 검사하는 과정이 여러 플랫폼에서 이뤄지므로 꽤 시간이 걸리게 된다.
펍지는 여러 상황을 고려해서 이런 브랜치 전략을 정했을 뿐 이것이 정답이라고 할 순 없다. 각자의 프로젝트에 맞는 최적의 브랜치 전략을 찾아보는 것이 중요하다고 전했다.
한편, 멀티 플랫폼을 대응하기 위해 내부 개발 가이드라인도 필요했다. 가이드라인은 엔지니어링, 아트, 디자인(기획) 가이드를 뜻한다.
엔지니어링 가이드는 대부분 성능 최적화에 맞춰져 있는 것이 특징이다. PC는 성능을 자유롭게 교체할 수 있는 반면, 콘솔은 하드웨어 성능이 제한되기 때문에 서비스 중인 플랫폼에서 가장 저사양 플랫폼 하드웨어를 기준으로 최적화를 맞출 필요가 있었다.
또한, 개발 과정에서 파티 시스템이나 보이스 시스템 등의 특정 모듈 기능을 활용하고 싶을 경우 최대한 공용 모듈을 활용하는 것이 좋다. 다양한 플랫폼에서 사용가능한 제품을 쓰는 것이 추후 유지보수 과정에서 유리하며, 자체적으로 만들어서 쓰거나 엔진에서 제공해주는 기능을 써도 좋다.
이렇듯 가이드라인을 만들때 지속적인 라이브 서비스를 위해 유지보스에 유리한 개발 환경을 마련할 필요가 있다. 통합할 수 있는 모든 것들은 통합하는 것이 중요하며, 때론 과감하게 지우거나 오버라이드해서 사용하도록 한다.
■ PART #4 심쉽 개발 포스트모템
그렇다면 이렇게 변경된 프로세서로 어떤 효과를 봤을까. 유저 입장에서 보면 한달 정도의 텀이 있던 콘솔 업데이트가 일주일로 당겨졌다는게 가장 큰 효과로 볼 수 있다. 개발자 입장에서도 앞서 언급했던 심쉽의 장점의 대부분을 체감할 수 있었다고 전했다.
다만, 처음에 예상했던 것처럼 진행 과정이 쉽지만은 않았다. 콘솔 개발을 하려면 콘솔 킷이 필요한데 PC와 다르게 많은 수량을 준비할 수 없었고 또한, 모든 사람들이 콘솔 개발 환경을 이해하고 개발해야 하니 구성원들을 설득해야만 했다.
하지만, 이런 어려움은 라이브를 반복하는 과정에서 숙달됨에 따라 많이 줄어들었고 점차 라이브 퀄리티가 높아지고 개발 속도로 빨라지는 경험을 할 수 있었다.
개발 비용 측면에서도 긍정적인 효과를 볼 수 있었다. 초기에는 심쉽 프로세스를 구축하는 시간과 비용이 기존 작업 방식보다 컸지만, 구축이 완료된 시점에서는 오히려 낮아져 많은 개발 비용을 세이브할 수 있었던 것 같다고 언급했다.
무엇보다 개발팀내 가장 큰 성과는 하나의 팀으로 일하는 방식을 깨닫게 된 것이라고 언급했다. PC와 콘솔로 구분돼 개발하는 조직이 아니라 펍지의 재미를 위해 움직이는 하나의 팀이라는 것이다.
끝으로 라이브 중인 프로젝트에서 신규 플랫폼을 런칭하는 일은 기존 개발 프로세스에 큰 변화를 주는 일이며, 이러한 변화는 모든 구성원의 일이 되기도 한다. 추후에 콘솔 확장 계획이 있다면 이런 고민거리가 있다는 점을 미리 알고 유연한 서비스로 만들어 나가보는 것이 좋을 것 같다고 전했다.
desk@inven.co.kr