애플 진영 개발자가 아니라도 스위프트에 관심을 가져야 하는 이유
OSS
게시글 작성 시각 2015-12-15 22:34:14
2015년 12월 15일 (수)
ⓒ ITWorld, Simon Bisson | InfoWorld
애플이 지난 주 당초 약속한 대로 스위프트(Swift) 언어를 오픈소스화했다. 약 1년 전에 공개된 스위프트는 범용 애플리케이션 개발을 염두에 두고 설계된 C 계열에 속하는 언어다. 애플은 새로운 데스크톱 및 모바일 앱 개발에 초점을 두고 LLVM 컴파일러를 사용하는 언어로 스위프트를 만들었다. 그 결과 C의 정교함과 깊이에 파이썬과 같은 인터프리트 언어의 쉬운 사용성을 결합한, 현대 언어 설계 사조를 폭넓게 활용하는 새로운 언어가 만들어졌다. 또한 속도도 빠르며 큰 배열과 컬렉션을 원활하게 처리하도록 설계됐다.
스위프트가 이번에 오픈소스로 공개됨에 따라 리눅스 진영의 지원과 서버 측 언어 기능이 추가되는 등 지속적으로 개발이 이루어지게 될 전망이다. 스위프트는 이미 빠른 속도로 발전하고 있다. 나온 지 1년여 만에 버전 2.2에 이르렀고 LLVM과 클랭(clang) 컴파일러에 전용 기능이 추가되고 있다. 아직 스위프트의 윈도우 버전은 없지만 마이크로소프트는 최신 비주얼 스튜디오 릴리즈 버전에 iOS와 OS X 애플리케이션에 대한 스위프트 지원을 추가했다.
OS X에서 스위프트를 사용한다면 엑스코드(Xcode)에서의 스위프트도 거의 똑같이 느껴진다. 오브젝티브-C 개발자에게 오래 전부터 익숙한 개발 환경이며, 두 언어의 컴파일러도 동일하다. 애플도 “스위프트는 C 없는 오브젝티브-C”라고 표현한 적이 있다.
그도 그럴 듯이 스위프트는 오브젝티브-C와 기반 LLVM 컴파일러의 추출물이라고 할 수 있다. 스위프트와 오브젝티브-C의 밀접함은 오브젝티브-C에서 특정 키 구조를 간소화하고 코드의 가독성을 더 높인 것이 곧 스위프트라고 말할 수 있을 정도다. 스위프트는 오브젝티브-C의 구문을 기반으로 하며, 자바스크립트와 C# 진영에서 건너오는 iOS 또는 OS X 개발자 관점에서 접근성이 높고 간소한 현대적인 구조를 지원한다. 이러한 개발자들은 스위프트에서 제어 흐름을 처리하는 방식부터 함수 사용법에 이르기까지 익숙한 요소를 많이 발견하게 된다.
스위프트와 오브젝티브-C의 유사성 덕분에 스위프트로 앱을 업데이트하는 과정도 간편하다. 같은 앱에서 스위프트와 오브젝티브-C 코드의 혼합 사용이 가능하므로 새 앱에서 기존 라이브러리를 재활용할 수 있다. 둘 중 한 언어에서 다른 한 언어로 바꿀 때 재사용할 코드를 굳이 다시 쓸 필요가 없다.
애플의 설계 원칙은 안전성에 초점을 두고 있으며 스위프트의 주요 특징 중 하나는 형식 상속 지원이다. 그 결과 스위프트는 강력한 형식 언어가 아니지만 형식에 안전한 언어다. 변수 형식을 선언하지 않았더라도 이미 선언된 값으로 이 변수를 설정하는 경우 스위프트는 이를 선언된 형식으로 추론한다. 따라서 코드의 안전성이 높아지고 충돌 위험이 낮아진다. 또한 스위프트는 자체 메모리 관리를 통해 포인터에 대한 접근을 제한한다.
형식 안전성은 곧 int를 string으로 전달할 수 없음을 의미하기도 한다. 스위프트 컴파일러는 이러한 경우를 항상 오류로 잡아낸다. guard 문은 값이 nil인 경우 해당 코드 섹션 실행을 중지시키므로 개발자는 일반적인 사용자 및 API 오류(보통 nil은 컴파일러 타임 오류를 일으킴)로부터 코드를 보호할 수 있게 된다. 또는 optionals를 사용해서 어떤 형식을 구현하든 관계없이 특정 변수에 null을 허용할 수도 있다.
스위프트로 앱을 만들기는 아주 쉽다. 바로 시작하면 된다. main 함수를 준비하거나 참조를 가져올 필요가 없다. 이러한 점이 코딩의 접근성을 높이도록 설계된 부분이다. OS X 또는 iOS 사용자 인터페이스의 대부분은 라이브러리로 처리되지만 모양을 입히고 꾸미기 전에 앱의 핵심부터 바로 시작할 수 있는 것이다.
스위프트의 핵심 요소 중 하나는 애플의 표현을 그대로 옮기자면 “프로토콜 지향 프로그래밍”이다. 다른 언어의 인터페이스와 긴밀하게 연관되는 프로토콜에는 특정 메소드를 구현하기 위한 클래스가 필요하다. 따라서 프로토콜을 사용하는 클래스에서 언제든 정의된 메소드를 사용할 수 있다. 소스 코드를 편집할 필요 없이 프로토콜을 통해 핵심 언어 요소를 포함한 모든 클래스 확장이 가능하다. 이는 서드파티 코드와 라이브러리로 작업할 수 있음을 의미한다.
또 다른 큰 장점은 개발 팀에게 코딩 표준을 구현하는 프로토콜 집합을 제공할 수 있다는 점이다. 프로토콜은 아주 강력한 도구로, 제네릭(Generic)을 개발 전략의 중요한 요소로 만들어준다.
스위프트에서 가장 중요한 혁신은 엑스코드에 플레이그라운드(Playground)를 추가한 것이다. 애플은 엑스코드와 스위프트를 사용해 LLVM 컴파일러의 더 많은 부분을 개발자에게 공개하면서 IDE 내에서 코드가 하는 일을 볼 수 있게 해준다. 개발자는 IDE에서 나올 필요 없이 플레이그라운드를 통해 코드의 특정 섹션을 신속하게 실행해서 원하는 대로 작동하는지 여부를 확인할 수 있다. 코드를 컴파일하고 빌드 또는 디버거를 실행할 필요가 없다. 작성한 코드 옆에 모두 제공되기 때문이다. 이러한 구조의 목적은 실험, 말 그대로 코드 놀이(play)를 촉진하는 데 있다.
이와 같은 기능을 다른 플랫폼으로 가져오는 것도 중요한 일이다. 언어는 클라이언트에서 서버, 클라우드에 이르기까지 개발자가 어디에서 일하든 사용 가능해야 하며, 효율적인 개발을 위해서는 현재 사용되는 스택의 모든 요소에서 일관성을 확보하는 것이 핵심이다. 리눅스에서는 스위프트 컴파일러에 플레이그라운드가 없다.
그러나 이쪽에서는 서버 애플리케이션 개발이 주를 이루므로 (출력을 콘솔로 넘기는 것 이상으로) 신속하게 함수를 시각화할 필요는 사실 없다. 애플은 인터랙티브한 방식으로 신속하게 코드를 다룰 수 있도록 리눅스 도구에 REPL 기반 디버거를 제공하므로 REPL(Read-Eval-Print-Loop) 도구를 식 계산기로 사용할 수 있다.
이제 스위프트 소스 코드가 깃허브(GitHub)에 공개되어 있으므로 누구나 원본 리포지토리를 가져와 코드를 실험하고 스위프트에 코드 기여를 요청할 수 있다. 아마도 여기서 가장 중요한 요소는 애플 개발 프레임워크를 다른 플랫폼으로 확장할 수 있는 가능성을 열어주는 스위프트의 코어 라이브러리일 것이다. 스위프트 코드를 한 번만 만들어 여러 플랫폼에 제공할 수 있게 되면 개발자들은 마이크로소프 오픈소스 .Net 외의 대안을 갖게 되고, 자마린(Xamarin)과 같은 크로스 플랫폼 도구 기업은 훨씬 더 폭넓은 개발자 집단을 지원할 수 있게 된다.
스위프트가 이번에 오픈소스로 공개됨에 따라 리눅스 진영의 지원과 서버 측 언어 기능이 추가되는 등 지속적으로 개발이 이루어지게 될 전망이다. 스위프트는 이미 빠른 속도로 발전하고 있다. 나온 지 1년여 만에 버전 2.2에 이르렀고 LLVM과 클랭(clang) 컴파일러에 전용 기능이 추가되고 있다. 아직 스위프트의 윈도우 버전은 없지만 마이크로소프트는 최신 비주얼 스튜디오 릴리즈 버전에 iOS와 OS X 애플리케이션에 대한 스위프트 지원을 추가했다.
OS X에서 스위프트를 사용한다면 엑스코드(Xcode)에서의 스위프트도 거의 똑같이 느껴진다. 오브젝티브-C 개발자에게 오래 전부터 익숙한 개발 환경이며, 두 언어의 컴파일러도 동일하다. 애플도 “스위프트는 C 없는 오브젝티브-C”라고 표현한 적이 있다.
그도 그럴 듯이 스위프트는 오브젝티브-C와 기반 LLVM 컴파일러의 추출물이라고 할 수 있다. 스위프트와 오브젝티브-C의 밀접함은 오브젝티브-C에서 특정 키 구조를 간소화하고 코드의 가독성을 더 높인 것이 곧 스위프트라고 말할 수 있을 정도다. 스위프트는 오브젝티브-C의 구문을 기반으로 하며, 자바스크립트와 C# 진영에서 건너오는 iOS 또는 OS X 개발자 관점에서 접근성이 높고 간소한 현대적인 구조를 지원한다. 이러한 개발자들은 스위프트에서 제어 흐름을 처리하는 방식부터 함수 사용법에 이르기까지 익숙한 요소를 많이 발견하게 된다.
스위프트와 오브젝티브-C의 유사성 덕분에 스위프트로 앱을 업데이트하는 과정도 간편하다. 같은 앱에서 스위프트와 오브젝티브-C 코드의 혼합 사용이 가능하므로 새 앱에서 기존 라이브러리를 재활용할 수 있다. 둘 중 한 언어에서 다른 한 언어로 바꿀 때 재사용할 코드를 굳이 다시 쓸 필요가 없다.
애플의 설계 원칙은 안전성에 초점을 두고 있으며 스위프트의 주요 특징 중 하나는 형식 상속 지원이다. 그 결과 스위프트는 강력한 형식 언어가 아니지만 형식에 안전한 언어다. 변수 형식을 선언하지 않았더라도 이미 선언된 값으로 이 변수를 설정하는 경우 스위프트는 이를 선언된 형식으로 추론한다. 따라서 코드의 안전성이 높아지고 충돌 위험이 낮아진다. 또한 스위프트는 자체 메모리 관리를 통해 포인터에 대한 접근을 제한한다.
형식 안전성은 곧 int를 string으로 전달할 수 없음을 의미하기도 한다. 스위프트 컴파일러는 이러한 경우를 항상 오류로 잡아낸다. guard 문은 값이 nil인 경우 해당 코드 섹션 실행을 중지시키므로 개발자는 일반적인 사용자 및 API 오류(보통 nil은 컴파일러 타임 오류를 일으킴)로부터 코드를 보호할 수 있게 된다. 또는 optionals를 사용해서 어떤 형식을 구현하든 관계없이 특정 변수에 null을 허용할 수도 있다.
스위프트로 앱을 만들기는 아주 쉽다. 바로 시작하면 된다. main 함수를 준비하거나 참조를 가져올 필요가 없다. 이러한 점이 코딩의 접근성을 높이도록 설계된 부분이다. OS X 또는 iOS 사용자 인터페이스의 대부분은 라이브러리로 처리되지만 모양을 입히고 꾸미기 전에 앱의 핵심부터 바로 시작할 수 있는 것이다.
스위프트의 핵심 요소 중 하나는 애플의 표현을 그대로 옮기자면 “프로토콜 지향 프로그래밍”이다. 다른 언어의 인터페이스와 긴밀하게 연관되는 프로토콜에는 특정 메소드를 구현하기 위한 클래스가 필요하다. 따라서 프로토콜을 사용하는 클래스에서 언제든 정의된 메소드를 사용할 수 있다. 소스 코드를 편집할 필요 없이 프로토콜을 통해 핵심 언어 요소를 포함한 모든 클래스 확장이 가능하다. 이는 서드파티 코드와 라이브러리로 작업할 수 있음을 의미한다.
또 다른 큰 장점은 개발 팀에게 코딩 표준을 구현하는 프로토콜 집합을 제공할 수 있다는 점이다. 프로토콜은 아주 강력한 도구로, 제네릭(Generic)을 개발 전략의 중요한 요소로 만들어준다.
스위프트에서 가장 중요한 혁신은 엑스코드에 플레이그라운드(Playground)를 추가한 것이다. 애플은 엑스코드와 스위프트를 사용해 LLVM 컴파일러의 더 많은 부분을 개발자에게 공개하면서 IDE 내에서 코드가 하는 일을 볼 수 있게 해준다. 개발자는 IDE에서 나올 필요 없이 플레이그라운드를 통해 코드의 특정 섹션을 신속하게 실행해서 원하는 대로 작동하는지 여부를 확인할 수 있다. 코드를 컴파일하고 빌드 또는 디버거를 실행할 필요가 없다. 작성한 코드 옆에 모두 제공되기 때문이다. 이러한 구조의 목적은 실험, 말 그대로 코드 놀이(play)를 촉진하는 데 있다.
이와 같은 기능을 다른 플랫폼으로 가져오는 것도 중요한 일이다. 언어는 클라이언트에서 서버, 클라우드에 이르기까지 개발자가 어디에서 일하든 사용 가능해야 하며, 효율적인 개발을 위해서는 현재 사용되는 스택의 모든 요소에서 일관성을 확보하는 것이 핵심이다. 리눅스에서는 스위프트 컴파일러에 플레이그라운드가 없다.
그러나 이쪽에서는 서버 애플리케이션 개발이 주를 이루므로 (출력을 콘솔로 넘기는 것 이상으로) 신속하게 함수를 시각화할 필요는 사실 없다. 애플은 인터랙티브한 방식으로 신속하게 코드를 다룰 수 있도록 리눅스 도구에 REPL 기반 디버거를 제공하므로 REPL(Read-Eval-Print-Loop) 도구를 식 계산기로 사용할 수 있다.
이제 스위프트 소스 코드가 깃허브(GitHub)에 공개되어 있으므로 누구나 원본 리포지토리를 가져와 코드를 실험하고 스위프트에 코드 기여를 요청할 수 있다. 아마도 여기서 가장 중요한 요소는 애플 개발 프레임워크를 다른 플랫폼으로 확장할 수 있는 가능성을 열어주는 스위프트의 코어 라이브러리일 것이다. 스위프트 코드를 한 번만 만들어 여러 플랫폼에 제공할 수 있게 되면 개발자들은 마이크로소프 오픈소스 .Net 외의 대안을 갖게 되고, 자마린(Xamarin)과 같은 크로스 플랫폼 도구 기업은 훨씬 더 폭넓은 개발자 집단을 지원할 수 있게 된다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/97055]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 316090 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 305687 | 2020-10-27 |
4771 | 줌라, 크리티컬 원격 실행 버그 패치 | 3074 | 2015-12-15 |
4770 | MS, 리눅스 자격증도 판다 | 3048 | 2015-12-15 |
4769 | 엔터프라이즈DB ‘PPAS 도입전략 고객사례’ 세미나 | 3435 | 2015-12-15 |
4768 | 애플 진영 개발자가 아니라도 스위프트에 관심을 가져야 하는 이유 | 3155 | 2015-12-15 |
4767 | 대구, 스마트시티 클라우드 플랫폼 구축 사업 착수 | 2935 | 2015-12-15 |
4766 | 시큐리티플러스-오픈소스협회 ‘제1회 보안 오픈소스 컨퍼런스’ 개최 | 2960 | 2015-12-15 |
4765 | MS, '윈도우 라이브 라이터' 오픈소스로 공개 | 3225 | 2015-12-15 |
4764 | 그루터 타조, 오라클 빅데이터 어플라이언스에서 돌아간다 | 3446 | 2015-12-15 |
4763 | 페이스북, 인공지능 서버 '빅서' 무료 공개 | 3718 | 2015-12-15 |
4762 | 그들이 자바·파이썬 대신 고(Go)를 선택한 까닭 | 4074 | 2015-12-15 |
0개 댓글