SwiftUI 렌더링 파이프라인 설명

발행: 3일 전 (2025년 12월 22일 오전 10:32 GMT+9)

9 min read

I’m ready to translate the article for you, but I need the full text you’d like translated. Could you please provide the content (excluding the source line you’ve already included)? Once I have the text, I’ll translate it into Korean while preserving all formatting, markdown, and code blocks.

🧠 큰 그림

모든 SwiftUI 업데이트는 동일한 파이프라인을 거칩니다:

State Change
   ↓
View Invalidation
   ↓
Body Recomputed
   ↓
Layout Pass
   ↓
Diffing
   ↓
Rendering

이 과정을 건너뛰는 것은 없으며, 마법도 없습니다. 성능 문제는 이러한 단계 중 하나에서 작업이 과도하게 발생할 때 발생합니다.

🔥 1. 상태 변경 (유일한 진입점)

Everything starts with state.

예시

@State changes → @State 변경
@StateObject / @ObservableObject property changes → @StateObject / @ObservableObject 프로퍼티 변경
@Binding updates → @Binding 업데이트
Environment value changes → Environment 값 변경

If no state changes → nothing re‑renders. This is why SwiftUI apps can be extremely efficient.
→ 상태가 변경되지 않으면 → 아무것도 다시 렌더링되지 않습니다. 이것이 SwiftUI 앱이 매우 효율적일 수 있는 이유입니다.

⚠️ 흔한 실수

Developers often think “body recomputes too much.”
→ 개발자들은 종종 “body가 너무 많이 재계산된다”고 생각합니다.

That’s not the problem. body recomputation is cheap; the cost comes from invalidation, layout, and diffing.
→ 그것은 문제가 아닙니다. body 재계산은 비용이 적으며, 비용은 무효화, 레이아웃, 그리고 차이 계산에서 발생합니다.

🧱 2. 뷰 무효화

상태가 변경될 때, SwiftUI는:

영향을 받은 뷰를 dirty 로 표시합니다
업데이트를 위해 예약합니다

중요

전체 앱이 아니라 영향을 받은 서브트리만 무효화됩니다.
전역 상태가 어디에나 존재하면 → 대규모 무효화가 발생합니다.
스코프된 상태 → 최소 무효화.

🔁 3. Body 재구성 (저비용)

SwiftUI가 다시 실행합니다:

var body: some View { … }

이 단계는:

빠름
예상됨
빈번함

SwiftUI는 객체가 아니라 값을 비교합니다. 뷰를 재구성하는 것은 저비용이며, 정체성을 재생성하는 것은 그렇지 않습니다.

🧠 핵심 인사이트

SwiftUI는 빈번한 body 재계산에 최적화되어 있으며, 정체성 변화가 빈번한 경우에는 최적화되지 않았습니다.

📐 4. 레이아웃 패스

body 재계산 후, SwiftUI는 레이아웃을 수행합니다:

부모가 크기를 제안합니다.
자식이 자신의 크기를 선택합니다.
부모가 자식을 배치합니다.

레이아웃은 모든 무효화 후, 애니메이션 중, 크기 변경, 회전, 그리고 리스트 업데이트 시에 발생합니다.

🧨 레이아웃 성능 저해 요인

GeometryReader를 과도하게 사용 (특히 리스트 내부)
깊게 중첩된 스택
매 프레임마다 동적 크기 측정
비동기 데이터에 반복적으로 의존하는 크기의 뷰

🔍 5. Diffing (핵심 단계)

SwiftUI는 이전 뷰 트리와 새 뷰 트리를 다음을 사용하여 비교합니다:

뷰 타입
위치
식별자 (id)

식별자가 일치하면:

상태가 보존됩니다
뷰가 제자리에서 업데이트됩니다

식별자가 변경되면:

상태가 파괴됩니다
뷰가 다시 생성됩니다
애니메이션이 초기화됩니다
작업이 재시작됩니다

Diffing은 대부분의 “버그”가 발생하는 지점입니다.

🆔 식별자가 전부입니다

빠른 (안정적인 ID)

ForEach(items, id: \.id) { item in
    Row(item)
}

비싼 (업데이트마다 ID가 변경됨)

ForEach(items) { item in
    Row(item)
        .id(UUID())
}

매 업데이트마다 전체 해체를 강제하면 성능이 크게 저하됩니다.

🎨 6. 렌더링 (GPU 단계)

디핑 후, SwiftUI는 그리기 명령을 발행하고 GPU가 최종 픽셀을 렌더링합니다. 렌더링은 보통 빠르지만 다음과 같은 경우는 예외입니다:

무거운 블러
레이어드 머티리얼
복잡한 마스크
오프‑스크린 렌더링
그림자 과다 사용

렌더링 문제는 프레임 드롭, 끊김이 있는 애니메이션, 스크롤 끊김 등으로 나타납니다.

🧵 7. 파이프라인의 애니메이션

애니메이션은 모든 단계에 영향을 미칩니다:

상태 변화 → 애니메이션 적용
레이아웃 보간
렌더링 보간

애니메이션은 레이아웃이나 diffing을 건너뛰지 않으며, 비효율성을 증폭시켜 잘못된 아키텍처가 더욱 크게 느껴지게 합니다.

⚙️ 8. 비동기 및 렌더링 조정

Bad pattern
잘못된 패턴

Task {
    data = await load()
}

Better pattern
더 나은 패턴

@MainActor
func load() async {
    isLoading = true
    defer { isLoading = false }
    data = await service.load()
}

Why?
왜?

Predictable invalidation → 예측 가능한 무효화
Single render cycle → 단일 렌더링 사이클
Avoids cascading updates → 연쇄적인 업데이트 방지

Async work should batch state changes rather than drip‑feed them. → 비동기 작업은 상태 변화를 한 번에 배치해야 하며, 지속적으로 흘려보내서는 안 됩니다.

🧪 9. 왜 리스트는 특별한가

List:

뷰를 적극적으로 재사용한다
식별자에 크게 의존한다
레이아웃 패스를 자주 트리거한다
화면 밖 행을 렌더링한다

성능은 다음에 달려 있다:

안정적인 ID
가벼운 행
최소한의 레이아웃 작업
캐시된 데이터

리스트는 렌더링 파이프라인의 모든 실수를 증폭시킨다.

🧠 정신 디버깅 체크리스트

무언가 느리게 느껴질 때, 다음을 물어보세요:

어떤 상태가 변경됐나요?
얼마나 무효화됐나요?
정체성이 변경됐나요?
레이아웃이 비용이 많이 들게 되었나요?
애니메이션이 비용을 증폭시켰나요?
비동기가 여러 업데이트를 트리거했나요?

거의 항상 문제를 정확히 찾을 수 있습니다.

🚀 최종 멘탈 모델

레이어로 생각하고, 코드가 아니라:

State
   ↓
Invalidation
   ↓
Body
   ↓
Layout
   ↓
Diffing
   ↓
Rendering

Control

State 범위
Identity 안정성
Layout 복잡도

…그리고 SwiftUI는 빠르고, 예측 가능하며, 확장 가능해집니다.

🏁 최종 생각

SwiftUI 성능은 트릭에 관한 것이 아니라 렌더링 파이프라인을 존중하는 데 있습니다. 작업이 어디서 발생하는지, 식별자가 왜 중요한지, 레이아웃이 성능에 어떤 영향을 미치는지를 이해하면 SwiftUI와 싸우는 것이 아니라 함께 작업하게 됩니다.