Amazon GameLift Streams로 여는 클라우드 게이밍 시대: 클라이언트 설치 없이 게임 즐기기

들어가며

게임은 점점 더 화려한 그래픽과 풍부한 콘텐츠로 무장하며 진화하고 있습니다. 그러나 역설적이게도, 게임에 도달하기까지의 여정 또한 점점 길어지고 있습니다. 수십 GB에 달하는 다운로드와 긴 설치 과정, 그리고 고사양 그래픽 카드 요구라는 관문이, 정작 게임의 가치를 경험하기도 전에 잠재 유저를 돌려보내고 있는 것입니다.

게임·미디어 산업 분석가이자 베스트셀러 『The Metaverse』의 저자인 Matthew Ball은 2026년 초 발표한 게임 산업 트렌드 리포트에서 게임 성숙 시장이 ‘관심 경쟁(War for Attention)’에서 밀리고 있다고 분석합니다. 수십 GB 다운로드, 고사양 하드웨어 요구, 긴 설치 시간 등 진입 마찰이 클수록 게임은 숏폼 영상·소셜미디어와의 시간 쟁탈전에서 구조적으로 불리합니다. 예를 들어 유저가 광고나 스트리머의 추천으로 게임에 흥미를 느껴도, “50GB 다운로드 → 설치 → 최초 실행 시 셰이더 컴파일”이라는 수십 분의 대기를 마주하는 순간 상당수의 유저는 이탈합니다. 즉 첫 플레이까지의 시간이 짧을 수록 신규 유저 확보에 유리합니다.

이러한 과제를 해결하기 위해 설계된 서비스가 Amazon GameLift Streams입니다. 유저가 링크를 여는 순간, 다운로드나 설치 없이 브라우저에서 곧바로 게임이 시작됩니다. 유저의 게임 진입을 방해하는 허들을 제거해, 광고나 추천으로 유입된 유저를 첫 플레이까지 놓치지 않고 데려갈 수 있습니다.

이 글에서 다루는 내용

이 글은 Amazon GameLift Streams를 처음 접하는 개발자, 설계자를 대상으로, 개념 이해부터 실제 구축·운영까지의 흐름을 살펴봅니다. 구체적으로는 (1) 클라우드 게임 스트리밍에 필요한 기술 요소와 그 구성의 어려움, (2) Amazon GameLift Streams가 이 어려움을 어떻게 관리형 서비스로 해결하는지, (3) 세 가지 핵심 리소스(애플리케이션, 스트림 그룹, 스트림 세션)로 구성되는 아키텍처, (4) 런타임, 스트림 클래스, 용량(Capacity), 다중 위치/다중 애플리케이션 등 설계 시 선택해야 할 요소와 통합 선택 가이드, 그리고 (5) 실제 스트리밍 환경을 구축하는 실습과 운영 단계의 관측성(Observability)까지 순서대로 살펴봅니다.

게임 스트리밍에는 어떤 기술이 필요한가

클라우드 게임 스트리밍 서비스를 구축하기 위해서 개발자는 많은 기술 요소를 손수 구현해야 한다는 것을 알 수 있습니다.

먼저 게임을 실제로 렌더링할 GPU 서버가 필요합니다. 최신 게임을 원활히 구동하려면 고성능 GPU 인스턴스를 확보하고, 게임 빌드와 그래픽 드라이버, 런타임 환경을 일일이 설치·구성해야 합니다. 다음으로는 렌더링된 화면을 유저에게 실시간으로 전달할 저지연 스트리밍 파이프라인이 필요합니다. 게임 화면을 비디오로 인코딩하고, 유저의 키보드·마우스·게임패드 입력을 다시 서버로 되돌려 보내는 양방향 통신을 수십 밀리초(ms) 수준의 지연으로 처리해야 하는데, 이때 사실상 표준으로 쓰이는 기술이 바로 뒤에서 설명할 WebRTC(Web Real-Time Communication)입니다.

여기서 끝이 아닙니다. 전 세계 유저에게 서비스하려면 여러 리전에 인프라를 배치하고 가까운 위치로 연결을 라우팅해야 하며, 접속자가 몰릴 때와 한산할 때에 맞춰 GPU 용량을 자동으로 늘리고 줄이는 스케일링도 직접 구현해야 합니다. 유휴 GPU를 방치하면 불필요한 비용이 발생하고, 반대로 용량이 부족하면 유저가 접속하지 못합니다.

정리하면, 클라우드 게임 스트리밍을 자체 구축하려면 GPU 인프라 관리, WebRTC 시그널링/미디어 파이프라인, 글로벌 배포, 용량 오토스케일링, 세션 수명 주기 관리를 모두 직접 다뤄야 합니다. 이는 게임 자체의 재미를 만드는 일과는 거리가 먼 곳에 상당한 개발 리소스를 쏟아야 한다는 뜻입니다. Amazon GameLift Streams는 바로 이 허들 전체를 관리형 서비스로 대신 처리하는 것을 목표로 합니다.

Amazon GameLift Streams란?

