Objective-C는 그자체로는 메소드 호출을 C함수 호출로 변경해주는 objc_msgSend 함수를 동작하게 해주는 런타임에 의존하는, 따라서 실질적으로는 C언어와 크게 다를 것 없는 언어였다. 처음부터 C에 객체지향 개념을 더해서 확장을 만들어보는 실험의 결과물이었던 관계로 언어자체의 새로운 기능은 매우 부족했고, 이후 NeXT에 의해서 Foundation 프레임워크가 만들어졌는데, 사실 Objective-C 언어의 기능이라 여겨지는 많은 것들은 사실 Foundation 프레임워크가 제공하는 기능이라고 봐도 무방할 것이다. NeXT는 이 프레임워크를 통해서 모든 객체 클래스의 원형이되는 NSObject 클래스와 기본적인 자료형인 여러 클래스들을 디자인하였다.
Objective-C의 명분은 C를 기반으로 객체지향을 가능케하는 언어를 만드는 것이었지만, 이는 완전히 새로운 언어가 아닌 기존 언어에 약간의 확장을 덧붙인 개념으로 구현되었다. NeXT가 시작하는 시점에, 이들은 객체지향언어를 개발플랫폼의 중심으로 삼고 싶었지만, 이 시기에는 이러한 개념이 널리 통용되고 있지 않았으며, 제한적인 언어들만이 이 개념을 구현에 옮기고 있었다. 따라서 당시로서는 Objective-C는 나쁘지 않은 선택이었다. Objective-C는 객체지향적인 기능을 사용하면서도 동시에 기존의 C 코드들을 그대로 사용할 수 있었다.
하지만 이 언어가 널리 쓰이지 못한 것이 일종의 함정이 되었다. Objective-C를 사용하여 개발을 하고 싶은 사람은 어쨌거나 NeXT의 방식을 사용하여 접근하는 수 밖에 없었고 (언어의 대부분의 기능이 NeXT가 만든 프레임워크에 기초하고 있었다.) 또한 코코아의 일부 패턴들은 (delegate 같은) Objective-C의 언어적 기능을 기반으로 하고 있었다. 어쨌거나 이 언어를 사용하는 것은 결국 애플 플랫폼이라는 틈새 시장외의 시장을 바라볼 수 없다는 제약으로 작용했고, 이는 언어자체의 확산에 큰 걸림돌이 되었다.
그렇거나 말거나 애플의 입장에서는 거의 독자적으로 사용하는 언어가 되다보니 자신들의 개발환경과 플랫폼 자체를 완전히 장악하는 효과를 보게되었다. 한편으로는 LLVM과 같은 차세대 컴파일러에 공격적으로 투자하여 Objective-C 언어 자체의 기능성을 보완해나갈 수 있는 기반도 이루었다.
그러던 중 아이폰SDK를 발표하게되고, 이 플랫폼은 당연하게도 전적으로 Objective-C를 사용하도록 되어 있었다. 플랫폼의 인기가 치솟으면서 덩달아서 Objective-C를 사용하는 개발자들이 늘어났다. 하지만 대부분의 Objective-C를 사용하는 많은 개발자들은 이전에는 다른 언어를 사용하던 사람들이었고, 언어자체에 대한 불만이 많을 수 밖에 없었다. 애플 입장에서도 이전까지 Objective-C를 잘 이끌어나갔고, Stored Property, ARC, Literals와 같은 고급 편의 기능들을 착실히 전개해 나갔지만, 기본적으로 이 언어가 C를 기반으로 하고 있다는 점은 변하지 않았다. 이것은 단점인 동시에 장점이기도 했지만, 시간이 지날 수록 그 ‘장점’이 점점 퇴색되는 분위기에 이른다.
Objective-C의 메시징은 결국 인스턴스, 클래스 그리고 그 부모 클래스의 디스패치 테이블을 뒤져서 올바른 C함수 포인터를 구해서 호출하는 방식이라 메시지 호출 자체가 상당히 큰 비용이 드는 작업일 수 밖에 없다. 그리고 이런 성능적 단점을 보완하기 위해서 C 코드를 사용하는 것은 결국 포인터를 다루는 작업이기 때문에 crash 문제에 민감할 수 밖에 없게 된다.
애플 외부의 커뮤니티에서는 꽤 오래전부터 애플이 너무 나이든 언어에 집착하고 있다는 지적이 있어왔다. 분명 애플은 Objective-C 2.0을 선보이면서 많은 기능들을 언어에 추가했지만, 근본적인 한계에 대해서는 어찌할 수 없었다. 따라서 다른 언어나 새로운 언어로의 이전이 필요하다는 지적은 상당히 많았다. 다행스럽게도 애플은 이미 성공적으로 자신들의 개발 플랫폼을 GCC 기반에서 LLVM으로 이행하는 데 성공하였으며, 언어 개발에 대한 적지 않은 경험도 가지고 있다. (Objective-C 2.0의 리터럴이나 ARC 등) 런타임과 컴파일러에 대한 제어권을 장악한 상태에서 이 둘을 활용하는 새로운 언어를 만들어낸다는 것은 대부분의 개발자들에게 상당히 원활한 이행을 요구할 수 있다는 의미가 되기도 했다.
어쨌든 애플이 내놓은 swift는 기본적으로는 Objective-C를 기반으로 언어의 기능을 확장하는데 포커스를 맞추었다 하겠다. (프로토콜이나 익스텐션을 중점적으로 소개하고 있다.) 그외에 스크립트 언어들로부터 간결한 문법을 받아들였으며 하스켈로부터 강한타입, 타입추론과 신규 타입을 자유롭게 정의할 수 있는 유연성을 이식해왔다. 따라서 간결한 문법을 기반으로 이전의 Objective-C + Cocoa에서 지향했던 의미가 명확한 네이밍 규칙에도 일정수준 근접할 수 있다. (실제로 많이 간결해지기는 했지만 swift의 코드는 Cocoa 문법으로 거의 그대로 트랜스코딩 될 수 있을 것처럼 생겼다.)
일부 옛스럽고 C에서 비롯된 듯한 부자연스러워 보이는 문법(inout 형식의 파라미터에 대해서 C스타일로 &를 붙여서 함수를 호출하는 등)이 잔재해있고, 함수형 언어에서 배열(리스트)를 간결하게 다루는 comprehension 구문이 정착되지 않은 것은 아쉬운 부분이지만, 현재도 swift 자체는 베타버전이므로 이 부분에 대해서는 점차 개선될 여지가 많아보인다. 또한 기존의 Objective-C 코드에 대해서도 import 과정을 거쳐 swift로 트랜스코딩하고 이를 swift 문법으로 그대로 사용할 수 있도록 한 점 또한 매우 높이 평가할 수 있다.
구글의 Go, 모질라의 Rust 를 비롯하여 많은 테크회사들이 자신들의 언어를 내놓고 있을 때, 애플은 정말로 적절한 전략으로 자신들의 언어를 훌륭하게 디자인해 내었다. 언어와 프레임워크가 서로를 의존하는 기존의 플랫폼으로부터 자연스럽게 이행할 수 있는 호환 전략과 기존 Objective-C 개발자들이 환영할만한 새로운 기능들의 접목은 매우 훌륭하다 평가할 수 있고, 이를 “공표”하는 수준이 아닌 베타 단계에서 깜짝 발표한 전략도 멋졌다.
환우령님의 지적에 따라 오타를 수정하였습니다. 저는 Lust라고 철썩같이 믿고 있었나봅니다.