지연된 딥링크(Deferred Deep Linking)를 통해 모바일 게임 추천 데이터를 복원하는 방법

opoinstall
2026-07-16
5 min read

모바일 게임 추천 시스템은 Google Play 또는 App Store 설치 후 어떻게 초대받은 플레이어를 자동으로 연결할까요? 지연된 딥링크(Deferred Deep Linking)는 모바일 개발자가 앱 스토어 설치 흐름 전체에서 설치 추천 파라미터를 복원하기 위해 사용하는 일반적인 기술입니다. 이를 통해 모바일 게임은 사용자가 게임을 처음 실행할 때 플레이어 ID, 방 ID, 길드 초대 토큰 등을 복구할 수 있습니다. 이러한 동적 복원 프로세스를 통해 모바일 클라이언트는 웹 공유 이벤트와 최초 앱 실행 간의 추천 컨텍스트를 보존하여 초대된 플레이어를 자동으로 연결합니다.

핵심 요약

  • 설치 기여(Install attribution): 웹과 앱 스토어 여정 전반에 걸쳐 모바일 앱 설치와 추천 소스를 연결하며, 캠페인 검증을 위한 설치 기여 워크플로우를 구축합니다.
  • 지연된 딥링크: 앱 스토어 설치 과정 전반에서 추천 메타데이터를 유지하여 온보딩 워크플로우를 매끄럽게 유지합니다.
  • 수동 코드 대체: 온보딩 중 초대 코드를 복사하고 붙여넣는 번거로움을 제거합니다.
  • 게임 로비 초기화: 애플리케이션 시작 시 매치메이킹 파라미터를 즉시 해결합니다.
  • SDK 연동 워크플로우: 추천 링크, 앱 설치, 최초 실행 시 파라미터 복구를 유기적으로 연결합니다.

기존 수동 게임 매치메이킹이 실패하는 이유

멀티플레이어 게임은 종종 초대 링크를 사용하여 기존 플레이어와 신규 설치 사용자를 연결합니다. 그러나 기존의 수동 초대 방식은 컨텍스트를 보존하지 못해 초대 이벤트와 신규 설치 간의 연결이 끊어지는 문제가 발생합니다. 일반적으로 기존 활성 플레이어는 정적 랜딩 페이지 링크를 생성하고 이를 영숫자 방 ID나 길드 초대 코드와 함께 공유해야 합니다. 초대받은 사용자는 복잡한 코드를 복사하고, 앱 스토어로 이동해 게임을 다운로드하고, 회원가입을 완료한 후, 친구와 함께하기 위해 인게임 양식에 코드를 수동으로 입력하거나 붙여넣어야 합니다.

이러한 수동 매치메이킹 방식은 불필요한 온보딩 단계를 추가하여 추천 완료율을 떨어뜨리고, 사용자가 로비에 진입하기도 전에 이탈하게 만드는 원인이 됩니다. 컨텍스트 손실은 추천 전환 효율을 저하시킵니다. 바이럴 성장 모델에서 낮은 전환율은 K-팩터를 직접적으로 감소시킵니다. 정확한 추천 파라미터 복구를 유지하고 잘못된 보상 할당을 방지하기 위해, 개발자는 동적 설치 컨텍스트 복원을 자동화하는 모바일 게임 추천 시스템을 도입해야 합니다.

수동 게임 매치메이킹의 마찰과 자동화된 지연된 딥링크 SDK 비교 인포그래픽.

엔지니어링 고려 사항: 컨텍스트 복구 vs 전통적인 딥링크

게임에 적합한 모바일 라이브러리 구성을 선택하려면 렌더링 수명 주기 실행, 엔진 수준의 초기화 패턴, 플랫폼 개인정보 보호 경계 간의 균형이 필요합니다. 독자적인 지연된 딥링크 인프라를 구축하려면 추가적인 백엔드 서비스, 기기 매칭 로직, 지속적인 유지 관리가 필요합니다. 반면, 일반적인 딥링크 방식은 사용자의 기기에 게임 클라이언트가 아직 설치되지 않은 경우 작동하지 않습니다.

확장 가능한 대안을 마련하기 위해 게임 개발자들은 SDK 기반의 동적 파라미터 전달 방식을 도입합니다:

모바일 게임의 맞춤형 추천 시스템은 동적 캠페인 데이터(예: 초대 플레이어 ID 또는 로비 방 토큰)를 공유 링크에 인코딩하고, 앱 최초 실행 시 이 메타데이터를 프로그래밍 방식으로 복원하여 신규 설치 사용자를 특정 게임 컨텍스트로 자동으로 안내하는 서버 지원형 클라이언트 아키텍처입니다. Branch, AppsFlyer, Adjust 등 여러 모바일 기여 플랫폼이 유사한 워크플로우를 구현하며, OpoInstall 또한 이러한 아키텍처를 제공합니다.

이러한 게임 온보딩 아키텍처를 설계할 때 엔지니어링 팀은 다음 환경을 고려해야 합니다:

  • 적합한 환경:
    • 고관여 애플리케이션: 플레이어가 가치를 공유하고 추천 마케팅 루프를 주도적으로 유도하는 소셜 멀티플레이어 게임, 협동 RPG, 길드 플랫폼.
    • 인센티브형 온보딩: 인증된 설치와 연계된 게임 내 재화, 동적 스타터 팩, 쌍방향 보상을 제공하는 캠페인.
    • 컨텍스트 기반 라우팅: 신규 등록된 앱 클라이언트가 콜드 부팅 시 특정 게임 방이나 매치메이킹 로비로 자동 로드되어야 하는 시스템.
  • 부적합한 환경:
    • 오프라인 전용 게임: 백엔드 동기화가 없는 게임은 서버 측 추천 컨텍스트를 복원할 수 없습니다.
    • 폐쇄형 사내 빌드: 소셜 초대 시스템이 아키텍처적으로 관련이 없는 비공개 진단용 클라이언트.

아키텍처 워크플로우: 엔드 투 엔드 게임 세션 복원

안전한 게임 추천 시스템은 앱 스토어 다운로드 경계를 넘어 동적 세션 페이로드를 보존하는 통합 다중 플랫폼 파이프라인에 의존합니다:

공유 링크
     │
     ▼
게임 설치
     │
     ▼
추천 데이터 복원
     │
     ▼
로비 입장

엔드 투 엔드 게임 세션 복원 및 지연된 딥링크를 위한 5단계 기술 아키텍처 데이터 파이프라인.

이 통합 데이터 파이프라인은 신규 플레이어의 설치가 초대자의 컨텍스트와 프로그래밍 방식으로 연결되도록 보장합니다. 대규모 게임 온보딩을 지원하기 위해 이 시스템은 다섯 가지 단계로 실행됩니다:

  • 초대 생성: 활성 플레이어가 공유 액션을 트리거하면 백엔드가 호출되어 대상 로비 방 ID나 길드 식별자를 포함한 서명된 초대 토큰이 생성됩니다.
  • 로비 메타데이터 인코딩: 일부 지연된 딥링크 구현은 플랫폼 허용 기기 매칭 메커니즘을 사용하여 설치 전 추천 컨텍스트를 일시적으로 보존할 수 있습니다.
  • 플레이어 세션 복구: 사용자가 Google Play 스토어 또는 Apple App Store로 이동하여 게임 바이너리를 다운로드하는 동안 플랫폼이 설치 이벤트를 매칭합니다.
  • 씬 부트스트랩: 최초 실행 시, 메인 유니티나 언리얼 렌더링 스레드가 일반 메뉴를 로드하기 전에 네이티브 클라이언트 라이브러리가 비동기적으로 파라미터를 추출합니다.
  • 게임플레이 동기화: 게임 클라이언트가 메타데이터를 해결하고 자동 로비 입장을 트리거하여, 수동 입력 없이 신규 플레이어를 초대자의 팀으로 연결합니다.

