• 북마크
  • 추가메뉴
어디로 앱에서 쉽고 간편하게!
애플 중고 거래 전문 플랫폼
오늘 하루 보지 않기
KMUG 케이머그

컬럼

융통성 높은 애플의 새 언어, 스위프트

  • - 첨부파일 : swift_screenshot_2x.jpg (795.4K) - 다운로드
  • - 첨부파일 : whats_new_2014_2x.png (1.0M) - 다운로드

본문

융통성 높은 애플의 새 언어, 스위프트

INFINITE LOOP / THE APPLE ECOSYSTEM

A fast look at Swift, Apple’s new programming language

For better or worse, Apple's new language lets you do things your way.

by John Timmer - June 5 2014, 10:08pm KST

swift1-640x215.jpg

애플 외부인 중에 스위프트(Swift)가 나오리라는 사실을 아는 사람이 있었다면 그는 분명 어떠한 예측도 바깥으로 내보내지 않았을 것이다. 기대했을 법 한 발표로 채워졌던 기조연설 중(세부사항은 놀라웠다 하더라도 말이다), 애플은 스티브 잡스가 넥스트를 창업하자마자 사용해왔던 프로그래밍 언어인 오브젝티브-C의 현대적인 대체 언어를 만들어냈다고 발표했다.

스위프트는 "몇 년 후에나 나올" 스타일의 발표가 아니었다. 발표한 그 날 당장, 550-페이지에 달하는 스위프트 가이드가 아이북 스토어에 나타났다. 게다가 개발자들은 스위프트를 사용한 애플리케이션 개발을 할 수 있는 엑스코드 6 베타에 접근할 수 있었다. 스위프트와 잘 어울리게 돌아가려면 전체적으로 Cocoa 툴킷을 얻어야 할 필요가 있었지만, 그것도 곧바로 이뤄졌다.

아직 스위프트 코드를 전혀 만들어내지 못 했음에도 불구하고, 본지는 스위프트 가이드를 통독하고 애플이 제공한 샘플 코드를 검토해 봤다. 본 기사는 스위프트 자체에 대한 우리의 첫 번째 글이며, 애플이 이루고자 하는 목표가 무엇인지에 대한 아이디어도 몇 개 나눠 봤다.



Why were we using Objective-C?

넥스트를 창업했을 때, 오브젝트-지향 프로그래밍은 아직 널리 채택된 프로그래밍이 아니었으며, 구현한 언어도 거의 없었다. 따라서 당시 오브젝티브-C는 아마 좋은 선택이었을 것이며, C 코드의 유산과 프로그래밍 관습을 통합하면서 상단에 오브젝트-오리엔테이션 레이어를 덧붙일 수 있었다.

하지만 결국 오브젝티브-C 언어를 채택한 주요 기업은 오로지 넥스트 밖에 없었다. 장점은 물론 있다. 넥스트가 오브젝티브-C의 강점을 위주로 한 전체 개발 환경을 구축할 수 있었기 때문이다. 즉, 오브젝티브-C 언어로 개발한다면 누구나 결국 넥스트 방식을 사용할 수 밖에 없었다. 가령 오브젝티브-C의 수많은 "언어 기능"은 사실 언어의 기능이 전혀 아니다. 넥스트 기반의 클래스, NSObject가 구현한 기능들이다. 그리고 delegates와 같은 Cocoa의 디자인 패턴은 오브젝티브-C의 언어적 성격을 요구했는데, 이는 객체가 특정 메시지에 반응할 것인지 아닌지를 안전하게 결정내리는 데에 쓰였다.

오브젝티브-C를 채택한 주요 기업이 넥스트 밖에 없다 함은, 이 언어를 틈새 시장용 언어로 만들어 버리기도 했다. 애플이 오브젝티브-C를 인계 받았을 때, 맥 개발에 있어서 보다 전통적이었던 Carbon 라이브러리에 대해 오브젝티브-C는 곧바로 대안이 됐다.

그런데 오브젝티브-C 개발만을 허용한 아이폰 SDK의 대중화 덕분에 상황이 좀 바뀌었다. 갑자기 대단히 많은 이들이 오브젝티브-C를 사용하기 시작하고 그들 중 많은 수가 다른 프로그래밍 언어의 경력도 갖고 있는 이들이었다. 애플에게는 훌륭한 소식이지만, 부담스러운 소식이기도 했다. 언어로서 오브젝티브-C를 전적으로 좋아하기만 하지 않았기 때문이며, 그때부터 애플은 미래의 맥 개발이 오브젝티브-C 프레임웍인 Cocoa라 발표함으로써 문제를 더 심각하게 만들었다.



