Dedicated Server와 Listen Server

1. Server 모델

네트워크 기반 애플리케이션, 특히 멀티플레이어 게임을 개발할 때 가장 중요한 아키텍처 결정 중 하나는 서버 모델을 선택하는 것입니다. 서버는 모든 클라이언트(플레이어)를 연결하고 게임 상태를 동기화하는 중앙 허브 역할을 합니다.

대표적인 서버 모델로는 데디케이티드 서버(Dedicated Server)와 리슨 서버(Listen Server)가 있으며, 각각의 선택은 성능, 비용, 확장성, 개발 복잡성 및 사용자 경험에 지대한 영향을 미칩니다.

---

2. 리슨 서버 (Listen Server)

2.1. 개념 및 기본 구조

리슨 서버는 "클라이언트가 곧 서버(Client-as-Server)"가 되는 구조입니다. 멀티플레이어 세션에 참여하는 여러 클라이언트 중 하나가 서버의 역할을 겸임합니다. 즉, 호스트(Host)가 된 클라이언트는 자신의 게임을 실행하면서 동시에 다른 클라이언트들(Peers)의 연결을 받고, 게임 월드의 상태를 계산하고, 그 결과를 모든 클라이언트에게 전송하는 책임을 집니다.

• 호스트 (Host): 서버 역할을 하는 클라이언트. 자신의 게임 플레이와 서버 로직(상태 동기화, 입력 처리 등)을 모두 처리해야 하므로 가장 많은 리소스(CPU, 메모리, 네트워크 대역폭)를 사용합니다.
• 피어 (Peers): 호스트에 연결된 다른 클라이언트들. 자신의 입력을 호스트에게 보내고, 호스트로부터 업데이트된 게임 상태를 받아 화면에 렌더링합니다.

이 구조는 별도의 서버 하드웨어가 필요 없어 비용 효율적이며, 소규모 비공개 세션(예: 친구들과의 LAN 파티, 협동 플레이)에 적합합니다.

2.2. 내부 구조 및 구현 방식

리슨 서버의 구현은 본질적으로 네트워킹 기능을 갖춘 애플리케이션 내에 서버 로직을 통합하는 것입니다.

2.2.1. 네트워크 소켓 프로그래밍 관점

리슨 서버의 핵심은 특정 네트워크 포트(Port)에서 들어오는 연결 요청을 "수신 대기(Listen)"하는 소켓(Socket)입니다.

1. 소켓 생성 (Socket Creation): 호스트 애플리케이션은 네트워크 통신을 위한 소켓을 생성합니다. (e.g., socket() in C++)
2. 바인딩 (Binding): 생성된 소켓을 호스트 컴퓨터의 특정 IP 주소와 포트 번호에 할당합니다. (e.g., bind()) 외부 클라이언트의 접속을 허용하기 위해 보통 INADDR_ANY (0.0.0.0) 주소를 사용하여 모든 네트워크 인터페이스로부터의 연결을 받아들입니다.
3. 수신 대기 (Listening): 소켓을 '수신 대기' 상태로 전환하여 클라이언트의 연결 요청을 기다립니다. (e.g., listen()) 이때 backlog 큐의 크기를 지정하여 동시에 처리할 수 있는 최대 연결 요청 수를 설정합니다.
4. 연결 수락 (Accepting): 블로킹(blocking) 함수인 accept()를 호출하여 실제 연결 요청이 들어올 때까지 대기합니다. 연결이 성공하면, 해당 클라이언트와 통신할 수 있는 새로운 소켓이 생성됩니다.
5. 데이터 통신 (Data Communication): 호스트는 각 클라이언트와 생성된 새 소켓을 통해 게임 데이터를 주고받습니다. (e.g., send(), recv()) 보통 각 클라이언트를 별도의 스레드(Thread)나 비동기 I/O 모델(e.g., select, epoll, IOCP)을 사용하여 관리함으로써 여러 클라이언트를 동시에 처리합니다.

2.2.2. 게임 엔진 관점

언리얼 엔진과 같은 현대 게임 엔진은 이러한 복잡한 과정을 추상화하여 제공합니다.

• 플레이어가 "Create Session" 또는 "Host Game"을 선택하면, 엔진은 내부적으로 UWorld 객체를 서버 월드로 전환하고, UNetDriver를 생성하여 클라이언트의 연결을 받아들일 준비를 합니다.
• 이때 호스트는 TRAVEL_Listen 상태가 되어 맵을 로드하고, 다른 클라이언트들은 TRAVEL_Absolute를 통해 호스트의 IP 주소로 접속을 시도합니다.
• 호스트의 NetDriver는 들어오는 연결을 감지하고 UNetConnection 객체를 생성하여 각 클라이언트를 관리합니다.

