app-ads.txt란 무엇이며 어디에 있어야 하는가

app-ads.txt는 앱의 광고 인벤토리를 판매하도록 허용된 광고 회사를 나열한 일반 텍스트 파일입니다. 스토어 등록정보에 신고한 웹사이트의 /app-ads.txt에 있으며, 광고 네트워크는 이 파일을 가져와 개발자의 인벤토리를 내놓은 쪽이 정말 개발자에게서 승인받았는지 확인합니다. 이 파일이 없으면 구매자에게는 그것을 확인할 방법이 없으며, 그것이 이 표준이 존재하는 이유의 전부입니다.

앱에 광고를 표시하지 않는다면 이 파일은 전혀 필요 없습니다. 표시한다면 약 10분이 걸리는데, 그중 9분은 위치를 올바르게 잡는 데 들어갑니다. 정기적으로 잘못되는 부분은 그것뿐입니다.

어떤 문제를 해결하는가

광고 인벤토리는 재판매됩니다. 앱과 광고주 사이 어딘가에 거래소, 리셀러, 중개인이 있으며, ads.txt와 그 앱 버전 형제가 나오기 전까지 구매자가 “이것은 정말 그 앱의 인벤토리다”와 “누군가 그것을 판매한다고 주장하고 있다”를 저렴하게 구별할 방법이 없었습니다. 주장을 검증할 수 없었기 때문에 사기가 통했습니다.

해결책은 일부러 단순한 기술입니다. 퍼블리셔가 자신을 대신해 판매할 수 있는 쪽의 목록을, 퍼블리셔만 관리하는 주소에 게시합니다. 구매자는 파일을 가져와 대조합니다. 메커니즘은 그것이 전부이며, 그래서 내용보다 주소가 더 중요합니다. 누구나 둘 수 있었던 곳에 있는 파일은 아무것도 증명하지 못합니다.

줄 형식

한 줄에 승인된 판매자 하나, 쉼표로 구분된 필수 필드 세 개와 선택 필드 하나:

google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0

필드	의미
google.com	광고 시스템의 도메인. 개발자의 도메인이 아니라 네트워크 자체의 정식 도메인입니다.
pub-0000000000000000	그 네트워크에서의 개발자 본인의 퍼블리셔 ID. 네트워크 대시보드에서 복사하세요.
DIRECT 또는 RESELLER	직접 계약을 맺었다면 DIRECT, 재판매를 승인했다면 RESELLER.
f08c47fec0942fa0	선택 사항인 인증 기관 ID. 네트워크가 공개하는 경우에만.

# 뒤는 모두 주석입니다. contact=, subdomain=, inventorypartnerdomain= 등으로 시작하는 줄은 판매자 레코드가 아니라 변수이며, 그대로 둡니다.

망가진 파일의 대부분은 두 가지 실수에서 나옵니다. 쉼표가 빠져서 줄 전체를 파싱할 수 없게 되는 것, 그리고 지원 포럼에서 남의 퍼블리셔 ID를 붙여 넣어 모르는 사람에게 내 인벤토리를 판매할 권한을 주는 것입니다. 각 네트워크의 대시보드는 원하는 줄을 정확히 보여 줍니다. 템플릿이 아니라 그것을 쓰세요.

어디에 있어야 하는가 — 모든 것을 결정하는 부분

크롤러는 패키지 이름을 모르고, 앱으로 개발자를 찾지도 않습니다. 크롤러는 스토어 등록정보의 개발자 웹사이트 URL을 읽고, 그 도메인의 루트에서 /app-ads.txt를 가져옵니다. 등록정보의 URL이 틀리면 완벽하게 올바른 파일도 보이지 않습니다.

AdMob은 탐색 규칙을 문서로 공개하고 있으며, 추측하기보다 한 번 읽어 둘 가치가 있습니다.

• 루트 디렉터리는 “the directory following the top level domain”(번역: 최상위 도메인 바로 다음의 디렉터리)을 뜻합니다. example.com/some/path/app-ads.txt가 아니라 example.com/app-ads.txt입니다.
• 크롤러는 “probe up to one subdomain level from the developer website when constructing an app-ads.txt URL”(번역: app-ads.txt URL을 구성할 때 개발자 웹사이트에서 하위 도메인 한 단계까지 탐색)합니다. support.help.example.com/game을 가리키는 등록정보에 대해, AdMob 자체 예시는 help.example.com/app-ads.txt와 example.com/app-ads.txt를 시도하는 것을 보여 줍니다.
• www.과 m.은 하위 도메인 위치에서 제외되므로 도메인 자체로 취급됩니다.