What's wrong with Objective-C?

오브젝티브-C는 애플을 대단히 잘 보좌했다. 런타임을 통제하고 스스로의 컴파일러를 작성함으로써 애플은 넥스트로부터 인계 받은 언어의 한계를 몇 가지 벗어나 프로퍼티나 가비지 컬렉터, 그리고 가비지 컬렉터의 대체품인 Automatic Reference Counting 등의 새로운 기능을 추가할 수 있었다.

하지만 바꿀 수 없는 부분이 있었다. 기본적으로 오브젝티브-C가 몇 가지 익스텐션을 갖춘 C이기 때문에, 오브젝티브-C는 본질적으로 객체가 점유하는 메모리 주소인 포인터라는 복잡한 객체를 C의 방식으로 계속 추적하고 있어야 했다. NSString의 인스턴스로부터 제일 복잡한 테이블뷰에 이르기까지 모든 것이 포인터를 사용해 넘어가거나 메시지로 전해졌다.

물론 대부분의 경우에는 문제가 안 됐다. 일반적으로 하는 일 모두가 포인터를 포함한다는 점을 상기 시키지 않고서도 복잡한 애플리케이션을 작성할 수 있기 때문이었다. 하지만 프로그램이 충돌을 일으키거나 보안 구멍을 여는 등, 메모리 상에서 잘못된 주소를 접근하려 한다거나 앱을 망쳐버릴 가능성도 있었다. C의 여러가지 다른 기능에도 마찬가지다. 개발자들은 코드를 주의 깊게 확인해야 한다. 그렇지 않으면 메모리 아무 곳에나 코드가 들어갈 수 있기 때문이다.

이런 문제점들 외에도 오브젝티브-C의 수명 문제도 있었다. 시간이 흐르면서 다른 언어들이 C와 같은 언어에 접목 시키기가 어려웠던 훌륭한 기능을 채택해왔다. 가령 "제너릭(generic)"이 있다. C에서 정수 연산과 부동 소수점 값으로 계산을 한다면, 각각 별도의 함수를 작성해야 하며, 부호가 없는(unsigned) 배장 정수와 배정밀도 부동 소수점 등의 함수도 마찬가지다. 제너릭이 있으면, 컴파일러가 수치(數値)로 인식하는 모든 것을 다루는 단일 함수를 작성할 수 있다.

오브젝티브-C의 문법에 그런 중요 기능을 애플이 물론 추가할 수 있다. 클로저(closure)가 그 사례이다. 그러나 원하는 모든 것을 추가할 수 있는지는 불분명하다. 게다가 C의 성격 자체가, 본질적으로 불안전할 수 밖에 없다. 엉성한 코더가 안정성과 보안을 대충 처리할 여지가 있기 때문이다. 변화가 있어야 했다.

하지만 애플은 기존의 다른 언어를 하나 골라서 채택하는 쉬운 길을 택하지 않았다. 왜일까? 오브젝티브-C와 Cocoa 프레임웍 간의 긴밀한 관계 때문이다. 오브젝티브-C는 프레임웍을 효율적으로 만들어 주는 디자인 패턴을 갖고 있다. 기존의 주류 언어 대다수는 Cocoa 프레임웍에서 요구하는 기능을 제공하지 않는다. 그래서 스위프트가 나왔다.

IMG_0036.jpg
The scene from WWDC this week.

몇 가지 이유가 있다. 개발을 LLVM로 이주하면서, 애플은 자신의 런타임과 툴체인(toolchain)을 통제할 수 있게 됐다. 즉, 변화 구현이 더 쉬워지고 그 결과도 완전히 이해할 수 있다는 의미다. 또한 애플은 프로퍼티나 Automatic Reference Counting, 클로저를 오브젝티브-C에 추가하는 등, 이미 언어 개발의 경험을 갖고 있었다.

그 과정에서 애플은 개발자들이 미래에 어떻게 반응할지에 대한 예상도 할 수 있었다. 애플이 가비지 컬렉션을 추가하고 개발자들에게 "굉장한 옵션"이라 알렸을 때, 개발자 반응은 복합적이었다. Automatic Reference Counting를 추가하여 "이것이 미래"라 했을 때는, 개발자들이 곧바로 훨씬 빠르게 합류했었다. (64-비트 Carbon을 죽이기로 한 결정은 개발자들이 운세를 점치도록 했을 것이 분명하다.)

