Node.js가 모바일 게임에서 많이 쓰이며, 처음 의아했던 것은 v1, v2, v3와 같은 버전의 API 구조에 포함되었다는 점이다.
API가 개별적으로 동작하고, 하위호환을 지원하는 것인데, 왜 게임은 이런 하위호환을 하지 못하는가?
우선 웹도 하위호환을 딱히 지원하지 않았던 과거가 있으나, REST API가 등장하면서 하위호환을 지원하는 Open API 제공하는 케이스가 생기게 됐는데, 결합도를 낮춘채 로직이나 동작을 하위호환 하는 노력이 가져다주는 장점에 공감했기 때문일 것이다.
헌데 왜 게임은 이런 노력을 하지 않는가?
왜냐면 게임이 기능의 추가 및 변경 될 때의 변화량이 크기 때문이고, 그 사이드 이펙트에 대한 검토 및 검증, 하위호환에 대한 노력 대비 효과가 낮기 때문이다.
현재 게임은 PC 온라인 기준 수십 기가, 모바일 게임도 수 기가를 넘기 쉽상인데, 이는 초기 데이터도 많지만 리소스 변화량도 그만큼 많다는 의미이고, 그런 데이터 번화량을 다 예측해 하위호환 해둔다는 것은 그만큼 공수 대비 효과가 낮을 수 있다는 의미이기도 하다.
또한 게임은 어차피 클라이언트가 통제 가능한 커스텀 앱이므로, 접근 제한을 거는 방식으로 이전 프로토콜을 가진 클라이언트의 접근을 중단하고, 제한 할 수 있다는 점도 한몫 할 것이다.
또한 DB 이슈랑도 한몫 하는데, 커스텀하게 짜여진 게임 서버 처리량 극대화에 따라서 캐시 서버라거나, 미들웨어 기능들이 하위 호환을 위해 규칙이 마련되어 있어야 하는데, 다른 제약들로 하위호환이 어려운 마당에 커스텀 기능들 마저 하위 호환을 지원하지 않게 되어있기 때문이기도 하다.
그래서 게임 서버는 매번 패치를 할 때 점검을 하고, 많은 변화량이 있는 만큼 QA를 좀 더 많이 하게 되고, 점검 시간, 점검 이슈가 좀 더 많아 지는 편이라고 할 수 있다.
또한 애초에 게임 서버는 Open API로 기능을 다른 프로그램에 열어주는 경우가 거의 없다. 사용하는 경우가 있을 지언정, 그것마저 제한적으로만 사용할 뿐이다.
그렇기에 클라이언트와 접근 제한 규칙만 잘 준수되어있다면 아무런 문제가 없기 때문에 굳이 노력 대비 효과가 낮은 선택을 하지 않는 것이다.