Amazon GameLift Streams는 AWS 인프라에서 게임을 렌더링하고 그 영상을 유저 디바이스로 전송하는 완전관리형(fully managed) 클라우드 게임 스트리밍 서비스입니다. 앞에서 살펴본 기술 허들을 서비스가 대신 처리하므로, 게임사는 인프라 구성이 아니라 게임 자체에 집중할 수 있습니다.

이 서비스만의 강점은 기존 게임 빌드를 코드 수정 거의 없이 완전관리형 클라우드 GPU 인스턴스에 올려 몇 분 만에 스트리밍을 시작할 수 있다는 점입니다. 렌더링된 게임 영상은 AWS 백본 네트워크를 통해 플레이어에게 직접 전달되는데, 이 전용 백본 경유가 지연 최소화의 물리적 기반입니다.

직접 구축한다면 수 주에서 수 개월이 걸렸을 인프라 작업이, 이 관리형 서비스를 사용하면 게임 빌드 업로드와 몇 번의 설정만으로 대체됩니다.

스트리밍 프로토콜: WebRTC(Web Real-Time Communication)

Amazon GameLift Streams는 게임 스트리밍에 필요한 저지연 양방향 통신을 WebRTC로 처리합니다.

WebRTC란?

WebRTC(Web Real-Time Communication)는 브라우저나 모바일 앱 등 두 피어(peer) 간에 별도의 플러그인이나 중간 릴레이 서버 없이 오디오, 비디오, 임의의 데이터를 실시간으로 주고받게 해주는 오픈소스 기술입니다. 중간 서버를 거치지 않는 피어 간 직접 연결로 수십 ms 수준의 낮은 지연을 달성할 수 있어, 실시간성이 생명인 화상회의, 라이브 스트리밍 분야에서 사실상 표준처럼 쓰입니다.

Amazon GameLift Streams에서의 WebRTC

Amazon GameLift Streams는 클라이언트가 스트림 세션에 연결할 때 WebRTC를 기반 프로토콜로 사용합니다. 추가 플러그인 없이 브라우저에서 직접 스트리밍이 가능한 이 프로토콜의 특징을 활용해, 키보드·마우스·게임패드 상호작용을 포함한 다양한 입력 방법을 지원합니다.

구체적으로는 화면을 내보내는 채널과 입력을 받아들이는 채널이 서로 반대 방향으로 동작합니다. 서버 측에서 렌더링된 게임 화면은 WebRTC의 비디오 스트림으로 인코딩되어 클라이언트에 저지연으로 전송되고(서버 → 클라이언트), 사용자의 키보드·마우스·터치 입력은 DataChannel을 통해 서버로 전달됩니다(클라이언트 → 서버).

리소스 모델

Amazon GameLift Streams는 세 가지 리소스와 그 관계를 중심으로 구성됩니다. 다음 다이어그램은 세 리소스(애플리케이션, 스트림 그룹, 스트림 세션)가 어떻게 연결되는지를 한눈에 보여줍니다.

애플리케이션(Application)

애플리케이션은 Amazon GameLift Streams에서 “무엇을, 어떤 OS에서, 어떤 진입점으로 실행할 것인가”를 정의하는 리소스로, Amazon Simple Storage Service(Amazon S3)에서 가져온 게임 빌드의 사본 + 런타임 환경 + 실행 파일 경로를 지정하는 메타데이터의 조합입니다.

애플리케이션의 구성 요소는 다음 표와 같습니다.

스트림 그룹(Stream Group)

애플리케이션을 스트리밍하기 위한 컴퓨팅 리소스 풀로, 생성 시 스트림 클래스(GPU 하드웨어)와 용량을 지정하며, 복수의 애플리케이션을 연결할 수 있습니다.

스트림 세션(Stream Session)

스트림 세션은 Amazon GameLift Streams가 서버에서 최종 사용자에게 전송하는 스트림의 인스턴스로, 스트림 그룹이 할당한 컴퓨팅 리소스 위에서 실행됩니다. 간단히 “스트림”이라고도 부릅니다.

이 세 리소스의 관계를 한 문장으로 요약하면, 여러 애플리케이션을 하나의 스트림 그룹에 연결(N:1)하고, 각 스트림 그룹이 보유한 용량 한도 내에서 다수의 스트림 세션을 동시 실행하는 구조입니다.

설계 시 선택해야 할 요소들

여기서는 Amazon GameLift Streams로 서비스를 설계할 때 결정해야 하는 요소들을 하나씩 살펴봅니다. 순서는 런타임(OS) → 스트림 클래스(하드웨어) → 용량(Capacity)과 스케일링 → 다중 위치/다중 애플리케이션 순이며, 각 요소를 개별적으로 설명한 뒤 마지막에 이들을 하나로 묶는 통합 선택 가이드를 알아보겠습니다.

런타임 환경 비교

Amazon GameLift Streams는 클라우드 게임 스트리밍을 위해 세 가지 런타임 환경을 제공합니다. 각 환경은 고유한 특징을 가지고 있어, 게임의 특성과 요구사항에 따라 선택이 달라집니다.

