Time for swift cover

Swift의 시대가 왔습니다. 내 앱을 당장 새로 짜야할까요?

iTunes의 Top100 앱중에서 Swift를 사용하는 앱은 아직 11개밖에 안된다는 것을 아시나요? Swift가 대세라는 것은 의심에 여지가 없습니다. 하지만 Swift로 넘어가면 당장 어떤 점이 잘못될 수 있을까요? 위험 요소와 도입 시점, 팀의 변동 등의 요소를 어떻게 판단하면 좋을까요? Ben Sandofsky가 Swift 도입에 따르는 위험과 보상 요소를 설명하고 Swift의 시대가 왔는지에 대한 의문에 답합니다.


작은 회사에 근무하는 분이라면 제 대답은 ‘빠르게 전환하라’ 입니다. 제 조언에는 부합하지 않는 상황인 분도 있겠지만 언젠가는 그렇게 되길 바랍니다..

기존 사례 (00:32)

오늘 저는 코드를 빠르고 안전하게 바꾸는 Apple의 새로운 런타임과 개발자 계기, Swift에 대해 말하고자 합니다.

1998년 Steve Jobs의 연설에서는 OS X가 런타임을 위한 최상의 플랫폼이 될지에 대해 소개했습니다. Java 애플리케이션 실행을 가장 빠르게 하리라 장담했죠.

2008년에는 Cocoa 개발의 미래로 MacRuby가 소개됐습니다. LLVM 기반으로 균일한 런타임에 Cocoa 개발의 새로운 best practice를 제공했습니다.

자, 이제 Swift의 시대가 왔을까요?

Swift의 시대가 왔을까? (01:04)

Swift 사용자는 빠르게 늘고있고 확실하게 대세를 향해 가고있습니다. 프로그래밍 언어 사용량을 보여주는 TIOBE Index of popularity에 따르면 Swift는 Objective‑C를 넘어섰습니다. 흥미롭게도 두 순위 사이에 Pascal이 있죠. 한편 Ryan Olsen의 블로그에 따르면 앱 스토어의 다운로드 100위 앱을 분석한 결과 Swift로 실행되는 앱은 11%입니다.

왜 이 주제를 발표하게 되었나 (02:54)

작년 7월, 대기업의 어떤 기획자들이 당장 Swift로 넘어가기 보다는 일단 상황을 지켜보고자 했습니다. 당황스러운 상황이라서 즉흥적으로 트윗했죠. “지금부터 쓰는 모든 Objective-C 코드는 Swift세상이 되면 기술적 부채가 될 것이다.”

이런 개발 뉴스를 더 만나보세요

3개월 후 제 의도와는 다르게 제 트윗을 인용한 글이 나타났습니다. 인터넷에 좌우되지 마세요. 트위터는 기술적인 토론을 하기에 좋은 공간이 아닙니다. 위 트윗에 대한 오해를 여기에서 해소하고자 합니다.

최상의 시나리오 (03:35)

코드가 마법처럼 자동으로 쓰이는 신기술이 최상의 시나리오겠죠. 그러나 그 누구도 특정 언어가 다른 언어보다 생산적이라고 측정할 수 없었습니다. previous paper에서는 C, C++, Perl, Python, Rex, Tcl 등 80개의 언어로 같은 프로그램을 구현했는데, 스크립트 언어로 구현하면 구현 속도는 빠를 수 있지만, Java, C++, C 등의 언어로 구현하는 것이 효율성이 높고 메모리 사용량이 적습니다.

물론 Swift 의 수많은 장점들이 있습니다. 새로운 디버거, 패키지매니저, 최신 프로그래밍언어의 개념들 도입 등등. 그것들을 하나하나 여기서 설명하기 보다는 포인트만 보려고 합니다.

중요한 것은 syntax가 아닌 트레이드오프 (04:48)

중요한 것은 syntax가 아닙니다. Python, Ruby, Perl은 아마 생산성이 비슷할 겁니다. 생산성에서 중요한 변화를 가져오는 것은 선택한 언어의 트레이드오프입니다. 예를들어 만약 가비지 컬렉팅이 되는 언어라면 메모리 관리에 덜 신경 써도 되겠죠.

Swift의 디자인 트레이드오프는 Objectice-C와 같습니다. GC대신 참조 카운팅을 고려해야 하고, UIKit도 사용해야 합니다. syntax가 변화했지만 앱의 전반적인 복잡도는 거의 동일합니다. Swift는 아마 아주 조금 더 생산적일 겁니다.

X 회사가 XX 앱을 YY 언어로 새로짰는데 정말 좋았대! 라는 글을 접해 봤을 겁니다. 중요한 점은 그 회사가 기존 앱을 새로 짠 것이라는 점이죠. 추후 어떤 앱을 다시 본다면 비즈니스 요구사항을 이미 알고 있을 테고 더 나은 앱을 만들 수 있을 겁니다. Lyft의 개발자는 블로그에서 새로 다시 짠다면 다른 아마 더 나은/다른 앱을 만들 수 있었을 것이라고 했습니다.

