📚 지식 노트

플랫폼 스토어와 요구 사항

게임은 대부분 남의 가게에서 판다. PC는 Steam·Epic Games Store, 콘솔은 PlayStation Store·Microsoft Store·Nintendo eShop, 모바일은 App Store·Google Play다. 가게마다 들어가는 문이 다르고, 그 문이 배포 일정과 패치 속도를 정한다. 서버 쪽 설계도 이 문을 전제로 해야 한다. 예를 들어 서버 버그를 고쳤는데 클라이언트 패치가 심사에 묶여 있으면 며칠 동안 두 버전이 함께 돈다.

• Steam: Steamworks의 검토 절차 문서에 따르면 출시 전에 스토어 페이지와 빌드를 각각 검토받는데 보통 3~5영업일이 걸리니 7영업일 이상 여유를 두라고 한다. 한 번 승인되면 이후 업데이트는 다시 검토받지 않는다. 그래서 PC는 하루에 몇 번이라도 패치할 수 있다.
• 콘솔: 소니의 TRC, 마이크로소프트의 Xbox Requirements(XR), 닌텐도의 Lotcheck처럼 플랫폼마다 기술 요구 사항 목록이 있고, 제출한 빌드가 이를 지키는지 플랫폼이 검사한다(인증, certification). 저장 데이터 손상 처리, 네트워크 끊김 안내, 계정 전환, 용어와 버튼 표기 같은 항목이다. 목록은 비밀 유지 계약 아래 개발사에게만 공개된다. 패치도 인증을 받아야 해서 콘솔 패치는 PC보다 며칠 늦게 나가는 일이 흔하다. 그래서 고칠 수 있는 것은 서버 설정으로 고치도록 미리 빼 둔다(아래 라이브 옵스).
• 모바일: 모든 빌드가 심사를 거친다. Apple의 App Review 가이드라인은 인앱 구매, 확률형 아이템의 확률 공개, 원격으로 받은 코드로 앱의 기능을 바꾸는 것에 대한 규칙을 담고 있다. 서버에서 받는 것은 데이터와 설정이어야지, 심사를 피해 기능을 바꾸는 코드여서는 안 된다.
• 나이 등급과 지역: 출시하려는 나라마다 등급(ESRB, PEGI, 게임물관리위원회 등)이 필요하고, 확률 공개·결제 한도·개인 정보 같은 지역 법이 서버 기능(결제, 텔레메트리)에 직접 걸린다.

빌드 파이프라인과 브랜치

게임 빌드는 웹 앱보다 훨씬 크고 느리다. 코드 컴파일보다 에셋 쿠킹(텍스처 압축, 셰이더 컴파일, 레벨 패키징)이 오래 걸리고, 결과물은 수십~수백 GB가 된다. 그래서 CI는 에셋 캐시를 적극적으로 쓰고, 플랫폼마다 따로 빌드하며, 클라이언트와 전용 서버를 같은 커밋에서 같은 버전 번호로 만든다. 둘이 다른 커밋에서 나오면 프로토콜이 어긋난다.

• 디포(depot): Steam에서 파일 묶음의 단위다. 운영체제별 실행 파일, 언어별 음성, 공용 데이터를 디포로 나누면 사용자는 필요한 디포만 받는다. 디포 여럿을 묶어 올린 것이 빌드 하나다.
• 브랜치: Steamworks의 브랜치 문서처럼 같은 게임에 여러 빌드를 동시에 걸어 둘 수 있다. 기본(default) 브랜치가 모두가 받는 버전이고, 비밀번호를 건 브랜치는 사내 QA나 외부 테스터용, 공개 베타 브랜치는 원하는 사람이 라이브러리의 속성에서 골라 참여한다. 빌드를 올린다고 바로 나가지 않고, 어느 브랜치에 걸지(Set Live)를 따로 정한다. 같은 빌드를 내부 → 베타 → 기본으로 차례로 걸면 다시 빌드하지 않고 출시하고, 문제가 생기면 기본 브랜치를 이전 빌드로 되돌린다.
• 서버 빌드: 전용 서버는 컨테이너 이미지나 서버 빌드로 만들어 새 플릿에 올린다(서버 설계 노트의 플릿). 클라이언트 출시와 서버 플릿 교체의 순서를 정해 둔다. 대개 새 서버를 먼저 띄워 두고, 클라이언트를 열고, 옛 플릿은 옛 클라이언트가 사라질 때까지 남긴다.
• 심볼과 크래시: 빌드마다 디버그 심볼을 보관해 두어야 출시 뒤 크래시 덤프를 읽을 수 있다. 크래시율은 출시 직후 가장 먼저 보는 숫자다.

패치 크기: 조각으로 나눠 바뀐 것만

100GB 게임의 패치가 100GB면 아무도 견디지 못한다. 그래서 배포 시스템은 파일을 조각(chunk)으로 자르고 조각마다 내용 해시로 이름을 붙인다(내용 주소 지정, content-addressed). 새 빌드를 올리면 이미 있는 조각은 다시 저장하지 않고, 사용자도 가진 조각은 다시 받지 않는다. Steam의 업로드 문서는 SteamPipe가 파일을 약 1MB 조각으로 나누고, 새 빌드에서 이미 아는 조각을 찾아 재사용한다고 설명한다.

