Metal 4 핵심 정리: 새로운 코어 API가 실제로 바꾸는 것

Metal 4는 재작성이 아닙니다. Apple은 이를 기존 Metal 타입과 나란히 동작하는 병렬 API 표면으로 출시했으며, 새로운 타입에는 MTL4 접두사를 붙여서 앱이 기존 렌더링 코드를 다시 작성하지 않고도 새로운 코어 API를 점진적으로 도입할 수 있도록 했습니다.¹ 이 프레이밍이 중요합니다. Metal 프레임워크 자체는 오랫동안 출시되어 왔으며, WWDC25에서 변경된 것은 Metal 4 코어 API입니다.

새로운 코어 API가 앱 개발자에게 실제로 바꾸는 세 가지는 다음과 같습니다.

1. 멀티스레드 명령 버퍼 인코딩이 일급 패턴이 됩니다.
2. 컴퓨트 인코더가 블릿(blit) 및 가속 구조 인코더를 하나의 통합된 표면으로 흡수합니다.
3. 머신러닝이 렌더 및 컴퓨트와 함께 일급 패스 타입으로 실행되며, CPU로 왕복하지 않고 GPU 타임라인에서 Core ML 모델을 실행합니다.

아래 섹션에서는 이 세 가지 변경 사항이 실제로 어떤 모습인지, 개발자가 사용하게 될 새로운 타입은 무엇인지, 그리고 Apple의 문서가 그러한 형태를 취한 이유에 대해 어떻게 설명하는지 살펴봅니다.

TL;DR

• MTL4CommandQueue, MTL4CommandBuffer, MTL4RenderCommandEncoder, MTL4ComputeCommandEncoder, MTL4MachineLearningCommandEncoder가 새로운 타입입니다.¹ 기존 MTL 접두사 타입은 그대로 유지됩니다. 둘을 혼합해서 점진적으로 도입합니다.
• 명령 버퍼는 별도의 MTL4CommandAllocator로부터 작업 메모리를 가져오며, 이를 통해 여러 스레드가 여러 버퍼에 병렬로 인코딩할 수 있습니다. 단일 commit:count: 호출로 배치를 큐에 제출합니다.¹
• MTL4ComputeCommandEncoder는 이전의 세 가지 인코더를 대체합니다. MTLBlitCommandEncoder, MTLComputeCommandEncoder, MTLAccelerationStructureCommandEncoder입니다.¹ 인코더 하나로 세 가지 작업을 처리합니다.
• MTL4MachineLearningCommandEncoder는 Metal 명령 버퍼 내부에서 Core ML 모델을 실행합니다.² 시스템이 각 모델에 대해 GPU 또는 Apple Neural Engine을 선택합니다. 텐서가 입력과 출력을 운반하며, 동일한 명령 버퍼에서 ML 추론과 렌더 및 컴퓨트 작업을 혼합합니다.
• 리소스 바인딩은 인코더별 바인딩 메서드 대신 인수 테이블(MTL4ArgumentTable)로 이동합니다. 모든 리소스는 추적되지 않으며, 명시적인 배리어로 동기화합니다.¹

왜 병렬 API 표면인가

병렬 타입 선택에 대한 Apple의 프레이밍을 문서에서 그대로 인용하면 다음과 같습니다. “Metal 4는 MTL4 접두사가 붙은 여러 타입을 도입하며, 이들은 자신이 대체하는 기존 MTL 타입과 완전히 독립적입니다(예: MTL4CommandQueue와 MTLCommandQueue). 다른 타입들은 Metal의 모든 버전에 공통입니다.”¹

런타임 검사는 단순합니다. 앱은 시스템이 Metal 4를 지원하는지 감지하여, 지원하면 MTL4CommandQueue를 생성하고 그렇지 않으면 MTLCommandQueue로 대체합니다. 앱이 생성하는 큐의 타입에 따라 나머지 렌더링 코드가 어떤 타입 패밀리를 사용할지가 결정됩니다.¹

이 설계의 나머지 절반은 두 패밀리가 상호 운용되도록 합니다. MTLEvent와 MTLSharedEvent는 MTLCommandQueue와 MTL4CommandQueue 인스턴스 모두에서 동기화를 수행합니다.¹ 상당량의 Metal 1 코드베이스를 운용하는 앱은 앱의 나머지 부분이 의존하는 동기화 패턴을 깨뜨리지 않고도 단일 서브시스템을 Metal 4로 전환할 수 있습니다.

