18 · 프로덕션 관측성

여기서부터 P1이다. P0가 "이 개념은 무엇인가"를 다뤘다면, P1은 내 손을 떠나 사용자 기기에서 도는 앱을 어떻게 관측하고 판독하는가를 다룬다. 디버거를 붙일 수 없고, 재현 절차를 물어볼 수 없고, 로그를 더 찍어보려면 다음 릴리스를 기다려야 하는 환경이다. 이 챕터는 그 환경에서 무엇을 계측하고 무엇을 버릴지를 정하는 기준을 세운다.

Q1. 관측성과 모니터링은 무엇이 다른가?

CS 원리

관측성(observability)은 원래 제어 이론 용어다. 어떤 시스템이 관측 가능하다는 것은 외부에서 측정 가능한 출력만으로 내부 상태를 유한 시간 안에 결정할 수 있다는 뜻이다. 내부를 직접 열어볼 수 없다는 전제가 핵심이다 — 열어볼 수 있으면 관측성을 논할 이유가 없다.

소프트웨어로 옮기면 전제가 그대로 성립한다. 사용자 기기의 프로세스는 열어볼 수 없다. 우리가 가진 것은 그 프로세스가 밖으로 내보낸 신호뿐이고, 그 신호만으로 "그때 내부에서 무슨 일이 있었는가"를 역산해야 한다. 그래서 설계 문제는 이렇게 바뀐다.

• 무엇을 내보낼 것인가 — 내보내지 않은 상태는 영원히 복원 불가능하다.
• 얼마나 내보낼 것인가 — 전부 내보내면 비용·배터리·프라이버시가 무너진다.
• 어떤 축으로 쪼갤 수 있게 내보낼 것인가 — 이게 "새 질문에 답할 수 있는가"를 결정한다.

세 번째가 모니터링과 관측성을 가르는 지점이다. 값 하나를 숫자로 요약해 보내면(예: "평균 응답 시간 320ms") 나중에 "iPhone SE에서만 느렸나"를 물을 수 없다. 요약하는 순간 축이 사라지기 때문이다. 반대로 이벤트마다 기기·OS·화면·네트워크 종류를 차원(dimension)으로 붙여 보내면, 그 조합으로 나중에 쪼갤 수 있다. 관측성은 결국 차원을 얼마나 살려서 보냈는가의 문제다.

iOS에서는

모바일 클라이언트에는 서버에 없는 제약이 셋 더 붙는다.

• 배포 지연 — 서버는 로그를 더 찍고 5분 뒤 재배포할 수 있다. 앱은 심사와 사용자 업데이트를 기다려야 하고, 구버전 사용자는 영원히 업데이트하지 않는다. 그래서 "지금 안 넣은 계측은 이번 사고에서 못 쓴다"가 아니라 "앞으로 몇 달간 못 쓴다"가 된다.
• 전송 신뢰성 없음 — 기기는 오프라인일 수 있고, 배터리가 나갈 수 있고, 사용자가 앱을 스와이프로 죽일 수 있다. 이벤트는 유실을 전제로 설계해야 한다.
• 사용자 자원 소모 — 계측 트래픽은 사용자의 데이터 요금과 배터리를 쓴다. 서버 계측과 달리 비용을 우리가 아니라 사용자가 낸다.

이 세 제약 때문에 모바일 관측 설계의 기본값은 "일단 다 보내고 나중에 거른다"가 아니라 "보낼 가치가 증명된 것만 보낸다"가 된다. 서버 관측성 담론을 그대로 옮겨오면 배터리와 요금제에서 먼저 터진다.

실험 · 도구

차원을 버리면 무엇을 못 하게 되는지는 직접 확인하는 편이 빠르다. 같은 데이터를 두 방식으로 기록해보자.

import Foundation

struct RenderSample {
    let screen: String
    let device: String
    let osMajor: Int
    let durationMs: Double
}

// 실제 사용자 분포를 흉내낸 표본 — 특정 조합만 느리다
let samples: [RenderSample] = (0..<2000).map { i in
    let device = i % 10 == 0 ? "iPhone SE (3rd)" : "iPhone 15"
    let os = i % 3 == 0 ? 17 : 18
    // SE + iOS 17 조합에서만 렌더가 크게 느려지는 상황
    let slow = (device == "iPhone SE (3rd)" && os == 17)
    return RenderSample(screen: "checkout",
                        device: device,
                        osMajor: os,
                        durationMs: slow ? Double.random(in: 900...1400)
                                         : Double.random(in: 40...120))
}

// (A) 모니터링식 — 수집 시점에 평균 하나로 접는다
let monitored = samples.map(\.durationMs).reduce(0, +) / Double(samples.count)
print(String(format: "A. 평균만 저장: %.1f ms", monitored))
// → 약 116ms. 렌더 시간으로는 "그럭저럭 정상" 범위라 그냥 넘어가게 된다.
//    느린 조합이 전체의 3.35%(67/2000)뿐이라 평균에 거의 묻힌다.
//    여기서 더 파고들 방법이 없다는 것이 핵심이다.

// (B) 관측성식 — 차원을 살려 원본을 저장했다면 사후에 쪼갤 수 있다
let byCombo = Dictionary(grouping: samples) { "\($0.device) / iOS \($0.osMajor)" }
for (combo, group) in byCombo.sorted(by: { $0.key < $1.key }) {
    let sorted = group.map(\.durationMs).sorted()
    let p95 = sorted[Int(Double(sorted.count) * 0.95)]
    print(String(format: "B. %@ — n=%d p95=%.0f ms", combo, group.count, p95))
}
// → "iPhone SE (3rd) / iOS 17 — n=67 p95=1380 ms" 가 튀어나온다.
//    같은 원본에서 나온 결과인데 (A)로는 영원히 볼 수 없던 사실이다.