이전의 변화는 모두 스위프트의 기능을 위한 길을 닦아 놓았다. 클로저와 Automatic Reference Counting 모두 들어 있다. 변수는 오브젝티브-C의 프로퍼티와 대단히 유사하게 다루며, 애플이 모든 것을 통제하기에 스위프트와 오브젝티브-C는 모두 동일한 런타임으로 지원할 수 있다. 즉, 새 언어와 옛 언어 코드를 같이 사용할 수 있다는 얘기다. 이 변화가 작업에 지장을 줄 정도는 아니다. 5년 전만 해도 아니었겠지만 말이다.

얼마나 오래 전부터 스위프트를 계획했는지는 결코 알 수 없을 테지만, 애플의 지난 5년 역사를 보면, 경험을 쌓고 조각을 맞춘 다음, 개발자 커뮤니티가 어느 정도나 받아들일지 가늠할지 알아 왔다는 사실을 알 수 있을 것이다.



Do you read me?

프로그래밍 언어를 하나 새로 작성하려면, 작성이 쉬운가와 읽기가 쉬운가의 균형을 맞춰야 한다. 스위프트 개발자 문건에서 제일 쉬운 사례를 하나 보여 드리겠다. 다음의 코드는 프로그래밍을 별로 알지 못 한다 하더라도 뭔지 아실 수 있을 것이다.

if thisIsTrue {
that = that + 50
} else {
that = that + 20
}

그러나 아래의 코드를 본다면 대부분 어리둥절해 할 것이다.

that = that + (thisIsTrue ? 50 : 20)

위의 두 코드의 결과는 정확히 같다. 다만 두 번째가 훨씬 더 작성이 빠르며, 첫 번째는 이해하기가 더 쉽다. 프로그래밍 언어 디자이너는 이러한 균형의 결정을 계속 해야 하며, 그 여파가 크다. 읽기가 쉽다면 초보자들이 코드 예제를 그만큼 더 이해하기 쉬워지며, 코멘트가 잘 없는 코드로 이뤄진 프로젝트라 할지라도 쉽게 작업할 수 있기 때문이다.

괄호에 대해 반감이 있지 않는 한, 오브젝티브-C는 읽기 면에 있어서 에러를 일으키는 경향을 갖는다. 두 문자열 사이의 텍스트를 끌어 당기는 함수가 있을 때, 프로그래밍 언어 대다수는 아래처럼 보이게 마련이다.

myString.getTextBetweenBrackets( leftBracket, rightBracket);

그렇지만 실제로 사용할 때, 변수의 이름을 아무렇게나 붙일 수 없다. 함수를 기억하지 않는 한, 괄호가 어떤 순서인지 알 수 없기 때문이다. 오브젝티브-C는 별도의 타이핑을 해야 하는 모호함을 없앴다. 그래서 동일한 코드는 아래와 같아진다.

[myString getTextBetweenLeftBracket: leftBracket andRightBracket: rightBracket];

어느 아규먼트가 무엇을 했는지에 대한 설명값은 아규먼트 수가 늘고, 변수 이름의 자기-설명적인 성격이 줄수록 늘어난다. 스위프트는 둘을 합친 것으로 보이지만 실질적으로는 아래와 같은 접근 방식이다.

myString.getBracketedText ( LeftBracket: leftBracket, rightBracket: rightBracket );

이런 중요한 방식으로 가독성을 유지하기에, 오브젝티브-C의 위 특징을 싫어한다면 스위프트도 똑같이 싫어할 것이다. (아니면 아마 가독성을 유지할 "수" 있다고 말해야 할 것이다. 스위프트에서는 메서드 서명을 괄호 안에 넣는 것을 생략할 수 있다. 애플은 별도의 텍스트 포함을 권장하지만, 신경 안 쓸 이들이 많으리라고 본다.)

수많은 다른 방식으로, 스위프트는 읽기가 다소 어려워졌다. 핵심 장소에서, 함수 호출망에 묻힌 느낌표라든가 물음표처럼 단일 문자의 출현은 코드의 행태를 완전히 바꿀 것이다. 또한 기본값 설정으로 아규먼트에 내부/외부 이름을 주는 등, 함수 정의로 훨씬 더 많은 일을 할 수 있다. 그렇지만 함수 정의는 그 이해를 위해 주의 깊게 읽어야 한다는 의미도 갖는다.

스위프트 가이드에서 가져 온 다른 예제를 보여 드리겠다. 태양계 행성을 정하는 예제다.

case Mercury = 1, Venus, Earth, Mars, Jupiter, Saturn, Uranus, Neptune