Windows 런타임은 Windows Server 2022 Base를 기반으로 하며, DirectX 12/11을 네이티브로 지원합니다. Windows 전용 게임이나 안티치트(anti-cheat) 솔루션이 필수인 게임에 적합합니다. 마이크와 게임패드 입력을 모두 지원하며, 안티치트를 지원하는 유일한 런타임입니다. 그러나 멀티 테넌시(multi-tenancy)를 지원하지 않아 하나의 인스턴스에서 하나의 세션만 실행할 수 있고, Windows 라이선스 비용까지 스트림 요금에 포함되어 있어 Linux, Proton 런타임에 비해 비용 효율이 낮습니다.

Proton 런타임은 Linux 기반 위에 Valve의 Proton 호환 레이어를 얹은 환경으로, Steam Deck 이나 Steam Machine에서 사용되는 것과 동일한 기술입니다. 가장 큰 장점은 멀티 테넌시를 지원하여 하나의 GPU에서 복수의 스트림 세션을 동시에 실행할 수 있다는 점이며, 이를 통해 인프라 비용을 크게 절감할 수 있습니다. Linux 런타임과 마찬가지로 OS 라이선스 비용이 발생하지 않으며, VKD3D와 DXVK 변환 레이어를 통해 DirectX 11 및 DirectX 12를 모두 지원합니다. 마이크와 게임패드 입력도 지원되어 다양한 게임에 활용할 수 있습니다. 현재 Proton 10.0-4, 9.0-2, 8.0-5, 8.0-2c 버전을 지원합니다.

Linux 런타임은 Ubuntu 22.04 LTS를 기반으로 하며, Vulkan 그래픽 API를 네이티브로 지원합니다. 멀티 테넌시를 지원하고 OS 라이선스 비용이 없어 비용 효율적입니다. 그러나 현재 마이크와 게임패드 입력이 지원되지 않으며, 안티치트 역시 미지원입니다. Vulkan으로 네이티브 개발된 게임이나 입력 장치가 필수적이지 않은 애플리케이션에 적합합니다.

세 런타임의 특성을 다음 표로 정리했습니다.

런타임 선택 가이드

런타임 선택은 게임 빌드가 어떤 플랫폼용 인지에서 출발합니다. 먼저 게임이 Windows용 빌드인지 Linux(Vulkan 네이티브)용 빌드인지 확인합니다. Linux용이라면 Linux 런타임을 사용합니다. Windows용이라면, DirectX 12 네이티브 지원이나 안티치트가 필수인지 따져봅니다. 필수라면 Windows 런타임으로 확정하고, 그렇지 않다면 Proton 런타임을 검토합니다. Proton은 멀티 테넌시로 하나의 GPU를 여러 세션이 공유할 수 있어, 호환성 테스트만 통과하면 가장 비용 효율적인 선택입니다. 다만 통과하지 못하면 Windows 런타임을 사용합니다. 빠른 출시가 우선이라면 일단 Windows 런타임으로 게임을 검증한 뒤, 대규모 서비스 단계에서 Proton으로 전환해 비용을 최적화하는 방식도 효과적입니다.

다음 다이어그램은 이 선택 흐름을 도식화한 것입니다.

Proton 호환성 테스트에 관한 내용은 Amazon GameLift Streams 개발자 가이드를 참고하세요.

스트림 클래스(Stream Class)

스트림 클래스는 CPU, GPU, RAM 등 하드웨어 리소스와 테넌시 모델(한 대의 머신에서 동시에 운영할 수 있는 스트림 수)을 함께 정의하는, 스트림 그룹의 핵심 구성 옵션입니다. 선택한 스트림 클래스가 스트리밍 품질과 비용을 결정하기 때문에, Amazon GameLift Streams를 설계할 때 가장 먼저, 그리고 가장 신중하게 선택해야 하는 부분입니다.

클래스 선정은 다음 세 단계로 나누어 생각하면 됩니다.

1. 런타임(OS): Windows Server 2022, Ubuntu 22.04 LTS, Proton 중에서 선택하며, 공유(멀티 테넌시) 옵션은 Ubuntu와 Proton 런타임에서 가능합니다.
2. GPU 세대: 얼마나 무거운 그래픽을 감당할 것인가
3. 테넌시 등급: 한 GPU를 독점할 것인가 나눠 쓸 것인가

명명 규칙 gen{세대}n_{등급}_{OS}도 이 구조를 그대로 반영합니다. 예를 들어 gen6n_ultra_win2022는 ‘6 세대 + NVIDIA(n) + ultra 등급 + Windows Server 2022’를 뜻하고, Linux, Proton용은 OS 접미사 없이 gen5n_high처럼 표기됩니다. 다만 구세대 Windows 클래스(gen5n, gen4n)는 등급 접미사 없이 gen5n_win2022, gen4n_win2022로만 제공된다는 점에 유의하세요.

테넌시 모델: 비용 구조의 핵심

테넌시는 등급 × 런타임으로 결정됩니다. 멀티 테넌시(GPU 공유)는 Linux, Proton에서만 가능하고, Windows는 모든 등급이 전용(1:1)입니다.

참고: Windows의 medium/small 클래스(gen6n_medium_win2022, gen6n_small_win2022)는 g6f 인스턴스 기반의 전용 1:1이며, 멀티 테넌시는 Linux/Proton 클래스에서만 제공됩니다.

