[Android] AdMob 배너 광고 레이아웃 깨짐 방지 및 가변 크기(Adaptive Banner) 적용 방법

앱을 운영하다 보면 AdMob 배너 광고를 붙여야 할 때가 많습니다. 저의 경우도 하단에 배너를 달아두고 운영 중인데, 최근 나오는 Android 기기들은 화면 크기나 비율이 워낙 제각각이라(폴더블, 태블릿, 가로 모드 등) 고정 크기 배너만 고집하면 레이아웃이 붕 뜨거나 어색하게 깨지는 문제가 발생하더군요.

자꾸 까먹기도 하고 실무에서 매번 찾아보기 귀찮아서, 안정적으로 배너 광고를 올리는 레이아웃 구조와 가변 배너(Anchored Adaptive Banner) 적용 방법을 정리해 둡니다.

1. 배너 광고 적용 시 자주 겪는 문제와 원인

단순히 "화면 아래에 View 하나 얹으면 되겠지" 하고 접근하면 운영하다가 꼭 아래와 같은 안 좋은 상황을 마주하게 됩니다.

  • 레이아웃 튐 현상: 광고가 로딩되기 전에는 높이가 0이었다가, 광고가 로드되는 순간 갑자기 화면이 툭 밀려 내려가면서 사용자가 버튼을 잘못 누르는 오인 클릭이 발생합니다.

  • 화면 크기 미대응: XML에 320x50 같은 고정 크기만 넣어두면 태블릿이나 가로 모드에서 양옆이 훤히 비어 보입니다.

  • 메모리 누수: Fragment나 Activity가 종료될 때 리소스를 제대로 해제하지 않으면 메모리를 계속 잡아먹습니다.

  • 정책 위반 위험: UMP(개인정보 동의) 흐름이 끝나기도 전에 광고를 요청하거나, 개발 중에 실제 광고 ID를 그대로 박아서 테스트하면 계정이 정지될 수 있습니다.

따라서 배너는 광고 컨테이너 높이, 화면 회전, 라이프사이클 관리를 처음부터 세트로 묶어서 설계해야 안전합니다.

2. 해결 방법: XML 레이아웃 구조 잡기

광고를 콘텐츠 위에 겹쳐 올리면 100% 버튼 오인 클릭으로 구글 경고를 받거나 사용자 원성을 삽니다. 아예 콘텐츠 영역과 광고 영역을 아래처럼 확실하게 분리해 주는 것이 좋습니다.

XML
<androidx.constraintlayout.widget.ConstraintLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <FrameLayout
        android:id="@+id/contentContainer"
        android:layout_width="0dp"
        android:layout_height="0dp"
        app:layout_constraintTop_toTopOf="parent"
        app:layout_constraintBottom_toTopOf="@id/adContainer"
        app:layout_constraintStart_of="parent"
        app:layout_end_of="parent" />

    <FrameLayout
        android:id="@+id/adContainer"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:minHeight="50dp"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_of="parent"
        app:layout_end_of="parent" />

</androidx.constraintlayout.widget.ConstraintLayout>

Tip: 광고 컨테이너에 android:minHeight="50dp" 정도로 최소 높이를 잡아두면, 광고가 늦게 뜨더라도 밑에 공간이 미리 확보되어 있어서 레이아웃이 위아래로 출렁거리는 현상을 막을 수 있습니다.

3. Kotlin 구현 코드 (Adaptive Banner 적용 및 해제)

공식 문서에서도 일반적인 상/하단 배너에는 화면 폭에 맞춰 높이가 결정되는 Anchored adaptive banner 방식을 권장합니다. 현재 디바이스의 가로 폭(dp)을 구해서 동적으로 광고 크기를 요청하는 컨트롤러 클래스 예시입니다.