주소 외에도, 제공 방식은 지루할 만큼 정확해야 합니다. HTTP 200, Content-Type: text/plain, 앞에 리디렉션 없음, 로그인 없음, JavaScript로 렌더링하지 않음, robots.txt에서 차단하지 않음. http에서 https로, 또는 루트 도메인에서 www로 리디렉션된 뒤에야 나타나는 파일은 흔하면서도 전혀 눈에 띄지 않는 실패입니다.

크롤러처럼 확인하세요.

curl -i https://your-domain.example/app-ads.txt

원하는 결과는 200 OK, text/plain, Location: 헤더 없음, 그리고 본문에 있는 개발자의 줄들입니다.

“하지만 저는 웹사이트가 없는데요”

인디 개발자에게는 이것이 일반적인 경우이며, 그래서 많은 앱에 파일이 아예 없습니다.

요건은 직접 관리하면서 파일을 제공하는 호스트 이름입니다. 마케팅 사이트, 회사 도메인, 랜딩 페이지를 가지라는 요건이 아닙니다. AdMob은 직접 이렇게 말합니다. “If you don’t have a suitable website that allows the uploading of an app-ads.txt file at the root level, you can use Firebase Hosting to host your app-ads.txt file.”(번역: 루트 수준에 app-ads.txt 파일을 업로드할 수 있는 적절한 웹사이트가 없다면, Firebase Hosting을 사용해 app-ads.txt 파일을 호스팅할 수 있습니다.) 플랫폼 호스팅은 우회책이 아니라 예상된 방법입니다. 선택지는 웹사이트 없이 하는 방법 가이드에서 살펴봅니다.

무엇을 쓰든 출시 주간보다 오래 두 가지가 지켜져야 합니다. 주소가 그대로여야 합니다. 다시는 신경 쓰지 않을 스토어 등록정보에 적혀 있기 때문입니다. 그리고 누군가 처음으로 설정을 “개선”할 때 앞에 리디렉션이 슬그머니 끼어들지 않고, 계속 일반 텍스트를 제공해야 합니다.

무언가를 바꿔도 바로 반영되지 않습니다

광고 네트워크는 자체 일정에 따라 다시 크롤링합니다. AdMob은 “it can take up to 24 hours for AdMob to crawl and verify your app-ads.txt files”(번역: AdMob이 app-ads.txt 파일을 크롤링하고 확인하는 데 최대 24시간이 걸릴 수 있습니다)라고 하며, 다른 네트워크는 더 느립니다. 한 시간 전에 업로드한 파일이 여전히 없다고 나온다면 거의 언제나 아직 이른 것뿐입니다. 다른 것을 바꾸기 전에 찾을 수 없음 가이드를 보세요.

AppFoyer가 여기서 하는 일

앱 페이지는 자체 하위 도메인에서 app-ads.txt를 제공합니다. 일반 텍스트, 200, 리디렉션 없음, 사양이 요구하는 헤더 포함입니다. 편집기는 입력하는 동안 각 줄을 검증하므로, 빠진 쉼표는 크롤러가 보기 전에 잡힙니다. 그 하위 도메인을 스토어 등록정보의 개발자 웹사이트로 설정하면 되며, appfoyer.page의 한 단계 아래입니다.

AdMob은 그곳에서 파일을 확인합니다. 2026년 10월, 개발자 웹사이트가 AppFoyer 주소인 앱들에 대해 “app-ads.txt file found and verified”(번역: app-ads.txt 파일을 찾았으며 확인됨)라고 보고했습니다. 다른 광고 네트워크에 대해서는 아직 저희가 직접 확보한 크롤링 결과가 없습니다.

공식 출처

• Set up app-ads.txt — AdMob 고객센터. 위에서 인용한 크롤러 규칙과 하위 도메인 예시는 이 페이지에서 가져왔습니다.
• ads.txt / app-ads.txt specification — IAB Tech Lab. 사양 그 자체이며, 줄 문법에 관한 권위 있는 출처입니다.