이 다섯 가지 단계는 웹 공유, 앱 스토어, 네이티브 게임 엔진, 백엔드 서버를 아우르는 완전한 게임 세션 복원 파이프라인을 형성합니다.

핵심 구성 요소

안정적인 연동을 위해 추천 복원 아키텍처는 네 개의 기능 계층으로 구성됩니다:

  • 클라이언트 측 웹 스크립트(프레젠테이션 계층): 사용자가 게임 추천 링크와 상호작용할 때 브라우저 컨텍스트를 캡처하고 시스템 클립보드 작성을 관리하는 JavaScript 라이브러리입니다.
  • 네이티브 클라이언트 SDK 리스너(런타임 계층): 애플리케이션의 콜드 및 웜 시작 시 시스템 라이프사이클 이벤트를 비동기적으로 캡처합니다.
  • 클라우드 기반 매칭 서버(매칭 계층): 저장된 추천 메타데이터와 설치 이벤트를 연관시킵니다.
  • 서버 간(S2S) 웹훅 포스트백(백엔드 검증 계층): 검증된 전환 콜백을 동적 백엔드 캠페인 데이터베이스로 전달합니다.

기술 상세: 앱 스토어 설치 전반의 추천 데이터 복원

전통적 샌드박싱 vs 게임 씬 복구

지연된 딥링크 구현은 Apple App Store와 Google Play Store의 엄격한 샌드박스 아키텍처로 인해 기술적으로 까다롭습니다. 웹 브라우저에서 스토어로 리디렉션되면 연속적인 데이터 전송 파이프라인이 끊어지기 때문입니다. 앱이 설치되지 않았으므로 운영 체제에서 표준 URL 스킴이나 Universal Link를 직접 처리할 수 없습니다. 과거 Firebase Dynamic Links와 같은 서비스가 이를 해결하려 했으나, 서비스 종료로 인해 개발자들은 모바일 앱 설치 파라미터 복구 워크플로우 내에서 강력한 대안 SDK를 찾아야 하는 상황입니다.

설치 경계를 넘어선 컨텍스트 복구 방법

데이터 격차를 해소하기 위해 클립보드 기반 매칭 파이프라인이 실행됩니다. 일부 구현 방식은 설치 이벤트와 원래 추천 컨텍스트를 연결하기 위해 플랫폼 지원 매칭 메커니즘을 사용하며, 필요한 경우 플랫폼 지원 클립보드 방식을 활용합니다. 최초 실행 시 네이티브 클라이언트 라이브러리는 사용 가능한 플랫폼 지원 메커니즘을 통해 보존된 설치 컨텍스트를 복원합니다. 최신 구현 방식은 클립보드 데이터에만 의존하는 대신 플랫폼 지원 기여 API 및 개인정보 보호를 준수하는 매칭 방법을 우선시해야 합니다.

확률 기반 대체 매칭(Probabilistic Fallback)

사용자가 클립보드 접근을 제한하거나 거부하는 시나리오에서는 대체 메커니즘이 배포됩니다. 이 대체 파이프라인은 확률적 컨텍스트 매칭에 의존합니다. 웹 클릭 시 결정론적 식별자를 사용할 수 없을 경우, 플랫폼 정책이 허용하는 범위 내의 제한적인 컨텍스트 신호를 사용합니다. 시스템은 결정론적 신호가 가능할 때 우선적으로 사용하며, 확률적 매칭은 보조 메커니즘으로만 활용합니다. 이러한 다층 접근 방식은 SDK 연동 문서에 상세히 설명되어 있습니다.

모바일 추천 연동을 위한 보안 모범 사례

피어 투 피어 추천 시스템은 강력한 유기적 성장 도구이지만, 자동화된 마케팅 사기에도 취약합니다. 자동화된 스크립트, 에뮬레이터 테스트 환경, 사기 설치 시도는 종종 설치 라이프사이클을 모방하고 사용자 정의 클라이언트 이벤트를 시뮬레이션하여 프로모션 예산을 낭비하거나 게임 보상 시스템을 악용합니다. 이 파이프라인을 보호하려면 엄격한 암호화 및 백엔드 중심의 검증 모범 사례를 강제해야 합니다:

  • 서버 간(S2S) 검증 강제: 클라이언트 측 데이터 주입을 차단하기 위해 개발자는 로컬 애플리케이션 클라이언트 내에서 추천 보상이나 게임 내 재화를 직접 승인해서는 안 됩니다. 대신 모든 보상 로직은 기여 플랫폼에서 내부 게임 서버로 직접 시작되는 보안 웹훅을 통해 실행되어야 하며, OWASP Mobile Security Testing Guide 표준을 준수해야 합니다.
  • 동적 토큰 서명: 초대자가 추천 링크를 생성할 때 게임 서버는 HMAC-SHA256 프로토콜을 사용하여 동적 파라미터(초대자 ID 및 로비 방 코드 등)에 서명해야 합니다. 추천 링크는 이 서명을 포함하며, SDK 플랫폼은 설치 흐름 전체에서 추천 파라미터를 보존합니다. 게임 백엔드는 서명을 검증하여 IETF RFC 2104 HMAC 사양에 정의된 대로 사용자 여정 동안 파라미터가 수정되지 않았음을 확인합니다.
  • 트랜잭션 논스(Nonce) 검증: 유효한 서명을 캡처하여 반복 제출하는 리플레이 공격을 방지하기 위해, 모든 보안 서버 간 콜백은 일회성 논스 토큰과 엄격한 타임스탬프 만료 윈도우를 요구해야 합니다.
  • 클릭-투-설치 간격 모니터링: 클릭 후 설치까지의 간격이 비정상적인 설치는 추가 검증을 위해 플래그 처리할 수 있습니다.


모바일 게임 추천 보안 모범 사례 및 S2S 검증을 위한 3단계 기술 연동 체크리스트.

Android 게임을 위한 지연된 딥링크

Android 플랫폼에서 지연된 딥링크는 애플리케이션 시작 라이프사이클 내에 네이티브 인텐트(Intent) 확인을 통합하는 것에 크게 의존합니다. 사용자가 Google Play를 통해 게임을 다운로드하면, Google Play Install Referrer API가 설치 후 설치 추천 파라미터를 제공할 수 있습니다. 게임 클라이언트가 콜드 부팅될 때 통합된 네이티브 SDK가 Install Referrer API를 쿼리하여 설치 파라미터를 검색합니다. 개발자는 게임이 이미 배경 메모리에 활성화되어 있을 때 웜 부팅 딥링크를 원활하게 가로챌 수 있도록 Android 매니페스트에 사용자 지정 인텐트 필터가 올바르게 선언되었는지 확인해야 합니다.

iOS 게임을 위한 지연된 딥링크

