Firebase 이후 Universal Links와 App Links 설정 방법

예전 page.link URL이 아직 QR 코드, 광고, 이메일, 앱 다운로드 버튼, referral flow에 남아 있다면 지금 필요한 것은 "Firebase와 비슷한 다른 서비스"가 아닙니다. 공개 링크를 계속 살아 있게 유지하면서 앱 열기, fallback, 캠페인 측정을 다시 정리하는 것입니다.

그래서 Firebase Dynamic Links가 하나로 묶어주던 역할을 분리해서 보는 편이 훨씬 현실적입니다.

1. 브랜드 공개 URL
2. 설치된 앱 열기
3. App Store / Google Play / web fallback
4. UTM과 캠페인 파라미터 유지

공식 Firebase Dynamic Links FAQ에 따르면 서비스는 2025년 8월 25일 종료되었습니다. 아직도 옛 링크가 캠페인이나 온보딩에 남아 있다면, 이제는 비슷한 대체품을 찾기보다 링크 레이어 자체를 더 깔끔하게 재구성하는 편이 안전합니다.

Universal Links와 App Links가 담당하는 일

Apple Universal Links

Apple Universal Links는 일반 HTTPS 링크에서 설치된 iOS 앱을 여는 방식입니다. 이를 위해서는:

• 도메인이 앱과 올바르게 연결되어 있어야 하고
• capability가 정확히 설정되어 있어야 하며
• apple-app-site-association 파일이 정상적으로 제공되어야 하고
• 앱이 해당 path를 처리할 수 있어야 합니다

Android App Links

Android App Links는 Android 쪽에서 같은 역할을 합니다. 여기에 필요한 것은:

• 검증된 도메인
• 올바른 manifest 설정
• 유효한 assetlinks.json
• 앱 내부 path 처리

이것만으로는 해결되지 않는 것

Universal Links와 App Links만으로는 다음을 해결하지 못합니다.

• desktop fallback
• 앱 미설치 사용자 목적지
• 캠페인용 브랜드 링크
• 기기별 라우팅
• UTM 유지
• 임시 캠페인 전환 규칙

이 부분은 여전히 redirect / routing 레이어가 맡아야 합니다.

Firebase 이후 가장 실용적인 구조

대부분의 팀에게 가장 관리하기 쉬운 구조는 아래와 같습니다.

go.yourbrand.com/promo
  -> edge에서 기기 판별
  -> iPhone + 앱 설치: Universal Link
  -> iPhone + 미설치: App Store
  -> Android + 앱 설치: App Link
  -> Android + 미설치: Google Play
  -> Desktop: 랜딩 페이지, docs, QR 안내 페이지

이 구조가 좋은 이유는:

• 도메인을 직접 통제할 수 있고
• fallback이 명확하며
• 마케팅은 하나의 깔끔한 URL만 공유하면 되고
• mobile, growth, product가 같은 실제 흐름을 테스트할 수 있기 때문입니다

실제로 많이 막히는 지점: 검증 파일

현업에서 자주 막히는 건 개념보다 다음 파일입니다.

• apple-app-site-association
• assetlinks.json

특히 메인 사이트가 Shopify, Wix, Webflow, 제한이 많은 CMS 위에 있을 때 root나 .well-known에 파일을 두는 작업이 번거로워집니다.

이 지점에서 UrlEdge가 실용적입니다. custom response를 이용하면 이런 파일을 edge에서 직접 반환할 수 있어 별도의 배포 경로를 만들지 않아도 됩니다.

실무형 이전 절차

1. 공개 링크 인벤토리를 만든다

다음 위치를 꼭 확인하세요.

• 유료 광고
• QR 코드
• 다운로드 버튼
• lifecycle 이메일
• 지원 문서
• 소셜 프로필 링크
• referral flow

2. 앱 열기와 fallback을 분리해 정의한다

각 링크에 대해 다음을 결정합니다.

1. 앱이 설치되어 있으면 열어야 하는가?
2. 설치되어 있지 않으면 스토어로 보내는가, 웹으로 보내는가?
3. desktop은 무엇을 보여줄 것인가?
4. UTM이나 캠페인 파라미터를 유지해야 하는가?

3. 공개용 기준 도메인을 정한다

예를 들면:

• go.yourbrand.com
• app.yourbrand.com
• links.yourbrand.com

이렇게 해두면 공개 링크 레이어를 서드파티 hostname에 덜 의존하게 됩니다.

4. 연동 파일을 검증한다

항상 공식 문서를 기준으로 확인하세요.

• Apple Universal Links
• Android App Links

이 단계가 틀리면 일반 redirect가 보여도 native app opening은 불안정하게 남습니다.

5. fallback 규칙을 명시적으로 적는다

예를 들어:

• iOS + 앱 설치 -> 앱
• iOS + 미설치 -> App Store
• Android + 앱 설치 -> 앱
• Android + 미설치 -> Google Play
• desktop -> 랜딩 또는 QR handoff

이 부분을 암묵적으로 두면 안 됩니다.

6. 실제 컨텍스트에서 테스트한다

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

• iPhone Safari
• Android Chrome
• 소셜 앱의 in-app browser
• desktop
• 모바일 QR 스캔
• UTM이 붙은 링크

여기서 "링크가 응답한다"와 "사용자 경험이 올바르다"의 차이가 드러납니다.

자주 생기는 실수

device routing만 있으면 충분하다고 생각한다

아닙니다. routing은 목적지를 고르고, Universal Links / App Links는 운영체제 수준의 신뢰된 앱 열기를 맡습니다.

desktop을 뒤로 미룬다

desktop fallback이 약하면 지원 문서, 영업 자료, QR 유입, 다운로드 안내 흐름이 쉽게 깨집니다.

UTM을 잃어버린다

광고, 이메일, QR, 소셜, 파트너 링크에 붙는 파라미터는 의도적으로 유지해야 합니다.

레이어를 너무 많이 쌓는다

shortener, 중간 redirect, 중간 페이지가 많아질수록 디버깅이 느려집니다.

UrlEdge가 들어가는 자리

UrlEdge는 다음을 함께 다루고 싶을 때 잘 맞습니다.

• 브랜드 공개 URL
• 기기별 라우팅
• 스토어 / 웹 fallback
• UTM 유지
• 클릭 분석
• 검증 파일의 edge 배포

모든 모바일 attribution 기능을 단독으로 대체하는 도구는 아닙니다. 하지만 가장 눈에 보이는 부분, 즉 공개 링크와 fallback 동작에 대한 통제권을 되돌려줍니다.

정리

Firebase Dynamic Links 이후에 필요한 것은 또 다른 "마법 상자"가 아니라 더 분명한 구조입니다.

• 브랜드 도메인
• 기기별 라우팅
• 제대로 검증된 Universal Links와 App Links
• 명시적인 fallback
• 유지되는 캠페인 파라미터

덜 마법적이지만, 훨씬 더 통제 가능합니다.