라이브 서비스 게임 패치 다운로더 용량 최소화와 미러링 서버 운영 가이드

패치 다운로더의 비용과 실패율은 ‘변경된 바이트만 받게 하는 매니페스트’와 ‘여러 원본에서 안전하게 재시도하는 전송 정책’으로 함께 줄일 수 있다. 파일 단위 교체만으로 끝내지 말고 청크 해시, 델타 패치, 압축, CDN·미러 우선순위, 무결성 검증을 하나의 배포 계약으로 설계해야 한다.

패치 다운로더 용량은 왜 계속 커지는가?

대부분의 용량 문제는 실제 변경량보다 배포 단위가 큰 데서 시작한다. 예를 들어 하나의 대형 .pak 또는 AssetBundle 안에서 일부 에셋만 바뀌었는데도 파일 전체를 다시 내려받으면 작은 수정이 수 GB 다운로드가 된다.

주요 원인은 다음과 같다.

원인	증상	개선 방향
파일 단위 교체	작은 수정에도 큰 파일 전체 재다운로드	고정 크기 또는 콘텐츠 정의 청크 적용
비결정적 빌드	같은 소스인데 파일 해시가 매번 변경	빌드 시간, 파일 순서, 압축 옵션 고정
압축 후 델타 생성	작은 원본 차이가 큰 바이너리 차이로 확대	패키징 순서와 델타 대상 검증
중복 리소스	공통 에셋이 여러 번 포함	공유 번들 또는 콘텐츠 주소화
캐시 무효화 오류	이미 받은 청크를 다시 요청	콘텐츠 해시 기반 캐시 키 사용

다운로드 절감률은 다음처럼 계산할 수 있다.

\text{절감률(\%)} = \left(1 - \frac{\text{실제 다운로드 바이트}}{\text{전체 클라이언트 파일 바이트}}\right) \times 100

여기서 전체 클라이언트 파일 바이트가 아니라 이전 버전에서 새 버전으로 갱신할 때 필요한 실제 전송량을 운영 지표로 삼아야 한다.

델타 패치와 청크 패치는 어떻게 구현할까?

실무에서는 파일 전체, 바이너리 델타, 청크 단위 전송을 상황에 맞게 섞는 방식이 가장 안정적이다.

1. 콘텐츠를 안정적인 청크로 분할한다

먼저 배포 산출물을 일정한 청크로 나누고 각 청크에 SHA-256 해시를 부여한다. 1 MiB~4 MiB는 요청 수와 재사용률 사이에서 자주 검토하는 범위지만 최적값은 네트워크 환경과 CDN 요청 비용을 기준으로 측정해야 한다.

MiB(메비바이트)는 2진수를 기준으로 처리하는 컴퓨터 시스템에서 $2^{20}$ 바이트(1,048,576 Byte)를 나타내는 데이터 용량 단위입니다.

고정 크기 청크는 구현이 단순하다. 반면 콘텐츠 정의 청킹(Content-Defined Chunking)은 파일 중간 삽입으로 뒤쪽 청크가 연쇄적으로 바뀌는 문제를 줄일 수 있지만 구현·검증 비용이 더 높다. 초기에는 고정 크기 청크와 결정적 빌드부터 적용하는 편이 안전하다.

{
  "version": "1.42.0",
  "files": [
    {
      "path": "Content/base_01.pak",
      "size": 8388608,
      "sha256": "a1b2...",
      "chunks": [
        { "id": "9f2c...", "size": 2097152, "sha256": "9f2c..." },
        { "id": "71de...", "size": 2097152, "sha256": "71de..." }
      ]
    }
  ]
}

클라이언트는 로컬 청크 저장소에서 해시를 조회하고 없는 청크만 다운로드한 뒤 최종 파일을 조립한다. 청크 ID를 해시값으로 쓰면 캐시 키와 무결성 식별자를 하나로 통일할 수 있다.

청크 매니페스트로 변경된 데이터만 요청하는 게임 패치 다운로더 구조

2. 델타 패치는 비용 대비 효과를 비교한다

바이너리 델타는 이전 파일과 새 파일의 차이를 별도 패치 파일로 생성하는 방식이다. 대형 파일이 대부분 유지될 때 효과가 크지만 이전 버전 조합이 많아지면 생성·보관해야 할 델타 수도 빠르게 증가한다.

