Swift 프로그래밍 배우기: 프라임 타임을 위한 준비가 되었습니까?

게시 됨: 2022-03-11

지난 6월 Apple이 iOS 앱을 작성하기 위한 새로운 프로그래밍 언어인 Swift를 출시하면서 iOS 개발자 커뮤니티 전체에 엄청난 화제와 흥분을 불러일으켰습니다.

출시 이후 많은 iOS 개발자는 Objective-C에서 Swift로 전환할지, 어떻게, 언제 전환할지에 대한 문제로 어려움을 겪고 있습니다. 물론 그 질문에 대한 답은 모든 팀과 프로젝트마다 다를 것입니다.

Swift의 많은 장점을 다루는 많은 기사를 읽을 수 있습니다. 따라서 동일한 요점을 다시 설명하는 대신 이 기사에서는 Swift로 앱 개발을 배우기 전에 고려할 수 있는 몇 가지 우려 사항에 중점을 둘 것입니다.

Swift를 사용한 프로그래밍은 프라임 타임에 대비할 수도 있고 아닐 수도 있습니다. 아직 Swift 언어를 배웠습니까?

하지만 먼저 시계를 조금 뒤로 돌리자...

Swift 이전: Objective-C를 사용하고 좋아할 것입니다…

때는 2010년이었습니다. iPhone은 아직 3년이 되지 않았고 iPhone용 기본 앱을 작성할 수 있는 기능은 약 2년 동안만 있었습니다. 그해 4월 8일 애플은 아이폰 OS 버전을 발표했다. iPhone OS(iOS로 이름을 변경하기 전)에는 멀티태스킹, 빠른 앱 전환 및 백그라운드 서비스와 같은 매력적인 새로운 기능이 포함되었습니다. 당연히 iPhone 개발자는 새로운 SDK를 손에 넣고 흥미진진한 새로운 기능을 모두 사용하기 시작했습니다.

그러나 iPhone OS 4 SDK에는 예기치 않은 폭탄이 포함되어 있습니다. 이 폭탄은 소프트웨어가 아니라 사용 계약에 있었습니다. iPhone OS 4 SDK에서는 개발자 계약의 섹션 3.3.1이 다음과 같은 문제가 되는 언어를 포함하도록 업데이트되었습니다.

응용 프로그램은 원래 Objective-C, C, C++로 작성되어야 하며 C, C++ 및 Objective-C로 작성된 코드만 컴파일하고 문서화된 API에 대해 직접 링크할 수 있습니다.
– iPhone OS 4 SDK 개발자 계약의 섹션 3.3.1

말할 필요도 없이, 이 새로운 제한은 많은 개발자들을 놀라게 했습니다. Steve Jobs 자신이 제공한 변경의 공식적인 이유는 최근에 발표된 Flash CS5와 같은 크로스 플랫폼 도구의 사용을 방지하기 위함이었습니다. 잡스는 "플랫폼과 개발자 사이의 중간 계층이 궁극적으로 [원래의] 표준 이하 앱을 생산한다"고 말한 것으로 인용되었습니다. 그러나 이러한 "중간 계층"에 대처하는 Apple의 접근 방식이 iPhone 앱을 작성하는 데 사용할 수 있는 프로그래밍 언어를 제한한다는 사실은 Apple의 생각에 대해 더 많은 것을 보여주었습니다. Objective-C는 누구에게나 충분해야 합니다.

Objective-C가 Tiobe Index의 "올해의 프로그래밍 언어" 상을 2년 연속 수상했기 때문에 이 주장에 동의하는 사람은 용서받을 수 있습니다. 그러나 현실은 Objective-C의 인기가 성장하는 앱 생태계의 기능이지 그 반대가 아니라는 것이었습니다. 2010년으로 돌아가도 많은 사람들이 이미 Objective-C에 만족하지 못했고 결과적으로 다른 프로그래밍 언어로 iPhone 앱을 작성하는 다른 방법이 이미 등장하고 있었습니다.

