크로스 게임 에코시스템 아키텍처 설계: Unreal Engine 6 뉴스에서 얻은 기술적 시사점

모든 Backend 엔지니어는 디자인 디렉터가 "슈팅 게임에서 획득한 인벤토리를 새로운 레이싱 게임으로 가져갈 수 있게 할 수 있을까요?"라고 가볍게 물어볼 때 등 뒤로 흐르는 식은땀을 잘 알고 있습니다. 플레이어에게는 데이터베이스 경계를 넘어 디지털 자산 하나를 이동시키는 것이 간단해 보일 수 있지만, 상호 연결된 에코시스템을 설계하는 것은 분산 트랜잭션의 악몽, 스키마 버저닝 지옥, 그리고 잔인한 Race condition을 초래합니다. 로컬 클라이언트 검증만으로는 이를 해결할 수 없으며, 전통적인 모놀리식 서버 아키텍처에 의존하는 것은 필연적으로 아이템 복제 취약점이나 치명적인 데이터 손실로 이어질 것입니다. Epic Games는 최근 이것이 그들이 다음에 다룰 핵심 엔지니어링 과제임을 확인했습니다.

Epic Games는 공식적으로 Unreal Engine 6를 티징하며, 이를 단순한 그래픽의 도약이 아닌 상호 연결된 게임 개발 에코시스템을 위한 기초 인프라로 포지셔닝했습니다. Rendering 엔지니어들이 Nanite와 Lumen의 다음 버전을 간절히 기다리는 동안, Backend 개발자들에게 진짜 중요한 이야기는 고립된 세션 기반 게임 인스턴스에서 영속적이고 타이틀 간 경계를 허무는 현실로의 전환입니다. Unreal Editor for Fortnite (UEFN)를 통한 Epic의 현재 궤적은 이미 이를 증명하고 있습니다. 그들은 플레이어의 ID, 인벤토리, 소셜 그래프가 개별 애플리케이션 계층 위에서 보안이 유지된 채로 존재하는 Framework를 구축하고 있습니다.

이 글에서는 상호 연결된 에코시스템으로 향하는 업계 전반의 변화가 갖는 기술적 함의를 분석합니다. 이러한 요구 사항 아래에서 왜 전통적인 Backend 아키텍처가 실패하는지 분석하고, 미래를 대비하기 위해 현재 Unreal Engine 5에서 C++ 서브시스템을 구조화하는 방법을 탐구하며, 분산 상태 동기화를 위한 실행 가능한 블루프린트를 제공합니다.

"상호 연결된 에코시스템" 개념 분석

최근의 unreal engine 6 뉴스를 분석해 보면, "상호 연결된 에코시스템"이라는 문구는 네트워크 토폴로지 설계 방식의 근본적인 전환을 의미합니다. 역사적으로 Multiplayer 게임은 사일로(Silo) 구조로 운영되었습니다. 클라이언트가 Dedicated Server에 연결하고, 서버는 모놀리식 SQL 데이터베이스와 통신하며, 세션이 끝나면 사일로는 폐쇄됩니다. 스튜디오가 후속작을 출시할 때, 대개 완전히 새로운 데이터베이스 클러스터를 구축하고, 기존 플레이어에게 코스메틱 배지를 부여하기 위해 일회성 마이그레이션 스크립트를 실행하곤 했습니다.

상호 연결된 에코시스템은 이러한 사일로를 깨뜨립니다. 플레이어는 통합되고 암호화되어 보안이 유지된 프로필을 유지하면서, 완전히 다른 게임 클라이언트(심지어 다른 엔진 버전으로 구축된 경우라도) 사이를 유동적으로 이동할 수 있어야 합니다. 이를 위해서는 "Player State"를 "Simulation State"에서 분리해야 합니다. Dedicated Server는 더 이상 장기적인 진행 데이터의 절대적인 소스(Source of Truth)가 될 수 없습니다. 서버는 단순히 플레이어의 전역 분산 데이터에 대한 일시적이고 권한이 있는 리스(Lease) 보유자 역할만 수행해야 합니다.

