Android App Links와 iOS Universal Links의 딥 라우팅 방식 차이점

App Links와 Universal Links의 차이점은 무엇인가요? Android App Links는 HTTPS 도메인의 디지털 에셋 링크(assetlinks.json)에 의존하는 반면, iOS Universal Links는 AASA(Apple App Site Association) JSON 파일을 필요로 합니다. 두 방식 모두 도메인 소유권을 검증하여 시스템 선택기 대화 상자를 우회합니다. 이러한 네이티브 라우팅은 도메인과 앱 간의 연결을 확립하며, 기존 URL Scheme 팝업의 번거로움을 제거하여 98.7%의 딥 링크 안정성을 확보합니다.

모바일 성장 및 앱 개발 분야에서, 업계는 App Links를 Android 딥 라우팅을 위한 가장 표준적인 방식으로 간주하고 있습니다. 최신 모바일 운영체제가 검증되지 않은 기존의 커스텀 리디렉션 프로토콜을 배제함에 따라, 개발자는 웹 도메인과 네이티브 앱 간의 검증된 암호화 핸드셰이크를 구축해야 하게 되었습니다. 이러한 연결이 없으면 사용자는 시스템 선택기 대화 상자를 계속 마주하게 되어 전환율이 크게 하락합니다.

리디렉션 과정에서의 모든 마찰은 즉각적인 사용자 이탈로 이어집니다. 모바일 사용자 경험을 최적화하려면 기술팀은 Android와 iOS의 근본적인 검증 아키텍처가 어떻게 다른지 이해해야 합니다.

도메인 검증 시대: 선택기 대화 상자의 마찰 제거

검증된 네이티브 라우팅이 도입되기 전, 모바일 플랫폼은 기존의 커스텀 프로토콜에 의존했습니다. 사용자가 웹 링크를 클릭할 때 브라우저는 대상 애플리케이션이 정식인지 악성인지 확인할 수 없었습니다. 이 보안 허점을 통해 악의적인 행위자가 동일한 커스텀 프로토콜을 등록하여 트래픽을 가로채는 일이 발생했습니다.

이를 해결하기 위해 최신 운영체제는 자동 도메인 검증을 도입했습니다:

• 선택기 대화 상자 제거: 도메인 소유권을 검증함으로써 운영체제는 “다음으로 열기…”와 같은 브라우저 선택 대화 상자를 우회합니다. 검증된 링크를 클릭하면 즉시 앱이 실행됩니다.
• 암호화된 연결: 두 플랫폼 모두 앱 설치 시 웹 도메인에 호스팅된 보안 JSON 매니페스트를 쿼리하여 신뢰할 수 있는 관계를 구축합니다.
• 샌드박스 격리: 리디렉션은 검증된 애플리케이션 내에서 샌드박스로 처리되어, 외부의 악성 앱이 인텐트 매개변수를 가로채는 것을 방지합니다.

현실적으로 이러한 설정을 올바르게 구현하려면 각 플랫폼의 고유한 파일 형식과 검증 파이프라인을 엄격히 준수해야 합니다.

연결 매니페스트 구성: Assetlinks JSON 대 AASA 사양

두 딥 라우팅 프로토콜의 핵심적인 기술적 차이는 연결 매니페스트의 구조와 각각의 호스팅 요구 사항에 있습니다.

Android Assetlinks JSON 프로토콜: 디지털 에셋 링크 파싱

Android App Links는 보안 HTTPS 도메인의 .well-known 디렉토리 내에 assetlinks.json이라는 이름의 JSON 파일을 요구합니다. 운영체제의 패키지 관리자는 앱 설치 시 이 파일을 쿼리하여 앱의 서명 인증서가 도메인에 선언된 에셋 링크와 일치하는지 확인합니다. 이 파일은 content-type 헤더로 application/json을 사용하여 제공되어야 하며, 앱의 정확한 패키지 이름과 SHA-256 지문 인증서가 포함되어야 합니다.

