22 · 성능 계측과 샘플링

20장이 "메인스레드가 얼마나 막혔나"를 다뤘다면, 이 챕터는 "이 작업이 어디서 시간을 썼나"를 다룬다. 사용자가 결제 버튼을 누르고 3초를 기다렸을 때, 그 3초가 네트워크였는지 디코딩이었는지 메인스레드 대기였는지를 인과 순서대로 쪼개는 기술이다. 원리는 2010년 Google의 Dapper 논문이 세웠고, 그 개념이 오늘날 모든 트레이싱 시스템의 뼈대다. 여기서는 그 원리가 왜 그렇게 설계됐는지부터 시작해 모바일 클라이언트 고유의 제약까지 내려간다.

Q1. 트랜잭션과 Span은 무엇이며 어떤 단위로 나눠야 하는가?

CS 원리

Dapper 논문이 세운 데이터 모델은 놀랄 만큼 단순하다. 각 span은 다음을 갖는다.

• trace id — 이 span이 속한 전체 트레이스의 식별자. 트리 전체가 공유한다.
• span id — 이 span 자신의 식별자.
• parent span id — 부모 span의 id. 루트는 없다.
• 이름 · 시작 시각 · 종료 시각

이 네 개만으로 인과 트리가 복원된다. 로그와의 결정적 차이가 여기 있다(18장 Q2) — 로그는 시간 순서만 있지만, span은 부모를 명시하므로 동시 실행되는 작업들이 섞여도 각자의 트리로 분리된다.

분할 단위를 정하는 원리는 정보 이론적 관점에서 보면 명확하다. span을 하나 추가하면 그만큼 정보가 늘지만 비용도 는다. 그래서 "그 구간의 소요 시간을 아는 것이 의사결정을 바꾸는가"가 기준이 된다.

Dapper의 설계 목표도 같은 방향을 가리킨다 — 저오버헤드, 애플리케이션 수준 투명성, 대규모 보편 배치. 이를 위해 Dapper는 계측을 RPC·스레딩·제어흐름 같은 공통 라이브러리에만 넣었고, 그 결과 핵심 계측 코드가 C++ 1000줄 미만, Java 800줄 미만이었다. 모든 곳에 넣지 않았기 때문에 보편 배치가 가능했다는 점이 핵심이다.

iOS에서는

iOS 클라이언트에서 트랜잭션 경계로 삼기 좋은 것은 사용자 관점의 작업 단위다.

• 화면 진입 — 진입부터 콘텐츠가 표시될 때까지. 사용자가 체감하는 "로딩"의 실체다.
• 사용자 액션 — 결제 제출, 검색 실행, 업로드 시작.
• 앱 시작 — 프로세스 시작부터 첫 프레임까지(18장 Q7).
• 백그라운드 작업 — 동기화, 프리페치.

그리고 Apple 네이티브 수단으로도 구간 계측은 할 수 있다. signpost의 구간(interval)이 span의 시간 측정 부분에 대응한다. 다만 signpost에는 부모-자식 관계 개념이 없어 트리는 만들어지지 않는다 — Instruments가 중첩처럼 보여주는 것은 시간 포함 관계일 뿐이다.

import OSLog

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

func submitOrder(_ order: Order) async throws -> Receipt {
    // ⚠️ OSSignpostID 는 '동시에 열린 같은 이름의 구간'을 구분하는 식별자일 뿐,
    //    부모-자식 관계를 표현하지 않는다. Instruments 는 (subsystem, category, name, id)
    //    로 begin/end 를 짝지을 뿐 트리를 복원하지 않는다.
    //    → 구간마다 새 id 를 발급해야 동시 실행에서 짝짓기가 깨지지 않는다.
    let id = signposter.makeSignpostID()
    let root = signposter.beginInterval("checkout.submit", id: id)
    defer { signposter.endInterval("checkout.submit", root) }

    let validated = try await withInterval("validate") { try await validate(order) }
    let response  = try await withInterval("http.post") { try await api.post("/orders", validated) }
    let receipt   = try await withInterval("decode")   { try decoder.decode(Receipt.self, from: response) }
    return receipt
}

/// 구간을 감싸는 헬퍼 — 계측 코드가 본문을 어지럽히지 않게 한다
/// 구간마다 고유 id 를 발급한다. 같은 id 를 공유하면 동시 실행 시 짝짓기가 깨진다.
func withInterval<T>(_ name: StaticString,
                     _ body: () async throws -> T) async rethrows -> T {
    let state = signposter.beginInterval(name, id: signposter.makeSignpostID())
    defer { signposter.endInterval(name, state) }
    return try await body()
}

signpost의 한계는 프로덕션 수집이 제한적이라는 것이다. 일반 OSSignposter 구간은 Instruments로만 보지만, MXMetricManager.makeLogHandle(category:)로 만든 핸들에 찍으면 MetricKit이 MXSignpostMetric으로 집계해 준다(18장 Q2 꼬리질문). 다만 하루 한 번 집계된 히스토그램이라 개별 트레이스나 부모-자식 트리는 얻을 수 없다. 그래서 실무 구성은 구간 이름을 공유해 두 경로로 내보내는 방식이 좋다 — 개발 중에는 Instruments에서 보고, 프로덕션에서는 같은 이름의 span으로 백엔드에 보낸다.

실험 · 도구

span 트리를 직접 만들어보면 데이터 모델이 얼마나 단순한지 알 수 있다.

import Foundation

struct Span {
    let traceID: String
    let spanID: String
    let parentID: String?
    let name: String
    let start: ContinuousClock.Instant
    var end: ContinuousClock.Instant?

    var durationMs: Double? {
        guard let end else { return nil }
        let d = end - start
        return Double(d.components.seconds) * 1000
             + Double(d.components.attoseconds) / 1e15
    }
}

final class Tracer {
    private(set) var spans: [Span] = []
    private var stack: [String] = []          // 현재 열린 span id 스택
    private let traceID = Tracer.randomHex(32)

    func begin(_ name: String) -> String {
        let id = Tracer.randomHex(16)
        spans.append(Span(traceID: traceID, spanID: id,
                          parentID: stack.last,      // ← 부모는 스택 top
                          name: name, start: .now, end: nil))
        stack.append(id)
        return id
    }

    func end(_ id: String) {
        guard let i = spans.firstIndex(where: { $0.spanID == id }) else { return }
        spans[i].end = .now
        stack.removeAll { $0 == id }
    }

    /// 트리 모양으로 출력 — 병목이 들여쓰기로 드러난다
    func printTree(parent: String? = nil, depth: Int = 0) {
        for s in spans where s.parentID == parent {
            let pad = String(repeating: "  ", count: depth)
            let ms = s.durationMs.map { String(format: "%.0f ms", $0) } ?? "미완료"
            print("\(pad)└ \(s.name) — \(ms)")
            printTree(parent: s.spanID, depth: depth + 1)
        }
    }

    static func randomHex(_ n: Int) -> String {
        (0..<n).map { _ in "0123456789abcdef".randomElement()! }.reduce(into: "") { $0.append($1) }
    }
}

