WWDC26 랩에서 Apple Swift 팀이 한 이야기

Apple은 WWDC26 Swift Group Lab을 Swift, Foundation, 서버 네트워킹 팀의 엔지니어 4명이 진행한 한 시간 분량의 대본 없는 Q&A로 공개했고, 그것을 자막 없이 내놓았습니다.¹ 저는 그들이 실제로 무슨 말을 했는지 읽어 보려고 이 영상을 로컬 받아쓰기 과정에 돌려 봤습니다. 잘 다듬어진 세션은 기능이 무엇을 하는지를 알려 줍니다. 반면 랩은 Holly가 핵심적인 동시성 설계 결정에 대해 자신이 틀렸음을 인정하는 자리이고, Corey가 취소된 코드 안에서 조용히 실패하는 정리(cleanup) 패턴을 설명하는 자리이며, 패널이 마케팅에서는 결코 하지 않을 조언 하나를 거듭 반복하는 자리입니다. 그 조언은 바로 “언어 기능을 모으지 마라”입니다. 솔직한 버전은 바로 여기에 있습니다.

출처에 대한 메모: Apple은 이 랩의 공식 트랜스크립트를 공개하지 않았습니다. 아래의 모든 인용은 공개된 영상을 로컬에서 받아쓰기한 것에서 옮긴 의역이며, 타임스탬프는 대략적인 값입니다. 발표자는 트랜스크립트가 알려 주는 대로 이름과 팀으로 표시합니다. Holly(Swift 언어 팀, 제네릭과 동시성), Corey(Swift 서버 네트워킹 팀), Tony(Foundation 및 표준 라이브러리), Doug(Swift 언어 팀).¹

TL;DR

• Holly는 만약 팀이 오늘 Swift 동시성을 설계한다면 nonisolated async 함수가 처음부터 호출자의 컨텍스트에서 실행되도록 했을 것이라고 말했습니다. 그녀는 “아주 오랫동안” 그 반대의 믿음을 갖고 있었지만, 실제 현장의 증거를 보고 생각을 바꿨습니다. Swift 6.2는 호출자 컨텍스트를 기본값으로 삼는 동작을 표준으로 만들었습니다.¹
• 거듭 강조된 지침은 타입을 의도적으로 비Sendable로 만들라는 것입니다. ~Sendable(SE-0518, Swift 6.4에서 구현)은 더 깔끔한 표기법을 제공하고, Foundation은 그동안 손대지 않기로 표시했던 타입들에 다시 어노테이션을 붙이고 있으며, UserDefaults의 전역 인스턴스는 Sendable 준수를 얻을 전망입니다.²¹
• Corey의 비동기 정리 패턴: 취소된 컨텍스트는 비동기 정리를 조용히 건너뛰므로, 모든 async defer에서 일시 중단되는 await 호출을 점검해 취소 실드(cancellation shield)로 감싸야 합니다. SE-0493(async defer)과 SE-0504(withTaskCancellationShield)는 모두 Swift 6.4에서 들어옵니다.³⁴
• 로드맵에 대한 솔직함: Disconnected 타입은 포럼에서 진행 중인 제안이고, 튜플 준수는 “거의 다 됐지만” 형식상으로는 다시 수정 단계로 돌아갔으며, UniqueArray는 원칙적으로 승인됐고, Subprocess 1.0은 출시 예정이며, SwiftPM은 Swift Build로 통합되고 있습니다.⁵⁶⁷⁸
• 패널에서 거듭 등장한 주제: “언어 기능은 수집품이 아니다.” 먼저 프로파일링하고, 프로파일러가 가리키는 좁은 도구만 채택하며, 나머지는 그대로 두라는 것입니다.¹

Apple이 다르게 설계할 동시성 결정

Holly의 동시성 회고는 대략 33:42 부근에서 시작됩니다. 이 랩에는 공식 자막이 없으며, 아래 트랜스크립트는 로컬 ASR(자동 음성 인식) 결과입니다.

