📚 발표 목차 (Table of Contents)

저희 Zero Ratency 팀의 서버 아키텍처 발표에 오신 것을 환영합니다!
본 문서에서는 저희가 직접 구축한 비동기 네트워크 소켓 입문부터 고성능 서버 코어 프레임워크까지의
기술적 의사결정과 구현 과정을 단계별로 소개합니다. 목차를 클릭하여 Zero Ratency의 기술적 여정을 함께 확인해 보시죠.

PART 1-1

AI 리소스 워크플로우

ComfyUI 기반 AI 캐릭터/배경 생성부터 영상화, 스프라이트 시트 변환까지의 자동화 파이프라인을 소개합니다.

PART 1-2

클라이언트 & UI 시스템

Unity 기반의 데모 클라이언트를 통한
인게임 리소스 테스팅 및 인터랙션 과정을 소개합니다.

PART 1-3

유저/로그 관리 시스템

Minimal API 기반의 백엔드 관리자 패널을 통한
유저 데이터 관리 및 실시간 로그 모니터링 시스템을 소개합니다.

PART 2

네트워크 & 소켓

TCP/UDP 통신의 차이점과 비동기(Async) 소켓 논 블로킹(Non-Blocking) 처리의 당위성에 대한 기초 설명을 기술합니다.

PART 3

서버 코어 기초 동작

클라이언트 접속을 관장하는 Listener부터 커넥션 풀을 관리하는 Connector, 세션 라이프사이클을 추적합니다.

PART 4

버퍼 제어와 스트림 파싱

네트워크 송수신 메모리 블록(Recv/SendBuffer) 관리 기법과 TCP 스트림 패킷 데이터 조각화 파싱(PacketSession) 과정을 다룹니다.

PART 5

직렬화 자동화 구축

다양한 데이터 구조체의 직렬화/역직렬화 이론과, 프리팹 코드를 자동화 생성하는 Packet Generator 설계 패턴을 집중 학습합니다.

PART 6

동시성 제어 (Concurrency)

경쟁 상태(Race Condition) 방어 기법, 메모리 락(Lock), 그리고 다중 스레드 병목 현상을 유연하게 제거하는 Lock-Free 기반 JobQueue와 JobTimer 최적화 기술 집대성하여 정리했습니다.

🚀 지연 시간 최소화를 꿈꾸는 Zero Ratency 팀원들을 소개합니다.

저희 Zero Ratency 팀은 지연 시간 최소화(Zero Ratency)를 목표로, 고도화된 백엔드 기반 기술을 탐구하기 위해
형성된 열정 넘치는 그룹입니다. 각자의 영역에 집중하여 단단한 서버 프레임워크를 함께 완성할 것 입니다.

👨‍💻

CORE ENGINEER

👑 유영호 (팀장)

C# .NET Core Socket Multi-threading

고성능 비동기 소켓 엔진 아키텍처 설계
패킷 직렬화 자동화 도구(Generator) 개발
멀티스레드 JobQueue 시스템 구축
Lock-Free 기반 고성능 자료구조 최적화

🎨

UI & CONTENT

정유현 (팀원)

Unity UI/UX Game Logic

클라이언트-서버 프로토콜 연동 규격 설계
반응형 UI 시스템 아키텍처 구축
인게임 핵심 전투/이동 로직 개발
서버 동기화 최적화 및 결과물 연동

🧙‍♂️

RESOURCE & CONTENT

김인규 (팀원)

AI Research ComfyUI Workflow

AI 기반 자동 리소스 생성 파이프라인 구축
ComfyUI 연동 애니메이션 워크플로우 설계
게임 내 핵심 컨텐츠 시나리오 및 기획
리소스 최적화 및 인게임 적용 가이드

⚙️

MES SYSTEM

박정우 (팀원)

MES Data Link Backend

실시간 제조 실행 데이터(MES) 브릿지 개발
서버 DB 연동 및 트랜잭션 관리 설계
공정 데이터 시각화 라이브러리 연동
외부 API 연동 및 데이터 정합성 검증

🔄 ComfyUI 리소스 생성 파이프라인

Dawnholder 프로젝트는 최신 생성형 AI 기술인 ComfyUI를 활용하여, 기획 단계의 아이디어를 실시간으로 고품질 게임 에셋으로 변환하는 독자적인 파이프라인을 구축했습니다.

STEP 1. Character Maker

