WWDC26 랩에서 Apple 성능 팀이 말한 것

WWDC26에서 Apple은 자사의 Power & Performance 엔지니어 다섯 명을 카메라 앞에 세워 한 시간 동안 개발자와 실시간 Q&A를 진행하며, 개발자들이 실제로 제기하는 질문에 답했습니다. 유휴 상태의 SwiftUI 화면이 왜 여전히 배터리를 소모하는지, 보유하지 않은 구형 기기를 어떻게 흉내 낼 수 있는지, 출시된 앱에서 가장 큰 전력 실수란 정말로 무엇인지 같은 질문들입니다. 다듬어진 세션은 프레임워크가 어떻게 동작하는지 알려줍니다. 반면 Group Lab은 Apple 자신의 팀이 그것을 어떻게 사용하는지 알려주었습니다. 이 글은 간직할 만한 현장 지침을 추려 정리합니다.

출처에 관한 메모: Apple은 이 랩 영상을 자막 없이 공개했습니다. 그래서 저는 로컬 환경에서 Whisper로 받아쓰기를 했고, 따라서 아래의 모든 랩 인용은 그 받아쓰기를 의역한 것이며 Apple의 축어적 트랜스크립트가 아닙니다. 화자는 랩 소개에서 주어진 이름과 역할을 바탕으로, 대화의 맥락에서 추론해 귀속했습니다. 성능을 담당한 Terry, MetricKit을 담당한 Yanni, Instruments를 담당한 Kaspar, CoreOS Power를 담당한 Kunal, 렌더 파이프라인을 담당한 Marco, 그리고 진행을 맡은 Cole입니다.¹ 랩의 지침이 Apple이 공식적으로 문서화한 내용에 닿는 부분에서는 해당 문서나 대응하는 세션을 인용하고 그 점을 표시했습니다.

랩 조언의 상당 부분을 떠받치는, 케이블 없는 파워 트레이스 워크플로는 약 11:42 지점에서 시작합니다.

TL;DR

• 구식 Objective-C 기반 MetricKit 표면은 퇴장 수순을 밟고 있습니다. MXMetricManager는 27.0에서 공식적으로 지원 중단(deprecated)되었으며, 새로운 메트릭 및 진단 유형은 새 Swift API에만 제공됩니다.²³
• Xcode Organizer는 이제 Metric Goals를 제공합니다. 이는 사용자 자신의 이력과, Apple이 사용자 앱과 유사하다고 판단한 앱들로부터 도출한 기준선으로, 실행, 행(hang) 비율, 디스크 쓰기, 배터리, 저장 공간, 히치(hitch)를 아우릅니다.⁴
• 팀이 권장하는 전력 워크플로는 Performance Trace의 Power Profiler 모드입니다. 기기에서 케이블 없이 .aar 트레이스를 기록하고, 이를 Mac으로 공유한 뒤, Instruments에서 CPU, GPU, 디스플레이, 네트워킹 전력 레인을 읽습니다. 이 기능은 iOS 27이 아니라 iOS 26에서 등장했습니다.⁵
• Apple Intelligence 작업은 대부분 Neural Engine과 Private Cloud Compute에서 실행되므로, CPU에 의존하는 앱 작업은 경합 없이 함께 실행될 수 있는 경우가 많습니다. 시스템이 일시 정지하고 재개할 수 있도록 백그라운드 작업을 청크 단위로 나누세요.¹
• 팀이 목격하는 가장 큰 전력 실수는 부족한 텔레메트리입니다. 올바른 것을 한 번도 측정하지 않았기 때문에, 개발자는 엉뚱한 것을 최적화하게 됩니다.¹

랩을 받아쓸 가치가 있는 이유

Apple의 녹화 세션은 대본이 있고, 리허설을 거치고, 편집됩니다. Group Lab은 그 어느 것도 아닙니다. 실제로 일하는 개발자들의 질문에 엔지니어가 실시간으로 반응하는 자리이며, 그 답변에는 현장 경험의 결이 담겨 있습니다. 무용담, “이건 늘 보는 패턴이에요”라는 식의 패턴 인식, 무엇이 어려운지에 대한 작은 고백들입니다. 바로 그 결이야말로 다듬어진 세션이 깎아내는 것입니다.

