think95592 님의 블로그

기획 맛보기 #3 — 게임의 시스템과 콘텐츠는 어떻게 상호작용하는가

think95592 — Fri, 14 Aug 2026 21:26:36 +0900

오늘의 한 문장

시스템은 플레이가 작동하는 규칙이고, 콘텐츠는 그 규칙을 이용해 플레이어가 실제로 경험하는 대상이다.

1. 시스템과 콘텐츠의 차이

게임을 구성하는 요소는 크게 로직과 데이터, 또는 시스템과 콘텐츠의 관점으로 나눠볼 수 있다.

시스템: 여러 대상에 반복 적용되는 규칙과 구조
콘텐츠: 그 규칙을 이용해 만들어진 개별 대상과 경험

예를 들어 RPG의 아이템을 생각해보자.

시스템

아이템을 획득할 수 있다.
인벤토리에 보관할 수 있다.
같은 아이템은 최대 99개까지 중첩된다.
장비 아이템은 지정된 슬롯에 착용한다.
소비 아이템은 사용하면 효과가 발동하고 수량이 감소한다.

콘텐츠

체력을 50 회복하는 하급 물약
공격력이 20 증가하는 철검
화염 저항을 부여하는 붉은 반지
사용하면 마을로 이동하는 귀환 주문서

즉, 인벤토리와 장착·사용 규칙은 시스템이고, 철검과 물약은 그 시스템을 통해 작동하는 콘텐츠다.

Unreal Engine 공식 문서도 게임을 구성하는 요소를 로직과 데이터로 구분한다. 로직은 게임 요소가 따르는 명령과 구조이고, 데이터는 그 로직이 구체적으로 무엇을 수행할지 설명한다. 다만 실제 프로젝트에서는 두 영역이 완전히 분리되지 않고 서로 섞일 수 있다고 설명한다.
Epic Games — Balancing Blueprint and C++

2. 시스템은 가능성을 만들고 콘텐츠는 가능성을 증명한다

시스템과 콘텐츠의 관계는 다음과 같다.

시스템이 가능한 행동의 범위를 만든다
                ↓
콘텐츠가 그 규칙을 구체적인 경험으로 만든다
                ↓
콘텐츠를 테스트하며 부족한 규칙을 발견한다
                ↓
시스템을 수정하거나 확장한다
                ↓
새로운 콘텐츠를 만들 수 있게 된다

시스템이 콘텐츠보다 먼저 존재하는 경우가 많지만, 개발이 한 방향으로만 진행되는 것은 아니다.

예를 들어 아이템 시스템에 다음 필드가 있다고 가정하자.

이름종류가격효과 값

하급 물약	소비	100	체력 +50
철검	장비	500	공격력 +20

이 구조로는 일반적인 회복 아이템과 장비를 만들 수 있다.

그런데 콘텐츠 기획자가 다음 아이템을 제안했다.

적에게 던진 뒤 플레이어에게 되돌아오는 부메랑

현재 시스템에는 투척, 비행, 충돌, 귀환에 관한 규칙이 없다. 이때 선택지는 두 가지다.

부메랑 아이디어를 포기하거나 기존 규칙에 맞게 바꾼다.
부메랑을 구현할 가치가 충분하다면 투척 무기 시스템을 확장한다.

두 번째 선택을 하면 부메랑 하나만 만들어지는 것이 아니다. 이후 투척 단검, 폭탄, 회수 가능한 창 같은 새로운 콘텐츠를 만들 수 있다.

따라서 좋은 콘텐츠 아이디어는 단순히 시스템을 소비하는 데 그치지 않고 새로운 시스템의 필요성을 발견하는 실험이 되기도 한다.

3. 몬스터 AI에서의 상호작용

시스템이 먼저 정의하는 것

몬스터 AI 시스템은 개별 몬스터가 아니라 공통 행동 규칙을 다룬다.

대기 → 탐색 → 추적 → 공격 → 피격 → 사망

여기에 다음 규칙이 포함될 수 있다.

플레이어를 발견하는 거리와 각도
소리에 반응하는 범위
추적을 포기하는 조건
공격 가능 거리
경로 탐색 방식
피격 시 행동 전환
대상이 사라졌을 때의 처리

시스템으로 만드는 콘텐츠

공통 AI 시스템에 데이터와 행동을 조합하면 여러 몬스터를 만들 수 있다.

몬스터	탐지 거리	이동	주요 행동
고블린	10m	지상 추적	접근 후 근접 공격
궁수	18m	거리 유지	원거리 공격
늑대	14m	빠른 추적	측면 이동 후 돌진

같은 탐지·추적 시스템을 사용하지만 수치와 행동 조합에 따라 다른 전투 경험이 만들어진다.

콘텐츠가 시스템을 확장하는 순간

콘텐츠 기획자가 “천장을 기어 다니다가 플레이어 위로 떨어지는 거미”를 제안했다고 가정해보자.

기존 AI가 지상 이동만 지원한다면 다음 기능이 추가로 필요하다.

벽과 천장 이동
천장 대기 상태
낙하 공격
지상과 천장 사이의 경로 전환
카메라 밖 공격을 방지하는 경고

거미 콘텐츠가 새로운 AI 기능을 요구했고, 확장된 시스템은 이후 박쥐나 벽을 타는 몬스터에도 재사용할 수 있다.

4. 아이템에서의 상호작용

아이템 시스템

획득과 버리기
인벤토리 보관
중첩과 최대 수량
장착 슬롯
사용 조건
효과 적용
강화와 분해

아이템 콘텐츠

회복 물약
무기와 방어구
제작 재료
퀘스트 아이템
버프 음식
열쇠와 지도

Epic Games의 Unreal Engine 아이템 예제에서는 먼저 모든 아이템이 공통으로 가져야 할 ID, 종류, 이름, 설명 등의 데이터 구조를 정의하고, 이후 데이터 테이블의 각 행에 개별 아이템을 입력한다. 아이템마다 별도의 코드를 만드는 방식은 아이템 수가 늘어날수록 비효율적이므로, 공통 구조와 중앙화된 데이터로 관리하는 방식을 제안한다.
Epic Games — Manage Items and Data

콘텐츠가 요구하는 확장

“착용한 상태에서 플레이어의 체력이 낮아지면 공격력이 증가하는 반지”를 만든다고 가정해보자.

기존 시스템이 고정 능력치만 지원한다면 다음 기능이 필요하다.

체력 변화 감지
조건부 효과
효과의 활성화와 비활성화
여러 효과가 겹칠 때의 계산 순서
UI에 현재 활성 상태 표시

콘텐츠 하나가 조건부 효과 시스템을 만들게 하고, 이후 다양한 장비 콘텐츠에 재사용할 수 있다.

5. 퀘스트에서의 상호작용

퀘스트 시스템

퀘스트 시스템은 이야기의 내용보다 진행 규칙을 정의한다.

잠김 → 수락 가능 → 진행 중 → 완료 가능 → 완료
                         ↘ 실패

주요 규칙은 다음과 같다.

퀘스트 수락 조건
목표 달성 판정
여러 목표의 순서
실패 조건
보상 지급
선행·후행 퀘스트
저장과 불러오기
NPC와 UI의 상태 변화

퀘스트 콘텐츠

늪에서 실종된 약초꾼을 찾아 마을로 데려온다.

콘텐츠 기획자는 다음을 정한다.

퀘스트를 주는 NPC
약초꾼의 위치
조사해야 할 흔적
등장하는 적
대화와 전투 순서
완료 보상

콘텐츠가 시스템을 확장하는 순간

기획자가 다음 선택지를 추가하려고 한다.

약초꾼을 구하거나, 그가 가진 희귀 약초만 빼앗아 돌아올 수 있다.

이 콘텐츠를 구현하려면 퀘스트 시스템이 다음을 지원해야 한다.

선택 결과 저장
상호 배타적인 목표
NPC 생존 상태
결과에 따라 달라지는 보상
이후 퀘스트와 대사의 변화

단순한 일자형 퀘스트가 분기형 콘텐츠로 발전하면서 시스템에도 선택 기록과 상태 추적 기능이 필요해진다.

6. 전투에서의 상호작용

전투 시스템

공격 입력과 애니메이션 상태
공격 범위와 적중 판정
피해 계산
회피 무적 시간
방어와 패링
상태이상
사망과 보상 처리

전투 콘텐츠

무기별 공격 동작
개별 스킬
몬스터의 공격 패턴
보스전 구성
전투 공간과 적 배치

콘텐츠가 시스템을 확장하는 순간

“보스의 공격을 정확한 순간에 막으면 무기가 부서지고 보스가 그로기 상태가 된다”는 패턴을 기획했다고 가정해보자.

이를 위해서는 다음 기능이 필요하다.

패링 성공 시간 판정
보스 무기의 내구도
무기 파괴 상태
그로기 게이지와 상태 전환
전용 카메라·이펙트·사운드
한 번 파괴된 무기가 다시 나타나지 않도록 하는 저장

보스 콘텐츠의 아이디어가 전투 시스템을 확장한다. 그리고 이 기능이 범용적으로 설계되면 다른 보스나 일반 적에게도 무기 파괴 콘텐츠를 적용할 수 있다.

7. 실제 사례: 《젤다의 전설 브레스 오브 더 와일드》

《젤다의 전설 브레스 오브 더 와일드》는 시스템이 다양한 콘텐츠 경험을 만들어내는 사례다.

불, 바람, 전기, 금속, 물리 오브젝트 등이 각 장소에서 별도의 연출로만 작동하는 것이 아니라 비교적 일관된 규칙으로 상호작용한다.

예를 들면 다음과 같다.

풀과 나무 오브젝트에 불이 붙는다.
불로 발생한 상승기류를 타고 날아오를 수 있다.
금속 물체는 전기와 상호작용한다.
물리 오브젝트를 밀거나 굴려 적을 공격할 수 있다.

각 상황을 개발자가 하나씩 정답으로 제작하지 않아도 시스템의 조합을 통해 여러 해결 방법이 발생한다.

이 게임의 테크니컬 디렉터 Takuhiro Dohta는 개발 목표 중 하나를 multiplicative gameplay라고 설명했다. 통일된 규칙 속에서 플레이어가 자신만의 해결 방법과 재미를 찾도록 하는 방향이다.
Nintendo — Breath of the Wild and “Multiplicative Gameplay”

이 사례에서 시스템은 단순히 콘텐츠를 담는 그릇이 아니다. 여러 시스템이 서로 반응하면서 개발자가 직접 만들지 않은 플레이 상황까지 발생시키는 콘텐츠 생성기에 가깝다.

8. 실제 사례: 기능에서 콘텐츠의 모습이 결정되다

Nintendo는 《Nintendo Land》 개발 당시 여러 프로토타입을 먼저 만든 뒤, 서로 다른 게임을 하나로 묶을 테마파크 콘셉트를 적용했다.

특히 《Donkey Kong’s Crash Course》에서는 프로토타입의 삼각형 형태가 플레이하기에 가장 재미있었기 때문에 최종 디자인에도 유지했다. 외형을 먼저 정한 뒤 기능을 끼워 넣은 것이 아니라, 재미있는 작동 방식이 콘텐츠의 형태를 결정한 것이다.
Nintendo — Iwata Asks: Design Follows Function

《Super Mario 3D World》의 Cat Mario 역시 벽을 오르고, 적을 할퀴고, 골대 기둥을 올라가는 기능을 중심으로 만들어졌다. 개발진은 기존 균형을 흔들 가능성보다 실제로 재미있는지를 우선해 여러 아이디어를 제작하고 검증했다고 설명한다.
Nintendo — Iwata Asks: Super Mario 3D World, “Function First”

이처럼 시스템과 기능에서 시작한 아이디어는 이후 캐릭터의 외형, 스테이지 구조, 적 배치 같은 콘텐츠로 확장된다.

9. 시스템을 먼저 만드는 것이 유리한 이유

콘텐츠를 반복해서 만들 수 있다

아이템 사용 규칙을 한 번 만들면 물약, 음식, 주문서 등 여러 콘텐츠를 같은 구조로 제작할 수 있다.

일관성을 유지할 수 있다

같은 상태이상인데 몬스터마다 적용 방식이 다르면 플레이어가 규칙을 학습하기 어렵다. 공통 시스템을 사용하면 비슷한 상황에서 같은 결과가 발생한다.

수정 비용을 줄일 수 있다

피해 계산 공식을 하나의 시스템에서 관리하면 전체 무기와 몬스터에 일관되게 반영할 수 있다.

팀이 병렬로 작업할 수 있다

프로그래머가 제작 도구와 공통 구조를 준비하면 콘텐츠 기획자와 아티스트가 개별 몬스터, 아이템, 퀘스트를 동시에 만들 수 있다.

대량 콘텐츠를 관리하기 쉽다

Unreal Engine은 데이터 테이블과 커브 테이블을 이용하면 외부 스프레드시트에서 수치를 관리하고 다시 게임에 반영할 수 있다고 설명한다. 특히 업데이트가 오래 지속되고 반복적인 밸런스 조정이 필요한 게임의 작업량과 복잡도를 줄이는 데 도움이 된다.
Epic Games — Data Driven Gameplay Elements

위험한 의존성을 일찍 발견할 수 있다

전투가 없는 상태에서 몬스터를 100종 기획하면 공격 판정이나 AI 규칙이 바뀔 때 모든 몬스터를 수정해야 한다. 핵심 시스템과 대표 콘텐츠를 먼저 검증하면 이런 대규모 재작업을 줄일 수 있다.

10. 시스템 우선이 항상 정답은 아니다

“시스템 먼저”는 모든 시스템을 완성한 뒤 콘텐츠를 만들라는 뜻이 아니다.

콘텐츠 없이 시스템만 설계하면 실제 요구를 알 수 없어 지나치게 복잡하거나 사용할 수 없는 구조를 만들 수 있다. 따라서 보통은 다음처럼 진행하는 편이 안전하다.

최소 시스템
    +
대표 콘텐츠 1~3개
    ↓
직접 플레이
    ↓
시스템과 콘텐츠를 함께 수정
    ↓
검증된 구조로 콘텐츠 확장

콘텐츠나 경험을 먼저 검증해야 하는 경우

독특한 보스전이 게임의 핵심일 때

보스 한 명의 전투 경험이 게임의 핵심이라면 범용 전투 시스템 전체보다 대표 보스를 먼저 프로토타이핑하는 편이 낫다. 그 보스를 구현하면서 실제로 필요한 시스템을 발견할 수 있다.

서사와 선택이 핵심일 때

분기형 어드벤처 게임이라면 전투나 인벤토리보다 대화 선택, 결과 저장, 감정 전달이 먼저 검증되어야 한다. 이 경우 대표 에피소드가 필요한 내러티브 시스템을 정의한다.

한 번만 등장하는 연출일 때

게임 전체에서 한 번 사용하는 장면을 위해 지나치게 범용적인 시스템을 만들면 개발 비용이 더 커질 수 있다. 재사용 가능성과 구현 비용을 비교해 전용 연출로 처리할 수 있다.

실험적인 플레이를 찾는 단계일 때

아직 무엇이 재미있는지 모르는 상태에서는 시스템 구조를 확정하기보다 빠른 프로토타입으로 여러 행동과 콘텐츠를 시험하는 것이 우선이다.

IP나 콘텐츠 제약이 강할 때

원작 캐릭터의 특정 능력, 이야기의 필수 장면, 실제 스포츠 규칙처럼 바꿀 수 없는 콘텐츠가 있다면 시스템이 그 요구사항을 지원하도록 설계해야 한다.

11. 실무에서 사용할 판단 기준

새로운 콘텐츠 아이디어가 나왔을 때 다음 질문을 확인할 수 있다.

기존 시스템으로 구현할 수 있는가?
구현할 수 없다면 콘텐츠를 조정할 수 있는가?
시스템을 확장하면 다른 콘텐츠에도 재사용할 수 있는가?
확장 비용에 비해 플레이 경험의 가치가 충분한가?
기존 콘텐츠와 충돌하거나 예외를 지나치게 늘리지 않는가?
대표 콘텐츠로 먼저 재미를 검증했는가?

특히 “재미있어 보인다”는 이유만으로 시스템을 계속 확장하면 일정이 무너질 수 있다. 반대로 현재 시스템에 맞지 않는다는 이유로 모든 새로운 아이디어를 거부하면 콘텐츠가 단조로워질 수 있다.

중요한 것은 콘텐츠의 가치와 시스템 확장 비용을 함께 판단하는 것이다.

오늘 배운 점

시스템과 콘텐츠는 뼈대와 살처럼 구분할 수 있지만 실제 개발에서는 계속 서로 영향을 준다.

시스템은 콘텐츠가 작동할 수 있는 규칙을 제공한다.
콘텐츠는 시스템이 실제로 재미있는지 검증한다.
새로운 콘텐츠는 기존 시스템의 한계를 발견한다.
확장된 시스템은 다시 더 다양한 콘텐츠를 만들게 한다.

따라서 가장 현실적인 개발 방식은 모든 시스템이나 모든 콘텐츠 중 하나를 먼저 완성하는 것이 아니다.

핵심 시스템을 최소한으로 만들고, 대표 콘텐츠로 검증한 뒤, 둘을 함께 확장하는 것이 중요하다.

기획 맛보기 #2 — 시스템 기획, 콘텐츠 기획, 시나리오 기획의 차이

think95592 — Thu, 13 Aug 2026 20:31:17 +0900

오늘의 한 문장

시스템 기획은 게임의 규칙을 만들고, 콘텐츠 기획은 그 규칙으로 플레이할 거리를 만들며, 시나리오 기획은 플레이에 의미와 맥락을 부여한다.

1. 게임 기획은 하나의 직무가 아니다

공부 자료에서는 게임 기획을 다음과 같이 구분했다.

시스템 기획: 게임의 구조와 규칙을 설계한다.
콘텐츠 기획: 시스템 위에 플레이할 내용을 채운다.
시나리오 기획: 세계관과 이야기, 캐릭터의 서사를 만든다.

이를 건물에 비유하면 이해하기 쉽다.

