Google Stadia 분석 (통합본)

Analysis 2019. 5. 8. 20:48

What

Google Stadia는 2019년 GDC에서 구글이 발표한 클라우드 게임 플랫폼이다. 기술적으로는 유투브와 유사한 형태의 스트리밍 기술을 사용한다. 스트리밍 게임과 일반 게임의 관계는 현재의 스트리밍 음원 서비스와 과거 mp3 파일의 관계와 유사하다. 과거에는 mp3 파일 형태의 음원을 구입하고, 다운로드 받고, 이를 사용자의 기기에서 직접 재생한 반면에, 현재의 스트리밍 음원 서비스는 사용자의 기기에 파일 형태로 음원을 저장하지 않고 서버의 음원을 사용자의 기기로 전달하여 재생하는 형태를 띄고 있다. 기존 게임도 이와 유사하게 게임을 구매하고, 다운로드 받고, 설치하고, 최종적으로 사용자의 기기에서 직접 게임을 실행했다. 하지만 스트리밍 게임은 이와는 다르게 클라우드 서버에서 실행한 게임을 사용자의 기기에 전달하는 형태로 게임을 즐기는 방식이다.

스트리밍 게임이 이루어지는 과정을 들여다보면 다음과 같은 과정을 거치게 된다. 클라우드 서버에서 게임을 실행하고, 실행의 결과물인 화면과 소리를 사용자의 클라이언트 기기로 전송하고, 사용자는 클라이언트 기기에서 재생되는 화면과 소리를 통해 게임을 플레이하는 형태이다. 일견 유투브와 같은 비디오 스트리밍과 유사하지만, 서버에서 클라이언트 기기로 스트리밍 데이터가 일방향 전송되는 유투브와 차이는 사용자의 입력 전달이라는 과정이 추가된다는 점이다. 게임을 플레이하기 위한 화면 터치, 게임 컨트롤러, 키보드/마우스 등 사용자의 입력은 클라이언트 기기에서 클라우드 서버로 전송되고, 클라우드 서버에서 실행 중인 게임에 전달되어 반영된다. 이러한 과정이 반복적으로 일어나면 사용자는 자신의 클라이언트 기기에서 직접 게임을 실행하지 않아도 스트리밍을 통해 게임을 즐길 수 있다.

스트리밍 게임의 장점은 사용자의 클라이언트 기기에서 실행하기 어려운 고사양의 게임이나 타 플랫폼향의 게임을 즐길 수 있다는 점이다. 예를 나의 PC는 사양이 낮아 최신 게임을 실행하기 어려운 상태라고 하더라도, 스트리밍 게임을 통해서 고사양의 PC 게임을 즐길 수 있고, 더 나아가서 PC 게임이 아닌 게임 콘솔용 게임이나 모바일 게임도 즐기는 것이 가능하다.

반면 스트리밍 게임의 단점은 높은 Latency로 인한 스트리밍의 끊김 현상이 있을 수 있다는 점이 가장 큰 부분으로 지적된다. 게임은 실시간으로 플레이가 되어야 하기에 유투브와 같이 버퍼링 기술을 활용할 수 없다. 모든 화면과 소리를 실시간으로 사용자의 기기로 전송해야 한다. 사용자가 실시간으로 게임을 플레이 하던 중 게임의 끊김 현상이 발생하면 게임의 특성상 사용자 경험의 심각한 저하가 유발된다. 또, 스트리밍 게임을 운영하기 위해서는 고사양의 서버 인스턴스 비용과 네트워크 트래픽 비용이 발생하는데, 이는 높은 사용 요금으로 직결되기에 구매력이 낮은 사용자를 끌어들이기 힘든 점도 스트리밍 게임의 큰 단점 중 하나이다.

스트리밍 게임의 명백한 장점때문에 과거에도 Play Station Now, Game Pass, Geforce Now, Game Fly 등 크고 작은 게임 스트리밍 서비스가 다수 존재했다. 그리고 현재에도 스트리밍 게임을 위한 기반 기술이나 스트리밍 서비스를 제공하는 많은 업체들이 존재한다. 그런데 과거에 존재했거나 현존하는 대부분의 게임 스트리밍 서비스는 사용 가능한 클라이언트 기기의 제약이 있는 형태였고, 서비스에 따라 다르지만 사용 요금 역시 발생했다. 또한 네트워크 상황에 따라 높은 Latency가 나타나는 경우도 비일비재 했기에 게임 스트리밍 서비스는 일반화 되지 못했다.

Stadia는 기존과 다르게 웹브라우저가 작동하는 대부분의 클라이언트 기기에서 사용 가능한 게임 플랫폼으로 소개가 되었으며, 발표된 성능 역시 현존하는 어떤 스트리밍 게임 서비스보다 높은 수준이었다. 또한 과거 스트리밍 서비스에는 존재하지 않았던 다양한 신규 기능들을 포함하고 있음을 강조하였다. Stadia는 이러한 차별점으로 인해 게임 시장의 판도를 바꿀 수 있는 새로운 게임 플랫폼으로 주목을 받고 있다. 물론 Stadia가 상용화 되었을 때 현실의 서비스 환경에서 구글이 발표한 수준을 만족할 수 있을지는 지켜보아야 할 일이다.

Specifications

Stadia는 클라우드 서버를 그 근간으로 하고 있다. 현대의 클라우드 서버는 여러대의 서버 인스턴스를 모아놓은 랙과 이 랙들이 모여있는 거대한 룸의 형태로 이루어져 있는데, 그 하나의 서버 인스턴스를 블레이드 서버라고 지칭한다. 책장에 꽂힌 책들처럼 여러 대의 블레이드 서버가 모여 클라우드 서버를 구성한다. 구글은 Stadia를 구성하는 블레이드 서버의 하드웨어 사양을 다음과 같이 발표했다.

GPU

CPU

Memory

10.7 Teraflops

56 compute units

HBM2 Memory

Custom x86 Processor

2.7 GHz

Hyperthreaded

AVX2

16 GB of total RAM

Up to 484GB/s transfer speed

L2+L3 Cache of 9.5MB

AMD와의 협업을 통해 Custom 제작한 GPU, 역시 Custom 제작을 한 CPU, 그리고 16기가의 램이 그 내용인데, 블레이드 서버 하나가 하이엔드 PC에 비견될 수 있는 성능을 가질 것으로 보인다. Stadia 블레이드 서버의 스펙에서 가장 주목해야 할 부분은 GPU이다. 구글은 Stadia 발표에서 현존하는 콘솔 게임기에 대비해 Stadia의 성능이 더 뛰어남을 강조했다.

PlayStation 4 Pro	Stadia	Xbox One X
4.2 teraflops	10.7 teraflops	6.0 teraflops

사실 GPU스펙을 보여주는 것은 어느 정도 부풀려진 이미지를 노린 것이다. Stadia의 블레이드 서버는 PC에 준하는 형태를 가지고 있다. 그런데 사람들의 일반적인 인식으로는 플레이스테이션이나 엑스박스와 같은 게임 전용 콘솔의 GPU 성능이 PC보다 월등히 뛰어나다 믿기에 Stadia의 성능이 더욱 대단해 보이는 것이다. 그러나 한 번 출시되면 10년 가까이 유지되는 게임 전용 콘솔의 특성상 게임 전용 콘솔의 GPU 성능은 동시대의 하이엔드 PC보다 떨어지는 것이 일반적이다. 즉, 현존하는 최고 성능의 게임 기기는 게임 전용 콘솔이 아닌 하이엔드 PC이다. 그렇다면 현존하는 하이엔드 PC의 GPU 성능과 Stadia를 비교하면 어떨까?

TITAN V	Radeon RX Vega 64	GeForce GTX 1080 Ti	Radeon R9 295X2	Stadia
13.8 teraflops	12.7 teraflops	11.3 teraflops	11.2 teraflops	10.7 teraflops

source: https://www.geeks3d.com/

PC 코어 게이머들의 로망인 GeForce GTX 1080 Ti 정도면 Stadia의 성능을 충분히 상회한다. 거기에 단순히 스펙상의 gflops 숫자로 나타나지 않는 NVidia의 게임 플레이 최적화된 GPU 설계와 성능을 고려하면 체감되는 게임의 구동 성능은 하이엔드 PC쪽이 훨씬 더 뛰어날 것이다.

