스위프트유아이(SwiftUI)란 무엇인가?

2019년, 애플은 WWDC 키노트에서 새로운 UI 프레임워크 하나를 세상에 공개한다. 그 이름은 SwiftUI. 지금도 WWDC 2019 하이라이트 웹페이지를 방문해 보면, "조쉬 섀퍼 (Josh Shaffer)가 SwiftUI로 개발자들이 모든 Apple 플랫폼에서 네이티브 앱을 쉽게 구축할 수 있는 방법을 소개하고 있다"고 안내한다.

당시 개발자들 사이에선 설레임과 걱정이 공존했다. SwiftUI는 UIKit을 대체할 수 있는 '선언형UI'를 지향했다. 즉, 더 이상 화면을 구성하기 위해 수많은 코드와 인터페이스 빌더(스토리보드)를 넘나들지 않아도 되는, 새로운 방식의 UI 선언 언어를 제시한 것이다.

이 선언형 UI의 흐름은 이미 웹에선 React, Flutter, Jetpack Compose 같은 프레임워크들이 만들고 있던 시대적 흐름이었다. SwiftUI는 이 흐름에 애플이 진지하게 뛰어든 결과였다. 그리고 UIKit과 비교했을 때, 철학부터 문법, 구조, 데이터 흐름 방식까지 전혀 다른 세상이 열렸다.

선언형 UI, 그게 뭐길래?

SwiftUI는 선언형(Declarative) 방식의 UI 프레임워크다. 즉, '무엇을 보여줄 것인가?'를 코드로 표현하면, 그걸 기반으로 SwiftUI가 적절한 시점에 알아서 랜더링해주는 방식이다. 단지 아래와 같이 사용 된다.

if isLoggedIn { 
    Text("환영합니다!")
} else { 
    Text("로그인 해주세요")
}

조건에 따라 어떤 UI를 보여줄지 "선언"만 해두면, SwiftUI는 isLoggedIn 상태가 변할 때마다 해당 조건을 감지하고 자동으로 UI를 업데이트한다. UIKit에서 이걸 하려면 기존 UILabel의 텍스트를 바꿔야 하고, UIView를 remove 하고 add 해야 하고, 때로는 애니메이션까지 고려해야 한다. SwiftUI는 이런 선언형 사고를 바탕으로, "코드가 UI를 직접 조작하지 않게" 한다.

UIKit과 SWiftUI의 사고방식 차이

구분	UIKit	SwiftUI
방식	명령형 (Imperative)	선언형 (Declarative)
상태관리	직접 상태 추적	상태값 기반으로 UI 자동 업데이트
코드량	상대적으로 많음	간결함, 추상화
학습난이도	초반엔 직관적이나 복잡해짐	초반엔 낯설지만 구조적 사고 유도
데이터흐름	View → Controller → Model	State → View 자동 렌더링
미리보기	없음 (런타임 확인)	실시간 미리보기 제공

UIKit은 일종의 "지휘자" 역할을 한다. 우리가 각 UI 요소에 명령을 내려야만 그에 맞춰 반응한다. 반면 SwiftUI는 "스코어(악보)"를 작성하면 오케스트라가 알아서 연주한다.

SwiftUI가 만들어내는 개발자의 변화

SwiftUI를 배우기 전에는 ViewController마다 IBOutlet을 연결하고, 각 요소의 상태를 수동으로 관리했다. 하지만 SwiftUI로 넘어오면서, 나는 다음과 같은 변화를 겪었다.

데이터가 UI를 바꾸는 것이 아니라, UI가 데이터를 반영하게 되었다.
코드보다 구조를 먼저 생각하게 되었다.
로직과 UI가 명확히 분리되면서, 생각이 더 깔끔해졌다.

이건 단순한 문법 차이가 아니라 사고 방식 자체의 전환이다. 프로그래밍 초심자라면, SwiftUI의 사고 방식이 더 익숙 할 수도 있다. 왜냐하면 UI를 "그리는"게 아니라 "묘사"하는 느낌이기 때문이다.

실제 경험 : 기존 개발자가 SwiftUI에 적응하기까지

세이브푸드(SaveFood) 프로젝트를 시작할 때, 나는 UIKit으로 해도 충분히 만들 수 있는 앱이라고 생각했다. 하지만 시간이 갈수록 다음과 같은 장점 때문에 SwiftUI를 고수하게 되었다.

편안한 미리보기 기능 : 레이아웃 잡으면서 실시간으로 결과를 볼 수 있다.
직관적인 상태 기반 뷰 업데이트 : @State, @Binding, @ObservedObject 개념에 익숙해지면 정말 강력하다.
쉬운 뷰 조합 : 컴포넌트 단위로 쪼개는 것이 어렵지 않다.

물론 단점도 있었다. 디버깅이 어렵고, 에러 메시지가 친절하지 않다. 그래서 아래와 같이 Logger.swift 파일을 만들어 직접 에러 메세지를 작성 했고, 복잡한 네비게이션 구조는 여전히 까다롭다.

import Foundation

func log(_ message: String,
         file: String = #file,
         function: String = #function,
         line: Int = #line) {
    let fileName = (file as NSString).lastPathComponent
    print("📄[\(fileName)] \(function):\(line) → \(message)")
}

하지만 이것은 언어나 프레임워크의 단점이라기보다는 패러다임 전환기에 겪는 성장통에 가까웠다.

SwiftUI를 쓰기 전에 알아야 할 것들

✅ State가 핵심이다.

UI는 State의 반영일 뿐이다.

✅ View는 데이터에 종속된다.

데이터를 직접 수정하려 하지 말고, 흐름을 만들자.

✅ 컴포넌트 단위로 쪼개라.

뷰가 무거워질수록 타입체크가 느려지고 관리가 어렵다.

✅ UIKit과 병행할 수 있다.

SwiftUI는 완전히 대체하는게 아니라, 일부 UIKit과 공존할 수 있다.

✅ 기억하자: 선언형이 무조건 더 쉬운 것은 아니다.

오히려 더 구조적인 설계가 필요하다.

SwiftUI는 '기술'이 아니라 '철학'이다

처음 SwiftUI를 보고 "이게 더 쉬운 건가?"라고 생각 할 수 있다. 하지만 곧 알게 된다. SwiftUI는 단순함을 지향하지만, 절대 얕지 않다. SwiftUI는 다음과 같은 질문을 우리에게 던진다.

"당신의 화면은 어떤 상태에서 무엇을 보여줘야 하는가?"
"변화는 어디에서부터 시작되는가?"
"데이터는 어떻게 흐르며, 누가 그 흐름을 책임져야 하는가?"

이 질문에 답할 수 있을 때 비로소, SwiftUI는 단순한 프레임워크를 넘어 앱을 어떻게 설계할 것인가에 대한 철학적 기준이 되어준다.

마무리하며: UIKit을 경험한 사람일수록 SwiftUI가 더 깊어진다

UIKit을 알고 있는 개발자는 SwiftUI의 철학을 더 깊이 있게 받아들일 수 있다. 반대로, SwiftUI로 시작한 초보자는 UIKit의 복잡함을 나중에 더 잘 이해할 수 있다. 중요한 건 두 프레임워크의 경쟁이 아니라, 내가 어떤 생각으로 UI를 구성할지에 대한 주체성이다. 그것이 선언형 UI의 본질이자, SwiftUI가 말하고 싶은 진짜 메시지일지도 모른다.

조현성의 동기화