19 · 비정상 종료 판독

"앱이 죽었다"는 한 문장이지만 그 뒤에는 서로 완전히 다른 메커니즘 다섯 개가 있다. 어떤 것은 우리 코드가 잘못된 메모리를 건드려서, 어떤 것은 OS가 자원 한도를 이유로, 어떤 것은 사용자가 직접 죽인 것이다. 대응 방법이 각각 다르므로 판독이 먼저다. 이 챕터는 크래시 리포트를 열었을 때 어느 갈래인지 3초 안에 판정하고, 그 판정이 왜 그렇게 나오는지를 커널 수준에서 설명하는 것을 목표로 한다.

Q1. 앱이 사라지는 방식은 몇 가지이며 어떻게 구분하는가?

CS 원리

구분의 뿌리는 누가 종료를 결정했는가다. 유닉스 계열 OS에서 프로세스가 사라지는 경로는 근본적으로 둘뿐이다.

• 프로세스 자신이 정의되지 않은 동작을 저질러 하드웨어·커널이 트랩을 발생시킨 경우 — 잘못된 주소 접근(SIGSEGV/SIGBUS), 잘못된 명령어(SIGILL), abort() 호출(SIGABRT). 여기서는 문제를 일으킨 명령어의 위치가 곧 원인이므로 스택트레이스가 결정적 증거다.
• 외부(커널·다른 프로세스)가 정책적으로 죽인 경우 — SIGKILL. 이 시그널은 핸들러를 등록할 수 없고 무시할 수도 없다. 프로세스는 자신이 죽는다는 사실조차 알지 못하고 즉시 사라진다.

이 이분법에서 실무적으로 가장 중요한 결론이 나온다. SIGKILL로 죽은 앱은 스스로 크래시 리포트를 남길 수 없다. 핸들러가 돌 기회가 없기 때문이다. 그래서 (2)·(3) 계열 종료는 앱이 아니라 OS가 대신 기록하며, 그 기록의 핵심 필드가 Termination Reason이다 — "내가 왜 이 프로세스를 죽였는지"에 대한 커널의 진술서인 셈이다.

또 하나 짚을 것은 스택트레이스의 의미가 갈래마다 다르다는 점이다. (1)에서 스택은 인과의 종점이다. (3) 정책 종료와 (2) 중 메모리 한도 초과에서 스택은 그저 죽는 순간 무엇을 하고 있었는지일 뿐이며, 원인은 이미 한참 전에 만들어져 있다. 메모리 한도를 넘긴 이유는 죽기 직전 함수가 아니라 30초 전에 디코딩한 이미지에 있다.

다만 (2) 안에서도 갈린다. CPU·디스크쓰기·웨이크업 한도 초과는 그 순간 실제로 자원을 태우고 있던 코드가 찍히므로 스택이 상당히 유용하다(Q5). "자원 종료면 스택이 무의미하다"고 뭉뚱그리면 정작 고칠 수 있는 단서를 버리게 된다. 이 차이를 모르면 크래시 리포트를 반복적으로 오독한다.

iOS에서는

Apple은 Exception Type별 문서를 개별 페이지로 제공한다. 실무에서 마주치는 빈도 순으로 정리하면 이렇다.

Swift 개발자에게 특히 중요한 것이 EXC_BREAKPOINT (SIGTRAP)이다. 이름이 "브레이크포인트"라 디버거 문제로 오해하기 쉬운데, 실제로는 Swift 런타임이 안전성 위반을 감지하고 의도적으로 트랩을 실행한 것이다. nil 강제 언래핑, 배열 인덱스 초과, Int 오버플로, fatalError·precondition 위반이 전부 여기로 온다. P0 05장에서 본 Optional의 안전성이 런타임에서 이렇게 강제된다.

또한 EXC_GUARD는 진단이 어려운 버그를 조기에 드러내려고 Apple이 일부러 만든 장치다. 예컨대 Core Data가 쓰는 SQLite 파일의 파일 디스크립터를 앱이 실수로 close()하면, 원래는 한참 뒤에 엉뚱한 곳에서 알 수 없는 크래시가 났다. 파일 디스크립터를 "guarded"로 표시해두면 잘못 건드리는 그 순간 터지므로 원인 지점이 명확해진다.

실험 · 도구

각 종료 유형을 의도적으로 재현해보면 리포트가 어떻게 달라지는지 몸으로 익힐 수 있다. 실기기에서, 디버거를 떼고 실행해야 한다 — 디버거가 붙어 있으면 시그널을 디버거가 가로채서 리포트가 생성되지 않는다.

import Foundation

enum CrashKind: String, CaseIterable {
    case forceUnwrap, arrayBounds, objcException, badAccess, abortCall, memoryHog

    func trigger() {
        switch self {
        case .forceUnwrap:
            // EXC_BREAKPOINT (SIGTRAP) — Swift 런타임 트랩
            let s: String? = nil
            print(s!)

        case .arrayBounds:
            // EXC_BREAKPOINT (SIGTRAP) — 같은 계열
            let a = [1, 2, 3]
            print(a[99])

        case .objcException:
            // EXC_CRASH (SIGABRT) — 잡히지 않은 ObjC 예외 → abort()
            NSException(name: .genericException, reason: "실험용", userInfo: nil).raise()

        case .badAccess:
            // EXC_BAD_ACCESS (SIGSEGV) — 명백히 잘못된 주소
            let p = UnsafeMutablePointer<Int>(bitPattern: 0x1)!
            p.pointee = 42

        case .abortCall:
            // EXC_CRASH (SIGABRT) — 직접 호출
            abort()

        case .memoryHog:
            // EXC_RESOURCE (MEMORY) 후 Jetsam SIGKILL — 스택은 원인이 아니다
            var blocks: [Data] = []
            while true { blocks.append(Data(count: 64 * 1024 * 1024)) }
        }
    }
}

재현 후 리포트를 확인하는 경로는 셋이다.

# 1) 기기에서 직접 — 설정 › 개인정보 보호 및 보안 › 분석 및 향상 › 분석 데이터
#    파일명이 앱 이름으로 시작하는 .ips 파일이 크래시 리포트다.

# 2) Xcode — Window › Devices and Simulators › View Device Logs
#    자동 심볼화되어 함수명까지 보인다.

# 3) 커맨드라인 — 기기 로그에서 종료 기록만 추린다
#    ⚠️ log show 에는 --device 가 없다. 기기 로그는 collect 로 받아 아카이브를 show 한다.
log collect --device --last 1h --output device.logarchive
log show device.logarchive --style compact \
    --predicate 'eventMessage CONTAINS "termination" OR eventMessage CONTAINS "jetsam"'

