26 · 앱 크기와 배포

P1의 마지막 챕터다. P0 14장이 "컴파일·링크·dyld 로드"의 원리였다면, 여기서는 그 산출물이 사용자에게 전달되는 과정을 다룬다 — 얼마나 크고, 왜 그만큼이며, 어떻게 재고, 어떻게 늘어나는 것을 막는가. 앱 크기는 설치 이탈률에 직접 연결되는 제품 지표이면서, 동시에 실행 시간과도 얽혀 있다(18장 Q7의 콜드 스타트). 그래서 성능 작업의 마지막 축이기도 하다.

Q1. 다운로드 크기와 설치 크기는 왜 다른가?

CS 원리

같은 앱에 여러 크기가 존재하는 이유는 세 단계의 변환을 거치기 때문이다.

1. 빌드 산출물 — 모든 아키텍처, 모든 해상도 자산, 디버그 심볼을 포함한 최대 크기.
2. 시닝(thinning) — 대상 기기에 필요한 것만 남긴다. 아키텍처 하나, 해당 해상도 자산만.
3. 압축 — 전송을 위해 압축한다.

그래서 나오는 숫자가 다르다.

두 숫자가 서로 다른 문제를 나타낸다는 점이 중요하다. 다운로드 크기는 설치 시점의 장벽이고, 설치 크기는 계속 남는 부담이다. 저장 공간이 부족한 사용자는 큰 앱부터 지운다.

그리고 압축률은 내용에 따라 크게 다르다. 이미 압축된 데이터(JPEG·동영상)는 더 안 줄지만, 실행 바이너리와 텍스트는 잘 줄어든다. 그래서 다운로드 크기를 줄이는 최적화와 설치 크기를 줄이는 최적화가 다를 수 있다.

iOS에서는

Apple 문서가 명확히 경고하는 것부터 짚어야 한다 — 디버깅용으로 만들거나 Xcode에서 App Store Connect에 업로드하는 바이너리는 크기 측정에 적합하지 않다. 구체적으로 다음을 쓰면 안 된다.

• .app 번들
• .xcarchive 번들
• 업로드용 .ipa 파일

이유는 사용자가 받는 번들에 없는 것들이 들어 있기 때문이다 — 대표적으로 크래시 리포팅용 dSYM(21장)이다. dSYM은 수십~수백 MB인데 사용자는 받지 않는다. 그래서 .ipa 파일 크기를 앱 크기로 보고하면 크게 부풀려진 값이 된다.

정확한 값을 얻는 경로는 둘이다.

• 개발 중 — Mac에서 App Size Report를 만든다. 다운로드·설치 크기의 근접 추정치를 준다.
• 배포 후 — App Store Connect가 가장 정확하다. 변형별 크기를 보여주고, 모바일 연결로 다운로드하는 한도를 넘으면 경고한다.

그리고 실무에서 자주 혼동되는 두 가지 비대칭이 있다.

(1) TestFlight 빌드가 더 크다. Apple 문서 명시 — TestFlight로 배포되는 앱에는 App Store 빌드에 없는 추가 데이터가 들어 있어 더 크다. 이 데이터는 App Store 배포 시에는 포함되지 않는다. 그래서 TestFlight에서 본 크기로 판단하면 과대평가한다.

(2) App Store 최종 크기가 업로드한 바이너리보다 커질 수 있다. 이것도 문서에 명시돼 있다 — App Store가 앱 바이너리에 추가 처리를 해서, 불법 복제 방지를 위한 DRM을 추가하고 다시 압축하기 때문이다. 그래서 "업로드 전에 재봤으니 됐다"가 정확하지 않다.

왜 크기가 중요한지도 문서가 설명한다 — App Store는 모바일 연결로 설치할 수 있는 앱 크기에 한도를 둔다. 한도를 넘으면 사용자가 Wi-Fi에 연결해야 설치할 수 있다. 그래서 Apple의 권고는 "한도보다 충분히 낮게 유지해 설치 가능 사용자 기반을 최대화하고 설치 시간을 최소화하라"이다.

실험 · 도구

App Size Report 만드는 절차는 정해져 있다.

# ── Xcode UI로 만들기 ──
# 1. Product › Archive
# 2. Organizer에서 Distribute App
# 3. Ad Hoc / Development / Enterprise 중 하나 선택
# 4. 앱 시닝 옵션에서 "All compatible device variants" 선택   ← 이게 핵심
# 5. 서명하고 Mac으로 export
#
# 결과 폴더에 생기는 것:
#   - universal IPA (구형 기기용, 모든 변형 포함)
#   - 변형별 thinned IPA
#   - App Thinning Size Report.txt   ← 이 파일이 목적

리포트 형식은 이렇다.

App Thinning Size Report for All Variants of ExampleApp

Variant: ExampleApp.ipa
Supported variant descriptors: [device: iPhone11,4, os-version: 12.0], …
App + On Demand Resources size: 6.7 MB compressed, 18.6 MB uncompressed
App size: 6.7 MB compressed, 18.6 MB uncompressed
On Demand Resources size: Zero KB compressed, Zero KB uncompressed