문제는 Apple이 이 랩을 자막 없이 공개했다는 점입니다. 인용하려면 로컬 음성 인식으로 영상을 처리해야 했고, 그 결과 고유명사와 API 철자는 근삿값으로 나옵니다. 저는 모든 기술적 주장을 사실로 진술하기 전에 Apple 문서나 대응하는 WWDC 세션과 대조해 확인했으며, 랩 자체의 표현은 명확히 의역으로 표시했습니다. 엔지니어들의 의도와 우선순위에 관한 틀은 권위 있는 것으로 받아들이고, 인용은 구체적 사항에 관한 기록상의 출처로 받아들이세요.

현장 데이터 이야기: MetricKit은 새로 만들어지고 있다

MetricKit을 담당하는 Yanni는 올해가 이 프레임워크에 매우 큰 해라고 말하며, 새로운 Swift 우선 API를 축으로 한 전면적 재구축을 설명했습니다. 그가 든 동기는 이렇습니다. 이 Swift API는 Swift concurrency를 위해 만들어졌고, 새로운 데이터 세분성을 염두에 두고 설계되어, 개발자가 일간 메트릭 보고뿐 아니라 더 짧은 간격의 세부 분할까지 얻을 수 있다는 것입니다. 무엇보다 중요한 점으로, 그는 새로운 진단 및 메트릭 유형이 새 API에만 제공된다는 사실을 짚으며, 이것이 마이그레이션해야 할 진짜 이유라고 규정했습니다.¹

Apple 문서는 그 주장의 더 단호한 측면을 뒷받침합니다. MetricKit이 출시된 이래 개발자들이 진입점으로 사용해 온 MXMetricManager는 이제 공식적으로 지원 중단되었습니다. Apple의 참조 페이지는 27.0에서 지원 중단으로 표시하며 개발자에게 대신 MetricManager를 사용하라고 안내합니다.² WWDC26 세션 222는 그 배타성을 명시합니다. 새로운 메트릭 및 진단 유형은 새 Swift API에 존재하며, 구식 API로 소급 제공되지 않습니다.³ 아직 MXMetricManager를 호출하고 있다면, 단지 오래된 방식에 머물러 있는 것이 아닙니다. 앞으로 Apple이 추가하는 모든 것으로부터 단절되어 있는 것입니다.

랩은 또한 현장 데이터가 어디에서 오고 그것을 어떻게 읽어야 하는지에 관한 뿌리 깊은 혼동도 드러냈습니다. Kunal과 Yanni는 그 경계를 분명히 그었습니다. Instruments는 책상 위 한 대의 기기에서 깊은 로컬 프로파일링을 제공하는 반면, Xcode Organizer와 MetricKit은 실제 기기 위 실제 사용자로부터 집계된 현장 텔레메트리를 제공합니다. 둘은 자주 어긋나며, 그 어긋남이 바로 핵심입니다. Kunal은 Instruments에서 재현할 수 있는 행(hang)을 쫓는 동안, 정작 Organizer는 행의 실제 최대 원인이 전혀 다른 것, 책상 앞에서는 결코 재현되지 않는 것임을 보여 준다는 개발자의 모습을 묘사했습니다.¹

Organizer 쪽의 새로운 지렛대가 Metric Goals입니다. Kunal은 개발자들이 WWDC를 떠나기 전에 가장 시도해 보길 바라는 단일 기능으로 이를 꼽았습니다. 세션 258은 그것이 무엇인지 자세히 설명합니다. “사용자 앱과 다른 앱 사이의 기술적·기능적 유사성에 기반해” Organizer가 도출하는 권장 목표치로, 사용자 자신의 과거 기준선과 결합되며 실행 시간, 행 비율, 디스크 쓰기, 배터리, 저장 공간, 히치에 걸쳐 있습니다.⁴ 랩은 그 가치를 인간적인 언어로 표현했습니다. Cole은 어떤 동영상 앱을 들어 보이며 그것의 높은 전력 소모가 문제인지, 아니면 하루 종일 동영상을 재생하는 데 드는 비용일 뿐인지 묻는 개발자의 모습을 묘사했습니다. Metric Goals 이전에는 아무도 그 질문에 답할 수 없었습니다. 이제 Organizer는 유사한 앱들과 비교해 판단의 근거가 될 기준선을 제시합니다.¹

