딥링크 (Deeplink)

🤔 혹시 이런 경험 있지 않나요?

• "친구가 보낸 상품 링크를 눌렀더니 앱 홈만 열려서 상품을 다시 검색했다"
• "푸시 알림을 눌렀는데 알림 내용과 상관없는 첫 화면이 나왔다"
• "아이폰으로 보낸 링크가 갤럭시 친구에게는 이상하게 열린다"

링크 설정이나 앱의 화면 처리, 로그인 상태 등을 확인할 상황입니다. 이 문제를 푸는 기술이 딥링크이고, 앱마케팅에서 공유와 재방문을 설계할 때 빠지지 않고 등장합니다.

🔑 딥링크, 한마디로 뭘까요?

딥링크(Deeplink)는 앱을 열어 특정 화면까지 바로 이동시키는 링크로, 웹 주소처럼 앱 안의 목적지를 지정하는 기술입니다.

쉽게 설명하자면 주소의 상세함 차이라고 할 수 있습니다. 보통의 앱 실행은 "OO아파트 정문까지"만 적힌 주소와 같습니다. 정문(앱 홈 화면)에 내려 주면 끝이라, 방문자는 동과 호수를 직접 찾아가야 합니다. 딥링크는 "OO아파트 3동 502호"까지 적힌 주소입니다. 앱이 링크를 처리하도록 설정되어 있고 접근 조건을 충족하면 지정한 화면(상품 상세, 이벤트 페이지, 특정 게시글)을 엽니다.

웹에서도 특정 페이지로 바로 연결하는 링크를 딥링크라고 부를 수 있습니다. 이 글은 앱 화면으로 연결하는 경우를 다룹니다. 웹 주소 역시 로그인이나 접근 권한이 필요할 수 있습니다. 앱도 링크와 화면을 연결하는 구현이 있어야 하며 주소 문자열만 적는 것으로 끝나지 않습니다.

🧭 딥링크가 생겨난 배경

딥링크가 풀어야 했던 문제는 두 겹입니다.

첫째, 기기와 운영체제(OS)마다 도착지가 달라지는 문제입니다. 아이폰 사용자가 공유한 링크를 갤럭시 사용자가 열면, 같은 링크라도 열리는 환경이 다릅니다. 앱이 있는 사람과 없는 사람, iOS와 Android, 모바일과 PC까지 조합이 늘어날수록 "누가 눌러도 올바른 곳에 도착하는 링크"를 만드는 일이 어려워집니다.

둘째, 웹과 앱을 넘나드는 여정의 끊김입니다. 광고, 문자, 이메일, SNS 게시물은 대부분 웹 링크로 시작하는데, 정작 서비스의 최종 목적지는 앱 안의 화면인 사례가 많습니다. 이 사이를 이어 주지 못하면 사용자는 홈 화면에서 목적지를 다시 찾아야 하고, 그 과정이 번거로워 이용을 포기할 수 있습니다.

🔗 앱스킴과 유니버설 링크, 앱 링크의 차이

딥링크 주소를 만드는 방식은 크게 앱스킴과 유니버설 링크, 앱 링크로 나눕니다. 주소 형식을 고르는 일과 앱이 그 주소를 받아 화면을 열도록 구현하는 일은 따로 하는 작업입니다.

앱스킴(URL Scheme)은 myapp://product?id=123처럼 앱이 자기 것으로 등록한 주소 형식입니다. 휴대전화 운영체제가 이 주소를 처리할 앱을 찾아 열고, 앱이 주소 속 상품 번호를 읽어 상품 화면을 엽니다. 앱이 설치되어 있지 않으면 이 주소를 처리할 앱이 없어서 아무 일도 일어나지 않거나 오류가 납니다. 같은 스킴을 다른 앱도 등록할 수 있다는 점도 약점입니다.

유니버설 링크(Universal Links)는 iOS에서, 앱 링크(App Links)는 Android에서 https:// 웹 주소를 앱과 연결하는 기능입니다. 앱 설정과 웹 서버에 올린 확인 파일로 그 도메인을 앱 운영자가 소유했는지 운영체제가 확인합니다. 도메인은 example.com처럼 웹사이트를 구별하는 주소 이름입니다. 앱이 없으면 같은 주소의 웹페이지가 열립니다.

앱이 설치되어 있어도 사용자 설정이나 링크를 누른 앱의 동작에 따라 웹페이지가 열리는 경우가 있습니다. 그래서 링크를 검증할 때는 주소창에 붙여 넣은 결과가 아니라 실제 문자, 광고, 메신저에서 링크를 누른 결과로 확인합니다.

🔀 일반 딥링크와 디퍼드 딥링크

디퍼드(deferred)는 ‘나중으로 미룬’이라는 뜻입니다. 앱이 없는 상태에서 누른 목적지를 설치 후까지 이어 주는 방식을 디퍼드 딥링크라고 합니다. 앱 화면으로 바로 연결하는 동작과 설치 과정을 넘어서 목적지를 복원하는 동작을 구분합니다.