# 실시간으로 보려면 stream 에 --device 를 준다
log stream --device --style compact \
    --predicate 'process == "runningboardd" OR process == "SpringBoard"'

memoryHog 케이스가 특히 교육적이다. 리포트를 열면 스택 최상단이 Data.init(count:)인데, 이건 원인이 아니라 마지막 한 방울일 뿐이다. 진짜 원인은 "왜 이만큼 쌓였는가"이고 그 답은 스택 어디에도 없다.

프로젝트 적용

팀에서 크래시를 분류할 때 쓸 판정 순서를 문서로 못 박아두면 오독이 크게 준다.

1. Exception Type이 EXC_CRASH (SIGKILL)인가? → 예라면 스택을 읽지 말고 Termination Reason으로. (Q4)
2. EXC_RESOURCE인가? → Exception Note에 NON-FATAL CONDITION이 있는지 확인. (Q5)
3. EXC_BREAKPOINT (SIGTRAP)인가? → Swift 런타임 트랩. 강제 언래핑·인덱스·오버플로를 의심하고 인앱 프레임 최상단을 본다.
4. EXC_CRASH (SIGABRT)인가? → Last Exception Backtrace 섹션이 있으면 그쪽이 진짜 원인 스택이다. 없으면 언어 예외가 아닌 abort()다.
5. 그 외 → 크래시 스레드의 스택을 위에서부터 읽되 첫 인앱 프레임을 찾는다.

대시보드 관점에서는 이 분류를 태그로 만들어 두는 것이 유용하다(18장 Q5). termination_kind=code_error | resource | policy | user 정도의 축이 있으면, "우리 크래시율의 절반이 사실은 메모리 한도"라는 사실이 한눈에 보인다. 대응 팀도 갈린다 — 코드 오류는 기능 담당자가, 자원·정책 종료는 성능 담당자가 본다.

꼬리 질문

Q2. 크래시 리포터는 왜 크래시 순간에 리포트를 전송하지 않는가?

CS 원리

시그널 핸들러의 제약은 재진입성(reentrancy) 문제다. 시그널은 프로세스의 실행 흐름을 임의의 명령어 경계에서 가로챈다. 즉 핸들러가 시작될 때, 중단된 코드가 어떤 상태에 있었는지 알 수 없다.

구체적으로 무엇이 위험한지 보자. malloc은 내부에 전역 자료구조와 그것을 보호하는 락이 있다.

1. 스레드가 malloc을 호출해 힙 락을 획득했다.
2. 락을 쥔 채로 자유 리스트를 수정하던 중 바로 그 순간 SIGSEGV가 발생했다.
3. 같은 스레드에서 시그널 핸들러가 실행된다.
4. 핸들러가 malloc을 호출한다 → 이미 자기가 쥐고 있는 락을 다시 잡으려 한다.

결과는 교착이거나, 재귀 락 감지에 의한 즉시 중단이다. 자유 리스트가 반쯤 수정된 상태였다면 힙 자체가 일관되지 않아 어떤 할당도 안전하지 않다.

그래서 POSIX는 async-signal-safe 함수 목록을 정의한다. 이 목록의 함수들은 "언제 어디서 중단당해도, 그리고 그 중단된 자기 자신 안에서 다시 호출돼도 안전하게 동작한다"는 성질을 보장한다. 목록은 놀랄 만큼 짧다 — write, read, open, close, _exit, signal 같은 저수준 시스템 호출이 대부분이다.

실제 프로덕션 크래시 리포터의 규칙을 보면 제약의 실체가 선명하다. KSCrash가 내부 코드 리뷰용으로 명문화한 규칙은 이렇다.

snprintf가 금지라는 점이 이 제약의 가혹함을 잘 보여준다. 문자열 포매팅처럼 순수해 보이는 함수조차 내부에서 락을 잡기 때문에 쓸 수 없고, 크래시 리포터는 16진수·10진수 변환 유틸을 직접 구현해서 쓴다.

iOS에서는

이 제약이 iOS 크래시 리포터의 아키텍처를 결정한다. 전형적인 구조는 이렇다.

1. 앱 시작 시(사전 준비) — 리포트를 쓸 버퍼를 미리 할당하고, 기기 정보·앱 버전 같은 고정 데이터를 미리 문자열로 만들어 둔다. 핸들러 안에서는 만들 수 없으므로 미리 만든다.
2. 크래시 순간(핸들러) — 스택을 언와인딩해 주소 목록을 얻고, 사전 할당 버퍼에 채워 write()로 파일에 쓴다. 심볼화도, JSON 직렬화도, 압축도 하지 않는다.
3. 다음 실행 시(정상 상태) — 디스크의 원시 리포트를 읽어 파싱·심볼화·직렬화하고 네트워크로 보낸다.

여기서 iOS 특유의 결과가 둘 나온다.

• 크래시 후 앱을 다시 켜지 않으면 리포트는 영원히 안 온다. 크래시가 너무 심각해서 사용자가 앱을 삭제해버리면 그 크래시는 집계되지 않는다. 즉 가장 치명적인 크래시일수록 과소 집계되는 편향이 있다.
• SIGKILL에는 이 구조 전체가 무력하다. 핸들러를 등록할 수 없으므로 1단계에서 준비한 것이 아무 소용이 없다. Jetsam·워치독 종료가 별도 메커니즘으로 다뤄지는 근본 이유다.

실험 · 도구

"핸들러 안에서 malloc을 부르면 위험하다"는 말은 추상적이다. 직접 재현해보면 확실해진다.

import Darwin

// ⚠️ 학습용이다. 실제 앱에 넣지 말 것.
func installUnsafeHandler() {
    signal(SIGSEGV) { sig in
        // ❌ 여기서 하면 안 되는 것들 — 전부 힙/락/ObjC에 의존한다
        //    print("crashed")                 ← stdio + 락
        //    let s = "crash: \(sig)"          ← Swift String = 힙 할당
        //    NSLog("crashed")                 ← Foundation + ObjC 런타임
        //    URLSession.shared.dataTask(...)  ← 스레드 + 할당 + 락

        // ✅ 이것만 안전하다 — write(2)는 async-signal-safe
        let msg = "CRASH\n"
        msg.withCString { p in
            _ = write(STDERR_FILENO, p, strlen(p))
        }
        _exit(sig)   // exit(3)이 아니라 _exit(2). exit는 atexit 핸들러를 돌린다.
    }
}

더 결정적인 검증은 실제 사례를 읽는 것이다. Sentry의 iOS SDK에서 보고된 이슈 #8134는 이 함정이 실전에서 어떻게 터지는지 보여준다 — handleSignal 안에서 지연 초기화되는 _Thread_local 변수를 읽었는데, 그 지연 초기화가 내부적으로 malloc을 호출했다. 그 결과 _os_unfair_lock_recursive_abort로 프로세스가 중단됐고, 원래 크래시는 리포트에 남지 않았다. 이 실패 모드는 Q6에서 따로 다룬다.