Stadia는 Linux기반의 Vulkan을 활용한다고 발표했다. Vulkan에 대한 부연 설명이 조금 필요한데, Vulkan은 표준화 그룹인 Khronos의 주도로 제정된 새로운 그래픽 라이브러리 표준이다. 기존 윈도우즈에서는 DirectX라는 마이크로소프트의 독자 표준을 사용해 왔고, Linux진영에서는 OpenGL이라는 역시 Khronos 그룹이 제정한 표준을 사용해 왔다. 모바일 기기에서는 OpenGL이 너무 무겁기 때문에 OpenGL ES라는 OpenGL의 부분집합 개념의 표준을 사용했다. 대부분의 모바일 기기들에서는 OpenGL ES 라이브러리가 제공되었고 운영체제나 어플리케이션들은 이 라이브러리를 사용해 그래픽을 표현했다. 안드로이드의 최하단 Rendering을 담당하는 SurfaceFlinger 역시 OpenGL ES를 사용하여 렌더링 연산을 수행해왔다.

문제는 이 OpenGL ES가 오랜 세월을 거치면서 상당히 많은 기능이 추가되었고, 이에 따라 점점 무거운 라이브러리로 변형되어 왔다는 점이다. 이를 극복하기 위해 Khronos에서는 가벼운 형태의 새로운 그래픽 라이브러리 표준을 정의하게 되는데 이것이 바로 Vulkan 라이브러리다. 참고로 애플은 독자적으로 DirectX와 비슷하게 Metal이라는 표준을 만들어 사용하고 있으며, 이는 Vulkan보다 먼저 상용화되었다. 성능 이점으로 인해 Vulkan 라이브러리는 점차 여러 모바일 기기에서 지원되기 시작했고, Linux에서도 역시 지원이 가능해졌다.

구글의 발표는 Stadia는 Linux기반의 운영체제를 탑재하고 있으며 Vulkan을 사용해 성능 향상이 기대된다는 점을 강조한 것이다. 그런데, 사실 모바일 기기가 아닌 PC에서 Vulkan의 유용성이 클지는 의문이다. Stadia의 블레이드 서버 인스턴스는 PC에 준하는 형태를 띄고 있으며 서버이기에 무제한의 전력을 공급받으며 발열이 발생해도 적정 온도가 유지되는 환경에서 구동된다. 저전력과 발열 감소를 위해 클럭을 희생해야 하는 모바일 기기와는 확연히 다른 환경이다. 그리고 Linux + Vulkan 조합이 Windows + DirectX 조합보다 높은 성능을 가지기는 어렵다. Vulkan과 같은 시도를 사실상 90년대 부터 시작한 것이 DirectX이고 그간 다양한 게임을 통해 성능이 검증된 플랫폼이라는 점을 감안한다면 구글의 선택이 성능 향상보다는 라이센스 비용 감소가 그 목적이 아닐까 하는 합리적인 의심을 해볼 수 있다.

Features에서 다루겠지만 구글은 하나의 블레이드 서버 인스턴스로는 감당하기 어려운 특장점들을 소개한다. 그리고 이를 가능하게 하기 위해서 하나의 하드웨어가 아닌 데이터 센터를 활용함을 강조한다. 다시 말해서 하나의 게임을 구동하기 위해 다수의 블레이드 서버 인스턴스를 동원하고, 다수의 GPU나 CPU를 해당 게임의 구동을 위해 활용한다는 것이다. 이 역시 듣기에는 그럴듯하지만, Parallel Processing이 무한대의 성능을 보장해 주지 않는다는 점에서 생각해볼 여지가 남는다. 여러 개의 하드웨어를 사용할수록 연산을 분리하고, 또 분산된 결과를 취합하는 오버헤드도 늘어나게 된다. 이 오버헤드가 임계점을 넘으면 결국 성능이 일정하게 유지되거나 오히려 저하되는 결과로 이어지는 것이 현실이기 때문이다.

또한 데이터 센터를 활용한 GPU/CPU Farm 형태의 솔루션은 서버 비용의 증가로 직결된다. 과거에 존재했던 클라우드 서버 기반의 게임 스트리밍 서비스들의 경우 서버 비용을 줄이기 위해 하나의 서버 인스턴스를 여러 사용자가 나누어 쓰는 기술을 공들여 개발하고 적용해왔다. 인스턴스 당 유저 숫자가 높을수록 더 싼 스트리밍 서비스가 가능하기 때문이었다. Stadia는 이와 정반대로 한 명의 유저가 다수의 서버 인스턴스를 점유하고 사용하는 형태의 서비스를 제공한다고 발표했다. 루머에 따르면 Stadia 서비스는 게임을 구매하는 비용을 제외하면 사용자에게 스트리밍 서비스 사용에 대한 과금을 하지 않는다고 한다. 사용자가 많아질수록, 또한 스트리밍을 많이 사용할수록 트래픽 비용이 급증하게 될 것이 쉽게 예측되는데, 아무리 마케팅 비용으로 큰 투자가 가능한 구글이라지만 유료 게임 판매와 게임내 구매를 통해서 안정적인 비즈니스 모델을 만들어 낼 수 있을지 의문이다.

구글은 Stadia 전용 컨트롤러를 발표했다. PC 게임을 즐기는 사용자들에게 게임 컨트롤러는 익숙한 악세사리이며, 최근의 PC 게임들은 콘솔화를 의식해서 대부분 게임 컨트롤러를 지원하고 있다. PC보다 규모는 적지만 스마트폰이나 태블릿과 연동하여 사용할 수 있는 게임 컨트롤러 역시 크고 작은 제조사에서 다양한 제품이 출시되어 있다. 구글은 사용자가 이미 가지고 있는 게임 컨트롤러를 Stadia에 활용할 수 있다고 언급했으며, 이와 동시에 Stadia 전용의 게임 컨트롤러를 발표한 것이다.

구글이 언급한 Stadia 전용 게임 컨트롤러는 일반적인 컨트롤러와 다른 2개의 버튼이 존재한다. 첫 번째 버튼은 Capture 버튼이다. 이 버튼을 통해 사용자는 게임의 다양한 부분들을 Capture하여 다른 사용자들에게 공유할 수 있다. 두 번째 버튼은 Google Assistant 버튼이다. 이 버튼을 누르면 컨트롤러에 내장된 마이크로폰이 작동하며, 사용자는 음성 명령을 통해 게임의 요소들을 호출할 수 있다. Capture 버튼의 경우는 플레이스테이션 컨트롤러에도 유사하게 비디오 캡쳐 기능을 하는 버튼이 존재해서 그리 새로운 기능은 아니다. Google Assistant 버튼의 경우 Stadia만의 특색이기는 하지만 게임 중간에 이 버튼을 누르고 굳이 음성을 통해 명령을 내릴 일이 많을지는 미지수이다. 음성입력을 활용하는 몇몇 게임이나 FPS 게임에서 팀원들과 의사소통을 위한 용도 이외에는 크게 쓰일 일이 없을 것으로 보인다.

그러나 위에 언급한 기능을 위해 전용 컨트롤러를 만든 것은 구글의 주된 목적이 아닌 것으로 보인다. Stadia 전용 컨트롤러의 가장 큰 특징은 컨트롤러가 클라이언트 기기가 아닌 Stadia의 데이터센터로 와이파이망을 통해 직접 연결된다는 점이다. 전통적인 클라우드 게임 스트리밍에서 게임 컨트롤러는 블루투스나 유선 연결의 형태로 클라이언트 기기에 연결이 되고 클라이언트 기기는 여기서 발생하는 입력 신호를 클라우드 서버로 전송하는 구조를 가진다. Stadia 전용 컨트롤러는 이 중간 과정을 생략하고 사용자의 입력을 데이터센터로 직접 전송한다. 이 방법을 통해 Stadia는 입력 Latency를 획기적으로 줄일 수 있다고 설명한다.