이는 WWDC25 이후 앱 개발자들이 묻고 있던 질문에 답을 줍니다. Metal 코드를 다시 작성해야 합니까? 아닙니다. API의 형태는 서브시스템별 점진적 도입을 권장합니다.

멀티스레드 명령 버퍼 인코딩

대표적인 런타임 개선 사항은 다음과 같습니다. 명령 버퍼 메모리는 큐가 아닌 동반 타입인 MTL4CommandAllocator에서 가져옵니다. 각 스레드는 자체 할당자를 사용하여 자체 명령 버퍼에 작업을 인코딩할 수 있고, 큐는 버퍼를 배치로 커밋합니다.

Apple의 API 형태:¹

let device: MTLDevice = ...
let commandQueue: MTL4CommandQueue = device.makeMTL4CommandQueue()
var commandAllocators: [MTL4CommandAllocator] = ...
let commandBuffer: MTL4CommandBuffer = device.makeCommandBuffer()

// Per frame:
let frameAllocator = commandAllocators[frameNumber % kMaxFramesInFlight]
frameAllocator.reset()
commandBuffer.beginCommandBuffer(allocator: frameAllocator)
// ...encode commands to commandBuffer...
commandBuffer.endCommandBuffer()
commandQueue.commit(commandBuffer, count: 1)

기존 API와 비교하여 두 가지 운용상의 변경 사항이 있습니다.

명령 버퍼는 재사용 가능합니다. Apple의 문서: “새 버퍼를 할당하는 대신, 다시 시작하고 새 명령을 인코딩하고 다시 커밋함으로써 각 명령 버퍼를 무한히 재사용하고 용도를 변경할 수 있습니다.”¹ 이전 Metal에서는 커밋할 때마다 새로운 일회성 버퍼가 필요했습니다.

자동 리소스 보유는 없습니다. “각 MTL4CommandBuffer 인스턴스는 리소스에 대한 강한 참조를 생성하지 않습니다.”¹ 동작은 이전 API의 makeCommandBufferWithUnretainedReferences()와 유사합니다. 앱은 GPU가 작업을 완료할 때까지 리소스가 살아 있도록 명시적으로 리소스 수명을 관리해야 합니다.

Apple이 샘플 코드에서 제공하는 프레임 할당자 패턴은 진행 중인 프레임당 하나의 할당자(샘플은 세 개 사용)를 사용하며, 프레임이 인코드 → 렌더 → 표시 라이프사이클을 진행함에 따라 이를 순환합니다.¹ 각 프레임 시작 시 할당자에 대해 reset()을 호출하면 메모리가 풀로 반환되어 재사용됩니다.

통합 컴퓨트 인코더

MTL4ComputeCommandEncoder는 “세 가지 이전 타입의 기능을 결합한 새로운 타입입니다. MTLBlitCommandEncoder, MTLComputeCommandEncoder, MTLAccelerationStructureCommandEncoder.”¹

이전 API는 작업 형태에 따라 인코더 타입을 전환해야 했습니다. 리소스 복사와 텍스처 전송에는 블릿, 커널 디스패치에는 컴퓨트, 레이 트레이싱 씬 관리에는 가속 구조였습니다. Metal 4는 이 세 가지를 하나의 표면으로 통합합니다. 가속 구조를 빌드하고, 디노이징 커널을 디스패치하고, 텍스처를 표시 버퍼에 복사하는 프레임을 인코딩하는 앱은 이제 단일 인코더 타입을 통해 세 가지 모두를 수행할 수 있습니다.

렌더 인코더에도 동작 변경이 있습니다. MTL4RenderCommandEncoder는 한 렌더 인코더의 끝에서 작업을 일시 중단하고 시퀀스의 다음 인코더 시작 후에 작업을 재개함으로써 명령 버퍼 전반에 걸친 렌더 패스 인코딩을 지원합니다.¹ Apple의 프레이밍: “이 기법은 개념적으로 MTLParallelRenderCommandEncoder 프로토콜을 대체하며, 각 스레드가 모든 스레드를 단일 렌더 인코더에 묶지 않고 자체 렌더 인코더를 가질 수 있어 여러 스레드와 함께 렌더 패스를 병렬로 인코딩하는 것을 단순화합니다.”¹

