스위프트는 탄력적인 구조체의 ABI 안정성을 유지하기 위해, 런타임 메타데이터에 필드 오프셋을 저장하고 이를 클라이언트 바이너리에 하드코딩된 즉시 오프셋 값으로 사용하지 않습니다. 모듈이 비얼어지지 않은 구조체를 내보낼 때, 컴파일러는 타입 메타데이터 내에 포함된 필드 오프셋 테이블을 통해 저장된 프로퍼티에 접근하는 코드를 생성합니다. 이러한 간접 접근은 라이브러리 저자가 기존 바이너리를 무효화하지 않고 향후 버전에서 새로운 저장된 프로퍼티를 추가할 수 있게 해줍니다. 반면, @frozen 구조체는 직접 오프셋 계산을 사용하여 더 빠른 메모리 접근이 가능하지만 레이아웃이 영구적으로 고정됩니다. 이로 인해 즉시 주소 지정에 비해 추가 메모리 로드로 인한 약간의 성능 손실이 발생합니다.
핵심 분석 SDK를 설계하여 수백 개의 클라이언트 애플리케이션에 배포한다고 상상해 보세요. 이 SDK는 처음에 apiKey와 environment라는 두 개의 필드를 가진 Config 구조체를 정의합니다. 출시 후 6개월이 지나 제품 요구 사항에 따라 이 구조체에 retryPolicy 및 timeoutInterval 필드를 추가해야 합니다.
// AnalyticsSDK (모듈 A) - 처음 컴파일됨 public struct Config { public let apiKey: String public let environment: String // 새로운 필드가 v2.0에 추가됨 (@frozen 없이): // public let retryPolicy: RetryPolicy }
구조체가 @frozen이라면, 이 변경은 기존 클라이언트 앱을 충돌시킵니다. 왜냐하면 이들은 컴파일 중 구조체의 크기와 필드 오프셋을 하드코딩했기 때문입니다. 우리는 이 진화 문제를 해결하기 위해 세 가지 접근 방식을 고려했습니다. 첫 번째 접근 방식은 구조체를 클래스로 변환하여 힙 할당과 포인터 안정성을 활용하는 것이었고, 이로써 ABI 호환성을 유지했지만 바람직하지 않은 참조 카운팅 오버헤드와 값 유형 불변성 보장을 깨는 참조 의미론이 도입되었습니다. 두 번째 접근 방식은 원래 구조체를 deprecated하고 병행 ConfigV2 구조체를 배포하는 것이었고, 이는 호환성을 유지했지만 API 표면을 분열시키고 개발자들에게 명시적인 마이그레이션을 강요했습니다. 세 번째 접근 방식은 @frozen 속성을 제거하여 탄력적인 구조체를 채택했고, 이는 컴파일러가 메타데이터 조회를 통해 간접 필드 접근을 생성하도록 허용했습니다.
우리는 성능과 미래의 유연성 간의 균형을 이룬 세 번째 해결책을 선택했습니다. 클라이언트 바이너리는 SDK의 메타데이터에서 런타임에 필드 오프셋을 동적으로 쿼리하여 재컴파일 없이 계속 작동했습니다. 그 결과, SDK 버전 간의 구성 구조의 원활한 발전이 이루어졌지만, 자주 접근되는 구성 필드는 성능 비용을 줄이기 위해 로컬로 캐시할 것을 문서화했습니다.
스위프트는 클라이언트 코드가 정의된 모듈을 가져올 때 탄력적인 구조체의 크기와 정렬을 어떻게 결정하나요?
탄력적인 구조체에 대해 컴파일할 때, 스위프트는 나중에 새로운 필드가 추가될 수 있기 때문에 정적으로 구체적인 크기나 정렬을 알 수 없습니다. 대신, 컴파일러는 런타임에 타입 메타데이터와 연관된 값 증명 테이블(VWT)에 문의하는 코드를 생성합니다. VWT는 크기, 정렬, 보폭 및 파괴를 위한 함수를 제공하여 클라이언트가 사전 지식 없이 올바른 양의 스택 공간 또는 힙 메모리를 할당할 수 있도록 합니다.
왜 탄력적인 열거형을 스위치 할 때 @unknown default 절이 필요하며, 새로운 케이스가 추가될 때 내부적으로 무엇이 발생하나요?
탄력적인 열거형은 가져오는 모듈에 전체 케이스 목록을 노출하지 않아, 기본 절 없이 철저한 스위칭을 방지합니다. 라이브러리 저자가 새로운 케이스를 추가하면, 열거형의 메타데이터가 새로운 태그 값을 포함하도록 업데이트됩니다. @unknown default로 컴파일된 클라이언트 코드는 런타임에 이 알 수 없는 태그를 처리할 수 있으며, 기본 브랜치로 넘어갑니다. 반면, 고정된 열거형은 스위치 문이 대체 방법 없이 점프 테이블로 컴파일되기 때문에 인식되지 않은 태그에서 오류가 발생합니다.
모듈 경계를 넘는 @inlinable 속성은 어떤 특정 최적화를 제공하며, 왜 이것이 탄력성을 깨뜨리나요?
@inlinable은 함수 또는 메서드의 본문을 가져오는 모듈의 컴파일러에 노출하여 모듈 간 인라인화 및 죽은 코드 제거를 가능하게 합니다. 이는 클라이언트 컴파일러가 구현 세부사항을 클라이언트 바이너리에 직접 포함하게 되어, 구현이 나중에 변경될 경우 클라이언트가 구 인라인 코드를 계속 사용하게 되어 세밀한 행동 차이나 충돌을 유발할 수 있기 때문에 탄력성을 깨뜨립니다.