크로스 타이틀 진행 데이터의 엔지니어링적 악몽

왜 이 아키텍처를 안정화하는 것이 그토록 어려울까요? 주요 원인은 지연 시간(Latency)과 분산 Race condition의 결합입니다. 현재 플레이어가 게임 A에서 전설적인 무기를 거래하고 5초 후에 게임 B에서 이를 장착하게 하려면, 지역 간 데이터베이스 복제 지연을 처리해야 합니다. 표준 PostgreSQL 설정은 대서양 횡단 시 150ms의 지연 시간을 발생시킬 수 있지만, 게임 클라이언트는 반응성을 느끼기 위해 50ms 미만의 승인 응답을 기대합니다.

수 초마다 상태 변경을 수행하는 동시 접속자 수(CCU) 100,000명 규모로 이 에코시스템을 확장하면, 갑자기 초당 8,300회 이상의 쓰기 작업이 발생하게 됩니다. 이 볼륨은 전통적인 관계형 데이터베이스를 즉시 마비시켜 쿼리 잠금과 트랜잭션 누락을 초래합니다. 또한, 이러한 상호 연결된 세계를 위한 컴퓨팅 인프라를 관리하려면 Architecting Zero Waste Servers The Fortnite Server Optimization Hibernation Proposal Analyzed 분석에서 다룬 복잡한 오케스트레이션 전략과 유사한 공격적인 확장성이 필요합니다.

기술 심층 분석: 범용 Player State 서브시스템 설계

에코시스템 우선 접근 방식을 위해 Unreal Engine 5 프로젝트를 준비하려면, Backend API 호출을 처리할 때 AGameMode나 APlayerState에 의존하는 것을 중단해야 합니다. 이러한 클래스는 UWorld 수명 주기와 뗄 수 없는 관계에 있습니다. 레벨이 변경되면 이 객체들은 파괴되며, 이는 진행 중인 Backend HTTP 요청이 고아가 되어 null 포인터 크래시나 저장 누락을 초래한다는 것을 의미합니다.

대신, 크로스 타이틀 Backend 통신은 UGameInstanceSubsystem에 의해 처리되어야 합니다. Game Instance는 레벨 전환이나 서버 연결 끊김에 관계없이 애플리케이션의 전체 수명 주기 동안 유지됩니다. 분산 Backend 로직을 서브시스템을 통해 라우팅함으로써, 네트워크 요청이 맵 변경 시에도 생존하게 하고 크로스 게임 마이크로서비스에 대한 영속적인 WebSocket 또는 HTTP 폴링 연결을 유지할 수 있습니다.

C++ 구현: Global Profile Subsystem

다음은 크로스 타이틀 플레이어 데이터를 가져오고 확인하기 위한 비동기식 영속적 서브시스템을 구조화하는 프로덕션 레벨의 C++ 예시입니다. 이 코드는 Unreal의 FHttpModule을 활용하며, 마이크로 스터터(Micro-stutters)를 방지하기 위해 JSON 파싱 로직을 메인 게임 스레드와 엄격히 분리합니다.

// GlobalProfileSubsystem.h
#pragma once

#include "CoreMinimal.h"
#include "Subsystems/GameInstanceSubsystem.h"
#include "Http.h"
#include "GlobalProfileSubsystem.generated.h"

USTRUCT(BlueprintType)
struct FGlobalPlayerProfile
{
    GENERATED_BODY()

    UPROPERTY(BlueprintReadOnly)
    FString AccountId;

    UPROPERTY(BlueprintReadOnly)
    int32 GlobalCurrency;

    UPROPERTY(BlueprintReadOnly)
    int32 SchemaVersion;
};

DECLARE_DYNAMIC_MULTICAST_DELEGATE_OneParam(FOnProfileSynced, const FGlobalPlayerProfile&, Profile);

UCLASS()
class UGlobalProfileSubsystem : public UGameInstanceSubsystem
{
    GENERATED_BODY()

public:
    virtual void Initialize(FSubsystemCollectionBase& Collection) override;
    virtual void Deinitialize() override;