클래스별 사양: Windows

Windows 런타임은 모든 클래스가 전용(1:1) 테넌시로 동작하므로, Linux/Proton 대비 동일 GPU에서 더 많은 리소스를 단일 세션에 할당합니다. 안티치트나 DirectX 12 네이티브가 필요한 경우 선택합니다. 사용 가능한 Windows 클래스는 다음 표와 같습니다.

클래스별 사양: Linux/Proton

다음 표는 Linux/Proton 런타임에서 사용 가능한 전체 스트림 클래스를 정리한 것입니다. 게임의 그래픽 복잡도와 목표 동시 접속 수를 기준으로 적합한 클래스를 선택합니다.

비용 격차 (실측 비교)

스트림 클래스 선택은 요금과 직결됩니다. 동일한 ultra 등급(전용 1:1)이라도 런타임에 따라 시간당 요금이 달라집니다.

동일 사양, 동일 리전에서 Linux/Proton 클래스가 Windows 대비 약 41% 저렴한 것을 확인할 수 있습니다. 여기에 더해, high·medium·small 등급에서는 Linux/Proton만 지원하는 멀티 테넌시(GPU 1대를 각각 2/4/12개 세션이 공유)로 세션당 요금을 추가로 낮출 수 있습니다. 즉 비용 최적화는 (1) OS 라이선스가 없는 Linux/Proton 선택, (2) 워크로드가 허용하면 멀티 테넌시 등급 활용 순으로 고려할 수 있습니다.

위 요금은 블로그 작성 시점 기준이며, 실제 요금은 Amazon GameLift Streams 요금 페이지에서 확인하세요.

스트림 용량(Capacity) 설정 및 스케일링 모델

스트림 용량은 스트림 그룹이 지원할 수 있는 동시 스트림 세션 수로, 다음 세 가지 설정으로 제어합니다.

상시 가동 용량(Always-on capacity): 사용자에게 고정 할당되어 항상 유지되는 최소 스트리밍 용량을 의미합니다. 사용 여부와 관계없이 항상 이 용량에 대한 비용을 지불합니다.

목표 유휴 용량(Target-idle capacity): 향후 활동을 예상하여 서비스가 미리 할당하고 보유하는 유휴 용량입니다. 이렇게 미리 확보해 두면, 접속이 갑자기 몰려도 새 용량을 할당하며 기다리는 지연 없이 곧바로 스트림을 시작할 수 있습니다. 다만 대기만 하는 용량이라도, 확보해 둔 만큼 비용이 청구됩니다.

최대 용량(Maximum capacity): 서비스가 할당할 수 있는 최대 용량을 나타냅니다. 필요시 인스턴스를 새로 생성하기 때문에 새 스트림을 시작하는 데 몇 분 정도 걸릴 수 있으며, 유휴 상태일 때 용량이 다시 해제됩니다. 반납되기 전까지는 할당된 용량만큼 비용이 청구됩니다.

이 세 설정이 실제 트래픽에 따라 어떻게 움직이는지를 24시간 사용량으로 시뮬레이션 해보겠습니다. 시뮬레이션 조건은 다음과 같습니다.

• 상시 가동 용량(Always-On): 3세션 — 수요와 무관하게 항상 유지되는 기본사용량
• 목표 유휴 용량(Target Idle): 4세션 — 수요에 더해 미리 준비해놓는 버퍼 용량
• 하루 트래픽: 새벽 1~3세션의 한산한 시간대에서 저녁 피크 약 26세션까지 오르내리는 패턴

이 조건에서는 새벽에 수요가 낮아 Always-On 수준 부근에 머물다가, 저녁 피크 시간대에 수요가 몰리면 할당 용량이 수요를 앞질러 Target Idle 버퍼만큼 여유를 두고 확장되고, 수요가 줄면 다시 축소되는 패턴을 볼 수 있습니다.