결국, 개발자 커뮤니티 전반의 압력에 따라 Apple은 불과 5개월 후 SDK 개발자 계약의 섹션 3.3.1에 대한 이러한 변경 사항을 철회했습니다. 그래도 메시지는 명확했습니다. iPhone용 앱을 작성하려면 아마도 Objective-C를 사용해야 할 것입니다.

... 아니면 아닐 수도 있습니다. 새로운 iOS 언어 Swift를 입력하세요.

그 사건으로부터 4년 후인 2014년 6월 Apple이 개발자들에게 새로운 언어인 Swift를 소개한 때로 빠르게 이동합니다. 4년 전의 메시지가 애플이 오브젝티브-C에 완벽하게 만족했다는 것이었다면 스위프트의 소개가 보낸 메시지는 애플이 마침내 진실을 인정할 준비가 됐다는 것이었다. Objective-C가 모바일 앱 작성에 가장 적합한 언어는 아닐 수도 있습니다.

Swift가 Objective-C보다 더 "현대적인" 언어라는 것에 대해 많은 이야기가 있었습니다. Swift 프로그래밍 언어를 배우는 방법에 관심이 있다면 Objective-C에서 Swift로 이동하기 위한 가이드를 확인하는 것이 좋습니다.

그러나 주목해야 할 것은 Objective-C와 Swift 언어 사이에 두 가지 중요한 차이점이 있다는 것입니다.

  1. Swift는 C 언어의 엄격한 상위 집합이 아닙니다 .
  2. Swift는 동적으로 유형이 지정 되지 않고 정적으로 유형이 지정됩니다.

C의 엄격한 상위 집합이 아니라는 것은 Swift가 그렇지 않으면 허용되지 않는 구문 구성을 자유롭게 사용할 수 있음을 의미합니다. 이를 통해 예를 들어 Swift에서 사용자 정의 연산자를 구현할 수 있습니다.

정적으로 유형이 지정된다는 것은 Swift가 Haskell과 같은 언어에서 개척한 유형 시스템의 최근 발전을 많이 활용할 수 있음을 의미합니다.

대중에게 공개되기까지 4년 동안 개발되었음에도 불구하고 Swift는 아직 어린 프로그래밍 언어이므로 많은 주의 사항이 있습니다.

Objective-C와의 호환성

iOS는 1989년에 처음 출시된 NeXTSTEP 운영 체제에서 역사를 가져오는 OS X과 공통 유산을 공유합니다. NeXTSTEP은 원래 대부분 Objective-C로 작성되었으며 OS X 및 iOS의 많은 핵심 라이브러리는 모두 그 뿌리를 추적합니다. 이러한 원래 구현으로 돌아가는 방법. (참고로 여기에서 NSString 과 같은 핵심 클래스에서 발견되는 유비쿼터스 "NS" 접두사가 유래되었습니다.) Swift는 이론적으로 이러한 핵심 라이브러리가 없을 때 존재할 수 있지만 현실은 가까운 장래에 작성할 수 있는 모든 Swift 프로그램이 Objective-C와 인터페이스해야 합니다.

그들의 신용으로, Swift의 개발자들은 기존 Objective-C 라이브러리와의 상호 작용을 가능한 한 고통 없이 만드는 환상적인 일을 해냈습니다. 그렇다고 그 과정이 완전히 고통스럽지 않다는 것은 아닙니다. Apple은 Swift에서 Objective-C 코드를 호출하는 방법과 그 반대의 방법을 설명하는 유용한 가이드를 제공했지만 알아야 할 몇 가지 중요한 임피던스 불일치가 있습니다.

아마도 가장 명백한 불일치는 헤더 파일과 관련이 있습니다. Objective-C는 C 루트로 인해 여전히 함수가 호출되기 전에 선언되어야 합니다. 라이브러리를 호출할 때 이러한 선언은 라이브러리의 헤더 파일에서 찾을 수 있습니다. 그러나 Swift는 헤더 파일을 사용하지 않습니다. 따라서 Objective-C에서 Swift 코드를 호출하려면 먼저 "브리징 헤더"를 생성해야 합니다. 개념적으로는 그렇게 복잡해 보이지 않을 수도 있지만 실제로는 꽤 많은 작업이 될 수 있습니다.

