딥 링크

딥 링크는 누르면 앱의 첫 화면을 건너뛰고 안쪽의 한 화면으로 바로 데려가는 링크입니다. 친구가 보낸 상품 링크를 누르면 쇼핑 앱의 첫 화면이 아니라 그 상품 화면이 뜹니다. 앱 화면마다 주소를 붙여 두어서 가능한 일입니다. 웹에서는 사이트 첫 페이지 대신 안쪽 페이지로 곧장 가는 링크를 같은 이름으로 부르기도 합니다.

쉽고 빠른 이해

딥 링크는 앱 안쪽의 한 화면을 가리키는 주소입니다. 배달 앱의 「음식이 출발했습니다」 알림을 누르면 배달 현황 화면이 바로 뜨는 것이 딥 링크 덕분입니다.

이게 없으면 링크는 앱을 열어 주기만 합니다. 사용자는 첫 화면에서 메뉴를 뒤져 그 화면을 다시 찾아야 합니다.

어떻게 도나:

1. 앱이 「이런 주소는 내가 연다」고 휴대폰 운영체제에 미리 알려 둡니다
2. 사용자가 그 주소를 누르면 운영체제가 앱을 열고 주소를 넘깁니다
3. 앱이 주소를 읽고 그에 맞는 화면을 엽니다

대가도 있습니다. 앱은 누가 만들었는지 모를 주소를 받아 화면을 엽니다. 주소에 담긴 값을 하나하나 확인해야 합니다. 누가 만든 앱인지 운영체제가 확인할 수 있게, 웹 서버에 확인 파일을 올려 두어야 하는 방식도 있습니다.

딥 링크는 주소만으로 다시 그릴 수 있는 화면에 붙입니다. 앞 단계에서 고른 값이 있어야 뜨는 화면에는 붙이지 않습니다.

상세

큰 건물로 손님을 부를 때 건물 주소만 적어 주면 손님은 로비에 도착합니다. 거기서 몇 층 어느 방인지 다시 물어야 합니다. 초대장에 방 번호까지 적어 주면 손님은 곧장 그 방 문 앞으로 갑니다.

딥 링크는 방 번호까지 적힌 초대장입니다. 로비는 앱의 첫 화면입니다. 방은 상품 화면이나 주문 화면 같은 앱 안쪽의 한 화면입니다.

주소가 없던 앱 화면

웹 페이지는 저마다 주소를 가집니다. 이 주소를 URL(Uniform Resource Locator, 자원 위치 지정자)이라고 부릅니다. https://shop.example.com/products/42 는 어느 쇼핑 사이트의 42번 상품 페이지를 가리킵니다. 누구든 이 주소를 받으면 그 페이지로 바로 갑니다.

웹에서 딥 링크라는 말은 이런 링크를 가리켰습니다. 사이트 첫 페이지가 아니라 안쪽 깊은 페이지로 바로 들어가는 링크입니다. 웹은 모든 페이지가 주소를 가지므로 따로 할 일이 없습니다.

앱 화면은 사정이 다릅니다. 앱은 휴대폰에 설치된 프로그램이라 화면마다 주소가 붙어 있지 않습니다. 딥 링크가 없으면 밖에서 앱을 여는 길은 아이콘을 누르는 것뿐입니다. 아이콘으로 열면 언제나 첫 화면이 뜹니다.

모바일에서 딥 링크는 앱 화면에 주소를 붙여 주는 일입니다. 주소가 생기면 문자 메시지나 이메일이나 푸시 알림에서 앱의 한 화면을 가리킬 수 있습니다. 아래부터는 이 모바일의 뜻으로 씁니다.

링크가 앱 안쪽까지 들어가야 하는 까닭

배달 앱이 「주문하신 음식이 출발했습니다」라는 푸시 알림을 보냈다고 해 봅시다. 사용자가 알림을 누르며 기대하는 것은 그 주문의 배달 현황 화면입니다.

