CI-CD & Store Release Policy Physics

1. Overview

CI-CD 및 스토어 릴리스 정책 역학(CI-CD & Store Release Policy Physics)은 로컬 PC에서 작동하던 코드가 자동화된 파이프라인(빌드/테스트/서명)을 타고 컨베이어 벨트를 지나 애플/구글 스토어의 깐깐한 심사대(Review Board)를 뚫고 수백만 유저 기기에 꽂히는 무중단 릴리스 역학을 다룹니다.

웹 브라우저를 새로고침하면 즉시 코드가 반영되는 백엔드(Web)와 달리, 모바일 앱은 유저가 '업데이트' 버튼을 누르지 않으면 영원히 구버전 파편화(Fragmentation)에 갇혀 버립니다. 또한, 스토어 심사에 떨어지면 배포가 1주일씩 강제 지연되는 치명적 병목이 존재합니다. 학습자는 GitHub Actions나 Fastlane을 통해 서명 암호 키(Keystore/Provisioning) 주입과 IPA/AAB 추출을 자동화하는 무인(CI) 공장을 짓고, 스토어 심사를 우회하기 위해 기능을 숨겼다가 런타임에 불을 켜는 원격 구성(Remote Config / Feature Flag)과 강제 업데이트 강요(Force Update) 물리학을 융합 통제합니다.

2. Scope & Boundaries

In-Scope

빌드 파이프라인 (CI): Fastlane, GitHub Actions, Code Signing(Keystore, 인증서, Provisioning Profile).
배포 및 스토어 릴리스 (CD): TestFlight, Play Console Alpha/Beta 트랙, 스토어 심사 통과 가이드라인(App Store Review Guidelines).
버전 파편화 제어: 점진적 릴리스(Phased Release), 강제 업데이트(Force Update), Feature Flagging.
크래시 리포팅: dSYM/Mapping File 난독화 해제 심볼 연동, Firebase Crashlytics.

Out-of-Scope

웹 백엔드 CI-CD (Docker/K8s 배포): 쿠버네티스 컨테이너 롤아웃이나 도커 이미지 빌드 $ightarrow$ 09-02. Cloud Native Physics 영역으로 위임.
유닛/UI 테스트 코드 작성 로직: 테스트를 '어떻게 작성할 것인가'의 로직 $ightarrow$ 09-04. Testing Physics 영역으로 위임 (여기서는 그 테스트를 언제 '자동 실행'할 것인지 파이프라인 묶음에 집중).

Boundaries

모바일 릴리스 vs 웹 릴리스 (13-04-02 vs 09-02): 웹 릴리스(09-02)가 개발자가 서버를 껐다 켜면 세상 모든 유저의 화면이 동시에 변하는 동기화 마법이라면, 모바일 릴리스(13-04-02)는 한 번 잘못된 코드가 배포되면 유저가 폰을 망치로 깨거나 앱을 삭제하기 전까지는 내가 원격으로 고칠 수 없는(스토어 심사 대기 3일) 무자비한 불가역(Irreversible) 물리학입니다.

3. Counterexample

수동 서명 인증서의 환상 (Manual Provisioning Fallacy): 개발자 A가 자신의 맥북에 있는 로컬 인증서 파일(P12)을 마우스로 클릭해 수동으로 앱을 아카이브(Archive)하고 스토어에 업로드하는 관습. A가 퇴사하면 다음 날부터 앱 업데이트가 불가능해지는 '단일 장애점(SPOF)'이 발생합니다. 코드 서명 키는 CI 서버(GitHub Secrets)나 fastlane match 같은 암호화 저장소에 중앙 집중화되어, 깃 푸시(Git Push)만으로 로봇이 서명하고 빌드하게 자동화해야 합니다.
파편화 무방비 배포 (Fragmentation Blindness): 서버 API 구조를 V2로 뜯어고치면서 V1 API를 꺼버린 뒤, 모든 유저가 오늘 밤 당장 앱을 새 버전으로 업데이트할 거라 착각하는 무지. 전체 유저의 20%는 6개월 전 앱 구버전을 쓰고 있으며, V1 API가 닫히는 순간 20% 유저는 에러 팝업과 함께 영원히 갇힙니다. 강제 업데이트(Force Update) 장치를 앱 내부에 미리 심어두거나, 하위 호환성을 유지해야 하는 구버전 파편화의 공포를 무시한 결과입니다.

4. Prerequisites

리눅스 쉘 명령어 및 CI/CD 기초 (Basic): 쉘 스크립트 작성법과 CI 서버가 도커(Docker) 컨테이너에서 환경을 띄우는 원리를 이해해야 합니다. (09-01. CI/CD Pipeline Physics)
응용 암호학 기초 (Recommended): 비대칭키와 인증서(Certificate) 개념을 알아야 Apple Provisioning Profile의 서명(Code Signing) 고통을 극복할 수 있습니다. (10-01. Cryptography)

5. Learning Map

