딥링크 실전 (유형별 작동 원리와 구축 선택)

🤔 혹시 이런 생각 해본 적 없나요?

• "광고를 눌러 들어온 사용자가 설치 후에 홈 화면에 떨어져 상품을 다시 찾는다."
• "웹에서는 잘 열리던 링크가 앱 사용자에게는 브라우저로 열려 로그인을 또 시킨다."
• "다이나믹 링크로 만들어 둔 링크들이 있는데 서비스가 끝났다니 어떻게 해야 하지?"

기초 코스의 딥링크에서 개념을 확인했다면, 이번 클래스는 실제로 구축할 때 만나는 선택지들을 다룹니다. 코호트 분석에서 재방문이 쌓여야 전환이 늘어난다고 했는데, 그 재방문의 길을 놓는 공사가 딥링크 구축입니다.

🚉 딥링크는 목적지까지 이어지는 환승 안내입니다

딥링크 실전 구축은 링크를 누른 사람의 설치 여부와 기기를 판별해, 미설치자는 스토어로 보내고 설치자는 앱 안 화면까지 데려다주는 연결을 설계하는 작업입니다.

지하철 환승에 비유하면 구조가 보입니다. 웹 주소는 역 이름까지만 알려 주는 표지판이라, 역에 내린 다음 출구를 직접 찾아야 합니다. 딥링크는 몇 번 출구로 나가 어느 건물로 들어가는지까지 적힌 환승 안내입니다. iOS 사용자와 안드로이드 사용자, 앱을 깐 사람과 안 깐 사람이 같은 링크를 눌러도 각자에게 맞는 경로로 안내되는 것이 목표입니다.

딥링크가 필요해진 이유가 여기 있습니다. 같은 콘텐츠라도 iOS와 안드로이드, 웹의 도착지가 전부 다른데, 링크는 하나만 공유되기 때문입니다. 문자와 SNS로 퍼지는 링크, 푸시에 싣는 링크, 광고의 도착 링크가 모두 이 판별을 거쳐야 사용자가 길을 잃지 않습니다.

🔗 앱스킴과 유니버설 링크: 두 가지 문법

딥링크의 바탕 기술은 두 가지 문법으로 나뉩니다.

앱스킴은 기기 안에서만 통하는 약속입니다. 링크를 누르면 시스템이 그 스킴을 받을 수 있는 앱을 찾고, 있으면 앱을 열면서 지정된 화면으로 보냅니다. 문제는 앱이 없을 때입니다. 스킴을 받을 앱이 없으면 링크가 그냥 죽어 버리므로, 미설치자가 섞인 바깥 세상에 이 링크를 그대로 뿌릴 수 없습니다.

유니버설 링크와 앱 링크는 보통의 https 주소를 씁니다. 앱이 있으면 앱이 열리고 없으면 웹이 열리므로 어느 쪽이든 막다른 길이 없습니다. 대신 조건이 붙습니다. 도메인의 소유를 증명하는 파일을 서버에 올려 두어야 하고, iOS의 유니버설 링크는 주소창에 직접 붙여 넣으면 동작하지 않는 것처럼 동작 조건이 까다로운 편입니다.

⏳ 디퍼드 딥링크: 설치를 건너서 목적지까지

실무에서 성과를 가르는 것은 미설치자 처리입니다. 두 흐름을 나란히 놓으면 차이가 보입니다.

• 일반 딥링크: 클릭 → 기기와 설치 여부 판별 → 미설치자는 스토어로 → 설치 후 앱을 열면 홈 화면
• 디퍼드 딥링크: 클릭 → 판별 → 스토어로 → 설치 후 첫 실행에서 원래 보려던 화면

디퍼드(deferred)는 지연됐다는 뜻입니다. 클릭 시점에 가려던 목적지를 기억해 뒀다가, 설치라는 긴 환승을 거친 뒤에도 이어서 안내하는 방식입니다. 광고에서 특정 상품을 보여 주고 설치를 받았는데 첫 화면이 홈이라면, 사용자는 그 상품을 다시 찾다가 이탈하기 쉽습니다. 설치 전 클릭과 설치 후 첫 실행을 잇는 이 기억은 보통 MMP나 딥링크 전문 도구가 맡습니다.

여기서 오해 하나를 정리하고 가겠습니다. 앱 설치 광고 자체에는 딥링크가 필요 없다고 여기는 경우가 있는데, 설치가 목표인 캠페인이라도 도착 경험까지 설계하면 설치 후 행동이 달라집니다. 반대로 이미 설치한 사용자를 다시 부르는 리타겟 광고에서는 딥링크가 선택이 아니라 전제입니다. 앱을 두고도 웹 로그인 화면으로 보내는 리타겟 광고는 비용만 쓰는 셈이 됩니다.

📍 딥링크가 바로 쓰이는 세 곳

구축한 딥링크는 캠페인 곳곳에서 곧바로 쓰입니다. 이 코스에서 다룬 것들과 이어 보면 이렇습니다.

• 푸시 알림: 푸시 운영의 발송 설계에서 도착 지점을 딥링크로 연결한다고 했습니다. 할인 알림을 눌렀는데 홈이 나오는 것과 그 상품이 나오는 것의 차이가 여기서 나뉩니다.
• 리타겟 광고: 이미 설치한 사용자를 부르는 광고는 앱 안 화면으로 직행해야 합니다. 장바구니에 담아 둔 상품 화면으로 바로 여는 식입니다.
• 공유와 초대: 사용자가 친구에게 보낸 링크는 받는 쪽의 기기와 설치 여부를 알 수 없는 대표적인 경우입니다. 미설치 친구는 스토어로, 설치 친구는 해당 콘텐츠로 이어져야 공유가 성과로 연결됩니다.