패턴이 유지됩니다. 병렬 인코딩이 자연스러운 형태가 되고, API는 더 이상 단일 코디네이터 타입을 요구하지 않습니다.

인수 테이블이 인코더별 리소스 바인딩을 대체합니다

기존 Metal 인코더 API는 각 인코더에 setVertexBuffer(_:offset:index:) 및 setFragmentTexture(_:index:) 같은 메서드를 노출했고, 인코더 내부에 단계별로 분리된 바인딩 테이블을 두었습니다.¹ Metal 4는 이 패턴을 명시적인 MTL4ArgumentTable 인스턴스로 대체합니다.

설계 이점에 대한 Apple의 프레이밍: “Metal 4 인코더는 모든 단계에서 모든 리소스 타입에 대한 바인딩 테이블을 저장하기 위한 메모리를 필요로 하지 않습니다. 각 테이블은 자신의 리소스 바인딩을 저장하는 데 필요한 메모리만 소비합니다.”¹

흐름:¹

let descriptor = MTL4ArgumentTableDescriptor()
descriptor.maxBufferBindCount = ...
descriptor.maxTextureBindCount = ...
let argumentTable = device.makeArgumentTable(descriptor: descriptor)

argumentTable.setResource(buffer, bufferIndex: 0)
argumentTable.setSamplerState(sampler, index: 0)

renderEncoder.setArgumentTable(argumentTable, stages: [.vertex, .fragment])

단일 인수 테이블은 자신이 바인딩하는 리소스가 모두에게 적합하다면 다른 명령 버퍼의 인코더를 포함하여 여러 인코더에 사용될 수 있습니다. Apple의 문서는 다음과 같이 설명합니다. “메모리 및 런타임 절감 효과는 인코더가 공유하는 공통 리소스마다, 그리고 인수 테이블을 새 인코더에 할당할 때마다 누적됩니다.”¹

트레이드오프가 있습니다. 이전 버전의 Metal은 MTLTextureDescriptor.hazardTrackingMode 또는 MTLHeapDescriptor.hazardTrackingMode를 통해 옵트인한 텍스처 및 힙에 대한 해저드 추적을 지원했습니다.¹ Metal 4에서는 “프레임워크가 모든 리소스를 추적되지 않은 것으로 간주합니다. 이러한 파이프라인의 셰이더 중 어느 하나라도 리소스를 수정한다면, 동시에 리소스에 접근할 수 있는 파이프라인 단계를 동기화해야 합니다.”¹ 앱은 이전 단계가 끝날 때까지 단계를 지연시키기 위해 명시적인 배리어를 추가합니다. 이는 예측 가능한 성능과 낮은 런타임 오버헤드를 대가로, 이전의 옵트인 추적보다 더 많은 코드를 요구합니다.

일급 패스로서의 머신러닝

MTL4MachineLearningCommandEncoder는 가장 아키텍처적으로 중요한 추가 사항입니다. Apple의 프레이밍:²

“Metal 4는 Metal 워크플로 내에서 CoreML 모델을 효율적으로 실행하는 기능을 도입합니다. 이는 씬을 렌더링하거나 컴퓨트 디스패치를 실행하는 등 Metal 컨텍스트에서 모델의 출력을 적용해야 하는 앱에 유용합니다.”

두 가지 일이 동시에 일어나고 있습니다. 첫째, ML 추론이 렌더 및 컴퓨트 작업과 동일한 명령 버퍼 안의 GPU 타임라인에서 실행됩니다. 앱은 모델 추론과 그 출력을 사용하는 렌더 패스 사이에 CPU를 거치는 왕복을 하지 않습니다. 둘째, 시스템이 추론 엔진을 선택합니다. “시스템은 각 머신러닝 모델에 대해 디바이스의 GPU 또는 Apple Neural Engine(ANE)과 같은 추론 엔진을 자동으로 선택합니다. 시스템이 ANE에서 모델을 실행하기로 선택하면 GPU는 GPU로 추가적인 독립 렌더 또는 컴퓨트 작업을 실행할 수 있습니다.”²

개발 워크플로:²

