이 페이지에는 2022 LTS에서 Unity 6로 업그레이드할 때 기존 프로젝트에 영향을 줄 수 있는 Unity 6의 변경 사항이 나열되어 있습니다.
이 업그레이드 가이드에서는 Unity 빌트인 렌더 파이프라인을 Unity 6 버전으로 업그레이드하는 방법에 대해 설명합니다. 다른 렌더 파이프라인을 업그레이드하려면 다음을 참조하십시오.
다른 패키지를 업그레이드하려면 사용하는 패키지의 기술 자료를 참조하십시오.
Progressive Lightmapper는 Advanced 필터링 옵션(Lighting Window > Lightmapping Settings > Filtering > Direct Filter > Gaussian) 중에 Gaussian 옵션을 포함합니다. 이제 Gaussian 필터링을 위한 Radius 컨트롤이 0.5와 같은 소수점 증분을 지원합니다. 이전에는 이 컨트롤이 정수 단계(1–5)만 지원했습니다.
이 변경 사항으로 인해 다음 프로퍼티는 C# API에서 지원 중단되었습니다.
int LightingSettings.filteringGaussRadiusAOint LightingSettings.filteringGaussRadiusDirectint LightingSettings.filteringGaussRadiusIndirect지원이 중단된 프로퍼티의 대체 부동 소수점은 다음과 같습니다.
float LightingSettings.filteringGaussianRadiusAOfloat LightingSettings.filteringGaussianRadiusDirectfloat LightingSettings.filteringGaussianRadiusIndirect지원이 중단된 멤버 함수 중 하나를 호출하여 가우시안 필터 반지름을 가장 가까운 정수로 반올림할 수 있습니다.
이제 라이트 프로브가 라이트맵처럼 밝아집니다. 이전에는 Unity 라이트 프로브의 밝기가 94%에 불과했습니다. 따라서 라이트 프로브가 비추는 오브젝트는 라이트맵이 비추는 오브젝트보다 약간 어두워 보입니다. 이 변경 사항이 미묘하기 때문에 많은 사용자가 눈에 띄는 차이를 보지 못할 수도 있습니다.
이전과 같은 모습을 선호하는 경우 다음과 같은 방법으로 구현할 수 있습니다.
인라이튼 베이크된 전역 조명 라이트매핑 백엔드는 더 이상 사용할 수 없습니다.
프로젝트를 이 버전으로 업그레이드하면 Unity는 인라이튼 베이킹 백엔드를 라이트매퍼 선택 드롭다운에서 제거하고 선택한 인라이튼 베이킹 백엔드가 있는 모든 씬에서 프로그레시브 라이트매퍼로 대체합니다.
Apple Silicon 기기에서 Unity는 프로그레시브 GPU 라이트매퍼를 인라이튼 베이킹 백엔드로 대체합니다. 다른 모든 기기에서 Unity는 CPU 프로그레시브 라이트매퍼를 선택합니다.
인라이튼 사전 계산된 실시간 전역 조명은 Unity 2024 LTS까지 지원됩니다.
UnityPlayer Java 클래스는 UnityPlayerForActivityOrService 및 UnityPlayerForGameActivity 두 개의 새로운 브리지 클래스로 대체되었습니다. 이러한 새로운 클래스는 모두 UnityPlayer에서 파생되지만, displayChanged와 windowFocusChanged 같은 공용 메서드는 UnityPlayer에서 UnityPlayerForActivityOrService로 전환되었습니다.
기본 Unity 활동을 확장하고 UnityPlayer 클래스를 사용하는 경우 컴파일 오류가 발생할 수 있습니다. 이 경우 UnityPlayer의 이름을 UnityPlayerForActivityOrService로 변경합니다.
UnityPlayer Java 클래스는 더 이상 FrameLayout을 확장하지 않습니다. FrameLayout에 액세스해야 하는 경우 UnityPlayer 인스턴스의 getFrameLayout 함수를 호출합니다.
이제 RenderPipelineEditorUtility.FetchFirstCompatibleTypeUsingScriptableRenderPipelineExtension이 지원 중단되었습니다. 대신 GetDerivedTypesSupportedOnCurrentPipeline을 사용합니다. 이 메서드의 서명도 다릅니다. 이제 처음 접하는 유형뿐만 아니라 파생되는 모든 유형을 반환합니다. Unity는 유형 순서를 보장하지 않으므로 일관성 문제가 발생하지 않습니다.
CustomEditorForRenderPipelineAttribute 및 VolumeComponentMenuForRenderPipelineAttribute는 현재 지원 중단되었습니다. 대신에 CustomEditor와 VolumeComponentMenu를 사용합니다. 이러한 속성이 활성화된 경우 파이프라인 선택을 제한하려면 SupportedOnRenderPipelineAttribute와 결합하고 RenderPipelineAsset 유형을 지정합니다. 빌트인 렌더 파이프라인에서 작동하는 SRP 속성을 활성화하려면 파라미터 없이 SupportedOnRenderPipelineAttribute를 사용하십시오. 이는 특정 파이프라인에서 활성화해야 하는 경우 두 속성 모두에 대한 통합 워크플로를 제공합니다.
Android__ Gradle__여러 빌드 프로세스를 자동화하는 Android 빌드 시스템입니다. 이러한 자동화로 인해 많은 일반적인 빌드 오류가 발생할 가능성이 감소합니다. 자세한 정보
See in Glossary 프로젝트를 수정하는 새로운 API가 도입되었습니다. API를 사용하여 이전 Android Gradle 템플릿 워크플로를 교체할 수 있습니다. 새 API를 사용하지 않으면 템플릿이 이전과 동일하게 작동합니다.
새 API를 사용하려면 다음과 같이 템플릿 업그레이더를 사용할 수 있습니다.
Unity의 프로그레시브 라이트매퍼는 더 이상 기본적으로 앰비언트 프로브와 스카이박스 반사 프로브를 베이크하지 않으며, Lighting 창의 Recalculate Environment Lighting 설정이 제거되었습니다.
씬이 환경 조명 없이 새로 생성되는 것을 방지하기 위해 Unity는 기본 스카이박스 머티리얼과 일치하는 환경 조명을 포함하는 기본 조명 데이터 에셋을 할당합니다.
다음과 같은 경우에는 Lighting 창에서 Generate Lighting을 선택해야 합니다.
이전의 자동 베이킹 동작에 의존하지만 기본 환경 조명 설정을 사용하는 경우 Unity는 기본 조명 데이터 에셋을 사용하도록 씬을 업그레이드합니다.
Lighting 창의 Auto Generate 설정이 제거되었으며 관련 API는 더 이상 사용되지 않습니다.
씬에 베이크된 조명을 생성하려면 다음 중 하나를 수행하십시오.
Lightmapping.Bake API를 사용합니다.Lightmapping.BakeAsync API를 사용합니다.편집하는 동안 라이트맵을 확인하려면 이제 Scene View Draw Mode를 선택하고 Lighting Data를 Preview로 설정할 수 있습니다. 이는 베이크된 조명의 미리 보기를 표시합니다. 미리 보기 라이트맵은 비파괴적이며, 씬을 베이크한 후에 사용할 수 있습니다.
씬이 자동 생성된 조명에 의존하는 경우 더 이상 베이크된 조명이 없습니다. Lighting 창에서 Generate Lighting을 선택하여 조명을 수동으로 다시 베이크합니다.
스크립트를 사용하여 씬을 열면 이제 자동 생성 조명이 완료될 때까지 기다리는 대신 Lightmapping.Bake 또는 Lightmapping.BakeAsync를 사용해야 합니다.
2022.1에 지원이 중단된 다음 그래픽스 포맷은 더 이상 사용되지 않으며, 사용 시 컴파일 오류가 발생합니다.
GraphicsFormat.DepthAutoGraphicsFormat.ShadowAutoGraphicsFormat.VideoAutoGraphicsFormatUtility.GetGraphicsFormat API는 더 이상 사용되지 않는 포맷을 반환하지 않습니다. 대신 다음 작업을 수행합니다.
GraphicsFormat.DepthAuto 대신 RenderTextureFormat.Depth를 GraphicsFormat.None으로 변환합니다. GraphicsFormat.None은 뎁스 전용 렌더링을 나타냅니다.GraphicsFormat.ShadowAuto 대신 RenderTextureFormat.Shadowmap을 GraphicsFormat.None으로 변환합니다. GraphicsFormat.None 포맷으로 렌더 텍스처를 생성하는 경우 RenderTextureDescriptor.shadowSamplingMode를 ShadowSamplingMode.CompareDepths로 설정하여 뎁스 비교 샘플링을 활성화해야 합니다.
GraphicsFormat.DepthAuto와 GraphicsFormat.ShadowAuto 모두 뎁스 스텐실 포맷으로 간주되었지만 컬러 포맷으로 사용되므로 코드를 조정해야 할 수 있습니다.
예를 들어 다음 스니핏에서 GraphicsFormatUtility.IsDepthFormat은 true 대신 false를 반환합니다.
RenderTextureDescriptor desc = new RenderTextureDescriptor(256, 256, RenderTextureFormat.Depth, 32);
bool isDepthOnly = GraphicsFormatUtility.IsDepthFormat(desc.graphicsFormat);
RenderTexture 또는 RenderTextureDescriptor가 뎁스 전용인지 확인하려면 다음 중 하나를 사용하십시오.
if (renderTexture.graphicsFormat == GraphicsFormat.None && renderTexture.depthStencilFormat != GraphicsFormat.None)if (renderTexture.format == RenderTextureFormat.Depth || renderTexture.format == RenderTextureFormat.Shadowmap)
런타임 시 생성된 2D 텍스처는 기본적으로 더 이상 밉맵 업로드 제한이 없습니다. 이전에는 밉맵 제한을 Texture2D 생성자(생성자가 TextureFormat으로 호출될 때 ignoreMipmapLimit 부울 파라미터를 제공하거나, GraphicsFormat으로 호출될 때 IgnoreMipmapLimit TextureCreationFlag를 제공)를 통해 명시적으로 비활성화해야 했거나, 구성된 텍스처의 tex.ignoreMipmapLimit을 토글해야 했습니다. 이 동작이 변경되어, 이제 런타임 시 생성된 2D 텍스처에 밉맵 제한이 옵트인됩니다.
프로젝트를 변경하지 않으면 다음과 같은 경우 GPU 대역폭 및 메모리 최적화를 놓치며, 텍스처가 현재 최대 해상도로 업로드되기 때문에 의도한 것보다 품질이 향상될 수 있습니다.
다음과 같은 경우 사용자는 이 변경 사항의 영향을 받지 않습니다.
ignoreMipmapLimit은 false)tex.ignoreMipmapLimit을 false로 설정지원이 중단된 생성자를 사용하는 경우 스크립트를 업그레이드해야 할 수 있습니다.
스크립트를 업그레이드하려면 MipmapLimitDescriptor가 있는 Texture2D 생성자를 사용하여 런타임 텍스처가 품질 설정의 영향을 받아야 함을 표시합니다.
이 변경 사항은 Texture2DArrays에 대한 새로운 밉맵 제한 지원과 일치하도록 적용되었습니다. 각 텍스처 셰이프가 고유한 기본 밉맵 제한 동작을 정의하도록 하는 대신, 일관성을 선택하고 런타임 텍스처에서 밉맵 제한을 명시적으로 활성화해야 하는 것으로 결정되었습니다. 이러한 옵트인 동작이 옵트아웃 동작보다 선호됩니다. 예상보다 적은 밉을 예기치 않게 업로드하는 것이 많은 밉을 예기치 않게 업로드하는 것보다 더 유해한 방식으로 런타임 텍스처가 다양하게 사용되기 때문입니다.
UI 툴킷의 UXML로 커스텀 컨트롤 생성을 간소화하여 워크플로 속도를 높이고 직관성을 높였습니다.
주요 개선 사항으로 UxmlElement 및 UxmlAttribute 속성이 도입되었습니다. 이러한 속성을 사용하면 속성 저작(authoring)을 간소화하고 속성 이름을 프로퍼티 이름에서 자동으로 파생하여 UxmlTraits 및 UxmlFactory 클래스가 필요하지 않습니다.
이제 특정 데이터 유형에 대한 커스텀 속성 컨버터를 생성하여 UXML 속성 문자열에서 값을 원활하게 전환할 수 있습니다. 또한 UxmlObject를 개선하여 비시각적인 커스텀 요소를 시각적 요소 내에서 정의할 수 있도록 했습니다. 새로운 시스템은 Unity 직렬화를 활용하고 소스 제너레이터를 사용하여 각 커스텀 요소 클래스의 모든 UxmlAttribute 정의 요소에 대한 UxmlSerializedData 클래스를 생성해서 커스텀 프로퍼티 드로어, 데코레이터 및 다양한 속성을 지원합니다.
‘속성 오버라이드’를 도입하면 UXML 속성의 동작을 커스터마이즈할 수 있으며 상속된 속성으로 작업할 때 유연성을 제공합니다. 이러한 개선 사항은 Unity 2023.2 이상에서 복잡한__ UI__(사용자 인터페이스) 사용자가 애플리케이션과 상호 작용하도록 해 줍니다. Unity는 현재 3개의 UI 시스템을 지원합니다. 자세한 정보
See in Glossary 요소를 만들 때 더욱 효율적이고 사용자 친화적인 경험을 제공합니다.
예를 들어 다음 코드 샘플은 UxmlFactory 및 UxmlTraits로 생성된 커스텀 컨트롤입니다.
public class HealthBar : VisualElement
{
private const float k_LowValue = 0;
private const float k_HighValue = 100;
// Declare as usable with Uxml
public new class UxmlFactory : UxmlFactory<HealthBar, UxmlTraits> { }
// Define attributes (and connect with class properties) for Uxml
public new class UxmlTraits : BindableElement.UxmlTraits
{
UxmlColorAttributeDescription m_Color = new UxmlColorAttributeDescription { name = "color", defaultValue = Color.white };
UxmlFloatAttributeDescription m_Value = new UxmlFloatAttributeDescription { name = "value", defaultValue = k_HighValue };
public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
{
base.Init(ve, bag, cc);
var bar = ve as HealthBar;
bar.color = m_Color.GetValueFromBag(bag, cc);
bar.value = m_Value.GetValueFromBag(bag, cc);
}
}
public Color color { get; set; }
[Range(k_LowValue, k_HighValue)]
public float value { get; set; }
}
다음 코드 샘플은 이전 코드 샘플과 동일한 작업을 수행하지만 새로운 UxmlElement 및 UxmlAttributes 시스템을 사용합니다.
[UxmlElement]
public class HealthBar2 : VisualElement
{
private const float k_LowValue = 0;
private const float k_HighValue = 100;
[UxmlAttribute]
public Color color { get; set; } = Color.white;
[UxmlAttribute]
[Range(k_LowValue, k_HighValue)]
public float value { get; set; } = k_HighValue;
}
더 많은 예제와 정보는 Unity UI 툴킷 기술 자료를 참조하고 가을에 발표될 자세한 블로그 게시물을 기다려 주십시오.
Assets/Create 메뉴가 재구성 및 분류되었습니다. 이 점검의 일부로 Unity 빌트인 ScriptTemplate 파일의 이름이 변경되었습니다.
CreateAssetMenuAttribute``, MenuItemAt tribute 또는 커스텀 ScriptTemplate을 사용하여 Assets/Create 메뉴에 요소를 추가한 사용자는 다른 요소에 대한 위치가 다르므로 메뉴 항목의 우선순위를 변경해야 할 수 있습니다.
EditorApplication.ExecuteMenuItem API로 메뉴 항목을 실행하여 에셋을 생성하는 사용자는 메뉴 항목의 새 경로를 확인해야 합니다.
이전에 Unity 빌트인 ScriptTemplates를 오버라이드한 사용자는 오버라이드 파일의 이름을 업데이트하여 빌트인 템플릿의 새로운 이름과 일치하도록 해야 합니다.
ExecuteDefaultAction 및 ExecuteDefaultActionAtTarget 메서드는 지원이 중단되었습니다. 이러한 메서드는 CallbackEventHandler에서 시작되었으며, VisualElement의 하위 클래스에 영향을 미칩니다. 이벤트 전파를 처리하기 위해 이러한 메서드를 오버라이드하거나 호출하는 커스텀 VisualElement 하위 클래스가 있는 경우, 이러한 메서드는 더 이상 이벤트의 기본 동작을 처리하는 데 권장되지 않습니다. 이 변경 사항은 CallbackEventHandler에서의 상속으로 인해 VisualElement에서 파생된 대부분의 사용자에게 영향을 줍니다.
ExecuteDefaultAction 및 ExecuteDefaultActionAtTarget을 대체하기 위해 다음 메서드가 추가되었습니다.
HandleEventTrickleDownHandleEventBubbleUpUnity는 해당 요소의 TrickleDown 직후 및 BubbleUp 콜백 직전에 이벤트 디스패치 경로의 각 요소에 이러한 새로운 메서드를 실행합니다. 이러한 메서드 중 디스패치 단계는 그에 따라 TrickleDown 또는 BubbleUp으로 설정되고 이벤트의 currentTarget은 메서드를 실행하는 요소와 일치합니다.
AtTarget 디스패치 단계와 PreventDefault 메서드는 지원이 중단되었습니다. 이제 StopPropagation 또는 StopPropagationImmediately 호출은 TrickleDown 및 BubbleUp 콜백의 추가 호출을 중지하는 동시에 HandleEventTrickleDown 및 HandleEventBubbleUp의 추가 실행을 중지합니다.
대부분의 경우 새 메서드로 업그레이드하지 않으려면 코드가 동작을 크게 변경하지 않아야 합니다. UI 툴킷은 여전히 사용되지 않는 메서드를 이전과 동일한 순서로 또는 최소한의 조정으로 호출합니다. 하지만 UI 툴킷 내의 모든 표준 컨트롤은 새로운 메서드를 사용하도록 마이그레이션되어 로직 실행 순서를 그에 맞게 조정했습니다. 업그레이드된 컨트롤을 사용하여 사용되지 않는 메서드에 대한 호출을 혼합하면 이전 Unity 버전에 비해 일부 로직이 동기화되지 않을 수 있습니다.
기존 코드를 새 메서드로 업그레이드하려면 다음 단계를 따르십시오.
ExecuteDefaultAction 및 ExecuteDefaultActionAtTarget을 HandleEventBubbleUp으로 대체하고 PreventDefault를 StopPropagation으로 대체합니다. 또는 동일한 코드 블록에서 StopPropagation이 이미 호출된 경우 PreventDefault 호출을 제거합니다. 이는 대부분의 경우에 해당됩니다.BubbleUp 콜백 중에 PreventDefault를 호출하는 문제가 발생하면(더 이상 진행이 불가능하고 StopPropagation으로 대체할 수 없음) TrickleDown 단계에서 콜백을 추가하여 StopPropagation을 호출하는 것이 좋습니다. 보통 이 단계는 이러한 시나리오를 해결하기에 충분합니다.
버퍼 레이아웃과 관련하여 Unity 셰이더에서 Metal 셰이더로의 교차 컴파일이 변경되었습니다. 이제 min16float, half 또는 real 유형이 포함된 모든 버퍼는 이전 Unity 버전과 다른 메모리 레이아웃을 갖습니다.
Metal을 타게팅하고 버퍼에 직접 원시 데이터를 작성하는 API를 사용하는 경우에만 조치를 취해야 합니다. 예를 들면 다음과 같습니다.
CommandBuffer.SetComputeFloatParam 또는 Material.SetFloat만 사용하는 경우에는 조치를 취할 필요가 없습니다.
더욱 구체적으로 HLSL min16float, half 및 real 내부 버퍼는 항상 32비트 MSL float로 전환되지만, 이전 Unity 버전에서는 타겟 플랫폼에 따라 16비트 MSL half로 전환될 수 있습니다.
Metal 플랫폼에서만 셰이더를 테스트한 경우 생성된 MSL 코드의 버퍼를 확인하여 레이아웃이 C#에서 액세스하는 버퍼 데이터와 일치하는지 확인합니다. 셰이더 코드에 #pragma metal_fxc_allow_float16_in_cpu_visible_buffers를 추가하고 시각적 결함이 해결되었는지 확인하여 이 변경 사항이 셰이더에 영향을 미치는지 테스트할 수 있습니다. 차이점이 발견되면 프로젝트의 크로스 플랫폼 호환성을 개선하기 위해 이 pragma를 제거하고 pragma 없이도 올바르게 작동하도록 셰이더 및 C# 코드를 조정합니다.
버퍼에서 네이티브 16비트 플로트를 사용하려면 DXC HLSL 컴파일러를 사용하고 셰이더에 #pragma require Native16Bit를 추가하는 것이 좋습니다. 하지만 Unity에서 DXC를 사용하는 것은 아직 실험 단계에 있습니다.
전역 패키지 캐시에는 여러 하위 폴더가 있습니다. 이러한 하위 폴더 중 하나인 packages는 패키지 관리자에서 더 이상 사용하지 않습니다.
전역 패키지 캐시의 packages 하위 폴더와 직접 상호 작용하는 자동화 스크립트나 파이프라인이 있는 경우(예: UPM_CACHE_PATH 환경 변수를 사용하는 경우)에만 조치를 취해야 합니다. 해당하는 경우에는 레퍼런스를 삭제할 수 있습니다. Unity는 packages에 대한 직접 대체 하위 폴더를 제공하지 않습니다. 이제 패키지가 프로젝트 캐시에 직접 추출됩니다.
Unity 2023.2로 생성된 프로젝트를 더 이상 관리하지 않는 경우 전역 패키지 캐시 루트에서 packages 하위 디렉토리를 안전하게 삭제할 수 있습니다. 이 작업은 선택 사항입니다.
이전 버전의 Unity 에디터는 패키지 관리자가 압축되지 않은 패키지 타르볼(tarball)의 콘텐츠를 저장할 위치에 대한 절대 경로를 지정하기 위해 UPM_CACHE_PATH 환경 변수를 사용하도록 지원했습니다.
UPM_CACHE_PATH에서 경로 값을 설정하는 자동화 스크립트나 파이프라인이 있는 경우에만 조치를 취해야 합니다. 이제 패키지가 프로젝트 캐시에 직접 추출되므로 UPM_CACHE_PATH를 대체할 수 없습니다. 그러나 UPM_CACHE_PATH를 사용하는 경우 이제 전역 캐시의 루트를 설정하는 UPM_CACHE_ROOT 환경 변수를 사용할 수 있습니다. 전역 캐시 루트는 이전에 UPM_CACHE_PATH와 연결된 하위 폴더의 상위 디렉토리입니다.
자세한 내용은 전역 캐시 커스터마이즈를 참고하십시오.
Unity는 Android에서 사용되는 다음 툴의 기본 버전을 업데이트했습니다. NDK, SDK 커맨드 라인 툴 및 SDK 툴의 기본 버전은 변경되지 않습니다. 업데이트된 버전은 다음과 같습니다.
| 툴 | 버전 |
|---|---|
| Gradle | 8.4 |
| Android Gradle 플러그인 | 8.3.0 |
| SDK 빌드 툴 | 34.0.0 |
| SDK 플랫폼 툴 | 34.0.5 |
| JDK(Java 개발 키트) | 17 |
프로젝트에서 커스텀 Gradle 템플릿을 사용하는 경우 업데이트된 Android Gradle 플러그인 버전의 빌드 문제를 방지하기 위해 해당 템플릿을 다시 생성하는 것이 좋습니다. 자세한 내용은 Gradle 템플릿 파일로 Gradle 프로젝트 파일 수정을 참고하십시오.
이전 Unity 에디터 버전에는 zstandard 압축을 지원하는 7-Zip 포크가 포함되어 있었습니다.
Windows 버전에는 업스트림 7-Zip 버전 22.01의 포크에 해당하는 mcmilk/7-Zip-zstd의 포크인 7-Zip-zstd가 포함되어 있었습니다. 이 코드는 CVE–2023–31102 및 CVE–2023–40481 같은 여러 주요 보안 문제에 취약합니다.
macOS 및 Linux 버전에는 tehmul/p7zip-zstd(2017년에 중지)의 포크인 p7zip-zstd가 포함되었으며, 이는 업스트림 7-Zip의 포크에 해당하는 p7zip(2016년에 중지)의 포크입니다. 이 코드는 CVE–2016–7804, CVE–2017–17969, CVE–2018–10115, CVE–2018–10172, CVE–2018–5996, CVE–2023–31102, CVE–2023–40481 같은 여러 주요 보안 문제에 취약합니다.
Unity 6에는 Windows, macOS 및 Linux 에디터용 7-Zip의 일반 업스트림 버전 23.01이 포함되어 있습니다. 그러나 이 7-Zip 업스트림 버전은 .zip 또는 .7z 아카이브의 zstandard 압축 또는 압축 풀기를 지원하지 않습니다. 또한 추가 압축 포맷 및 mcmilk/7-Zip-zstd 포크에 추가된 해시 알고리즘을 지원하지 않습니다.
zstandard 압축을 사용하여 아카이브에서 작동하는 7za 또는 7z.exe 바이너리를 사용하는 패키지가 있는 경우 다음 옵션 중 하나를 사용하십시오.