Kotlin
class BannerAdController(
    private val activity: Activity,
    private val adContainer: FrameLayout,
    private val adUnitId: String,
) {
    private var adView: AdView? = null

    fun load() {
        // 현재 컨테이너 폭이나 디바이스 폭을 기준으로 dp 단위 가로 크기 계산
        val widthPx = adContainer.width.takeIf { it > 0 }
            ?: activity.resources.displayMetrics.widthPixels
        val density = activity.resources.displayMetrics.density
        val adWidth = (widthPx / density).toInt()

        val bannerView = AdView(activity).apply {
            // 현재 방향과 가로 폭에 맞는 가변 배너 사이즈 설정
            setAdSize(
                AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize(
                    activity,
                    adWidth,
                ),
            )
            this.adUnitId = adUnitId
            adListener = object : AdListener() {
                override fun onAdFailedToLoad(error: LoadAdError) {
                    // 실무 운영 시 에러 코드 정도만 로그를 남기고, 광고 ID는 로그에 찍지 마세요.
                }
            }
        }

        // 기존 뷰 정리 후 교체
        adContainer.removeAllViews()
        adContainer.addView(bannerView)
        adView = bannerView

        // 광고 로드
        bannerView.loadAd(AdRequest.Builder().build())
    }

    // Activity나 Fragment의 onDestroy에서 반드시 호출해줘야 메모리 누수가 안 납니다.
    fun destroy() {
        adContainer.removeAllViews()
        adView?.destroy()
        adView = null
    }
}

배너 형식 선택 가이드

운영 중인 화면의 성격에 따라 배너 타입을 맞춰서 써야 뷰가 안 깨집니다.

배너 종류설명추천 상황
Anchored adaptive화면 폭에 맞춰 높이가 자동 결정되는 고정 위치 배너일반적인 상단 / 하단 고정 레이아웃
Inline adaptive스크롤 영역 안에 들어가는 가변 높이 배너피드 목록, 기사 본문 중간 삽입
Fixed banner320x50 등 딱 정해진 dp 크기 사용구형 UI 유지나 특수 목적 레이아웃

4. 실무 운영 시 핵심 체크리스트

코드를 잘 짜놓고도 삐끗하면 계정이 날아가거나 심사 거절을 당하기 십상입니다. 제 경험상 아래 네 가지는 무조건 배포 전에 확인하셔야 합니다.

① UMP 동의 흐름 직후 로드하기

유럽연합 기준(및 최신 정책)으로 UMP 동의 팝업 처리가 완전히 끝나고 광고 요청이 가능한 상태(ConsentStatus)가 되었을 때 배너 로드 함수를 호출해야 안전합니다. 동의를 안 받았거나 거부된 상태에서 무작정 로드 함수부터 돌리면 안 됩니다.

② 테스트 광고 ID 철저 분리

개발이나 테스트 기기에서 실제 운영 광고 ID를 호출해 버리면 무효 클릭 트래픽으로 계정이 정지될 수 있습니다. BuildConfig나 빌드 플래버를 나눠서 개발 빌드에는 무조건 AdMob 공식 테스트 ID를 쓰도록 격리해 두세요.

  • Android 배너 테스트 광고 단위 ID: ca-app-pub-3940256099942544/6300978111

  • 주의: 실제 광고 ID나 테스트 디바이스 해시값은 GitHub 같은 공개 저장소에 소스코드로 커밋되지 않도록 마스킹 처리가 필수입니다.

③ 주요 조작 버튼과의 안전거리 확보

하단 내비게이션 바 바로 위에 배너를 바짝 붙여놓거나, '다음 단계' 버튼 바로 밑에 배너를 두면 오인 클릭 유도로 제재를 받습니다. 마진(Margin)을 주거나 경계선을 명확히 긋는 편이 좋습니다.

5. 마치며 (요약)

  • XML 레이아웃에서 콘텐츠 영역과 광고 컨테이너 영역을 겹치지 않게 완전히 분리하자.

  • AdSize.getCurrentOrientationAnchoredAdaptiveBannerAdSize를 써서 기기 대응을 해주자.

  • Activity/Fragment 생명주기에 맞춰 destroy() 처리를 안 하면 메모리가 질질 샌다.

  • 실제 광고 ID 관리는 소스코드에 날것으로 노출하지 말고 빌드 환경별로 분리해서 주입하자.

