애플 생태계의 정점, SwiftUI 성능 최적화의 모든 것: 네이티브의 한계를 넘어서
안녕하세요. 15년 차 iOS 네이티브 개발자이자, 기술 서적 작가로 활동 중인 제이슨입니다. 오늘 여러분과 나눌 이야기는 제 개발 인생에서 가장 애증이 교차했던, 그러나 정복했을 때 가장 큰 희열을 안겨준 주제, 바로 SwiftUI 성능 최적화입니다. 아마 이 글을 읽고 계신 분들은 플러터(Flutter)나 리액트 네이티브(React Native) 같은 크로스 플랫폼 프레임워크의 한계를 느끼고 네이티브로 넘어오셨거나, 혹은 익숙했던 UIKit을 떠나 SwiftUI라는 새로운 바다에 뛰어든 분들일 것입니다. 그리고 분명 "네이티브인데 왜 이렇게 버벅거리지?"라는 의문을 한 번쯤 품어보셨을 겁니다.
솔직히 고백하겠습니다. 저도 2019년 WWDC에서 SwiftUI가 처음 발표되었을 때, "이제 복잡한 UI 코딩은 끝났다, 선언형 만세!"라고 외치며 자만했습니다. 하지만 실무 프로젝트에 도입하여 복잡한 데이터 흐름과 화려한 애니메이션을 다루기 시작하자마자, 프레임 드랍(Frame Drop)과 메모리 누수(Memory Leak)라는 거대한 벽에 부딪혔습니다. 최신형 아이폰 14 프로 맥스에서조차 리스트 스크롤이 미세하게 끊기는 현상을 보며 등줄기에 식은땀이 흘렀던 기억이 생생합니다. 그 문제를 해결하기 위해 마신 커피만 해도 수백 잔은 될 것입니다. ☕
SwiftUI는 '선언형 UI'라는 강력하고 아름다운 무기를 가지고 있지만, 그 내부 동작 원리(Under the hood)를 정확히 이해하지 못하면 오히려 독이 됩니다. 플러터가 Skia 엔진 위에서 독자적으로 렌더링하는 것과 달리, SwiftUI는 애플의 하드웨어와 가장 밀접하게 맞닿아 있는 Metal 엔진과 Core Animation을 직접 제어합니다. 즉, 최적화만 잘하면 타의 추종을 불허하는 압도적인 퍼포먼스를 낼 수 있다는 뜻입니다. 오늘은 단순히 "이 코드를 쓰세요"가 아니라, "왜 SwiftUI 렌더링 엔진이 멈칫하는지", "어떻게 해야 120Hz ProMotion 디스플레이를 온전히 장악할 수 있는지"에 대해 아주 깊이 있게, 그리고 철저히 실전 경험과 데이터를 바탕으로 파헤쳐 보겠습니다.
1. 뷰(View)의 정체성: SwiftUI가 화면을 그리는 진짜 원리
SwiftUI 성능 최적화의 첫 단추이자 가장 중요한 핵심은 바로 'Identity(정체성)'를 이해하는 것입니다. 많은 개발자가 SwiftUI의 뷰(View)를 단순히 가벼운 구조체(Struct)라고만 생각하고 무분별하게 생성합니다. 물론 구조체 자체는 힙(Heap)이 아닌 스택(Stack)에 할당되므로 가볍습니다. 하지만 SwiftUI가 이 뷰를 관리하고 렌더링하기 위해 내부적으로 생성하는 '의존성 그래프(Dependency Graph)'는 결코 가볍지 않습니다.
SwiftUI는 뷰의 상태가 변할 때마다 body 프로퍼티를 다시 계산합니다. 이때 렌더링 엔진은 "이 뷰가 아까 그 뷰인가?"를 판단해야 합니다. 이를 판단하는 기준이 바로 Identity입니다. 만약 여러분이 뷰의 정체성을 모호하게 코딩하면, SwiftUI는 기존 뷰를 수정(Modify)하는 대신 파괴(Destroy)하고 새로 생성(Create)합니다. 이것이 바로 성능 저하의 주범입니다. 뷰가 파괴되고 다시 생성되면 내부의 모든 상태(@State)가 초기화되고, 애니메이션 컨텍스트가 끊기며, 불필요한 레이아웃 연산이 발생합니다.
제 경험을 예로 들어보겠습니다. 복잡한 금융 앱 대시보드를 개발할 때, 조건문(if-else)을 남발하여 뷰를 구성한 적이 있습니다. 사용자가 탭을 전환할 때마다 화면이 미세하게 깜빡이고(Flicker), 부드러워야 할 그래프 애니메이션이 뚝뚝 끊겼습니다. 원인을 파헤쳐 보니, 조건문에 따라 뷰의 구조적 정체성(Structural Identity)이 계속 바뀌고 있었습니다. SwiftUI는 _ConditionalContent라는 내부 타입을 통해 이를 관리하는데, 조건 분기가 많아질수록 뷰 계층 구조가 달라져 '완전히 다른 뷰'로 인식했던 것입니다. 결과적으로 렌더링 비용이 3배 이상 증가했습니다.
이 문제를 해결하기 위해서는 AnyView 사용을 극도로 자제해야 합니다. AnyView는 컴파일러가 뷰의 구체적인 타입 정보를 지워버리기 때문에(Type Erasure), SwiftUI의 Diffing 알고리즘이 뷰의 변경 사항을 효율적으로 추적할 수 없습니다. 대신 @ViewBuilder나 제네릭(Generic)을 활용하여 뷰의 타입을 명확히 유지해야 합니다. 실제로 프로젝트에서 약 20개의 AnyView를 제거하고 제네릭으로 리팩토링한 것만으로, 스크롤 프레임 레이트가 45fps에서 60fps로 안정화되었고, CPU 사용량이 15% 감소하는 것을 목격했습니다.
또한, id(_:) 수정자를 사용할 때도 전략이 필요합니다. 고유하지 않은 ID를 부여하거나, 데이터가 변경되지 않았는데도 ID가 바뀌게 되면 SwiftUI는 강제로 뷰를 다시 그립니다. 반대로, 이를 역이용하여 뷰를 강제로 초기화해야 할 때(예: 데이터가 바뀌었을 때 스크롤 위치를 최상단으로 리셋)는 id 변경이 아주 유용한 트릭이 될 수 있습니다. 원리를 알면 독도 약으로 쓸 수 있는 법입니다.
💡 핵심 원리: SwiftUI는 뷰의 계층 구조(Hierarchy)와 위치를 기반으로 'Structural Identity'를 부여하고, id 수정자를 통해 'Explicit Identity'를 부여합니다. 최적화의 핵심은 SwiftUI가 이 정체성을 잃어버리지 않도록 돕는 것입니다. 뷰가 파괴되고 재생성되는 비용은 단순히 속성을 변경하는 비용보다 수십 배 비쌉니다.
2. 상태 관리의 나비효과: @State와 @ObservedObject의 치명적 함정
SwiftUI에서 가장 흔하게 저지르는 실수이자, 앱의 반응성을 망치는 주범은 상태 관리 도구의 오용입니다. @State, @Binding, @ObservedObject, @StateObject, @EnvironmentObject 등 수많은 프로퍼티 래퍼(Property Wrapper)들이 존재하지만, 이것들의 생명주기(Lifecycle)를 정확히 모르고 연결하면 "나비효과"가 발생합니다. 즉, 화면 구석의 작은 '좋아요' 버튼 하나를 눌렀는데, 화면 전체가 다시 그려지는(Redraw) 참사가 벌어지는 것이죠.
가장 대표적인 실수는 뷰 내부에서 의존성을 주입받을 때 @ObservedObject와 @StateObject를 혼동하는 것입니다. View는 구조체이므로 렌더링 과정에서 언제든지 파괴되고 다시 생성될 수 있습니다. 만약 뷰가 다시 생성될 때 @ObservedObject로 선언된 객체를 뷰 내부에서 초기화(init)해버리면, 뷰가 다시 그려질 때마다 객체도 함께 초기화됩니다. 이로 인해 진행 중이던 네트워크 요청이 취소되거나, 사용자가 입력하던 데이터가 날아가는 현상을 수없이 목격했습니다. @StateObject는 뷰가 다시 생성되더라도 객체의 인스턴스를 메모리에 유지해주는 안전장치입니다.
실제 사례를 들어보겠습니다. 실시간 주식 시세를 보여주는 트레이딩 앱을 개발할 때였습니다. 최상위 뷰(Parent View)에 1초마다 갱신되는 타이머가 있었고, 하위 뷰(Child View)에는 수백 개의 데이터를 그리는 복잡한 차트가 있었습니다. 타이머가 울려 상위 뷰의 body가 호출될 때마다, 하위 뷰인 차트 뷰도 덩달아 다시 생성되었습니다. 차트 데이터는 변하지 않았음에도 불구하고 불필요한 렌더링 연산을 수행했고, 결과적으로 배터리 소모량이 시간당 15%나 증가했습니다. 아이폰 뒷면이 뜨거워질 정도였죠.
이 문제를 해결하기 위해 두 가지 전략을 사용했습니다. 첫째, 뷰 쪼개기(View Splitting)입니다. 변경되는 상태(타이머)를 별도의 작은 뷰로 분리하여, 렌더링의 영향을 국소화했습니다. 둘째, EquatableView의 도입입니다. 뷰가 Equatable 프로토콜을 준수하게 하고, 데이터가 변경되지 않았으면(lhs.data == rhs.data) 렌더링을 건너뛰도록 강제했습니다. 그 결과 CPU 사용량이 평균 40%에서 5% 미만으로 뚝 떨어지는 기적을 맛보았습니다. 이는 단순한 최적화가 아니라 앱의 생존이 걸린 문제였습니다.
3. 리스트(List)와 레이지 스택(Lazy Stack): 대용량 데이터 처리의 기술
모바일 앱의 80%는 리스트 형태의 UI를 가지고 있습니다. 그만큼 리스트 성능은 앱의 전체적인 인상을 좌우하는 척도입니다. 초보 개발자분들이 흔히 VStack 안에 ForEach를 넣고 ScrollView로 감싸는 실수를 합니다. 데이터가 10개, 20개일 때는 아이폰의 고성능 AP 덕분에 문제가 없어 보입니다. 하지만 데이터가 100개가 넘어가는 순간 앱은 버벅거리고 메모리 경고를 띄웁니다. VStack은 화면에 보이지 않는 뷰까지 한 번에 모두 생성하기 때문입니다.
이때 등장하는 것이 List와 LazyVStack, LazyHStack입니다. 이들은 화면에 보이는 만큼만 뷰를 생성하는 Lazy Loading(지연 로딩) 기법을 사용합니다. 하지만 이것만 쓴다고 만사형통은 아닙니다. 셀(Cell) 안에 들어가는 콘텐츠가 무겁다면, 스크롤을 내릴 때마다 뚝뚝 끊기는 '히치(Hitch)' 현상이 발생할 수 있습니다.
제가 맡았던 대형 SNS 프로젝트에서는 피드 하나에 고화질 이미지 5장, 자동 재생 동영상, 텍스트, 댓글 미리보기 등 복잡한 UI가 포함되어
댓글
댓글 쓰기