일반 딥링크가 미설치자를 자동으로 스토어로 보내는 것은 아닙니다. HTTPS 웹 주소를 사용하는 링크는 웹페이지를 열 수도 있고, 앱 전용 주소는 처리할 앱이 없어 실패할 수도 있습니다. 앱이 없을 때 어디로 보낼지를 별도로 정합니다.

앞에서 본 유니버설 링크와 앱 링크는 설치된 앱을 여는 기능이어서, 이 설정만으로 설치 후 목적지 복원까지 되지는 않습니다.

앱 광고의 기여를 분석하는 MMP나 전문 링크 서비스가 이런 기능을 제공하기도 합니다. 그래도 앱 개발팀의 연결 구현과 테스트가 필요합니다. 운영체제, 브라우저와 링크를 누른 앱, 개인정보 설정 및 서비스의 지원 조건에 따라 결과가 달라질 수 있습니다.

본문 내용을 시각화한 학습용 도식입니다. 실제 서비스 화면이 아닙니다. 디퍼드 딥링크가 설정되고 정상 처리되는 경우의 개념도입니다. 실제 동작은 플랫폼과 설정에 따라 검증해야 합니다.

📣 마케팅에서 딥링크가 일하는 곳

딥링크는 사용자가 약속된 화면을 찾도록 돕습니다. 링크가 제대로 열린 것과 이후 성과가 생긴 것은 따로 확인합니다.

• 공유와 추천: 공유받은 상품이나 글로 연결하고, 삭제된 콘텐츠라면 안내와 다른 탐색 경로를 제공합니다.
• 푸시 알림: 알림 내용과 도착 화면을 맞춥니다. 장바구니 상품 할인 안내라면 할인 대상 상품 화면이나 장바구니에서 실제 혜택을 확인할 수 있어야 합니다.
• 리타겟팅 광고: 한동안 접속하지 않은 사용자를 되부르는 광고에서, 딥링크는 사용자가 보던 상품이나 새 혜택 화면으로 곧장 연결해 복귀 문턱을 낮춥니다.
• 채널 기여 확인: 채널 구분 값을 링크에 넣어 수집하면 유입을 구분하는 데 도움이 됩니다. 그러나 실제 이벤트 수집과 광고 기여 판정은 별도의 설정과 규칙이 필요합니다. 링크가 열린 사실만으로 광고 덕분에 구매했다고 판단하지 않습니다.

처음 설치하는 캠페인에서도 특정 콘텐츠를 이어 주려면 디퍼드 딥링크가 도움이 될 수 있습니다. 반대로 앱 전체를 소개하는 목적이면 스토어 안내만으로 계획할 수도 있습니다. 대상과 약속한 목적지에 맞춰 정합니다.

🔚 다이나믹 링크 종료 이후 딥링크 만드는 방법

무료로 많이 쓰던 파이어베이스 다이나믹 링크(Firebase Dynamic Links)는 2025년 8월 25일에 종료됐습니다. Firebase 공식 FAQ에 따르면 이 서비스가 처리하던 링크는 page.link 주소와 자체 도메인 주소 모두 작동을 멈췄고 새 링크도 만들 수 없습니다. 지금 딥링크를 만드는 방법은 세 가지입니다.

고르기 전에 필요한 기능부터 적습니다. 설치된 앱의 화면을 여는 것만 필요한지, 설치 후 목적지 복원과 캠페인 성과 측정까지 필요한지에 따라 맞는 방법이 다릅니다. 예전 다이나믹 링크 주소가 문자, QR 코드, 이메일에 남아 있다면 실제 주소를 목록으로 모아 새 링크로 바꿀 대상을 정합니다.

링크를 만든 뒤에는 개발팀과 테스트 기기로 아래 순서로 확인합니다.

1. iOS와 Android, 앱 설치 여부, 로그인 여부, 앱 버전, 링크를 누를 앱(문자, 메신저, 브라우저)의 조합을 표로 적습니다.
2. 조합마다 링크를 누르고 기대한 화면과 실제로 열린 화면, 확인 시각을 기록합니다.
3. 로그인한 뒤 원래 목적지로 돌아오는지, 판매 종료 상품이나 잘못된 상품 번호가 어떻게 처리되는지 봅니다.
4. 실패한 조합은 앱의 링크 처리 코드, 도메인 확인 파일, 브라우저 동작을 개발팀과 대조한 뒤 같은 조건으로 다시 시험합니다.

🤝 리퍼럴(추천 초대) 뜻과 설계

리퍼럴(referral)은 기존 사용자가 아는 사람에게 앱이나 서비스를 추천해 새 사용자가 들어오는 경로입니다. 리퍼럴 마케팅은 이 추천이 일어나도록 초대 기능과 보상 조건을 설계하는 일입니다. 사용자의 유입부터 추천까지를 다섯 단계로 나누는 AARRR에서 마지막 R(Referral)이 이 단계입니다. 초대 링크는 받는 사람의 기기와 앱 설치 여부를 알 수 없으므로, 디퍼드 딥링크로 초대한 콘텐츠와 추천인 정보를 설치 뒤까지 이어 주는 일이 함께 필요합니다.

초대 기능을 넣는다고 공유가 저절로 일어나지는 않습니다. 설계할 때 세 가지를 점검합니다.