배너 광고의 핵심은 많이 노출해서 클릭을 유도하는 게 아니라, 사용자가 앱 서비스를 이용하는 흐름을 방해하지 않으면서 묵묵히 제자리에 붙어 있게 만드는 것입니다. 혹시 지금 고정 크기로 띄워둔 배너가 있다면 가변 배너 구조로 가볍게 변경해 보시는 걸 권장합니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

안드로이드 화면 꺼짐 방지 FLAG_KEEP_SCREEN_ON 및 WakeLock 적용 방법

이래저래 시험 타이머나 운동 기록, 지도 내비게이션 같은 앱을 개발하다 보면 사용자가 화면을 가만히 쳐다보고 있어야 하는 상황이 자주 생깁니다. 이때 대충 구현하면 스마트폰 설정에라 맞춰진 화면 자동 꺼짐 시간 때문에 화면이 픽 꺼져버려서 사용자가 불편을 겪게 됩니다. 처음에는 그냥 "화면 안 꺼지게 백그라운드에서 계속 돌리면 되겠지" 하고 접근하기 쉬운데, 운영하다 보면 배터리가 광탈하거나 앱을 껐는데도 화면이 계속 켜져 있는 등 온갖 버그성 문제가 터지곤 합니다. 저의 경우도 타이머 앱을 만들 때 화면 유지와 백그라운드 상태 관리를 제대로 분리하지 못해 고생했던 기억이 있습니다. 자꾸 까먹기도 하고 나중에 프로젝트할 때 바로 복사해서 쓰려고 실무 기준으로 핵심만 정리해 둡니다. 헷갈리기 쉬운 핵심 개념: 화면 유지 vs CPU 작업 유지 가장 먼저 확인해야 할 점은 화면만 계속 켜둘 것인가 , 아니면 화면이 꺼져도 내부 CPU 연산(작업)을 계속 돌릴 것인가 를 명확히 구분하는 것입니다. 이걸 혼동하면 안 써도 되는 무거운 권한을 쓰거나 배터리 이슈가 발생합니다. 저의 경우 아래 표를 기준으로 상황에 맞게 기술을 선택해 적용하고 있습니다. 구분 목적 대표 방식 적합한 상황 주의할 점 화면 유지 현재 화면을 계속 보이게 함 FLAG_KEEP_SCREEN_ON 타이머, 영상, 지도 화면 화면을 벗어나면 해제 필수 CPU 작업 유지 화면이 꺼져도 작업 계속 실행 WakeLock , Foreground Service 녹음, 위치 추적, 긴 다운로드 배터리 소모 및 구글 정책 검토 예약/재시도 작업 조건 충족 시 백그라운드 실행 WorkManager 서버 데이터 동기화, 업로드 즉시 실행 보장 안 됨 상태 복구 앱 재진입 시 시간 재계산 저장 시각 + 현재 시각 비교 시험 타이머, 카운트다운 화면 유지와 별개로 설계 필요 단순히 타이머 숫자를 화면에 계속 보여줘야 하는 수준이라면 복잡하게 생각할 것 없이 FLAG_KEEP_SCREEN_ON 하나면...
자세한 내용 보기

안드로이드 백그라운드 타이머 구현 및 Foreground Service 알림 설계 정리