2.3. 계층별 동작 분석

• 사용자 영역 (User Space):
  • 애플리케이션 계층: 게임 또는 애플리케이션 코드가 실행됩니다. 호스트에서는 게임 로직과 서버 로직이 동일한 프로세스 내에서 실행됩니다. 호스트의 입력은 즉시 처리되는 반면, 피어의 입력은 네트워크를 통해 호스트로 전송되어 처리된 후 그 결과가 다시 피어에게 전달됩니다.
  • 라이브러리/엔진 계층: 소켓 API를 추상화한 엔진의 네트워킹 라이브러리(e.g., 언리얼의 NetDriver, Unity의 UNET)가 사용됩니다. NAT Traversal을 위한 STUN/TURN 서버와의 통신이나 세션 관리를 위한 백엔드 서비스(e.g., Steam, Epic Online Services)와의 연동이 이 계층에서 이루어집니다.
• 커널 영역 (Kernel Space):
  • 전송 계층 (Transport Layer - TCP/UDP): 애플리케이션으로부터 send() 요청을 받은 데이터는 TCP 또는 UDP 프로토콜에 따라 세그먼트(Segment) 또는 데이터그램(Datagram)으로 캡슐화됩니다. 게임 데이터는 보통 실시간성이 중요한 UDP가 선호됩니다.
  • 네트워크 계층 (Network Layer - IP): TCP/UDP 세그먼트는 IP 헤더가 추가되어 IP 패킷(Packet)으로 만들어집니다. 이때 출발지 IP(호스트)와 목적지 IP(피어) 주소가 기록됩니다.
  • 데이터 링크 계층 (Data Link Layer): IP 패킷은 이더넷 프레임(Ethernet Frame)으로 캡슐화되어 물리적인 네트워크 인터페이스(NIC)를 통해 전송됩니다.

2.4. 장점 및 단점

장점

1. 비용 효율성: 별도의 서버 하드웨어나 호스팅 비용이 필요 없습니다.
2. 간편함: 설정이 간단하여 소규모 비공개 게임(LAN 파티, 친구 간의 플레이)에 매우 편리합니다.
3. 낮은 지연 시간 (호스트 한정): 호스트 플레이어는 자신의 입력이 네트워크를 거치지 않고 즉시 처리되므로 '0-ping'에 가까운 쾌적한 환경에서 플레이할 수 있습니다.

단점

1. 성능 및 안정성 부족: 호스트의 PC 사양과 네트워크 상태가 전체 세션의 품질을 결정합니다. 호스트의 리소스가 부족하거나 인터넷 연결이 불안정하면 모든 클라이언트가 랙(lag)이나 연결 끊김을 경험합니다.
2. 호스트 의존성: 호스트가 게임을 종료하면 서버 자체가 사라지므로 세션이 강제 종료됩니다.
3. 호스트 어드밴티지 (Host Advantage): 호스트의 지연 시간이 다른 클라이언트보다 현저히 낮아 반응 속도에서 불공평한 이점을 가집니다. 이는 경쟁적인 FPS 게임 등에서 심각한 문제가 될 수 있습니다.
4. 보안 취약성: 호스트가 모든 게임 상태 정보를 가지고 있으므로 메모리 조작 등의 치팅(cheating)에 취약합니다. 또한, 호스트의 IP 주소가 클라이언트에게 노출되어 DDoS 공격의 대상이 될 수 있습니다.
5. 네트워크 설정의 복잡성 (NAT): 대부분의 가정용 인터넷은 공유기(Router)의 NAT(Network Address Translation) 환경 뒤에 있으므로, 외부 클라이언트가 접속하려면 포트 포워딩(Port Forwarding)과 같은 추가 설정이 필요할 수 있습니다.

---

3. 데디케이티드 서버 (Dedicated Server)

3.1. 개념 및 기본 구조

데디케이티드 서버는 이름 그대로 "서버 역할만을 전담하는 독립적인 컴퓨터"입니다. 이 서버는 게임을 직접 플레이하지 않으며, 오직 클라이언트들의 연결을 관리하고, 게임 월드를 시뮬레이션하며, 모든 플레이어의 상태를 동기화하는 작업에만 모든 리소스를 할애합니다.

• 서버 (Server): 데이터 센터나 클라우드 환경에서 24시간 가동되는 고성능 컴퓨터. 그래픽 렌더링이나 사운드 출력이 필요 없으므로 보통 GUI가 없는 헤드리스(Headless) 리눅스 환경에서 실행됩니다.
• 클라이언트 (Clients): 모든 플레이어는 동등한 클라이언트로서 데디케이티드 서버에 접속합니다. 자신의 입력을 서버로 보내고, 서버가 처리한 결과를 받아 게임 상태를 업데이트합니다.

