brunch

You can make anything
by writing

C.S.Lewis

by 윤거성 David Yun Dec 16. 2019

유니버설 링크, URI 스킴, 앱 링크 및 딥 링크:

아래 글은 딥링크에 관련하여 유니버설 링크, URI 스킴, App link에 대한 개념을 소개하고, 해당 정보를 쉽게 이해할 수 있도록 만들어진 글입니다. Branch는 이 분야에 대해 글로벌 업계에 막대한 영향력을 가지고 있는 선도 기업입니다. Branch에서 만든 글을 통해서 많은 분들께서 딥링크(Deep link)에 대한 명확한 이해를 하실 수 있기를 바랍니다.

===============

딥 링크, 유니버설 링크, URI/URL 스킴 및 앱 링크는 최근 수년간 모바일 앱 내부 콘텐츠를 연결하는 방법을 현저히 바꿔왔습니다. 이는 어떤 기술을 구현해야 할지, 각각 업계 최고의 사례는 무엇인지에 대하여 수많은 앱 개발자들을 혼란에 빠뜨려왔습니다.

게다가, 모바일 딥 링크는 여전히 빠르게 진화하고 있는 분야입니다. 수년 전 작동하던 방식이 여전히 가능하다고 해서 반드시 오늘날 최선의 접근법인 것은 아닙니다. 수년간의 시대에 뒤처진 항목과 잘못된 정보에서 벗어나 오해를 불식하고 모바일 딥링크의 세계에 새로운 바람을 불어넣을 시간입니다.

딥 링크는 무엇인가요?

우선 몇 가지 핵심적인 용어: 딥 링크는 단순히 개념일 뿐입니다. 우리는 사실 딥 링크를 매일 이용하는데, 아마 이 블로그 포스트를 읽기 위해 클릭하셨을 수도 있습니다. 이 용어는 단지 특정 콘텐츠에 직접 도달하는 모든 링크를 뜻할 뿐입니다. 사람들이 http://example.com/my-awesome-content-page URL을 클릭할 때 http://example.com/으로 이동하여 다시 웹사이트를 뒤져서 my-awesome-content-page로 이동하는 것을 예상하지는 않습니다. 달리 말해서, 웹의 대다수 링크는 사실상 딥링크이며 단지 그렇게 부르고 있지 않을 뿐입니다. 우리에게 이는 단지 "링크"일뿐입니다.

모바일 앱의 딥 링크는 훨씬 더 복잡하지만, 모바일 딥 링크는 여전히 앱 사용자에게 만족스러운 콘텐츠 경험을 제공하는 가장 좋은 방법입니다. 유니버설 링크, URI 스킴 및 앱 링크는 모바일 딥 링크가 작동하도록 하는 다양한 기술 표준으로 사용자가 앱 내부 콘텐츠에 직접 도달하도록 해줍니다. 모바일 앱 내부 페이지를 친구와 공유하려 한다면, 딥 링크는 친구를 해당 페이지로 인도합니다. 딥 링크가 없다면, 친구는 스스로 정확한 페이지를 찾으려 발버둥 칠 것이며, 때때로 앱스토어에 있거나(심지어 앱이 이미 설치되어 있는데도) 모바일 웹에 있는 자신을 발견하게 될 것입니다.

모바일 딥 링크 구현 절차는 지난 수년간 진화해 왔으며, 안드로이드와 iOS는 각자의 해결책을 제시해 왔습니다. 이는 앱 개발 커뮤니티 상에 혼란을 불러왔는데 심지어 숙련된 엔지니어조차 위기 상황에서 링크를 즉석에서 업데이트해야 했으며 신규 엔지니어들은 그들 앱의 딥 링크를 구현할 때 최적의 경로를 고민해야 했습니다.

다음은 현재 사용하는 다양한 모바일 딥 링크 표준의 상세 내용입니다:

참고: iOS와 안드로이드는 모바일 시장의 99.3% 를 차지하고 있습니다. 그렇기 때문에 Branch는 다른 플랫폼은 거의 지원하지 않으며, 간략히 하기 위해 다른 플랫폼은 여기서 배제하였습니다.

물론, 모든 플랫폼과 OS 버전을 지원하는 표준은 없습니다:

페이스북은 실제 전망을 보여준 오픈 소스 딥 링크 표준을 발명한 공로를 특별히 인정받아 마땅하지만, 그 이후 이를 완전히 포기하였습니다:

