iOS 27 MetricKit, Swift 새 API와 상태별 지표

게시 2026.07.14 · 약 6분 분량

애플은 2026년 6월 WWDC26의 'Meet the new MetricKit' 세션에서 iOS 27용 MetricKit을 바닥부터 다시 만들었다고 발표했다. 2026년 7월 기준 핵심 변화는 세 가지다. 기존 MXMetricManager를 대체하는 Swift 우선 MetricManager API, 앱의 상태별로 성능을 쪼개 보는 StateReporting 프레임워크, 그리고 Metal 프레임률과 메모리 예외 진단 같은 새 지표다. 이 글은 iOS 앱 개발자를 대상으로 WWDC26에서 공개된 새 API의 구조와 도입 판단 기준을 다룬다. 모든 세부 시그니처를 담은 레퍼런스는 아니다.

MetricKit이란 무엇인가

MetricKit은 앱이 실제 사용자 기기에서 어떻게 동작하는지를 애플이 대신 수집해 개발자에게 넘겨 주는 프레임워크다. Xcode의 Instruments가 내 손안의 개발 기기를 측정한다면, MetricKit은 앱스토어에 배포된 뒤 수많은 사용자 기기에서 벌어진 일을 하루 단위로 모아 보내 준다. 애플은 2019년 iOS 13(WWDC19)에서 MetricKit을 처음 공개했고, iOS 14에서 수집 지표를 크게 넓혔다.

애플 공식 문서에 따르면 MetricKit이 주는 데이터는 크게 두 종류다. 하나는 지표(metric)로, 실행 시간·행(hang, 화면이 잠깐 멈추는 현상)·애니메이션 부드러움·CPU·GPU·디스크·네트워크 사용량이 좋아지는지 나빠지는지 추세를 보여 준다. 다른 하나는 진단(diagnostic)으로, 어떤 코드 경로가 그 문제를 일으켰는지 구체적인 단서를 준다. 지표로 '느려지고 있다'를 알고, 진단으로 '어디서'를 찾는 구조다. 프레임워크의 전체 그림은 애플 공식 MetricKit 문서에서 확인할 수 있다.

iOS 27에서 무엇이 바뀌었나

가장 큰 변화는 진입점이 MXMetricManager에서 MetricManager로 바뀐 것이다. 애플은 WWDC26 'Meet the new MetricKit' 세션에서 이 프레임워크를 현대적인 Swift API로 다시 설계했다고 밝혔다. 예전에는 구독자(subscriber) 객체를 만들어 델리게이트 콜백으로 리포트를 받았지만, 새 MetricManager는 리포트를 비동기 스트림으로 내보낸다.

metricReports와 diagnosticReports를 for await로 순회하면 리포트가 도착할 때마다 이어서 처리할 수 있다. 이 비동기 시퀀스 패턴이 낯설다면 콜백을 순차 코드로 바꾸는 async/await를 먼저 익히면 이해가 빠르다. 애플 설명에 따르면 각 리포트는 하루 전체를 합산한 항목과 몇 시간 단위의 세부 항목(intervalEntries)으로 나뉘고, 값은 .cpu·.memory·.display·.gpu 그룹으로 묶여 전달된다. 리포트가 Codable을 따르므로 JSONEncoder().encode(report) 한 줄로 JSON 직렬화해 서버로 보낼 수 있다.

import MetricKit

let manager = MetricManager()

Task {
 for await report in manager.metricReports {
 // 하루 단위로 도착하는 성능 지표
 handle(report)
 }
}

상태별 측정은 어떻게 하나

iOS 27부터는 지표를 앱의 상태별로 나눠 볼 수 있다. 애플이 든 예시는 탭이 여러 개인 앱에서 행 시간을 잴 때, 사용자가 탭 1에 있을 때와 탭 2에 있을 때를 구분해 측정하는 것이다. 전체 평균만 보면 '가끔 멈춘다'에서 끝나지만, 상태별로 쪼개면 '지도 탭에서만 멈춘다'까지 좁힐 수 있다. 실제로 WWDC26 세션 데모에서는 지출 관리 앱의 스크롤 끊김(hitch) 비율이 전체 평균으로는 15ms/s였지만, 상태별로 나눠 보니 지출 탭은 1ms/s, 리포트 탭은 71ms/s로 문제가 특정 화면에 몰려 있음이 드러났다.

