개발 slecs

iOS 앱 광고·결제 프로덕션 ID 본격 적용

목차

처음으로 광고와 인앱 결제 기능을 실제 운영 환경 설정으로 전환했다. 개발 단계에선 테스트 ID를 썼다면, 이제 실제 사용자가 만나볼 애플리케이션으로 준비하는 단계였다.

AdMob 설정을 두 단계로 나눈 이유

iOS 앱에서 광고를 운영하려면 Google의 AdMob 네트워크에 앱을 등록하고, 앱 수준의 ID와 광고 단위(배너, 인터스티셜, 리워드 등)별 ID가 필요하다. 초반엔 하나의 테스트 ID로 여러 광고 위치를 관리했지만, 성과 분석과 광고 수익화를 제대로 추적하려면 각 배너 위치마다 고유한 ID가 필요했다.

Info.plist 에는 AdMob 앱 ID를 등록했고, ad_config.dart 에는 화면별·배치별 배너 ID를 분리했다. 이렇게 하면:

  • 각 배너의 노출/클릭 데이터를 별도로 추적 가능
  • AdMob 대시보드에서 위치별 성과 분석 가능
  • A/B 테스트를 위해 배너 배치를 동적으로 변경할 수 있음
  • 추후 특정 배너 위치의 광고 정책 조정이 용이
// ad_config.dart 예시 구조
final adConfig = {
  'appId': 'ca-app-pub-xxxxxxxxxxxxxxxx~yyyyyyyyyy',  // Info.plist와 동기화
  'banners': {
    'homeScreenBanner': 'ca-app-pub-xxxxxxxxxxxxxxxx/bbbbbbbbbb',
    'detailScreenBanner': 'ca-app-pub-xxxxxxxxxxxxxxxx/cccccccccc',
  }
};

배너 ID를 하드코딩하지 않고 설정 파일로 관리하면, 백엔드 업데이트 없이도 광고 위치를 빠르게 변경할 수 있다. 물론 앱 재배포는 필요하지만, 이 정도 유연성만으로도 운영 리스크가 크게 줄어든다.

IAP 검증 로직의 우선순위 정리

인앱 결제(IAP) 검증은 보안이 매우 중요한 부분이다. 사용자가 구매 완료 후 앱 내에서 보상을 받으려면, 해당 거래가 정말 애플을 통해 승인된 것인지 확인해야 한다.

검증 단계 담당 우선순위 변경 사항
transactionId 확인 프론트엔드 (앱) 1순위로 상향 — 로컬 영수증 검증
영수증 서명 검증 백엔드 2순위 — transactionId로 사전 필터링 후 수행
Apple 서버 재검증 백엔드 3순위 — 의심 거래만

기존엔 모든 거래를 백엔드에서 일괄 검증하려고 했지만, 이렇게 하면:
- 네트워크 왕복 지연으로 사용자가 오래 대기
- 백엔드 부하 증가 (모든 결제 요청이 몰림)
- 오프라인 상황에서 로컬 검증 불가

변경 후엔 transactionId를 우선 확인해서 명백한 위조 거래는 앱 단에서 차단하고, 의심 거래만 백엔드로 올린다. 백엔드 서비스(내부 클래스에 IAP 검증 로직 추가)에선 이미 필터링된 거래를 다시 한 번 검증하는 방식이다.

이 우선순위 변경이 보안을 약화시키지 않으려면:
- 클라이언트 검증은 보조 수단 (속도용)
- 백엔드 검증이 최종 심사
- transactionId 자체도 사용자가 임의로 위조할 수 없도록 Apple 서명 확인

pubspec.yaml 에 추가된 패키지들이 이런 검증을 지원할 거다.

배포와 문서화

버전을 1.0.0+5 로 올렸다는 건, 안드로이드의 build number 개념처럼 iOS도 단계적으로 빌드를 올리고 있다는 신호다. 매번 출시할 때마다 build 번호를 증가시키면 TestFlight 테스트 등에서 버전 혼동을 방지할 수 있다.

APPLE-REVIEW-STATUS.md 문서화도 중요한데, 애플은 앱 심사 시 광고와 결제 구현을 꼼꼼히 본다:
- 광고가 모든 기능을 방해하지 않는가?
- 사용자가 결제 취소 방법을 명확히 알 수 있는가?
- 서드파티 광고 네트워크 정책을 준수하는가?

이런 체크리스트를 미리 문서화해두면, 리뷰 반려 시 어디를 수정해야 하는지 팀 내에서 빠르게 대응할 수 있다.

멀티 플랫폼 운영의 복잡성

iOS 앱을 운영한다는 건 이런 작은 설정 변화도 영향이 크다는 뜻이다. AdMob App ID가 바뀌면 광고 수익 추적이 끊기고, IAP 검증이 느리면 사용자 경험이 나빠진다. 안드로이드와 다른 정책, 다른 ID 체계, 다른 리뷰 프로세스를 모두 관리해야 한다.

앞으로 이 구조를 유지하려면:
- 환경별(dev/stage/prod) 설정 분리를 명확히
- CI/CD에서 배포 시 ID가 바뀌지 않도록 자동화
- 광고와 결제 테스트는 항상 테스트 ID로 먼저 검증

작은 commit 같지만, 실제로는 사용자 수익화와 앱 심사 통과에 직결된 중요한 전환점이었다.

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

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

이어보기

댓글 0

첫 댓글 달아줘.