함정은 큰 팩 파일이다. 에셋 수천 개를 파일 하나에 이어 붙여 두면, 앞쪽 에셋 하나가 몇 바이트만 커져도 그 뒤 모든 바이트가 밀려 조각 경계가 전부 어긋난다. 아래 예에서 에셋 B가 한 칸 커지자 그냥 이어 붙인 팩은 조각 4개 중 4개를 모두 새로 받는다. 에셋마다 조각 경계에서 시작하도록 빈칸을 채워 두면 B가 든 조각 1개만 바뀐다. Steam 문서도 팩 파일 안의 에셋을 1MB 경계에 맞추라고 권한다.

• 순서를 지킨다: 빌드할 때마다 팩 안의 에셋 순서가 바뀌면 위의 정렬도 소용없다. 빌드 도구가 같은 입력에 같은 순서·같은 바이트를 내도록(결정적 빌드) 만든다.
• 압축과 암호화는 조각 단위로: 팩 전체를 한 번에 압축하면 작은 변경이 압축 결과 전체를 바꾼다. 에셋이나 블록 단위로 압축해야 델타가 산다.
• 자주 바뀌는 것은 따로: 밸런스 표, 문자열, 이벤트 데이터는 작은 파일로 떼어 두거나 아예 서버 설정으로 뺀다. 수치 하나 고치려고 수 GB 패치를 내지 않는다.

패치를 내려보내는 길: 매니페스트, CDN, 런처

조각을 실제로 사용자에게 옮기는 것은 CDN이다. 대형 업데이트 날에는 수백만 명이 몇 시간 안에 같은 조각을 받으므로, 원본 저장소가 직접 받으면 버티지 못한다. 조각은 내용 해시가 이름이라 한 번 만들면 바뀌지 않으니 캐시하기에 가장 좋은 데이터다. 엣지 캐시에 오래 두어도 틀릴 일이 없다. CDN과 오브젝트 저장소의 일반 구조는 미디어와 파일 사례 노트에 있다.

• 매니페스트: 빌드 하나는 "어떤 파일이 어떤 조각들로 이뤄졌는지"의 목록이다. 런처는 이것만 받아 비교하면 무엇을 받아야 할지 안다. 매니페스트는 서명해 두어 중간에서 바꿔치기할 수 없게 한다.
• 미리 받기: 출시 며칠 전에 암호화된 조각을 미리 내려보내고(preload), 출시 시각에 키만 풀면 몰림이 출시 순간에 몰리지 않는다.
• 런처: Steam 같은 스토어 클라이언트가 이 일을 대신하지만, 자체 런처를 쓰는 게임은 위 과정을 직접 만든다. 런처는 게임 실행 전에 버전을 맞추고, 손상된 파일을 해시로 검사해 다시 받는(파일 검증) 기능도 맡는다.
• 콘솔·모바일: 패치 배포는 플랫폼의 시스템이 하고, 개발사는 패키지를 올린다. 모바일 게임은 앱 크기 제한과 셀룰러 다운로드 경고 때문에 앱은 작게 내고, 큰 에셋은 첫 실행 때 자체 CDN에서 받는 구조가 흔하다.

라이브 옵스: 원격 설정, 기능 플래그, 단계적 출시

출시한 게임을 바꾸는 가장 빠른 길은 빌드가 아니라 설정이다. 클라이언트와 서버가 시작할 때(그리고 주기적으로) 원격 설정을 받아, 이벤트 일정, 드롭률, 상점 진열, 새 기능의 켜짐 여부를 그 값으로 정한다. Firebase Remote Config 문서처럼 관리형 서비스도 많고, 게임 백엔드 대부분이 같은 기능을 준다. 설정이 곧 배포이므로 웹 서비스의 배포 원칙을 그대로 적용한다.

• 기능 플래그: 새 기능을 코드에 넣되 꺼 둔 채 출시하고, 설정으로 켠다. Pete Hodgson의 Feature Toggles 글은 출시용, 실험용, 운영용(킬 스위치), 권한용 플래그를 나누고, 출시용 플래그는 짧게 쓰고 지우라고 권한다. 플래그가 쌓이면 조합이 늘어 테스트가 어려워진다.
• 단계적 출시: 사용자 id를 해시해 0~99 버킷에 고정 배정하고, 켜는 비율을 1% → 10% → 50% → 100%로 넓힌다. 같은 사람은 늘 같은 쪽에 있어 경험이 흔들리지 않는다. 스토어도 같은 기능을 준다. Google Play는 단계적 출시로 일부 사용자에게만 새 버전을 내보내고, Apple은 단계별 출시로 자동 업데이트를 7일에 걸쳐 나눠 보낸다.
• 킬 스위치: 문제가 생기면 끌 수 있는 스위치를 미리 만들어 둔다. 콘솔·모바일 패치는 인증과 심사에 며칠이 걸리니, 새 상점, 새 모드, 무거운 기능에는 서버 쪽 끄기를 반드시 단다.
• A/B 테스트: 같은 버킷 방식으로 그룹을 나눠 다른 값을 주고, 텔레메트리로 재방문율이나 전환율을 비교한다(게임 백엔드 노트의 텔레메트리 절). 경쟁 게임에서는 밸런스처럼 공정성에 걸리는 값은 실험하지 않는다.
• 설정도 검증한다: 잘못된 설정 한 줄(드롭률 100배)이 서버 버그보다 크게 터진다. 스키마 검사, 리뷰, 단계적 적용, 되돌릴 수 있는 버전 기록을 코드 배포처럼 둔다.