Sequence	Core Cluster	Objective & Description	Evidence (BoK)
1	Code Signing Matrix	내가 짠 코드가 악성 앱이 아님을 증명하기 위해, 기기와 애플/구글 서버의 암호학적 3자 대면(서명)을 통과하는 벽을 넘습니다.	Primary
2	Fastlane & CI Auto	마우스를 10번 눌러 스토어에 올리던 1시간의 낭비를 없애고, 깃 푸시(Push) 한 번에 빌드 로봇(CI)이 패키징을 완료하는 공장을 세웁니다.	Industry
3	Store Review & Rollout	애플의 깐깐한 심사 통과 규칙을 꿰뚫고, 배포 후 버그가 터졌을 때 유저 1%에게만 피해가 가도록 점진적 배포(Phased)를 제어합니다.	Industry
4	Feature Flag & Force Update	앱 업데이트 심사를 거치지 않고도 버튼 색깔을 바꾸거나 구버전 유저를 강제로 앱스토어로 쫓아내는 런타임 통제권을 장악합니다.	Primary

6. Learning Topics

Basic

Core Topic 01: 코드 서명(Code Signing)과 프로비저닝 프로파일

Why to Learn: 애플이나 구글이 출처를 알 수 없는 바이너리가 유저 폰에 설치되는 것을 암호학적으로 원천 봉쇄하는 철옹성을 통과하기 위함입니다.
What to Learn: Keystore / Upload Key(Android), Certificate, App ID, Provisioning Profile(iOS), Entitlements.
How to Learn: 개발자 인증서(Who), App ID(What), Device 리스트(Where)가 암호학적으로 하나로 묶인 프로비저닝 프로파일 문서를 뜯어보고, 이 세 가지 중 단 하나라도 매칭되지 않으면 빌드 기계가 컴파일 직전에 서명(Signature)을 뱉어내는 엄격한 자물쇠를 이해합니다.
Implement: Xcode를 켜지 않고 터미널(xcodebuild)에서 수동으로 릴리스 키를 주입해 IPA 바이너리를 생성하고, 서명 무결성을 검증(codesign -v)하는 CLI(Command Line) 빌드 스크립트 작성.

Core Topic 02: Fastlane과 파이프라인(CI) 자동화

Why to Learn: 빌드 돌리고, 버전 넘버 1 올리고, 캡처 화면 5장 떠서 스토어에 드래그 앤 드롭하는 잉여 인간의 단순 노동을 스크립트 로봇에게 떠넘기기 위함입니다.
What to Learn: Fastlane (Ruby), GitHub Actions / Bitrise, 릴리스 레인(Lane), CI 스크립트.
How to Learn: 개발자가 "v1.2 배포"라고 태그를 달면, 클라우드 머신이 깨어나서 Git 코드를 받고 $ightarrow→ 유닛 테스트를 치고 → ightarrow→ 버전 범프(Bump)를 하고 → ightarrow$ 스토어 API를 찔러 바이너리를 밀어 넣는 컨베이어 벨트를 시각화합니다.
Implement: Fastfile을 작성하여 lane :beta 실행 시 1) 빌드 클린 2) 단위 테스트 실행 3) Firebase App Distribution으로 테스터들에게 APK/IPA를 자동 이메일 송출하는 자동화 스크립트 배포.

Why to Learn: 1년 전 앱 버전을 아직도 폰에 쥐고 있는 극소수 악성(?) 유저 때문에 서버 API 아키텍처를 업그레이드하지 못하는 백엔드의 족쇄를 끊기 위함입니다.
What to Learn: Fragmentation, 강제 업데이트(Force Update), 권장 업데이트(Soft Update), Remote Config.
How to Learn: 앱이 켜질 때 즉시 서버 API로 min_required_version 값을 요청하고, 현재 내 앱 버전이 그보다 낮으면 화면 전체를 덮는 투명 다이얼로그(Dim)를 띄워 "스토어로 이동" 버튼 말고는 아무것도 누를 수 없게 차단하는 런타임 잠금 장치를 구축합니다.
Implement: Firebase Remote Config에서 '최소 요구 버전'을 1.5로 쏘고, 앱 내 버전이 1.4일 경우 유저의 뒤로가기 제스처까지 전부 인터셉트하여 마비시키는 얼음(Freeze) 방어막 컴포넌트 설계.

Core Topic 04: 앱스토어 심사 생태계와 점진적 릴리스(Phased Release)

Why to Learn: 스토어 심사에 떨어져서 일주일 동안 배포가 지연되는 스타트업의 지옥을 피하고, 치명적 버그 앱이 100만 명에게 동시에 깔리는 재앙을 1만 명 선에서 끊어내기 위해서입니다.
What to Learn: App Store Review Guidelines, 구글 Play Console 심사, Phased Release (점진적 배포), 심사 우회 제약.
How to Learn: 유저 100%에게 릴리스 스위치를 올렸는데 결제 버그가 발견되어(Rollback 불가) 밤을 새우는 공포 대신, 첫날 1%, 둘째 날 5%에게만 스토어 업데이트가 노출되게 통제하다 크래시 비율이 오르면 즉시 릴리스를 멈추는 방수벽 밸브(Valve)를 제어합니다.
Implement: "로그인 안 하고도 둘러보기 기능 제공", "외부 결제 링크 아웃 차단" 등 애플 심사 가이드라인 3대 리젝(Reject) 사유를 위반하는지 점검하는 런칭 전(Pre-flight) 체크리스트 문서화 및 자동 스캔 통과 기준 확립.

