[Swift] URL Scheme: iOS 앱 간 연결의 핵심 기술

URL Scheme이란?

URL Scheme는 iOS 앱을 식별하고 외부에서 앱을 호출할 수 있게 해주는 고유 주소 체계입니다.

마치 Safari에서 https://로 웹사이트를 여는 것처럼, letsgitit:// 같은 앱 전용 프로토콜을 등록해두면 다른 앱(예: Safari, GitHub 웹페이지)에서 우리 앱을 열 수 있어요.

일상에서 만나는 URL Scheme

가장 간단한 예시로는 기본 앱에서 많이 활용하는 기능들이 있습니다.

번호 형태의 텍스트를 누르면 전화걸기가 바로 뜨는 방식이죠. 번호를 누르면 팝업메뉴가 뜨고 다양한 액션을 취할 수 있게 확인되는 부분에서 연결하는 느낌입니다. (기본 앱끼리 간의 호환성이 엄청 뛰어나지 않을까 하는 생각이 들었어요)

문득 생각난 예시가 카카오T나 카카오페이에서 카카오톡 앱을 열 때와 비슷하다고 생각했는데, 동작은 비슷하지만 조금 다를 수도 있다고 합니다. (개인적으로 LG 익시오(AI 통화녹음 앱)에서 이걸 지원해줬으면 좋았을 텐데 하는 생각을 했어요.)

다른 활용 예시들:

• 지도에서 열기
• 이메일 보내기
• Toss 앱으로 인증하기

사용할 수 있는 범위는 정말 다양할 것 같습니다.

URL Scheme 지원 여부 확인하기

실제로 URL Scheme를 지원하는지 확인하는 방법은 웹에서 공개 문서를 검색하는 것입니다.

• 검색어: 앱이름 + URL Scheme (예: 카카오톡 URL Scheme, 네이버 앱 스킴)
• 대부분 공식 문서 혹은 블로그에 사용 예시가 있다고 합니다.

실무에서의 URL Scheme 활용 패턴

실무에서는 주로 이런 패턴으로 활용됩니다:

• 로그인 인증 콜백 (OAuth 인증 후 앱으로 되돌아올 때) - 현재 같은 상황
• 앱 간 기능 요청 (A 앱에서 B 앱 기능 일부 호출 - 예: 송금, QR스캔) - 카메라에서 QR 스캔 같은 것
• 딥링크: 특정 화면 직접 진입 (예: 특정 게시글, 상품 등)

---

딥링크란 무엇인가?

딥링크는 단순히 앱만 여는 게 아니라, 앱 안에서 특정 위치(화면, 콘텐츠, 탭, 글 등)를 바로 보여주는 기능입니다.

"링크 하나 클릭했는데, 앱이 열리더니 딱 내가 보던 화면이 떠!" 이게 바로 딥링크입니다.

 

딥링크 경험 예시

유튜브	Safari → 유튜브 앱에서 영상 재생
인스타그램	브라우저 링크 → 앱의 특정 계정 or 포스트 바로 열기
카카오맵	웹 지도 → 앱에서 길찾기 화면 바로 실행
쿠팡	프로모션 링크 클릭 → 앱에서 특정 상품 상세 페이지로 이동

 

---

딥링크의 종류

 

딥링크는 구현 방식에 따라 세 가지로 나뉩니다:

종류	설명	예시
URL Scheme 딥링크	앱 고유 스킴 사용 (구형 방식)	youtube://watch?v=1234
Universal Link	웹 주소 기반 (iOS 공식 권장)	https://youtube.com/watch?v=1234
Deferred Deep Link	앱이 설치 안 되어 있어도, 설치 후 딥링크 자동 적용	마케팅, 광고에서 많이 씀

 

요약하자면 딥링크가 상위 개념입니다.

 

"앱 외부(웹 또는 다른 앱)에서 앱 내부의 특정 위치로 연결하는 기술"을 딥링크라고 하고, 앱 간의 연결을 하기 위해서 URL Scheme과 Universal Link, Deferred Deep Link의 선택지가 있는 것입니다.

 

 

세 가지 딥링크 방식 비교

항목	URL Scheme	Universal Link	Deferred Deep Link
링크 형식	myapp://screen/123	https://myapp.com/screen/123	https://xyz.page.link/... (Firebase 등)
앱 설치 시 동작	무조건 앱 실행 시도	앱 설치되어 있으면 앱 열림	설치되면 앱 실행 + 링크 복원
앱 미설치 시 동작	❌ 아무 반응 없음 or 오류	✅ 웹페이지 fallback or AppStore 이동	✅ AppStore → 설치 후 앱에서 목적지로 자동 이동
사용 목적	앱 간 실시간 연결, 인증 호출 등	웹 공유, SNS 마케팅, 푸시 대응 등	앱 설치 유도 + 설치 후에도 목적 유지
보안성	❌ 낮음 (스푸핑/가로채기 가능)	✅ 높음 (도메인 검증)	✅ 높음 (동적 링크 플랫폼 기반)
설정 난이도	⭐ 쉬움 (Plist 설정만)	⭐⭐⭐ 복잡 (도메인 설정 + AASA 파일 + Capabilities)	⭐⭐⭐⭐ 플랫폼 연동 필요 (Firebase, Branch 등)
권장 여부	❌ Deprecated 경향 (하지만 여전히 사용됨)	✅ iOS 공식 권장 방식	🔁 Universal 기반 확장 (권장 방식 포함)
대표 사용처	Toss 인증, 카카오톡 로그인	쿠팡 상품 링크, 마케팅 캠페인	앱 설치 유도형 공유 링크, 추천인 코드 등

