Android 앱 화면 아래에 배너 광고를 붙였다.

Google Mobile Ads SDK 초기화도 실행됐고 광고가 들어갈 자리도 만들어 두었다.

직접 만든 APK가 아니라 Google Play 내부 테스트로 배포한 앱을 실제 휴대전화에 설치했다.

앱은 정상적으로 열렸지만 광고는 보이지 않았다.

화면 아래에 빈 막대조차 없어서 처음에는 광고 컨테이너나 안전 영역 계산을 의심했다.

하지만 이번 원인은 앱 화면이 아니었다.

광고 SDK가 실행됐는데도 AdMob 배너가 보이지 않는다면 어디부터 확인해야 할까?

광고가 안 보인다는 결과부터 나눴다

광고가 안 보인다는 결과는 같아도 원인은 여러 단계에 있을 수 있다.

화면만 보고 원인을 정하지 않고 코드, Android 로그, AdMob Console과 Google Play 상태를 순서대로 확인했다.

테스트 광고와 운영 광고는 다르다

개발 중에는 Google이 제공하는 테스트 광고 단위를 사용해야 한다.

테스트 광고는 실제 수익 광고와 분리되어 있고 개발자가 자신의 운영 광고를 반복해서 누르는 문제도 피할 수 있다.

릴리즈 빌드에는 운영용 AdMob 앱 ID와 배너 광고 단위 ID가 필요하다.

개발 빌드에는 테스트 ID를 사용하고 릴리즈 빌드에는 운영 ID가 없으면 빌드가 실패하도록 구성했다.

하지만 운영 ID가 들어 있다는 사실은 광고 게재 승인이 끝났다는 뜻이 아니다.

ID는 광고 요청을 어느 앱과 광고 단위로 보낼지 정할 뿐이다.

쉬운 설명: SDK는 광고 기능을 앱에 넣는 도구 모음이고, 앱 ID는 앱을 구분하며 광고 단위 ID는 광고가 들어갈 자리를 구분한다.

개인정보 동의가 광고 요청보다 먼저다

동의가 필요한 지역을 고려하면 앱 시작과 동시에 광고부터 요청해서는 안 된다.

Google UMP SDK에서 동의 정보를 갱신하고 필요한 화면을 처리한 뒤 canRequestAds()가 허용될 때 광고를 요청했다.

동의 화면이 필요하지 않은 사용자도 이 흐름을 통과한 다음 광고 요청 단계로 이동한다.

그래서 SDK 초기화 로그만으로 실제 광고 요청까지 나갔다고 단정할 수 없었다.

UMP 정보 갱신, canRequestAds() 결과, 광고 요청 시작과 로드 성공·실패 콜백을 각각 확인해야 했다.

쉬운 설명: UMP는 사용자에게 광고 관련 동의를 묻는 도구이고, canRequestAds()는 지금 광고를 요청해도 되는지 알려 주는 확인값이다.

빈 광고 영역이 없었던 이유

광고가 정상적으로 로드됐을 때만 하단 컨테이너를 보여주도록 만들었다.

로드에 실패하면 컨테이너 높이와 WebView 아래 여백을 함께 제거했다.

사용자에게 광고 대신 빈 회색 막대를 남기지 않기 위한 처리였다.

따라서 화면 아래에 아무것도 없다는 사실은 레이아웃 코드가 실행되지 않았다는 증거가 아니었다.

오히려 실패 상태를 의도대로 처리한 것이었다.

Android 로그에서 확인한 것

Google Play 내부 테스트 설치본을 실행하고 ADB 로그를 확인했다.

앱 프로세스는 정상적으로 실행됐고 크래시나 ANR은 없었다.

Google Mobile Ads SDK 초기화와 광고 네트워크 연결도 실행되고 있었다.

설치 출처는 com.android.vending으로 표시되어 직접 설치한 APK가 아니라 Google Play 설치본임을 확인했다.

쉬운 설명: ADB는 휴대전화의 실행 기록을 확인하는 도구이고, ANR은 앱이 멈춰 사용자 입력에 반응하지 않는 상태를 뜻한다.

하지만 SDK가 초기화됐다는 사실만으로 광고가 서버에서 내려왔다는 뜻은 아니었다.

다음 확인 지점은 AdMob Console이었다.

실제 원인은 AdMob의 준비 상태였다

AdMob Console에서 계정은 승인 진행 중이었다.

앱에는 검토 필요, 광고 게재 제한과 스토어 추가 필요 상태가 표시됐다.

광고 요청 수도 0이었다.

이 상태에서는 UI 코드를 고쳐도 운영 광고가 갑자기 나타나지 않는다.

AdMob이 앱을 공개 스토어에서 확인하고 광고 게재를 승인하는 과정이 남아 있었기 때문이다.

