앱 설치 유입경로 추적을 외부 솔루션 없이 직접 구현한 마케터의 실전기. 딥링크 구조 설계부터 백엔드 명세서 작성까지, AI를 활용해 개발팀에 업무를 배분한 전 과정을 공유합니다.

앱 광고의 블랙박스 — 클릭과 설치 사이에서 무슨 일이 벌어지는가

앱 광고를 집행할 때마다 한 가지가 늘 찝찝했다. 클릭은 되는데, 앱스토어로 넘어간 다음부터는 캄캄했다.

메타 광고 관리자에는 “앱 설치” 숫자가 찍힌다. 그런데 그 숫자가 어디서 온 건지, 어떤 소재가 실제 설치를 만들었는지, 앱 안에서는 확인할 방법이 없었다. 광고 → 클릭 → 앱스토어 → 설치. 이 흐름에서 “앱스토어”가 중간에 끼는 순간, 추적의 실이 끊긴다.

웹이라면 간단하다. UTM 파라미터를 붙여서 랜딩 페이지로 보내면 GA에서 바로 확인할 수 있다. 하지만 앱은 다르다. 앱스토어라는 제3자 플랫폼을 거치기 때문에, 클릭과 설치 사이의 연결고리를 직접 만들어줘야 한다.

이번에 그 블랙박스를 직접 열어봤다. AI를 활용해서.

앱 설치 유입경로 추적이란? — 전체 구조 한눈에 보기

앱 설치 유입경로 추적이란, 사용자가 어떤 경로(광고, SNS, 공유 링크 등)를 통해 앱을 설치했는지를 기술적으로 식별하고 기록하는 것을 말한다.

전체 흐름은 이렇다:

마케팅 링크 클릭 (UTM 파라미터 포함)
    ↓
딥링크 서버가 OS 판별
    ↓
├─ 앱 설치됨 → 앱이 바로 열림 (딥링크)
└─ 앱 미설치 → 스토어로 리다이렉트 (UTM 정보를 실어서)
    ↓
앱 설치 후 첫 실행
    ↓
앱이 UTM 정보를 읽어서 → Firebase/Mixpanel에 기록

핵심은 마케팅 링크에 붙인 UTM 파라미터가 앱스토어를 거쳐 앱까지 전달되는 파이프라인을 만드는 것이다. 이 파이프라인이 “딥링크 인프라”다.

iOS와 Android, 추적 방식이 다르다

같은 목적이지만 OS마다 기술 구현이 완전히 다르다. 이것이 앱 추적이 복잡한 핵심 이유다.

구분	iOS	Android
도메인 인증 방식	Apple App Site Association (AASA)	Digital Asset Links (assetlinks.json)
인증 파일 위치	/.well-known/apple-app-site-association	/.well-known/assetlinks.json
UTM 전달 방식	App Store 캠페인 토큰(ct 파라미터)	Install Referrer API (referrer 파라미터)
UTM 정밀도	캠페인 단위까지	소스/매체/캠페인/콘텐츠 전부 가능
필수 조건	HTTPS, 리다이렉트 불가, 직접 200 응답	HTTPS, 리다이렉트 불가, SHA256 인증서 필요

Android는 Install Referrer API를 통해 utm_source, utm_medium, utm_campaign, utm_content까지 전부 앱에 전달할 수 있다. iOS는 App Store의 ct(campaign token) 파라미터로 캠페인 단위까지만 추적이 가능하다.

직접 해보니 Android 쪽이 훨씬 정밀한 추적이 가능했다. iOS는 Apple의 개인정보 보호 정책 때문에 의도적으로 제한을 걸어둔 구조다.

왜 Adjust·AppsFlyer 없이 직접 구현했는가

대부분의 앱 설치 추적 가이드는 “MMP(Mobile Measurement Partner)를 도입하세요”로 끝난다. Adjust, AppsFlyer, Branch — 이런 솔루션을 쓰면 확실히 편하다.

하지만 현실은 이렇다:

• 비용: MMP는 월 수십만 원에서 수백만 원이다. 초기 스타트업에게는 부담이다.
• 타이밍: 솔루션 도입 → 검토 → 계약 → 연동까지 최소 2~4주. 광고 집행은 다음 주부터인데.
• 검증 필요: 유료 솔루션이 정말 필요한지, 자체 추적으로 충분한지 먼저 확인하고 싶었다.