사실 서버로의 컨트롤러 직접 연결은 안드로이드 운영체제의 오래된 문제를 해결하기 위한 고육지책이다. 애플의 아이폰이나 지금은 사라진 윈도우즈폰의 운영체제는 네이티브 기반이고 이런 운영체제에서는 블루투스를 통한 컨트롤러 연결의 Latency가 현저히 낮게 처리된다. 그러나 안드로이드는 네이티브 스택 위에 자바로 이루어진 커다란 스택이 존재하며, 블루투스를 통해 안드로이드 기기에 연결된 컨트롤러의 Latency는 좋지 않은 성능을 보인다. 이는 안드로이드 초창기부터 있어왔던 오래된 문제이며, 특히 오디오 신호를 전달하는 헤드셋이나 마이크, 연주와 관련된 장치에서는 큰 문제가 되어왔다. 최근 안드로이드 버전에서 많은 개선이 있기는 했지만, 여전히 변화무쌍한 Latency를 보이는 경우가 많다.

Stadia는 안드로이드의 블루투스 성능 저하를 딛고 사용자의 게임 입력을 원활하게 처리하기 위해 컨트롤러를 데이터센터에 직접 연결한 것이다. 문제를 극복하기 위한 좋은 시도로 보이지만, 컨트롤러가 직접 인터넷에 연결이 되어 있어야 한다는 점에서 사용자 시나리오가 그리 좋을 것 같지는 않다. 디스플레이가 없는 컨트롤러를 와이파이에 연결하기 위해서는 결국 클라이언트 기기를 통해 설정을 해주어야 하는데, 최근 프린터의 무선 셋팅에서 보듯이 이런 형태의 설정은 엔트리 레벨의 사용자에게 쉬운 작업이 아닐 것이다. 또한 연결이 끊어지거나, 망이 전환되는 등의 예외 상황 처리도 녹록하지는 않아 보인다.

구글은 클라우드 게임의 레이턴시 이슈를 의식하여 이를 개선하기 위한 시도로 Public Internet이 아닌 자사의 Backbone 망을 활용한 Stadia 서버와의 연결을 제시했다. 인터넷의 특성상 네트워크 패킷은 목적지에 도착하지만 어떤 경로로 패킷이 전달될지는 보장되지 않는다. 패킷이 도착하는 순서가 각각 달라져서 의미있는 데이터를 확보하는데 기대치보다 오랜 시간이 걸리는 경우가 발생해 고른 품질의 스트리밍이 보장되지 않는 점을 개선하기 위해 구글은 자사가 그동안 투자한 해저 케이블 등 전용 망을 이용하여 Stadia서버와 연결된다고 설명했다. 이를 통해 예측 가능한 Latency, 안정적인 연결, 그리고 덤으로 보안성도 강화된다는 설명이다. 이는 실제로 기술적으로 상당히 유의미한 부분이라고 할 수 있다.

그러나 사실 전용망을 통한 클라우드 서버 연결은 클라우드 서비스를 하기 위해서는 기본적으로 선행되어야 할 부분이다. 스트리밍 서비스 제공자나 Low Latency의 네트워크 서비스를 제공하는 벤더들의 경우 대부분 서비스 제공 지역에 자체 Backbone 망을 구축하고 있거나 Backbone을 대여하여 사용한다. 사실상 타 사업자들의 서비스에서도 Stadia와 같은 형태의 서비스가 제공되는 것임을 고려하면 Stadia만의 큰 차별점이라 보기는 어렵다. 물론 구글의 전용망은 전세계의 대부분을 커버할 수 있다는 점과 유투브를 통해서 그 안정성이 입증되어 있다는 점은 구글만의 장점이라고 할 수 있겠다.

또 하나의 맹점은 사실 최근의 클라우드 서버 연결은 인터넷 망뿐만이 아닌 이동통신망을 통해서 이루어지는 경우가 늘어나고 있다는 점이다. 구글이 전용망을 운영하더라도 사용자의 클라이언트 기기가 이동통신망에 물려 있다면 전용망의 장점이 반감될 수밖에 없다. 사실 이를 극복하기 위해 최근에는 Edge Computing이 대두되고 있다. 클라우드 서비스를 인터넷망이 아닌 이동통신망 내부에 구축하는 방법을 통해 이동통신망에 물린 기기들이 인터넷망으로 나가지 않고 이동통신망 내에서 클라우드 서비스를 접근하는 방식이다. 이를 지원하기 위해서는 이동통신망 내부에 클라우드 서비스를 위한 서버를 구축하는 작업이 필요하다. Stadia도 이동통신사와 협력을 통해 이와 같은 방식의 접근을 하는 것이 미래의 통신 환경을 대비하는 방법이 될 것이다.

Features

Cross Platform

Stadia의 발표 도입부에 가장 강조된 점은 Stadia는 Box가 필요없는 크로스 플랫폼이라는 점이었다. 클라이언트 기기의 종류에 상관없이 크롬브라우저가 설치된 기기라면 어디에서나 플레이 가능하다. 실제로 크롬북, 픽셀폰, 그리고 태블릿에서 끊김 없이 게임을 플레이하는 장면이 시연되었다. 비즈니스적인 목적이나 기술적인 이유로 구동 가능한 기기가 제한되었던 기존 게임 스트리밍 서비스와 비교하면 혁신적인 시도라고 할 수 있다.

이를 가능하게 하는 것이 크롬 브라우저를 통한 게임의 실행이다. 사실 스트리밍 서비스에서 스트리밍을 받는 대상 기기의 성능은 크게 중요하지 않다. 기기에서 가장 중요한 부분은 하드웨어를 통한 영상 디코딩 가속인데, 유투브의 등장으로 대부분의 기기에서 영상 디코딩은 하드웨어로 지원되고 있는 것이 현실이기 때문이다. 크롬브라우저 역시 기기의 디코딩 가속을 이용할 수 있기에 크롬브라우저에서 웹기반으로 충분히 스트리밍 기능을 제공할 수 있다. 단순히 특정 게임에 대한 링크를 공유하는 것만으로 크롬브라우저가 설치된 어느 기기에서도 즉시 게임을 플레이할 수 있다는 것은 충분히 매력적인 부분이다.

물론 통일된 크롬브라우저의 표면 밑에서는 기기간의 호환성을 유지하기 위한 숨은 노력이 많이 필요하지만, 크로스 플랫폼 지원을 통해 얻을 수 있는 이득에 비하면 적은 비용이라 할 수 있다. 3D 렌더링이 필요한 실제 게임 구동과 달리 웹브라우저에서 스트리밍에 필요한 호환성 지원은 상대적으로 작은 부분이기에 더욱 그렇다.

구글의 이러한 크로프 플랫폼 접근은 아마 다른 클라우드 게임 서비스에도 많은 영향을 줄 것이다. 자사의 스마트폰에서만 가능했고 최근에야 아이폰으로 확장된 플레이스테이션 스트리밍이나 Windows가 탑재된 노트북에서만 가능했던 마이크로소프트의 Game Pass 등의 서비스도 지원 가능한 플랫폼을 늘리려는 노력을 시도하지 않을까 예상해 본다. 특히나 마이크로소프트는 이미 xCloud라는 게임 스트리밍 플랫폼을 준비중이라고 밝히고 있는데, xCloud는 Game Pass보다 훨씬 폭넓은 기기를 지원하게 될 것 같다.

Realtime Rigidbody Physics

Stadia의 멀티플레이어 기능 소개 초반에 도시를 배경으로 날아가는 캐릭터가 소개된다. 그리고 보이는 모든 물건을 파괴할 수 있다는 설명이 곁들여진다. 구글은 Realtime Rigidbody Physics를 통해 이런 연출이 가능함을 말했다. 일반적으로 게임을 개발할 때 기본이 되는 배경을 Scene이라고 부른다. 이 Scene에는 다양한 Object들이 등장하고 이들간의 상호작용이 우리가 보게되는 게임의 장면들을 구성한다. 게임에 등장하는 어떤 사물을 파괴하려면 그 사물을 표현하는 Object에 대한 연산이 필요하다. 이 연산 과정에서 물리적인 상호작용을 처리할 수 있는 Rigidbody가 필요한데, 파괴하고자 하는 Object에 Rigidbody가 포함되어 있어야 그 물체의 파괴를 표현할 수 있다. 문제는 이 Rigidbody의 연산에는 많은 컴퓨팅 파워가 필요하기 때문에, Scene에 등장하는 모든 Object에 Rigidbody를 포함할 수 없다는 점이다. 그래서 일반적으로 게임 내에서 물리적인 상호작용이 필요한 Object에만 Rigidbody를 적용한다. 시중에 나와 있는 게임을 플레이하다 보면 상호작용할 수 있는 물체와 그렇지 못한 물체를 경험할 수 있다.

