앱 공장 4화 – 앱 12개에 광고 코드를 한 줄도 넣지 않은 방법

앱 코드에서 광고 의존성을 제거한 구조

작성자

· 카테고리:

,

광고는 앱마다 다르게 설정해야 하지만 앱 코드가 광고 SDK를 직접 알게 하고 싶지는 않았습니다. core_ads와 app.yaml, AdSlot으로 광고 의존성을 한 방향으로 모은 과정을 정리했습니다.

앱 공장 시리즈 4화 영상입니다.

1. 앱 12개의 광고 코드를 다시 찾아봤습니다

앱이 늘어나면서 광고 코드도 같이 늘어날 거라고 생각하기 쉽습니다. 저도 Android 앱을 각각 관리할 때는 앱마다 SDK를 초기화하고 광고 단위 ID를 넣고 화면에서 광고를 호출했습니다.

앱 공장으로 옮긴 뒤 실제 앱 코드를 전부 검색해 봤습니다. 광고는 붙어 있었지만 앱 코드에서 Google Mobile Ads SDK를 가져오거나 광고 단위 ID를 직접 적은 줄은 없었습니다.

광고를 없앤 것이 아니라 광고에 대한 지식을 앱 밖으로 옮겼습니다. 앱은 광고가 무엇인지 몰라도 되고, 광고 구조는 공유 패키지 한 곳에서 관리하도록 만든 것입니다.

2. 의존성을 한 방향으로만 흐르게 했습니다

앱 12개의 광고 코드 측정 결과
앱 코드에는 광고 SDK와 하드코딩된 광고 ID가 없고, 공유 패키지가 광고를 담당합니다.

광고 구현은 core_ads 패키지에만 있습니다. 앱은 core_ads가 제공하는 위젯과 자리 이름을 사용할 수 있지만 Google 광고 SDK를 직접 가져오지는 못합니다.

이 방향이 중요한 이유는 광고 SDK가 바뀌거나 초기화 방식이 달라졌을 때 앱 12개를 모두 수정하지 않기 위해서입니다. core_ads 한 곳을 고치고 공통 검사를 통과시키면 모든 앱이 같은 규칙을 사용합니다.

공유한다는 이유로 앱마다 필요한 차이까지 코드에 넣으면 core_ads가 조건문으로 가득 찹니다. 그래서 앱별 차이는 설정으로 분리했습니다.

3. 앱마다 다른 값은 app.yaml에 둡니다

app.yaml의 앱별 광고 설정
앱마다 다른 광고 단위와 배치 정보는 assets/config/app.yaml에서 설정합니다.

앱 이름과 패키지 ID, 디자인 콘셉트, 광고 단위 ID와 배치 정보는 assets/config/app.yaml에 있습니다. 새로운 앱을 만들 때 광고 코드를 복사하는 대신 설정 값을 채웁니다.

개발 빌드에서는 테스트 광고 ID를 사용하고 릴리즈 빌드에서는 app.yaml의 실제 ID를 읽습니다. 코드에 실제 ID를 직접 넣지 않으니 테스트와 릴리즈의 경계도 한곳에서 관리할 수 있었습니다.

광고 단위가 아직 발급되지 않은 앱은 설정 단계에서 드러납니다. 화면 코드 곳곳을 찾아다니며 빈 값을 확인할 필요가 없습니다.

4. 화면은 광고가 아니라 자리 이름만 압니다

화면 코드가 사용하는 AdSlot 자리 이름
화면은 광고 종류나 ID 대신 home_banner 같은 자리 이름만 전달합니다.

화면에서 필요한 것은 광고 종류가 아니라 광고가 들어갈 자리입니다. 그래서 home_banner 같은 자리 이름을 AdSlot에 넘깁니다.

그 자리에 배너를 보여줄지, 어떤 광고 단위 ID를 사용할지, 노출 빈도를 어떻게 제한할지는 core_ads와 app.yaml이 정합니다. 화면은 광고 정책을 몰라도 됩니다.

이 구조를 사용하면 광고를 잠시 끄거나 배치 전략을 바꿀 때 화면을 다시 설계하지 않아도 됩니다. 앱별 UI와 광고 운영 규칙이 서로 덜 얽히게 되었습니다.

5. 규칙은 세 단계에서 검사합니다

광고 규칙을 확인하는 단계별 게이트
광고 규칙은 pre-commit, pre-push, release-ready 단계에서 반복 검사합니다.

구조를 정해도 누군가 앱 코드에 광고 SDK를 직접 가져오면 다시 무너집니다. 처음에는 문서에 금지라고 적었지만 실제로는 같은 실수가 반복됐습니다.

그래서 pre-commit에서는 포맷과 설정 파일을 빠르게 확인하고, pre-push에서는 광고 ID 하드코딩과 앱·패키지 간 잘못된 참조 같은 아키텍처 규약을 검사합니다. release-ready에서는 릴리즈 설정과 테스트 값이 섞이지 않았는지 다시 확인합니다.

영상 제작 당시 아키텍처 가드는 75줄짜리 셸 스크립트였고 1초 이내에 실행됐습니다. 같은 규칙을 여러 단계에서 확인하더라도 목적이 다릅니다. 개발 중에는 빠르게 형식과 설정을 보고, 원격 저장소에 보내기 전에는 구조를 확인하고, 출시 전에는 실제 배포 값을 검사합니다.

6. 기존 앱 세 개도 같은 구조로 옮겼습니다

이름추첨기, 로또고, 콘지기는 기존 Android 앱이었습니다. Flutter로 옮기면서 광고 구현도 core_ads와 app.yaml 구조로 바꿨습니다.

신규 앱뿐 아니라 기존 앱을 같은 구조로 이전해 보니 공통 규약이 실제 업데이트에도 사용할 수 있는지 확인할 수 있었습니다. 영상 공개 시점까지 신규 등록 7개와 업데이트 3개가 모두 반려 없이 통과했습니다.

반려가 없었다고 구조가 완벽하다는 뜻은 아니지만, 앱 코드를 단순하게 유지하면서도 실제 심사를 통과할 수 있다는 첫 확인은 되었습니다.

7. 정리

앱 12개에 광고를 붙이는 방법은 광고 코드를 잘 복사하는 일이 아니었습니다. 광고 구현은 core_ads에, 앱별 값은 app.yaml에, 화면에는 자리 이름만 남겼습니다.

다음 글에서는 이 규칙을 에이전트에게 매번 설명하지 않기 위해 절차를 파일로 관리하게 된 과정을 정리해 보겠습니다.


앱 공장 · 4화

YouTube에서 영상으로 보기 ↗

이전 글: 앱 공장 3화 · 다음 글: 앱 공장 5화

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다