시스템 기획 = 건물의 구조와 설비
콘텐츠 기획 = 건물 안의 가구와 활동
시나리오 기획 = 그 공간이 존재하는 이유와 이야기

세 분야는 서로 독립적이지 않다. 시스템이 없으면 콘텐츠가 작동할 수 없고, 콘텐츠가 없으면 시스템을 경험할 수 없다. 시나리오는 플레이어가 그 행동을 해야 하는 이유와 감정적인 맥락을 제공한다.

Ubisoft도 게임 디자인을 플레이어의 경험을 만드는 규칙과 시스템·메커니즘의 설계로 설명한다.
Ubisoft Careers — Our Job Roles

2. 시스템 기획: 게임의 뼈대를 설계한다

시스템 기획자는 여러 콘텐츠가 공통으로 사용하는 규칙을 만든다.

예를 들어 전투 시스템을 설계한다면 다음을 정의해야 한다.

공격 입력은 언제 허용되는가?
공격이 적중했는지는 어떻게 판정하는가?
피해량은 어떤 공식으로 계산되는가?
치명타, 방어력, 회피는 어떤 순서로 적용되는가?
캐릭터가 사망하면 어떤 상태로 전환되는가?
예외 상태에서는 어떤 규칙이 우선하는가?

즉, “불 속성 검을 만든다”보다 먼저 게임에서 속성이 어떻게 작동하는가를 정한다.

주요 설계 대상

전투와 피격 판정
캐릭터 이동과 조작
적 AI
스킬과 상태이상
인벤토리와 장비
성장과 레벨업
재화의 획득과 소비
퀘스트 진행 구조
저장과 불러오기
멀티플레이 규칙

주요 결과물

시스템 개요서와 기능 명세
플로차트와 상태 전이도
계산 공식과 수치 구조
입력·조건·처리·결과·예외 규칙
UI 흐름과 화면 와이어프레임
데이터 구조와 필요한 항목
프로토타입과 테스트 조건

Riot Games의 시스템 디자이너 채용 설명에서도 성장, 건설, 자원 생산과 소비, 기능 해금 같은 구조를 설계하고, 관련 문서와 프로토타입을 만들며 프로그래머·아티스트·UI·수치 담당자와 함께 구현한다고 설명한다.
Riot Games — Game Designer, System

프로그래머와의 협업

세 분야 중 일반적으로 프로그래머와 가장 직접적이고 빈번하게 협업한다.

시스템 기획자는 “무엇이 어떤 규칙으로 작동해야 하는가”를 정의하고, 프로그래머는 이를 실제 코드와 도구로 구현한다. 구현 과정에서 기술적 한계나 더 좋은 방법이 발견되면 양쪽이 명세를 다시 조정한다.

ScreenSkills도 게임플레이 디자이너를 기술팀과 아트팀을 연결하는 역할로 설명하며, 기술적으로 구현하기 어려운 경우 프로그래머와 가능 범위를 논의해 명세를 수정한다고 소개한다.
ScreenSkills — Gameplay Designer

3. 콘텐츠 기획: 시스템 위에 플레이할 거리를 만든다

콘텐츠 기획자는 시스템이 정한 규칙을 이용해 플레이어가 실제로 만나고 경험할 대상을 만든다.

전투 시스템에 공격, 방어, 속성, 상태이상 규칙이 준비되었다면 콘텐츠 기획자는 이를 조합해 다음과 같은 내용을 만든다.

몬스터 종류와 배치
개별 스킬과 아이템
퀘스트와 보상
보스전 패턴
던전과 이벤트
상점 판매 목록
성장 구간별 콘텐츠
라이브 서비스 이벤트

쉽게 말하면 시스템 기획이 몬스터를 만들 수 있는 규칙을 설계한다면, 콘텐츠 기획은 그 규칙을 사용해 고블린, 골렘, 드래곤을 실제로 만든다.

주요 결과물

몬스터·아이템·스킬 데이터시트
퀘스트 진행표와 조건표
전투 및 보스 패턴 문서
콘텐츠 구성표와 해금 순서
등장 확률과 보상 테이블
에셋 요청 목록
게임 엔진에서 설정한 실제 데이터
플레이테스트 결과와 밸런스 수정안

콘텐츠 기획의 결과물은 문서에만 머물지 않는다. 프로젝트에 따라 기획자가 엔진이나 전용 툴에서 몬스터 수치, 퀘스트 조건, 아이템 효과를 직접 입력하고 테스트하기도 한다.

프로그래머와의 협업

협업의 직접성은 개발 도구가 얼마나 준비되어 있는지에 따라 달라진다.

필요한 시스템이나 제작 도구가 없다면 프로그래머와 직접 협의한다.
기존 시스템과 툴로 콘텐츠를 만들 수 있다면 데이터 입력과 테스트 중심으로 일한다.
콘텐츠가 기존 규칙을 벗어나면 시스템 확장을 요청한다.
오류가 콘텐츠 데이터 때문인지 시스템 코드 때문인지 함께 확인한다.

따라서 콘텐츠 기획은 시스템 기획보다 프로그래머와 덜 직접적일 수 있지만, 퀘스트 스크립트나 이벤트 트리거를 직접 다루는 프로젝트에서는 협업 강도가 상당히 높아질 수 있다.

4. 시나리오 기획: 플레이에 의미와 맥락을 만든다

시나리오 기획자는 세계관, 사건, 인물 관계와 이야기의 흐름을 설계한다.

다만 게임의 시나리오는 영화나 소설처럼 정해진 순서대로 보여주는 이야기만을 의미하지 않는다. 플레이어가 이동하거나 선택하고, 전투하고, 퀘스트를 완료하는 과정에서 이야기가 어떻게 전달될지도 함께 고려해야 한다.

주요 설계 대상

세계관과 시대적 배경
주요 사건과 전체 플롯
캐릭터의 목표와 관계
메인·서브 퀘스트의 서사
선택지와 분기
대사와 보이스오버
환경을 이용한 이야기 전달
게임플레이와 서사의 연결

주요 결과물

세계관 설정집
캐릭터 설정서
전체 플롯과 에피소드 구성표
퀘스트 시놉시스
대사 및 보이스오버 대본
분기형 대화 플로차트
컷신·연출 요청서
내러티브 트리거와 조건표
용어·고유명사·현지화 기준표

시나리오 작가와 내러티브 디자이너

두 역할은 겹칠 수 있지만 강조점이 다르다.

시나리오 작가: 이야기, 장면, 대사 자체를 작성한다.
내러티브 디자이너: 그 이야기가 게임의 규칙과 플레이를 통해 언제, 어떻게 전달되는지를 설계한다.

Ubisoft의 내러티브 디자이너들은 이 역할을 게임 메커니즘과 서사를 연결하는 직무로 설명한다. 단순히 대사를 작성하는 데 그치지 않고 대화가 시작되는 조건, 전투 중 대사가 끊겼을 때의 처리, 분기와 트리거까지 고려한다.
Ubisoft — What Is Narrative Design?

프로그래머와의 협업

시나리오 작문만 담당한다면 프로그래머와 직접 협업하는 비중이 비교적 낮을 수 있다. 하지만 내러티브 디자이너가 다음 요소까지 담당한다면 직접적인 협업이 필요하다.

대화 발생 조건
선택지와 분기 저장
컷신 진입과 종료
퀘스트 상태에 따른 대사 변화
동료의 상황별 반응
음성 재생 우선순위
전투로 대화가 중단되었을 때의 처리

따라서 시나리오 기획은 프로그래머와 거의 협업하지 않는다고 단정하기 어렵다. 현대의 내러티브 디자인은 시스템과 구현 도구를 다루는 기술적인 역할까지 포함할 수 있다.

5. 세 분야 비교

구분시스템 기획콘텐츠 기획시나리오 기획

핵심 질문	어떤 규칙으로 작동하는가?	그 규칙으로 무엇을 플레이하는가?	왜 이것을 하고 어떤 의미를 느끼는가?
중심 대상	구조, 규칙, 상태, 공식	몬스터, 스킬, 아이템, 퀘스트	세계관, 사건, 인물, 대사
성격	반복 사용되는 뼈대	뼈대를 이용한 개별 사례	플레이에 부여되는 맥락
대표 산출물	명세서, 플로차트, 공식, 데이터 구조	데이터시트, 퀘스트표, 패턴, 배치	설정집, 플롯, 대사, 분기표
프로그래머 협업	매우 직접적	중간~높음	역할에 따라 낮음~높음
주요 협업 대상	프로그래머, UI·UX, QA	시스템·레벨 기획, 아트, QA	콘텐츠·레벨 기획, 연출, 오디오, 현지화
주된 검증 방법	기능 테스트와 예외 검증	반복 플레이와 밸런스 테스트	흐름, 맥락, 전달 시점 검증

이 표는 일반적인 경향이지 모든 회사에 적용되는 고정 규칙은 아니다.

6. 같은 소재를 세 분야는 어떻게 다르게 볼까?

몬스터

분야	담당 관점
시스템 기획	AI 상태, 이동·탐지 규칙, 공격 판정, 피해와 사망 처리
콘텐츠 기획	몬스터 종류, 능력치, 스킬 조합, 출현 위치와 보상
시나리오 기획	몬스터의 기원, 세력, 행동 목적, 세계관 속 의미

예를 들어 “독 늪의 고블린”을 만든다면 다음처럼 나뉜다.

시스템: 독 상태는 2초마다 피해를 주며 최대 3회 중첩된다.
콘텐츠: 고블린 주술사는 독 투사체와 독 장판을 사용한다.
시나리오: 고블린 부족은 오염된 늪을 신성한 땅으로 믿고 지킨다.

스킬

분야	담당 관점
시스템 기획	자원 소모, 재사용 대기시간, 판정 방식, 상태이상 우선순위
콘텐츠 기획	개별 스킬의 범위, 피해량, 연출 콘셉트와 성장 수치
시나리오 기획	능력의 설정상 기원, 사용자와의 관계, 명칭과 설명문

예를 들어 “시간 정지” 스킬이라면 다음과 같다.

시스템: 일정 범위의 대상에게 시간 정지 상태를 적용한다.
콘텐츠: 지속시간은 3초이며 보스에게는 50%만 적용된다.
시나리오: 주인공이 과거의 사고로 얻은 금지된 능력이다.

아이템

분야	담당 관점
시스템 기획	획득, 보관, 장착, 사용, 중첩, 삭제 규칙
콘텐츠 기획	아이템 종류, 능력치, 희귀도, 드롭률, 제작 재료
시나리오 기획	아이템 이름, 유래, 설명문, 이야기 속 상징성

예를 들어 “왕의 부서진 검”이라면 다음과 같다.

시스템: 양손 무기이며 강화와 분해가 가능하다.
콘텐츠: 공격력 45, 치명타 확률 5%, 보스 드롭률 10%.
시나리오: 멸망한 왕국의 마지막 왕이 사용한 검의 일부다.

퀘스트

분야	담당 관점
시스템 기획	수락·진행·완료·실패 상태와 조건 판정
콘텐츠 기획	목표, 동선, 적 배치, 난이도, 보상과 소요 시간
시나리오 기획	사건의 이유, 등장인물의 동기, 대사와 선택 결과

“사라진 약초꾼 찾기” 퀘스트를 예로 들면 다음과 같다.

시스템: NPC와 대화하면 수락되고, 흔적 세 개를 조사하면 다음 단계가 열린다.
콘텐츠: 흔적은 마을에서 늪까지 이어지며 마지막 구간에 독 고블린이 등장한다.
시나리오: 약초꾼은 병든 딸을 살리기 위해 금지된 늪에 들어갔고, 플레이어는 그를 구할지 약초를 먼저 가져갈지 선택한다.

7. 실제 개발에서는 세 분야가 연결된다

퀘스트 하나를 만든다고 가정하면 다음과 같은 순환이 일어난다.

시나리오 기획
약초꾼이 늪에서 실종된 사건을 설계
        ↓
콘텐츠 기획
조사 목표, 이동 동선, 전투와 보상을 구성
        ↓
시스템 기획
조사·분기·실패 조건을 처리할 퀘스트 규칙을 확인
        ↓
프로그래머
필요한 기능과 제작 도구를 구현
        ↓
각 기획자
게임에 입력하고 플레이테스트한 뒤 함께 수정

시나리오에서 “전투 중에도 동료와 대화한다”는 장면을 요구했는데 대화 시스템이 전투를 지원하지 않을 수 있다. 반대로 프로그래머가 만든 새로운 대화 기능이 더 좋은 서사 표현으로 이어질 수도 있다.

Ubisoft가 소개한 《Bury Me, My Love》 개발 사례에서도 개발자가 제안한 셀카 기능이 서사에 활용되었고, 메시지 입력 표시 기능은 인물의 망설임과 감정을 전달하는 장치가 되었다. 기술과 이야기가 일방향으로 전달된 것이 아니라 서로의 아이디어를 발전시킨 사례다.

또한 《The Division》과 같은 온라인 게임에서는 전투와 다른 플레이어의 대화 때문에 음성 전달이 방해될 수 있어, 내러티브 디자이너가 레벨 디자이너와 협의하여 적이 없는 공간을 마련하기도 한다. 이야기를 제대로 전달하려면 시나리오뿐 아니라 시스템과 공간까지 함께 설계해야 한다.
Ubisoft — What Is Narrative Design?

8. 회사마다 직무 경계가 다른 이유

시스템·콘텐츠·시나리오라는 구분은 이해에 도움이 되지만, 업계 전체가 사용하는 절대적인 분류는 아니다.

직무 범위는 다음 조건에 따라 달라진다.

회사와 팀의 규모
게임의 장르
개발 단계
자체 제작 도구의 완성도
라이브 서비스 여부
프로젝트의 서사 비중
각 구성원의 전문성

소규모 팀

한 명의 게임 기획자가 시스템, 콘텐츠, 레벨, UI를 모두 담당할 수 있다. 시나리오 담당자가 세계관부터 대사, 퀘스트 입력까지 맡기도 한다.

대규모 팀

업무가 더 세분화될 수 있다.

전투 시스템 디자이너
경제·성장 디자이너
퀘스트 디자이너
레벨 디자이너
내러티브 디자이너
게임 라이터
테크니컬 디자이너
라이브 콘텐츠 디자이너

Ubisoft의 현직자 인터뷰에서도 내러티브 디자인의 범위는 아직 완전히 표준화되지 않았으며, 소규모 스튜디오에서는 내러티브 디자인과 작문 업무를 한 사람이 담당한다고 설명한다. 역할의 중첩 정도는 프로젝트, 스튜디오, 팀 규모에 따라 크게 달라진다.

따라서 채용 공고를 볼 때는 직무명만 확인하면 안 된다. 다음 내용을 구체적으로 살펴봐야 한다.

어떤 기능과 콘텐츠를 담당하는가?
문서 작성과 게임 내 구현 중 어디까지 맡는가?
사용하는 엔진과 제작 도구는 무엇인가?
주요 협업 대상은 누구인가?
요구하는 포트폴리오는 명세, 데이터, 퀘스트, 대본 중 무엇인가?

오늘 배운 점

처음에는 시스템 기획자는 규칙을 만들고, 콘텐츠 기획자는 수치를 채우며, 시나리오 기획자는 글을 쓰는 사람이라고 단순하게 생각했다.

하지만 실제로는 세 분야 모두 플레이어 경험을 서로 다른 관점에서 설계하는 역할이다.

시스템 기획은 플레이가 가능한 규칙을 만든다.
콘텐츠 기획은 규칙을 구체적인 경험으로 바꾼다.
시나리오 기획은 그 경험에 이유와 감정을 부여한다.

세 역할의 경계보다 더 중요한 것은 하나의 게임 안에서 서로의 결과물이 자연스럽게 연결되는가이다. 좋은 게임 기획자는 자신의 담당 분야뿐 아니라 앞뒤 분야가 무엇을 필요로 하는지도 이해해야 한다.

기획 맛보기 #1 — 게임 기획이란 무엇인가

think95592 — Wed, 12 Aug 2026 18:57:59 +0900

오늘의 한 문장

게임 기획은 머릿속의 아이디어를 팀이 같은 방향으로 이해하고, 개발자가 실제로 구현하고 테스트할 수 있는 명세로 바꾸는 과정이다.

1. 아이디어와 기획은 다르다

“적을 쓰러뜨리는 재미있는 액션 게임을 만들고 싶다”는 아이디어다. 만들고 싶은 방향은 보이지만, 이것만으로는 개발을 시작하기 어렵다.

개발하려면 적어도 다음 질문에 답할 수 있어야 한다.

플레이어는 어떤 행동을 하는가?
승리와 실패는 언제 결정되는가?
공격이 적에게 적중했는지는 어떻게 판정하는가?
적이 죽으면 무엇을 얻는가?
획득한 보상은 다음 플레이에 어떤 영향을 주는가?
플레이어에게 결과를 어떻게 전달하는가?

Unity 역시 게임 디자인 문서인 GDD를 콘셉트부터 게임 규칙, 조작법, 시각 요소, 개발 일정까지 담는 개발의 청사진으로 설명한다. 동시에 프로젝트의 규모에 따라 문서 형식과 분량은 달라질 수 있다고 안내한다. 즉, 좋은 기획은 문서가 긴가보다 개발에 필요한 판단이 들어 있는가가 중요하다.
Unity Learn — Fill out a game design document

아이디어를 명세로 바꾸는 예시

아이디어:

공격하면 적이 시원하게 날아간다.

구현 가능한 명세:

공격 버튼을 누르면 0.2초 후 공격 판정이 발생한다.
공격 범위 안의 적에게 20의 피해를 준다.
적이 피해를 받으면 공격 방향으로 3m 밀려난다.
보스와 슈퍼아머 상태의 적은 밀려나지 않는다.
적중 시 타격 이펙트, 효과음, 짧은 화면 흔들림을 출력한다.
공격이 빗나가면 적중 효과를 출력하지 않는다.

두 문장은 같은 아이디어를 다루지만, 두 번째 문장에는 입력, 조건, 결과, 예외, 피드백이 있다. 개발자와 아티스트, 사운드 담당자는 이를 바탕으로 작업을 시작할 수 있고, QA 담당자는 정상 작동 여부를 확인할 수 있다.