이제 구글이 언급한 "보이는 모든 물건을 파괴할 수 있다"는 문장을 살펴보면 이것이 왜 강조되었는지를 알 수 있다. 화면에는 도시가 등장하고 있다. 이 상황에서 도시의 모든 물건을 파괴할 수 있다는 말은 곧 "보이는 모든 물건에 Rigidbody가 포함되어 있다"라는 말과 동치이다. 게임 개발 경험이 있는 사람이면 이것이 얼마나 많은 컴퓨팅 파워를 필요로 하는 일인지를 쉽게 알 수 있다. 구글은 여러 개의 GPU를 활용한 Realtime Rigidbody Physics 기술을 통해 이런 연출이 가능하다고 말한다. 그러나 아무리 많은 GPU를 사용하더라도 모든 Object에 Rigidbody를 넣는 것은 무모한 시도이기에 상호작용이 가능한 Object를 실시간으로 선별하여 해당되는 Object들의 Rigidbody를 활성화시키는 기술로 추정된다.

그러나 실제로 이런 연출을 게임 내에서 한다면 컴퓨팅 파워의 소모가 엄청날 것이고, 연산이 가능하다 하더라도 게임 개발자는 모든 물체의 상호작용에 대한 구현을 해야 하며, 그래픽 디자이너는 물체의 파괴를 고려한 엄청난 양의 그래픽 리소스를 제작해야 할 것이다. 사실 이렇게 게 많은 노력을 투입하지 않더라도 필요한 장면들에 대해서는 곧이 곧대로 Rigidbody를 활용하지 않고 비슷한 연출을 할 수 있다. 게임 개발자의 입장에서 굳이 Realtime Rigidbody를 활용한 연출을 할지는 지켜보아야 할 일이다. 그 정도의 개발 리소스를 게임 내의 다른 영역에 투입하면 훨씬 더 좋은 컨텐츠를 만드는 것이 가능하지 않을까 하는 의문이 남는다.

Stream Connect

멀티플레이어 기능의 일환으로 구글은 Stream Connect라는 기능을 소개한다. 하나의 플레이어가 헌터로서 게임을 하는 도중에 다른 플레이어가 게임에 참여해 관찰자 역할을 수행한다. 추가된 플레이어는 자기 시점의 Camera View를 실시간으로 배당받아 게임에 참여하게 된다. 두 플레이어는 같은 게임을 플레이하게 되며 서로간의 상호 작용이 가능하다. 이와 같은 형태로 실시간으로 Camera View의 갯수를 늘려나갈 수 있다.

기능적인 면에서 보자면 Stream Connect는 전통적인 멀티플레이어 게임의 사용 시나리오와 다르지 않다. 추가적으로 참여하는 플레이어와 기존 플레이어의 상호작용을 위해서는 어차피 게임 개발자가 해당 상황에 대한 구현을 해야 하기 때문에 특별히 Stadia만의 특화 기능이라고 보기에는 무리가 있다. 다만 추가되는 플레이어의 화면 연산이 기존 플레이어에게 할당된 GPU가 아닌 물리적으로 다른 GPU에서 독립적으로 수행이 된다는 점이 기술적으로 독특한 부분이다. 이와 함께 서로 다른 플레이어들 간의 동기화를 유지하는 기술을 적용했다고 구글은 이야기 했다. 구글의 언급이 실제로 구현된다면 Stream Connect를 활용해서 사용자가 추가되더라도 게임이 느려지는 일이 없이 자연스러운 멀티플레이어 게임이 가능해 지리라 예상된다.

Style Transfer

Style Transfer는 실시간으로 적용 가능한 화면 Filter이다. 게임 화면을 사용자가 원하는 스타일로 실시간으로 변경해서 보여주는 기능이다. 구글이 자랑하는 AI 기술과 Stadia의 여러 인스턴스를 활용하여 게임 화면을 실시간으로 변경하여 보여준다. 쉬운 예로 컬러풀한 게임 화면을 흑백으로 바꾼다던지, 실사에 가까운 화면을 점선모양 애니메이션으로 바꾼다던지 하는 변경을 게임 실행 중에 적용하는 경우가 해당된다. 미리 정의된 스타일을 적용할 수 있고, 혹은 사용자가 지정한 형태로 Custom한 Style을 적용할 수도 있다.

개인적인 감상은 필요한 기능이라기 보다는 구글의 기술력을 보여주고 싶은 기능이거나 내세울 Feature가 모자라서 피칭에 추가된 항목이라고 생각된다. Stadia를 추진하는 구글이 실상 게임 생태계에 대한 이해가 부족하다는 점을 여실히 보여주는 부분이다. 게임에서 화면의 분위기는 매우 중요한 요소이다. 이를 위해 많은 고민과 고려가 수반되고 실제로 많은 노력을 들여 게임마다 고유한 분위기를 낸다. 게임을 플레이하는 사용자는 이렇게 게임 PD가 세심하게 구성한 게임의 화면을 즐기기 위해 기꺼이 비용을 지불하고 게임을 구매한다. 그런 게임의 화면에 필터를 씌워 변경하는 일은 일시적인 재미를 위해서 잠시 쓰는 기능일 수 있지만, 게임 자체를 즐기는 사용자들에게 크게 의미가 있는 기능은 아닐 것이다. 시리즈를 거듭하며 매번 성공 신화를 쓴 블리자드의 디아블로를 돌아보면, 매 시리즈 훌륭한 게임성에도 불구하고 열혈팬들 사이에서 디아블로1의 음침한 분위기를 살리지 못했다는 비판이 수반되고는 한다. 과연 디아블로 플레이어들이 파스텔톤의 디아블로를 원할지 생각해 본다면 Style Transfer 기능의 미래를 쉽게 짐작할 수 있을 것이다.

Crowd Play

Crowd Play는 Stadia의 멀티플레이어 시나리오의 확장 기능이다. 이 기능의 타겟은 게임 방송을 진행하는 진행자와 이를 시청하는 시청자들 사이에서 이루어진다. 방송의 진행자가 특정 게임을 플레이 하던 도중 시청자를 선별하여 게임에 접속하게 할 수 있는 것이다. 간단히 링크를 공유하는 것만으로 시청자는 방송 중인 게임에 접속하여 방송 진행자와 같이 게임을 플레이 할 수 있다. 물론 게임에 대한 접근 권한은 게임을 개설한 방송 진행자가 전권을 가지고 조절할 수 있다.

구글의 성공적인 서비스인 유투브와의 연계를 고려한 기능이라고 볼 수 있다. 마이크로소프트의 Mixer, 많은 사용자를 가진 Twitch를 비롯해서 게임플레이를 공유하는 시장은 점점 중요해지고 커지고 있기에 이를 지원하기 위한 기능은 나름대로 의미가 있는 기능이라고 볼 수 있다. 그러나 게임 방송을 시청하는 시청자의 대부분은 자신이 하기에 어렵거나, 특이한 형태의 플레이들을 시청하는 Lean Back 경험을 즐기고 있기에 방송중인 게임에 접속하여 같이 게임을 하는 시나리오는 비율상 높지는 않을 것이다. 그리고 게임마다 다를 수 있지만 자체적으로 멀티플레이어를 지원하는 게임보다는 서버를 통한 멀티 플레이어를 지원하는 게임이 더 늘어나는 추세이기에 Crowd Play를 능동적으로 활용한 게임 방송이 얼마나 시장에서 의미를 가지게 될지는 미지수이다.

State Share