한 개발자가 잘 다듬어진 세션에서는 좀처럼 청하지 않는 질문을 패널에게 던졌습니다. Swift 6 동시성이 현장에서 충분히 오래 쓰여 그 도입 과정을 지켜볼 수 있게 된 지금, 팀이 오늘이라면 다르게 설계할 만한 것이 있느냐는 것이었습니다. Holly는 에두르지 않고 답했습니다. 네, 분명히 있습니다.

구체적인 아쉬움은 nonisolated async 함수가 어디에서 실행되는가에 있습니다. 두 건의 Swift Evolution 제안이 이 동작을 정반대 방향으로 움직였습니다. 첫 번째 제안은 nonisolated async 함수를 항상 전역 동시 스레드 풀로 넘기도록 만들었습니다. 나중의 제안, 즉 Swift 6.2의 제안은 그 함수가 자신을 호출한 컨텍스트에 머무르도록 만들어, 메인 액터에서 호출된 함수는 메인 액터에 머무릅니다.¹ Holly는 이 방향 전환의 계기를, 초기 동시성 검사 플래그를 실제 앱과 라이브러리에서 돌려 본 사람들에게서 나온 증거로 거슬러 올라가 설명했습니다. 그들은 비Sendable 타입을 액터로 격리된 컨텍스트와 이 nonisolated async 함수들 사이에서 주고받고 있었고, 전역 풀을 기본값으로 삼는 동작은 데이터 경쟁 오류를 낳았습니다. async 함수가 다른 곳에서 실행되는 동안 원래의 액터가 여전히 그 값들을 붙들고 있었기 때문입니다.¹

그리고 어떤 세션 녹화에도 나오지 않는 부분이 바로 여기에 있습니다. “전역 동시 스레드 풀에서 실행하는 것이 장기적인 이점을 위한 올바른 모델이라는 믿음을 저는 아주 오랫동안 지켜 왔습니다. 하지만 실제 프로젝트에서 벌어진 문제들 때문에 시간이 지나며 생각을 바꾸게 됐습니다”라고 Holly는 말했습니다(ASR 의역, 약 35:50).¹ Doug는 애초의 결정을 시스템 전체를 내다본, 변호할 만한 베팅으로 자리매김했습니다. 사용 가능한 동시성이 늘면 잠재적 병렬성도 늘고, 그것이 더 나은 성능으로 이어질 수 있다는 것입니다. 그 대가는 사람들이 완전한 안전 모델을 쓰기 시작한 뒤에야 비로소 드러났고, 너무 많은 타입을 Sendable 쪽으로 떠밀었습니다. Doug는 그것을 두고 “이 모든 개념을 표현하는 자연스러운 방식이 아니다”라고 표현했습니다.¹ 호출자 컨텍스트를 기본값으로 삼는 쪽이 더 다가가기 쉬운 이유는, 병렬성을 명시적으로 선택하기 전까지는 비동시 코드처럼 동작하기 때문입니다. Swift 6.2를 도입하고 나서 어째서 갑자기 동시성 이야기가 한결 차분하게 느껴졌는지 궁금했다면, 그 답은 그것을 설계한 사람들이 첫 기본값이 잘못이었음을 인정하고 그 수정을 내놓았다는 데 있습니다.

타입을 의도적으로 비Sendable로 만들라

이 랩에서 가장 직관에 반하는 조언은 2년에 걸친 마이그레이션 습관에 정면으로 맞섭니다. Holly는 자신의 타입을 Sendable로 만드는 방법을 묻는 개발자들을 끊임없이 만난다고 말하면서, 더 나은 질문은 흔히 그 반대라고 했습니다. 이 타입은 비Sendable이어야 하는 것 아닐까?¹ 하나의 계산 안에서만 쓰이는 일시적인 타입이라면, 명시적으로 비Sendable이라고 표시함으로써 더 깔끔한 데이터 모델을 얻고, 격리 경계를 넘겨 전달할 의도가 있는 것과 그렇지 않은 것 사이의 경계가 더 또렷해집니다. 그것은 성능에도 도움이 됩니다. 타입을 넘기는 비용은, 애초에 이동할 필요가 없던 중간 값에 대해서는 치르지 않고 싶은 비용이기 때문입니다.¹