2. 기획자는 Why를, 개발자는 How를 본다

공부 자료에서 가장 인상적이었던 부분은 다음 구분이었다.

기획자는 왜 이런 경험이 필요한가를 생각한다.
개발자는 그 경험을 어떻게 작동시킬 것인가를 생각한다.

예를 들어 기획자가 “적의 공격 직전에 붉은 표시를 보여준다”고 정했다면, 그 이유는 단순히 화면을 화려하게 만들기 위해서가 아니다.

플레이어가 공격을 예측하고 회피했다는 성취감을 느끼게 하기 위해서다.

개발자는 이 의도를 바탕으로 경고 표시가 나타나는 시점, 공격 상태 전환, 피격 판정, 애니메이션 연동 방식을 설계한다.

다만 Why와 How를 직군별로 완전히 나누어서는 안 된다. 실제 개발에서는 기획자도 구현 비용과 기술적 제약을 알아야 하고, 개발자도 기능이 만들어야 할 플레이 경험을 이해해야 한다.

MDA 프레임워크는 이를 다음과 같이 설명한다.

규칙과 수치(Mechanics)
        ↓
플레이 중 발생하는 행동(Dynamics)
        ↓
플레이어가 느끼는 경험(Aesthetics)

디자이너는 규칙에서 경험을 향해 설계하지만, 플레이어는 먼저 경험을 느끼고 그 뒤에 있는 행동과 규칙을 발견한다. 따라서 기획자는 “어떤 기능을 넣을까?”보다 “어떤 경험을 만들고, 어떤 규칙으로 그 경험을 발생시킬까?”를 고민해야 한다.
Hunicke·LeBlanc·Zubek — MDA: A Formal Approach to Game Design and Game Research

3. 좋은 기획서의 조건

좋은 기획서는 모든 내용을 길게 설명한 문서가 아니다. 필요한 사람이 필요한 결정을 내릴 수 있게 해주는 문서다.

목적이 분명하다

기능이 존재하는 이유와 만들고자 하는 플레이 경험을 먼저 설명한다.

나쁜 예: 구르기 기능을 추가한다.
좋은 예: 근접 전투에서 공격을 피하고 곧바로 반격하는 경험을 제공하기 위해 구르기를 추가한다.

동작을 확인할 수 있다

“적절하게”, “자연스럽게”, “재미있게” 같은 표현만으로는 완료 여부를 판단하기 어렵다.

입력
발생 조건
처리 결과
성공과 실패
예외 상황
화면·소리 피드백

위 항목이 구체적일수록 구현과 테스트가 쉬워진다.

읽는 사람에게 맞는 형태를 사용한다

복잡한 흐름은 순서도, 수치 비교는 표, 공간 구조는 그림으로 표현하는 편이 좋다. 모든 정보를 긴 문장으로 적을 필요는 없다.

실제로 《SimCity》 개발에 참여한 Stone Librande는 핵심 아이디어를 팀에 전달하기 위해 3년간 100개가 넘는 한 페이지 문서를 사용했다. 이는 무조건 한 장만 써야 한다는 뜻이 아니라, 하나의 주제를 빠르게 이해할 수 있는 단위로 전달했다는 점이 중요하다.
GDC Vault — Simulating a City, One Page at a Time

변경할 수 있어야 한다

기획서는 처음 작성한 내용을 끝까지 지키는 계약서가 아니다. 프로토타입과 테스트 결과에 따라 계속 수정되는 현재의 기준점이다. Unity도 GDD를 프로젝트의 변화에 맞춰 수정하고 확장해야 하는 동적 문서로 설명한다.

따라서 문서에는 다음 정보가 있으면 좋다.

작성자와 최근 수정일
현재 확정된 내용
아직 검증이 필요한 가설
변경된 이유
관련 문서와 담당자

4. 레퍼런스는 어떻게 분석해야 할까?

레퍼런스를 찾을 때 단순히 “재미있는 게임”을 고르면 분석 범위가 너무 넓어진다. 내가 만들 게임의 문제를 해결하는 데 도움이 되는 게임을 골라야 한다.

예를 들어 보스전의 공격 예고를 기획한다면 다음처럼 범위를 좁힐 수 있다.

공격을 피할 수 있을 만큼 명확하게 알려주면서도 긴장감을 유지하는 게임

레퍼런스를 분석할 때는 기능의 외형보다 기능과 경험 사이의 인과관계를 찾아야 한다.

레퍼런스 분석 질문

플레이어가 실제로 하는 행동은 무엇인가?
게임은 어떤 규칙과 정보를 제공하는가?
그 규칙 때문에 어떤 플레이 양상이 발생하는가?
플레이어는 어떤 감정을 느끼는가?
이 요소가 해결하는 문제는 무엇인가?
우리 게임에 적용하려면 무엇을 유지하고 무엇을 바꿔야 하는가?

예시

관찰:

보스가 강한 공격 전에 무기를 크게 들어 올린다.

분석:

공격 전에 준비 동작을 보여준다.
플레이어가 공격 방향과 시점을 예측할 수 있다.
공격이 강해도 피할 기회가 있기 때문에 부당하다는 느낌이 줄어든다.
회피에 성공하면 자신의 판단과 조작 실력으로 극복했다는 성취감을 느낀다.

적용:

보스의 강한 공격에는 최소 0.8초의 고유한 준비 동작과 전용 효과음을 사용한다. 일반 공격과 실루엣이 겹치지 않도록 한다.

이렇게 분석해야 레퍼런스의 겉모습을 복사하지 않고, 그 기능이 작동하는 원리를 가져올 수 있다.

5. 콘셉트는 한 문장으로 설명할 수 있어야 한다

콘셉트 문장은 팀이 기능을 선택하거나 제거할 때 사용하는 판단 기준이다. 다음 요소를 넣으면 비교적 명확하게 정리할 수 있다.

누가 + 무엇을 반복하며 + 어떤 경험을 얻는 게임인가 + 차별점은 무엇인가

예시:

빛을 잃어가는 숲의 수호자가 낮에 자원을 모으고 밤에 거점을 방어하며, 준비와 생존의 긴장감을 경험하는 로그라이트 디펜스 게임.

이 문장에서는 다음 내용을 확인할 수 있다.

플레이어 역할: 숲의 수호자
핵심 행동: 자원 수집과 거점 방어
핵심 경험: 준비와 생존의 긴장감
장르와 구조: 로그라이트 디펜스
변형 포인트: 낮과 밤의 역할 변화

반대로 다음 문장은 콘셉트로 사용하기 어렵다.

재미있는 전투와 감동적인 스토리가 있는 액션 게임.

대부분의 게임에 적용할 수 있고, 어떤 기능을 우선해야 하는지 판단할 기준이 없기 때문이다.

Unity의 GDD 학습 자료도 프로젝트 초기에 콘셉트, 장르, 대상 플레이어와 플랫폼을 정리하고, 간단한 게임은 “누가 무엇을 모으면서 무엇을 피하는가” 같은 문장으로 출발하도록 안내한다.
Unity Learn — GDD의 콘셉트 작성 예시

6. 실제 개발에서 기획자는 무엇을 하는가?

《Super Mario 3D Land》 개발진 인터뷰에서 기획 리더는 팀에서 나온 아이디어를 조율하고 제품에 반영하는 다리 역할을 했다고 설명한다. 디렉터는 전반적인 사양과 게임의 균형을 조정했고, 디자인 리더는 Mario의 움직임과 연출 등을 담당했다. 하나의 아이디어를 실제 제품으로 만들기 위해 여러 분야의 판단을 연결한 것이다.
Nintendo — Iwata Asks: Super Mario 3D Land

후속작 《Super Mario 3D World》의 프로듀서는 게임이 전체 콘셉트를 계속 따르고 있는지 확인하는 것이 자신의 주요 역할이었다고 말했다. 당시의 방향은 2D 《New Super Mario》를 좋아하는 사람도 즐길 수 있는 거치형 3D Mario 게임이었다. 콘셉트가 단순한 홍보 문구가 아니라 개발 도중 수많은 선택을 검토하는 기준으로 사용된 사례다.
Nintendo — Iwata Asks: Super Mario 3D World

결국 실제 게임 개발에서 기획자는 다음을 연결한다.

아이디어
  ↓
플레이어에게 주고 싶은 경험
  ↓
필요한 규칙과 기능
  ↓
구현 가능한 명세
  ↓
프로토타입과 테스트
  ↓
결과에 따른 수정

오늘 배운 점

게임 기획은 좋은 아이디어를 많이 내는 일만이 아니다. 아이디어의 의도를 설명하고, 필요한 규칙을 정리하고, 여러 직군이 같은 결과를 상상할 수 있도록 전달하는 일이다.

좋은 기획서는 모든 답을 처음부터 알고 있는 문서가 아니다. 현재의 의도와 가설을 명확하게 보여주고, 구현과 테스트를 거쳐 더 나은 답으로 수정할 수 있는 문서다.

앞으로 기능을 기획할 때는 다음 네 가지부터 확인해야겠다.

이 기능은 왜 필요한가?
플레이어에게 어떤 경험을 주려는가?
개발자가 바로 구현할 만큼 구체적인가?
결과를 플레이해서 검증할 수 있는가?

[Project 4조참치] 게임 기획 회의를 ‘결정’보다 ‘검증 가능한 탐색’으로 운영해보기

think95592 — Tue, 11 Aug 2026 19:37:46 +0900

팀 프로젝트로 멀티플레이 게임을 만들기 전, 각자 만들고 싶은 게임을 제안하고 투표했다. 그 결과 표를 많이 받은 기획 세 개를 추렸지만, 지금 단계에서 곧바로 최종 기획 하나를 확정하는 것은 이르다고 느꼈다.

아직 개인 과제와 학습 기간이 남아 있고, 실제 제작은 다음 챕터에서 진행한다. 그래서 이번 팀 시간은 “최종 게임을 고르는 회의”보다, 팀이 어떤 멀티플레이 경험을 만들고 싶은지 함께 구체화하는 시간으로 운영해보려고 한다.

운영 방식

각 기획 제안자가 먼저 아래 항목을 노란 스티키로 작성한다.

타깃·상황
핵심 루프
차별점
최소 구현
폐기 기준
가장 큰 위험
다음 행동

다른 팀원은 파란 스티키로 의견을 단다. 단순히 “좋다”, “재밌을 것 같다”가 아니라 다음 형식으로 적는다.

[질문] 아직 이해되지 않거나 구체화가 필요한 점
[반례] 규칙이나 재미가 깨질 수 있는 상황
[보완] 더 강하게 만들 수 있는 방향
[범위] 첫 프로토타입에서는 빼거나 줄일 요소

회의에서 파란 의견을 확인한 뒤에는 세 가지로 처리한다.

지금 정할 수 있는 내용은 초록 스티키로 합의한다.
실제로 만들어 봐야 알 수 있는 내용은 빨간 스티키로 옮기고, 이후 검증할 질문으로 남긴다.
지금 중요하지 않은 내용은 보류한다.

멀티플레이 기획에서 추가로 볼 것

이번 프로젝트는 멀티플레이 게임을 만드는 것이 전제이므로, 각 기획에 아래 질문도 붙이기로 했다.

이 게임의 핵심 루프에서 플레이어들은 서로 어떤 방식으로 영향을 주는가?

협력, 경쟁, 역할 분담, 방해, 정보 비대칭, 공간 충돌, 관전과 리액션 중 어떤 상호작용이 핵심인지 적는다. 단순히 여러 명이 같은 게임을 하는 것이 아니라, 다른 플레이어의 행동 때문에 내 선택이나 상황이 달라지는 게임을 만들기 위해서다.

현재 단계의 목표

8월 24일까지는 개인 학습과 과제를 우선한다. 따라서 지금 팀 회의에서 목표로 삼는 것은 최종 기획 확정이 아니다.

세 기획을 팀 전체가 이해할 수 있게 구체화하기
각 기획의 핵심 멀티플레이 상호작용 찾기
최소 구현과 가장 큰 위험 확인하기
다음 챕터에서 더 탐구할 주력 후보와 예비 후보 정하기

이 방식이 실제로 잘 작동할지는 아직 검증되지 않았다. 다만 말이 많은 사람의 의견만 남거나, 추상적인 기획을 투표만으로 확정하는 일을 줄일 수 있을 것 같다.

매일 한 시간의 팀 시간을 활용해 회의 기록을 남기고, 나중에는 이 방식이 실제로 기획 결정과 협업에 도움이 됐는지도 돌아볼 예정이다.

[Unreal Engine 멀티플레이] 멀티플레이 핵심 개념 통합 복습

think95592 — Mon, 10 Aug 2026 20:44:02 +0900

0. 가장 먼저 기억할 한 문장

클라이언트는 행동의 의도를 보내고, Ownership이 요청 경로를 정하며, 서버가 권위 있는 원본을 검증·변경한다. 지속 상태는 Property Replication으로, 특정 대상의 순간 피드백은 RPC로 전달하고, 각 클라이언트는 받은 결과를 UI와 로그로 표현한다.

숫자 야구의 타자 추측 흐름으로 쓰면 다음과 같다.

Client A 입력
→ Client A가 소유한 PlayerController의 Server RPC
→ 서버 PlayerController
→ 서버 GameMode 검증·판정
→ 서버 원본 상태 변경
├─ GameState Property Replication → Client A/B OnRep → 공용 UI·로그
└─ PlayerController Client RPC → 요청자인 Client A → 개인 피드백

이 흐름을 외우는 것이 목표는 아니다. 아래 질문을 순서대로 답하면 같은 흐름을 새 기능에서도 스스로 만들 수 있어야 한다.

행동은 어느 PC에서 시작되는가?
클라이언트가 소유한 네트워크 액터는 무엇인가?
최종 판정에 사용하는 원본 데이터는 서버의 어느 객체에 있는가?
서버는 클라이언트 요청에서 무엇을 다시 검증해야 하는가?
결과는 지속 상태인가, 순간 사건인가?
누가 결과를 알아야 하며 늦게 접속해도 알아야 하는가?
Client A/B의 UI와 로그에서 무엇이 보여야 하는가?

1. 네 개의 판단 축

1.1 실행 PC

함수 이름이나 클래스 이름만 보고 실행 위치를 추측하지 않는다. 어느 인스턴스에서 누가 호출했는지를 함께 본다.

일반 함수는 호출한 현재 PC에서 실행된다.
Client A가 로컬 UI 함수를 호출하면 Client A에서 실행된다.
Client A가 유효한 Server RPC를 호출하면 RPC 본문은 서버에서 실행된다.
서버가 A 소유 PlayerController의 Client RPC를 호출하면 Client A에서 실행된다.
서버가 복제 프로퍼티를 변경하면 그 값은 관련 클라이언트로 전송되고 클라이언트의 OnRep가 실행된다.

HasAuthority()는 이 액터의 현재 인스턴스가 권위 있는 서버 인스턴스인지 묻는다. IsLocalController()는 이 PlayerController가 현재 컴퓨터의 로컬 플레이어 Controller인지 묻는다. 둘은 서로 바꿔 쓰는 조건이 아니다.

1.2 원본 데이터

원본 데이터는 최종 게임 결과를 결정할 때 신뢰하는 값이다. 클라이언트에도 같은 이름의 복제 변수가 있을 수 있지만, 그 값은 서버 원본의 복사본이다.

예를 들어 Client A의 GameState에 CurrentTryCount == 1이 보이더라도 Client A가 그 값을 2로 바꿔 서버의 시도 횟수를 증가시킬 수 있는 것은 아니다. 서버의 GameMode와 서버 GameState가 권위 있는 값을 변경해야 한다.

1.3 전달 방법

전달 수단은 데이터의 의미로 고른다.

의미	기본 수단	판단 근거
클라이언트의 행동 요청	Server RPC	클라이언트에서 서버로 의도를 전달한다.
현재도 유효한 공용 상태	Property Replication	현재 접속자와 늦은 접속자가 최신 값을 알아야 한다.
특정 플레이어의 순간 피드백	Client RPC	소유자 한 명에게 지금 한 번 전달하면 된다.
현재 접속자에게만 필요한 순간 표현	상황에 맞는 RPC	과거 사건을 늦은 접속자에게 재생할 필요가 없다.
로컬에서만 필요한 표시·임시값	로컬 함수·변수	네트워크 전송 자체가 필요 없다.

한 기능 안에서도 RPC와 Property Replication을 함께 사용할 수 있다. 요청, 판정, 상태, 표현은 서로 다른 문제이기 때문이다.

1.4 서버 검증

Server RPC가 서버에서 실행된다는 사실만으로 안전해지지 않는다. Server RPC의 인자는 클라이언트가 만든 요청이므로 서버가 다시 검사해야 한다.

검증은 보통 다음 범주로 나눈다.

요청자: 실제 연결된 유효한 플레이어인가?
역할·권한: 현재 이 행동을 할 수 있는 플레이어인가?
단계: 현재 게임 상태에서 허용되는 행동인가?
값: 개수, 범위, 형식, 중복이 올바른가?
자원: 남은 횟수, 마나, 아이템, 탄약 등이 충분한가?
시간: 서버 기준 마감과 쿨다운을 지켰는가?
중복·경쟁: 같은 요청이 두 번 적용되거나 오래된 요청이 다음 단계에 적용되지 않는가?
수명주기: 이미 종료·이탈·리셋 중인 객체와 라운드에 대한 요청은 아닌가?

2. 프레임워크 클래스의 존재 범위와 책임

Dedicated Server 1개와 Client A/B를 기준으로 본다.

객체	서버	소유 Client A	다른 Client B	적합한 책임
GameMode	있음	없음	없음	비밀 데이터, 규칙, 승패, 서버 상태 전이
GameState	있음	있음	있음	모두가 알아야 하는 현재 경기 상태
A의 PlayerState	있음	있음	있음	A의 역할·팀·점수 같은 플레이어 상태
A의 PlayerController	있음	있음	보통 없음	A의 Server RPC 입구, A 전용 Client RPC
Pawn/Character	서버와 관련 클라이언트에 복제 가능	있음	있음	월드 안 플레이어 행동과 표현
UMG UI	없음	A의 로컬 UI	B의 로컬 UI	입력 수집과 복제 결과 표현

