2026-06-18 TIL (79일차)

🌐 언리얼 엔진 멀티플레이어 네트워크 핵심 개념 총정리

언리얼 엔진의 멀티플레이어 환경은 철저한 클라이언트-서버(Client-Server) 아키텍처를 기반으로 작동합니다. 성공적인 멀티플레이 게임을 개발하기 위해 반드시 알아야 할 네트워크의 핵심 개념과 주요 클래스들의 역할을 정리했습니다.

---

1. 서버의 절대적 권한 (Server Authority)과 헤드리스(Headless)

⚖️ 서버는 게임의 ‘절대적인 심판’

서버는 게임 내에서 일어나는 모든 일의 최종 결정권자(Authority)입니다. 클라이언트(플레이어의 컴퓨터)가 “내가 적을 맞췄다!”라고 보내는 패킷을 무조건 신뢰하지 않습니다. 클라이언트의 데이터를 그대로 믿으면 패킷 변조를 통한 해킹(예: 무조건 헤드샷 적중)에 무방비로 노출되기 때문입니다. 따라서 서버는 직접 보이지 않는 맵에 총알을 발사해 보고, 장애물에 막히지 않고 적중했는지를 물리적으로 계산하여 판정합니다.

🙈 ‘눈을 가린 보드게임 마스터’ (Headless Server)

데디케이티드 서버(Dedicated Server)는 그래픽(렌더링)과 소리(오디오) 기능을 완전히 꺼버린 헤드리스(Headless) 상태로 구동됩니다.

• 클라이언트의 맵: 빛, 그림자, 캐릭터 외형, 환경음 등 눈에 보이고 들리는 모든 것을 렌더링합니다.
• 서버의 맵: 화려한 그래픽은 없지만, 투명한 물리 충돌체(Collision), AI 이동 경로(NavMesh), 보이지 않는 트리거 등 게임 판정에 필요한 뼈대만을 메모리에 띄워 통제합니다.

---

2. 데이터 동기화와 리플리케이션 (Replication)

📡 서버 오픈과 대기 (Listen)

서버가 Open {Level이름}?Listen 명령어를 실행하면, 서버 컴퓨터가 맵을 열고 소켓(Socket, 통신 구멍)을 개방하여 다른 플레이어들의 접속을 기다립니다. 이때 서버가 클라이언트에게 3D 맵 에셋이나 그래픽 파일을 다운로드해 주는 것이 아닙니다(에셋은 이미 각자의 하드디스크에 설치되어 있음). 서버가 뿜어내는 것은 ‘좌표, 체력, 상태 변화 등의 순수 데이터’입니다.

👯 원본과 복사본의 관계

• 원본 (Authority): 게임 세계의 ‘진짜’ 몬스터, 아이템, 캐릭터는 오직 서버에만 존재합니다.
• 복사본 (Proxy): 클라이언트 화면에 보이는 모든 것들은 서버가 보내준 정보를 바탕으로 흉내 내고 있는 ‘껍데기(복사본)’입니다. 이렇게 서버의 상태를 클라이언트에 동기화하는 과정을 리플리케이션(Replication)이라고 합니다.

---

3. 🗺️ 주요 클래스의 생존 구역 (어디에 존재하는가?)

언리얼 엔진 멀티플레이의 핵심은 “이 클래스가 누구의 컴퓨터에 존재하는가?”를 파악하는 것입니다.

클래스 (Class)	서버 (Server)	내 컴퓨터 (나)	남의 컴퓨터 (타인)	역할 및 비유
GameMode	🔵 (원본)	❌	❌	심판만 아는 비밀 룰북. 점수 계산, 승리 조건 등을 관리. (클라이언트에 있으면 해킹 위험)
PlayerController	🔵 (원본)	🔵 (복사본)	❌	나만 쥐고 있는 리모컨. 나의 키보드/마우스 입력을 처리. 남의 컨트롤러는 내 컴퓨터에 존재하지 않음 (Null).
Character / Pawn	🔵 (원본)	🔵 (복사본)	🔵 (복사본)	경기장을 뛰는 육체. 내가 움직이면 남들 화면에서도 움직여야 하므로 모두에게 동기화됨.
PlayerState	🔵 (원본)	🔵 (복사본)	🔵 (복사본)	선수 등번호와 점수판. 남의 컨트롤러를 볼 수 없으므로, 닉네임, 핑(Ping), K/D 점수 등 공개 정보를 담아 모두에게 뿌려주는 가방.