1. Xcode 26의 번들 도구에 포함된 metal-package-builder를 사용하여 Core ML 모델을 Metal ML 패키지로 변환합니다.
2. Metal ML 패키지를 Xcode 프로젝트에 추가합니다. Xcode가 빌드 시점에 이를 Metal 라이브러리로 컴파일합니다.
3. 런타임에 앱은 해당 라이브러리에서 MTL4MachineLearningPipelineState를 생성합니다.
4. 인코더는 파이프라인 상태, 스크래치 메모리용 MTLHeap, 그리고 입력과 출력용 MTLTensor 인스턴스를 받습니다.

MTLTensor는 다차원 데이터 배열을 위한 새로운 리소스 타입입니다.² Apple의 문서는 이 타입이 int8 및 fp16 같은 일반적인 ML 가중치 타입과 함께 작동한다고 설명합니다. 텐서는 입력을 모델로 전달하고 출력을 모델 외부로 운반합니다. 추론 호출 사이의 일시적인 데이터의 경우, Metal Shading Language는 GPU에 직접 상주하는 텐서 타입을 추가합니다.²

• tensor_handle: CPU에서 생성된 MTLTensor에 대한 핸들
• tensor_inline: 텐서 또는 버퍼에 대한 뷰로서 GPU에 정의된 텐서
• cooperative_tensor: 자신의 요소를 함께 작업하는 스레드들에 분배하는 텐서

cooperative_tensor 타입은 지연 시간에 민감한 경우입니다. “협력 텐서는 해당 텐서와 함께 작업하는 스레드들 사이에 데이터를 균등하게 분배함으로써 일시적인 텐서를 위한 임시 메모리를 제공합니다. 이러한 메모리 분배는 스레드 전용 또는 스레드그룹 전용 주소 공간에서 메모리를 할당함으로써 메모리 대역폭을 줄이며, 이는 지연 시간이 중요한 머신러닝 알고리즘에 중요합니다.”²

MSL은 또한 셰이더 코드에서 직접 작동하는 텐서 연산자도 도입했습니다. 합성곱, 행렬 곱셈, 축소(reduction)입니다.² 추론 패스 사이에 가중치를 조작해야 하는 앱은 텐서를 CPU 메모리로 다시 복사하거나 별도의 컴퓨트 패스를 실행하지 않고도 그렇게 할 수 있습니다. 연산자가 일반 MSL 커널에 통합됩니다.

인용할 가치가 있는 한 가지 경계가 있습니다. “머신러닝 인코더는 Core ML 모델을 실행하지만, 새로운 네트워크를 빌드하거나 기존 네트워크의 레이어와 입력을 수정할 수는 없습니다. 이러한 작업에 대해서는 Core ML 및 Metal Performance Shaders Graph를 참조하세요.”² Metal 4의 ML 인코더는 추론을 출시하기 위한 것이지, 학습이나 모델 구축을 위한 것이 아닙니다.

Metal 4가 Apple 스택에 의미하는 바

Metal 4 도입을 계획하는 앱 개발자를 위한 세 가지 시사점:

1. 서브시스템별로 점진적으로 도입하세요. 병렬 MTL4 접두사 타입과 기존 API와의 이벤트 기반 상호 운용은 부분 마이그레이션을 위해 설계되었습니다. 명확한 성능 압박이 있는 서브시스템(렌더 경로, 컴퓨트 파이프라인, 모델 추론 루프)을 골라 먼저 마이그레이션하세요.¹
2. 멀티스레드 인코딩이 새로운 표준입니다. 스레드별 할당자 패턴, commit:count: 배치 제출, 일시 중단/재개 렌더 패스 메커니즘은 모두 성능이 좋은 앱이 사용할 형태로서 병렬 인코딩을 가정합니다. 단일 스레드 인코딩도 여전히 작동하지만, 프레임워크의 런타임 이득은 멀티스레드 도입과 함께 누적됩니다.¹
3. ML이 다른 모든 것과 같은 명령 버퍼에서 실행됩니다. 온디바이스 모델 추론과 렌더링 또는 컴퓨트를 결합하는 앱(Core ML 모델을 통해 필터링하는 이미지 처리 파이프라인, 분류기 출력에 의존하는 실시간 효과, 렌더링이 프레임당 추론 결과에 의존하는 AR 경험)에게는, 그 출력을 사용하는 렌더 패스와 동일한 명령 버퍼에 ML 추론을 인코딩할 수 있다는 점이 질적인 변화입니다.²