GameMode

서버에만 존재한다.
클라이언트가 직접 접근할 수 없다.
비밀 구역과 판정 규칙을 두기에 적합하다.
UI에서 읽어야 하는 공개 상태는 GameState나 PlayerState로 옮겨야 한다.

GameState

서버와 모든 클라이언트에 존재한다.
공용 현재 상태를 복제하기에 적합하다.
모든 클라이언트에 보인다고 해서 모든 클라이언트가 소유하는 Server RPC 창구인 것은 아니다.

PlayerState

해당 플레이어뿐 아니라 다른 클라이언트에서도 필요할 수 있는 플레이어별 상태에 적합하다.
역할, 팀, 공개 점수, 관전용 정보 등에 사용한다.
개인에게만 보여야 하는 비밀 데이터를 무조건 PlayerState에 복제하면 안 된다.

PlayerController

서버에는 각 플레이어의 PlayerController가 있다.
소유 클라이언트에는 자신의 PlayerController가 있다.
다른 클라이언트의 PlayerController는 보통 없다.
그래서 Client A의 요청 입구와 Client A 전용 응답 출구로 적합하다.

UI

각 클라이언트의 로컬 표현 계층이다.
입력을 모으고 버튼을 제어할 수 있지만 게임 결과의 권위자가 아니다.
Dedicated Server에는 UI를 생성하지 않는다.

3. `MYBaseball` 타자 추측을 처음부터 끝까지 추적하기

3.1 로컬 입력

위젯의 SubmitSelectedZones()는 로컬에서 선택된 타일을 확인하고 현재 복제된 역할·단계에 따라 요청 함수를 선택한다.

타일 OnClicked
→ 위젯의 로컬 SelectedZones 변경
→ 선택 완료 버튼
→ SubmitSelectedZones()
→ PlayerController::SubmitGuessZones()

이때 SelectedZones는 아직 승인된 게임 상태가 아니다. 서버에 보내고 싶은 입력 초안이다.

클라이언트의 역할·단계 분기는 잘못된 버튼 사용을 줄이는 UX 방어다. 조작된 클라이언트가 RPC를 직접 호출할 수 있으므로 최종 권한 판정에는 사용할 수 없다.

관련 코드:

MYBaseball/Source/MYBaseball/UI/MYBaseballGameWidget.cpp
UMYBaseballGameWidget::SubmitSelectedZones()

3.2 소유한 PlayerController에서 Server RPC 호출

AMYBaseballPlayerController::SubmitGuessZones()는 IsLocalController()를 확인한 뒤 ServerSubmitGuessZones()를 호출한다.

서버 요청에는 다음이 포함된다.

선택한 구역 배열
클라이언트가 현재 보고 있는 시도 번호 ExpectedTryCount

ExpectedTryCount는 클라이언트가 시도 횟수를 결정한다는 뜻이 아니다. 서버의 현재 시도 번호와 비교해 오래된 요청을 거부하기 위한 표식이다.

관련 코드:

MYBaseball/Source/MYBaseball/MYBaseballPlayerController.h
AMYBaseballPlayerController::ServerSubmitGuessZones
MYBaseball/Source/MYBaseball/MYBaseballPlayerController.cpp
AMYBaseballPlayerController::SubmitGuessZones()

3.3 서버 PlayerController에서 RPC 본문 실행

Client A가 호출했지만 _Implementation() 본문은 서버에 있는 A의 PlayerController에서 실행된다.

Client A: ServerSubmitGuessZones(...) 호출
                   ↓ 네트워크
Server: A의 PlayerController에서 ServerSubmitGuessZones_Implementation(...) 실행

서버 PlayerController는 GetAuthGameMode<AMYBaseballGameMode>()로 서버 전용 GameMode를 얻어 TrySubmitGuessZones()에 요청을 전달한다.

GameMode를 얻지 못했을 때는 서버가 요청자에게 개인 시스템 오류를 돌려준다. 클라이언트가 직접 GameMode를 찾는 구조가 아니다.

3.4 서버 GameMode 검증

현재 TrySubmitGuessZones()가 검사하는 핵심 조건은 다음과 같다.

서버 권위에서 실행되는가?
요청 PlayerController가 유효한가?
현재 단계가 BatterGuessing인가?
ExpectedTryCount가 서버 CurrentBatterTryCount와 같은가?
서버 기준 제한시간이 남아 있는가?
요청자의 서버 PlayerState 역할이 Batter인가?
서버의 비밀 구역이 준비되어 있는가?
구역이 정확히 세 개인가?
각 구역이 1~9 범위인가?
중복 구역이 없는가?
서버 기준 시도 횟수가 세 번 미만인가?

검증에 성공한 뒤에만 타이머를 정리하고 시도를 증가시키며 적중 구역과 결과를 계산한다. 잘못된 입력이 시도를 소비하지 않게 하려면 검증 완료 전에는 권위 상태를 바꾸지 않는 순서가 중요하다.

관련 코드:

MYBaseball/Source/MYBaseball/MYBaseballGameMode.cpp
AMYBaseballGameMode::TrySubmitGuessZones()

3.5 서버 원본 상태 변경

현재 기능의 데이터 위치는 다음처럼 나뉜다.

데이터	권위 위치	공개 방식
`SecretZones`	서버 GameMode	복제하지 않음
판정용 `CurrentBatterTryCount`	서버 GameMode	화면용 현재값을 GameState에 반영
현재 시도·적중 수·맞힌 구역	서버 GameState	Property Replication
결과·아웃	서버 GameState	Property Replication
이닝 단계	서버 GameState	Property Replication
점수·주자·경기 결과	서버 GameState	Property Replication
역할·고정 팀	서버 PlayerState	Property Replication
공용 게임 로그·채팅	서버 GameState	제한된 배열로 Property Replication
개인 거부 메시지	서버에서 생성	요청자 PlayerController의 Client RPC

비밀 구역은 클라이언트 UI에 필요하지 않으며 공개하면 게임 규칙이 깨진다. 반면 현재 단계와 점수는 모든 참가자와 늦은 접속자가 알아야 하므로 GameState에 둔다.

3.6 Property Replication으로 Client A/B 갱신

GameState의 공개 상태는 ReplicatedUsing으로 선언되어 있고 GetLifetimeReplicatedProps()에서 DOREPLIFETIME으로 등록된다.

서버 GameState 값 변경
→ 복제 시스템이 관련 클라이언트에 최신 값 전송
→ Client A GameState 복사본 변경
→ Client A OnRep
→ Client B GameState 복사본 변경
→ Client B OnRep

Property Replication은 RPC처럼 프로퍼티 변경 줄에서 즉시 원격 함수를 호출하는 구조가 아니다. 네트워크 업데이트 시점에 최신 상태가 전달되며, 중간 값이 합쳐질 수도 있다. 중요한 것은 과거의 모든 변경 과정이 아니라 수신자가 최종적으로 현재 상태에 수렴하는 것이다.

관련 코드:

MYBaseball/Source/MYBaseball/Game/MYBaseballGameState.h
MYBaseball/Source/MYBaseball/Game/MYBaseballGameState.cpp
AMYBaseballGameState::GetLifetimeReplicatedProps()

3.7 Client RPC로 요청자 개인 피드백 전달

요청 거부 이유는 요청한 플레이어에게만 필요하다.

서버 GameMode 검증 실패
→ 서버 A PlayerController::SendPrivateSystemLog()
→ ClientReceivePrivateSystemLog() Client RPC
→ Client A의 로컬 로그 UI

Client B와 관전자에게는 전달하지 않는다. 과거의 개인 오류를 늦게 접속한 플레이어가 받을 필요도 없으므로 Property Replication보다 Client RPC가 적합하다.

반대로 승인된 공용 판정 상태는 A만의 피드백으로 끝내면 안 된다. Client B와 늦은 접속자도 현재 상태를 알아야 하므로 GameState 복제를 함께 사용한다.

4. RPC와 Property Replication을 구분하는 기준

Server RPC가 적합한 것

추측 제출 요청
채팅 전송 요청
재경기 동의 요청
공격 시작 요청
문 열기 요청

공통점은 클라이언트가 서버에 “이 행동을 하고 싶다”고 알리는 순간 요청이라는 것이다.

Property Replication이 적합한 것

현재 경기 단계
현재 점수와 아웃
현재 체력과 사망 상태
문이 현재 열려 있는가
현재 라운드와 남은 기회
늦게 접속한 플레이어가 즉시 알아야 하는 정보

공통점은 과거에 무슨 일이 있었는지보다 지금 값이 무엇인지가 중요하다는 것이다.

Client RPC가 적합한 것

요청자만 보는 입력 거부 이유
해당 플레이어의 개인 결과 화면 열기
소유자에게만 필요한 순간 안내

Multicast가 적합할 수 있는 것

현재 접속자에게 한 번 보여주는 폭발 이펙트
짧은 피격 효과음
과거 사건을 늦은 접속자에게 재생할 필요가 없는 순간 표현

Multicast는 지속 상태의 대체물이 아니다. 늦게 접속한 클라이언트는 과거 Multicast를 받지 못한다.

로컬 처리가 적합한 것

타일 선택 강조
마우스 오버
입력창 임시 문자열
복제된 마감 시각으로 남은 초 계산
서버 판정에 영향을 주지 않는 UI 애니메이션

5. OnRep와 UI 수명주기

OnRep의 역할

OnRep는 클라이언트의 복제값이 갱신되었을 때 표현 계층에 변화를 알리는 연결점이다. 현재 GameState는 OnRep에서 델리게이트를 Broadcast하고 위젯이 그 델리게이트를 받아 다시 그린다.

서버 Setter
→ 서버 값 변경
→ 서버에서는 Notify 직접 호출
→ Property Replication
→ 클라이언트 OnRep
→ 클라이언트 Notify/Delegate
→ 로컬 위젯 Refresh

서버가 프로퍼티를 직접 변경했을 때 서버의 OnRep 자동 호출에 의존하지 않는다. 현재 코드는 서버 Setter에서 Notify를 직접 호출하고 클라이언트 OnRep에서도 같은 Notify를 호출한다.

UI가 늦게 만들어질 수 있다

다음 순서가 가능하다.

복제값 도착
→ OnRep 실행
→ 위젯이 아직 없음
→ 위젯 생성

OnRep 이벤트만 구독하면 초기 화면이 비어 있을 수 있다. 안전한 패턴은 두 가지를 함께 사용하는 것이다.

델리게이트를 구독해 이후 변경을 받는다.
위젯 생성·바인딩 직후 Getter로 현재 상태를 읽어 즉시 한 번 갱신한다.

현재 PlayerController는 BeginPlay()와 OnRep_PlayerState()에서 위젯 생성 및 상태 바인딩을 시도한다. 개인 Client RPC가 위젯보다 먼저 도착하는 경우를 위해 최대 20개의 개인 시스템 로그 대기 큐도 사용한다.

흔한 OnRep 오해

OnRep가 게임 규칙을 판정해야 한다 → OnRep는 클라이언트 표현 갱신에 집중한다.
OnRep는 모든 중간 값을 한 번씩 보장한다 → Property Replication은 현재 상태 수렴이 목적이다.
OnRep가 실행되면 UI가 반드시 존재한다 → 객체 생성·복제·자산 로딩 순서는 다를 수 있다.
서버와 클라이언트의 OnRep 동작을 완전히 같다고 가정한다 → 서버는 Setter에서 필요한 Notify를 명시적으로 호출하는 편이 안전하다.

6. 접속과 이탈을 같은 체계로 보기

접속

서버 GameMode의 PostLogin()에서 새 참가자를 등록하고 역할과 팀을 배정한다.

클라이언트 접속
→ 서버 PlayerController/PlayerState 생성
→ 서버 GameMode::PostLogin()
→ 서버 PlayerState 역할·팀 변경
→ PlayerState Property Replication
→ 클라이언트 OnRep
→ 로컬 UI 갱신

늦게 접속한 클라이언트에게 필요한 현재 상태는 Property Replication으로 복구한다.

역할과 팀
이닝과 공수
점수와 주자
현재 경기 단계
현재 타석 상태
최근 공용 게임 로그와 채팅

늦게 접속한 클라이언트에게 필요하지 않은 것은 다시 보내지 않는다.

과거 버튼 클릭
다른 플레이어의 개인 오류 메시지
이미 끝난 짧은 이펙트
투수의 비밀 구역

이탈

서버 GameMode의 Logout()에서 참가자와 역할을 정리하고 경기 조건을 다시 평가한다.

UI에서 플레이어를 숨기는 것만으로 서버 참가자 목록이 정리되는 것은 아니다. 이탈한 플레이어가 서버의 생존자·턴·준비 목록에 남으면 다음과 같은 버그가 생긴다.

모든 플레이어가 끝났는데 경기가 종료되지 않음
존재하지 않는 플레이어의 턴을 기다림
재경기 동의가 영원히 완료되지 않음
역할이 비어 있는데 다음 참가자에게 재배정되지 않음

접속·이탈 정책도 원본은 서버가 가져야 한다.

7. 복제 비용과 정확성

정확히 동작한다고 모든 값을 매 프레임 복제하면 안 된다. 무엇을 얼마나 자주, 누구에게 보낼지 판단한다.

현재 프로젝트의 좋은 사례: 마감 시각 복제

남은 시간을 매초 복제하지 않는다.

서버가 서버 기준 마감 시각을 한 번 정한다.
GameState가 그 마감 시각을 복제한다.
각 클라이언트는 서버 시간과 마감 시각의 차이를 로컬 UI에 표시한다.
실제 시간 초과 판정은 서버가 한다.

표시는 로컬에서 부드럽게 계산하면서 판정 권위는 서버에 남고, 매초 복제 트래픽도 줄어든다.

현재 프로젝트의 공용 로그와 채팅

게임 로그는 최근 30개를 GameState 배열로 복제한다.
채팅은 최근 50개를 GameState 배열로 복제한다.
늦은 접속자가 현재 기록을 받아야 하므로 순간 Multicast보다 상태 복제가 맞다.
규모가 커지면 배열 전체 갱신 비용을 측정하고 증분 복제를 검토한다.

`ForceNetUpdate()`의 의미

ForceNetUpdate()는 원격 UI를 현재 코드 줄에서 동기식으로 즉시 바꾸는 함수가 아니다. 다음 네트워크 업데이트를 앞당기도록 요청한다. 지연과 패킷 전달, 여러 프로퍼티의 갱신 순서는 여전히 존재한다.

따라서 UI는 여러 OnRep의 고정 순서를 가정하기보다 갱신 신호를 받았을 때 필요한 현재 상태 묶음을 다시 읽는 편이 안전하다.

Relevancy, Priority, Dormancy의 위치

Relevancy는 이 연결에 이 액터를 보낼 필요가 있는지 판단한다.
Priority는 대역폭이 부족할 때 어떤 관련 액터를 먼저 보낼지 조절한다.
Dormancy는 한동안 변하지 않는 액터의 반복 확인 비용을 줄인다.
FlushNetDormancy()는 휴면 중 상태가 바뀐 액터를 다시 전송 대상으로 깨운다.

Priority를 높인다고 관련성이 없는 액터가 보이거나 휴면 상태가 자동 해제되는 것은 아니다.

8. 패키징과 Dedicated Server가 최종 검증인 이유

PIE에서는 서버와 여러 클라이언트가 한 에디터 프로세스 안에 섞여 보여 잘못된 실행 위치가 가려질 수 있다. 패키징된 Dedicated Server와 Client는 프로세스가 분리되므로 구조적 오류가 더 명확하게 드러난다.

패키징 환경에서 드러나는 문제

클라이언트 코드가 GameMode에 접근함
Dedicated Server가 UI를 만들려고 함
UI Blueprint가 cook에서 빠져 위젯 로드 실패
클라이언트와 서버가 서로 다른 기본 맵을 실행함
주소·포트·방화벽 문제로 연결 자체가 실패함
Client/Server Target 또는 엔진 빌드 환경이 맞지 않음
로그에 NetMode와 요청자가 없어 실행 위치를 구분할 수 없음

현재 `MYBaseball`의 배포 결정

Lvl_UIOnly를 Game/Server/Editor 기본 맵과 cook 대상에 사용한다.
/Game/UI를 항상 cook하여 WBP_BaseballGame 누락을 방지한다.
렌더링이 필요 없는 Dedicated Server도 같은 빈 게임 월드를 사용할 수 있다.
현재 기록상 런처 엔진은 Client/Server Target 제약이 있었다.
한글 프로젝트 경로 때문에 MSVC 중간 파일 생성 실패가 있었으므로 영문 경로의 소스 빌드 환경 검증이 남아 있다.

패키징 성공과 멀티플레이 성공은 별개다. 다음 세 단계를 각각 확인한다.

Build/Cook/Stage/Pak/Archive가 성공했는가?
Dedicated Server가 올바른 맵과 GameMode로 실행되는가?
Client A/B가 접속해 실제 RPC·복제·UI 흐름을 통과하는가?

9. 로그로 멀티플레이 흐름 진단하기

화면이 맞아 보이는 것만으로 실행 위치를 증명할 수 없다. 기능 한 번에 같은 식별 정보를 서버와 클라이언트 로그에 남긴다.

권장 로그 문맥

기능명 | NetMode | 요청자 | 함수명 | 단계 | 요청 번호 | 서버 상태 | 승인/거부 이유

타자 추측 한 번의 기대 로그는 다음과 같다.

[Guess][ClientA][Client] SubmitGuessZones ExpectedTry=0
[Guess][PlayerA][DedicatedServer] ServerSubmitGuessZones ExpectedTry=0
[Guess][PlayerA][DedicatedServer] Accepted Try=1 Hit=2 Result=None
[Guess][ClientA][Client] OnRep_AtBatStatus Try=1 Hit=2
[Guess][ClientB][Client] OnRep_AtBatStatus Try=1 Hit=2
[Guess][ClientA][Client] PrivateFeedback Accepted

PC별 기대 결과