방식	장점	주의점	적합한 상황
전체 파일 교체	구현과 복구가 단순	전송량이 큼	작은 파일, 긴급 복구
바이너리 델타	변경량이 작을 때 매우 효율적	버전 조합과 적용 실패 관리 필요	인접 버전 간 대형 파일 갱신
청크 다운로드	캐시 재사용과 미러 운영에 유리	매니페스트·조립 로직 필요	지속적인 라이브 서비스

델타 파일이 원본 신규 파일보다 크거나 디스크 여유 공간을 과도하게 요구하면 전체 파일 또는 청크 다운로드로 즉시 폴백해야 한다. 매니페스트에 deltaSize, fullSize, baseVersion을 기록하면 클라이언트가 선택을 자동화할 수 있다.

3. 압축과 패키징 순서를 고정한다

압축은 전송량을 줄이지만 비결정적인 압축 결과는 델타 효율을 망칠 수 있다. 다음 항목을 빌드 파이프라인에서 고정한다.

파일 정렬 순서와 메타데이터 기록 규칙을 고정한다.
빌드 타임스탬프, 임시 경로, 랜덤 식별자가 산출물에 포함되지 않게 한다.
압축 라이브러리 버전과 압축 레벨을 고정한다.
동일 입력으로 두 번 빌드해 SHA-256이 같은지 CI에서 확인한다.

미러링 서버는 어떻게 장애와 혼잡을 줄이는가?

미러링은 동일한 패치 콘텐츠를 여러 원본에 복제하고 다운로더가 상태가 좋은 원본을 선택하도록 하는 운영 방식이다. 단순히 URL을 여러 개 두는 것만으로는 부족하다. 원본 간 콘텐츠 일치, 헬스 체크, 재시도 제한, CDN 캐시 정책을 함께 관리해야 한다.

flowchart LR
    C[게임 런처] --> M[서명된 매니페스트]
    M --> C
    C -->|우선 요청| CDN[CDN 원본]
    C -->|타임아웃 또는 5xx| MirrorA[미러 A]
    C -->|재시도 실패| MirrorB[미러 B]
    CDN --> Store[동일한 청크 저장소]
    MirrorA --> Store
    MirrorB --> Store

매니페스트 자체는 작지만 매우 중요하다. HTTPS로 제공하고 배포용 개인키로 서명한 뒤 런처에 포함된 공개키로 검증한다. 청크 해시 검증만으로는 공격자가 이전의 정상 매니페스트를 재전송하는 롤백 공격을 막기 어렵기 때문이다. version, publishedAt, 최소 지원 런처 버전, 서명 만료 시각을 함께 검증한다.

CDN과 두 개의 미러 서버로 패치 청크를 제공하는 라이브 운영 구성

미러 선택 정책

다운로더는 단일 서버를 끝까지 붙잡지 않아야 한다. 연결 실패, TLS 오류, HTTP 5xx, 일정 시간 이상의 무응답을 실패로 분류하고 다른 미러로 전환한다. HTTP 404는 콘텐츠 배포 불일치 가능성이 있으므로 단순 재시도보다 해당 미러를 일시 제외하고 운영 경보를 발생시키는 편이 낫다.

권장 정책은 다음과 같다.

연결·첫 바이트 타임아웃을 별도로 둔다.
같은 청크에 대해 동일 미러를 무한 재시도하지 않는다.
지수 백오프와 난수를 섞어 동시 재시도를 분산한다.
청크별 실패 횟수와 미러별 실패율을 텔레메트리로 전송한다.
해시 불일치가 발생한 미러는 즉시 격리하고 해당 청크를 다른 원본에서 다시 받는다.

백오프 대기 시간의 예시는 다음과 같다.

t_n = \min(t_{max}, t_0 \times 2^n) + \mathrm{jitter}

여기서 jitter는 여러 클라이언트가 같은 시점에 재시도하는 현상을 완화하는 임의 지연이다.

패치 배포 전에는 무엇을 테스트해야 하는가?

