23 · 프라이버시와 데이터 수집

18~22장에서 만든 관측 파이프라인은 사용자 기기에서 우리 서버로 데이터를 계속 보내는 장치다. 그 데이터에 무엇이 실리는지, 어디까지 선언해야 하는지, 무엇을 물어봐야 하는지를 모르면 기능적으로는 잘 돌면서 심사에서 반려되거나 법적 문제를 만드는 앱이 된다. P0 11장 Q6이 "로그와 크래시 리포트에 민감 정보를 남기지 말라"까지였다면, 이 챕터는 실제로 어디서 새는지, 플랫폼이 무엇을 강제하는지, 어디까지 줄여야 하는지를 다룬다.

Q1. PII는 관측 데이터의 어디로 새는가?

CS 원리

유출의 근본 구조는 데이터의 출처와 목적지가 설계 시점에 분리되어 있다는 데 있다. URL을 만든 코드는 그 URL이 나중에 관측 이벤트에 실릴 것을 모르고, 관측 SDK는 그 URL에 무엇이 들었는지 모른다. 양쪽 다 자기 관심사만 보므로 아무도 검사하지 않는다.

이 구조는 P0 17장의 결합·응집 논의와 정확히 이어진다 — 두 모듈이 공유 데이터 구조를 통해 암묵적으로 결합되어 있고, 그 결합이 코드에 보이지 않는다.

유출 경로를 분류하면 셋이다.

실무에서 사고를 만드는 것은 대부분 두 번째와 세 번째다. 첫 번째는 코드 리뷰에서 걸리지만, 나머지는 실제로 전송된 데이터를 봐야 발견된다.

iOS에서는

iOS에서 각 경로가 구체적으로 어떻게 열리는지 보자.

(1) URL. 자동 네트워크 계측은 요청 URL을 breadcrumb과 span에 기록한다. 쿼리스트링에 액세스 토큰, 이메일, 검색어가 있으면 그대로 나간다. 검색어는 특히 민감한데, 검색 내용 자체가 건강·성향·위치 정보일 수 있기 때문이다.

(2) 에러 메시지. 서버가 {"error": "카드 4242-****-****-1234 승인 거절"}처럼 응답하면, 그 문자열이 에러 객체에 담겨 이벤트 제목이 된다. DecodingError도 위험한데, 디코딩 실패 시 문제가 된 값을 메시지에 포함하는 경우가 있다.

(3) UI 텍스트. 18장 Q4 꼬리질문에서 다룬 문제다. 자동 인터랙션 수집이 버튼 타이틀이나 접근성 레이블을 쓰면 사용자 데이터가 이름이 된다.

(4) 스크린샷·뷰 계층. 에러 시점 화면을 자동 캡처하는 기능이 있는 SDK가 많다. 진단에는 매우 유용하지만 화면에 보이는 모든 것이 전송된다. 마스킹이 기본값인 구현이 대부분이지만, 커스텀 뷰는 마스킹 대상으로 인식되지 않을 수 있다.

(5) 로그. print는 시스템 로그에 남지 않지만(18장 Q3), 일부 SDK는 앱의 콘솔 출력을 캡처해 이벤트에 첨부한다. 그리고 Logger도 privacy: .public을 남발하면 리댁션이 무력화된다.

여기서 Apple이 준 기본 안전장치를 다시 짚을 가치가 있다 — 통합 로깅은 동적 문자열과 복합 객체를 기본적으로 리댁션한다. 정수·실수·불리언은 리댁션하지 않는다. 즉 기본값이 안전한 쪽이고, 여는 것은 명시적 행위다. 우리 관측 파이프라인도 같은 원칙(기본 차단, 명시적 허용)으로 설계해야 한다.

실험 · 도구

가장 확실한 검증은 실제로 나가는 데이터를 눈으로 보는 것이다.

import Foundation