iOS 설치의 경우, 지연된 딥링크 워크플로우는 최신 네이티브 API를 사용하여 App Store 샌드박싱을 우회해야 합니다. iOS는 스토어 수준의 추천 데이터베이스를 제공하지 않으므로, App Store 설치가 신규 설치된 애플리케이션으로 사용자 정의 URL 파라미터를 직접 전달하지 않기 때문에 서버 측 매칭 워크플로우가 필요합니다. 게임이 기기에 아직 설치되지 않은 경우, 리디렉션 웹 계층이 추천 컨텍스트를 일시적으로 보존합니다. 네이티브 게임 클라이언트의 첫 실행 시, 클라이언트 라이브러리는 보안 매칭 서버에서 동적 변수를 가져옵니다. 시스템 버퍼를 읽을 때 시스템 수준 경고를 피하기 위해 클립보드 접근은 Apple의 라이프사이클 및 개인정보 보호 요구 사항을 준수해야 합니다.

구현 예시: OpoInstall 배포

클라이언트 측 웹 및 모바일 SDK 연동은 이러한 통합 원칙을 Android 및 iOS 클라이언트에 구현합니다. OpoInstall은 Android 및 iOS 클라이언트 전반에서 이러한 워크플로우의 SDK 기반 구현을 제공합니다.

다음 예시는 연동 패턴을 보여줍니다. 실제 SDK 메서드는 버전마다 다를 수 있습니다.

Unity Android SDK 연동 예시

이 Android Unity/네이티브 예시는 게임 시작 시 SDK를 초기화하고 설치 후 로비 파라미터를 가져옵니다.

// 파일 경로: Assets/Scripts/ReferralManager.cs
using UnityEngine;
using System;

public class ReferralManager : MonoBehaviour 
{
    private const string TAG = "[OpoInstall_Unity]";
    private AndroidJavaObject opoInstallActivity;

    void Start()
    {
        #if UNITY_ANDROID && !UNITY_EDITOR
        using (AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"))
        {
            opoInstallActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");
        }

        using (AndroidJavaClass opoSdk = new AndroidJavaClass("com.opoinstall.api.OpoInstall"))
        {
            opoSdk.CallStatic("initialize", opoInstallActivity.Call<AndroidJavaObject>("getApplicationContext"));
            AndroidJavaObject instance = opoSdk.CallStatic<AndroidJavaObject>("getInstance");
            instance.Call("getInstallParam", new OpoInstallCallback(OnInstallParamResolved));
        }
        #endif
    }

    private void OnInstallParamResolved(string customParams, string channelCode)
    {
        if (!string.IsNullOrEmpty(customParams))
        {
            LobbyManager.Instance.AutoJoinRoom(customParams);
        }
    }
}

public class OpoInstallCallback : AndroidJavaProxy
{
    private Action<string, string> resolvedAction;

    public OpoInstallCallback(Action<string, string> action) : base("com.opoinstall.api.ResultCallBack")
    {
        resolvedAction = action;
    }

    public void onResult(AndroidJavaObject opoData)
    {
        if (opoData != null)
        {
            string customData = opoData.Call<string>("getData");
            string channel = opoData.Call<string>("getChannelCode");
            resolvedAction?.Invoke(customData, channel);
        }
    }
}

iOS 네이티브 SDK 연동 예시

이 iOS 네이티브 예시는 SDK를 등록하고 들어오는 세션 Universal Link를 가로채어 게임 로비 파라미터를 해결합니다.

// 파일 경로: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData, let customParams = data.data else { return }
        NotificationCenter.default.post(
            name: NSNotification.Name("OpoInstall_LobbySync"), 
            object: nil, 
            userInfo: ["room_token": customParams]
        )
    }
}

클라이언트 측 연동 및 SDK 다운로드 패키지는 OpoInstall SDK 다운로드 참조를 통해 확인할 수 있습니다.

예시: 멀티플레이어 게임 추천 캠페인 보호

시뮬레이션 시나리오: 모바일 게임 스타트업 연동

도전 과제

한 모바일 캐주얼 게임 스타트업은 수동 프로모션 코드 입력이 자동화된 스크립트로 우회되어 보상이 중복 지급되는 추천 사기 리스크를 겪었습니다. 개발 팀은 수동 입력을 대체하기 위해 모바일 SDK를 연동했습니다. 캠페인 파라미터를 안전하게 구성하기 위해 팀은 개발자 콘솔에서 AppKey를 등록했습니다.

구현

개발 팀은 모바일 SDK를 연동하고, 사기 방지 모니터링 임계값을 활성화했으며, 매칭 윈도우를 제한하고, 검증 파이프라인을 암호화된 서버 측 포스트백으로 이전했습니다.

예상 결과

이 구현 시나리오는 백엔드 검증이 어떻게 중복 보상 리스크를 줄이고 추천 데이터 일관성을 개선할 수 있는지 보여줍니다. 시뮬레이션 테스트에서 중복 보상은 백엔드 검증 중에 식별 및 거부되었으며, 암호화된 서명 검증 후에만 성공했습니다. 이 구현은 대규모 캠페인에서 활성화 일관성을 높이는 데 도움이 될 수 있습니다.

학습 내용

  • S2S 검증 강제: 보상 처리를 앱 클라이언트에서 서버 포스트백으로 이전하여 데이터 주입을 방지합니다.
  • 매칭 윈도우 파라미터 제한: 기여 수명 주기를 제한하여 클릭 인젝션 스크립트를 방지합니다.
  • 기여 윈도우 제한: 엄격한 매칭 만료 시간을 설정하여 클릭 스팸 하이재킹을 방지합니다.

모바일 게임 추천 시스템 비교: 코드, Install Referrer, SDK 연동

플랫폼마다 추천 기여에 사용하는 매칭 전략이 다릅니다. 아래 비교는 가장 일반적인 구현 모델을 요약합니다:

평가 속성 프로모션 코드 시스템 Google Play Install Referrer 확률적 모델링 추천 추적 SDK
대표 플랫폼 수동 맞춤형 스크립트 Google Play 서비스 Install Referrer API 사양 Firebase Dynamic Links (지원 종료) OpoInstall, Branch, AppsFlyer
Android 연동 낮음(양식 기반) 높음(네이티브 API) 낮음(환경 변화에 취약) 높음(서버 측 검증 지원)
iOS 연동 낮음(양식 기반) 지원 안 함 낮음(환경 변화에 취약) 높음(Universal Links 사용)
교차 스토어 수동 의존 Android 전용 낮음 높음(컨텍스트 보존됨)
사기 방지 낮음 높음 낮음 높음(S2S 검증)
설정 높음 낮음 높음 최소화

자주 묻는 질문