    UFUNCTION(BlueprintCallable, Category = "Ecosystem|Backend")
    void FetchCrossTitleProfile(const FString& AuthToken);

    UPROPERTY(BlueprintAssignable, Category = "Ecosystem|Events")
    FOnProfileSynced OnProfileSynced;

private:
    void OnProfileFetchComplete(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful);
    
    FGlobalPlayerProfile CachedProfile;
    FString BackendApiUrl = TEXT("https://api.your-ecosystem.com/v1/profile");
};

// GlobalProfileSubsystem.cpp
#include "GlobalProfileSubsystem.h"
#include "Serialization/JsonReader.h"
#include "Serialization/JsonSerializer.h"

void UGlobalProfileSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);
    UE_LOG(LogTemp, Log, TEXT("Global Profile Subsystem Initialized."));
}

void UGlobalProfileSubsystem::Deinitialize()
{
    Super::Deinitialize();
}

void UGlobalProfileSubsystem::FetchCrossTitleProfile(const FString& AuthToken)
{
    TSharedRef<IHttpRequest, ESPMode::ThreadSafe> Request = FHttpModule::Get().CreateRequest();
    Request->OnProcessRequestComplete().BindUObject(this, &UGlobalProfileSubsystem::OnProfileFetchComplete);
    Request->SetURL(BackendApiUrl);
    Request->SetVerb("GET");
    Request->SetHeader(TEXT("Authorization"), FString::Printf(TEXT("Bearer %s"), *AuthToken));
    Request->SetHeader(TEXT("Content-Type"), TEXT("application/json"));
    
    // 모바일 또는 열악한 네트워크에서 무한 대기를 방지하기 위해 엄격한 타임아웃 구현
    Request->SetTimeout(10.0f);
    Request->ProcessRequest();
}

void UGlobalProfileSubsystem::OnProfileFetchComplete(FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful)
{
    if (!bWasSuccessful || !Response.IsValid() || Response->GetResponseCode() != 200)
    {
        UE_LOG(LogTemp, Error, TEXT("Failed to fetch cross-title profile. HTTP Code: %d"), 
               Response.IsValid() ? Response->GetResponseCode() : -1);
        // 실제 시나리오에서는 여기서 지수 백오프(Exponential Backoff) 재시도 로직을 트리거합니다.
        return;
    }

    TSharedPtr<FJsonObject> JsonObject;
    TSharedRef<TJsonReader<>> Reader = TJsonReaderFactory<>::Create(Response->GetContentAsString());

    if (FJsonSerializer::Deserialize(Reader, JsonObject) && JsonObject.IsValid())
    {
        // 이전 클라이언트가 데이터를 손상시키는 것을 방지하기 위한 강력한 스키마 검증
        int32 PayloadSchema = JsonObject->GetIntegerField(TEXT("schemaVersion"));
        if (PayloadSchema > 3) // 예시: 최대 지원 클라이언트 스키마
        {
            UE_LOG(LogTemp, Warning, TEXT("Client out of date. Required schema %d is unsupported."), PayloadSchema);
            return;
        }

        CachedProfile.AccountId = JsonObject->GetStringField(TEXT("accountId"));
        CachedProfile.GlobalCurrency = JsonObject->GetIntegerField(TEXT("globalCurrency"));
        CachedProfile.SchemaVersion = PayloadSchema;

        // 메인 게임 스레드에 안전하게 브로드캐스트
        OnProfileSynced.Broadcast(CachedProfile);
    }
}

타이틀 간 스키마 충돌 관리

위 페이로드의 SchemaVersion 정수를 주목하십시오. 동일한 Backend에 액세스하는 두 개의 서로 다른 게임이 있을 때, 이들은 필연적으로 서로 다른 데이터 구조를 기준으로 컴파일됩니다. 게임 A는 "Weapon" 객체가 5개의 속성을 가진다고 이해할 수 있는 반면, 6개월 후에 컴파일된 게임 B는 "Weapon"이 8개의 속성을 가질 것으로 기대할 수 있습니다.

