팩트체크, 넷코드에 대한 세 가지 오해 바로잡기

멀티플레이어 게임을 만들고 배포하는 일은 만만치 않습니다. 일관성 있는 하나의 공유 현실을 만들려면 모든 부분을 다른 플레이어와 동기화해야 하므로 싱글플레이어 게임보다 신경 쓸 부분이 훨씬 많습니다. 

멀티플레이어 개발의 핵심 요소 중 하나인 넷코드는 게임 플레이어와 서버가 통신하는 방법과 내용을 처리합니다. 

그러나 넷코드가 지연이나 실망스러운 멀티플레이어 경험의 원인으로 지목되는 오명을 쓰는 경우도 있습니다. 

이번 포스팅에서는 멀티플레이어 게임을 올바르게 네트워킹할 수 있도록 일반적인 오해에 대해 자세히 살펴보고 넷코드에 관한 진실과 거짓을 밝혀보겠습니다.

전자책 다운로드

넷코드란 멀티플레이어 게임 개발에서 '생성' 부분을 의미하며, 게임에서 클라이언트와 서버 간의 네트워킹과 동기화를 처리하는 부분을 나타내는 포괄적인 용어입니다. 

멀티플레이어 게임에서 서버와 클라이언트는 네트워크를 통해 패킷을 전송하여 서로 통신합니다. 원격으로 연결되는 게이머들 간에 공유 현실을 만들려면 다른 클라이언트로 데이터 패킷을 전송하여 캐릭터 이동이나 오브젝트 생성과 같은 게임플레이 이벤트가 서로 동기화되어야 합니다. 이때 네트워크를 통해 패킷을 송수신하는 부분을 트랜스포트라고 합니다.

트랜스포트의 send 함수를 직접 호출하여 패킷을 수동으로 전송할 수도 있지만, 멀티플레이어 제작 경험이 적은 프로그래머의 경우 이 패턴이 금방 버거워질 수 있습니다. 

넷코드 라이브러리는 네트워킹된 변수나 원격 프로시저 호출(RPC)과 같은 기능을 사용하여 게임플레이 코드에서의 패킷 전송을 추상화합니다. 

Unity에는 두 가지 넷코드 패키지, 즉 Netcode for GameObjects(사전 릴리스)와 Netcode for Entities(실험 기능)가 있습니다.

1. "추후에 언제든지 멀티플레이어로 전환할 수 있다"

🚫 거짓: 게임 개발 주기 중 후반부에 멀티플레이어를 추가할 수 있다. 

✅ 진실: 멀티플레이어는 구현하기 까다로울 수 있습니다. 플레이어에게 멀티플레이어 경험을 제공하고 싶다면 가급적 게임을 설계하고 개발하는 초기 단계부터 멀티플레이어를 고려해야 합니다. 

이유: 멀티플레이어는 게임플레이의 대부분 측면과 관련이 있으므로 게임 개발에도 영향을 미칩니다. 예를 들어 일인용 게임에 인벤토리 시스템이 있는 경우, 멀티플레이어 게임은 인벤토리 항목을 서버에 동기화해야 합니다.

이외에도 싱글플레이어 경험에서는 상당히 쉽게 구현할 수 있는데 멀티플레이어 경험에 구현하자니 까다로워지는 것들이 많이 있습니다.

왜 멀티플레이어 게임 대다수가 키네마틱 캐릭터 컨트롤러를 사용하며 물리 상호 작용이 최소화되어 있을까요? 여러 사람 간에 공유되는 물리 시뮬레이션을 구현하고 물리를 예측하는 일은 경험이 풍부한 개발자에게도 골치 아픈 일입니다.

특히 다른 게임에서 일반적으로 사용되지 않는 독특한 메카닉이 게임에 사용된 경우에는 게임 속 기능들이 멀티플레이어와 호환되는지 여부를 조기에 확인하는 것이 좋습니다.

Soaring Pixels Games에서 만든 Breakwaters를 예시로 살펴보고 초기 단계부터 멀티플레이어를 구현한 방법과 소규모 협동 게임을 만드는 과정에서 이 결정이 중요했던 이유가 무엇인지 알아보세요.

2. "지연은 짧을수록 좋다"

🚫 거짓: 멀티플레이어 게임의 경우 지연이 짧을수록 좋다. 지연이 짧을수록 게임플레이 경험이 우수해진다. 

✅ 사실: 플레이어에게 원활한 경험을 제공하기 위해 지연을 줄이는 것도 중요하지만, 일관성 있는 경험을 제공하는 것도 그만큼 중요합니다. 하나의 공유 현실에서 서로의 상태를 동기화하면 다소 시간이 걸리지만 전반적인 경험을 놓고 보면 플레이어는 이를 알아차리지 못합니다. 

이유: 모든 플레이어에게 원활하면서 일관된 경험을 제공하게 되면 지연이 항상 낮게 유지되지 않을 수 있습니다.  

게임이 보다 원활하고 일관되도록 개선하기 위해 가장 일반적으로 사용하는 기술은 버퍼링입니다.

네트워크에서 들어오는 데이터 패킷은 즉시 처리되지 않고 대기열로 들어갑니다. 이상적인 상황에서 게임 시뮬레이션의 단일 업데이트를 뜻하는 '틱(tick)' 마다 클라이언트는 대기열에 있는 요소를 특정 크기로 유지하면서 대기열에서 작업 항목을 하나 가져옵니다.