우리 팀의 판단은 명확했다. 광고 집행 전까지 최소한의 추적 인프라를 직접 만들자. 데이터가 쌓이고, 규모가 커지면 그때 MMP를 도입해도 늦지 않다.

실전 — AI와 함께 딥링크 인프라를 설계한 과정

마케터가 딥링크 인프라를 설계한다고 하면 의아할 수 있다. 나도 처음엔 “이건 개발자 영역 아닌가?”라고 생각했다. 하지만 AI를 활용하면 얘기가 달라진다.

Step 1. 문제 정의 — “우리가 추적해야 할 것”을 정리

가장 먼저 한 일은 기술이 아니라 질문을 정리하는 것이었다.

• 메타 광고에서 앱 설치 캠페인을 돌리면, 어떤 소재가 실제 설치를 만들었는지 앱에서 알 수 있는가?
• 카카오톡으로 공유한 링크에서 들어온 설치와, 인스타 광고에서 들어온 설치를 구분할 수 있는가?
• 이 정보를 우리가 쓰는 분석 도구(Firebase, Mixpanel)에서 볼 수 있는가?

답은 전부 “지금은 안 된다”였다. 이 세 가지를 “된다”로 바꾸는 것이 프로젝트의 목표가 됐다.

Step 2. 기술 구조 파악 — AI에게 딥링크 원리를 물어본 과정

Claude에게 이렇게 물었다:

“앱 광고를 클릭하면 앱스토어로 넘어가잖아. 그러면 최종적으로 앱을 설치한 사람이 어떤 광고를 보고 왔는지를 앱 내에서 어떻게 알 수 있어?”

30분 만에 전체 구조가 그려졌다. 핵심은 세 가지였다:

1. 도메인 인증 파일: iOS와 Android에게 “이 도메인은 우리 앱과 연결되어 있다”고 알려주는 JSON 파일
2. 리다이렉트 서버: 앱이 미설치된 유저를 OS에 맞는 스토어로 보내주는 엔드포인트
3. 앱 내 UTM 수신: 설치 후 앱이 첫 실행될 때 UTM 파라미터를 읽어서 분석 도구에 기록

비유하자면, 구글 서치콘솔에서 사이트 소유권을 확인할 때 HTML 파일을 서버에 올리는 것과 같은 개념이었다. 이렇게 익숙한 것에 빗대어 이해하니 금방 감이 잡혔다.

Step 3. 백엔드 명세서 작성 — 개발자에게 넘길 문서 만들기

구조를 이해한 다음 문제는 이걸 개발자에게 어떻게 전달하느냐였다. “딥링크 좀 만들어주세요”라고 하면 돌아오는 질문이 10개다.

AI와 함께 백엔드 개발자가 바로 작업에 들어갈 수 있는 수준의 명세서를 만들었다. 포함한 내용은:

• 정확히 어떤 파일을, 어떤 경로에, 어떤 내용으로 배포해야 하는지
• 검증 방법 (curl 명령어까지)
• 리다이렉트 로직의 구현 코드 (Express.js 기준)
• 앱 개발팀에서 제공해야 하는 값 체크리스트

마케터가 명세서를 쓰면 생기는 장점이 있다. 개발자가 “왜 이걸 해야 하는지” 묻지 않는다. 비즈니스 맥락이 문서에 이미 담겨 있기 때문이다.

Step 4. 앱 코드 작성 — Install Referrer + UTM 파싱 구현

백엔드 명세서만 쓴 게 아니다. 앱에서 UTM 정보를 수신하고 분석 도구에 기록하는 코드도 AI와 함께 작성했다.

핵심 로직은 이렇다:

1. 앱 첫 실행 감지: AsyncStorage로 “이미 추적했는지” 체크 (1회만 실행)
2. UTM 읽기: Android는 Install Referrer API, iOS는 딥링크 URL에서 파싱
3. 분석 도구에 기록: Firebase user properties + Mixpanel super properties로 영구 태깅
4. 이벤트 발송: 앱_설치_소스 (Mixpanel) / app_install_source (Firebase) 이벤트 로깅

// 추적 흐름 요약
앱 첫 실행
  → 이미 추적했는지 확인 (AsyncStorage)
  → Android: Install Referrer API에서 UTM 읽기
  → iOS: 딥링크 URL에서 UTM 파싱
  → Firebase user property에 install_source 저장
  → Mixpanel super property에 install_source 저장
  → "추적 완료" 플래그 저장