첫 번째 아이템에 인덱스를 추가하기만 하면 된다. 다른 것이 없다면 컴파일러는 1로부터 계속 늘어나리라 여기고 자동적으로 그렇게 처리한다. 훌륭하며 시간을 벌어주는 일이다. 그렇지만 토성이 태양계 6 번째 행성임을 기억하지 못 한다거나, 태양계 행성보다 더 복잡한 목록을 처리해야 한다면, 도대체 어떤 숫자를 이해해야 하는지 시간을 낭비할 수도 있다.

그렇다면 읽기와 타이핑의 대결에서 어떤 의미를 가질까? 스위프트로 더 많은 코드 예제를 읽지 않는 한 말하기 어렵다. 당장으로서 스위프트 코드 중 아주 많은 수가 따라잡기 어려웠다. 그러나 대부분은 사용에 따라 익숙해지리라 기대한다. 프로그래머 대부분은 스위프트의 상대적으로 압축된 문법을 좋아할 테지만, 스위프트의 융통성은 의도치 않게 완벽하게 작동할 코드를 낳아도 다른 스위프트 사용자들이 읽기 어려워 할 코드를 낼 수도 있음을 의미한다.



Language basics: lots of options

위에도 지적했지만 함수 호출로부터 개발자들은 메서드 서명 정보를 배제시켜 왔었다. 사실 스위프트의 수많은 사항이 옵션이다. 가령 세미콜론은 코드 줄 끝을 정의하는가? 그게 좋다면 그리 정할 수 있다. 그렇지 않으면 문장 끝이 어디인지 컴파일러가 알아서 판단하여 실행한다. 논리적인 값 정하기에서, 가령 if 조건식처럼 괄호가 쓰일까? 가독성에 도움이 된다면? 컴파일러가 굳이 보지 않아도 될 것이다.

즉 많은 부분이 선택 사항이며, 여러분의 재량에 따라 스위프트 코드를 작성할 수 있다. 다른 프로그래밍 언어와 구별하기 위해 상당히 주의 깊게 들여다 봐야 하리라는 의미다. 실제로 여러분은 다른 언어 사용자들을 혼란스럽게 만들어버릴 스위프트 코드를 작성할 수 있다.

언어가 문자열의 집합이 아니라 문자열이 근본적인 일부가 됐다는 점에서 스위프트는 자바와 유사한 면도 지닌다. 문자열과 수를 객체처럼 다루기 때문이다(그들도 프로퍼티를 갖는다). 부호가 없는 8-비트 정수인 UInt8에 안전하게 저장할 수 있는 최대값을 알고 싶다면, UInt8.max를 호출하면 된다. 이경우 최대값 이상의 값을 지정하려 한다면 런타임은 오도미터(odometer)와 같은 것으로 직접 지정하지 않는 이상 길이를 줄여서 최대값으로 맞출 것이다. 과학적 기수법(scientific notation)으로 부동 소수점 변수값을 지정할 수 있다는 점도 멋지다.

타입(type)으로 변수를 선언하거나 단순히 변수에 값을 지정하더라도 스위프트는 실제로 여러분이 원하는 타입이 무엇인지 이해해낸다. (즉, 5.7이라는 값을 어딘가 지정하면, 스위프트가 알아서 이 변수를 배정밀도 부동 소수점 변수로 만든다.) 스위프트는 또한 변하지 않을 듯한 값을 상수로 사용하도록 권유한다. "var" 대신 "let"을 사용하도록 한다는 의미다.

보통의 논리연산자와 수치연산자 -+는 문자열을 연결 시켜주기도 한다. 또한 고유의 연산자를 정의 내릴 수도 있으며, 애플은 객체 비교를 위한 새로운 연산자 두 개를 소개했다. 논리연산자 ==는 객체 두 개를 테스트할 때 쓰이며, 이들이 같은지를 판별한다. 따라서 배열을 할 때, 동일한 객체를 갖고 있는지를 확인해 준다. 메모리에서 동일한 장소에 지정이 됐는지를 알기 위해서는 ===를 사용한다. 연산자 범위는 0부터 50이며, 이 사이의 모든 정수값(0과 50도 포함)은 간단한 루프를 작성할 때 도움이 될 것이다.

if/else 선언처럼 for/do/while 루프 컬렉션도 존재한다. 다만 switch/statements에 큰 변화가 있었다. 프로그래밍 언어 대다수는 실행으로부터 여러가지 case statement를 직접적으로 유지해 놓아야 하는데, 이것이 에러의 공통 요인이다. 스위프트에서는 컴파일러에게 다음 case statement까지 가고 싶은지를 직접 알려 줘야 한다. 또한 다른 루프와 논리연산자에 레이블을 붙여서 "break myLabel"을 사용해 벗어나야 할 연산이 무엇인지 확실히 해 둘 수도 있다.