메인 스레드 밖에서 실행되는 코드가 async-signal-safe한지 확인할 때 쓰는 도구는 이렇다.

# 핸들러가 어떤 심볼을 호출하는지 정적으로 확인 — malloc/objc/stdio 흔적을 찾는다
nm -u YourCrashHandler.o | grep -E 'malloc|free|objc_|printf|dispatch_'

# 런타임 검증: Xcode Scheme › Diagnostics › Malloc Stack Logging 을 끄고
# Thread Sanitizer 로 락 재진입을 관찰한다 (핸들러 경로를 반복 실행하는 테스트와 함께)

프로젝트 적용

대부분의 팀은 크래시 리포터를 직접 만들지 않는다. 그래도 이 원리를 알아야 하는 이유는 우리 코드가 크래시 경로에 끼어드는 경우가 있기 때문이다.

• NSSetUncaughtExceptionHandler를 직접 설치하지 않는다. 여기서 로그를 남기거나 서버로 보내려는 시도가 흔한데, 이 핸들러는 SDK가 설치한 것을 덮어써서 크래시 리포트를 통째로 유실시킬 수 있다. 꼭 필요하면 기존 핸들러를 저장했다가 마지막에 호출해야 한다.
• 크래시 직전에 뭔가 저장하려 하지 않는다. "죽기 전에 사용자 데이터만 저장하자"는 발상은 위험하다 — 힙이 손상된 상태에서 파일을 쓰면 멀쩡한 저장 파일까지 깨뜨릴 수 있다. 중요한 상태는 크래시 시점이 아니라 평상시에 원자적으로 저장해둬야 한다(P0 10장).
• 종료 직전 정리 로직은 applicationWillTerminate에 의존하지 않는다. 이 콜백은 정상 종료 경로에서만 불리고 크래시·SIGKILL에서는 불리지 않는다.

또 하나 실무 규칙 — 리포트가 안 올라오는 문제를 디버깅할 때 디버거를 떼야 한다. Xcode가 붙어 있으면 디버거가 시그널을 먼저 가로채므로 리포터의 핸들러가 실행되지 않는다. "내 기기에서는 크래시 리포트가 안 생긴다"의 십중팔구가 이것이다.

꼬리 질문

Q3. 시그널 핸들러와 Mach exception 핸들러는 무엇이 다른가?

CS 원리

XNU는 이름 그대로 Mach 마이크로커널과 BSD 층의 결합이다(P0 03장). 예외 처리에서 이 이중 구조가 그대로 드러난다.

CPU가 잘못된 메모리 접근 같은 트랩을 일으키면 커널이 받는다. 이때 커널의 처리 순서는 이렇다.

1. Mach 예외 전달 — 커널이 예외 포트로 메시지를 보낸다. 포트는 스레드 → 태스크(프로세스) → 호스트 순으로 계층적으로 조회되며, 각 층에 핸들러가 등록돼 있을 수 있다.
2. 핸들러가 메시지를 받고 "처리했다"고 응답하면 — 커널은 문제가 해결됐다고 보고 스레드 실행을 재개하거나 종료를 진행한다.
3. 아무도 처리하지 않으면 — 커널이 BSD 시그널로 변환해(EXC_BAD_ACCESS → SIGSEGV 등) 프로세스에 전달한다. 여기서 비로소 signal()로 등록한 핸들러가 실행된다.

이 순서에서 두 방식의 성질 차이가 전부 나온다.

Mach 방식의 결정적 장점은 "환자를 건드리지 않고 옆에서 관찰한다"는 점이다. 크래시 난 스레드는 정지된 채로 있고, 핸들러 스레드가 그 스레드의 레지스터와 스택을 읽는다. 그래서 힙 락 재진입 문제 자체가 발생하지 않고, 스택에 핸들러 프레임이 섞이지도 않는다.

iOS에서는

Mach 방식이 기술적으로 우월한데도 iOS 서드파티 리포터가 그대로 쓰지 못하는 이유는 API 공개 범위에 있다. Apple의 시스템 크래시 리포터는 Mach 예외 메커니즘을 쓰지만, 서드파티가 예외 메시지를 받아 안전하게 응답하는 데 필요한 API가 iOS에서 완전히 공개돼 있지 않다. 이 때문에 두 가지 실패가 가능하다.

• 프로세스가 잠긴다 — 예외 메시지에 제대로 응답하지 못하면 커널이 응답을 기다리며 프로세스가 멈춘 채로 남는다. 사용자 눈에는 "앱이 얼어붙은" 상태다.
• 시스템 리포터로 전달되지 않는다 — 우리가 예외 포트를 가로챈 뒤 원래 핸들러(시스템)로 넘기지 못하면, Apple의 크래시 리포트가 생성되지 않는다. 즉 Xcode Organizer와 기기의 분석 데이터에서 그 크래시가 사라진다.

두 번째가 실무에서 특히 아프다. 서드파티 SDK 대시보드에는 크래시가 보이는데 Apple 쪽에는 안 보이거나 그 반대인 상황이 생기고, 어느 쪽 숫자를 믿어야 하는지 판단이 어려워진다.

그래서 현실의 선택지는 대체로 셋이다.

1. 시그널 기반만 사용 — 안전하고 공개 API만 쓴다. 대신 async-signal-safe 제약을 정면으로 감당해야 하고, 스택 오버플로 대응에 sigaltstack이 필요하다.
2. Mach 기반을 쓰되 조심스럽게 체이닝 — 원래 예외 포트를 저장했다가 처리 후 반드시 넘긴다. 구현 난이도가 높다.
3. 둘을 조합 — Mach로 잡되 실패 시 시그널로 폴백하거나, 유형별로 나눠 담당시킨다.

덧붙여 디버거가 붙어 있으면 둘 다 무력화된다. 디버거는 태스크의 예외 포트를 자기가 차지하므로 우리 핸들러까지 메시지가 오지 않는다. 앞서 말한 "디버거를 떼고 테스트하라"의 커널 수준 이유가 이것이다.

실험 · 도구

예외 포트가 계층적으로 조회된다는 사실은 직접 확인해볼 수 있다.

import Darwin
import MachO

