질문에 대한 답변
스위프트의 동시성 모델은 6.0 버전에서 상당한 강화가 이루어졌으며, 모듈 경계를 넘는 엄격한 데이터 격리 요구조건이 도입되었습니다. 엄격한 동시성 검사가 컴파일된 모듈이 @preconcurrency로 표시된 레거시 모듈에 호출할 때, 컴파일러는 호출되는 구현이 액터 격리 보장을 선행할 수 있으므로 정적 분석만으로 안전성을 보장할 수 없습니다. 이 격차를 해소하기 위해, 스위프트는 함수의 타입 정보 및 위스니스 테이블 내에 격리 요구사항을 메타데이터로 포함시켜 호출 규칙이나 심볼 변형을 변경하지 않고 ABI 안정성을 유지합니다. 런타임에 생성된 코드는 swift_task_isCurrentExecutor 내장 함수를 사용하여 현재 작업이 필요한 글로벌 액터의 직렬 실행기에서 실행되고 있는지 확인하는 동적 검사를 수행합니다; 검사가 실패하면 작업은 올바른 실행기로 비동기적으로 대기열에 추가되거나 빌드 구성에 따라 진단 충돌이 발생합니다.
생활 속 상황
금융 기술 팀은 UI 업데이트를 완료 처리기로 게시하는 경우가 있는 백그라운드 스레드에서 무거운 통계 계산을 수행하는 스위프트 5.9로 작성된 레거시 분석 SDK (모듈 B)를 유지했습니다. 그들이 새로운 소비자 뱅킹 앱 (모듈 A)에서 스위프트 6을 채택하면서 모든 UI 업데이트가 MainActor에서 발생하도록 보장해야 했습니다. 이를 위해 전체 SDK를 즉시 재작성하지 않고도 격리 경계 문제를 해결할 세 가지 접근 방식을 고려했습니다.
첫 번째 옵션은 SDK를 스위프트 6 액터 및 Sendable 타입으로 채택하기 위해 동기적으로 재작성하는 것이었습니다. 이는 컴파일 타임 안전성을 제공하고 실행 시간 오버헤드가 없지만, 공학적 비용이 너무 비쌌고—예상 소요 시간은 3개월—중요한 계산 논리에서 높은 회귀 위험을 초래했습니다. 두 번째 옵션은 모듈 A의 호출 지점에서 SDK의 모든 콜백을 DispatchQueue.main.async로 수동으로 랩핑하는 것이었습니다. 이 접근법은 명시적이었고 SDK 변경이 필요하지 않았지만, 쉽게 놓칠 수 있는 부서진 분산 보일러플레이트를 생성하여 새로운 개발자가 기능을 추가할 때 데이터 경합이 발생할 수 있었습니다. 세 번째 옵션은 SDK의 공개 인터페이스에 @preconcurrency 주석을 추가하고 MainActor 격리 요구사항을 결합하는 것이었습니다.
팀은 세 번째 솔루션을 선택하여 레거시 콜백에 @preconcurrency @MainActor를 주석 처리했습니다. 이를 통해 모듈 A는 이러한 메서드를 호출하면서 스위프트 런타임이 전환 기간 중 실행기 컨텍스트를 동적으로 확인할 것이라는 보장을 가질 수 있었습니다. 배경 스레드가 UI 콜백을 호출하려고 할 때와 같이 위반 사항이 발생하면, 앱은 디버그 빌드에서 즉시 충돌하며 개발자가 스레딩 가정을 점진적으로 식별하고 수정할 수 있도록 명확한 진단을 제공합니다. SDK가 엄격한 동시성으로 완전히 마이그레이션되면, @preconcurrency를 제거하여 정적 격리를 전적으로 시행하였고, 런타임 격리 검사가 없는 코드베이스와 보장된 스레드 안전성을 확보했습니다.
후보자들이 자주 놓치는 점
@preconcurrency가 함수의 ABI에서 변형된 심볼 이름에 어떤 영향을 미치며, 동적 링크에 왜 이것이 중요한가요?
@preconcurrency는 격리 요구 사항이 심볼 자체가 아닌 타입 메타데이터와 위스니스 테이블에 인코딩되기 때문에 함수의 변형된 심볼 이름이나 낮은 수준의 호출 규약을 변경하지 않습니다. 이 설계는 ABI 안정성에 매우 중요하여, 라이브러리 작성자가 기존 공개 API에 액터 격리를 추가하면서도 이전에 컴파일된 클라이언트와 이진 호환성을 깨지 않도록 합니다. 동적 검사는 메타데이터에 기반하여 컴파일러에 의해 호출 지점이나 진입점에 삽입되어 이전 이진 파일이 새롭고 격리 인식 라이브러리를 원활하게 링크할 수 있도록 합니다.
글로벌 액터의 shared 인스턴스를 let으로 선언할 때와 var로 선언할 때의 차이는 무엇이며, 이것이 실행기의 독창성에 어떤 영향을 미칩니까?
GlobalActor 프로토콜은 기본 액터 인스턴스를 반환하는 정적 shared 속성을 요구하며, 이 속성은 단일 프로세스 전역에서 독창적인 직렬 실행기를 보장하기 위해 let 상수로 선언되어야 합니다. 만약 shared가 var라면 이론적으로 런타임에 실행기를 교체할 수 있어 글로벌 액터가 모든 격리 작업을 위한 단일 직렬 큐를 제공한다는 근본적인 불변 조건을 위반하게 됩니다. 이는 데이터 경합을 유발하고 격리 경계를 깨뜨릴 수 있습니다. 스위프트 컴파일러는 shared가 정적 불변 속성이 되도록 요구하여 swift_task_isCurrentExecutor가 항상 일관된 단일 실행기 객체와 비교하도록 보장합니다.
함수가 글로벌 액터에 격리될 때, 컴파일러가 같은 액터 내에서 호출되더라도 실행기로의 이동을 생성하는 이유는 무엇이며, isolated 매개변수 수식어가 어떻게 이를 최적화합니까?
컴파일러는 호출자가 대상 글로벌 액터의 실행기에서 이미 실행되고 있다는 것을 정적으로 증명할 수 없는 경우, 일반적으로 모듈 경계를 넘거나 격리 정보가 삭제된 존재론적 타입을 통해 호출될 때 실행기로의 이동 또는 최소한 런타임 검증을 처리합니다. 이러한 보수적인 접근은 안전성을 보장하지만 동기화 오버헤드를 발생시킵니다. 개발자는 호출자의 격리 컨텍스트를 인수로 명시적으로 전달하는 isolated 매개변수 수식어(예: func process(isolation: isolated MainActor = #isolation)를 사용하여 이를 최적화할 수 있습니다. 이를 통해 컴파일러는 호출자가 같은 실행기에 위치하고 있다고 증명할 경우 런타임 검사를 생략할 수 있으며, 실행 간 전환 비용이 없는 직접 함수 호출로 줄일 수 있습니다.