스위프트는 또한 같은 배열에서 문자열과 정수를 합칠 수 없다 하더라도, 어떤 수치와 문자값과도 연동하는 배열과 딕셔너리를 포함한다. 즉, .insert와 .count와 같은 함수로 저장해 놓은 값에 접근하고 조작할 수 있다는 얘기다.



Structs, enumerations, and objects

C는 오브젝티브-C처럼 객체 클래스같은 것을 제공하지 않고 관계 데이터와 메서드의 집합체인 스트럭트(struct)를 허용할 뿐이다.

스트럭트는 스위프트로 되돌아 왔으며, 클래스와 비슷하기는 하지만 상속과 deinitializer, 참조횟수계산(reference counting)이 없다. 복사하는 식으로 돌아가는데, 클래스의 경우 오브젝티브-C의 클래스와 매우 유사하게 돌아가지만, 참조(reference)로 돌아가기도 한다.

애플이 "1등급 타입"이라 부르는 enumerator의 역할이다. initializer를 갖고 정수값에만 국한되지 않는다. 위의 예제를 사용하여 행성을 지정할 수 있는데, 화성은 4, 혹은 "태양으로부터 4번째 행성" 값을 가질 수 있다는 얘기다. 사실 화성을 크기, 직경, 궤도주기, 궤도거리를 대표하는 4 수치의 컬렉션으로 지정할 수도 있다. 그러면 이 값들을 코드 어디에서건 회수할 수 있다.

기초적인 변수에도 경계가 흐릿해졌다. 배열과 딕셔너리는 NSArray와 NSDictionary 클래스로부터 동일한 메서드 대부분에 응답하는 것으로 보인다. 클래스와 스트럭트 등 주요 아이템 사이의 유사성은 객체-지향의 Cocoa와 보다 C와 유사한 접근에 의존하는 부분 사이에서의 조화롭지 않은 부분을 없애주는 데에 도움 된다.

애플은 언제나 개발자들에게 "setter"와 "getter" 메서드를 사용한 객체로 변수에 접근하기를 권장했었다. 스위프트는 이 권장을 아예 공식화 시켜서, 보통의 클래스 정의의 일부로 만들어 버렸다. 모든 클래스는 이제 "wild change"와 "did change" 메서드로 변수가 변화하더라도 의존값을 유지할 수 있게 됐다. 초기화(Initialization) 메서드는 특정 순서로 배열되기 때문에, 서브클래스는 상위 클래스의 initializer를 호출하여 스스로의 콘텐츠를 배열할 수 있게 됐다.

오브젝티브-C에서 돌아온 기능도 있다. 클래스가 특정 기능을 제공하도록 보장하는 역할로 스스로를 선언할 수 있는 프로토콜(protocol)이다. 따라서 "webPage" 프로토콜은 URL와 페이지 텍스트 등에 대한 접근을 보장할 수 있다. 즉, webPage 기능을 제공하고 필요한 부분을 정확하게 구현하도록 교환을 하는 클래스를 만들 수 있다.

Categories도 (더 강력하게, 그리고 이름도 바뀐 채) 돌아왔다. Categories는 기존 클래스에 기능 추가용으로 훌륭했다. 따라서 가령 NSString의 Category로서 위에 언급한 괄호로 묶은 텍스트 기능을 추가할 수 있으며, 앱에서 만들어내는 모든 NSString이 여기에 응답할 수 있을 것이다. Categories는 현재 익스텐션(extension)으로 이름이 바뀌었고, 새로운 initializer와 수정중인 새 변수를 추가할 수 있게 됐다. 부동 소수점 수치처럼 기초적인 언어 기능을 수정할 때 쓰일 수 있을 것이다.

다중값의 포장지로 움직이는 "터플(tuple)"이라는 특별한 타입도 있다. 함수가 아이템 하나만을 되돌릴 수 있을 때, 이 아이템이 터플일 경우 여러가지 다른 타입의 다중값의 조합을 둘러 쌀 수 있다. 터플에 접근할 수 있다면 각각 값에 변수를 지정하여 사용할 수 있다.



Closures, generics, and operator overloading

애플은 애플리케이션 안에서 머무르다 끝나는 코드 덩어리, 블록(block)을 소개했다. 블록은 보통, 사용자가 대화창에서 대화를 내보낼 때 코드를 실행해야 하는 경우에 유용하다. 대화를 다루는 곳에서(논리적으로 혹하는 곳이다) 블록용으로 코드를 유지할 수 있지만, 대화창으로 보낼 때, 버튼을 눌러야 실행된다. 한편 블록은 코드 가독성을 개선하는 데에도 유용하다. 따라서 놀랍지 않게도, 스위프트에서 블록은 되돌아 왔으며, 이번에는 보다 공식적인 이름, 클로저로 등장했다.