State Share는 현재 진행중인 게임의 상태를 즉시 공유할 수 있는 기능이다. 게임에 등장하는 캐릭터의 위치, 게임의 스테이지, 가지고 있는 아이템등의 정보를 즉시 공유하는 기능이다. 게임의 상태는 url의 형태로 공유가 되며, 해당 url을 통해 공유된 게임의 상태에서 즉시 게임을 시작할 수 있다. 해당 기능의 구현을 예상해 본다면, 게임의 상태를 Stadia 서버에 저장하고, 이를 가리키는 url을 생성하여 공유가 가능하게 하고, 다른 사용자가 이 url을 통해 접근하면 서버에 저장된 게임의 상태를 새로운 게임 프로세스에 적용하여 이 상태를 그대로 사용자에게 스트리밍하는 방식으로 추정된다.

이 기능은 사실상 고전적인 Save/Load 기능과 큰 차이가 없어 보인다. UX의 관점에서 게임을 저장하고 다시 로드하여 플레이하는 복잡도를 줄였을 뿐 같은 기능을 수행한다. 어차피 이 기능을 지원하기 위해서는 게임 구현 내부에 Save/Load를 위한 구현이 포함되어야 하고, Stadia만을 위한 인스턴트 로드 기능까지도 구현해야 할 것이다.

물론 Stadia가 게임 구현을 바꾸는 것이 아닌 현재 실행되는 게임의 메모리 정보를 통째로 백업하고 재생하는 형태로 이 기능을 구현했을 수 있다. 가상화 기술에서 많이 쓰이는 방법으로 Virtual Machine의 상태를 저장하고 복구하는 것과 같은 원리이다. 이런 형태의 구현이라면 게임 개발자는 게임을 전혀 수정할 필요가 없다. 다만 Stadia의 입장에서는 사용자가 State Share를 호출하는 횟수 만큼 저장 공간을 할당하여 게임 상태를 저장해야 하기에 스토리지의 로드가 큰 이런 방법으로 State Share기능 구현을 하지는 않았으리라 예상한다.

기술을 떠나서 State Share가 목표로 하는 게임은 시연에 나타난 것과 같은 혼자서 플레이하는 Standalone 게임들이다. 그런데 최근의 게임 시장은 멀티플레이어 기능이 들어가지 않은 게임을 찾는 것이 더 어려울 지경이다. 여러 사람이 실시간으로 공동 플레이를 하는 게임의 경우 State Share 기능은 적용이 불가능하다. 이런 관점에서 State Share 기능 역시 구글의 게임 시장에 대한 이해 부족을 방증한다고 보인다. 아마도 이 기능을 기획하고 개발한 팀장은 게임을 아주 오래전에 해보았거나 아예 게임을 하지 않을 가능성이 크다.

Performance

Stadia 발표에서 가장 놀라운 부분은 바로 런칭 시점에 4K 비디오를 60 FPS로 제공하고, 향후 8K로 확장한다는 부분이었다. 만약 구글이 발표한 성능이 스트리밍을 포함한 end to end delay라면 이 발표는 너무 심한 과장이라고 볼 수 있다. 서버에서 렌더링 처리가 완료된 시점부터 계산을 하더라도 한 장의 최종 4K 화면을 인코딩 -> 네트워크 전송 -> 디코딩 -> 클라이언트단의 렌더링하는 전체 과정이 16ms 이내에 완료되어야 한다. 버퍼링이 가능한 비디오 스트리밍에서도 달성하기가 쉽지 않은 수준인데, 버퍼링이 불가능한 게임 스트리밍에서 현재의 네트워크와 장비를 이용해 이와 같은 성능을 보이는 것은 굉장히 어려운 일이기 때문이다. 스트리밍 솔루션을 구축해본 경험이 있는 사람이라면 구글의 수치가 얼마나 과장되었는지 알 수 있을 것이다. 세계에서 가장 빠른 대한민국의 네트워크 환경에서도 최대 성능으로 잡을만한 목표인데, 글로벌 환경에서 이와 같은 수치는 불가능하다 해도 과언이 아닐 것이다. 설혹 구글이 이런 현실적인 제약을 전부 극복하고 4K 60 FPS를 어떤 환경에서도 제공할 수 있는 기술을 가지고 있다면 현재 엄청난 수익을 가져다 주고 있는 유투브에 먼저 적용하지 않았을까? 그 대단한 기술을 아직 성공 가능성도 예측할 수 없는 신규 플랫폼에 먼저 투입하는 것은 상당히 어색한 접근이다.

상식적으로 생각해 볼 때 이 지표를 통해 구글이 의미하는 바는 Stadia 서버에서 4K 게임 컨텐츠를 60 FPS로 구동한다는 의미로 보인다. 이 결과물이 클라이언트 기기로 전달되어 최종적으로 렌더링 되는 성능은 물론 이것보다 떨어질 것이다. Stadia는 크로스 플랫폼을 지향하기에 사용자의 기기마다, 또 네트워크 환경마다, 성능이 다르게 나타날 것이다. 결국 사용자들이 체감하는 성능은 서버에서 구동되는 게임의 성능이 아닌 실제 클라이언트 기기에서 체감되는 성능인데, 그렇다면 실제 Real World에서 Stadia의 성능은 어떨까하는 궁금증이 생기지 않을 수 없다.

유투브의 Digital Foundry 채널에서는 Stadia에 대한 소개와 함께 Latency 측정 결과를 공유하였다. 측정 방법은 초고속 카메라를 사용해서 물리적인 버튼이 눌리는 시점부터 화면에 버튼 동작이 반영되는 시점까지의 시간을 측정했다. 소프트웨어적인 측정보다는 부정확한 면이 있을 수 있지만 사용 경험 면에서 보기에는 충분히 유의미한 숫자로 해석될 수 있을 것이다. 몇몇 테스트 제약 조건이 있는데 Stadia는 와이파이에 연결된 픽셀북에서 측정하였고, 나머지 플랫폼의 경우에는 유선 연결을 사용하였다. Project Stream은 Stadia의 조상격인 구글의 스트리밍 프로젝트이고 200mbps의 유선 연결을 사용해 측정되었다. 전체 측정 결과는 다음과 같다.

Platform	Stadia	Project Stream	PC 30fps	PC 60fps	Xbox One X
Latency	166ms	179ms	112ms	79ms	145ms

source: https://youtu.be/VG06H7IQ9Aw?t=731

Stadia는 166ms의 측정결과를 보인다. 입력 랙이 포함되어 있다고는 하지만 60 FPS를 구현하기 위한 16ms와는 거의 10배 정도의 차이가 난다. 스펙상으로 뒤떨어질 것처럼 보였던 Xbox나 PC의 성능은 Stadia보다 더 뛰어나다. 그리고 예상대로 하이엔드 PC가 가장 좋은 성능을 보여주고 있다. 물론 Stadia의 166ms라는 수치도 기존의 클라우드 게임 서비스와 비교할 때 그렇게 나쁜 수치는 아니다. 오히려 클라우드 업계에서는 뛰어난 축에 속하는 수치라고 볼 수 있다. 하지만 기존 게임 플랫폼을 뒤집기에는 한참이나 부족한 숫자로 보인다. 하이엔드 PC는 1초에 10번의 입력에도 훌륭하게 반응한다. 하지만 Stadia는 1초에 6번 이상의 입력이 발생할 경우 랙을 느끼게 된다. 캐주얼한 게임이나 시뮬레이션 게임과 같이 정적인 부분이 많은 게임에는 문제가 없겠지만, RTS나 FPS같이 PC 사양에 따라 승패가 갈릴 정도의 인텐시브한 게임에서는 승률이 떨어지는 것을 직접 체감할 수 있을 것으로 예상된다.

Digital Foundry의 이어지는 테스트 결과에서는 조금 다른 설정을 사용한 결과를 보여준다. 여기서 재미있는 숫자가 나타난다.

Platform

Stadia

Project Stream

'15 mbps'

PC 30fps

PC 60fps

Xbox One X

Latency

166ms

188ms

112ms

79ms

145ms

source: https://youtu.be/VG06H7IQ9Aw?t=776