용량 할당 우선순위 로직 {#용량-할당-우선순위-로직-1}

새 스트림 요청이 들어오면 서비스는 다음 순서로 용량을 확보합니다. 이미 확보된 유휴 용량이 있으면 수 초 내에 즉시 할당하고, 없다면 최대 용량 한도 안에서 온디맨드로 새 용량을 할당합니다. 이 흐름을 다음 다이어그램으로 정리했습니다.

축소 로직

스트림 세션이 종료되면 해당 용량은 유휴(idle) 상태로 전환됩니다. 유휴 용량이 설정된 Target Idle 값을 초과하면 일정 시간 후 초과분이 자동으로 회수됩니다. 다만, 설정된 Minimum (always-on) 값 아래로는 절대 축소되지 않으므로 최소한의 즉시 응답 가능한 용량은 항상 유지됩니다.

과금 모델

Amazon GameLift Streams는 스트림 그룹에 용량이 할당되는 순간부터 초 단위로 과금이 시작됩니다. 그렇기 때문에 비용을 절감하려면 불필요한 유휴 용량을 최소화하는 것이 중요합니다. 과금을 완전히 중단하려면 용량을 0으로 줄이거나 스트림 그룹을 삭제해야 합니다. 이 외에 콘텐츠 스토리지에 대해 GB-월 기준의 별도 요금이 발생하며, 무료 티어는 제공되지 않습니다.

리전과 게임 수로 확장하기: 다중 위치 & 다중 애플리케이션

Amazon GameLift Streams는 스트림 그룹을 더 효율적으로 운영하기 위한 두 가지 확장 구성 방식을 제공합니다.

다중 위치 스트림 그룹 (Multi-Location Stream Group)

하나의 스트림 그룹으로 여러 리전의 용량을 통합 관리하는 구성입니다. 연결된 애플리케이션이 각 위치(Location)에 자동으로 복제되므로 별도 배포가 필요 없습니다. start-stream-session 호출 시 위치 우선순위를 지정할 수 있어, 예를 들어 “서울 우선 → 도쿄 폴백” 같은 구성이 가능합니다. 또한 위치별로 Always-On/Maximum 용량을 독립적으로 설정할 수 있어 리전마다 트래픽 패턴에 맞게 최적화할 수 있습니다.

반드시 알아둬야 할 것은, Amazon GameLift Streams 서비스를 제공하는 모든 리전이 동일한 역할을 하는 것은 아니라는 점입니다. 주 위치(primary location)로 선택 가능한 리전과 원격 위치(remote location)로만 추가 가능한 리전으로 구분되며, 현재 서울 포함 총 12개 리전에서 스트리밍이 가능합니다.

• 주 위치로 선택 가능: US East(Ohio), US West(Oregon), Tokyo, Frankfurt
• 원격 위치로만 추가 가능: N. Virginia, Seoul, Mumbai, Sydney, Ireland, London, Stockholm, São Paulo 등
• 스트리밍 가능: 전체 위치

다중 애플리케이션 스트림 그룹 (Multi-Application Stream Group)

하나의 스트림 그룹에 여러 애플리케이션을 묶어 리소스를 공유하는 구성입니다. 하나의 스트림 그룹당 최대 250개 애플리케이션을 연결할 수 있고, 하나의 애플리케이션도 최대 100개의 스트림 그룹에 연결할 수 있습니다. 단, 런타임이 같은 앱끼리만 묶을 수 있습니다. 예를 들어 Windows 앱은 Windows 그룹에만 넣을 수 있습니다.

만일 50개 게임을 각각 별도 스트림 그룹으로 운영하면 유휴 용량도 50개가 필요하지만, 하나의 Multi-Application Stream Group로 묶으면 유휴 용량을 공유하므로 비용이 대폭 절감됩니다. 또한 기본 애플리케이션은 모든 Always-On 컴퓨팅 리소스에 자동으로 사전 캐싱되어 스트림 시작 시 앱 로딩 시간을 줄여줍니다. 그 외 링크된 애플리케이션도 서비스의 최적화 과정에서 캐싱될 수 있습니다.

두 구성을 한 줄로 비교하면 다음과 같습니다.

Multi-Location Stream Group과 Multi-Application Stream Group은 동시에 적용이 가능합니다. 이를 활용하면 하나의 스트림 그룹이 여러 리전에 걸쳐 있으면서 동시에 여러 앱을 호스팅할 수 있습니다.

통합 선택 가이드

앞서 살펴본 요소들(런타임, 스트림 클래스, 용량, 다중 위치/다중 애플리케이션)을 실제 설계 순서에 맞춰 하나로 이어보겠습니다.

1단계: 어떤 게임인가?(런타임 결정) 가장 먼저 게임의 런타임을 결정합니다. 먼저 “Windows용 게임이냐, Linux(Vulkan 네이티브)용 게임이냐, 그 외의 게임이냐” 를 확인합니다. 안티치트나 DirectX 12 네이티브가 필수인 Windows 게임이면 Windows 런타임으로 확정하고, Vulkan으로 개발된 게임이면 Linux, 그 외 DirectX 게임은 Proton 호환성 테스트를 거쳐 통과 시 Proton으로 결정합니다. 참고로 모바일 네이티브 게임(Android/iOS 빌드)은 현재 직접 지원하지 않으므로, PC/콘솔 빌드를 준비할 수 있는지를 먼저 확인해야 합니다.

2단계: 얼마나 무거운 게임인가?(스트림 클래스 결정) 런타임을 정했으면 그래픽 복잡도에 맞춰 GPU 세대와 등급을 고릅니다. 그래픽 집약 AAA 게임은 pro/ultra, 보통 복잡도의 3D 게임은 high/medium, 캐주얼·2D 게임은 small이 출발점입니다. 이때 Linux/Proton을 택했다면 멀티 테넌시 등급으로 세션당 단가를 낮출 여지가 생깁니다.

3단계: 언제 얼마나 많은 유저가 동시에 접속하는가?(용량 결정) 목표 동시 접속 수와 트래픽 패턴에 맞춰 Always-On/Target Idle/Maximum을 설정합니다. 상시 트래픽이 있으면 Always-On을, 피크가 예측되면 Target Idle 버퍼를 활용해 접속 지연을 방지합니다.

4단계: 어느 지역 유저에게, 몇 개의 게임을 서비스하는가?(확장 구성 결정) 여러 리전의 유저를 대상으로 하면 Multi-Location Stream Group로 글로벌 커버리지와 폴백(우선 리전이 안 되면 다른 리전이 대신 처리)을 확보하고, 여러 게임을 운영하면 Multi-Application Stream Group로 유휴 용량을 공유해 비용을 절감합니다. 이 두 구성은 함께 쓸 수 있습니다.

정리하면 “게임 성격 → 하드웨어 → 용량 → 확장”의 순으로 결정해 나가되, 각 단계에서 비용 최적화(멀티 테넌시, 유휴 용량 공유) 옵션 선택 가능 여부를 함께 검토합니다.

모바일 지원에 대하여

모바일 지원과 관련해 혼동될 수 있는 지점을 짚고 넘어가겠습니다. Amazon GameLift Streams로 서비스되는 게임을 모바일 기기로 플레이하는 것은 가능하지만, 모바일 네이티브 앱 자체를 GameLift Streams로 스트리밍하는 것은 지원하지 않습니다.

모바일 기기에서의 플레이(재생)는 지원됩니다. WebRTC는 모바일 브라우저와 모바일 앱에서 동작하므로, 스마트폰이나 태블릿에서도 별도 설치 없이 스트리밍 게임을 즐길 수 있습니다. 즉 유저의 디바이스가 모바일이어도 문제가 없습니다.

그러나 모바일 네이티브 게임 빌드(Android APK/AAB, iOS IPA)를 호스팅하는 것은 현재 지원하지 않습니다. Amazon GameLift Streams가 실행할 수 있는 것은 Windows Server 2022, Ubuntu 22.04(Linux), Proton 런타임 위에서 동작하는 PC/콘솔 계열 빌드입니다.

스트리밍 환경 구축 방법

이제 실제로 Amazon GameLift Streams로 게임을 스트리밍하는 방법을 확인해 보겠습니다. 크게 세 단계를 거치는데, 먼저 스트리밍할 게임 빌드를 애플리케이션으로 등록하고, 그 다음 실제 컴퓨팅 자원을 관리하는 스트림 그룹을 만든 뒤, 마지막으로 사용자에게 화면을 내보내는 스트림 세션을 시작합니다. 참고로 실습에는 실제 컴퓨팅 자원이 사용되어 비용이 청구됩니다. 마지막의 리소스 정리 단계를 따라 마무리하면 불필요한 과금을 막을 수 있습니다.

사전 준비 사항

실습을 시작하기 전에 다음이 준비되어 있어야 합니다.

• AWS 계정: Amazon GameLift Streams, Amazon S3, AWS Identity and Access Management (IAM)에 접근할 수 있는 권한이 있는 계정
• AWS Command Line Interface (AWS CLI): 최신 버전으로 설치하고, 사용할 자격 증명(credentials)과 기본 리전을 구성해 둡니다.
• 게임 실행 파일(빌드): 스트리밍할 게임의 실행 파일. 압축하지 않은 폴더 형태여야 하며, 대상 런타임(Windows/Linux/Proton)에 맞는 빌드를 준비합니다. (테스트용으로는 Unreal Engine의 Lyra 같은 샘플 프로젝트 빌드를 사용할 수 있습니다.)
• Amazon S3 버킷: 게임 빌드를 업로드할 버킷으로 기본값인 S3 Standard 스토리지 클래스여야 합니다.
• 서비스 사용 권한: Amazon GameLift Streams가 Amazon S3의 빌드에 접근할 수 있도록 하는 IAM 역할/권한

1단계. 애플리케이션 등록

애플리케이션은 “게임 빌드를, 어떤 OS 환경에서, 어느 실행 파일로 띄울지”를 Amazon GameLift Streams에 알려주는 것입니다. 게임 빌드 파일들을 Amazon S3 버킷에 올려둔 뒤, 그 위치와 실행 파일 경로를 지정해 애플리케이션을 만듭니다.

aws gameliftstreams create-application \
    --description "My Game Demo" \
    --runtime-environment '{"Type": "WINDOWS", "Version": "2022"}' \
    --application-source-uri "s3://example-bucket/my-game-build/" \
    --executable-path "lyra/Windows/LyraStarterGame/Binaries/Win64/LyraGame-Win64-Shipping.exe"

여기서 application-source-uri는 빌드 폴더를 올려둔 Amazon S3 위치이고, executable-path는 그 폴더를 기준으로 한 실행 파일의 상대 경로입니다. 이때 빌드 파일을 담은 Amazon S3 버킷은 반드시 기본값인 S3 Standard 스토리지 클래스여야 하며, 업로드는 압축하지 않은 폴더 형태여야 합니다. 등록 직후에는 Amazon GameLift Streams가 빌드를 내부적으로 처리하므로 상태가 Ready가 될 때까지 잠시 기다려야 합니다.

2단계. 스트림 그룹 생성

스트림 그룹은 실제 컴퓨팅 자원을 어느 지역에 얼마나 확보할지를 관리하는 리소스입니다. 앞서 만든 애플리케이션을 기본(default) 애플리케이션으로 연결하고, 스트림 품질을 결정하는 스트림 클래스와 지역별 용량을 지정합니다.

aws gameliftstreams create-stream-group \
    --description "Seoul Demo Stream Group" \
    --stream-class "gen6n_ultra_win2022" \
    --default-application-identifier "a-1234567Ab" \
    --location-configurations '[
      {
        "LocationName": "ap-northeast-2",
        "AlwaysOnCapacity": 1,
        "MaximumCapacity": 4
      }
    ]'