딥 링크가 없으면 알림은 앱을 열어 주기만 합니다. 사용자는 첫 화면에서 주문 내역 메뉴를 찾아 들어가야 합니다. 한 번 누르면 끝날 일이 서너 번으로 늘어납니다.

공유 링크도 같습니다. 친구가 보낸 상품 링크를 눌렀다고 합시다. 쇼핑 앱 첫 화면이 뜨면 그 상품을 검색해서 다시 찾아야 합니다. 딥 링크는 이렇게 다시 찾는 수고를 없앱니다.

운영체제가 링크를 앱에 넘기는 흐름

링크를 누른 순간 그 링크를 어느 앱이 열지 정하는 것은 휴대폰의 운영체제입니다. 앱은 설치될 때 「이런 모양의 주소는 내가 연다」는 목록을 운영체제에 미리 알려 둡니다.

안드로이드에서는 이 목록을 매니페스트에 적습니다. 매니페스트는 앱이 어떤 화면과 권한을 갖는지 운영체제에 알리는 설정 파일입니다.

매니페스트 안에서 받을 주소의 모양을 적는 항목이 인텐트 필터입니다. 「https://shop.example.com/products 로 시작하는 주소는 상품 화면이 받는다」처럼 적습니다. 아이폰의 운영체제인 iOS 에서도 앱 설정에 받을 주소를 적어 둡니다.

사용자가 링크를 누르면 운영체제가 이 목록을 뒤져 맞는 앱을 찾습니다. 찾으면 그 앱을 열고 누른 주소를 넘깁니다. 주소를 받은 앱은 경로를 읽어 어느 화면을 열지 정합니다.

사용자 지정 스킴

URL 맨 앞의 https 나 mailto 같은 부분을 스킴이라고 부릅니다. 스킴은 이 주소를 무엇으로 열지 알려 주는 앞부분입니다. https 면 브라우저가 엽니다. mailto 면 메일 앱이 엽니다.

첫째 방식은 앱이 자기만의 스킴을 새로 지어 쓰는 것입니다. 쇼핑 앱이 myshop 이라는 스킴을 운영체제에 알려 두면 myshop://products/42 는 그 앱이 엽니다. 이런 스킴을 사용자 지정 스킴(custom URL scheme)이라고 부릅니다.

만들기는 쉽지만 약점이 둘 있습니다. 하나는 스킴에 주인이 없다는 것입니다. 다른 앱이 똑같이 myshop 을 알려 두어도 운영체제는 막지 않습니다. 둘이 겹치면 어느 앱이 열릴지 장담할 수 없습니다.

다른 하나는 앱이 없을 때입니다. 앱이 깔려 있지 않으면 이 주소를 열 곳이 없습니다. 브라우저는 myshop 이 무엇인지 모릅니다. 사용자에게는 오류 창이 뜨거나 아무 반응이 없습니다.

도메인 주인이 보증하는 웹 주소

둘째 방식은 사용자 지정 스킴 대신 평범한 웹 주소를 씁니다. https://shop.example.com/products/42 를 누르면 앱이 깔려 있을 때는 앱이 이 주소를 엽니다. 앱이 없으면 브라우저가 같은 주소의 웹 페이지를 엽니다.

웹 주소는 어느 앱이든 받겠다고 적어 둘 수 있습니다. 그래서 운영체제는 이 앱이 shop.example.com 의 주인이 만든 앱인지 확인합니다. 확인은 도메인의 주인이 자기 웹 서버에 파일을 올려 두는 식으로 합니다.

그 파일에는 「이 도메인의 링크는 이 앱이 열어도 된다」는 뜻으로 앱의 식별자가 적혀 있습니다. 앱이 설치되면 운영체제가 이 파일을 받아 설치한 앱과 대조합니다. 맞으면 그때부터 이 도메인의 링크를 그 앱에 넘깁니다.