이러한 개별 표준을 좀 더 자세히 들여다봅시다.

URI 스킴은 무엇입니까? URL과는 다른 것인가요?

만약 엔지니어로 가득한 방에서 난장판을 일으키기를 원한다면 코드 들여 쓰기 할 때 탭을 쓸지 스페이스를 쓸지 논쟁을 하기만 하면 그렇게 될 것입니다. 혹은 URI와 URL의 차이를 혼동할 수 있습니다. 이에 대해 에세이도 씌었지만, 우리의 목적을 위해서는 모든 URL은 또한 URI라는 점만 기억합니다. 처음에 중요한 부분은 스킴입니다. 이미 http://와 https:// 스킴에 익숙할 것입니다. 심지어 ftp:// 혹은 feed:// 도 만난 적이 있을 것입니다. 이러한 모든 것들은 요구되는 콘텐츠 유형을 나타내며 모바일 앱은 자신만의 맞춤 URI 스킴을 등록할 수 있습니다. 예를 들자면 myapp://와 같이 만들 수 있습니다.

딥 링크를 연구해보면, URI 스킴에 관한 심각한 콘텐츠와 마주칠지도 모릅니다. 앱 개발의 오랜 역사를 통하여, URI 스킴은 iOS와 안드로이드 양쪽 진영에서 주된 앱의 딥 링크 방법이었습니다.

URI 스킴의 한계로

유감스럽게도 URI 스킴의 한계로 인해, 커스텀 URI 스킴에 있어서 다음 두 가지 상황을 쉽게 처리할 수 없는 심각한 단점이 존재합니다:

앱이 설치되지 않은 경우.

두 개 이상의 앱이 myapp://에 응답하려 하는 경우.

URI 스킴은 친구가 공유한 링크를 클릭하였는데 앱이 설치되어 있지 않은 경우에 대한 자체 대비책이 없어서 그저 에러 페이지를 보여줍니다. 또한, 중앙 등록 시스템이 없어서 URI 충돌이 발생할 수 있습니다 (애플의 공식적인 입장은 현재로는 처리 절차가 없다는 것입니다) 많은 개발자가 복잡한 자바스크립트 재설정을 사용하여 첫 번째 문제의 회피 방법을 개발하였지만, 매번 새로운 iOS가 출시될 때마다 동작을 멈추는 경향이 있습니다. 두 번째 문제에 대해서는 해결책이 절대 없을 것 같습니다.

이러한 제한으로 인해 iOS와 안드로이드는 각각 유니버설 링크와 앱 링크로 알려진 2세대 딥 링크 표준을 개발하였습니다. 애플이 URI 스킴의 자바스크립트 재설정을 차단하였기 때문에 유니버설 링크는 iOS 딥 링크의 핵심입니다. 앱 링크는 훨씬 더 낮은 수용률을 보였습니다.

유니버설 링크와 앱 링크의 차이점