내부 테스트와 공개 스토어는 다르다

Google Play 내부 테스트 앱은 초대받은 테스터만 접근할 수 있다.

Play에서 설치할 수 있어도 일반 사용자의 검색 결과에 나타나는 공개 등록정보는 아니다.

AdMob에서 Android application ID와 내부 테스트 URL로 검색했지만 앱을 찾지 못했다.

등록하지 않은 다른 앱 스토어를 선택해 억지로 넘어가는 것은 올바른 해결이 아니었다.

실제 Google Play 등록정보가 공개된 뒤 정확한 앱을 연결해야 한다.

그래서 프로덕션 출시 심사를 먼저 제출하고 공개 등록정보가 생긴 뒤 AdMob 연결과 앱 검토를 다시 진행하기로 했다.

현재 프로덕션 버전은 심사 중이며 아직 공개 완료 상태가 아니다.

쉬운 설명: 내부 테스트는 초대받은 사람만 설치할 수 있고, 프로덕션 공개가 끝나야 누구나 찾을 수 있는 스토어 앱이 된다.

app-ads.txt는 승인과 다른 단계다

AdMob은 개발자 웹사이트 루트의 app-ads.txt를 통해 광고 인벤토리를 판매할 권한이 있는 게시자를 확인한다.

처음 확인했을 때 해당 주소는 404를 반환했다.

사이트 루트에 AdMob이 제공한 레코드를 추가한 뒤 HTTP 200과 정확한 파일 내용을 확인했다.

하지만 app-ads.txt가 정상이라고 광고가 즉시 나오는 것은 아니다.

이 다섯 항목은 서로 다른 단계다.

쉬운 설명: app-ads.txt는 이 사이트의 운영자가 앱 광고를 판매할 권한이 있다는 것을 광고 회사에 알려 주는 공개 확인 파일이다.

Android 13의 광고 ID 선언

Google Mobile Ads SDK가 포함된 앱은 병합된 매니페스트에 com.google.android.gms.permission.AD_ID 권한이 들어갈 수 있다.

Android 13 이상을 대상으로 하는 앱은 Play Console에서도 광고 ID 사용 여부를 선언해야 한다.

프로덕션 제출 직전에 광고 ID 선언이 빠졌다는 차단 메시지가 나타났다.

실제 SDK 사용과 매니페스트 권한을 확인한 뒤 광고 ID를 사용한다고 답했다.

사용 목적은 분석, 광고 또는 마케팅, 사기 예방·보안·규정 준수로 작성했다.

이 답변은 데이터 보안 양식과도 일치해야 한다.

쉬운 설명: 광고 ID는 기기 자체의 고유번호가 아니라 광고 제공과 성과 측정에 사용하는 재설정 가능한 식별값이다.

처리 순서 요약

  1. 개발 빌드에서 Google 공식 테스트 광고가 표시되는지 확인한다.
  2. 릴리즈 빌드에 운영 AdMob 앱 ID와 광고 단위 ID가 들어갔는지 확인한다.
  3. UMP 동의 처리 후 canRequestAds()가 허용되는지 확인한다.
  4. 광고 요청과 성공·실패 콜백을 Android 로그에서 확인한다.
  5. 광고 실패 시 컨테이너를 숨기는 코드가 있는지 확인한다.
  6. AdMob의 계정 승인, 앱 검토와 광고 게재 제한 상태를 확인한다.
  7. AdMob의 광고 요청 수가 실제로 증가하는지 확인한다.
  8. 공개 Google Play 등록정보가 AdMob 앱에 연결됐는지 확인한다.
  9. 공개 주소에서 app-ads.txt가 정확히 열리는지 확인한다.
  10. Play Console의 광고, 데이터 보안과 광고 ID 선언이 실제 SDK 사용과 일치하는지 확인한다.

이 순서의 핵심은 화면 수정부터 시작하지 않는 것이다.

요청이 나가지 않았다면 UI 문제가 아니고 요청은 나갔지만 계정이 제한됐다면 앱 코드만으로 해결할 수 없다.

이번 작업에서는 배너 위치, 실패 시 컨테이너 제거, UMP 동의 순서와 Google Play 설치본의 SDK 실행까지 확인했다.

반면 운영 광고 노출은 프로덕션 공개, AdMob 스토어 연결과 앱 검토가 끝난 뒤 다시 검증해야 한다.

광고 연동은 코드 한 줄이 아니라 앱, 동의, 스토어, 계정 심사와 게시자 파일이 이어지는 하나의 흐름이었다.

한 줄 요약: AdMob 광고가 보이지 않을 때는 배너 UI부터 고치지 말고 테스트 광고, 동의 후 요청 여부, Android 로그, AdMob 승인·앱 검토, 공개 스토어 연결과 app-ads.txt를 순서대로 확인해야 한다.