From 27f3832894d0f3af5e727eff1e5ba568c538fb0b Mon Sep 17 00:00:00 2001 From: qornwh1 Date: Tue, 3 Mar 2026 17:43:32 +0900 Subject: [PATCH] =?UTF-8?q?fix=20:=20=EC=88=98=EC=A0=95=ED=9B=84=20?= =?UTF-8?q?=EB=A6=AC=EB=93=9C=EB=AF=B8=20=EC=A0=95=EB=A6=AC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ANALYSIS.md | 173 ------------- MMORPG_ARCHITECTURE_ANALYSIS.md | 424 -------------------------------- 2 files changed, 597 deletions(-) delete mode 100644 ANALYSIS.md delete mode 100644 MMORPG_ARCHITECTURE_ANALYSIS.md diff --git a/ANALYSIS.md b/ANALYSIS.md deleted file mode 100644 index 5f12d39..0000000 --- a/ANALYSIS.md +++ /dev/null @@ -1,173 +0,0 @@ -# MMO Game Server 코드 분석 및 문제점 보고서 - -## 1. 프로젝트 구조 개요 - -``` -a301_mmo_game_server/ -├── MMOTestServer/ -│ ├── MMOserver/ # 메인 게임 서버 (.NET 9.0) -│ │ ├── Game/ # GameServer (ServerBase 상속) -│ │ ├── Packet/ # PacketCode 열거형 + ProtoBuf 패킷 정의 -│ │ └── RDB/ # DB 연결, Repository, Service, Handler -│ └── ServerLib/ # 공유 라이브러리 -│ ├── Packet/ # PacketSerializer, PacketType -│ ├── RDB/ # IDbConnectionFactory, ARepository, Response -│ └── Service/ # ServerBase, Session, SessionManager -└── ClientTester/ - ├── EchoClientTester/ # 더미 클라이언트 부하 테스터 - └── TempServer/ # 단순 에코 서버 -``` - -### 기술 스택 -| 구성 요소 | 기술 | -|-----------|------| -| 네트워크 | LiteNetLib 2.0.2 (UDP) | -| 직렬화 | protobuf-net 3.2.56 | -| DB | MySQL + Dapper 2.1.66 | -| 설정 | Microsoft.Extensions.Configuration | -| 로깅 | Serilog | -| 프레임워크 | .NET 9.0 | - -### 아키텍처 흐름 -``` -클라이언트 → LiteNetLib UDP → ServerBase (인증/에코) → GameServer (게임 로직) - ↓ - Handler → Service → Repository → MySQL -``` - -### 인증 흐름 -1. 클라이언트 연결 → `pendingPeers`에 등록 -2. Auth 패킷(type=1, 8byte hashKey) 수신 → 인증 처리 -3. 기존 같은 hashKey 세션 있으면 교체 (WiFi→LTE 재연결) -4. `sessions`에 등록 + `OnSessionConnected()` 호출 - ---- - -## 2. 발견된 문제점 - -### [CRITICAL] IDbConnection 리소스 누수 - `ARepository.cs` - -**모든 DB 메서드에서 `IDbConnection`을 `using` 없이 사용.** -MySQL 커넥션이 풀로 반환되지 않아 풀 고갈 → 서버 장애 발생. - -```csharp -// 문제: connection이 Dispose되지 않음 -public async Task GetByIdAsync(int id) -{ - IDbConnection conn = CreateConnection(); // 열림 - return await conn.GetAsync(id); // 반환 후 conn 방치 -} -``` - -**영향받는 메서드:** GetByIdAsync, GetAllAsync, InsertAsync, UpdateAsync, DeleteAsync, QueryAsync, QueryFirstOrDefaultAsync, ExecuteAsync, WithTransactionAsync (총 9개) - -### [CRITICAL] GameServer 추상 메서드에 NotImplementedException - -실제 클라이언트가 인증 후 `OnSessionConnected()`가 호출되면 **서버가 크래시**됨. -에코 테스트는 인증 없이 동작하므로 문제가 노출되지 않았을 뿐. - -```csharp -protected override void OnSessionConnected(NetPeer peer, long hashKey) -{ - throw new NotImplementedException(); // 서버 크래시 -} -``` - -### [HIGH] Auth 패킷 페이로드 검증 주석 처리 - `ServerBase.cs:202-209` - -payload 길이 검증이 주석 처리되어, 8바이트 미만의 잘못된 패킷으로 `BitConverter.ToInt64`에서 **IndexOutOfRangeException** 발생 가능. - -```csharp -// 주석 처리됨 - 악의적 패킷으로 크래시 가능 -// if (payload.Length < sizeof(long)) -// { -// peer.Disconnect(); -// return; -// } -``` - -### [HIGH] MemoryStream 미해제 - `PacketSerializer.cs` - -Serialize/DeserializePayload에서 MemoryStream을 `using` 없이 사용. - -```csharp -public static byte[] Serialize(ushort type, ushort size, T packet) -{ - MemoryStream ms = new MemoryStream(); // Dispose 안됨 - // ... -} -``` - -### [HIGH] NetDataWriter 매 전송마다 할당 - `ServerBase.cs:234-257` - -`SendTo`, `Broadcast`, `BroadcastExcept` 호출 시마다 `new NetDataWriter()` 생성. -초당 수천 패킷 처리 시 GC 압력 급증. - -### [MEDIUM] Serilog 구조적 로깅 구문 오류 - `ServerBase.cs:89` - -`request.ConnectionKey`가 템플릿 변수가 아닌 리터럴 문자열로 들어감. - -```csharp -// 잘못됨: {request.ConnectionKey}는 Serilog 템플릿 변수가 아님 -Log.Debug("해당 클라이언트의 ConnectionKey={request.ConnectionKey}가 동일하지 않습니다", request.Data.ToString()); -``` - -### [MEDIUM] DummyClients.SendPing() BodyLength 불일치 - -`BodyLength`를 `"seq:{seq}".Length`로 계산하지만, 실제 전송 문자열은 `"Echo seq:{seq}"`. - -```csharp -packetHeader.BodyLength = $"seq:{seq}".Length; // "seq:0" = 5 -writer.Put($"Echo seq:{seq}"); // "Echo seq:0" = 10 ← 불일치 -``` - -### [MEDIUM] SessionManager가 GetHashCode()를 키로 사용 - -`session.GetHashCode()`는 객체 해시이므로 의미 있는 키가 아님. `session.HashKey`를 써야 함. -또한 **SessionManager 자체가 어디서도 사용되지 않음**. - -### [MEDIUM] PacketSerializer.Serialize의 size 파라미터 무의미 - -`size`를 인자로 받아 헤더에 쓰지만, 실제 직렬화된 payload 크기와 무관. 호출자가 잘못된 size를 넘기면 역직렬화 시 문제 발생. - -### [LOW] async void 이벤트 핸들러 - `EchoClientTester/Program.cs:32` - -```csharp -service.OnAllDisconnected += async () => // async void 위험 -{ - await cts.CancelAsync(); -}; -``` - -`async void`는 예외가 전파되지 않아 프로세스가 비정상 종료될 수 있음. - -### [LOW] Thread Safety - `ServerBase.cs` - -`pendingPeers`와 `sessions`가 일반 `Dictionary`. LiteNetLib은 단일 스레드 폴링이므로 현재는 문제 없지만, 외부에서 `SendTo/Broadcast`를 호출하면 race condition 가능. - -### [LOW] PacketHeader 클래스가 ClientTester와 MMOserver에 중복 정의 - -동일한 개념의 패킷 헤더가 각 프로젝트에 다른 형태로 존재. - ---- - -## 3. 수정 사항 요약 - -| # | 심각도 | 파일 | 수정 내용 | -|---|--------|------|-----------| -| 1 | CRITICAL | ARepository.cs | 모든 DB 메서드에 `using` 추가 | -| 2 | CRITICAL | GameServer.cs | NotImplementedException → 로그 출력으로 변경 | -| 3 | HIGH | ServerBase.cs | Auth/Echo payload 길이 검증 주석 해제 | -| 4 | HIGH | PacketSerializer.cs | MemoryStream에 `using` 추가 | -| 5 | HIGH | ServerBase.cs | NetDataWriter 재사용 (ThreadLocal 풀) | -| 6 | MEDIUM | ServerBase.cs | Serilog 템플릿 구문 수정 | -| 7 | MEDIUM | DummyClients.cs | BodyLength 계산 수정 | -| 8 | MEDIUM | PacketSerializer.cs | size 파라미터 제거, 자동 계산 | -| 9 | LOW | EchoClientTester/Program.cs | async void 이벤트 안전하게 변경 | -| 10 | HIGH | ServerBase.cs | `isListening`에 `volatile` 추가 (스레드 간 가시성) | -| 11 | HIGH | ServerBase.cs | `Deserialize` 실패 시 null payload 체크 추가 | -| 12 | HIGH | ClientTester/PacketSerializer.cs | ServerLib과 동일한 MemoryStream 누수 + size 파라미터 수정 | -| 13 | MEDIUM | TestHandlers.cs | 모든 핸들러 메서드에 try-catch 추가 (예외 → Error 응답) | -| 14 | HIGH | PacketSerializer.cs (양쪽) | `size` 필드 검증 구현 - 헤더 size > 실제 payload 시 null 반환 | -| 15 | MEDIUM | TestRepository.cs | `DbConnectionFactory` → `IDbConnectionFactory` 인터페이스로 변경 | -| 16 | LOW | DummyClients.cs | `pendingPings` 무한 증가 방지 - 오래된 항목 자동 정리 | diff --git a/MMORPG_ARCHITECTURE_ANALYSIS.md b/MMORPG_ARCHITECTURE_ANALYSIS.md deleted file mode 100644 index af8ce60..0000000 --- a/MMORPG_ARCHITECTURE_ANALYSIS.md +++ /dev/null @@ -1,424 +0,0 @@ -# MMORPG 아키텍처 적합성 분석 보고서 - -## 1. 분석 목적 - -현재 서버 구조가 **다수의 플레이어가 동시 접속하여 실시간으로 상호작용하는 MMORPG**에 적합한지 평가하고, 부족한 부분과 개선 방향을 제시한다. - ---- - -## 2. MMORPG 서버의 핵심 요구사항 - -| 요구사항 | 설명 | -|----------|------| -| 대규모 동시접속 (CCU) | 수백~수천 명이 같은 월드에서 실시간 플레이 | -| 저지연 패킷 처리 | 위치/액션 동기화는 50ms 이내 응답 필요 | -| 관심 영역 관리 (AOI) | 내 주변 플레이어만 패킷을 주고받아야 대역폭 절약 | -| 게임 루프 (Tick) | 고정 주기(예: 20~60Hz)로 월드 상태를 업데이트 | -| 존/채널 분리 | 지역별 부하 분산 및 인스턴스 관리 | -| 엔티티 관리 | 플레이어, NPC, 몬스터 등의 상태를 중앙에서 관리 | -| 서버 간 통신 | 로그인/로비/게임/채팅 등 역할별 서버 분리 | -| 장애 복구 | 서버 크래시 시 세션 복구, 데이터 무결성 보장 | - ---- - -## 3. 현재 구조 평가 - -### 3.1 네트워크 계층 - -**현재 구조:** -``` -단일 ServerBase → 단일 NetManager → 단일 스레드 PollEvents() -``` - -| 항목 | 현재 상태 | MMORPG 요구 | 평가 | -|------|-----------|-------------|------| -| 프로토콜 | UDP (LiteNetLib) | UDP 기반 필수 | **적합** | -| 직렬화 | ProtoBuf | 고성능 바이너리 직렬화 | **적합** | -| 폴링 모델 | 단일 스레드 `while + Task.Delay(1)` | 멀티스레드 or 고성능 이벤트 루프 | **부적합** | -| 패킷 라우팅 | type 기반 if 분기 | 핸들러 매핑 테이블 + 디스패처 | **부적합** | - -**문제점:** - -- **단일 스레드 병목**: `PollEvents()`가 단일 스레드에서 모든 패킷을 처리한다. CCU 500 이상에서 패킷 큐가 쌓이면 처리 지연이 발생한다. MMORPG에서 플레이어 100명이 초당 10패킷을 보내면 초당 1,000패킷인데, `HandlePacket` 내부에서 DB 조회 같은 블로킹 작업이 끼면 전체 루프가 멈춘다. - -- **패킷 디스패처 없음**: `HandlePacket(peer, hashKey, type, payload)` 하나로 모든 게임 패킷을 처리해야 한다. 패킷 종류가 17개인 현재도 거대한 switch문이 필요하며, 패킷이 늘어날수록 유지보수가 어려워진다. - -- **`Task.Delay(1)` 해상도**: Windows에서 실제로 ~15ms 간격으로 폴링된다. 60Hz 게임 루프가 필요한 MMORPG에서는 16.6ms마다 정확한 틱이 필요한데, 현재 구조로는 불가능하다. - ---- - -### 3.2 세션 관리 - -**현재 구조:** -``` -Dictionary sessions (hashKey → peer) -Dictionary pendingPeers (peerId → peer) -``` - -| 항목 | 현재 상태 | MMORPG 요구 | 평가 | -|------|-----------|-------------|------| -| 자료구조 | 일반 Dictionary | ConcurrentDictionary 또는 락 기반 | **위험** | -| 인증 | 8byte hashKey raw 전송 | JWT/OAuth + 토큰 갱신 | **부적합** | -| 세션 정보 | hashKey + NetPeer만 | 플레이어 ID, 존, 위치, 상태 등 | **부족** | -| 재연결 | hashKey 기반 피어 교체 | 세션 상태 전체 복구 | **부분 구현** | - -**문제점:** - -- **인증 보안 취약**: 8바이트 hashKey를 평문으로 보내면, 패킷 스니핑으로 다른 사람의 세션을 탈취할 수 있다. MMORPG는 JWT 같은 시간 제한 토큰 + 서버 측 검증이 필수다. - -- **세션에 게임 상태 없음**: `Session` 클래스에 `HashKey`와 `Peer`만 있다. MMORPG에서는 세션이 플레이어의 현재 존, 위치, 파티, 인벤토리 캐시 등을 들고 있어야 패킷 처리 시 매번 DB를 조회하지 않는다. - -- **재연결 시 상태 미복구**: WiFi→LTE 전환 시 피어만 교체하고 게임 상태(존, 위치, 버프 등)를 클라이언트에 재전송하는 로직이 없다. - ---- - -### 3.3 게임 루프 & 월드 관리 - -**현재 구조:** -``` -없음. GameServer 클래스는 빈 껍데기. -``` - -| 항목 | 현재 상태 | MMORPG 요구 | 평가 | -|------|-----------|-------------|------| -| 게임 루프 | 없음 | 고정 틱 (20~60Hz) | **미구현** | -| 존/맵 관리 | 없음 | Zone/Channel/Instance 분리 | **미구현** | -| AOI (관심 영역) | 없음 | Grid/Quadtree 기반 영역 관리 | **미구현** | -| 엔티티 시스템 | 없음 | Player/NPC/Monster 상태 관리 | **미구현** | -| 물리/충돌 | 없음 | 서버 권위 이동 검증 | **미구현** | - -**문제점:** - -이것이 가장 큰 갭이다. MMORPG 서버의 핵심인 **게임 루프**가 존재하지 않는다. - -- **게임 루프 없음**: 현재는 "클라이언트가 패킷을 보내면 서버가 반응"하는 순수 리액티브 구조다. MMORPG는 클라이언트 입력이 없어도 서버가 자체적으로 NPC AI, 몬스터 이동, 버프 타이머, 리스폰 등을 주기적으로 처리해야 한다. - -- **AOI 없음**: 현재 `Broadcast()`는 **모든 접속자**에게 패킷을 보낸다. 플레이어 100명이 모두 움직이면 초당 `100 × 100 = 10,000`패킷이 발생한다. 1,000명이면 `1,000,000`패킷이다. AOI 없이는 CCU 50만 넘어도 대역폭이 폭발한다. - -- **존/채널 없음**: 모든 플레이어가 하나의 `sessions` Dictionary에 평면적으로 존재한다. "마을에 있는 플레이어"와 "던전에 있는 플레이어"를 구분할 방법이 없다. - ---- - -### 3.4 데이터베이스 계층 - -**현재 구조:** -``` -Handler → Service → Repository(Dapper) → MySQL -매 요청마다 새 커넥션 (풀링은 MySQL 드라이버에 위임) -``` - -| 항목 | 현재 상태 | MMORPG 요구 | 평가 | -|------|-----------|-------------|------| -| ORM | Dapper (경량) | 경량 ORM 적합 | **적합** | -| 커넥션 풀링 | MySQL 드라이버 위임 | 명시적 풀 관리 | **보통** | -| 캐싱 | 없음 | Redis/인메모리 캐시 필수 | **부적합** | -| 비동기 | async/await | 논블로킹 필수 | **적합** | - -**문제점:** - -- **캐시 계층 없음**: 플레이어가 스킬을 쓸 때마다 DB에서 스탯을 읽으면 게임이 안 된다. MMORPG는 로그인 시 플레이어 데이터를 메모리에 올리고, 주기적으로 DB에 저장(Write-Back)하는 구조가 필수다. - -- **게임 루프에서 DB 호출 위험**: 현재는 패킷 핸들러에서 직접 DB를 호출하는 구조인데, 게임 루프 스레드에서 DB await를 하면 틱 지연이 발생한다. 게임 로직과 DB I/O는 반드시 분리해야 한다. - ---- - -### 3.5 서버 구조 (스케일링) - -**현재 구조:** -``` -단일 프로세스, 단일 서버 -``` - -| 항목 | 현재 상태 | MMORPG 요구 | 평가 | -|------|-----------|-------------|------| -| 서버 분리 | 모놀리식 단일 서버 | 로그인/로비/게임/채팅 분리 | **부적합** | -| 수평 확장 | 불가 | 존별 서버 분산 | **부적합** | -| 메시지 큐 | 없음 | Redis Pub/Sub, RabbitMQ 등 | **미구현** | -| 로드밸런싱 | 없음 | 게이트웨이 + 존 서버 라우팅 | **미구현** | - -**문제점:** - -- **단일 서버 한계**: 하나의 `ServerBase` 인스턴스가 인증, 에코, 게임 패킷을 모두 처리한다. CCU가 늘어나면 서버를 추가할 방법이 없다. - -- **서버 간 통신 없음**: "A 서버의 플레이어가 B 서버의 플레이어에게 귓속말"이 불가능하다. 파티, 길드, 거래 등 크로스 존 기능을 구현할 수 없다. - ---- - -## 4. 종합 평가 - -### 적합성 점수 - -| 영역 | 점수 (10점) | 비고 | -|------|:-----------:|------| -| 네트워크 프로토콜 | 8 | UDP + ProtoBuf 조합 우수 | -| 패킷 처리 파이프라인 | 3 | 단일 스레드, 디스패처 없음 | -| 세션 / 인증 | 3 | 보안 취약, 게임 상태 없음 | -| 게임 루프 | 0 | 미구현 | -| 월드 / 존 관리 | 0 | 미구현 | -| AOI (관심 영역) | 0 | 미구현 | -| 엔티티 시스템 | 0 | 미구현 | -| DB / 캐시 | 4 | Dapper 좋으나 캐시 없음 | -| 서버 확장성 | 1 | 단일 프로세스 모놀리식 | -| **종합** | **2.1 / 10** | | - -### 결론 - -> 현재 구조는 **에코 서버 / 소규모 매칭 게임 (10~20명)** 수준에 적합하며, -> **MMORPG로 사용하기에는 핵심 시스템 대부분이 미구현** 상태이다. -> -> 네트워크 기반(LiteNetLib + ProtoBuf)과 DB 레이어(Dapper + Repository 패턴)는 -> 좋은 출발점이지만, 그 위에 올라가야 할 게임 서버 계층이 빠져 있다. - ---- - -## 5. MMORPG 전환을 위한 로드맵 - -### Phase 1: 게임 루프 & 엔티티 시스템 (최우선) - -``` -현재: 클라이언트 패킷 → ServerBase → GameServer(빈 껍데기) -목표: 클라이언트 패킷 → 입력 큐 → GameLoop(고정 틱) → 월드 상태 업데이트 → 브로드캐스트 -``` - -**구현 항목:** - -1. **고정 틱 게임 루프** - - `Stopwatch` 기반 정밀 타이머로 50ms(20Hz) 또는 33ms(30Hz) 간격 틱 - - 패킷 수신은 입력 큐에 적재, 게임 루프에서 꺼내서 처리 - - 네트워크 I/O와 게임 로직 스레드 분리 - -2. **엔티티 관리자** - - `GamePlayer`, `GameNpc`, `GameMonster` 등 인게임 엔티티 클래스 - - 위치, 상태, 스탯을 서버 메모리에서 관리 - - 로그인 시 DB → 메모리 로드, 주기적으로 메모리 → DB 저장 - -3. **패킷 디스패처** - - `Dictionary>` 핸들러 매핑 테이블 - - 패킷 타입별 핸들러 자동 등록 (어트리뷰트 또는 초기화 시 등록) - -``` -예시 구조: -GameLoop -├── ProcessInputQueue() // 클라이언트 패킷 처리 -├── UpdateNpcAI() // NPC 행동 업데이트 -├── UpdateBuffTimers() // 버프/디버프 타이머 -├── UpdateRespawns() // 몬스터 리스폰 -├── BroadcastWorldState() // 변경된 상태만 클라이언트에 전송 -└── SaveDirtyEntities() // 변경된 엔티티 DB 저장 (N틱마다) -``` - -### Phase 2: 존/채널 & AOI - -**구현 항목:** - -1. **존 시스템** - - `Zone` 클래스: 해당 존의 플레이어/NPC/몬스터 목록 관리 - - 존 진입/퇴장 시 엔티티 이동 - - 인스턴스 던전은 동적 Zone 생성/파괴 - -2. **AOI (Area of Interest)** - - 그리드 기반 관심 영역: 맵을 NxN 셀로 나누고, 플레이어가 속한 셀 + 인접 셀만 패킷 전송 - - `Broadcast()` → `BroadcastToNearby(position, radius, data)`로 교체 - - CCU 1,000명 기준 패킷 수: 1,000,000 → ~50,000 (95% 감소) - -``` -예시: -┌───┬───┬───┐ -│ │ B │ │ B는 A의 AOI 범위 안 → 패킷 수신 -├───┼───┼───┤ -│ │ A │ │ A가 이동 패킷 발신 -├───┼───┼───┤ -│ │ │ C │ C는 AOI 범위 밖 → 패킷 안 받음 -└───┴───┴───┘ -``` - -### Phase 3: 인증 강화 & 세션 확장 - -**구현 항목:** - -1. **JWT 기반 인증** - - 로그인 서버에서 JWT 발급 → 게임 서버에서 검증 - - hashKey 대신 토큰 기반 인증, 만료/갱신 처리 - -2. **세션 확장** - ```csharp - public class GameSession - { - public long AccountId { get; init; } - public NetPeer Peer { get; set; } - public GamePlayer? Player { get; set; } // 인게임 엔티티 참조 - public Zone? CurrentZone { get; set; } // 현재 존 - public DateTime LastActivity { get; set; } // AFK 감지 - } - ``` - -3. **재연결 상태 복구**: 재연결 시 현재 존, 위치, 파티 상태를 클라이언트에 재전송 - -### Phase 4: 캐시 & DB 최적화 - -**구현 항목:** - -1. **인메모리 캐시 도입** - - 접속 중인 플레이어 데이터는 메모리에 상주 - - Write-Back 패턴: 변경 사항을 큐에 쌓고 N초마다 일괄 DB 저장 - - 아이템/스킬 테이블 등 정적 데이터는 서버 시작 시 로드 - -2. **DB I/O 분리** - - 게임 루프 스레드에서 직접 DB 호출 금지 - - 별도 DB Worker 스레드에서 저장 큐 처리 - - 긴급 저장(거래, 결제)만 즉시 처리 - -### Phase 5: 서버 분산 아키텍처 - -**구현 항목:** - -1. **서버 역할 분리** - ``` - 클라이언트 - ↓ - 게이트웨이 서버 (인증 + 라우팅) - ├── 로비 서버 (매칭, 파티, 채팅) - ├── 게임 서버 A (마을 존) - ├── 게임 서버 B (필드 존) - ├── 게임 서버 C (던전 인스턴스) - └── DB/캐시 서버 (Redis + MySQL) - ``` - -2. **서버 간 메시지 큐** - - Redis Pub/Sub 또는 RabbitMQ로 서버 간 통신 - - 크로스 존 기능: 귓속말, 길드, 파티 초대, 거래 - -3. **수평 확장** - - 존 단위로 게임 서버 인스턴스 추가 - - 게이트웨이가 플레이어를 적절한 존 서버로 라우팅 - ---- - -## 6. 현재 코드에서 재사용 가능한 부분 - -현재 코드가 완전히 쓸모없는 것은 아니다. 아래 부분은 그대로 또는 약간의 수정으로 재사용 가능하다. - -| 컴포넌트 | 재사용성 | 비고 | -|----------|:--------:|------| -| LiteNetLib 기반 네트워크 | **높음** | UDP 전송 계층으로 그대로 사용 | -| ProtoBuf 패킷 정의 | **높음** | PacketBody.cs의 17개 패킷 구조 재사용 | -| PacketSerializer | **높음** | 직렬화/역직렬화 로직 그대로 사용 | -| ARepository + Dapper | **높음** | DB 계층 그대로 사용 | -| ServerBase 인증 흐름 | **보통** | JWT로 교체하되 pending → auth 흐름은 유지 | -| Session/재연결 로직 | **보통** | 확장 후 재사용 | -| Docker/compose 설정 | **높음** | 배포 파이프라인 그대로 사용 | - ---- - -## 7. 권장 우선순위 요약 - -``` -[즉시] Phase 1: 게임 루프 + 엔티티 시스템 + 패킷 디스패처 - → 이것 없이는 어떤 게임 로직도 구현 불가 - -[단기] Phase 2: 존/채널 + AOI - → CCU 50명만 넘어도 Broadcast 폭발 - -[중기] Phase 3: 인증 강화 + 세션 확장 - → 보안과 재연결 안정성 - -[중기] Phase 4: 캐시 + DB 분리 - → 성능 병목 해소 - -[장기] Phase 5: 서버 분산 - → CCU 1,000+ 대응 -``` - ---- - -## 8. 현재 수용 가능 인원 추정 - -### 처리 성능 (단일 스레드 기준) - -``` -PollEvents() 틱 간격: ~15ms (Task.Delay(1) Windows 해상도) -초당 틱 수: ~66회 -틱당 처리 가능 시간: 15ms -``` - -| 시나리오 | 패킷 1개 처리 시간 | 유저당 초당 패킷 | 예상 CCU | -|----------|-------------------|-----------------|----------| -| 에코 테스트 (현재) | ~0.01ms | 10 | **~1,000명** | -| 간단한 게임 로직 | ~0.1ms | 10 | **~500명** | -| 실제 MMORPG 로직 | ~1ms | 10 | **~50명** | -| DB 호출 포함 | ~5ms | 10 | **~10명** | - -> HandlePacket 안에 뭘 넣느냐가 전부다. -> 지금 빈 껍데기라서 수백 명이 되는 거지, 로직이 들어가는 순간 급락한다. - -### 개선 시 수용 인원 (단일 서버) - -| 개선 단계 | 핵심 변경 | 예상 CCU | -|-----------|-----------|----------| -| **현재** | 단일 스레드, 동기 처리 | 30~50명 | -| **Phase 1** | 게임 루프 + 입력 큐 분리 | **200~500명** | -| **Phase 1 + 2** | + AOI 적용 | **1,000~2,000명** | -| **Phase 1~4** | + 캐시 + DB 분리 | **3,000~5,000명** | -| **Phase 5** | 멀티 서버 분산 | **서버당 5,000 × N대** | - -### 개선별 효과 설명 - -**Phase 1 (게임 루프)** - 4~10배 향상 -``` -현재: 패킷 100개 → 하나씩 순차 처리 (100번 컨텍스트 스위칭) -개선: 패킷 100개 → 큐에 모아서 → 틱 1번에 일괄 처리 (배치) -``` - -**Phase 2 (AOI)** - 가장 극적인 효과 -``` -현재: 유저 1,000명 이동 → 브로드캐스트 1,000 × 1,000 = 1,000,000 패킷/틱 -개선: 유저 1,000명 이동 → AOI 반경 내 ~20명에게만 = 20,000 패킷/틱 (98% 감소) -``` - -> AOI가 가장 임팩트가 크다. 네트워크 부하가 O(N²) → O(N)으로 바뀐다. - ---- - -## 9. 하드웨어 & 네트워크 요구사항 - -### M4 Mac Mini 깡통 (16GB RAM) 기준 - -| 리소스 | M4 Mac Mini | 서버 필요량 (CCU 3,000) | 여유 | -|--------|-------------|------------------------|------| -| CPU | 10코어 (4P+6E) | 게임 루프 1~2코어 + 네트워크 1코어 | **충분** | -| RAM | 16GB | 유저당 ~10KB × 3,000 = 30MB + 앱 ~500MB | **매우 충분** | -| 디스크 | 256GB SSD | MySQL + 로그 | **충분** | - -> M4 싱글코어 성능이 서버용 Xeon보다 빠르다. -> 게임 루프는 본질적으로 싱글스레드 위주라서 M4로 CCU 3,000~5,000 처리 가능. - -### 네트워크 대역폭 계산 (AOI 적용 후) - -``` -유저 1명이 받는 패킷: -- 주변 플레이어 이동: ~20명 × 30Hz × 50byte = 30KB/s -- NPC/몬스터 상태: ~10개 × 10Hz × 40byte = 4KB/s -- 기타 (채팅, 파티): = 1KB/s -────────────────────────────────────────────────────── -유저 1명 ≈ 35KB/s (다운) + 5KB/s (업) = 40KB/s -``` - -| CCU | 필요 대역폭 | 필요 회선 | -|-----|-------------|-----------| -| 100명 | 4MB/s (32Mbps) | 100Mbps 충분 | -| 500명 | 20MB/s (160Mbps) | 1Gbps 필요 | -| 1,000명 | 40MB/s (320Mbps) | 1Gbps 필요 | -| 3,000명 | 120MB/s (960Mbps) | 1Gbps 빡빡 | -| 5,000명 | 200MB/s (1.6Gbps) | 2.5Gbps 이상 | - -### 환경별 결론 - -| 환경 | 병목 | 현실적 CCU | -|------|------|-----------| -| M4 Mac Mini + 가정용 기가 인터넷 | 업로드 속도, NAT 테이블 | **100~500명** | -| M4 Mac Mini + IDC/클라우드 1Gbps 보장 | 대역폭 | **2,000~3,000명** | -| 클라우드 서버 + 2.5Gbps 이상 | CPU | **3,000~5,000명** | - -> **병목은 Mac Mini 성능이 아니라 네트워크다.** -> CPU/RAM은 남아돌지만, 가정용 인터넷은 업로드 제한(보통 다운의 1/10)과 -> 공유기 NAT 테이블 한계가 있다.