---

 

상황별 권장 딥링크 방식상황별 권장 딥링크 방식 

시나리오	권장 딥링크	방식이유
A 앱에서 B 인증앱 열기	✅ URL Scheme	즉시 전환, 빠른 응답
카톡/메일에서 앱 설치 유도	✅ Deferred Deep Link	설치 후에도 원래 목적 유지
웹에서 특정 상품으로 앱 연결	✅ Universal Link	사용자 경험, 보안, fallback 완비
앱 설치 후 광고 성과 추적	✅ Firebase 기반 Deferred Deep Link	클릭 → 설치 → 전환까지 추적 가능
인증 후 redirect 시 콜백 처리	✅ URL Scheme or Universal Link	OAuth 구조에 따라 선택 가능

 

---

URL Scheme이 여전히 사용되는 이유

그렇다면 왜 아직도 URL Scheme 방식을 고집하는 경우가 있을까요? 무슨 성능적 이점이라도 있을까요?

 

URL Scheme의 장점:

• 실시간 앱 간의 전환에 강함
• 인증 앱, 결제 앱, 카카오톡 인증처럼 실시간 호출이 필요한 구조에 적합

하지만 보안적인 스푸핑의 위험이 있어서 추천하지 않는데도 불구하고 인증 앱에 어떻게 쓸 수가 있는 건지 궁금했습니다.

 

---

스푸핑 위험이란?

URL Scheme은 앱 이름만 맞추면 누구나 흉내낼 수 있습니다.

예시:
kakaotalk://auth?code=abc123
이 스킴을 악성 앱이 사전에 등록해버리면 → 진짜 인증 대신 가짜 앱이 열릴 수도 있음

 

이를 Scheme Hijacking / URL Spoofing이라고 부릅니다.

 

---

그럼에도 불구하고 보안 분야에서 사용하는 이유

 

보안이 URL Scheme 자체에 의존하지 않기 때문입니다.

🔑 핵심은 "URL은 신호일 뿐, 진짜 인증은 내부에서 다시 검사"하기 때문이에요.

결국 "URL Scheme도 결과 신호만 전달하고, 진짜 보안은 서버에서 하니까 문제없잖아? 그런데 왜 Apple은 Universal Link를 더 권장할까?"

---

Universal Link가 더 권장되는 이유

URL Scheme의 문제점: "기능 부족 + 예측 불가능성"

• 앱 미설치 시 처리 없음
• iMessage, 메일, 브라우저 등에서 막힐 수 있음 (사용자 기기 보안 설정에 따라 차단될 수 있음)
• 링크 공유 불안정
• 누가 등록했는지 식별 불가

 

Universal Link는 "플랫폼 연계와 UX에 최적화"

• 설치 여부에 따라 자동 fallback: 앱 설치 O → 앱 실행 / 설치 X → 웹 페이지 열림
• 공유 가능: SNS, 메일, iMessage에서 자유롭게 전달 가능
• 도메인 검증 기반: apple-app-site-association 파일로 검증된 앱만 링크 처리 가능
• Safari, 메일, 카카오톡 등에서도 안정 작동: 사용자 환경 전반에서 통일된 UX 보장
• URL 그대로 유지됨: 사용자 입장에서 신뢰도 상승 (https://로 시작함)

 

보안은 다중 레이어로 설계되어야 안전합니다. 즉, 들어오는 입구부터 위험을 줄이면 전체 보안 사고 확률이 낮아지는 것입니다.

 

 

---

OAuth 인증에는 URL Scheme이 최적화된 이유

 

내 상황에서 URL Scheme을 쓰는 것이 맞는가?

OAuth 인증에는 URL Scheme이 최적화된 방식이라고 합니다.

 

왜 OAuth에는 URL Scheme이 더 나은가?

OAuth 연동 기준에서 실시간 앱 전환이 빠르다는 장점이 있습니다:

1. 실시간 전환이 중요하기 때문입니다. → 사용자가 로그인하고 앱으로 즉시 돌아와야 하기 때문이에요.
2. Universal Link는 Safari에서 자동 앱 이동을 제한합니다. 예를 들어 Safari에서 Universal Link를 클릭해도 사용자가 "앱에서 열기"를 직접 눌러야 할 수 있어요.
3. code → token 과정은 서버에서 보안 검증하므로, 중간에 URL Scheme로 code가 오더라도 탈취 위험은 거의 없습니다.

---

OAuth에서 코드 탈취가 문제없는 이유

왜 중간에 코드가 탈취당해도 문제가 없을까요?

1. OAuth 2.0에서는 Access Token이 발급될 때 client_id와 연동된 상태로 만들어짐 → 즉, "이 토큰은 앱 A가 사용자로부터 위임받은 권한이다"
2. 토큰이 Scope를 기준으로 동작하기 때문에 앱 B가 다른 Scope를 요구하면 거부됨
3. 토큰 자체는 단순 문자열이라 복제할 수 있지만, 서버가 이 토큰이 어느 앱에서 만들어졌는지 알고 있음 → 그래서 보호됨

 

 

처음에는 뭐부터 무엇을 해야할지 감이 잡히지 않을때가 많이 있는데, 뭐라도 하다보니까 감이 잡히는 느낌을 받곤 해요.

"일단 해보고, 해본다음 생각하자 " 자꾸 잊게 되고 놓치는 경우가 많지만 "오늘도 나는 포기 하지않았다"  이 부분이 저에게 추진력을 가져다 줬으면 좋겠습니다.!