현장 데이터 위생에 관한 이야기가 하나 더 나왔는데, 개발자들이 거듭 틀리는 부분이라 분명히 짚어 둘 가치가 있습니다. 바로 실행 타이머를 직접 만들지 말라는 것입니다. 랩에서는 프로세스 생성 시각을 알아내려고 커널 API를 들여다보고 그것을 실행의 기준점으로 삼는 개발자들의 사례가 소개되었습니다. Yanni의 답변은 이랬습니다. MetricKit과 Organizer는 의도적으로 실행을 그런 식으로 측정하지 않으며, 사용자가 실제로 체감하는 구간을 측정한다는 것입니다. Apple 문서는 그 정의를 뒷받침합니다. 실행 시간은 “사용자가 아이콘을 탭한 순간부터 첫 화면이 그려질 때까지의 밀리초 수”이며, 정적 스플래시 화면 이후에 측정됩니다.⁶ 직접 만든 타이머는 탭의 순간을 볼 수 없습니다. 그 시점에는 아직 프로세스가 존재하지 않기 때문입니다. Apple의 도구는 그것을 볼 수 있으며, 게다가 앱에 측정 오버헤드를 전혀 더하지 않습니다.

팀이 실제로 권장하는 전력 워크플로

랩에서 가장 유용했던 절차적 조언은 책상 앞에서는 결코 나타나지 않는 전력 문제를 어떻게 잡아낼지에 관한 것이었습니다. Kaspar와 Kunal은 하나의 워크플로로 거듭 돌아왔습니다. 케이블 없는 트레이스입니다.

그 작동 방식은, Kaspar의 표현을 빌리면, Instruments에서 연결을 끊고, 기기에서 여러 시간 동안 실행될 수 있는 트레이스를 기록한 뒤, 그 파일을 Mac으로 공유해 Instruments에서 열어 나중에 분석하는 것입니다. 그 이점은 실세계 조건에 있습니다. 돌아다니고, 실제 셀룰러 핸드오프를 겪고, 기기가 따뜻해지도록 두고, 통제된 책상 세션에서 일어나는 일이 아니라 실제로 일어나는 일을 포착하는 것입니다. Kunal은 이를 특정 부류의 버그, 즉 예정되어서는 안 될 때 예정된 백그라운드 작업을 잡아내는 방법으로 지목했습니다. 케이블로 연결한 채 지켜보는 동안에는 보이지 않는 버그입니다.¹

이 워크플로는 Performance Trace의 Power Profiler 모드이며, 그 출처를 정확히 해 둘 가치가 있습니다. 이것은 iOS 27의 새 기능이 아니라 WWDC25의 iOS 26 기능입니다. Apple은 이를 “Power Profiler로 앱의 전력 사용량 측정하기”로 문서화합니다. 설정 > 개발자 > Performance Trace에서 활성화하고, 제어 센터의 컨트롤로 트리거하며, 생성된 .aar 파일을 Mac으로 공유한 뒤, Instruments에서 전력을 CPU, GPU, 디스플레이, 네트워킹 레인에 걸쳐 서브시스템별로 분해해 읽습니다.⁵ 랩은 이를 27의 헤드라인이 아니라 권장하는 기본 수단으로 제시했습니다. (올해 진정으로 새로운 형제 격은 lookback 컬렉션 워크플로와 metalperftrace라는 macOS CLI로, 이는 Metal 머신러닝 글에서 다뤘습니다. 이들은 서로 다른 작업을 위한 서로 다른 도구입니다. 혼동하지 마세요.)