Swift와 Objective-C 간의 인터페이스에서 발생하는 또 다른 복잡성은 유형 시스템의 고유한 차이점에서 비롯됩니다. 다른 현대 언어에서 힌트를 얻은 Swift는 nil 개념을 없앴습니다. 그 자리에 Swift의 선택적 유형이 있습니다. 예를 들어 파일이 이미 존재하는 경우에만 파일을 여는 메서드는 반환 유형이 File? ( File 대신) Swift에서. 유형이 선택 사항인 모든 위치를 추적함으로써 Swift 컴파일러는 두려운 "Null Pointer Error"가 발생하는 것을 효과적으로 불가능하게 만들 수 있습니다. 물론 Objective-C를 호출하지 않는 한 그렇습니다. Objective-C는 nil 을 반환하지 않는다는 보장을 하지 않기 때문에 Swift는 Objective-C 코드를 호출할 때 사용되는 Implicitly Unwrapped Optionals 라고 하는 특수한 유형의 유형을 가지고 있습니다. 이러한 유형은 존재 확인에 필요한 수반되는 모든 오버헤드와 함께 Swift 언어에서 선택 사항으로 처리될 수 있습니다. 또는 선택 사항이 아닌 유형과 동일하게 사용할 수 있지만 Objective-C 가 nil 을 반환하면 런타임 오류가 발생하므로 Swift의 컴파일 시간 안전 보장 중 일부를 잃게 됩니다.

마지막으로, Swift와 Objective-C 사이에서 프로그래밍할 때 고려해야 할 약간 더 미묘한 불일치는 이 두 언어에서 객체와 클래스가 숨겨져 생성되는 방식과 관련이 있습니다. Objective-C는 동적 특성으로 인해 동적 디스패치를 ​​사용하여 객체에 대한 메서드를 호출합니다( objc_msgSend 를 통해). Swift는 확실히 동적 디스패치를 ​​사용할 수 있지만 정적으로 유형이 지정되기 때문에 vtable 을 사용하여 각 메서드에 대한 함수 포인터를 저장하는 옵션도 있습니다. Swift가 사용하는 이 두 메커니즘 중 몇 가지 요인에 따라 다릅니다. Plane Old Swift Objects는 클래스 또는 클래스 내의 메소드가 @objc Swift 속성을 사용하여 주석 처리되지 않는 한 vtable 메커니즘을 사용합니다. Objective-C 클래스에서 상속하는 Swift 클래스는 상속된 메서드에 대해 동적 @objc 를 ​​사용하지만 하위 클래스에 의해 도입된 새 메서드에는 사용하지 않습니다. 그럼에도 불구하고 Swift 코드는 항상 Swift 클래스와 함께 작동할 수 있지만 Objective-C 코드는 적절하게 주석이 달린 Swift 객체와 메서드만 사용할 수 있습니다.

오브젝티브-C보다 빠름?

Apple이 출시를 발표했을 때 특히 강조된 Swift의 이점 중 하나는 속도였습니다. Apple이 Objective-C에서 고급 언어로 전환하는 것을 꺼리는 이유 중 하나는 본질적으로 C의 확장인 Objective-C가 훨씬 빠르고 효율적인 프로그램을 만들 수 있기 때문입니다. Python이나 Ruby와 같은 것보다. 그럼에도 불구하고 Objective-C는 절대적인 성능에 있어 로켓 우주선이 아니며 그 중 많은 부분이 동적 타이핑에 기인할 수 있습니다. 따라서 Swift가 정적 유형 시스템을 채택하면 Swift 가 적어도 Objective-C만큼 빠르거나 빨라야 합니다.

물론 속담에 "거짓말에는 거짓말, 저주받은 거짓말, 벤치마크의 세 가지 유형이 있습니다."라는 말이 있습니다. (또는 그와 비슷한 것...) 확실히, Swift 언어가 더 빨리 실행되는 데에는 여러 가지 이유가 있습니다. 불행히도, Swift가 메모리 관리를 위해 Apple의 ARC(Automatic Reference Counting) 기술을 활용하는 방식은 때때로 Swift의 컴파일러가 특히 더 낮은 최적화 설정(예: 개발 중에 사용할 수 있는 것)에서 상당히 느린 프로그램을 생성하는 것으로 보입니다. 좋은 소식은 Swift의 개선 사항이 이 문제를 지속적으로 해결하는 것 같으므로 가까운 장래에 Swift가 적어도 Objective-C보다 빠르거나 빠른 실행 파일을 생성할 가능성이 있다는 것입니다.