// 사용
let tracer = Tracer()
let root = tracer.begin("checkout.submit")
let http = tracer.begin("http.post")
Thread.sleep(forTimeInterval: 0.3)
tracer.end(http)
let decode = tracer.begin("decode")
Thread.sleep(forTimeInterval: 0.05)
tracer.end(decode)
tracer.end(root)
tracer.printTree()
// └ checkout.submit — 352 ms
//   └ http.post — 301 ms
//   └ decode — 51 ms

이 구현의 한계가 곧 실전 트레이싱의 어려움을 보여준다 — stack이 단일 배열이라 동시 실행을 다루지 못한다. 두 작업이 겹치면 부모 관계가 뒤섞인다. 실제 구현은 이 스택을 태스크 로컬이나 명시적 컨텍스트 전달로 관리해야 한다(18장 Q5 꼬리질문).

프로젝트 적용

span 설계에서 정할 것 넷.

• 이름 규칙을 고정한다. 영역.동작 형태(checkout.submit, http.post, db.query)로 통일하면 집계와 검색이 쉬워진다. 이름에 가변값을 넣지 않는다 — 18장 Q6의 그룹핑 문제가 그대로 재현된다.
• 깊이를 제한한다. 3~4단계면 대부분 충분하다. 더 깊어지면 읽기 어렵고 오버헤드가 는다.
• 계측 코드를 본문에서 분리한다. 위의 withInterval처럼 감싸는 헬퍼를 만들면 비즈니스 로직이 계측으로 어지러워지지 않는다. Dapper가 공통 라이브러리에만 계측을 넣어 투명성을 확보한 것과 같은 발상이다.
• 실패한 span도 닫는다. defer로 종료를 보장하고, 실패 사유를 span 속성으로 남긴다. 열린 채 사라진 span은 집계를 오염시킨다.

꼬리 질문

enum TraceContext {
    @TaskLocal static var currentSpanID: String?
}

func withSpan<T>(_ name: String, _ body: () async throws -> T) async rethrows -> T {
    let id = tracer.begin(name, parent: TraceContext.currentSpanID)
    defer { tracer.end(id) }
    return try await TraceContext.$currentSpanID.withValue(id) {
        try await body()
    }
}

Q2. 분산 트레이스는 클라이언트와 서버를 어떻게 잇는가?

CS 원리

분산 트레이싱의 근본 문제는 프로세스 경계를 넘어 컨텍스트를 전달하는 것이다. 한 프로세스 안에서는 태스크 로컬이나 스택으로 "현재 span"을 알 수 있지만, 네트워크를 건너면 그 정보가 사라진다.

해법은 대역 내 전달(in-band propagation)이다 — 요청 자체에 컨텍스트를 실어 보낸다. HTTP라면 헤더가 자연스러운 자리다.

W3C Trace Context가 정한 형식을 뜯어보면 설계 의도가 보인다.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             ── ──────────────────────────────── ──────────────── ──
             │                 │                        │          └ trace-flags (2 hex)
             │                 │                        └ parent-id (16 hex = 8바이트)
             │                 └ trace-id (32 hex = 16바이트)
             └ version (2 hex, 현재 00. ff는 무효)

• 고정 길이 — 파싱이 단순하고 빠르다. 가변 길이 구조를 피한 것은 모든 홉에서 파싱된다는 점을 고려한 설계다.
• trace-id 16바이트 — 전 세계 규모에서 충돌하지 않을 만큼 크다. 전부 0은 무효로 규정해 "값이 없음"과 구분한다.
• parent-id는 "호출자의 span id" — 이름이 parent인 이유는 받는 쪽 관점에서 부모이기 때문이다. 서버는 이 값을 부모로 삼아 자기 span을 만든다.
• version 필드 — 형식이 진화할 수 있도록. 모르는 버전을 만나면 안전하게 무시하거나 처리한다.

sampled 플래그가 특히 중요하다. trace-flags의 최하위 비트가 1이면 "호출자가 트레이스 데이터를 기록했을 수 있다"는 뜻이고, 이를 통해 하위 서비스들이 기록 결정을 맞춘다. 이게 없으면 클라이언트는 기록하는데 서버는 버려서 반쪽짜리 트레이스가 남는다 — Q3에서 다룰 문제다.

tracestate는 벤더별 정보를 담는 확장 슬롯이다. 여러 벤더가 각자 항목을 쉼표로 이어 붙이므로, 그 목록 자체가 트레이스가 지나온 경로를 드러낸다.

iOS에서는

클라이언트에서 이 헤더를 붙이는 것은 어렵지 않지만, 주의할 점이 몇 가지 있다.

import Foundation

struct TraceParent {
    let traceID: String     // 32 hex
    let spanID: String      // 16 hex
    let sampled: Bool

    /// W3C traceparent 헤더 값 생성
    var headerValue: String {
        let flags = sampled ? "01" : "00"
        return "00-\(traceID)-\(spanID)-\(flags)"
    }

    /// 유효성 검사 — 전부 0인 값은 무효라고 스펙이 규정한다
    var isValid: Bool {
        traceID.count == 32 && spanID.count == 16
        && traceID != String(repeating: "0", count: 32)
        && spanID  != String(repeating: "0", count: 16)
        && traceID.allSatisfy(\.isHexDigit) && spanID.allSatisfy(\.isHexDigit)
    }
}

extension URLRequest {
    mutating func attach(_ tp: TraceParent, tracestate: String? = nil) {
        guard tp.isValid else { return }
        setValue(tp.headerValue, forHTTPHeaderField: "traceparent")
        if let tracestate { setValue(tracestate, forHTTPHeaderField: "tracestate") }
    }
}

// ── 사용: 우리 서버로 가는 요청에만 붙인다 ──
func makeRequest(_ url: URL, span: Span) -> URLRequest {
    var req = URLRequest(url: url)
    // ⚠️ 서드파티 도메인에는 붙이지 않는다 — 내부 식별자가 외부로 새어 나간다
    if TrustedHosts.contains(url.host ?? "") {
        req.attach(TraceParent(traceID: span.traceID,
                               spanID: span.spanID,
                               sampled: span.isSampled))
    }
    return req
}

모바일 클라이언트 고유의 제약 셋을 짚어야 한다.

(1) 클럭을 신뢰할 수 없다. 사용자 기기의 벽시계는 임의로 바뀔 수 있다. 그래서 구간 길이는 반드시 단조 시계(ContinuousClock)로 재고, 서버 span과 시간축을 맞출 때는 절대 시각을 그대로 믿지 않는다. 클라이언트 span이 서버 span보다 나중에 시작한 것처럼 보이는 물리적으로 불가능한 트레이스가 흔히 나온다. (P0 16장 Q4의 연장선이다.)

(2) 헤더가 외부로 나갈 수 있다. 우리 서버가 아닌 곳에 traceparent를 붙이면 내부 추적 식별자가 제3자에게 전달된다. 허용 호스트 목록으로 제한해야 한다. 자동 계측이 모든 요청에 헤더를 붙이는 구현이라면 특히 확인이 필요하다.

(3) CORS. 웹뷰에서 나가는 요청이라면 서버가 traceparent를 허용 헤더로 선언해야 한다. 안 하면 요청이 실패한다.

실험 · 도구

헤더가 제대로 붙고 서버가 이어받는지는 직접 확인해야 한다.

# 1) 헤더 형식 검증 — 스펙에 맞는지 정규식으로 확인
echo "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01" \
  | grep -E '^[0-9a-f]{2}-[0-9a-f]{32}-[0-9a-f]{16}-[0-9a-f]{2}$' \
  && echo "형식 OK"