compressed가 다운로드 크기, uncompressed가 설치 크기다. 이 예시에서는 2.8배 차이가 난다.

CI에서 자동화하려면 xcodebuild로 export하면서 thinning 키를 <thin-for-all-variants>로 준다.

# ── CI 자동화 ──
# ExportOptions.plist 에 thinning 키를 넣는다
cat > ExportOptions.plist <<'PLIST'
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>method</key><string>ad-hoc</string>
  <key>thinning</key><string>&lt;thin-for-all-variants&gt;</string>
</dict>
</plist>
PLIST
#   ⚠️ 값의 꺾쇠괄호는 반드시 이스케이프해야 한다 (문서 명시)

xcodebuild -exportArchive \
  -archivePath build/MyApp.xcarchive \
  -exportPath build/export \
  -exportOptionsPlist ExportOptions.plist

# 리포트에서 숫자만 뽑아낸다
grep "^App size:" "build/export/App Thinning Size Report.txt" | head -1
#   App size: 6.7 MB compressed, 18.6 MB uncompressed

파싱해서 지표로 만드는 스크립트는 이렇다.

#!/bin/bash
# 모든 변형의 크기를 뽑아 최댓값을 기준으로 삼는다
REPORT="build/export/App Thinning Size Report.txt"

awk '
  /^Variant:/          { variant = $2 }
  /^App size:/         {
    # "App size: 6.7 MB compressed, 18.6 MB uncompressed"
    dl = $3; dlu = $4; inst = $6; instu = $7
    printf "%-40s 다운로드 %s %s / 설치 %s %s\n", variant, dl, dlu, inst, instu
  }
' "$REPORT"

# 가장 큰 변형이 기준이다 — 그 기기 사용자가 가장 오래 기다린다

프로젝트 적용

크기 관리의 출발점 넷.

• .ipa 파일 크기를 앱 크기로 보고하지 않는다. dSYM 등이 포함돼 부풀려진 값이다. 이 실수가 매우 흔하고, 실제보다 나쁘게 보이게 만든다.
• App Size Report를 CI에 넣는다. 릴리스마다 자동 생성해 기록하면 추세가 보인다. Q5에서 다룰 회귀 감시의 기반이다.
• 가장 큰 변형을 기준으로 본다. 평균이 아니라 최악의 기기가 사용자 경험을 결정한다.
• App Store Connect 값과 정기적으로 대조한다. 개발 중 리포트는 근접 추정치이고, DRM 추가와 재압축 때문에 최종 값이 다를 수 있다.

꼬리 질문

Q2. 앱 크기는 무엇이 지배하는가?

CS 원리

바이너리 크기가 커지는 메커니즘을 알면 대응이 명확해진다.

• 코드 자체 — 우리가 쓴 코드와 의존성의 코드.
• 제네릭 특수화 — Swift 컴파일러가 제네릭 함수를 구체 타입별로 복제한다(P0 05장 Q7). 성능은 좋아지지만 코드 크기가 늘어난다.
• 인라이닝 — 함수 본문이 호출 지점에 복제된다(21장 Q4). 같은 트레이드오프다.
• 메타데이터 — Swift 런타임이 쓰는 타입 메타데이터, 프로토콜 준수 정보, 리플렉션 정보.
• 문자열 상수 — 소스에 박힌 문자열이 그대로 바이너리에 들어간다.

두 번째와 세 번째가 최적화 레벨과 직결된다. Swift의 -O는 성능을 위해 특수화와 인라이닝을 적극적으로 하고, -Osize는 코드 크기가 크게 늘어나는 경우를 억제한다. 그래서 같은 코드가 설정에 따라 눈에 띄게 다른 크기가 된다. 주의 — Swift에는 -Os가 없다(unknown argument 에러). Xcode의 Fastest, Smallest [-Os]는 C/ObjC용 GCC_OPTIMIZATION_LEVEL 설정이고, Swift는 별도로 SWIFT_OPTIMIZATION_LEVEL을 쓴다.

자산 쪽 원리는 다르다. 여기서는 중복이 핵심 문제다.

• 해상도 중복 — @1x·@2x·@3x가 다 들어가면 대부분의 사용자에게 3분의 2가 낭비다.
• 포맷 비효율 — 압축 설정이 적절하지 않으면 그대로 커진다.
• 미사용 자산 — 쓰지 않는 이미지·폰트·데이터가 계속 남아 있다.

Apple이 에셋 카탈로그를 강조하는 이유가 여기 있다 — 카탈로그에 넣고 메타데이터를 태그해야 시스템이 골라낼 수 있다. 번들에 파일로 넣으면 시스템은 그게 뭔지 모르므로 전부 전달한다.

iOS에서는

Apple이 제시하는 기본 최적화 순서를 그대로 따르는 것이 효율적이다.

