내 게임 멀티플레이가 두 달째 안 돼요 — Valve의 P2P 네트워킹 라이브러리 장애 사태

인디 게임 개발자들의 한숨

친구랑 같이 하는 게임, 그러니까 멀티플레이 게임을 만들어 본 적 있는 분이라면 '네트워킹'이 얼마나 골치 아픈지 잘 아실 거예요. 그런데 최근 Valve(밸브)가 공개한 네트워킹 라이브러리에서 두 달 넘게 P2P 연결이 제대로 안 되는 문제가 보고되면서, 이걸 쓰던 개발자들이 곤란을 겪고 있어요. 오늘은 이 사태를 통해 게임 네트워킹이 도대체 왜 어려운지부터 같이 알아볼게요.

P2P가 뭐고, 왜 어려운 걸까

먼저 P2P(Peer-to-Peer)라는 말부터 풀어볼게요. 이게 뭐냐면, 게임을 하는 두 사람의 컴퓨터가 중간에 큰 서버를 거치지 않고 직접 데이터를 주고받는 방식이에요. 중앙 서버를 두는 방식에 비해 서버 운영비가 안 들어서, 자금이 빠듯한 인디 게임이나 소규모 멀티플레이 게임에서 정말 많이 써요.

그런데 여기에 큰 장벽이 하나 있어요. 바로 NAT(나트)라는 녀석이에요. 집에서 공유기를 쓰면 내 컴퓨터는 '192.168.x.x' 같은 내부 주소를 갖잖아요. 이건 우리 집 안에서만 통하는 주소라서, 인터넷 너머의 친구 컴퓨터는 내 진짜 위치를 알 수가 없어요. 마치 아파트 동·호수 없이 '○○아파트'까지만 적힌 편지 같은 거죠. 그래서 두 사람을 직접 연결하려면 NAT 통과(NAT traversal)라는 까다로운 기술이 필요해요. 서로의 진짜 주소를 알아내고 구멍을 뚫어주는 과정인데, 공유기 종류가 워낙 다양해서 이게 정말 복잡하고 잘 깨져요.

Valve가 만든 GameNetworkingSockets

Valve는 스팀(Steam)을 운영하는 회사답게, 이 어려운 문제를 대신 해결해주는 GameNetworkingSockets라는 라이브러리를 오픈소스로 공개했어요. 개발자들이 NAT 통과, 암호화, 패킷 유실 처리 같은 복잡한 걸 직접 구현하지 않아도 되게끔 도와주는 도구예요. 스팀의 중계 서버 인프라(SDR이라고 불러요)를 빌려서 연결을 안정적으로 이어주기도 하고요.

많은 인디 게임이 이 라이브러리에 의존하고 있어요. 그런데 바로 이 P2P 연결 기능이 두 달 넘게 제대로 동작하지 않는 문제가 깃허브(GitHub) 이슈로 보고됐고, 한동안 뚜렷한 해결이 안 되면서 개발자들이 답답해하고 있는 상황이에요. 핵심 인프라를 한 회사에 의존할 때 생기는 전형적인 위험이 드러난 셈이죠.

의존성의 양날의 검

이 사태가 주는 교훈은 게임 개발에만 국한되지 않아요. 우리가 개발할 때 외부 라이브러리나 클라우드 서비스에 기대는 건 너무나 당연한 일이잖아요. 바퀴를 다시 발명할 필요는 없으니까요. 하지만 그 의존 대상에 문제가 생기면, 내 잘못이 전혀 없는데도 내 서비스가 멈춰버려요. 그리고 고치는 것도 내 손을 떠나 있죠. 이번 일은 "편리한 의존"과 "통제권 상실"이 동전의 양면이라는 걸 잘 보여줘요.

비슷한 영역의 대안으로는 직접 운영하는 중계 서버 방식, 또는 다른 오픈소스 네트워킹 라이브러리(예: ENet, Mirror, Photon 같은 상용 솔루션)가 있어요. 각각 비용, 안정성, 구현 난이도에서 장단점이 갈려요. 무료지만 직접 챙겨야 하는 것과, 돈을 내지만 책임을 맡길 수 있는 것 사이의 선택인 거죠.

한국 개발자에게 주는 시사점

멀티플레이 게임이나 실시간 통신 기능을 만들 계획이 있다면, 핵심 기능을 외부 인프라 하나에 전부 거는 게 위험할 수 있다는 걸 기억해두면 좋아요. 가능하면 연결이 실패했을 때를 대비한 대체 경로(fallback)를 마련해두고, 의존하는 라이브러리의 이슈 트래커를 가끔 들여다보면서 "이게 멈추면 나는 어떻게 대응하지?"를 미리 생각해두는 습관이 큰 도움이 됩니다.

마무리

한 줄로 정리하면, 편리한 무료 인프라일수록 그게 멈췄을 때의 대비책을 함께 준비해야 한다는 거예요. 여러분은 프로젝트에서 외부 의존성 때문에 곤란했던 경험이 있나요? 그럴 때 직접 구현으로 갈아탔는지, 아니면 다른 서비스로 옮겼는지 이야기 나눠봐요.