이 구조는 안정적이고 공평한 멀티플레이어 환경을 제공하며, 대규모 동시 접속이 필요한 MMO, FPS, 배틀로얄 장르에 필수적입니다.

3.2. 내부 구조 및 구현 방식

3.2.1. 서버 애플리케이션

데디케이티드 서버는 클라이언트와 동일한 코어 로직을 공유하지만, 렌더링, 오디오, 입력 처리와 관련된 코드는 제외된 채로 빌드됩니다.

• 헤드리스(Headless) 빌드: 게임 엔진에서는 보통 'Server' 빌드 타겟을 제공합니다. 이 타겟으로 빌드하면 그래픽/사운드 관련 라이브러리는 포함되지 않은, 순수 로직 연산만을 위한 실행 파일이 생성됩니다.
• 최적화: 서버는 수많은 클라이언트의 상호작용을 동시에 처리해야 하므로, CPU 연산과 메모리 사용량에 대해 극도로 최적화되어야 합니다. 멀티스레딩을 활용하여 네트워크 I/O, 물리 연산, AI 계산 등을 병렬로 처리하는 것이 일반적입니다.

3.2.2. 서버 인프라 및 배포

1. 하드웨어/클라우드 선택: 물리 서버를 직접 구매하여 데이터 센터에 배치(On-premise)하거나, AWS, Google Cloud, Azure와 같은 클라우드 서비스 제공업체(CSP)의 가상 머신(VM)을 임대하여 사용합니다.
2. OS 및 환경 설정: 보통 안정성과 성능이 뛰어난 리눅스(e.g., Ubuntu, CentOS)를 서버 OS로 선택합니다. 방화벽 설정, 시스템 라이브러리 설치, 서버 애플리케이션 배포 등의 작업이 이루어집니다.
3. 자동화 및 오케스트레이션:
   • 도커(Docker): 서버 애플리케이션을 컨테이너화하여 실행 환경을 격리하고 배포를 용이하게 합니다.
   • 쿠버네티스(Kubernetes): 수많은 서버 컨테이너의 배포, 스케일링, 관리를 자동화합니다. 플레이어 수요에 따라 동적으로 게임 서버 인스턴스를 생성(Scaling-out)하거나 삭제(Scaling-in)하는 오토스케일링(Autoscaling)을 구현하는 데 핵심적인 역할을 합니다.
   • Agones, Open Match: 구글에서 개발한 오픈소스로, 쿠버네티스 위에서 대규모 게임 서버 플릿(fleet)을 운영하고 매치메이킹을 구현하는 데 특화된 플랫폼입니다.

3.3. 계층별 동작 분석

• 사용자 영역 (User Space):
  • 애플리케이션 계층: 데디케이티드 서버 프로세스가 실행됩니다. 이 프로세스는 여러 클라이언트 소켓으로부터의 입력을 비동기적으로 받아 게임 월드를 업데이트하고, 그 결과를 다시 모든 클라이언트에게 브로드캐스트/멀티캐스트합니다.
  • 오케스트레이션 계층: 쿠버네티스와 같은 컨테이너 오케스트레이션 시스템이 서버 프로세스의 생명 주기를 관리합니다. 매치메이커로부터 "새 게임 세션 생성" 요청을 받으면, 도커 컨테이너를 실행하여 새로운 서버 인스턴스를 시작하고, 외부 접속이 가능하도록 네트워크(IP, Port)를 설정한 후 주소를 매치메이커에게 반환합니다.
• 커널 영역 (Kernel Space):
  • 리슨 서버와 동일하게 TCP/IP 스택을 통해 데이터가 처리됩니다. 하지만 데디케이티드 서버는 고성능 네트워크 카드와 최적화된 커널 설정을 통해 훨씬 더 많은 양의 패킷을 지연 없이 처리할 수 있습니다.
  • I/O 멀티플렉싱: epoll(리눅스)이나 IOCP(윈도우)와 같은 고성용 I/O 모델을 사용하여 단일 스레드 혹은 소수의 스레드만으로 수천 개의 클라이언트 연결을 효율적으로 관리합니다. 이는 select 모델의 성능 한계를 극복하기 위한 필수 기술입니다.

3.4. 장점 및 단점

장점

1. 높은 성능과 안정성: 서버 전용 하드웨어의 모든 리소스를 사용하므로 안정적이고 일관된 성능을 제공합니다.
2. 공평성: 모든 클라이언트는 서버와의 네트워크 지연 시간(ping)에만 영향을 받으므로, '호스트 어드밴티지'가 존재하지 않아 공평한 경쟁 환경을 보장합니다.
3. 확장성: 클라우드와 컨테이너 오케스트레이션 기술을 통해 사용자 수에 맞춰 서버 자원을 유연하게 확장하거나 축소할 수 있습니다.
4. 지속성 (Persistence): 24/7 운영이 가능하므로, 플레이어가 접속을 종료해도 게임 월드가 계속 유지되는 MMO와 같은 장르에 적합합니다.
5. 강화된 보안: 서버가 신뢰할 수 있는 환경(데이터 센터)에서 실행되고, 클라이언트에게 서버의 내부 정보나 다른 클라이언트의 IP가 노출되지 않으므로 치팅과 DDoS 공격에 훨씬 안전합니다.