단계	Dedicated Server	Client A	Client B
타일 입력	없음	있음	없음
로컬 Submit 함수	없음	있음	없음
Server RPC 본문	있음	없음	없음
GameMode 판정	있음	GameMode 없음	GameMode 없음
GameState 권위 변경	있음	없음	없음
GameState OnRep	서버 Setter에서 별도 Notify	있음	있음
A 전용 Client RPC	송신	수신	없음
UI 갱신	UI 없음	공용+개인	공용만

증상에서 원인 좁히기

버튼을 눌러도 서버 로그가 없다

확인 순서:

로컬 버튼 함수가 실행됐는가?
IsLocalController() 조건을 통과했는가?
Server RPC를 PlayerController 같은 소유 액터에서 호출했는가?
해당 액터와 연결이 유효한가?
서버 프로세스 로그를 보고 있는가?

서버 판정 로그는 있는데 Client A/B UI가 안 바뀐다

확인 순서:

서버가 실제 GameState 프로퍼티를 변경했는가?
프로퍼티에 ReplicatedUsing이 있는가?
DOREPLIFETIME 등록이 있는가?
액터가 복제되는가?
OnRep가 실행됐는가?
위젯이 델리게이트를 구독했는가?
위젯 생성 직후 Getter 초기화를 했는가?

Client A만 바뀌고 Client B는 안 바뀐다

공용 상태를 Client RPC로만 보낸 것은 아닌가?
GameState 대신 요청자 로컬 UI만 직접 바꾼 것은 아닌가?
B에게 해당 액터가 관련성이 있는가?
B의 OnRep와 바인딩 로그가 있는가?

늦게 접속한 Client C가 현재 상태를 모른다

현재 상태를 과거 Multicast에만 의존한 것은 아닌가?
공개 상태가 GameState/PlayerState의 복제 프로퍼티인가?
초기 UI가 현재 Getter 값을 읽는가?
휴면 액터라면 변경 시 휴면을 해제했는가?

제한시간 직전 요청이 다음 시도를 소비한다

서버 기준 마감 시각으로 검사하는가?
클라이언트가 보낸 시도 식별자를 서버 현재 시도와 비교하는가?
시간 초과 처리와 RPC 처리가 같은 서버 원본 상태를 기준으로 한 번만 전이되는가?

이탈 후 경기가 끝나지 않는다

Logout()에서 서버 참가자 목록을 제거했는가?
제거 후 종료 조건을 다시 평가했는가?
이탈한 PlayerState나 Controller 포인터를 목록에 유지하고 있지 않은가?

10. 자주 틀리는 정신 모형 교정

잘못된 생각	올바른 판단
Server RPC면 클라이언트 값을 신뢰해도 된다.	Server RPC 인자는 요청일 뿐이며 서버가 모두 재검증한다.
Replicated 액터면 아무 클라이언트나 Server RPC를 호출할 수 있다.	클라이언트→서버 RPC에는 Ownership 경로가 필요하다.
GameState는 모두에게 있으므로 클라이언트 요청 창구다.	GameState의 가시성과 클라이언트 소유권은 다르다.
UI에서 버튼을 막았으니 서버 검증은 필요 없다.	조작된 클라이언트는 UI를 우회할 수 있다.
Client RPC로 현재 상태를 보내면 복제와 같다.	늦은 접속자는 과거 Client RPC를 받지 못한다.
Multicast를 Reliable로 하면 영구 상태가 된다.	Reliable도 과거 사건을 늦은 접속자에게 재생하지 않는다.
OnRep는 서버와 클라이언트에서 항상 같은 방식으로 호출된다.	서버는 Setter에서 로컬 Notify가 별도로 필요할 수 있다.
OnRep가 실행되면 위젯이 준비되어 있다.	UI 생성 순서가 늦을 수 있어 구독과 현재값 초기화가 모두 필요하다.
복제 프로퍼티를 클라이언트에서 바꾸면 서버도 바뀐다.	서버 원본에는 영향이 없고 다음 복제에서 덮일 수 있다.
`ForceNetUpdate()`는 즉시 동기식 UI 갱신이다.	네트워크 업데이트를 앞당길 뿐 지연과 전달 순서는 남는다.
PIE에서 되면 Dedicated Server 패키지도 된다.	맵, cook, Target, 연결, 방화벽, 프로세스 분리가 별도 변수다.

11. 현재 `MYBaseball`의 확인 상태

코드에서 확인된 것

위젯에서 PlayerController로 입력 전달
소유 PlayerController의 Reliable Server RPC
서버 GameMode의 역할·단계·값·시간·시도 검증
GameMode의 비밀 구역 서버 전용 보관
GameState의 경기 상태 Property Replication
GameState OnRep와 델리게이트 기반 UI 갱신
PlayerState 역할·팀 복제
요청자 전용 개인 시스템 로그 Client RPC
UI 생성 전 개인 RPC를 위한 대기 큐
PostLogin() 역할 배정과 Logout() 정리
서버 마감 시각 복제와 로컬 카운트다운 계산
공용 로그·채팅의 제한된 배열 복제
UI 전용 기본 맵과 명시적 cook 설정

저장된 실행 로그에서 확인된 것

서버의 역할 배정
서버의 비밀 구역 승인
서버의 타자 추측 판정
여러 시도와 아웃·홈런 결과

12. 마지막 자가 설명 기준

타자 추측 제출을 다음 수준으로 설명할 수 있어야 한다.

Client A의 로컬 UI는 추측 의도만 만들고, A가 소유한 PlayerController의 Server RPC를 호출한다.

RPC 본문은 서버의 A PlayerController에서 실행되고 서버 전용 GameMode로 요청을 전달한다.

GameMode는 요청자의 역할, 현재 단계, 서버 마감시간, 시도 번호, 입력 개수·범위·중복, 남은 기회를 검사한 뒤에만 비밀 구역과 비교하고 권위 상태를 변경한다.

공용 현재 상태는 서버 GameState에서 복제되어 Client A/B의 OnRep와 UI를 갱신한다.

요청자만 알아야 하는 거부 이유는 A의 PlayerController Client RPC로 보낸다.

늦은 접속자는 과거 RPC가 아니라 GameState와 PlayerState의 현재 복제값으로 화면을 복구한다.

Dedicated Server에는 UI가 없으며, 서버 판정 로그와 Client A/B의 OnRep·개인 피드백 로그를 분리해 전체 흐름을 검증한다.

이 설명에서 함수 이름이 바뀌어도 실행 PC·원본 데이터·전달 방법·검증 조건을 유지할 수 있으면 다른 멀티플레이 기능에도 적용할 수 있다.

[Unreal Engine 멀티플레이] 패키징과 Dedicated Server 배포 준비

think95592 — Fri, 7 Aug 2026 20:08:06 +0900

오늘의 목표

에디터의 PIE에서 실행하는 것과 실제 패키징된 게임의 차이를 이해하고, 일반 Game 빌드와 Dedicated Server 배포에 필요한 준비 사항을 점검했다.

추가로 서버가 잘못된 입력을 거부했을 때, 요청한 플레이어에게만 오류를 보여주는 Client RPC 시스템 로그도 구현했다.

1. PIE와 패키징 실행의 차이

PIE는 Unreal Editor 내부에서 빠르게 게임을 시험하는 개발 환경이다. 에디터가 콘텐츠와 모듈을 직접 제공하므로, 패키징에서 누락될 자산이나 실행 환경 문제를 발견하지 못할 수 있다.

반면 패키징 실행은 다음 과정을 거친 독립 프로그램이다.

Build: C++ 코드와 모듈 컴파일
Cook: 맵, Blueprint, 이미지 등의 자산을 플랫폼용으로 변환
Stage: 실행에 필요한 파일을 임시 배포 폴더에 모음
Package: 실행 파일과 Pak 파일로 묶음
Archive: 최종 배포 폴더로 복사

따라서 “PIE에서 된다”는 것이 “패키지에서도 된다”는 뜻은 아니다.

2. Unreal의 Build Target

Unreal에는 실행 목적에 따른 Target이 있다.

Editor: Unreal Editor에서 프로젝트를 실행하기 위한 빌드
Game: 일반 독립 실행 게임
Client: 서버 기능을 제외한 전용 클라이언트
Server: 렌더링과 로컬 플레이어가 없는 Dedicated Server

이번 프로젝트에는 다음 Target을 준비했다.

MYBaseball.Target.cs
MYBaseballEditor.Target.cs
MYBaseballClient.Target.cs
MYBaseballServer.Target.cs

일반 Game 빌드는 Listen Server와 클라이언트 역할을 모두 수행할 수 있다. 하지만 진짜 Dedicated Server 실행 파일을 만들려면 Server Target 빌드가 필요하다.

현재 설치된 런처판 UE 5.7에서는 Client/Server Target 빌드가 거부됐다. Epic의 공식 Dedicated Server 문서도 소스 빌드 엔진을 전제로 안내한다.

3. UI 전용 게임의 맵 설정

이 프로젝트는 캐릭터나 월드 렌더링 없이 UI만 사용한다. 따라서 빈 맵인 Lvl_UIOnly를 클라이언트와 서버의 기본 맵으로 지정했다.

[/Script/EngineSettings.GameMapsSettings]
GameDefaultMap=/Game/UI/Lvl_UIOnly.Lvl_UIOnly
ServerDefaultMap=/Game/UI/Lvl_UIOnly.Lvl_UIOnly
EditorStartupMap=/Game/UI/Lvl_UIOnly.Lvl_UIOnly

패키징할 맵과 UI 폴더도 명시했다.

[/Script/UnrealEd.ProjectPackagingSettings]
+MapsToCook=(FilePath="/Game/UI/Lvl_UIOnly")
+DirectoriesToAlwaysCook=(Path="/Game/UI")

처음에는 WBP_BaseballGame이 C++의 Soft Reference로만 연결되어 패키지에서 누락됐다. UI 폴더를 항상 Cook하도록 설정한 뒤 Blueprint UI가 정상적으로 포함됐다.

4. 일반 Game 빌드로 멀티플레이 테스트

Dedicated Server가 없어도 일반 Game 빌드를 두 개 실행해 기본 네트워크 흐름을 시험할 수 있다.

첫 번째 게임은 Listen Server로 실행한다.

.\MYBaseball.exe "/Game/UI/Lvl_UIOnly?listen" -log

두 번째 게임은 로컬 서버에 접속한다.

.\MYBaseball.exe "127.0.0.1:7777" -log

여기서 127.0.0.1은 현재 컴퓨터 자신을 의미하고, 7777은 Unreal 게임 서버의 기본 포트다.

Listen Server 테스트에서는 두 플레이어의 역할 배정, Server RPC, 상태 복제, Client RPC 등을 확인할 수 있다. 다만 렌더링 없는 전용 서버 환경 자체를 검증하는 것은 아니다.

5. UDP와 RDP의 차이

처음에는 UDP와 RDP라는 용어가 헷갈렸다.

UDP: 게임 데이터가 오가는 통신 방식
7777/UDP: Unreal 게임 클라이언트가 서버에 접속하는 기본 포트
RDP: Windows 서버 화면에 원격 접속하기 위한 Remote Desktop Protocol
3389/TCP: RDP가 주로 사용하는 포트

즉, RDP는 서버 관리용이고 UDP 7777은 실제 게임 접속용이다. 게임 클라이언트가 RDP 포트로 접속하는 것이 아니다.

6. 요청자에게만 보이는 Client RPC 시스템 로그

잘못된 입력을 공용 GameState 로그에 기록하면 상대 플레이어와 관전자에게도 보인다. 하지만 입력 거부 사유는 요청한 플레이어에게만 보여야 한다.

따라서 다음 흐름으로 구현했다.

로컬 UI 입력
→ 소유 PlayerController의 Server RPC
→ 서버 GameMode 검증
→ 거부 시 같은 PlayerController의 Client RPC
→ 요청자 GameLogText에만 [시스템] 로그 표시

Client RPC는 다음과 같이 선언했다.

UFUNCTION(Client, Reliable)
void ClientReceivePrivateSystemLog(const FString& Message);

서버는 요청을 거부할 때 해당 PlayerController로만 메시지를 보낸다.

if (!bAccepted)
{
    SendPrivateSystemLog(ErrorMessage);
    return;
}

클라이언트는 받은 메시지를 로컬 배열에 저장한다.

PrivateSystemLogEntries.Add(
    FString::Printf(TEXT("[시스템] %s"), *SanitizedMessage));

화면의 GameLogText에는 공용 경기 로그와 로컬 개인 로그를 합쳐 표시한다. 개인 로그 배열은 복제하지 않으므로 상대 플레이어의 화면에는 나타나지 않는다.

현재 시스템 로그는 다음과 같이 한글로 표시된다.

[시스템] 구역은 3개까지만 선택할 수 있습니다.
[시스템] 현재 단계에서는 타자가 추측을 제출할 수 없습니다.
[시스템] 제한 시간이 끝난 뒤 추측이 도착했습니다.
[시스템] 채팅 메시지는 120자까지 입력할 수 있습니다.

7. 패키징 과정에서 발견한 문제

한글 프로젝트 경로

프로젝트의 상위 경로에 한글이 포함되어 MSVC가 중간 컴파일 파일을 만들지 못했다.

Cannot open compiler intermediate file
Invalid argument

영문 임시 경로로 복사하자 같은 코드가 정상적으로 컴파일됐다. 전용 서버 작업 전 프로젝트를 D:\MYBaseball 같은 영문 경로로 옮길 필요가 있다.

런처 엔진의 Target 제한

일반 Editor와 Game Target은 성공했지만 Client와 Server Target은 다음 메시지와 함께 실패했다.

Client targets are not currently supported from this engine distribution.
Server targets are not currently supported from this engine distribution.

따라서 Dedicated Server 단계에서는 UE 소스 빌드 엔진을 준비해야 한다.

Soft Reference 자산 누락

첫 패키지에서는 WBP_BaseballGame을 찾을 수 없다는 경고가 발생했다. UI 폴더를 DirectoriesToAlwaysCook에 추가한 후 해결됐다.

8. 현재까지 검증한 내용

UE 5.7 Editor Target 컴파일
일반 Game Target 컴파일
Windows Build, Cook, Stage, Pak, Archive
패키지에서 Lvl_UIOnly 로드
MYBaseballGameMode 적용
Blueprint UI 포함
Client RPC 개인 시스템 로그 구현
시스템 로그 한글화

아직 U8 전체를 통과한 것은 아니다. 일반 Game 패키징은 완료했지만 Dedicated Server와 외부 접속 시험이 남아 있다.

9. 남은 작업

프로젝트를 영문 경로로 이동
UE 소스 빌드 엔진 준비
Client/Server Target 빌드
Dedicated Server와 Client A/B 실행
개인 시스템 로그가 요청자에게만 보이는지 확인
외부 네트워크 또는 클라우드 VM 접속
주소, 포트, 방화벽, 프로세스, 맵, 로그 순서로 접속 실패 진단
테스트 후 인스턴스 중지·삭제와 비용 확인
팀원이 따라 할 수 있는 배포 문서 작성

오늘의 핵심 정리

PIE 성공만으로 배포 가능 상태라고 판단하면 안 된다. 코드뿐 아니라 맵과 UI 자산이 Cook에 포함되는지 실제 패키지를 실행해서 확인해야 한다.

또한 공용 상태는 GameState에 복제하지만, 특정 플레이어만 알아야 하는 입력 거부 사유는 소유 PlayerController의 Client RPC로 보내야 한다.

마지막으로 Dedicated Server 배포는 실행 파일만 만드는 작업이 아니다. 빌드 환경, 주소, UDP 포트, 방화벽, 서버 로그, 클라우드 비용과 종료 절차까지 하나의 배포 과정으로 봐야 한다.

[Unreal Engine 멀티플레이] 게임 사이클과 복제 최적화

think95592 — Thu, 6 Aug 2026 19:19:21 +0900

멀티플레이 게임의 전체 흐름은 클라이언트 UI가 아니라 서버 상태 머신이 결정한다.

Lobby → Countdown → Playing → Ending → Returning → Lobby

클라이언트는 버튼을 누르거나 화면을 표시할 뿐이고, 실제 참가·시작·승패·종료·복귀 판정은 서버가 책임진다.

1. 게임 사이클의 상태 책임

클래스책임

GameMode	서버 전용. 상태 전이, 참가자 관리, 시작 조건, 승패 판정, 종료 처리
GameState	모두가 봐야 하는 현재 경기 상태를 복제. 현재 단계, 종료 시각, 생존자 수, 최종 결과
PlayerState	플레이어별 지속 상태. 생존/탈락/관전자 여부, 등수, 팀
PlayerController	각 플레이어의 입력과 개인 UI. Server RPC 요청 창구, Client RPC 수신 대상
UMG/UI	로컬 표현 계층. 게임 규칙이나 승패를 결정하지 않음

핵심은 다음과 같다.

서버가 원본 상태를 바꾸고, GameState와 PlayerState가 그 결과를 복제하며, 각 클라이언트 UI는 복제값을 화면에 표현한다.

Dedicated Server에는 UI를 만들지 않는다. UI는 각 클라이언트의 로컬 PlayerController가 생성한다.

2. 접속 이벤트별 책임

이벤트	역할
PreLogin	PlayerController 생성 전 접속 허용 여부 검사. 정원 초과, 차단 등은 ErrorMessage로 거부
Login	서버가 PlayerController를 생성하는 단계
PostLogin	접속 성공 후 참가자 등록, 역할 배정, 관전자/다음 라운드 대기 처리
PostNetInit	복제 액터의 초기 네트워크 상태가 준비된 뒤 필요한 초기화 확인. 로컬 UI 작업은 로컬 클라이언트인지 별도 확인
Logout	이탈자를 참가자·생존자 목록에서 제거하고 종료 조건 재검사

특히 Logout은 단순한 목록 삭제가 아니다. 플레이어가 나가면 “남은 생존자가 몇 명인가?”가 바뀌므로, 서버는 즉시 승패·종료 조건을 다시 판단해야 한다.