요약하자면 앱을 새언어로 다시 코딩하는 것과 새 언어를 선택하는 것은 별개입니다. 기존 앱과 똑같은 앱을 새 언어로 다시 만드는 것은 힘든 작업입니다. 하지만 여전히 언어 교체에 따르는 장점은 있습니다.

Swift는 버그를 줄여줍니다 (07:26)

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
    goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

Objective‑C의 결함은 C의 결함에서 비롯됩니다. 만약 default로 떨어지는 switch 문처럼 몇몇 트릭을 알고 있다면 이를 우회할 수도 있습니다. 그러나 Apple은 C를 향상해서 더 안전하게 만들지는 못했기 때문에 C로 역행해서 호환성을 유지해야 합니다.

@implementation NSString (Helper)
- (BOOL)containsString:(NSString *) string {
    NSRange range = [self rangeOfString:string options:NSCaseInsensitiveSearch];
    return range.location != NSNotFound;
}
@end

NSString의 카테고리인 containsString가 있는데 iOS 8에서 Foundation 내에 containsString: 라는 메서드를 추가했습니다. 차이점은 Foundation의 메서드는 대소문자를 구분하는 반면 위 예제의 경우는 그렇지 않다는 점입니다. Objective‑C는 언제나 카테고리 앞에 회사 이름을 접두사로 붙이도록 하는데, Swift는 namespace를 사용합니다. 일반적으로 Swift를 사용하면 코드 작성이 간단하고 안전해지며 버그가 줄어들고 빨라집니다. Objective-C에서 Swift로 단순히 포팅하는 경우에도 그렇습니다.

Swift로 이전하는데에 대한 단점은? (10:14)

Swift로 이전하면서 생길수 있는 단점들이 뭐가 있을까요?

1. Swift 번들링으로 인한 용량 증가 (10:21)

bitcode로 컴파일된 버전이 아닌 실제 최종 바이너리를 벤치마킹해야 합니다. 체크 박스를 잘 확인하세요.

Thin version의 경우 Objective‑C의 Hello World 앱은 72k지만 Swift는 3.1mb입니다. full version인 경우 92k 대 4.6mb이죠. 그러나 45mb 앱을 만든다고 가정할 때 몇 mb가 증가하는 정도는 중요한 문제가 아닐 수 있습니다. 하지만 신생 시장의 높은 다운로드 비용를 염두에 두면 쉽게 무시할 수는 없습니다. 이 문제는 Swift 3.0에서 개선될 것이라고 하니 기다려 볼 수 있을것 같습니다.

2. 새로운 패러다임 = 적은 지원 (11:52)

새로운 패러다임이 등장하면 지원은 적을 수밖에 없습니다. 클래스를 사용하지 않고 struct를 사용하는 점은 새롭죠. NSCoding 프로토콜을 사용하면서 non-class type 'Post' cannot conform to class protocol 'NSCoding' 라는 에러에 맞닥뜨릴 수도 있습니다. Swift를 사용하기로 했다면 struct의 세계가 완벽하게 완성될 때까지 조금은 느긋하게 기다리는 마음이 필요하며, 여차하면 기존 체계로 돌아가야 할 수도 있다는 점을 고려하세요.

3. 새로운 런타임 = 새로운 버그 (13:18)

Mike Ash는 Swift로 개발하다가 weak 레퍼런스 관련 버그를 발견했습니다. weak 레퍼런스의 경쟁 조건(race condition)으로 인해 앱에서 원인 불명의 크래시가 날 수도 있습니다. 또한 내부 데이터 빌드에 무언가를 넣었을 때 디버그 빌드와 릴리즈 빌드가 서로 달라 실행 시에 크래시가 난 경우도 있습니다.

4. Swift의 빠른 변화 (14:23)

언어의 발전 측면에서는 좋은 일이지만 코드 변동이 생깁니다. Khan Academy 앱은 3만 라인 정도인데 Swift 2의 새 syntax에 맞추기 위해 일주일 정도를 소요했습니다. 같은 시간을 사용자에게 필요한 기능을 넣는데 쓸 수도 있었을 겁니다.

Tyler Fox에 따르면 Swift 3.0에서는 다시한번 많은 문법적 변화가 있을 예정입니다. Swift에 변화 속도를 생각하면 Swift syntax로의 포팅과 역행 테스트를 위해 적어도 이주일은 잡아야 합니다.

코드 변동에 따른 의존성 증대 (15:17)

Xcode를 사용 언어의 버전으로 번들링하는데 따르는 부작용으로 의존성 지옥에 빠지게 됩니다. Dropbox가 2.0 SDK를 Swift로 교체하면서 개발자들은 Xcode의 최신 버전밖에 사용할 수 없게 됐습니다. 작년에 저는 실리콘 밸리라는 TV 프로그램의 기술 자문을 하면서 Swift 1.2를 포함한 작은 앱을 만들었는데 그 앱은 Xcode의 그 버전에 종속됐죠. 단순히 1.2 버전을 2.0으로 교체하는 데만 일주일이 걸렸습니다.