패치 QA는 정상 설치 확인만으로 충분하지 않다. 이전 버전, 손상된 캐시, 디스크 부족, 미러 장애처럼 실제 라이브 환경에서 자주 생기는 상태를 테스트 매트릭스로 관리해야 한다.

단계별 검증 절차

빌드 검증: 같은 커밋을 두 번 빌드해 산출물·매니페스트·청크 해시가 결정적으로 재현되는지 확인한다.
업데이트 검증: 지원하는 모든 이전 버전에서 목표 버전으로 업데이트하고 실제 다운로드 바이트와 예상 전송량을 비교한다.
장애 검증: 특정 미러의 404, 429, 500, 지연, 연결 끊김을 주입해 폴백·재개·해시 검증이 동작하는지 확인한다.
복구 검증: 다운로드 중 강제 종료, 청크 파일 일부 손상, 디스크 부족 후 재실행 시 안전하게 재개되는지 확인한다.
릴리스 검증: 매니페스트와 모든 청크가 CDN·미러에 완전히 전파된 뒤에만 최신 매니페스트를 공개한다.

특히 공개 순서는 중요하다. 새 매니페스트를 먼저 노출하면 클라이언트가 아직 복제되지 않은 청크를 요청해 404를 받는다. 청크 업로드와 원본 간 일치 확인이 끝난 뒤 매니페스트를 원자적으로 전환해야 한다.

운영 지표는 무엇을 봐야 하는가?

다운로드 성공률만 보면 용량 낭비와 사용자 체감 문제를 놓치기 쉽다. 버전·지역·ISP·미러별로 다음 지표를 분리해 수집한다.

지표	확인할 문제
업데이트 성공률	설치 실패, 무결성 오류, 권한·공간 문제
평균·P95 다운로드 시간	지역별 혼잡과 느린 원본
클라이언트당 다운로드 바이트	청크 재사용률과 델타 효율
해시 불일치율	저장소 복제 오류, 캐시 오염, 클라이언트 버그
미러별 HTTP 상태 코드	404 배포 순서 오류, 5xx 장애, 429 제한
재개 성공률	중단 후 복구 품질과 임시 파일 관리

운영 알림은 미러 1대의 일시적 실패보다 ‘전체 성공률 저하’와 ‘특정 버전의 404 급증’에 우선순위를 둔다. 후자는 배포 순서나 매니페스트 참조 오류를 빠르게 가리키는 신호다.

자주 묻는 질문 (FAQ)

청크 크기는 몇 MiB가 적절한가?

정답은 고정값이 아니다. 작은 청크는 재사용률과 재개 정밀도를 높이지만 요청 수·메타데이터를 늘린다. 1 MiB와 4 MiB 같은 후보를 실제 패치 이력, CDN 비용, P95 다운로드 시간으로 비교해 결정한다.

CDN이 있는데 미러 서버도 필요한가?

CDN이 단일 원본이나 단일 계정 구성에 묶여 있다면 원본 장애·설정 오류가 전체 배포 실패로 이어질 수 있다. 별도 원본 또는 별도 CDN을 미러로 두면 장애 격리와 전환 선택지가 생긴다. 다만 콘텐츠 동기화와 검증 체계를 갖추지 못한다면 미러 수만 늘려서는 안정성이 높아지지 않는다.

해시 검증만 하면 매니페스트 서명은 필요 없는가?

필요하다. 청크 해시는 받은 데이터의 무결성을 검증하지만 어떤 버전의 어떤 청크를 받아야 하는지는 매니페스트가 결정한다. 서명은 매니페스트 위변조와 의도치 않은 이전 버전 배포를 방지하는 핵심 장치다.

정리

패치 용량 최소화의 출발점은 결정적 빌드와 콘텐츠 해시 기반 매니페스트다. 그 위에 청크 재사용과 선택적 델타를 올리고 CDN·미러의 장애 전환과 무결성 검증을 연결하면 다운로드 비용과 라이브 장애를 함께 낮출 수 있다. 다음 릴리스에서는 먼저 ‘클라이언트당 실제 다운로드 바이트’, ‘미러별 404·해시 불일치율’, ‘업데이트 P95 시간’을 측정해 병목이 용량인지 전송 경로인지부터 분리해 보자.