전력 논의에서 간직할 만한 기법이 두 가지 더 있습니다.

• 저전력 모드를 빈약한 기기의 대용으로. Terry는 새 하드웨어만 보유했지만 구형 하드웨어에서 앱이 어떻게 느껴지는지 알아야 하는 개발자를 위한 요령을 제시했습니다. 저전력 모드를 켜는 것입니다. 이는 배터리를 아끼기 위해 CPU 속도를 늦추어, 그러지 않으면 구형 기기에서만 보였을 문제를 드러냅니다. 그는 이것이 일반적인 최적화 관행으로도 좋다고 덧붙였습니다. 많은 사용자가 스스로 선택해 저전력 모드를 쓰며, 그 상태에서도 앱은 쾌적하게 느껴져야 하기 때문입니다.¹
• 발열과 네트워크 시뮬레이션을 위한 Device Conditions. 랩에서는 앱을 높은 발열 상태나 저하된 네트워크 링크로 강제로 몰아넣는 “condition inducer”가 거듭 언급되었습니다. 이 기능의 Apple 공식 명칭은 Device Conditions입니다. 화자 본인도 Xcode 27의 어디에 있는지 확신하지 못했습니다. 이는 과거 Devices 창에 있었으며, Device Hub에 통합될 수도 있습니다. 랩의 화자는 그것이 무엇을 하고 무엇을 하지 않는지에 대해 신중했습니다. 이는 뜨거운 기기의 스로틀링 동작을 인위적으로 유발하는 것이지, 실제로 하드웨어를 가열하지는 않습니다. 따라서 전화기를 굽지 않고도, 발열 압박 아래에서 앱이 어떻게 동작하는지, 즉 히치가 늘고 행이 늘어나는 모습을 관찰할 수 있습니다.¹

그리고 한 번 이상 나온 확고한 규칙이 있습니다. Simulator에서는 절대 프로파일링하지 말라는 것입니다. Kaspar는 Simulator가 Mac에서 실행되므로 어떤 기기를 선택하든 그 성능은 실제 기기 성능에 대해 아무것도 알려 주지 않는다고 지적했습니다. 프로파일링에는 실제 기기를 쓰고, 사들일 수 없는 기기 다양성을 메우기 위해 MetricKit과 Organizer의 현장 데이터에 기대세요.¹

성능 분류: 발열, AI 경합, 청크 단위 작업

질문이 분류(triage) 전략으로 넘어가자, 세 가지 지침이 두드러졌습니다.

발열 플레이북. 한 개발자가 직사광선 아래 야외에서 사용되어 기기가 끊임없이 뜨거워지는 ARKit 및 Metal 앱에 관해 질문했습니다. Kunal의 답변은 API에서 시작했습니다. ProcessInfo.thermalState를 청취하고, 그것이 올라가면 경험을 낮추라는 것입니다.¹ 패널이 제시한 구체적 지렛대는 이렇습니다. 더 가벼운 네트워크 리소스를 요청해 기기가 디코딩과 파싱에 쓰는 시간을 줄이고, 풍부한 애니메이션을 더 단순한 것으로 교체하며, 압박 아래에서 프레임 속도나 렌더링 해상도를 낮추는 것입니다. Kunal은 시스템이 높은 발열 상태에서는 이미 애니메이션과 디스플레이 프레임 속도를 스로틀링하므로 일부 완화는 자동이며, 그 위에 직접 만든 것을 얹는 것이라고 짚었습니다. 이에 대한 Marco의 마무리 한마디는 이렇습니다. 밀어내는 픽셀이 적을수록 작업이 줄어들며, “열역학을 피해 갈 방법은 없다”는 것입니다. 앱의 연산은 제어할 수 있지만 물리는 제어할 수 없으니, 자신이 쥐고 있는 부분을 철저히 최적화하라는 뜻입니다.¹

