AX 엔지니어링 3 — AdMob 배너가 화면 아래를 128dp나 차지하고 있었습니다

들어가며

물타기 계산기를 에뮬레이터에 띄워 보다가 “광고 영역이 왜 이렇게 높아?”라는 말이 나왔습니다. 하단바 위의 빈 띠가 화면 아래를 크게 차지하고 있었습니다. 재 보니 약 128dp였습니다. 계산기 화면에서 결과 카드와 하단바 사이가 통째로 광고 자리였습니다.

결론부터 쓰면, 배너 크기를 인라인 적응형에 높이 상한 60dp로 바꿨습니다. deprecated 함수는 쓰지 않았습니다. 같은 문제가 있던 Pocket PDF에도 같은 규칙을 넣었습니다.

왜 128dp였나

배너 크기는 이렇게 청하고 있었습니다.

val size = AdSize.getLargeAnchoredAdaptiveBannerAdSize(context, widthDp)

“큰 앵커드 적응형” 배너입니다. 구글 문서에 따르면 이 배너는 스크롤하지 않는 화면을 위한 큰 형식이고, 높이가 50~150dp, 화면 높이의 20%까지 갑니다. 높이는 SDK가 정합니다. 폭 411dp 폰에서 약 128dp가 나왔습니다.

광고가 오면 화면이 밀리지 않도록 자리를 미리 그 높이만큼 잡아 둡니다. 그래서 광고가 오기 전에도 128dp짜리 빈 띠가 서 있었습니다.

예전 크기로 돌아갈 수 없었던 이유

이 앱은 9월 초까지 일반 앵커드 적응형을 썼습니다. 폰에서 약 60dp였습니다.

// 2026-09-05 ~ 09-26
val size = AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(context, widthDp)

그런데 SDK가 이 함수를 deprecated로 표시하면서 큰 쪽을 대신 가리켰습니다. deprecated 경고를 없애려고 큰 배너로 옮겼고, 그 대가로 화면 아래가 두 배 가까이 커졌습니다.

앱이 쓰는 SDK(25.5.0)의 AdSize를 직접 열어 보니 상황은 이랬습니다.

일반 앵커드 셋은 모두 deprecated였습니다. deprecated 함수로 돌아가면 높이는 해결되지만, 경고를 다시 덮어야 하고 언젠가 그 함수가 사라지는 날 다시 정해야 합니다.

같은 회사의 다른 앱인 Pocket PDF는 실제로 그렇게 하고 있었습니다. 큰 배너가 폴더블에서 140dp까지 커지자 일반 앵커드로 돌아가고, 경고는 @Suppress("DEPRECATION")로 덮었습니다.

높이를 우리가 정할 수 있는 길

deprecated가 아닌 것 중 높이를 줄일 수 있는 후보는 둘이었습니다.

**고정 크기 AdSize.BANNER(320×50)**는 deprecated가 아닙니다. 하지만 폭이 320dp로 고정이라 넓은 폰에서는 양옆이 빕니다.

**인라인 적응형 getInlineAdaptiveBannerAdSize(width, maxHeight)**는 폭은 우리가 주고, 높이는 SDK가 우리가 준 상한 안에서 고릅니다. 이름은 “인라인”이지만, 구글 문서는 스크롤하는 콘텐츠에서 인라인을 권할 뿐 고정 자리에 쓰지 말라고 하지는 않습니다.

Pocket PDF의 예전 주석에는 인라인 적응형을 거른 이유가 적혀 있었습니다. “인라인 적응형은 최대 높이만 받고 실제 높이는 광고가 와야 알려 주므로 자리를 미리 잡을 수 없다.” 맞는 말이지만, 상한 자체를 자리로 잡으면 이 걱정은 없어집니다. 광고는 그 안에 서고, 더 낮게 오면 가운데에 섭니다. 어떤 높이가 와도 화면은 밀리지 않습니다.

/** 배너 높이의 상한(dp) */
private const val BannerMaxHeightDp = 60

class BannerAd(context: Context, widthDp: Int) {
    /** 광고 자리의 높이 — 광고가 이보다 낮게 와도 자리는 그대로라 화면이 밀리지 않는다 */
    val heightDp: Int = BannerMaxHeightDp