Screen-Shot-2014-06-04-at-7.27.21-PM.png
Apple's Swift guide is free in iBooks.

C에서 코드 블록을 다룰 수는 있다. 함수는 메모리 주소로 끝나며, 이 함수에 연결되는 포인터를 만들 수 있다. 스위프트는 특정 시그내처와 일치하는 모든 함수가 있는 변수 설정을 가능하게 해 주는, 매우 유사한 기능을 제공한다. 클로저로부터 꽤 논리적인 확장이랄 수 있으며, 실질적인 메모리 주소에서 돌아갈 위험도를 없애주기도 한다.

위에서 언급했듯, 스위프트는 여러 종류의 변수로 돌아가는 함수인 제너릭을 추가했다. 가령 어떤 종류의 숫자를 배열에 넣을지와 상관 없이, 배열에 있는 콘텐츠를 요약해주는 제너릭 함수를 만들어낼 수 있으며, 특정 프로토콜 입력을 제한 시키도록 설정함으로써, 제너릭이 돌아가는 객체의 종류도 제한 시킬 수 있다. 예를 들어서 스위프트의 모든 기본 변수 타입은 == 연산자에 대응하게 해 주는 Equatable 프로토콜을 구현한다.

어떠한 클래스도 Equatable 프로토콜을 구현한다는 점은 분명 매우 유용할 것이다. ==에도 대응해야 한다는 의미이기 때문이다. 그러기 위해서 스위프트는 프로그래머가 커스텀 클래스용 기본 연산자를 구현할 방법을 정의할 수 있도록 허용하는, 연산자 오버로딩(overloading)이라는 기능을 사용한다. 따라서 하드 드라이브를 나타내는 커스텀 클래스를 구현할 경우, ==를 오버로드하여 제조업체와 용량, 속도가 모두 같은지를 확인할 수 있다. 또한 +를 오버로드하여 단순히 두 개를 합친 새 드라이브를 제공할 수도 있을 것이다.



What's missing?

여러분이 선택한 언어의 기능 중 스위프트가 제공하지 않는 기능이 아주 많으리라 확신한다. 애플의 최신 노력이 시작부터 어그러질 수 있다면서 말이다. 뭣보다 눈에 띄는 부분이 에러 캐칭(error catching)이 완전히 없다는 점이다. 그렇다. 컴파일러는 현재 일반적인 에러를 잡아낼 정도로 상당히 영리해졌으며, nil 객체를 통해 수많은 실수를 피할 영리한 방법이 스위프트에 있기도 하다.

그러나 필자와 같은 이들은 어떻게든 언어와 컴파일러가 얼마나 뛰어났는지 상관 없이 문제를 일으킬 수 있다. 게다가 우리는 프로그램이 정지되는 광경을 보느니, 프로그래밍 망치기를 기꺼이 좋아하기도 한다.

물론 현재 버전은 베타이며, 애플은 분명 마음 속에 확장을 염두에 두고 디자인했을 것이다. 오브젝티브-C 기능 추가의 경험을 잊었을 리 없다. 즉, 개발자들이 요구할 경우(스위프트에 없는 다른 기능도 마찬가지다) 에러 캐칭이 퍼블릭베타에서 나타날 가능성이 없진 않을 터이다. 다행히도 오에스텐 위드(Weed)를 잘라냈던 것처럼 뭔가 위대한 것을 소개 받지 않는다면, 애플이 아무도 원하지 않는다고 하여 모두를 확신 시키려 하진 않을 것이다.

Screen-Shot-2014-06-04-at-4.30.30-PM-640x387.png
Enlarge / A screenshot of some Swift action.
Apple



Is it any good?

스위프트는 여러 모로 급속한 발진은 아니다. 애플은 특정 디자인 패턴을 좋아하며, 오브젝티브-C와 Cocoa가 특정 디자인 패턴을 따르도록 만들었었다. 프로퍼티처럼 무계획적으로 채택된 패턴을 공식화 시키는 것처럼 스위프트도 마찬가지이다. 스위프트가 추가한 기능 대부분은 이미 다른 프로그래밍 언어에도 존재하는 것이며, 개발자들에게 친숙할 것이다. 이 기능들은 일반적으로 좋은 기능들이며, pointer math처럼 없앤 기능은 어찌 됐든 피하는 편이 나았다.