Apple Intelligence 경합 모델. 한 날카로운 질문은, 시스템이 Apple Intelligence 작업으로 바쁠 때 iOS 27이 앱의 백그라운드 작업을 어떻게 우선순위 매기는지 물었습니다. Terry의 답은 안심시키면서도 구체적이었습니다. Apple Intelligence 기능 상당수는 Neural Engine이나 Private Cloud Compute에서 실행되므로, 앱이 CPU를 쓰는 동안 AI 워크로드가 Neural Engine을 쓴다면, 둘은 같은 자원을 두고 경합하지 않고 동시에 실행될 수 있는 경우가 많습니다. 그가 권한 방어적 수는 구조적인 것이었습니다. 백그라운드 작업을 작은 청크로 구성해 시스템이 일시 정지하고 재개할 수 있게 하라는 것입니다. 중단될 때마다 처음부터 다시 시작해야 하는 하나의 거대한 작업으로 만들지 마세요. 청크 단위 작업은 스케줄러가 원하는 만큼 자주 실행해 주지 않을 때에도 진전을 이룹니다.¹

StateReporting 카디널리티. 새로운 MetricKit StateReporting 기능은 메트릭을 애플리케이션 상태별로 분할하게 해 주는데, 이는 강력하면서도 오용하기 쉽습니다. 랩은 카디널리티에 관한 명확한 규칙을 제시했습니다. 목록의 정확한 항목 수처럼 자주 바뀌는 정밀한 값을 보고하지 말라는 것입니다. 대신 버킷으로 나누세요. 소, 중, 대처럼 말입니다. 그러면 나중에 “이 크기 범위에서 성능이 퇴보했는가?”라고 물을 수 있습니다. 모든 개별 카운트를 기록하는 비용을 치르지 않고서요. Yanni의 예시는 이렇습니다. 1,000개 항목 목록과 1,001개 항목 목록은 의미 있는 차이를 만들지 않으므로, 정확한 수를 기록하는 것은 순전한 오버헤드입니다. 분석에 중요한 경계를 정의하고 버킷을 보고하세요.

특히 실행과 관련해, 패널은 분류 조언을 하나로 묶는 단일 멘탈 모델로 수렴했습니다. 첫 프레임을 그리는 데 필요한 최소한의 데이터를 파악하고, 그것만 로드하고, 나머지는 전부 미루라는 것입니다. Terry는 흔한 실패를 경계했습니다. 한 무더기의 백그라운드 작업을 떼어 내고는, 그 모두가 끝날 때까지 메인 스레드를 막아 버리는 실패입니다. 이는 실행 중에 앱 전체를 얼어붙게 만듭니다. 그것이 자신의 문제인지 확인하려면, Kaspar는 System Trace 템플릿의 메인 스레드 뷰를 가리켰습니다. 거기서는 막힌 메인 스레드가 곧바로 드러납니다. 패널은 또한 System Trace가 스레드 우선순위, 선점(preemption), 컨텍스트 스위치 히스토그램을 드러낸다고 설명했지만, 저는 그것들을 문서화된 Instruments 27 기능으로 확인하지 못했으므로, 이는 사양이라기보다 도구에 대한 랩의 설명으로 받아들이세요.

도구 메모: Foundation Models instrument과 초보자를 위한 진입로

랩을 마무리하는 도구 관련 항목이 두 가지 있습니다.

Foundation Models 기능을 출시하는 개발자를 위해, Kaspar는 이 Instruments 도구가 작년의 기본적인 토큰 수 메트릭에서, 프롬프트와 응답을 포착하고 얼마나 많은 토큰이 캐시되는지 보여 주는 본격적인 디버깅 instrument으로 성장했다고 설명했습니다.¹ WWDC26 세션들을 가로지른 정확한 그림은 이렇습니다. Foundation Models instrument은 트레이스가 진행되는 동안 기기에서 프롬프트와 응답 데이터를 포착합니다(세션 243. 이 세션은 포착에 민감한 정보가 포함될 수 있어 프로덕션에서는 꺼져 있다는 점도 짚습니다).⁷ 캐시된 토큰 수는 모델 응답의 usage API를 통해 들어옵니다(세션 241).⁸ 두 가지 서로 다른 메커니즘, 즉 트레이스 타임라인을 위한 것과 응답별 집계를 위한 것으로, 수치를 읽을 때 분명히 구분해 둘 가치가 있습니다.