그러나 Swift의 속도에는 또 다른 주의 사항이 있습니다. Swift의 요점은 개발자가 Objective-C에서 작성했던 것과 동일한 코드를 작성 하지 않는다는 것입니다. 이것은 성능에 무엇을 의미합니까? 글쎄, 확실히 그것은 Swift와 Objective-C 간의 성능 비교가 단순한 벤치마크가 밝힐 수 있는 것보다 더 복잡하다는 것을 의미합니다. 또한 생성된 실행 파일의 절대적인 런타임 성능을 비교하면 절반의 이야기만 알 수 있습니다.

모두가 빠른 프로그램을 원하지만 종종 개발 속도가 그 이상은 아니더라도 중요합니다. 더 적은 코드 줄로 더 많은 작업을 수행할 수 있고 표현력이 뛰어난 언어는 이와 관련하여 큰 이점이 될 수 있습니다. 반면에 편집-컴파일-실행-디버그 주기가 프로그래머의 하루 중 많은 부분을 차지하는 컴파일된 언어로 작업할 때 느린 컴파일러는 생산성을 크게 떨어뜨릴 수 있습니다. 증거는 주로 일화이지만, 특히 Swift의 고급 유형 시스템을 실행하는 코드로 작업할 때 Swift 컴파일러는 현재 성가실 만큼 느린 것 같습니다. 한 그룹은 컴파일 속도가 Objective-C로 다시 전환하도록 동기를 부여할 만큼 문제가 있음을 발견했습니다.

컴파일러

Swift 컴파일러에 대해 말하자면, 새로운 Swift 언어로의 전환을 고려할 때 그 자체가 훨씬 더 주의해야 할 사항입니다. 컴파일 속도 외에도 Swift가 Apple에서 작업하는 소규모 개발자 간부에서 등장하여 대중에게 공개됨에 따라 컴파일러는 스트레스를 받는 상태에서 균열을 보이기 시작했습니다. Swift 컴파일러가 충돌하게 만드는 코드의 예를 수집하는 데 전념하는 전체 GitHub 저장소도 있습니다.

또한 Swift 컴파일러가 어떻게 변경될 것인지에 대한 질문도 있습니다. GitHub의 또 다른 프로젝트는 커뮤니티에서 Swift에 대한 변경 사항에 대한 추측과 분석을 수집하고 있습니다. 예를 들어 사용자 정의 연산자는 파서에 상당한 부담을 줄 수 있습니다. 처음에 Swift의 사용자 정의 연산자는 물음표(?) 문자를 사용할 수 없었습니다. 이것은 최신 Swift 릴리스에서 수정되었지만 유효한 사용자 정의 연산자로 간주될 수 있는 훨씬 더 많은 유연성을 위해 증가하는 Swift 개발자 커뮤니티의 요청이 계속해서 유입되고 있습니다.

언어에 대한 파서 가 유동적이라는 소식을 들을 때마다 일시 중지해야 합니다. 언어의 파서는 프로그래밍 언어의 심장이자 영혼입니다. 코드에 의미를 부여하기 위해 언어 의미 체계를 적용하기 전에 먼저 유효한 코드와 그렇지 않은 코드를 결정하는 것은 파서입니다. 따라서 Apple이 Swift에 대해 일정 수준의 런타임 호환성을 보장하겠다고 약속한 것은 고무적입니다. 그렇다고 해서 Swift 코드가 Xcode 및/또는 iOS의 새로운 릴리스마다 다시 컴파일되지 않고 실행된다는 보장은 없습니다. 또한 향후 Swift 릴리스와 호환성을 유지하기 위해 Swift 코드의 일부를 다시 작성할 필요가 없다는 보장도 없습니다. 그러나 다시 말하지만, 이 프로세스를 가능한 한 고통 없이 만들겠다는 Apple의 약속은 최소한 작은 위안입니다.