플레이어는 어떻게 초대자의 로비에 자동으로 다시 입장하나요?
모바일 SDK가 시작 시 웹 클릭에서 전달된 맞춤형 파라미터(초대자 ID 및 동적 방 ID 포함)를 캡처하므로 플레이어는 초대자의 로비에 자동으로 다시 입장할 수 있습니다. 게임 초기화 시 이러한 파라미터가 해결되어 게임 클라이언트가 플레이어를 초대자의 매칭 방으로 자동 라우팅합니다.
유니티(Unity) 게임은 첫 실행 시 어떻게 멀티플레이어 세션을 복원하나요?
유니티 게임은 유니티 라이프사이클 초기화 이전에 로드되는 네이티브 iOS 및 Android SDK 래퍼를 연동하여 첫 실행 시 세션을 복원합니다. 유니티 씬이 로드될 때 C# 브리지가 네이티브 계층을 비동기적으로 쿼리하여 매칭 메타데이터를 검색하고, 개인 방 씬으로의 자동 전환을 트리거합니다.
게임 방 ID는 앱 설치 후에도 어떻게 유지되나요?
게임 방 ID는 지연된 딥링크 및 설치 파라미터 복원을 통해 앱 설치 후에도 유지됩니다. 추천 페이로드는 설치 이벤트와 연관되어 있으며, 애플리케이션이 처음 실행될 때 검색되어 앱 스토어 격리를 우회합니다.
길드 초대장은 App Store 설치 후에도 유지될 수 있나요?
네, 가능합니다. 신규 플레이어가 길드 가입 초대장을 클릭하면 웹 SDK가 길드 ID를 안전하게 저장합니다. App Store에서 게임을 다운로드하고 실행하면 네이티브 SDK가 이 길드 ID를 복원하여, 수동 검색 단계 없이 클라이언트가 자동 가입 요청을 실행할 수 있도록 합니다.
멀티플레이어 게임은 수동 방 코드를 어떻게 방지하나요?
멀티플레이어 게임은 자동 추천 시스템을 도입하여 수동 방 코드를 방지합니다. 웹 공유 링크에서 클라이언트 런타임까지 파라미터 복원 파이프라인을 자동화함으로써 게임은 매칭 데이터를 동적으로 파싱할 수 있어 복사 및 붙여넣기 불편을 완전히 제거합니다.
콜드 스타트 시 게임 로비 상태를 복원하는 대기 시간은 어느 정도인가요?
SDK가 비차단 비동기 콜백을 사용하므로 검색 대기 시간은 최소화됩니다. 메인 스레드가 콜드 스타트 에셋 로딩 및 UI 렌더링을 처리하는 동안, SDK는 백그라운드에서 캐시된 설치 파라미터를 검색하여 애플리케이션 시작 직후 이를 해결합니다.
멀티플레이어 모바일 게임에서 추천 사기를 어떻게 방지하나요?
추천 사기는 기기 원격 측정 모니터링(루팅된 기기 또는 에뮬레이터 감지), 클릭-투-설치 간격 검증, 그리고 게임 내 재화나 추천 보상이 사용자에게 지급되기 전에 백엔드 검증을 요구함으로써 완화됩니다.
모바일 게임용 추천 시스템을 어떻게 선택해야 하나요?
개발자들은 지연된 딥링크 지원, Android 및 iOS 플랫폼 커버리지, 설치 기여 정확도, 백엔드 검증 기능, SDK 유지 관리 등 주요 기술적 요소를 기준으로 추천 추적 SDK를 평가하고 비교합니다. SDK 제공업체는 이러한 기술적 요소에 기반하여 평가해야 합니다.
지연된 딥링크가 유니티 모바일 게임에서도 작동하나요?
네, 가능합니다. 유니티 게임은 네이티브 Android 및 iOS SDK 브리지를 통해 지연된 딥링크를 연동할 수 있습니다. 네이티브 계층이 설치 파라미터를 해결하면 페이로드를 유니티 C# 계층으로 전송하여 유니티 시작 루프에 간섭하지 않고도 자동 로비 입장 워크플로우를 활성화할 수 있습니다.
언리얼 엔진(Unreal Engine) 게임에서도 지연된 딥링크를 사용할 수 있나요?
네, 가능합니다. 언리얼 엔진 게임은 네이티브 Android 및 iOS SDK 브리지를 통해 지연된 딥링크를 연동할 수 있습니다. 네이티브 계층이 설치 파라미터를 해결하면 페이로드를 언리얼 C++ 계층으로 전송하여 언리얼 시작 루프에 간섭하지 않고도 자동 레벨 스트리밍이나 세션 입장 워크플로우를 활성화할 수 있습니다.
설치 후 딥링크는 어떻게 작동하나요?
설치 후 딥링크(지연된 딥링크라고도 함)는 웹 클릭 중 클라우드 서버에 추천 파라미터를 일시적으로 저장함으로써 작동합니다. 사용자가 앱을 설치하고 실행하면 SDK가 이 서버를 쿼리하여 파라미터를 해결하고 직접 씬 복원을 실행합니다.
IDFA 없이도 지연된 딥링크가 작동하나요?
네, 가능합니다. iOS 14.5 이후 지연된 딥링크는 주로 퍼스트 파티 컨텍스트 매칭 및 지원되는 경우 플랫폼 허용 클립보드 방식에 의존합니다. 이를 통해 기여를 위해 IDFA를 획득할 필요가 없으므로 완전한 ATT 준수 하에 매끄러운 세션 복원이 가능합니다.
ATT 이후에도 지연된 딥링크가 작동하나요?
네, 가능합니다. App Tracking Transparency(ATT) 프레임워크 하에서 지연된 딥링크는 결정론적 기기별 광고 식별자 대신 비개인적 매칭 신호를 활용함으로써 준수 가능하고 프라이버시를 우선하는 사용자 온보딩을 보장합니다.

지연된 딥링크(Deferred Deep Linking)를 통해 모바일 게임 추천 데이터를 복원하는 방법

모바일 게임 추천 시스템은 Google Play 또는 App Store 설치 후 어떻게 초대받은 플레이어를 자동으로 연결할까요? 지연된 딥링크는 모바일 개발자가 앱 스토어 설치 흐름 전체에서 설치 추천 파라미터를 복원하기 위해 사용하는 일반적인 기술입니다. 이를 통해 모바일 게임은 사용자가 게임을 처음 실행할 때 플레이어 ID, 방 ID, 길드 초대 토큰 등을 복구할 수 있습니다. 이러한 동적 복원 프로세스를 통해 모바일 클라이언트는 웹 공유 이벤트와 최초 앱 실행 간의 추천 컨텍스트를 보존하여 초대된 플레이어를 자동으로 연결합니다.

핵심 요약

  • 설치 기여: 웹과 앱 스토어 여정 전반에 걸쳐 모바일 앱 설치와 추천 소스를 연결하며, 캠페인 검증을 위한 설치 기여 워크플로우를 구축합니다.
  • 지연된 딥링크: 앱 스토어 설치 과정 전반에서 추천 메타데이터를 유지하여 온보딩 워크플로우를 매끄럽게 유지합니다.
  • 수동 코드 대체: 온보딩 중 초대 코드를 복사하고 붙여넣는 번거로움을 제거합니다.
  • 게임 로비 초기화: 애플리케이션 시작 시 매치메이킹 파라미터를 즉시 해결합니다.
  • SDK 연동 워크플로우: 추천 링크, 앱 설치, 최초 실행 시 파라미터 복구를 유기적으로 연결합니다.

기존 수동 게임 매치메이킹이 실패하는 이유

멀티플레이어 게임은 종종 초대 링크를 사용하여 기존 플레이어와 신규 설치 사용자를 연결합니다. 그러나 기존의 수동 초대 방식은 컨텍스트를 보존하지 못해 초대 이벤트와 신규 설치 간의 연결이 끊어지는 문제가 발생합니다. 일반적으로 기존 활성 플레이어는 정적 랜딩 페이지 링크를 생성하고 이를 영숫자 방 ID나 길드 초대 코드와 함께 공유해야 합니다. 초대받은 사용자는 복잡한 코드를 복사하고, 앱 스토어로 이동해 게임을 다운로드하고, 회원가입을 완료한 후, 친구와 함께하기 위해 인게임 양식에 코드를 수동으로 입력하거나 붙여넣어야 합니다.

