RPC

[네트워킹 스터디] RPC 정리

정의

RPC(Remote Procedure Call) = 한 클라이언트에서 함수를 호출하면, 네트워크를 타고 다른 클라이언트(들)한테 가서 "똑같은 함수가 그쪽에서도 실행되게" 만드는 메커니즘

예시 게임

발로란트는 RPC를 사용하여 "ShotHit" 같은 이벤트 발생을 보내 체력에 반영한다. [출처]

---

특징

지금까지 배운 권위 구조(StateAuthority)는 지속적으로 유지되는 상태 값을 다루는 도구였다면, RPC는 한 순간 딱 발생하고 끝나는 이벤트를 다루는 도구다

상태를 다룰 땐 Property, 이벤트/동작을 다룰 땐 RPC로 처음부터 용도가 나뉜 별도의 두 도구

---

1. 왜 상태 동기화랑 따로 쓰나

폭발 같은 이벤트를 굳이 Networked Property로 처리하면: IsExploding = true라는 상태를 만들고, 다른 클라이언트들이 그 값을 감시하다가 true가 되면 이펙트 재생하고, 다시 false로 되돌려야 함 — 번거롭고 부자연스러움.

RPC는 그냥 "폭발해!"라고 한 번 신호를 보내면 받은 쪽에서 바로 해당 함수를 실행하고 끝. 훨씬 자연스러움.

 

2. RPC 호출 방향 (누가 누구한테)

• 모든 클라이언트한테 (All): 다들 똑같이 실행 (폭발 이펙트처럼 다 같이 봐야 하는 것)
• 권위자한테만 (StateAuthority): 예) "나 데미지 입었어"를 권위자한테 보내서, 권위자가 검증 후 실제 체력을 깎게 함
• 호출자 자신 제외 (Others): 나는 이미 로컬에서 처리했으니 나머지한테만 전파

→ 이 방향 설정을 잘못하면 이펙트 중복 재생되거나 아예 안 보이는 버그가 생기는, 실무에서 자주 실수하는 지점이라고 함

---

공부하며 궁금했던 것

Q. 상태(Property)랑 이벤트(RPC)가 애매하게 섞이는 경우는 어떻게 하나? (예: 소총/대포/핵폭탄)

A. 판단 기준은 "쏘는 빈도"가 아니라 "이게 시간이 지나도 계속 값을 들고 있어야 하는가".

하나의 액션 안에 사실 RPC 요소와 Property 요소가 항상 같이 섞여 있음:

• 소총: "쐈다"(RPC, 이펙트/사운드) + "탄약 몇 발 남았나"(Property, 지속 값)
• 대포: "발사했다"(RPC) + "충전 게이지 %"(Property, 계속 변하는 값)
• 핵폭탄: "버튼 눌렀다"(RPC) + "날아가는 폭탄의 위치"(Property, NetworkObject로 스폰) + "터졌다"(다시 RPC)

결론: 애매한 게 아니라, 게임 로직 자체가 원래 "순간 이벤트 + 지속 상태"의 조합으로 이루어져 있는 것. 하나의 액션을 통째로 "이건 RPC냐 Property냐"로 고민하지 말고, 쪼개서 각 부분에 맞는 도구를 배정하면 됨. 이게 거의 모든 게임 액션(점프, 아이템 획득 등)에서 반복되는 패턴.

---

관련 예시로 정리

• 점프: 버튼 눌렀다(RPC, 애니메이션/사운드) → 공중 위치·속도(Property) → 착지(RPC, 이펙트/사운드)
• 아이템 획득: 충돌 감지(RPC, 이펙트/사운드) → 인벤토리에 아이템 추가된 상태(Property)

---

오늘의 요약

1. RPC는 상태(Property)와 별개로, "순간 발생하고 끝나는 이벤트"를 원격 클라이언트에서도 실행시키는 도구다.
2. 호출 방향(All / StateAuthority / Others)을 명확히 정하지 않으면 중복 실행·미실행 버그가 생긴다.
3. 하나의 게임 액션엔 거의 항상 RPC 요소와 Property 요소가 섞여 있다 — 애매한 게 정상이며, 액션을 잘게 쪼개서 각 부분에 맞는 도구를 배정하는 게 핵심 스킬이다.