본문으로 건너뛰기
Didit, 신원·사기 방지 인프라 구축 위해 750만 달러 투자 유치
Didit
블로그로 돌아가기
블로그 · 2026년 3월 13일

Safari ITP 및 추적 방지 기능을 위한 iOS SDK 최적화 전략 (KO)

Safari의 지능형 추적 방지(ITP) 및 기타 개인 정보 보호 기능은 끊임없이 진화하며, 기존 추적 방법에 의존하는 iOS SDK에 어려움을 안겨줍니다. 이 글에서는 이러한 변화에 대응하기 위한 iOS SDK 최적화 방안을 제시합니다.

작성자: Didit업데이트됨
optimizing-ios-sdk-safari-itp-tracking-prevention.png

퍼스트 파티 컨텍스트 활용Safari의 ITP는 서드 파티 쿠키를 강력하게 제한합니다. 가능한 한 서버 측 솔루션이나 직접 통합을 활용하여 퍼스트 파티 컨텍스트 내에서 작동하도록 iOS SDK를 설계하세요.

개인 정보 보호 식별자 우선 적용영구적인 교차 사이트 식별자에서 벗어나세요. 사용자 개인 정보 설정과 Apple의 앱 추적 투명성 프레임워크를 존중하여 일시적이거나 사용자 동의를 얻은 식별자에 집중하세요.

강력한 대체 기능 구현일부 데이터 포인트 또는 추적 메커니즘이 차단될 수 있음을 예상하세요. ITP가 활성화된 경우에도 핵심 기능을 유지할 수 있도록 점진적 성능 저하 및 대체 전략을 갖춘 SDK를 구축하세요.

Apple 정책 최신 정보 유지ITP 및 개인 정보 보호 정책은 동적입니다. Apple 개발자 문서 및 개인 정보 업데이트를 정기적으로 검토하여 SDK가 규정을 준수하고 효과적으로 작동하는지 확인하세요.

Safari의 지능형 추적 방지(ITP)는 특히 서드 파티 쿠키 및 영구 식별자에 의존하는 개발자들에게 웹 추적 환경을 근본적으로 변화시켰습니다. iOS SDK의 경우, 웹 뷰와 통합하거나 교차 도메인 통신을 처리할 때 독특한 일련의 과제를 제시합니다. Apple이 앱 추적 투명성(ATT)과 같은 기능 및 데이터 수집에 대한 엄격한 정책을 통해 사용자 개인 정보 보호에 지속적으로 노력함에 따라, SDK 개발자는 기능성을 보장하고 데이터 무결성을 유지하며 사용자 동의를 존중하기 위해 전략을 사전에 조정해야 합니다.

이 블로그 게시물은 iOS Safari 내 ITP 및 유사한 개인 정보 보호 메커니즘의 복잡성을 자세히 설명하며, SDK를 최적화하기 위한 실행 가능한 통찰력과 실제 사례를 제공합니다. 우리의 목표는 안정적으로 작동할 뿐만 아니라 개인 정보 보호에 대한 인식이 높아지는 디지털 세상에서 사용자 신뢰를 높이는 탄력적이고 개인 정보 보호 중심적인 SDK를 구축하도록 돕는 것입니다.

Safari ITP 이해 및 iOS SDK에 미치는 영향

지능형 추적 방지(ITP)는 Safari(및 WebKit)에 내장된 개인 정보 보호 강화 기술 세트입니다. 주요 기능은 서드 파티가 쿠키 및 기타 웹사이트 데이터 형식을 사용하는 것을 제한하여 교차 사이트 추적을 제한하는 것입니다. 수년 동안 ITP는 여러 반복을 거치며 각각 더 엄격한 제어를 도입했습니다.

  • 서드 파티 쿠키 차단: 가장 중요한 측면입니다. ITP는 서드 파티 쿠키를 공격적으로 분할하거나 차단하여 광고주 및 분석 제공업체가 여러 웹사이트에서 사용자를 추적하기 어렵게 만듭니다.
  • Storage Access API: 사용자가 상호 작용할 때 임베디드 콘텐츠가 퍼스트 파티 스토리지에 대한 액세스를 요청할 수 있도록 하는 개인 정보 보호 중심적인 방법으로 도입되었습니다.
  • 링크 장식 보호: ITP는 링크 장식을 통한 추적을 방지하기 위해 URL에서 추적 매개변수를 제거할 수도 있습니다.
  • 리퍼러 정책: Safari는 종종 더 제한적인 리퍼러 정책(예: strict-origin-when-cross-origin)을 보내 서드 파티 사이트로 전달되는 정보의 양을 제한합니다.
  • 일시적 바운스 추적 방지: 트래커가 퍼스트 파티 쿠키를 설정하기 위해 자신의 사이트를 통해 사용자를 리디렉션하는 기술을 식별하고 완화합니다.