초보자에 대해, 패널은 어디서 시작해야 하는지에 일관된 입장을 보였습니다. Marco는 첫 점검으로 플레임 그래프 뷰의 Time Profiler를 권했습니다. 플레임 그래프는 아웃라인 형태의 숫자를 읽게 하는 대신, 콜 스택이 얼마나 비용을 차지하는지 시각적으로 보여 주기 때문입니다. Kaspar는 다음 단계로 Top Functions 모드를 덧붙였습니다. 가장 무거운 함수들의 평면 목록으로, 깊이 중첩된 콜 트리를 따라가지 않고도 문제아를 한눈에 짚어낼 수 있습니다.¹ 그리고 패널이 가장 자주 반복한 메타 조언은 이것입니다. 최적화하기 전에 측정하라. Kunal의 표현으로는, 가장 흔한 함정은 부족한 텔레메트리이며, 그것이 개발자를 실질적 성과가 없는 영역의 최적화로 이끕니다. 실행과 백그라운드 작업에 관한 Terry의 따름정리는 이렇습니다. 절반의 빈도로 보내는 네트워크 요청은 공짜로 얻는 전력 이득입니다. 어느 한 서브시스템에 뛰어들기 전에 전체 그림을 보세요.¹

핵심 요약

오늘 앱을 출시하는 iOS 개발자에게: - MXMetricManager에서 새로운 MetricManager Swift API로 마이그레이션하세요. 구식 표면은 27.0에서 지원 중단되었고, 새로운 메트릭 및 진단 유형은 새 API 전용입니다.²³ - Xcode Organizer를 열어 실행, 행, 배터리, 히치, 디스크 쓰기, 저장 공간에 대해 유사 앱 기준선과 자신의 Metric Goals를 대조해 보세요.⁴ - 실행을 직접 만든 타이머로 측정하는 것을 멈추세요. MetricKit과 Organizer는 아이콘 탭부터 측정하며, 그것은 자신의 프로세스가 볼 수 없는 것입니다.⁶

성능 및 전력 분류를 위해: - Power Profiler 케이블 없는 트레이스(iOS 26, 설정 > 개발자 > Performance Trace)를 사용해, 책상 앞에서는 결코 재현되지 않는 백그라운드 작업과 실세계 전력 문제를 잡아내세요.⁵ - Simulator가 아니라 실제 기기에서 프로파일링하고, 보유하지 않은 구형 하드웨어의 대역으로 저전력 모드를 사용하세요.¹ - ProcessInfo.thermalState를 청취하고, 압박 아래에서 프레임 속도, 해상도, 애니메이션의 풍부함, 네트워크 부하를 낮추세요.¹

AI 기능을 만드는 팀에게: - 백그라운드 작업을 청크로 나누어 스케줄러가 일시 정지하고 재개할 수 있게 하세요. CPU 작업은 Neural Engine과 Private Cloud Compute AI 워크로드와 경합 없이 함께 실행될 수 있는 경우가 많습니다.¹ - StateReporting 값을 버킷으로 나누세요(소, 중, 대). 빠르게 바뀌는 정확한 카운트는 절대 보고하지 마세요.¹ - Foundation Models의 경우, 프롬프트와 응답 포착을 위해 Instruments 도구를 읽고(세션 243), 응답 usage API에서 캐시된 토큰 수를 가져오세요(세션 241).⁷⁸

이 랩은 시리즈의 더 깊은 분석들과 자연스럽게 짝을 이룹니다. 메트릭을 앱 상태별로 분할하는 것에 관한 iOS 27의 MetricKit과 StateReporting, 새로운 디핑과 행 탐지 워크플로에 관한 Instruments 27과 앱 응답성, 그리고 현장 데이터와 책상 프로파일링이 왜 어긋나는지에 관한 성능의 사각지대입니다. 시리즈 전체 허브는 Apple Ecosystem Series입니다.

참고 문헌