지금 읽는 곳두 표준이 어떻게 검증되는지부터 확인해야 하는 이유목차
S2 › 데이터기술 › 과목 246 › 레슨 08
앱-웹 하이브리드 환경에서 딥링크·유니버설링크 전환 추적이 끊기는 원인과 진단 순서
같은 링크가 어제는 앱을 열었는데 오늘은 웹으로 빠진다면, 원인 후보는 정해져 있고 확인 순서도 정해져 있습니다.
핵심요약
- 유니버설 링크는 AASA 파일, 앱 링크는 assetlinks.json으로 도메인 소유권을 검증한다
- 인앱 브라우저에서 열린 링크는 OS 레벨 라우팅을 우회해 웹뷰로만 열리는 경우가 흔하다
- 커스텀 URI 스킴은 앱 미설치 시 오류로 실패하고 디퍼드 딥링크를 자체 지원하지 않는다
- 디퍼드 딥링크는 클릭 시점 기기 정보를 저장해 설치 후 대조하는 확률적 매칭에 의존한다
- 진단은 유입 환경·검증 파일·설치 여부·파라미터 순서로 좁혀야 시간이 줄어든다
두 표준이 어떻게 검증되는지부터 확인해야 하는 이유
iOS 유니버설 링크는 자사 도메인에 호스팅하는 Apple App Site Association(AASA) 파일로, 안드로이드 앱 링크는 assetlinks.json 파일로 도메인 소유권을 검증합니다. 두 방식 모두 HTTPS 스킴을 쓰는 반면, 전통적 딥링크는 커스텀 URI 스킴을 쓴다는 점이 근본적 차이입니다. 앱 링크는 안드로이드 6.0 이상, 유니버설 링크는 iOS 9 이상에서 동작하며 서로 호환되지 않으므로 두 표준을 모두 구현해야 크로스플랫폼 커버리지가 확보됩니다.
이 사실이 진단에서 중요한 이유는, 링크가 앱을 못 여는 사고의 상당수가 태그나 어트리뷰션 문제가 아니라 검증 파일 문제이기 때문입니다. 도메인 이전, 인증서 갱신, CDN 설정 변경, 리다이렉트 규칙 추가 같은 웹 쪽 작업 뒤에 검증 파일이 접근 불가 상태가 되면 링크는 조용히 웹으로만 열립니다. 앱 코드는 그대로인데 어느 날부터 안 되는 경우, 이 지점을 먼저 봐야 합니다.
인앱 브라우저는 무엇을 망가뜨리나
인스타그램, 틱톡, 페이스북, 링크드인, 카카오톡 같은 인앱 브라우저에서 탭한 링크는 iOS와 안드로이드 양쪽 모두에서 OS 레벨 라우팅을 우회해, 유니버설 링크·앱 링크가 정상 작동하지 않고 인앱 웹뷰로만 열리는 경우가 흔합니다.
광고 트래픽 대부분이 소셜 앱 안에서 발생한다는 점을 생각하면, 이건 예외 상황이 아니라 기본 상황에 가깝습니다. 그래서 "앱에서는 되는데 광고로 들어오면 안 된다"는 신고를 받으면 코드를 뒤지기 전에 유입 환경부터 확인해야 합니다. 문자 메시지나 QR로 열었을 때는 되고 인스타그램 광고로 열었을 때만 안 된다면, 원인은 구현이 아니라 인앱 브라우저 라우팅입니다. 이 경우 해결은 링크 수정이 아니라 랜딩 설계를 바꾸는 방향으로 갑니다.
커스텀 URI 스킴은 어디까지 쓸 수 있나
전통적 URI 스킴 방식은 앱이 설치돼 있지 않으면 오류 팝업을 띄우며 실패하고, 디퍼드 딥링크를 자체적으로 지원하지 않습니다. 원활한 크로스 환경 작동을 위해서는 URI 스킴, 유니버설 링크, 앱 링크를 통합 구현하는 것이 필요합니다.
실무에서 문제가 되는 조합은 오래된 캠페인 소재가 여전히 URI 스킴 링크를 물고 있는 경우입니다. 신규 소재는 유니버설 링크로 바꿨는데 과거에 배포된 QR 코드나 카카오 알림톡 버튼이 예전 링크를 유지하고 있으면, 미설치 사용자에게는 계속 오류 화면이 뜹니다. 링크 표준을 바꿨다면 이미 밖에 나가 있는 링크 자산 목록을 함께 정리해야 합니다.
설치 이후 파라미터가 사라지는 경우는 어떻게 보나
디퍼드 딥링크는 사용자가 앱 미설치 상태에서 링크를 클릭하면 클릭 시점의 기기 정보(IP, 유저에이전트, 화면 크기, 타임스탬프 등)를 서버에 저장해두고, 설치·최초 실행 후 이 정보와 새 기기 정보를 대조해 원래 콘텐츠로 연결하는 방식입니다. 확률적 매칭의 정확도는 트래픽 패턴과 클릭-설치 간격에 따라 달라진다고 업계 자료들이 설명합니다.
구현이 제대로 되지 않으면 신규 사용자는 캠페인 맥락 없이 홈 화면에 진입하고, 캠페인 파라미터를 담아야 할 값들이 비어 있거나 아예 존재하지 않게 됩니다. 안드로이드 쪽에는 별도의 확인 수단이 있습니다. 구글 플레이 Install Referrer API로 받은 설치 리퍼러 정보는 90일간 유효하고 재설치 전까지 값이 바뀌지 않으므로, 리퍼러 값이 들어오는지 여부로 링크 문제인지 앱 내 라우팅 문제인지를 가를 수 있습니다.
어떤 순서로 진단하면 시간이 줄어드나
순서는 다섯 단계로 고정해두는 편이 좋습니다. 첫째, 어떤 환경에서 클릭했는지 확인합니다(인앱 브라우저인지 기본 브라우저인지). 둘째, 검증 파일이 현재 접근 가능한지 확인합니다(AASA, assetlinks.json). 셋째, 앱 설치 상태를 나눠 봅니다(설치됨 / 미설치 후 신규 설치). 넷째, 앱이 열렸는지와 의도한 화면으로 갔는지를 분리해 봅니다. 다섯째, 어트리뷰션 파라미터가 남아 있는지 확인합니다.
검증은 삭제 후 클릭, 재설치, 최초 실행까지 전체 흐름을 iOS와 안드로이드 양쪽에서 직접 재현해 의도한 화면과 파라미터가 도달하는지 확인하는 방식이 표준입니다. 이 재현 테스트를 건너뛰고 로그만 보면, 설치된 기기에서만 확인하다가 미설치 경로의 문제를 통째로 놓칩니다. iOS의 경우 추적 권한 프롬프트는 1회성이며 시스템이 선택을 기억해 앱을 삭제 후 재설치하지 않는 한 다시 묻지 않으므로, 권한 관련 동작까지 확인하려면 삭제·재설치 재현이 사실상 유일한 방법입니다.