20. 게임 네트워크 직렬화: 바이너리 프로토콜 설계와 스키마 진화
문제 20 — 게임 네트워크 직렬화: 바이너리 프로토콜 설계와 스키마 진화
게임 서버와 클라이언트는 초당 수많은 메시지를 주고받는다. 이 메시지를 바이트로 바꾸는 직렬화(serialization) 방식은 대역폭, CPU, 그리고 무엇보다 "클라와 서버를 따로 업데이트할 수 있는가(스키마 진화)"를 좌우한다.
다음을 설명하라.
-
직렬화 포맷 비교: JSON 같은 텍스트 포맷, Protocol Buffers(가변 길이 태그드), FlatBuffers/Cap'n Proto(제로카피), 그리고 손수 짠 커스텀 바이너리 포맷을 대역폭·인코딩/디코딩 비용·스키마 유연성 관점에서 비교하라. 실시간 게임 트래픽에 각각 언제 적합한가?
-
스키마 진화(버저닝): 서버만 먼저 배포되고 구버전 클라이언트가 남아 있는 상황에서, 필드를 추가/삭제/변경해도 양쪽이 깨지지 않으려면 어떤 규칙이 필요한가? (필드 번호/태그, optional/기본값, 미지 필드 보존, "절대 재사용 금지" 규칙 등)
-
엔디안·정렬·가변 길이 인코딩: 바이트 순서(엔디안)를 왜 고정해야 하는가? 정수를 varint 로 인코딩하면 무엇이 이득이고 무엇을 조심해야 하는가? 문자열/배열의 길이 접두사(length-prefix)와 경계 검증의 중요성은?
-
델타 압축과 스냅샷: 위치·상태처럼 매 틱 조금씩 바뀌는 데이터를 매번 전체로 보내지 않고 델타(변경분)로 보내는 이유와, 델타 기준(baseline)·신뢰성(유실 시 복구)·주기적 풀 스냅샷의 관계를 설명하라.
-
보안 관점: 신뢰할 수 없는 클라이언트 바이트를 역직렬화할 때 반드시 지켜야 할 것(길이 상한, 재귀/중첩 깊이 제한, 할당 상한, 알 수 없는 태그 처리)을 논하라.
직접 답을 작성한 뒤, 위 해설 보기에서 모범답안과 대조하세요.