이를 위해 StateReporting 프레임워크가 새로 나왔다. 애플 설명에 따르면 사용 순서는 세 단계다. 먼저 StateReporting을 임포트하고, 역방향 DNS 형식의 문자열로 상태 영역(도메인)을 정의한 뒤 MetricManager를 만들 때 등록한다. 그다음 앱이 각 상태로 진입할 때마다 전환을 보고한다. 상태에 부가 정보를 붙이고 싶으면 ReportableMetadata 매크로로 구조체를 직접 정의해 함께 넘길 수 있다. 애플에 따르면 한 도메인에는 한 번에 하나의 활성 상태만 존재하므로, 탭과 네트워크 상태처럼 여러 축을 동시에 나눠 보려면 도메인을 여러 개 정의하면 된다.

import MetricKit
import StateReporting

let domain = StateReportingDomain("com.example.app.tabs")
let manager = MetricManager(enabledStateReportingDomains: [domain])

let reporter = StateReporter.reporter(for: domain.rawValue)
reporter.reportTransition(to: "지도")

Metal 프레임률과 메모리 예외 진단

새 지표도 늘었다. 애플은 iOS 27의 MetricKit이 Metal 프레임률 지표를 새로 제공한다고 밝혔다. Metal(애플의 저수준 그래픽 API)로 화면을 그리는 게임에서 초당 몇 프레임이 나오는지는 체감 품질을 좌우하는 핵심 수치인데, 이제 실사용 기기의 렌더 성능을 필드에서 받아볼 수 있다.

진단 쪽에서는 메모리 예외 진단(memory exception diagnostic)이 추가됐다. 앱이나 익스텐션이 메모리 한도를 넘겨 시스템에 강제 종료될 때, 무슨 일이 있었는지 더 구체적인 단서를 준다. 메모리 초과 종료는 일반 크래시 로그에 잘 남지 않아 원인 추적이 까다로웠는데, 이 진단이 그 공백을 메운다. 애플에 따르면 크래시 진단에는 각 종료가 지표에 어떻게 반영됐는지 알려 주는 terminationCategory(종료 범주) 필드도 붙어, 비정상 종료와 개별 진단을 연결하기 쉬워졌다.

기존 MXMetricManager 코드는 어떻게 옮기나

애플은 새 기능을 쓰려면 MXMetricManager에서 MetricManager로 옮기라고 안내한다. 다만 서둘러 전환할 이유는 없다. 기존 구독자 기반 코드는 그대로 동작하고, 상태별 측정·Metal 프레임률·메모리 예외 진단처럼 iOS 27에서 새로 생긴 데이터가 필요해질 때 MetricManager로 갈아타면 된다. MetricManager는 iOS 27 이상에서만 동작하므로, 이전 버전을 함께 지원하는 앱이라면 if #available(iOS 27, *) 분기로 감싸 기존 MXMetricManager 경로와 공존시키면 된다.

실무 순서는 이렇게 잡는 편이 좋다. 수집한 리포트를 서버로 모으는 파이프라인이 없다면 그것부터 만든다. MetricKit 리포트는 하루에 한 번, 그것도 앱이 다음번에 실행될 때 전달되므로 기기 하나의 데이터만 봐서는 의미가 약하다. 여러 기기의 리포트를 쌓아야 비로소 추세가 보인다. 리포트가 Codable이라 JSON으로 저장하기 좋다. 이렇게 원격에서 성능을 관찰하는 흐름은, 기기 쪽에서 로그를 print에서 os_log로 옮겨 정돈해 두면 진단 단계에서 함께 쓰기 좋다.

결국 iOS 27의 MetricKit은 '얼마나 느린가'를 넘어 '어떤 상태에서 느린가'까지 답하도록 바뀌었다. 상태별 해상도가 필요할 만큼 규모가 있는 앱이라면 새 API가 주는 이점이 분명하다.