// 현재 태스크에 등록된 예외 포트를 조회한다 — 디버거를 붙였을 때와 뗐을 때를 비교해보자
func dumpExceptionPorts() {
    var masks = [exception_mask_t](repeating: 0, count: Int(EXC_TYPES_COUNT))
    var ports = [mach_port_t](repeating: 0, count: Int(EXC_TYPES_COUNT))
    var behaviors = [exception_behavior_t](repeating: 0, count: Int(EXC_TYPES_COUNT))
    var flavors = [thread_state_flavor_t](repeating: 0, count: Int(EXC_TYPES_COUNT))
    var count: mach_msg_type_number_t = mach_msg_type_number_t(EXC_TYPES_COUNT)

    let kr = task_get_exception_ports(
        mach_task_self_,
        exception_mask_t(EXC_MASK_BAD_ACCESS | EXC_MASK_BAD_INSTRUCTION |
                         EXC_MASK_ARITHMETIC | EXC_MASK_BREAKPOINT),
        &masks, &count, &ports, &behaviors, &flavors)

    guard kr == KERN_SUCCESS else { print("조회 실패: \(kr)"); return }

    print("등록된 예외 포트 \(count)개")
    for i in 0..<Int(count) {
        // port가 0이 아니면 누군가(디버거 또는 SDK)가 그 예외를 가로채고 있다는 뜻
        print(String(format: "  mask=0x%x port=0x%x behavior=%d",
                     masks[i], ports[i], behaviors[i]))
    }
}

확인 포인트는 명확하다 — Xcode 디버거를 붙이고 실행하면 포트가 잡혀 있고, 디버거 없이(기기에서 직접 앱 아이콘으로) 실행하면 비어 있거나 SDK가 잡은 포트만 보인다. 이 차이가 "디버거를 붙이면 크래시 리포트가 안 생기는" 이유를 눈으로 보여준다.

어느 방식으로 잡혔는지는 리포트에서도 단서가 나온다.

# Apple 크래시 리포트의 Exception Note 필드
#   EXC_CORPSE_NOTIFY  → Mach 예외 경로로 시스템이 "시체(corpse)"를 만들어 리포트한 것
# 이 노트가 있으면 시스템 리포터가 Mach 층에서 정보를 수집했다는 뜻이다.
#    ⚠️ iOS 15+ 의 .ips 는 JSON 이다. "Exception Type" 같은 필드명 문자열이 없으므로
#       grep 이 아니라 jq 로 파싱해야 한다. (첫 줄은 메타 헤더, 둘째 줄이 본문)
jq -s '.[1] | {type: .exception.type, signal: .exception.signal,
               subtype: .exception.subtype, termination: .termination}' \
   ~/Downloads/YourApp-crash.ips

# Console.app 이나 Xcode 가 "번역"해 보여주는 텍스트에서는 grep 이 통한다
grep -A2 "Exception Type" translated-report.txt

프로젝트 적용

대부분의 팀에서 이 지식이 실제로 쓰이는 지점은 SDK를 여러 개 붙였을 때의 충돌 진단이다.

• 크래시 리포팅 SDK를 둘 이상 붙이지 않는다. 둘 다 예외 포트나 시그널 핸들러를 잡으려 하면 나중에 초기화된 쪽이 이기거나, 체이닝이 어긋나 양쪽 다 리포트를 못 남기는 상황이 된다. A/B 비교를 위해 잠시 둘을 붙이는 경우가 있는데, 그 기간의 데이터는 신뢰할 수 없다는 점을 알고 있어야 한다.
• Apple 쪽 숫자와 SDK 숫자를 정기적으로 대조한다. Xcode Organizer의 크래시와 SDK 대시보드의 크래시가 크게 어긋나면 예외 포트 체이닝이 깨졌을 가능성이 높다.
• "앱이 얼어붙었다"는 제보를 워치독으로만 단정하지 않는다. 예외 처리가 잘못 얽히면 프로세스가 응답 없이 남을 수 있고, 이건 메인스레드 블로킹과 증상이 같지만 원인이 전혀 다르다.

꼬리 질문

Q4. Termination Reason 코드는 무엇을 말해주는가?

CS 원리

여기서 작동하는 원리는 정책적 종료에는 근거가 남아야 한다는 것이다. 프로세스가 스스로 잘못해서 죽으면 증거(스택·레지스터)가 프로세스 안에 남지만, 외부가 정책적으로 죽인 경우엔 프로세스 안에 아무 증거도 없다. 그래서 죽인 쪽이 이유를 기록해야 한다.

XNU에서 이 역할을 하는 것이 termination namespace + code 쌍이다. 네임스페이스는 "누가 죽였는가"(예: RUNNINGBOARD, JETSAM, SPRINGBOARD)를, 코드는 "왜 죽였는가"를 나타낸다. 리포트에는 이렇게 찍힌다.

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note:  EXC_CORPSE_NOTIFY
Termination Reason: Namespace RUNNINGBOARD, Code 0xdead10cc

Exception Codes가 전부 0인 것에 주목할 만하다 — 메모리 접근 위반이 아니므로 fault address 같은 것이 없다. 정보가 전부 Termination Reason에 있다는 신호다.

iOS에서는

Apple이 문서화한 코드표에서 iOS 실무 빈도 상위만 발췌하면 이렇다(문서에는 0xd00d2bad, watchOS 전용 0xc51bad01~03 등이 더 있다). 이 표는 외워두면 크래시 판독 속도가 크게 달라진다.

실무에서 특히 자주 오해받는 것이 0xdead10cc다. 이름 때문에 "교착 상태(deadlock) 때문에 죽었다"로 읽기 쉬운데, 실제 의미는 "앱이 서스펜드되는 시점에 파일 락이나 SQLite 락을 쥐고 있었다"이다. 다른 프로세스(예: 같은 App Group 컨테이너를 쓰는 익스텐션)가 그 파일에 접근하지 못하게 되므로 시스템이 앱을 죽인다.

Apple이 제시하는 해법도 구체적이다 — 메인스레드에서 beginBackgroundTask로 추가 실행 시간을 요청하되, 파일 쓰기를 시작하기 훨씬 전에 요청해야 한다. 쓰기가 끝나고 락을 놓을 시간까지 확보해야 하기 때문이다. 앱 익스텐션에서는 대신 ProcessInfo.performExpiringActivity를 쓴다.

scene-create watchdog transgression: application<com.example.MyCoolApp>:667
exhausted real (wall clock) time allowance of 19.97 seconds
 | WatchdogEvent: scene-create
 |  "Elapsed total CPU time (seconds): 15.290 (user 15.290, system 0.000), 28% CPU",
 |  "Elapsed application CPU time (seconds): 0.367, 1% CPU"

주의할 것은 이 값이 모든 상황에 적용되는 고정 임계가 아니라는 점이다. Apple은 전환 종류별 일반 허용치 표를 문서화하지 않았고, 널리 인용되는 "런치 20초 / scene-update 10초"는 관측값에서 나온 근사다. 실제 값은 기기·OS 버전·시스템 부하에 따라 달라진다. 그래서 고정 숫자에 맞춘 설계는 위험하고, 개별 리포트의 값은 신뢰할 수 있다.

