Firebase Dynamic Links 대안: 앱과 캠페인 링크 이전

2026년에 Firebase Dynamic Links 대안을 찾고 있다면 먼저 예전 제품이 해주던 일을 분리해서 봐야 합니다. 대부분의 팀이 실제로 필요한 것은 세 가지입니다.

브랜드 HTTPS 링크
iOS, Android, desktop을 나누는 기기별 라우팅
앱이 없거나 desktop에서 열린 경우의 명확한 fallback

일부 팀은 deferred deep linking이나 모바일 attribution까지 필요합니다. 하지만 모든 팀이 그 복잡도를 필요로 하는 것은 아닙니다. 이 구분을 먼저 해야 이전 비용과 대체 stack이 달라집니다.

공식 Firebase Dynamic Links FAQ에 따르면 Firebase Dynamic Links는 deprecated 되었고 2025년 8월 25일 종료되었습니다. QR 코드, 카카오톡 공유, 이메일, 유료 광고, 앱 설치 흐름이 아직 Dynamic Links URL에 의존하고 있다면 링크 계층을 다시 설계해야 합니다.

대부분의 팀이 Dynamic Links로 하던 일

Dynamic Links 대체를 말할 때 실제 요구사항은 보통 다음 중 하나입니다.

iPhone 사용자를 App Store로 보내기
Android 사용자를 Google Play로 보내기
desktop 사용자를 웹 랜딩이나 QR handoff 페이지로 보내기
긴 app-store URL 대신 브랜드 링크 공유하기
UTM 파라미터를 유지해 캠페인 성과 측정하기
설치된 앱이 있으면 native link로 열기

이것들은 같은 문제가 아닙니다.

스토어 fallback과 기기 라우팅은 대부분 HTTP redirect 문제입니다.
설치된 앱 열기는 Android App Links와 Apple Universal Links 설정 문제입니다.
설치 후 특정 화면으로 보내는 deferred deep linking은 앱 내부 로직이나 attribution stack이 필요할 수 있습니다.
UTM 보존은 redirect quality 문제입니다. 이 부분이 중요하다면 경로와 UTM을 잃지 않는 도메인 포워딩을 함께 보세요.

[!TIP] 가장 빠른 이전은 “Firebase 기능을 전부 1:1로 복제”하는 것이 아닙니다. 제품팀과 마케팅팀이 실제로 의존하는 동작만 정확히 대체하는 것입니다.

간단한 판단 트리

스마트 라우팅만 필요하다면

목표가 다음 정도라면 스마트 redirect layer로 충분한 경우가 많습니다.

iOS -> App Store
Android -> Google Play
Desktop -> 웹사이트 또는 QR 페이지

이 경우 UrlEdge 기기별 타기팅이 잘 맞습니다.

설치된 앱을 직접 열어야 한다면

설치된 iOS 앱이나 Android 앱을 바로 열고, 설치되지 않은 사용자는 스토어 또는 웹으로 보내려면 두 계층이 모두 필요합니다.

링크 라우팅 계층
앱과 도메인에 설정된 native app link

즉 AASA 파일, assetlinks.json, 앱 내부 path handling을 함께 준비해야 합니다.

deferred deep linking 또는 attribution이 필요하다면

설치 attribution, post-install screen routing, campaign matching이 핵심이라면 redirect service 하나만으로 충분하다고 가정하지 마세요. UrlEdge는 branded link와 traffic routing layer를 맡고, attribution과 app-state logic은 기존 모바일 stack과 함께 설계하는 편이 안전합니다.

실용적인 대체 구조

많은 팀의 이전 구조는 다음과 같습니다.

브랜드 스마트 링크와 앱 스토어 fallback 라우팅을 나타내는 노트북과 스마트폰

go.brand.example/promo
  -> edge에서 기기 감지
  -> iOS: App Store 또는 Universal Link target
  -> Android: Google Play 또는 App Link target
  -> Desktop: 랜딩 페이지, 문서, QR handoff page

이 구조의 장점은 명확합니다.

도메인이 팀 소유로 남습니다.
fallback 동작을 문서화하고 테스트할 수 있습니다.
마케팅 링크가 특정 모바일 vendor에 묶이지 않습니다.
나중에 geo rule, analytics, 임시 override를 추가할 수 있습니다.