그런 맥락에서 스위프트는 오브젝티브-C에 비해 멋지고 개선된 언어이다. 큰 변화는 모두가 다 기본적인 문법이다. 세미콜론과 괄호를 사용하든, 안 하든 상관이 없다. 함수 호출에서 메서드 시크내처를 포함했지만 그렇게 느낄 때만 포함했음을 알 수 있다. 여러 다른 예제로 볼 때 스위프트에서는 여러분이 편안하게 여기는 문법과 스타일을 고를 수 있다. 즉, 선택할 경우 타이핑을 최소한으로 줄일 수도 있을 것이다.

신기능 대부분은 다른 언어에도 쓰이지만, 문법 변화는 오브젝티브-C의 차별성을 대단히 많이 없앴으며, 대단히 다른 문법으로 동일한 코드를 작성할 수 있을 것이다. 따라서 다른 언어에 친숙한 매우 많은 이들에게 스위프트는 꽤 친숙해 보일 것이다. 전혀 C를 손댄 적이 없는 개발자들을 끌어들이기 위해 특히 중요하다. 이들은 여전히 애플 프레임웍의 디자인 패턴을 배워야 할 테지만, 적어도 같은 시간에 완전히 다른 언어로 씨름할 일은 없어질 것이다.

일반적으로는 긍정적이다. 애플이 단일한 스타일을 선택했다면 우리가 선호하지 않을 선택이 이뤄질 가능성이 컸다. 그러나 융통성 덕분에 우리는 우리가 원하는 방식에 가깝게 작업할 수 있게 됐다.

가깝게, 라고 말했다. 별로 선호하지 않는 특정 문법 기능이 몇 가지 있으며, 문자 하나가 코드 라인의 의미로 볼 때 급격한 변화를 일으킬 수도 있는 사례가 꽤 있다. 그렇다면 문법 변화 때문에, 대규모 프로젝트와 여러 개발사들이 오브젝티브-C로 작업할 때보다 더 어려워 할 수도 있는 일이다.



What's Apple up to?

초심자들에게는 분명하다. 스위프트는 수많은 일반 에러가 일어나기 더 어렵게 했으며, 나쁜 관행 여럿을 불가능하게 만들었다. 선택한다면 스위프트에서 간결하게 코딩할 수 있으며, 개발자들에게는 더 쉬울 것이다. 개발자들이 더 생산적일 수 있는 새롭고 멋진 기능이 추가 됐으며, 모두 좋아 보인다.

다만 보다 일반적으로, 필자 같은 이들은 애플에게 다소 짜증을 낼 수도 있다. 필자가 워낙 autorelease pool을 잘 사용해 왔기에, 필자의 앱은 메모리 노출을 하지 않으며, Automatic Reference Counting가 회수할 수 없을 순환참조로 끝나지 않도록 확실히 하기 위한 예측 불허의 문법을 배워야 할 이유를 모르겠다. 필자는 프로퍼티 접근을 위한 점표기법(dot notation)을 좋아하지 않기에, 피할 수 없을 때만 사용한다. 간단히 말해서, 필자는 시중을 드는 공룡이다.

필자와 같은 사람들 때문에 런타임 및 컴파일러 팀이 멋진 일을 할 수 없을 것이다. 모두가 동일한 기능을 사용한다면 옛날 기능 지원을 없애기 더 쉬울 테고, 모든 일을 최적화 시키기도 더 쉬울 터이다. 메모리를 더 적게 사용하고 성능이 더 나아짐은 컴퍼넌트 비용을 더 낮추고 배터리 수명도 더 늘어남을 의미한다. 애플에게는 대단히 좋을 소식이다.

애플은 스위프트로 더 나은 성능을 약속했으며, 어느 정도 개선이 일어날 수 있음은 여러분도 알 수 있다. 상수는 이제 스위프트의 일부가 됐으며, 합리적인 소식이다. 주가 추적 앱을 만든다면 가격이 매 초마다 바뀌어도 주식 이름과 기호는 거의 바뀌지 않기 때문에 스위프트로 완전히 새로운 객체를 만들기가 그만큼 더 쉬워졌다는 의미다. 안전-스레드 안에서만 바뀌도록 모든 코드를 지나치게 만드는 기호 상수와 이름을 선언하시라. 아마 컴파일러가 상수 사용의 최적화를 관리할 수 있을지도 모른다.

