ads.txt가 나온 지 1년 만에 200만 개 퍼블리셔가 채택했습니다. 이 숫자를 처음 봤을 때 저는 솔직히 좀 놀랐습니다. 광고 업계에서 뭔가 새로운 표준이 빠르게 자리를 잡는 경우가 드문데, ads.txt는 달랐거든요. 그리고 그 흐름이 이제 모바일 앱으로도 그대로 넘어오고 있습니다. 웹에서 검증된 방식이 인앱 환경으로 확장된다는 건 당연한 수순처럼 보이지만, 실제 구현 방식이나 이점을 제대로 아는 개발자는 생각보다 많지 않더라고요. 그래서 이번 글에서는 ads.txt가 무엇인지부터 시작해, app-ads.txt가 모바일 앱에 어떤 의미를 갖는지를 제가 직접 파악한 내용을 바탕으로 정리해 보겠습니다.
ads.txt가 생긴 배경 — 도메인 스푸핑이라는 문제
ads.txt는 2017년 IAB Tech Lab에서 만든 텍스트 파일 기반의 표준입니다. 여기서 IAB란 Interactive Advertising Bureau의 약자로, 디지털 광고 업계의 표준을 제정하는 주요 기관입니다. ads.txt가 나오게 된 직접적인 계기는 도메인 스푸핑(Domain Spoofing) 문제였는데요. 사기 업체들이 Financial Times 같은 프리미엄 매체인 척 위장해서 광고 인벤토리를 판매하는 일이 업계에서 광범위하게 벌어지고 있었습니다.
여기서 도메인 스푸핑이란, 실제로 해당 매체의 광고 지면에 접근 권한이 없는 판매자가 마치 그 매체의 인벤토리를 파는 것처럼 속이는 행위입니다. 광고주 입장에서는 믿을 만한 매체에 광고가 집행된다고 생각하고 예산을 썼는데, 실제로는 엉뚱한 곳에 집행된 셈이 되는 거죠. 저도 처음에 이 구조를 이해했을 때 '이게 어떻게 가능하지?'라는 생각이 먼저 들었습니다.
ads.txt의 방식은 단순하지만 효과적입니다. 퍼블리셔가 자신의 웹사이트에 ads.txt 파일을 올려두고, 자신의 인벤토리를 판매할 권한이 있는 광고 소스 목록을 명시해 두는 겁니다. DSP(Demand-Side Platform, 광고 구매자 플랫폼)는 입찰 전에 이 파일을 확인해서, 리스트에 없는 판매자가 보낸 비딩 요청은 그냥 걸러냅니다. AdExchanger의 보고에 따르면 ads.txt를 구현하지 않은 퍼블리셔는 실제로 금전적 손해를 입고 있다고 하는데, 이건 단순한 경고가 아니라 DSP들이 승인되지 않은 인벤토리를 구매 자체를 거부하기 때문입니다.
- 출시 시기: 2017년, IAB Tech Lab 주도
- 도입 속도: 출시 1년 만에 200만 퍼블리셔 채택
- 작동 원리: 퍼블리셔 웹사이트에 승인된 광고 소스 목록 파일 업로드
- 핵심 효과: DSP가 미승인 인벤토리 입찰 요청 자동 차단
app-ads.txt란 — 웹 표준이 모바일 앱으로 확장된 이유
웹에서 ads.txt가 효과를 입증하자, 자연스럽게 인앱 광고 환경으로도 확장이 이뤄졌습니다. 이게 app-ads.txt입니다. 개념 자체는 ads.txt와 거의 동일합니다. 앱 개발자가 자신의 개발자 웹사이트에 app-ads.txt 파일을 올려두고, 자신의 앱 인벤토리를 판매할 권한이 있는 광고 소스를 명시하는 방식입니다.
그런데 여기서 웹과 결정적으로 다른 점이 하나 있습니다. 웹은 퍼블리셔의 도메인에 직접 파일을 올리면 되는데, 앱은 앱 자체에 URL이 없습니다. 그래서 앱 스토어(구글 플레이, 애플 앱 스토어 등)에 등록된 앱 목록에 개발자 웹사이트 URL을 연결해 두는 게 출발점이 됩니다. DSP는 인앱 비딩 요청을 받았을 때, 앱 스토어 정보에서 개발자 웹사이트 URL을 확인하고, 그 웹사이트의 app-ads.txt 파일을 찾아가 해당 광고 소스가 승인된 건지 검증하는 구조입니다.
여기서 DSP란 Demand-Side Platform의 약자로, 광고주나 에이전시가 여러 매체의 광고 인벤토리를 한 곳에서 구매할 수 있는 플랫폼을 의미합니다. 브랜드 마케팅 담당자 대부분이 이 DSP를 통해 인앱 광고를 구매하기 때문에, DSP가 app-ads.txt 없는 인벤토리를 거부하기 시작하면 개발자 입장에서는 선택의 여지가 없는 셈입니다. 웹에서 이미 그런 흐름이 굳어졌고, 인앱에서도 동일한 패턴이 반복될 것이라고 저는 봅니다.
더 많은 브랜드가 인앱 광고에 예산을 쏟기 시작하면서 이 흐름은 더 빨라질 것 같습니다. 실제로 제가 이 구조를 들여다보면서 느낀 건, 광고 생태계의 투명성 요구가 결국 플랫폼을 가리지 않는다는 겁니다. 웹이든 앱이든 DSP가 손을 대지 않으면 인벤토리가 팔리지 않는 구조라서, 표준을 따르는 것 자체가 수익과 직결됩니다. (출처: IAB Tech Lab)
광고 사기 방지와 수익 확보 — 개발자에게 실제로 무슨 의미인가
app-ads.txt의 이점을 두 가지로 정리하는 분들이 많은데, 저도 이 구분에 동의합니다. 하나는 수익 확보, 다른 하나는 광고 사기 방지입니다. 이 둘은 분리된 문제처럼 보이지만 사실 같은 동전의 양면입니다.
광고 사기 측면부터 보면, 사기 업체들이 합법적인 앱처럼 보이는 가짜 앱을 만들어 DSP에 비딩 요청을 보내는 방식이 실제로 존재합니다. DSP는 비딩 요청만 보고는 진짜 앱인지 가짜 앱인지 구별하기 어렵습니다. 결국 광고주 예산이 가짜 인벤토리에 흘러들어가고, 그만큼 진짜 개발자들이 받았어야 할 수익이 줄어드는 구조입니다. app-ads.txt는 이 경로를 차단합니다. 개발자 웹사이트에 명시된 승인 목록에 없는 광고 소스는 입찰 자체를 못 하니까요.
수익 확보 측면에서도 이야기는 비슷하게 흘러갑니다. app-ads.txt를 준수하는 DSP들이 늘어날수록, app-ads.txt가 없는 앱은 DSP의 미디어 구매 풀에서 자동으로 제외됩니다. 이건 벌점이 아니라 그냥 구조의 문제입니다. 웹에서 이미 일어난 일이고, 인앱에서도 똑같은 일이 일어날 것이라는 게 현재 업계 흐름입니다. 제가 이 구조를 처음 정리했을 때 든 생각은, 이걸 선택의 문제로 바라보는 개발자라면 나중에 후회할 수 있겠다는 것이었습니다.
브랜드 마케팅 담당자들의 시각도 중요합니다. 브랜드 안전(Brand Safety)에 민감한 광고주들은 검증되지 않은 인벤토리에 예산을 쓰는 걸 점점 더 꺼립니다. app-ads.txt는 바로 그 검증의 근거가 됩니다. 즉, 개발자 입장에서 app-ads.txt를 구현하는 건 "우리 앱은 믿을 수 있는 인벤토리입니다"라는 신호를 광고 생태계 전체에 보내는 행위입니다. (출처: AdExchanger)
app-ads.txt 구현 방법 — 실제로 어떻게 적용하나
구현 방식을 두고 어렵게 생각하는 분들이 있는데, 구조 자체는 생각보다 단순합니다. 제가 파악한 흐름을 그대로 정리하면 두 단계입니다.
첫 번째는 앱 스토어의 앱 목록에 개발자 웹사이트 URL을 정확히 입력해 두는 것입니다. 이 URL이 DSP가 app-ads.txt를 찾아가는 출발점이 됩니다. 구글 플레이든 애플 앱 스토어든, 앱 등록 정보에 개발자 웹사이트 항목이 있는데 여기에 실제 운영 중인 웹사이트 주소가 들어가 있어야 합니다. 이게 비어 있거나 잘못된 URL이면 이후 단계가 전부 무너집니다.
두 번째는 그 웹사이트에 app-ads.txt 파일을 올리는 것입니다. 파일 안에는 IAB가 정한 구조에 따라 승인된 광고 소스 정보를 한 줄씩 기입합니다. 여기서 IAB 구조란 광고 소스 도메인, 퍼블리셔 ID, 거래 유형(DIRECT 또는 RESELLER), 인증 기관 ID 등을 쉼표로 구분해 나열하는 포맷을 의미합니다. 각각의 광고 소스(SSP, 광고 네트워크 등)에 직접 연락해서 app-ads.txt 항목을 요청하면, 대부분 정해진 포맷으로 제공해 줍니다.
- 1단계: 앱 스토어 앱 목록에 개발자 웹사이트 URL 정확히 등록
- 2단계: 등록된 웹사이트에 app-ads.txt 파일 업로드 (루트 디렉토리 권장)
- 파일 내용: 각 광고 소스에 직접 연락해 IAB 포맷의 항목 수령 후 기입
- 주의사항: 웹사이트 URL이 앱 스토어와 app-ads.txt 파일 위치가 정확히 일치해야 함
저는 이 과정을 처음 파악했을 때, 기술적 난이도보다는 광고 소스 목록을 누락 없이 관리하는 게 실제 관건이라는 인상을 받았습니다. 파일 구조보다 '어떤 광고 소스를 내 인벤토리 판매 주체로 승인할 것인가'를 명확히 정하는 게 더 중요한 작업입니다.
app-ads.txt를 필수로 봐야 하냐, 선택으로 봐야 하냐를 두고 아직 다양한 시각이 존재합니다. 단기적으로는 구현하지 않아도 큰 문제 없다고 보는 분들도 있고, 저처럼 웹에서의 흐름이 그대로 반복될 것이라 생각하는 분들도 있습니다. 다만 한 가지는 분명합니다. 웹에서 ads.txt를 채택하지 않은 퍼블리셔가 실제로 DSP의 구매 대상에서 밀려났다는 사실은 이미 기록된 결과입니다. 인앱 환경에서도 그 패턴이 반복되기 전에 미리 준비해 두는 게 훨씬 낫다고 저는 생각합니다. 광고 업계의 투명성 요구는 한 방향으로만 흘러가고 있으니까요.
입력 방법
google.com, pub- , DIRECT, f08c47fec0942fa0
'개발자마인드' 카테고리의 다른 글
| 알 수 없는 버그의 늪, 레이스 컨디션과의 전쟁 (0) | 2026.06.29 |
|---|---|
| [2026 최신] 초보 개발자 탈출! 객체 지향 프로그래밍(OOP) SOLID 5대 원칙 완벽 가이드 및 실전 적용법 (0) | 2026.06.24 |
댓글