핵심은 (B)가 더 많은 데이터를 보내서 이긴 게 아니라는 점이다. 두 방식이 관찰한 이벤트 수는 같다. 차이는 요약 시점뿐이다. 수집 시점에 접으면 축이 사라지고, 저장 후에 접으면 언제든 다시 펼 수 있다.

프로젝트 적용

"차원을 살려라"를 무한정 적용하면 카디널리티가 폭발한다. 실무 기준은 세 단계로 정한다.

규칙 하나로 요약하면 "값의 종류가 유한하고 미리 열거할 수 있으면 차원, 아니면 본문"이다. /user/12345/orders/98765는 차원으로 쓰면 사용자 수만큼 축이 늘어나지만, /user/{id}/orders/{id}로 정규화하면 유한해진다. 원본 값이 필요하면 검색 축이 아니라 이벤트 본문에 담는다.

꼬리 질문

Q2. 로그·메트릭·트레이스는 각각 어떤 질문에 답하는가?

CS 원리

셋의 차이는 무엇을 축으로 삼는가에서 나온다.

가장 중요한 구분은 트레이스만 인과 구조를 갖는다는 점이다. 로그도 타임스탬프가 있으니 순서를 알 수 있을 것 같지만, 동시성이 있으면 시간 순서와 인과 순서가 어긋난다. 스레드 A의 로그와 스레드 B의 로그가 시간순으로 섞여 찍혔을 때, 그중 어느 것이 어느 요청에 속하는지는 타임스탬프로 복원되지 않는다. 트레이스는 각 구간에 부모 구간의 식별자를 명시적으로 달아 이 문제를 푼다 — 이게 22장에서 다룰 traceparent의 존재 이유다.

iOS에서는

셋 다 Apple이 제공하는 네이티브 수단이 이미 있다. 벤더 SDK 없이도 개념을 확인할 수 있다.

• 로그 — 통합 로깅(Logger / OSLog). subsystem·category로 필터 축을 만든다.
• 메트릭 — MetricKit이 OS 차원에서 집계한 값을 하루 한 번 넘겨준다. Xcode Organizer의 크래시율·행률·히치율도 같은 계열이다.
• 트레이스 — signpost(OSSignposter)가 구간의 시작·끝을 기록해 Instruments에서 구간 트리로 보여준다. 이름이 다를 뿐 span과 같은 개념이다.

차이는 도달 범위다. signpost는 개발 중 Instruments로만 보고, MetricKit은 사용자 기기에서 오지만 하루 한 번 집계돼서 온다. "지금 프로덕션에서 이 요청이 어디서 막혔나"를 실시간으로 보려면 결국 자체 계측이나 벤더 SDK가 필요하다. 셋 중 무엇이 부족한지 알고 도구를 고르는 것이 순서다.

실험 · 도구

같은 결제 요청을 세 방식으로 계측하면 각각이 무엇을 남기는지가 선명해진다.

import os
import OSLog

private let log = Logger(subsystem: "com.example.shop", category: "checkout")
private let signposter = OSSignposter(subsystem: "com.example.shop", category: "checkout")

func submitOrder(_ order: Order) async throws -> Receipt {
    // ── 트레이스: 구간에 이름을 주고 시작/끝을 짝지어 기록 ──
    let state = signposter.beginInterval("submitOrder", id: signposter.makeSignpostID())
    defer { signposter.endInterval("submitOrder", state) }

    // ── 로그: 개별 사건의 서술. 동적 문자열은 기본이 private이라 리댁션된다 ──
    log.notice("주문 제출 시작 items=\(order.items.count, privacy: .public)")

    do {
        let validated = try await validate(order)          // 하위 구간
        let receipt   = try await postToServer(validated)  // 하위 구간
        log.notice("주문 성공")
        // ── 메트릭: 접어서 세는 값. 차원은 유한한 것만 ──
        Counter.increment("checkout.result", dimensions: ["outcome": "success"])
        return receipt
    } catch {
        // 실패도 분류해서 센다 — "실패가 는다"가 아니라 "무슨 실패가 느는지" 보려고
        log.error("주문 실패 reason=\(String(describing: error), privacy: .public)")
        Counter.increment("checkout.result", dimensions: ["outcome": classify(error)])
        throw error
    }
}

// 실패 분류를 유한한 집합으로 고정한다 — 이게 메트릭 차원이 될 수 있는 조건
func classify(_ error: Error) -> String {
    switch error {
    case is TimeoutError:          return "timeout"
    case let e as HTTPError where (500...599).contains(e.status): return "server"
    case let e as HTTPError where (400...499).contains(e.status): return "client"
    case is DecodingError:         return "decode"
    default:                       return "other"
    }
}

Instruments에서 이 앱을 프로파일하고 os_signpost 계측기를 추가하면 submitOrder 구간이 막대로 나타나고, 그 안에 validate·postToServer가 중첩된 모양으로 보인다. 로그는 Console.app이나 log stream --predicate 'subsystem == "com.example.shop"'으로 따로 본다. 같은 코드 경로인데 보는 창이 다르다는 것이 셋의 관계를 잘 보여준다.

프로젝트 적용

셋을 다 붙이는 것이 목표가 아니다. 실무에서는 질문의 종류로 역산한다.