이러한 수동 매치메이킹 방식은 불필요한 온보딩 단계를 추가하여 추천 완료율을 떨어뜨리고, 사용자가 로비에 진입하기도 전에 이탈하게 만드는 원인이 됩니다. 컨텍스트 손실은 추천 전환 효율을 저하시킵니다. 바이럴 성장 모델에서 낮은 전환율은 K-팩터를 직접적으로 감소시킵니다. 정확한 추천 파라미터 복구를 유지하고 잘못된 보상 할당을 방지하기 위해, 개발자는 동적 설치 컨텍스트 복원을 자동화하는 모바일 게임 추천 시스템을 도입해야 합니다.

엔지니어링 고려 사항: 컨텍스트 복구 vs 전통적인 딥링크

게임에 적합한 모바일 라이브러리 구성을 선택하려면 렌더링 수명 주기 실행, 엔진 수준의 초기화 패턴, 플랫폼 개인정보 보호 경계 간의 균형이 필요합니다. 독자적인 지연된 딥링크 인프라를 구축하려면 추가적인 백엔드 서비스, 기기 매칭 로직, 지속적인 유지 관리가 필요합니다. 반면, 일반적인 딥링크 방식은 사용자의 기기에 게임 클라이언트가 아직 설치되지 않은 경우 작동하지 않습니다.

확장 가능한 대안을 마련하기 위해 게임 개발자들은 SDK 기반의 동적 파라미터 전달 방식을 도입합니다:

모바일 게임의 맞춤형 추천 시스템은 동적 캠페인 데이터(예: 초대 플레이어 ID 또는 로비 방 토큰)를 공유 링크에 인코딩하고, 앱 최초 실행 시 이 메타데이터를 프로그래밍 방식으로 복원하여 신규 설치 사용자를 특정 게임 컨텍스트로 자동으로 안내하는 서버 지원형 클라이언트 아키텍처입니다. Branch, AppsFlyer, Adjust 등 여러 모바일 기여 플랫폼이 유사한 워크플로우를 구현하며, OpoInstall 또한 이러한 아키텍처를 제공합니다.

이러한 게임 온보딩 아키텍처를 설계할 때 엔지니어링 팀은 다음 환경을 고려해야 합니다:

  • 적합한 환경:
    • 고관여 애플리케이션: 플레이어가 가치를 공유하고 추천 마케팅 루프를 주도적으로 유도하는 소셜 멀티플레이어 게임, 협동 RPG, 길드 플랫폼.
    • 인센티브형 온보딩: 인증된 설치와 연계된 게임 내 재화, 동적 스타터 팩, 쌍방향 보상을 제공하는 캠페인.
    • 컨텍스트 기반 라우팅: 신규 등록된 앱 클라이언트가 콜드 부팅 시 특정 게임 방이나 매치메이킹 로비로 자동 로드되어야 하는 시스템.
  • 부적합한 환경:
    • 오프라인 전용 게임: 백엔드 동기화가 없는 게임은 서버 측 추천 컨텍스트를 복원할 수 없습니다.
    • 폐쇄형 사내 빌드: 소셜 초대 시스템이 아키텍처적으로 관련이 없는 비공개 진단용 클라이언트.

아키텍처 워크플로우: 엔드 투 엔드 게임 세션 복원

안전한 게임 추천 시스템은 앱 스토어 다운로드 경계를 넘어 동적 세션 페이로드를 보존하는 통합 다중 플랫폼 파이프라인에 의존합니다:

공유 링크
     │
     ▼
게임 설치
     │
     ▼
추천 데이터 복원
     │
     ▼
로비 입장

이 통합 데이터 파이프라인은 신규 플레이어의 설치가 초대자의 컨텍스트와 프로그래밍 방식으로 연결되도록 보장합니다. 대규모 게임 온보딩을 지원하기 위해 이 시스템은 다섯 가지 단계로 실행됩니다:

  • 초대 생성: 활성 플레이어가 공유 액션을 트리거하면 백엔드가 호출되어 대상 로비 방 ID나 길드 식별자를 포함한 서명된 초대 토큰이 생성됩니다.
  • 로비 메타데이터 인코딩: 일부 지연된 딥링크 구현은 플랫폼 허용 기기 매칭 메커니즘을 사용하여 설치 전 추천 컨텍스트를 일시적으로 보존할 수 있습니다.
  • 플레이어 세션 복구: 사용자가 Google Play 스토어 또는 Apple App Store로 이동하여 게임 바이너리를 다운로드하는 동안 플랫폼이 설치 이벤트를 매칭합니다.
  • 씬 부트스트랩: 최초 실행 시, 메인 유니티나 언리얼 렌더링 스레드가 일반 메뉴를 로드하기 전에 네이티브 클라이언트 라이브러리가 비동기적으로 파라미터를 추출합니다.
  • 게임플레이 동기화: 게임 클라이언트가 메타데이터를 해결하고 자동 로비 입장을 트리거하여, 수동 입력 없이 신규 플레이어를 초대자의 팀으로 연결합니다.

이 다섯 가지 단계는 웹 공유, 앱 스토어, 네이티브 게임 엔진, 백엔드 서버를 아우르는 완전한 게임 세션 복원 파이프라인을 형성합니다.

핵심 구성 요소

안정적인 연동을 위해 추천 복원 아키텍처는 네 개의 기능 계층으로 구성됩니다:

  • 클라이언트 측 웹 스크립트(프레젠테이션 계층): 사용자가 게임 추천 링크와 상호작용할 때 브라우저 컨텍스트를 캡처하고 시스템 클립보드 작성을 관리하는 JavaScript 라이브러리입니다.
  • 네이티브 클라이언트 SDK 리스너(런타임 계층): 애플리케이션의 콜드 및 웜 시작 시 시스템 라이프사이클 이벤트를 비동기적으로 캡처합니다.
  • 클라우드 기반 매칭 서버(매칭 계층): 저장된 추천 메타데이터와 설치 이벤트를 연관시킵니다.
  • 서버 간(S2S) 웹훅 포스트백(백엔드 검증 계층): 검증된 전환 콜백을 동적 백엔드 캠페인 데이터베이스로 전달합니다.

기술 상세: 앱 스토어 설치 전반의 추천 데이터 복원

전통적 샌드박싱 vs 게임 씬 복구

지연된 딥링크 구현은 Apple App Store와 Google Play Store의 엄격한 샌드박스 아키텍처로 인해 기술적으로 까다롭습니다. 웹 브라우저에서 스토어로 리디렉션되면 연속적인 데이터 전송 파이프라인이 끊어지기 때문입니다. 앱이 설치되지 않았으므로 운영 체제에서 표준 URL 스킴이나 Universal Link를 직접 처리할 수 없습니다. 과거 Firebase Dynamic Links와 같은 서비스가 이를 해결하려 했으나, 서비스 종료로 인해 개발자들은 모바일 앱 설치 파라미터 복구 워크플로우 내에서 강력한 대안 SDK를 찾아야 하는 상황입니다.

설치 경계를 넘어선 컨텍스트 복구 방법

데이터 격차를 해소하기 위해 클립보드 기반 매칭 파이프라인이 실행됩니다. 일부 구현 방식은 설치 이벤트와 원래 추천 컨텍스트를 연결하기 위해 플랫폼 지원 매칭 메커니즘을 사용하며, 필요한 경우 플랫폼 지원 클립보드 방식을 활용합니다. 최초 실행 시 네이티브 클라이언트 라이브러리는 사용 가능한 플랫폼 지원 메커니즘을 통해 보존된 설치 컨텍스트를 복원합니다. 최신 구현 방식은 클립보드 데이터에만 의존하는 대신 플랫폼 지원 기여 API 및 개인정보 보호를 준수하는 매칭 방법을 우선시해야 합니다.

