개발 slecs

모바일 앱 광고 아이디와 릴리즈 서명을 프로덕션용으로 전환

목차

모바일 앱을 실제 스토어에 배포하려면 개발 환경의 편의성과 프로덕션 환경의 보안·정합성 사이의 균형을 맞춰야 한다. 이번 작업은 그 분기점을 명확히 하는 과정이었다.

AdMob ID 이중 관리, 왜 복잡할까

보통 모바일 개발 초기엔 AdMob 테스트 ID를 쓴다. 테스트 ID는 실제 광고 노출로 집계되지 않고, 클릭도 자유로워서 개발·테스트 단계에서 광고 레이아웃이나 로딩 동작을 안심하고 검증할 수 있다. 하지만 앱이 실제 사용자에게 배포되는 순간, 테스트 ID를 그대로 두면 광고 수익은 전혀 안 들어오고, 구글의 정책 위반으로 AdMob 계정 정지까지 받을 수 있다.

이번 commit에서 app/lib/ad/ad_config.dart 파일을 수정한 것은 바로 이 전환점을 코드에 반영한 것이다. 테스트 ID에서 실제 프로덕션 광고 ID로 교체했다는 뜻이다. 흥미롭게도, 많은 팀이 이 작업을 할 때 "개발 빌드일 땐 테스트 ID, 릴리즈 빌드일 땐 실제 ID"라고 빌드 변수로 분기하거나, 환경 설정 파일로 관리하는 방식을 선택한다. 이건 배포 후 "어, 테스트 ID로 나갔네?" 같은 사고를 미리 방지하는 중요한 패턴이다.

// 예: 빌드 타입으로 분기하는 패턴
const String admobAppId = kIsWeb ? '' : 
  (kDebugMode ? 'ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy' : 
   'ca-app-pub-실제ID~실제ID');

릴리즈 서명, 앱 스토어 배포의 필수 열쇠

변경 파일 중 upload-keystore.jks와 key.properties 가 핵심이다. 이 두 파일은 앱을 Google Play에 업로드할 때 필수적인 "디지털 서명"을 생성한다.

Keystore (.jks 파일)는 프라이빗 키와 인증서를 저장하는 저장소다. 이 파일 하나로 앱의 정체성이 보장된다. 구글이 이 keystore로 서명된 apk/aab만 같은 앱 ID로 업로드된 앱 버전으로 인정한다. 만약 keystore를 잃어버리면? 같은 패키지명으로 재배포할 수 없다. 업데이트가 불가능해진다는 뜻이다.

Key.properties는 그 keystore를 언락하고 사용할 때 필요한 비밀번호와 알리어스(alias) 정보를 담는다. build.gradle.kts 에서 빌드 시 이 파일을 읽어서 자동으로 앱을 서명한다.

// build.gradle.kts 의 전형적인 서명 설정
signingConfigs {
    create("release") {
        val keystoreProperties = Properties()
        val keystorePropertiesFile = rootProject.file("key.properties")
        if (keystorePropertiesFile.exists()) {
            keystorePropertiesFile.inputStream().use { 
                keystoreProperties.load(it) 
            }
        }
        keyAlias = keystoreProperties["keyAlias"] as String
        keypassword=*** as String
        storeFile = file(keystoreProperties["storeFile"] as String)
        storepassword=*** as String
    }
}

보안의 벽: .gitignore 에 무엇을 숨길까

.gitignore 수정이 이 commit에 포함된 이유는 명확하다. keystore와 key.properties는 절대 git 저장소에 커밋돼선 안 된다. 이 파일들은 곧 "앱 배포 권한"이다. 누군가 이 파일들을 얻으면, 내 앱 이름으로 악의적인 버전을 배포할 수 있다.

실무에선 보통 이런 민감한 파일들을 다음과 같이 관리한다:

  • 로컬 개발 머신에만 보관 — CI/CD 서버나 클라우드 빌드 시스템에서는 별도의 보안 저장소(예: GitHub Secrets, Jenkins Credentials, 내부 Vault)에서 동적으로 주입
  • 팀에선 otp 같은 보안 채널로 공유 — slack은 절대 금지
  • 정기적으로 로테이션 — 특히 팀원 이탈 시 새로운 keystore 생성 후 재발급

AndroidManifest.xml 변경은 아마 앱 ID(package name)나 권한 설정이 추가됐을 가능성이 높다. 광고 SDK가 필요한 권한(예: INTERNET, ACCESS_NETWORK_STATE)을 명시적으로 선언해야 AdMob이 제대로 작동하기 때문이다.

회고: 프로덕션 전환 체크리스트

이런 작업을 하면서 배운 건, 단순히 "테스트에서 실제로 바꾸는 것" 이상으로 중요한 게 "이 시점에 정말 준비가 됐는가" 라는 질문이다.

  • AdMob 계정에서 실제 광고 ID를 발급받았는가?
  • 앱이 AdMob 정책 검토를 통과했는가? (클릭 유도 금지 등)
  • Keystore를 로컬에만 보관하고 버전 관리에서 제외했는가?
  • 팀이 키 관리 규칙을 명확히 이해하고 있는가?
  • 빌드/배포 프로세스에서 자동으로 올바른 ID/서명이 적용되는가?

하나라도 빠지면 나중에 "앱이 떴는데 광고가 안 보인다", "다음 버전을 배포할 수 없다" 같은 상황에 빠진다.

다음: 이 설정이 CI/CD 파이프라인에서도 제대로 작동하는지 확인하고, 팀원들이 로컬 개발 환경에서 키를 어떻게 관리할지 문서화하는 단계가 남아있다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.