양대 마켓 동시 제출하면서 데모 두 개 밀어넣은 아침

오전 여섯 시부터 시작한 작업이 어떻게 됐냐면, 플러터 앱의 iOS와 Android 제출을 동시에 돌리면서 데모 사이트 두 개를 배포하고, 거기다 백엔드 파이프라인 병렬화까지 밀어넣었다. 한 가지 작업이 끝나면 다음으로 넘어가는 식이 아니라, 세 개 레인이 동시에 달리는 구조였다. 스토어 제출은 특정 단계에서 사람이 멍하니 기다려야 하는 구간이 반드시 생기는데, 그 틈을 활용하는 방식으로 시간을 썼다.

iOS: 스크린샷 지옥과 READY_TO_SUBMIT까지

App Store Connect 제출이 이 시간대에서 가장 손이 많이 갔다. 빌드 2 기준으로 iPad 스크린샷 12장을 새로 뽑아야 했는데, ASC가 요구하는 사이즈 규격이 기기 세대마다 달라서 asc_screenshots_ipad.py를 기존 파일에서 분리해 따로 뽑아냈다. iPhone용 asc_screenshots.py와 iPad용을 한 파일에 넣으면 사이즈별 로직이 섞여서 유지보수가 힘들어진다. 언어별·기기 폼팩터별 조합이 늘어나는 시점부터는 파일을 쪼개두는 게 훨씬 낫다는 걸 이미 몇 번 경험했다.

스크린샷 업로드보다 더 번거로웠던 건 IAP 리뷰 스크린샷이었다. App Store 심사팀이 인앱결제를 검토할 때 별도 스크린샷을 요구하는데, 이게 일반 앱 스크린샷 업로드 플로우와 API 엔드포인트 자체가 달라서 asc.py를 손봐야 했다. ASC API 문서를 처음 읽으면 이 차이가 잘 안 보인다. 실제 코드를 까보고서야 inAppPurchaseReviewScreenshots 리소스가 별도 타입으로 분리돼 있다는 걸 확인했다. 문서만 보다가 시간을 꽤 날릴 수 있는 함정이다.

ExportOptions.plist도 빌드 2에 맞게 업데이트했고, Info.plist에 AdMob App ID를 실 값으로 박았다. 그 전까지는 테스트 ID로 빌드를 올리고 있었는데 심사 전에 실 ID 전환은 필수다. READY_TO_SUBMIT 상태까지 올린 뒤에도 체크리스트를 한 번 더 돌렸다. 로고 빌드 연결, IAP 스크린샷 첨부, TestFlight 내부 빌드 상태 확인. 이 세 가지 중 하나라도 빠지면 심사 제출 버튼이 안 눌리거나 리젝 확률이 올라간다.

Android: AAB v2, 테스터 44명, 콘텐츠 선언 11종

Play 쪽은 iOS보다 제출 절차가 단순한 편인데 앱 콘텐츠 선언이 생각보다 손이 갔다. Google이 요구하는 선언 항목이 11종인데 광고 유형, 데이터 수집 여부, 대상 연령, 금융 서비스 해당 여부, 헬스케어 해당 여부 등 꼼꼼하게 채워야 하는 항목들이다. 하나라도 잘못 체크하면 정책 위반으로 앱이 내려가는 케이스가 드물지 않아서 하나씩 천천히 처리했다.

앱아이콘은 사운드웨이브 디자인으로 전면 교체했다. Android는 mipmap 해상도별로 전부 갈아치워야 한다.

폴더	대표 해상도
mipmap-mdpi	48×48
mipmap-hdpi	72×72
mipmap-xhdpi	96×96
mipmap-xxhdpi	144×144
mipmap-xxxhdpi	192×192

피처 그래픽과 스크린샷은 en/ko/ja 세 언어로 올렸다. Play Console의 스토어 등록정보 섹션에서 언어별로 각각 업로드해야 하는 구조라 반복 작업이 길었다. versionCode 2로 올린 AAB를 비공개 트랙에 게시하고, 내부 테스트 트랙을 활성화해서 테스터 44명에게 배포했다. 내부 테스트는 보통 수 시간 내로 링크가 활성화되는데 이번에도 큰 딜레이 없이 올라왔다.

AdMob 광고 ID는 iOS와 Android 양쪽 다 실 ID로 교체하는 작업을 versionCode 올리는 타이밍에 묶어서 처리했다. ad_config.dart에 집중 관리하던 ID들을 실 값으로 바꾸고, AndroidManifest.xml과 Info.plist에 각각 AdMob App ID를 박아 넣었다. 이걸 별도 커밋으로 분리하지 않고 versionCode bump와 묶은 건, 광고 ID가 테스트 상태로 배포되면 수익 집계가 안 되는 건 기본이고 심사 과정에서 문제가 될 수 있어서다. 같은 배포 묶음으로 처리해두면 나중에 릴리즈 이력 추적할 때도 한눈에 보인다.