stream-class는 CPU/GPU/메모리 등 하드웨어 사양을 정하는 값으로, 명령어 예제에 제공한 gen6n_ultra_win2022는 NVIDIA 기반의 Windows Server 2022 ultra 등급입니다. 용량 설정에서 AlwaysOnCapacity는 항상 켜둬서 즉시 스트림을 시작할 수 있는 자원이고, MaximumCapacity는 수요에 따라 늘어날 수 있는 상한입니다. 생성한 스트림 그룹의 상태가 Active가 되면 스트리밍을 시작할 수 있습니다.

3단계. 스트림 세션 시작

마지막으로 스트림 그룹, 애플리케이션, 리전(어느 지역에서, 어떤 프로토콜로 연결할지)을 지정해 세션을 시작합니다.

aws gameliftstreams start-stream-session \
    --identifier "sg-1234567Ab" \
    --application-identifier "a-1234567Ab" \
    --protocol "WebRTC" \
    --signal-request "<ICE_OFFER_STRING>" \
    --locations '["ap-northeast-2"]' \
    --connection-timeout-seconds 120 \
    --session-length-seconds 3600

여기서 protocol은 현재 WebRTC만 지원합니다. signal-request는 직접 입력하는 임의 문자열이 아니라, 클라이언트(브라우저 등)가 WebRTC 연결을 초기화하면서 만들어내는 ICE offer 문자열입니다. 실제로는 매우 긴 JSON이며, Amazon GameLift Streams는 이에 대한 응답(answer)을 돌려주어 연결을 완성합니다. 클라이언트 측 WebRTC 연결 구현에는 Amazon GameLift Streams Web SDK를 활용할 수 있으며, SDK가 ICE offer 생성과 시그널링 과정을 추상화해 줍니다. connection-timeout-seconds는 클라이언트가 제한 시간 안에 접속하지 못하면 세션을 자동 종료하는 값이고, session-length-seconds는 세션의 최대 유지 시간입니다.