# 2) 전부 0인 무효값 검출
for v in "00000000000000000000000000000000" "0000000000000000"; do
  echo "$v" | grep -qE '^0+$' && echo "❌ 무효: $v"
done

# 3) 실제 요청 확인 — 프록시로 헤더를 들여다본다
#    Charles/Proxyman 또는 로컬 서버로 요청을 받아 헤더를 출력
python3 -m http.server 8080 &    # 간단 확인용
# 더 정확히는 헤더를 에코하는 스크립트를 쓴다

// 4) 앱 안에서 검증 — 디버그 빌드에서 나가는 요청의 헤더를 로깅한다
/// ⚠️ URLProtocol.registerClass 만으로는 URLSession 트래픽을 못 가로챈다.
///    URLSessionConfiguration.protocolClasses 맨 앞에 넣어야 한다:
///      config.protocolClasses = [TraceHeaderInspector.self] + (config.protocolClasses ?? [])
final class TraceHeaderInspector: URLProtocol {
    override class func canInit(with request: URLRequest) -> Bool {
        #if DEBUG
        if let tp = request.value(forHTTPHeaderField: "traceparent") {
            let host = request.url?.host ?? "?"
            // 외부 도메인에 붙었다면 즉시 잡아낸다
            assert(TrustedHosts.contains(host), "❌ 외부 호스트 \(host)에 traceparent 유출")
            Logger(subsystem: "com.example.shop", category: "trace")
                .debug("→ \(host, privacy: .public): \(tp, privacy: .public)")
        }
        #endif
        return false     // 실제로 가로채지는 않는다
    }
}

클럭 문제를 재현해보는 것도 유익하다.

// 벽시계와 단조 시계의 차이 — 기기 시각을 바꾸면 결과가 갈린다
let wallStart = Date()
let monoStart = ContinuousClock.now

// (이 사이에 설정 › 일반 › 날짜 및 시간에서 시각을 1시간 뒤로 바꿔본다)
Thread.sleep(forTimeInterval: 5)

print("벽시계 측정: \(Date().timeIntervalSince(wallStart)) 초")   // ← 음수가 나올 수 있다
print("단조 측정:  \(ContinuousClock.now - monoStart)")           // ← 항상 약 5초

프로젝트 적용

분산 트레이스를 실제로 쓰려면 서버 팀과 합의가 필요하다. 정할 것 넷.

• 헤더 표준을 W3C로 통일한다. 벤더 고유 헤더(x-…-trace-id 등)를 쓰면 나중에 백엔드를 바꿀 때 양쪽을 다 고쳐야 한다. 표준을 쓰면 이식성이 생긴다.
• 샘플링 결정 주체를 정한다. 클라이언트가 정하고 서버가 따를지, 서버가 재결정할지. 대개 클라이언트가 정하고 서버가 존중하는 쪽이 트레이스 완결성에 유리하다(Q3).
• 허용 호스트 목록을 코드로 관리한다. 하드코딩보다 설정으로 두되, 기본값은 차단이어야 한다.
• 시간축 불일치를 다루는 규칙을 정한다. 클라이언트 span과 서버 span의 시각이 어긋날 때 어느 쪽을 기준으로 표시할지, 음수 구간을 어떻게 표시할지.

그리고 실용적 팁 하나 — 서버 응답에 처리 시간을 담아 보내면 클럭 문제를 상당 부분 우회할 수 있다. 클라이언트가 잰 "왕복 시간"에서 서버가 알려준 "서버 처리 시간"을 빼면 네트워크 구간이 나오고, 이 계산은 양쪽 시계가 안 맞아도 성립한다.

꼬리 질문

Q3. 샘플링은 왜 트레이스 전체 단위로 해야 하는가?

CS 원리

수식으로 보면 명확하다. span 하나가 샘플링될 확률을 p, 트레이스의 span 수를 n이라 하자.

• 독립 샘플링 — 트레이스가 온전할 확률 = pⁿ. p=0.1, n=5면 0.00001(십만 분의 1).
• 트레이스 단위 샘플링 — 트레이스가 온전할 확률 = p. p=0.1이면 0.1.

같은 데이터 양을 보내면서 온전한 트레이스 수가 1만 배 차이난다. 그리고 독립 샘플링에서 남는 나머지 데이터는 버려지는 것이 아니라 더 나쁘다 — 조각난 트레이스가 저장 공간을 차지하면서 분석을 방해한다.

Dapper의 해법은 우아하다. trace id 자체를 샘플링 결정의 입력으로 쓴다.

sampled = hash(trace_id) < threshold

이 방식의 성질이 결정적이다.

• 결정적(deterministic) — 같은 trace id면 어느 노드에서 계산해도 같은 답이 나온다.
• 조율 불필요 — 노드끼리 통신하지 않아도 자동으로 일치한다.
• 균일 — trace id가 무작위이므로 해시도 균일 분포다.

실제로는 여기에 명시적 전달이 더해진다. 시작점이 결정한 결과를 traceparent의 sampled 비트로 실어 보내면, 하위 노드는 해시를 계산할 필요도 없이 플래그만 보고 따르면 된다. 스펙 표현으로는 "하위 서비스가 기록 결정을 조율하는 데 도움이 된다"이다.

iOS에서는

클라이언트가 트레이스의 시작점인 경우가 대부분이라, 샘플링 결정 권한이 우리에게 있다. 이건 책임이기도 하다 — 여기서 버리면 서버 쪽도 그 트레이스를 못 본다.

결정 방식은 두 갈래다.

모바일에서 동적 판정이 특히 유용한 이유는 트랜잭션의 중요도 차이가 크기 때문이다. 결제 플로우는 하루 수천 건인데 스크롤 트랜잭션은 수백만 건이다. 같은 비율을 쓰면 결제 표본이 너무 적거나 스크롤 데이터가 너무 많다.

/// 트랜잭션 이름과 상황에 따라 샘플링 비율을 다르게 준다
func sampleRate(for name: String, context: TraceContext) -> Double {
    // 1. 실패는 무조건 기록한다 — 희귀하고 가장 가치 있다
    if context.hasError { return 1.0 }

    // 2. 느린 것도 무조건 — 병목 조사의 핵심 표본
    if let elapsed = context.elapsedSoFar, elapsed > .seconds(3) { return 1.0 }

    // 3. 나머지는 트랜잭션 종류별로
    switch name {
    case "checkout.submit", "payment.process":  return 1.0    // 저빈도·고가치
    case "app.launch":                          return 0.1
    case "screen.load":                         return 0.05
    case "list.scroll":                         return 0.001  // 고빈도·저가치
    default:                                    return 0.01
    }
}

여기서 2번(느린 것은 무조건)은 구현이 까다롭다. 소요 시간은 끝나야 알 수 있는데 샘플링 결정은 시작할 때 해야 하기 때문이다. 해법은 두 가지다 — 모든 트레이스를 일단 메모리에 기록해두고 끝날 때 전송 여부를 결정하거나(tail-based), 시작 시점의 힌트(직전 실행에서 이 화면이 느렸는지)로 추정한다. 전자는 메모리 비용이 크고, 후자는 부정확하다. 클라이언트에서는 짧은 트랜잭션에 한해 tail-based가 현실적이다.