지역 사회

이제까지 만들어진 최악의 프로그래밍 언어(이름이 없는 상태로 남을 것) 중 일부는 해당 커뮤니티의 힘만으로 실패한 기술의 쓰레기통으로 강등되어야 한다고 상식이 말한 지 오래 만에 부양되었습니다. 동시에, 커뮤니티의 부족을 위해 실패한 정말 좋은 프로그래밍 언어의 모음은 셀 수 없을 정도로 많습니다. 강력한 커뮤니티는 튜토리얼을 만들고, Stack Overflow에 대한 질문에 답하고, 온라인이나 컨퍼런스에서 직접 만나 이야기, 팁 및 트릭을 공유하고, 유용한 라이브러리를 작성하고 서로 공유합니다. 프로젝트에 사용할 언어를 선택할 때 커뮤니티는 확실히 고려해야 할 사항입니다.

슬프게도 iOS/Objective-C 커뮤니티는 친절하고 환영한다는 평판이 좋지 않습니다. 이는 점차 변화하고 있으며 오픈 소스는 Objective-C 개발에서 점점 더 중요한 역할을 하고 있습니다. 그러나 이 초기 단계에서 Swift 커뮤니티가 앞으로 어떻게 보일지 말하기는 어렵습니다. 대부분이 공식 Apple API와 자체 개인 코드 모음으로만 작업하는 고립된 개발자로 구성됩니까? 아니면 팁, 트릭 및 유용한 라이브러리를 공유하는 활기찬 그룹 커뮤니티가 될까요?

커뮤니티 역할의 또 다른 측면은 Swift 개발자 자신의 역할입니다. 프로그래밍의 전반적인 추세는 독점 프로그래밍 언어 및 플랫폼에서 오픈 소스 솔루션으로 이동하는 것입니다. 특히 프로그래밍 언어 및 런타임 수준에서 오픈 소스 개발은 실질적인 이점이 될 수 있습니다. Swift 개발자는 자신의 의도가 Swift 언어와 런타임을 완전히 공개하는 것이라고 여러 번 밝혔지만, 아직 그런 일은 일어나지 않았으므로 주의가 필요합니다.

즉, Swift 뒤에 있는 개발자는 장기 실행 LLVM 프로젝트 뒤에 있는 동일한 개발자 중 일부입니다. LLVM은 일리노이 대학교 Urbana-Champaign에서 프로젝트로 공개적으로 시작되었기 때문에 완벽한 비유는 아닙니다. 그러나 그들의 공로로 핵심 개발자들은 대부분이 Apple에서 일하기로 전환한 후에도 여전히 매우 개방적이고 커뮤니티에 참여하고 있습니다. 커뮤니티의 패치 및 기능 제안이 언어로 들어갈지 여부는 아직 남아 있지만 Swift 언어가 공개적으로 계속 개발될 것이라고 기대하는 것은 완전히 합리적입니다.

스위프트를 배워야 하나요?

물론 여기에 "모든 사람에게 맞는" 정답은 없습니다. 항상 그렇듯이 작업에 적합한 도구를 선택하려면 해당 프로젝트의 모든 세부 사항에 대한 자세한 지식이 필요합니다. 확실히 이 시점에서 Objective-C는 iOS 개발을 위한 "안전한" 선택으로 남아 있지만 Swift는 확실히 고려할 가치가 있습니다.

하지만 Swift가 iOS 개발에 가져오는 가장 중요한 변화는 많은 개발자들이 처음으로 "어떤 언어를 사용해야 합니까?"라는 질문을 스스로에게 하게 될 것이라는 점입니다. Apple, Objective-C 및 iOS 플랫폼의 역사를 감안할 때, 특히 선택이 바이너리가 아니라는 점을 고려하면 이 변경만으로도 상당히 흥미진진합니다. Apple이 선호도를 분명히 했지만 iOS 개발자 커뮤니티는 이미 이 질문에 대한 더 많은 가능한 답변을 제공하기 위해 수년 동안 열심히 일해 왔습니다.