Swift 6.4는 이 의도에 실제 표기법을 부여합니다. ~Sendable(SE-0518)을 쓰면, 사용 불가 준수를 작성하는 대신, 마치 ~Copyable이 복사 가능성을 억제하듯 준수를 곧바로 억제할 수 있습니다.² Holly는 그 차이를 정확하게 짚었습니다. 사용 불가 Sendable 준수는 해당 타입과 모든 하위 클래스가 분명히 sendable이 아니라고 선언하고, 그것을 계층 전체로 전파합니다. 반면 ~Sendable은 단지 준수가 없다는 뜻일 뿐이므로, 가변 상태를 전혀 추가하지 않는 하위 클래스는 여전히 자신의 Sendable 준수를 직접 추가할 수 있습니다.²¹

바로 그 유연성이 Foundation에 필요했던 것입니다. Tony는 Foundation의 초기 Sendable 감사에서 나온 세 번째 범주를 설명했습니다. 상위 클래스는 안전하지만 하위 클래스는 그렇지 않을 수 있는 클래스들입니다. 그의 예시는 NSString이었는데, 이는 불변이고 sendable인 반면, NSMutableString은 가변 하위 클래스로 sendable이 아닙니다.¹ Foundation은 잘못된 어노테이션을 서둘러 붙이는 대신, 모호한 클래스들을 비Sendable로 표시해 두고 기다렸습니다. 이제 팀은 Swift 6.4 어노테이션을 사용해 그 타입들을 정확하게 다시 어노테이션하고 있는 중이며, 표준 전역 UserDefaults가 Sendable 준수를 얻을 것으로 예상한다고 Tony는 랩에서 말했습니다.¹ UserDefaults 준수와 더 넓은 범위의 Foundation 재어노테이션은 랩에서 나온 정보로 받아들이기 바랍니다. Tony가 Q&A에서 둘 다 언급했지만, 이것들은 공개된 제안에서 제가 독립적으로 확인할 수 있는 기능이 아닙니다. 패널의 평소 경고도 여기에 그대로 적용됩니다. Tony의 말처럼, Swift 6 모드를 억지로 통과시키려고 @unchecked Sendable에 손을 뻗어서는 안 됩니다. unchecked 어노테이션은 하나하나가 컴파일러가 증명해 줄 수 있었던 안전성을 모두 내버리기 때문입니다.¹

비동기 정리, 실제로 실행되도록 하기

Corey는 이 랩에서 가장 실용적인 교정을 맡고 있는데, 그것은 알아채지 못한 채 출시해 버리는 부류의 버그입니다. 구조적 동시성의 대표적 성과는 취소의 자동 전파입니다. 어떤 작업을 취소하면 그 작업을 위해 생성된 모든 것이 함께 취소됩니다. 뷰가 닫히거나 클라이언트가 연결을 끊었을 때 바로 그렇게 되기를 바라는 동작입니다.¹ 함정은 정리에 도사리고 있습니다. 절반쯤 쓰인 파일을 정상 상태로 플러시해야 할 수도 있고, 데이터베이스 트랜잭션을 롤백해야 할 수도 있는데, 그 정리 자체가 비동기입니다. Corey의 표현을 빌리면, 대부분의 Swift 코드는 취소된 컨텍스트에서 실행되기를 거부합니다. 가능한 한 빨리 풀려나야 한다고 가정하기 때문입니다. 그래서 취소된 작업 안에서 실행되는 비동기 정리는 제 역할을 조용히 못 해낼 수 있습니다.¹

그 해법이 바로 취소 실드이며, 이는 비동기 defer와 곧바로 짝을 이룹니다. SE-0493은 defer 블록이 await 호출을 담을 수 있게 해 주며, Swift 6.4에서 들어옵니다.³ SE-0504는 withTaskCancellationShield를 추가하는데, 이 또한 Swift 6.4이며, 취소가 요청되지 않은 것처럼 블록을 실행해 일시 중단되는 정리가 끝까지 완료되도록 합니다.⁴ Corey의 점검 레시피는 구체적입니다. 각 async defer 블록을 보고 그 안의 await가 실제로 일시 중단될지 물으라는 것입니다. 만약 일시 중단되는 것이 있다면, 그것을 취소 실드로 감싸십시오.¹ 그는 이 둘을 “훌륭한 동반자”이자 “리소스를 깔끔하게 정리하기 위한 정말 멋진 원투 펀치”라고 불렀습니다.¹ 비Sendable 타입은 같은 규율을 강화한다고 Corey는 지적했습니다. 동시성 도메인을 넘을 수 없는 값은 비동기 제어 흐름을 선형적이고 추론하기 쉬운 상태로 유지하도록 강제하기 때문입니다.¹