• "이번 릴리스에서 뭔가 나빠졌나?" → 메트릭. 릴리스별 크래시율·행률·주요 플로우 성공률만 있으면 된다. 여기에 로그를 쓰면 비싸고 느리다.
• "이 사용자의 결제가 왜 실패했나?" → 로그 + breadcrumb. 개별 사건의 서술이 필요하다.
• "결제가 느린데 어디가 느린가?" → 트레이스. 네트워크인지 디코딩인지 메인스레드 대기인지는 구간을 쪼개야 보인다.

흔한 실패 패턴은 로그로 메트릭을 대신하려는 것이다. "에러 로그 개수를 세서 에러율로 쓰자"는 처음엔 동작하지만, 로그 양이 늘면 샘플링·보관기한·검색 비용에 부딪히고, 로그 문구를 바꾸는 순간 지표가 조용히 끊긴다. 세어야 하는 값은 처음부터 세는 도구로 세는 것이 맞다.

꼬리 질문

Q3. 로그 레벨은 무엇을 바꾸는가?

CS 원리

로깅 시스템은 쓰기 비용과 보존 가치의 트레이드오프를 레벨이라는 축 하나로 압축한 것이다. 모든 메시지를 디스크에 남기면 I/O가 앱 성능을 갉아먹고 저장소가 찬다. 아무것도 안 남기면 사후 판독이 불가능하다. 그래서 실용적인 시스템은 계층을 둔다.

• 휘발 계층 — 메모리 링 버퍼. 쓰기가 매우 싸고, 프로세스가 죽거나 버퍼가 돌면 사라진다.
• 영속 계층 — 디스크. 쓰기가 비싸고, 용량 한도에 도달하면 오래된 것부터 지워진다.

레벨은 "이 메시지를 어느 계층까지 올릴 것인가"의 선언이다. 여기서 중요한 함의가 나온다 — 레벨은 사후에 바꿀 수 없다. 이미 메모리에만 쓰인 메시지를 나중에 "역시 중요했네" 하며 디스크로 옮길 수는 없다. 그래서 레벨 선택은 미래의 디버깅 가능성을 지금 결정하는 행위다.

iOS에서는

Apple 통합 로깅의 레벨별 동작은 공식 문서에 표로 명시돼 있다. 이 표는 외워둘 가치가 있다.

세 가지를 짚어야 한다.

• 기본값이 notice다. Logger.log("...")처럼 레벨을 안 주면 notice로 나가 디스크에 남는다. "가벼운 디버그 로그"라 생각하고 쓴 것이 실은 영속 로그일 수 있다.
• 디스크 저장소는 한도가 있고, 넘으면 오래된 것부터 지운다. 그래서 notice를 남발하면 정작 중요한 error·fault의 보존 기간이 짧아진다. 로그 예산은 제로섬이다.
• 레벨이 높을수록 느리다. Apple도 명시한다 — debug는 메모리에만 저장하므로 오버헤드가 매우 낮고, fault 같은 심각한 레벨은 추가 정보를 함께 수집하고 디스크에 쓰기 때문에 오버헤드가 크다. 뜨거운 경로에서 error를 반복 호출하면 그 자체가 성능 문제가 된다.

덧붙여 error와 fault는 activity 객체가 있으면 관련 프로세스 체인의 정보까지 함께 캡처한다. 이게 오버헤드 차이의 실체이기도 하고, 동시에 두 레벨이 사후 판독에서 강한 이유이기도 하다.

실험 · 도구

레벨이 실제로 보존을 가른다는 것은 기기에서 직접 확인할 수 있다.

import OSLog

let log = Logger(subsystem: "com.example.shop", category: "levels")

log.debug("이 줄은 디스크에 남지 않는다")
log.info("이 줄은 영속화를 미리 켜둔 경우에만 남는다")
log.notice("이 줄은 디스크에 남는다 (기본 레벨)")
log.error("이 줄도 남고, activity 체인 정보가 더 붙는다")
log.fault("이 줄도 남는다 — 가장 비싸다")

실행 후 Mac에서 기기 로그를 뜯어본다.

# 실시간 스트림 — 기기 로그를 보려면 --device 가 필요하다.
# debug/info 까지 보려면 --level 도 명시해야 한다.
log stream --device --predicate 'subsystem == "com.example.shop"' --level debug

# 지나간 로그는 "수집 → 조회" 두 단계다.
#   ⚠️ log show 에는 --device 옵션이 없다. 로컬 Mac 저장소나 아카이브만 읽는다.
#      그래서 기기 로그는 log collect 로 아카이브를 만든 뒤 그것을 show 한다.
log collect --device --start '2026-08-14 09:00:00' --output shop.logarchive
log show shop.logarchive --predicate 'subsystem == "com.example.shop"'          # debug 없음
log show shop.logarchive --predicate 'subsystem == "com.example.shop"' --info   # info 포함

확인 포인트는 이것이다 — log stream --level debug로는 5줄이 다 보이는데, 아카이브를 log show로 열면 debug가 사라져 있다. 스트리밍은 메모리에서 실시간으로 가로채는 것이고, show는 저장소를 읽는 것이라 그렇다. 사용자 기기에서 사후에 얻을 수 있는 것은 후자뿐이다.

프로젝트 적용

레벨 정책을 팀 규칙으로 못 박아두지 않으면 반드시 무너진다. 실무에서 쓸 만한 기준은 이렇다.