실험 · 도구

0xdead10cc는 재현이 까다로워 보이지만 원리를 알면 간단하다.

import UIKit

// ⚠️ 재현 실험용. 실제 앱에서 이렇게 하면 안 된다.
final class DeadlockReproducer {
    private var handle: FileHandle?

    /// 공유 컨테이너 파일에 락을 걸고 놓지 않은 채 백그라운드로 간다
    func reproduce() {
        let url = FileManager.default
            .containerURL(forSecurityApplicationGroupIdentifier: "group.com.example.shop")!
            .appendingPathComponent("shared.db")

        handle = try? FileHandle(forWritingTo: url)
        // 배타적 락 획득 후 의도적으로 해제하지 않는다
        flock(handle!.fileDescriptor, LOCK_EX)

        // 이 상태에서 홈으로 나가 앱이 서스펜드되면 → 0xdead10cc
    }

    /// ✅ 올바른 패턴 — 백그라운드 진입 전에 반드시 놓는다
    func correct() {
        var taskID = UIBackgroundTaskIdentifier.invalid
        // 쓰기를 "시작하기 전에" 시간을 확보한다. 끝난 뒤에 요청하면 늦다.
        taskID = UIApplication.shared.beginBackgroundTask(withName: "db-write") {
            // 만료 핸들러: 시간이 다 되면 여기서라도 반드시 락을 놓는다
            self.releaseLock()
            UIApplication.shared.endBackgroundTask(taskID)
            taskID = .invalid
        }

        defer {
            releaseLock()
            if taskID != .invalid {
                UIApplication.shared.endBackgroundTask(taskID)
                taskID = .invalid
            }
        }

        performWrite()
    }

    private func releaseLock() {
        guard let h = handle else { return }
        flock(h.fileDescriptor, LOCK_UN)
        try? h.close()
        handle = nil
    }

    private func performWrite() { /* … */ }
}

재현 절차는 이렇다 — 실기기에서 앱을 실행하고 reproduce()를 호출한 뒤 홈 화면으로 나간다. 몇 분 대기하면 앱이 종료되고, 설정 › 분석 데이터에서 Termination Reason: Namespace RUNNINGBOARD, Code 0xdead10cc를 확인할 수 있다.

기기 로그로 실시간 관찰하는 방법도 있다.

# 종료 결정을 내리는 주체(runningboardd)의 로그를 본다
log stream --predicate 'process == "runningboardd"' --style compact --level info

# 이미 지나간 종료 기록만 추린다
log show --last 30m --predicate \
  'eventMessage CONTAINS "0xdead10cc" OR eventMessage CONTAINS "8badf00d"' --style compact

프로젝트 적용

이 코드표를 실제로 활용하는 방법은 분류를 자동화해 대시보드 축으로 만드는 것이다.

/// Termination Reason 코드를 대응 팀·대응 방법으로 매핑한다
enum TerminationCode: UInt32 {
    case watchdog          = 0x8badf00d
    case lockHeldOnSuspend = 0xdead10cc
    case thermal           = 0xc00010ff
    case diskSpace         = 0xbaddd15c
    case voipNoCall        = 0xbaadca11
    case bgTaskTimeout     = 0x2182bad2
    case bgURLSession      = 0x2182bad3
    case bgFetch           = 0x2182bad4

    /// 스택트레이스가 원인을 가리키는가 — 판독 방법을 가른다
    var stackIsCause: Bool { false }   // SIGKILL 계열은 전부 아니다

    var owner: String {
        switch self {
        case .watchdog, .thermal:                     return "성능"
        case .lockHeldOnSuspend, .bgTaskTimeout,
             .bgURLSession, .bgFetch:                 return "백그라운드 동작"
        case .diskSpace:                              return "저장소"
        case .voipNoCall:                             return "통화"
        }
    }

    var firstCheck: String {
        switch self {
        case .watchdog:          return "메인스레드 동기 I/O·네트워킹 (20장)"
        case .lockHeldOnSuspend: return "백그라운드 진입 시 파일·SQLite 락 해제 여부"
        case .thermal:           return "지속적 고CPU 작업, 열 상태 알림 구독 여부"
        case .diskSpace:         return "캐시 디렉터리 크기, 파일 정리 주기"
        case .voipNoCall:        return "CallKit 보고 누락"
        case .bgTaskTimeout, .bgURLSession, .bgFetch:
                                 return "백그라운드 작업 소요 시간과 분할"
        }
    }
}

운영 규칙 두 가지를 덧붙이면 좋다.

• 이 코드들을 "크래시"와 같은 목록에 섞어두지 않는다. 원인 유형도, 대응 팀도, 판독 방법도 다르다. 대시보드를 분리하면 "우리 크래시율이 나쁘다"가 아니라 "우리는 워치독이 문제다"라는 실행 가능한 결론이 나온다.
• 0xdead10cc는 App Group을 쓰는 앱에서 특히 확인한다. 익스텐션과 본 앱이 같은 파일을 공유하면 발생 확률이 크게 오르는데(24장), 익스텐션 쪽 코드가 원인인 경우가 많아 본 앱만 봐서는 못 찾는다.

꼬리 질문

Q5. EXC_RESOURCE에 NON-FATAL CONDITION이 붙는 것은 무슨 뜻인가?

CS 원리

운영체제가 자원 한도를 다루는 방식에는 두 가지 층이 있다.

• 소프트 리밋(soft limit) — 넘으면 경고한다. 프로세스에게 스스로 교정할 기회를 준다.
• 하드 리밋(hard limit) — 넘으면 종료한다. 협상은 없다.

이 구분이 존재하는 이유는 즉시 죽이는 것이 항상 최선은 아니기 때문이다. 일시적 스파이크로 죽이면 정상 앱까지 불안정해지고, 반대로 아무 신호 없이 방치하다 갑자기 죽이면 앱이 대비할 방법이 없다. 그래서 두 단계를 둔다.

EXC_RESOURCE는 이 소프트 리밋 층의 알림 메커니즘이다. 특이한 점은 알림을 "예외"라는 형태로 전달한다는 것인데, 그래서 크래시 리포트 인프라를 그대로 재사용할 수 있다 — 스택트레이스가 함께 캡처되므로 "한도를 넘긴 그 순간 무슨 코드가 돌고 있었는지"를 알 수 있다.

다만 여기에도 앞서 본 함정이 그대로 적용된다. 메모리 한도를 넘긴 순간의 스택은 마지막 할당 지점일 뿐 축적의 원인이 아니다. CPU·웨이크업 서브타입에서는 반대로 스택이 상당히 유용한데, 그 시점에 실제로 CPU를 태우고 있던 코드가 찍히기 때문이다.