Android 에셋 검증 파일 형식을 지정하려면 아래의 표준 구조를 참조하세요:

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.opoinstall.travel",
      "sha256_cert_fingerprints": [
        "14:6D:E9:83:C5:30:06:22:98:5B:90:75:EF:C4:22:15:30:19:93:33:F4:6D:E9:83:C5:30:06:22:98:5B:90:75"
      ]
    }
  }
]

iOS AASA JSON 사양: Apple App Site Association 형식 지정

iOS Universal Links는 apple-app-site-association(AASA)이라는 서명되지 않은 JSON 파일에 의존합니다. Android와 마찬가지로 이 파일은 .well-known 디렉토리에 위치해야 합니다.

방법은 어떨까요? Google Play 서비스를 통해 App Links를 즉시 검증하는 Android와 달리, iOS는 Apple의 CDN 프록시를 통해 도메인을 쿼리합니다. 파일 구조는 애플리케이션 ID(10자리의 팀 ID와 번들 식별자의 조합)와 네이티브 실행을 트리거하는 와일드카드 경로 배열을 정의합니다.

iOS 연결 파일 형식을 지정하려면 아래의 표준 구조를 참조하세요:

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "6E65F4E7IUX.com.opoinstall.travel",
        "paths": [
          "/booking/*",
          "/promo/*"
        ]
      }
    ]
  }
}

Apple Universal Links 대 Android App Links: 프로토콜 및 검증 비교

운영체제 제약 조건 하에서 이러한 검증된 네이티브 라우팅 프로토콜이 레거시 URL Scheme과 어떻게 비교되는지 아래 기술 매트릭스를 분석해 보세요:

Opoinstall SDK를 사용하여 Universal Links 및 App Links 라우팅 자동화하기

수백 개의 동적 마케팅 캠페인에 걸쳐 AASA 및 Assetlinks 매니페스트를 구성, 검증 및 유지 관리하는 것은 엔지니어링 실패의 흔한 원인입니다. 통합 모바일 어트리뷰션 SDK를 도입하면 서버 측 호스팅 아키텍처 전체를 자동화하여 이러한 운영 문제를 해결할 수 있습니다.

개발자 콘솔에서 라우팅 도메인 등록

통합은 어트리뷰션 대시보드에 브랜드 도메인을 매핑하는 것으로 시작됩니다. 웹 랜딩 페이지를 네이티브 앱과 일치시키려면 교차 플랫폼 매핑에 관한 공식 딥 링크 통합 가이드를 참조하세요. SDK는 글로벌 CDN에서 AASA 및 assetlinks.json 파일을 자동으로 생성, 호스팅 및 암호화 서명하여 수동 서버 측 파일 유지 관리 작업을 완전히 제거합니다.

경량 SDK 프레임워크 통합

다음 단계는 클라이언트 빌드에 당사의 경량 원클릭 실행 모바일 SDK 프레임워크를 통합하는 것입니다. 이 비차단 라이브러리는 앱의 진입점에 후킹하여 들어오는 사용자 활동을 가로챕니다.

왜 중요할까요? 시스템의 기본 웨이크업 타이밍 시퀀스는 다음과 같이 실행됩니다:

1. 사용자가 외부 브라우저에서 검증된 HTTPS 캠페인 링크를 클릭합니다.
2. 운영체제가 URL 요청을 가로채고 로컬 레지스트리 데이터베이스를 쿼리하여 도메인이 설치된 앱과 연결되어 있는지 확인합니다.
3. 일치하는 항목이 있으면 OS는 웹 컨테이너를 완전히 우회하여 밀리초 내에 앱을 실행합니다.
4. OS는 URL 페이로드를 앱 델리게이트 또는 런처 액티비티에 직접 전달합니다.
5. 앱이 없는 경우, OS는 기본 브라우저에서 웹 페이지를 표시하는 것을 기본값으로 합니다.

대체 메커니즘 분석: URL Scheme이 앱 미설치 사용자를 구하는 방법