가장 흔한 실수는 루프 안에서 error를 찍는 것이다. 네트워크가 끊긴 상태에서 재시도 루프가 초당 수십 번 error를 찍으면, 디스크 I/O가 발생할 뿐 아니라 저장소 한도를 밀어내 정작 중요한 과거 로그를 지운다. 반복되는 실패는 첫 발생만 error로 남기고 이후는 카운터로 세는 편이 옳다.

꼬리 질문

Q4. Breadcrumb은 로그와 무엇이 다른가?

CS 원리

breadcrumb은 고정 크기 링 버퍼(circular buffer)다. 항목이 상한 N에 도달하면 가장 오래된 것을 덮어쓴다. 이 자료구조 선택에서 모든 성질이 따라 나온다.

• 메모리가 상수 — 앱이 며칠을 돌아도 breadcrumb이 차지하는 메모리는 늘지 않는다. 로그와 달리 무한히 자랄 걱정이 없다.
• 보존은 개수 기준이지 시간 기준이 아니다 — "최근 5분"이 아니라 "최근 N개"다. 초당 100개를 찍는 앱에서 N=100이면 breadcrumb은 사고 직전 1초만 담고 있다.
• 제로섬이다 — 항목 하나를 추가하면 반드시 다른 하나가 밀려난다. 로그처럼 "일단 남겨두자"가 성립하지 않는다.

이 제로섬 성질이 로그와의 근본적 차이다. 로그에서 시끄러운 항목은 비용을 늘릴 뿐이지만, breadcrumb에서 시끄러운 항목은 다른 정보를 파괴한다. 스크롤 이벤트를 breadcrumb으로 남기는 순간, 사용자가 30초 전에 눌렀던 버튼 기록은 사라진다.

iOS에서는

iOS 앱에서 자동 수집되는 breadcrumb은 대체로 네 갈래다 — 화면 전환(뷰 컨트롤러 생명주기), 사용자 인터랙션(터치·버튼), 네트워크 요청(URL·메서드·상태코드), 시스템 이벤트(메모리 경고·백그라운드 전환·배터리 상태). 자동 수집은 편하지만 두 가지를 반드시 손봐야 한다.

• URL이 통째로 들어간다 — 쿼리스트링에 토큰이나 개인정보가 있으면 그대로 새어 나간다. 경로 템플릿으로 정규화하거나 쿼리를 잘라내야 한다. (22장에서 자세히 다룬다.)
• 고빈도 화면이 버퍼를 먹는다 — 무한 스크롤 피드에서 셀 등장 이벤트를 자동 수집하면 순식간에 버퍼가 채워진다.

또 하나 iOS 고유의 함정은 breadcrumb이 메모리에만 있다는 점이다. 앱이 SIGKILL로 즉사하면(Jetsam·워치독) 메모리가 통째로 사라지므로 breadcrumb도 함께 사라진다. 크래시 리포터가 시그널을 잡아 디스크에 flush할 수 있는 경우에만 살아남는다. 즉 breadcrumb은 잡히는 크래시에는 강하고 잡히지 않는 종료에는 무력하다 — 이 비대칭이 19장의 주제로 이어진다.

실험 · 도구

링 버퍼의 제로섬 성질은 40줄이면 재현된다.

import Foundation

struct Crumb {
    let at: Date
    let category: String
    let message: String
}

/// 고정 크기 링 버퍼 — breadcrumb의 실제 자료구조
final class CrumbTrail {
    private var storage: [Crumb] = []
    private let limit: Int

    init(limit: Int) { self.limit = limit }

    func add(_ category: String, _ message: String) {
        storage.append(Crumb(at: Date(), category: category, message: message))
        if storage.count > limit {
            storage.removeFirst(storage.count - limit)   // 가장 오래된 것부터 밀려난다
        }
    }

    var snapshot: [Crumb] { storage }
}

// ── 시나리오: 결정적 단서(로그인)를 남기고, 스크롤이 쏟아진다 ──
let trail = CrumbTrail(limit: 8)

trail.add("auth", "로그인 성공 method=sso")     // ← 나중에 꼭 필요할 단서
trail.add("nav",  "장바구니 진입")

for i in 1...20 {                                // 무한 스크롤 자동 수집
    trail.add("ui", "cell willDisplay row=\(i)")
}

trail.add("http", "POST /orders → 500")          // 사고 직전 결정적 신호

print("버퍼에 남은 것:")
trail.snapshot.forEach { print("  [\($0.category)] \($0.message)") }
// [ui] cell willDisplay row=15 ... row=20
// [http] POST /orders → 500
//
// → "로그인 성공"과 "장바구니 진입"은 이미 사라졌다.
//   버퍼가 8칸인데 스크롤 이벤트 20개가 전부 밀어냈기 때문이다.

해결은 버퍼를 키우는 게 아니라 들어오는 것을 거르는 것이다. 위 코드에서 "ui" 카테고리를 필터링하거나, 같은 카테고리의 연속 항목을 하나로 접으면(cell willDisplay ×20) 8칸 안에 사고 재구성에 필요한 것이 전부 남는다.

프로젝트 적용

breadcrumb 정책은 "이 사고를 처음 보는 동료에게 이 목록만 보여줬을 때 무슨 일이 있었는지 설명되는가"를 기준으로 잡는다. 실무 체크리스트는 넷이다.

• 상태 전이만 남긴다 — "결제 화면 진입", "주소 선택 완료"처럼 되돌아보면 의미가 있는 지점만. 스크롤·호버·프레임 단위 이벤트는 제외.
• 연속 중복은 접는다 — 같은 항목이 반복되면 카운트로 합친다. 링 버퍼 한 칸으로 20번의 반복을 표현할 수 있다.
• 네트워크는 정규화해서 남긴다 — POST /orders/{id} → 500 형태. 전체 URL과 본문은 넣지 않는다.
• 실패 직전 맥락을 우선한다 — 버퍼가 부족하면 성공 경로를 줄이고 실패·경고를 남긴다.