/// 디버그 빌드에서 나가는 모든 이벤트를 검사한다 — PII 패턴이 있으면 즉시 중단
enum PIIGuard {
    // 실무에서 가장 자주 새는 패턴들
    private static let patterns: [(name: String, regex: NSRegularExpression)] = {
        let defs: [(String, String)] = [
            ("이메일",      #"[\w.+-]+@[\w-]+\.[\w.]+"#),
            ("전화번호",     #"01[016789][-.\s]?\d{3,4}[-.\s]?\d{4}"#),
            ("주민번호",     #"\d{6}[-\s]?[1-4]\d{6}"#),
            ("카드번호",     #"\b(?:\d[ -]?){13,19}\b"#),
            ("Bearer 토큰", #"(?i)bearer\s+[A-Za-z0-9._~+/-]{20,}"#),
            ("JWT",        #"eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\."#),
        ]
        return defs.compactMap { name, p in
            (try? NSRegularExpression(pattern: p)).map { (name, $0) }
        }
    }()

    /// 전송 직전 훅에서 호출한다
    static func inspect(_ payload: String, origin: String) {
        #if DEBUG
        for (name, re) in patterns {
            let range = NSRange(payload.startIndex..., in: payload)
            if let m = re.firstMatch(in: payload, range: range) {
                let hit = (payload as NSString).substring(with: m.range)
                fatalError("🚨 \(origin) 에 \(name) 유출: \(hit.prefix(12))…")
            }
        }
        #endif
    }
}

// 전송 훅에 연결 — 이벤트가 나가기 전에 전부 검사한다
Observability.beforeSend = { event in
    PIIGuard.inspect(event.jsonString, origin: "event.\(event.type)")
    return event
}

URL 정규화는 별도로 강제하는 편이 안전하다.

extension URL {
    /// 관측용 안전 표현 — 쿼리 제거 + 경로의 식별자 치환
    var observabilitySafe: String {
        guard var c = URLComponents(url: self, resolvingAgainstBaseURL: false) else { return "invalid" }
        c.query = nil            // 쿼리스트링은 통째로 버린다 (토큰·검색어의 주 서식지)
        c.fragment = nil
        c.user = nil
        c.password = nil

        // 경로의 가변 세그먼트를 템플릿으로 — 18장 Q6의 그룹핑 문제도 함께 해결된다
        let normalized = c.path.split(separator: "/").map { seg -> String in
            if seg.allSatisfy(\.isNumber) { return "{id}" }
            if seg.count >= 20, seg.allSatisfy({ $0.isHexDigit || $0 == "-" }) { return "{uuid}" }
            if seg.contains("@") { return "{email}" }
            return String(seg)
        }.joined(separator: "/")

        return "\(c.host ?? "?")/\(normalized)"
    }
}

// "https://api.shop.com/users/12345/orders?token=eyJhbG..."
//   → "api.shop.com/users/{id}/orders"

실제 전송 내용을 직접 확인하는 절차도 정기적으로 돌려야 한다.

# 1) 프록시로 실제 전송 페이로드를 캡처한다 (Charles / Proxyman / mitmproxy)
#    관측 백엔드로 나가는 요청만 필터링해 본문을 눈으로 확인
mitmproxy --set flow_detail=3 -w capture.mitm

# 2) 캡처에서 PII 패턴을 검색
mitmdump -nr capture.mitm -s dump_bodies.py \
  | grep -Ei '[a-z0-9._%+-]+@[a-z0-9.-]+|bearer |eyJ[A-Za-z0-9_-]{10,}'

# 3) 정기 점검 — 릴리스 전 체크리스트에 넣는다
#    주요 플로우(로그인·검색·결제)를 한 번씩 실행하고 캡처를 검사

프로젝트 적용

실무에서 세울 방어선 다섯.

• URL은 절대 원본으로 넣지 않는다. 정규화 함수를 하나 만들어 모든 경로가 그것을 거치게 한다. 자동 계측이 원본 URL을 쓴다면 SDK의 훅으로 덮어쓴다.
• 에러 메시지를 이벤트 제목으로 쓰지 않는다. 18장 Q6에서 그룹핑 이유로 이미 권고한 것과 같은 결론이다 — 분류는 타입으로, 값은 별도 필드로. 프라이버시와 그룹핑이 같은 해법을 가리킨다.
• 자동 수집 항목을 하나씩 검토한다. 스크린샷·뷰 계층·UI 텍스트 수집은 기본값이 켜져 있을 수 있다. 필요 없으면 끄고, 켜면 마스킹 설정을 반드시 확인한다.
• 전송 전 검사 훅을 넣는다. 위의 PIIGuard처럼 디버그에서 즉시 실패시키면 개발 중에 잡힌다.
• 정기적으로 실제 전송을 캡처해 본다. 코드 검토만으로는 자동 유출을 못 잡는다. 분기마다 한 번은 프록시로 확인한다.

꼬리 질문

Q2. Privacy Manifest는 무엇을 선언하며 빠뜨리면 어떻게 되는가?

CS 원리

Privacy Manifest는 선언적 계약(declarative contract) 방식이다. 플랫폼이 코드를 정적 분석해 "이 앱이 무엇을 하는지" 알아내려 하는 대신, 개발자가 선언하게 하고 그 선언과 실제 동작이 어긋나면 제재한다.

이 방식이 선택된 이유는 정적 분석의 한계에 있다. 어떤 API를 호출했는지는 바이너리에서 찾을 수 있지만, 그 결과를 무엇에 쓰는지는 알 수 없다. 같은 API가 정당한 용도와 핑거프린팅에 모두 쓰일 수 있으므로, 의도를 물어보는 수밖에 없다.

그래서 구조가 이렇게 된다.

• API 호출 여부 — 플랫폼이 자동으로 검출할 수 있다. 그래서 선언 누락이 업로드 시점에 잡힌다.
• 사용 목적 — 개발자가 선언한다. Apple이 제공한 승인된 사유 목록에서 고른다.
• 선언과 실제의 일치 — 사후 검증과 정책으로 강제한다.

중요한 설계 원칙이 하나 더 있다 — 선언은 바이너리 단위다. Apple 문서가 명시한다: required reason API를 쓰는 각 실행 파일이나 동적 라이브러리마다, 그것을 포함하는 번들이 해당 API를 보고하는 privacy manifest를 포함해야 한다. 그리고 서드파티 SDK는 자기를 링크하는 앱의 manifest나 다른 SDK의 manifest에 의존할 수 없다.

이건 책임의 국소화다. 각 바이너리가 자기 행위를 스스로 선언하므로, 앱 개발자가 SDK 내부를 알 필요가 없다.

iOS에서는

최상위 키 넷의 의미를 정확히 정리하면 이렇다.

NSPrivacyTrackingDomains의 런타임 효과가 실무에서 가장 놀라운 부분이다. 이건 단순한 선언이 아니라 시스템이 강제하는 차단 목록이다. ATT 허가를 못 받은 상태에서 그 도메인에 요청하면 실패하고 에러가 돌아온다. 즉 선언을 잘못하면 정상 사용자에게 기능이 안 되는 상황이 만들어진다.

수집 데이터 선언에는 필드가 넷 들어간다.

• NSPrivacyCollectedDataType — Apple이 정의한 목록에서 고른다. 임의 값을 만들면 Xcode가 프라이버시 리포트를 제대로 생성하지 못한다.
• NSPrivacyCollectedDataTypeLinked — 이 데이터를 사용자 신원에 연결하는가.
• NSPrivacyCollectedDataTypeTracking — 이 데이터를 추적에 쓰는가.
• NSPrivacyCollectedDataTypePurposes — 수집 목적. 역시 정의된 목록에서만 고른다.

그리고 서드파티 SDK가 수집하는 데이터는 우리 앱 manifest가 다루지 않아도 된다 — SDK가 자기 manifest를 제공해야 한다. Apple 문서가 명시하는 분업이다.

실험 · 도구

manifest 파일의 실제 모양은 이렇다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <!-- 추적하지 않는 앱이라면 false. true면 TrackingDomains 필수 -->
  <key>NSPrivacyTracking</key>
  <false/>

  <key>NSPrivacyTrackingDomains</key>
  <array/>

  <!-- 수집 데이터 선언 -->
  <key>NSPrivacyCollectedDataTypes</key>
  <array>
    <dict>
      <key>NSPrivacyCollectedDataType</key>
      <string>NSPrivacyCollectedDataTypeCrashData</string>
      <key>NSPrivacyCollectedDataTypeLinked</key>
      <false/>
      <key>NSPrivacyCollectedDataTypeTracking</key>
      <false/>
      <key>NSPrivacyCollectedDataTypePurposes</key>
      <array>
        <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
      </array>
    </dict>
    <dict>
      <key>NSPrivacyCollectedDataType</key>
      <string>NSPrivacyCollectedDataTypePerformanceData</string>
      <key>NSPrivacyCollectedDataTypeLinked</key>
      <false/>
      <key>NSPrivacyCollectedDataTypeTracking</key>
      <false/>
      <key>NSPrivacyCollectedDataTypePurposes</key>
      <array>
        <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
      </array>
    </dict>
  </array>

  <!-- Required Reason API 사유 선언 (Q3에서 자세히) -->
  <key>NSPrivacyAccessedAPITypes</key>
  <array>
    <dict>
      <key>NSPrivacyAccessedAPIType</key>
      <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
      <key>NSPrivacyAccessedAPITypeReasons</key>
      <array>
        <string>CA92.1</string>
      </array>
    </dict>
  </array>
</dict>
</plist>

Xcode에서 만들고 검증하는 절차는 이렇다.

# 생성: File › New File › Resource 섹션 › App Privacy File
#   기본 이름이 PrivacyInfo.xcprivacy 이고, 이 이름이 필수다.
#   ⚠️ 타깃의 리소스에 반드시 추가해야 Xcode가 프라이버시 리포트 생성 시 인식한다.

# 프라이버시 리포트 생성 — 앱과 링크된 모든 SDK의 manifest를 집계한다
#   Product › Archive
#   Organizer 에서 아카이브를 Control-click › Generate Privacy Report
#   → PDF로 저장되며, App Store Connect의 개인정보 항목 작성에 그대로 쓴다

# 정적 라이브러리로 SDK를 배포한다면
#   Xcode 15+ 의 static framework 지원으로 리소스를 번들해야 한다.
#   프레임워크 타깃을 만들고 Mach-O Type = Static Library 로 설정한 뒤
#   PrivacyInfo.xcprivacy 를 번들 리소스에 추가한다.

# 앱 번들 안 manifest 전수 확인 (앱 + 익스텐션 + 프레임워크)
find "YourApp.app" -name 'PrivacyInfo.xcprivacy' | while read -r f; do
  echo "── $f"
  plutil -p "$f" | head -20
done

가장 유용한 도구는 프라이버시 리포트다. 앱과 링크된 모든 SDK의 manifest를 집계해 주므로, "우리가 실제로 무엇을 수집하는지"를 한 장으로 볼 수 있다. 그리고 그 형식이 App Store의 개인정보 영양성분표와 비슷하게 구성돼 있어 그대로 옮겨 적을 수 있다.

프로젝트 적용

manifest 관리에서 정할 것 다섯.

• 모든 바이너리에 manifest가 있는지 CI에서 검증한다. 앱·익스텐션·프레임워크마다 필요하고, 21장 Q6의 dSYM 개수 검증과 같은 방식으로 확인할 수 있다.
• SDK 도입 시 manifest 제공 여부를 확인한다. Apple이 지정한 "privacy manifest와 서명이 필요한 SDK" 목록에 있으면 필수이고, 없어도 required reason API를 쓰거나 데이터를 수집하거나 추적 도메인에 접속하면 제공해야 한다. 없는 SDK는 도입을 재검토한다 — 21장 Q3에서 dSYM 미제공 SDK를 재검토하라고 한 것과 같은 맥락이다.
• 릴리스마다 프라이버시 리포트를 생성해 diff를 본다. SDK를 업데이트했더니 수집 항목이 늘어난 경우를 잡을 수 있다.
• NSPrivacyTrackingDomains는 매우 신중하게 다룬다. 잘못 넣으면 정상 기능이 차단된다. 추적하지 않는다면 NSPrivacyTracking을 false로 두고 목록을 비운다.
• 선언과 실제를 정기적으로 대조한다. 선언은 코드가 아니라 문서라 코드가 바뀌어도 자동으로 안 바뀐다. 새 API를 쓰기 시작했는데 manifest를 안 고치면 다음 업로드에서 막힌다.

꼬리 질문

# 아카이브 안 모든 manifest를 정규화해 하나로 모은다
find "$ARCHIVE" -name 'PrivacyInfo.xcprivacy' -print0 \
  | xargs -0 -I{} sh -c 'echo "== {}"; plutil -convert json -o - "{}"' \
  > privacy-snapshot.json

# 이전 릴리스와 비교 — 변화가 있으면 검토 대상
diff previous-privacy-snapshot.json privacy-snapshot.json || {
  echo "⚠️ 프라이버시 선언이 변경되었습니다. 검토 후 App Store Connect 항목을 갱신하세요."
}

Q3. Required Reason API는 왜 생겼는가?

CS 원리

핑거프린팅의 원리는 엔트로피 누적이다. 개별 신호가 주는 정보량은 작지만, 독립적인 신호를 여러 개 모으면 정보량이 더해져서 개인을 특정할 수 있게 된다.

정보 이론으로 표현하면, 신호 하나가 k가지 값을 가질 때 그 신호의 엔트로피는 최대 log₂k 비트다. 독립 신호를 여러 개 합치면 엔트로피가 합산된다.

아래 세 개가 위험한 이유는 값의 범위가 사실상 연속이라 그 자체로 엔트로피가 크기 때문이다. 예를 들어 시스템 부팅 시각은 초 단위로 기록되는데, 같은 초에 부팅한 다른 기기를 만날 확률이 매우 낮다. 여기에 디스크 여유 공간까지 더하면 사실상 고유한 식별자가 된다.

그리고 이 신호들은 앱을 지우고 다시 깔아도 유지된다는 성질이 있다. 광고 식별자는 사용자가 초기화할 수 있지만, 부팅 시각은 초기화할 수 없다. 사용자가 통제할 수 없는 식별자라는 점이 핵심 문제다.

iOS에서는

Apple이 요구하는 선언 구조는 단순하다. NSPrivacyAccessedAPITypes 배열의 각 항목에 두 키를 넣는다.

• NSPrivacyAccessedAPIType — API 카테고리 식별자. Apple이 정의한 값 중에서만 고른다.
• NSPrivacyAccessedAPITypeReasons — 그 카테고리에 대해 Apple이 승인한 사유 코드 배열.

사유 코드는 CA92.1, C617.1, 35F9.1 같은 형태로, 카테고리마다 허용된 값이 다르다. 임의로 만들 수 없고, 목록에 없는 정당한 용도가 있으면 Apple에 새 사유를 요청하는 절차가 따로 있다.

Apple이 명시한 제약이 셋이다.

1. 선언한 사유가 실제 사용을 정확히 반영해야 한다.
2. 선언한 사유로만 그 API와 파생 데이터를 쓸 수 있다.
3. 선언한 사유가 사용자에게 제시된 앱 기능과 일관해야 하고, API나 파생 데이터를 추적에 쓸 수 없다.

2번이 특히 중요하다. "파일 타임스탬프를 백업 기능을 위해 읽는다"고 선언했다면, 그 타임스탬프를 사용자 식별에 재사용할 수 없다. API 호출 자체가 아니라 데이터의 용도까지 구속한다.

강제 시점은 두 단계다 — 업로드 시 미선언이면 Apple이 이메일로 알린다. 그리고 2024년 5월 1일부터는 아예 받지 않는다.

실험 · 도구

어떤 API를 쓰고 있는지 찾는 것이 첫 단계다.

# 1) 소스에서 required reason API 계열 호출을 찾는다
grep -rn --include='*.swift' --include='*.m' --include='*.h' \
  -e 'UserDefaults' \
  -e 'systemUptime' -e 'mach_absolute_time' -e 'kern.boottime' \
  -e 'volumeAvailableCapacity' -e 'systemFreeSize' -e 'statfs' \
  -e 'creationDate' -e 'modificationDate' -e 'contentModificationDate' \
  -e 'activeInputModes' \
  Sources/

# 2) 바이너리에서 심볼을 확인한다 — 서드파티 SDK 포함
#    소스에 없어도 링크된 라이브러리가 쓰고 있을 수 있다
nm -u "YourApp.app/YourApp" | grep -E 'statfs|NSUserDefaults|mach_absolute'
#   ⚠️ kern.boottime 은 링크 심볼이 아니라 sysctl 문자열이라 심볼 테이블에 안 나온다.
#      문자열 상수로 찾아야 한다:
strings -a "YourApp.app/YourApp" | grep -x 'kern.boottime'

# 3) 링크된 프레임워크 각각도 확인
for f in YourApp.app/Frameworks/*.framework; do
  bin="$f/$(basename "$f" .framework)"
  [ -f "$bin" ] || continue
  echo "== $(basename "$f")"
  nm -u "$bin" 2>/dev/null | grep -E 'statfs|NSUserDefaults|boottime' | head -3
done

2번과 3번이 중요한 이유는 우리 소스에 없어도 SDK가 쓰고 있을 수 있기 때문이다. 다만 그 경우 선언 의무는 SDK 쪽에 있으므로, 발견하면 SDK의 manifest를 확인한다.

선언한 사유가 실제와 맞는지 확인하는 것은 코드 리뷰의 몫이다. 자동 검증이 안 되므로 절차로 다룬다.

// 선언한 사유와 실제 용도를 코드에 명시해두면 리뷰가 쉬워진다
enum PrivacyAPIUsage {
    /// NSPrivacyAccessedAPICategoryUserDefaults — 사유 CA92.1
    /// 앱 자체의 설정을 읽고 쓰기 위해서만 사용한다.
    /// ⚠️ 이 값을 사용자 식별이나 추적에 재사용하면 선언 위반이다.
    static let defaults = UserDefaults.standard

    /// NSPrivacyAccessedAPICategoryFileTimestamp — 사유 (해당 코드)
    /// 사용자에게 표시할 파일 목록의 정렬에만 사용한다.
    static func modificationDate(of url: URL) throws -> Date? {
        try url.resourceValues(forKeys: [.contentModificationDateKey]).contentModificationDate
    }
}

프로젝트 적용

실무 규칙 넷.

• API 사용 목록을 코드 주석과 manifest에 동시에 남긴다. 위 예시처럼 사용 지점에 사유 코드를 적어두면, 나중에 "이걸 왜 쓰지?"를 다시 조사할 필요가 없다.
• 파생 데이터의 용도를 추적한다. 선언은 API 호출이 아니라 데이터 용도까지 구속한다. 예컨대 UserDefaults에 저장한 값을 나중에 사용자 식별에 쓰면 선언 위반이다.
• SDK 추가 시 API 사용을 확인한다. 바이너리 심볼 검사를 CI에 넣어두면 새 SDK가 뭘 쓰는지 파악할 수 있다.
• Apple 문서를 주기적으로 확인한다. Apple이 명시하듯 required reason API 목록과 사유는 계속 검토되고 갱신된다. 한 번 맞췄다고 영원히 맞는 것이 아니다.

그리고 대안이 있으면 대안을 쓴다. 예를 들어 "설치 후 경과 시간"이 필요하다면 부팅 시각을 읽는 대신 첫 실행 시 우리가 저장한 타임스탬프를 쓰면 된다. 이 값은 앱을 지우면 사라지므로 사용자가 통제할 수 있고, 핑거프린팅 우려가 없다.

꼬리 질문

Q4. ATT는 무엇을 바꾸고 무엇은 안 바꾸는가?

CS 원리

ATT가 규율하는 것은 "추적(tracking)"이라는 특정 행위이고, 그 정의가 핵심이다. 정의의 요소가 셋이다.

1. 데이터를 수집한다 — 앱 사용자에 관한 데이터.
2. 다른 회사와 공유하거나 다른 회사 데이터와 결합한다 — 자사 안에서만 쓰면 해당하지 않는다.
3. 앱과 웹사이트를 가로질러 사용자·기기를 식별한다 — 우리 앱 안에서의 사용자 식별은 해당하지 않는다.

세 요소가 모두 성립할 때 추적이다. 그래서 대부분의 관측·분석 작업은 2번에서 걸러진다 — 우리 서버로 보내 우리만 쓰면 다른 회사와 공유하지 않으므로 추적이 아니다.

이 구분이 실무에서 중요한 이유는 ATT 허가율이 낮기 때문이다. 관측 데이터를 ATT 뒤에 두면 대부분의 사용자에게서 데이터를 못 받게 되고, 그러면 18~22장에서 만든 파이프라인이 무력해진다. 추적이 아닌 것을 추적으로 취급하면 스스로 손해다.

반대로 추적인 것을 아니라고 판단하면 정책 위반이 된다. 광고 SDK나 어트리뷰션 SDK를 붙였다면, 그 SDK가 데이터를 다른 회사와 결합하는지 확인해야 한다.

iOS에서는

ATT 사용 절차는 Apple 문서가 세 단계로 정리한다.

1. NSUserTrackingUsageDescription을 Info.plist에 설정한다. 시스템 권한 알림에 표시할 문구다.
2. ATTrackingManager.requestTrackingAuthorization을 호출해 요청을 띄운다.
3. ATTrackingManager.trackingAuthorizationStatus로 상태를 확인한다.

import AppTrackingTransparency
import AdSupport

enum Tracking {
    /// 요청은 앱이 포그라운드 활성 상태일 때만 표시된다.
    /// 런치 직후 호출하면 알림이 안 뜨고 조용히 실패할 수 있다.
    static func requestIfNeeded() async -> ATTrackingManager.AuthorizationStatus {
        // 이미 결정된 상태면 다시 묻지 않는다 — 한 번 거부하면 다시 못 묻는다
        let current = ATTrackingManager.trackingAuthorizationStatus
        guard current == .notDetermined else { return current }
        return await ATTrackingManager.requestTrackingAuthorization()
    }

    /// IDFA — 허가 없으면 전부 0이 반환된다
    static var advertisingID: String? {
        guard ATTrackingManager.trackingAuthorizationStatus == .authorized else { return nil }
        let id = ASIdentifierManager.shared().advertisingIdentifier
        // 방어적으로 한 번 더 확인 — 전부 0이면 사용 불가
        return id.uuidString == "00000000-0000-0000-0000-000000000000" ? nil : id.uuidString
    }
}

상태 값이 넷이다 — notDetermined(아직 안 물어봄), restricted(정책상 불가), denied(거부), authorized(허용). 실무에서 중요한 점은 한 번 거부하면 앱에서 다시 물어볼 수 없다는 것이다. 사용자가 설정에서 직접 바꿔야 한다. 그래서 요청 타이밍이 한 번뿐인 기회가 된다.

그리고 앞서 본 NSPrivacyTrackingDomains의 강제력이 여기 연결된다. ATT 허가가 없으면 그 도메인으로의 요청이 실패하므로, ATT는 IDFA만 막는 것이 아니라 네트워크까지 막는다.

관측 파이프라인 관점에서 정리하면 이렇다.

실험 · 도구

ATT 상태별 동작을 반드시 테스트해야 한다. 개발 중에는 대개 허용 상태라 거부 경로가 검증되지 않는다.

# 1) 상태를 초기화해 notDetermined 로 되돌린다
#    기기: 설정 › 개인정보 보호 및 보안 › 추적 › (앱 목록에서 토글)
#    또는 앱을 삭제 후 재설치

# 2) 거부 상태로 전체 플로우 테스트
#    설정 › 개인정보 보호 및 보안 › 추적 › "앱이 추적을 요청하도록 허용" 끄기
#    → 모든 앱이 자동 거부 상태가 된다. 이 상태로 주요 기능을 전부 돌려본다.

# 3) ⚠️ simctl privacy 에는 tracking 서비스가 없다
#    (지원: calendar, contacts, location, photos, media-library, microphone,
#           motion, reminders, siri 등 — `xcrun simctl help privacy` 로 확인)
#    시뮬레이터에서 ATT 상태를 되돌리려면 앱을 삭제 후 재설치한다:
xcrun simctl uninstall booted com.example.shop
xcrun simctl install   booted /path/to/Shop.app
#    → ATT 검증은 위 1)·2)의 실기기 설정 경로가 유일하게 믿을 수 있는 방법이다.

// 4) 거부 상태에서 관측 파이프라인이 정상 동작하는지 확인하는 테스트
func testObservabilityWorksWithoutTrackingPermission() async {
    // ATT 거부 상태를 가정
    let status = ATTrackingManager.trackingAuthorizationStatus
    XCTAssertNotEqual(status, .authorized)

    // 크래시 리포팅과 성능 계측은 ATT와 무관하므로 계속 동작해야 한다
    Observability.capture(event: .init(type: "test"))
    await Task.yield()
    XCTAssertTrue(Observability.lastSendSucceeded,
                  "ATT 거부 상태에서 관측 전송이 막히면 설정이 잘못된 것이다")
}

가장 중요한 검증은 ATT 거부 상태로 앱 전체를 써보는 것이다. 여기서 다음을 확인한다.

• 크래시 리포팅·성능 계측이 계속 동작하는가 (동작해야 정상)
• 앱의 핵심 기능이 정상인가 (NSPrivacyTrackingDomains 차단으로 망가지지 않는가)
• 앱 시작이 느려지지 않는가 (차단된 요청을 동기로 기다리는 코드가 있으면 20장 Q5의 행이 된다)

프로젝트 적용

실무 판단 다섯.

• 관측 데이터를 ATT 뒤에 두지 않는다. 크래시·성능·자사 분석은 추적이 아니므로 허가와 무관하게 수집한다. 잘못 묶으면 데이터의 대부분을 잃는다.
• 추적용 SDK와 관측용 SDK를 분리한다. 도메인도 분리한다(Q2 꼬리질문). 하나가 차단돼도 다른 하나가 살아 있어야 한다.
• 요청 타이밍을 설계한다. 한 번뿐인 기회이므로, 사용자가 왜 필요한지 이해한 시점에 묻는다. 런치 직후에 묻는 것은 허가율이 낮고, 앱이 아직 활성 상태가 아니면 알림이 안 뜰 수도 있다.
• 거부 상태를 기본 경로로 설계한다. 허가율이 낮다는 전제로 기능을 만든다. 허가받아야만 동작하는 핵심 기능이 있으면 구조를 재검토해야 한다.
• SDK가 실제로 무엇을 하는지 확인한다. "분석 SDK"라고 이름 붙어 있어도 타사와 데이터를 공유하면 추적이다. 벤더의 privacy manifest와 문서로 확인한다.

꼬리 질문

Q5. 클라이언트와 서버 스크러빙은 왜 둘 다 필요한가?

CS 원리

이건 심층 방어(defense in depth)의 전형이다. 단일 방어선은 반드시 뚫리므로, 독립적인 방어를 여러 겹 두어 하나가 실패해도 다음이 막게 한다.

두 방어선의 성질을 비교하면 왜 둘 다 필요한지가 명확해진다.

가장 중요한 비대칭이 규칙 변경 반영이다. 클라이언트 규칙은 배포된 순간 고정된다. 새로운 유출 패턴을 발견해도 이미 나간 앱은 못 고친다. 그리고 P0 16장에서 본 대로 일부 사용자는 업데이트를 영원히 하지 않는다.

반대 방향의 비대칭은 맥락 정보다. 클라이언트는 값의 타입과 출처를 안다 — "이건 사용자 이메일 필드"라는 것을 확실히 알고 지울 수 있다. 서버는 문자열만 받으므로 패턴 매칭에 의존하고, 그래서 오탐(정상 값을 지움)과 미탐(유출을 놓침)이 생긴다.

정리하면 클라이언트는 정확하지만 갱신이 느리고, 서버는 부정확하지만 즉시 반영된다. 상보적이다.

iOS에서는

클라이언트 스크러빙은 전송 직전 훅에서 구현한다. 대부분의 SDK가 beforeSend 계열 콜백을 제공한다.

import Foundation

enum Scrubber {
    /// 전송 직전에 이벤트를 검사·수정한다. nil을 반환하면 전송을 취소한다.
    static func scrub(_ event: inout Event) -> Event? {
        // ── 1. 구조적 스크러빙: 타입을 아는 필드는 확실하게 처리한다 ──
        event.request.url = event.request.url.flatMap { URL(string: $0)?.observabilitySafe }
        event.request.headers.removeValue(forKey: "Authorization")
        event.request.headers.removeValue(forKey: "Cookie")
        event.request.body = nil                    // 본문은 통째로 제외
        event.user = event.user.map { u in          // 식별자는 남기되 개인정보는 제거
            var u = u; u.email = nil; u.name = nil; u.ipAddress = nil; return u
        }

        // ── 2. 허용 목록: 알려진 키만 남긴다 (차단 목록보다 안전) ──
        let allowedContextKeys: Set<String> = ["device", "app", "network", "order_meta"]
        event.contexts = event.contexts.filter { allowedContextKeys.contains($0.key) }

        // ── 3. 패턴 스크러빙: 남은 자유 텍스트를 정규식으로 훑는다 ──
        event.message = redact(event.message)
        for i in event.breadcrumbs.indices {
            event.breadcrumbs[i].message = redact(event.breadcrumbs[i].message)
        }

        // ── 4. 최후 검증: 그래도 남아 있으면 전송을 포기한다 ──
        if containsLikelyPII(event.jsonString) {
            Logger(subsystem: "com.example.shop", category: "privacy")
                .error("스크러빙 후에도 PII 의심 — 이벤트 폐기")
            return nil          // 보내지 않는 것이 보내는 것보다 낫다
        }
        return event
    }

    private static func redact(_ s: String) -> String { /* 정규식 치환 */ s }
    private static func containsLikelyPII(_ s: String) -> Bool { /* Q1의 PIIGuard 로직 */ false }
}

여기서 2번(허용 목록)이 설계상 가장 중요하다. 차단 목록("이 키들은 지운다")은 새 키가 추가되면 자동으로 통과하지만, 허용 목록("이 키들만 남긴다")은 새 키가 기본적으로 차단된다. 실수의 방향이 안전한 쪽이다. Q1 꼬리질문에서 스크린샷 마스킹도 같은 원칙을 권한 것과 이어진다.

4번도 중요한 판단이다 — 스크러빙에 실패했으면 보내지 않는 쪽을 택한다. 이벤트 하나를 잃는 비용보다 유출 비용이 훨씬 크다.

서버 스크러빙 쪽은 대개 관측 백엔드가 기능으로 제공한다. 설정할 것은 셋이다.

• 기본 PII 제거 — 이메일·전화번호·카드번호 패턴을 자동 감지해 제거하는 기본 규칙.
• 커스텀 규칙 — 우리 도메인 특유의 패턴(주문 번호 형식, 내부 토큰 형식).
• IP 주소 처리 — 수집하지 않거나 마지막 옥텟을 마스킹.

실험 · 도구

두 방어선이 각각 무엇을 잡는지 확인하는 테스트를 만들어두면 좋다.

import XCTest

final class ScrubberTests: XCTestCase {
    /// 클라이언트 스크러빙이 구조적 필드를 확실히 지우는지
    func testStructuralScrubbing() {
        var event = Event(
            message: "결제 실패",
            request: .init(url: "https://api.shop.com/pay?token=eyJhbGciOiJIUzI1NiJ9.abc&email=a@b.com",
                           headers: ["Authorization": "Bearer secret123"],
                           body: "{\"card\":\"4242424242424242\"}")
        )
        let out = Scrubber.scrub(&event)
        let json = out?.jsonString ?? ""

        XCTAssertFalse(json.contains("eyJhbGciOiJIUzI1NiJ9"), "JWT가 남았다")
        XCTAssertFalse(json.contains("a@b.com"),               "이메일이 남았다")
        XCTAssertFalse(json.contains("secret123"),             "토큰이 남았다")
        XCTAssertFalse(json.contains("4242424242424242"),      "카드번호가 남았다")
        XCTAssertTrue(json.contains("api.shop.com/pay"),       "경로는 남아야 조사가 된다")
    }

    /// 패턴 스크러빙이 자유 텍스트에서 잡아내는지
    func testPatternScrubbing() {
        var event = Event(message: "사용자 hong@example.com 의 주문 처리 실패")
        let out = Scrubber.scrub(&event)
        XCTAssertFalse((out?.message ?? "").contains("hong@example.com"))
    }

    /// 스크러빙 실패 시 폐기하는지
    func testDropsWhenScrubbingFails() {
        var event = Event(message: "주민번호 900101-1234567 확인 필요")
        // 패턴에 안 걸리도록 일부러 변형한 케이스를 넣어 최후 검증을 시험한다
        XCTAssertNil(Scrubber.scrub(&event), "PII가 남았는데 전송됐다")
    }
}

서버 규칙은 샘플 페이로드로 검증한다. 대부분의 백엔드가 규칙 테스트 기능을 제공하고, 없으면 스테이징 프로젝트에 실제로 보내보고 저장된 결과를 확인한다.

# 서버 스크러빙 검증 — 의도적으로 PII를 담은 이벤트를 스테이징에 보내고
# 저장된 결과를 조회해 제거됐는지 확인한다
curl -X POST "$STAGING_INGEST_URL" \
  -H 'Content-Type: application/json' \
  -d '{"message":"test scrub hong@example.com 010-1234-5678 4242424242424242"}'

sleep 5
# 저장된 이벤트를 조회해 원문이 남아 있는지 확인
fetch-event "$EVENT_ID" | grep -E 'hong@|010-1234|4242' \
  && echo "❌ 서버 스크러빙 실패" || echo "✅ 서버 스크러빙 동작"

프로젝트 적용

이중 방어를 실제로 구성하는 순서는 이렇다.

1. 서버 스크러빙을 먼저 켠다. 즉시 효과가 있고 모든 버전에 적용되므로 가장 빠른 위험 감소다. 클라이언트 작업을 기다릴 이유가 없다.
2. 클라이언트에 구조적 스크러빙을 넣는다. URL·헤더·본문·사용자 필드처럼 타입을 아는 것부터. 여기가 가장 효과가 크다.
3. 허용 목록으로 전환한다. 차단 목록으로 시작했다면 허용 목록으로 바꾼다. 처음에 무엇이 필요한지 모를 때는 차단 목록으로 시작하는 것이 현실적이지만, 안정되면 뒤집는다.
4. 최후 검증과 폐기 정책을 넣는다. 스크러빙 후에도 의심되면 버린다.
5. 정기 점검을 절차화한다. Q1의 프록시 캡처를 분기마다.

그리고 스크러빙이 조사 능력을 얼마나 해치는지 측정해야 한다. 너무 공격적으로 지우면 이벤트가 쓸모없어진다 — 이게 Q6의 주제다.

꼬리 질문

/// 민감 값 래퍼 — 실수로 로그에 찍혀도 원문이 안 나간다
struct Sensitive<T>: CustomStringConvertible, CustomDebugStringConvertible {
    private let value: T
    init(_ value: T) { self.value = value }
    /// 명시적으로 꺼낼 때만 원문에 접근한다
    func reveal() -> T { value }
    var description: String { "<redacted>" }
    var debugDescription: String { "<redacted>" }
}

struct User {
    let id: String                    // 안전 — 내부 식별자
    let name: Sensitive<String>       // 문자열 보간해도 <redacted>
    let email: Sensitive<String>
}

let u = User(id: "u_123", name: Sensitive("김철수"), email: Sensitive("a@b.com"))
print("사용자 \(u.name) 처리 실패")   // "사용자 <redacted> 처리 실패"

Q6. 최소 수집과 디버깅 능력을 어떻게 절충하는가?

CS 원리

데이터 최소화(data minimization)는 필요한 만큼만 수집한다는 원칙이다. 그런데 "필요한 만큼"이 모호해서 실무에서 잘 작동하지 않는다. 이를 다루기 쉽게 만드는 방법이 질문 기반 역산이다.

절차는 이렇다.

1. 답하려는 질문을 적는다. 22장 Q4의 샘플링 비율 결정과 같은 출발점이다.
2. 그 질문에 필요한 최소 정보를 정한다.
3. 그 정보를 얻는 가장 덜 민감한 표현을 고른다.

3번에서 쓰는 변환 기법을 정리하면 이렇다.

여기서 버킷화가 Q3의 핑거프린팅과 직접 연결된다. 디스크 여유 공간을 정확한 바이트로 수집하면 엔트로피가 커서 식별에 쓰일 수 있지만, "1GB 미만 / 1~10GB / 10GB 이상"으로 버킷화하면 엔트로피가 2비트도 안 되어 식별에 쓸모가 없다. 그런데 "저장 공간 부족이 크래시와 상관있나"라는 질문에는 여전히 답할 수 있다.

즉 정밀도를 낮추는 것만으로 위험은 크게 줄고 유용성은 거의 유지되는 경우가 많다. 이게 최소화 설계의 핵심 지렛대다.

iOS에서는

실무에서 자주 마주치는 절충 사례를 구체적으로 보자.

"실패한 필드명" 사례를 자세히 보면 원리가 잘 드러난다. 디코딩 실패를 조사하려면 응답 본문이 필요할 것 같지만, 실제로 알아야 할 것은 "어느 필드가, 어떤 타입을 기대했는데, 무엇이 왔나"다.

import Foundation

extension DecodingError {
    /// 값 자체를 노출하지 않고 진단에 필요한 정보만 뽑는다
    var safeDiagnostic: [String: String] {
        switch self {
        case .keyNotFound(let key, let ctx):
            return ["kind": "keyNotFound",
                    "key": key.stringValue,                       // 필드명은 스키마 정보 — 안전
                    "path": ctx.codingPath.map(\.stringValue).joined(separator: ".")]
        case .typeMismatch(let type, let ctx):
            return ["kind": "typeMismatch",
                    "expected": String(describing: type),         // 기대 타입 — 안전
                    "path": ctx.codingPath.map(\.stringValue).joined(separator: ".")]
        case .valueNotFound(let type, let ctx):
            return ["kind": "valueNotFound",
                    "expected": String(describing: type),
                    "path": ctx.codingPath.map(\.stringValue).joined(separator: ".")]
        case .dataCorrupted(let ctx):
            return ["kind": "dataCorrupted",
                    "path": ctx.codingPath.map(\.stringValue).joined(separator: ".")]
                    // ⚠️ ctx.debugDescription 은 값을 포함할 수 있어 넣지 않는다
        @unknown default:
            return ["kind": "unknown"]
        }
    }
}

// "orders[3].shippingAddress.zipCode 에서 String을 기대했는데 실패"
// → 값 없이도 원인 파악에 충분하다. 서버 스키마 변경이 범인이라는 것이 바로 보인다.

버킷화도 간단한 헬퍼로 강제할 수 있다.

/// 정밀도를 낮춰 핑거프린팅 위험을 제거하면서 규모 감각은 유지한다
enum Bucket {
    /// 로그 스케일 버킷 — 1, 2-5, 6-20, 21-100, 101-1000, 1000+
    static func count(_ n: Int) -> String {
        switch n {
        case 0:         return "0"
        case 1:         return "1"
        case 2...5:     return "2-5"
        case 6...20:    return "6-20"
        case 21...100:  return "21-100"
        case 101...1000:return "101-1k"
        default:        return "1k+"
        }
    }

    /// 저장 공간 — 정확한 바이트는 Q3의 핑거프린팅 위험이 있다
    static func diskSpace(_ bytes: Int64) -> String {
        let gb = Double(bytes) / 1_073_741_824
        switch gb {
        case ..<0.5:  return "critical"
        case ..<2:    return "low"
        case ..<10:   return "normal"
        default:      return "ample"
        }
    }
}

실험 · 도구

수집 항목을 검토하는 절차를 정기 회의 안건으로 만들면 실제로 작동한다. 판단 기준을 표로 만들어두면 논의가 빨라진다.

필드 검토표 (분기 1회)

┌──────────────────┬──────────────────┬─────────┬──────────┬────────────┐
│ 필드             │ 답하는 질문      │ 민감도  │ 최근 사용 │ 판정        │
├──────────────────┼──────────────────┼─────────┼──────────┼────────────┤
│ screen           │ 어디서 에러?     │ 낮음    │ 상시     │ 유지        │
│ user.anonymousID │ 같은 사용자 묶기 │ 낮음    │ 상시     │ 유지        │
│ user.email       │ (중복 — id로 대체)│ 높음    │ 없음     │ ❌ 제거     │
│ request.url      │ 어느 API?        │ 중간    │ 상시     │ 정규화 유지 │
│ request.body     │ 파싱 실패 원인   │ 높음    │ 2회/6개월 │ ❌ 진단 필드로 대체 │
│ disk.freeBytes   │ 공간 부족 상관?  │ 높음    │ 1회/6개월 │ ⚠️ 버킷화   │
│ search.query     │ 검색 품질        │ 높음    │ 없음     │ ❌ 메타데이터로 │
└──────────────────┴──────────────────┴─────────┴──────────┴────────────┘

판정 기준:
  - 최근 6개월 사용 이력이 없고 민감도가 높으면 → 제거
  - 사용은 있으나 정밀도가 과한 경우 → 버킷화 또는 일반화
  - 다른 필드로 답할 수 있으면 → 제거

"최근 사용"을 파악하는 방법은 18장 Q7 꼬리질문의 방법과 같다 — 대시보드 참조 여부, 쿼리 로그, 사고 회고에서의 인용 여부.

제거할 때는 단계적으로 한다.

// 1단계: 수집은 유지하되 사용 여부를 관찰한다 (deprecation 경고처럼)
if FeatureFlag.observePIIFieldUsage {
    Logger(subsystem: "com.example.shop", category: "privacy")
        .notice("deprecated 필드 접근: request.body")
}

// 2단계: 샘플링을 1%로 낮춘다 — 누군가 아쉬워하면 되돌린다
// 3단계: 수집 중단
// 4단계: 저장된 과거 데이터의 보관 기간 만료를 기다리거나 삭제 요청

4단계가 중요하다. 수집을 멈춰도 이미 저장된 데이터는 남아 있다. 보관 기간 정책을 확인하고, 필요하면 소급 삭제를 요청한다.

프로젝트 적용

최소화를 실제로 지속하는 방법 다섯.

• 새 필드 추가 시 "어떤 질문에 답하는가"를 필수 기재한다. PR 템플릿에 항목을 넣으면 자연스럽게 강제된다. 질문을 못 적으면 그 필드는 필요 없는 것이다.
• 민감 필드에는 만료일을 붙인다. "6개월 뒤 재검토" 같은 주석과 함께 캘린더에 등록한다. 기본값이 유지가 아니라 재검토가 되게 한다.
• 정밀도를 기본적으로 낮춘다. 숫자 값은 일단 버킷화하고, 정밀도가 필요하다는 근거가 나오면 그때 올린다.
• 보관 기간을 필드 민감도에 따라 다르게 둔다. 백엔드가 지원한다면 민감 필드만 짧게 보관한다. 지원하지 않으면 애초에 안 보내는 쪽으로 간다.
• 제거의 성공 사례를 공유한다. "이 필드를 뺐는데 조사에 아무 지장 없었다"는 경험이 쌓이면, 팀이 "혹시 몰라서 넣자"는 습관에서 벗어난다.

마지막 항목이 문화적으로 중요하다. 관측 데이터는 "많을수록 안심"이라는 심리가 작동하는 영역이라, 의식적으로 반대 방향의 근거를 쌓지 않으면 계속 늘어난다.

꼬리 질문

출처 · 참고자료