공룡과는 달리 우리들은 Chicxulub 운석이 떨어지고 있음을 알고 있다. 앞으로 2-3년 후, 애플이 미래가 스위프트에 있으며 우리 모두 오브젝티브-C를 버려야 한다고 발표한다 하더라도 놀라지 않을 것이다. 분노할 일도 아니다. 새 언어 사용법을 확실히 알도록 계속 준비를 해 온 후의 이야기이기 때문이다.


A fast look at Swift, Apple’s new programming language | Ars Technica

위민복님이 번역한 글입니다.
0 0
로그인 후 추천 또는 비추천하실 수 있습니다.
회원사진
포인트 765,229
가입일 :
2002-05-23 22:53:10
서명 :
KMUG 애플에 대한 모든 것. 케이머그
자기소개 :
2000년 3월 1일 부터 시작 http://www.kmug.co.kr webmaster@kmug.co.kr

최신글이 없습니다.

최신글이 없습니다.

댓글목록 1

존재와당위님의 댓글

Basic, C, 포트란등을 배운바 있지만 아직 획기적인 언어는 나온 것 같지 않아보입니다
PHP 도 쉽다고 하지만 일반인들에겐 어렵게 보입니다.

획기적인 것은 아마도 매우 쉬운 언어를  만들어 내거나 아무 쉽게 사용할 수 있는 프레임웍 만들어 내는 것입니다

전체 2,464 건 - 4 페이지
2016.07
06

팀 쿡 인터뷰 (Fortune, 2016년 3월)

By Adam Lashinsky Photograph by Joe Pugliese for Fortune 캘리포니아 쿠퍼티노의 애플 본사에서 있었던 2월 12일 인터뷰에서 CEO 팀 쿡은 애플의 상황에 대해 폭넓게 얘기해 주었다. 그는 9년 연속 …

2016.07
04

2013 뉴 맥프로 발열 이슈에 관한 번역

뉴 맥프로가 나오고 나서 전문직 종사자들은 열광하였습니다. 혁신적인 디자인과 무섭도록 놀라운 컴퓨팅 파워를 광고 했기 때문이죠. 하지만 얼마지나지 않아 점점 발열 (Overheating Issue)에 관해 문제가 올라오기 시작했습니다.…

2016.06
30

애플뮤직은 국내 음원 서비스와 무엇이 다른가 - Mastered for iTunes 에 대하여

아이튠즈 뮤직에서 앨범을 검색하다 보면 [Mastered for iTunes] 라는 마크가 표시가 되어 있는 앨범들을 볼 수 있습니다. (애플뮤직 또한 다운로드 섹션으로 이동하게 되면 저 마크가 있는 앨범들을 볼 수 있습니다.) Mas…

2016.06
30

나에게 맞는 맥프로의 선택, 6코어 vs 12코어 전격 비교테스트

작업들이 무거워지게 되면, 결국엔 맥프로를 구매, 고려하게 되는데요, 이때 여러가지 선택의 기로에 놓이게 됩니다. 가장 먼저 선택하게되는 CPU의 성능,,4코어,8코어,6코어,12코어 참 여러가지 입니다. 코어가 많으면 많을수록 좋겠거니, 당연히…

2016.06
27

여러분이 못들어 봤지만 애플에서 제일 중요한 임원 조니 스루지 Johny Srouji

여러분이 못들어 봤지만 애플에서 제일 중요한 임원 The Most Important Apple Executive You’ve Never Heard Of A visit with Cupertino’s chief chipmaker, Johny S…

2016.06
17

애플 vs. 미국 법무부

LAW & DISORDER / CIVILIZATION & DISCONTENTS How Apple will fight the DOJ in iPhone backdoor crypto case US government's position stands or…

2016.06
10

영화에 나오지 않는 스티브 잡스의 애플복귀 드라마

잡스의 애플 복귀, 영화에 나오지 않는 드라마 映画「スティーブ・ジョブズ」を観る前に知っておくと10倍楽しめる ジョブズ復帰とMac OS X、映画にないドラマ…

2016.06
03

트로이의 목마, 애플페이

트로이의 목마, 애플페이 How Apple’s Trojan horse will eat the credit card industry On Dec 21st 2015 - in Washington Post 지난해 신용카드 업계의 지원과 온갖 팡파…

2016.05
27

애플워치는 미래다

애플워치는 미래다 The New York TimesPERSONAL TECH | GADGETWISE With Taps on the Wrist, Apple Watch Points to the Future By MICHAEL D. SHEAR DEC…

2016.05
13

인간 운전자를 없애려는 경쟁

인간 운전자를 없애려는 경쟁 The High-Stakes Race to Rid the World of Human Drivers The competition is fierce, the key players are billionaires, bu…