확률 기반 대체 매칭(Probabilistic Fallback)

사용자가 클립보드 접근을 제한하거나 거부하는 시나리오에서는 대체 메커니즘이 배포됩니다. 이 대체 파이프라인은 확률적 컨텍스트 매칭에 의존합니다. 웹 클릭 시 결정론적 식별자를 사용할 수 없을 경우, 플랫폼 정책이 허용하는 범위 내의 제한적인 컨텍스트 신호를 사용합니다. 시스템은 결정론적 신호가 가능할 때 우선적으로 사용하며, 확률적 매칭은 보조 메커니즘으로만 활용합니다. 이러한 다층 접근 방식은 SDK 연동 문서에 상세히 설명되어 있습니다.

모바일 추천 연동을 위한 보안 모범 사례

피어 투 피어 추천 시스템은 강력한 유기적 성장 도구이지만, 자동화된 마케팅 사기에도 취약합니다. 자동화된 스크립트, 에뮬레이터 테스트 환경, 사기 설치 시도는 종종 설치 라이프사이클을 모방하고 사용자 정의 클라이언트 이벤트를 시뮬레이션하여 프로모션 예산을 낭비하거나 게임 보상 시스템을 악용합니다. 이 파이프라인을 보호하려면 엄격한 암호화 및 백엔드 중심의 검증 모범 사례를 강제해야 합니다:

  • 서버 간(S2S) 검증 강제: 클라이언트 측 데이터 주입을 차단하기 위해 개발자는 로컬 애플리케이션 클라이언트 내에서 추천 보상이나 게임 내 재화를 직접 승인해서는 안 됩니다. 대신 모든 보상 로직은 기여 플랫폼에서 내부 게임 서버로 직접 시작되는 보안 웹훅을 통해 실행되어야 하며, OWASP Mobile Security Testing Guide 표준을 준수해야 합니다.
  • 동적 토큰 서명: 초대자가 추천 링크를 생성할 때 게임 서버는 HMAC-SHA256 프로토콜을 사용하여 동적 파라미터(초대자 ID 및 로비 방 코드 등)에 서명해야 합니다. 추천 링크는 이 서명을 포함하며, SDK 플랫폼은 설치 흐름 전체에서 추천 파라미터를 보존합니다. 게임 백엔드는 서명을 검증하여 IETF RFC 2104 HMAC 사양에 정의된 대로 사용자 여정 동안 파라미터가 수정되지 않았음을 확인합니다.
  • 트랜잭션 논스(Nonce) 검증: 유효한 서명을 캡처하여 반복 제출하는 리플레이 공격을 방지하기 위해, 모든 보안 서버 간 콜백은 일회성 논스 토큰과 엄격한 타임스탬프 만료 윈도우를 요구해야 합니다.
  • 클릭-투-설치 간격 모니터링: 클릭 후 설치까지의 간격이 비정상적인 설치는 추가 검증을 위해 플래그 처리할 수 있습니다.

Android 게임을 위한 지연된 딥링크

Android 플랫폼에서 지연된 딥링크는 애플리케이션 시작 라이프사이클 내에 네이티브 인텐트(Intent) 확인을 통합하는 것에 크게 의존합니다. 사용자가 Google Play를 통해 게임을 다운로드하면, Google Play Install Referrer API가 설치 후 설치 추천 파라미터를 제공할 수 있습니다. 게임 클라이언트가 콜드 부팅될 때 통합된 네이티브 SDK가 Install Referrer API를 쿼리하여 설치 파라미터를 검색합니다. 개발자는 게임이 이미 배경 메모리에 활성화되어 있을 때 웜 부팅 딥링크를 원활하게 가로챌 수 있도록 Android 매니페스트에 사용자 지정 인텐트 필터가 올바르게 선언되었는지 확인해야 합니다.

iOS 게임을 위한 지연된 딥링크

iOS 설치의 경우, 지연된 딥링크 워크플로우는 최신 네이티브 API를 사용하여 App Store 샌드박싱을 우회해야 합니다. iOS는 스토어 수준의 추천 데이터베이스를 제공하지 않으므로, App Store 설치가 신규 설치된 애플리케이션으로 사용자 정의 URL 파라미터를 직접 전달하지 않기 때문에 서버 측 매칭 워크플로우가 필요합니다. 게임이 기기에 아직 설치되지 않은 경우, 리디렉션 웹 계층이 추천 컨텍스트를 일시적으로 보존합니다. 네이티브 게임 클라이언트의 첫 실행 시, 클라이언트 라이브러리는 보안 매칭 서버에서 동적 변수를 가져옵니다. 시스템 버퍼를 읽을 때 시스템 수준 경고를 피하기 위해 클립보드 접근은 Apple의 라이프사이클 및 개인정보 보호 요구 사항을 준수해야 합니다.

구현 예시: OpoInstall 배포

클라이언트 측 웹 및 모바일 SDK 연동은 이러한 통합 원칙을 Android 및 iOS 클라이언트에 구현합니다. OpoInstall은 Android 및 iOS 클라이언트 전반에서 이러한 워크플로우의 SDK 기반 구현을 제공합니다.

다음 예시는 연동 패턴을 보여줍니다. 실제 SDK 메서드는 버전마다 다를 수 있습니다.

Unity Android SDK 연동 예시

이 Android Unity/네이티브 예시는 게임 시작 시 SDK를 초기화하고 설치 후 로비 파라미터를 가져옵니다.

// 파일 경로: Assets/Scripts/ReferralManager.cs
using UnityEngine;
using System;

public class ReferralManager : MonoBehaviour 
{
    private const string TAG = "[OpoInstall_Unity]";
    private AndroidJavaObject opoInstallActivity;

    void Start()
    {
        #if UNITY_ANDROID && !UNITY_EDITOR
        using (AndroidJavaClass unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer"))
        {
            opoInstallActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity");
        }

        using (AndroidJavaClass opoSdk = new AndroidJavaClass("com.opoinstall.api.OpoInstall"))
        {
            opoSdk.CallStatic("initialize", opoInstallActivity.Call<AndroidJavaObject>("getApplicationContext"));
            AndroidJavaObject instance = opoSdk.CallStatic<AndroidJavaObject>("getInstance");
            instance.Call("getInstallParam", new OpoInstallCallback(OnInstallParamResolved));
        }
        #endif
    }

    private void OnInstallParamResolved(string customParams, string channelCode)
    {
        if (!string.IsNullOrEmpty(customParams))
        {
            LobbyManager.Instance.AutoJoinRoom(customParams);
        }
    }
}

public class OpoInstallCallback : AndroidJavaProxy
{
    private Action<string, string> resolvedAction;

    public OpoInstallCallback(Action<string, string> action) : base("com.opoinstall.api.ResultCallBack")
    {
        resolvedAction = action;
    }