텍스트/스케치를 기반으로
고퀄리티 캐릭터 원화 생성

→

STEP 2. Background Maker

월드 컨셉에 맞는
웅장한 배경 에셋 생성

→

STEP 3. Frame to Video

정지 영상을 기반으로
부드러운 애니메이션 영상 생성

→

STEP 4. Spritesheet Maker

영상을 인게임 적용 가능한
스프라이트 시트로 자동 변환

📽️ 파이프라인 최종 결과물 (Ninja Character)

IDLE ANIMATION

WALKING ANIMATION

JUMP ANIMATION

🖼️ Unity UI 개발 환경 현황

Unity 엔진의 캔버스 시스템을 활용하여, 테스트용으로 다양한 해상도에 대응 가능한 반응형 UI를 구축했습니다.
특히 드로우 콜 최적화와 레이어링 관리에 집중하여 쾌적한 테스트 환경을 제공합니다.

데모 테스트 씬(Scene) 구성

에디터 상의 요소 배치 및 계층 구조

상세 레이아웃 작업

인스펙터를 활용한 정밀 프로퍼티 설정

📽️ 리소스 테스트 및 인터랙션

🎥 리소스 테스트 시연 (Dawnholder Client)

💡 주요 특징:
- 데모 클라이언트를 통해 리소스 테스트
- 실제 Scene에서 시각적으로 확인하며 직관적 대응 가능

🖥️ 백엔드 관리 시스템 (Admin Panel)

서버의 유저 데이터 정합성을 유지하고, 발생하는 모든 인게임 이벤트를 추적하기 위한 통합 관리 시스템입니다.
Minimal API 아키텍처를 기반으로 설계되어 가볍고 빠른 성능을 제공합니다.

📊 통합 관리 프레임워크 현황

👤 유저 계정 관리

회원가입, 로그인 등 핵심 유저 인증 로직의 정합성을 검증하고 데이터를 관리합니다.

📜 실시간 로그 추적

전체 로그 조회 및 닉네임, 액션 타입별 필터링 기능을 통해 서버 상태를 실시간으로 파악합니다.

⚡ Minimal API 연동

RESTful 엔드포인트를 통해 클라이언트와 효율적으로 데이터를 송수신하며 오버헤드를 최소화합니다.

네트워크 설계 철학 (TCP vs UDP)

전화 통화 📞 vs 엽서 던지기 📮

네트워크 통신의 첫 단추, 어떤 프로토콜을 선택해야 할까요?
강력한 신뢰성이 요구되는 자체 게임 서버 환경에서는 데이터 유실을 완벽히 방어해야 합니다.
따라서 저희 Zero Ratency 팀은 무결성을 최우선으로 보장하는 TCP(Transmission Control Protocol)를 메인 네트워크 기반으로 채택하였습니다.

통신 신뢰성 패러다임의 차이

📞 TCP (전화통화)

상대방이 전화를 받았는지
확인 후 대화 시작
(3-Way Handshake)

🙋 고객 (클라이언트)

📨 SYN

→

←

✅ ACK

🏢 직원 (서버)

✔ 장점: 데이터 분실 확률 0% 보장

VS

📮 UDP (엽서 던지기)

주소만 적고 우체통에
무작정 때려넣기

✍️ 작성자 (클라이언트)

🚀 초고속 발송

→

📬 우체통 (서버)

✔ 장점: 답답함 없는 극강의 속도

비동기 소켓 적용 (Async)

진동벨의 마법: 요리가 완성될 때까지 멍 때리지 마라! 🛎️

서버가 수천 명의 접속자 요청을 처리할 때 발생할 수 있는 가장 큰 병목은 바로 대기 시간(Blocking)입니다.
이를 해결하기 위해 저희 Zero Ratency 팀은 스레드 유휴 시간을 최소화하고 자원 효율을 극대화하는
논 블로킹 비동기(Async) 소켓 아키텍처를 설계하여 압도적인 처리량을 확보했습니다.

동기(Sync) 식당 메뉴얼 vs 비동기(Async) 식당 메뉴얼

😩 답답한 방식: 동기 (Blocking)

🏃‍♂️ 종업원 (서버 스레드)

주방에 요리 요청
Receive() 호출

⛔ 데이터 수신 대기 존

종업원이 주방장 앞에서 30분간 꼼짝도 못하고
요리(데이터)가 나올 때까지 기다립니다.