이렇게 하면 서버가 틱당 하나의 패킷을 전송할 때 클라이언트도 항상 틱당 하나의 패킷을 처리할 수 있습니다. 

그런데 왜 이렇게 해야 할까요? 클라이언트가 들어오는 패킷을 즉시 처리해도 틱당 하나의 패킷을 수신하지 않을까요? 네트워킹 조건이 완벽하다면 그렇겠지만, 네트워크를 통해 전송되는 모든 패킷의 전송 지연 시간은 각기 다를 수 있습니다. 

이러한 패킷당 왕복 시간(RTT)의 변동을 지터(jitter)라고 합니다. 버퍼링은 지연을 늘리되 지터를 줄이는 기술로, 결과적으로 일관성을 높여 플레이어 경험을 개선합니다.

예시: 격투 게임은 박자에 맞추어 일련의 버튼을 빠르게 누르는 동작을 수반하기도 합니다. 플레이어는 이러한 동작을 계속해서 반복하여 근육 기억을 통해 학습합니다. 격투 게임이 공정하게 느껴지려면 플레이어 캐릭터의 행동이 주어진 입력과 일치하는 것이 매우 중요합니다. 

다양한 격투 게임은 이러한 일관성을 확보하기 위해 일정한 속도로 입력을 폴링한 후 해당 입력을 잠시 동안 버퍼에 저장합니다. 이렇게 하면 플레이어의 입력을 게임플레이 프레임에 일관되게 매핑할 수 있습니다. 따라서 평균 입력 지연은 길어지지만, 지연의 일관성이 대폭 향상됩니다.

버퍼링을 추가하면 게임이 원활해지기는 하지만, 대부분의 경우 지연이 너무 길어져 플레이어가 자신의 입력과 화면의 게임플레이가 일치하지 않는다고 느끼게 됩니다.

지연을 늘리지 않고도 원활한 버퍼링 효과를 얻을 수 있는 다양한 기술이 있습니다. 클라이언트에 권한이 있는 게임은 플레이어 캐릭터에 대한 입력을 플레이어 오브젝트에 즉시 적용하여 로컬 플레이어의 지연을 최소화합니다. 다른 플레이어는 여전히 상대 플레이어에 대한 데이터를 버퍼링하여 이를 원활하게 나타낼 수 있습니다. 

이 방법은 플레이어 입장에서 훌륭하게 느껴지기도 하지만, 훨씬 쉽게 부정행위를 범할 수 있어 다른 문제가 야기될 수 있습니다. 

따라서 경쟁 게임에서는 클라이언트측 예측이라는 기술을 사용할 수 있습니다. 이 기술은 로컬 플레이어 입력을 즉시 적용하는데, 서버도 동일한 입력을 적용하여 플레이어 동작을 계산하고 클라이언트가 유효한 동작을 실행했는지 확인한 뒤 필요한 경우에 정정합니다.

3. "대역폭은 무료이다"

🚫 거짓: 광대역 계약이 매우 저렴하므로 대역폭은 무료에 가깝다. 

✅ 진실: 대역폭은 무료가 아니며 지역마다 비용이 다를 수 있습니다. 일부 지역은 다른 지역보다 대역폭 사용에 훨씬 많은 비용을 청구합니다.

이유: 일반적으로 개인이 사용하는 광대역은 상용 서버에 적용되는 요금에 비해 상당히 저렴합니다. 광대역 계약이 저렴한 까닭은 대부분 사람이 대역폭의 일부만 사용하기 때문입니다. 하지만 상용 서버는 완전히 다릅니다. 거의 온종일 실행되며, 게임 서버가 플레이어 수백 명의 트래픽을 지원하는 경우가 많습니다. 따라서 호스팅 회사가 기가바이트 단위로 요금을 부과하는 것이 상당히 일반적입니다.

이런 점에서 대역폭을 절약하는 것이 운영비를 낮추는 데 아주 중요합니다. 게다가 게임의 대역폭 사용량을 낮추면 인터넷 속도가 느린 곳의 플레이어도 게임을 원활하게 즐길 수 있습니다. 

멀티플레이어 게임에서 흔히 지연이 발생하는 원인 중 하나는 사용자의 홈 네트워크 정체입니다. 동영상 스트리밍과 같이 네트워크에 다른 대규모 트래픽이 있으면 이러한 현상이 자주 발생하지만, 게임의 대역폭 비용을 줄이기만 해도 플레이어 경험을 개선할 수 있습니다.

멀티플레이어 게임을 빌드하는 일은 어렵지만 흥미롭습니다. 차기 히트작이 될 배틀로열 게임을 빌드하는 경우에도, 아기자기한 온라인 협동 게임을 빌드하는 경우에도, 멀티플레이어 네트워킹에 대한 섬세한 이해가 언제나 선행되어야 합니다. 

다음 전자책을 다운로드하여 멀티플레이어 네트워킹에 대한 일반적인 오해에 대해 자세히 알아보세요. 

아울러 Unity 넷코드 솔루션과 기술 자료를 참조하여 지금 바로 멀티플레이어 프로젝트를 시작해 보세요.