Migration 협업 비용 (17:07)

Facebook이나 Twitter 같은 대기업에서 일한다면 팀 간 업무가 독립적일 겁니다. 같은 회사 내의 모든 독립적인 부서들과 협업해야 하죠. 혹은 한 팀은 기본 프레임워크와 네트워킹 스택을 담당하고 다른 팀은 사용자가 사용하는 기능을 담당하는 것처럼 메인 앱을 관리하는 두 개의 독립적인 팀이 있을 수도 있습니다.

결론 (17:56)

만약 작은 팀 소속으로 협업 비용이 낮다면 코드 migration에 이 주일을 소모하거나 출시 직전 버그를 발견하는 것을 두려워하지 말고 Swift로 교체하세요. Objective‑C에 이미 능통하거나 종속적이거나 시간이 없는 경우에는 Swift 3.0 출시를 기다리세요.

Swift 3.0은 ABI 안정성에 초점을 맞춰서 다양한 버전의 Swift 라이브러리를 만들 수 있으며 앱 용량 절감에도 도움이 될 것으로 기대됩니다. 또한 Foundation과 UIKit 부문에서의 개선도 기대할 만합니다. 프레임워크 업데이트도 예상됩니다. 참가하는 전문가도 늘어나서 struct의 완성도도 높아지겠죠. NSNotificationCenter를 대체할 다른 패턴도 등장할 수 있습니다.

Q&A (20:00)

Q: Apple이 언제쯤 Objective-C를 완전히 대체할 계획일까요? 최근 몇몇 라이브러리를 보면 Objective-C 데이터 타입 대신 Swift 데이터 타입을 반환하고 있습니다. 언제쯤 완전한 대체가 일어날까요?

Ben: (사실 제가 Apple에서 일하는 것이 아니므로 임의로 말해도 괜찮겠죠.) Apple이 OS X Carbon의 Objective‑C API를 사랑한다는 인터뷰가 있습니다. 아무리 Apple이 개발자들에게 Objective-C로 그만 개발하라고 말해도 Objective-C를 계속 지원할 것이라고 봅니다. deprecated 표시는 뜨겠지만 삭제하진 않을 겁니다. Objective‑C 이상으로 말도 안 되는 API도 있으니까요. deprecating API 사용을 겁내실 필요는 없을 것 같습니다.

Q: Objective-C를 버리지 않으면 좋겠네요.

Ben: 비단 iOS에만 적용되는 문제는 아닙니다. Apple은 무언가를 한 번 개발하면 작동하므로 다시 손대지는 않는 성향이라고 들었습니다. OS X는 Carbon이 작동하므로 이를 trace 합니다. Objective‑C를 버리면 iOS가 가장 먼저 영향을 받겠죠. Apple은 하향 호환성을 몹시 중시하므로 저는 별로 걱정이 안됩니다.

Q: 새로 짜는 것 말고 Objective‑C 앱을 Swift로 한 번에 포팅하는 방법이 있나요?

Ben: 가장 아름답고 현명한 방법은 한 번에 한 파일씩 Swift로 재작업하는 것으로 생각합니다. 완벽히 작동되고 MVC를 완벽히 지킨 앱이라고 해도 해당 코드를 버리고 Swift로 migration 하는 작업을 시작하라고 할 겁니다. 특히 예전 코드로 돌아갈 수 있는 annotation을 버리라고요. Swift로 바꾸지 않을 대단한 이유가 없는 이상 재작업하는 것이 좋습니다.

Q: 새로운 앱을 개발한다면 바로 Swift로 작업할 건가요?

Ben: 혼자서만 작업한다면 당연히 Swift로 할 겁니다. 멋지게 만들어서 Swift 3.0이 나올 때 Facebook에 10억에 팔겠어요. SDK가 중요한 회사의 직원과 대화한 적이 있는데 모든 문젯거리가 사라지겠군요! 라는 반응이었습니다. 반면 회사에서 책임이 높아질수록 보수적이 되겠죠. 가능한 간단하고 모든 투자자들에게 문제없도록 하고 싶을 겁니다.

Q: notification center를 대체할 새 제품와 회사에 대한 아이디어를 말했는데 아마 제2의 Realm처럼 될 수 있겠네요..

Ben: 바로 그겁니다.

다음: Swift 시작부터 RxSwift까지 #2: UI를 보다 Swift스럽게 만들어 볼까요?

General link arrow white

컨텐츠에 대하여

이 컨텐츠는 저자의 허가 하에 이곳에서 공유합니다.

Ben Sandofsky

Ben Sandofsky builds apps, advises startups, and teaches with CodePath. He has shipped software for over a decade, from tiny startups to giant enterprise companies. He spent over four years at Twitter; among other projects, he was tech lead for Twitter for iPhone, iPad, and Mac. Last year he was a technical consultant for HBO’s Silicon Valley.

4 design patterns for a RESTless mobile integration »

close