다른 결과는 비슷하지만 Project Stream의 테스트 조건이 15mbps로 변경되었다. 그리고 변경된 Project Stream의 Latency는 188ms로 이전 테스트의 179ms보다 증가한 것을 볼 수 있다. 15mbps는 인코딩된 비디오 스트리밍의 비트레이트를 의미한다. 비디오 인코딩에서 비트레이트를 높일 경우 높은 품질의 영상을 얻을 수 있지만 데이터의 양이 증가한다. 반면 비트레이트를 낮추면 영상의 품질이 떨어지지만 데이터의 양이 감소하게 된다. 예전 512KB의 MP3 파일과 128KB의 MP3 파일의 음질 차이와 같은 현상이 비디오에서도 나타나는 것이다. 두 번째 테스트에서 15mbps를 적용하였을 때 퍼포먼스가 더 저하되었다는 점에서 첫 번째 테스트의 Project Stream은 15mps이하의 비트레이트를 사용하였다는 것을 유추할 수 있다. Stadia는 수치가 그대로인 것으로 보아 첫 번째 테스트와 두 번째 테스트 모두 동일한 비트레이트를 사용했고 이는 15mbps보다 낮을 것이라 예상된다.

구글은 Stadia의 출시 시점에 4K 60FPS를 적용하고 추후 8K로 확장할 것이라 언급했다. 그런데 게임 화면의 변화 정도에 따라 조금 달라지기는 하겠지만, 15mbps의 비트레이트는 4K 화면을 깨끗하게 전송하기에는 조금 모자란 수치이다. H.264를 사용한다고 가정했을 때, QHD급의 화면을 15mbps로 인코딩하면, 게임 화면의 디테일한 부분이 깨지는 것을 육안으로 관찰할 수 있다. QHD의 2배에 해당하는 4K 화면에서는 15mbps 인코딩에서 더더욱 화면이 깨질 것이다. 하물며 8K에서는 뭉개짐의 수준이 더욱 올라갈 것이다. 4K 해상도를 전달하기 위해서는 최소 20mbps이상의 비트레이트가 적절하고, 8K라면 30~50mbps 까지 필요 수준이 올라갈 가능성도 있다. 향상된 비트레이트는 Stadia의 Latency를 더욱 끌어올릴 것이 자명하다는 점에서 Stadia의 8K 지원이 부풀려진 것임을 짐작할 수 있다. PC 게임 조차도 대부분 FHD를 사용하고 4K게임이 이제 늘어나고 있는 추세인데 8K게임은 조금 더 먼 미래의 일로 생각된다.

GDC에서 구글이 시연한 어새신 크리드의 동작을 보면 시연임을 감안해도 괜찮은 수준인데, 아마도 구글이 인코딩 시점에 4K화면을 그대로 사용하지 않고 더 낮은 해상도로 변환하여 스트리밍했을 가능성이 높아 보인다. 실제 안드로이드 기기들도 모니터에 비해 작은 화면을 가지고 있기에 4K 컨텐츠를 재생할 때 이미지 버퍼를 더 작은 버퍼로 줄여서 사용하는 것이 일반적이다. 즉, 컨텐츠가 아무리 4K여도 실제 렌더링은 무늬만 4K인 것이 현실이기에 스트리밍 해상도 변환이 큰 문제는 아니다. 하지만 이런 상황에서 4K 60 FPS를 Stadia의 성능 지표로 내세우는 것은 너무 과장이 심한 것으로 판단된다.

Ecosystem

Stadia는 여러 가지 새로운 Feature들을 소개하였는데 이를 활용하기 위해서는 기존의 게임을 수정하거나 새로운 게임을 제작해야 한다. 대부분의 스트리밍 게임 서비스가 기존의 게임을 수정하지 않고 스트리밍으로 제공하는데 중점을 두는 것과는 사뭇 다른 방향이다. 개발사 입장에서는 Stadia 전용 게임 개발에 대한 비용이 발생할 수 밖에 없기에, 구글 입장에서 개발사들이 Stadia 게임을 개발하도록 유도하는 과정에 상당한 초기 비용이 들어갈 것이다. 구글은 게임 개발사들이 Stadia에 게임을 내도록 유도해야 하는 숙제를 가지고 있다. 게임 개발 생태계를 지원하기 위해 구글은 다양한 지원을 발표했다.

Game Engine

현대의 게임 개발은 자체적인 게임 엔진을 보유한 대형 개발사를 제외하면 대부분 범용 게임 엔진을 사용해 이루어진다. 최근의 게임 엔진들은 다양한 기능을 쉽게 사용할 수 있도록 제공하고, 그래픽 인터페이스와 스크립트를 통한 게임 개발을 원활하게 지원한다. 게임 엔진을 활용하면 게임 개발자가 여러 골치아픈 상황을 생각하지 않고 게임 로직을 개발하는데 집중할 수 있다는 장점이 있다. 구글은 이를 의식하여 범용 게임엔진과 협력하여 Stadia용 게임 개발을 지원하려 하고 있다.

유니티는 현재 세계적으로 가장 많이 쓰이고 있는 게임 엔진이다. 초기에는 인디게임을 위한 게임엔진 정도로 인식되었지만, 안드로이드와 ios같은 신규 플랫폼에 빠르게 적응하면서 점유율을 끌어올렸고, 현재 모바일 게임 개발에서는 독보적인 점유율을 유지하고 있다. 또 플랫폼 확장에 가장 관심이 많은 게임엔진으로 유니티로 개발한 게임을 아주 다양한 플랫폼으로 출시할 수 있는 강점을 가지고 있다. 구글도 가장 먼저 유니티를 협력 대상 게임엔진으로 소개하였다.

언리얼은 PC게임에서 가장 잘 알려지고 뛰어난 그래픽 표현이 가능한 게임 엔진이다. 리니지2를 포함한 MMOPRG의 대부분이 언리얼을 사용했을 정도로 언리얼의 그래픽 성능은 정평이 나 있다. 그러나 모바일 시장에 대한 적응이 조금 느렸던 언리얼은 경쟁상대로 생각지도 않았던 유니티에 주도권을 많이 내주게 되었다. 그래도 여전히 최고급의 게임 엔진으로 자리잡고 있는 언리얼을 구글은 두 번째 협력 대상 게임엔진으로 소개했다.

하복은 게임엔진 제품도 가지고 있지만, 게임엔진의 일부인 물리엔진으로 더욱 유명하다. 물리엔진은 게임 내에 등장하는 물체의 움직임과 충돌을 처리하는 기능을 수행한다. 이는 게임의 상당히 중요한 요소로 하복은 물리엔진 중 가장 유명한 엔진이다. 2015년 마이크로소프트가 인수했을 정도로 기술력을 인정받았으며 DirectX 12 버전에 통합되어 제공될 예정이라고 한다. 구글은 Stadia 게임 개발에 하복을 사용할 수 있다고 소개했다.

Game Studio

구글은 Games and Entertainment라는 1st Party 게임 개발 스튜디오를 만들것이라 발표했다. 실제로 일본 등지에서 게임 PD를 리쿠르트하고 있으며 게임 스튜디오 구성에 필요한 인력들을 채용하는 중에 있다. 1st Party 스튜디오는 여러 가지 역할을 수행할 수 있지만, 가장 중요한 역할은 소속 플랫폼을 위한 뛰어난 독점 게임을 만드는 것이다. 타 플랫폼에서는 플레이할 수 없는 독자적인 게임을 제공하여 사용자들을 lock-in하는 것이 가장 큰 존재의 이유이다. 또한 소속 플랫폼의 기능을 충분히 활용하는 게임을 선제적으로 만들어 여타 3rd Party 개발사들이 플랫폼의 기능을 충분히 활용할 수 있도록 지원하는 역할도 가지고 있다.

1st Party 스튜디오의 가장 좋은 예제는 닌텐도이다. 수퍼마리오나 젤다와 같은 닌텐도의 자체 제작 타이틀들은 닌텐도 게임기 판매의 일등 공신 역할을 하고 있다. 실제로 닌텐도 스위치가 처음 등장했을 때 게이머들은 닌텐도 스위치에서 플레이 가능한 게임이 얼마 없는 상황에서도 오로지 젤다를 플레이하기 위해 닌텐도 스위치를 구매하는 현상을 보여주었다.

Games and Entertainment도 닌텐도와 유사한 역할을 수행할 것으로 예상된다. Entertainment가 붙어있는 점은 게임 외에 영화 컨텐츠도 가지고 있는 소니의 경우를 의식한 것으로 유추된다.