(💡 참고: 클라이언트에서 GetGameMode()를 호출하면 항상 nullptr을 반환합니다. 게임모드는 서버에만 있기 때문입니다. 게임모드에 접근하려면 HasAuthority()를 통해 현재 코드가 서버에서 실행 중인지 확인해야 합니다.)

---

4. 네트워크 하부 구조 (NetDriver, NetConnection, NetMode)

언리얼 엔진이 이 복잡한 통신을 어떻게 관리하는지 로우레벨(Low-level) 구조를 이해하는 것도 중요합니다.

🔌 NetDriver 와 NetConnection (인터넷 공유기와 랜선)

• NetDriver (인터넷 공유기): 컴퓨터의 네트워크 포트(Socket)를 직접 열고 닫으며, 외부에서 들어오는 모든 데이터를 가장 먼저 받아내는 네트워크 총괄 관리자(Hub)입니다. 싱글플레이에서는 존재하지 않으며 멀티플레이 시에만 생성됩니다.
• NetConnection (개별 랜선): 공유기에 1번, 2번 컴퓨터로 가는 랜선이 꽂혀 있듯이, 특정 컴퓨터 1대와 통신하기 위해 만들어진 전용 통신 파이프(객체)입니다.

이 구조를 실제 언리얼 엔진의 C++ 코드 느낌으로 단순화해서 보면 이렇습니다.

class UNetDriver 
{
    // [서버용] 나에게 접속한 여러 플레이어들의 랜선 다발 (배열)
    TArray<UNetConnection*> ClientConnections; 

    // [클라이언트용] 내가 서버와 연결하기 위해 꽂은 단 하나의 랜선
    UNetConnection* ServerConnection;
    
    // ... 기타 네트워크 처리 함수들 ...
}

❓ 궁금증 해결: UNetDriver는 도대체 어디에 있는 걸까?

UNetDriver는 언리얼 엔진 소스 코드에 내장된 핵심 C++ 클래스입니다. 외부의 제3자 서버 프로그램이 아니라, 서버 컴퓨터와 클라이언트 컴퓨터가 각각 자신의 메모리(RAM)에 직접 생성해서 들고 있는 객체입니다.

• 서버 컴퓨터: 멀티플레이 방을 열면 엔진 내부에서 자기만의 UNetDriver를 하나 켭니다. (거대한 우체국 본점)
• 클라이언트 컴퓨터: 서버에 접속하려고 하면 엔진 내부에서 자기만의 UNetDriver를 하나 켭니다. (동네 우체국 지점)

즉, 멀티플레이가 켜지는 순간 각자의 컴퓨터 안에서 언리얼 엔진이 스스로 UNetDriver를 깨워 서로 통신을 시작하는 구조입니다.

---

💡 심화 1: 역할 분담 (우체국과 우체부)

각 컴퓨터가 들고 있는 넷드라이버는 이 커넥션 객체들을 관리하며 다음과 같이 역할을 분담합니다.

• UNetDriver (우체국 집중국): 인터넷 망에서 날아오는 모든 데이터(패킷)를 무작정 받아 겉면을 보고 “아, 이건 1번 랜선에서 온 데이터네?” 하고 분류하여 해당 UNetConnection에게 토스합니다.
• UNetConnection (개인 전담 우체부): 자기가 담당하는 플레이어의 데이터만 전문적으로 처리합니다. 상대방의 핑(Ping) 계산, 패킷 유실 시 재전송 요청을 수행하며, 가장 중요하게는 이 랜선의 끝에 어떤 PlayerController가 연결되어 있는지 기억하고 관리합니다.