💀 이 동안 다른 손님은 완전 무시!

VS

🚀 스마트한 방식: 비동기 (Async/IOCP)

🏃‍♂️ 종업원 (메인 스레드)

🛎️ 진동벨(SAEA) 지급 후 즉시 이탈!

✅ 다른 테이블 서빙 가능!

다른 클라이언트들을 자유롭게 처리합니다

🔔 [징~징~] 요리 완성! 여유 있는 스레드 1명이
콜백 실행 후 Session에 전달!

Listener: 무한 수락 자동 루프

결코 쉬는 법이 없는 식당 안내데스크 📝

수천 개의 클라이언트 접속이 쏟아지는 현관문, 어떻게 통제할까요?
저희는 단일 스레드 병목을 막기 위해 비동기 Listener 예약 시스템을 구축했습니다.
Zero Ratency 팀은 클라이언트가 문을 두드리는 즉시 대기열(Backlog)에 빠르고 안전하게 입장할 수 있도록 논 블로킹 파이프라인을 완성했습니다.

RegisterAccept() 코루틴형 순환 비유

1단계. 영업 대기 🕐

👁️ 안내원 (Listener) 입구 앞에서 눈뜨고 대기

RegisterAccept() 호출

→

2단계. 손님 당도! 🚶

🚪 문 열림! (OS 알림) 클라이언트 접속 감지

OnAcceptCompleted
발동

→

3단계. 처리 & 복귀 🔄

🎫 Session 발급 🔁 재호출 루프!

끊임없는 루프 형성

Connector: 봇 스웜 부하 테스트

관광버스 500대 예약 뚫기 (더미 클라이언트) 🚌

분산 서버 환경 및 대규모 더미 클라이언트 로드 테스트 환경을 위해, 다수의 연결을 동시에 제어하는 기능은 필수적이었습니다.
이를 위해 저희 Zero Ratency 팀은 수백 개의 소켓 커넥션을 운영체제에 전담시켜 일괄적으로 연결해 주는
비동기 Connector 단체 버스 패턴을 커스텀 구현했습니다.

N단 동시 접속 아키텍처 (클론 복제)

매크로 사령관 탑차 (DummyClient Main)

"총원 500명 복제 완료, 지정한 IP 서버로 즉시 일제 침투 시작!"

🤖 클론 1호
ConnectAsync()

🤖 클론 2호
ConnectAsync()

🤖 클론 500호
ConnectAsync()

➔ ➔ ➔

🏢 타겟 게임 서버 (Dawnholder Server)
500개의 Session 동시 강제 렌더링 부하 발생 💥

Session & Disconnect 안전 관리

원자적 잠금으로 Double Free 완전 차단 🔒

클라이언트 접속 해제(Disconnect)는 언제 발생할 지 모르며, 중복 해제 시 치명적인 서버 크래시를 유발합니다.
저희 Zero Ratency 팀은 멀티스레드 환경에서도 중첩 해제 사고를 방어하고 철저하게 메모리를 회수하는
안전한 생명주기(Lifecycle) 잠금장치 패턴을 Session 코어 로직에 적용했습니다.

🔐 화장실 잠금장치 비유 — Interlocked.Exchange()

😱 방어 없을 때 — Double Free 발생

🧵 스레드 A (송신 실패)

Socket.Close() 호출 ①

💥 이미 닫힌 소켓 또 Close!

🧵 스레드 B (수신 실패)

Socket.Close() 호출 ②

💥 ObjectDisposedException 크래시!

✅ Interlocked.Exchange() 적용 후 — 완벽 방어

m_disconnected 플래그

0

잠금 해제 상태

🧵 스레드 A (먼저 진입)

Exchange(ref flag, 1)
→ 이전값 0 반환

🔒 잠금 획득!
Socket.Close() 실행 ✓

→

🧵 스레드 B (뒤에 진입)

Exchange(ref flag, 1)
→ 이전값 1 반환

⛔ 이미 1 → 즉시 return!
Socket.Close() 실행 안 함 ✓

Recv / Send Buffer

GC 없는 무한 재사용 칠판 🎯

데이터 송수신 시 매번 메모리를 할당하면 가비지 컬렉터(GC) 부하로 인해 치명적 프레임 드랍이 발생합니다.
이를 원천 차단하기 위해 Zero Ratency 팀은 거대한 청크(Chunk) 메모리를 미리 할당해두고 슬라이딩 도어처럼 재사용하는
자체 제작 Recv/SendBuffer 풀링 시스템을 통째로 개발했습니다.