실험 · 도구

두 샘플링 방식의 차이를 시뮬레이션으로 확인해보자.

import Foundation

let p = 0.3
let spansPerTrace = 5
let traceCount = 100_000

// (A) 독립 샘플링 — span마다 따로 판정
var intactA = 0, spansSentA = 0
for _ in 0..<traceCount {
    let kept = (0..<spansPerTrace).filter { _ in Double.random(in: 0...1) < p }.count
    spansSentA += kept
    if kept == spansPerTrace { intactA += 1 }
}

// (B) 트레이스 단위 — trace id 해시로 한 번 판정
var intactB = 0
var spansSentB = 0
for _ in 0..<traceCount {
    let traceID = UInt64.random(in: 0...UInt64.max)
    // 결정적 판정: 해시 값이 임계 아래면 채택. 모든 노드가 같은 답을 낸다.
    let sampled = Double(traceID % 10_000) / 10_000 < p
    if sampled { intactB += 1; spansSentB += spansPerTrace }
}

print(String(format: "A 독립:     온전한 트레이스 %d개 (%.4f%%), 전송 span %d개",
             intactA, Double(intactA) / Double(traceCount) * 100, spansSentA))
print(String(format: "B 트레이스: 온전한 트레이스 %d개 (%.2f%%), 전송 span %d개",
             intactB, Double(intactB) / Double(traceCount) * 100, spansSentB))

// A 독립:     온전한 트레이스 243개 (0.2430%), 전송 span 149,8xx개
// B 트레이스: 온전한 트레이스 29981개 (29.98%), 전송 span 149,9xx개
// → 전송한 span 총량은 거의 같은데(둘 다 약 15만) 쓸 수 있는 트레이스가 약 123배 차이난다.

결정적 샘플링이 여러 노드에서 같은 답을 내는지도 확인할 수 있다.

// 같은 trace id에 대해 서로 다른 "노드"가 독립적으로 판정해도 결과가 같아야 한다
func decide(traceID: String, rate: Double) -> Bool {
    // trace id의 하위 비트를 균일 난수로 취급한다 (W3C trace-id는 무작위이므로 유효)
    let tail = String(traceID.suffix(8))
    guard let v = UInt32(tail, radix: 16) else { return false }
    return Double(v) / Double(UInt32.max) < rate
}

let tid = "4bf92f3577b34da6a3ce929d0e0e4736"
print(decide(traceID: tid, rate: 0.3))   // 클라이언트
print(decide(traceID: tid, rate: 0.3))   // 게이트웨이
print(decide(traceID: tid, rate: 0.3))   // 백엔드 서비스
// → 셋 다 같은 값. 서로 통신하지 않았는데 자동으로 일치한다.

프로젝트 적용

샘플링 정책에서 정할 것 다섯.

• 결정 지점을 하나로 고정한다. 트레이스 시작점(대개 클라이언트)에서만 결정하고, 이후는 traceparent의 플래그를 따른다.
• 실패와 이상치는 항상 기록한다. 이것들이 가장 정보량이 크고 가장 희귀하다. 균일 샘플링은 정확히 이런 것들을 놓친다.
• 트랜잭션 종류별 비율을 설정으로 뺀다. 코드에 하드코딩하면 조정할 때마다 릴리스가 필요하다. 원격 설정으로 두면 사고 중에 임시로 올릴 수 있다.
• 보정 계수를 함께 전송한다. 비율이 종류마다 다르면 집계 시 원래 규모를 복원해야 한다. 각 트레이스에 샘플링 비율을 실어 보내면 백엔드가 가중치로 쓸 수 있다.
• 서버 팀과 합의한다. 클라이언트가 1.0으로 올렸는데 서버가 0.01로 잘라버리면 여전히 반쪽이다.

꼬리 질문

// 트레이스에 샘플링 비율을 남긴다 — 백엔드가 가중치로 쓴다
span.setAttribute("sampling.rate", value: rate)
span.setAttribute("sampling.weight", value: 1.0 / rate)

Q4. 샘플링 비율은 얼마로 잡아야 하는가?

CS 원리

표본 수와 추정 정확도의 관계는 통계학의 기본 결과로 정리된다. 비율 p를 추정할 때 표본 n개의 표준오차는 대략 √(p(1−p)/n)이다. 여기서 핵심 성질이 나온다 — 정확도는 표본 수의 제곱근에 비례한다. 오차를 절반으로 줄이려면 표본이 4배 필요하다.

이 관계가 실무에서 뜻하는 바는 이렇다.

특히 분위수는 표본을 잡아먹는다는 점이 중요하다. p99를 보려면 상위 1%가 통계적으로 의미 있을 만큼 쌓여야 하는데, 표본 100건이면 그 1%는 단 1건이다. 그 한 건이 우연히 이상치면 p99가 통째로 흔들린다.

희귀 사건 쪽은 계산이 더 직관적이다. 발생률 r인 사건을 n개 표본에서 한 번도 못 볼 확률은 (1−r)ⁿ이다. r=0.001, n=1000이면 약 37%가 되어, 천 건을 봐도 세 번 중 한 번은 놓친다. 이게 Q3에서 "균일 샘플링은 희귀 사건을 못 본다"고 한 것의 수치적 근거다.

iOS에서는

모바일에서 비율을 정할 때 고려할 축이 세 개 더 붙는다.

• 사용자당 비용. 서버는 비율을 올려도 회사가 비용을 내지만, 클라이언트는 사용자의 데이터 요금과 배터리가 늘어난다(18장 Q7). 그래서 같은 통계적 필요라도 모바일에서는 문턱이 높다.
• 사용자 수 대비 트랜잭션 수. 서버는 요청 수가 곧 표본 수지만, 클라이언트는 사용자 수도 봐야 한다. 표본 1000건이 사용자 10명에게서 나왔다면 그 10명의 기기·네트워크 특성에 편향된다. "표본 수"와 "표본을 낸 사용자 수"를 함께 봐야 한다.
• 전송 지연. 오프라인 큐 때문에 표본이 며칠에 걸쳐 도착한다. "오늘 1000건"이 오늘 발생한 1000건이 아니다.

비율을 역산하는 절차는 이렇다.

/// 필요 표본 수에서 샘플링 비율을 역산한다
struct SamplingPlan {
    let transaction: String
    let dailyVolume: Int        // 일일 발생 건수 (메트릭으로 전수 집계한 값)
    let neededSamples: Int      // 답하려는 질문에 필요한 표본 수
    let maxRate: Double = 1.0

    var rate: Double {
        guard dailyVolume > 0 else { return maxRate }
        return min(maxRate, Double(neededSamples) / Double(dailyVolume))
    }
}

let plans = [
    // 결제: 하루 500건뿐. p95를 보려면 300건은 필요 → 60%가 나오지만 전량 수집이 낫다
    SamplingPlan(transaction: "checkout.submit", dailyVolume: 500,    neededSamples: 300),
    // 화면 로드: 하루 200만 건. p95에 1000건이면 충분 → 0.05%
    SamplingPlan(transaction: "screen.load",     dailyVolume: 2_000_000, neededSamples: 1_000),
    // 스크롤: 하루 1000만 건. 500건이면 충분 → 0.005%
    SamplingPlan(transaction: "list.scroll",     dailyVolume: 10_000_000, neededSamples: 500),
]

