앱 MVP Android App Links: 도메인 검증·앱 열기·웹 폴백을 나누는 5가지 기준
앱 MVP Android App Links: 도메인 검증·앱 열기·웹 폴백을 나누는 5가지 기준
웹 URL을 눌렀을 때 Android 앱이 열리게 하려면, 앱에 화면 경로만 추가하면 될까요? 아닙니다. Android App Links는 우리 앱이 처리할 URL과 그 URL 도메인을 우리가 증명할 수 있는지를 함께 확인하는 방식입니다. 이 글은 도메인 소유, assetlinks.json 배포, 배포용 서명 인증서, 실제 기기 검증, 앱으로 열리지 않을 때의 웹 폴백을 분리하는 기준을 다룹니다. 특정 링크가 반드시 앱에서 열리거나, 설치·전환·검색 성과가 생긴다고 보장하지 않습니다.
1. 먼저 “앱 화면으로 갈 URL”과 “우리가 증명할 수 있는 도메인”을 분리합니다
딥링크는 사용자를 앱의 특정 화면으로 보낼 수 있는 경로이고, Android App Links는 여기에 웹사이트와 앱의 연결을 검증하는 단계를 더합니다. 그래서 제품 기획에서 가장 먼저 답할 질문은 “이 화면으로 갈 수 있나?”보다 “이 URL의 호스트를 우리 팀이 운영하고, 공개 파일을 올릴 수 있나?”입니다.
예를 들어 캠페인 URL, 도움말 URL, 결제 완료 URL을 한꺼번에 앱으로 열겠다고 정하기 전에 호스트를 나눠 적어 보세요. 운영 도메인, 외부 파트너 도메인, 테스트 전용 도메인은 책임자가 다를 수 있습니다. 우리가 통제하지 않는 호스트는 App Links 검증 대상이라고 단정하지 말고, 브라우저 열기나 사용자의 수동 선택을 포함한 별도 흐름으로 다루는 편이 안전합니다.
2. assetlinks.json은 앱 코드가 아니라 도메인 쪽의 공개 증명입니다
Android 공식 문서는 앱과 웹사이트의 연결을 위해 Digital Asset Links JSON 파일을 사용한다고 설명합니다. 파일 이름은 assetlinks.json이며, 각 호스트의 https://호스트/.well-known/assetlinks.json 위치에서 HTTPS로 접근되고, JSON 콘텐츠 타입으로 제공되며, 리디렉션 없이 열려야 합니다.
여기서 자주 생기는 혼동은 “앱 빌드가 성공했으니 링크도 준비됐다”는 판단입니다. 파일은 앱 저장소가 아니라 웹 서버·CDN·배포 설정에 걸려 있을 수 있습니다. 도메인이 여러 개라면 파일도 각 호스트에서 확인해야 합니다. 따라서 출시 체크리스트에는 경로 문자열, HTTP 응답, 리디렉션 여부, 배포 담당자와 변경 이력을 각각 남기세요.
3. 패키지 이름과 “사용자 기기에서 쓰이는” 서명 지문을 대조합니다
연결 파일에는 연결할 Android 앱의 패키지 이름과 서명 인증서의 SHA-256 지문이 들어갑니다. 이 둘은 비슷해 보이지만 역할이 다릅니다. 패키지 이름은 어떤 앱을 뜻하는지, 지문은 그 앱이 해당 도메인의 링크를 처리하도록 허가된 배포본인지 확인하는 근거입니다.
특히 로컬에서 확인한 키와 실제 사용자에게 배포되는 앱의 서명이 다를 수 있습니다. Android 문서는 Play App Signing을 사용하는 경우 로컬 keytool 결과가 사용자 기기의 인증서와 보통 일치하지 않을 수 있다고 안내합니다. 그래서 팀은 개발·스테이징·운영 배포본을 같은 값으로 가정하지 말고, 이번에 검증할 배포 경로와 그 근거를 명시해야 합니다. 지문 자체는 공개 범위와 보관 위치를 팀 보안 정책에 맞게 관리하세요.
4. “파일이 있다”와 “기기에서 검증됐다”를 별도 완료 조건으로 둡니다
배포 전에는 최소 두 층을 확인합니다. 첫째, 브라우저나 HTTP 검사로 해당 호스트의 파일이 정확한 경로에서 응답하는지 봅니다. 둘째, 실제 설치된 앱에서 시스템이 그 호스트 연결을 검증하고, 사용자가 탭한 URL이 기대한 처리 정책을 따르는지 봅니다. Android의 검증 안내는 호스트별 검증 상태와 링크 처리 정책을 기기에서 점검하는 방법을 별도로 제공합니다.
한 번의 탭 성공만으로 전체 URL 규칙이 맞다고 결론내리지 마세요. 운영 호스트마다 대표 URL을 정하고, 새 설치·업데이트 뒤·기본 브라우저가 있는 상태·앱이 없는 상태를 구분해 기록합니다. 링크가 브라우저로 열리거나 선택 화면이 보이면 곧바로 “앱 버그”로 묶기보다, 호스트 파일·서명 지문·앱 매니페스트·기기별 사용자 선택 중 어떤 층의 관측인지 먼저 분류하세요.
5. 앱으로 열리지 않는 경우에도 사용자가 작업을 끝낼 웹 경로를 남깁니다
App Links 검증은 우리 도메인과 앱의 연결을 다루므로, 소유하지 않은 도메인이나 검증되지 않은 호스트까지 자동으로 앱이 열릴 것이라고 약속할 수 없습니다. 제품 화면과 캠페인 안내에는 앱 미설치, 검증 지연, 사용자의 기본 연결 선택, 외부 도메인 같은 상황에서 웹으로도 핵심 정보를 확인하거나 다음 행동을 할 수 있는 경로를 마련해 두세요.
이것은 모든 링크를 웹으로 돌리라는 뜻이 아닙니다. 앱에서만 가능한 기능은 필요한 앱 상태를 설명하고, 웹에서 가능한 정보는 웹에서도 이어지게 하는 범위 결정입니다. 이미 일반적인 앱 진입 경로를 정리했다면 앱 MVP App Clip: 설치 전 한 가지 작업만 남기는 기준처럼 설치 전 사용자가 해야 할 한 가지 작업을 먼저 정리한 글도 함께 참고할 수 있습니다.
확인 대상 | 완료를 판단할 질문 | 남길 증거 | 미확인일 때의 처리 |
|---|---|---|---|
도메인 소유 | 이 호스트의 공개 파일을 우리가 배포할 수 있는가? | 담당자·호스트 목록 | 검증 대상에서 분리하고 웹 경로를 검토 |
연결 파일 | 정확한 경로·HTTPS·JSON·무리디렉션인가? | 응답 확인 시각·배포 버전 | 앱 출시 조건으로 완료 처리하지 않음 |
앱 식별 | 패키지와 운영 배포 서명 지문이 맞는가? | 배포 경로·대조 기록 | 개발용 값으로 대체하지 않음 |
기기 검증 | 설치된 기기에서 호스트 처리 정책이 기대와 맞는가? | 기기·OS·URL·관측 결과 | 호스트별 원인 분류 |
웹 폴백 | 앱이 열리지 않아도 사용자가 다음 정보를 얻는가? | 웹 화면·안내 문구 | 사용자에게 불가능한 동작을 약속하지 않음 |
자주 묻는 질문
커스텀 스킴 딥링크가 있으면 App Links를 생략해도 되나요?
목표에 따라 다릅니다. Android App Links는 HTTP·HTTPS 웹 링크와 우리 웹사이트의 검증된 연결을 다룹니다. 웹 URL을 우리 도메인과 연결해 앱에서 처리하려는 경우라면, 커스텀 스킴의 존재만으로 도메인 검증이 완료됐다고 볼 수 없습니다.
assetlinks.json을 한 번 올리면 모든 서브도메인에 적용되나요?
아닙니다. Android 공식 문서는 여러 호스트를 지원하면 각 도메인에 파일을 게시하라고 안내합니다. 실제 대상 호스트 목록과 각 파일의 공개 경로를 별도로 확인해야 합니다.
로컬에서 얻은 SHA-256 지문을 그대로 쓰면 되나요?
배포 경로를 먼저 확인해야 합니다. Play App Signing을 쓰는 경우 로컬 키에서 얻은 지문이 사용자 기기에서 쓰이는 인증서와 다를 수 있다고 Android 문서는 설명합니다. 어떤 배포본을 검증하는지와 그에 맞는 근거를 대조하세요.
링크가 브라우저로 열리면 앱 구현 오류인가요?
그렇지 않습니다. 도메인 파일의 접근·리디렉션·지문, 앱의 URL 선언, 기기 검증 상태, 사용자 선택 같은 층을 구분해서 확인해야 합니다. 확인 전에는 원인을 단정하기보다 웹 폴백도 사용자가 필요한 정보를 얻는지 점검하세요.
확인한 공식 출처
Android Developers · About App Links — 2026-09-20 확인
Android Developers · Configure website associations and dynamic rules — 2026-09-20 확인
Android Developers · Verify App Links — 2026-09-20 확인