    private val view = AdView(context).apply {
        setAdSize(AdSize.getInlineAdaptiveBannerAdSize(widthDp, BannerMaxHeightDp))
        adUnitId = AdUnits.BANNER
    }
}

Compose 쪽은 바뀐 것이 없습니다. 원래도 heightDp만큼 자리를 잡고 그 안에 AdView를 붙이고 있었습니다.

Box(
    modifier = Modifier
        .fillMaxWidth()
        .height(banner.heightDp.dp),
    contentAlignment = Alignment.Center,
) {
    AndroidView(factory = { FrameLayout(it) }, update = { banner.attachTo(it) })
}

60을 고른 이유는 예전 일반 앵커드 배너가 폰 세로에서 56~64dp였기 때문입니다. 표준 배너(50)보다 조금 여유를 둬서 SDK가 고를 칸을 남겼습니다.

두 앱의 높이는 이렇게 바뀌었습니다.

에뮬레이터에서 광고가 안 떴던 이유

바꾼 뒤 에뮬레이터에서 확인하려 했는데 광고 칸이 계속 비어 있었습니다. 바꾸기 전 큰 배너도 비어 있었으니 크기 문제는 아니었습니다. 원인이 세 겹이었습니다.

1. 광고를 그리는 WebView가 죽고 있었습니다

로그에 이런 줄이 약 90초마다 찍혔습니다.

E chromium: [ERROR:aw_browser_terminator.cc(154)] Renderer process crash detected

배너는 WebView로 그려집니다. 에뮬레이터가 메모리 부족으로 소프트웨어 그래픽으로 떠 있었고, 다른 에뮬레이터도 함께 돌고 있었습니다.

2. 에뮬레이터가 DNS를 풀지 못했습니다

앱을 다시 띄우니 WebView는 더 죽지 않았는데, 이번에는 광고 세 개가 30초 뒤 모두 실패했습니다.

I Ads : Ad failed to load : 0

IP로는 인터넷에 닿는데 이름을 못 풀고 있었습니다.

adb shell ping -c 1 8.8.8.8                      # 성공
adb shell ping -c 1 googleads.g.doubleclick.net  # unknown host

에뮬레이터 안에서 고치려 한 두 방법은 듣지 않았습니다. Private DNS를 dns.google로 바꾸면, 그 이름을 푸는 데에도 고장 난 DNS가 필요합니다. 루트로 네트워크 DNS를 바꾸는 ndc resolver 명령은 이 안드로이드 판에 없었습니다. 결국 에뮬레이터를 DNS 서버를 지정해 다시 띄웠습니다.

emulator -avd twinkle_pixel -dns-server 8.8.8.8,8.8.4.4

3. 다시 띄운 에뮬레이터에는 옛 빌드가 깔려 있었습니다

드디어 테스트 광고가 떴는데 여전히 컸습니다. 에뮬레이터를 다시 띄우면서 디스크가 예전 상태로 돌아가, 바꾸기 전 빌드가 깔려 있었기 때문입니다. 지금 빌드를 다시 깔자 테스트 배너가 60dp 칸에 폭을 다 채워 섰습니다.

에뮬레이터에서 광고가 안 뜨면 크기나 코드부터 의심하게 되는데, 이번에는 셋 다 코드 밖의 문제였습니다. 로그에서 Ads 태그와 chromium 태그를 같이 보는 습관이 도움이 됐습니다.

남은 것

• 수익: 큰 배너가 보통 수익이 더 높습니다. 출시 뒤 AdMob에서 채움률과 수익이 얼마나 달라지는지 봐야 합니다.
• 실기기: 에뮬레이터의 테스트 광고로만 확인했습니다. 실제 광고가 인라인 적응형 60dp 칸에 어떻게 서는지는 실기기와 출시 뒤에 봅니다.

정리

• 큰 앵커드 적응형 배너는 높이를 SDK가 정하고, 폰에서도 128dp까지 커질 수 있습니다.
• 일반 앵커드 적응형은 deprecated입니다. 높이를 우리가 정하면서 deprecated를 피하는 길은 인라인 적응형의 maxHeight입니다.
• 인라인 적응형은 실제 높이를 미리 알 수 없지만, 상한을 그대로 자리로 잡으면 화면이 밀리지 않습니다.
• 에뮬레이터에서 광고가 비면 WebView 렌더러와 DNS부터 확인합니다.