iOS와 Android의 딥링크: 실무 가이드

딥링크는 웹 페이지가 아니라 설치된 앱 안의 특정 화면을 여는 URL입니다. 개념은 그것이 전부이지만, 지난 15년 동안 서로 다른 세 가지 방식으로 구현되었고 각각 고장 나는 방식도 다릅니다. 마케팅 팀이 이 주제로 계속 버그를 접수하는 이유는 세 가지가 아직도 동시에 존재하기 때문이며, 같은 URL이라도 메시지에서 눌렀는지, 브라우저에서 눌렀는지, 이메일 클라이언트에서 눌렀는지, 소셜 앱 안의 내장 웹뷰에서 눌렀는지에 따라 다르게 동작할 수 있습니다.

이 가이드는 각 방식이 할 수 없는 일까지 포함해 그 구조를 정직하게 설명합니다. 하나만 가져가야 한다면 이것으로 하십시오. 클릭을 알맞은 앱 화면으로 보내는 일은 이미 해결된 인프라이고, 앱을 설치한 사용자를 알맞은 화면으로 보내는 일은 그렇지 않습니다. 적어도 링크 플랫폼만으로는 되지 않습니다.

앱 연결 방식의 세 세대

맞춤 URL 스킴

최초의 방식입니다. 앱이 myapp 같은 스킴을 등록하면 myapp://product/42 같은 URL이 요청을 그 앱에 넘깁니다. 스킴은 구현이 아주 간단하고 내부 라우팅 형식으로는 지금도 쓸모가 있지만, 구조적인 문제를 두 가지 안고 있습니다.

소유권 검증이 없습니다. 어떤 앱이든 아무 스킴이나 등록할 수 있고, 두 앱이 같은 스킴을 주장하면 iOS에서는 결과가 정의되지 않으며 Android에서는 선택 대화상자가 뜹니다. 그리고 대체 목적지가 없습니다. 앱이 설치되지 않은 기기에서 스킴 URL은 오류 페이지를 띄우거나 아무 일도 하지 않으므로, 모든 스킴 링크에는 실패를 감지해 사용자를 쓸모 있는 곳으로 보내는 감싸개가 필요합니다. 브라우저가 내비게이션 타이머 처리를 조이면서 깨진 것이 바로 그 취약한 부분입니다.

iOS의 Universal Links

Apple이 내놓은 대체 방식은 평범한 HTTPS URL을 씁니다. 앱은 applinks:yourbrand.com 형태의 연결 도메인 권한(associated domain entitlement)을 선언하고, 도메인은 어떤 경로가 앱에 속하는지 기술한 JSON 파일을 /.well-known/apple-app-site-association에 공개합니다.

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

이 파일은 리디렉션 없이 HTTPS로, JSON으로, 정확히 그 경로에서 제공되어야 합니다. iOS는 설치와 업데이트 무렵에 주로 Apple의 CDN을 거쳐 이 파일을 가져오므로, 변경이 즉시 반영되지는 않습니다. 이 방식의 장점은 같은 URL이 어디서나 동작한다는 점입니다. 앱이 설치되어 있고 경로가 일치하면 앱이 열리고, 그렇지 않으면 Safari가 웹 페이지를 엽니다. 오류 상태가 존재하지 않습니다.

Android의 App Links

Android의 대응 방식은 /.well-known/assetlinks.json에 두는 Digital Asset Links 파일을 사용하며, 여기에 앱 패키지와 서명 인증서의 SHA-256 지문(fingerprint)을 적습니다.

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

앱 쪽에서는 해당 도메인에 대해 자동 검증을 켠 인텐트 필터를 선언합니다. 검증에 성공하면 선택 대화상자 없이 링크가 앱을 엽니다. 실패하면 링크는 브라우저를 열며, 원인으로 가장 흔한 것은 단연 지문 불일치입니다. 팀이 로컬 릴리스 키의 지문을 공개해 두었는데 Play App Signing이 다른 키로 앱을 다시 서명하는 경우입니다. 파일에 들어가야 할 지문은 스토어가 배포되는 아티팩트에 대해 보여 주는 값입니다.