셋의 공통점은 링크를 누르는 순간이 아니라 도착한 다음이 성과를 정한다는 것입니다. 유입을 만드는 비용은 이미 나갔으므로, 도착 경험이 나쁘면 그 비용이 마지막 한 걸음에서 새어 나갑니다.

🔚 다이나믹 링크 종료 이후의 선택지

구축 도구를 고를 때 반드시 알아야 할 변화가 있습니다. 무료 대표 도구였던 파이어베이스 다이나믹 링크(Firebase Dynamic Links)가 종료됐습니다.

공식 FAQ 기준으로 서비스는 2025년 8월 25일에 종료됐고, 그날 이후 기존 링크도 동작하지 않습니다. 무료라는 이유로 다이나믹 링크에 얹어 둔 링크가 있다면 이미 끊긴 상태이므로, 문자와 QR과 이메일에 뿌려진 옛 링크부터 점검하는 것이 순서입니다.

지금 시점의 선택지는 이렇게 정리됩니다.

• MMP의 딥링크 기능: 앱스플라이어의 원링크(OneLink)처럼 어트리뷰션 도구에 딸린 딥링크를 씁니다. 이미 MMP를 쓰고 있다면 측정과 딥링크가 한곳에 모여 관리가 단순해집니다.
• 딥링크 전문 도구: 브랜치(Branch) 같은 전문 서비스를 붙입니다.
• 직접 구축: 유니버설 링크와 앱 링크를 자체 도메인으로 구성합니다. 외부 의존이 없는 대신 디퍼드 처리는 따로 만들어야 합니다.

구글도 종료 안내에서 타사 딥링크 서비스로의 이전을 권하고 있으므로, 어느 쪽이든 옮기는 것 자체는 정해진 수순입니다. 고르는 기준은 리타겟 광고를 돌리는지(MMP 연동이 유리), 링크를 만드는 사람이 마케터인지 개발자인지(도구의 관리 화면 유무)입니다.

🧭 구축 뒤에 확인할 것

링크를 깔았다면 끝이 아니라 검수가 남습니다.

1. 경우의 수를 표로 만들어 직접 눌러 봅니다. iOS와 안드로이드, 설치자와 미설치자, 카카오톡과 문자와 브라우저처럼 링크가 열리는 환경을 조합하면 확인할 조합이 열 개 안팎 나옵니다. 하나씩 눌러 도착지를 기록합니다.
2. 유입 경로별 성과를 나눠 봅니다. 딥링크에 캠페인 구분 값을 붙여 두면 푸시로 온 재방문과 SNS 공유로 온 재방문이 나뉘어 보입니다. 웹의 UTM과 같은 발상입니다.
3. 재방문 기여를 코호트로 확인합니다. 딥링크를 깐 뒤 푸시와 리타겟으로 돌아온 집단의 잔존이 나아졌는지를 이전 클래스의 세로 읽기로 비교합니다.

❓ 딥링크와 어트리뷰션 링크는 같은 건가요?

역할이 다른데 한 링크가 겸하는 경우가 많습니다. 딥링크는 사용자를 알맞은 화면으로 데려다주는 안내 역할이고, 어트리뷰션 링크는 그 유입이 어느 매체의 공적인지 기록하는 측정 역할입니다.

MMP가 만들어 주는 링크는 보통 두 역할을 함께 합니다. 그래서 MMP의 딥링크 기능을 쓰면 안내와 측정이 한 링크로 정리되고, 유입 경로별 성과 비교도 같은 화면에서 이어집니다.

❓ 다이나믹 링크로 만들어 둔 QR 코드는 어떻게 되나요?

이미 동작하지 않습니다. 2025년 8월 25일 종료와 함께 기존 링크가 전부 끊겼으므로, 인쇄물과 매장 안내판에 깔린 QR 코드는 스캔해도 목적지로 이어지지 않습니다.

새 도구로 링크를 다시 만들고 QR 코드도 다시 발급해야 합니다. 어디에 배포했는지 목록부터 만들어 인쇄물, 이메일 서명, 오래된 게시글 순으로 바꿔 나가는 것이 현실적인 순서입니다.

📋 3줄 요약

1. 딥링크 실전 구축은 링크를 누른 사람의 설치 여부와 기기를 판별해 미설치자는 스토어로 보내고 설치자는 앱 안 화면까지 연결하는 작업입니다.

2. 일반 딥링크는 설치를 마친 사용자를 홈 화면에 떨어뜨리지만 디퍼드 딥링크는 첫 실행에서 원래 보려던 화면까지 데려갑니다.

3. 무료로 쓰이던 파이어베이스 다이나믹 링크는 2025년 8월 25일 종료됐고 그날 이후 기존 링크도 동작하지 않으므로 문자와 QR에 뿌린 옛 링크부터 점검합니다.

참고 자료

• 동적 링크 지원 중단 FAQ, Firebase 공식 문서
• 유니버설 링크 안내, Apple Developer
• Android 앱 링크 안내, Android Developers