AdMob app-ads.txt 인증 오류 해결 방법 — Nginx 서버 설정부터 Google Play 연동까지

Android 앱에 Google AdMob 광고를 적용하고 앱을 출시했는데, AdMob 관리 화면에서 app-ads.txt 파일을 찾을 수 없다는 경고가 표시되는 경우가 있습니다.

서버에 파일을 업로드하고 브라우저에서 정상적으로 열리는 것까지 확인했는데도 AdMob에서는 인증되지 않은 상태가 유지되기도 합니다.

이런 문제는 단순히 파일이 존재하는지만 확인해서는 해결되지 않을 수 있습니다.

이번 글에서는 Spring Boot + Nginx 기반 서버를 운영하는 환경을 예시로 app-ads.txt 설정 방법과 인증 오류를 해결하는 과정을 정리하겠습니다.

1. app-ads.txt란?

app-ads.txt는 Authorized Sellers for Apps의 약자로, 앱 광고 인벤토리를 판매할 권한이 있는 광고 시스템을 공개적으로 선언하는 텍스트 파일입니다.

IAB Tech Lab에서 제안한 표준으로, 광고 구매자가 해당 앱의 승인된 광고 판매자를 확인하는 데 사용합니다.

예를 들어 Google AdMob을 사용한다면 다음과 같은 내용을 등록합니다.

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

각 항목의 의미는 다음과 같습니다.

항목의미
google.com광고 시스템 도메인
pub-XXXXXXXXXXXXXXXXAdMob 게시자 ID
DIRECT광고 시스템과 직접적인 판매 관계
f08c47fec0942fa0Google의 인증기관 ID

게시자 ID는 AdMob 계정에서 발급받은 실제 값을 사용해야 합니다.

app-ads.txt는 모든 앱에 법적으로 의무화된 파일은 아니지만, Google은 설정을 강력히 권장하고 있습니다.

특히 앱 사칭이나 승인되지 않은 광고 판매를 방지하는 데 도움이 됩니다.

2. AdMob이 app-ads.txt를 찾는 방법

여기서 가장 중요한 부분은 AdMob이 앱 내부에서 파일을 찾는 것이 아니라는 점입니다.

AdMob은 Google Play 또는 Apple App Store에 등록된 개발자 웹사이트 주소를 확인하고, 해당 도메인을 기준으로 파일을 검색합니다.

예를 들어 Google Play에 등록한 개발자 웹사이트가 다음과 같다고 가정하겠습니다.

https://www.example.com

AdMob 크롤러는 일반적으로 다음 주소에서 파일을 확인합니다.

https://example.com/app-ads.txt
http://example.com/app-ads.txt

www를 사용하는 웹사이트라면 특히 주의해야 합니다.

AdMob은 www를 제외한 루트 도메인을 기준으로 파일을 찾을 수 있으므로, 루트 도메인에서도 파일을 제공하거나 올바르게 리디렉션해야 합니다.

개발자 웹사이트에 다음 주소를 등록한 경우에도 마찬가지입니다.

https://example.com/privacy/myapp

AdMob은 개인정보처리방침 경로에 파일을 찾는 것이 아니라 호스트 이름을 기준으로 루트 경로를 검사합니다.

따라서 다음 주소에 파일을 배치해야 합니다.

https://example.com/app-ads.txt

3. app-ads.txt 파일 생성하기

먼저 서버에 배포할 텍스트 파일을 생성합니다.

Ubuntu 서버를 사용하는 경우 다음 명령어로 파일을 만들 수 있습니다.

sudo mkdir -p /var/www/admob

sudo nano /var/www/admob/app-ads.txt

파일 내용에는 AdMob에서 제공한 게시자 정보를 입력합니다.

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

여러 광고 시스템을 사용한다면 해당 시스템에서 안내하는 판매자 정보를 추가할 수 있습니다.

다만 임의의 판매자 정보를 추가하지 말고, 실제 사용하는 광고 플랫폼에서 제공한 내용을 사용해야 합니다.

파일을 저장한 뒤 권한을 설정합니다.