for p in plans {
    print(String(format: "%@ — 일 %d건, 필요 %d건 → 비율 %.4f%%",
                 p.transaction, p.dailyVolume, p.neededSamples, p.rate * 100))
}
// checkout.submit — 일 500건, 필요 300건 → 비율 60.0000%
// screen.load     — 일 2000000건, 필요 1000건 → 비율 0.0500%
// list.scroll     — 일 10000000건, 필요 500건 → 비율 0.0050%
//
// → 같은 앱 안에서 비율이 1만 배 넘게 차이난다. 단일 비율로는 절대 맞출 수 없다.

여기서 일일 발생 건수를 어떻게 아는가가 관건인데, 답은 Q3 꼬리질문에서 이미 나왔다 — 메트릭은 전수 집계한다. 카운터로 센 전체 건수를 분모로 쓰면 된다. 트레이스만 있고 메트릭이 없으면 분모를 모르므로 비율을 계산할 수도, 결과를 보정할 수도 없다.

실험 · 도구

표본 수가 분위수 안정성에 미치는 영향을 직접 확인해보자.

import Foundation

/// 실제 분포에서 n개를 뽑아 p95를 추정하는 실험
func estimateP95(sampleSize: Int, trials: Int = 5) -> [Double] {
    // 현실적인 응답 시간 분포 — 대부분 빠르고 꼬리가 긴 형태
    func draw() -> Double {
        Double.random(in: 0...1) < 0.9
            ? Double.random(in: 40...120)      // 정상
            : Double.random(in: 300...3000)    // 느린 꼬리
    }
    return (0..<trials).map { _ in
        let s = (0..<sampleSize).map { _ in draw() }.sorted()
        return s[min(s.count - 1, Int(Double(s.count) * 0.95))]
    }
}

for n in [20, 100, 1000, 10_000] {
    let runs = estimateP95(sampleSize: n)
    let fmt = runs.map { String(format: "%.0f", $0) }.joined(separator: ", ")
    print(String(format: "표본 %6d개 → p95 추정: %@ ms", n, fmt))
}
// 이 분포의 이론적 참값은 p95 = 1650 ms 다.
//   P(X ≤ x) = 0.9 + 0.1·(x−300)/2700 = 0.95  →  x = 1650
//
// 표본     20개 → p95 추정: 426, 619, 2164, 119, 2968 ms   ← 25배 편차. 못 쓴다.
// 표본    100개 → p95 추정: 2054, 1777, 2203, 1305, 684 ms
// 표본   1000개 → p95 추정: 1614, 1983, 1599, 1617, 1790 ms
// 표본  10000개 → p95 추정: 1528, 1632, 1662, 1653, 1686 ms  ← 참값 근처로 수렴
//
// 주의: 10000개에서도 폭이 ±80 ms 남는다. "표본을 늘리면 값이 고정된다"가 아니라
//       "오차가 √n 에 반비례해 줄어든다"가 정확한 표현이다.

희귀 사건 탐지 확률도 계산해두면 비율 결정이 쉬워진다.

/// 발생률 r인 사건을 표본 n개에서 한 번 이상 볼 확률
func detectionProbability(rate r: Double, samples n: Int) -> Double {
    1 - pow(1 - r, Double(n))
}

for r in [0.01, 0.001, 0.0001] {
    let line = [100, 1_000, 10_000, 100_000]
        .map { String(format: "n=%d: %.0f%%", $0, detectionProbability(rate: r, samples: $0) * 100) }
        .joined(separator: "  ")
    print(String(format: "발생률 %.2f%% → %@", r * 100, line))
}
// 발생률 1.00% → n=100: 63%  n=1000: 100%  n=10000: 100%  n=100000: 100%
// 발생률 0.10% → n=100: 10%  n=1000: 63%   n=10000: 100%  n=100000: 100%
// 발생률 0.01% → n=100: 1%   n=1000: 10%   n=10000: 63%   n=100000: 100%
//
// → 0.01% 사건을 안정적으로 보려면 표본이 수만 건 필요하다.
//   그래서 "실패는 무조건 100% 기록"(Q3)이 압도적으로 효율적인 것이다.

이 표가 조건부 100% 기록의 정당성을 수치로 보여준다. 0.01% 사건을 균일 샘플링으로 잡으려면 전체 표본을 수만 건으로 늘려야 하는데, 그러면 정상 케이스 수만 건까지 함께 보내게 된다. 반면 실패만 골라 100% 기록하면 필요한 것만 온다.

프로젝트 적용

비율 결정 절차를 문서로 만들면 이렇다.

1. 답하려는 질문을 적는다. "결제 p95가 릴리스별로 어떻게 변하나", "특정 기기에서만 느린가". 질문이 없으면 비율을 정할 근거도 없다.
2. 질문에 필요한 표본 수를 정한다. 평균이면 수백, p95면 수백~1000, p99나 희귀 사건이면 수천 이상.
3. 분모(전수 건수)를 메트릭에서 가져온다. 없으면 먼저 카운터부터 붙인다.
4. 비율 = 필요 표본 ÷ 전수 건수. 1.0을 넘으면 전량 수집이다.
5. 세분화 축을 고려해 곱한다. 기기별·릴리스별로 나눠 볼 거라면 각 칸마다 필요 표본이 있어야 하므로, 칸 수만큼 곱해야 한다. 이 단계가 자주 빠져서 "전체로는 충분한데 쪼개면 표본이 없는" 상황이 생긴다.
6. 비용 한도와 대조한다. 계산된 비율이 전송량·배터리 예산을 넘으면 질문의 우선순위를 낮추거나 세분화 축을 줄인다.
7. 원격 설정으로 두고 주기적으로 재검토한다. 트래픽이 늘면 같은 비율이 과잉이 된다.

5번을 구체적으로 보면 이렇다 — p95를 기기 10종 × 릴리스 3개로 나눠 보려면 칸이 30개이고, 칸마다 1000건이 필요하면 총 3만 건이 있어야 한다. 전체 1000건으로는 어느 칸도 신뢰할 수 없다.

꼬리 질문

/// 목표 표본 수를 유지하도록 비율을 조정한다
func adaptiveRate(target: Int, observedDailyVolume: Int, current: Double) -> Double {
    guard observedDailyVolume > 0 else { return current }
    let ideal = Double(target) / Double(observedDailyVolume)
    // 급격한 변화를 막기 위해 완만하게 수렴시킨다
    return min(1.0, max(0.00001, current * 0.7 + ideal * 0.3))
}

Q5. 자동 계측은 무엇을 잡고 무엇을 놓치는가?

CS 원리

자동 계측의 근본 전략은 가로채기(interception)다. 우리 코드를 수정하지 않고 계측을 넣으려면, 실행 흐름이 반드시 지나는 지점을 가로채야 한다.

Dapper가 같은 문제를 푼 방식이 참고가 된다 — 애플리케이션 수준 투명성을 목표로 삼고, 계측을 RPC·스레딩·제어흐름 같은 공통 라이브러리에 넣었다. 애플리케이션 개발자는 아무것도 안 해도 트레이스가 생긴다. 핵심 계측 코드가 C++ 1000줄 미만이었던 것은 가로챌 지점이 적었기 때문이다.

