AppLovin 광고 미디에이션 암호 프로토콜, 한 개발자가 풀어낸 이야기

광고 미디에이션이 뭔가요

모바일 앱에서 광고로 수익을 내본 분들은 아시겠지만, 광고는 한 곳에서만 받는 게 아니에요. 구글 AdMob, Meta Audience Network, AppLovin, Unity Ads… 수많은 광고 네트워크가 있고, 각 광고 자리(임프레션)마다 "어디서 받은 광고를 보여줄지" 실시간으로 결정해야 해요. 이 결정을 자동으로 해주는 시스템이 광고 미디에이션(Ad Mediation) 이에요.

그중 AppLovin MAX는 모바일 광고 미디에이션에서 가장 큰 점유율을 가진 플랫폼 중 하나예요. 게임 앱이나 무료 앱 SDK 안에 들어가서 여러 광고 소스로부터 입찰을 받아 가장 높은 가격을 부른 광고를 보여줘요. 그런데 이 통신 과정에서 광고 가격, 입찰 정보, 사용자 데이터 같은 민감한 정보가 오가다 보니, AppLovin은 자체적인 암호화 프로토콜로 통신을 보호하고 있어요.

이번 글의 저자는 이 암호화 프로토콜을 리버스 엔지니어링으로 해독해낸 과정을 공유했어요.

어떻게 풀어냈을까

시작은 SDK 분석이었어요. AppLovin SDK는 자바/코틀린으로 작성된 안드로이드 라이브러리로 배포되는데, ProGuard나 R8 같은 도구로 난독화되어 있어요. 클래스 이름이 a, b, c로 바뀌고 메서드 흐름이 일부러 꼬여 있어서 그냥 읽으면 도무지 무슨 코드인지 모르겠죠.

저자는 jadx 같은 디컴파일러로 SDK를 풀어보고, 네트워크 요청을 가로채는 프록시(예: mitmproxy, Charles)를 통해 실제로 어떤 데이터가 어떤 형태로 서버에 가는지 관찰했어요. 그러다 보니 요청 본문이 단순 JSON이 아니라 일종의 바이너리 블롭으로 인코딩되어 있고, 암호화 키가 클라이언트 코드 안에서 동적으로 생성된다는 점을 발견했어요.

이게 흥미로운 지점인데요. 일반적인 HTTPS만으로는 부족하다고 본 거예요. HTTPS는 통신 채널을 보호할 뿐, 클라이언트 자체를 신뢰하지 않는 환경(예: 루팅된 기기, 인증서 핀 우회 등)에서는 페이로드(payload, 실제 데이터 본문)가 노출될 수 있거든요. 그래서 AppLovin은 페이로드를 한 겹 더 자체 암호화한 거예요.

저자는 SDK가 사용하는 암호 알고리즘이 표준 AES 기반이지만, 키 생성 로직이 독자적이라는 걸 알아냈어요. 키는 디바이스 정보, 타임스탬프, 그리고 SDK에 하드코딩된 시드값을 조합해서 만들어져요. 이걸 재현해서 같은 키를 만들어내고, 결국 서버로 가는 요청과 서버에서 오는 응답을 모두 평문으로 볼 수 있게 됐죠.

이게 왜 의미 있을까

광고 SDK 통신을 들여다보는 일은 단순한 호기심을 넘어요. 첫째로 개인정보 관점이에요. 광고 SDK는 광고 ID, 위치, 기기 정보 같은 민감한 데이터를 주고받기 때문에, 실제로 어떤 데이터가 어디로 흘러가는지 외부에서 검증할 수 있어야 해요. GDPR이나 한국 개인정보보호법 관점에서도 "SDK가 정확히 뭘 보내는지" 알 수 있어야 진짜 컴플라이언스(법규 준수)가 가능해요.

둘째로 광고 사기(ad fraud) 탐지예요. 가짜 트래픽, 봇 클릭, 가격 조작 같은 문제가 광고 업계의 골칫거리인데, 미디에이션 프로토콜이 블랙박스라면 광고주가 의심해도 검증할 방법이 없어요. 프로토콜이 공개적으로 분석 가능해지면 광고 생태계의 투명성이 올라가요.

셋째로 보안 설계 관점의 교훈이에요. 클라이언트 측 암호화는 "공격자에게 시간을 더 들이게 만드는" 효과는 있지만 절대적인 보호는 아니에요. 클라이언트가 키를 만들 수 있다면, 그 코드를 분석한 누군가도 결국 만들 수 있거든요. 이걸 보안 업계에선 "security through obscurity는 한계가 있다"고 말해요.

비슷한 사례들

이런 식의 SDK 리버스 엔지니어링은 사실 처음이 아니에요. 과거에 Snapchat, TikTok, Facebook SDK 등이 모두 비슷한 분석 대상이 됐고, 그때마다 "이런 데이터가 빠져나가고 있었다"는 발견이 이어졌어요. iOS의 App Tracking Transparency, 안드로이드의 Privacy Sandbox 같은 정책 변화는 이런 분석의 누적된 결과이기도 하고요.

특히 모바일 광고 분야는 MMP(Mobile Measurement Partner, AppsFlyer·Adjust 등) 라는 별도 측정 솔루션과 미디에이션 SDK가 복잡하게 얽혀 있어서, 데이터 흐름을 정확히 파악하기가 쉽지 않아요. 그래서 이런 리버스 엔지니어링 분석은 업계 투명성에 기여하는 측면이 있어요.

한국 개발자에게 주는 시사점

앱 개발하면서 광고 SDK를 붙여본 분들에게 이 글은 두 가지 메시지를 줘요. 하나는 "내 앱에 박힌 SDK가 정확히 뭘 하는지 한 번쯤은 의심해보자" 예요. 광고 수익은 중요하지만, 사용자 데이터가 어디로 어떻게 가는지 모르는 채로 SDK를 통합하는 건 위험할 수 있어요. 특히 어린이 대상 앱이라면 COPPA 같은 규정 때문에 더 주의가 필요해요.

또 하나는 보안을 설계할 때의 교훈인데요, "클라이언트 안에 비밀을 숨기는 방식은 결국 시간 끌기일 뿐"이라는 점이에요. 진짜 보안은 서버 측 검증, 짧은 수명의 토큰, 페이로드 서명 같은 방법으로 만들어야지, 클라이언트 난독화에 기대면 안 돼요. 이건 게임 개발에서 치트 방어, 결제 검증 등에도 그대로 적용되는 원칙이에요.

마무리

한 줄 정리하면, AppLovin의 자체 암호 프로토콜이 SDK 분석과 키 재현을 통해 해독됐고, 이는 모바일 광고 생태계의 투명성과 클라이언트 측 보안의 한계를 동시에 보여주는 사례예요.

여러분은 앱에 광고 SDK를 붙일 때 어떤 기준으로 선택하시나요? 수익률, 통합 난이도, 개인정보 정책 중 무엇을 가장 우선으로 두시는지 댓글로 의견 나눠봐요.