단축 링크는 목적지를 어떻게 고르는가

단축 링크는 고정된 포인터라기보다 판단이 이뤄지는 지점이며, 앱 캠페인에 유용한 이유가 바로 이것입니다. 인쇄한 코드 하나가 iPhone 사용자와 Android 사용자, 데스크톱 방문자를 각각 다르게 처리할 수 있고, 코드를 인쇄한 뒤에도 그 판단을 바꿀 수 있습니다.

리디렉션 엔진은 요청의 사용자 에이전트와 그 요청이 실어 오는 클라이언트 힌트, 그리고 국가처럼 네트워크에서 파생한 신호를 봅니다. 앱 트래픽용으로 구성한 링크는 보통 iOS URL, Android URL, 그 밖의 모든 경우에 쓰는 웹 URL이라는 세 가지 목적지를 담습니다. 그 위에 타기팅 규칙을 얹으면 국가, 기기, 운영체제, 언어로 경로를 나눌 수 있으므로, 캐나다의 Android 트래픽은 한 목적지로 보내고 나머지는 다른 목적지로 보내는 캠페인을 링크를 따로 만들지 않고도 구성할 수 있습니다.

알아 둘 만한 구현 세부 사항이 두 가지 있습니다. 헷갈리는 동작의 대부분이 여기서 설명되기 때문입니다.

첫째는 소셜 크롤러입니다. Facebook이나 Telegram의 수집기 같은 봇이 미리보기 카드를 만들려고 링크를 요청할 때, 제대로 된 리디렉션 엔진은 그 요청을 클릭으로 세지도 않고 휴대폰인 것처럼 라우팅하지도 않으며 미리보기 메타데이터로 응답합니다. 링크를 게시한 순간, 아직 아무도 누르지 않았는데 클릭 수가 튄다면 그 엔진은 이 일을 하지 않고 있는 것입니다.

둘째는 연결의 경계이며, 이 글에서 기술적으로 가장 중요한 지점입니다. Universal Links는 사용자가 실제로 탭한 URL의 도메인을 기준으로 평가됩니다. 누군가 go.yourbrand.com/p/42를 탭했고 그 도메인이 yourbrand.com/p/42로 리디렉션한다면, iOS는 리디렉션 목적지를 연결된 링크로 보지 않으므로 앱이 열리지 않습니다. 단축 링크가 앱을 네이티브로 열게 하려면 연결 파일을 단축 도메인 자체에서 제공해야 합니다. 그럴 수 없는 경우의 현실적인 대안은 맞춤 스킴이나 스토어로 바로 넘기는 것이며, 실제로 대부분의 단축 서비스 딥링크 기능이 하는 일이 이것입니다. 어느 쪽을 구현했는지 사업자에게 꼭 물어보십시오. 광고 문구는 어느 쪽이든 똑같기 때문입니다.

대체 경로의 사슬

제대로 동작하는 앱 링크는 사실 작은 의사결정 트리이며, 갈래마다 의도한 답이 필요합니다.

| 상황 | 무슨 일이 일어나야 하는가 | 흔한 실수 | | --- | --- | --- | | 앱이 설치되어 있고 경로도 인식됨 | 앱이 목표 화면에서 열림 | 리디렉션 체인이 연결을 깨뜨림 | | 앱은 설치되어 있으나 경로를 인식하지 못함 | 웹 페이지가 열리고 앱 사용을 안내 | 탭할 때마다 선택 대화상자가 뜸 | | 앱이 없는 모바일 | 해당 플랫폼의 스토어 페이지 | 스토어 링크가 한쪽 플랫폼으로 고정됨 | | 데스크톱 | 그 화면에 대응하는 완전한 웹 페이지 | 일반 메인 페이지로 떨어짐 | | 소셜 크롤러 | 미리보기 메타데이터, 클릭은 세지 않음 | 미리보기 요청이 분석을 부풀림 |

스토어 갈래는 링크 하나로 뭉뚱그리지 말고 플랫폼에 맞는 등록 페이지를 가리키게 하고, 웹 갈래는 앱 화면과 실질적으로 같은 내용으로 유지하십시오. 나머지를 아무리 잘 구성해도 앱 캠페인 트래픽의 상당 부분은 결국 웹 갈래로 향하므로, 그곳을 막다른 길로 두면 집행 예산의 대부분을 낭비하게 됩니다.