Corey의 구조적 동시성에 관한 더 넓은 조언이 이 절을 마무리합니다. 단호하게 적극 활용하라, 문제를 일으키는 건 탈출구이기 때문이다. 의도적으로 작업을 다른 곳으로 보내는 경우가 아니라면, 구조화되지 않은 작업(Task.detached나 맨 Task)은 “거의 어떤 대가를 치르더라도” 피하고, 메인 흐름에서는 절대 쓰지 마십시오. 작업 그룹(task group)을 기본으로 삼고, 객체의 수명을 그 어휘적 범위(lexical scope)에 맞추며, 선형적인 비동기 코드를 작성하십시오. 단계 A, 그다음 B, 그다음 C라는 레시피로, 병렬성에 손을 뻗는 것은 작업이 정말로 갈라질 때 작업 그룹 안에서만 하십시오.¹

로드맵에 대한 솔직함

이 랩은 또한 패널이 출시된 기능과 낙관적인 기능을 갈라놓는 자리이기도 하며, 무엇을 토대로 구축할지 결정할 때 그 격차가 중요해집니다.

전달된 비Sendable 값을 저장하는 문제에는 실질적인 답이 다가오고 있습니다. 오늘날에는 sending 키워드로 전달하고, 영역 기반(region-based) 격리 덕분에 컴파일러가 원래 소유자가 접근 권한을 놓았음을 증명할 수 있지만, 그런 값을 저장해야 한다면 작동하는 것은 안전하지 않은 옵트아웃뿐입니다.¹ Holly는 Disconnected를 가리켰습니다. 이는 저장을 거쳐서도 전달 속성을 보존해 값을 잠시 넣어 두었다가 나중에 넘겨줄 수 있게 하는 타입을 위한, 포럼에서 진행 중인 제안입니다. 지금 막 설계되고 논의되는 중이며, 아직 구현되지 않았습니다.⁵¹

튜플 준수는 형식상의 지위에 맞선 엔지니어의 낙관을 보여 주는 가장 또렷한 예입니다. 튜플이 Equatable, Hashable, Comparable에 조건부로 준수하기까지 무엇이 남았느냐는 질문에, Holly는 그것이 파라미터 팩(parameter pack)의 발전형이라고 설명했습니다. 요소 타입이 파라미터 팩인 튜플에 대한 확장을, 각 요소가 준수할 것을 요구하는 where 절과 함께 작성할 수 있는 문법이 언어에 필요하다는 것입니다.¹ 그녀는 실험적 구현이 컴파일러 저장소에 존재하며 “거의 끝까지 다 왔다”고 말했습니다.¹ 형식상의 기록은 더 신중합니다. 튜플 준수의 원래 제안인 SE-0283은 수정을 위해 반려됐고 그 2020년 구현은 되돌려졌습니다. 일반적인 파라미터 팩 방식은 오늘날 실험적 TupleConformances 컴파일러 플래그 뒤에만 존재합니다.¹⁰ Holly의 “거의 다 왔다”는 출시된 기능이 아니라 구현에 대한 엔지니어의 솔직한 판단으로 읽어야 합니다.