버전 호환과 강제 업데이트

출시 순간 모든 사용자가 새 버전을 쓰지는 않는다. 업데이트를 미룬 사람, 콘솔 패치가 아직 인증 중인 플랫폼, 단계적 출시로 아직 못 받은 사람이 섞인다. 그래서 백엔드와 경기 서버는 한동안 여러 클라이언트 버전을 함께 상대한다. 어디까지 받아 줄지를 정하는 것이 버전 관문이다.

• 프로토콜 번호: 클라이언트 버전과 별도로 "서버와 말이 통하는가"를 나타내는 번호를 둔다. 문구 수정 같은 패치는 프로토콜이 그대로라 옛 클라이언트와 새 클라이언트가 같은 경기에 들어갈 수 있다. 번호가 바뀌면 매치메이커가 같은 번호끼리만 묶고, 경기 서버도 그 번호의 플릿에서 고른다.
• 백엔드 API는 넓게 받는다: 새 필드는 선택으로 더하고, 옛 필드는 바로 지우지 않는다. API에 버전을 달고 옛 버전을 지원 기간 동안 유지한다. 데이터 형식 진화의 일반 원칙은 데이터 모델과 인코딩 노트와 같다.
• 강제 업데이트: 보안 구멍, 경제를 무너뜨리는 버그, 프로토콜 변경이 있으면 최소 지원 버전을 올린다. 모바일은 스토어 심사와 단계적 출시가 끝난 뒤에 올려야 한다. 아직 새 버전을 받을 수 없는 사람까지 막지 않도록, 플랫폼별로 최소 버전을 따로 둔다.
• 점검: 데이터베이스 구조를 크게 바꾸는 업데이트는 서버를 잠시 닫는 점검으로 처리하기도 한다. 점검 공지·로그인 차단·대기열도 같은 관문에서 한다. 점검 없이 하려면 옛 형식과 새 형식을 함께 읽는 기간을 두고 데이터를 뒤에서 옮긴다.

클라우드 게이밍: 화면을 스트리밍한다

클라우드 게이밍은 배포를 거꾸로 뒤집는다. 게임을 내려보내지 않고 데이터센터의 GPU 서버에서 돌린 뒤, 화면을 영상으로 인코딩해 보낸다. 기기는 입력을 올려 보내고 영상을 디코딩해 보여 주기만 하니, 설치도 패치도 없고 성능 낮은 기기에서도 무거운 게임이 돈다. 대가는 지연과 대역폭, 그리고 GPU 서버 비용이다.

• 지연 예산: 콘솔을 TV에 연결해 해도 입력에서 화면까지 수십 ms가 걸린다. 클라우드는 여기에 네트워크 왕복과 인코딩·디코딩이 더해진다. 그래서 데이터센터를 사용자 가까이 많이 두고, 지터 버퍼를 최소로 잡고, 하드웨어 인코더와 낮은 지연 설정을 쓴다. 왕복 시간이 늘면 바로 체감되니 네트워크 노트의 유선 연결·와이파이 대역 이야기가 그대로 중요하다.
• 멀티플레이와 함께: 클라우드에서 도는 게임도 온라인 경기라면 여전히 경기 서버에 접속한다. 스트리밍 서버와 경기 서버가 같은 데이터센터에 있으면 그 구간의 지연이 거의 사라져, 오히려 집에서 하는 것보다 서버와 가까워질 수 있다.
• 서비스 현황(2026년): Google Stadia는 Google의 발표대로 2023년 1월에 문을 닫았다. NVIDIA GeForce NOW는 사용자가 이미 산 PC 게임(Steam 등)을 스트리밍하는 방식으로 운영 중이며 2025년부터 RTX 5080급(Blackwell) 서버를 들였다. Xbox Cloud Gaming은 오랜 베타를 거쳐 2025년 10월 Game Pass 개편과 함께 정식 서비스가 됐다.
• 개발사가 직접: 플랫폼 구독 서비스 밖에서 자기 게임을 스트리밍으로 내보낼 수도 있다. AWS는 2025년에 Amazon GameLift Streams를 내놓아, 게임을 올리면 브라우저로 스트리밍하는 데모·체험판·즉시 플레이를 만들 수 있게 했다.