WWDC 2026 개발자 하이라이트

WWDC 2026 의 개발자 핵심은 네 가지입니다. 앱 안에서 온디바이스 LLM 을 호출하는 Foundation Models(Apple Intelligence) 프레임워크, 데이터 레이스를 컴파일 시점에 잡는 Strict Concurrency 가 기본 켜진 Swift 6.2, 코드를 외부로 보내지 않고 자동완성·테스트 생성을 돌리는 Xcode 18 의 온디바이스 AI, 그리고 공간 컴퓨팅용 visionOS 3 입니다. 한 문장으로 줄이면, 애플이 프라이버시를 지키는 온디바이스 방식으로 AI 코딩 흐름에 합류하면서 동시성 안전성을 강제하기 시작했다는 것이 이번 발표의 골자입니다.

기존 프로젝트라면 Swift 6.2 의 Strict Concurrency 부터 점검하세요. 6.2 에서 기본 활성화되기 때문에, 본문 callout 대로 우선 -strict-concurrency=complete 플래그로 경고만 켜서 데이터 레이스 후보가 몇 군데인지 규모를 파악한 뒤 점진적으로 @Sendable 을 붙여가는 게 안전합니다. 한 번에 전환하려 하면 빌드가 통째로 막힙니다. Apple Intelligence 의 Foundation Models 나 Xcode 18 의 온디바이스 AI 기능을 쓰려면 대상 기기·OS 가 해당 칩셋을 지원하는지(구형 기기 제외 여부)를 먼저 확인하셔야 실기기 테스트에서 당황하지 않습니다.

가장 큰 함정은 Swift 6.2 의 Strict Concurrency 마이그레이션 작업량을 얕보는 것입니다. 본문이 짚었듯 대규모 프로젝트에서는 @Sendable 검사 강화로 수정해야 할 곳이 예상보다 훨씬 많고, 모듈 경계와 기존 콜백 코드에서 컴파일 에러가 쏟아집니다. 두 번째는 Apple Intelligence 의 Foundation Models 를 GitHub Copilot 같은 클라우드 모델과 같은 것으로 착각하는 경우입니다. 이건 온디바이스라 지원 기기가 제한되고 모델 크기·성능도 다르므로, 모든 사용자 기기에서 동일하게 동작한다고 가정하면 안 됩니다. 신규 API 다수가 베타라 정식 릴리스 전까지 시그니처가 바뀔 수 있다는 점도 유의하세요.

이번 발표는 iOS·macOS 네이티브 앱을 만드는 개발자에게 직접적입니다. 사용자 데이터를 외부로 보내지 않고 텍스트 요약·이미지 분석을 앱 안에서 처리해야 하는 프라이버시 중심 앱이라면 Foundation Models 가 GitHub Copilot 같은 클라우드 모델보다 적합하고, 데이터 레이스로 간헐적 크래시가 나던 멀티스레드 앱이라면 Swift 6.2 의 Strict Concurrency 가 근본 해결책이 됩니다. 반대로 구형 기기까지 폭넓게 지원해야 하는 앱은 Foundation Models 가 신형 칩셋에 묶이므로 클라우드 기반 추론을 병행해야 하고, 크로스플랫폼이 목표라면 애플 전용 프레임워크보다 Flutter 같은 선택지가 낫습니다. 레거시 코드가 많은 대규모 프로젝트는 Strict Concurrency 마이그레이션 비용이 크므로 당장 6.2 전면 전환을 서두를 필요는 없습니다.

애플 공식 자료가 1차 출처로 가장 정확합니다. Foundation Models 프레임워크는 developer.apple.com 의 해당 문서와 매년 공개되는 WWDC 세션 영상에서 API 시그니처와 코드 샘플을 확인할 수 있고, Swift 6.2 의 동시성은 Swift.org 의 Migration Guide 와 Concurrency 챕터를 읽으면 @Sendable·actor·data race 개념이 정리됩니다. SwiftUI 8 의 @Observable 매크로와 visionOS 3 도 같은 developer.apple.com 문서 트리에 있습니다. 검색 키워드로는 strict concurrency, actor isolation, on-device inference, RealityKit 을 잡아 두면 후속 학습 경로가 명확해집니다.