성능용 컨테이너는 더 멀리까지 와 있습니다. Tony가 언급한 UniqueArray는 SE-0527(“RigidArray and UniqueArray”, 현재 원칙적으로 승인됨)에서 나온 것으로, 표준 라이브러리에 새로운 Containers 모듈을 도입하며, 이미 swift-collections 1.3에 초기 형태로 들어 있습니다.⁷ Tony는 이것을, 카피온라이트(copy-on-write)의 retain/release 트래픽이 Instruments 추적에 드러나는 Array의 업그레이드판으로 자리매김했습니다.¹ Tony가 자신이 가장 좋아한다고 꼽은, 크로스 플랫폼 오픈 소스 프로세스 API인 Subprocess는 올해 버전 1.0을 출시합니다. 1.0 마일스톤은 발표됐지만 최신 공개 태그는 여전히 0.5에 머물러 있으므로, 출시된 것이 아니라 출시되는 단계입니다.⁶¹ 도구 쪽에서, Holly는 개발자가 알아채지 못할 수도 있는 SwiftPM의 변화를 설명했습니다. Xcode의 패키지 빌드와 오픈 소스 툴체인의 빌드가 이제 하나의 구현, 즉 Swift Build를 공유하게 됐으며, 그것이 기본 빌드 시스템 백엔드가 되고 있습니다(main에서는 기본값, 6.4 목표).⁸¹

마지막으로, Holly가 앞세운 마이그레이션 경로입니다. @diagnose는 SE-0522(“Source-Level Control Over Compiler Warnings”, 승인됨)에서 나온 새 어트리뷰트입니다.⁹ 이는 경고를 소스 수준에서 제어할 수 있게 해 주어, 한 영역에서는 지원 중단 경고를 억제하거나, 엄격한 메모리 안전성이나 엄격한 동시성처럼 기본적으로 꺼져 있는 경고를 가장 중요한 영역에서 옵트인할 수 있습니다. 이로써 단계적인 Swift 6 마이그레이션을 위한 더 세밀한 도구가 됩니다.¹

모아 본 엔지니어의 지침

이 랩의 가치는, 세션의 러닝 타임에는 결코 담기지 않는, 차곡차곡 쌓인 실무자의 조언에 있습니다. 핵심을 출처와 함께 정리하면 다음과 같습니다.

• 선형적인 비동기 코드를 작성하십시오. Corey: 구조화되지 않은 작업은 거의 어떤 대가를 치르더라도 피하고, 각 작업을 순차적인 레시피로 유지하며, 작업이 정말로 갈라질 때만 작업 그룹 안에서 병렬성을 도입하십시오.¹
• MainActor 마이그레이션 레시피. Holly: 리프(leaf) 타입에서 시작해 바깥쪽으로 작업해 나가거나, 완전히 메인 액터여야 하는 모듈이라면 main-actor-by-default를 켜고 떼어 낸 부분을 명시적으로 어노테이션하십시오. 가변 상태를 전혀 건드리지 않는 메서드는 nonisolated로 표시하고, 실제로는 한 번도 변경되지 않는 static var를 let으로 바꿔 nonisolated로 남도록 하십시오.¹
• 준수 비용은 고르지 않습니다. Doug: 사용되지 않는 Equatable이나 Hashable 준수는 그 위트니스(witness) 코드를 바이너리에 남깁니다. 런타임의 존재 타입(existential)에 대한 as? 캐스팅이 그것을 발견할 수 있기 때문이며, 코드 크기 비용이 듭니다. 반면 Sendable은 런타임 표현이 없는 순수 컴파일 타임 태그이므로, 사용되지 않는 Sendable 준수는 비용이 들지 않습니다.¹
• @inlinable과 @inline(never) 조합. Corey가 가장 좋아하는 기법: @inlinable은 함수 본문을 모듈 경계 너머로 노출해 제네릭 특수화와 효과 전파를 풀어 주고, @inline(never)는 차갑고 코드가 많은 경로(바이트 단위 폴백 복사)가 인라인되지 않게 막아 뜨거운 경로를 빠르게 유지합니다. 그는 이 짝을 “Swift 네트워킹 포트폴리오 전체에서 세 번”, 흔치 않은 차가운 경로 성능 문제에 대해 써 왔습니다.¹
• 프로젝트가 아니라 가장 뜨거운 경로를 최적화하십시오. Corey: “우리는 가장 뜨거운 경로를 따라 span과 unique array 몇 개를 도입해 큰 성과를 거뒀습니다.” 이는 작고 컴파일러가 뒷받침하는 변경으로 성능 향상의 거의 전부를 가져다줍니다. 새 성능 타입을 격리된 상태로 유지해, 그것을 채택하는 일이 결코 거대한 리팩터링을 강요하지 않도록 하십시오.¹
• 기능 모으기를 그만두십시오. 패널에서 거듭 나온 문장은 Corey가 인용한 친구의 말에서 나옵니다. “언어 기능은 수집품이 아니다.” 그것들을 다 쓴다고 상을 받는 것은 아닙니다. 먼저 프로파일링하고, 프로파일러가 가리키는 좁은 도구(비복사 타입, UniqueArray, Span)에 손을 뻗고, 남은 시간은 버그 수정과 기능에 쓰십시오.¹