• 편리하게: 공유 버튼까지 가는 동작이 적어야 하고, 받는 사람의 설치와 로그인 상태에 맞는 도착 화면이 준비되어 있어야 합니다.
• 자주: 가계부 앱의 월말 결산, 게임의 기록 달성처럼 공유하고 싶어지는 순간에 버튼을 둡니다.
• 자연스럽게: 함께 쓰면 좋아지는 기능처럼 공유가 추천한 사람에게도 의미가 있어야 합니다.

보상을 줄지, 누구에게 줄지는 서비스 목적에 맞춰 정합니다.

보상은 초대 버튼을 누른 시점이 아니라 초대받은 사람이 가입한 뒤 정한 첫 행동을 마친 시점에 주는 방식을 쓸 수 있습니다. 공유 버튼 클릭, 실제 링크 방문, 가입, 보상 지급은 서로 다른 기록이므로 측정할 때 각각 따로 집계합니다. 추천인을 구분하는 값을 링크에 넣어 가입 기록과 연결하되, 공개 링크에 이메일 같은 개인정보를 그대로 넣지 않습니다.

초대 보상만 노린 중복 가입을 막으려면 지급 조건과 사용자별 지급 상한을 정하고, 앱 화면의 완료 표시가 아니라 서버의 실제 성공 기록과 지급 내역을 대조합니다. 같은 기기를 썼다는 신호 하나만으로 가족 같은 정상 사용자를 부정 이용자로 확정하지 않고, 이의 제기 절차를 함께 둡니다.

❓ 자주 묻는 질문

원링크와 딥링크는 어떻게 다른가요?

딥링크는 앱의 특정 화면으로 연결하는 기술을 가리키는 일반 개념이고, 원링크(OneLink)는 앱스플라이어가 제공하는 링크 상품의 이름입니다. 원링크 하나로 사용자의 기기와 설치 상태에 따라 스토어, 웹페이지, 앱 화면 가운데 맞는 목적지로 보내고, 그 유입을 캠페인 성과로 측정할 수 있습니다. 딥링크와 디퍼드 딥링크 기능을 쓰려면 앱에 앱스플라이어 SDK(앱에 넣는 측정용 개발 도구 묶음)를 설치하고 개발자가 링크 처리를 구현해야 합니다.

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

역할이 다르지만 한 링크가 두 역할을 함께 하는 경우가 많습니다. 딥링크는 사용자를 알맞은 화면으로 보내는 역할이고, 어트리뷰션 링크는 정한 규칙에 따라 유입과 전환을 캠페인에 배분하는 측정 역할입니다. 앱 화면이 제대로 열렸어도 동의와 수집 조건에 따라 측정 자료가 없을 수 있으므로 두 역할을 따로 검증합니다.

상품 A로 가는 세 가지 경로 적기

계정이나 유료 도구 없이 메모장에 가상 상품 A를 적습니다. 주소 문자열을 만들기 전에 경로부터 정하는 연습입니다. A는 로그인해야 볼 수 있고 앱과 모바일 웹 모두에 있으며 아직 판매 중이라고 가정합니다.

1. 앱 설치와 로그인 완료: 링크를 눌러 앱의 상품 A를 여는 것이 목표입니다.
2. 앱 미설치: 웹 상품 A의 로그인 안내를 먼저 보여 주고 설치 선택지도 제공하기로 정합니다.
3. 2번에서 설치를 선택: 설치 후 필요한 로그인을 마치면 앱의 상품 A로 이어 주도록 디퍼드 딥링크와 로그인 복귀를 준비합니다.

어느 단계에서나 홈만 열리면 성공이라고 적지 말고 기대 화면과 실제 화면을 비교합니다. 기기, 운영체제, 앱 버전, 설치와 로그인 상태, 링크를 누른 위치를 기록하면 개발팀이 재현하는 데 도움이 됩니다.

이번에는 상품 A가 삭제됐다고 조건을 바꿉니다. 상품 화면 대신 판매 종료 안내와 다른 상품 탐색 경로를 마련합니다. 이 연습에서는 상품이 삭제된 뒤에는 예전에 받은 링크도 판매 종료 안내로 보낸다고 정합니다. 세 가지 경로와 바뀐 조건의 기대 결과를 적으면 설계 연습을 마친 것입니다. 실제 링크 작동은 승인된 테스트 앱과 기기에서 별도로 확인해야 합니다.

📋 3줄 요약

1. 딥링크는 앱의 특정 화면으로 연결하며 앱 구현과 로그인 및 접근 조건을 함께 확인해야 합니다.

2. 디퍼드 딥링크는 설치 전 목적지를 설치 후 이어 주는 방식이며 미설치자의 대체 경로도 따로 정합니다.

3. 링크 동작과 광고 기여 측정은 구분하고 기기와 설치 상태 및 로그인 조건별로 실제 결과를 확인합니다.

참고 자료

• 딥링크와 App Links, Android Developers
• Universal Links, Apple
• iOS 링크 초기 설정과 제한, AppsFlyer
• 딥링크와 연결 링크 구성, AppsFlyer
• 동적 링크 지원 중단 FAQ, Firebase