1단계 — 릴리스 빌드 설정 확인. Apple 문서는 Release 구성의 기본 최적화 레벨이 Fastest, Smallest [-Os]이며 이것이 컴파일된 바이너리를 매우 작게 만들 수 있다고 안내한다 — 이는 C/ObjC(GCC_OPTIMIZATION_LEVEL) 이야기다. Swift는 SWIFT_OPTIMIZATION_LEVEL이 별도이고 Release 기본값이 -O다. 앱이 예상보다 크다면 설정이 의도치 않게 바뀌지 않았는지 먼저 확인한다.

# 최적화 레벨 확인 — Swift와 C/ObjC 는 설정이 별개다
xcodebuild -showBuildSettings -configuration Release -scheme MyApp \
  | grep -E 'SWIFT_OPTIMIZATION_LEVEL|GCC_OPTIMIZATION_LEVEL|LLVM_LTO'
#   SWIFT_OPTIMIZATION_LEVEL = -O        ← Swift Release 기본값 (속도 우선)
#   GCC_OPTIMIZATION_LEVEL = s           ← C/ObjC 는 s (=-Os)
#
# ⚠️ -Onone 으로 바뀌어 있으면 바이너리가 크게 는다.
#    크기가 문제라면 Swift 는 -Osize 를 검토한다 (기본값 아님, 성능과 맞바꿈).
#    Swift 에 -Os 는 존재하지 않는다.

2단계 — IPA를 뜯어본다. Apple이 안내하는 절차가 명확하다.

# thinned IPA 를 만든 뒤 (Q1) 내용을 직접 확인한다
cd build/export
cp "MyApp-iPhone14,2.ipa" inspect.zip
unzip -q inspect.zip -d inspect/
# 또는 풀지 않고 목록만 크기순으로 본다
unzip -lv inspect.zip | sort -k1 -n -r | head -30

# 앱 번들 안에서 가장 큰 항목 찾기
du -ah "inspect/Payload/MyApp.app" | sort -rh | head -30
#   → 여기서 실행 바이너리가 큰지, 자산이 큰지가 즉시 드러난다

# 실행 바이너리 내부 구성 보기
size -m "inspect/Payload/MyApp.app/MyApp"
#   __TEXT (코드) / __DATA / __LINKEDIT 별 크기

# 섹션별 상세 — Swift 메타데이터가 큰지 확인할 수 있다
otool -l "inspect/Payload/MyApp.app/MyApp" | grep -A4 "sectname" | head -60

Apple이 함께 안내하는 것이 미사용 파일 정리다 — 앱의 README 파일을 타깃에 추가하지 않았는지 확인하고, 사용하지 않는 이미지 자산과 헤더 파일을 제거하라는 구체적 예시까지 준다. 실제로 이런 것들이 쌓이는 경우가 흔하다.

3단계 — 에셋 카탈로그 채택. 문서가 권하는 것 셋이다.

• 메타데이터 태그. 각 자산에 어느 기기용인지 표시해 시닝 효과를 최대화한다.
• 리사이즈 가능 영역 정의. 이미지의 늘어나는 중앙 영역과 끝 캡을 정의하면 작은 이미지로 큰 영역을 채울 수 있다.
• 자산 유형별 압축 레벨 설정. 특히 wide color 이미지나 Metal 텍스처는 ASTC 압축을 고려한다.

4단계 — 데이터를 코드에서 빼낸다. 이것도 문서의 구체적 권고다 — 코드에 문자열로 데이터를 넣지 말고 property list 같은 자산 파일로 번들하라는 것이다. 일부 개발자가 소스 코드로 이미지 같은 리소스를 배포하기도 하는데, 이런 것들을 자산 파일로 옮기면 바이너리 크기가 크게 줄고, App Store Connect가 더 효율적으로 압축할 수 있다.

실험 · 도구

어디가 큰지 자동으로 분해하는 스크립트를 만들어두면 매번 편하다.

#!/bin/bash
# 앱 번들 구성을 카테고리별로 집계한다
APP="$1"   # inspect/Payload/MyApp.app

echo "── 전체"
du -sh "$APP"

echo "── 실행 바이너리"
find "$APP" -maxdepth 1 -type f -perm +111 -exec du -h {} \; 2>/dev/null

