2025년 7월 30일·7분
왜 Swift가 존재하는가: iOS에서 Objective‑C를 어떻게 대체했는가
Apple이 Swift를 만든 이유, Swift가 어떻게 iOS에서 Objective‑C를 점진적으로 대체했는지, 그리고 이 전환이 툴링, 채용, 코드베이스에 어떤 의미를 남기는지 알아봅니다.
Apple이 Swift를 만든 이유, Swift가 어떻게 iOS에서 Objective‑C를 점진적으로 대체했는지, 그리고 이 전환이 툴링, 채용, 코드베이스에 어떤 의미를 남기는지 알아봅니다.
Swift는 단지 Apple이 "새로운 언어를 재미로" 만든 것이 아닙니다. iOS 개발에서의 실제 문제들 — 느린 반복, 실수로 작성하기 쉬운 안전하지 않은 패턴들, 그리고 복잡해진 현대 앱과 Objective‑C의 오래된 설계 사이의 불일치 — 에 대한 대응으로 등장했습니다.
이 글은 실용적인 질문에 답합니다: 왜 Swift가 존재하는지, 어떻게 기본이 되었는지, 그리고 그 역사가 오늘날 당신의 코드베이스와 팀 결정에 어떤 영향을 미치는지.
초기 Swift 릴리스부터 안정되고 널리 채택된 툴체인에 이르기까지 명확하고 가벼운 타임라인을 제공합니다—잡학에 빠지지 않고요. 그 과정에서 역사와 일상적 결과를 연결합니다: 개발자가 어떻게 더 안전한 코드를 쓰게 되었는지, API가 어떻게 진화했는지, Xcode 워크플로우에서 무엇이 변했는지, 그리고 concurrency와 SwiftUI 같은 기능이 포함된 "모던 Swift"가 무엇을 의미하는지.
Objective‑C는 특히 오래된 코드베이스나 특정 라이브러리에서 여전히 많이 사용됩니다. 목적은 공포나 긴급함을 조성하는 것이 아니라 명확성입니다: Swift가 Objective‑C를 하루아침에 지운 것이 아니라 상호 운용성과 생태계 변화로 서서히 대체되었다는 점입니다.
Objective‑C는 수십 년 동안 Apple 개발의 기반이었습니다. 2008년 첫 iPhone SDK가 등장했을 때 Objective‑C(및 Cocoa Touch 프레임워크)는 앱을 만드는 주요 방식이었고, 이는 Mac OS X의 Cocoa와 비슷했습니다. 초창기 iOS 앱을 작성했다면, Objective‑C를 통해 Apple의 플랫폼 관례를 배운 셈입니다.
Objective‑C는 특히 "Cocoa 방식"에 맞춰 사용하면 강력했습니다.
강력한 동적 런타임 위에 자리해 메시징, 리플렉션, 카테고리, 메서드 스위즐링 등이 유연하고 플러그인 친화적인 패턴을 가능하게 했습니다. 델리게이션, 타깃-액션, 알림, KVC/KVO(키-값 코딩/관찰) 같은 Cocoa 관례는 깊게 통합되어 잘 문서화되어 있었습니다.
또한 성숙한 생태계가 있었습니다. Apple의 프레임워크, 서드파티 라이브러리, 수년간의 Stack Overflow 답변들이 모두 Objective‑C를 전제로 했습니다. 툴링과 API도 그것에 맞춰졌고, 팀은 예측 가능한 기술을 가진 개발자를 채용할 수 있었습니다.
문제점은 철학적이라기보다 실무적인 마찰이었습니다.
Objective‑C는 특히 "간단한" 작업에서 장황할 수 있었습니다. 메서드 시그니처, 대괄호, 보일러플레이트는 코드를 길고 한눈에 파악하기 어렵게 만들었습니다. 많은 API가 포인터 중심 개념을 노출해 실수 가능성을 높였고, ARC(Automatic Reference Counting) 도입 이전에는 메모리 문제가 더 컸습니다.
메모리와 안전성 문제는 지속적인 우려였습니다. ARC가 있어도 소유권, 참조 사이클, 그리고 널러빌리티(nullability)를 이해해야 했고, 런타임에서 놀랄 일이 생길 수 있었습니다.
또한 C API와의 상호작용이 흔했는데, 항상 유쾌하지는 않았습니다. C 타입의 브리징, Core Foundation 처리, "toll‑free bridging" 관리는 현대적인 앱 코드 작성과는 다른 정신적 부담을 주었습니다.
레거시 iOS 코드베이스는 안정적이고 검증된 Objective‑C에 의존하는 경우가 많습니다. 오랜 기간 운영된 앱에는 여전히 Objective‑C 레이어(또는 오래된 의존성)가 포함되어 있고, 그것들은 여전히 실무에서 잘 작동합니다.
Apple이 Swift를 만든 것은 Objective‑C가 "망가졌기" 때문이 아닙니다. Objective‑C는 수년간 성공적인 iPhone과 Mac 앱을 가능하게 했습니다. 하지만 앱이 커지고 팀이 늘어나며 API가 확장되면서 Objective‑C의 기본값이 초래하는 비용이 눈에 띄게 되었고—특히 수백만 줄의 코드에서 작은 위험이 곱해질 때—그 비용이 더 분명해졌습니다.
주요 목표 중 하나는 흔한 실수를 쓰기 어렵게 만드는 것이었습니다. Objective‑C의 유연성은 강력하지만 런타임까지 문제를 숨길 수 있습니다: nil에 메시지를 보내는 것, id 타입의 혼동, API 널러빌리티를 잘못 관리하는 것 등이 그 예입니다. 이러한 문제들은 규율, 관례, 코드 리뷰로 관리할 수 있었지만, 대규모에서는 비용이 컸습니다.
Swift는 이런 가드레일을 내장합니다: 옵셔널은 "이 값이 없을 수 있나?"를 생각하게 만들고, 강한 타입은 실수로 잘못 쓰는 걸 줄이며 guard, switch의 완전성 검사, 더 안전한 컬렉션 처리 등은 더 많은 버그를 컴파일 단계로 옮깁니다.
Swift는 코드 작성의 일상 경험을 현대화했습니다. 간결한 문법, 타입 추론, 풍부한 표준 라이브러리는 헤더/구현 패턴, 장황한 제네릭 우회, 매크로 사용 등의 보일러플레이트를 줄여 일상 작업을 더 명확하게 만듭니다.
성능 측면에서 Swift는 값 타입과 제네릭에 대해 공격적인 컴파일러 최적화를 허용하도록 설계되었습니다. 이것이 자동으로 모든 Swift 앱을 Objective‑C 앱보다 빠르게 만들지는 않지만, Apple이 보다 동적 런타임 동작에 덜 의존하면서 성능을 향상시킬 수 있는 언어 모델을 제공했습니다.
Apple은 iOS 개발을 새 개발자에게 접근 가능하게 하고 장기간 유지되는 제품에 적합하도록 만들 필요가 있었습니다. Swift의 API 명명 규칙, 호출 지점에서의 명확한 의도 표현, 표현적인 타입 강조는 부적절한 "부족한 지식"(tribal knowledge)을 줄이고 몇 달 후에 코드베이스를 읽기 쉽게 만드는 것을 목표로 합니다.
결과는: 실수 가능성이 줄어든 코드, 더 깨끗한 API, 그리고 대형 팀이 오랜 기간 앱을 유지할 수 있게 지원하는 언어—Objective‑C가 일을 못 한다고 주장하는 것은 아니었습니다.
Swift는 하룻밤 사이에 "이겼다"가 아닙니다. Apple은 새로운 코드에 더 나은 선택지를 제공하면서, 기존 Objective‑C 앱과 병행 채택하기 쉽도록 수년간 언어를 안정화하고 빠르게 만들었습니다.
ABI 안정성은 Swift 런타임과 표준 라이브러리가 Apple 플랫폼에서 Swift 5 버전들 간에 바이너리 수준으로 호환된다는 뜻입니다. Swift 5 이전에는 많은 앱이 Swift 라이브러리를 앱 내부에 번들로 포함해야 했고, 이는 앱 크기를 늘리고 배포를 복잡하게 만들었습니다. ABI 안정성으로 Swift는 Objective‑C처럼 OS 업데이트에 걸쳐 컴파일된 코드가 더 안정적으로 실행될 수 있게 되어, 장수하는 프로덕션 코드베이스에 Swift를 더 신뢰할 수 있게 만들었습니다.
수년 동안 많은 팀은 새 기능에는 Swift를 쓰고 핵심 모듈은 Objective‑C로 남겼습니다. 이 기능별, 단계별 경로는 전면 리라이트 대신 현실적 일정과 실무에 맞는 Swift 확산을 가능하게 했습니다.
Swift는 모든 팀에게 기존 Objective‑C 코드를 버리라고 강요해서 이기지 않았습니다. Apple은 두 언어가 같은 앱 타깃에서 공존할 수 있게 보장했습니다. 이 호환성이 Swift 채택이 첫날부터 막히지 않은 큰 이유입니다.
혼합 코드베이스는 iOS에서 정상입니다: 기존 네트워킹, 애널리틱스, UI 구성요소는 Objective‑C로 남겨두고 새로운 기능은 Swift로 작성할 수 있습니다. Xcode는 이를 직접 지원하므로 "Swift가 Objective‑C를 대체"한다는 말은 보통 점진적 변화를 의미합니다.
상호 운용성은 두 가지 보완 메커니즘을 통해 작동합니다:
YourModuleName-Swift.h 같은 헤더를 생성하여 Objective‑C와 호환되는 Swift 클래스와 메서드를 노출합니다. 보통 @objc로 옵트인하거나 NSObject를 상속하여 노출합니다.플러밍을 모두 외울 필요는 없지만, "다른 언어에 노출하려면 명시적으로 노출 단계가 있다"는 사실을 이해하면 일부 타입이 자동으로 보이고 일부는 보이지 않는 이유를 설명하는 데 도움이 됩니다.
대부분 팀은 몇 가지 반복적인 통합 지점을 마주합니다:
실제 앱은 장수합니다. 상호 운용성은 기능별로 마이그레이션하고 계속 배포하며 위험을 줄일 수 있게 해줍니다—특히 서드파티 SDK나 오래된 컴포넌트, 시간 제약 때문에 한 번에 전부 바꾸기 현실적이지 않을 때 유용합니다.
Swift는 단순히 문법을 현대화한 것이 아니라, 일상적인 iOS 코드의 모습 자체를 바꿨습니다. 리뷰와 관례에 의존하던 많은 패턴이 컴파일러가 도와주는 것으로 옮겨갔습니다.
nil을 명시적으로Objective‑C 개발자는 nil에 메시지를 보내도 조용히 아무것도 일어나지 않는 것에 익숙했습니다. Swift는 옵셔널(String?)로 부재를 명시하게 하고 if let, guard, ?? 같은 패턴으로 핸들링하도록 권장합니다. 이로 인해 많은 충돌 범주와 "왜 이게 비었지?" 버그가 줄어듭니다—물론 실수가 완전히 사라지는 건 아닙니다.
Swift는 많은 곳에서 타입을 추론하므로 보일러플레이트를 줄이면서도 가독성을 유지합니다:
let title = "Settings" // inferred as String
더 중요한 점은 제네릭을 통해 런타임 id에 의존하지 않고 재사용 가능하고 타입 안전한 코드를 작성할 수 있다는 것입니다. "아무것도 담는 배열" 대신 "정확히 내가 기대하는 배열"을 쓰면 예기치 않은 객체가 섞이는 일이 줄어듭니다.
Swift의 throw/try/catch는 실패 경로를 명시적으로 다루게 하고 NSError **를 전달하는 관습을 줄입니다. 컬렉션은 강하게 타입화되어 ([User], [String: Int]) 문자열은 완전한 유니코드-정확 String으로 다뤄집니다. 결과적으로 오프바이원 실수, 잘못된 가정, "컴파일은 되는데 런타임에서 깨지는" 문제들이 줄어듭니다.
런타임 중심 패턴(메서드 스위즐링, 동적 메시지 포워딩, 특정 DI 접근법, KVC/KVO 기반 코드, 플러그인 아키텍처 등)에서는 Objective‑C 런타임이 여전히 유용합니다. Swift는 이들과 상호 운용할 수 있지만, 진정한 런타임 다이내믹성이 필요하다면 Objective‑C가 실용적인 도구로 남아 있습니다.
Swift는 문법만 바꾸지 않았습니다—iOS 생태계 전체가 툴과 관례를 현대화하도록 압박했습니다. 이 전환은 항상 매끄럽지 않았습니다: 초기 Swift 릴리스는 종종 느린 빌드, 불안정한 자동완성, 리팩터에 따른 불안감을 불러일으켰습니다. 시간이 지나며 개발자 경험은 Swift의 큰 장점 중 하나가 되었습니다.
Xcode의 Swift 지원은 일상적으로 다음과 같은 개선을 이루었습니다:
1.x/2.x 시대의 Swift를 사용해 본 사람이라면 거친 경험을 기억할 것입니다. 그 이후로 인덱싱, 소스 안정성, "Xcode가 혼란스러움" 현상이 줄어드는 일관된 추세가 이어졌습니다.
Swift Package Manager(SPM)는 많은 팀에서 외부 의존성 시스템의 필요성을 줄였습니다. 기본적으로 패키지와 버전을 선언하면 Xcode가 이를 해결하고 빌드에 통합합니다. 모든 설정에 완벽한 것은 아니지만, 많은 앱에서는 온보딩을 단순화하고 의존성 업데이트를 예측 가능하게 만들었습니다.
Apple의 API 설계 가이드라인은 프레임워크를 더 명확한 명명, 더 나은 기본 동작, 의도를 전달하는 타입으로 밀어붙였습니다. 이 영향은 외부로도 퍼져 서드파티 라이브러리들이 점점 Swift-first API를 채택하게 되었고, 레거시 Objective‑C를 내부적으로 브리지하더라도 현대적인 iOS 코드베이스는 일관성이 생겼습니다.
UIKit은 사라지지 않았습니다. 대부분의 프로덕션 iOS 앱은 여전히 복잡한 내비게이션, 정교한 제스처, 고급 텍스트 처리, 그리고 팀들이 오랫동안 다듬어온 UI 컴포넌트를 위해 UIKit에 크게 의존합니다. 변한 점은 많은 사람들이 UIKit 코드를 Swift로 작성한다는 것입니다—기본 프레임워크는 동일하지만 사용 방식이 바뀌었습니다.
많은 팀에게 "UIKit 앱"은 더 이상 Objective‑C를 의미하지 않습니다. 스토리보드, 닙, 프로그램적 뷰는 Swift 뷰 컨트롤러와 Swift 모델에 의해 구동되는 것이 일반적입니다.
이 변화는 중요합니다. Apple은 점점 더 새로운 API를 Swift 사용성에 맞춰 설계하므로(명확한 명명, 옵셔널, 제네릭, 결과 타입 등) Swift 오버레이가 종종 "의도된" 표면으로 느껴집니다. 이는 새로운 개발자가 UIKit 코드베이스에서 더 빨리 생산성을 얻도록 영향을 줍니다.
SwiftUI는 단순히 버튼을 그리는 새로운 방법이 아니었습니다. 그것은 다른 사고방식을 촉진했습니다:
실무적으로 팀 아키텍처 논의에 변화가 생겼습니다. SwiftUI를 채택한 팀은 종종 단방향 데이터 흐름, 더 작은 뷰 컴포넌트, 부수 효과(네트워킹, 영속성)를 뷰 코드에서 분리하는 것에 더 중점을 둡니다. "전면 채택"을 하지 않더라도 SwiftUI는 주로 폼, 리스트, 상태 기반 레이아웃에서 보일러플레이트를 줄여줍니다.
출시 중인 앱은 자주 두 프레임워크를 섞습니다:
UIHostingController를 사용해 SwiftUI를 UIKit에 임베드하여 새 화면을 추가이 하이브리드 접근은 팀이 성숙한 UIKit 인프라(내비게이션 스택, 코디네이터, 기존 디자인 시스템)를 유지하면서 SwiftUI를 점진적으로 도입하게 해 줍니다. 또한 위험을 관리할 수 있게 해주어, 전체 UI 레이어를 리라이트할 필요 없이 제한된 영역에서 SwiftUI를 파일럿할 수 있습니다.
오늘 새로 시작한다면 Apple의 최신 UI 스토리는 SwiftUI이고, 위젯, Live Activities, 일부 앱 확장 등 인접 기술들은 강하게 Swift 지향적입니다. UI를 제외하더라도 Apple 플랫폼 전반에서 Swift 친화적인 API가 기본값을 형성하므로, 새 프로젝트는 보통 Swift로 계획되며 결정은 "UIKit을 얼마나 사용할 것인가?"가 됩니다.
결과적으로 한 프레임워크가 다른 것을 완전히 대체하는 것이 아니라, Swift가 레거시 친화적 경로(UIKit)와 새로 나온 Swift-네이티브 경로(SwiftUI) 모두에 공통 언어가 되었다는 점이 중요합니다.
동시성은 앱이 인터페이스를 멈추지 않고 여러 일을 동시에 수행하는 방식을 뜻합니다—데이터 로드, JSON 디코딩, 화면 업데이트 등. Swift의 현대적 접근은 이런 작업을 스레드 수동 관리처럼 느끼지 않고 일반 코드처럼 다루게 설계되었습니다.
async/await로 비동기 작업(예: 네트워크 요청)을 위에서 아래로 읽히는 스타일로 작성할 수 있습니다:
async는 중간에 대기할 수 있는 함수임을 표시합니다.await는 "결과가 준비될 때까지 여기서 일시 중단" 지점을 표시합니다.중첩된 콜백 대신 레시피처럼 읽힙니다: 데이터를 가져오고, 파싱하고, 상태를 업데이트합니다.
Swift는 async/await와 함께 구조화된 동시성을 제공합니다. 기본 아이디어는: "백그라운드 작업은 명확한 소유자와 수명을 가져야 한다"입니다. 작업(task)은 스코프 안에서 생성되고 자식 작업은 부모에 연결됩니다.
이것은 다음을 개선합니다:
두 가지 개념이 동시성으로 인한 무작위 충돌을 줄이는 데 도움됩니다:
대부분 팀이 단번에 전환하지는 않습니다. OperationQueue, GCD, 델리게이트 콜백, completion handler 등 기존 패턴과 모던 Swift 동시성을 혼용하는 경우가 흔합니다—특히 레거시 라이브러리나 오래된 UIKit 흐름과 통합할 때 그렇습니다.
실제 iOS 앱을 마이그레이션하는 것은 "모두 변환" 프로젝트가 아니라 위험 관리 프로젝트입니다. 목표는 배포를 계속하면서 유지해야 할 Objective‑C 양을 점진적으로 줄이는 것입니다.
일반적인 접근법은 점진적 마이그레이션입니다:
이렇게 하면 일정 중단 없이 신뢰를 쌓으면서 파급 범위를 제한할 수 있습니다.
몇몇 Objective‑C 패턴은 깔끔하게 변환되지 않습니다:
objc_runtime 트릭을 많이 쓰는 코드는 재설계가 필요합니다.마이그레이션을 특성화된 구현 교체로 취급하세요, 기능 변경으로 보지 마세요. 중요한 흐름(네트워킹, 캐싱, 결제, 인증)에 대한 특성화 테스트를 먼저 추가한 다음 포팅하세요. 스냅샷 테스트는 UIKit 코드가 Swift로 이동할 때 UI 회귀를 잡는 데 도움이 됩니다.
팀이 따를 가벼운 표준을 만드세요: 코딩 컨벤션, 린팅(SwiftLint 등), 모듈 경계, 브리징 헤더 규칙, "정당한 이유 없이는 새로운 Objective‑C 금지" 같은 규칙을 문서화하면 코드베이스가 일관성 없이 이중언어가 되는 것을 막을 수 있습니다.
Swift는 단순히 문법을 바꾼 것이 아니라 iOS 팀의 "일상"을 바꿨습니다. 제품에 Objective‑C가 남아 있어도, 일상적 결정(사람, 프로세스, 장기 유지보수)은 이제 Swift 우선 기대에 의해 형성됩니다.
대부분의 신규 iOS 포지션은 Swift를 기본으로 가정합니다. 후보자는 전문적으로 Objective‑C를 써본 적이 없을 수 있고, 혼합 코드베이스에서는 온보딩 시간이 늘어날 수 있습니다.
실무적 권고: Objective‑C 지식은 "플러스"로 취급하고, 온보딩 자료에는 Objective‑C가 어디에 있고 왜 존재하는지 명시하세요. 브리징 헤더, 파일 소유권, "컨텍스트 없이 건드리지 말아야 할" 영역에 대한 짧은 내부 가이드는 초기 실수를 방지합니다.
Swift의 강한 타입과 명확한 옵셔널은 리뷰를 빠르게 만들 수 있습니다: 리뷰어는 값이 무엇일 수 있는지 추측하는 데 시간을 덜 쓰고 의도를 검증하는 데 더 집중할 수 있습니다. 프로토콜, 제네릭, 값 타입 같은 패턴은 절제하여 사용하면 더 일관된 아키텍처를 장려합니다.
반대편 위험은 스타일의 분산입니다. 팀은 공유된 Swift 스타일 가이드와 자동 포맷/린트를 도입해 리뷰가 동작 확인에 집중하도록 해야 합니다. (이미 가이드가 있다면 내부 문서 허브에 링크하세요.)
모던 API를 직접 활용하면 커스텀 래퍼를 오래 유지할 필요가 줄어들어 유지보수가 쉬워집니다. 하지만 Objective‑C는 특히 성숙한 앱의 안정적 모듈에서 당장 사라지지는 않을 것입니다.
혼합 코드베이스에 대해 현실적으로 예산을 책정하세요: 마이그레이션은 비즈니스 마일스톤을 중심으로 계획하고 무조건적인 "청소"가 되지 않도록 하세요. "완료"의 정의(예: 모든 새 코드는 Swift로, 레거시 모듈은 기회가 있을 때만 수정)를 정하고 주요 리팩터 때 규칙을 재검토하세요.
결정 프레임워크 예시는 /blog/migrating-objective-c-to-swift를 참조하세요.
Swift와 Objective‑C 중 선택은 보통 철학적 논쟁이 아니라 비용, 위험, 일정의 문제입니다. 좋은 소식은 대부분의 경우 "전부 아니면 전무"를 고를 필요가 거의 없다는 점입니다. 대부분의 팀은 코드베이스를 제자리에서 진화시키는 방식으로 가장 좋은 결과를 얻습니다.
새 프로젝트라면 Swift를 기본으로 하세요. 이는 Apple의 최신 API와 정렬되고, 더 나은 안전 기능을 제공하며, async/await 같은 현대 패턴에 바로 접근할 수 있게 해 줍니다.
첫 번째 결정은 UI 전략입니다: Swift로 UIKit, SwiftUI, 또는 혼합을 쓸지 정하세요. 확실치 않다면 /blog/swiftui-vs-uikit에서 트레이드오프를 비교하세요.
기존 Objective‑C 앱의 경우 안정적이고 테스트된 모듈은 Objective‑C로 두고 다음과 같은 곳에 Swift를 도입하세요:
실용적 규칙: 명확한 경계(공개 API, 소유권, 테스트)가 정의될 수 있을 때 새 Swift 모듈을 시작하세요. 코드가 성숙하고 밀접하게 얽혀 있거나 건드리기 위험한 레거시 Objective‑C는 그대로 두세요.
계획 참고자료: /blog/ios-migration-checklist.
개인과 팀을 위한 추천 순서는 다음과 같습니다:
iOS 코드 현대화는 종종 같은 엔지니어링 시간 경쟁을 하는 인접 작업을 드러냅니다: 관리자 대시보드, 내부 도구, 백엔드 서비스, iOS 앱이 의존하는 API 등. iOS 팀이 Swift 마이그레이션에 집중하는 동시에 지원 소프트웨어를 계속 출시하려면, Koder.ai 같은 도구를 이용해 웹 앱, Go 백엔드(PostgreSQL 포함), 또는 Flutter 동반 앱을 채팅 기반 워크플로로 빠르게 생성하고—소스 코드를 내보내고 배포하며 스냅샷/롤백으로 안전하게 반복할 수 있습니다.
안전한 다음 단계를 스코핑하는 데 외부 도움이 필요하면—새 모듈, 부분 마이그레이션, 또는 "가만히 두기" 중 어떤 것이 좋을지—/pricing을 확인하세요.
Swift는 예기치 않은 nil 동작이나 느슨한 타입 사용 같은 일반적인 iOS 개발 위험을 줄이고, 대형 코드베이스에서 가독성 및 유지보수성을 개선하며, 시간이 지나면서 컴파일러 최적화를 더 잘 활용할 수 있게 하기 위해 만들어졌습니다. Objective‑C가 “나쁘다”는 의미가 아니라, 대규모에서 안전한 기본값을 더 쉽게 쓰게 하려는 목적이었습니다.
다음 요인들의 점진적 결합을 통해 Swift는 강제적인 리라이트 없이 기본 언어가 되었습니다:
이 때문에 대부분 팀에서 “새 코드에 Swift 사용”이 가장 쉬운 선택이 되었습니다.
Swift 5는 Apple 플랫폼에서 ABI(바이너리 인터페이스) 안정성을 도입했습니다. 이것은 Swift로 컴파일된 코드가 OS에 번들된 런타임과 바이너리 수준에서 호환될 수 있다는 의미입니다. 이전에는 앱이 Swift 표준 라이브러리를 번들로 포함해야 해서 앱 크기와 배포 복잡도가 늘어났습니다. ABI 안정성으로 앱 크기와 배포 신뢰도가 개선되어 Swift가 장기간 운영되는 프로덕션 코드베이스에 더 적합하게 느껴지게 되었습니다.
혼합 코드베이스에서는 다음과 같이 동작합니다:
YourModuleName-Swift.h 헤더를 통해 Objective‑C와 호환되는 Swift API를 노출할 수 있으며, 보통 @objc 어노테이션이나 NSObject 상속으로 선택적으로 공개합니다.모든 Swift 기능이 Objective‑C에 보이는 것은 아니므로 경계를 의도적으로 설계하는 것이 중요합니다.
옵셔널(T?)은 값의 부재를 명시적으로 표현하고 컴파일 시점에 처리하도록 강제합니다(예: if let, guard, ??). Objective‑C에서는 nil에 메시지를 보내면 조용히 무시되는 동작과 애매한 nullability 때문에 런타임에서 버그가 드러나는 경우가 많았습니다. 실무적으로 옵셔널은 충돌과 "값이 비어 있어 발생하는" 논리 버그를 줄여줍니다.
Swift의 제네릭과 강한 타입 시스템은 캐스팅과 런타임 타입 검사(과거 Objective‑C의 id와 비유)가 줄어들게 만듭니다. 실무적으로 얻는 이점은:
[User] 같은 안전한 컬렉션(‘아무것도 담는 배열’ 대신)결과적으로 코드가 더 안전하고 예측 가능해집니다.
네—Objective‑C는 여전히 런타임 다이내믹성이 진짜로 필요할 때 유리합니다(예: KVC/KVO의 광범위 사용, 메서드 스위즐링, 셀렉터 기반 API, 플러그인 스타일 아키텍처 등). Swift는 이러한 패턴과 상호 운용할 수 있지만, 순수 Swift 대안은 직접 변환하기보다 설계 재검토가 필요할 수 있습니다.
실무에서는 점진적 마이그레이션이 가장 안전한 전략입니다:
이 과정을 위험 관리 관점으로 보고, 배포를 멈추지 않으면서 장기 유지비를 줄이는 것이 목표입니다.
흔한 함정들은 다음과 같습니다:
@objc, NSObject 등 제한된 언어 기능이 필요함마이그레이션 전에 경계를 설계하고 테스트를 추가하면 이런 문제를 줄일 수 있습니다.
전혀 그럴 필요 없습니다. 많은 프로덕션 앱이 혼합 아키텍처입니다:
UIHostingController로 SwiftUI 화면을 UIKit에 임베드합니다.이 방식은 SwiftUI가 보일 때마다 보일러플레이트를 줄이는 동시에 성숙한 UIKit 네비게이션과 복잡한 컴포넌트를 그대로 유지할 수 있게 해 줍니다.