데모 사이트: risk-rag 명암비 싸움과 행사 리포트 자동화 공개

앱 제출 대기 구간에 데모 사이트 두 건을 배포했다. 하나는 AI 위험성평가 RAG 엔진 데모(risk-rag), 다른 하나는 행사 리포트 자동화 작동 데모다.

demo/
├── risk-rag/
│   └── index.html          # RAG 엔진 작동 데모
├── event-report-automation/
│   └── index.html          # 리포트 자동화 데모
thumbs/
├── risk-rag.jpg            # 재캡처 (명암비 보정 후)
└── event-report-automation.jpg

risk-rag는 데모 HTML을 처음 올리고 나서 두 번 더 수정이 들어갔다. 이유가 명암비 문제였다. ok 상태 배지와 warn 상태 배지에 쓴 색상이 배경 대비 WCAG AA 기준을 못 넘어서 색을 보정해야 했다. WCAG AA는 일반 텍스트 기준 명암비 4.5:1 이상을 요구하는데, 처음에 쓴 초록/노랑 계열이 여기서 걸렸다. 밝은 배경에 채도 높은 색을 그냥 쓰면 이런 일이 자주 생긴다. 색상 값 수정하고, 그 결과를 썸네일로 다시 캡처해서 교체하는 과정이 커밋 세 개로 쪼개졌다.

솔직히 말하면 처음부터 명암비 체커 한 번 돌리고 색을 잡았으면 커밋 하나로 끝날 일이었다. 급하게 올리고 눈으로 봐서 괜찮겠다 싶으면 통과시키는 습관이 이런 식으로 돌아온다. 다음엔 배지 색상 확정 전에 도구 먼저 돌리는 순서로 바꿔야겠다.

행사 리포트 자동화 데모는 event-report-automation 디렉토리로 분리해서 배포했다. 실제 작동하는 자동화 파이프라인의 처리 흐름을 시각적으로 보여주는 정적 데모 페이지다. 메인 index.html에서 링크를 연결하고 썸네일도 추가했다. risk-rag와 달리 이쪽은 첫 배포에서 별다른 수정 없이 마무리됐다.

opsvoro: E-E-A-T 보강 스크립트에 샤드 병렬화 추가

enrich_eeat.py는 콘텐츠 E-E-A-T 신호를 보강하는 스크립트인데, 처리 대상 레코드가 늘어나면서 단일 프로세스로는 처리 시간이 너무 길어지는 상황이 생겼다. 해결 방법은 단순하게 갔다. --shard i/N 옵션을 추가해서 워커를 N개 띄우고 각 워커가 i번째 파티션만 담당하는 방식이다.

# 4개 워커로 분산 처리
python enrich_eeat.py --shard 0/4
python enrich_eeat.py --shard 1/4
python enrich_eeat.py --shard 2/4
python enrich_eeat.py --shard 3/4

파티셔닝 기준은 레코드 인덱스를 N으로 나눈 나머지다. 외부 오케스트레이터 없이 스크립트 레벨에서 분산이 되니까, tmux 세션 여러 개나 systemd 서비스 인스턴스로 바로 띄울 수 있다. 카프카나 Celery 같은 걸 붙이는 방법도 있지만 지금 규모에서는 오버엔지니어링이다. 병렬화가 필요한 타이밍에 의존성 없이 빠르게 적용할 수 있는 패턴으로는 이게 제일 무난하다. 나중에 처리량이 더 늘어나면 그때 본격적으로 큐를 붙이는 걸 고려하면 된다.

돌아보면

양대 마켓 동시 제출이라는 게 생각보다 멘탈을 쪼개는 작업이다. iOS는 ASC, Android는 Play Console, 각각 요구하는 에셋 포맷과 제출 절차가 달라서 둘을 동시에 트래킹하다 보면 어느 순간 뭘 어디까지 했는지 헷갈리기 시작한다. CLAUDE.md에 진행 상태를 docs 커밋으로 계속 기록해둔 게 이 부분에서 실제로 도움이 됐다. "Play 내부테스트 트랙 활성(테스터44명)+AAB v2 게시 완료 기록"처럼 완료 시점마다 커밋을 남겨두면 재개할 때 어디서부터 시작해야 하는지 바로 보인다.

가장 삽질한 부분은 역시 IAP 리뷰 스크린샷 처리였다. ASC API가 일반 스크린샷과 IAP 스크린샷을 다른 리소스 타입으로 구분한다는 걸 코드를 직접 들여다보고서야 파악했다. 문서 수준에서는 이 차이가 모호하게 서술돼 있어서 처음 접하면 그냥 같은 업로드 플로우인 줄 착각하기 쉽다. risk-rag 명암비 건은 세 번 커밋이 간 게 아깝지만 접근성 기준을 맞춰두는 게 나중에 훨씬 편하다. 어차피 언젠가는 고쳐야 할 부분이라면 배포 초기에 정리하는 게 낫다.

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

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