다음 이미지는 Amazon GameLift Streams 콘솔에서 실제 스트리밍 세션을 실행한 화면입니다. Windows Server 2022 Base 런타임, 서울 위치에서 동작 중이며, FPS 60, RTT 4ms, Jitter 7ms의 안정적인 지표로 Unreal Engine 기반 3D 슈팅 게임이 쾌적하게 구동되는 것을 확인할 수 있습니다.

관측성 & 모니터링

스트리밍 환경은 구축만으로 끝나지 않고, 운영하면서 “자원이 충분한지, 사용자 체감 품질이 괜찮은지, 문제가 생기면 원인이 무엇인지”를 계속 모니터링 해야 합니다. Amazon GameLift Streams는 이를 위해 두 가지 방안을 제공합니다. 하나는 자원·성능·세션 상태를 실시간에 가깝게 보여주는 Amazon CloudWatch 메트릭이고, 다른 하나는 문제 분석을 위해 세션이 생성, 변경한 파일을 가져오는 세션 파일 내보내기입니다.

일반적으로 운영 관점에서 다음 세 가지를 확인하게 됩니다. 비용과 직결되는 용량이 수요에 맞게 잡혀 있는지(capacity), 사용자가 느끼는 지연, 프레임 품질이 정상 범위인지(performance), 그리고 세션이 정상 종료되는지 오류로 끝나는지(status)입니다.

Amazon CloudWatch 메트릭

메트릭은 크게 1분 간격으로 발행되는 실시간 지표와, 세션이 끝날 때 한 번 집계되는 종료 지표로 나뉩니다. 모든 메트릭은 15개월간 보관되므로 과거 추이 분석과 임계값 알람 설정에 활용할 수 있습니다.

실시간 메트릭 (1분 간격):

용량 메트릭은 스케일링 판단에, 성능 메트릭은 사용자 체감 품질 점검에 사용합니다. 예컨대 IdleCapacity가 0에 가까우면 곧 신규 세션을 못 받을 수 있다는 신호이고, RoundTripTime이 높으면 지연 문제를 의심할 수 있습니다.

세션 종료 시 메트릭:

ErroredStreamSessions는 안정성 모니터링의 핵심 지표로, 낮게 유지되는 것이 정상입니다. 값이 갑자기 늘면 빌드나 환경 문제를 의심해야 합니다.

세션 파일 내보내기

ExportStreamSessionFiles API는 세션 동안 애플리케이션이 생성·변경한 파일(로그, 진단 정보, crash dump, 세이브 파일, 스크린샷 등)을 Amazon S3에 압축 저장합니다. QA 로그 확보나 문제 재현·디버깅에 유용합니다.