앱 고유 콘텐츠 유형의 URI 스킴과 달리 유니버설 앱과 앱 링크는 웹 페이지와 앱 내부의 특정 콘텐츠를 가리키는 단순한 표준 웹 링크입니다. (https://example.com) 유니버설 링크 혹은 앱 링크가 열리면 장치는 해당 도메인에 등록된 설치된 장치가 있는지 확인합니다. 만약 있다면, 웹 페이지를 구동하지 않고 해당 앱을 즉시 시작합니다. 그렇지 않다면, 기본 웹 브라우저로 해당 웹 URL을(앱 혹은 플레이 스토어로의 간단한 재설정일 수 있음) 시작합니다.

측정과 분석에 전적으로 참여하는 경우, 여기에서 문제를 느낄지도 모릅니다: 앱이 즉시 시작된다는 것은 재설정 체인에 기반을 둔 전통적인 웹과 이메일 마케팅 추적 방법이 더는 동작하지 않음을 뜻합니다. 이는 심각한 문제일 수 있는데 현재로는 유니버설 링크와 앱 링크 표준 모두 해결책이 부족합니다. 유일한 옵션은 앱이 구동된 후 소급하여 클릭을 측정하는 것입니다.

유니버설 링크는 현재 iOS 표준이지만 단점이 있습니다.

유니버설 링크는 실제로는 보편적이지 않습니다. 페이스북이나 트위터와 같은 주요 플랫폼이 유니버설 링크를 전혀 지원하지 않으며 오른쪽 위 모서리의 친숙해 보이는 버튼이 본질적으로는 핵 옵션이라는 힌트를 주지 않습니다. 방문자가 깨닫지 못한 채로 쉽게 유니버설 링크를 중지시킬 수 있습니다. 한번 중지시키고 나면 일반 사용자가 이를 되돌리기는 매우 어려우며 앱 때문에 그렇게 되었다고 생각하게 됩니다.

설상가상으로 유니버설 링크가 심각하게 망가지는데 애플이 검증 도구를 제공하지 않으므로 테스트하기 어렵습니다.

URL/URI 스킴은 더는 사용하지 않습니까?

애플에 따르면, 그렇습니다. 애플은 공식적으로 iOS 9.2 버전부터 딥 링크를 위한 URI 링크를 더는 지원하지 않으며 개발자는 iOS에서 같은 기능을 위해 유니버설 링크를 구현하도록 강요받았습니다.

현실적으로는 아직 아닙니다. 유니버설 링크가 작동할 때는 정말 좋지만, 여전히 URI 스킴으로 백업할 필요가 있는 경우가 매우 많으며 오로지 이에만 의존하는 경우 상당량의 트래픽을 남기게 됩니다. 가까운 미래의 어느 시점에 URI 스킴을 포기하기에는 안드로이드 생태계는 너무 파편화되어 있습니다.

디퍼드 딥 링크

아직 논의하지 않은 중요한 개념이 하나 있습니다: 디퍼드 딥 링크. URI 스킴, 유니버설 링크, 혹은 앱 링크를 통해 구현된 표준 딥 링크 중 어느 것이라도 앱이 장치에 이미 설치된 경우에만 동작합니다. 그렇지 않다면, 잘해야 사용자를 앱 스토어 혹은 플레이 스토어로 인도할 뿐입니다. 심지어 사용자를 앱 내부의 특정 위치로 인도하려 할 때 먼저 이를 설치해야 한다면 어떻게 해야 할까요? 디퍼드 딥 링크가 이를 가능하게 하는데, 설치 과정을 통해 특정 콘텐츠의 문맥을 보존하여 설치 후 사용자를 정확한 지점으로 인도합니다.

다른 딥 링크 표준

덜 일반적인 두 가지 다른 딥 링크 표준을 실행할 수도 있습니다: 크롬 인텐트 및 페이스북 앱 링크.

크롬 인텐트

크롬 팀은 앱이 설치되지 않은 경우 대비책을 제시하려는 의도로 자체 개발 확장 커스텀 URI 스킴을 구현하였습니다. 근본적인 문제에 대한 우아한 해결책인 크롬 인텐트는 안드로이드 버전 크롬 브라우저와 소수의 서드 파티 앱에서만 지원됩니다. 표준 기술과 크롬에 특화된 대안을 모두 지원해야 하므로 모든 딥 링크 구현에 복잡성이 추가됩니다.

페이스북 앱 링크

페이스북은 2014년에 URI 스킴 딥 링크의 한계를 해결하기 위한 개방 표준으로 앱 링크를 만들었습니다. 앱 링크의 두 가지 주요 구성요소:

표준 http : // 링크의 웹 페이지 대상에 추가할 메타 태그 집합입니다. 이 태그는 네이티브 앱 내부 해당 콘텐츠의 커스텀 URI 스킴 위치 및 앱이 설치되지 않은 경우의 실시해야 할 행동 양식을 지정합니다.

개방 링크를 지원하는 앱 내부에서 사용할 라우팅 엔진입니다. 이 엔진은 링크를 열기 전 앱 링크 태그 대상 URL을 확인하여 해당 앱을 구동하거나 지정된 대체 행동 양식을 실행합니다.

앱 링크 표준은 치명적인 한계가 있는데 원래 앱과 대상 앱 모두 작동해야 합니다. 메타 태그 구성 요소가 널리 채용된 데 반하여 라우팅 엔진의 주요한 구현은 핵심 페이스북 및 메신저 앱에 그쳤습니다. 오늘날 페이스북은 사용자를 플랫폼 내부에 제한하는 것을 선호하며 주요 안드로이드 앱을 제외하면 곳곳에서 앱 링크 라우팅 엔진을 제거해 왔습니다. 페이스북이 또한 iOS 유니버설 링크를 차단한 이후로 iOS 상의 페이스북 혹은 메신저의 서드 파티 앱을 안정적으로 구동할 방법은 없습니다. Branch는 이러한 한계를 피할 해결책을 구현하였습니다.