- Swift를 OS에 포함시키는 것은 개발자들에게 더 나쁜 상황을 초래했다는 불만이 Swift 포럼에서 제기됨
- 이에 대한 반응으로, OS와 함께 제공되는 라이브러리의 세계에 오신 것을 환영한다는 냉소적인 의견이 있었음
- 이 글은 Apple에서 Swift를 개발할 때의 경험을 바탕으로, Swift가 OS의 일부가 된 배경과 문제점을 설명함
OS 의존성
- 과거에는 개인용 컴퓨터가 실행 중인 프로세스에게 전체 기계를 제어하도록 허용했으나, 현재는 운영 체제 커널이 항상 실행되며 기본 OS 서비스를 제공함
- 대부분의 현대 OS는 시스템 호출 인터페이스를 통해 특정 권한 있는 작업을 요청할 수 있는 프로그램을 생성할 수 있도록 함.
- 오늘날의 Apple OS는 시스템 호출 인터페이스가 OS 버전에 따라 안정적이지 않기 때문에, 기본적인 작업을 수행하기 위해 C/POSIX 표준 라이브러리와 그 확장을 사용해야 함.
Apple의 모델 (Swift 이전)
- Swift 이전에는 Apple의 대부분의 공개 API가 C 또는 Objective-C로 작성되어 네이티브 코드 형태로 제공됨.
- 새로운 OS 버전은 기존 라이브러리의 새로운 바이너리 호환 버전을 포함하여, 이전 버전의 API를 포함하는 상위 집합을 제공함.
- 이 모델의 주된 단점은 새로운 기능과 API가 새로운 OS 버전에 묶여 있다는 것임.
Swift "베타" 1 ~ 5
- Swift 1부터 Swift 5까지 많은 변화가 있었으며, ABI 안정성이 항상 Swift의 목표였음.
- Swift 5로 넘어가면서 대부분의 문제가 해결되었고, Swift가 OS에 포함될 때 기존 앱과 프로젝트가 영향을 받지 않도록 하는 방법을 찾아야 했음.
전환
- Swift를 OS에 포함시키는 과정에서 기존에 구축된 앱과 프로젝트를 깨뜨리지 않는 방법을 찾아야 했음.
- "rpath"라는 기능을 사용하여 실행 가능한 파일이 하드코딩된 경로가 아닌 일련의 디렉토리를 검색하여 동적 라이브러리를 찾을 수 있도록 함.
우리가 잃은 것
- Swift가 OS에 포함되면서 앱은 더 이상 Swift를 포함할 필요가 없게 되었고, Swift와 Objective-C 런타임이 함께 제공되면서 성능 개선이 가능해짐.
- 그러나 외부 Swift 기여자들은 새로운 API가 새로운 OS에서만 존재한다는 문제에 직면함.
대안
- 개발자들에게 더 나은 상황을 제공하기 위해 Apple이 할 수 있는 몇 가지 합리적인 방법들이 있으나, Apple이 이를 수행할지는 불확실함.
결론
- Swift가 OS에 포함되는 것이 앱 개발자들에게 나쁜 거래였을 수도 있지만, Apple은 시스템 라이브러리를 Swift로 작성할 수 있는 옵션을 포기할 수 없었음.
Swift와 관련된 새로운 것은 아님
- Swift와 관련된 많은 문제는 OS와 함께 제공되는 라이브러리의 결과임.
- Swift의 기술적 변화와 사회적 변화 모두가 이러한 문제에 영향을 미침.
GN⁺의 의견
- Swift가 OS의 일부가 되는 것은 개발자들에게 더 큰 제약을 가하는 것이지만, 이는 Apple의 라이브러리 배포 모델의 필연적인 결과임.
- 이 글은 Swift가 OS에 통합되는 과정에서 발생한 기술적, 운영적 도전과 그에 대한 해결책을 탐구함으로써, 소프트웨어 개발의 복잡성과 라이브러리 관리의 중요성을 강조함.
- Swift의 OS 통합은 앱 개발자들에게는 더 큰 파일 크기와 호환성 문제를 가져왔지만, Apple에게는 시스템 라이브러리를 Swift로 작성하고 업데이트하는 능력을 제공함으로써, 전체 시스템의 일관성과 보안을 유지하는 데 도움이 됨.