추가 적립 안내

오브젝티브-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 코드를 개별 클래스나 프레임워크(서드파티나 여러분만의)의 형태로 가져와서 함께 사용하는 등, 많은 선택지가 있습니다.

_감수자의 말_ 오브젝티브-C 유저들에게 단비가 될 책
_머리말과 기본 소개

1장. 스위프트 프로젝트 만들기
스위프트 프로젝트 시작하기
기본적인 변화
_헤더 파일이여, 이젠 안녕!
_메인 함수가 사라지다
_세미콜론?
스위프트와 오브젝티브-C 함께 쓰기

2장. 플레이그라운드와 스위프트 REPL
스위프트 플레이그라운드
_플레이그라운드 둘러보기
_플레이그라운드에서 할 수 있는 일
_플레이그라운드 생성하기
스위프트 REPL
_REPL 사용법
_가능성
_한계

3장. 언어 기본 사항
데이터 타입
_기본 타입
_문자열
_함수
_블록
_튜플
_클래스, 구조체, 열거형
_콜렉션
변수 선언
_VAR와 LET
_가변성
_타입 추론
문법
_세미콜론
_@의 행방
_대괄호의 시대는 갔다
_제어 블록
_후기 전처리기 시대
_주석
연산자
_같은 것
_다른 것
_새로운 것
튜플
_튜플 생성과 사용
_튜플 재사용

4장. 제어 구조
전반적인 변경 사항
_소괄호는 선택 사항
_중괄호는 필수
_부울 조건부
반복문
_FOR-IN문
_WHILE문과 REPEAT-WHILE문
조건문
_IF문
_GUARD문
_SWITCH문
정수, 그 너머의 세계로!
_문자열
_열거형
_범위
_패턴 일치
_안전성

5장. 옵셔널
옵셔널이 왜 필요할까?
옵셔널 선언
옵셔널 사용하기
_추출
_옵셔널 바인딩
_암시적 추출
_옵셔널 체이닝
몇 가지 조심할 점
_NIL 병합 연산자
_추출이 필요 없는 경우

6장. 함수
함수 호출
함수 정의
_파라미터 명명
_디폴트 파라미터 값
_반환 값
_함수 파라미터 수정
_입출력 파라미터
_가변 개수 파라미터
함수 범위
_전역 범위
_메소드 범위
_중첩 함수
함수 사용
_함수 타입
_함수를 파라미터 값으로 사용
_함수를 반환 값으로 사용

7장. 블록과 클로저
클로저 정의
_정의 생성
_블록을 변수로 할당
_함수 파라미터로 받기
_타입 별칭 생성
_클로저 실행
클로저 최적화
_암시적 반환
_타입 추론
_단축 인자 이름들
_후행 클로저 구문
_연산자 함수
값 캡처링

8장. 문자열
문자열 구성
문자열 조작
_문자열 값 검토
_문자열 비교
_문자열 콘텐츠 수정
NSString과 상호작용하기
_부분 문자열
_변환
_경로 수정과 URL 메소드
_명시적 NSString 생성
유니코드

9장. 클래스
클래스 정의
메소드
속성
_저장 속성
_읽기전용 속성
_self 키워드에 대한 고찰
이니셜라이저
_이니셜라이저 생성
_편의 이니셜라이저와 지정 이니셜라이저 사용
_디이니셜라이징
상속
_메소드 재정의
_상위클래스 호출
접근 제어
_Private
_fileprivate
_Internal
_Public
_Open
서브스크립트 지정

10장. 구조체와 열거형
구조체
_구조체 정의
_구조체 수정
열거형
_열거형 생성
_열거형 사용
_관련 값
_메소드와 계산 속성
중첩 유형

11장. 메모리 관리
스위프트 메모리 관리
약한 참조와 미소유 참조를 사용하는 경우
클로저

12장. 콜렉션
전반적인 비교
배열
_배열 생성
_배열 콘텐츠 읽어오기
_배열 조작
딕셔너리
_딕셔너리 생성
_딕셔너리로부터 읽어오기
딕셔너리 조작
_객체 추가 및 교체
객체 삭제
가변성

13장. 프로토콜, 익스텐션, 제네릭
프로토콜
_프로토콜 생성
_프로토콜 요구 조건 만족
익스텐션
제네릭
_제네릭 함수
_제네릭 타입

14장. 서로 가지지 못한 것들
오브젝티브-C에서만 가능한 기능
_KVO
_리플렉션
_다이나믹 디스패치
스위프트에서 새롭게 선보이는 기능
_네임스페이스
_사용자 지정 연산자
_FILTER, MAP, REDUCE

15장. 오브젝티브-C와 상호작용하기
오브젝티브-C에 스위프트 도입하기
_스위프트 파일 추가하기
오브젝티브-C에서 스위프트 코드 이용하기
스위프트에서 오브젝티브-C 코드 이용하기
_오브젝티브-C 파일 추가
_문법 변화
_타입 변화
프레임워크