덧붙여 breadcrumb과 로그를 같은 코드에서 이중으로 남기지 않는다. 둘 다 쓰면 유지보수 지점이 둘이 되고 문구가 어긋나기 시작한다. 실무에서는 로그를 남기는 얇은 함수 하나가 필요한 경우에만 breadcrumb도 함께 추가하도록 감싸는 편이 낫다.

꼬리 질문

Q5. 태그·컨텍스트·스코프 중 무엇으로 검색하는가?

CS 원리

이 구분은 데이터베이스 인덱스의 트레이드오프를 그대로 옮겨온 것이다. 인덱스를 만들면 검색이 빨라지지만 쓰기 비용과 저장 공간이 늘고, 카디널리티가 지나치게 높으면 인덱스의 이점이 사라진다(모든 행이 고유하면 인덱스가 테이블만큼 커진다). 관측 백엔드도 같은 제약 아래 있으므로 "모든 필드를 색인할 수는 없다"는 결론이 나오고, 그래서 색인 대상(태그)과 비색인 대상(컨텍스트)을 개발자가 나누게 한다.

스코프는 다른 종류의 문제를 푼다 — 횡단 관심사의 전파다. 이벤트가 발생하는 지점(에러가 throw된 곳)은 대개 맥락 정보를 갖고 있지 않다. 네트워크 계층의 디코딩 실패 지점이 "지금 사용자가 결제 화면에 있다"는 사실을 알 리 없다. 이 정보를 함수 인자로 계속 넘기면 모든 시그니처가 오염된다. 스코프는 이를 앰비언트 상태로 두어 이벤트 생성 시점에 자동으로 합쳐지게 한다. 개념적으로는 태스크 로컬 값이나 스레드 로컬 저장소와 같은 계열의 해법이다.

iOS에서는

iOS 앱에서 태그로 삼을 만한 것과 삼으면 안 되는 것은 꽤 명확하게 갈린다.

• 태그로 좋은 것 — 화면 이름, 앱 버전, OS 메이저, 기기 모델, 네트워크 종류(wifi/cellular/none), 로그인 여부, A/B 실험 그룹, 기능 플래그 상태. 전부 값의 종류가 유한하고 미리 열거 가능하다.
• 태그로 나쁜 것 — 사용자 ID, 주문 번호, 전체 URL, 타임스탬프, 에러 메시지 원문, 파일 경로. 값이 사실상 무한하다.

iOS 고유의 주의점은 스코프의 생명주기가 앱 생명주기와 어긋나기 쉽다는 것이다. 화면 진입 시 screen=checkout을 스코프에 넣고 이탈 시 지우는 패턴은, 뒤로 가기가 아니라 앱이 백그라운드로 갔다가 돌아오거나 딥링크로 다른 화면이 밀고 들어오면 지우는 코드가 실행되지 않는다. 그 결과 한참 뒤 다른 화면에서 난 에러에 screen=checkout이 붙어 있는 오염이 생긴다. 그래서 스코프는 진입·이탈 쌍으로 관리하기보다 진입 시 덮어쓰기로 두는 편이 안전하다.

또 하나, 스코프가 전역 상태라는 점이 동시성과 충돌한다. 여러 태스크가 동시에 스코프를 건드리면 어느 이벤트에 어떤 값이 붙을지 결정적이지 않다. 그래서 백그라운드 작업의 맥락은 전역 스코프가 아니라 그 작업 범위에만 적용되는 스코프로 격리해야 한다.

실험 · 도구

태그와 컨텍스트를 잘못 나누면 어떤 질문이 막히는지 직접 비교해보자.

import Foundation

struct Event {
    let title: String
    let tags: [String: String]        // 색인됨 — 검색·집계 가능
    let contexts: [String: Any]       // 비색인 — 읽기 전용
}

// ── (A) 잘못된 분류: 검색해야 할 것을 컨텍스트에, 못 쓸 것을 태그에 ──
let bad = Event(
    title: "결제 실패",
    tags: [
        "order_id": "ORD-2026-0814-99213",           // ❌ 카디널리티 무한
        "url": "https://api.shop.com/orders?token=eyJhbG…", // ❌ 무한 + 토큰 유출
    ],
    contexts: [
        "screen": "checkout",                         // ❌ 검색해야 하는데 색인 안 됨
        "network": "cellular",                        // ❌ 위와 같음
    ]
)

// ── (B) 올바른 분류 ──
let good = Event(
    title: "결제 실패",
    tags: [
        "screen": "checkout",        // ✅ 유한 — "결제 화면 에러만 보기"가 된다
        "network": "cellular",       // ✅ 유한 — "셀룰러에서만 나나?" 확인 가능
        "http_status": "500",        // ✅ 유한
        "app_version": "4.12.0",     // ✅ 유한 — 릴리스별 회귀 추적
    ],
    contexts: [
        "order": [                   // ✅ 상세는 읽히기만 하면 된다
            "id": "ORD-2026-0814-99213",
            "item_count": 3,
            "total": 48_000,
        ],
        "request": [
            "path": "/orders",       // ✅ 정규화된 경로. 쿼리·토큰 제거
            "method": "POST",
        ],
    ]
)

