32강. 최종 점검: 멀티플레이 버그 디버깅과 심화 과정 연결

?1. 이번 강의에서 해결할 문제

“클라이언트에서 가끔 안 됨”이라는 보고만으로는 실행 위치, Ownership, 패킷 손실, Travel과 세션 상태 중 원인을 찾을 수 없습니다. 또한 작은 2인 게임이 완성됐다고 Replication Graph, Fast Array, Push Model, Network Prediction과 Lag Compensation을 무조건 도입하면 복잡도만 늘어납니다.

✓2. 학습 목표

✓이 강의를 마치면

• 서버·소유 클라이언트·다른 클라이언트 증상을 분리한 재현 보고서를 작성합니다.
• RepNotify, RPC, Ownership, Relevancy, Travel과 Session 로그를 순서대로 확인합니다.
• 심화 네트워크 기술이 해결하는 규모·성능·예측 문제와 도입 전 측정 기준을 설명합니다.

◇3. 핵심 개념

네트워크 버그는 “보이는 증상”과 “권위 있는 상태”를 분리해 진단합니다.

증상	첫 확인	다음 확인
Server RPC가 서버에 안 옴	호출 Actor LocalRole·Owner	Owning Connection·복제 Component
서버 값은 바뀌나 HUD가 안 바뀜	DOREPLIFETIME·OnRep	UI 초기 바인딩·Pawn 교체
호스트만 정상	IsLocallyControlled와 Authority 혼용	원격 Client 로그
한 클라이언트만 효과 없음	Actor Relevancy·Unreliable 손실	Multicast 호출 위치
Travel 뒤 팀이 초기화	PlayerState copy/override	새 GameMode·GameState 설정
세션 Join 뒤 이동 없음	Join Result·Connect String	ClientTravel·방화벽·맵 Cook
이동 떨림	서버/클라이언트 Collision·속도	CharacterMovement 보정·지연

✎4. 단계별 실습

재현 보고서 템플릿

# NET-001 원격 클라이언트 점령 UI 미갱신
- 빌드/엔진: UE 5.x, Development, commit ...
- 서버 모델: Listen / Dedicated
- 실행: 서버 1, 클라이언트 2, 별도 프로세스
- 네트워크: 150ms, 5% loss
- 재현: Host → Join → Travel → Client B enters point
- 예상: 서버 진행률과 두 HUD가 0→1
- 실제: 서버·Host 정상, Client B 0 고정
- 서버 로그: Property changed sequence ...
- Client B 로그: OnRep 없음 / Actor relevancy ...
- 범위: 규칙 정상, 전달 또는 바인딩 문제

진단 로그

CapturePoint.cpp

UE_LOG(LogCaptureNet, Verbose,
    TEXT("[%s] Point=%s OwnerTeam=%d Progress=%.2f Role=%s"),
    *CaptureNetDebug::NetModeToString(GetWorld()),
    *GetName(), OwningTeamId, CaptureProgress,
    *UEnum::GetValueAsString(GetLocalRole()));

필요한 시간 구간에만 LogNet, LogRep, LogNetTraffic 같은 범주를 활성화하고 파일 크기와 개인정보 노출을 통제합니다. stat net, Network Emulation, Unreal Insights의 Networking Insights와 서버·클라이언트 별도 로그를 사용합니다. 도구·명령 이름은 프로젝트 UE 버전에서 확인합니다.

심화 기술 선택 기준

주제	해결하려는 문제	이 과정에서의 경계
Replication Graph	많은 Actor·연결의 relevancy·priority 확장	2인 게임에는 도입하지 않고 Actor 수·대역폭 측정 뒤 검토
Fast Array Serializer	항목 단위 배열 추가·변경·삭제 복제	작은 최근 킬 1개 이후 큰 인벤토리·로그에서 검토
Push Model	Property 변경 추적 비용과 명시적 dirty 처리	프로파일 근거와 엔진 설정을 갖춘 뒤 적용
Iris	새 복제 시스템·필터·우선순위	프로젝트 UE 버전 지원·마이그레이션 범위를 먼저 확인
Network Prediction	커스텀 이동·능력의 예측·재시뮬레이션	기본 CharacterMovement로 부족한 측정된 기능에 적용
Lag Compensation	고지연 히트 판정의 과거 상태 보정	서버 히스토리·시간 동기화·악용 방지 설계가 필요