sequenceDiagram
    participant 사용자
    participant 운영체제
    participant 서버 as 웹 서버
    participant 앱
    사용자->>운영체제: 앱을 설치한다
    운영체제->>서버: 확인 파일을 요청한다
    서버-->>운영체제: 이 도메인을 열어도 되는 앱의 식별자
    Note over 운영체제: 설치한 앱과 대조해 기억한다
    사용자->>운영체제: 링크를 누른다
    운영체제->>앱: 주소를 넘기며 연다

그림의 앞 화살표 셋은 설치할 때 일어납니다. 뒤 화살표 둘은 사용자가 링크를 누를 때마다 일어납니다. 링크를 누르는 순간에는 확인을 다시 하지 않고 기억해 둔 결과를 씁니다.

플랫폼마다 붙은 이름과 확인 파일

안드로이드와 iOS 는 이 방식에 저마다 이름을 붙였습니다. 확인 파일의 이름도 다릅니다. 둘 다 도메인의 /.well-known/ 이라는 약속된 경로 아래에 둡니다.

안드로이드 앱은 만든 사람만 가진 키로 서명해서 내놓습니다. 이 키를 알아보게 해 주는 증명서가 서명 인증서입니다. 남은 그 키가 없으니 같은 인증서로 서명한 앱을 만들 수 없습니다.

안드로이드 확인 파일에는 앱의 패키지 이름을 적습니다. 패키지 이름은 com.example.shop 처럼 앱마다 붙는 이름입니다. 이름은 누구든 똑같이 지어 붙일 수 있어서 이것만으로는 가짜 앱을 거르지 못합니다.

파일에는 서명 인증서의 지문도 함께 적습니다. 지문은 인증서를 짧은 값으로 줄인 것입니다. 이름만 같은 가짜 앱은 같은 키로 서명할 수 없어서 지문이 달라 걸러집니다.

iOS 파일에는 앱의 식별자와 그 앱이 열 경로를 적습니다. 두 파일 모두 HTTPS(HyperText Transfer Protocol Secure)로 내려 줘야 합니다. iOS 는 다른 주소로 리다이렉트한 뒤에 받은 파일을 인정하지 않습니다.

이 파일을 올리는 일은 백엔드 쪽 몫입니다. 파일이 없거나 받아지지 않으면 확인이 실패합니다. 그러면 링크가 앱으로 곧장 가지 않고 브라우저로 새어 나갑니다.

앱이 깔려 있지 않을 때

두 방식이 가장 크게 갈리는 것은 앱이 없는 사용자를 맞을 때입니다. 아래 그림이 링크를 누른 뒤의 갈림을 보입니다.

flowchart TD
    A["링크를 누른다"] --> B{"앱이 깔려 있나"}
    B -->|예| C["앱이 열리고 그 화면이 뜬다"]
    B -->|아니오| D{"어느 방식인가"}
    D -->|사용자 지정 스킴| E["열 곳이 없다"]
    D -->|웹 주소| F["브라우저가 같은 주소의 웹 페이지를 연다"]

웹 주소 방식은 앱이 없어도 링크가 죽지 않습니다. 대신 웹 사이트에도 같은 경로의 페이지를 마련해 두어야 합니다. 페이지가 없으면 앱이 없는 사용자는 페이지를 찾을 수 없다는 오류를 봅니다.

앱을 설치하게 한 뒤 원래 가려던 화면으로 보내고 싶을 때도 있습니다. 링크를 누른 사용자를 앱 스토어로 먼저 보냅니다. 설치 뒤 첫 실행에서 원래 가려던 화면을 엽니다. 이것을 지연 딥 링크(deferred deep link)라고 부릅니다. 설치를 거치는 동안 링크가 끊기므로 누른 링크를 따로 기억해 두는 장치가 필요합니다.

링크를 받은 앱이 할 일

앱이 받는 것은 주소 문자열 하나입니다. 앱은 주소의 경로를 읽어 열 화면과 불러올 값을 정합니다. 경로가 /products/42 면 상품 화면을 열고 42번 상품을 불러옵니다. 웹 서버가 요청 경로를 보고 처리할 함수를 고르는 것과 같은 일입니다.

