UIKit으로 몇 년 일한 사람이 SwiftUI를 배울 때 진짜 장벽은 문법이 아니다.
VStack과 Text는 30분이면 쓴다.
막히는 건 "내가 뷰를 붙잡고 시킨다"는 사고방식이고, 그게 안 바뀌면 몇 달 뒤에도
"상태가 왜 초기화되지", "frame이 왜 안 먹지", "왜 이렇게 느리지"에서 멈춘다.
이 강의는 2시간 안에 그 사고방식을 교체하는 데 전부를 쓴다.
이 강의를 읽는 법
모든 주장은 Apple 공식 문서와 WWDC 세션의 원문에 붙여 두었다. 블로그에서 도는 관행 대신 1차 자료를 기준으로 쓴 이유는, SwiftUI가 iOS 17의 Observation 도입으로 정답이 한 번 크게 바뀐 프레임워크이기 때문이다. 지금도 검색하면 낡은 조언이 상위에 뜬다.
- UIKit 경험을 전제한다. 두 프레임워크를 계속 나란히 놓고 대조한다.
- 버전 무관·개념 위주. 특정 iOS 버전 전용 기능은 다루지 않는다 (Observation만 iOS 17+ 표기).
- 순서대로 읽어야 한다. 3챕터는 2챕터를, 5챕터는 2·3챕터를 전제로 쓰였다.
- 각 챕터의
<h2>섹션마다 완료 체크박스가 붙는다. 며칠에 나눠 봐도 진행률이 챕터별로 따로 저장된다.
🔑 2시간을 어디에 쓰는가
1~3챕터(약 80분)가 머릿속 모델 교체다. 여기가 이 강의의 본체다. 4~5챕터(약 50분)는 그 모델 위에서 레이아웃과 실전 통합을 다룬다. 시간이 부족하면 1·2·3챕터만 읽어도 남는 게 있다. 4·5챕터만 읽으면 남지 않는다.
전체 지도 — 5챕터가 어떻게 이어지는가
챕터 목록
01 · 선언형으로 머리 바꾸기 약 25분
뷰가 객체가 아니라 값이라는 것.
body가 반복 호출되는 함수라는 것. 모디파이어가 설정이 아니라 감싸기라는 것. 그리고 UIKit 습관 11개의 번역표.02 · 상태 — 단일 진실 공급원 약 30분
@State·@Binding·@Observable·@Bindable·@Environment를 언제 쓰는지 결정 트리로. "body가 읽은 것만 의존성"이라는 규칙과 ObservableObject 이행표.03 · identity와 lifetime 약 25분
입력하던 텍스트가 사라지는 버그의 정체.
if/else가 왜 "숨기기"가 아닌지, 상태 수명이 왜 identity 수명과 같은지, AnyView를 왜 피하는지.04 · 레이아웃 — 3단계 협상 약 25분
부모가 제안하고 자식이 결정한다. Auto Layout과 방향이 반대인 이유,
.frame이 강제가 아닌 이유, 컨테이너 선택 기준, GeometryReader를 아끼는 이유.05 · UIKit과 함께 살기 + 성능 약 25분
UIViewRepresentable과 Coordinator, UIHostingController로 화면 단위 점진 도입. Self._printChanges()와 느린 업데이트 4대 원인, ForEach의 일정 개수 규칙.다른 강의와의 관계
이 사이트의 다른 강의와 겹치지 않게 범위를 잘랐다.
| 주제 | 여기서 다루는 정도 | 더 깊게 |
|---|---|---|
비동기 · async/await · actor | .task 사용법 수준까지만 | Swift Concurrency |
| Swift 언어 · 값/참조 타입 · CoW | 전제로 두고 넘어감 | Swift & Foundation 로드맵 |
| 메모리 · 성능 원리 | SwiftUI 갱신 비용에 한정 | iOS 개발자 CS 로드맵 |
| 선언형 모델 · 상태 · identity · 레이아웃 · UIKit 통합 | 이 강의의 본체 | — |
📝 다루지 않는 것
SwiftData·@Query, matchedGeometryEffect 같은 애니메이션 심화, PreferenceKey, 커스텀 Layout 구현, iOS 26 Liquid Glass 등 최신 디자인 시스템. 핵심 20%를 먼저 굳히는 게 이 강의의 목적이라 의도적으로 제외했고, 5챕터 끝에 다음 단계 목록을 남겨 두었다.