사례 4 — App Store 심사 자동화와 서명 지옥

근거 확인된 출처성숙도 App Store Connect API 9,100줄 증거

문제

3개 앱의 심사 제출이 웹 콘솔 수동 작업이었다 — 느리고, 기록이 안 남고, 반복될수록 실수가 쌓였다.

해결

ASC(iris) API 직접 호출로 제출 자동화 + GitHub Actions 서명 업로드 파이프라인.

결과

제출 전문 9,100줄이 증거로 남고, 서명 실패 3단계를 커밋으로 극복 — 재제출이 절차가 아닌 명령이 됐다.

배경과 시기GitHub에서 피드백 남기기

심사 제출은 "이벤트"가 아니라 상태 전이다: PREPARE → SUBMIT → IN_REVIEW → REJECT/ACCEPT. 상태 전이를 API로 다룰 수 있다면, 거절 이력도 데이터가 된다.
이 관점 전환 후: 제출 기록을 JSON으로 남기는 것이 원칙이 됐고, 그 기록이 다음 심사의 지도가 됐다.

FastlaneASC(iris) API 직접 호출

직접 호출 선택

직접 호출 선택. 이유: 제출 전문(요청·응답)을 통째로 증거로 남기고 싶었고, 2FA/세션 이슈 없이 상태 전이를 정밀 제어하고 싶었다.
서명 자동 프로필수동 signing

자동 시도 → 실패 → 수동 → identity 정렬 (3단계, 아래 Failure).
로컬 업로드GitHub Actions

Actions 선택

Actions 선택. 이유: 서명 자료를 로컬에 두지 않고 파이프라인에서 처리.

가설: “자동 서명 프로필이면 끝”
→ 업로드 거부. (allow automatic store profile selection)
가설: “수동 signing이면 끝”
→ identity 불일치 재발. (use manual distribution signing in release)
가설: “identity만 정렬하면 끝”
→ AAB 빌드 자체가 실패. 원인은 플러그인 모듈 JVM 타깃 — JVM 타깃을 11로 맞춰 AAB 빌드를 되살린다 (refs #410)로 종결.

교훈: iOS 배포 실패는 단일 원인이 아니라 연쇄다. 각 단계를 커밋으로 분리해 둬서, 다음 앱(내일이없다면)에서 같은 연쇄를 30분 만에 통과했다.

실제로 막혔던 지점 — provisioning profile 을 못 찾아 IPA 빌드가 죽는다

상황
“3개 앱을 연달아 심사에 올려야 했는데, 웹 콘솔 수동 제출로는 이력도 남지 않고 실수가 쌓였습니다.”
과제
“제출을 재현 가능한 명령으로 만들고, 서명·빌드 실패까지 파이프라인으로 처리하는 게 목표였습니다.”
행동
“Fastlane 대신 ASC API를 직접 호출해 제출 전문을 통째로 증거로 남겼고, 서명은 자동→수동→정렬 세 단계의 실패를 커밋으로 분리하며 좁혔습니다. 업로드는 GitHub Actions로 옮겼습니다.”
결과
“9,100줄의 제출 기록이 남았고, 3개 앱 제출이 명령 하나가 됐습니다. 다음 앱의 서명 문제는 같은 연쇄를 30분 만에 해결했습니다.”

주장	증거
API 자동화	asc_official_api.json (9,100줄)
3앱 대상	asc_summary_after_submit.json (3앱 상태 기록)
서명 3단	커밋 연쇄 2026-08-19 (refs #410)
Actions	커밋 `enable signed mobile store uploads`
거절 대응 체계	ios_review_recovery_2026_07_06/ (스크린샷·결과 JSON)