> ## Documentation Index
> Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 콘텐츠 업데이트 모범 사례

> 콘텐츠 업데이트 모범 사례

<Tip>**MSIXVC2를 사용하시나요?** 이 페이지에서 설명하는 정렬 및 레이아웃 제약 조건은 기존 MSIXVC 형식에 적용됩니다. MSIXVC2는 이러한 요구 사항을 제거하는 콘텐츠 기반 세분화를 사용합니다. MSIXVC2 콘텐츠 업데이트 가이드는 [MSIXVC2를 사용한 콘텐츠 업데이트](/build/core-features/common/packaging/packaging-updates-msixvc2)를 참조하세요.</Tip>

## 개요

출시 후 데이터를 수정, 추가 또는 제거하여 콘텐츠 패키지를 업데이트할 수 있습니다. 업데이트를 시작하려면 전체 업데이트된 패키지를 Partner Center에 업로드하고 게시합니다. 이후 콘텐츠의 디지털 설치는 업데이트된 패키지를 직접 다운로드합니다. 시스템의 콘텐츠 업데이트 기술은 기존 설치를 수정하여 업데이트된 패키지와 동일하게 만듭니다.

Microsoft Game Development Kit(GDK) 콘텐츠는 하위 파일 세분화 수준에서 동작하는 XVC 또는 MSIXVC 패키지로 패키징됩니다.
데이터를 원위치에서 덮어쓸 수 있습니다. 또한 4키비바이트(KiB)(4,096바이트)의 배수 단위로 파일에 데이터를 삽입하거나 파일에서 데이터를 제거할 수 있습니다.
데이터를 효율적으로 이동할 수는 없습니다.

사용자가 원본 게임 디스크에서 이미 콘텐츠 업데이트가 있는 게임을 설치하면, 설치 프로세스는 디스크와 클라우드 모두에서 데이터를 가져옵니다. 패키지의 변경되지 않은 부분은 디스크에서 설치되고, 업데이트된 데이터는 스트리밍 설치를 통해 클라우드에서 다운로드됩니다. 이 프로세스는 시스템 UI와 모든 인게임 API에 대해 일반적인 스트리밍 설치와 완전히 동일하게 동작합니다.

콘솔이나 PC가 이전에 설치된 콘텐츠를 업데이트할 때, 프로세스는 새로운 데이터나 제거된 데이터를 수용하기 위해 설치된 XVC 또는 MSIXVC 패키지 파일을 원위치에서 수정한 다음 새 데이터를 다운로드합니다. 업데이트가 설치되기 시작한 시점부터 업데이트가 완료될 때까지 게임을 실행할 수 없습니다.

## 패키지를 효율적으로 작성하기

콘텐츠 업데이트는 게임 개발 프로세스를 방해하지 않으려고 합니다. 게임 콘텐츠에 어떤 변경 사항이 있어도 패키지를 올바르게 업데이트할 수 있습니다. 그러나 프로세스가 다운로드 크기(플레이어가 게임을 플레이할 수 없는 시간에 해당)나 소비되는 하드 드라이브 공간 측면에서 효율적이지 않을 수 있습니다. 다음 팁은 최고의 사용자 경험을 보장하도록 게임을 패키징하는 데 도움이 됩니다.

**간단:**