// (A)로는 "셀룰러에서 결제 화면 에러가 늘었나?"에 답할 수 없다.
// order_id 태그는 이벤트마다 고유해서 집계 축으로 아무 의미가 없고,
// 오히려 백엔드의 태그 인덱스를 터뜨린다.

판단이 애매할 때 쓰는 질문은 하나다. "이 값으로 '~인 것만 보여줘' 또는 '~별로 개수 세줘'를 하고 싶은가?" 그렇다면 태그, 아니면 컨텍스트다. 주문 번호는 "이 주문만 보여줘"가 아니라 이미 찾은 이벤트를 읽을 때 필요한 값이므로 컨텍스트다.

프로젝트 적용

태그 스키마는 코드로 고정해두는 것이 유지보수에 결정적이다. 문자열 리터럴로 흩어놓으면 screen과 screen_name이 공존하고, 오타 하나가 새로운 축을 만들어 조용히 데이터를 쪼갠다.

// 태그 키와 허용 값을 타입으로 못 박는다 — 오타와 카디널리티 폭발을 둘 다 막는다
enum ObservabilityTag {
    case screen(Screen)             // Screen은 열거형이라 값이 유한함이 보장된다
    case network(NetworkKind)
    case httpStatus(Int)
    case loggedIn(Bool)

    var pair: (key: String, value: String) {
        switch self {
        case .screen(let s):     return ("screen", s.rawValue)
        case .network(let n):    return ("network", n.rawValue)
        case .httpStatus(let c): return ("http_status", String(c))
        case .loggedIn(let b):   return ("logged_in", b ? "true" : "false")
        }
    }
}

enum Screen: String { case home, search, cart, checkout, orderDetail, settings }
enum NetworkKind: String { case wifi, cellular, none }

스코프 사용 규칙은 셋이다.

• 전역 스코프에는 세션 내내 유효한 것만 — 사용자 식별자, 앱 버전, 실험 그룹.
• 화면·작업 단위는 진입 시 덮어쓰기 — 이탈 시 지우기에 의존하지 않는다.
• 동시 실행되는 작업은 격리된 스코프로 — 전역을 건드리면 다른 태스크의 이벤트를 오염시킨다.

꼬리 질문

Q6. 같은 버그가 여러 이슈로 쪼개지는 이유는?

CS 원리

그룹핑은 동치 관계(equivalence relation)를 정의하는 문제다. 무한히 들어오는 이벤트를 유한한 이슈 집합으로 사상해야 하고, 이때 필요한 것은 "두 이벤트가 같은 원인인가"를 판정하는 함수다. 그런데 진짜 원인은 관측 불가능하므로, 실제로는 관측 가능한 특징에서 대리 키(surrogate key)를 뽑아 쓴다. 그게 지문이다.

대리 키를 쓰면 두 방향의 오류가 필연적으로 생긴다.

• 과분할(over-splitting) — 같은 원인인데 지문이 달라 여러 이슈가 된다. 지문 재료에 원인과 무관한 변동이 섞였을 때 발생.
• 과병합(over-merging) — 다른 원인인데 지문이 같아 한 이슈가 된다. 지문 재료가 원인을 구별하기에 부족할 때 발생.

둘은 트레이드오프 관계다. 지문 재료를 늘리면 과병합이 줄지만 과분할이 늘고, 줄이면 반대가 된다. 그래서 "완벽한 그룹핑"은 존재하지 않고, 어느 쪽 오류가 덜 아픈지를 상황마다 고르게 된다. 실무에서는 과분할이 더 아프다 — 이슈 목록이 노이즈로 덮여 우선순위를 판단할 수 없고, 각 이슈의 발생 횟수가 잘게 쪼개져 "얼마나 심각한지"를 알 수 없기 때문이다.

iOS에서는

iOS 앱에서 그룹핑이 깨지는 원인은 몇 가지로 정형화된다.

• 메시지에 가변값 삽입 — 가장 흔하다. 주문 번호, 사용자 ID, 타임스탬프, 파일 경로, 좌표값이 에러 메시지에 들어가는 경우.
• 심볼화 실패 — dSYM이 없으면 스택이 주소만 남아, 빌드마다 주소가 달라지면서 같은 버그가 릴리스별로 쪼개진다. (20장 주제와 직결)
• 인앱 프레임 부재 — 크래시가 시스템 프레임에서 발생하고 우리 코드 프레임이 스택에 없으면(예: 비동기 콜백 깊은 곳), 시스템 프레임 기준으로 묶여 서로 다른 버그가 한 덩어리가 된다.
• Swift 비동기 스택 — await를 넘나드는 호출은 연속된 스택이 아니라 재개 지점부터 시작하는 스택이라, 원래 호출자 정보가 잘려 그룹핑 재료가 빈약해진다.
• NSError 도메인·코드가 뭉뚱그려짐 — 서로 다른 네트워크 실패가 전부 같은 도메인·코드로 오면 한 이슈로 합쳐진다.

특히 비동기 스택 절단은 P0 02장에서 다룬 "Task는 스레드가 아니다"의 실무적 귀결이다. 스레드 스택은 호출 관계를 연속적으로 보존하지만, 태스크는 정지·재개하며 스택이 끊어지므로 크래시 리포트에서 인과 사슬이 짧아진다.

실험 · 도구

지문 계산을 흉내내면 무엇이 그룹핑을 깨는지 즉시 보인다.

import Foundation
import CryptoKit

struct Report {
    let type: String
    let message: String
    let frames: [String]     // 인앱 프레임만 추린 것
}