Logout(B)
→ Registered와 Alive에서 B 제거
→ 종료 조건 재검사
→ A만 생존했다면 Ending 전이
→ 연결 중인 A에게 결과 Client RPC 전송

연결이 끊긴 B에게 RPC를 보내려 하면 안 된다. 이미 존재하지 않는 네트워크 연결이기 때문이다.

3. UI 전달 방식: 지속 상태와 개인 명령 구분

GameState 복제

현재 경기 단계, 종료 카운트다운, 생존자 수, 최종 순위처럼 늦게 접속한 사람도 알아야 하는 값은 GameState에 복제한다.

서버: Phase를 Playing → Ending으로 변경
→ GameState::Phase 복제
→ Client A/B의 OnRep_Phase 실행
→ 각자 로컬 UI 갱신

Client RPC

“이 플레이어에게 지금 결과창을 열어라”처럼 개인에게 한 번 전달하는 명령은 해당 PlayerController의 Client RPC가 적합하다.

서버 GameMode
→ 승자 PlayerController의 Client RPC
→ 승자 클라이언트에서 개인 결과 UI 표시

둘은 함께 쓸 수 있다.

GameState: 지금 게임이 Ending이라는 공용 사실
Client RPC: 특정 플레이어에게 결과 UI를 열라는 개인 명령

4. 중간 접속자 정책

Playing 중에도 접속을 허용할 수 있다. 이 경우 PostLogin에서 새 플레이어를 생존자가 아니라 관전자 또는 다음 라운드 대기자로 등록해야 한다.

PostLogin(NewPlayer)
→ 현재 Phase 확인
→ Playing이면 Spectator로 등록
→ Alive 목록에는 넣지 않음
→ GameState의 현재 복제값으로 UI 초기화

중간 접속자가 과거의 Multicast RPC를 받지 못할 수 있으므로, 현재 경기 상태를 과거 RPC에만 의존하면 안 된다. GameState의 현재 복제값으로 UI를 초기화해야 한다.

5. 복제 최적화: 하나의 네트워크 예산 문제

복제 최적화는 “모든 복제를 줄이자”가 아니다.

필요한 사람에게, 필요한 상태만, 필요한 빈도로 보내서 서버의 네트워크 예산을 지키는 설계다.

항목	서버가 답하는 질문	예시
Relevancy	이 클라이언트에게 이 액터가 필요한가?	멀리 있는 아이템은 보내지 않음
Dormancy	이 액터가 당분간 안 바뀌는가?	닫힌 문은 반복 전송 중단
NetUpdateFrequency	얼마나 자주 갱신 후보로 볼 것인가?	플레이어는 자주, 문은 적게
NetPriority	혼잡할 때 무엇부터 보낼 것인가?	플레이어 이동을 장식물보다 우선

// 플레이어: 초당 약 30번 갱신 후보
NetUpdateFrequency = 30.0f;

// 문: 초당 약 2번 갱신 후보
NetUpdateFrequency = 2.0f;

NetUpdateFrequency = 30.0f는 “3초에 한 번”이 아니라 초당 약 30번, 즉 약 0.033초 간격으로 갱신 후보가 된다는 의미다. 실제 전송은 관련성, 휴면 상태, 네트워크 예산에 따라 더 늦어질 수 있다.

6. 문·아이템·플레이어 정책

액터	정책
문	근처 플레이어에게만 관련성 유지. 열고 닫는 동안 상태 복제, 멈추면 휴면
드롭 아이템	가까운 플레이어에게만 전송. 바닥에 멈추면 낮은 빈도 또는 휴면
플레이어	이동·전투가 중요하므로 문보다 높은 갱신 빈도와 우선순위
개인 인벤토리	소유자에게만 조건 복제 검토
공용 점수·경기 단계	GameState에 필요한 값만 복제

문이 닫힌 상태로 오래 멈췄다면 서버는 휴면시킬 수 있다.

SetNetDormancy(DORM_DormantAll);

하지만 휴면 중인 문을 다시 열 때는 서버가 먼저 깨워야 한다.

FlushNetDormancy();
bIsOpen = true;
ForceNetUpdate();

FlushNetDormancy() 없이 상태만 변경하면, 서버 로그에는 열린 것으로 보이지만 클라이언트는 계속 닫힌 문을 볼 수 있다.

NetPriority를 높이는 것만으로는 이 문제를 해결할 수 없다. 휴면 또는 관련성 단계에서 이미 제외된 액터는 우선순위를 비교하는 단계까지 가지 못하기 때문이다.

7. 디버그 로그 예시

[Server] Logout: B removed from Alive. AliveCount 2 -> 1
[Server] EndCheck: AliveCount=1, Winner=A, Phase -> Ending
[Server] Door: FlushDormancy, bIsOpen=true
[Client B] OnRep_DoorState: Open

로그에는 최소한 다음을 남기는 것이 좋다.

어떤 서버 상태가 바뀌었는가
누가 참가/이탈했는가
생존자 수와 현재 Phase는 무엇인가
휴면을 깼는가
클라이언트가 복제된 상태를 실제로 받았는가

정리

멀티플레이 구조를 설계할 때는 항상 다음 순서로 생각한다.

서버가 결정해야 하는 상태인가?
모두가 현재도 알아야 하는 지속 상태인가?
특정 한 명에게만 전달할 명령인가?
늦게 접속한 사람도 현재 상태를 알아야 하는가?
이 액터와 값은 누구에게, 얼마나 자주 보내야 하는가?

게임 사이클은 서버 상태 머신으로 지키고, 복제 최적화는 그 상태를 필요한 대상에게 필요한 비용으로 전달하는 일이다.

[Unreal Engine 멀티플레이]전투·애니메이션·컴포넌트 동기화

think95592 — Wed, 5 Aug 2026 17:22:32 +0900

핵심 원칙

전투 기능은 입력, 서버 판정, 애니메이션, 피해 상태, UI를 분리한다.

클라이언트 입력
→ Server RPC
→ 서버 검증·명중 판정·피해 적용
→ 지속 상태 복제
→ 각 클라이언트 UI 갱신

클라이언트는 공격 의도를 요청하고 화면을 표현한다. 서버는 공격 가능 여부, 명중 대상, 피해량, 사망을 최종 결정한다.

RPC와 Property Replication 구분

Server RPC: 클라이언트가 서버에 공격을 요청할 때 사용한다.
NetMulticast RPC: 공격 몽타주, 타격 이펙트, 사운드처럼 한 번 재생하면 끝나는 표현에 사용한다.
Property Replication: 체력, 사망, 보호막처럼 늦게 접속한 플레이어도 현재값을 알아야 하는 상태에 사용한다.

예를 들어 공격 이펙트는 늦게 접속한 플레이어가 과거분까지 볼 필요가 없지만, 체력 70과 사망 여부는 반드시 현재 상태로 받아야 한다.

서버 권위 공격 설계

클라이언트는 다음처럼 최소 정보만 보낸다.

ServerRequestAttack();

클라이언트가 대상, 피해량, 치명타 여부를 보내면 조작할 수 있으므로 서버가 직접 결정한다.

서버 검증 항목:

살아 있는가
현재 공격 가능한 상태인가
쿨다운이 끝났는가
무기 상태가 올바른가
서버 기준 공격 범위 안에 대상이 있는가
서버 Trace 또는 Overlap 결과로 실제 명중했는가

Trace와 충돌 옵션

LineTraceSingleByChannel은 서버가 공격자 앞에 있는 대상을 찾는 가상 선 충돌 검사다.

FCollisionQueryParams Params(
    SCENE_QUERY_STAT(MeleeAttack),
    false,
    this);

GetWorld()->LineTraceSingleByChannel(
    Hit, Start, End, ECC_Pawn, Params);

Params를 먼저 만드는 이유는 충돌 검사 규칙을 설정하기 위해서다.

this: 공격자 자신은 충돌 검사에서 제외한다.
false: 단순 충돌을 사용한다.
ECC_Pawn: Pawn 충돌 채널을 검사한다.

자기 자신을 제외하지 않으면 공격 시작점 근처의 공격자 캡슐을 먼저 맞힐 수 있다.

공격 상태와 중복 피해 방어

서버는 공격 상태를 소유한다.

Idle → Windup → Active → Recovery → Idle

Idle 상태일 때만 새 공격 요청을 승인한다. 따라서 클라이언트가 공격 요청을 여러 번 보내도 첫 요청 뒤에는 이미 Windup 상태이므로 나머지 요청을 거부할 수 있다.

같은 휘두름 중 같은 대상에게 여러 프레임 피해가 들어가는 문제는 서버 전용 피격 대상 집합으로 막는다.

TSet<TObjectPtr<AActor>> HitActorsThisAttack;

한 공격에서 이미 맞힌 대상이면 다시 피해를 적용하지 않는다. 이 목록은 UI나 늦은 접속자에게 필요하지 않은 서버 내부 처리이므로 복제하지 않는다.

애니메이션과 피해 판정

공격 몽타주는 표현이고, 피해 판정은 게임 규칙이다.

몽타주가 보인다고 명중한 것은 아니다.
클라이언트 AnimNotify로 피해를 확정하면 안 된다.
서버가 공격 시작 후 정해진 공격 창에서 Trace/Overlap을 실행해 명중을 판정한다.
긴 공격·차징처럼 진행 시점이 중요한 몽타주는 서버 시작 시각 또는 공격 상태를 함께 동기화할 수 있다.

AimOffset 동기화

내 캐릭터는 입력 직후 ControlRotation을 바꾸고 즉시 AimOffset을 계산해 표현한다. 다른 클라이언트는 서버가 복제한 캐릭터 회전과 필요한 조준 원본을 받아 자기 AnimInstance에서 AimOffset을 계산한다.

내 캐릭터: 로컬 입력 → 즉시 표현 → 서버 검증
남의 캐릭터: 서버 복제본 수신 → 로컬 AnimInstance 표현

애니메이션 파라미터인 AimYaw, AimPitch는 보통 복제하지 않고, 각 클라이언트가 회전 원본으로 계산한다.

HealthComponent와 UI

체력과 사망 상태는 UHealthComponent에 둔다.

서버 HealthComponent가 원본 변경
→ CurrentHealth / bIsDead 복제
→ 클라이언트 OnRep 실행
→ UI 체력바 갱신

UI는 체력을 직접 바꾸거나 판정하지 않는다. 복제된 현재값을 읽어 그리기만 한다.

또한 UI가 복제 알림보다 늦게 생성될 수 있으므로, 이벤트 구독 후 현재 체력값으로 한 번 초기화해야 한다.

디버깅 기준

“공격 애니메이션은 보이는데 체력이 안 깎인다”면 다음 순서로 확인한다.

서버가 ServerRequestAttack을 승인했는가?
서버의 공격 상태가 올바르게 전환됐는가?
서버 HitWindow가 시작됐는가?
서버 Trace의 Start, End, 충돌 채널, 자기 자신 제외 설정이 맞는가?
HitActor가 실제 대상인가?
서버가 ApplyDamageOnServer를 호출했는가?
CurrentHealth 복제와 클라이언트 OnRep가 실행됐는가?

HitActor=None이면 애니메이션 재생 여부와 별개로 서버 명중 판정이 실패한 것이므로 체력이 줄지 않는 것이 정상이다.

[Unreal Engine 멀티플레이] 남은 시간이 아닌 마감 시각을 복제하는 서버 권위 타이머

think95592 — Tue, 4 Aug 2026 19:23:43 +0900

오늘의 학습 목표

오늘은 멀티플레이 숫자 야구의 타자 입력 제한 시간을 구현하면서 네트워크 타이머를 동기화하는 방법을 학습했다.

핵심은 서버가 15, 14, 13...처럼 남은 시간을 계속 보내는 것이 아니다.

서버는 타이머가 언제 끝나는지를 나타내는 마감 시각 하나만 복제하고, 각 클라이언트가 동기화된 서버 시간과 비교해 남은 시간을 직접 계산한다.

남은 시간 = 마감 서버 시각 - 현재 서버 시각

이 구조를 사용하면 네트워크 복제 횟수를 줄이면서도 모든 클라이언트에서 비슷한 카운트다운을 표시할 수 있다.

1. 핵심 아이디어

현재 서버 시간이 100초이고 제한 시간이 15초라고 가정해 보자.

서버는 다음 값을 계산한다.

마감 시각 = 100 + 15
          = 115초

그리고 115라는 고정된 마감 시각을 GameState를 통해 클라이언트에 복제한다.

각 클라이언트는 매 프레임 다음 계산만 수행한다.

남은 시간 = 115 - 현재 서버 시각

예를 들어 클라이언트가 추정한 현재 서버 시각이 108.3초라면 다음과 같다.

남은 시간 = 115 - 108.3
          = 6.7초

서버가 남은 시간을 매초 복제할 필요 없이 시작할 때 계산한 마감 시각 하나만 전달하면 된다.

2. 전체 실행 흐름

서버 GameMode
├─ 현재 서버 시각 확인
├─ 현재 서버 시각 + 제한 시간 계산
├─ GameState에 마감 시각 저장
└─ 실제 시간 초과 판정용 서버 타이머 시작
            ↓
서버 GameState
└─ 마감 시각을 모든 클라이언트에 복제
            ↓
각 클라이언트 GameState
└─ RepNotify로 마감 시각 변경 감지
            ↓
각 클라이언트 UMG
├─ 마감 시각 - 현재 서버 시각 계산
├─ 남은 시간을 정수로 변환
└─ 화면에 카운트다운 표시

여기서 화면의 카운트다운과 실제 시간 초과 판정은 서로 다른 책임을 가진다.

클라이언트 UMG
= 남은 시간을 계산해서 보여 주는 역할

서버 GameMode
= 실제 기회를 종료하고 아웃을 판정하는 역할

클라이언트 화면에 0초가 표시됐다는 이유만으로 클라이언트가 직접 게임 상태를 변경해서는 안 된다.

3. 마감 시각을 GameState에 저장하는 이유

마감 시각은 모든 참가자가 알아야 하는 현재 경기 상태다.

타자는 자신의 남은 시간을 확인해야 한다.
투수도 타자의 남은 시간을 확인할 수 있다.
관전자도 현재 카운트다운을 볼 수 있다.
늦게 접속한 클라이언트도 현재 남은 시간을 계산해야 한다.

GameMode는 서버에만 존재하므로 클라이언트가 접근할 수 없다. 반면 GameState는 서버와 모든 클라이언트에 존재하며 공용 상태를 복제하기에 적합하다.

UPROPERTY(ReplicatedUsing =
    OnRep_BatterGuessDeadlineServerTime)
float BatterGuessDeadlineServerTime = 0.0f;

0.0f는 현재 활성화된 타자 입력 타이머가 없다는 의미로 사용한다.

4. RepNotify 구성

마감 시각이 클라이언트에 복제되면 OnRep 함수가 호출된다.

UFUNCTION()
void OnRep_BatterGuessDeadlineServerTime();

void AMYBaseballGameState::
    OnRep_BatterGuessDeadlineServerTime()
{
    NotifyBatterGuessDeadlineChanged();
}

현재 위젯은 매 프레임 GameState의 값을 확인하지만, RepNotify를 함께 구성하면 다음과 같은 확장도 가능하다.

타이머 시작 애니메이션
경고음 재생
타이머 패널 표시
다른 UI에 타이머 변경 이벤트 전달
이벤트 기반 UI 갱신

5. DOREPLIFETIME 등록

UPROPERTY(ReplicatedUsing = ...)를 선언하는 것만으로는 프로퍼티 복제가 완성되지 않는다.

GetLifetimeReplicatedProps()에 해당 프로퍼티를 등록해야 한다.

#include "Net/UnrealNetwork.h"

void AMYBaseballGameState::GetLifetimeReplicatedProps(
    TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);

    DOREPLIFETIME(
        ThisClass,
        BatterGuessDeadlineServerTime
    );
}

두 코드의 역할은 다음과 같다.

UPROPERTY(ReplicatedUsing = ...)
= 복제 대상이며 어떤 OnRep 함수를 사용할지 선언

DOREPLIFETIME(...)
= 언리얼의 실제 프로퍼티 복제 목록에 등록

둘 중 하나가 누락되면 기대한 대로 복제되지 않을 수 있다.

6. 서버에서 마감 시각 생성하기

타자의 입력 시간이 시작되면 GameMode가 마감 시각을 계산하고 실제 판정용 타이머를 설정한다.

void AMYBaseballGameMode::StartBatterGuessTimer()
{
    if (!HasAuthority())
    {
        return;
    }

    AMYBaseballGameState* BaseballGameState =
        GetGameState<AMYBaseballGameState>();

    if (!IsValid(BaseballGameState)
        || BaseballGameState->GetInningPhase()
            != EMYInningPhase::BatterGuessing)
    {
        return;
    }

    GetWorldTimerManager().ClearTimer(
        BatterGuessTimerHandle
    );

    const float DeadlineServerTime =
        BaseballGameState->GetServerWorldTimeSeconds()
        + BatterGuessTimeLimitSeconds;

    BaseballGameState
        ->SetBatterGuessDeadlineServerTime(
            DeadlineServerTime
        );

    GetWorldTimerManager().SetTimer(
        BatterGuessTimerHandle,
        this,
        &ThisClass::HandleBatterGuessTimeout,
        BatterGuessTimeLimitSeconds,
        false
    );
}

제한 시간은 상수로 관리했다.

static constexpr float BatterGuessTimeLimitSeconds =
    15.0f;

현재 서버 시간이 203.4초라면 마감 시각은 다음과 같다.

현재 서버 시각 : 203.4
제한 시간      :  15.0
마감 서버 시각 : 218.4

GameState에는 남은 시간 15가 아니라 마감 시각 218.4가 저장되고 복제된다.

7. 기존 타이머를 먼저 제거하는 이유

새로운 타이머를 시작하기 전에 기존 타이머를 제거한다.

GetWorldTimerManager().ClearTimer(
    BatterGuessTimerHandle
);

이전 시도의 타이머가 남아 있으면 다음과 같은 문제가 발생할 수 있다.

첫 번째 시도의 타이머
두 번째 시도의 타이머