게임 A가 더 최신 버전의 페이로드를 받으면, 전통적인 역직렬화 방식은 종종 크래시를 일으키거나 인식되지 않는 필드를 자동으로 잘라냅니다. 그런 다음 게임 A가 해당 프로필을 다시 Backend에 저장하면, 사실상 3개의 새로운 속성을 삭제하여 플레이어의 데이터를 영구적으로 손상시키게 됩니다. 역직렬화 중에 알 수 없는 JSON 키를 캐싱하고 직렬화 중에 무조건 다시 추가하는 "스키마 인식 직렬화"를 구현해야 합니다.

분산 Race condition 해결: "Alt-F4" 문제

강력한 C++ 서브시스템이 있더라도, 네트워킹의 물리적 현실은 치명적인 취약점을 드러냅니다. "Alt-F4" 문제를 생각해 보십시오. 플레이어가 게임 A(RPG)에서 전설의 검을 NPC에게 팔고 즉시 애플리케이션을 강제 종료합니다. 그리고 곧바로 게임 B(컴패니언 모바일 앱)를 실행하여 전역 통화 잔액을 확인합니다.

만약 게임 A의 Dedicated Server가 아직 중앙 데이터베이스에 트랜잭션 배시(Batch)를 반영(Flush)하지 못했다면, 게임 B는 오래된 데이터를 가져오게 됩니다. 플레이어가 게임 B에서 통화를 사용하면, 이후의 데이터베이스 쓰기는 게임 A의 지연된 트랜잭션을 덮어쓰거나 심각한 충돌을 일으킬 것입니다. 데이터가 클라이언트 시뮬레이션에 도달했을 때 이 상태 업데이트를 잘못 관리하면, Multiplayer Desyncs Fixing The Unreal Engine Rpc Replication Issue Breaking Your States 가이드에서 요약한 오류들이 빠르게 발생할 것입니다.

분산 서버 리스(Lease) 구현

이를 방지하기 위해 상호 연결된 에코시스템은 분산 락(Distributed Locks) 또는 리스(Leases)에 의존합니다. 게임 서버가 플레이어를 인증할 때, Redis와 같은 고속 인메모리 데이터 저장소로부터 리스를 요청해야 합니다. 이 리스는 특정 서버 인스턴스에 정해진 기간(예: 60초) 동안 플레이어 프로필에 대한 독점적인 쓰기 권한을 부여하며, 하트비트(Heartbeat) 핑을 통해 지속적으로 갱신됩니다.

플레이어가 게임 B를 부팅하면, 프로필을 가져오기 위한 API 요청이 게임 A가 여전히 활성 리스를 보유하고 있음을 감지합니다. Backend는 게임 A의 리스가 만료되거나 정상적으로 반납될 때까지 게임 B에 쓰기 권한 부여를 거부합니다. 게임 B의 클라이언트는 잠금이 해제될 때까지 "전역 프로필 동기화 중..."이라는 메시지와 함께 로딩 화면을 안전하게 표시할 수 있습니다. 이를 통해 트랜잭션이 에코시스템 전반에서 선형적으로 처리됨을 보장합니다.

"직접 구축" vs Backend-as-a-Service의 현실

이러한 인프라를 수동으로 설계하는 것은 엄청난 작업입니다. 탄력적인 크로스 게임 Backend를 위해서는 영속적 저장을 위한 수평 확장형 PostgreSQL 클러스터, 분산 락을 위한 고가용성 Redis 클러스터, 그리고 타이틀 간 트래픽을 지능적으로 라우팅하기 위한 Kubernetes 기반 API 게이트웨이를 배포해야 합니다.

이 스택을 구축하고, 보안을 유지하며, 부하 테스트를 수행하는 데는 일반적으로 시니어 엔지니어의 시간 4~6개월이 소요됩니다. 실제 게임 메커니즘이 아닌 인프라의 상용구 코드를 작성하는 데 드는 시간입니다. 또한 SSL 인증서 유효성 유지, 데이터베이스 취약점 패치, 오토 스케일링 그룹 구성 등은 스튜디오에 영구적인 DevOps 비용을 부과합니다.