func fingerprint(_ r: Report) -> String {
    let material = ([r.type, r.message] + r.frames).joined(separator: "|")
    let digest = SHA256.hash(data: Data(material.utf8))
    return digest.map { String(format: "%02x", $0) }.joined().prefix(8).description
}

let frames = ["CheckoutViewModel.submit()", "OrderRepository.post(_:)"]

// ── (A) 메시지에 주문 번호가 들어간 경우 ──
let bad = (99213...99215).map {
    Report(type: "OrderError", message: "주문 ORD-\($0) 실패", frames: frames)
}
print("A. 지문:", bad.map(fingerprint))
// → ["3f9c1a2b", "8e04d771", "c15b6e9a"]  ← 전부 다르다. 이슈 3개로 쪼개진다.

// ── (B) 가변값을 메시지에서 뺀 경우 ──
let good = (99213...99215).map { _ in
    Report(type: "OrderError", message: "주문 제출 실패", frames: frames)
}
print("B. 지문:", good.map(fingerprint))
// → ["a72e0f45", "a72e0f45", "a72e0f45"]  ← 동일. 이슈 1개, 발생 3건.

// ── (C) 과병합 사례: 공통 헬퍼에서 던지면 프레임이 같아진다 ──
let merged = [
    Report(type: "APIError", message: "요청 실패", frames: ["APIClient.send(_:)"]),
    Report(type: "APIError", message: "요청 실패", frames: ["APIClient.send(_:)"]),
]
print("C. 지문:", merged.map(fingerprint))
// → 동일한데, 실제로는 결제 API 장애와 프로필 API 장애가 섞여 있을 수 있다.
//   이럴 땐 fingerprint에 엔드포인트를 명시적으로 추가해 갈라줘야 한다.

(C)가 보여주는 것이 중요하다. 과분할은 눈에 잘 띄지만(이슈가 폭증하니까) 과병합은 조용하다. 이슈 하나가 "발생 5만 건"으로 보여서 심각해 보이는데, 실은 서로 무관한 세 가지 문제가 섞여 있어 어느 것부터 고쳐야 할지 알 수 없는 상태다.

프로젝트 적용

그룹핑을 건강하게 유지하는 규칙은 셋이다.

• 에러 메시지는 상수로 — 가변값은 전부 컨텍스트나 태그로 뺀다. 이건 Q4의 breadcrumb 접기, Q5의 태그 분류와 정확히 같은 원리다. 가변 부분이 섞인 문자열은 어디서든 문제를 만든다.
• 공통 진입점에서는 fingerprint를 명시 — APIClient처럼 모든 요청이 지나는 지점에서 던지는 에러는 엔드포인트나 도메인을 지문에 추가해 갈라준다.
• 심볼화를 CI에서 보장 — dSYM 업로드가 빠지면 그룹핑이 릴리스마다 리셋된다. 수동 절차로 두면 반드시 언젠가 빠진다.

Swift에서 에러 타입을 설계할 때 이 원리를 미리 반영해두면 편하다.

// ❌ 메시지에 값이 섞여 지문이 흩어진다
struct OrderError: Error {
    let description: String   // "주문 ORD-99213 실패 (재고 0)"
}

// ✅ 분류는 타입으로, 값은 별도 필드로
enum OrderError: Error {
    case outOfStock          // 지문 재료가 되는 것은 이 case 이름
    case paymentDeclined
    case addressInvalid
    case serverUnavailable(status: Int)

    // 상세는 이벤트 컨텍스트로 따로 실어 보낸다
    var groupingKey: String {
        switch self {
        case .outOfStock:              return "order.out_of_stock"
        case .paymentDeclined:         return "order.payment_declined"
        case .addressInvalid:          return "order.address_invalid"
        case .serverUnavailable:       return "order.server_unavailable"
        }
    }
}

꼬리 질문

struct TracedError: Error {
    let underlying: Error
    let origin: String
    init(_ underlying: Error,
         function: String = #function, file: String = #fileID, line: Int = #line) {
        self.underlying = underlying
        self.origin = "\(file):\(line) \(function)"
    }
}

Q7. 관측 SDK는 앱에 어떤 비용을 부과하는가?

CS 원리

모든 계측은 관측자 효과를 갖는다 — 관측 행위 자체가 관측 대상을 바꾼다. 소프트웨어에서 이는 은유가 아니라 문자 그대로다. 계측 코드는 같은 CPU, 같은 메모리, 같은 I/O 대역폭을 대상 코드와 나눠 쓴다.

비용은 발생 위치에 따라 성격이 다르다.

핵심 원리는 비용이 균등하지 않다는 것이다. 초기화 비용은 사용자가 앱을 열 때마다 지불되고 그 순간은 사용자가 가장 민감한 구간이다. 반면 전송 비용은 백그라운드로 미룰 수 있어 체감이 훨씬 적다. 그래서 최적화 순서는 "총 비용이 큰 것"이 아니라 "체감 구간에 있는 것"부터다.

iOS에서는

iOS에서 특히 중요한 세 지점이 있다.

(1) 초기화 시점의 딜레마. 크래시 리포터는 시그널·예외 핸들러를 설치해야 하는데, 설치 이전에 발생한 크래시는 잡히지 않는다. 그래서 SDK는 application(_:didFinishLaunchingWithOptions:) 최상단이나 그보다 이른 시점에 초기화되기를 요구한다. 그런데 그 자리가 정확히 콜드 스타트 예산을 먹는 자리다. "빨리 초기화할수록 더 많이 잡지만 더 느려진다"는 정면 트레이드오프이고, 우회로가 없다.