iOS에서는

Apple 문서가 정의하는 서브타입은 넷이다.

CPU와 CPU_FATAL의 차이가 소프트/하드 리밋 구분과 정확히 대응한다. CPU는 대개 NON-FATAL CONDITION과 함께 오고, CPU_FATAL은 실제 종료를 동반한다. 후자는 주로 앱 익스텐션처럼 CPU 예산이 엄격한 환경에서 나타난다.

WAKEUPS는 진단이 흥미롭다. Apple 문서는 이 예외가 스레드 간 통신 API를 예상보다 자주 호출할 때 발생한다고 설명하면서, "통신이 워낙 잦기 때문에 크래시 리포트에는 대개 비슷한 백트레이스를 가진 백그라운드 스레드가 여러 개 나타난다"고 덧붙인다. 즉 서로 닮은 스레드가 여러 개 보이는 것 자체가 단서다.

MEMORY 서브타입이 실무적으로 가장 중요하다. 이건 P0 01장에서 다룬 per-process 메모리 한도의 경고 단계이고, 문서도 "종료로 이어지는 전조일 수 있다"고 명시한다. 그런데 많은 팀이 이 리포트를 노이즈로 취급해 필터링해버린다 — Jetsam 종료를 미리 알려주는 유일한 신호를 버리는 셈이다.

실험 · 도구

리포트에서 이 구분을 자동으로 뽑아내면 대시보드 분류가 쉬워진다.

# .ips 는 JSON 이므로 jq 로 EXC_RESOURCE 관련 필드를 뽑는다
jq -s '.[1].exception' YourApp-*.ips
#   { "type": "EXC_RESOURCE", "subtype": "MEMORY", ... }

# Console/Xcode 가 번역해 보여주는 텍스트라면 grep 이 통한다

# 전형적인 비치명 메모리 경고 출력:
#   Exception Type:    EXC_RESOURCE
#   Exception Subtype: MEMORY
#   Exception Note:    NON-FATAL CONDITION
#   Exception Message: Memory limit exceeded (Limit 1400 MB)
#
# 전형적인 치명적 CPU 초과 (익스텐션 등):
#   Exception Type:    EXC_RESOURCE
#   Exception Subtype: CPU_FATAL
#   Exception Message: CPU consumption exceeded (Limit 80% over 60s)

앱 안에서 자기 메모리 사용량을 관찰해 한도 접근을 감지할 수도 있다.

import Foundation
import os          // os_proc_available_memory() 는 os 모듈에 있다

/// 현재 프로세스의 실제 메모리 footprint (Jetsam이 보는 값에 가장 가깝다)
func currentFootprintBytes() -> UInt64? {
    var info = task_vm_info_data_t()
    var count = mach_msg_type_number_t(MemoryLayout<task_vm_info_data_t>.size / MemoryLayout<natural_t>.size)
    let kr = withUnsafeMutablePointer(to: &info) {
        $0.withMemoryRebound(to: integer_t.self, capacity: Int(count)) {
            task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), $0, &count)
        }
    }
    guard kr == KERN_SUCCESS else { return nil }
    return info.phys_footprint       // ← resident_size가 아니라 phys_footprint를 봐야 한다
}

/// 시스템이 이 프로세스에 부여한 대략적 한도
func memoryLimitBytes() -> UInt64 {
    // 정확한 한도를 조회하는 공개 API는 없다.
    // os_proc_available_memory()로 "남은 양"을 얻어 역산하는 것이 현실적이다.
    UInt64(os_proc_available_memory()) + (currentFootprintBytes() ?? 0)
}

// 사용 예: 큰 작업 전에 여유를 확인하고 작업 규모를 조절한다
let available = os_proc_available_memory()
print("남은 메모리: \(available / 1024 / 1024) MB")
if available < 200 * 1024 * 1024 {
    // 이미지 다운샘플 비율을 높이거나 캐시를 비운다
}

여기서 resident_size가 아니라 phys_footprint를 봐야 한다는 점이 중요하다. Jetsam이 판정에 쓰는 값이 footprint이고, 여기에는 P0 01장에서 본 압축된 메모리도 포함된다. resident_size만 보면 압축분이 빠져 실제보다 낮게 보인다.

프로젝트 적용

운영 규칙 셋으로 정리된다.

• NON-FATAL 리포트를 크래시 지표에서 분리하되 버리지는 않는다. 별도 지표(예: "메모리 경고율")로 추적하면 Jetsam 종료가 늘기 전에 회귀를 잡을 수 있다.
• MEMORY 경고는 스택이 아니라 "직전에 무엇을 했는가"로 조사한다. breadcrumb의 화면 전환 기록(18장 Q4)과 결합하면 "특정 화면 진입 후 경고가 몰린다"가 보인다. 이게 스택보다 훨씬 유용하다.
• CPU·WAKEUPS 경고는 스택을 그대로 활용한다. 특히 WAKEUPS에서 비슷한 백그라운드 스레드가 여러 개 보이면 타이머·폴링 루프를 의심한다.

덧붙여 메모리 한도는 기기와 익스텐션 종류에 따라 크게 다르다. 본 앱은 기기 RAM에 비례해 늘어나지만 익스텐션은 훨씬 낮은 고정값에 가깝다(24장). 그래서 "본 앱에서 잘 되던 이미지 처리가 공유 익스텐션에서 죽는" 상황이 흔하고, 이때 EXC_RESOURCE (MEMORY)가 먼저 뜨는 경우가 많다.

꼬리 질문

Q6. 크래시 리포터가 원래 크래시를 가리는 일은 왜 일어나는가?

CS 원리

이건 관측자 효과의 극단적 형태다. 18장 Q7에서 관측 도구가 대상의 성능을 바꾼다는 얘기를 했는데, 여기서는 관측 도구가 관측 대상 자체를 파괴한다.

메커니즘은 단순하다.

1. 원래 크래시(예: SIGSEGV)가 발생하고 리포터의 핸들러가 호출된다.
2. 핸들러가 안전하지 않은 호출(할당·락·ObjC)을 한다.
3. 그 호출이 실패하거나 교착하거나 abort()를 유발한다.
4. 프로세스는 2차 크래시로 종료된다. 시스템 크래시 리포트에는 2차 크래시가 기록된다.
5. 원래 크래시의 정보는 어디에도 남지 않는다.

여기서 특히 고약한 점은 실패가 결정적이지 않다는 것이다. 힙 락이 잡혀 있는지 여부는 크래시가 발생한 정확한 타이밍에 달렸으므로, 같은 버그라도 어떤 사용자에게는 정상 리포트가 나오고 어떤 사용자에게는 리포터가 죽는다. 재현이 극도로 어렵고 통계적으로만 드러난다.

