어라 헤더가 없네?
가장 첫 인상은 헤더(Header) 같이 별도로 정의된 스펙 문서가 없어서 마치 스크립트 언어를 연상케 하는 겉모습이었다. 문법 자체도 간결해 보여서 마치 Python을 컴파일이 가능한 버전으로 만든 건 같았다.
하지만 이내 헤더가 없음에 약간의 좌절도 느꼈다. 숨기고 싶은 인터페이스와 공개하고 싶은 인터페이스를 어떻게 구분할 수 있을까? 이런 느낌은 현재 내가 하고 있는 SDK 개발 처럼, 특정한 라이브러리 등을 외부에 제공해야 할 때 하게되는 고민 같다.
Type Safe?
타입 안전(type-safe)이라는 표현은 뭐라고 하는 것이 좋을까? 개인적으로는 스위프트는 ‘타입 강제’ 언어라는 표현이 더 어울린다고 생각한다.
타입 세이프의 의미는 값과 타입 간의 관계를 명확히 한다는 표현이다. 그런데 이건 결국 '컴파일 타임 때 타입이 반드시 결정’ 이라는 제한으로 이루어진다. 그 덕분에 오버플로우 체크를 엄격하게 할 수 있는 길을 만들어 놨다.
현대적인 스크립트 언어들과의 차이점이 여기서 보인다. 대게 이런 언어들은 타입이 동적(Dynamic)이다. 한 변수의 타입이 하나가 아니라 다른 것으로 런타임 때 마구 바뀔 수 있다. 그래서 스크립트언어가 느리다는 것은 잘 알려져있다.
물론 뭐든 장단점과 특징이 있기 마련. 타입 강제라는 표현은 나쁘다라는 의미가 아니라 특징이라고 받아들이자.
강력한 언어 != 간결한 언어
문법(Syntax) 면에서 스위프트는 결코 간결하지 않다. 애플이 WWDC에서 이야기 한 ‘빠르게 개발 할 수 있는 언어’ 라는 표현은 틀렸다고 생각한다. 사용 할 수 있는 키워드도 많고 제한 사항도 많고 이상한 규칙도 많다.
물론 언어에 익숙해지고 몸에 익는다면 개발속도는 빨라지게 마련이다. 그런데 이건 모든 언어에 대해 할 수 있는 말이다.
오히려 구식 C 언어 같은 언어가 간결한 문법을 가지고 있다. 그 만큼 언어를 배울 때의 시간은 적게 소모된다. 스위프트는 언어를 배우는데 소모되는 시간이 좀 길다고 느껴진다. (물론 C의 포인터 같은 이질적인 뭔가는 사람에 따라 다르겠지만...)
다만 스위프트로 모듈을 잘 만들어 놓으면 이 모듈을 가져다 쓰는 개발자 입장에서는 편하고 빠르게 개발이 가능하다는 것은 부정하기 힘들다.
퍼포먼스를 위함인가 개념을 위한 의도인가
간혹 스위프트를 보다보면 의 존재하는지 이해하기 힘든 문법이 보인다. 예를 들어 override 라던가 mutating 같은 것이다.
사실 override는 코드 읽기 측면에서 도움이 될 수도 있다. 상위 클래스의 구현을 보지 않고도 이 메소드가 상속받아서 재구현(오버라이드) 되어 있다고 바로 파악 할 수 있기 때문이다. 그렇다면 강제로 명시하지 않아도 되는 것 아닌가? 스위프트는 현재 override 키워드를 강제하고 있다.
가장 이해하기 힘든 것은 mutating 이다. 구조체의 경우 멤버 프로퍼티를 메소드에서 수정하는 것을 기본적으로 제한하고 있다. 수정하고 싶다면 반드시 mutating 을 명시해야 한다. 그런데 이건 무슨 의도가 있는건가? 아니면 퍼포먼스를 위한 특수한 설계인가? 왜 굳이 struct 에서만 mutating을 명시해야 하는가? class는 왜 mutating이 없어도 되는가?
컴파일러 입장에서 보면 mutating 이든 override 이든 명시하지 않아도 코드를 보고 알아서 파악은 가능하다. 다만 문법에서 일부러 쓰도록 강요하고 있다.
느린데 제법 빠르다
스위프트가 발표되고 Xcode 6 베타가 즉시 발표됨에 따라 언어 벤치마크도 제법 활발하게 이루어졌다. 하지만 대부분 스위프트가 느리다는 결과를 보여주고 있다.
그런데 문제는 컴파일러 최적화 옵션(-Ofast)을 주면 C++에 버금갈 정도로 빨라진다는데 있다. 도데체 최적화를 안하면 뭔 짓을 하길래 이렇게 느릴까?
아직은 NextStep 에서 벗어나질 못 했다.
물론 이는 기본 프레임워크 때문일지도 모르겠지만, 아직은 많은 기본적이어야 할 데이터타입이 NS로 시작하는 이름의 클래스에 의존적이다. NS는 NextStep의 약자이고 Objective-C 를 대표하는 프레임워크이기도 했다. 그런데 NS Framework 들은 스위프트 문법과 어울리지 않다는 생각이다.
Array나 Dictionary 같은 타입은 잘 벗어났으면서 왜 NSDate는 Date로 벗어나질 못 하는걸까? 심지어 String 조차 NSString의 브릿지를 많이 제공하고 있는데 이는 스위프트 고유의 것은 아니다.
섵부른 이야기 일 수도 있지만, 스위프트는 아직 미완성이라고 생각한다. 즉 나중에는 벗어날 것 같다는 생각이다.
Po<LLVM>wer
LLVM이 대단한 것은 사실이고 실제로 좋다고 생각한다. 이건 그냥 넘어가자.
현재 스위프트의 장점 중 상당수는 이 LLVM에 의해 포장되어 있다고 느껴진다. 스위프트 소개에는 LLVM의 소개가 빠지질 않는다.
Xcode 6의 플레이그라운드 기능은 유용하다. 하지만 이 기능은 LLVM에 의존적이다. 제대로 된 플레이 그라운드가 나오려면 컴파일 방식이 아닌 좀 느리더라도 인터프리터가 제공되는 편이 좋지 않을까?
LLVM이 대단하긴 하지만 스위프트라는 언어만 본다면 제외하고 생각하는게 좋다는 느낌이다.
미완성
결론은 이걸로 맺어질 것 같다. 이 언어가 개발된지 4년 밖에 안되었고 다른 유명 언어들은 대게 10년 이상 개발된 언어들이라는 차이를 보자. 스위프트는 계속 변해갈 것이다. 다만 현 시점에선 아직 1.0 을 내놓기 이전의 알파라는 느낌이 강하다.
앞서 몇 가지 관련 이야기를 했었지만 또 다른 예를 하나 들어보자. class 에서 static 키워드를 사용하면 에러가 난다. 그런데 에러 내용을 봤는가. "static 은 아직 class 에서는 지원하지 않는다.” 이런 에러 메시지가 돌아온다.
심지어 OOP에서 가장 기본으로 삼는 포장화(Access Control)도 없다. 드러내고 싶은 멤버는 public 으로, 감추고 싶은 멤버는 private 로 만들어 주는 등 클래스 포장 기술은 OOP의 기본이다. 그런데 왜 없나? 일단 Xcode 6 Beta 2 에서는 Known Issue로 분류되어 있기에 나중에 추가될 것은 확실하다.
결국 기본적으로 제공되어야 할 것이 없기에 스위프트를 미완성이라 평가하는 것이다.
미래는 어떻게 될지 알 수가 없다. 느긋하게 가는 편하지만 느린 미래일까 아니면 카오스급 급변의 미래일까. ;-)
[관련글] 스위프트(Swift) 가이드
댓글 없음 :
댓글 쓰기