두 타이머가 동시에 살아 있으면 첫 번째 타이머의 콜백이 나중 시도를 시간 초과로 처리할 수 있다.

따라서 같은 용도의 타이머를 다시 시작하기 전에는 기존 TimerHandle을 정리해야 한다.

8. 서버 타이머와 마감 시각의 역할

서버에서 생성한 마감 시각은 UI 표시를 위한 기준이지만, 마감 시각만 저장한다고 실제 게임 로직이 실행되지는 않는다.

GetWorldTimerManager().SetTimer(
    BatterGuessTimerHandle,
    this,
    &ThisClass::HandleBatterGuessTimeout,
    BatterGuessTimeLimitSeconds,
    false
);

이 서버 타이머가 실제로 다음 함수를 호출한다.

HandleBatterGuessTimeout();

두 장치의 역할은 다음과 같다.

복제된 마감 시각
= 각 클라이언트가 화면의 남은 시간을 계산하기 위한 기준

서버 TimerManager
= 제한 시간이 끝났을 때 실제 게임 상태를 변경하는 장치

화면 표시와 권위 있는 판정을 분리하는 것이 중요하다.

9. 마감 시각은 서버만 변경한다

GameState의 Setter에서도 Authority를 검사한다.

void AMYBaseballGameState::
    SetBatterGuessDeadlineServerTime(
        const float NewDeadlineServerTime)
{
    if (!HasAuthority())
    {
        UE_LOG(
            LogMYBaseball,
            Warning,
            TEXT(
                "SetBatterGuessDeadlineServerTime "
                "rejected without authority."
            )
        );

        return;
    }

    const float SanitizedDeadline =
        FMath::Max(
            0.0f,
            NewDeadlineServerTime
        );

    if (FMath::IsNearlyEqual(
        BatterGuessDeadlineServerTime,
        SanitizedDeadline))
    {
        return;
    }

    BatterGuessDeadlineServerTime =
        SanitizedDeadline;

    NotifyBatterGuessDeadlineChanged();
    ForceNetUpdate();
}

Authority 검사

클라이언트가 자신의 GameState 복제본에서 Setter를 호출해도 서버의 원본은 변경되지 않는다.

함수 내부에서도 Authority를 검사하면 잘못된 호출을 명확하게 차단할 수 있다.

음수 방지

FMath::Max(0.0f, NewDeadlineServerTime);

음수 마감 시각을 방지한다. 이 구현에서는 0을 비활성화 상태로 사용한다.

중복 변경 방지

FMath::IsNearlyEqual(...);

부동소수점 값을 단순히 ==로 비교하지 않고 거의 같은 값이면 불필요한 변경과 UI 알림을 생략한다.

빠른 복제 요청

ForceNetUpdate();

GameState가 다음 일반 네트워크 업데이트 시점까지 기다리지 않고 변경된 상태를 가능한 한 빨리 복제하도록 요청한다.

다만 이것은 즉시 전송을 절대적으로 보장하는 명령이 아니라 다음 복제 기회를 앞당기는 요청에 가깝다.

서버에서는 RepNotify가 자동으로 호출된다고 기대하지 않고 Setter 안에서 알림 함수를 직접 호출했다. 덕분에 Listen Server의 로컬 UI도 변경을 감지할 수 있다.

10. 클라이언트가 서버 시간을 구하는 방법

각 클라이언트의 로컬 GetTimeSeconds() 값은 서로 다를 수 있다.

따라서 단순히 다음과 같이 계산하면 모든 클라이언트의 기준이 일치하지 않는다.

// 클라이언트마다 기준이 다를 수 있다.
GetWorld()->GetTimeSeconds();

언리얼의 AGameStateBase는 서버 시간 기준의 현재 시각을 구할 수 있는 함수를 제공한다.

GetServerWorldTimeSeconds();

개념적으로는 클라이언트의 로컬 월드 시간에 서버와의 시간 차이를 보정하는 방식이다.

서버에서 받은 시간 - 클라이언트 로컬 시간
= 서버 시간 보정값

클라이언트 로컬 시간 + 서버 시간 보정값
= 추정된 현재 서버 시각

따라서 Client A와 Client B의 로컬 시간이 달라도 GetServerWorldTimeSeconds()를 사용하면 같은 서버 시간축에 가까운 값을 얻을 수 있다.

별도의 서버 시간 동기화 RPC를 직접 만들지 않아도 되는 이유는 GameState가 이미 관련 기능을 제공하기 때문이다.

11. 남은 시간 계산하기

GameState에서는 마감 시각과 현재 서버 시각을 사용해 남은 시간을 계산한다.

float AMYBaseballGameState::
    GetBatterGuessTimeRemaining() const
{
    if (BatterGuessDeadlineServerTime <= 0.0f)
    {
        return 0.0f;
    }

    return FMath::Max(
        0.0f,
        BatterGuessDeadlineServerTime
        - GetServerWorldTimeSeconds()
    );
}

공식은 단순하다.

남은 시간
= 마감 서버 시각 - 현재 서버 시각

예를 들어 다음과 같다.

복제된 마감 시각 : 218.4
현재 서버 시각   : 210.1
남은 시간        :   8.3초

마감 이후에는 계산 결과가 음수가 될 수 있다.

218.4 - 219.2 = -0.8

UI에 음수가 표시되지 않도록 최소값을 0으로 제한한다.

FMath::Max(0.0f, RemainingTime);

12. UMG에서는 로컬 계산만 수행한다

각 클라이언트의 Widget은 NativeTick()에서 타이머 표시를 갱신한다.

void UMYBaseballGameWidget::NativeTick(
    const FGeometry& MyGeometry,
    const float InDeltaTime)
{
    Super::NativeTick(
        MyGeometry,
        InDeltaTime
    );

    RefreshTimerText();
}

이 계산은 클라이언트의 로컬 연산이다.

Client A
→ Client A의 UMG에서 남은 시간 계산

Client B
→ Client B의 UMG에서 남은 시간 계산

Dedicated Server
→ UMG가 없으므로 화면 계산 없음

매 프레임 실행되더라도 네트워크 패킷을 추가로 전송하지 않는다. 복제된 마감 시각과 동기화된 서버 시간을 읽어 화면만 갱신하기 때문이다.

13. 타이머 활성 상태 검사

카운트다운은 다음 조건을 모두 만족할 때만 표시한다.

const bool bTimerIsActive =
    IsValid(BoundGameState)
    && BoundGameState->GetInningPhase()
        == EMYInningPhase::BatterGuessing
    && BoundGameState
        ->GetBatterGuessDeadlineServerTime()
        > 0.0f;

필요한 조건은 다음과 같다.

GameState가 유효하다.
현재 이닝 단계가 타자 추측 단계다.
마감 서버 시각이 0보다 크다.

활성 상태라면 남은 시간을 정수로 변환한다.

const int32 DisplayedSeconds =
    bTimerIsActive
    ? FMath::CeilToInt(
        BoundGameState
            ->GetBatterGuessTimeRemaining()
      )
    : -1;

14. CeilToInt를 사용하는 이유

화면에 표시할 시간은 올림 처리한다.

FMath::CeilToInt(RemainingTime);

표시 결과는 다음과 같다.

14.92초 → 15
 5.01초 →  6
 4.98초 →  5
 0.01초 →  1
 0.00초 →  0

내림 처리하면 타이머가 시작되자마자 실제로는 거의 15초가 남았는데 화면에는 14초가 표시될 수 있다.

사용자에게 남아 있는 완전한 초 단위를 자연스럽게 보여 주려면 올림 처리가 적합하다.

15. TextBlock은 숫자가 바뀔 때만 갱신한다

남은 시간 계산은 매 프레임 수행하지만, TextBlock까지 매 프레임 다시 설정할 필요는 없다.

if (DisplayedSeconds
    == LastDisplayedTimerSeconds)
{
    return;
}

60FPS 환경에서 한 초 동안 계산 결과가 다음과 같이 변할 수 있다.

14.95
14.93
14.91
...
14.10

모두 올림하면 15다.

따라서 화면의 정수 값이 이전과 같다면 SetText()를 호출하지 않는다.

이 구조는 다음 비용을 줄인다.

불필요한 TextBlock 갱신
반복적인 문자열 생성
Slate 레이아웃 및 페인트 작업
불필요한 UI 상태 변경

네트워크 복제는 시작 시 마감 시각을 한 번 전달하는 수준으로 유지하면서 UI도 필요한 순간에만 변경할 수 있다.

16. 실제 타이머 표시

타이머가 활성화되지 않았다면 다음과 같이 표시한다.

if (!bTimerIsActive)
{
    TimerText->SetText(
        FText::FromString(
            TEXT("TIME: --")
        )
    );

    TimerText->SetColorAndOpacity(
        FSlateColor(
            FLinearColor::White
        )
    );

    return;
}

활성 상태에서는 두 자리 숫자로 표시한다.

TimerText->SetText(
    FText::FromString(
        FString::Printf(
            TEXT("TIME: %02d"),
            DisplayedSeconds
        )
    )
);

화면에는 다음과 같이 나타난다.

TIME: 15
TIME: 09
TIME: 00

남은 시간이 5초 이하가 되면 색상을 변경해 긴박감을 줄 수 있다.

const FLinearColor TimerColor =
    DisplayedSeconds <= 5
    ? FLinearColor(
        1.0f,
        0.18f,
        0.12f,
        1.0f
      )
    : FLinearColor::White;

TimerText->SetColorAndOpacity(
    FSlateColor(TimerColor)
);

17. UMG에서 시간 초과를 판정하면 안 되는 이유

클라이언트가 표시하는 시간은 UI용 추정값이다.

네트워크 지연과 서버 시간 보정 때문에 클라이언트마다 아주 작은 차이가 발생할 수 있다.

다음과 같이 UMG에서 게임 상태를 변경하면 안 된다.

// 잘못된 구조
if (DisplayedSeconds <= 0)
{
    ++TryCount;
}

모든 클라이언트에서 같은 코드가 실행되면 중복 판정이 발생할 수 있다. 악의적인 클라이언트가 코드를 조작할 가능성도 있다.

따라서 책임을 다음과 같이 분리한다.

클라이언트 UMG
= TIME: 00 표시

서버 GameMode
= 실제 시간 초과 처리
= 시도 횟수 증가
= 아웃 판정
= 다음 시도 시작

18. 서버의 실제 시간 초과 처리

서버 타이머가 만료되면 GameMode에서 시간 초과를 처리한다.

void AMYBaseballGameMode::
    HandleBatterGuessTimeout()
{
    if (!HasAuthority())
    {
        return;
    }

    ClearBatterGuessTimer();

    ++CurrentBatterTryCount;

    BaseballGameState->SetAtBatStatus(
        CurrentBatterTryCount,
        0,
        TArray<int32>()
    );

    // 남은 기회가 있다면
    // 다음 15초 타이머 시작
    StartBatterGuessTimer();
}

서버는 다음 작업을 담당한다.

현재 타이머를 종료한다.
타자의 시도 횟수를 증가시킨다.
GameState의 타석 상태를 변경한다.
아웃 조건을 검사한다.
남은 기회가 있다면 새로운 타이머를 시작한다.

클라이언트는 결과를 GameState Replication으로 전달받아 화면에 표시한다.

19. RPC와 시간 초과가 거의 동시에 발생하는 경우

실제 멀티플레이에서는 타자가 제한 시간 마지막 순간에 입력할 수 있다.

다음 상황이 발생할 수 있다.

서버의 마감 시각은 이미 지남
서버 TimerManager의 콜백은 아직 대기 중
타자의 입력 RPC가 먼저 서버에 도착

서버 타이머 콜백만 믿으면 마감 이후에 도착한 입력이 정상 입력으로 처리될 수 있다.

따라서 Server RPC를 처리하는 시점에도 마감 시각을 다시 확인해야 한다.

if (BaseballGameState
        ->GetBatterGuessDeadlineServerTime()
        > 0.0f
    && BaseballGameState
        ->GetBatterGuessTimeRemaining()
        <= 0.0f)
{
    HandleBatterGuessTimeout();

    OutErrorMessage =
        TEXT(
            "The guess arrived "
            "after the time limit."
        );

    return false;
}

서버의 현재 시각을 기준으로 이미 마감됐다면 서버가 직접 시간 초과를 처리하고 해당 RPC를 거절한다.

20. 이전 시도의 늦은 RPC 방지

네트워크 지연으로 이전 시도에서 보낸 RPC가 다음 시도에 도착할 수도 있다.

이를 방지하기 위해 클라이언트가 자신이 입력한 시도의 번호를 함께 보낼 수 있다.

if (ExpectedTryCount
    != CurrentBatterTryCount)
{
    OutErrorMessage =
        TEXT(
            "This guess belongs "
            "to an expired attempt."
        );

    return false;
}

예를 들어 다음과 같다.

클라이언트가 보낸 ExpectedTryCount : 0
서버의 CurrentBatterTryCount       : 1

두 값이 다르면 이전 시도에서 보낸 오래된 요청으로 판단하고 거절한다.

이 검사가 없다면 첫 번째 시도에서 늦게 도착한 입력이 두 번째 시도의 입력으로 잘못 처리될 수 있다.

마지막 순간의 입력은 두 단계로 검증한다.

1. 요청의 시도 번호가 현재 시도와 같은가?
2. 서버 기준 마감 시각이 지나지 않았는가?

21. 타이머 종료와 상태 초기화

타이머를 종료할 때는 TimerHandle만 제거하는 것이 아니라 GameState의 마감 시각도 0으로 변경한다.

void AMYBaseballGameMode::
    ClearBatterGuessTimer()
{
    GetWorldTimerManager().ClearTimer(
        BatterGuessTimerHandle
    );

    if (AMYBaseballGameState* BaseballGameState =
        GetGameState<AMYBaseballGameState>())
    {
        BaseballGameState
            ->SetBatterGuessDeadlineServerTime(
                0.0f
            );
    }
}

0이 클라이언트에 복제되면 각 UI는 타이머가 비활성화됐다고 판단한다.

TIME: --

정상적인 입력으로 시도가 끝난 경우에도 기존 타이머를 먼저 제거한다.

현재 시도 시작
→ 새로운 마감 시각 복제

현재 시도 종료
→ 서버 타이머 제거
→ 마감 시각 0 복제

다음 시도 시작
→ 새로운 마감 시각 복제

정답이 확정되지 않아 다음 기회가 남아 있다면 새로운 15초 타이머를 시작한다.

22. 남은 시간을 매초 복제하는 방식과 비교

서버가 남은 시간을 매초 복제한다면 다음 값을 계속 변경해야 한다.

15 → 14 → 13 → ... → 1 → 0

15초 타이머 하나에도 최대 16회의 상태 변경이 발생한다.

네트워크 상태에 따라 특정 값이 늦게 도착하거나 중간 숫자를 건너뛸 수도 있다.

마감 시각 방식은 다음 값 하나를 복제한다.

DeadlineServerTime = 218.4

각 클라이언트는 이 고정값과 현재 서버 시각을 사용해 카운트다운을 진행한다.

마감 시각 방식의 장점

타이머 전용 복제 횟수가 감소한다.
모든 클라이언트가 같은 서버 시간축을 사용한다.
중간에 접속한 클라이언트도 현재 남은 시간을 계산할 수 있다.
클라이언트가 매끄럽게 카운트다운을 표시할 수 있다.
실제 판정은 계속 서버 권위로 유지된다.
타이머마다 별도의 시간 동기화 RPC가 필요하지 않다.

언리얼은 GameState를 통해 서버 시간 동기화를 지원한다. 이번 구현은 그 기능 위에 게임 타이머를 구성한 것이다.

23. 실행 위치와 책임 정리

코드실행 위치책임

StartBatterGuessTimer()	서버	마감 시각과 실제 서버 타이머 생성
SetBatterGuessDeadlineServerTime()	서버	권위 있는 마감 시각 변경
프로퍼티 Replication	서버 → 클라이언트	마감 시각 전달
OnRep_BatterGuessDeadlineServerTime()	각 클라이언트	복제 도착 알림
GetBatterGuessTimeRemaining()	호출한 컴퓨터	서버 시간축으로 남은 시간 계산
NativeTick()	각 로컬 클라이언트	카운트다운 UI 갱신
HandleBatterGuessTimeout()	서버	기회 소진과 아웃 판정
ClearBatterGuessTimer()	서버	타이머 제거 및 마감 시각 초기화

24. 오늘 배운 내용

오늘은 멀티플레이 타이머에서 남은 시간을 매초 복제하는 대신, 서버가 고정된 마감 시각 하나를 복제하는 구조를 구현했다.

GameMode는 마감 시각을 생성하고 실제 서버 타이머를 통해 시간 초과를 판정한다. GameState는 마감 시각을 모든 클라이언트에 복제한다.

각 클라이언트의 UMG는 다음 공식으로 화면의 남은 시간을 계산한다.

남은 시간
= 복제된 마감 서버 시각
- 동기화된 현재 서버 시각

UI는 카운트다운을 보여 줄 뿐이며, 실제 시도 횟수 증가와 아웃 판정은 서버만 수행한다.

또한 제한 시간 끝에 도착한 입력이 잘못 처리되지 않도록 RPC 처리 시점에 마감 시각과 시도 번호를 다시 검증했다.

이번 구조의 핵심을 한 문장으로 정리하면 다음과 같다.

서버는 마감 시각과 실제 판정을 소유하고,
GameState는 마감 시각을 복제하며,
각 클라이언트는 서버 시간축을 기준으로 화면만 갱신한다.

[Unreal Engine 멀티플레이] 서버 권위 기반 숫자 야구 구현

think95592 — Mon, 3 Aug 2026 20:57:05 +0900

오늘의 학습 목표

오늘은 언리얼 엔진의 서버 권위 구조를 기반으로 멀티플레이 숫자 야구를 구현했다.

주요 구현 내용은 다음과 같다.

GameMode와 GameState의 책임 분리
PlayerController의 Server RPC를 통한 입력 전달
서버에서 투수의 정답과 타자의 추측 검증
GameState Replication을 통한 TRY, HIT, OUT 동기화
3아웃 달성 시 공수 교대
클라이언트 조작과 잘못된 RPC 요청 방지

