NetEase 게임회사 기술스택
- Unity용 고수준 네트워크 프레임워크
- UNet의 후계자이자 “Unity C#으로 짜여진 고수준 RPC+동기화 시스템”
- 주로 소규모 개발팀, 인디, 프로토타이핑용
- 구조:
1
2
3
Unity (C#)
└─ Mirror (고수준 동기화, 서버-클라 구조, 간편한 RPC)
- Unity와 잘 통합됨
- 빠르게 네트워크 게임 프로토타이핑 가능
- 대규모 게임에선 확장성, 성능 한계 있음 (많은 객체/플레이어 시)
- 낮은 수준의 네트워크 통신 라이브러리 (C)
- 신뢰성 있는 UDP 기반 통신 제공
- Godot, Warframe, 게임 엔진 서버단 등에서 많이 사용됨
- 구조:
1
2
3
4
클라이언트 (Unity, C++, Rust 등)
└─ ENet (낮은 수준의 UDP 프로토콜)
└─ 서버 (커스텀 서버, C++ 등에서 동작)
- 빠르고 신뢰성 있는 커스텀 통신 가능
- MMO, 대규모 PVP 등에 적합
- 직접 동기화 구조/로직 구현해야 함
- Unity와의 통합은 직접 구현 필요 (ex. C++ DLL or C# 바인딩)
- Unity + Mirror? → ❌ 거의 불가능
- → Mirror는 성능과 확장성 한계 때문에 대형 게임에는 안 쓰임
- → 보안 취약점, 클라이언트 기반 한계 존재
- Unity + ENet or 자체 UDP → ✅ 가능성 매우 높음
- → NetEase는 자체 C++ 네트워크 레이어 혹은 ENet 같은 경량 UDP 솔루션 기반 구조 사용
- → Unity는 렌더링/입력 처리용, 네트워크는 C++ 서버가 담당
🎯 요약 비교
| 항목 | Mirror | ENet |
|---|---|---|
| 위치 | Unity 내부 | Unity 외부 (C++ 서버 등) |
| 계층 | 고수준 동기화 | 저수준 UDP 통신 |
| 성격 | RPC, 동기화, 편의 중심 | 빠르고 세밀한 커스텀 통신 |
| 확장성 | 인디/소규모 적합 | 대규모 게임 적합 |
| NetEase급 사용? | ❌ | ✅ (또는 자체 ENet-like UDP 사용) |
✍️ 결론:
SMC는 Mirror를 사용했을 가능성은 거의 없고, ENet 또는 NetEase 자체 UDP 네트워크 솔루션을 사용했을 가능성이 매우 높습니다.
메카시티라는 모바일게임을 몇년 전에 재밌게 했던 기억때문에 똑같이 만들어 보고 싶어서 2년 전에 이렇게 스크린샷을 찍고 서버 선택 화면까지는 ui를 따라 만들었었습니다..
그래서 fishnet이라는 네트워킹 프레임워크를 다뤄보고 mirror, netcode 등 방랑하다가 unreal engine도 살짝 건들여보고, godot도 건들여봤었는데요. ** **요새 네트워킹 프레임워크를 가지고 간단한 온라인게임을 만들어보려는데 손에 잡히지 않고 어려운것 같아, 가장 하이레벨로 코드가 정리되어 있어서 자유자재로 커스터마이징 하기 좋겠다는 판단이 들어서 fishnet으로 다시 돌아왔었습니다. (fishnet은 **한달 2달러인 유료구독입니다.)** ** **그런데 이번에 gpt에게 제가 따라만들려는 그 메카시티 fps 게임이 어느 기술스택으로 만들어졌을지 궁금해서 물어봤습니다. ** **그런데 의외의 답변이었습니다. ** **자체 서버 프레임워크를 사용하고 있고, 그렇게 커스텀 프레임워크가 다른 프레임워크(유니티와 바인딩된 서버 프레임워크)들 보다 성능이 좋다는 것이었습니다. ** **
| 항목 | ObjectNet | Mirror | FishNet | Netcode for GameObjects (NGO) | ENet |
|---|---|---|---|---|---|
| 🧠 개발 언어 | C# | C# | C# | C# | C (바인딩 필요) |
| 🧱 엔진 통합 | Unity 전용 | Unity 전용 | Unity 전용 | Unity 공식 | 비 Unity 전용 (저수준 UDP) |
| 📦 설치 방식 | 유니티 패키지 (비공식) | Unity 패키지 (Asset Store/Git) | Unity 패키지 | Unity 패키지 (Unity 공식) | C/C++ 라이브러리 |
| 🛠️ 구조 | 고수준 + 동기화 | 고수준 + 유연한 동기화 | 고성능 + 확장형 | Unity 권장 아키텍처 | 저수준 신뢰성 UDP |
| 🚀 퍼포먼스 | 중간 (실험적) | 중간 | 상대적으로 우수함 | 최근 개선 중 (완성도 낮음) | 매우 우수 (엔진급) |
| 🔧 서버 권한 | 가능 (직접 구현) | 가능 | 기본 Server Authority | 기본 Server Authority | 직접 구현 필요 |
| 🎯 클라이언트 예측 | ❌ 없음 | ❌ 수동 구현 | ✅ 일부 기본 제공 | ❌ 거의 없음 | ❌ 직접 구현 |
| 📡 트랜스포트 | Mirror 기반(Photon 등도 가능) | Telepathy/UDP 등 | 자체 트랜스포트 (KCP 등 지원) | Unity Transport | 자체 UDP |
| 🧩 특징 | 간단한 구조, 자유도 높음 | 가장 널리 쓰임, 커뮤니티 활발 | Mirror의 고성능 대안 | Unity 공식 지원이지만 미성숙 | 고성능 로우레벨 네트워킹 |
| 🎮 게임 규모 | 소규모~중간 | 소규모~중간 | 중~대형까지 가능 | 소~중형, 실험적 | 대형 (서버 따로 둬야) |
- FishNet은 **Unity 엔진 내에서 서버를 돌리는 구조**
- 즉, 서버도 UnityEngine 위에서 실행됨
- 서버 실행 시 물리 처리, 씬 로딩 등 포함됨
- NetEase, Tencent, Riot 등 대형사는 Unity 서버를 쓰지 않습니다.
- 서버는 **C++, Rust, Go, Java**로 독립적으로 제작
- 이유: 무게, 성능, 메모리 관리, 헤드리스 환경 대응
- FishNet은 클라이언트와 서버 코드가 같은 Unity 프로젝트 안에 있거나 공유 구조가 있음
- 대형 서비스는 반드시:
- 서버 코드는 외부 유출 불가
- 클라이언트에서 절대 상태 조작 못함
- 클라이언트는 “입력만 보내고 결과만 받음”
- FishNet은 NetworkBehaviour, Observed Components 등의 자동 동기화 구조가 오히려 보안에 약점이 됨
- FishNet은 고수준 네트워크 프레임워크로, 내부 구조를 완전히 통제하기 어렵고, 핵심을 고치려면 비용이 큼
- 대형사는 자신만의:
- 트래픽 최적화 구조
- 암호화 계층
- 지역별 라우팅 처리
- 로비 + 매치메이킹 + 룸 통신 분산처리
- 를 모두 **자체 개발**해서 쓰는 게 일반적
- FishNet은 주로 **P2P or 단일 룸 중심 구조**
- NetEase는:
- 지역별 로비 서버
- 매치메이커
- 룸 서버 (서버 프로세스 스폰)
- 중간 통신 게이트웨이
- 등 **계층화된 네트워크 구조**를 채택
🎯 예시 비교
| 항목 | FishNet | NetEase 구조 |
|---|---|---|
| 서버 위치 | Unity 내부 | Unity 외부 (C++ 서버 등) |
| 통신 방식 | RPC, 동기화 자동 제공 | 직접 설계 (명시적 메시지 프로토콜) |
| 보안 | 클라이언트 접근 가능 | 완전 분리 (Black Box) |
| 권한 처리 | Host 기반 권장 | Server 권한 철저 |
| 트래픽 처리 | FishNet 내부 처리 | 자체 TCP/UDP 커널 + CDN |
💬 정리된 한 줄 요약
FishNet은 인디 또는 중소형 프로젝트에 이상적이지만, NetEase는 “보안·성능·확장성·통제권”을 위해 처음부터 커스텀 서버와 네트워크를 직접 개발합니다.
- 초기 프로토타이핑/기획 검증용으로 FishNet을 내부적으로 썼을 수는 있음
- 예: 캐릭터 컨트롤, 전투 시스템 등
- 이후 실서비스 구조로 넘어가며 커스텀 서버로 완전 전환**
🔚 결론
NetEase 같은 대형 게임사는 FishNet이 아무리 좋아도 보안, 성능, 구조적 이유로 쓰지 않습니다. 다만, 당신이 대형 구조를 배우기 위한 중간 단계로 FishNet을 시작하고, ** **이후 ENet 기반으로 점진 전환하는 건 매우 좋은 전략입니다. chatgpt
내 결론:
실서비스 할거면 처음부터 실서비스 할 수 있는 걸로 만들자. devramyun
- FPS, 배틀로얄, MOBA처럼 경쟁 요소가 강한 게임은 1픽셀 차이로 승패가 갈림 → 해킹은 곧 매출 하락
- 특히 SMC처럼 스킨, 메카 강화, 랭킹이 있는 게임은 치트 하나로 유저 이탈
👉 해결책 = 클라이언트는 ‘입력’만 보내고, 모든 결정은 서버가 내림
🔒 실제 사례: 철저한 Server Authority
| 항목 | 서버가 하는 일 |
|---|---|
| 이동 처리 | 클라이언트 입력(방향, 속도)을 받고 충돌/중력 등은 서버에서 계산 |
| 총 쏘기 | 서버에서 총알 생성 여부 판단 후 피격 판정 |
| 데미지 처리 | 서버에서만 체력 감소 가능. 클라는 시각 효과만 |
| 메카 소환 | 서버에서 조건 확인 후 소환 결정 및 위치 결정 |
| 아이템 획득 | 서버에서 충돌 판정 후 승인. 클라는 그냥 요청만 보냄 |
| 순간이동 등 핵 방지 | 서버는 시간당 이동 거리, 좌표 변화량 체크로 “워프 핵” 감지 |
✅ 클라이언트는 “Request”만 보내고, 서버가 “State”를 결정해서 다시 전달 ❌ 클라이언트는 절대 직접 상태를 변경하지 못함
🧱 구조 비교
| 항목 | 클라이언트 권한 (FishNet/Mirror 등 기본 구조) | 서버 권한 (대형 게임 구조) |
|---|---|---|
| 이동 | 클라에서 좌표 갱신, 서버는 동기화만 | 클라는 방향+속도만 전달, 좌표는 서버가 결정 |
| 총 발사 | 클라가 생성 후 서버에 알려줌 | 서버가 명령 받고 생성 및 피해 판정 |
| 피격 | 클라에서 피격 효과 발생 → 서버에 통보 | 서버가 피격 여부 판단 후 클라에 알림 |
| 보간/예측 | 클라가 알아서 움직임 | 서버가 기준 제공, 클라는 보간만 수행 |
| 위치 조작 방지 | 불가능 (클라 해킹 가능) | 가능 (서버가 최종 상태 권한) |
🔐 실전 구현 패턴 예
1
2
3
4
5
6
7
클라: "나는 앞으로 0.1초 동안 오른쪽으로 이동할게요!"
서버: "확인. 장애물과 중력 고려해서 당신은 여기에 위치합니다."
→ 클라: (서버 좌표로 스냅)
클라: "이 버튼을 눌러 총을 쐈어요!"
서버: "좋아. 사거리 안이고 쿨다운도 없네. 총알을 생성합니다."
이런 구조에서는 “총을 쏘는 것조차 서버가 허락해야 합니다.”**
- NetEase와 Tencent는 내부 보안팀이 별도로 존재함
- 자체 패킷 암호화, 안티치트 커널 드라이버, 트래픽 속도 탐지 등 여러 겹의 방어선 사용
- 게임 개발자 입장에서는 “모든 상태를 서버가 정한다는 철학”이 가이드라인으로 강제됩니다
- 초기 프로토타입: FishNet + Host Authority로 빠르게 구현
- 중기 구조 전환: 서버가 위치, 공격 등 판정 처리 → 클라는 입력만
- 최종 구조: ENet 기반 C++ or Python 서버 + Unity 클라로 완전 분리
🧠 요약
🎯 대형 게임사는 진짜로 서버 권한을 철저히 관리합니다. 유저는 “내가 게임을 조종한다”고 착각하지만, 실제로는 “입력 요청을 보내고, 서버가 허락한 대로만 움직입니다.”
⚖️ 클라이언트 위임 + 밴 전략이 가능한 조건
| 조건 | 설명 |
|---|---|
| 🕹️ 캐주얼 게임 | 비경쟁 게임 (예: 파밍, 샌드박스, 미니게임)은 어느 정도 허용 |
| 🧑🤝🧑 친구 기반 게임 | 신뢰 기반 (예: 친구끼리 하는 게임)이라서 핵이 문제가 안 됨 |
| 👨💻 실시간 검증 어려움 | 서버 리소스가 부족할 때, “사후 처리”로 치트 대응 |
| ⚠️ 베타 테스트 | 개발 초기에 유저 피드백을 우선시할 때 |
→ 이럴 때는 **클라에서 총알 쏘고, 이동하고, 맞았다고 서버에 통보만 해도 됨** → 핵 쓰면 나중에 밴
❗ 그런데 왜 대형사는 절대 그렇게 안 하냐?
| 이유 | 설명 |
|---|---|
| 💣 핵이 퍼지는 속도 > 밴하는 속도 | 공개 핵 한 번 터지면 하루 만에 수백~수천명 |
| 📉 유저 신뢰 붕괴 | “저 판은 핵이네” 하는 순간 → 이탈 → 매출 하락 |
| 📱 모바일 환경은 쉽게 뚫림 | 루팅된 폰/에뮬레이터에서 메모리 조작 간단 |
| 🎮 경쟁 장르일수록 더 치명적 | FPS, 배틀로얄, 랭킹 있는 게임은 핵 = 망하는 길 |
| 🧑💼 커뮤니티 이슈 폭발 | 유저 입장에서 “왜 저 핵쟁이 안 밴됨?” → 평점 테러 |
예:
🎯 “1명이 핵을 쓰면 5명이 떠난다.” ← 실제 운영 통계 기반 문장입니다.
🧠 클라 위임이 가능한 범위 (현실적 예)
| 기능 | 위임 가능? | 설명 |
|---|---|---|
| 카메라 움직임 | ✅ 가능 | 서버가 알 필요 없음 |
| UI 선택 | ✅ 가능 | 로컬 처리 |
| 이펙트 재생 | ✅ 가능 | 맞았는지는 서버가 판단 |
| 이동 처리 | ⚠️ 제한적 가능 | 이동 요청만 보내고, 서버가 최종 위치 결정해야 안전 |
| 총 발사 | ❌ 서버에서 결정 권장 | 탄막 핵, 무한 공격 방지 |
| 체력 감소 | ❌ 반드시 서버 | 핵 사용자가 무적되는 걸 막기 위함 |
✅ 중간 타협안: 서버 권한 기반 + 로컬 예측 + 치트 감지 시스템 대형 게임은 다음 조합을 사용합니다:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[클라]
- 입력 예측 (즉시 반응)
- 로컬에서 움직이고 총쏘고 이펙트 띄움
[서버]
- 실제 이동 좌표 판정
- 공격/피격/자원 획득 확정
- 시간당 이동거리, 좌표 변화량 체크 (치트 감지)
- 비정상 행동 감지 → 자동 밴
[결과]
- 로컬은 부드럽고 반응 빠름
- 핵은 의미 없음 (서버에서 무시됨)
🔚 요약
✅ “클라 위임 + 밴” 전략은 가능하지만, 핵 대응이 늦으면 신뢰도와 매출에 치명적입니다. 🎮 경쟁/실시간/랭킹/매출이 중요한 게임일수록 서버 권한이 핵심입니다. 🧠 현실적으로는 “로컬 반응성 + 서버 결정 + 핵 탐지” 구조가 가장 많이 쓰입니다.
다음과 같은 **현실적인 기술 스택 로드맵**을 추천합니다:
🎯 목표
🎮 Unity 기반 TPS/메카 게임에서 ✅ 클라이언트 예측 + ✅ 서버 권한 구조 + ✅ 확장 가능하고 보안성 있는 분산 서버 구조를 ✅ 혼자 또는 소규모로 만들고 싶다
🧱 추천 기술 스택 (현실적 선택 + 확장성 고려)
| 영역 | 추천 기술 | 이유 |
|---|---|---|
| 🎮 클라이언트 | Unity + ENet-CSharp 바인딩 | Unity로 빠른 3D 개발, ENet으로 직접 통신 제어 |
| 📡 네트워크 계층 | ENet (C 기반) | 고성능 UDP, 신뢰성 있는 패킷 처리, 매우 경량 |
| 🧠 서버 로직 | Rust or Python (초기엔 Python) | Rust는 성능, Python은 빠른 개발 (PyENet 존재) |
| 📦 통신 포맷 | FlatBuffers or Protobuf | 빠르고 안정적인 이진 포맷 (지연 최소화) |
| ⏱ Tick 시스템 | Fixed Tick 구조 직접 구현 | 예측 + 보정 + 동기화에 필수 |
| 📜 상태 구조 | Custom State Manager | 예측용 입력 큐 + 롤백용 상태 큐 |
| 🛠 유틸 | Wireshark + 디버그 HUD | 패킷 분석 및 보정 시각화용 |
| 📈 운영 준비 | (후속) Redis + Docker (멀티룸) | 룸 서버 분리/확장 단계에서 필요 |
- Unity에서 TickManager, InputQueue, ApplyInput() 구조 구현
- 서버 없이, 예측 + 롤백 + 보정 구조만 완성
- PyENet으로 서버 구성
- InputFrame 전송, StateFrame 응답 구조
- 예측 ↔ 검증 구조 동작
- Unity에 ENet.dll 붙여서 직접 UDP 통신 구현
- RPC 없이, 명시적 메시지 설계
- tokio + enet-rs 조합으로 고성능 서버 구현
- 멀티 룸/유저당 세션 분리 등 확장 가능
🌐 비교 요약
| 옵션 | 빠름 | 쉬움 | 확장성 | 추천 대상 |
|---|---|---|---|---|
| FishNet | ⚪ | 🟢 | ⚪ | 인디/중형 게임 |
| Mirror | ⚪ | 🟢 | ❌ | 학습용 |
| ENet + Python | 🟡 | 🟢 | 🟡 | 실험 및 구조 설계 |
| ENet + Rust | 🟢 | ⚪ | 🟢 | 최종 구조로 이상적 |
💡 요약 정리
✅ 시작은 Python 서버로 빠르게 붙이고, 점진적으로 Rust로 이전하면 성능과 확장성 모두 잡을 수 있어. 고수준 프레임워크(FishNet 등)는 참고만 하고, 커스텀 구조로 넘어가는 게 최적 전략이야.