단점

1. 높은 비용: 서버 하드웨어 구매 또는 임대 비용, 데이터 센터 상면 비용, 네트워크 트래픽 비용 등 지속적인 지출이 발생합니다.
2. 복잡한 설정 및 관리: 서버를 배포, 모니터링, 업데이트하고 보안을 유지하기 위해 전문적인 시스템 관리 지식(DevOps)이 필요합니다.

---

4. 비교 및 최적 사용 시나리오

특징	리슨 서버 (Listen Server)	데디케이티드 서버 (Dedicated Server)
주요 개념	클라이언트가 서버를 겸임	서버 역할만 전담하는 독립 머신
성능/안정성	호스트 PC/네트워크에 크게 의존, 불안정	고성능 하드웨어로 안정적이고 일관됨
비용	저비용 (별도 하드웨어 불필요)	고비용 (서버 임대/구매, 유지보수)
공평성	호스트 어드밴티지 존재 (불공평)	모든 플레이어가 동등 (공평)
확장성	낮음 (최대 4~8명 수준)	높음 (수십 ~ 수천 명 이상 가능)
지속성	호스트가 떠나면 세션 종료	24/7 운영으로 영속적인 월드 가능
보안	치팅, DDoS 공격에 취약	상대적으로 매우 안전
구현/관리	비교적 간단	전문적인 DevOps 지식 필요
추천 장르	Co-op 게임, LAN 파티, 친구 간의 비공개 세션	MMO, FPS, 배틀로얄 등 대규모/경쟁 게임

언제 무엇을 사용해야 하는가?

• 리슨 서버:
  • 개발 초기 단계에서 빠르게 멀티플레이어 기능을 프로토타이핑할 때
  • 4인 이하의 소규모 협동 게임 (e.g., Left 4 Dead, Deep Rock Galactic)
  • 사용자가 직접 서버를 호스팅하는 커뮤니티 기반 게임
• 데디케이티드 서버:
  • 경쟁의 공정성이 매우 중요한 FPS, MOBA, 스포츠 게임 (e.g., Valorant, League of Legends)
  • 수백 명 이상이 동시에 접속하는 대규모 멀티플레이어 게임 (e.g., World of Warcraft, PUBG)
  • 게임 월드가 영속적으로 유지되어야 하는 MMO, 생존 건설 게임 (e.g., Minecraft 서버)
  • 상업적으로 성공하여 안정적인 서비스 제공이 필수적인 모든 온라인 게임

---

5. 구술형 요약

 데디케이티드 서버와 리슨 서버는 멀티플레이어 게임의 핵심 아키텍처로, 가장 큰 차이는 '서버 역할을 누가 담당하는가'에 있습니다.

 

 리슨 서버는 플레이어 중 한 명, 즉 '호스트'가 자신의 컴퓨터로 게임을 즐기면서 동시에 서버 역할까지 수행하는 방식입니다. 별도의 서버 컴퓨터가 필요 없어 비용이 저렴하고 구현이 간단하다는 장점이 있습니다. 그래서 친구들끼리 즐기는 소규모 협동 게임에 주로 사용됩니다. 하지만 호스트의 컴퓨터 사양과 인터넷 상태가 전체 게임 품질을 좌우하고, 호스트가 게임을 끄면 방이 폭파되는 단점이 있습니다. 또한, 호스트는 네트워크 지연이 없어 다른 플레이어보다 유리한 '호스트 어드밴티지' 문제가 발생할 수 있습니다.

 

 반면에 데디케이티드 서버는 게임 플레이에는 참여하지 않고 오직 서버 기능만을 전담하는 독립된 고성능 컴퓨터입니다. 데이터 센터 같은 곳에서 24시간 운영되며, 모든 플레이어는 이 서버에 동등한 조건으로 접속합니다. 따라서 호스트 어드밴티지 없이 공평한 환경을 제공하고, 수백, 수천 명의 동시 접속도 감당할 수 있어 안정성과 확장성이 매우 뛰어납니다. 이런 특징 때문에 대규모 MMO나 경쟁이 중요한 FPS 게임에서는 데디케이티드 서버가 필수적입니다. 다만, 서버를 운영하고 유지보수하는 데 상당한 비용과 전문 인력이 필요하다는 단점이 있습니다.