FAQ

Apple은 정말로 WWDC26 Swift 랩을 자막 없이 공개했나요?

네. Apple은 Swift Group Lab(세션 8001)을 개발자 사이트에 공식 트랜스크립트나 자막이 없는 영상으로 게시했습니다.¹ 정확하게 인용하기 위해, 저는 그 녹화를 로컬 받아쓰기 과정에 돌렸습니다. 그래서 이 글의 모든 인용은 대략적인 타임스탬프가 붙은 그 로컬 ASR에서 옮긴 의역이며, 이름과 팀으로 출처를 표시했습니다.¹

Swift 팀은 동시성에 대해 무엇을 바꾸겠다고 말했나요?

Holly는 만약 Apple이 오늘 Swift 동시성을 설계한다면, nonisolated async 함수가 전역 동시 스레드 풀로 넘어가는 대신 처음부터 호출자의 컨텍스트에서 실행되도록 했을 것이라고 말했습니다. 그녀는 오랫동안 전역 풀에 대한 믿음을 갖고 있었지만 실제 현장의 증거를 보고 생각을 바꿨고, Swift 6.2는 호출자 컨텍스트 동작을 기본값으로 만들었습니다.¹

제 Swift 타입을 Sendable로 만들어야 하나요, 아니면 비Sendable로 만들어야 하나요?

이 랩의 조언은 일시적인 계산용 타입을 의도적으로 비Sendable로 만들라는 것입니다. Swift 6.4는 그것을 위해 ~Sendable 표기법(SE-0518)을 추가하는데, 이는 사용 불가 준수와 다릅니다. 하위 클래스가 가변 상태를 전혀 추가하지 않으면 여전히 Sendable을 추가할 수 있기 때문입니다.² Tony는 Foundation이 모호한 클래스들을 새 기능으로 다시 어노테이션하고 있으며 전역 UserDefaults가 Sendable 준수를 얻을 것으로 예상한다고 말했고, 두 가지 모두 랩에서 나온 정보입니다.¹

작업이 취소될 때 비동기 정리가 확실히 실행되게 하려면 어떻게 해야 하나요?

취소된 컨텍스트에서는 대부분의 Swift 코드가 일시 중단되는 작업을 건너뛰므로, 비동기 정리가 조용히 실패할 수 있습니다. Corey의 패턴은 모든 async defer에서 실제로 일시 중단되는 await 호출을 점검해 취소 실드로 감싸는 것입니다. async defer(SE-0493)와 withTaskCancellationShield(SE-0504)는 모두 Swift 6.4에 등장합니다.³⁴¹

튜플 준수는 Swift에서 출시되나요?

아직 아닙니다. SE-0283은 수정을 위해 반려됐고 그 원래 구현은 되돌려졌습니다. 일반적인 파라미터 팩 방식은 실험적 TupleConformances 플래그 뒤에만 존재합니다. Holly는 랩에서 컴파일러 내부의 실험적 구현이 “거의 끝까지 다 왔다”고 말했지만, 이는 출시된 기능이라기보다 엔지니어의 낙관을 반영한 것입니다.¹

이 랩은 발표에 대한 솔직한 동반자입니다. 맥락 속에서 출시된 기능을 알고 싶다면 Swift 2026의 새로운 기능을 읽어 보고, Holly가 논한 호출자 컨텍스트 기본값 뒤에 있는 마이그레이션 메커니즘에 대해서는 실전에서의 Swift 6.2 동시성을 살펴보십시오. 패널의 “먼저 프로파일링하고 좁은 도구를 채택하라”는 철학은 Swift Testing 대 XCTest에서 테스트로도 이어집니다. WWDC26 보도 전체는 Apple Ecosystem Series에 담겨 있습니다.

References