더 근본적인 문제도 있다. 원래 크래시가 힙 손상이었다면 — 예를 들어 use-after-free나 버퍼 오버플로로 힙 메타데이터가 깨진 상태 — 리포터가 아무리 조심해도 할당 관련 동작은 위험하다. 즉 가장 심각한 종류의 버그일수록 리포터가 실패할 확률이 높다. 통계 편향이 여기서 또 발생한다.

iOS에서는

실제 사례를 보는 것이 가장 빠르다. sentry-cocoa 이슈 #8134의 구조는 이렇다.

• 시그널 핸들러 handleSignal 안에서 _Thread_local 변수를 읽었다. 코드만 보면 그냥 변수 읽기라 안전해 보인다.
• 그런데 C/C++의 스레드 로컬 변수는 첫 접근 시 지연 초기화될 수 있고, 그 초기화 경로가 내부적으로 malloc을 호출한다.
• 크래시 시점에 힙 락이 잡혀 있었다면 이 malloc이 이미 자기가 쥔 락을 다시 잡으려 하고, libsystem이 이를 감지해 _os_unfair_lock_recursive_abort로 프로세스를 중단시킨다.
• 결과 — 원래 크래시가 가려진다.

이 사례가 교훈적인 이유는 "변수 하나 읽는 것"조차 안전하지 않을 수 있다는 점이다. 소스 코드 수준에서는 할당이 전혀 보이지 않는다. 위험은 컴파일러와 런타임이 삽입한 코드에 숨어 있다.

Swift에서는 이런 함정이 더 많다. 다음은 전부 보이지 않는 힙 할당을 유발한다.

마지막 두 줄이 sentry 사례와 정확히 같은 패턴이다. "이미 초기화됐겠지"라는 가정이 틀리는 순간 위험한 코드가 실행된다.

실험 · 도구

내가 쓰는 SDK가 이 문제를 겪고 있는지 판별하는 법은 리포트의 패턴을 보는 것이다.

// 🚩 리포터가 죽은 리포트의 전형적 패턴
Exception Type:  EXC_CRASH (SIGABRT)

Thread 0 Crashed:
0   libsystem_kernel.dylib    __pthread_kill + 8
1   libsystem_pthread.dylib   pthread_kill + 268
2   libsystem_c.dylib         abort + 180
3   libsystem_platform.dylib  _os_unfair_lock_recursive_abort + 36   ← 락 재진입
4   libsystem_malloc.dylib    _malloc_zone_malloc_instrumented + 264 ← 핸들러 안의 malloc
5   libsystem_c.dylib         tlv_get_addr + 100                      ← 스레드 로컬 지연 초기화
6   SentryCrash               handleSignal + 152                      ← 리포터의 핸들러
7   libsystem_platform.dylib  _sigtramp + 56                          ← 여기부터 위가 2차 크래시
8   ???                       ???                                     ← 원래 크래시는 여기 아래에
9   ???                       ???                                        있었는데 잘려 있다

// 판별 신호 3가지
//  (1) _sigtramp 위쪽이 전부 시스템·리포터 심볼이고 우리 코드가 없다
//  (2) recursive_abort / malloc / tlv_get_addr 조합이 보인다
//  (3) 같은 스택의 이슈가 대시보드 상위에 대량으로 쌓여 있다

대시보드에서 이 패턴을 자동으로 찾는 방법도 있다.

# 인앱 프레임이 하나도 없는 이슈를 찾는다 — 리포터 자기 크래시의 강력한 신호
#   대부분의 백엔드가 "in-app frame 없음" 필터를 지원한다.

# 로컬 .ips 더미를 jq 로 분석한다 (.ips 는 JSON — 첫 줄 메타, 둘째 줄 본문)
# 1) 재진입 abort 흔적이 있는 리포트 수
for f in *.ips; do
  jq -s -e '.[1].threads[]?.frames[]?.symbol? // empty
            | select(test("_os_unfair_lock_recursive_abort"))' "$f" >/dev/null 2>&1 \
    && echo "$f"
done | wc -l

# 2) 크래시 스레드에 우리 바이너리 프레임이 하나도 없는 리포트 수
for f in *.ips; do
  jq -s -e --arg app "YourAppName" '
    .[1] as $r
    | ($r.usedImages | map(.name) | index($app)) as $idx
    | $r.threads[] | select(.triggered == true)
    | [ .frames[].imageIndex ] | index($idx) | not' "$f" >/dev/null 2>&1 \
    && echo "$f"
done | wc -l
#   → 이 비율이 갑자기 오르면 리포터 실패 또는 심볼화 문제 (21장 Q3)

발견했을 때의 대응은 SDK 업데이트가 1순위다. 이런 버그는 리포터 벤더가 고쳐야 하고, 대개 이미 알려져 있다. 임시 완화책으로는 문제가 되는 자동 계측 기능을 끄거나, 리포터를 다른 구현으로 교체하는 방법이 있다.

프로젝트 적용

우리 코드가 크래시 경로에 끼어들지 않게 하는 것이 실무의 핵심이다.

• 시그널 핸들러를 직접 설치하지 않는다. 정말 필요하다면 기존 핸들러를 sigaction으로 저장했다가 체이닝하고, 핸들러 본문은 write()와 사전 계산된 상수 문자열만 쓴다.
• NSSetUncaughtExceptionHandler도 마찬가지로 체이닝한다. (Q2)
• 크래시 리포팅 SDK를 두 개 이상 붙이지 않는다. (Q3) 서로의 핸들러를 덮어써 양쪽 다 실패할 수 있다.
• SDK 버전을 고정해두고 방치하지 않는다. 이 종류의 버그는 조용히 데이터를 망가뜨리므로, 릴리스 노트에 크래시 핸들러 관련 수정이 있으면 우선순위를 높여 반영한다.

그리고 지표로 감시하는 방법이 있다 — "인앱 프레임이 없는 크래시의 비율"을 추적한다. 이 비율이 갑자기 오르면 리포터 문제이거나 심볼화 문제(20장)다. 둘 다 조용히 진행되므로 능동적으로 보지 않으면 몇 달을 놓친다.

꼬리 질문

swiftc -O -c Handler.swift -o Handler.o
nm -u Handler.o | grep -E 'swift_alloc|swift_retain|malloc|objc_msgSend|_tlv_'

Q7. MetricKit과 자체 크래시 리포팅은 왜 둘 다 필요한가?

CS 원리

이건 신뢰의 경계(trust boundary) 문제다. 관측 주체가 관측 대상 안에 있으면 대상이 무너질 때 관측도 함께 무너진다. 밖에 있으면 대상이 무너져도 관측이 살아남지만, 대신 안에서만 알 수 있는 정보는 얻을 수 없다.

