[TIL] Listen Server 기반 프로토타입 빌드 패키징 정리

1오늘 한 일

오늘은 팀원들과 함께 NeoSanctum의 프로토타입 단계 빌드 패키징을 진행했다. 핵심은 단순히 실행 파일을 뽑는 것이 아니라, 현재 프로젝트의 멀티플레이 구조가 Dedicated Server 방식인지, Listen Server 방식인지를 먼저 파악하고 그에 맞는 패키징 전략을 선택하는 것이었다.

이번 패키징의 목적은 최종 배포가 아니라 아래 항목들을 검증하는 것이었다.

1

패키징된 빌드가 실제 실행 파일 환경에서 정상 실행되는지 확인

2

호스트가 방을 열고 다른 클라이언트가 접속할 수 있는지 확인

3

최근 머지된 캐릭터 관련 수정 사항이 패키징 빌드에서도 정상 반영되는지 확인

4

프로토타입 단계의 기본 플레이 흐름(캐릭터·드론 부착·기본 전투)을 실행 파일에서 검증

에디터 PIE 환경에서는 잘 동작하더라도 실제 패키징 빌드에서는 경로 문제, 에셋 누락, 초기화 순서 문제 등이 다르게 드러날 수 있다. 프로토타입 단계에서도 중간중간 패키징 테스트가 필요하다.

---

2Dedicated Server vs Listen Server

처음에는 멀티플레이 게임이기 때문에 서버와 클라이언트를 따로 패키징해야 하는지 고민했다. 하지만 현재 프로젝트는 Dedicated Server가 아닌 Listen Server 구조다.

구분	Dedicated Server	Listen Server
서버 실행 파일	서버 전용 빌드 별도 필요	일반 게임 실행 파일 사용
호스트 플레이어	서버에서 직접 플레이하지 않음	호스트가 직접 플레이
구조	서버와 클라이언트 완전 분리	호스트가 서버 + 클라이언트 역할 동시 수행
패키징	서버 빌드 / 클라이언트 빌드 분리 필요	Standalone 패키징으로 테스트 가능

현재 구조는 한 명이 호스트가 되어 게임을 실행하고, 나머지 팀원이 그 호스트에게 접속하는 방식이다. 따라서 Dedicated Server처럼 서버 빌드와 클라이언트 빌드를 분리하는 방식은 현재 단계에 맞지 않았다.

---

3처음에 한 실수 — Dedicated Server 방식으로 패키징

처음에는 멀티플레이 게임이니까 당연히 서버와 클라이언트를 분리해서 패키징해야 한다고 생각했다. 그래서 처음 시도는 Dedicated Server 방식 그대로 진행했다.

1

서버 전용 빌드(WindowsServer) 따로 패키징

2

클라이언트 전용 빌드(WindowsClient) 따로 패키징

3

서버 빌드를 실행하고, 클라이언트 빌드로 해당 서버에 접속 시도

문제 발생: 접속은 됐지만 실제로 현재 프로젝트 구조와 맞지 않아 제대로 동작하지 않았다. 현재 프로젝트는 Dedicated Server를 전제로 작성된 코드가 아니기 때문에, 서버 전용 빌드에서 예상치 못한 초기화 문제와 흐름 오류가 발생했다. 호스트가 직접 플레이하는 구조임에도 불구하고 서버 빌드에는 플레이어 관련 로직이 빠져 있어서 의도한 대로 테스트할 수 없었다.

이 시점에서 다시 생각해보니, 현재 프로젝트에서는 호스트 플레이어가 직접 게임에 참여하고 있었다. 즉 이미 Listen Server 구조로 설계되어 있었던 것이다. Dedicated Server 방식은 우리 프로젝트 구조와 애초에 맞지 않는 선택이었다.

---

4Standalone으로 전환한 이유

Listen Server에서는 호스트의 게임 실행 파일이 서버 역할도 함께 수행한다. 호스트 플레이어는 별도의 서버 프로그램을 실행하는 것이 아니라, 일반 게임 빌드를 실행한 뒤 그 안에서 세션을 열어 다른 클라이언트의 접속을 받는다.

따라서 방향을 바꿔 아래 방식으로 재패키징했다.

1

서버 전용 빌드 따로 생성하지 않음

2

클라이언트 전용 빌드 따로 생성하지 않음

3

일반 Standalone 게임 빌드 단일 생성 → 팀원 전원이 동일한 빌드 사용

4

호스트가 빌드를 실행 후 세션을 열어 Listen Server 역할 수행

5

나머지 클라이언트가 같은 빌드로 호스트에 접속 → 정상 동작 확인

이 방식으로 전환하자 기존에 발생하던 초기화 문제와 흐름 오류가 사라졌다. 테스트 비용도 가장 낮고, 팀원들이 빠르게 빌드를 받아 실행해볼 수 있는 현실적인 방법이었다.

---

5이번 패키징에서 확인한 것

이번 패키징은 완성 빌드 목적이 아니라 현재 개발 흐름이 실제 빌드에서도 유지되는지 검증하는 것이었다.

확인 항목	내용
빌드 실행 여부	에디터가 아닌 실제 실행 파일에서 게임이 정상 실행되는지 확인
Listen Server 흐름	호스트가 세션을 열고 다른 클라이언트가 접속할 수 있는지 확인
최근 머지 반영	캐릭터 관련 hotfix가 패키징 빌드에서도 정상 동작하는지 확인
기본 플레이 흐름	캐릭터 동작, 드론 부착, 기본 전투 테스트가 빌드에서 가능한지 확인

---

6앞으로 공부할 내용

이번 패키징 작업을 계기로 Unreal Engine의 멀티플레이 패키징 흐름을 더 깊게 정리할 예정이다.

주제	학습 방향
패키징 구조	Listen Server / Dedicated Server 패키징 차이, Standalone 패키징과 서버 전용 패키징 비교
세션 흐름	패키징 빌드에서 세션 생성 / 접속 흐름, 프로토타입 단계에서 필요한 최소 패키징 범위
전환 준비	추후 Dedicated Server로 전환할 때 필요한 구조 변경 사항
GAS × 멀티플레이	Prediction 구조, TargetData 기반 히트스캔 처리, 서버 검증 후 GameplayEffect 적용, GameplayCue 로컬 피드백 구성

---

7오늘의 회고

새로 배운 것	멀티플레이 빌드 패키징 전에 프로젝트의 네트워크 구조를 먼저 파악해야 한다. Listen Server 구조에서는 호스트의 일반 게임 빌드가 서버 역할을 겸하므로, Standalone 패키징 하나로 호스트/클라이언트 흐름을 모두 검증할 수 있다.
어려웠던 점	처음에 멀티플레이 = 서버/클라이언트 분리라고 단순하게 생각해 Dedicated Server 방식으로 패키징을 진행했다. 서버 전용 빌드에 플레이어 관련 로직이 빠져 있어 의도한 대로 동작하지 않았고, 그제야 구조가 맞지 않다는 것을 알아챘다.
기억할 핵심	Listen Server = 호스트가 서버 + 클라이언트 동시 수행 → Standalone 패키징으로 충분. Dedicated Server 방식 패키징은 서버에 플레이어 로직이 없어 Listen Server 프로젝트와 구조적으로 맞지 않는다. 패키징 방식 선택 전에 반드시 네트워크 아키텍처를 확인할 것.
다음 목표	Listen Server / Dedicated Server 패키징 흐름을 문서로 정리하고, 추후 Dedicated Server로 전환할 때 어떤 구조 변경이 필요한지 미리 파악해두기. GAS Prediction 구조와 서버 검증 흐름도 병행 학습 예정.