설치 경계에 대한 정직한 설명

사업자의 마케팅과 현실이 갈라지는 지점이 여기입니다. 신규 사용자가 특정 상품으로 가는 링크를 탭했는데 앱이 없어서 스토어로 이동하고, 설치한 뒤 앱을 열었다고 해 봅시다. 앱은 이제 기본 홈 화면을 보여 줍니다. 상품 식별자를 설치 너머로 실어 나른 것이 아무것도 없기 때문입니다. 이것을 동작하게 만드는 일을 디퍼드 딥링킹(deferred deep linking, 설치 이후로 미뤄진 딥링크 연결)이라고 부르며, 링크 플랫폼 혼자서 할 수 있는 일이 아닙니다.

앱 안에 SDK가 있어야 하고, 그 SDK가 첫 실행 때 사용자가 설치 전에 무엇을 탭했는지 서버에 물어봐야 합니다. 서버는 두 이벤트를 짝지어야 하는데, 그 대조에 쓸 수 있는 신호가 크게 줄었습니다. 기기 지문(fingerprint)은 신뢰하기 어렵고 플랫폼 정책의 제약도 점점 커지고 있습니다. 광고 식별자는 대부분의 사용자가 거절하는 동의를 필요로 합니다. Apple의 어트리뷰션 프레임워크는 여러분의 앱에 경로를 넘겨주는 것이 아니라 광고주에게 설치 단위의 기여도를 보고합니다. 한때 토큰을 실어 나르던 클립보드 기법은 이제 눈에 보이는 붙여넣기 알림을 띄웁니다.

남아 있는 방법은 동작하지만, 통합 비용이 다른 별개의 제품입니다. 모바일 측정 파트너(MMP) SDK, 앱 안에서의 초기화, 그리고 정확한 일치가 아니라 확률에 기대는 대조 시간 창이 필요합니다. LinkProfit은 기기별로 클릭을 라우팅하고 스토어로 넘겨주며, 설치 이후 라우팅을 제공한다고 주장하지 않습니다. 그것을 제대로 하려면 여러분의 앱 안에 코드를 넣어야 하기 때문입니다. 디퍼드 라우팅이 반드시 필요한 요구사항이라면, 링크 플랫폼을 대신하는 것이 아니라 그 옆에 그 SDK를 두는 것으로 계획하십시오.

웹뷰와 그 밖의 현실적인 함정

인앱 브라우저

소셜 앱 안에서 탭한 링크는 대부분 시스템 브라우저가 아니라 내장 웹뷰에서 열리며, 웹뷰는 앱 연결을 일관되게 처리하지 않습니다. 어떤 웹뷰는 Universal Links를 무시하고, 어떤 웹뷰는 맞춤 스킴을 차단하며, 동작은 앱 버전마다 다릅니다. 시험할 때는 완벽하게 동작하던 링크가 실제 운영에서 웹사이트를 여는 가장 흔한 원인이 이것입니다. 시험은 보통 메시지 앱에서 링크를 눌러 보는 방식으로 이뤄지고, 메시지 앱은 올바르게 동작하기 때문입니다.

이것을 한 번에 해결하는 설정은 없습니다. 통하는 방법은 웹 목적지를 잘 만들고, 거기에 앱에서 열기 버튼을 눈에 띄게 두고, 게시 채널마다 동작이 같으리라 가정하는 대신 하나씩 시험해 보는 것입니다.

연결 파일에서 나오는 실수

반복해서 나오는 것이 네 가지입니다. 연결 파일을 리디렉션을 거쳐 제공하는 것으로, 최상위 도메인에서 www로 가는 자동 리디렉션도 여기에 해당하며 그것만으로 파일이 무효가 됩니다. 잘못된 콘텐츠 타입으로 제공하거나 프레임워크가 다시 쓰는 경로에서 제공하는 것. 앞에서 설명한 대로 잘못된 Android 서명 지문을 공개하는 것. 그리고 iOS가 이 파일을 캐시한다는 사실을 잊는 것입니다. 이미 앱을 설치한 기기에 수정 사항이 닿기까지 하루 이상 걸릴 수 있습니다.