여기서 핵심은 "둘 다 부분적으로 눈이 멀었다"는 것이다. 어느 쪽도 완전하지 않으므로, 둘의 숫자가 어긋날 때 어느 쪽이 무엇에 눈이 먼지 알고 판단해야 한다.

iOS에서는

MetricKit이 제공하는 것을 정확히 알아두면 역할 분담이 명확해진다.

• 진단(diagnostic) 5종 — MXCrashDiagnostic(크래시), MXCPUExceptionDiagnostic(CPU 예외), MXHangDiagnostic(행), MXDiskWriteExceptionDiagnostic(디스크 쓰기 예외), 그리고 MXAppLaunchDiagnostic(느린 실행, iOS 16+). iOS 15 이상에서는 즉시 전달된다.
• 메트릭 — 실행 시간·응답성·메모리·디스크·배터리 등. 직전 24시간치를 하루 최대 한 번 전달한다.
• MXAppExitMetric — 포그라운드/백그라운드별 종료 유형 통계. 워치독·메모리 자원 한도·강제 종료를 OS가 직접 분류해준다. Q1에서 말한 "사용자 강제 종료와 워치독 구분"의 정답이 여기 있다.

사용법 자체는 간단하고, Apple은 구독·수신 호출이 앱 런치 같은 성능 민감 코드에서도 안전하다고 명시한다.

import MetricKit

final class AppMetrics: NSObject, MXMetricManagerSubscriber {
    static let shared = AppMetrics()

    func start() {
        MXMetricManager.shared.add(self)   // 런치 경로에서 호출해도 안전하다고 문서에 명시
    }

    // 하루 최대 1회 — 직전 24시간 집계
    func didReceive(_ payloads: [MXMetricPayload]) {
        for payload in payloads {
            // 종료 유형 분포 — 자체 리포터가 못 보는 SIGKILL 계열이 여기 있다
            if let exits = payload.applicationExitMetrics {
                let fg = exits.foregroundExitData
                upload(metric: "exit.fg.watchdog",      fg.cumulativeAppWatchdogExitCount)
                upload(metric: "exit.fg.memory",        fg.cumulativeMemoryResourceLimitExitCount)
                upload(metric: "exit.fg.badAccess",     fg.cumulativeBadAccessExitCount)
                upload(metric: "exit.fg.abnormal",      fg.cumulativeAbnormalExitCount)
                upload(metric: "exit.fg.normal",        fg.cumulativeNormalAppExitCount)

                let bg = exits.backgroundExitData
                upload(metric: "exit.bg.memory",        bg.cumulativeMemoryResourceLimitExitCount)
                upload(metric: "exit.bg.taskTimeout",   bg.cumulativeBackgroundTaskAssertionTimeoutExitCount)
                upload(metric: "exit.bg.cpuLimit",      bg.cumulativeCPUResourceLimitExitCount)
            }
            // 실행 시간 히스토그램 — 실사용자 기기 분포 (18장 Q7의 콜드 스타트 검증)
            if let launch = payload.applicationLaunchMetrics {
                uploadHistogram("launch.timeToFirstDraw", launch.histogrammedTimeToFirstDraw)
            }
        }
    }

    // iOS 15+ 에서는 즉시 전달
    func didReceive(_ payloads: [MXDiagnosticPayload]) {
        for payload in payloads {
            payload.crashDiagnostics?.forEach   { forward($0.jsonRepresentation()) }
            payload.hangDiagnostics?.forEach    { forward($0.jsonRepresentation()) }  // 20장
            payload.cpuExceptionDiagnostics?.forEach { forward($0.jsonRepresentation()) }
            if #available(iOS 16.0, *) {
                // 느린 콜드 스타트의 콜스택 — 18장 Q7·26장 Q3 과 직접 연결된다
                payload.appLaunchDiagnostics?.forEach { forward($0.jsonRepresentation()) }
            }
        }
    }

    private func upload(metric: String, _ value: Int) { /* … */ }
    private func uploadHistogram(_ name: String, _ h: MXHistogram<UnitDuration>) { /* … */ }
    private func forward(_ json: Data) { /* 자체 백엔드로 전달 */ }
}

중요한 실무 포인트 — MetricKit 페이로드를 그냥 두면 아무 데도 안 간다. Apple은 데이터를 앱에 전달만 하고, 그걸 서버로 보내 집계하는 것은 우리 몫이다. Xcode Organizer가 별도로 보여주는 값이 있지만 그건 사용자 동의 기반의 Apple 자체 수집이고, MetricKit 콜백과는 다른 경로다.

실험 · 도구

MetricKit은 실기기에서만 동작하고 하루 한 번 오므로 개발 중 검증이 까다롭다. Xcode가 페이로드 시뮬레이션 기능을 제공한다.

# Xcode 메뉴: Debug › Simulate MetricKit Payloads
#   → didReceive(_ payloads:) 콜백이 즉시 호출된다.
#   ⚠️ 실기기에서 실행 중이어야 하고, 시뮬레이터에서는 동작하지 않는다.

# 실제 페이로드가 오는지 확인하려면 앱을 하루 이상 실기기에서 사용한 뒤
# 콜백에 로그를 심어 확인한다.
log stream --predicate 'subsystem == "com.example.shop" AND category == "metrickit"' \
           --style compact

둘의 숫자를 대조하는 것이 이 챕터의 실전 활용이다. 다음 표를 팀 운영 지표로 만들어두면 유용하다.

프로젝트 적용

실무 구성은 이렇게 정리된다.

• 자체 리포터는 개별 사건 조사용. breadcrumb·태그·사용자 맥락이 붙어 있어 "이 사용자가 왜 실패했나"에 답한다. 즉시성이 필요한 알람도 여기서 건다.
• MetricKit은 기준선(ground truth)용. "우리가 실제로 얼마나 죽고 있나"의 정답에 가장 가깝다. 자체 리포터 숫자를 검증하는 데 쓴다.
• MXAppExitMetric은 크래시 대시보드와 분리해 별도 지표로. 워치독·메모리 종료는 크래시가 아니라 성능 문제이고 대응 팀이 다르다(Q4).
• 두 숫자의 비율을 지표로 만든다. 자체 리포터 건수 / MetricKit 크래시 건수가 1에서 크게 벗어나면 계측 자체에 문제가 생긴 것이다.

주의할 점 하나 — MetricKit 페이로드는 사용자 동의나 시스템 정책에 따라 안 올 수 있고, 특정 iOS 버전에서 전달이 누락되는 사례도 보고된 적이 있다. 그래서 MetricKit도 "완벽한 기준선"은 아니고, 둘이 서로를 검증하는 관계로 두는 것이 맞다.

꼬리 질문

출처 · 참고자료