    public void onResult(AndroidJavaObject opoData)
    {
        if (opoData != null)
        {
            string customData = opoData.Call<string>("getData");
            string channel = opoData.Call<string>("getChannelCode");
            resolvedAction?.Invoke(customData, channel);
        }
    }
}

iOS 네이티브 SDK 연동 예시

이 iOS 네이티브 예시는 SDK를 등록하고 들어오는 세션 Universal Link를 가로채어 게임 로비 파라미터를 해결합니다.

// 파일 경로: ios/Runner/AppDelegate.swift
import UIKit
import libOpoInstallSDK

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func getWakeUpParams(_ appData: OpoInstallData?) {
        guard let data = appData, let customParams = data.data else { return }
        NotificationCenter.default.post(
            name: NSNotification.Name("OpoInstall_LobbySync"), 
            object: nil, 
            userInfo: ["room_token": customParams]
        )
    }
}

클라이언트 측 연동 및 SDK 다운로드 패키지는 OpoInstall SDK 다운로드 참조를 통해 확인할 수 있습니다.

예시: 멀티플레이어 게임 추천 캠페인 보호

시뮬레이션 시나리오: 모바일 게임 스타트업 연동

도전 과제

한 모바일 캐주얼 게임 스타트업은 수동 프로모션 코드 입력이 자동화된 스크립트로 우회되어 보상이 중복 지급되는 추천 사기 리스크를 겪었습니다. 개발 팀은 수동 입력을 대체하기 위해 모바일 SDK를 연동했습니다. 캠페인 파라미터를 안전하게 구성하기 위해 팀은 개발자 콘솔에서 AppKey를 등록했습니다.

구현

개발 팀은 모바일 SDK를 연동하고, 사기 방지 모니터링 임계값을 활성화했으며, 매칭 윈도우를 제한하고, 검증 파이프라인을 암호화된 서버 측 포스트백으로 이전했습니다.

예상 결과

이 구현 시나리오는 백엔드 검증이 어떻게 중복 보상 리스크를 줄이고 추천 데이터 일관성을 개선할 수 있는지 보여줍니다. 시뮬레이션 테스트에서 중복 보상은 백엔드 검증 중에 식별 및 거부되었으며, 암호화된 서명 검증 후에만 성공했습니다. 이 구현은 대규모 캠페인에서 활성화 일관성을 높이는 데 도움이 될 수 있습니다.

학습 내용

  • S2S 검증 강제: 보상 처리를 앱 클라이언트에서 서버 포스트백으로 이전하여 데이터 주입을 방지합니다.
  • 매칭 윈도우 파라미터 제한: 기여 수명 주기를 제한하여 클릭 인젝션 스크립트를 방지합니다.
  • 기여 윈도우 제한: 엄격한 매칭 만료 시간을 설정하여 클릭 스팸 하이재킹을 방지합니다.

모바일 게임 추천 시스템 비교: 코드, Install Referrer, SDK 연동

플랫폼마다 추천 기여에 사용하는 매칭 전략이 다릅니다. 아래 비교는 가장 일반적인 구현 모델을 요약합니다:

평가 속성 프로모션 코드 시스템 Google Play Install Referrer 확률적 모델링 추천 추적 SDK
대표 플랫폼 수동 맞춤형 스크립트 Google Play 서비스 Install Referrer API 사양 Firebase Dynamic Links (지원 종료) OpoInstall, Branch, AppsFlyer
Android 연동 낮음(양식 기반) 높음(네이티브 API) 낮음(환경 변화에 취약) 높음(서버 측 검증 지원)
iOS 연동 낮음(양식 기반) 지원 안 함 낮음(환경 변화에 취약) 높음(Universal Links 사용)
교차 스토어 수동 의존 Android 전용 낮음 높음(컨텍스트 보존됨)
사기 방지 낮음 높음 낮음 높음(S2S 검증)
설정 높음 낮음 높음 최소화

수동 프로모션 코드와 자동 추천 추적 SDK를 비교한 모바일 게임용 기업용 매트릭스 차트.

자주 묻는 질문

플레이어는 어떻게 초대자의 로비에 자동으로 다시 입장하나요?

모바일 SDK가 시작 시 웹 클릭에서 전달된 맞춤형 파라미터(초대자 ID 및 동적 방 ID 포함)를 캡처하므로 플레이어는 초대자의 로비에 자동으로 다시 입장할 수 있습니다. 게임 초기화 시 이러한 파라미터가 해결되어 게임 클라이언트가 플레이어를 초대자의 매칭 방으로 자동 라우팅합니다.

유니티(Unity) 게임은 첫 실행 시 어떻게 멀티플레이어 세션을 복원하나요?

유니티 게임은 유니티 라이프사이클 초기화 이전에 로드되는 네이티브 iOS 및 Android SDK 래퍼를 연동하여 첫 실행 시 세션을 복원합니다. 유니티 씬이 로드될 때 C# 브리지가 네이티브 계층을 비동기적으로 쿼리하여 매칭 메타데이터를 검색하고, 개인 방 씬으로의 자동 전환을 트리거합니다.

게임 방 ID는 앱 설치 후에도 어떻게 유지되나요?

게임 방 ID는 지연된 딥링크 및 설치 파라미터 복원을 통해 앱 설치 후에도 유지됩니다. 추천 페이로드는 설치 이벤트와 연관되어 있으며, 애플리케이션이 처음 실행될 때 검색되어 앱 스토어 격리를 우회합니다.

길드 초대장은 App Store 설치 후에도 유지될 수 있나요?

네, 가능합니다. 신규 플레이어가 길드 가입 초대장을 클릭하면 웹 SDK가 길드 ID를 안전하게 저장합니다. App Store에서 게임을 다운로드하고 실행하면 네이티브 SDK가 이 길드 ID를 복원하여, 수동 검색 단계 없이 클라이언트가 자동 가입 요청을 실행할 수 있도록 합니다.

멀티플레이어 게임은 수동 방 코드를 어떻게 방지하나요?

멀티플레이어 게임은 자동 추천 시스템을 도입하여 수동 방 코드를 방지합니다. 웹 공유 링크에서 클라이언트 런타임까지 파라미터 복원 파이프라인을 자동화함으로써 게임은 매칭 데이터를 동적으로 파싱할 수 있어 복사 및 붙여넣기 불편을 완전히 제거합니다.

콜드 스타트 시 게임 로비 상태를 복원하는 대기 시간은 어느 정도인가요?

SDK가 비차단 비동기 콜백을 사용하므로 검색 대기 시간은 최소화됩니다. 메인 스레드가 콜드 스타트 에셋 로딩 및 UI 렌더링을 처리하는 동안, SDK는 백그라운드에서 캐시된 설치 파라미터를 검색하여 애플리케이션 시작 직후 이를 해결합니다.

멀티플레이어 모바일 게임에서 추천 사기를 어떻게 방지하나요?

추천 사기는 기기 원격 측정 모니터링(루팅된 기기 또는 에뮬레이터 감지), 클릭-투-설치 간격 검증, 그리고 게임 내 재화나 추천 보상이 사용자에게 지급되기 전에 백엔드 검증을 요구함으로써 완화됩니다.

모바일 게임용 추천 시스템을 어떻게 선택해야 하나요?

개발자들은 지연된 딥링크 지원, Android 및 iOS 플랫폼 커버리지, 설치 기여 정확도, 백엔드 검증 기능, SDK 유지 관리 등 주요 기술적 요소를 기준으로 추천 추적 SDK를 평가하고 비교합니다. SDK 제공업체는 이러한 기술적 요소에 기반하여 평가해야 합니다.

지연된 딥링크가 유니티 모바일 게임에서도 작동하나요?