1. 숫자 야구의 네트워크 흐름

이번 숫자 야구에서는 투수가 정답 숫자를 가지고 타자가 숫자를 추측한다.

게임 규칙은 다음과 같이 구성했다.

서버가 투수의 정답을 관리한다.
타자가 숫자를 입력한다.
타자의 PlayerController가 Server RPC를 호출한다.
서버가 입력 형식과 플레이어 역할을 검증한다.
추측이 정답이면 HIT를 증가시킨다.
추측이 틀리면 OUT을 증가시킨다.
시도할 때마다 TRY를 증가시킨다.
OUT이 3이 되면 투수와 타자의 역할을 교대한다.
변경된 결과는 GameState를 통해 모든 클라이언트에 복제한다.

전체 흐름을 정리하면 다음과 같다.

타자의 채팅 또는 입력 UI
        ↓
로컬 PlayerController
        ↓ Server RPC
서버의 PlayerController
        ↓
서버 GameMode
├─ 현재 타자인지 검사
├─ 입력 형식 검사
├─ 정답과 추측 비교
└─ 3아웃 검사
        ↓
서버 GameState
├─ TRY 변경
├─ HIT 변경
├─ OUT 변경
└─ 공수 상태 변경
        ↓ Replication
모든 클라이언트 UI 갱신

2. 왜 서버 권위 구조가 필요한가?

멀티플레이 게임에서 클라이언트가 직접 정답 판정이나 점수를 변경하게 만들면 치팅에 매우 취약해진다.

예를 들어 클라이언트가 다음 값을 직접 변경할 수 있으면 안 된다.

정답 숫자
HIT 횟수
OUT 횟수
현재 투수와 타자
공수 교대 여부

클라이언트는 자신이 입력한 숫자만 서버에 전달해야 한다.

클라이언트
"123을 추측했습니다."

서버
"이 플레이어가 정말 현재 타자인가?"
"123은 유효한 숫자인가?"
"서버에 저장된 정답과 일치하는가?"

최종 판정과 상태 변경은 모두 서버가 담당한다.

3. GameMode와 GameState의 책임 분리

멀티플레이 게임을 구현할 때 GameMode와 GameState의 역할을 정확히 구분해야 한다.

GameMode의 역할

GameMode는 서버에만 존재한다.

따라서 외부에 공개되면 안 되는 정보와 게임 규칙을 관리하기에 적합하다.

이번 숫자 야구에서 GameMode는 다음 역할을 담당한다.

투수의 정답 숫자 보관
타자의 추측 검증
현재 플레이어가 타자인지 검사
HIT와 OUT 판정
3아웃 검사
공수 교대 처리
새로운 정답 생성

투수의 정답은 클라이언트에 복제하면 안 된다.

UCLASS()
class ABaseballGameMode : public AGameModeBase
{
    GENERATED_BODY()

private:
    // 서버에만 존재하며 클라이언트에 복제되지 않는다.
    FString SecretNumber;

public:
    void HandleGuess(
        class ABaseballPlayerController* RequestingPlayer,
        const FString& Guess
    );

private:
    bool IsValidGuess(const FString& Guess) const;
    void GenerateSecretNumber();
    void SwitchSides();
};

GameState의 역할

GameState는 서버와 모든 클라이언트에 존재한다.

전체 플레이어가 알아야 하는 공용 상태를 저장하고 복제하는 데 적합하다.

이번 숫자 야구에서 GameState는 다음 정보를 관리한다.

현재 시도 횟수 TRY
현재 안타 횟수 HIT
현재 아웃 횟수 OUT
현재 투수
현재 타자

UCLASS()
class ABaseballGameState : public AGameStateBase
{
    GENERATED_BODY()

public:
    UPROPERTY(ReplicatedUsing = OnRep_RoundState)
    int32 TryCount = 0;

    UPROPERTY(ReplicatedUsing = OnRep_RoundState)
    int32 HitCount = 0;

    UPROPERTY(ReplicatedUsing = OnRep_RoundState)
    int32 OutCount = 0;

    UPROPERTY(ReplicatedUsing = OnRep_PlayerRoles)
    TObjectPtr<APlayerState> PitcherPlayerState;

    UPROPERTY(ReplicatedUsing = OnRep_PlayerRoles)
    TObjectPtr<APlayerState> BatterPlayerState;

    UFUNCTION()
    void OnRep_RoundState();

    UFUNCTION()
    void OnRep_PlayerRoles();

    virtual void GetLifetimeReplicatedProps(
        TArray<FLifetimeProperty>& OutLifetimeProps
    ) const override;
};

두 클래스의 책임을 요약하면 다음과 같다.

클래스실행 위치담당 역할

GameMode	서버에만 존재	정답, 규칙, 판정, 공수 교대
GameState	서버와 모든 클라이언트	TRY, HIT, OUT, 투수·타자 상태
PlayerController	서버와 소유 클라이언트	입력 수집, Server RPC 전달
Widget	각 클라이언트	입력과 결과 표시

4. PlayerController로 입력 전달하기

타자의 숫자 입력은 로컬 UI에서 발생한다.

하지만 Widget은 네트워크 액터가 아니기 때문에 Widget에서 직접 RPC를 호출하는 구조는 적합하지 않다.

입력은 로컬 PlayerController에 전달하고, PlayerController가 Server RPC를 호출하도록 구성한다.

Widget
→ PlayerController
→ Server RPC
→ GameMode

PlayerController 헤더

UCLASS()
class ABaseballPlayerController : public APlayerController
{
    GENERATED_BODY()

public:
    void SubmitGuess(const FString& Guess);

protected:
    UFUNCTION(Server, Reliable)
    void ServerSubmitGuess(const FString& Guess);
};

로컬 입력 처리

void ABaseballPlayerController::SubmitGuess(const FString& Guess)
{
    if (!IsLocalController())
    {
        return;
    }

    ServerSubmitGuess(Guess);
}

SubmitGuess()는 자신의 화면에서 조작 중인 로컬 PlayerController만 실행하도록 검사한다.

5. Server RPC에서 GameMode 호출하기

Server RPC가 서버에 도착하면 서버의 GameMode에 판정을 요청한다.

void ABaseballPlayerController::ServerSubmitGuess_Implementation(
    const FString& Guess)
{
    ABaseballGameMode* GameMode =
        GetWorld()->GetAuthGameMode<ABaseballGameMode>();

    if (!IsValid(GameMode))
    {
        return;
    }

    GameMode->HandleGuess(this, Guess);
}

GetAuthGameMode()는 Authority가 있는 서버에서 GameMode를 가져올 때 사용한다.

GameMode는 클라이언트에 존재하지 않으므로 클라이언트에서 호출하면 유효한 GameMode를 얻을 수 없다.

PlayerController는 해당 클라이언트가 소유하는 액터이기 때문에 클라이언트에서 서버로 RPC를 전달하는 진입점으로 사용할 수 있다.

6. 서버에서 입력 검증하기

클라이언트가 보낸 문자열은 절대 그대로 신뢰하면 안 된다.

서버는 최소한 다음 내용을 확인해야 한다.

요청한 플레이어가 현재 타자인가?
숫자의 길이가 올바른가?
모든 문자가 숫자인가?
중복된 숫자가 없는가?
현재 게임이 추측 가능한 상태인가?
너무 빠르게 입력을 반복하고 있지는 않은가?

숫자 형식 검사

다음 예시는 세 자리 숫자이며 중복 숫자를 허용하지 않는 규칙이다.

bool ABaseballGameMode::IsValidGuess(const FString& Guess) const
{
    constexpr int32 RequiredLength = 3;

    if (Guess.Len() != RequiredLength)
    {
        return false;
    }

    TSet<TCHAR> UsedDigits;

    for (const TCHAR Character : Guess)
    {
        if (!FChar::IsDigit(Character))
        {
            return false;
        }

        if (UsedDigits.Contains(Character))
        {
            return false;
        }

        UsedDigits.Add(Character);
    }

    return true;
}

클라이언트 UI에서도 입력을 검사할 수 있지만, 그것은 사용자의 실수를 빠르게 알려주기 위한 검사일 뿐이다.

보안을 위한 실제 검증은 반드시 서버에서 다시 수행해야 한다.

7. 서버에서 타자 권한 검사하기

Server RPC를 호출할 수 있다는 사실만으로 해당 플레이어가 현재 타자라는 의미는 아니다.

서버는 RPC를 요청한 PlayerController의 PlayerState와 GameState에 저장된 현재 타자를 비교해야 한다.

void ABaseballGameMode::HandleGuess(
    ABaseballPlayerController* RequestingPlayer,
    const FString& Guess)
{
    if (!IsValid(RequestingPlayer))
    {
        return;
    }

    ABaseballGameState* BaseballGameState =
        GetGameState<ABaseballGameState>();

    if (!IsValid(BaseballGameState))
    {
        return;
    }

    APlayerState* RequestingPlayerState =
        RequestingPlayer->GetPlayerState<APlayerState>();

    if (RequestingPlayerState !=
        BaseballGameState->BatterPlayerState)
    {
        // 현재 타자가 아닌 플레이어의 요청
        return;
    }

    if (!IsValidGuess(Guess))
    {
        return;
    }

    const bool bIsHit = Guess == SecretNumber;

    BaseballGameState->ApplyGuessResult(bIsHit);

    if (BaseballGameState->OutCount >= 3)
    {
        SwitchSides();
    }
    else if (bIsHit)
    {
        GenerateSecretNumber();
    }
}

현재 타자인지는 클라이언트가 Boolean 값으로 보내도록 만들지 않았다.

// 좋지 않은 구조
ServerSubmitGuess(Guess, true);

클라이언트가 true를 보내는 것은 아무런 검증 근거가 되지 않는다. 서버가 자신이 보유한 PlayerState를 기준으로 직접 판단해야 한다.

8. GameState에서 TRY, HIT, OUT 변경하기

GameState의 상태도 서버만 변경할 수 있도록 함수 안에서 Authority를 검사한다.

void ABaseballGameState::ApplyGuessResult(bool bIsHit)
{
    if (!HasAuthority())
    {
        return;
    }

    ++TryCount;

    if (bIsHit)
    {
        ++HitCount;
    }
    else
    {
        ++OutCount;
    }

    // Listen Server의 로컬 UI를 위한 갱신
    OnRoundStateChanged.Broadcast(
        TryCount,
        HitCount,
        OutCount
    );
}

GameState 헤더에 함수를 추가한다.

DECLARE_DYNAMIC_MULTICAST_DELEGATE_ThreeParams(
    FOnRoundStateChanged,
    int32, TryCount,
    int32, HitCount,
    int32, OutCount
);

UPROPERTY(BlueprintAssignable)
FOnRoundStateChanged OnRoundStateChanged;

void ApplyGuessResult(bool bIsHit);

서버가 값을 변경하면 Replication을 통해 클라이언트에 새로운 상태가 전달된다.

9. Replication 등록하기

UPROPERTY(ReplicatedUsing)만 작성해서는 값이 복제되지 않는다.

GetLifetimeReplicatedProps()에서 각 프로퍼티를 등록해야 한다.

#include "Net/UnrealNetwork.h"

void ABaseballGameState::GetLifetimeReplicatedProps(
    TArray<FLifetimeProperty>& OutLifetimeProps) const
{
    Super::GetLifetimeReplicatedProps(OutLifetimeProps);

    DOREPLIFETIME(
        ABaseballGameState,
        TryCount
    );

    DOREPLIFETIME(
        ABaseballGameState,
        HitCount
    );

    DOREPLIFETIME(
        ABaseballGameState,
        OutCount
    );

    DOREPLIFETIME(
        ABaseballGameState,
        PitcherPlayerState
    );

    DOREPLIFETIME(
        ABaseballGameState,
        BatterPlayerState
    );
}

GameState는 기본적으로 Replication을 지원하지만, 커스텀 프로퍼티는 직접 등록해야 한다.

10. OnRep로 UI 갱신하기

클라이언트에서 복제된 값이 변경되면 OnRep_RoundState()가 호출된다.

void ABaseballGameState::OnRep_RoundState()
{
    OnRoundStateChanged.Broadcast(
        TryCount,
        HitCount,
        OutCount
    );
}

Widget은 GameState의 델리게이트에 이벤트를 연결해 UI를 갱신한다.

TRY : 4
HIT : 1
OUT : 2

복제 변수와 UI를 직접 강하게 연결하기보다 GameState가 델리게이트를 발생시키고 Widget이 이를 구독하도록 만들면 역할을 분리할 수 있다.

GameState
→ 데이터 보관과 변경 알림

Widget
→ 데이터를 화면에 표시

주의할 점은 서버에서 값을 변경했을 때 서버 자신의 OnRep 함수가 자동 호출된다고 기대하면 안 된다는 것이다.

Listen Server의 호스트 UI도 갱신해야 한다면 서버에서 값을 변경한 직후 델리게이트를 직접 호출하거나 별도의 공통 갱신 함수를 사용하는 것이 안전하다.

11. 3아웃 공수 교대 처리

OUT이 3이 되면 서버의 GameMode가 투수와 타자를 교대한다.

void ABaseballGameMode::SwitchSides()
{
    ABaseballGameState* BaseballGameState =
        GetGameState<ABaseballGameState>();

    if (!IsValid(BaseballGameState))
    {
        return;
    }

    Swap(
        BaseballGameState->PitcherPlayerState,
        BaseballGameState->BatterPlayerState
    );

    BaseballGameState->TryCount = 0;
    BaseballGameState->OutCount = 0;

    GenerateSecretNumber();

    BaseballGameState->NotifyRoundStateChanged();
}

공수 교대 과정은 다음과 같다.

OUT 증가
    ↓
OUT이 3 이상인가?
    ├─ 아니오: 현재 공격 유지
    └─ 예
        ├─ 투수와 타자 교환
        ├─ TRY 초기화
        ├─ OUT 초기화
        ├─ 새 정답 생성
        └─ 변경 상태 복제

HIT을 초기화할지는 게임 규칙에 따라 달라진다.

누적 점수로 사용할 경우 유지하고, 이닝 또는 라운드 점수로 사용할 경우 공수 교대 시 초기화할 수 있다.

중요한 점은 공수 교대 판단도 클라이언트가 아니라 서버에서 처리해야 한다는 것이다.

12. 투수의 정답은 복제하지 않는다

이번 구현에서 가장 중요한 보안 요소는 정답을 GameState에 저장하지 않는 것이다.

GameState에 정답을 Replicated 프로퍼티로 저장하면 모든 클라이언트가 해당 값을 받을 수 있다.

// 정답이 클라이언트에 노출될 수 있는 구조
UPROPERTY(Replicated)
FString SecretNumber;

화면에 표시하지 않더라도 클라이언트 메모리나 네트워크 데이터를 분석하면 정답을 확인할 수 있다.

따라서 정답은 서버에만 존재하는 GameMode에 저장한다.

// 서버에만 존재
FString SecretNumber;

클라이언트에는 판정 결과만 전달한다.

클라이언트가 알아야 하는 정보
├─ TRY
├─ HIT
├─ OUT
├─ 현재 투수
└─ 현재 타자

클라이언트가 알면 안 되는 정보
└─ 서버가 관리하는 정답

13. Replication과 RPC의 역할 차이

이번 구현에서는 RPC와 Replication을 서로 다른 목적으로 사용했다.

RPC

플레이어가 숫자를 입력했다는 일회성 요청을 서버에 전달한다.

타자의 추측 입력
→ Server RPC

Replication

서버에서 확정된 현재 게임 상태를 모든 클라이언트와 동기화한다.

TRY, HIT, OUT
→ GameState Replication

정리하면 다음과 같다.

RPC
= 어떤 행동을 요청하거나 이벤트를 전달

Replication
= 서버에서 확정된 상태를 지속적으로 동기화

TRY, HIT, OUT을 Multicast RPC로만 전달할 수도 있지만, 늦게 접속한 플레이어는 이전 RPC를 받을 수 없다.

GameState의 Replication을 사용하면 새로 접속한 클라이언트도 서버의 현재 상태를 전달받을 수 있다.

14. 구현하면서 주의할 점

클라이언트의 판정을 신뢰하지 않는다

// 클라이언트가 판정 결과까지 보내면 안 된다.
ServerSubmitResult(Guess, true);

클라이언트는 추측만 보내고 정답 판정은 서버가 수행해야 한다.

타자가 아닌 플레이어의 RPC를 검사한다

RPC 호출이 서버에 도착했더라도 현재 타자가 아니면 요청을 거절해야 한다.

정답을 GameState에 저장하지 않는다

GameState는 클라이언트에 존재하기 때문에 비밀 데이터를 보관하기에 적합하지 않다.

UI에서 게임 규칙을 처리하지 않는다

Widget은 입력과 출력만 담당한다. 아웃 판정이나 공수 교대는 서버 GameMode가 처리해야 한다.

RPC 입력 횟수를 제한한다

악의적인 클라이언트가 Server RPC를 빠르게 반복 호출할 수 있으므로 서버에서 입력 간격도 검사해야 한다.

15. 오늘 배운 내용

오늘은 서버 권위 기반으로 멀티플레이 숫자 야구를 구현했다.

클라이언트는 자신의 추측만 PlayerController의 Server RPC로 전달하고, GameMode는 서버에서 정답과 추측을 비교했다.

판정 결과인 TRY, HIT, OUT은 GameState에 저장하고 Replication을 통해 모든 클라이언트에 동기화했다.

OUT이 3이 되면 서버가 투수와 타자를 교대하고 새로운 정답을 생성하도록 구현했다.

전체 클래스의 책임은 다음과 같이 정리할 수 있다.

PlayerController
= 클라이언트 입력을 Server RPC로 전달

GameMode
= 서버 전용 정답, 입력 검증, 판정, 공수 교대

GameState
= TRY, HIT, OUT과 플레이어 역할 복제

Widget
= 입력을 받고 복제된 결과를 화면에 표시

이번 구현에서 가장 중요한 원칙은 다음과 같다.

클라이언트는 요청한다.
서버는 검증하고 결정한다.
GameState는 결정된 결과를 공유한다.