iOS SDK, 특히 웹 콘텐츠와 상호 작용하는 SDK(예: 인앱 브라우저, 인증 흐름, 결제 게이트웨이 또는 임베디드 분석)의 경우 ITP의 영향은 심각할 수 있습니다. SDK가 WKWebView 내에서 서드 파티 도메인의 쿠키를 설정하거나 읽는 데 의존하거나 특정 리퍼러 정보가 전달될 것으로 예상하는 경우 ITP는 이러한 메커니즘을 손상시켜 다음을 초래할 수 있습니다.

  • 인증 또는 결제 프로세스 실패.
  • 부정확한 어트리뷰션 또는 분석 데이터.
  • 상태 또는 세션 정보 누락으로 인한 손상된 사용자 경험.

ITP 방지 iOS SDK 개발 전략

ITP에 적응하려면 기존 추적 방식에서 개인 정보 보호 중심 데이터 처리 방식으로 사고방식을 전환해야 합니다. 다음은 주요 전략입니다.

1. 퍼스트 파티 컨텍스트 및 서버 측 솔루션 우선 적용

서드 파티 쿠키에 대한 ITP의 제한을 우회하는 가장 효과적인 방법은 퍼스트 파티 컨텍스트 내에서 작동하는 것입니다. 이는 쿠키를 설정하거나 스토리지에 액세스하는 도메인이 사용자가 현재 방문하는 도메인과 동일하다는 것을 의미합니다.

실제 사례: 분석을 위한 서버 측 추적

자체 쿠키를 설정하려는 WKWebView에 임베디드된 서드 파티 분석 스크립트에 의존하는 대신 서버 측 접근 방식을 고려하세요.

  1. SDK 데이터 수집: iOS 앱(또는 WKWebView 내의 웹 콘텐츠)은 관련 사용자 상호 작용 데이터(예: 제품 조회, 버튼 클릭)를 수집합니다.
  2. 백엔드로 데이터 전송: 이 데이터는 자체 백엔드 서버로 직접 전송됩니다.
  3. 백엔드, 분석 제공업체로 전달: 백엔드는 이 데이터를 분석 제공업체의 API로 전달합니다. 이 통신은 서버 대 서버로 이루어지므로 클라이언트 측 쿠키에 대한 ITP 제한을 우회합니다.

이 접근 방식은 데이터에 대한 완전한 제어를 제공하고, 안정적으로 전송되도록 보장하며, 브라우저 측 추적 방지에 영향을 받지 않습니다.

2. 교차 사이트 요구 사항을 위한 Storage Access API 활용

임베디드 WKWebView 내에서 교차 사이트 쿠키에 대한 액세스가 절대적으로 필요한 경우(예: 신원 공급자와의 단일 로그인), Storage Access API는 승인된 개인 정보 보호 중심적인 방법입니다. 이 API를 통해 서드 파티 콘텐츠는 사용자가 상호 작용할 때 퍼스트 파티 스토리지에 대한 명시적인 권한을 요청할 수 있습니다.

실제 사례: WKWebView의 원활한 SSO

SDK가 SSO를 달성하기 위해 신원 공급자(IDP)의 쿠키에 액세스해야 하는 인증 흐름을 위해 WKWebView를 임베드한다고 가정해 보세요. Storage Access API가 없으면 Safari는 이러한 쿠키를 차단합니다.

클라이언트 측(임베디드 웹 콘텐츠 내):

document.requestStorageAccess().then(function() {
    // 스토리지 액세스 권한이 부여되었습니다. 이제 쿠키를 사용하는 요청을 할 수 있습니다.
    // 예: SSO iframe 로드 또는 IDP에 대한 XHR 요청
}).catch(function() {
    // 스토리지 액세스가 거부되었거나 사용자 상호 작용이 필요합니다.
    // 적절히 처리하고, 전체 리디렉션 로그인으로 대체할 수 있습니다.
});

iOS SDK (WKUIDelegateWKNavigationDelegate):

Safari가 제시하는 사용자 프롬프트를 처리해야 합니다. WKUIDelegate 메서드 webView:requestMediaCapturePermissionFor:initiatedBy:decisionHandler:(또는 유사한 권한 요청)가 호출될 수 있지만, 스토리지 액세스의 경우 프롬프트는 일반적으로 Safari 자체에서 처리됩니다. WKWebViewConfiguration, 특히 websiteDataStore가 올바르게 설정되었는지 확인하세요.

3. 개인 정보 보호 식별자 및 사용자 동의 채택

앱 추적 투명성(ATT)을 통해 Apple은 다른 회사가 소유한 앱 및 웹사이트 간 추적에 대한 명시적인 사용자 동의를 요구합니다. SDK는 이를 존중해야 합니다. 동의 없이 추적 목적으로 영구적인 장치 식별자에 의존하는 것을 피하세요.

실제 사례: ATT 및 IDFA 처리