딥 링크 주소는 누구나 만들어 보낼 수 있습니다. 문자 메시지에 섞인 링크 하나로 앱의 어느 화면이든 열 수 있다는 뜻입니다. 그래서 앱은 받은 주소를 믿을 수 없는 입력으로 다룹니다. 백엔드가 밖에서 들어온 요청 값을 검증하는 것과 같은 태도입니다.

없는 경로나 이상한 값이 오면 첫 화면으로 돌려보냅니다. 로그인이 필요한 화면이면 로그인부터 거치게 합니다. 결제나 삭제처럼 되돌릴 수 없는 일은 링크만으로 실행하지 않고 사용자에게 한 번 더 묻습니다.

딥 링크를 붙이는 화면과 안 붙이는 화면

딥 링크는 주소만으로 내용을 다시 불러올 수 있는 화면에 붙입니다. 상품 화면은 상품 번호만 있으면 서버에서 내용을 다시 받아 그릴 수 있습니다.

결제 확인 화면처럼 앞 단계에서 고른 값이 있어야 뜨는 화면은 다릅니다. 주소 하나만으로는 장바구니에 무엇을 담았는지 알 수 없습니다. 이런 화면은 링크로 들어오면 그 흐름의 첫 단계로 보냅니다.

딥 링크가 쓰이는 곳

앱 밖에서 앱 안의 한 화면을 가리켜야 하는 곳이면 어디든 딥 링크가 쓰입니다. 흔한 곳을 표로 모았습니다.

푸시 알림에서는 서버가 알림에 실어 보내는 데이터 묶음인 페이로드에 딥 링크 주소를 함께 넣습니다. 사용자가 알림을 누르면 앱이 이 주소를 꺼내 화면을 엽니다. 어느 화면 주소를 실을지는 알림을 만드는 백엔드가 정합니다.

외부 로그인도 딥 링크로 돌아옵니다. 외부 로그인에 쓰는 OAuth 2.0 같은 절차는 로그인이 끝나면 미리 정해 둔 주소로 사용자를 돌려보냅니다. 이 주소를 앱의 딥 링크로 두면 브라우저의 로그인 화면에서 앱으로 되돌아옵니다.

이 돌아올 주소를 리다이렉트 URI라고 부릅니다. URI(Uniform Resource Identifier, 통합 자원 식별자)는 URL 을 포함하는 더 넓은 이름입니다. 여기서는 URL 과 같은 것으로 읽어도 됩니다.

관련 항목

딥 링크가 속하는 상위 분류

하이퍼링크 · URL · 모바일 개발 · 앱 내비게이션

딥 링크를 구현하는 방식과 플랫폼 기능

URL 스킴 · Android App Links · 유니버설 링크 · 지연 딥 링크 · 인텐트 · 인텐트 필터 · 매니페스트

딥 링크의 도메인 주인을 확인하는 파일과 규약

Digital Asset Links · apple-app-site-association · Well-Known URI · HTTPS · 도메인 이름 · 코드 서명

딥 링크를 실어 나르는 채널

푸시 알림 · 페이로드 · QR 코드 · 이메일 마케팅 · 공유 시트 · 앱 스토어

딥 링크를 받아 화면을 여는 앱 구성 요소

액티비티 · 웹뷰 · 네이티브 앱 · iOS · Android

딥 링크로 앱에 돌아오는 로그인 절차

OAuth 2.0 · 리다이렉트 URI · PKCE · 소셜 로그인

딥 링크를 노리는 공격과 그 방어

입력 검증 · 피싱 · URL 스킴 하이재킹 · 오픈 리다이렉트

앱이 없을 때 딥 링크를 대신하는 수단

웹 페이지 · 프로그레시브 웹 앱 · 스마트 앱 배너 · 랜딩 페이지