Swift 프로토콜이 연관 타입(PATs)이나 Self 요구사항을 가지고 있을 때, 이들은 1급 존재 타입(예: [MyProtocol])으로 작동할 수 없는데, 이는 컴파일러가 컴파일 타임에 연관 타입에 대한 증인 테이블을 구성하는 데 필요한 구체적인 타입 메타데이터를 가지고 있지 않기 때문입니다. 이 제한으로 인해 이질적 컬렉션은 인스턴스를 직접 저장할 수 없으며, 연관 타입의 메모리 레이아웃이 일치하는 타입 간에 다르기 때문에 발생합니다. 개발자들은 타입 지우기 패턴을 통해 이 제약을 해결하며, 프로토콜 증인 테이블이나 클로저 기반 디스패치를 활용하여 인터페이스 접근을 통일화하면서 기저의 연관 타입 복잡성을 캡슐화하는 박싱 래퍼를 구현합니다.
크로스 플랫폼 미디어 엔진을 설계하는 동안, 우리 팀은 MP3, AAC 및 FLAC와 같은 다양한 오디오 코덱을 관리할 수 있는 PlaylistController가 필요했습니다. 각 코덱은 디코딩된 오디오 샘플을 나타내는 연관 Buffer 타입을 가진 Playable 프로토콜을 구현했습니다. 연관 Buffer는 형식에 따라 크게 달랐으며, 압축되지 않은 PCM 데이터는 FLAC를 위한 반면, MP3에는 압축된 패킷을 사용했습니다. 이로 인해 비호환적인 메모리 레이아웃이 발생하여 표준 다형성 저장 방식이 불가능했습니다.
한 가지 접근 방식은 Playlist<T: Playable>를 통한 제네릭 특수화로, 전체 컬렉션을 단일 구체적인 타입으로 제한했습니다. 이는 런타임 디스패치 오버헤드를 제거하고 인라인 같은 공격적인 컴파일러 최적화를 가능하게 합니다. 그러나 이 접근 방식은 다형성을 완전히 포기하여 사용자가 동일한 재생 목록 구조 내에서 MP3와 FLAC 트랙을 혼합할 수 없게 만듭니다.
대안으로, 개발자들은 최신 Swift에서 사용할 수 있는 [any Playable] 구문을 통한 Swift의 기본 존재 컨테이너를 활용할 수 있습니다. 이것은 이질적 저장을 지원하지만, 연관 Buffer 타입에 접근하려면 매 호출 시 존재를 수동으로 열어야 하므로 장황한 보일러플레이트가 발생하며, 대형 값 타입의 경우 힙 할당을 강제합니다. 또한 구체적인 타입 정보의 손실로 인해 컴파일러는 메서드 호출을 비가상화할 수 없고, 이는 밀접한 오디오 처리 루프에서 측정 가능한 오버헤드를 도입합니다.
최적의 해결책은 클로저 기반 증인 테이블을 활용하여 play() 및 stop() 메서드를 위임하는 AnyPlayable이라는 수동 타입 지우기 박스를 구현하는 것입니다. 이 래퍼는 구체적인 인스턴스를 클래스 기반 컨테이너나 존재 버퍼에 저장하여 연관 타입의 복잡성을 숨기고 일관된 인터페이스를 노출합니다. 비록 이것이 가상 디스패치와 유사한 간접 오버헤드를 도입하지만, 버퍼 구현 차이를 성공적으로 추상화하고, 런타임 캐스팅 복잡성 없이 진정한 이질적 컬렉션을 지원합니다.
우리는 미디어 애플리케이션이 본질적으로 통합된 재생 목록 내에서 다양한 코덱을 혼합할 필요가 있기 때문에 타입 지우기 래퍼 접근 방식을 선택했으며, 가상 디스패치의 오버헤드는 오디오 스트리밍의 I/O 지연에 비해 미미합니다. 이 구현은 표준 코덱과 함께 독점적인 DRM 형식을 원활하게 통합할 수 있게 해주었으며, Controller의 아키텍처를 수정하지 않고도 가능했습니다. 궁극적으로, 이는 트랙 초기화 동안 컴파일 타임 타입 안전성을 유지하면서도 사용자 작성 콘텐츠 라이브러리에 필수적인 런타임 유연성을 제공했습니다.
질문 1: 연관 타입이 포함된 경우, as! any Playable을 간단히 사용하여 구체적인 타입을 존재로 캐스팅할 수 없는 이유는 무엇인가?
Swift는 연관 타입이 있는 프로토콜을 맨 얼굴 존재로 사용하는 것을 금지합니다. 이는 존재 컨테이너가 고정 크기 인라인 저장소(일반적으로 3개의 단어)를 요구하는 반면, 연관 타입은 임의로 큰 메모리 발자국을 요구할 수 있기 때문입니다. Buffer 연관 타입이 FLAC의 512바이트 디코딩된 프레임을 나타내지만, MP3의 경우 4바이트 패킷 인덱스를 나타낼 때, 존재는 컴파일 타임에 구체적인 타입을 알지 않고는 인라인으로 둘 다 수용할 수 없습니다. 결과적으로, 컴파일러는 메모리 안전성을 보장하고 스택 손상 또는 버퍼 오버플로우로 인한 런타임 충돌을 방지하기 위해 타입 지우기 또는 제네릭 제약을 강제합니다.
질문 2: Swift 5.1의 불투명 결과 타입(some Collection)은 성능 및 API 발전 측면에서 타입 지우기 박스와 어떻게 다른가?
불투명 결과 타입은 역제네릭 및 컴파일 타임 특수화를 활용하여, 컴파일러가 구현 세부 정보를 호출자에게 숨기면서 완전한 구체적 타입 정보를 유지할 수 있도록 합니다. 이는 수동 타입 지우기 박스에 고유한 가상 디스패치 벌금 및 힙 할당 비용을 피합니다. 하지만 불투명 타입은 반환 지점에서 기본 타입이 고정되어 있어야 하며(SE-0368 다수의 불투명 결과 제외), 반면 타입 지우기 박스는 런타임 중 동일한 컨테이너 내에서 구체적 타입의 동적 변형을 허용하여 성능과 다형성 유연성 간의 거래를 합니다.
질문 3: 타입 지우기 박스가 자기 참조 프로토콜(예: Self를 반환하는 메서드를 가진 프로토콜)을 캡처할 때 어떤 메모리 관리 위험이 나타나는가?
타입 지우기 박스는 종종 구체적 인스턴스를 저장하기 위해 클래스 기반 래퍼 또는 클로저 캡처를 사용합니다. 프로토콜이 Self를 반환하게 요구하거나 Self를 참조하는 연관 타입을 사용할 경우, 박스는 참조 의미론을 통해 타입 정체성을 보존해야 하며, 이는 구체적 타입이 박스에 대한 역참조를 보유할 경우 잠재적인 유지 주기 문제가 발생할 수 있습니다. 동시에 여러 스레드가 박스 상태를 변형할 경우 레이스 조건이 발생할 수 있습니다. 개발자들은 박스가 Sendable에 제대로 준수하도록 해야 하며, 일반적으로 Actor 격리 또는 불변 값 의미론을 구현하여 데이터 레이스를 방지하고 지워진 인터페이스 추상을 유지해야 합니다.