Android Install Referrer부터 iOS 서버 매칭, Airbridge 구조 비교까지
2023년, FE 개발자로 활동하기 전의 나는 Android App Links와 iOS Universal Links 설정 과정을 각각 정리했었다.
당시 공부했던 내용은 이후 협업에서 많은 도움이 되었다. 백엔드 개발자와 앱 내부 경로를 맞출 때도,
앱링크가 안된다고 했을때도, 도메인 설정을 이야기할 때도, 앱 링크의 구조를 알고 있다는 사실은 생각보다 큰 힘이 되어주었다.
그때는 앱 링크를 제대로 구현하는 것만으로도 충분히 어렵고 가치 있는 일이었다.
그리고 시간이 지난 2026년, 다시 앱 링크를 설계하면서 생각이 깊어졌다.
앱이 설치된 상태에서 특정 화면을 여는 것만으로 충분할까?
앱이 설치되어 있지 않다면, 사용자가 눌렀던 링크의 목적지는 설치 후 어디에 남아 있을까?
이번 글은 이 질문에서 시작한다. App Links와 Universal Links의 설정을 다시 나열하기보다, 링크 클릭부터 앱 설치와 첫 실행까지 이어지는 전체 아키텍처를 살펴보고 직접 디퍼드 딥링크를 설계한 과정을 정리하려 한다.
2023년에는 앱과 도메인을 연결하는 방법을 공부했다
Android App Links와 iOS Universal Links의 기본 원리는 비슷하다. HTTPS URL을 운영하는 도메인과 앱이 서로 신뢰 관계를 맺고, 운영체제가 해당 URL을 앱으로 열어도 되는지 검증한다.
| 구분 | Android | iOS |
|---|---|---|
| 기술 | App Links | Universal Links |
| 도메인 검증 파일 | /.well-known/assetlinks.json |
/.well-known/apple-app-site-association |
| 앱 설정 | Intent Filter, 패키지명, 서명 인증서 | Associated Domains, App ID |
| 앱 내부 처리 | URL을 파싱한 뒤 앱 라우터의 화면으로 변환 | |
2023년의 글에서는 AndroidManifest, assetlinks.json, SHA-256 인증서 지문, AASA와 Associated Domains 같은 설정에 집중했다. 당시의 목표는 다음과 같았다.
웹 URL 클릭
↓
운영체제가 도메인과 앱의 관계를 검증
↓
설치된 앱 실행
↓
앱 내부의 특정 화면으로 이동
이 구조는 지금도 유효하다.
Apple 역시 Universal Links를 하나의 HTTPS URL로 웹과 설치된 앱의 콘텐츠를 연결하는 방식으로 설명한다.
그런데 여기에는 중요한 전제가 하나 숨어 있다.
앱이 이미 설치되어 있어야 한다.
Deep Link와 Deferred Deep Link는 해결하는 문제가 다르다
예를 들어 사용자가 다음 상품 링크를 눌렀다고 생각해보자.
https://example.com/products/42앱이 설치되어 있다면 App Links 또는 Universal Links가 앱을 실행하고, 앱 라우터는 /products/42를 상품 상세 화면으로 바꾸면 된다.
하지만 앱이 설치되어 있지 않다면 사용자는 웹 페이지나 앱스토어로 이동한다. 이후 앱을 설치하고 처음 실행해도 앱은 사용자가 조금 전 /products/42를 눌렀다는 사실을 알지 못한다.
| 상태 | 일반 Deep Link | Deferred Deep Link |
|---|---|---|
| 앱 설치됨 | 특정 화면으로 바로 이동 | 특정 화면으로 바로 이동 |
| 앱 미설치 | 웹 또는 앱스토어로 이동하고 문맥이 끊김 | 설치 후 첫 실행에서도 원래 목적지를 복원 |
결국 디퍼드 딥링크의 본질은 링크를 여는 기술이 아니다.
설치라는 비연속 구간을 통과하면서도 사용자가 클릭한 목적지를 보존하는 기술이다.
먼저 직접 디퍼드 딥링크를 설계해봤다
Android에는 Google Play Install Referrer API가 있지만 iOS에는 같은 역할을 하는 API가 없다. 그렇다면 서버에 클릭 정보를 저장하고, 앱이 설치된 뒤 첫 실행 때 서버에 요청하면 해결할 수 있지 않을까?
처음 설계한 흐름은 다음과 같았다.
1. 서버에 클릭 정보 저장
↓
2. 앱스토어로 이동해 앱 설치
↓
3. SDK가 첫 실행 때 서버 확인
↓
4. 저장된 딥링크를 SDK에 전달
↓
5. 앱 내부 목적지로 이동
여기서 표현을 정확하게 할 필요가 있다. 앱을 설치하는 순간에는 우리 앱 코드가 실행되지 않는다. 서버 API를 호출할 수 있는 시점은 앱 설치 시점이 아니라 설치 후 첫 실행 시점이다.
1단계: 추적 링크를 만든다
실제 목적지를 URL에 그대로 노출하기보다 서버가 발급한 임의 토큰을 사용한다.
https://link.example.com/l/abc123서버에는 토큰과 실제 앱 목적지를 저장한다.
clickId: abc123
destination: /products/42
platform: android | ios
createdAt: 2026-08-25T12:00:00+09:00
expiresAt: 2026-08-25T13:00:00+09:00
consumedAt: null2단계: 링크 서버가 목적지를 보관한다
사용자가 링크를 열면 서버는 클릭 이벤트와 목적지를 저장한 뒤 플랫폼에 맞는 스토어로 리다이렉트한다.
GET /l/{clickId}
•
1. clickId 유효성 검사
2. 목적지와 만료 시간 저장
3. Android 또는 iOS 판단
4. Play Store 또는 App Store로 이동3단계: 첫 실행에서 매칭 키로 목적지를 복원한다
앱 또는 SDK는 첫 실행 때 서버에 보류 중인 딥링크를 요청한다. 하지만 서버 API를 호출하는 것만으로는 목적지를 찾을 수 없다. 설치 전에 발생한 클릭과 설치 후 첫 실행에 공통으로 존재하는 매칭 키가 필요하다.
Android에서는 Google Play Install Referrer를 통해 click_id를 복원할 수 있다.
POST /v1/deferred-links/resolve
Content-Type: application/json
•
{
"platform": "android",
"installationId": "new-installation-id",
"matchType": "install_referrer",
"clickId": "abc123"
}여기서 clickId는 설치 전 클릭과 설치 후 앱을 연결하는 키다. 반면 installationId는 새로 설치된 앱에서 생성되므로 설치 전 클릭을 찾는 용도로 사용할 수 없고, 동일 설치의 중복 요청을 막는 용도로 사용한다.
서버는 다음 순서로 요청을 처리한다.
1. clickId에 연결된 클릭 정보 조회
2. 플랫폼과 유효 시간 검증
3. 이미 소비된 링크인지 확인
4. 허용된 앱 내부 경로인지 검증
5. installationId 기준으로 멱등 처리
6. 목적지를 반환하고 링크를 소비 상태로 변경{
"destination": "/products/42",
"matched": true,
"matchType": "install_referrer"
}iOS에는 Install Referrer에 해당하는 API가 없다. 따라서 iOS 흐름은 이 지점에서 아직 완성되지 않는다. 첫 실행 때 서버 API를 호출할 수는 있지만, installationId만으로는 설치 전에 발생한 어떤 클릭을 조회해야 하는지 결정할 수 없기 때문이다.
정리하면 Android는 Install Referrer에서 얻은 clickId로 목적지를 복원할 수 있다. 반면 iOS는 설치 전후를 연결할 별도의 매칭 방법을 먼저 찾아야 한다.
결국 첫 실행에서 어려운 것은 서버에 요청하는 방법이 아니라, 그 요청을 설치 전의 어떤 클릭과 연결할 것인가였다.
Android에는 Install Referrer라는 다리가 있다
Android는 Google Play Install Referrer API를 통해 Play Store가 보관한 referrer URL과 클릭·설치 시각 등의 정보를 조회할 수 있다.
추적 링크 서버가 Play Store로 이동시킬 때 click_id를 referrer에 포함하면, 새로 설치된 앱이 첫 실행에서 그 값을 다시 읽을 수 있다.
추적 링크 클릭
↓ click_id=abc123
Google Play
↓ 앱 설치
Install Referrer 조회
↓ abc123 복원
서버에서 /products/42 조회
즉 Android에서는 click_id가 설치 전 브라우저와 설치 후 앱 사이를 연결하는 비교적 명확한 키가 된다.
다만 이것도 모든 Android 설치를 해결하는 만능 API는 아니다.
- Google Play를 통해 설치한 경우에만 사용할 수 있다.
- referrer가 비어 있거나 조회에 실패하는 경우를 처리해야 한다.
- 동일한 clickId가 반복 사용되지 않도록 소비 여부를 관리해야 한다.
- 앱 실행 직후 온보딩이나 로그인이 필요하면 실제 이동 시점을 보류해야 한다.
- 딥링크 목적지는 허용된 경로인지 서버와 앱 양쪽에서 검증해야 한다.
iOS는 서버 요청보다 매칭이 문제였다
그렇다면 iOS에서는 어떤 정보를 이용해 클릭과 첫 실행을 연결할 수 있을까?
처음에는 휴대폰의 고유 ID를 서버에 함께 보내면 된다고 생각했다. 하지만 후보를 하나씩 확인하면서 단순한 기기 ID로는 이 문제를 해결할 수 없다는 것을 알게 되었다.
installationId는 앱을 설치한 뒤에 생성되므로 설치 전 Safari의 클릭에는 존재하지 않는다. IDFV 역시 앱에서만 접근할 수 있어 Safari와 값을 공유할 수 없다.
IDFA도 모든 링크에서 사용할 수 있는 답은 아니었다. ATT 동의가 필요하고, 일반적인 웹 링크가 IDFA를 직접 읽어 새로 설치된 앱에 넘겨주는 구조도 아니기 때문이다.
마지막으로 클릭 시각, IP 주소, User-Agent와 기기 정보를 조합하는 방법을 생각해봤다. 그러나 이것은 동일 사용자를 증명하는 것이 아니라 가장 비슷한 후보를 추정하는 확률적 매칭이다. 공유 Wi-Fi, VPN과 Private Relay 환경에서는 다른 사용자를 잘못 연결할 수 있고, 핑거프린팅 정책도 함께 검토해야 한다.
결국 필요한 것은 더 많은 기기 정보가 아니었다. 설치 전 클릭과 설치 후 앱이 모두 알고 있는 공통 매칭 키였다. 이 기준으로 실제 사용할 수 있는 방법을 다시 나눠봤다.
| 설치 전 Safari에서 abc123 클릭 |
? | 설치 후 새 앱의 installationId |
서버는 두 사건을 저장할 수 있지만, 저장했다는 이유만으로 같은 사용자라고 증명할 수는 없다. 이것이 iOS 디퍼드 딥링크에서 가장 어려운 지점이었다.
iOS에서 생각해볼 수 있는 매칭 방법
| 방법 | 장점 | 제약 |
|---|---|---|
| 동일 계정 매칭 | 자사 서비스 안에서 명시적으로 연결 가능 | 웹과 앱에서 같은 계정 로그인이 필요하며 이동 시점이 로그인 이후가 됨 |
| 일회용 코드 | 정확하고 설명하기 쉬움 | 사용자 입력 과정이 추가됨 |
| 클립보드 토큰 | 클릭 토큰을 직접 전달 가능 | 사용자의 클립보드 접근 허용과 UX 고려가 필요함 |
| IDFA | 동의한 광고 환경에서는 결정적 매칭 가능 | ATT 동의가 필요하고 일반적인 웹 링크 전체를 해결하지 못함 |
| IP·기기 정보 추정 | 별도 입력 없는 자동화 가능 | 공유 Wi-Fi, VPN, Private Relay에서 오탐 가능. 핑거프린팅 정책도 검토해야 함 |
특히 IP 주소, 브라우저와 기기 특성을 조합해 사용자를 식별하는 방식은 단순한 기술 문제가 아니다. Apple은 기기나 사용자를 고유하게 식별하기 위한 핑거프린팅을 금지하고 있다.
따라서 직접 구현한다면 확률적 매칭을 당연한 기본값으로 삼기보다, 서비스 특성에 맞는 명시적 연결 방법과 매칭 실패 시 fallback을 함께 설계하는 편이 안전하다고 판단했다.
매칭 성공 → 원래 목적지로 이동
매칭 보류 → 로그인 후 다시 확인
매칭 실패 → 홈 또는 캠페인 전용 랜딩으로 이동
만료됨 → 기본 화면으로 이동따라서 iOS에서는 동일 계정, 일회용 코드, 사용자가 허용한 클립보드 토큰 또는 전문 솔루션처럼 서비스에 맞는 매칭 전략을 먼저 선택해야 한다.
Android와 iOS는 목적지를 찾는 방법이 다르다. 하지만 각 플랫폼에서 매칭을 완료해 목적지를 얻은 이후의 처리는 같다. 반환받은 경로를 기존 App Links와 Universal Links에서 사용하던 URL 파서와 앱 라우터에 전달하면 된다.
그래서, 결국 직접 구현할 수 있을까?
결론부터 말하면 설치 전과 설치 후에 함께 전달할 수 있는 명시적인 매칭 키가 있다면 직접 구현할 수 있다. 핵심은 기기를 추측하는 것이 아니라, 플랫폼별로 신뢰할 수 있는 키를 정하고 그 키가 없을 때의 실패까지 설계하는 것이다.
Android는 Install Referrer의clickId로 연결한다.
iOS는 자사 랜딩 페이지에서 클립보드clickToken을 전달한다.
공유된 키가 없다면 억지로 추정하지 않고matched: false와 fallback을 반환한다.
Android: Install Referrer로 직접 구현한다
Google Play를 통한 설치라면 Install Referrer에 clickId를 넣어 설치 전 클릭과 설치 후 앱을 결정적으로 연결할 수 있다. 링크 저장 API, resolve API, 만료와 중복 처리, 앱 라우팅을 직접 구현한다.
iOS: 자사 링크는 클립보드 토큰으로 직접 구현한다
iOS에는 Install Referrer에 해당하는 API가 없다. 대신 자사 랜딩 페이지라면 설치 버튼을 포함한 사용자 경험을 직접 통제할 수 있다. 사용자가 앱 설치하고 이어보기 버튼을 누를 때 임의의 clickToken을 클립보드에 복사하고 App Store로 이동시키는 방식을 선택했다.
1. 자사 링크 클릭
↓
2. 서버에 clickToken → 목적지 저장
↓
3. 사용자가 ‘앱 설치하고 이어보기’ 선택
clickToken을 클립보드에 복사
↓
4. App Store에서 앱 설치
↓
5. 첫 실행에서 클립보드 접근 허용
↓
6. SDK가 clickToken으로 서버 조회
↓
7. 목적지 복원 후 앱 라우터로 이동
클립보드 쓰기는 랜딩 페이지의 버튼 클릭처럼 명시적인 사용자 동작에서 실행한다. 앱의 첫 읽기에서는 iOS가 표시하는 클립보드 접근 요청과 거부 가능성을 UX에 포함해야 한다.
첫 실행 API는 다음과 같이 호출한다.
POST /v1/deferred-links/resolve
Content-Type: application/json
{
"platform": "ios",
"installationId": "new-installation-id",
"matchType": "clipboard_token",
"clickToken": "abc123"
}서버는 토큰의 만료 여부와 소비 여부를 확인하고, 허용된 앱 내부 경로만 반환한다.
{
"destination": "/products/42",
"matched": true,
"matchType": "clipboard_token"
}clickToken에는 사용자 개인정보나 실제 목적지를 넣지 않는다. 추측하기 어려운 임의 값으로 만들고, 짧은 TTL과 단일 소비 정책을 적용한다. installationId는 클릭 매칭이 아니라 동일 설치의 중복 요청을 막는 데 사용한다.
토큰이 없거나 권한을 거부하면 fallback한다
클립보드 토큰은 정확하지만 모든 사용자가 권한을 허용한다는 보장은 없다. 토큰이 없거나, 만료되었거나, 사용자가 접근을 거부하면 잘못된 클릭을 추정하지 않고 캠페인 랜딩 또는 홈으로 이동한다.
{
"destination": null,
"matched": false,
"fallback": "/campaign"
}토큰 있음 → 원래 목적지로 이동
토큰 없음 → 캠페인 랜딩으로 이동
클립보드 거부 → 캠페인 랜딩으로 이동
토큰 만료·소비됨 → 기본 화면으로 이동그렇다면 광고·SNS·검색 링크는 어떻게 할까?
외부 링크라도 자사 도메인의 랜딩 페이지를 거쳐 사용자가 설치 버튼을 누르게 할 수 있다면 같은 clickToken 방식을 적용할 수 있다. 이때 유입 채널은 달라도 서버가 저장하는 것은 clickToken → destination이라는 동일한 관계다.
반대로 링크가 자사 랜딩을 거치지 않고 App Store로 바로 이동한다면 설치 전후에 공유할 키가 없다. 이 경우 installationId, IP 주소와 기기 정보만으로 특정 클릭을 정확하게 복원할 수는 없다. 지문처럼 여러 신호를 조합해 사용자를 추적하는 방식도 직접 구현안에서 제외했다.
따라서 이 설계의 경계는 분명하다. 명시적인 키를 전달할 수 있는 유입은 직접 복원하고, 키를 전달할 수 없는 유입은 매칭 실패로 처리한다. 이것은 구현을 포기한 것이 아니라, 잘못된 사용자를 다른 목적지로 보내지 않기 위한 실패 정책이다.
완성한 직접 구현안
| 유입 경로 | 매칭 키 | 처리 |
|---|---|---|
| Android Google Play | Install Referrer의 clickId | 목적지 복원, 실패 시 fallback |
| iOS 자사 랜딩 링크 | 클립보드 clickToken | 목적지 복원, 거부·만료 시 fallback |
| iOS 외부 링크 | 자사 랜딩을 거치면 clickToken | 같은 방식으로 목적지 복원 |
| 공유 키 없는 iOS 유입 | 없음 | 추정하지 않고 fallback |
여기까지는 특정 솔루션을 전제로 하지 않고, 서버와 앱 SDK를 직접 만든다는 가정으로 완성한 아키텍처다.
구현할 때 먼저 정해야 했던 것들
아키텍처를 그린 뒤에는 다음 항목을 코드보다 먼저 결정해야 한다고 느꼈다.
- 목적지 모델
앱이 이해할 수 있는 경로와 파라미터를 하나의 규칙으로 만든다. - 매칭 키
Android는 Install Referrer를 사용하고, iOS는 서비스 특성에 맞는 명시적 매칭 방법을 결정한다. - 유효 시간
오래된 클릭이 갑자기 실행되지 않도록 TTL을 둔다. - 단일 소비와 멱등성
동일 링크가 여러 번 처리되어 결제나 쿠폰 같은 동작을 중복 실행하지 않게 한다. - 보안
외부 URL을 그대로 실행하지 않고 앱에서 허용한 route와 action만 처리한다. - 라우팅 시점
로그인, 온보딩, 권한 요청이 끝나기 전에 화면 이동이 실행되지 않도록 보류 큐를 둔다. - fallback
매칭이 실패해도 사용자가 막히지 않도록 홈이나 캠페인 랜딩을 제공한다. - 관측 가능성
클릭, 스토어 이동, 첫 실행, 매칭 결과, 실제 라우팅을 각각 로그로 남긴다.
특히 앱 내부 라우터는 직접 딥링크와 디퍼드 딥링크에서 공통으로 사용하는 것이 좋았다.
Universal Link ─┐
App Link ─┼─→ DeepLinkParser → RouteCommand → App Router
Deferred Link ─┘입력 채널마다 별도의 화면 이동 코드를 만들면 인증, 온보딩, 중복 실행과 cold start 처리에서 서로 다른 버그가 생기기 쉽다. 어떤 경로로 들어오더라도 최종적으로는 하나의 RouteCommand로 정규화하는 방식이 유지보수에 유리했다.
직접 설계를 마친 뒤, Airbridge와 비교해 봤다
Airbridge가 공개한 디퍼드 딥링크 흐름을 2023년에 처음 봤을 때는 솔직히 잘 이해하지 못했다. SDK가 서버에서 딥링크를 가져온다는 설명은 알겠는데, 왜 그렇게 많은 구성 요소가 필요한지는 체감되지 않았다.
이번에는 순서를 반대로 했다. 먼저 Airbridge 없이 “직접 구현한다면 어떻게 해야 할까?”라는 질문에서 출발해 링크 서버, 클릭 저장소, 플랫폼별 매칭 키, 첫 실행 SDK, resolve API, fallback과 앱 라우터까지 설계를 끝냈다.
그다음 Airbridge가 공개한 흐름을 다시 읽었다.
사용자가 Tracking Link 클릭
↓
서버에 클릭 정보 저장
↓
앱 설치
↓
SDK가 첫 실행 때 서버 확인
↓
저장된 딥링크를 SDK에 전달
↓
앱 내부 목적지로 이동
내가 설계한 흐름과 큰 틀이 거의 같았다. 클릭 정보를 저장하고, 설치 후 첫 실행에서 다시 조회하고, 복원한 목적지를 기존 앱 라우터로 전달한다는 생명주기가 일치했다.
2023년에는 이해하지 못했던 구조를 몇 년 뒤 스스로 고민한 끝에 비슷한 결과로 그려냈다. 이때 얼마나 뿌듯했는지 모른다. 정답을 먼저 보고 따라간 것이 아니라, 문제의 제약에서 출발해 같은 방향에 도달했다는 느낌이 들었다.
물론 “비슷하다”는 것이 “같은 제품을 만들었다”는 의미는 아니다.
| 구성 | 직접 설계 | Airbridge의 공개 흐름 |
|---|---|---|
| 링크 진입점 | 자체 링크·랜딩 페이지 | Tracking Link와 도메인 라우팅 |
| 클릭 정보 저장 | 직접 스키마와 TTL 설계 | 서비스에서 저장·관리 |
| 첫 실행 확인 | 자체 SDK 또는 앱 초기화 코드 | Airbridge SDK 콜백 |
| 클릭-설치 매칭 | Install Referrer·clickToken처럼 근거를 명시 | SDK와 서버의 매칭 계층 제공 |
| 매칭 실패 | matched: false와 fallback을 직접 정의 | 저장된 링크가 없으면 SDK 결과가 없을 수 있음 |
| 측정과 운영 | 로그와 관리 도구를 직접 개발 | 어트리뷰션과 테스트·분석 기능 포함 |
내 설계는 어떤 키로 클릭과 설치를 연결할 것인가를 플랫폼별로 명시하는 데 초점을 맞췄다. Airbridge가 제품으로 제공하는 범위는 그 생명주기에 채널별 매칭, SDK 초기화, 만료, 예외 처리, 어트리뷰션과 운영 도구를 더한 시스템에 가깝다.
또 공개 문서만으로 Airbridge 내부의 현재 매칭 알고리즘 전체를 알 수는 없다. 따라서 여기서는 외부에서 확인할 수 있는 아키텍처 흐름까지만 비교했다. 중요한 것은 Airbridge를 내 구현안의 답으로 넣는 것이 아니라, 직접 완성한 설계가 실제 제품의 공개 구조와 어디까지 닮았고 어디서 달라지는지 확인하는 일이었다.
결론: 앱 링크는 URL 설정이 아니라 문맥을 복원하는 아키텍처였다
2023년에는 플랫폼 문서를 따라 앱과 도메인을 연결했다. 2026년에는 링크 하나가 브라우저, 링크 서버, 앱스토어, SDK와 앱 라우터를 통과하는 전체 생명주기를 보게 되었다.
디퍼드 딥링크에서 서버를 만드는 것 자체는 어렵지 않았다. 진짜 문제는 설치 전 클릭과 설치 후 첫 실행을 정확하고 정책에 맞게 연결하는 것이었다.
- Android는 Install Referrer의
clickId로 직접 연결한다. - iOS는 자사 랜딩 페이지에서 클립보드
clickToken을 전달해 직접 연결한다. - 외부 링크도 자사 랜딩을 거친다면 동일한 토큰 구조를 사용할 수 있다.
- 설치 전후에 공유된 키가 없다면 사용자를 추정하지 않고 fallback한다.
결국 앱 링크는 URL을 앱으로 여는 설정 기능만이 아니었다.
끊어진 사용자 문맥을 어디까지, 어떤 근거로 복원할 것인가에 대한 아키텍처 문제였다.
결국 iOS에서도 디퍼드 딥링크를 직접 구현할 수 있었다. 단, 서버에 installationId만 보내는 방식으로는 부족했고, 설치 전후를 이어주는 명시적인 clickToken과 실패 정책이 함께 필요했다.
그리고 모든 설계를 마친 뒤 Airbridge의 공개 구조와 비교했을 때, 클릭 저장부터 첫 실행 복원과 앱 라우팅까지 큰 생명주기가 비슷하다는 것을 확인했다. Airbridge는 내가 채택한 구현 방법이 아니라, 직접 도달한 설계를 검증하고 차이를 살펴본 비교 대상이었다.
몇 년 전에는 이해하지 못했던 구조를 이제는 스스로 질문하고 설계해 비슷한 결론에 도달할 수 있게 되었다. 앱 링크를 다시 공부하며 얻은 가장 큰 결과는 특정 API의 사용법보다, 문제를 바라보는 시야가 달라졌다는 사실이었다.
참고 자료
'flutter' 카테고리의 다른 글
| Flutter vs React Native in 2026: 성능보다 중요한 선택 기준 (0) | 2026.08.14 |
|---|---|
| Flutter에서 백그라운드 위치 수집,어떤 방법을 골랐나 (0) | 2026.03.19 |
| Flutter WebView net::ERR_UNKNOWN_URL_SCHEME (0) | 2025.05.06 |
| flutter, js_interop 사용 후기 및 언제 사용할까 (0) | 2025.04.30 |
| infinity_scroll_shell 오픈소스 배포 과정 기록 (6) | 2024.09.18 |
댓글