echo "── 임베디드 프레임워크 (Q3)"
du -sh "$APP"/Frameworks/* 2>/dev/null | sort -rh

echo "── 앱 익스텐션 (24장)"
du -sh "$APP"/PlugIns/* 2>/dev/null | sort -rh

echo "── 에셋 카탈로그"
du -h "$APP"/Assets.car 2>/dev/null

echo "── 번들에 직접 들어간 파일 상위 20"
find "$APP" -type f ! -path "*/Frameworks/*" ! -path "*/PlugIns/*" \
  -exec du -h {} \; | sort -rh | head -20
#   ⚠️ 여기에 README, 테스트 픽스처, 미사용 이미지가 있는지 본다

에셋 카탈로그 내부는 assetutil로 들여다볼 수 있다.

# Assets.car 안의 항목별 정보
xcrun assetutil --info "$APP/Assets.car" > assets.json
python3 - <<'PY'
import json
items = json.load(open("assets.json"))
sized = [(i.get("SizeOnDisk", 0), i.get("Name", "?"), i.get("Scale", "")) for i in items if isinstance(i, dict)]
for s, n, sc in sorted(sized, reverse=True)[:20]:
    print(f"{s/1024:8.1f} KB  {n} @{sc}x")
PY
# → 어느 이미지가 큰지, 불필요한 스케일이 들어갔는지 확인

Swift 특유의 크기 요인도 확인할 수 있다.

# 심볼 크기 상위 — 제네릭 특수화가 폭발한 곳을 찾는다
nm -nm "$APP/MyApp" | sort -k1 | tail -30    # 주소 순 상위 심볼 (대략적 감만 준다)

# 링커 맵으로 정확한 기여도 확인 — 빌드 설정에서 Write Link Map File = YES
#   Build Settings › Write Link Map File
#   결과: DerivedData/.../MyApp-LinkMap-normal-arm64.txt
awk '/^# Symbols:/{f=1;next} f{print $2, $NF}' MyApp-LinkMap-normal-arm64.txt \
  | sort -k1 -r | head -30
#   → 어느 심볼·어느 오브젝트 파일이 바이너리를 키우는지 정량적으로 나온다

링크 맵이 가장 정확한 도구다. 심볼별·오브젝트 파일별 기여도를 바이트 단위로 알려주므로, "어느 모듈이 바이너리의 몇 %인가"를 정확히 답할 수 있다.

프로젝트 적용

크기 관리 실무 규칙 다섯.

• 측정부터 한다. 추측으로 최적화하면 효과 없는 곳에 시간을 쓴다. IPA를 뜯고 링크 맵을 보는 30분이 며칠을 아낀다.
• 빌드 설정을 먼저 확인한다. 최적화 레벨이 잘못돼 있으면 다른 무엇보다 효과가 크고, 확인 비용이 0에 가깝다.
• 에셋 카탈로그를 기본으로. Apple 표현대로 일찍 채택하면 나중에 비싼 최적화가 필요할 가능성이 줄어든다. 새 프로젝트라면 처음부터 그렇게 한다.
• 코드에 데이터를 넣지 않는다. 큰 문자열 상수, 코드로 표현한 이미지, 하드코딩된 JSON은 자산 파일로 옮긴다.
• 미사용 자산 정리를 주기적으로. 기능이 제거돼도 자산은 남는 경우가 많다. 릴리스마다 상위 항목을 훑으면 발견된다.

꼬리 질문

# 오브젝트 파일별 크기 합산
python3 - <<'PY'
import re, collections, sys
path = "MyApp-LinkMap-normal-arm64.txt"
objs, sizes = {}, collections.Counter()
section = None
for line in open(path, encoding="utf-8", errors="ignore"):
    if line.startswith("#"):
        if "Object files:" in line: section = "obj"
        elif "Symbols:" in line:    section = "sym"
        else:                        section = None
        continue
    if section == "obj":
        m = re.match(r"\[\s*(\d+)\]\s+(.*)", line.strip())
        if m: objs[int(m.group(1))] = m.group(2)
    elif section == "sym":
        parts = line.split()
        if len(parts) >= 3 and parts[1].startswith("0x"):
            size = int(parts[1], 16)
            m = re.match(r"\[\s*(\d+)\]", parts[2])
            if m: sizes[int(m.group(1))] += size

# 라이브러리 단위로 묶는다 — libFoo.a(Bar.o) 에서 libFoo.a 를 추출
lib = collections.Counter()
for idx, size in sizes.items():
    name = objs.get(idx, "?")
    m = re.search(r"([^/]+\.a)\(", name)
    lib[m.group(1) if m else "(앱 코드)"] += size

for name, size in lib.most_common(20):
    print(f"{size/1024/1024:8.2f} MB  {name}")
PY

Q3. 동적 프레임워크는 어떤 비용을 주는가?

CS 원리

정적 링크와 동적 링크의 차이가 크기에 미치는 영향을 정리하면 이렇다.

dead code stripping이 경계를 못 넘는다는 점이 크기 관점의 핵심이다. 정적 라이브러리라면 링커가 실제로 참조되는 오브젝트 파일만 가져올 수 있지만, 동적 프레임워크는 독립적으로 로드되는 단위라 통째로 포함된다. 큰 SDK에서 함수 하나만 써도 전부 들어간다.

실행 시간 쪽 원리는 P0 14장의 dyld 논의로 돌아간다. 앱 시작 시 dyld가 하는 일이 있다.

1. 각 동적 라이브러리를 찾아서 메모리에 매핑한다.
2. 의존성을 재귀적으로 해결한다.
3. 심볼을 바인딩한다 — 각 참조를 실제 주소로 연결.
4. 초기화 코드(+load, C++ 정적 생성자 등)를 실행한다.

이 비용이 프레임워크 개수에 비례한다. 그래서 작은 프레임워크 20개가 큰 프레임워크 1개보다 느리다 — 총 코드량이 같아도 그렇다.

시스템 프레임워크는 예외다. dyld 공유 캐시에 미리 준비돼 있어 이 비용이 대부분 사라진다. 우리가 만든 프레임워크는 캐시에 없으므로 매번 비용을 낸다.

iOS에서는

실무 선택지와 특성을 정리하면 이렇다.

XCFramework는 별개 축이라는 점을 짚어야 한다. XCFramework는 여러 플랫폼·아키텍처 변형을 한 배포 단위로 묶는 포맷이지 정적/동적 여부를 정하는 것이 아니다. 안에 정적 라이브러리가 들어갈 수도, 동적 프레임워크가 들어갈 수도 있다.

배포 형태로 XCFramework가 표준이 된 이유는 fat binary의 한계 때문이다. 예전에는 여러 아키텍처를 하나의 바이너리에 합쳤는데, 시뮬레이터용 arm64와 기기용 arm64가 같은 아키텍처 이름이라 구분이 안 되는 문제가 생겼다. XCFramework는 플랫폼별로 디렉터리를 나눠 이를 해결한다.

그리고 24장의 익스텐션 제약이 여기 연결된다. 익스텐션과 코드를 공유하는 정식 수단이 embedded framework이므로, 익스텐션이 있으면 동적 프레임워크가 필요할 수 있다. 이 경우 크기·시작 시간 비용을 감수하는 대신, 익스텐션마다 코드가 복제되는 것을 피한다 — 정적으로 하면 앱과 익스텐션 각각에 코드가 들어가 오히려 더 커질 수 있다.

실험 · 도구

프레임워크 개수가 시작 시간에 미치는 영향은 직접 잴 수 있다.

# dyld가 앱 시작에 쓰는 시간을 출력한다 (동작하는 환경이라면)
#   Xcode › Edit Scheme › Run › Arguments › Environment Variables
#     DYLD_PRINT_STATISTICS = 1
#   ⚠️ 현행 OS 에서는 출력이 없을 수 있다 → Instruments App Launch 템플릿 사용
#
# 콘솔 출력 예시:
#   Total pre-main time: 412.19 milliseconds (100.0%)
#           dylib loading time:  198.34 milliseconds (48.1%)   ← 프레임워크 로드
#          rebase/binding time:   62.11 milliseconds (15.0%)   ← 심볼 바인딩
#              ObjC setup time:   41.22 milliseconds (10.0%)
#             initializer time:  110.52 milliseconds (26.8%)   ← +load 등
#
#   → dylib loading 이 크면 프레임워크 개수를 줄이는 것이 직접적 개선이다

# 실제로 로드되는 동적 라이브러리 목록과 개수
otool -L "MyApp.app/MyApp" | grep -c "@rpath"
otool -L "MyApp.app/MyApp" | grep "@rpath"

# 번들 안 프레임워크 크기 순위
du -sh MyApp.app/Frameworks/* | sort -rh

정적/동적 전환의 효과를 비교하려면 두 빌드를 만들어 잰다.

# SPM 의존성이라면 Package.swift 에서 type을 바꿔 비교할 수 있다
#   .library(name: "Core", type: .static,  targets: ["Core"])
#   .library(name: "Core", type: .dynamic, targets: ["Core"])
#
# 각각 빌드해 App Size Report(Q1)와 DYLD_PRINT_STATISTICS를 비교한다

# 비교 항목:
#   1) 다운로드/설치 크기      (Q1의 리포트)
#   2) pre-main 시간           (DYLD_PRINT_STATISTICS)
#   3) 앱 + 익스텐션 총 크기   (익스텐션이 있으면 정적이 더 클 수 있다)

3번이 중요하다. 익스텐션이 있는 앱에서는 정적이 항상 작은 것이 아니다. 앱과 익스텐션 두 곳에 같은 코드가 들어가면 동적으로 공유하는 편이 총합이 작다.

// 시작 시간에 영향을 주는 것 — 초기화 코드도 dyld 비용이다
// ❌ 전역 상수의 초기화가 무거우면 앱 시작에 얹힌다
let heavyResource = loadLargeConfiguration()     // 프로세스 시작 시 실행될 수 있다

// ✅ 지연 초기화로 미룬다
enum Config {
    static let shared: Configuration = {
        // 실제로 처음 접근할 때 초기화된다 (swift_once)
        loadLargeConfiguration()
    }()
}
// ⚠️ 다만 19장 Q6에서 본 대로, 지연 초기화는 크래시 핸들러 같은
//    제약 있는 컨텍스트에서 예기치 않은 할당을 유발할 수 있다.

프로젝트 적용

선택 기준 다섯.

• 기본값을 정적으로 둔다. 익스텐션 공유가 필요하지 않다면 정적이 크기와 시작 시간 모두에 유리하다.
• 익스텐션이 있으면 총합으로 판단한다. 앱 + 익스텐션 전체 크기를 비교해야 정확하다.
• 프레임워크 개수를 줄인다. 모듈 분리는 빌드 시간과 아키텍처에 좋지만, 배포 단위까지 쪼갤 필요는 없다. 개발 시에는 여러 모듈로 두고 배포 시 하나로 합치는 구성이 좋다.
• 시작 시간을 측정한다. DYLD_PRINT_STATISTICS로 pre-main 시간을 보고, dylib loading 비중이 크면 개수를 줄인다. 18장 Q7의 콜드 스타트 예산과 같은 축이다.
• SDK 도입 시 크기 기여도를 확인한다. Q2의 링크 맵 분석으로 정량화하고, 도입 기준에 크기 항목을 넣는다 — 21장(dSYM), 23장(privacy manifest), 24장(app-extension-safe)에 이은 네 번째 도입 기준이다.

꼬리 질문

// Package.swift — 개발은 모듈별로, 배포는 앱 바이너리에 통합
products: [
    .library(name: "Core",      type: .static, targets: ["Core"]),
    .library(name: "Networking", type: .static, targets: ["Networking"]),
    .library(name: "Design",     type: .static, targets: ["Design"]),
]

Q4. 크기 회귀를 CI에서 어떻게 막는가?

CS 원리

크기 회귀는 점진적 열화(gradual degradation)의 전형이다. 한 번에 크게 늘지 않고 릴리스마다 조금씩 늘어난다. 이런 문제의 성질이 셋 있다.

• 개별 변경은 정당해 보인다. 기능 추가에 200KB가 늘었다면 누구도 반대하지 않는다. 그런데 50번 반복되면 10MB다.
• 책임이 분산된다. 누구의 잘못도 아니므로 아무도 고치지 않는다.
• 임계에 도달했을 때는 이미 늦다. 되돌리려면 수십 개의 결정을 재검토해야 한다.

이런 문제에 효과적인 대응이 예산제(budget)다. 총량을 정해두고 넘으면 무언가를 빼야 하게 만든다. 그러면 각 추가 결정이 기회비용을 갖게 되어, "이 기능이 저 기능보다 3MB 가치가 있나"라는 질문이 자연스럽게 나온다.

다만 예산제가 작동하려면 조건이 있다.

1. 측정이 자동이고 신뢰할 수 있어야 한다. 수동 측정은 반드시 빠진다.
2. 피드백이 빨라야 한다. PR 단계에서 알려줘야 그 자리에서 조정한다. 릴리스 후에 알면 되돌리기 어렵다.
3. 원인을 알려줘야 한다. "5MB 늘었다"만 알려주면 조사 비용 때문에 무시하게 된다.

3번이 특히 중요하다. 원인 없는 경고는 결국 임계를 올리는 것으로 귀결된다.

iOS에서는

CI 파이프라인 구성을 단계별로 정리하면 이렇다.

#!/bin/bash
set -euo pipefail

ARCHIVE="build/MyApp.xcarchive"
EXPORT="build/export"
BASELINE="ci/size-baseline.json"

# ── 1. 아카이브 + 시닝 export (Q1) ──
xcodebuild archive -scheme MyApp -configuration Release \
  -archivePath "$ARCHIVE" -destination 'generic/platform=iOS'

xcodebuild -exportArchive -archivePath "$ARCHIVE" \
  -exportPath "$EXPORT" -exportOptionsPlist ci/ExportOptions.plist
#   ExportOptions.plist 에 thinning = <thin-for-all-variants> 필수

# ── 2. 리포트 파싱 — 가장 큰 변형을 기준으로 삼는다 ──
REPORT="$EXPORT/App Thinning Size Report.txt"
python3 ci/parse_size_report.py "$REPORT" > build/size-current.json
cat build/size-current.json
#   {"max_download_mb": 24.3, "max_install_mb": 61.8, "variant": "iPhone14,2"}

# ── 3. 기준선과 비교 ──
python3 ci/compare_size.py "$BASELINE" build/size-current.json
#   실패 시 exit 1 — 빌드가 멈춘다

비교 스크립트가 원인까지 알려주는 것이 핵심이다.

# ci/compare_size.py
import json, sys

baseline = json.load(open(sys.argv[1]))
current  = json.load(open(sys.argv[2]))

THRESHOLD_PCT = 3.0      # 이전 릴리스 대비 3% 이상 증가하면 실패
THRESHOLD_MB  = 1.0      # 또는 절대 1MB 이상 (둘 중 하나만 넘어도 실패)

failed = False
for key, label in [("max_download_mb", "다운로드"), ("max_install_mb", "설치")]:
    before, after = baseline[key], current[key]
    delta = after - before
    pct = delta / before * 100 if before else 0
    mark = "  "
    # 절대값과 비율 중 하나만 넘어도 실패시킨다.
    # AND 로 두면 앱이 커질수록 같은 MB 증가가 낮은 %가 되어 큰 증가를 놓친다.
    if delta > THRESHOLD_MB or pct > THRESHOLD_PCT:
        mark, failed = "❌", True
    elif delta > 0:
        mark = "⚠️ "
    print(f"{mark} {label}: {before:.1f} → {after:.1f} MB "
          f"({delta:+.2f} MB, {pct:+.1f}%)")

if failed:
    print("\n크기 회귀 감지. 원인 분석:")
    # 번들 구성 diff 를 함께 출력한다 — 이게 없으면 개발자가 임계만 올린다
    print(open("build/size-diff.txt").read())
    sys.exit(1)

원인 분석은 번들 구성과 링크 맵을 diff해서 만든다.

# ci/size-diff.sh — 무엇이 늘었는지 항목별로 비교한다
inventory() {
  local app="$1"
  # 파일별 크기 목록 (경로를 앱 번들 기준 상대 경로로)
  find "$app" -type f -exec sh -c 'echo "$(stat -f%z "$1") ${1#*.app/}" ' _ {} \; \
    | sort -k2
}

inventory "build/baseline/MyApp.app"  > /tmp/base.txt
inventory "build/export/Payload/MyApp.app" > /tmp/curr.txt

join -j2 -a1 -a2 -e 0 -o 0,1.1,2.1 /tmp/base.txt /tmp/curr.txt \
  | awk '{ d = $3 - $2; if (d != 0) printf "%+10.1f KB  %s\n", d/1024, $1 }' \
  | sort -rn | head -25 > build/size-diff.txt

cat build/size-diff.txt
#   + 2841.3 KB  Frameworks/NewAnalyticsSDK.framework/NewAnalyticsSDK
#   +  412.0 KB  Assets.car
#   +   88.5 KB  MyApp
#   → "새 SDK가 2.8MB" 라는 결론이 즉시 나온다

이 출력이 있으면 PR 리뷰에서 바로 논의가 된다 — "이 SDK가 2.8MB인데 정말 필요한가?"

실험 · 도구

파이프라인이 실제로 동작하는지 일부러 깨뜨려 확인한다. 21장 Q6의 게이트 훈련과 같은 발상이다.

# 훈련 1: 큰 파일을 일부러 추가하고 CI를 돌린다
dd if=/dev/urandom of=Resources/dummy.bin bs=1m count=5
#   → CI가 "❌ 다운로드: 24.3 → 29.1 MB (+4.80 MB, +19.8%)" 로 실패해야 정상
#   → size-diff.txt 에 "dummy.bin" 이 나와야 정상

# 훈련 2: 기준선 파일을 지우고 돌린다
mv ci/size-baseline.json /tmp/
#   → 기준선이 없을 때 "실패"가 아니라 "기준선 생성"으로 처리되는지 확인
#     (첫 실행에서 항상 실패하면 아무도 안 쓰게 된다)

# 훈련 3: thinning 키를 빼고 export 한다
#   → 리포트가 안 생기고, 그것이 명확한 에러로 드러나야 한다

기준선 갱신 정책도 정해야 한다.

# 기준선은 "릴리스된 버전"으로만 갱신한다
#   - main 브랜치의 모든 커밋으로 갱신하면 회귀가 조금씩 누적되어도 안 걸린다
#     (매번 직전 커밋 대비 비교라 3% 미만 증가가 무한히 쌓인다)
#   - 릴리스 태그가 붙을 때만 갱신하면 "이번 릴리스 전체 증가분"이 검사된다

# 릴리스 시점에 기준선 갱신
if [ -n "${RELEASE_TAG:-}" ]; then
  cp build/size-current.json ci/size-baseline.json
  git add ci/size-baseline.json
  git commit -m "chore: 크기 기준선 갱신 ($RELEASE_TAG)"
fi

이 기준선 갱신 주기가 설계에서 가장 중요한 결정이다. 매 커밋 갱신은 점진적 열화를 놓치고, 영원히 고정하면 정당한 기능 추가도 막힌다. 릴리스 단위가 적절한 균형이다.

프로젝트 적용

도입 순서를 효과 순으로 정리하면 이렇다.

1. 측정과 기록부터. 실패시키지 않고 기록만 시작한다. 몇 릴리스치 데이터가 쌓이면 정상 증가 폭을 알 수 있고, 그때 임계를 정한다. 처음부터 임계를 추측해 걸면 오탐이 잦아 무시된다.
2. PR 코멘트로 노출. 실패시키기 전에 PR에 크기 변화를 코멘트하는 단계를 둔다. 마찰 없이 인식을 만든다.
3. 원인 diff 추가. 이게 있어야 논의가 된다.
4. 임계 초과 시 실패. 데이터가 충분히 쌓인 뒤에 켠다.
5. 정기 검토. 분기마다 크기 추세를 보고 정리 작업을 계획한다. 회귀 방지만으로는 이미 쌓인 것이 안 줄어든다.

그리고 익스텐션 크기도 함께 본다(24장). 익스텐션이 늘면 앱 전체가 늘고, 익스텐션은 자체 자원 예산도 빡빡하다.

꼬리 질문

# 아카이브 없이 빠르게 비교할 수 있는 값들
du -sk "$BUILT_APP"                          # 앱 번들 총 크기 (dSYM 제외)
stat -f%z "$BUILT_APP/MyApp"                 # 실행 바이너리 크기
du -sk "$BUILT_APP/Frameworks" 2>/dev/null   # 프레임워크 총 크기
du -sk "$BUILT_APP/Assets.car" 2>/dev/null   # 에셋 카탈로그 크기

Q5. P1을 마치며 — 무엇을 얻었는가?

CS 원리

P1의 아홉 챕터를 관통하는 구조를 정리하면 이렇다.

다섯 번째 행이 P1에서 가장 반복적으로 나타난 패턴이다. 에러 메시지에서 가변값을 빼면 그룹핑이 복구되고(18장 Q6), breadcrumb이 접히고(18장 Q4), 프라이버시가 개선되고(23장 Q1), span 이름이 안정된다(22장 Q1). 하나의 설계 원칙이 네 가지 문제를 동시에 해결한다.

여섯 번째 행도 중요하다. P0 17장의 관심사 분리가 P1에서 성능과 배포 제약의 해법으로 되돌아온다 — UI 타입에서 로직을 분리하면 격리 전염이 사라지고(20장 Q6), 프레임워크에서 UIKit 의존을 줄이면 app-extension-safe 문제가 자동으로 풀린다(24장 Q6). 좋은 설계가 플랫폼 제약을 자연스럽게 만족시킨다는 것이 P1이 준 실증이다.

iOS에서는

실무에서 바로 점검할 수 있는 체크리스트로 정리하면 이렇다.

관측 파이프라인 (18~22장)

• 크래시·행·히치 지표를 각각 추적하고 있는가? 셋은 다른 문제다.
• 자체 리포터 숫자와 MetricKit 숫자를 대조하고 있는가? (19장 Q7)
• 인앱 프레임 보유율을 감시하고 있는가? (21장 Q3)
• 샘플링 비율을 필요 표본 수에서 역산했는가? (22장 Q4)
• 계측 오버헤드를 실측했는가? (22장 Q7)

플랫폼 준수 (23~24장)

• 모든 바이너리에 privacy manifest가 있는가? (23장 Q2)
• Required Reason API 사유가 실제 용도와 일치하는가? (23장 Q3)
• ATT 거부 상태로 전체 플로우를 테스트했는가? (23장 Q4)
• 공유 컨테이너 접근이 동기화돼 있는가? (24장 Q3)
• 익스텐션 크래시가 수집되고 있는가? (24장 Q1)

성능과 배포 (20·25·26장)

• commit hitch와 render hitch를 구분해 보고 있는가? (25장 Q6)
• 가장 느린 지원 기기에서 검증하는가? (20장 Q7)
• App Size Report가 CI에 있는가? (26장 Q4)
• SDK 도입 기준 네 가지를 확인하는가? — dSYM·manifest·extension-safe·크기

실험 · 도구

P1에서 다룬 도구를 어떤 질문에 쓰는지로 정리하면 선택이 쉬워진다.

마지막 행이 P1의 결론에 가깝다. 모든 로컬 측정은 표본 하나이고, 실사용자 분포는 다르다. 그래서 프로덕션 지표로 확인하기 전까지 개선은 가설이다.

프로젝트 적용

P1을 실제 프로젝트에 도입한다면 순서가 중요하다. 효과와 비용을 함께 고려한 순서는 이렇다.

1. 아카이브 장기 보관(21장 Q6) — 이것만 있으면 나머지는 나중에 복구 가능하다. 비용이 거의 0이고 없으면 되돌릴 수 없다.
2. 심볼화율 감시(21장 Q3) — 크래시 데이터의 신뢰성 자체가 여기 달렸다.
3. MetricKit 수집(19장 Q7) — OS가 집계한 기준선을 확보한다. 자체 계측을 검증할 잣대가 생긴다.
4. 행률·히치율 감시(20장) — 크래시율이 좋은데 평점이 나쁜 원인의 대부분이 여기다.
5. privacy manifest 정비(23장) — 심사 차단 요인이므로 우선순위가 높다.
6. 크기 측정 자동화(26장) — 기록만 먼저 시작한다.
7. 트레이싱·프로파일링(22장) — 앞의 것들이 자리 잡은 뒤에 도입한다. 비용이 가장 크다.

순서의 근거는 "없으면 되돌릴 수 없는 것"부터다. 아카이브와 dSYM은 시점을 놓치면 영영 복구되지 않지만, 트레이싱은 언제 도입해도 그때부터 데이터가 쌓인다.

꼬리 질문

출처 · 참고자료