출판사 리뷰
오브젝티브-C를 써 왔던 스위프트 개발자들의 부담을 덜어주는 최적의 가이드스위프트는 격변의 시기를 거쳐 어느새 강하고 튼튼한 언어로 자리매김했으며 빠른 속도로 오브젝티브-C를 밀어내고 있다. 초기에는 매번 동일한 주제의 오브젝티브-C 코드를 참고하고 이를 스위프트 코드로 변환하는 수작업을 거쳐야만 했지만, 이제는 원하는 내용을 구현하는 스위프트 코드를 쉽게 찾아볼 수 있을 정도다. 그럼에도 상당수의 오브젝티브-C 개발자들은 스위프트로 옮겨가는 시기를 고민하고 있다. 오브젝티브-C에 익숙한 사람들에게 스위프트를 충실히 안내하는 이 책은 그래서 절묘하다. 이미 상당한 기반 지식이 있는 이들에게 백과사전이나 바이블 식의 설명은 필요 없을 것이다. 핵심은 현재의 오브젝티브-C를 스위프트가 어떤 식으로 대체하고 있는가에 있기 때문이다. 이 책은 오브젝티브-C 유저들이 익숙하고 자연스럽게 스위프트 문법과 구조에 익숙해질 수 있는 최적의 구성을 갖췄다. 아울러 ‘꼼꼼한 재은 씨’ 시리즈의 저자 이재은 씨가 최근 업데이트 된 기능들을 감수 보완하여 믿음을 더했다.
◆
출판사 리뷰
스위프트를 가볍게 시작하게 하는 책.
바이블이 부담스러운 당신을 위한 책.
각 장 설명글만 읽어도 반하게 될 책.소프트웨어 개발에서 가장 어려운 일이 바로 첫 번째 고비를 잘 넘기는 것입니다. 프로그래밍 초보자가 오브젝티브-C나 스위프트를 배우는 것은 큰 도전일 수 있습니다. 새 프로젝트나 워크스페이스를 만들 때, 갈피를 잡을 수 없이 정렬된 많은 템플릿 옵션들을 보면 반감마저 생깁니다. 경험 많은 iOS나 macOS 개발자라 해도, 새로운 아이디어를 시도한다는 것이 쉽지만은 않습니다. 프로젝트 타입을 선택해야 하고(가장 까다로운 부분이죠?), 코드 실행을 위해서 매일 똑같은 ‘빌드-앤-런(Build & Run)’ 버튼을 클릭해서 다람쥐 쳇바퀴 돌듯 프로그램을 돌려봐야 합니다. 아이디어가 괜찮은 것 같다 할지라도, 템플릿은 제대로 선택한 것인지, 아니면 다시 전 단계로 되돌아가서 새 프로젝트를 만들고 코드를 복사해서 다시 붙여야 할지 고민할 수도 있겠죠. 애플은 스위프트에서 두 가지 새로운 도구를 선보였습니다. 하나는 REPL로, 특히 스크립트 언어에서 쓰던 오래된 방식인데, 상호작용적 프로그래밍이 가능한 Read-Eval-Print-Loop라는 이름의 개발환경입니다. 다른 하나는 스위프트 플레이그라운드라는 것으로, 언어를 배우거나 코딩하는 데 혼란을 최소화할 수 있는 아주 편리하고도 독창적인 개발환경입니다.
모든 프로그래밍 책이 언어의 기본 개념부터 시작하는 것은 다 이유가 있습니다. 기초적인 개념을 이해하지 못하면, 프로그래밍 언어를 제대로 이해할 수 없기 때문입니다. 클래스나 콜렉션 같은 고급 구조체 개념에서 헤맬 수도 있지만 기본 데이터 타입, 함수, 연산자 같은 기본 사항을 제대로 이해하지 못한다면 정말 난항을 겪게 됩니다. 그럼에도 많은 경력 프로그래머들이 처음 한 두 단원 정도는 그냥 넘겨버리고 기본은 차차 하면서 배우겠다고 생각하죠. 스위프트와 오브젝티브-C는 비슷하지만 똑같지 않습니다. 데이터 타입, 함수, 변수 및 상수 선언 방식 등 두 언어 사이에는 중요하면서도 커다란 차이가 있습니다. 그래서 이 책에서 기본 개념이 무엇보다 중요하다고 강조하고, 또 여러분이 플레이그라운드를 열어 새로운 기능을 직접 사용해보라고 권하는 것입니다.
데이터를 다룰 때 완전히 순차적으로 작업하는 것은 어렵습니다. 그래서 모든 프로그래밍 언어에서는 제어 구조가 필수입니다. 외견상으로는 스위프트의 제어 구조가 오브젝티브-C의 제어 구조와 같아 보여도, 좀 더 자세히 들여다보면 여러 측면에서 기존의 기능보다 월등하다는 것을 알 수 있습니다.
옵셔널은 값을 가질 수도 있고, 가지지 않을 수도 있기 때문에 일반적인 변수나 상수와는 다릅니다. 애플이 스위프트의 기능을 처음 소개했을 때 오브젝티브-C 개발자들이 가장 어려워한 기능이 바로 옵셔널입니다. 왜일까요? 몇 가지 이유가 있습니다. * 오브젝티브-C에 이미 옵셔널 변수가 있다는 오해. * 옵셔널 변수가 있기 때문에 논-옵셔널(non-optional) 변수도 있어야 한다는 생각. * nil 키워드의 아주 미묘한 재정의. * 스위프트 코드에는 물음표가 하도 많아서 배트맨에게 온갖 수수께끼를 내며 괴롭히는 악당 리들러가 코딩하는 중인가 싶을 정도입니다. 어떤 이유에서건, 옵셔널은 애플 프레임워크의 중요한 일부이고 절대로 옵션이 아닌 필수기능입니다.
어떤 프로그래밍 언어를 쓰든 간에 함수는 꼭 필요합니다. 스위프트는 오브젝티브-C보다 함수의 기능이 훨씬 개선되었습니다. 독립적으로 쓰일 수도 있고 클래스에 속한 메소드나 구성체 또는 열거형에도 쓰일 수 있습니다. 함수 안에 또 다른 함수(중첩 함수)를 생성할 수 있고, 함수를 파라미터로 다른 함수에 전달할 수 있으며, 반환 값으로 다른 함수에서 반환할 수도 있습니다. 함수의 기능이 이렇게 확대되다보니 스위프트에서는 함수도 일급 객체(first class citizen)라 할 만합니다.
오브젝티브-C에서 함수와 메소드는 성격이 매우 다릅니다. 함수가 전형적인 C 언어의 성향을 띤다면 메소드는 전적으로 오브젝티브-C의 성질을 띱니다. 함수와 메소드는 문법도 다르고 수행하는 기능도 달랐죠. 하지만 스위프트에서는 이 둘의 차이가 많이 줄어들었습니다. 이제 메소드는 객체 타입에 속하는 함수라고 할 수 있습니다. 이 책에서는 함수가 단독으로 사용될 때와 객체 타입에 속해서 사용될 때 모두 특별한 언급이 없는 한 함수라는 단어를 사용합니다. 스위프트에서는 구조체와 열거형의 영향력이 막강해졌으므로, 클래스, 구조체, 열거형을 ‘객체’라는 용어로 통일합니다. 인스턴스라는 용어도 클래스, 구조체, 열거형 중 하나를 의미합니다. 필요할 경우에는 객체 타입을 ‘클래스 객체’, ‘구조체 인스턴스’와 같이 구별하여 사용합니다.
블록은 iOS와 macOS 개발에서 상대적으로 새로운 개념입니다 애플이 오브젝티브-C에서 블록을 제공하기는 하지만 사실상 C 언어에 있던 기능을 개선한 것입니다. 하지만 블록을 구현하는 문법은 헷갈리고 외우기도 어렵고 직관적이지도 않습니다. 블록 코드 유형을 몇 가지 보여주는 Gosh Darn Block Syntax (http://goshdarnblocksyntax.com)와 같은 사이트가 만들어진 것을 봐도 블록을 사용하기가 꽤 어렵다는 것을 알 수 있습니다. 그럼에도 블록은 프로그래밍의 일부이며 API 곳곳에서 사용되고 있습니다. 애플은 블록 구문을 개선하고 많은 패턴에서 사용하는 구문을 단순화하여 기능을 최적화하려고 오랜 기간 노력했습니다. 또 블록의 이름을 좀 더 세련된 이름인 클로저(closure)로 바꿨습니다. 클로저라는 이름은 다른 언어들에 있는 같은 이름의 기능들과 좀 더 공통점이 많기 때문에 블록을 다루면서 헷갈릴 가능성이 적어졌지요.
문자열(String)은 어떤 프로그래밍 언어에서도 핵심 요소입니다. 다른 프로그래밍 언어 대부분이 고유의 문자열을 만족스럽게 발전시켜 지원하고 있는 반면, 의외로 오브젝티브-C는 애플의 파운데이션 라이브러리에 의존해 C 언어의 저급한 문자열 함수에서 약간 발전시킨 기능들을 제공하는 수준에 머무르고 있습니다. 스위프트의 강력한 고유 문자열 타입(이름까지 편리하게도 String이죠)은 NSString과 함께 쓸 수 있도록 설계되었습니다. NSString이 AppKit과 UIKit 프레임워크에 임베드될 수 있다는 점을 생각하면, NSString을 사용할만한 자리에 String을 쓸 수 있다는 사실(그 반대의 경우도 가능하죠)에 어느 정도 안도감이 듭니다. 스위프트에서 문자열은 구조체로 구현되고, 기본적으로 Character 값의 집합으로 이루어집니다. Char의 크기가 1바이트인 오브젝티브-C와 달리 스위프트의 Character는 유니코드 문자이며, String 타입이 자체적으로 유니코드를 처리합니다.
스위프트는 오브젝티브-C와 마찬가지로 객체 지향 프로그래밍언어입니다. 스위프트의 핵심 객체인 클래스에서는 객체 지향 언어의 특징인 상속(inheritance), 다형성(polymorphism), 캡슐화(encapsulation)가 모두 제공됩니다.
“이봐요, 클래스! 이제 객체 타입이 댁들의 독무대가 아닙니다.” 스위프트에선 구조체와 열거형도 함수를 데이터와 연결하는 능력을 갖추게 되었거든요. 구조체와 열거형은 단순한 데이터 타입에서 복합적 객체 타입으로 새롭게 변신했고, 그래서 한편으로는 명확하게 구분되던 둘 사이의 특징이 꽤 모호해진 면도 있습니다.
아마도 지난 몇 년 간 오브젝티브-C 개발자들이 힘겨워한 것이 메모리 관리일 것입니다. 초기 메모리 관리에는 수동 참조 계수(manual reference counting)가 쓰였습니다. 객체 참조를 유지하고 작업이 끝났을 때 참조를 해제하라는 의도를 사용자가 밝혀야 했습니다. 한동안 애플이 OS X 개발 중에 형편없는 콜렉션에 손을 대긴 했지만 참조 계수는 iOS에서 유일한 메모리 관리 수단으로, OS X에서 인기도 좋았습니다. 그러다 오브젝티브-C에 자동 참조 계수(ARC)가 나타났습니다. 기본 프로세스는 같지만 언제 어디서 객체를 유지하고 해제할 것이냐를 정하는 힘든 작업을 사용자가 아닌 컴파일러가 주로 수행합니다.
오브젝티브-C와 스위프트의 콜렉션 기능을 다짜고짜 비교부터 해보자고 드는 것은 좋은 생각이 아닙니다. NSArray나 NSDictionary와 같은 콜렉션은 워낙 잘 알려져 있고 자주 사용되어 오브젝티브-C의 대표적 기능으로 꼽지만, 실제로는 파운데이션 프레임워크의 일부이고 언어 대 언어로 직접적 비교를 할 수 있는 대상은 오로지 C 언어 고유의 배열뿐이니까요. 하지만 파운데이션 콜렉션이 iOS와 macOS의 개발에 널리 사용된다는 점에서 보면, 콜렉션의 사용법 차원에서 스위프트의 콜렉션과 비교해보는 일은 의미가 있습니다. 스위프트에는 두 가지 콜렉션 타입(배열과 딕셔너리)이 있는데, 스위프트의 문자열처럼 이 둘도 변수보다는 상수로 선언함으로써 불변으로 만들 수 있습니다. 스위프트의 콜렉션은 Foundation의 콜렉션들과 상응합니다. Dictionary는 NSDictionary 또는 NSMutableDictionary와, Array는 NSArray 또는 NSMutableArray와, Set은 NSSet 또는 NSMutableSet과 상응하죠.
프로토콜은 오브젝티브-C 개발자에게 아주 익숙한 단어입니다. 프로토콜은 클래스가 따를 동작을 정의(속성이나 메소드의 형태로)할 목적으로 애플의 프레임워크에서 제공하는 개념입니다. 현재 클래스에 추가적인 기능을 제공하기 위해 사용되는 익스텐션은 어쩌면 새롭게 느껴질지도 모르지만, 오브젝티브-C에서 카테고리로서 이미 존재하는 개념입니다. 스위프트의 프로토콜과 익스텐션은 클래스와 더불어 구조체와 열거형에도 사용될 수 있다는 점에서 오브젝티브-C와 다릅니다. ‘제네릭’은 스위프트에서 도입된 완전히 새로운 기술입니다. 제네릭의 목적은 함수나 타입이 컴파일 시점에 특정 자료형으로 지정되지 않아도 될 수 있도록 하는 것입니다. 이렇게 되면 함수나 타입을 좀 더 넓은 범위의 타입으로 쓸 수 있고, 이는 사실상 포괄적(generic)인 것이 됩니다. 스위프트의 배열과 딕셔너리는 강력한 타입화를 위해 제네릭에 의존합니다. 만약 제네릭이 없다면 스위프트 개발자들은 생성할 모든 타입을 예측하기 위해서뿐만 아니라 가능한 모든 타입 조합을 처리하기 위해 변형 배열 타입과 변형 딕셔너리 타입을 생성해야 합니다.
애플이 아무리 노력했다고 해도, 처음 몇 차례의 버전에서 스위프트가 오브젝티브-C의 모든 특징들을 결코 완전히 대체하지는 못했을 것입니다. 반대로 말하면, 구문만 새롭고 오브젝티브-C의 특징을 단순히 모방한 것에 그쳤다면, 스위프트는 결코 진정한 최신 언어로 비춰질 수 없었을 것입니다.
macOS와 iOS 개발의 미래는 분명 스위프트에 달려 있습니다. 스위프트가 질풍노도의 시기를 겪고 있는 새로운 언어라는 사실, 그리고 코코아 개발이 여전히 오브젝티브-C와도 밀접하게 연관되어 있다는 사실을 감안하면, 상호 운용이 어느 정도 가능하다는 보증 없이 스위프트로 완전히 옮겨와도 괜찮다고 개발자들에게 확신을 심어주는 것은 결코 쉬운 일이 아닐 것입니다. 다행히도, 두 언어를 통합하는 정도는 개별 개발자나 개발 조직에 알맞게 조정될 수 있습니다. 현재의 오브젝티브-C 프로젝트에 스위프트의 클래스를 선별적으로 도입하거나, 스위프트 기반의 프레임워크를 통째로 포함시킬 수도 있습니다. 시작은 소규모로 했다가도 시간이 지나서 엄청난 수의 스위프트 코드를 도입하는 것입니다. 반대로 말하면, 새 프로젝트를 스위프트로 시작하고 싶은 경우에도 현재의 오브젝티브-C 코드를 개별 클래스나 프레임워크(서드파티나 여러분만의)의 형태로 가져와서 함께 사용하는 등, 많은 선택지가 있습니다.
![2026 최신판 원큐패스 ISMS-P 기본서 인증심사원 자격검정 [핵심이론+실전문제] 이미지](https://image.imilkbook.com/HanBook/Simg/cover/119/392997119.jpg)