앱 갈래의 분석

클릭이 앱 안으로 들어가는 순간 웹 분석은 그것을 더 이상 보지 못하며, 보고가 조용히 무너지는 지점이 여기입니다. 캠페인 파라미터를 링크에 유지해 리디렉션 엔진이 기록하게 하고, 앱 목적지에도 식별자를 함께 넘겨 앱 안의 세션을 그 클릭과 이어 붙일 수 있게 하십시오. 링크 클릭 추적 가이드에서 클릭 이벤트가 알려 줄 수 있는 것과 없는 것을 다루며, 봇과 순 방문자에 대한 단서도 여기에 똑같이 적용됩니다.

게시하기 전에 시험하기

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

앞의 두 명령은 리디렉션 없이 200을 반환해야 합니다. Safari 주소창에 Universal Link를 입력하는 방식은 의도적으로 앱을 열지 않으므로, 메모나 메시지에서 누르거나 시뮬레이터 명령으로 시험하십시오. 그러지 않으면 있지도 않은 버그를 쫓게 됩니다.

링크 플랫폼이 실제로 포함하는 것

딥링크 지원은 업체마다 매우 다르게 묶여 있으며, 그 차이는 기능의 유무가 아니라 어느 요금제를 사야 하는가의 문제입니다.

| 사업자 | 딥링크 제공 범위, 2026년 8월 기준 | | --- | --- | | BL.INK | 모든 요금제, 입문 등급은 사용자 한 명과 도메인 하나에 월 48달러 | | Short.io | 월 48달러의 Team 요금제부터 | | Rebrandly | 월 99~119달러의 Growth 요금제부터 | | Switchy | 130개가 넘는 앱을 지원한다고 광고 | | LinkProfit | 모든 요금제에서 기기별 목적지 제공 |

여기서 정직한 기준점은 BL.INK입니다. 모든 등급에 딥링크를 넣는 것은 드문 일입니다. 물론 도메인 하나에 매기는 입문 가격은 높습니다. 일반적으로 눈여겨볼 패턴은 Rebrandly가 딥링크를 Growth에 둔 방식입니다. 기능 하나 때문에 필요해진 등급이 결국 청구서 전체를 결정하는 일이 많기 때문입니다.

실제로 통하는 배포 순서

1. 링크로 연결하려는 앱 화면마다 대표 웹 URL을 정하십시오. 웹 페이지가 대체 목적지이자 기준이 됩니다.
2. 링크에 실제로 등장할 도메인에 두 연결 파일을 모두 공개하고, 리디렉션 없이 HTTPS로 제공되는지 확인하십시오.
3. iOS에는 연결 도메인 권한을, Android에는 검증된 인텐트 필터를 추가하되, 배포되는 빌드의 지문을 사용하십시오.
4. 단축 링크가 어느 도메인에서 탭될지, 그리고 그 도메인에 연결이 있는지 아니면 플랫폼이 스킴이나 스토어로 넘기는지 확인하십시오.
5. 링크마다 기기별 목적지와 웹 대체 목적지를 구성하고, 스토어 등록 페이지는 플랫폼에 맞게 지정하십시오.
6. 두 플랫폼 모두에서 메시지 앱으로, 시스템 브라우저로, 그리고 여러분이 게시하는 모든 소셜 앱에서 시험하십시오.
7. 캠페인 파라미터가 리디렉션에서 살아남아 분석에 기록되는지 확인하십시오.
8. 캠페인별, 수신자별, 상품별로 링크를 생성한다면 API로 생성을 자동화하십시오.

하나씩 떼어 놓고 보면 어려운 일은 없습니다. 어려운 점은 조각들이 앱 프로젝트, DNS 존, 링크 플랫폼이라는 세 곳에 흩어져 있고, 대개 서로 다른 세 사람이 그것을 맡고 있다는 사실입니다. 연결 파일을 누가 책임지는지 적어 두는 것이 이 글의 어떤 개별 설정 조언보다 값어치가 큽니다.