---

💡 심화 2: NetConnection의 정체와 생성 시점

초보자들이 가장 많이 하는 오해 중 하나는 “ClientConnection, ServerConnection, UNetConnection이 모두 다른 객체인가?” 하는 것입니다.

결론부터 말하자면, ClientConnection과 ServerConnection의 정체(데이터 타입)가 바로 UNetConnection입니다. 즉, UNetConnection은 ‘통신 케이블(랜선)’ 그 자체를 의미하는 설계도(클래스)입니다. 서버 입장에서는 내게 꽂힌 랜선을 ‘클라이언트 커넥션’이라 부르고, 클라이언트 입장에서는 내 컴퓨터에 꽂힌 랜선을 ‘서버 커넥션’이라고 부를 뿐, 실제로는 동일한 타입의 양방향 파이프입니다.

이 랜선(UNetConnection)은 언제 생성될까요? 통신이 발생할 때마다 생기는 것이 아니라, ‘플레이어가 서버에 처음 접속을 시도하는 바로 그 순간(Handshake)’에 딱 한 번 생성됩니다.

1. 클라이언트의 접속 시도: 클라이언트가 서버에 접속을 시도하면, 클라이언트 컴퓨터의 UNetDriver가 즉시 UNetConnection 객체를 생성(ServerConnection에 저장)하고 서버에 노크(요청)합니다.
2. 서버의 수락: 서버가 요청을 받으면, 서버의 UNetDriver 역시 새로운 UNetConnection 객체를 생성하여 자신의 ClientConnections 배열에 추가합니다.
3. 연결 완료: 양쪽 컴퓨터에 각각 UNetConnection이 생성되어 논리적으로 연결이 완료되면, 앞서 배운 PlayerController가 이 랜선을 타고 클라이언트에게 발급됩니다.

---

🔗 소유권 (Ownership)

멀티플레이에서는 ‘누가 이 액터의 진짜 주인인가?’를 따지는 소유권(Ownership)이 매우 중요합니다. RPC(원격 프로시저 호출)의 실행 권한을 결정하기 때문입니다.

• 소유권 트리: ClientConnection ➡️ PlayerController ➡️ Pawn(Character) ➡️ Weapon(무기 액터)
• 이 소유 관계(Family)에 속해 있다면, 액터에서 GetNetConnection()을 호출했을 때 본인을 조종하는 통신 객체를 정상적으로 받아올 수 있습니다.

---

🖥️ 넷 모드 (NetMode)

현재 코드가 실행되고 있는 컴퓨터의 정체(역할)를 나타냅니다. (GetNetMode() 함수로 확인 가능)

1. NM_Standalone: 싱글플레이 모드. (네트워크 연결 없음)
2. NM_DedicatedServer: 플레이어(그래픽/사운드) 없이 오직 게임 로직만 돌아가는 순수 서버.
3. NM_ListenServer: 누군가가 방장(호스트)이 되어 서버 역할과 클라이언트(플레이) 역할을 동시에 수행하는 서버.
4. NM_Client: 서버에 접속하여 화면을 렌더링하고 입력을 보내는 일반 접속자.

---

5. 핵심 요약: 로직 처리와 보안

데미지 계산, 아이템 획득, 스탯 변화 등 게임에 중대한 영향을 미치는 모든 핵심 로직은 반드시 서버(Authority)에서만 처리해야 합니다.

클라이언트에서 데미지를 깎도록 구현하면, 해커가 패킷 스니핑/변조를 통해 조작된 데이터를 서버로 보내 게임 생태계를 파괴할 수 있습니다. 클라이언트는 오직 “마우스를 클릭했다(공격 시도)”라는 입력(Input)만을 서버에 전달하고, 깎인 체력의 결과값(Replication)을 받아 화면의 UI를 갱신하는 역할만 수행해야 합니다.