여기서 자동 계측의 본질적 한계가 나온다. 가로챌 수 있는 것은 공통 경계뿐이고, 공통 경계는 도메인을 모른다.

결론은 둘 다 필요하다는 것이다. 자동 계측이 골격을 만들고, 수동 계측이 그 안을 채운다. 자동만 있으면 "HTTP 요청이 2초 걸렸다"까지만 알고, 수동만 있으면 계측 누락이 많다.

iOS에서는

iOS에서 자동 계측이 흔히 가로채는 지점과 그 방식은 이렇다.

• URLSession — URLProtocol 등록 또는 델리게이트 스위즐링. 요청 시작·응답 수신 시점을 잡는다.
• 뷰 컨트롤러 생명주기 — viewDidLoad·viewWillAppear·viewDidAppear 스위즐링. "화면 로드 시간"의 근거가 된다.
• 앱 생명주기 — UIApplicationDelegate 메서드와 알림 관찰. 콜드 스타트 측정.
• SwiftUI — View 수정자나 onAppear 훅. UIKit보다 가로채기가 까다로워 커버리지가 낮은 편이다.

여기서 iOS 고유의 사각지대가 여럿 생긴다.

(1) 화면 로드 시간의 정의가 애매하다. viewDidAppear는 "뷰가 나타났다"이지 "콘텐츠가 표시됐다"가 아니다. 데이터를 비동기로 불러와 채우는 화면이라면, 자동 계측은 빈 화면이 뜬 시점을 로드 완료로 기록한다. 사용자가 체감하는 것은 콘텐츠가 채워진 시점이므로 실제보다 훨씬 좋게 나온다.

(2) Swift Concurrency 경계를 못 따라간다. 스위즐링은 Objective-C 런타임 기반이라 Swift의 async 함수를 가로챌 수 없다. await를 넘나드는 작업의 구간은 수동으로 계측해야 한다.

(3) 스위즐링 자체의 제약. Apple 플랫폼에서 스위즐링은 런타임에 메서드 구현을 교체하는 것이라, 여러 SDK가 같은 메서드를 대상으로 하면 초기화 순서에 따라 동작이 달라진다(18장 Q7 꼬리질문). 재현이 어려운 버그의 원인이 된다.

(4) SwiftUI 커버리지. SwiftUI는 뷰가 값 타입이고 생명주기가 UIKit과 달라 스위즐링 대상이 거의 없다. SwiftUI 앱일수록 수동 계측 비중이 커진다.

실험 · 도구

자동 계측이 실제로 무엇을 잡는지 확인하려면 트레이스를 열어 빈 구간을 찾는 것이 가장 빠르다.

// 자동 계측만 켠 상태의 전형적 트레이스
// └ ProductListViewController — 2400 ms
//   └ GET /products — 320 ms
//   └ (빈 구간 2080 ms)          ← 여기서 뭘 했는지 아무도 모른다
//
// 빈 구간을 수동 계측으로 채운다
@MainActor
final class ProductListViewModel {
    func load() async {
        await withSpan("products.load") {
            let data = await withSpan("products.fetch") {      // 자동 계측과 중복될 수 있다
                try? await api.get("/products")
            }
            let items = await withSpan("products.decode") {     // ← 자동으로는 안 잡힌다
                try? decoder.decode([Product].self, from: data ?? Data())
            }
            await withSpan("products.enrich") {                 // ← 안 잡힌다
                await enrichWithLocalData(items ?? [])
            }
            await withSpan("products.render") {                 // ← 안 잡힌다
                applySnapshot(items ?? [])
            }
        }
    }
}

"콘텐츠 표시 시점"을 제대로 재는 것도 수동 작업이다.

import UIKit

/// viewDidAppear가 아니라 "실제 콘텐츠가 그려진 첫 프레임"을 잰다
final class ContentAppearanceTracker {
    private var span: SpanHandle?

    func begin(_ name: String) { span = tracer.begin(name) }