7. Terminology

Term (EN / ko, abbr)	1문장 정의	단계(기본/권장/실무/심화)	역할/맥락	관련 개념	유사/대비/함께 사용	오해 포인트	Evidence(Primary/Secondary/Industry)	Flags(core)
Code Signing	이 앱 코드를 만든 사람이 진짜 '너'인지, 그리고 해커가 바이너리를 중간에 조작하지 않았는지 도장을 찍어 OS가 확인하는 암호 물리입니다.	기본	무결성 검증	Keystore, Prov Profile	vs. Unsigned APK	코드 서명만 하면 스토어 심사까지 다 통과된다는 맹신	Primary	core
Fastlane	iOS/Android의 빌드, 스크린샷 캡처, 스토어 업로드 등 손으로 하던 모든 노가다를 자동화해 주는 모바일계의 CD(배포) 로봇입니다.	실무	배포 자동화	CI/CD, Github Actions	vs. Manual Archive	Fastlane이 컴파일러 자체 속도를 빠르게 해 준다는 오해 (자동화 도구임)	Industry Docs	core
Force Update	앱이 켜질 때 서버에서 최소 허용 버전을 읽어와, 기준 미달인 유저 기기의 화면을 얼려버리고 앱스토어로 내쫓는 강제 통제망입니다.	권장	버전 파편화	Remote Config	vs. OTA (Over-The-Air)	모든 업데이트를 유저가 폰에서 자동 다운로드하게 만들 수 있다는 웹 개발자의 착각	Primary	core
Phased Release	앱을 100%의 유저에게 동시에 배포하지 않고 1% $
ightarrow $5%$
ightarrow$ 100%로 7일에 걸쳐 서서히 풀며 크래시가 터지면 중단하는 안전장치입니다.	실무	리스크 분산	Staged Rollout	vs. Big Bang Release	점진적 배포 중 오류가 나면 롤백(이전 버전 설치)이 가능하다는 치명적 오해 (롤백 안 됨)	Industry/Google	core

8. References

Primary References

[CS2023: Software Engineering] — 지속적 통합/지속적 배포(CI/CD) 파이프라인, 버전 관리 시스템(Version Control) 및 릴리스 파편화 제어.
[SWEBOK v3: Software Quality] — 리스크 완화(Risk Mitigation) 릴리스 전략, 서명 무결성 증명 체계.

Secondary References

[Fastlane Documentation] — 릴리스 레인(Lane), match를 통한 중앙 집중화된 인증서(Provisioning Profile/Keystore) 암호화 주입 저장소.
[Feature Toggles (Martin Fowler)] — 피처 플래그 기반 런타임 제어망 및 다중 버전 백엔드 API 하위 호환성 유지 룰.

Industry References

[Apple Developer: App Store Review Guidelines] — 흔한 리젝(Reject) 사유: 외부 결제, 개인정보 수집 고지 누락, 데모 뷰 부재 등 심사 룰.
[Google Play Console: Staged rollouts] — 단계적 출시를 통한 크래시 발생율 모니터링 및 업데이트 강제 중지(Halt) 트리거 물리.

9. Final Checklist

Primary Checklist

로컬 PC(Mac)의 수동 빌드/아카이브에 의존하지 않고, GitHub Actions나 Bitrise 같은 클라우드 CI 시스템과 Fastlane을 엮어 빌드 릴리스 로봇 파이프라인을 100% 자동화했는가?
iOS 배포 시 프로비저닝 프로파일 갱신 누락이나 인증서 만료로 빌드가 터지는 단일 장애점(SPOF)을 막기 위해, fastlane match 등으로 암호화된 중앙 집중 인증서 저장소를 구축했는가?

Secondary Checklist

심각한 보안 결함이나 서버 API 브레이킹 체인지(Breaking Change) 발생 시, 구버전 앱을 실행한 유저가 더 이상 진입하지 못하도록 서버 원격 구성(Remote Config) 기반의 강제 업데이트(Force Update) 잠금 화면을 마련했는가?
신규 버전을 스토어에 프로덕션 출시할 때, 치명적 버그가 100만 명에게 동시 타격(Big Bang)되는 것을 막기 위해 유저의 1%부터 시작하는 점진적 배포(Phased Release / Staged Rollout)를 기본 정책으로 세팅했는가?

Industry Checklist

앱스토어/플레이스토어 배포 바이너리 생성 후, dSYM(iOS)과 Proguard Mapping File(Android)을 Firebase Crashlytics 같은 리포팅 툴에 자동 업로드하여 난독화된 오류 코드를 사람 언어로 즉시 해독(De-obfuscation)하는가?
앱스토어 심사(App Review) 도중 테스터가 소셜 로그인이나 서버 환경에 샌드박스로 접근할 수 있도록 데모(테스트) 계정 정보와 우회 통로를 App Store Connect 심사 노트에 명확히 주입했는가?