[Android] 애드몹(AdMob) 테스트 광고 ID와 운영 ID 안전하게 분리 설정하는 방법

5월 07, 2026

앱에 애드몹(AdMob)을 붙여서 출시 준비를 하다 보면 가장 먼저 정해야 하는 게 바로 광고 ID 관리 기준입니다.

개발 환경에서 테스트하다가 실수로 실제 운영 광고를 클릭하기라도 하면 '무효 활동'으로 찍혀서 계정이 정지되는 불상사가 생길 수 있거든요. 반대로 운영 빌드에 테스트 ID를 그대로 남겨두면 출시 후에 수익이 전혀 나지 않는 문제가 생깁니다.

매번 프로젝트 세팅할 때마다 설정이 헷갈리는 부분이라, 아예 깔끔하게 정리해서 기록해 둡니다.

자주 발생하는 문제 상황

운영하다 보면 보통 아래와 같은 지점에서 실수가 나옵니다.

개발 중에 실제 운영 광고 단위 ID가 뜨는 줄 모르고 직접 클릭함 (계정 정지 리스크)
릴리즈(Release) 빌드에 테스트용 광고 ID를 그대로 넣어서 배포함 (수익 0원)
테스트 디바이스 해시값이나 실제 운영 ID를 GitHub 같은 공개 저장소에 그대로 push함
배너, 전면 광고 ID 문자열을 여러 화면 코드에 하드코딩해서 나중에 수정하기 힘들어짐

빌드 타입(Build Type)별 ID 분리 설정

가장 확실한 방법은 Gradle의 buildTypes를 활용해서 디버그(Debug)와 릴리즈(Release) 환경의 ID를 빌드 시점에 분리해 주입하는 것입니다.

1. Gradle 설정 (build.gradle)

Groovy
android {
    buildTypes {
        debug {
            // Google 공식 데모 배너 및 전면 광고 ID
            buildConfigField("String", "ADMOB_BANNER_AD_UNIT_ID", '"ca-app-pub-3940256099942544/9214589741"')
            buildConfigField("String", "ADMOB_INTERSTITIAL_AD_UNIT_ID", '"ca-app-pub-3940256099942544/1033173712"')
        }
        release {
            // 실제 운영 광고 ID (공개 저장소라면 local.properties 등에서 불러오는 방식을 권장합니다)
            buildConfigField("String", "ADMOB_BANNER_AD_UNIT_ID", '"ca-app-pub-xxxxxxxxxxxxxxxx/yyyyyyyyyy"')
            buildConfigField("String", "ADMOB_INTERSTITIAL_AD_UNIT_ID", '"ca-app-pub-xxxxxxxxxxxxxxxx/yyyyyyyyyy"')
        }
    }
}

주의: 퍼블릭 저장소(GitHub 등)를 쓰신다면 release 블록의 실제 ID도 직접 적지 말고 local.properties나 CI/CD 환경 변수(Secret)를 통해 주입하는 구조로 가져가야 안전합니다.

2. 코드에서 ID 공급자(Provider) 구조로 관리

광고 ID를 화면 코드마다 직접 복사해 넣으면 나중에 교체할 때 누락이 생깁니다. 아래처럼 BuildConfig 값을 바라보는 싱글톤이나 프로바이더 객체를 하나 만들어서 관리하는 편이 좋습니다.

Kotlin
object AdMobIds {
    const val TEST_BANNER = "ca-app-pub-3940256099942544/9214589741"
    const val TEST_INTERSTITIAL = "ca-app-pub-3940256099942544/1033173712"
}

class AdUnitProvider {
    fun bannerAdUnitId(): String {
        return if (BuildConfig.DEBUG) {
            AdMobIds.TEST_BANNER
        } else {
            BuildConfig.ADMOB_BANNER_AD_UNIT_ID
        }
    }

    fun interstitialAdUnitId(): String {
        return if (BuildConfig.DEBUG) {
            AdMobIds.TEST_INTERSTITIAL
        } else {
            BuildConfig.ADMOB_INTERSTITIAL_AD_UNIT_ID
        }
    }
}

테스트 디바이스 등록 기준

데모 ID를 쓰는 방법 외에, 내 실제 운영 ID 환경에서 테스트를 해야 할 때는 기기를 '테스트 디바이스'로 등록해야 안전합니다. 코드에서 등록할 때는 반드시 디버그 빌드에서만 동작하도록 차단을 걸어줍니다.

Kotlin
fun configureTestDevices() {
    if (!BuildConfig.DEBUG) return // 운영 빌드에서는 절대 실행 안 되게 차단

    val testDeviceIds = listOf("내_기기_테스트_해시_값")
    val configuration = RequestConfiguration.Builder()
        .setTestDeviceIds(testDeviceIds)
        .build()

    MobileAds.setRequestConfiguration(configuration)
}

Tip: 기기 해시값은 디버그 빌드로 실행 후 로그캣(Logcat)에 Use RequestConfiguration.Builder().setTestDeviceIds(...)를 검색하면 쉽게 찾아서 넣을 수 있습니다.

UMP 동의 흐름과 환경별 비교

디버그 환경이라고 해서 UMP(개인정보 동의 흐름)를 아예 생략해 버리면, 나중에 릴리즈 빌드에서만 광고가 안 나오는 현상이 발생할 수 있습니다. ID 분리만 다르게 처리하고 전체적인 로직 흐름은 동일하게 가져가야 검수가 편합니다.

구분	Debug 환경	Release 환경
광고 ID 주입	구글 데모 광고 ID 사용	실제 운영 광고 ID 주입
테스트 디바이스	활성화 (로그캣 해시 등록)	비활성화 (코드 차단)
UMP 개인정보 동의	실행 (`canRequestAds()` 확인)	실행 (`canRequestAds()` 확인)
로그 출력 수준	에러 및 광고 로드 로그 전체 확인	민감 정보(ID 등) 로그 제외

블로그 및 공개 저장소 보안 기준

기록용으로 블로그 글을 쓰거나 오픈소스에 올릴 때 아래 정보들은 무조건 마스킹 처리를 하셔야 계정을 안전하게 지킬 수 있습니다.

Google 데모 광고 ID: 예제 코드에 그대로 공개 가능
운영 광고 단위 ID / App ID: 무조건 ca-app-pub-xxxxxxxxxx/yyyyyyyyyy 처리
테스트 디바이스 해시값: 내 고유 기기 정보이므로 예제에서 제외
애드몹 콘솔 스크린샷: 계정 ID, 수익금 현황, 실제 광고 ID 영역 모자이크 필수

실무자용 최종 체크리스트

[ ] 개발 단계에서 실제 광고를 직접 클릭하지 않았는가
[ ] buildTypes를 통해 디버그와 릴리즈 빌드의 광고 ID가 명확히 분리되었는가
[ ] 광고 ID 문자열이 화면 UI 코드에 하드코딩되어 있지 않은가
[ ] UMP 동의 여부(canRequestAds())를 검증한 뒤에 광고 로드를 요청하는가
[ ] 미디에이션(Mediation)을 쓰는 경우 타사 네트워크의 테스트 모드 설정을 별도로 확인했는가

처음에 이 구조를 안 잡아두면 나중에 앱 출시 직전에 코드를 다 뒤엎거나, 정책 위반 경고를 받고 골치 아파지는 경우가 많습니다. 처음 세팅할 때 10분만 투자해서 빌드 타입별 주입 구조를 만들어 두시는 것을 추천합니다.

이 블로그 검색

PURPLEOCEAN 개발 노트