현재 StartBook 저장소에는 별도의 심화 네트워크 과정 문서가 존재하지 않습니다. 따라서 위 항목에 가짜 링크를 만들지 않고 이 섹션을 향후 심화 과정 연결 위치로 유지합니다. 실제 과정이 추가되면 이 문단과 과정 안내 데이터의 다음 과정 링크를 해당 실제 경로로 교체합니다.

→5. 코드가 동작하는 이유

NetMode·Role·Owner·Sequence가 포함된 로그는 같은 기능의 서버 원본과 클라이언트 복사본을 시간순으로 비교하게 합니다. 증상을 권한 판정, 상태 변경, 전송, 수신 후 표현으로 나누면 무작정 RPC 신뢰도나 업데이트 빈도를 높이지 않고 실패 단계만 수정할 수 있습니다.

심화 기술은 “더 고급”이라서가 아니라 측정된 규모·정확도 문제를 해결할 때 선택합니다. 기본 Replication과 CharacterMovement로 2인 경기가 안정적이라는 기준선이 있어야 개선 전후를 비교할 수 있습니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• 클라이언트 화면만 녹화: 같은 시각의 서버 상태·RPC 승인·Property 변경 로그를 함께 수집합니다.
• 안 되면 Reliable·NetUpdateFrequency부터 증가: Ownership, DOREPLIFETIME, Relevancy와 상태 의미를 먼저 확인합니다.
• PIE 정상만으로 배포 완료: 별도 프로세스, 패키지, 지연·손실과 서버 모델을 반복합니다.
• 심화 기술을 측정 없이 도입: Actor 수, RPC 빈도, 대역폭, 보정 횟수와 사용자 증상을 기준선으로 남깁니다.

✎7. 직접 실습

✎최종 회귀 체크리스트

• 리슨 서버와 별도 서버에서 두 플레이어가 접속한다.
• 원격 클라이언트 Server RPC가 소유 경계에서 도달하고 비소유 호출은 거부된다.
• 체력·탄약·점수·점령 진행률이 늦은 참가와 패킷 손실 뒤 최신 값으로 수렴한다.
• Multicast 유실이 데미지·승리 상태를 바꾸지 않는다.
• 로비 Ready 뒤 ServerTravel로 두 클라이언트가 CaptureMap에 도착한다.
• 한 플레이어 퇴장 뒤 PlayerArray와 점령 집계가 정리된다.
• 150ms 지연·5% 손실에서 플레이 가능하고 보정·거절 로그를 설명할 수 있다.
• 세션 Delegate가 중복 등록되지 않고 종료·재시도 경로가 기록돼 있다.
• 재현 보고서에 엔진 버전, 빌드, 서버 모델, 실행 수와 로그가 포함돼 있다.

실습 과제와 포트폴리오 과정에서 검증 기록 정리하기

?8. 이해 점검 질문 3개

?이해 점검

1. RPC가 안 보일 때 Reliable로 바꾸기 전에 확인할 Ownership 정보는 무엇인가요?
2. Replication Graph와 Fast Array를 이 2인 과정에 즉시 넣지 않는 이유는 무엇인가요?
3. 멀티플레이 재현 보고서에 서버·클라이언트 로그가 함께 필요한 이유는 무엇인가요?

■9. 핵심 요약

■핵심 요약

멀티플레이 디버깅은 권한 판정 → 서버 상태 변경 → 전송 → 클라이언트 수신 → 표현 순서로 증거를 모읍니다. CaptureArena의 기본 복제 기준선을 완성한 뒤 Actor 규모, 배열 변화, CPU, 대역폭, 이동 보정과 지연 판정을 측정할 때 Replication Graph, Fast Array, Push Model, Network Prediction과 Lag Compensation 심화로 확장합니다.

Prediction Key와 서버 보정이 있는 GAS 전투로 이어가기