SwiftUI 7년 회고: 애플의 선언형 UI는 왜 아직도 '2군'에 머물러 있을까

2019년 WWDC에서 애플이 SwiftUI를 처음 공개했을 때, 개발자 커뮤니티의 반응은 거의 축제에 가까웠어요. 코드 몇 줄로 UI가 만들어지고, 프리뷰 화면에서 실시간으로 결과가 보이고, 데이터가 바뀌면 화면이 알아서 갱신되고요. 수백 줄짜리 UIKit 보일러플레이트에 지쳐 있던 iOS 개발자들에게는 구원처럼 보였거든요. 그런데 7년이 지난 지금, 한 개발자가 'SwiftUI: 평범함의 기록(A Story of Mediocrity)'이라는 제목의 긴 회고를 공개했어요. 7년 내내 SwiftUI로 실제 제품을 만들어 온 경험을 정리한 글인데, 결론이 꽤 씁쓸합니다. '못 쓸 물건은 아니지만, 애플이 약속했던 미래는 아직 오지 않았다'는 거예요.

선언형 UI, 이게 뭐냐면

SwiftUI의 핵심은 '선언형(declarative) UI'라는 개념이에요. 이게 뭐냐면, 화면을 '어떻게' 그릴지 순서대로 명령하는 대신, '무엇을' 보여줄지 선언만 하는 방식이에요. 요리로 비유하면 기존 UIKit은 '팬을 달구고, 기름을 두르고, 계란을 깨 넣고...'처럼 조리 과정을 하나하나 지시하는 방식이고, SwiftUI는 '완성된 계란프라이'를 보여주면서 '이런 상태가 되게 해줘'라고 말하는 방식이죠. 데이터가 바뀌면 프레임워크가 알아서 화면을 다시 그려주니까, 개발자는 상태 관리에만 집중하면 돼요. 웹의 React, 안드로이드의 Jetpack Compose도 똑같은 철학을 공유하는 형제들이에요.

그런데 왜 '평범하다'는 평가가 나올까

문제는 이 아름다운 철학이 현실에서 자주 삐걱거린다는 거예요. 회고에서 짚는 핵심은 크게 세 가지로 정리할 수 있어요.

첫째, 성능과 예측 불가능성이에요. SwiftUI는 상태가 바뀌면 어떤 뷰를 다시 그릴지 프레임워크가 알아서 판단하는데, 이 판단 과정이 개발자에게 블랙박스거든요. 분명히 작은 값 하나만 바꿨는데 화면 전체가 다시 그려지면서 버벅이는 경우가 생기고, 왜 그런지 추적하기가 정말 어려워요. UIKit에서는 '내가 이 뷰를 갱신하라고 명령했으니 갱신된다'는 인과관계가 명확했는데, SwiftUI에서는 프레임워크의 속마음을 추리해야 하는 상황이 되는 거죠.

둘째, API의 빈틈이에요. 7년이 지났는데도 UIKit에서는 한 줄이면 되던 세밀한 커스터마이징이 SwiftUI에는 아예 없는 경우가 있어요. 그럴 때마다 UIViewRepresentable이라는 '비상 탈출구'로 UIKit 코드를 감싸서 끼워 넣어야 하는데, 이러면 선언형의 장점이 반쯤 사라져요. 결국 SwiftUI를 쓴다는 건 'SwiftUI 지식 + UIKit 지식 + 둘을 잇는 접착제 코드'를 전부 다뤄야 한다는 뜻이 되곤 하죠.

셋째, 매년 바뀌는 지형이에요. 대표적인 게 내비게이션인데요, 애플은 NavigationView를 내놓았다가 몇 년 만에 통째로 deprecated 처리하고 NavigationStack으로 갈아탔어요. 새 API가 더 좋아진 건 맞지만 최신 OS에서만 동작하니까, 구버전 사용자를 지원해야 하는 실무 앱은 한동안 두 세계를 오가는 분기 코드를 유지해야 했죠.

업계 맥락: 구글과 비교하면 보이는 것

흥미로운 건 같은 선언형 UI라도 구글의 행보와 온도차가 크다는 점이에요. 구글은 Jetpack Compose를 밀기 시작한 뒤 자사 앱들을 적극적으로 Compose로 다시 쓰면서 '우리가 먼저 쓴다'는 신호를 확실히 줬어요. 반면 애플의 간판 앱들은 여전히 상당 부분 UIKit과 AppKit 위에 있다고 알려져 있고요. 프레임워크를 만든 회사가 자기 제품에 전면 도입을 망설인다면, 외부 개발자 입장에선 신뢰하기 어렵죠. 물론 애플도 최근 몇 년 사이 시스템 앱 곳곳에 SwiftUI 적용을 넓혀가고는 있지만, '전면 전환'과는 아직 거리가 있어요.

한국 개발자에게 주는 시사점

그럼 우리는 SwiftUI를 배워야 할까요, 말아야 할까요? 답은 '둘 다 알아야 한다'에 가까워요. 국내 채용 공고를 보면 규모 있는 서비스일수록 UIKit 경험을 여전히 요구하는데, 오래된 대형 코드베이스가 UIKit으로 쓰여 있기 때문이에요. 반대로 신규 프로젝트나 사이드 프로젝트라면 SwiftUI로 시작하는 게 생산성 면에서 확실히 유리하고요. 실무에서 가장 현실적인 전략은 화면 골격은 SwiftUI로 짜되, 성능이 민감하거나 세밀한 제어가 필요한 부분은 UIKit으로 내려갈 준비를 해두는 하이브리드 접근이에요. 프레임워크 하나에 올인하기보다, '선언형 사고방식'이라는 이식 가능한 개념을 익혀두면 나중에 Compose나 React로 옮겨도 그대로 자산이 됩니다.

마무리

정리하면, SwiftUI는 실패작은 아니지만 7년이 지난 지금도 '주력이라 부르기엔 아쉬운' 위치에 머물러 있다는 게 이 회고의 진단이에요. 여러분은 어떻게 생각하세요? 지금 새 iOS 앱을 시작한다면 SwiftUI에 올인하실 건가요, 아니면 아직은 UIKit과의 하이브리드가 정답이라고 보시나요?