📋 RecvBuffer — 슬라이딩 커서 모델

▼ 내부 byte[] 배열 (고정 크기 버퍼)

데이터 수신 중 (Clean 전)

❌ 이미 읽은
공간 (낭비)

ReadCursor

✅ 유효 데이터 (처리 대기)

WriteCursor

빈 공간

↓ Clean() 호출 — 유효 데이터를 앞으로 당기기! ↓

Clean() 후 — 공간 대폭 확보

✅ 유효 데이터 (앞으로 복사)

WriteCursor

🎉 확보된 여유 공간 (재사용!)

🔄

GC 부하 0%

new byte[] 한 번만 할당

🚀

커서 이동만

복사 없이 포인터만 증가

♻️

무한 재사용

Clean()으로 공간 회수

PacketSession: TCP 단편화 방어

반쪽짜리 편지도 모아서 완성하는 우체부 📦

TCP 통신 특성상 패킷은 쪼개지거나 뭉쳐서 도착하는 '스트림 조각화' 현상이 필연적입니다.
안정적인 데이터 조립을 위해 Zero Ratency 팀은 헤더를 분석하여 온전한 패킷 규격이 완성될 때까지 킵해두고
정교하게 잘라내는 결합형 PacketSession 파서를 서버 아키텍처 내부로 완벽하게 융합했습니다.

📬 퍼즐 조각 조립 비유 — TCP 스트림 파싱

📤 클라이언트가 보낸 것

패킷 A10 bytes

패킷 B20 bytes

총 30 bytes 동시 발송

TCP 스트림

→

무작위 분할!

📥 실제로 도착하는 것

🔴 Recv ① — 15 bytes 도착

패킷A 완성 ✓ (10b)

B조각 5b 대기

→ A는 OnRecvPacket(A) 전달 ✓
→ B 나머지 5b 버퍼에 보관

🟢 Recv ② — 15 bytes 도착

B조각 5b

B 나머지 15b

→ 5+15=20b → 패킷B 완성! ✓
→ OnRecvPacket(B) 전달 ✓

🔑 PacketSession 파싱 원리

① 헤더 확인: 첫 2바이트(Size 필드)를 읽어 전체 패킷 크기 파악

② 대기: 버퍼에 Size만큼 안 쌓이면 다음 Recv까지 보관

③ 조립: 완성되면 OnRecvPacket 콜백 호출 후 커서 전진

Serialization & Encoding

낭비를 빈틈없이 없앤 기차칸 조립 패킷 🚄

무거운 JSON 데이터 포맷 대신, 전송 규격을 극한으로 깎아내기 위한 직렬화(Serialization) 최적화가 필요했습니다.
저희 Zero Ratency 팀은 BitConverter와 포인터를 활용하여 바이트 배열(Byte Array) 수준에서 데이터를 다이렉트로
조립하고 분해하는 초경량 바이너리 직렬화 파이프라인을 성공적으로 구축했습니다.

🧱 테트리스 블록 비유 — 패킷 바이트 레이아웃

❌ 기존 방식 (JSON) — 무겁고 느림

                                {"size":16, "id":100, "playerId":42, "posX":10.5, "posY":20.0}
                            

↳ 모든 문자가 1바이트씩 차지 (약 60~80 Bytes)

VS

✅ Dawnholder 방식 (Binary) — 초경량 압축

                                    Size
                                    (2 Bytes)
                                
                                    PacketID
                                    (2 Bytes)
                                
                                    PlayerID
                                    (int, 4 Bytes)
                                
                                    PosX
                                    (float, 4 Bytes)
                                
                                    PosY
                                    (float, 4 Bytes)

offset: 0 총 단 16 Bytes 만 소모!

Packet Generator

XML 명세서로 코드를 찍어내는 붕어빵 파이프라인 🤖

서버 로직이 방대해질수록 수백 개의 패킷 클래스를 일일이 하드코딩하는 것은 치명적 휴먼 에러의 주범이 됩니다.
이를 완전히 방지하고자, Zero Ratency 팀은 XML 설계 문서만 작성하면 수천 줄의 패킷 직렬화 C# 코드를 1초 만에 뽑아내는
강력한 자동화 툴(Packet Generator)을 자체 개발해 유지보수성을 극대화했습니다.