(2) 메서드 스위즐링의 비용과 위험. 자동 계측은 대개 URLSession·뷰 컨트롤러 생명주기·UIApplication 메서드를 스위즐링해서 구현된다. 런타임에 메서드 구현을 교체하는 것이라 두 가지가 따라온다 — 초기화 시점에 클래스를 훑는 비용이 들고, 이후 모든 호출에 한 겹이 얹힌다. 게다가 다른 SDK도 같은 메서드를 스위즐링하면 순서에 따라 동작이 달라지는 재현 난이도 높은 버그가 생긴다.

(3) 메모리와 Jetsam. breadcrumb 버퍼, 전송 대기 큐, 세션 리플레이 버퍼는 전부 메모리를 상주시킨다. P0 01장에서 본 대로 iOS는 앱별 메모리 상한을 넘으면 시스템에 여유가 있어도 그 앱만 죽인다. 관측 SDK가 수십 MB를 상주시키면 관측 도구가 Jetsam 종료를 유발하는, 가장 역설적인 실패가 가능하다.

참고로 벤더가 공개하는 오버헤드 수치(예: 트레이싱 3% 미만, 프로파일링 5% 미만)는 특정 조건에서 측정한 값이다. 계측 지점 수, 샘플링 비율, 기기 성능에 따라 크게 달라지므로 자기 앱에서 직접 재는 것 말고 대안이 없다.

실험 · 도구

SDK가 실행 시간에 얼마를 더하는지는 직접 재야 한다. 가장 정직한 방법은 초기화를 켜고 끈 두 빌드의 콜드 스타트를 비교하는 것이다.

import os
import OSLog

// 프로세스 시작부터 첫 프레임까지를 signpost로 감싼다
let launchSignposter = OSSignposter(subsystem: "com.example.shop", category: "launch")

@main
struct ShopApp: App {
    init() {
        let state = launchSignposter.beginInterval("cold-launch",
                                                   id: launchSignposter.makeSignpostID())
        LaunchTrace.state = state

        // 컴파일 플래그로 관측 SDK 초기화를 켜고 끈다 → A/B 비교용 두 빌드
        #if OBSERVABILITY_ENABLED
        let t0 = ContinuousClock.now
        ObservabilitySDK.start(dsn: Secrets.dsn)
        let elapsed = ContinuousClock.now - t0
        // ⚠️ Duration.components 는 (seconds, attoseconds) 다. 둘 다 더해야 하고,
        //    1 ms = 1e15 attoseconds 이므로 attoseconds 는 1e15 로 나눈다.
        let ms = Double(elapsed.components.seconds) * 1000
               + Double(elapsed.components.attoseconds) / 1e15
        Logger(subsystem: "com.example.shop", category: "launch")
            .notice("SDK 초기화 \(ms, privacy: .public) ms")
        #endif
    }
    var body: some Scene { WindowGroup { RootView() } }
}

더 신뢰할 수 있는 건 OS가 재는 값이다. 두 가지를 함께 본다.

# 1) Instruments의 App Launch 템플릿으로 콜드 스타트 구간을 직접 프로파일
#    → pre-main(dyld) 구간과 post-main 구간이 나뉘어 나온다.
#      동적 프레임워크가 늘면 pre-main이, 초기화 코드가 늘면 post-main이 커진다.

# 2) MetricKit의 실사용자 실행 시간 히스토그램
#    MXAppLaunchMetric.histogrammedTimeToFirstDraw 를 릴리스별로 비교한다.
#    실험실 측정과 달리 저사양 기기·저온 캐시 상황이 섞여 들어온다.

주의할 함정 하나 — 시뮬레이터나 최신 기기에서만 재면 안 된다. 관측 SDK의 초기화 비용은 CPU가 느린 구형 기기에서 배로 늘어나고, 그 기기 사용자가 정확히 이탈에 민감한 사용자다. Apple도 성능 문제를 볼 때 기기 모델별로 필터링하라고 명시한다.

프로젝트 적용

관측 비용을 예산으로 관리하는 실무 방식은 이렇다.

• 콜드 스타트 예산을 숫자로 정한다 — "관측 SDK 초기화는 콜드 스타트의 5%를 넘지 않는다" 같은 기준을 두고 CI에서 회귀를 잡는다. 숫자가 없으면 매 릴리스마다 조금씩 늘어난다.
• 자동 계측을 전부 켜지 않는다 — 대개 기본값이 "다 켜짐"인데, 쓰지 않는 계측(예: 세션 리플레이, 파일 I/O 추적)은 꺼서 스위즐링 대상과 메모리를 줄인다.
• 전송은 반드시 지연·배치 — 이벤트마다 즉시 전송하면 라디오가 계속 깨어 배터리를 먹는다. 배치해서 보내거나 백그라운드 세션에 맡긴다.
• 메모리 상한을 건다 — breadcrumb 개수, 큐 크기에 명시적 상한을 두고 메모리 경고 시 비운다.
• 바이너리 크기를 릴리스마다 확인 — 26장에서 다룰 App Size Report로 SDK 추가 시 증가분을 기록한다.

그리고 판단 기준 하나를 팀에 공유해두면 좋다 — "이 계측이 없어서 못 고친 버그가 실제로 있었는가?" 관측 설정은 한번 켜면 끄기 어려운데(끄면 불안하니까), 이 질문을 주기적으로 던지지 않으면 아무도 안 보는 데이터를 계속 수집하며 비용만 낸다.

꼬리 질문

출처 · 참고자료