애플리케이션이 없어 네이티브 링크가 실패하면 플랫폼은 자동으로 표준 웹-투-앱 리디렉션으로 대체됩니다.

Android에서는 플랫폼이 Play 스토어를 우회하여 직접 APK 다운로드를 제공할 수 있으며, 표준 Google Play Install Referrer API를 활용하여 설치 페이로드를 캡처합니다. 이를 통해 초대 ID나 캠페인 추적 토큰과 같은 맞춤형 매개변수가 설치 장벽을 통과하여 안전하게 전달되므로, 최초 설치 시에도 끊김 없는 리퍼럴 루프를 보장합니다.

Android 12 검증 실패 디버깅: assetlinks 검증 사례 연구

한 주요 여행 애플리케이션이 표준 시스템 업데이트를 진행했습니다. 스테이징 과정에서 QA 팀은 Android 12 및 13 기기에서 프로모션 이메일의 딥 링크가 작동하지 않아 사용자가 네이티브 앱 대신 웹 브라우저를 선택해야 하는 문제가 발생했다고 보고했습니다.

비정상 증상: Android 12에서의 브라우저 선택 및 대화 상자 마찰

이전 기기에서는 딥 링크가 정상적으로 작동했습니다. 그러나 Android 12는 엄격한 검증 정책을 도입했습니다. 선언된 도메인 중 하나라도 assetlinks.json 핸드셰이크에 실패하면 시스템은 매니페스트에 선언된 모든 도메인에 대해 App Links를 비활성화하여, 사용자 여정을 짜증스러운 브라우저 선택 대화 상자로 되돌립니다.

CLI 검증 명령 및 Google의 검증 크롤러 확인

엔지니어링 팀은 기술 감사를 시작했습니다. 우선, Android Debug Bridge(ADB)를 통해 대상 기기에서 명령줄 권한 확인을 실행하여 패키지의 검증 상태를 검사했습니다:

# 로컬 패키지 관리자를 쿼리하여 Android App Link 도메인 검증
$ adb shell pm get-app-links com.opoinstall.travel

명령줄 출력은 state: 1024 (unverified) 상태를 반환했습니다. 이는 Android 패키지 관리자가 설치 중에 도메인-앱 연결을 거부했음을 확인해 주었습니다.

Digital Asset Links JSON 정렬 및 SSL 핸드셰이크 조정

개발자들은 오류를 격리하기 위해 Google의 디지털 에셋 링크 검증 크롤러를 쿼리했습니다. 크롤러 로그에는 TLS 핸드셰이크 타임아웃이 나타났습니다. 웹 서버가 자동화된 Google 크롤러 IP를 차단하는 방화벽 뒤에 assetlinks.json 파일을 호스팅하고 있었기 때문입니다.

또한 서버는 HTTP 포트에서 HTTPS로 301 리디렉션을 실행하고 있었습니다. Android의 검증 시스템은 App Links에 대해 HTTP 리디렉션을 엄격히 금지하기 때문에 자동 핸드셰이크가 실패했습니다.

차단을 해결하기 위해 팀은 웹 서버를 구성하여 HTTP 리디렉션을 우회하고, application/json 헤더와 함께 443 포트에서 직접 HTTP 200 응답을 반환하도록 했습니다.

마이그레이션 후 성능 감사: 98.7% 리디렉션 정확도 도달

업데이트된 패키지를 다시 설치한 후 엔지니어링 팀은 ADB 검증 도구를 다시 실행했습니다. 명령은 verified 상태를 반환했습니다.

SDK는 선택기 대화 상자를 트리거하지 않고도 딥 링크 인텐트를 즉시 가로챘습니다. 교차 플랫폼 리디렉션 정확도는 98.7%로 다시 급증하여, 모든 캠페인 사용자에게 원활한 예약 경험을 성공적으로 복구하고 고객의 마케팅 투자 수익(ROI)을 보호했습니다.