이렇게 세팅하면 이후 해당 유저가 발생시키는 모든 이벤트에 설치 소스가 자동으로 붙는다. Mixpanel에서 “페이스북 광고로 들어온 유저의 구독 등록 전환율”을 바로 볼 수 있게 되는 것이다.

마케터가 만든 백엔드 명세서, 이렇게 생겼다

실제로 작성해서 개발자에게 전달한 명세서의 구조를 공개한다. 총 3가지 작업으로 나눠서 전달했다.

작업	내용	난이도
작업 1	iOS 인증 파일 배포 (AASA)	낮음 — JSON 파일 하나를 특정 경로에 올리는 것
작업 2	Android 인증 파일 배포 (Digital Asset Links)	낮음 — JSON 파일 배포 + SHA256 인증서 확인
작업 3	/link 리다이렉트 엔드포인트 구현	중간 — User-Agent로 OS 판별 후 스토어로 리다이렉트하는 API

명세서에 포함한 핵심 항목들:

• 배포 위치와 파일 내용: 복사-붙여넣기 수준으로 구체적으로
• 필수 조건 표: HTTPS 필수, 리다이렉트 불가 등 실수하기 쉬운 조건을 표로 정리
• 검증 방법: curl -I https://도메인/.well-known/apple-app-site-association — 개발자가 배포 후 바로 확인할 수 있도록
• 최종 URL 예시: 요청 → 응답이 어떤 형태인지 실제 예시로 보여줌
• 앱 개발팀 제공 값 체크리스트: 누가 무엇을 확인해야 하는지 명확하게

명세서 작성의 핵심 원칙은 “개발자가 나에게 질문하지 않아도 되는 수준”이었다. 배경 설명, 구현 코드, 검증 방법, 체크리스트까지 한 문서에 담으면 커뮤니케이션 비용이 확 줄어든다.

이 방식의 한계와 유료 솔루션이 필요한 시점

직접 구현이 만능은 아니다. 규모와 정밀도에 따라 MMP가 필요한 시점이 온다.

구분	직접 구현	MMP (Adjust, AppsFlyer 등)
비용	무료 (개발 리소스만)	월 수십만~수백만 원
세팅 시간	1~2주 (백엔드 배포 포함)	2~4주 (계약 + SDK 연동)
iOS 추적 정밀도	캠페인 단위	SKAN 연동으로 더 정밀
리타겟팅 추적	불가	가능
프로드 탐지	없음	내장
멀티채널 어트리뷰션	수동 분석 필요	자동
적합한 단계	월 광고비 500만 원 이하, 초기 검증	월 광고비 1,000만 원 이상, 스케일업

전환 시점의 신호:

• 광고 채널이 3개 이상으로 늘어날 때
• iOS 추적 정밀도가 의사결정에 영향을 줄 때
• 광고 프로드(허위 설치)가 의심될 때
• 리타겟팅 캠페인을 본격적으로 돌릴 때

직접 구현은 “추적의 원리를 이해하고, 최소한의 데이터를 모으는 단계”에 적합하다. 이 단계를 거치면 MMP를 도입할 때도 무엇을 왜 추적하는지 명확하게 알고 시작할 수 있다.

FAQ — 앱 설치 유입경로 추적에 대해 자주 묻는 질문

마무리 — 마케터가 기술을 이해하면 생기는 일

이번 작업을 하면서 가장 크게 달라진 건 개발자와의 대화다.

예전에는 “이거 추적 되게 해주세요”라고만 했다. 돌아오는 건 “어떤 방식으로요?”, “어떤 이벤트를요?”, “어떤 도구에요?” 같은 역질문이었다. 지금은 “AASA 파일 배포하고, /link 엔드포인트에서 User-Agent로 OS 판별해서 referrer 파라미터 실어서 리다이렉트 해주세요. 명세서 보내드렸습니다”라고 말한다.

마케터가 기술을 “사용”할 줄 알 필요는 없다. 하지만 기술이 어떤 구조로 돌아가는지 이해하면, 문제 정의가 정확해지고, 개발자에게 넘기는 업무의 품질이 달라진다. AI는 그 이해의 속도를 극적으로 높여준다.

앱 설치 유입경로 추적은 앱 마케팅의 기본 중 기본이다. 하지만 “기본”이 늘 “쉬운” 건 아니었다. 이번에 직접 해보면서 비로소 기본이 내 것이 됐다.