SwiftUI 7년, 왜 아직 UIKit과 함께 써야 할까요

SwiftUI 7년, 왜 아직 UIKit과 함께 써야 할까요

IT & AI 뉴스 썸네일

SwiftUI는 짧은 코드로 Apple 기기용 화면을 만들 수 있게 해요. 2019년 공개 후 7년이 지났지만, 복잡한 레이아웃과 성능에 민감한 화면에서는 UIKit이나 AppKit이 여전히 필요하다는 비판이 나왔어요. 새 프로젝트에서 어느 한쪽만 고집하기보다 화면의 복잡도와 지원할 운영체제 범위에 따라 나눠 쓰는 판단이 필요해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
데이터 흐름	`@State`, `@Binding`, `ObservedObject`, `@Observable` 등 상태 관리 방식이 이어서 추가됐어요	뷰가 갱신되는 원인을 추적하기 어려우면 디버깅과 성능 점검 시간이 늘어요
레이아웃	복잡한 화면에서는 `GeometryReader`와 직접 좌표 계산 같은 우회가 필요할 수 있어요	선언형 문법으로 줄인 코드가 예외 처리에서 다시 길어질 수 있어요
호환성	새 API를 쓰면서 구형 OS도 지원하면 `if #available` 분기와 대체 구현이 함께 남아요	기능 추가보다 버전별 동작 확인에 더 많은 시간이 들 수 있어요
실무 선택	단순 화면은 SwiftUI로 만들고 정밀한 제어가 필요한 곳은 UIKit·AppKit으로 내려갈 수 있어요	전면 교체보다 혼합 구성이 일정과 유지보수 위험을 줄이기 쉬워요

1. SwiftUI의 편리함은 복잡한 화면에서 시험받아요

Apple은 2019년 SwiftUI를 공개하면서 선언형 문법, 실시간 미리보기, Apple 플랫폼 사이의 코드 공유를 주요 장점으로 소개했어요. 데이터가 바뀌면 화면도 따라 바뀌는 구조라서, 설정 화면이나 목록처럼 상태와 화면의 관계가 단순한 기능은 적은 코드로 만들 수 있어요. 3

원문 작성자는 이 장점이 화면이 복잡해질수록 약해진다고 지적해요. SwiftUI의 상태 관리 방식에는 `@State`, `@Binding`, `ObservedObject`, Observation 프레임워크와 `@Observable`이 차례로 더해졌어요. 선택지가 늘었지만, 어떤 변경이 특정 뷰를 다시 그리는지 한눈에 파악하기는 쉽지 않다고 해요. 불필요한 갱신이 생기거나 기대한 갱신이 빠지면 개발자는 모델 코드와 뷰 계층을 함께 추적해야 해요. 2

레이아웃에서도 비슷한 문제가 생겨요. 부모와 자식 뷰가 크기를 협상하는 방식은 간단한 구성에서 편리해요. 사용자 정의 사이드바나 떠 있는 요소가 섞이면 결과를 예측하기 어려울 수 있어요. 원문은 Apple의 Landmarks 예제와 실제 앱 화면을 사례로 들고, 좌표를 직접 계산하려고 `GeometryReader`를 쓰는 순간 선언형 레이아웃의 이점이 줄어든다고 비판해요. 다만 이는 한 개발자의 경험과 사례에 기반한 평가예요. 모든 SwiftUI 앱이 같은 문제를 겪는다는 뜻은 아니에요. 2

API가 운영체제에 묶여 배포된다는 점도 유지보수 비용을 만들어요. 새로운 탐색이나 이미지 관련 API가 나와도 지원 대상에 오래된 iOS와 macOS가 포함되면 바로 하나로 통일하기 어려워요. 새 구현과 대체 구현을 함께 두고 `if #available`로 나누는 코드가 남아요. `NavigationView`에서 `NavigationStack`으로 옮기는 과정처럼 기존 API가 새 API로 바뀌면 기능 개발과 별개로 두 경로를 계속 확인해야 해요. 1

성능 비판은 범위를 좁혀 읽을 필요가 있어요. 원문 작성자는 같은 이미지 갤러리를 SwiftUI와 UIKit으로 구현한 비교에서 UIKit 쪽 스크롤이 더 부드러웠다고 밝혔어요. 오래된 iPhone에서 진행한 하나의 비교이므로 SwiftUI 전체의 성능을 판정하는 벤치마크로 볼 수는 없어요. 그래도 긴 목록, 이미지 디코딩, 빈번한 상태 갱신이 겹치는 화면이라면 출시 전에 실제 지원 기기에서 프레임 드롭과 메모리 사용량을 재야 한다는 근거는 돼요. 2

화면 성격에 따라 경계를 나눠요

실무에서는 프레임워크를 하나로 통일하는 것보다 경계를 분명히 정하는 편이 현실적이에요. 설정, 폼, 단순 목록, 작은 상태 화면은 SwiftUI의 생산성을 활용하기 좋아요. 대량 콘텐츠 목록, 정교한 텍스트 편집, 복잡한 탐색, 픽셀 단위 제어가 필요한 화면은 UIKit이나 AppKit을 먼저 검토할 수 있어요. SwiftUI 화면 안에 기존 뷰를 감싸거나 반대로 기존 앱에 SwiftUI 화면을 넣는 혼합 구성도 가능해요.

728x90

도입 전에는 최소 지원 OS와 핵심 화면을 먼저 정해야 해요. 새 API가 필요한 화면에는 구형 OS용 대체 구현 비용을 적어 두는 편이 좋아요. 성능이 중요한 화면은 최신 기기만 보지 말고 지원 범위에서 가장 느린 기기로 측정해야 해요. 프레임워크 내부 동작을 추측하기보다 Instruments로 갱신 횟수, 메인 스레드 작업, 스크롤 프레임을 확인하면 교체할 부분을 좁힐 수 있어요.

왜 중요한가요

SwiftUI를 둘러싼 논쟁은 선호하는 문법을 고르는 문제로 끝나지 않아요. 앱 팀이 부담할 디버깅 시간, 운영체제별 분기, 성능 점검 범위를 바꿔요. 짧은 초기 코드만 보고 전면 도입하면 복잡한 화면에서 우회 코드가 늘 수 있어요. 반대로 기존 프레임워크만 고집하면 단순 화면을 빠르게 만드는 이점을 놓칠 수 있어요. 2

새 앱이라면 화면별 위험도를 나눠 시작하는 편이 안전해요. SwiftUI로 빠르게 만들 수 있는 화면과 정밀한 제어가 필요한 화면을 구분하고, 후자에는 UIKit·AppKit으로 내려갈 통로를 남겨 두면 돼요. 기존 앱은 전체를 다시 쓰기보다 새 기능부터 작은 단위로 적용해 실제 유지보수 비용을 확인할 수 있어요. 이 기준이 있으면 프레임워크에 대한 찬반보다 제품의 품질과 개발 일정에 맞춰 선택할 수 있어요. 1

참고 자료

1. SwiftUI 7년 후, 여전히 베타처럼 느껴지는 이유 — GeekNews
2. SwiftUI After 7 Years: A Story of Mediocrity — Yakov Manshin
3. Apple unveils groundbreaking new technologies for app development — Apple Newsroom