SDK가 이전에 어트리뷰션 또는 타겟팅을 위해 광고주 식별자(IDFA)에 의존했다면:

  1. ATT 권한 요청: IDFA에 액세스하기 전에 사용자 권한을 요청하려면 AppTrackingTransparency.framework를 사용하세요.
  2. 조건부 IDFA 사용: 사용자가 권한을 부여한 경우에만 IDFA를 검색하고 사용하세요.
  3. 대체 식별자: 거부된 경우, 교차 사이트 추적에 사용되지 않는 컨텍스트별, 일시적 식별자(예: 세션 ID) 또는 서버 생성, 비영구적 ID에 의존하세요.

Swift 예시:

import AppTrackingTransparency
import AdSupport

func requestTrackingAuthorization() {
    if #available(iOS 14, *) {
        ATTrackingManager.requestTrackingAuthorization { status in
            switch status {
            case .authorized:
                let idfa = ASIdentifierManager.shared().advertisingIdentifier.uuidString
                print("IDFA: \(idfa)")
                // 동의된 추적에 IDFA 사용
            case .denied, .notDetermined, .restricted:
                print("ATT 권한이 거부되었거나 결정되지 않았습니다.")
                // 다른 개인 정보 보호 중심 방법 사용
            @unknown default:
                break
            }
        }
    } else {
        // iOS 14 이전 버전용 대체 기능
        // ASIdentifierManager.shared().isAdvertisingTrackingEnabled를 통해 추적 활성화 여부 확인
    }
}

Didit이 돕는 방법

Didit은 올인원 신원 플랫폼으로서 개인 정보 보호 우선 접근 방식을 본질적으로 따르므로 ITP 및 유사한 추적 방지 메커니즘에 강력하게 대처할 수 있습니다. 우리의 핵심 목표는 교차 사이트 추적이 아닌 실제 사람을 안전하게 확인하는 것입니다. Didit의 아키텍처는 단일의 통제된 시스템 내에서 신원 확인, 생체 인식, 사기 감지 및 인증을 처리하도록 설계되어 서드 파티 추적 쿠키에 대한 의존도를 최소화합니다. 우리는 다음을 통해 이를 달성합니다.

  • 퍼스트 파티 통합: Didit의 SDK 및 API는 응용 프로그램에 직접, 퍼스트 파티 통합되도록 설계되어 신원 확인 프로세스가 앱의 컨텍스트 내에서 발생하도록 하여 교차 사이트 추적과 관련된 ITP 문제를 크게 우회합니다.
  • 서버 측 처리: AML 심사 및 사기 신호 분석과 같은 Didit의 강력한 기능 중 상당수는 서버 대 서버로 작동합니다. 이는 민감한 데이터 처리 및 신원 확인이 백엔드에서 안전하게 이루어져 클라이언트 측 추적 취약성을 제거한다는 것을 의미합니다.
  • 일시적 생체 인식: Didit은 생체 인식 데이터를 메모리에서 처리하고 삭제하며, 응용 프로그램에 부울 결과만 반환합니다. 이러한 "설계에 의한 개인 정보 보호" 접근 방식은 추적을 위한 영구적인 생체 인식 식별자를 저장하지 않으므로 ITP의 목표와 완벽하게 일치합니다.
  • 안전한 인증 흐름: 생체 인식 재인증을 포함한 우리의 인증 방법은 상태 관리를 위해 교차 사이트 쿠키에 의존하지 않는 챌린지-응답 메커니즘을 사용하여 안전하고 비공개적으로 구축됩니다.
  • 규정 준수 및 신뢰: SOC 2 Type II, ISO 27001 및 GDPR을 준수하는 Didit은 데이터 개인 정보 보호 및 보안 기반 위에 구축되어 추적 방지 기술의 변화에 자연스럽게 탄력적인 플랫폼입니다.

시작할 준비가 되셨나요?

Safari의 ITP 및 더 넓은 개인 정보 보호 환경에 맞게 iOS SDK를 조정하는 것은 단순한 규정 준수를 넘어 사용자 신뢰를 구축하고 제품의 수명을 보장하는 것입니다. 퍼스트 파티 컨텍스트를 수용하고, Storage Access와 같은 적절한 API를 활용하며, 사용자 동의를 우선시하고, Apple의 진화하는 정책에 대한 정보를 지속적으로 얻음으로써 강력하고 개인 정보 보호를 존중하는 SDK를 만들 수 있습니다.

Didit의 개인 정보 보호 우선 신원 플랫폼이 규정 준수를 단순화하고 사용자 경험을 향상시키는 방법을 살펴보세요. 저희 웹사이트를 방문하거나, 기술 문서를 확인하거나, 데모를 요청하여 Didit의 작동 방식을 확인하세요.

신원 및 사기 방지 인프라.

KYC, KYB, 거래 모니터링, 지갑 심사를 위한 단일 API. 5분 만에 통합하세요.

AI에게 이 페이지 요약 요청
Safari ITP 및 추적 방지를 위한 iOS SDK 최적화.