Stadia Partners

Stadia는 1st Party이외에도 3rd Party 게임 스튜디오를 참여시키기 위한 계획을 발표하였는데 Stadia Partners가 그것이다. 게임 스튜디오들은 Stadia Partner를 통해서 개발에 필요한 지원을 얻을 수 있을 것으로 보인다. Stadia가 기존과는 다른 신규 기능들을 많이 소개하고 있기 때문에 전통적인 게임 개발과 비교해 더 많은 초기 지원이 필요할 것으로 예상된다.

Stadia.dev

구글은 개발자 지원을 위해 https://stadia.dev를 소개했다. GDC를 통해 소개된 Stadia의 기능들에 대한 설명을 찾을 수 있으며, Stadia 개발자로 등록할 수 있다. 실제 등록 버튼을 눌러보면 신상 정보 이외에 소속된 회사의 Tax ID를 입력해야 개발자 등록이 가능한 것을 알 수 있다. Tax ID는 미국 회사일 경우에만 해당되는 항목이기는 하지만 이외에도 회사의 형태나 주소, 대표 연락처 등을 기재해야 개발자 등록이 가능하다. 일반적인 구글의 개발자 등록에 비해 상당히 과도한 정보를 요구하고 있는데, 이는 구글이 Stadia에 입점할 게임의 수준을 어느 정도 컨트롤하려는 의도로 보인다.

Future

GDC의 Stadia 발표에서 구글이 하고 싶은 것이 단순히 기존 게임을 스트리밍하는 서비스를 통해 수익을 얻는 모델이 아닌 신규 게임 플랫폼 홀더로서 위치를 차지하기 위한 것임을 유추할 수 있다. 소니, 마이크로소프트, 닌텐도 등 기존 게임 플랫폼 홀더들과 동일선상에서 경쟁하려는 것이 그 목적이다. 그 판단 근거는 다음과 같다.

Stadia 서버에 대한 대규모 투자: AMD 협력, 서버 생산, 지역별 데이터센터 구축, 전용망 대역폭 확보
게임 툴 업체와의 협력 비용: Unity, Unreal, Havok, Cryengine, etc.
Stadia 신규 인력 채용 규모
Stadia Games and Entertainment 설립 비용

구글은 상당한 스펙의 Stadia 서버를 발표했고, 심지어 하나의 게임 구동을 위해 여러 대의 인스턴스를 활용하겠다고 발표했다. 또한 전용망을 통한 서버 연결을 말했고, 지역별로 데이터센터를 구축하고 있음을 시사했다. 사실 이 비용은 적은 투자가 아니다. 마이크로소프트나 소니도 비용 문제로 게임 스트리밍 서비스에 대한 고민이 많은 상태이다.

고상한 표현으로 협력이라고 발표했지만 AMD와 같은 하드웨어 업체는 물론이고, 게임 업계의 특성상 게임 관련 협력업체들이 신규 플랫폼 지원에 대한 NRE를 요구했을 가능성이 크다. 구글은 이 모든 비용을 감수하고 초기 협력 개발을 진행하였을 것이다. 게임엔진 업체 협력만 해도 몇백만불 이상의 비용이 들지 않았을까 예상이 된다.

현재 Stadia 관련 인력의 대규모 채용이 이루어지고 있다. Linkedin에서 Stadia 키워드로 검색만 해도 지역별로 Stadia 관련 구인이 활발히 이루어지고 있음을 확인할 수 있다. 이 정도의 신규 인력을 채용하는 것은 그만큼 구글이 생각하는 사업의 범위가 크다는 점을 대변한다.

무엇보다도 Games and Entertainment의 설립은 작정하고 소니, 마이크로소프트, 닌텐도와 경쟁을 하겠다는 의중을 명확히 드러내는 것이다. 물리적인 게임기를 판매하지 않을 뿐, 나머지 모델은 전통적인 게임 플랫폼 홀더들의 그것과 전혀 다르지 않기 때문이다.

구글은 그동안 플레이 스토어를 운영하면서 메신저에 이어 두 번째로 사용시간이 많은 게임 카테고리, 그리고 게임앱에서 나오는 수익 규모에 대해 어떤 회사보다 더 잘 알게 되었을 것이다. 그리고 이러한 배경지식은 당연히 게임 사업 진출 검토로 이어졌을 것이다. 그렇다면 과연 구글의 이러한 도전은 성공할 수 있을지 궁금해진다. 그간 구글은 많은 서비스를 런칭하였고, 그 중에는 성공한 서비스도 있었지만 결국 역사의 뒤안길로 사라진 서비스도 많이 있었기 때문이다. 투자의 규모로 보아 초기 유투브를 훌쩍 뛰어넘을 수도 있는 구글의 도전과 그 가능성에 대해 생각해 보자.

우선 Stadia의 강점이 무엇일까. GDC에서 많은 기능을 소개했지만 사실 대부분의 기능은 게임의 본질과 상관이 없는 것들이다. 구글이 게임 생태계에 대한 이해가 떨어진다는 점만 노출된 것이다. 스치듯이 소개된 Realtime Rigidbody Physics 정도가 게임의 퀄리티를 끌어올릴 수 있는 기능인데, 이 기능 역시 클라우드 서버 비용에 상당한 무리를 주는 것이기 때문에 ROI가 나올지 의심스럽다. 뛰어난 스펙이라고 소개된 단일 하드웨어의 성능이나 전용 네트워크, 전용 컨트롤러 등도 기존 클라우드 게임과 비교했을 때 어느 정도 그 강점이 있는 것이지 콘솔 게임과 비교하면 대부분 단점으로 전락한다.

결국 서두에 소개된 Cross Platform이 가장 큰 장점으로 귀결 된다. 물리적인 콘솔이 필요없다는 점은 Stadia의 가장 큰 장점으로 작용할 것이다. 보통 게임 콘솔의 비용은 300불에서 400불 사이로 결정되는데, 이 정도 가격은 코어 게이머가 아닌 계층에게는 선뜻 투자하기 어려운 정도의 비용이다. 이 비용을 없애는 것은 기존 코어 게이머가 아닌 사용자들을 게이머로 유치하는데 가장 큰 동인으로 작용할 수 있다. 물론 원활한 게임을 위해서는 Stadia 전용 컨트롤러 정도는 구매를 해야겠지만 이 경우에도 진입 장벽은 30~50불 정도로 낮아질 것이기에 기존 콘솔 게임과 비교해서 확실한 차이를 가져갈 수 있다.

그렇다면 Stadia의 약점은 무엇인가. 아이러니하게도 Cross Platform이 가장 큰 약점이 될 수 있다. 사용자가 몰리면 몰릴수록 수익이 상승하는 콘솔 게임과 달리 스트리밍의 경우는 늘어나는 사용자와 사용량에 따라 클라우드 서버 비용과 트래픽 비용 상승으로 수익의 상승폭이 상대적으로 낮을 수밖에 없다. 결국 콘솔게임 이상의 수익을 내기 위해서는 콘솔게임과 비교해 훨씬 더 많은 사용자를 유치해야 한다는 장벽을 극복해야 한다.

2018년 플레이스테이션 4의 판매 대수는 1800만대 정도이고, Xbox는 600만대, 닌텐도 스위치는 1700만대 정도이다. 2018년 초반까지의 누적판매량은 플레이스테이션 4의 경우 7600만대에 이르고, Xbox도 3500만대 수준이다. 게임 콘솔의 구매자가 전시 용도로 구매를 하는 경우는 없으니 게임 콘솔의 판매 대수의 상당수가 액티브 유저로 간주될 수 있을 것이다. 액티브 유저를 판매량의 50%로 보수적으로 잡더라도 플레이스테이션의 경우 3800만명이 된다. PC 게임에서 가장 유명한 플랫폼인 밸브 스팀의 경우도 가입된 사용자는 1억명이 넘는 것으로 파악되고 있고, 동시접속자는 1300만명에 이른다. 서비스 측면에서 바라보면 이것은 실로 어마어마한 숫자이다. 구글이 뛰어넘어야 할 상대는 바로 이들이다.