Metal Shading Language 추가 사항은 별도의 다룸이 필요합니다. 셰이더 코드의 텐서 타입과 연산자, 그리고 사용자 정의 연산을 위한 연산 디스크립터는 Metal 커널이 표현할 수 있는 것을 바꿉니다. 그것은 별도의 게시물입니다.

전체 Apple Ecosystem 클러스터: 이 스택 위에서 실행되는 프레임워크에 대한 Foundation Models 온디바이스 LLM, 개발자 관리 특화를 위한 커스텀 어댑터 라이프사이클, Metal 4가 이제 인라인으로 실행하는 모델의 ML 프레임워크에 대한 Core ML 온디바이스 추론. 허브는 Apple Ecosystem Series에 있습니다.

FAQ

Metal 4는 Metal과 별개의 프레임워크입니까?

아닙니다. 프레임워크는 여전히 Metal입니다. Apple의 문서는 Metal 4를 “Metal 4 코어 API”로 설명합니다. 이는 동일한 프레임워크에서 기존 MTL 타입과 함께 출시되는 MTL4 접두사가 붙은 새로운 타입의 집합입니다.¹ 앱은 런타임에 Metal 4 지원을 감지하고 적절한 큐 타입을 생성함으로써 새로운 타입을 점진적으로 도입합니다.

Metal 4를 사용하려면 iOS 26이 필요합니까?

Metal 프레임워크는 iOS 8 이상을 지원하지만, Metal 4 코어 API는 Apple이 WWDC25에서 도입한 버전입니다. 런타임 감지를 실행하고 디바이스가 지원하는 것에 따라 MTL4CommandQueue 또는 MTLCommandQueue를 생성하세요.¹

Metal 4 ML 패스와 Foundation Models의 관계는 무엇입니까?

서로 다른 스택에서 실행됩니다. MTL4MachineLearningCommandEncoder는 Metal ML 패키지로 변환된 Core ML 모델을 렌더 및 컴퓨트 작업과 동일한 명령 버퍼에서 실행합니다.² Foundation Models는 자체 세션 API로 Apple의 온디바이스 시스템 언어 모델을 실행하는 별개의 프레임워크이며, Foundation Models 온디바이스 LLM 게시물에서 다룹니다. 둘은 보완적입니다. 앱은 텍스트 생성에 Foundation Models를 사용하고 렌더 루프 내부에서 비전 또는 오디오 모델 추론에 Metal 4 ML 패스를 사용할 수 있습니다.

컴퓨트 인코더가 이제 통합된 이유는 무엇입니까?

Apple의 문서는 MTLBlitCommandEncoder, MTLComputeCommandEncoder, MTLAccelerationStructureCommandEncoder를 MTL4ComputeCommandEncoder로 결합합니다.¹ 그 정당화는 성능만이 아닌 운용적 측면입니다. 컴퓨트, 블릿, 가속 구조 작업을 위한 단일 인코더 타입은 파이프라인 관리를 단순화하며 세 가지를 교차하는 앱에서 인코더 변동을 줄입니다.

Metal 4에서 store-action 옵션을 여전히 사용할 수 있습니까?

MTL4RenderCommandEncoder에서는 그렇지 않습니다. Apple의 문서는 다음과 같이 설명합니다. “Store-action 옵션(MTLStoreActionOptions 참조)은 Apple silicon GPU에 적용되지 않으므로 사용할 수 없습니다.”¹ 이 아키텍처 결정은 Metal 4 코어 API에 대한 Apple의 GPU 전용 타깃을 반영합니다.

인수 테이블을 반드시 사용해야 합니까?

Metal 4에서는 그렇습니다. 인코더 프로토콜은 리소스별 바인딩 메서드를 노출하지 않습니다. MTL4ArgumentTable에서 리소스 바인딩을 구성하고 해당 테이블을 하나 이상의 인코더 단계에 할당합니다.¹ 런타임 이점은 모든 인코더에 대한 고정 크기의 단계별 테이블 대신 테이블이 실제로 사용하는 바인딩에 대해서만 메모리를 할당한다는 것입니다.

참고 문헌