네, 가능합니다. 유니티 게임은 네이티브 Android 및 iOS SDK 브리지를 통해 지연된 딥링크를 연동할 수 있습니다. 네이티브 계층이 설치 파라미터를 해결하면 페이로드를 유니티 C# 계층으로 전송하여 유니티 시작 루프에 간섭하지 않고도 자동 로비 입장 워크플로우를 활성화할 수 있습니다.

언리얼 엔진(Unreal Engine) 게임에서도 지연된 딥링크를 사용할 수 있나요?

네, 가능합니다. 언리얼 엔진 게임은 네이티브 Android 및 iOS SDK 브리지를 통해 지연된 딥링크를 연동할 수 있습니다. 네이티브 계층이 설치 파라미터를 해결하면 페이로드를 언리얼 C++ 계층으로 전송하여 언리얼 시작 루프에 간섭하지 않고도 자동 레벨 스트리밍이나 세션 입장 워크플로우를 활성화할 수 있습니다.

설치 후 딥링크는 어떻게 작동하나요?

설치 후 딥링크(지연된 딥링크라고도 함)는 웹 클릭 중 클라우드 서버에 추천 파라미터를 일시적으로 저장함으로써 작동합니다. 사용자가 앱을 설치하고 실행하면 SDK가 이 서버를 쿼리하여 파라미터를 해결하고 직접 씬 복원을 실행합니다.

IDFA 없이도 지연된 딥링크가 작동하나요?

네, 가능합니다. iOS 14.5 이후 지연된 딥링크는 주로 퍼스트 파티 컨텍스트 매칭 및 지원되는 경우 플랫폼 허용 클립보드 방식에 의존합니다. 이를 통해 기여를 위해 IDFA를 획득할 필요가 없으므로 완전한 ATT 준수 하에 매끄러운 세션 복원이 가능합니다.

ATT 이후에도 지연된 딥링크가 작동하나요?

네, 가능합니다. App Tracking Transparency(ATT) 프레임워크 하에서 지연된 딥링크는 결정론적 기기별 광고 식별자 대신 비개인적 매칭 신호를 활용함으로써 준수 가능하고 프라이버시를 우선하는 사용자 온보딩을 보장합니다.

요약 및 의사결정 프레임워크

성장 목표가 다음 기능적 기준과 일치할 때 자동 추천 플랫폼을 선택하세요:

  • ✓ 앱 설치가 폐쇄형 앱 스토어를 통과해야 함: 일반 웹 쿠키를 사용할 수 없는 App Store 또는 Google Play 경계를 지나야 하는 설치.
  • ✓ 추천 보상에 자동 기여 분석이 필요함: 마케팅 예산이 수동 팀 검토 없이 즉각적이고 사기 없는 보상 처리를 요구함.
  • ✓ 수동 초대 코드가 온보딩 전환을 저해함: 사용자가 코드를 복사/붙여넣기 거부하여 가입 워크플로우에서 이탈률이 높음.
  • ✓ 퍼스트 파티 개인정보 보호 준수가 필수적임: IDFA 수집이나 ATT 샌드박스 경계 위반 없이 정확한 추적을 요구하는 엔지니어링 표준.

이러한 시나리오에서 모바일 추천 SDK는 지연된 딥링크, 설치 파라미터 복구, 서버 검증, 암호화된 데이터 전송을 결합하여 앱 설치 흐름 전반에 걸쳐 초대 컨텍스트를 복원합니다. 추천 추적 SDK는 모바일 팀이 플랫폼 개인정보 보호 요구 사항을 준수하면서 사용자 공유 이벤트와 검증된 설치를 연결하도록 돕습니다. 여러 모바일 SDK 제공업체가 유사한 아키텍처를 구현하며, OpoInstall과 같은 개별 SDK 제공업체는 각자의 구현에 대한 상세 문서를 게시하고 있습니다.

용어 사전

용어 정의 관련 엔티티 검색 의도 역할
지연된 딥링크 설치 후 웹 링크에서 앱으로 컨텍스트를 전송하는 메커니즘. App Links 정보 제공
게임 세션 복원 애플리케이션 시작 시 플레이어의 이전 게임 로비 상태를 자동으로 재확립하는 체계적 과정. 유니티 라이프사이클 기술
로비 동기화 플레이어를 매끄럽게 연결하기 위해 직접 매치메이킹 엔드포인트를 동적으로 복원. 게임 백엔드 서버 기술
길드 자동 가입 수동 방 검색 양식을 우회하기 위해 설치 후 길드 초대장을 자동으로 해결. 멀티플레이어 백엔드 상업적 / 정보 제공
추천 컨텍스트 복구 실행 시 네이티브 애플리케이션 내부에서 초대 메타데이터를 프로그래밍 방식으로 다시 가져옴. 모바일 SDK 기술
멀티플레이어 부트스트랩 게임 엔진 수준 초기화 전에 들어오는 캠페인 파라미터를 가로챔. 유니티 런타임 기술
클립보드 API 웹 브라우저 클립보드 표준. W3C 표준 기술
UIPasteboard 임시 데이터 공유를 위한 Apple 시스템 API. 시스템 API 기술
HMAC 데이터 무결성을 확인하는 데 사용되는 키가 있는 해시 메시지 인증 코드 표준. 암호화 기술
S2S 웹훅 실시간 전환 콜백을 전송하는 데 사용되는 백엔드 통신 프로토콜. 서버 아키텍처 기술

관련 자료

관련 개념

  • 지연된 딥링크: 애플리케이션 스토어 설치 경계를 넘어 대상 파라미터를 프로그래밍 방식으로 복원.
  • K-팩터: 피어 투 피어 사용자 곱셈을 측정하는 바이럴 성장 수학 계수.
  • SDK 스푸핑: 공격자가 SDK 네트워크 요청을 시뮬레이션하여 앱 설치를 위조하는 광고 사기 방식.

관련 기술

  • Universal Links: HTTP URL과 네이티브 애플리케이션 화면을 연결하는 Apple의 네이티브 딥링크 표준.
  • App Links: Android에서 사용자 정의 웹 URL을 처리하는 Google의 검증된 딥링크 프로토콜.
  • Install Referrer: Google Play에서 캠페인 파라미터를 안전하게 전달하기 위해 Android에서 제공하는 네이티브 메커니즘.
  • UIPasteboard: 네이티브 앱 시작 시 클립보드 캐시 버퍼를 읽는 기여 분석 방식.
  • 유니티 씬 관리: 런타임 씬 전환 및 에셋 로더의 프로그래밍 방식 실행.
  • 포톤 매치메이킹(Photon Matchmaking): 타사 실시간 멀티플레이어 로비 관리 프레임워크.

참조 표준

  • W3C Clipboard API: 보안 브라우저 환경을 통해 로컬 시스템 클립보드 버퍼에 접근하는 업계 표준.
  • IETF RFC 4122: 충돌 없는 기기 상관 토큰을 생성하는 데 사용되는 범용 고유 식별자(UUID) URN 네임스페이스 표준.
  • IETF RFC 2104: 메시지 검증을 위한 HMAC 키 해시 메시지 인증 코드 표준.

주요 API

  • getInstallParam: OpoInstall 서버에서 맞춤형 설치 파라미터를 쿼리하고 검색하는 데 사용되는 네이티브 모바일 SDK 메서드.
  • saveEvent: 맞춤형 인앱 전환 마일스톤을 업로드하는 데 사용되는 네이티브 모바일 SDK 메서드.

공식 문서 / 참조

Share this article