* 팩 파일을 사용하여 여러 자산을 단일 파일로 집계하는 경우, 팩 파일 생성기가 각 자산의 시작을 4KiB 경계에 정렬하도록 하세요. 이 팁은 [간단한 정렬 예제](#AS)에서 시연됩니다.
* 자산을 압축하는 경우 압축이 결정론적이고 각 자산이 독립적으로 압축되도록 하세요.
* 청크 ID를 변경하거나 청크 ID 간에 파일을 이동하지 마세요.
* 패키지 내의 청크, 청크 내의 파일, 파일 내의 자산을 재정렬하지 마세요. 자산을 이름이나 다른 안정적인 식별자로 정렬하는 것을 고려하세요.

**고급:**

* 팩 파일을 사용하여 여러 자산을 단일 파일로 집계하는 경우, 팩 파일 생성기가 각 자산의 시작을 일관되게 정렬하도록 하세요. 이 가이드는 항상 4KiB의 시작에 정렬하는 것의 고급 버전입니다.

  이전 패키지에서 오프셋 `PriorAssetOffset`에서 시작하고 업데이트로 빌드되는 패키지에서 `AssetOffset`에서 시작하는 자산의 예를 고려해보세요. 팩 파일 생성기가 각 자산의 시작을 4KiB 경계에 정렬하도록 하려면 `PriorAssetOffset % 4096 == 0` 및 `AssetOffset % 4096 == 0`으로 설정합니다. 이 조건은 항상 `PriorAssetOffset % 4096 == AssetOffset % 4096`을 만족합니다. 이 문장을 만족하도록 하는 다른 방법도 작동합니다. 이 조건은 팩 파일 생성기가 더 적은 패딩을 사용할 수 있게 해줍니다.

  이 팁은 [상태 저장 정렬 예제](#AAS)에서 시연됩니다.
* 결정론적이지 않은 압축을 사용하고 압축되지 않은 자산이 변경되지 않은 경우, 이전 패키징에서 압축된 데이터를 복사하여 압축된 데이터도 변경되지 않도록 하세요.
* 자산이 예상 런타임 로드 순서와 일치하도록 자동으로 정렬된 경우, 첫 릴리스에서 자동 정렬을 동결하는 것을 고려하세요.
* 팩 파일에 업데이트에서 자주 변경되는 아주 작은 자산이 많이 있는 경우, 이를 인접하게 만드는 것을 고려하세요. 4KiB를 100번 수정하는 것보다 400KiB를 수정하는 것이 더 효율적입니다.

## 팩 파일에서 좋은 정렬과 나쁜 정렬의 예

일부 게임은 많은 자산을 *팩 파일*이라고 하는 큰 파일로 결합합니다. 하위 파일 콘텐츠 업데이트는 이러한 게임에 대한 업데이트 다운로드의 다운로드 크기 및 하드 드라이브 크기 효율성을 크게 개선합니다. 이 기술을 활용하려면 게임의 팩 파일 생성 도구가 파일 내 자산의 4KiB 정렬을 유지하는 것이 중요합니다. 이 섹션에서는 팩 파일 내의 자산을 정렬하는 좋은 방법과 나쁜 방법의 예를 보여줍니다.

설명을 위해 각 예제는 문자가 있는 셀 시리즈로 표시됩니다. 각 셀은 다이어그램에서 1KiB이며 설명을 단순화합니다. 셀 사이의 실선은 4KiB 경계가 있는 곳을 나타냅니다.

### 데이터 덮어쓰기

다음 다이어그램에서 업데이트에서 단일 셀이 덮어쓰기됩니다. 다운로드되는 유일한 것은 이 셀을 포함하는 4KiB 페이지입니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_overwrite.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=5f7f4411ee0a3d16b6451b7fea33d1ec" alt="다이어그램은 단일 셀을 &#x22;변경된 데이터&#x22;로, 4KiB 페이지를 구성하는 네 셀을 &#x22;다운로드된 데이터&#x22;로 보여줍니다." width="1280" height="452" data-path="images/gdk/features/common/contentupdate_overwrite.png" />

### 삽입

다음 다이어그램에서 업데이트에서 단일 셀이 삽입됩니다. 그 결과 삽입 후 모든 셀이 하나씩 이동합니다. 이 이동은 셀을 4KiB 경계를 넘어 이동시켜, 삽입 후 이전 패키지와 새 패키지에서 어떤 4KiB 페이지도 동일하지 않게 만듭니다. 삽입 이후의 모든 4KiB 페이지가 다운로드됩니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_insert_non4k.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=f59f2be0322605d3bc6145bac1900caf" alt="다이어그램은 &#x22;ABCD&#x22; &#x22;EFGH&#x22; &#x22;IJKL&#x22; &#x22;MNOP&#x22; &#x22;QRST&#x22; &#x22;UVXW&#x22;를 보여주며, &#x22;J&#x22;와 &#x22;K&#x22; 사이에 데이터 &#x22;Z&#x22;가 삽입되고, 그 결과 &#x22;IJZK&#x22; &#x22;LMNO&#x22; &#x22;PQRS&#x22; &#x22;TUVW&#x22; &#x22;X&#x22;가 다운로드되는 것을 보여주며, 페이지 간 문자 이동을 나타내는 화살표가 있습니다." width="1280" height="480" data-path="images/gdk/features/common/contentupdate_insert_non4k.png" />

다음 다이어그램에서 업데이트에서 단일 셀이 삽입됩니다. 또한 세 개의 패딩 셀이 삽입됩니다. 네 셀은 함께 사실상 4KiB 삽입이며, 이는 이후 셀이 4KiB 경계를 넘어 이동하는 것을 방지합니다. 삽입과 패딩을 포함하는 8KiB만 다운로드됩니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_insert_4k.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=ffd813c89872b96b018e47e31f222710" alt="다이어그램은 &#x22;ABCD&#x22; &#x22;EFGH&#x22; &#x22;IJKL&#x22; &#x22;MNOP&#x22; &#x22;QRST&#x22; &#x22;UVXW&#x22;를 보여주며, &#x22;J&#x22;와 &#x22;K&#x22; 사이에 데이터 &#x22;Z&#x22;가 삽입되고, 그 결과 &#x22;IJZK&#x22;와 &#x22;L 패딩 패딩 패딩&#x22;이 다운로드되는 것을 보여줍니다." width="1280" height="480" data-path="images/gdk/features/common/contentupdate_insert_4k.png" />

### 삭제

다음 다이어그램에서 업데이트에서 단일 셀이 삭제됩니다. 그 결과 삭제 후 모든 셀이 하나씩 이동합니다. 이 이동은 셀을 4KiB 경계를 넘어 이동시킵니다. 삭제 이후의 모든 4KiB 페이지가 다운로드됩니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_delete_non4k.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=cc79ed7e3642c373f68cb8cf1f8fb375" alt="다이어그램은 &#x22;ABCD&#x22; &#x22;EFGH&#x22; &#x22;IJKL&#x22; &#x22;MNOP&#x22; &#x22;QRST&#x22; &#x22;UVXW&#x22;를 보여주며, 데이터 &#x22;K&#x22;가 삭제되고, 그 결과 &#x22;IJLM&#x22; &#x22;NOPQ&#x22; &#x22;RSTU&#x22; &#x22;VWX&#x22;가 다운로드되는 것을 보여주며, 페이지 간 문자 이동을 나타내는 화살표가 있습니다." width="1280" height="510" data-path="images/gdk/features/common/contentupdate_delete_non4k.png" />

다음 다이어그램에서 업데이트에서 여덟 셀이 삭제됩니다. 4KiB만 다운로드됩니다. 삭제의 시작과 끝의 4KiB 페이지 내에 있는 셀입니다.

삭제가 4KiB 정렬되어 있고 그 길이가 4KiB의 배수인 경우 데이터 다운로드가 필요하지 않습니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_delete_4k.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=7eef5d5ad6f21a30374495979f914188" alt="다이어그램은 &#x22;ABCD&#x22; &#x22;EFGH&#x22; &#x22;IJKL&#x22; &#x22;MNOP&#x22; &#x22;QRST&#x22; &#x22;UVXW&#x22;를 보여주며, 데이터 &#x22;KLMNOPQR&#x22;이 삭제되고, 그 결과 &#x22;IJST&#x22;가 다운로드되는 것을 보여줍니다." width="1280" height="510" data-path="images/gdk/features/common/contentupdate_delete_4k.png" />

<a id="AS" />

### 정렬: 간단

다음 다이어그램은 여섯 개의 자산을 보여줍니다. 각 자산은 임의의 수의 셀에 저장됩니다. 모든 자산의 시작이 4KiB 경계에 있습니다. 그 결과 자산을 독립적으로 추가, 변경(크기 증가 또는 감소 포함) 또는 삭제할 수 있습니다.

이 정렬은 팩 파일 내 자산을 정렬하는 가장 쉬운 방법입니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_packfile1.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=38675f40bc9f2e9609f0bc39ddca37dc" alt="다이어그램은 여러 셀에 걸친 자산의 예를 보여줍니다. 각 자산은 4KiB 경계에서 시작합니다. 이전 자산이 4KiB 배수의 길이가 아니었던 경우 자산 사이에 패딩 셀이 있습니다." width="1280" height="290" data-path="images/gdk/features/common/contentupdate_packfile1.png" />

### 정렬: 상태 없는 고급

다음 다이어그램은 일곱 개의 자산을 보여줍니다. 각 자산은 임의의 수의 셀에 저장됩니다. 모든 큰 자산의 시작은 4KiB 경계에 정렬되지만, 작은 자산(다이어그램의 Asset 6)은 이전 자산과 패딩 없이 연속적으로 팩됩니다. 이 정렬 방법은 세 가지 이점을 제공합니다.

1. 패딩에 더 적은 공간을 사용합니다.
2. Asset 5를 변경할 때 Asset 6 다운로드는 사실상 무료입니다.
3. Asset 6을 변경할 때 어차피 전체 4KiB가 다운로드됩니다. 그것이 패딩이든 Asset 5의 끝이든 문제가 되지 않습니다.

자산이 필요한 패딩에 맞을 수 있는 경우 패딩 없이 팩하세요.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_packfile2.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=733719567c04e2f7ed2566277fc46ef3" alt="다이어그램은 여러 셀에 걸친 자산의 예를 보여줍니다. 각 자산은 4KiB 경계에서 시작합니다. 이전 자산이 4KiB 배수의 길이가 아니었던 경우 자산 사이에 패딩 셀이 있습니다. Asset 6은 Asset 6 바로 뒤에 패딩 없이 이어지는 단일 셀입니다." width="1280" height="290" data-path="images/gdk/features/common/contentupdate_packfile2.png" />

<a id="AAS" />

### 정렬: 상태 저장 고급

다음 다이어그램은 일곱 개의 자산을 보여줍니다. 각 자산은 임의의 수의 셀에 저장됩니다. 첫 번째 패키지의 모든 자산의 시작이 패딩 없이 팩됩니다. 새 패키지에서 모든 자산의 시작은 이전 패키지에서 시작했던 것과 동일한 4KiB 페이지 오프셋에서 시작합니다.

예를 들어, Asset 3은 이전 패키지에서 4KiB 페이지의 한 셀 안쪽에서 시작했습니다. 새 패키지에서는 Asset 3 앞에 패딩이 추가되어 마찬가지로 4KiB 페이지의 한 셀 안쪽에서 시작하도록 되었습니다.

이 접근 방식은 콘텐츠 업데이트가 요구하는 정렬을 유지하면서 패딩의 양을 최소화합니다. 이 접근 방식의 단점은 팩 파일 도구가 그 오프셋과 일치시키기 위해 이전 팩 파일의 레이아웃에 대한 지식이 필요하다는 것입니다.

<img src="https://mintcdn.com/microsoft-4404708b/sIrPFR_ir_sNKVEv/images/gdk/features/common/contentupdate_packfile3.png?fit=max&auto=format&n=sIrPFR_ir_sNKVEv&q=85&s=00cbcaaf404c9a2eb2b52e4efe0c2506" alt="다이어그램은 여러 셀에 걸친 자산의 예를 보여줍니다. 첫 번째 패키지에는 패딩 셀이 없습니다. 새 패키지에는 Asset 3과 Asset 5 앞에 패딩 셀이 있습니다. 첫 번째 패키지에서 새 패키지로의 선은 패딩 셀이 Asset 3과 Asset 5가 두 패키지 모두에서 가장 가까운 4KiB 경계로부터 동일한 거리에서 시작하도록 함을 강조합니다." width="1280" height="464" data-path="images/gdk/features/common/contentupdate_packfile3.png" />

## 조각화

시간이 지나면서 기존 파일에 많은 변경이 이루어진 업데이트 이력이 긴 타이틀과, 큰 파일에 상당한 수의 작은 편집이 있는 패키지의 경우, 콘텐츠 업데이트 알고리즘이 최적이 아닌 업데이트 크기를 생성할 수 있습니다. 두 가지 방법으로 최적이 아닌 업데이트 크기를 확인할 수 있습니다.
1.\t`/priorpackage`와 함께 실행할 때 `makepkg pack`의 출력을 확인하세요. "More than # page-level XTS entries. Page-level update efficiency will be compromised for # pages."라는 경고가 표시됩니다.
1.\t`makepkg pack` 또는 `packageutil compare`에서 생성된 비교 보고서를 확인하세요. 이러한 보고서에 변경되지 않았다는 것을 아는 파일이 100% 재다운로드되는 것으로 표시된다면, 이는 XVC 파일 형식의 암호화 조각 데이터 구조에서 공간이 부족해지고 있다는 증상일 수 있습니다.

Microsoft Account 담당자의 안내에 따라, 보다 최적의 델타 계산을 생성하기 위해 `makepkg pack`에 대한 `/maxencryptionfragments` 옵션 사용을 고려하세요. 이 값을 너무 높게 설정하면 게임 실행 또는 DLC 마운트 중에 메모리 부족 오류의 위험이 증가합니다.

데이터를 삽입하면 콘텐츠 업데이트로 인해 물리적 하드 드라이브에 있는 패키지 데이터의 조각화가 발생합니다. 콘텐츠 업데이트는 업데이트 중에 패키지의 부분 조각 모음을 수행하여 이 효과를 최소화하려고 시도합니다. 여유 하드 드라이브 공간이 있는 경우, 인접한 두 조각의 크기 합이 100메비바이트(MiB) 이상이 되도록 보장합니다. 콘텐츠 업데이트는 모든 조각이 100MiB 이상이 되도록 시도합니다.

XBOX One ERA용 콘텐츠 업데이트의 이전 반복은 조각 모음을 수행하지 않았습니다.

## 도구 사용

* **`makepkg /contentid GUID`:** 패키지 제품군 이름과 함께 버전 전반에 걸쳐 패키지를 식별하는 콘텐츠 ID 매개변수입니다. 패키지 간 업데이트를 테스트하려면 동일한 콘텐츠 ID와 패키지 제품군 이름을 사용하여 두 패키지를 모두 만드세요.
* **`packageutil compare`:** 이 도구는 이전 패키지에서 새 패키지로 업데이트하는 방법을 설명하는 업데이트 플랜을 생성합니다. 또한 업데이트를 수행하기 위해 다운로드되는 파일과 해당 파일 내의 범위를 나열하는 보고서를 생성합니다. 이 보고서를 사용하여 예상치 못한 변경 사항을 식별하세요.
* **`xbapp update`(PC: `wdapp update`):** 이 도구는 개발 킷 또는 PC에 이전에 설치된 패키지를 새 패키지로 업데이트합니다. 소매 콘솔과 동일한 방법을 사용하므로 업데이트 후 사용자 경험과 IO 성능을 테스트하는 데 사용할 수 있습니다.

## 세부 정보

이 섹션에서는 콘텐츠 업데이트가 작동하는 방식에 대한 구현 세부 정보를 설명합니다. 이러한 세부 사항은 변경될 수 있습니다. 모든 것을 이해하고 세밀하게 조정하고자 하는 관심이 매우 많은 개발자를 대상으로 합니다.

**업데이트 스트리밍 플랜이란 무엇인가요?**

업데이트 스트리밍 플랜은 XBOX FastStart 기술의 진화입니다. 콘텐츠 업데이트 v3는 이러한 플랜을 사용하여 XBOX 콘솔과 PC에 이전 패키지를 새 패키지로 변환하는 방법을 알려줍니다. 이 접근 방식은 콘솔이나 PC가 다운로드 중에 할 수 있는 것보다 게시 시점에 클라우드에서 더 집중적인 분석을 수행할 수 있게 해줍니다.

**삽입 또는 삭제에 허용되는 배수로 왜 4KiB가 선택되었나요?**

4KiB는 XBOX 및 지원되는 PC 파일 시스템의 NTFS 클러스터 크기입니다. NTFS 클러스터 크기와 다른 배수로 삽입 또는 삭제를 수행하려면 업데이트를 설치하는 데 상당한 디스크 IO가 필요합니다.

콘텐츠 패키지는 4KiB 블록으로 암호화되고 무결성 보호됩니다. 암호화 블록 크기와 다른 배수로 삽입 또는 삭제를 수행하려면 업데이트를 설치하기 위해 데이터를 다시 암호화해야 합니다. 이 요구 사항은 적절한 사용자가 로그인하지 않았거나 게임 디스크를 사용할 수 없어 라이선스를 사용할 수 없는 시나리오에서 백그라운드 업데이트를 방지합니다.

이 요구 사항을 통해 패키지는 효율적으로 업데이트될 수 있으며 업데이트 프로세스가 끝날 때 시간이 많이 소요되는 압축 해제 단계가 필요하지 않습니다.

**makepkg/packageutil 중에 무엇이 발생하고, 게시 중에 무엇이 발생하나요?**

두 경우 모두 동일한 처리가 발생합니다. 게시 중에 패키지는 이전 패키지에 대한 클라우드의 최선의 선택(makepkg /priorpackage에 해당)에서 나온 데이터를 사용하여 암호화됩니다. 그런 다음 많은 이전 패키지의 업데이트 스트리밍 플랜이 생성됩니다(packageutil compare에 해당).

**makepkg에서 지정된 /priorpackage가 소매 패키지에 영향을 미치나요?**

아니요. 클라우드의 게시 프로세스는 항상 이 지정을 재정의합니다. `makepkg` 옵션은 게시 전 로컬 예상을 활성화하기 위해서만 제공됩니다.

**업데이트된 게임 데이터만 다운로드되나요?**

아니요. 패키지에는 모든 데이터 페이지의 암호화 해시, Game OS(콘솔 전용), 임베디드 NTFS 파일 시스템을 포함한 상당한 시스템 데이터가 포함됩니다. 이는 필요한 경우 다운로드됩니다.

또한, HTTP 요청의 오버헤드를 최소화하기 위해 일부 변경되지 않은 데이터가 재다운로드될 수 있습니다. 현재 변경된 데이터에 둘러싸인 64KiB 미만의 변경되지 않은 데이터는 재다운로드의 대상이 되지만, 이 구성은 *다운로드 시간*을 최적화하기 위해 변경될 수 있습니다.

packageutil compare에서 생성된 보고서는 위의 정보를 그 예상에 포함시킵니다.

### 참고 항목

[콘텐츠 업데이트 만들기, 검토 및 테스트](/build/core-features/common/packaging/packaging-testing-updates)

[업데이트 확인](https://learn.microsoft.com/build/store/commerce/fundamentals/xstore-checking-for-updates)


## Related topics

- [콘텐츠 업데이트 만들기, 검토 및 테스트](/ko/build/core-features/common/packaging/packaging-testing-updates.md)
- [업데이트 확인](/ko/publishing/xstore-commerce/xstore-checking-updates.md)
- [MSIXVC2를 사용한 콘텐츠 업데이트](/ko/build/core-features/common/packaging/packaging-updates-msixvc2.md)
- [타이틀 패키징, 업데이트, 스트리밍 설치 테스트](/ko/build/core-features/common/packaging/title-packaging-streaming-install-testing.md)
- [Streaming Installation 및 Intelligent Delivery 개요](/ko/build/core-features/common/packaging/overviews/streaming_install-intelligent_delivery.md)