사실 게임 플랫폼의 성패를 가르는 것은 게임 타이틀이다. 그렇기에 게임 플랫폼 홀더들은 자신의 플랫폼에 익스클루시브한 타이틀을 가져가는데 큰 힘을 기울인다. 콘솔 초기 닌텐도가 지배하던 세상을 플레이스테이션이 뒤집을 수 있었던 것도 게임기의 성능이 아닌 파이널판타지, 진삼국무쌍과 같은 독점 타이틀의 힘이었다. 게임기 성능으로는 가장 떨어지는 닌텐도 스위치가 소니나 마이크로소프트와 대등하게 경쟁할 수있는 것도 젤다, 마리오, 포겟몬 같은 독점 타이틀의 힘이다. Xbox 역시 한 때 Halo 전용 머신이라고 불리기도 했던 역사를 가지고 있다. PC 게임 플랫폼의 왕좌를 차지하고 있는 스팀에서도 가장 사용율이 높은 게임은 자체 개발한 Dota2이다. 블리자드는 겨우 8개 정도의 타이틀을 가지고 독자적인 게임 플랫폼을 운영하고 있다. 이것이 가능한 이유는 그 8개의 게임이 스타크래프트, 월드오브워크래프트, 디아블로, 오버워치 처럼 하나같이 전설적인 타이틀이기 때문이다.

Stadia가 성공하는 길도 간단하다. 스트리밍이나 크로스 플랫폼이 중요한 것이 아니다. Stadia에서만 플레이 가능한 전설적인 타이틀을 확보하는 것이 그것이다. 무수한 3rd Party 에코가 필요한 것도, 킬러 타이틀이 수십개씩 있어야 하는 것도 아니다. 위에 열거한 게임들과 어깨를 나란히 할 수 있는 2~3개의 타이틀만 있어도 사용자는 Stadia에 유입될 것이다. 게이머들 중 구매력이 가장 큰 코어 게이머들은 인디게임 수백개를 공급한다 해도 꿈쩍하지 않겠지만, 한 두 개의 AAA 타이틀이 있다면 기꺼이 지갑을 열 것이다. 그리고 이렇게 되면 게임 개발사들이 알아서 Stadia에 참여할 것이고 에코는 자연스럽게 형성될 것이다.

Stadia가 광고한대로 수십개의 GPU를 연결해 기존 게임기에서 꿈도 꾸지 못했던 규모의 게임 타이틀을 제작하고 거기에 게임성을 확보한다면 Stadia는 성공할 수 있을 것이고, 미래의 게임 플랫폼이 될 수 있을 것이다. Games and Entertainment를 설립한 것으로 보아 구글도 어느 정도 1st Party의 필요성을 인지하고 있는 것 같아 희망적이지만, 게임성과는 전혀 무관한 기능들을 대표 기능으로 소개한 것을 보면 상당히 좌절스럽다. 솔직한 감상으로는 Stadia는 별의 커비 수준의 게임도 만들지 못할 것 같다. 온통 성능과 기능 관점의 소개를 그것도 부풀려진 수치로 하는 행태는 기술 회사의 그것이지 컨텐츠에 목숨을 거는 게임 회사의 자세는 아니기 때문이다.

Stadia의 성공에는 또 하나의 가정이 필요하다. 기존 게임 플랫폼 강자인 소니, 마이크로소프트, 밸브, 블리자드, 오리진 등의 경쟁사가 Stadia와 유사한 형태의 게임 스트리밍 서비스를 하지 않아야 한다. 그러나 안타깝게도 소니는 이미 상당 기간 스트리밍 서비스를 해왔고 스트리밍 관련 회사를 인수하는 등 스트리밍에 대한 지속적인 투자를 해오고 있었다. 소니가 인수한 Gaikai는 인수 당시를 기준으로 업계에서 가장 뛰어난 수준의 스트리밍 기술을 확보하고 있었다. 밸브는 SteamLink라는 독자적인 게임 스트리밍 기능을 가지고 있다. 이 기술을 사용해서 거의 최초로 4K 스트리밍을 시연했을 정도로 뛰어난 기술력을 자랑한다. 최근에는 로컬 네트워크에서만 작동하던 SteamLink를 퍼블릭 네트워크에서 사용할 수 있는 기능을 선보였다. 블리자드는 스타크래프트를 런칭한 90년대부터 최고의 네트워크 기술을 보유하고 있었다. 당시로서는 획기적인 IPX 프로토콜을 선보였고, 엄청난 동시접속자를 자랑하는 배틀넷을 오랜 기간 운영해 오고 있다. 블리자드가 스트리밍에 뛰어든다면 최적화된 그래픽과 네트워크 성능을 결합한 솔루션을 선보일 수 있을 것이다.

그러나 스트리밍에서 가장 위협적인 Stadia의 경쟁 상대는 바로 마이크로소프트이다. 타 경쟁 업체는 구글이 GDC에서 선보인 다양한 기술적인 요소들 중 일부분을 가지고 있거나 없는 기술이 있을 수 있다. 그러나 기술의 마이크로소프트는 구글이 선보인 모든 기술 스택을 더 뛰어난 수준으로 확보하고 있다. DirectX와 Vulkan를 비교하면 DirectX의 낙승이다. 구글이 반복적으로 자랑한 AMD와 협업을 통한 다중 CPU/GPU 활용 역시 마이크로소프트는 업계 최고인 Nvidia와 협업하고 있으며, 특히 가상화는 구글이 Azure를 뛰어넘기가 매우 힘들 것이다. 마이크로소프트의 네트워크 기술 역시 오픈 소스 스택을 기반으로 하고 있을 Stadia의 프로토콜 수준보다 떨어지리라고 예상하기는 어렵다. 이러한 기술적 우위에 더해 마이크로소프트는 게임 생태계에 대한 충분한 이해를 가지고 있다. 최근에는 플레이스테이션에 밀리고 있지만, 초창기 비웃음 속에 런칭한 엑스박스를 한 때 소니를 위협할 정도로 성공적인 게임 플랫폼으로 구축한 마이크로소프트의 저력은 절대 무시할 수 없다. Stadia가 GPU 30개를 활용한 엄청난 대작 게임을 선보였다고 가정해 보자. 마이크로소프트는 Azure 기반으로 같은 형태의 게임을 더 뛰어난 성능으로 충분히 런칭할 수 있으며, 그 게임에는 게이머들을 열광시킬 Halo의 캐릭터들이 등장할 것이다.

설상가상으로 마이크로소프트는 공식블로그를 통해 엑스박스 게임을 모바일 기기로 스트리밍할 수 있는 Project xCloud를 곧 선보일 것이라고 발표했다. 4개의 인스턴스가 결합된 블레이드 서버를 소개하고 있으며 Azure가 지원되는 54개국을 대상으로 삼는다고 한다. 그 54개국 안에는 큰 규모의 게임 시장을 가진 지역은 전부 포함되어 있다. 2020년 런칭을 준비한다고 하니, 이번 Stadia의 발표를 보고 그것을 뛰어넘는 기능들을 준비할 가능성이 높다. 마이크로소프트는 그럴만한 기술력과 자본력을 가지고 있고, 이미 전세계에 운영 중인 Azuere 데이터센터들을 보유하고 있다. Stadia의 가장 강력한 경쟁상대가 이미 워밍업 단계를 끝내고 있는 것이다.

구글이 클라우드 게임의 태생적인 성능 한계와 고비용을 극복하고 기존 게임 플랫폼의 강자들을 뛰어넘어 Stadia를 성공시킬 수 있을지 지켜보는 것은 상당히 흥미로운 관전 포인트가 될 것이다. Stadia는 게임의 미래가 될 것인가 아니면 또 하나의 거대한 서비스 실패 사례가 될 것인가 궁금한 부분이 아닐 수 없다.

Fin.

'Analysis' 카테고리의 다른 글

Google Stadia 분석: Ecosystem(생태계)편 (0)	2019.05.10
Google Stadia 분석: Performance(성능)편 (0)	2019.05.10
Google Stadia 분석: Specification(사양)편 (0)	2019.05.10
Google Stadia 분석: Features(기능)편 (0)	2019.05.10

ABOUT ME