스토어 배포 국가·연령등급 현황 대시보드 만들기
모바일 앱 여러 개(Android/iOS)를 여러 국가에 서비스하고 있다. 새 스토어 정책(예: Utah SB 142, Texas SB 2420, Android target SDK 34 의무화)이 나올 때마다 운영 담당자가 영향 여부를 수작업으로 확인해 왔다.
확인 과정은 이랬다.
- App Store Connect와 Google Play Console에 각각 로그인해 앱별 territory·country availability 화면을 하나씩 클릭한다. 앱 수 × 국가 수만큼의 셀을 사람이 본다.
- IARC, ESRB, PEGI, USK, ACB, CLASS_IND, GRAC, RARS 등 8종 등급체계를 앱마다 따로 확인한다.
- 개발 조직과 운영 담당자가 메일을 여러 번 주고받으며 회신한다.
정책 한 건마다 몇 시간씩 들었고, 사람이 하다 보니 누락 위험과 의사소통 비용이 컸다.
자동 수집과 단일 대시보드로 묶어서 “이 정책이 우리 앱에 영향이 있나?“라는 질문에 콘솔을 열지 않고 한 화면에서 몇 분 안에 스스로 답할 수 있게 한다. 한 사람이 대시보드를 보면 여러 사람이 주고받던 질의응답을 대신하도록, 사용자와 수혜자를 분리하는 구조로 설계했다.
운영하면서 두 가지 반복 업무가 더 보였다.
- 정책 원문을 해석하는 일 자체가 병목이었다. 그래서 LLM 영향성 분석을 붙였다.
- 심사 대기 상태를 확인하는 일도 반복이었다. 그래서 iOS 심사 자동 모니터링을 붙였다.
처음에는 일부 앱만 대상으로 시작했다가 다른 앱까지 넓혔고, 서로 다른 법인의 스토어 계정 두 개를 동시에 다룬다. API 키만 추가하면 다른 조직의 앱에도 같은 구조로 확장된다.
- 국가별 배포 현황: 앱(행) × 국가(열) 히트맵으로 전체 셀을 한 화면에 표시한다. 전체 배포율과 앱별 커버리지 요약을 함께 보여 준다.
- 국가 상세: 특정 국가의 앱별 배포 상태와 등급 분포를 보여 준다. 국가는 12개 지역으로 분류한다.
- 연령 등급: 8종 등급체계를 하나의 매트릭스로 통합한다. 스토어 원본값과 IARC 정규화 값을 함께 표기한다.
- 앱별 배포 스펙: 버전, target SDK, Unity·SDK 버전, Play Billing 등 18개 항목을 조직별로 관리한다. 빌드 산출물(
.aab/.xcarchive)을 업로드하면 민감 권한을 7개 카테고리로 자동 분류한다. - 스토어 정책 위키: Confluence에 정리된 정책 문서를 자동 동기화하고, 정책마다 영향 앱, 플랫폼, 대응 항목, 영향도를 LLM이 분석한다.
- 스토어 심사 현황: iOS 앱의 심사 단계를 App Store Connect API로 10분마다 수집한다(감시 지정 앱은 1분). 상태가 바뀌면 Google Chat으로 알린다. Android는 Play Console API가 심사 상태를 제공하지 않아 별도 도구로 링크만 건다.
- 등급 변경·동기화 이력: 변경 타임라인과 출처(Apple/Google)별 동기화 상태를 보여 준다. 매일 KST 08:00, 12:00에 자동 동기화한다.
- 서비스 안내: 사용법, 알림 채널, 표기 규칙을 관리자가 화면에서 직접 편집한다.
- 그 밖에 앱 상세 스펙, API 수집 이력 조회, 수동 수집 실행을 둔다.
LLM 영향성 분석
섹션 제목: “LLM 영향성 분석”Claude 모델을 사내 AI 게이트웨이를 거쳐 호출한다. 하는 일은 네 가지다.
- Confluence 정책 원문 해석
- 영향도 분류(high / medium / low / none)
- 영향 받는 앱 식별과 앱별 판단 근거 생성
- 대응 체크리스트 생성
구현 구성
섹션 제목: “구현 구성”| 구성 요소 | 내용 |
|---|---|
| 스토어 API 연동 | App Store Connect(JWT 인증, availability v2, 등급), Google Play Developer API |
| 수집 엔진 | DB 스키마, 수집 오케스트레이터, 스냅샷·변경 감지 |
| 웹 UI | Next.js 8개 화면(히트맵, 등급 매트릭스, 스펙 표) |
| 정책 분석 | Confluence 동기화 + LLM 영향 분석 파이프라인 |
| 빌드 산출물 분석 | .aab/.apk는 aapt·bundletool, .xcarchive/.ipa는 직접 파싱 |
| 심사 감시 | iOS 심사 모니터링 + 알림 채널 |
| 다중 계정 | 이중 계정 프로파일, GRAC 등급 파싱, 앱 묶음·조직 분류 |
기술 스택
섹션 제목: “기술 스택”- 백엔드: Python 3.11, FastAPI 0.115, SQLAlchemy 2.0, APScheduler 3.10, Pydantic 2.9
- 프론트엔드: Next.js 14.2, React 18.3, TypeScript 5.6, Tailwind CSS 3.4, SWR 2.2
- DB: PostgreSQL 16
- 외부 API: App Store Connect API, Google Play Developer API, Confluence REST API, Google Chat Webhook
- 빌드 분석 도구: aapt, bundletool
- 인프라: AWS Lightsail 단일 호스트
- 컨테이너: Docker Compose(Backend + Frontend + PostgreSQL 16)
- 환경변수: 호스트에
.env와 스토어 API 키 파일을 마운트 - 배포: 원격 배포 스크립트로
docker compose build와up을 실행
AI 도구로 개발한 방식
섹션 제목: “AI 도구로 개발한 방식”코드 대부분은 Cursor와 Claude Code로 작성했다. AI에게는 스토어 API 조사, DB 스키마·REST API·컴포넌트 구조 설계, 코드 작성과 디버깅, 배포 구성과 문서화를 맡겼다. 사람은 요구사항 정의, 방향 판단, 코드 리뷰, 스토어 API 연동 검증, 배포 환경 설정을 맡았다. 기존 업무와 병행했는데도 혼자 직접 짰을 때 예상한 공수보다 개발 기간이 줄었다.