SwiftUI는 Apple이 발표한 최신 UI 프레임워크로, 선언형 프로그래밍 패러다임을 채택하고 있습니다. SwiftUI에서 모든 뷰(View)는 구조체(Struct)로 선언됩니다.
UIKit에서는 Class 기반의 UIViewController로 뷰를 구현했습니다. SwiftUI에서 뷰에 대한 구현에 왜 구조체를 선택했을까요?
이번 글에서는 SwiftUI에서 View가 구조체로 설계된 이유를 성능, 메모리 관리, 상태 관리, 그리고 선언형 프로그래밍 모델 측면에서 생각해보겠습니다.
1. 값 타입의 장점: 명확한 상태 관리
SwiftUI는 선언형 프로그래밍을 기반으로 하여 UI 상태를 관리합니다. 이 과정에서 중요한 점은 상태의 변화를 명확하게 관리할 수 있어야 한다는 것입니다. 구조체는 값 타입이기 때문에 상태가 변경될 때마다 새로운 값이 생성됩니다. 이는 UI의 상태를 관리하고 추적하는 데 있어 매우 유리합니다.
클래스와 달리, 구조체는 변경이 발생하면 기존 인스턴스를 수정하는 대신 새로운 인스턴스를 생성합니다. 이러한 특성 덕분에 상태 변화가 명확해지고, 한 부분의 상태 변경이 다른 부분에 예기치 않은 영향을 미치지 않도록 방지할 수 있습니다. 즉, 구조체를 사용하면 SwiftUI에서 상태 관리가 더욱 직관적이고 예측 가능하게 이루어집니다.
2. 불변성과 성능 최적화
SwiftUI의 핵심 목표 중 하나는 성능 최적화입니다. 구조체는 불변성(immutability)을 선호하는 Swift의 디자인 철학과 잘 맞아떨어집니다. 불변성은 상태를 변경하지 않으므로, 사이드 이펙트(Side Effect)를 줄이고 코드의 예측 가능성을 높여줍니다.
또한, 구조체는 스택 메모리를 사용하여 클래스보다 더 빠르게 동작합니다. SwiftUI에서 뷰는 종종 작고 단순한 속성들을 포함하고 있기 때문에, 구조체의 복사 비용이 낮고, 이는 성능을 저하시키지 않습니다. Swift 컴파일러는 구조체의 복사를 최적화할 수 있는 다양한 기법을 제공하므로, 성능 저하 없이 뷰를 자주 업데이트할 수 있습니다.
3. 메모리 관리의 간결함
기존의 UIKit과 같은 프레임워크에서는 클래스가 주로 사용되었습니다. 그러나 클래스는 참조 타입이기 때문에, 여러 참조가 동일한 객체를 가리킬 수 있으며, 이로 인해 강한 참조 사이클(Strong Reference Cycle) 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해서는 복잡한 메모리 관리 기법이 필요합니다.
반면, 구조체는 값 타입으로, 참조 카운팅(ARC)에 의존하지 않으며 강한 참조 사이클로 인한 메모리 릭(memory leak) 문제를 피할 수 있습니다. SwiftUI는 구조체를 사용하여 이러한 메모리 관리의 복잡성을 크게 줄였고, 이를 통해 메모리 관리가 더욱 간결하고 안전해졌습니다.
4. 선언형 프로그래밍 모델과의 조화
SwiftUI는 선언형 프로그래밍 모델을 채택하고 있으며, 이는 UI의 상태에 따라 뷰를 그리는 방식입니다. 이 모델에서는 상태가 변경될 때마다 새로운 뷰를 생성하는 것이 일반적입니다. 구조체는 이러한 선언형 모델과 매우 잘 맞아떨어집니다. 뷰의 상태가 변경될 때마다 새로운 구조체 인스턴스를 생성하는 것이 매우 자연스럽기 때문입니다.
구조체는 불변성과 명확한 상태 관리를 제공하므로, 선언형 프로그래밍에서 요구하는 명확한 데이터 흐름과 상태 변경을 손쉽게 구현할 수 있습니다.
결론
SwiftUI에서 View가 구조체로 설계된 이유는 성능, 메모리 관리, 상태 관리, 그리고 선언형 프로그래밍 모델에 대한 조화라는 네 가지 측면에서 명확히 드러난다고 생각합니다. 구조체는 값 타입의 장점을 통해 상태 관리가 쉽고, 성능이 뛰어나며, 메모리 관리가 간단합니다. 또한, 선언형 프로그래밍 모델에 자연스럽게 맞아떨어지기 때문에 SwiftUI는 Struct를 선택했다고 봅니다.