    /// 데이터가 채워진 뒤 호출한다 — 다음 프레임이 실제로 표시된 시점에 종료
    ///
    /// ⚠️ CATransaction.setCompletionBlock 을 쓰면 안 된다. 이 블록은
    ///    "이 트랜잭션에 추가된 애니메이션이 모두 끝났을 때" 불리고,
    ///    애니메이션이 없으면 **즉시** 실행된다. 렌더 서버 도착과 무관하다.
    ///    그래서 다음 프레임을 기다리려면 CADisplayLink 를 한 번 돌린다.
    func markContentReady() {
        var link: CADisplayLink?
        link = CADisplayLink(target: BlockTarget { [weak self] in
            link?.invalidate()           // 한 프레임만 기다린다
            self?.span?.end()
            self?.span = nil
        }, selector: #selector(BlockTarget.fire))
        link?.add(to: .main, forMode: .common)
    }

    /// CADisplayLink 가 셀렉터를 요구하므로 얇은 타깃을 둔다
    final class BlockTarget: NSObject {
        private let block: () -> Void
        init(_ block: @escaping () -> Void) { self.block = block }
        @objc func fire() { block() }
    }
}

// 사용
tracker.begin("screen.products.contentReady")
// … 비동기 로드 …
collectionView.reloadData()
tracker.markContentReady()     // ← viewDidAppear 가 아니라 '콘텐츠가 그려진 프레임' 시점

스위즐링 충돌 여부는 런타임에 확인할 수 있다.

import ObjectiveC

/// 특정 메서드가 스위즐링됐는지 확인 — 구현 주소가 원래 이미지 밖이면 교체된 것
func isSwizzled(_ cls: AnyClass, _ sel: Selector) -> Bool {
    guard let m = class_getInstanceMethod(cls, sel) else { return false }
    let imp = method_getImplementation(m)
    var info = Dl_info()
    guard dladdr(UnsafeRawPointer(imp), &info) != 0,
          let fname = info.dli_fname else { return false }
    let owner = String(cString: fname)
    // UIKit 메서드인데 구현이 UIKit 바이너리 밖에 있으면 누군가 바꾼 것
    return !owner.contains("UIKit")
}

#if DEBUG
print("viewDidAppear 스위즐링됨:", isSwizzled(UIViewController.self, #selector(UIViewController.viewDidAppear(_:))))
#endif

프로젝트 적용

자동·수동 계측의 조합 전략은 이렇다.

• 자동 계측은 필요한 것만 켠다. 기본값이 "전부 켜짐"인 경우가 많은데, 안 쓰는 계측은 스위즐링 대상과 오버헤드만 늘린다. 파일 I/O 추적이나 세션 리플레이처럼 무거운 것은 특히 검토한다.
• 주요 플로우는 반드시 수동 계측한다. 결제·검색·업로드처럼 비즈니스 핵심 플로우는 도메인 구간으로 직접 나눈다.
• "콘텐츠 표시" 시점을 직접 정의한다. 자동 계측의 화면 로드 시간을 그대로 믿지 말고, 각 화면의 "준비 완료" 조건을 코드로 명시한다.
• 스위즐링 충돌을 의심할 근거를 만든다. SDK 초기화 순서를 코드 한 곳에 모아두고 주석으로 이유를 남긴다. 문제가 생겼을 때 순서를 바꿔볼 수 있는 것과 없는 것의 차이가 크다.
• SwiftUI 비중이 크면 수동 계측 예산을 더 잡는다. 자동 커버리지가 낮다는 것을 전제로 계획한다.

꼬리 질문

struct TracedScreen: ViewModifier {
    let name: String
    @State private var span: SpanHandle?

    func body(content: Content) -> some View {
        content
            .onAppear { if span == nil { span = tracer.begin("screen.\(name)") } }
            .onDisappear { span?.end(); span = nil }
    }
}

extension View {
    func traced(_ name: String) -> some View { modifier(TracedScreen(name: name)) }
}

// 사용 — 이름을 우리가 정하므로 읽을 수 있고 안정적이다
ProductListView().traced("products")

Q6. 프로파일링은 Time Profiler와 무엇이 다른가?

CS 원리

샘플링 프로파일러의 원리는 통계적 추정이다. 모든 함수 호출을 기록하는 것(instrumenting profiler)은 오버헤드가 너무 커서, 대신 일정 주기로 스택을 훔쳐본다.

1 ms마다 스택을 뜬다:
  t=0ms   [main, viewDidLoad, parseJSON, decodeObject]
  t=1ms   [main, viewDidLoad, parseJSON, decodeObject]
  t=2ms   [main, viewDidLoad, parseJSON, decodeArray]
  t=3ms   [main, viewDidLoad, layoutSubviews]
  …
1000개 샘플 중 parseJSON이 700개에 등장 → CPU 시간의 약 70%로 추정

여기서 중요한 성질이 셋 나온다.

• 확률적이다. 샘플이 적으면 오차가 크다. 100개 샘플로 "이 함수가 5% 썼다"는 신뢰할 수 없다.
• 짧고 잦은 함수를 놓칠 수 있다. 샘플링 주기보다 훨씬 짧게 실행되는 함수는 우연히 샘플에 안 잡힐 수 있다. 반대로 총 시간이 길면 개별 호출이 짧아도 통계적으로 드러난다.
• 대기 시간은 안 잡힌다. 스레드가 블록돼 있으면 CPU를 안 쓰므로 기본 설정에서는 샘플에 안 나온다(20장 Q5 꼬리질문). 그래서 "느린데 프로파일러에 안 보이는" 상황이 생긴다.

세 번째가 특히 중요하다. 프로파일러는 "바쁜" 문제를 잡고, 행 도구는 "기다리는" 문제를 잡는다. 어느 쪽인지 모르면 잘못된 도구로 몇 시간을 헤맨다.

iOS에서는

두 환경의 차이를 구체적으로 정리하면 이렇다.

실무적으로 중요한 것은 서로를 대체할 수 없다는 점이다.

Time Profiler만 쓰면 — 개발자의 최신 기기, 좋은 네트워크, 적은 데이터에서만 본 결과다. 20장 Q7에서 본 "재현 안 되는 이유 세 가지"가 그대로 적용된다. 실사용자의 병목은 다른 곳일 수 있다.

프로덕션 프로파일러만 쓰면 — 해상도가 낮아 세밀한 최적화 근거로 쓰기 어렵고, 메모리·I/O 같은 다른 축을 못 본다.

그래서 순서가 있다. 프로덕션 프로파일로 "어느 함수가 실사용자에게서 무겁나"를 좁히고, Time Profiler로 그 함수를 정밀 분석한다. 20장 Q7의 좁히기 절차와 같은 구조다.

실험 · 도구

샘플링 프로파일러를 직접 만들어보면 원리와 한계가 동시에 이해된다.

import Foundation

/// 아주 단순한 샘플링 프로파일러 — 메인스레드 스택을 주기적으로 뜬다
final class MiniProfiler {
    private var counts: [String: Int] = [:]
    private var thread: Thread?
    private let interval: TimeInterval

    init(intervalMs: Double = 10) { self.interval = intervalMs / 1000 }

    func start() {
        let t = Thread { [weak self] in
            guard let self else { return }
            while !Thread.current.isCancelled {
                Thread.sleep(forTimeInterval: self.interval)
                // ⚠️ 실제 구현은 메인스레드를 정지시키고 스택을 언와인딩해야 한다.
                //    여기서는 개념만 — 20장 Q3 꼬리질문의 위험이 그대로 적용된다.
                let frames = Thread.callStackSymbols   // (자기 스레드 기준이라 데모용)
                let key = frames.prefix(4).joined(separator: " < ")
                self.counts[key, default: 0] += 1
            }
        }
        t.qualityOfService = .utility
        t.start()
        thread = t
    }

    func stop() -> [(String, Int)] {
        thread?.cancel()
        let total = counts.values.reduce(0, +)
        return counts.sorted { $0.value > $1.value }.prefix(10).map { k, v in
            (String(format: "%.1f%% %@", Double(v) / Double(total) * 100, k), v)
        }
    }
}

샘플 수와 정확도의 관계도 실험으로 확인할 수 있다.

// 실제 비율이 5%인 함수를, 샘플 수를 바꿔가며 추정해본다
func estimate(trueRatio: Double, samples: Int) -> Double {
    let hits = (0..<samples).filter { _ in Double.random(in: 0...1) < trueRatio }.count
    return Double(hits) / Double(samples) * 100
}

for n in [50, 200, 1000, 10_000] {
    let runs = (0..<5).map { _ in estimate(trueRatio: 0.05, samples: n) }
    print(String(format: "샘플 %6d개 → 추정치: %@", n,
                 runs.map { String(format: "%.1f%%", $0) }.joined(separator: ", ")))
}
// 샘플     50개 → 추정치: 2.0%, 8.0%, 4.0%, 0.0%, 6.0%     ← 편차가 매우 크다
// 샘플    200개 → 추정치: 4.5%, 6.0%, 3.5%, 5.5%, 4.0%
// 샘플   1000개 → 추정치: 5.1%, 4.7%, 5.3%, 4.9%, 5.2%
// 샘플  10000개 → 추정치: 5.02%, 4.98%, 5.04%, 4.97%, 5.01%  ← 안정
//
// → 프로덕션 프로파일러는 샘플링 주기가 낮아 샘플 수가 적다.
//   그래서 "5% 차이"를 논하기 어렵고, "이 함수가 압도적"만 신뢰할 수 있다.

Instruments 쪽 실무 팁 셋.

# 1) 대기 스레드도 보고 싶으면 — Time Profiler의 스레드 상태 옵션을 켠다
#    (블록된 스레드가 샘플에 포함되어 "기다리는" 문제도 보인다)

# 2) 릴리스 구성으로 프로파일링한다
#    디버그 빌드는 최적화가 없어 프로파일이 완전히 다르게 나온다.
#    Product › Scheme › Edit Scheme › Profile › Build Configuration = Release

# 3) 느린 기기에서 프로파일링한다
#    최신 기기의 프로파일은 실사용자 병목과 다를 수 있다.

프로젝트 적용

두 도구의 역할 분담을 팀 절차로 만들면 이렇다.

1. 프로덕션 프로파일 / 지표로 대상 선정. "실사용자에게서 시간을 많이 쓰는 함수"를 찾는다. 여기서 개발자의 직관이 자주 틀린다.
2. 재현 시나리오 구성. 20장 Q7의 조건 — 느린 기기, 나쁜 네트워크, 큰 데이터.
3. Time Profiler로 정밀 분석. 릴리스 구성, 실기기. 콜 트리를 펼쳐 어느 경로가 무거운지 본다.
4. 수정 후 두 곳에서 검증. Instruments에서 개선을 확인하고, 다음 릴리스의 프로덕션 지표로 실사용자에게도 개선됐는지 확인한다.

4번이 자주 빠진다. 개발 기기에서 30% 빨라진 것이 실사용자에게서는 0%일 수 있다 — 병목이 달랐거나, 개선한 경로를 실사용자는 잘 안 타거나, 다른 병목이 지배적이거나.

그리고 프로덕션 프로파일링을 켤 때는 18장 Q7의 비용 항목을 반드시 측정한다. 프로파일러는 상시 도는 계측이라 배터리와 CPU에 지속적 부담을 준다. 벤더가 제시하는 오버헤드 수치는 특정 조건의 값이므로 자기 앱에서 직접 재야 한다.

꼬리 질문

Q7. 계측 오버헤드를 어떻게 측정하고 예산화하는가?

CS 원리

계측 오버헤드는 고정 비용 + 변동 비용으로 나뉜다.

Dapper의 측정값이 이 구조를 잘 보여준다. 루트 span 생성·소멸에 평균 204 ns, 비루트에는 176 ns. 나노초 단위라 하나로는 무시할 만하다. 그런데 트레이스당 span이 수천 개면 밀리초 단위가 되고, 초당 수백 트레이스면 유의미해진다.

여기서 나오는 원칙이 "단가가 아니라 총량을 본다"는 것이다. "span 하나가 200 ns니까 괜찮다"는 판단은 몇 개를 만드는지 모르면 무의미하다.

그리고 비용의 위치가 중요하다는 점을 다시 짚어야 한다(18장 Q7). 총량이 같아도 콜드 스타트에 있는 1 ms와 백그라운드 작업 중의 10 ms는 체감이 전혀 다르다. 예산은 총량이 아니라 구간별로 잡아야 한다.

iOS에서는

iOS에서 측정할 항목과 방법을 정리하면 이렇다.

콜드 스타트가 1순위인 이유는 18장 Q7에서 본 대로다 — 사용자가 앱을 열 때마다 지불하고, 그 순간이 가장 민감하다. 그리고 관측 SDK는 크래시를 놓치지 않으려고 아주 이른 시점에 초기화되므로 정확히 그 자리에 얹힌다.

네트워크 전송량도 모바일 고유의 항목이다. 셀룰러에서 계측 데이터를 계속 보내면 사용자 데이터 요금을 쓴다. 배치 전송과 와이파이 우선 전송이 기본이어야 한다.

실험 · 도구

A/B 빌드 비교가 가장 정직한 방법이다. 컴파일 플래그로 계측을 통째로 끈다.

// Build Settings › Swift Compiler - Custom Flags 에 -DOBSERVABILITY_ENABLED 추가/제거
@main
struct ShopApp: App {
    init() {
        #if OBSERVABILITY_ENABLED
        let t0 = ContinuousClock.now
        ObservabilitySDK.start(config: .default)
        let dt = ContinuousClock.now - t0
        LaunchMetrics.record("sdk_init_ms", ms(dt))
        #endif
    }
    var body: some Scene { WindowGroup { RootView() } }
}

# 두 빌드를 같은 기기에서 번갈아 여러 번 실행해 콜드 스타트를 비교한다
# (한 번만 재면 캐시 상태·시스템 부하 때문에 편차가 크다)

# 1) 실기기 콜드 스타트 — Instruments 의 App Launch 템플릿이 표준이다.
#    (시뮬레이터 측정은 CPU/GPU 가 Mac 것이라 참고도 되지 않는다)
#
# 2) pre-main 구간 분해 — 스킴 환경변수에 DYLD_PRINT_STATISTICS=1 (26장 Q3)
#
# 3) 자체 계측 — 첫 프레임에 signpost 를 찍고 로그로 회수한다
#    (위 launchSignposter 방식) 후 아카이브에서 구간을 뽑는다:
log collect --device --last 10m --output launch.logarchive
log show launch.logarchive --signpost --style compact \
    --predicate 'subsystem == "com.example.shop" AND category == "launch"'

# 2) 더 신뢰할 수 있는 방법 — MetricKit 히스토그램을 릴리스별로 비교
#    MXAppLaunchMetric.histogrammedTimeToFirstDraw
#    실사용자 분포라 기기·상황이 섞여 들어온다 (18장 Q7)

메모리와 span 수를 함께 재면 변동 비용의 실체가 보인다.

/// 계측 지점 수와 실제 비용을 함께 기록한다 — "단가가 아니라 총량" 원칙
final class InstrumentationBudget {
    private static var spanCount = 0
    private static var totalOverheadNs: UInt64 = 0

    static func measured<T>(_ name: String, _ body: () throws -> T) rethrows -> T {
        let t0 = ContinuousClock.now
        let span = tracer.begin(name)
        let createCost = ContinuousClock.now - t0

        defer {
            let t1 = ContinuousClock.now
            tracer.end(span)
            let endCost = ContinuousClock.now - t1

            spanCount += 1
            totalOverheadNs += UInt64((createCost + endCost).components.attoseconds / 1_000_000_000)
        }
        return try body()
    }

    /// 세션 종료 시 보고 — 트랜잭션당 span 수가 예상보다 많은지 확인
    static func report() {
        let avgNs = spanCount > 0 ? totalOverheadNs / UInt64(spanCount) : 0
        Logger(subsystem: "com.example.shop", category: "budget").notice(
            "span \(spanCount, privacy: .public)개, 총 오버헤드 \(totalOverheadNs / 1_000_000, privacy: .public)ms, 평균 \(avgNs, privacy: .public)ns")
        // Dapper 보고값(루트 204ns / 비루트 176ns)과 비교해볼 수 있다.
        // 크게 벗어나면 우리 구현에 불필요한 비용이 있다는 뜻이다.
    }
}

프로젝트 적용

오버헤드 관리를 절차로 만들면 이렇다.

• 도입 시 기준선을 측정한다. SDK를 넣기 전에 콜드 스타트·메모리·바이너리 크기를 기록한다. 넣은 뒤에 재면 비교 대상이 없다.
• 예산을 숫자로 못 박는다. "콜드 스타트 증가분 5% 이내" 같은 기준을 정하고 CI에서 회귀를 감시한다. 숫자가 없으면 매 릴리스마다 조금씩 는다.
• 기능 단위로 켜고 끈다. 자동 계측 항목, 세션 리플레이, 프로파일링을 각각 원격 설정으로 제어할 수 있게 해두면, 문제가 생겼을 때 릴리스 없이 끌 수 있다.
• 주기적으로 "이 계측이 쓰였는가"를 검토한다. 18장 Q7 꼬리질문의 방법 — 대시보드 참조 여부, 사고 회고 기여, 소유자 부재를 점검하고 안 쓰는 것은 샘플링을 낮췄다가 제거한다.
• span 수 상한을 둔다. 트랜잭션당 span 수에 상한(예: 100)을 걸고 초과분은 버리되 버렸다는 사실을 기록한다. 조용히 자르면 트레이스가 잘린 것을 모른다.

꼬리 질문

출처 · 참고자료