horizOn을 사용하면 이러한 복잡성이 완전히 추상화됩니다. Kubernetes 포드나 데이터베이스 샤드를 관리하는 대신, Unreal Engine 서브시스템은 즉시 사용 가능한 고가용성 지리 분산 엔드포인트와 통신하기만 하면 됩니다. 분산 락, 스키마에 구애받지 않는 문서 저장소, 실시간 플레이어 상태 복제가 자동으로 처리되므로, 인프라와 싸우는 대신 에코시스템 전반에 걸쳐 매력적인 메커니즘을 구축하는 데 집중할 수 있습니다.

에코시스템 대응형 게임 아키텍처를 위한 5가지 모범 사례

인프라 호스팅 방식을 어떻게 선택하든, 다음 규칙을 준수하면 에코시스템이 성장함에 따라 발생할 수 있는 치명적인 데이터 실패로부터 스튜디오를 보호할 수 있습니다.

1. 클라이언트 타임스탬프를 절대 신뢰하지 마십시오: 여러 게임 간의 데이터를 조정할 때, 어떤 저장 상태가 최신인지 결정하기 위해 클라이언트의 로컬 시스템 시간을 사용하지 마십시오. 항상 엄격하고 단조 증가(Monotonically increasing)하는 서버 측 트랜잭션 ID를 사용하여 이벤트 순서를 정렬하십시오.
2. 가변 상태를 정적 정의와 분리하십시오: Backend 데이터베이스에는 동적 데이터(예: WeaponID: 45, Level: 3)만 저장해야 합니다. 데미지 수치나 스탯 가중치와 같은 정적 밸런싱 데이터를 플레이어 프로필에 저장하지 마십시오. 이는 크로스 타이틀 밸런싱을 불가능하게 만듭니다.
3. 지수 백오프(Exponential Backoff) 구현: Backend 요청이 실패했을 때 즉시 재시도하면 장애 발생 시 자체 인프라에 의도치 않은 DDoS 공격을 가하게 됩니다. UGameInstanceSubsystem에 무작위 지수 백오프 알고리즘을 구현하여 재접속 시도를 분산시키십시오.
4. 쓰기 실패 시 Dead Letter Queues 사용: 게임 서버가 여러 번의 재시도 후에도 메인 데이터베이스 쓰기에 실패하더라도, 플레이어의 진행 데이터를 버려서는 안 됩니다. 트랜잭션을 로컬 디스크나 보조 큐(Dead Letter Queue)에 직렬화하여 나중에 수동 처리하거나 비동기 복구가 가능하도록 하십시오.
5. 엄격한 스키마 버저닝 강제: 모든 API 요청과 JSON 페이로드는 버전 헤더를 포함해야 합니다. Backend 서비스가 호환되지 않는 버전 불일치를 감지하면, 호환되지 않는 데이터를 제공하기보다는 페이로드 형식을 안전하게 다운그레이드하거나 클라이언트 업데이트를 강제해야 합니다.

결론 및 다음 단계

Unreal Engine 6의 티징은 플랫폼 엔지니어들이 수년 동안 알고 있었던 사실을 확인시켜 줍니다. 즉, 게임의 미래는 깊이 상호 연결되어 있다는 것입니다. 플레이어들은 자신의 시간과 비용 투자가 단일 실행 파일의 경계를 넘어서기를 기대합니다. 단일 타이틀 아키텍처에서 분산 에코시스템으로 전환하려면 게임 인스턴스와 중앙 데이터베이스 간의 데이터 흐름 방식을 근본적으로 재고해야 합니다.

네트워크 로직을 영속적 서브시스템으로 이동하고, 엄격한 스키마 검증을 적용하며, 분산 락을 활용함으로써 미래의 요구 사항에 맞춰 현재의 UE5 프로젝트를 대비할 수 있습니다. 인프라 코드를 작성하는 데 수개월을 허비하지 않고 크로스 타이틀 진행 시스템을 설계할 준비가 되었다면, horizOn을 무료로 체험하거나 포괄적인 API docs를 확인하여 분산 상태 관리가 얼마나 간단해질 수 있는지 확인해 보십시오.

---

출처: Epic Games Officially Teases Unreal Engine 6