파이어베이스 다이내믹 링크 종료, 딥링크와 인증 이전 방법
핵심 요약 파이어베이스 다이내믹 링크는 2025년 8월 25일 종료돼 기존 링크가 404를 반환한다. 딥링크는 App Links·Universal Links로, 인증 이메일 링크는 최신 파이어베이스 SDK로 옮기는 이전 절차를 정리했다.
목차
2026년 7월 기준 파이어베이스 다이내믹 링크(Firebase Dynamic Links, 앱 설치 여부에 따라 목적지를 다르게 보내 주던 딥링크 서비스)는 이미 종료됐다. 파이어베이스 공식 종료 안내(Dynamic Links Deprecation FAQ)에 따르면 서비스는 2025년 8월 25일에 중단됐고, 그 뒤로 기존 링크를 누르면 HTTP 404가 돌아온다. 지금 할 일은 세 갈래다. 앱 안에서 특정 화면으로 보내는 딥링크는 안드로이드 App Links와 iOS Universal Links로 옮기고, 파이어베이스 인증의 이메일 링크는 최신 SDK로 올리며, 설치 유도와 유입 분석까지 필요하면 서드파티 딥링크 서비스를 붙인다.
이 글은 모바일 앱에서 들어오는 URL을 처리하던 개발자를 대상으로 한다. 웹에서 도는 인증 흐름은 이번 종료의 영향을 받지 않으므로 다루지 않는다.
기존 링크를 누르면 이제 어떻게 되나
이제 기존 다이내믹 링크를 누르면 HTTP 404가 돌아온다. 구글은 2023년 8월에 이 서비스의 지원 중단을 예고했고, 2025년 8월 25일을 최종 종료일로 못 박았다. page.link 형태의 기본 서브도메인이든 직접 연결한 커스텀 도메인이든 모두 같은 운명이다.
링크 클릭만 죽는 게 아니다. 파이어베이스 공식 FAQ에 따르면 짧은 링크를 만들던 Short Links API와 클릭 통계를 받아 오던 Analytics API 호출은 종료 이후 400 또는 403 상태 코드를 반환한다. 즉 종료 시점부터는 기존 링크가 열리지 않을 뿐 아니라 새 링크를 만들 수도, 클릭 데이터를 뽑을 수도 없다. 앱 안에 다이내믹 링크 SDK 호출이 남아 있다면 그 코드 경로는 이제 아무 일도 하지 않는다고 봐야 한다.
무엇이 영향받고 무엇은 멀쩡한가
영향은 다이내믹 링크로 만든 딥링크에서 끝나지 않는다. 파이어베이스 인증이 내부적으로 다이내믹 링크를 쓰던 기능들이 함께 걸린다. 파이어베이스 공식 FAQ는 다음 기능들이 영향을 받는다고 정리한다.
- 이메일 링크 로그인(매직 링크 방식)
- 비밀번호 재설정, 이메일 주소 확인 같은 아웃오브밴드(OOB) 이메일 작업
- 안드로이드 OAuth 흐름 중 파이어베이스 인증 안드로이드 SDK가 v20.0.0 미만인 경우
- 파이어베이스 JS SDK로 OAuth를 구현한 코르도바(Cordova) 앱
반대로 멀쩡한 것도 분명하다. 파이어베이스는 이번 종료가 모바일 기기에서 들어오는 URL을 처리하는 부분에만 영향을 준다고 밝혔다. 브라우저에서 도는 웹 인증 흐름은 그대로 동작한다. 그래서 순수 웹 앱만 운영한다면 딥링크 자체를 안 쓰는 한 급하게 손댈 곳이 없다. 손봐야 하는 쪽은 네이티브 앱, 그중에서도 들어오는 링크를 열어 화면을 여는 코드다.
딥링크를 App Links·Universal Links로 옮기기
구글은 앱 설치 후 딥링크만 필요하다면 플랫폼이 기본 제공하는 방식, 즉 안드로이드 App Links와 iOS Universal Links로 옮기라고 권한다. 둘 다 내 도메인의 https 링크를 앱이 직접 열도록 운영체제가 연결해 주는 표준 기능이다. 별도 서비스 의존 없이 도메인만 있으면 된다.
파이어베이스 마이그레이션 가이드(App Links & Universal Links로 이전)는 이 과정을 여섯 단계로 나눈다.
- 파이어베이스 호스팅으로 링크를 서빙할 도메인을 준비한다.
- 도메인 검증용 설정 파일을 호스팅한다.
- 기존 다이내믹 링크가 쓰던 경로 규칙에 맞춰 App Links·Universal Links를 만든다.
- 앱 코드에서 들어온 링크를 받아 화면으로 여는 처리를 추가한다.
- 설치·미설치, 안드로이드·iOS 조합으로 실제로 열리는지 테스트한다.
- 바깥에 뿌려진 기존 다이내믹 링크를 새 링크로 교체한다.
핵심은 검증 파일 두 개다. 안드로이드는 /.well-known/assetlinks.json 경로에 패키지 이름과 서명 인증서의 SHA256 지문을 담은 파일을 올려 도메인과 앱을 연결한다.
[
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.app",
"sha256_cert_fingerprints": ["FA:C6:17:..."]
}
}
]iOS는 같은 자리인 /.well-known/apple-app-site-association에 팀 ID를 붙인 앱 식별자와 처리할 경로 규칙을 넣는다. 확장자 없는 이 파일은 파이어베이스 호스팅의 firebase.json에서 Content-Type 헤더를 맞춰 줘야 iOS가 인식한다.
{
"applinks": {
"apps": [],
"details": [
{ "appID": "ABCDE12345.com.example.app", "paths": ["*"] }
]
}
}인증 이메일 링크는 계속 쓸 수 있나
쓸 수 있다. 단 최신 파이어베이스 인증 SDK로 올려야 한다. 파이어베이스 공식 FAQ는 이메일 링크 로그인과 비밀번호 재설정·이메일 확인 같은 아웃오브밴드 이메일 작업이 종료 이후에도 계속 동작하지만, 그러려면 최신 파이어베이스 인증 SDK로 업그레이드해 새 방식으로 옮겨야 한다고 안내한다.
안드로이드에서 OAuth 로그인을 붙여 놓았다면 버전 조건이 하나 더 붙는다. 파이어베이스는 안드로이드 OAuth 흐름을 계속 쓰려면 파이어베이스 인증 안드로이드 SDK를 최소 v20.0.0 이상으로 올려야 한다고 명시한다. 그래서 인증 기능을 쓰는 앱이라면 딥링크 교체와 별개로 인증 SDK 버전부터 점검하는 편이 안전하다.
스토어 이동·디퍼드 딥링킹이 필요하면
App Links·Universal Links로 다이내믹 링크의 모든 기능이 채워지지는 않는다. 파이어베이스 마이그레이션 가이드는 이 표준 방식이 제공하지 않는 것을 분명히 짚는다. 앱이 안 깔린 사용자를 기기에 맞는 스토어로 보내 설치를 유도하는 동작, 설치 후 첫 실행에서 원래 가려던 화면으로 이어 주는 디퍼드 딥링킹(deferred deep linking, 설치 뒤로 목적지를 미뤄 전달하는 방식), 클릭·유입 분석, 짧은 링크 자동 생성이 여기에 빠진다.
| 기능 | App·Universal Links | 서드파티(Branch 등) |
|---|---|---|
| 설치된 앱으로 딥링크 이동 | 지원 | 지원 |
| 미설치 시 스토어 유도 | 미지원 | 지원 |
| 설치 후 목적지 이어주기 | 미지원 | 지원 |
| 클릭·유입 분석 | 미지원 | 지원 |
| 짧은 링크 자동 생성 | 미지원 | 지원 |
이 기능들이 마케팅이나 사용자 유입에 실제로 필요하다면 서드파티 딥링크 서비스로 가야 한다. 파이어베이스는 완전한 기능 대체가 필요한 경우의 예시로 Adjust, Airbridge, AppsFlyer, Bitly, Branch, Kochava, Singular를 든다. 반대로 앱 안에서 화면을 여는 딥링크만 있으면 되는 경우라면 서드파티 없이 App Links·Universal Links만으로 충분하다. 무료로 붙는 표준 방식과 유료 기능이 얹히는 서드파티 사이에서, 내 앱이 실제로 스토어 유도나 유입 분석을 쓰고 있었는지부터 확인하고 고르면 된다.