타이머 앱을 만들고 운영하다 보면 백그라운드 처리 때문에 골치 아픈 일이 많습니다. 화면이 켜져 있을 때는 잘 돌다가도, 사용자가 홈 버튼을 누르고 다른 앱을 보거나 화면을 꺼버리면 타이머가 멈추거나 종료 알림이 안 오는 현상이 발생하곤 합니다. 처음에는 무조건 Foreground Service로 다 돌리면 해결될 줄 알았는데, 실제 서비스를 운영해 보니 배터리 소모나 구글 플레이 정책 측면에서 고려할 게 한두 가지가 아니었습니다. 자꾸 까먹어서 나중에도 바로 보고 적용할 수 있도록 실무 기준으로 정리해 둡니다. 백그라운드 타이머 운영 시 자주 겪는 문제 보통 처음 구현할 때 아래와 같은 지점에서 막히거나 실수를 많이 합니다. 화면이 꺼지면 타이머가 같이 멈춰버리는 현상 앱을 백그라운드로 보낸 뒤 타이머 종료 알림이 먹통이 되는 상황 모든 카운트다운을 무조건 Foreground Service로 처리해서 배터리를 낭비하는 구조 상단 알림창에 일시정지, 재개, 종료 같은 제어 버튼이 없는 불편함 알림 채널 중요도를 너무 높여서 사용자에게 과도한 피로감을 주는 경우 PendingIntent 나 로그에 사용자 ID나 민감한 데이터를 그대로 남기는 보안 실수 백그라운드 타이머를 작업할 때는 "코드를 백그라운드에서 계속 실행한다"가 아니라, "사용자가 인지할 수 있는 지속된 작업과 종료 알림을 조합한다"로 접근하는 것이 운영상 훨씬 안전합니다. 핵심 개념: 계산은 상태로, 표시는 알림으로 분리 타이머의 남은 시간은 매초 줄어드는 루프 코드가 아니라, 시작 기준 시각과 현재 시각의 차이 로 계산하는 것이 정석입니다. Foreground Service는 시간을 계산하는 주체가 아니라, 백그라운드에서도 사용자에게 "타이머가 돌고 있다"는 것을 보여주고 제어할 수 있게 돕는 창구일 뿐입니다. 저의 경우 아래와 같이 역할을 나누어 구조를 잡았습니다. 구성 요소 역할 주의할 점 TimerSession 시작 시각, 전체 시간, 일...
자세한 내용 보기

관광 앱 다국어 데이터 모델 및 검색 색인 설계 (자꾸 까먹어서 정리)

관광 앱을 개발하거나 서비스를 운영하다 보면 외국인 여행자를 위해 다국어를 지원해야 하는 일이 꼭 생깁니다. 처음에는 단순히 앱 내 UI 문자열( strings.xml )만 번역하면 끝날 줄 알았는데, 실제 서비스를 돌려보니 장소명이나 지역명 같은 콘텐츠 데이터 처리 가 진짜 번역의 핵심이더군요. 특히 공공데이터를 가져와서 쓰다 보면 한국어만 달랑 있거나, 영문 표기 방식이 데이터 소스마다 제각각이라 데이터가 다 깨집니다. 저의 경우도 "제주시", "Jeju-si", "Jeju City"가 마구 뒤섞여서 검색도 안 되고 화면도 깨지는 삽질을 좀 했습니다. 나중에 또 같은 문제로 고생하지 않으려고 표시 이름, 내부 지역 코드 표준화, Fallback 처리, 그리고 검색 색인 구조까지 실무에서 바로 쓸 수 있게 정리해 둡니다. 1. 기본 개념: 표시 이름과 원본 이름 분리하기 공공데이터에서 가져온 원본 이름을 그대로 덮어써 버리면, 나중에 번역 데이터가 바뀌거나 원본 데이터가 업데이트될 때 매칭할 기준이 사라집니다. 원본 이름은 그대로 보존하고, UI 표시용과 로마자 표기를 별도로 분리해서 관리 해야 유지보수가 쉬워집니다. 항목 예시 용도 원본 이름 성산일출봉 공공데이터 원본 데이터 보존 (비교용) 한국어 표시명 성산일출봉 한국어 UI 표시 영어 표시명 Seongsan Ilchulbong 영어 UI 표시 로마자 표기 Seongsan Ilchulbong 외국어 검색 보조용 검색 키워드 sunrise peak, seongsan 검색 색인 확장용 출처명 공공데이터 제공 기관명 저작권 및 출처 표시 요구사항 대응 2. 데이터 모델 설계 예시 (Kotlin) 저의 경우, 이 문제를 해결하기 위해 아래처럼 장소 기본 정보와 번역 맵( Map<AppLanguage, String> )을 분리한 데이터 모델을 사용합니다. 외부 노출을 막기 위해 실제 API URL이나 내부 코드는 더미 값으로 대체한 구조입니다. Ko...
자세한 내용 보기