🏭 자동화된 붕어빵 기계 — Data-Driven Pipeline

📜

레시피 작성

PDL Schema (XML)

→

⚙️

붕어빵 기계 가동

PacketGenerator 자동 파싱

→

📦

C# 코드 생산

GenPackets.cs

Unity 배포

서버 배포

✨ 효과: 클라이언트와 서버가 완벽히 동일한 패킷 코드를 공유하여 버전 불일치 버그 원천 차단

Race Condition

하나의 메모지에 동시에 글씨 쓰기 📝

멀티 스레드 환경에서는 동시다발적인 자원 접근 시 필연적으로 경합(Race Condition)이 일어납니다.
저희 Zero Ratency 팀은 이러한 치명적인 데드락(Deadlock)과 변수 오염을 완벽방어하기 위해,
스레드 간의 메모리 락(Lock) 체계와 동기화 구조를 기초부터 단단하게 설계했습니다.

⚔️ 경쟁 상태 - 메모리 (List) 오염 과정

🧵 스레드 A

1️⃣ List의 현재 공간(Count) 확인
→ Count = 5

3️⃣ 5번 인덱스에 'User1' 저장

5️⃣ Count++ (6으로 업데이트)

💥 동시 접근 충돌

🧵 스레드 B

2️⃣ List의 현재 공간(Count) 확인
→ A가 쓰기 전이라 여전히 Count = 5

4️⃣ 5번 인덱스에 'User2' 덮어쓰기!

6️⃣ Count++ (6으로 덮어씀)

🚨 결과: User1 데이터 증발 (Memory Loss)

배열에는 2명이 들어왔지만 실제 저장된 Count는 6, 5번 인덱스는 User2가 독차지합니다.

JobQueue: Lock-Free Flush

일감 던져놓고 퇴근하기 (총대 메기 패턴) 🏃💨

모든 스레드가 자물쇠(Lock)가 풀리길 기다리며 줄을 서면 어마어마한 병목이 역발생합니다.
Zero Ratency 팀이 고안한 궁극의 해결책은 Lock-Free 기반의 JobQueue 시스템입니다.
'처음 도착한 스레드가 쌓인 일감을 전담 처리(총대 메기)' 하는 이 영리한 기법으로 스위칭 오버헤드를 획기적으로 없앴습니다.

📥 위임형 일괄 처리 시스템 (m_Flush)

🧵 스레드 2

→

Job B 전달
(즉시 퇴근 💨)

🧵 스레드 3

→

Job C 전달
(즉시 퇴근 💨)

🧵 스레드 1

→

Job A (최초 진입)
(Flush 권한 확보 👑)

🗂️ 공용 JobQueue

Job A (스레드 1)

Job B (스레드 2)

Job C (스레드 3)

👑 스레드 1 (독점 실행기)

"내가 첫 번째로 왔으니 큐에 쌓인 걸 다 처리할게!"

Execute(A) Execute(B) Execute(C)

결과: 스레드 경합(Lock Contention)이 거의 0에 수렴하여 처리량 극대화

JobTimer & Gathering

지치지 않는 톱니바퀴 (심장 박동 사이클) ⏱️

스킬 쿨타임, 몬스터 스폰 등 미래의 예약 작업들을 어떻게 1프레임의 오차 없이 관리할까요?
저희 Zero Ratency 팀은 우선순위 큐(Priority Queue)를 기반으로 메인 루프에서 끊임없이 만료된 작업만 건져서 실행하는
중앙 집중형 JobTimer (심장 박동) 스케줄링 시스템을 서버의 엔진으로 연동시켰습니다.

🔄 메인 스레드 심장 박동 사이클 (Tick)

⚙️ Main Thread

1️⃣ Check JobTimer

가장 빨리 예약된 Job의
실행 시간 확인 (Peek)

2️⃣ 시간이 다 되었다면?

큐에서 꺼내어(Pop)
실제 대기열(JobQueue)로 Push

3️⃣ Pending Jobs 처리

네트워크 등 외부에서 유입된
모든 행동(Flush) 즉시 수행

4️⃣ Thread.Sleep

잠시 휴식 (CPU 점유율 방어)
이후 다시 상단으로 반복

네트워크 아키텍처로의여정을 시작합니다 (Introduction to Network Architecture)