Unity 네트워크 구조 정리 - 호스트 방식 vs 데디케이트 서버
Unity 네트워크 구조 정리 - 호스트 방식 vs 데디케이트 서버
왜 정리하냐
멀티플레이 게임을 만들려면 네트워크 구조를 먼저 정해야 한다. 큰 틀에서 보면 딱 두 가지 방식으로 나뉜다.
- 호스트 방식 (P2P / Listen Server)
- 데디케이트 서버 방식 (Dedicated Server)
1-1.P2P(호스트 방식)
한 줄 정의: 중앙 서버 없이 플레이어끼리 직접 통신(Peer To Peer)
장점
- 중앙서버가 없기 때문에 중앙서버가 변조되거나 해킹에 노출되지 않음(이 장점을 살린것이 블록체인)
- 서버 인프라 필요 없음 -> 비용 필요X
- 피어 수가 늘어나면 파일 전송 속도가 올라감
단점
- 모든 클라이언트가 서버 역할을 겸함으로 자신의 IP주소가 다른 클라이언트에 노출됨
- 치팅 방지가 거의 불가능 (각자 자기 클라이언트에서 판정하니 조작 여지가 큼)
- 실무에서 거의 안 씀 → 라이브러리/엔진 지원이 빈약함
- 작업의 분담으로 인해 원활한 서비스를 위해서는 클라이언트 컴퓨터의 성능이 높아야 함
- 피어 수가 적으면 전송 속도가 떨어짐
예시 게임
- 던전앤파이터, 스트리트 파이터, 스타크래프트
1-2.Listen Server(호스트 방식)
한 줄 정의: 클라이언트 한 명이 서버도 겸함
장점
- 호스트가 중심이므로 최소한 판정 기준은 하나로 통일됨(호스트 제외)
- 서버 인프라 필요 없음 -> 비용 필요X
- 구현 비교적 간단
단점
- 호스트의 PC/인터넷 성능이 전체 게임 성능을 결정
- 호스트 이탈 시, 해당 로직 구현 없으면 방이 터짐(마이그레이션 로직)
- 호스트가 곧 서버 권한을 가지므로 호스트 클라이언트의 치팅에 취약
예시 게임
- Left4Dead2, Meccha Chameleon, Palworld
2.데디케이트 서버 방식 (Dedicated Server)
한 줄 정의: 게임 로직만 전담해서 항상 켜져 있는 독립된 서버
장점
- 서버 성능이 플레이어 환경과 무관 → 안정적인 성능
- 클라이언트는 입력만 보내고 서버가 검증 → 모드/운영 관리 용이(추방, 세팅, 플러그인)
- 플레이어가 없어도 월드 상태 유지 가능
단점
- 서버 운영 비용 발생
- 구현 복잡도 높음
- 지역별 레이턴시, 로드밸런싱 같은 운영 이슈
예시 게임
- 오버워치, League Of Legends, PUBG
3.비교 요약
| 구분 | Listen Server | P2P | Dedicated Server |
|---|---|---|---|
| 비용 | 낮음 | 낮음 | 높음 |
| 치팅 방지 | 약함 | 매우 약함 | 강함 |
| 성능 안정성 | 호스트 의존 | 각 클라이언트 의존 | 서버 스펙에 따라 일정 |
| 구현 난이도 | 낮음~중간 | 중간 | 중간~높음 |
| 호스트 이탈 리스크 | 있음 | 있음 | 없음 |
| 실무 채택도 | 높음 | 매우 낮음 | 높음 |
표 너무 못생겼다
오늘의 요약
소규모/포트폴리오 프로젝트면 Listen Server로 시작하는 게 합리적. 나중에 필요하면 데디케이트로 전환.
다음에 볼만한 것
권위 모델 중간 지점
- Shared 모드 (Photon Fusion Shared Mode 등 - 권위 분산/로테이션 방식)
전송/연결 방식 (별도 축)
- Relay 서버 (Unity Relay, Photon Relay - NAT 우회 중계)
실제 서비스/SDK 비교
- Steam(Steamworks) 서버 방식
- Photon Fusion의 Host Mode / Client-Server Mode / Shared Mode 차이
- EOS(Epic Online Services) 네트워크 구조