aws gameliftstreams export-stream-session-files \
    --identifier "sg-1234567Ab" \
    --stream-session-identifier "ABC123def4567" \
    --output-uri "s3://my-export-bucket/sessions/"

세션 식별은 --identifier(스트림 그룹)와 --stream-session-identifier(세션) 두 개로 하고, --output-uri로 결과를 저장할 Amazon S3 위치를 반드시 지정해야 합니다(필수값). 끝에 /로 끝나는 prefix를 주면 Amazon GameLift Streams가 세션 메타데이터 기반으로 YYYYMMDD-HHMMSS-appId-sg-Id-sessionId.zip 형태의 파일명을 자동 생성하고, .zip으로 끝나는 경로를 주면 그 이름 그대로 저장합니다.

이 API는 진행 중인 세션(ACTIVE, CONNECTED, PENDING_CLIENT_RECONNECTION, RECONNECTING 상태)에 대해서만 호출할 수 있으며, 호출해 두면 세션이 종료될 때 zip이 생성됩니다. zip 안에서 파일은 application/(앱·게임 폴더), profile/(사용자 프로필), temp/(시스템 임시 폴더)로 정리됩니다. 내보내기 상태는 GetStreamSession으로 확인하고, 결과물을 지우려면 해당 Amazon S3 객체를 삭제하면 됩니다.

리소스 정리

테스트를 마쳤다면 반드시 생성한 리소스를 정리해야 합니다. Amazon GameLift Streams는 무료 티어가 없고, 용량이 할당되어 있는 동안 초 단위로 과금이 계속 발생하기 때문에, 리소스를 정리하지 않으면 요금이 계속 발생합니다.

정리는 다음 순서로 진행합니다.

1) 스트림 세션 종료. 진행 중인 세션이 있다면 먼저 종료합니다. 콘솔에서는 세션 화면의 Terminate session을 사용하거나, CLI로 종료할 수 있습니다.

aws gameliftstreams terminate-stream-session \
    --identifier "sg-1234567Ab" \
    --stream-session-identifier "ABC123def4567"

2) 스트림 그룹 용량을 0으로 축소하거나 삭제. 당분간 재사용할 계획이 없다면 스트림 그룹 자체를 삭제하는 것이 가장 확실합니다.

aws gameliftstreams delete-stream-group \
    --identifier "sg-1234567Ab"

3) 애플리케이션 삭제. 더 이상 사용하지 않는 애플리케이션을 삭제합니다. (해당 애플리케이션이 특정 스트림 그룹에 연결되어 있지 않아야 삭제할 수 있습니다.)

aws gameliftstreams delete-application \
    --identifier "a-1234567Ab"

4) Amazon S3 정리. 게임 빌드를 올려둔 Amazon S3 버킷과, 세션 파일을 내보낸 버킷의 객체는 스토리지 요금이 계속 발생하므로, 더 이상 필요 없다면 객체 또는 버킷을 삭제합니다.

정리 후에는 콘솔이나 list-stream-groups, list-applications로 남은 리소스가 없는지 다시 한번 확인하는 것을 권장합니다.

마치며

이 글에서는 Amazon GameLift Streams를 활용해 게임 스트리밍 환경을 구축하고 운영하는 방법을 처음부터 끝까지 살펴봤습니다. 게임 스트리밍 구현에 필요한 기술 요소들(GPU 인프라, WebRTC 저지연 스트리밍, 글로벌 배포, 용량 스케일링)을 자체 구축하는 것이 왜 어려운 일인지 확인한 뒤, Amazon GameLift Streams를 활용해 이를 간편히 해결하는 방법을 알아봤습니다.

구체적으로는 세 가지 주요 리소스(애플리케이션, 스트림 그룹, 스트림 세션)로 구성되는 아키텍처, 게임 성격에 따라 결정하는 런타임과 스트림 클래스, 트래픽에 맞춰 자동으로 늘어나고 줄어드는 용량 스케일링, 여러 리전, 여러 게임으로 확장하는 다중 위치/다중 애플리케이션 구성, 그리고 운영 단계에 필수적인 관측성까지 살펴봤습니다.

이제 게임사는 복잡한 인프라를 구축할 필요 없이, 기존 빌드를 Amazon S3에 올리는 것만으로 전 세계 플레이어에게 즉시 제공 가능한 클라우드 게임 서비스를 제공할 수 있습니다.

지금 바로 Amazon GameLift Streams 콘솔에서 여러분의 게임을 스트리밍 해보세요. Amazon S3에 빌드를 업로드하고 스트림 그룹을 생성하면, 첫 스트리밍까지 10분이면 충분합니다. 도입을 검토하고 계신다면 AWS 담당자에게 문의하세요.

참고 자료

• Amazon GameLift Streams 공식 문서
• Amazon GameLift Streams 런치 블로그
• 지원 리전 및 스트리밍 위치
• Configuration Options (Stream Classes)
• 스트림 세션 수명 주기
• API Reference — AWS CLI
• Proton 호환성 테스트 가이드
• Amazon GameLift Streams 요금 페이지
• The State of Video Gaming in 2026 — Matthew Ball