sudo chmod 644 /var/www/admob/app-ads.txt

파일은 Nginx 프로세스가 읽을 수 있어야 합니다.

4. Nginx에서 app-ads.txt 제공하기

Spring Boot 애플리케이션을 Nginx 뒤에서 실행하는 환경을 가정하겠습니다.

일반적인 구성은 다음과 같습니다.

인터넷 사용자
     |
     v
   Nginx
     |
     +-- /api/* ------> Spring Boot
     |
     +-- /privacy/* --> Spring Boot
     |
     +-- /app-ads.txt -> 정적 파일

이 구조에서는 app-ads.txt 요청을 Spring Boot까지 전달할 필요가 없습니다.

Nginx에서 파일을 직접 제공하면 됩니다.

Nginx 설정 예시

기존 HTTPS 서버 블록에 다음 location을 추가합니다.

location = /app-ads.txt {
    alias /var/www/admob/app-ads.txt;
    default_type text/plain;
}

location =은 정확히 /app-ads.txt 경로에 해당하는 요청을 처리합니다.

기존 Spring Boot 리버스 프록시 설정이 있더라도 정확한 경로를 지정한 location이 우선 적용됩니다.

예를 들어 다음과 같은 기존 설정이 있다고 가정하겠습니다.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    # 기존 SSL 인증서 설정은 유지

    location = /app-ads.txt {
        alias /var/www/admob/app-ads.txt;
        default_type text/plain;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}

이 코드는 구조를 설명하기 위한 예시입니다. 실제 운영 서버에서는 기존 SSL 인증서 설정, 다른 location, 보안 헤더 등을 유지해야 합니다.

설정 검사 및 적용

Nginx 설정을 변경했다면 먼저 문법을 확인합니다.

sudo nginx -t

정상적인 경우 설정 검사 성공 메시지가 표시됩니다.

이후 Nginx를 재로드합니다.

sudo systemctl reload nginx

기존 서버를 재시작하는 대신 설정을 재로드하므로 정상적인 연결에 대한 영향을 줄일 수 있습니다.

5. curl로 파일 접근 상태 확인하기

Nginx 설정이 끝났다면 서버 외부에서 파일에 접근할 수 있는지 확인해야 합니다.

브라우저로 확인하는 것도 가능하지만, 실제 문제를 분석할 때는 curl을 사용하는 것이 편리합니다.

HTTP 응답 헤더 확인

curl -I https://example.com/app-ads.txt

정상적인 경우 다음과 유사한 응답을 기대할 수 있습니다.

HTTP/2 200
content-type: text/plain

위 내용은 정상 응답의 예시입니다.

특히 HTTP 상태 코드가 200인지 확인해야 합니다.

파일 내용 확인

curl -sS https://example.com/app-ads.txt

다음과 같이 등록한 게시자 정보가 출력되어야 합니다.

google.com, pub-XXXXXXXXXXXXXXXX, DIRECT, f08c47fec0942fa0

브라우저에서는 정상적으로 보이지만 실제로 HTML 오류 페이지를 반환하는 서버도 있으므로 파일 내용을 확인하는 것이 좋습니다.

리디렉션 확인

curl -IL https://example.com/app-ads.txt

이 명령어는 리디렉션을 따라가며 최종 응답을 확인합니다.

예를 들어 다음과 같은 구조일 수 있습니다.

http://example.com/app-ads.txt
            |
            v
https://example.com/app-ads.txt
            |
            v
          200 OK

HTTP에서 HTTPS로 리디렉션하는 것은 일반적인 구성입니다.

다만 지나치게 복잡한 리디렉션이나 잘못된 호스트로 이동하는 설정은 피하는 것이 좋습니다.

6. app-ads.txt 인증 오류의 주요 원인

AdMob에서 파일을 찾지 못하는 문제는 여러 원인으로 발생할 수 있습니다.

원인 1. Google Play 개발자 웹사이트 주소 누락

AdMob은 앱 스토어에 등록된 개발자 웹사이트 정보를 사용합니다.

따라서 Play Console에서 웹사이트 주소가 등록되어 있는지 확인해야 합니다.

일반적인 확인 경로는 다음과 같습니다.

Google Play Console → 앱 정보 → 스토어 설정 → 스토어 등록정보 연락처 세부정보

메뉴 이름은 Play Console UI 변경에 따라 달라질 수 있습니다.

개발자 웹사이트 주소를 등록하거나 수정했다면 변경사항이 AdMob에 반영되기까지 시간이 걸릴 수 있습니다.

원인 2. app-ads.txt 파일 경로 오류

다음과 같은 위치에 파일을 업로드하면 AdMob에서 찾지 못할 수 있습니다.

https://example.com/files/app-ads.txt
https://example.com/privacy/app-ads.txt
https://example.com/assets/app-ads.txt

일반적으로 파일은 다음 주소에서 접근할 수 있어야 합니다.

https://example.com/app-ads.txt

웹사이트가 Spring Boot로 구성되어 있더라도 반드시 Spring Boot의 정적 리소스 폴더에 저장해야 하는 것은 아닙니다.

Nginx가 해당 URL에서 올바른 파일을 제공하면 됩니다.

원인 3. www와 루트 도메인 설정 차이

웹사이트가 다음 주소에서만 정상적으로 동작하는 경우가 있습니다.

https://www.example.com

반면 다음 주소에서는 오류가 발생할 수 있습니다.

https://example.com

AdMob 크롤러는 루트 도메인을 기준으로 파일을 확인할 수 있으므로 두 주소의 동작을 점검해야 합니다.

다음 명령어로 각각 확인합니다.

curl -IL https://example.com/app-ads.txt

curl -IL https://www.example.com/app-ads.txt

두 주소가 반드시 독립적으로 200 응답을 반환해야 하는 것은 아닙니다.

한쪽에서 다른 쪽으로 정상적으로 리디렉션되어 최종적으로 파일을 제공하는 방식도 사용할 수 있습니다.

원인 4. robots.txt에서 크롤러 차단

robots.txt 파일에 크롤러 접근을 제한하는 설정이 있으면 AdMob에서 파일을 읽지 못할 수 있습니다.

예를 들어 다음 설정을 확인해야 합니다.

User-agent: *
Disallow: /

이 설정은 일반적인 크롤러 접근을 차단합니다.

AdMob의 app-ads.txt 크롤러 접근을 명시적으로 허용하려면 다음과 같이 설정할 수 있습니다.

User-agent: Google-adstxt
Disallow:

다만 다른 그룹에 있는 Googlebot, Mediapartners-Google 관련 차단 규칙도 확인해야 합니다.

robots.txt를 수정할 때는 사이트 전체의 검색엔진 접근 정책에 영향을 주지 않도록 주의해야 합니다.

원인 5. 게시자 ID 오류

파일이 정상적으로 제공되더라도 게시자 ID가 틀리면 인증에 실패할 수 있습니다.

다음과 같은 실수를 확인해야 합니다.

  • AdMob 게시자 ID를 잘못 입력한 경우

  • pub- 접두사를 누락한 경우

  • 광고 단위 ID를 게시자 ID 대신 사용한 경우

  • google.com을 잘못 입력한 경우

  • 불필요한 문자가 포함된 경우

가장 안전한 방법은 AdMob 관리 화면에서 제공하는 app-ads.txt 내용을 그대로 복사하는 것입니다.

원인 6. AdMob 크롤링 대기

서버 설정과 파일 내용이 모두 정상인데도 인증 상태가 즉시 변경되지 않을 수 있습니다.

Google 공식 안내에 따르면 최초 크롤링과 확인에 최대 24시간이 걸릴 수 있습니다.

스토어의 개발자 웹사이트 주소를 최근 변경했다면 변경사항 감지에도 시간이 필요합니다.

또한 실제 상태 반영에는 며칠이 걸릴 수 있으며, 광고 요청이 적은 사이트는 더 오래 걸릴 수도 있습니다.

따라서 파일을 수정한 직후 인증 상태가 바뀌지 않는다고 해서 서버 설정을 반복적으로 변경할 필요는 없습니다.

7. Spring Boot에서 직접 제공하는 방법

Nginx 설정을 변경하기 어렵다면 Spring Boot에서 파일을 제공하는 방법도 있습니다.

Spring Boot의 정적 리소스 폴더에 파일을 배치합니다.

src/
└── main/
    └── resources/
        └── static/
            └── app-ads.txt

Spring Boot는 기본적으로 static 디렉터리의 파일을 정적 리소스로 제공할 수 있습니다.

따라서 별도의 컨트롤러 없이 다음 주소에서 접근할 수 있습니다.

https://example.com/app-ads.txt

다만 Spring Security를 사용하는 경우에는 해당 경로가 인증 없이 접근 가능한지 확인해야 합니다.

예를 들어 Spring Security 6에서는 다음과 같이 설정할 수 있습니다.

@Bean
SecurityFilterChain securityFilterChain(
        HttpSecurity http
) throws Exception {

    http.authorizeHttpRequests(auth -> auth
        .requestMatchers("/app-ads.txt").permitAll()
        .anyRequest().authenticated()
    );

    return http.build();
}

위 코드는 접근 권한 설정을 설명하는 최소 예시입니다.

기존 프로젝트의 로그인, CSRF, 세션, API 인증 등 다른 보안 설정을 삭제하거나 이 코드로 전체 교체해서는 안 됩니다.

실제 운영 환경에서는 기존 SecurityFilterChain에 해당 경로만 추가하는 것이 안전합니다.

8. 여러 앱에서 하나의 app-ads.txt 파일 사용하기

하나의 개발자 계정으로 여러 앱을 운영하는 경우에도 앱마다 별도의 app-ads.txt 파일을 만들 필요는 없습니다.

예를 들어 여러 Android 앱의 개발자 웹사이트를 동일한 도메인으로 등록할 수 있습니다.

앱 A ─┐
앱 B ─┼──> example.com/app-ads.txt
앱 C ─┘

모든 앱이 같은 AdMob 게시자 계정을 사용한다면 하나의 게시자 항목으로 여러 앱을 인증할 수 있습니다.

반대로 여러 광고 판매자 계정을 사용한다면 필요한 판매자 항목을 파일에 각각 추가해야 할 수 있습니다.

중요한 것은 각 앱의 스토어 등록정보와 파일의 게시자 정보가 올바르게 연결되어 있어야 한다는 점입니다.

9. Netlify에서 app-ads.txt 제공하기

정적 웹사이트를 Netlify로 운영한다면 app-ads.txt 파일을 함께 배포할 수 있습니다.

예를 들어 다음과 같은 구조입니다.

my-website/
├── index.html
├── app-ads.txt
└── assets/

이 폴더를 Netlify에 배포하면 사이트 루트에서 파일을 제공할 수 있습니다.

Astro를 사용하는 경우에는 다음과 같이 public 디렉터리에 배치하면 됩니다.

astro-project/
├── public/
│   └── app-ads.txt
├── src/
│   └── pages/
│       └── index.astro
└── astro.config.mjs

Astro의 public 디렉터리에 있는 파일은 빌드 결과물에 그대로 복사됩니다.

배포 후 다음 주소를 확인합니다.

https://example.netlify.app/app-ads.txt

단, 실제 AdMob 인증에는 앱 스토어에 등록된 개발자 웹사이트 도메인과 파일 위치가 일치해야 합니다.

Netlify의 임시 주소에 파일을 배포했다는 사실만으로 다른 도메인의 app-ads.txt 인증이 완료되는 것은 아닙니다.

10. 문제 해결을 위한 점검 순서

app-ads.txt 인증 오류가 발생하면 다음 순서로 확인하는 것을 추천합니다.

1단계. AdMob에서 안내하는 app-ads.txt URL을 확인합니다.

2단계. Google Play에 등록된 개발자 웹사이트 주소를 확인합니다.

3단계. 해당 도메인의 /app-ads.txt 파일에 접근할 수 있는지 확인합니다.

4단계. curl을 이용해 HTTP 응답 코드와 실제 파일 내용을 검사합니다.

5단계. 루트 도메인과 www 리디렉션을 확인합니다.

6단계. robots.txt의 크롤러 차단 여부를 확인합니다.

7단계. 게시자 ID가 AdMob 계정의 정보와 일치하는지 확인합니다.

8단계. 필요한 경우 서버 설정을 수정하고 크롤링 결과를 기다립니다.

이 순서대로 확인하면 단순 파일 누락부터 DNS, 리디렉션, 게시자 ID 문제까지 체계적으로 점검할 수 있습니다.

11. 운영 서버에서 주의할 점

Nginx와 Spring Boot를 함께 사용하는 서버라면 다음 사항을 주의해야 합니다.

기존 리버스 프록시 설정 유지

app-ads.txt를 제공하기 위해 기존 location / 설정을 삭제하거나 변경할 필요는 없습니다.

정확한 파일 경로에 대한 location만 추가하는 편이 안전합니다.

HTTPS 인증서 확인

www와 루트 도메인을 모두 사용하는 경우 SSL 인증서가 해당 호스트를 지원하는지 확인해야 합니다.

파일 접근 권한 확인

Nginx가 파일을 읽을 수 없는 경우 HTTP 403 오류가 발생할 수 있습니다.

파일뿐 아니라 상위 디렉터리의 접근 권한도 확인해야 합니다.

서버 로그 확인

문제가 계속 발생한다면 Nginx 로그를 확인합니다.

sudo tail -f /var/log/nginx/access.log

오류 로그도 확인할 수 있습니다.

sudo tail -f /var/log/nginx/error.log

로그 파일의 실제 경로는 Nginx 설정에 따라 다를 수 있습니다.

접근 로그에서 app-ads.txt 요청과 응답 상태를 확인하면 서버가 요청을 어떻게 처리했는지 분석하는 데 도움이 됩니다.

다만 특정 크롤러의 요청이 보이지 않는다는 이유만으로 Google이 아직 접근하지 않았다고 단정할 수는 없습니다. CDN, 프록시, 로그 설정에 따라 기록 위치가 달라질 수 있기 때문입니다.

12. 최종 점검 체크리스트

  • Google Play에 개발자 웹사이트 URL 등록

  • app-ads.txt 파일 생성

  • 올바른 AdMob 게시자 ID 입력

  • 루트 도메인에서 파일 접근 가능

  • HTTP 200 응답 확인

  • 파일 내용이 HTML이 아닌 일반 텍스트인지 확인

  • www 및 HTTPS 리디렉션 확인

  • robots.txt 크롤러 접근 확인

  • Nginx 또는 Spring Boot 보안 설정 확인

  • AdMob 크롤링 및 인증 상태 확인

13. 마무리

AdMob의 app-ads.txt 인증 오류는 파일 자체의 문제보다 도메인과 서버 설정에서 발생하는 경우가 많습니다.

특히 개발자 웹사이트를 별도로 운영하고 있다면 Google Play 등록정보, Nginx 설정, 파일 경로를 함께 확인해야 합니다.

문제 해결에서 중요한 것은 다음 세 가지입니다.

  1. AdMob이 실제로 검사하는 도메인을 확인합니다.

  2. 해당 도메인의 루트 경로에서 올바른 파일을 제공해야 합니다.

  3. HTTP 응답, 리디렉션, 크롤러 접근과 게시자 ID를 검증합니다.

Spring Boot와 Nginx를 함께 사용하는 환경에서는 Nginx에서 정적 파일을 직접 제공하는 방법이 간단하고 관리하기 편리합니다.

다만 기존 서버 구성을 유지해야 하므로, 실제 운영 환경에 맞춰 적용하는 것이 중요합니다.


참고 자료

태그: Android, AdMob, app-ads.txt, Google Play, Nginx, Spring Boot, Ubuntu, 광고 수익화, 앱 개발, 서버 설정