이전 계획

1. 활성 Dynamic Link 목록 만들기

무작정 새 링크를 만들지 마세요. 먼저 사용 중인 URL을 모읍니다.

카카오톡 공유 링크
QR 코드
이메일과 lifecycle 메시지
유료 광고와 Naver/Google 캠페인
파트너 문서
앱 onboarding flow
referral link

최소한 다음 컬럼을 가진 sheet를 만드세요.

old_dynamic_link,owner,use_case,ios_destination,android_destination,desktop_destination,notes
https://xyz.page.link/sale,growth,app download,https://apps.apple.com/app/...,https://play.google.com/store/apps/...,https://brand.example/sale,seasonal campaign

2. 채널이 아니라 동작으로 분류하기

각 링크를 다음 중 하나로 나눕니다.

Store fallback only
Web fallback only
Native app link with fallback
Campaign 또는 geo/device 특수 규칙

이 분류가 redirect platform만으로 충분한지, 앱 내부 native link 작업이 필요한지 결정합니다.

3. 브랜드 도메인으로 이동하기

이전은 product-owned short domain 의존을 줄일 좋은 시점입니다. go.brand.example 또는 links.brand.example 같은 도메인을 쓰면 SSL, DNS, 장기 link ownership을 팀이 통제할 수 있습니다.

4. 플랫폼별 목적지를 명확히 쓰기

“fallback”이라고만 적어두면 QA가 되지 않습니다.

iPhone -> App Store
Android phone -> Google Play
Desktop -> 제품 랜딩 + QR code
Tablet -> 제품 성격에 따라 desktop web 또는 app store

5. 실제 기기에서 테스트하기

최소한 다음 조합은 확인하세요.

iPhone Safari
iPhone 인앱 브라우저
Android Chrome
Android 인앱 브라우저
Desktop Chrome
Desktop Safari
앱 설치됨 / 설치 안 됨
UTM 파라미터 있음
QR scan

리디렉션 검사기를 사용하면 캠페인 대시보드 추측이 아니라 실제 리디렉션 동작을 볼 수 있습니다.

흔한 이전 실수

모든 링크 동작을 하나로 취급

스토어 fallback, 설치 앱 열기, deferred deep linking은 서로 다른 요구사항입니다. 하나로 뭉뚱그리면 과하게 사거나 부족하게 만듭니다.

Desktop fallback을 빼먹음

모바일 링크 프로젝트는 iOS와 Android만 보고 desktop을 놓치는 경우가 많습니다. desktop fallback은 부가 기능이 아니라 사용자 경험입니다.

UTM 파라미터를 흘려보냄

기존 링크가 utm_ 값을 가지고 있었다면 의도적으로 보존해야 합니다. 모든 대체 경로가 query string을 자동 전달한다고 가정하지 마세요.

UrlEdge가 잘 맞는 부분

UrlEdge는 다음 요구사항에 강합니다.

브랜드 커스텀 도메인
App Store / Google Play fallback
desktop web fallback
기기별 규칙
국가별 규칙
redirect validation
edge-side analytics

앱 출시 주기와 독립적으로 링크 라우팅 계층을 운영하고 싶을 때 특히 유용합니다.

FAQ

모든 기기에 하나의 링크를 써도 되나요?

예. 하나의 브랜드 URL에서 iOS는 App Store, Android는 Google Play, desktop은 웹이나 QR handoff page로 보낼 수 있습니다.

Universal Links나 App Links가 여전히 필요한가요?

설치된 앱을 직접 열고 싶다면 필요합니다. HTTP redirect와 native app association은 서로 다른 계층의 문제입니다.

앱 다운로드 페이지만 Dynamic Links로 썼다면요?

이전은 생각보다 단순할 수 있습니다. 기기별 스마트 링크, 명확한 store fallback, query parameter 보존만으로 충분한 경우가 많습니다.

기본 라우팅

스마트 규칙

보안과 모니터링

유틸리티와 검사기

무료로 시작하기

회사와 커뮤니티

법무와 컴플라이언스

문서