臥薪嘗膽

원문 : http://www.computerworld.com.au/article/315254/a-z_programming_languages_scala/

트위터와 링크드인 모두 스칼라를 사용하지만, 웹 2.0 스타트업들의 총아인 스칼라는 대기업에서도 널리 사용된다. 컴퓨터월드는 마틴 오더스키와 얘기를 나눴다.

컴퓨터월드는 프로그래밍 언어 세계로의 연속된 조사를 하고 있다. 이미 해스켈, 얼랭, (역시 JVM 에서 실행되는) 클로저 등의 몇 가지 다른 함수형 언어를 살펴보았다.

이번 인터뷰에서는 마틴 오더스키와 스칼라에 관해 이야기했다. 우리는 스칼라를 개발자들이 써봤으면 하는 6가지 스크립트 언어 중 하나로 꼽은 바 있다. 스칼라는 자바 가상 머신에서 돌아가는 새로운 언어 중 하나이며, 점점 인기를 얻고 있다.

트위터 개발자 중 한 명은 스칼라가 그 새로운 웹 2.0 스타트업의 선택 받은 언어가 될 수 있다고 말했다. 링크드인 또한 스칼라를 쓴다. 소니 픽쳐스, EDF, SAP을 비롯한 많은 대기업에서도 사용한다. 마틴 오더스키는 스칼라의 역사, 미래, 그리고 무엇이 스칼라를 매우 흥미롭게 만들었는지에 관해 얘기해줬다.

왜 이름을 스칼라라고 지었나?

아주 작게 시작하지만 먼 길을 갈 수 있다는 점에서 확장 가능한scalable 언어라는 뜻이다. 새로 접한 사람들에게는 스크립트 언어처럼 보인다. 실제로 지난 2년 동안 자바 스크립트 언어 시합인 JavaOne ScriptBowl에서 경쟁하도록 초대를 받기도 했다. 그러나 스칼라는 진짜로 스크립트 언어는 아니다 - 그것은 스칼라의 주요 특성이 아니다. 사실, 스칼라는 자바로 할 수 있는 모든 것을 표현할 수 있고, 자바의 능력을 넘어서 대규모 시스템에 필요한 많은 것들을 스칼라가 제공할 수 있다고 믿는다. 설계 기준 중 하나는 매우 작은 프로그램에서부터 시작해서 거대한 시스템에 이르기까지 모두 유용하고, 그 과정에서 구조를 바꿀 필요가 없는 언어를 만들고 싶다는 것이었다.

무엇때문에 스칼라를 개발하게 되었나?

90년대 중반에 자바 언어와 컴파일러 개발에 참여하게 됐다. 필립 와들러라는 연구원과 함께 일하게 되었고, 우리는 나중에 제너릭 자바(GJ)가 되고 그 후 자바 버전 5가 된 피자를 개발했다. 도중에 나는 javac 컴파일러를 작성했다. GJ를 위한 그 컴파일러는, 우리의 확장판이었는데, 선이 GJ 언어 구성물을 자바에 채택하기로 결정하기 오래 전에 표준으로 채택되었다 - 컴파일러를 먼저 채택한 것이다.

10년 전에 스위스로 옮겼을 때, 더 기본적인 주제들을 연구하기 시작했다. 함수형 프로그래밍과 객체 지향 프로그래밍을 유용하게 조합할 수 있을지를 확인하기 위해 몇 가지 실험적인 연구를 했다. 95,6년에 피자로도 이미 해봤지만, 그건 절반의 성공이었다. 왜냐하면 다음어지지 않은 부분이 많았기 때문인데, 모두 그 당시에 자바를 기본 언어로 사용한 것과 관련이 있었다. 자바는 그리 변경하기 쉽지 않았다. 그래서 2000년 경부터 시작해서 EPFL(국립 로잔 공과대학)에 있는 내 그룹과 함께, 자바와 함께 쓸 수 있으면서도 객체 지향과 함수형 언어 테크닉을 유용하게 섞어 쓸 수 있는 언어를 개발했다.

이 중 첫번째는 Funnel이라 불렀고, 두번째가 스칼라였다. 두번째 실험은 아주 잘 돼서, 실험 단계는 접고 스칼라를 사람들이 기댈 수 있는 실제 언어로 만들기로 했다. 거친 면을 좀 다듬고, 문법을 약간 바꾸고, 스칼라와 스칼라 툴이 널리 쓰일 수 있다는 것을 확신하기 위해서 스칼라 툴을 스칼라로 다시 작성했다. 그 후 2006년에 스칼라 버전 2를 출시했다. 스칼라는 그 때부터 급속하게 인기를 얻고 있다.

객체 지향과 함수형 언어 테크닉을 결합하는 주요 이점은 뭔가?

둘 다 많은 것을 제공한다. 함수형 언어는 강력한 조합을 제공하기 때문에 간단한 부분들을 가지고 흥미로운 것들을 만들 수 있다 - 함수들은 프로그램의 요소들을 흥미로운 방법으로 다른 요소들과 결합한다. 이와 관련된 함수형 프로그래밍의 이점은 함수들을 데이터로 간주할 수 있다는 점이다. 거의 모든 프로그래밍 언어의 전형적인 데이터 타입은 "정수형int"이다. 정수형 값은 함수 내부를 포함한 어디에서도 선언할 수 있고,  그것을 함수로 넘기고, 함수로부터 리턴하거나 필드에 저장할 수도 있다. 함수형 언어에서는 함수에 대해서도 똑같이 할 수 있다. 함수를 다른 함수 내에서 선언하고, 함수를 함수로 넘기거나 리턴 받을 수도 있고 필드에도 저장할 수 있다. 이런 특성은 여러분 자신의 제어 구조를 만드는 데, 매우 고수준의 라이브러리를 정의하거나 새로운 DSL 만드는 데 강력한 방법을 제공한다.

반면, 객체 지향 프로그래밍은 시스템 컴포넌트를 구조화하고 복잡한 시스템을 확장하거나 개선하는 데 강력한 방법들을 제공한다. 상속과 조합aggregation은 네임스페이스를 만들고 조직화하기 위한 유연한 방법을 제공한다. IDE(통합 개발 환경)에서 어떤 지점에서 호출할 수 있는 모든 메서드를 팝업 메뉴로 제공하는 컨텍스트 도움과 같은 유용한 툴 지원이 있다. 

두 가지 언어가 각각 존재하는 듯한 느낌을 주지 않고 하나의 언어로 결합하는 게 어려운 일이었다.

그 도전의 가장 중요한 부분이 무엇을 뺄 것인지를 결정하는 것이었을 것 같은데?

맞다. 만약 각 언어의 스타일을 모두 가져와 결합했다면, 중복된 점이 많아졌을 것이고 단지 서로 영향이 거의 없는 두 개의 서브 언어가 됐을 것이다. 한 쪽의 구성물을 다른쪽의 구성물과 동일시하는 게 어려운 점이었다. 예를 들어, 함수형 프로그래밍 언어의 함수값function value는 객체 지향 언어의 객체에 해당한다. 근본적으로 그것을 "apply" 메서드가 있는 객체라고 볼 수 있다. 결과적으로 우리는 함수값을 객체로 모델링할 수 있었다.

또다른 예는 함수형 언어의 대수algebraic 데이터 타입들을 객체 지향 언어에서는 클래스 계층으로 모델링될 수 있다는 것이다. 또한, 자바에 있는 스태틱 필드와 메서드를 제거하고 대신 싱글턴 객체의 멤버로 모델링했다. 그 외에도 한 언어의 구성물을 다른 언어에 존재하는 것과 매칭시켜서 합친 경우가 많이 있다.

스칼라를 개발하면서 맞닥뜨린 전체적으로 가장 큰 도전은 뭐였나?

컴파일러 기술을 개발하는 것이 확실히 어려웠다. 흥미롭게도 그 어려움은 객체 지향 언어에서보다 더했다. 진보된advanced 스태틱 타입 시스템을 갖춘 객체 지향 언어는 매우 드물었고, 그들 중에 하나도 주류가 아니었다. 스칼라는 자바나 비슷한 언어보다 훨씬 더 표현적인expressive 타입 시스템을 갖고 있어서, 구성 요소 조합을 위해 우아한 타입 개념과 프로그래밍 관념abstraction을 개발함으로써 새로운 영역을 개척break new ground해야 했다. 이것은 매우 어려운 작업이 되었고 또한 새로운 연구 결과도 나왔다.

또다른 어려운 부분은 상호 운용성interoperability과 관계가 있었다. 우리는 상호 운용이 매우 잘 되기를 원했고, 따라서 자바의 모든 것을 스칼라로 매핑해야 했다. 자바 라이브러리의 거대한 부분을 충실하게 매핑하기를 원했던 것과, 동시에 자바 언어의 모든 구성물과 중복을 피하는 것 사이에 항상 긴장이 있었다. 그것은 지속적이고 도전적인 엔지니어링 문제였다. 전체적으로 그 결과에 매우 만족하지만, 할 일이 참 많았다. 

포럼에 스칼라의 효율성과 확장성에 대해 긍정적인 평가도 많지만, 자주 언급되는 다른 점은 매우 재미있게 쓸 수 있는 언어라는 것이다. 이것도 스칼라를 설계할 때의 목표 중 하나였나?

물론이다. 동료들과 나는 코드를 작성하느라 많은 시간을 보내서 즐겁게 프로그래밍할 수 있는 것을 원했다. 그건 아주 분명한 목표였다. 우리는 규약이 많은high-protocol 전통적인 언어에 있는 상투적인 것들incantations을 가능하면 많이 없애기를 원했고, 개발자들이 원하는 대로 모델링할 수 있도록 스칼라에 높은 표현력을 주고 싶었다. javac를 개발할 때 자바 프로그래밍을 많이 했는데 자바 프로그래머들이 얼마나 쓸데 없는 작업을 많이 해야 하는지를 깨달았다. 같은 프로그램을 스칼라로 개발하면 라인 수가 대체로 2~3배 적은 것을 볼 수 있다. 많은 상투어boilerplate를 쓸 필요없고, 게다가 훨씬 더 재미있다.

이것은 우리가 개발자들에게 주는 강력한 도구이지만, 두 가지 면이 있다. 개발자들에게 많은 자유를 주지만 잘못된 사용을 피해야할 책임도 준다. 철학적으로 그게 자바와 스칼라의 가장 큰 차이점이라고 생각한다. 자바는 상당히 제한된 개념을 갖고 있어서 어떤 자바 프로그램이라도 다른 자바 프로그램과 좀 비슷해 보이고, 이는 프로그래머들을 교체하기swap 쉽도록 한다는 주장이 있다. 스칼라는 매우 표현적인 프로그래밍 언어이기 때문에 이러한 균일성은 없다.

스칼라 프로그램을 여러 가지 방법으로 개발할 수 있다. 자바로 시작한 프로그래머들에게 좋도록 자바처럼 짤 수도 있다. 이는 프로그래밍 그룹이 스칼라로 넘어오기 쉽도록 하고, 프로젝트의 리스크가 낮도록 한다. 그들은 중요하지 않은 부분부터 시작한 후 적당하다고 생각하는 속도로 범위를 넓힐 수 있다.

하지만 스칼라 프로그램을 완전히 함수적인 방법으로 짤 수도 있고 이런 프로그램들은 전형적인 자바 프로그램들과 전혀 달라 보일 수 있다. 종종 훨씬 더 간결하다. 이게 주는 이점은 고수준의 라이브러리나 스칼라에 내장된 DSL처럼 자신만의 관용구idioms를 개발할 수 있다는 것이다. 전통적으로, 똑같은 효과를 얻으려면 몇 가지 다른 언어나 설정 기법을 혼합해야 했다. 따라서 궁극적으로는 스칼라의 단일 언어 접근법이 더 간단한 해결책을 내놓게 할 수도 있다.

스칼라를 쓰기를 원하는 자바 개발자들에게는 학습 부담(learning curve)이 작겠지만 PHP나 파이선, 루비와 같이 동적 규율을 갖춘 동적 언어로 일하는 데 익숙한 프로그래머들이 배우기에는 어떨까?

확실히 자바나 닷넷 개발자들이 스칼라를 배우기 가장 쉽다. 다른 커뮤니티들에 관해서라면 걸림돌stumbling blocks은 언어 자체와는 별 관련이 없고, 패키징하는 법과 자바에 특정한 도구를을 구성set up하는 법이다. 이런 것들을 어떻게 구성하는지를 한 번 배우면, 언어 자체를 배우는 데는 어렵지 않을 것이다.

트위터가 스칼라를 쓰고 있는 것은 어떻게 생각하나? 이런 인지도 높은 사이트가 스칼라를 쓰는 게 스칼라 언어의 개발에 도움이 되나?

그것은 굉장한 소식이었다. 그들이 스칼라로 옮겨갔다는 것과 스칼라가 잘 쓰이고 있다는 게 기쁘다. 트위터는 외적인 성장을 잘 버텨왔고, 스칼라로 교체하기 전보다 더 견고해진 것 같다. 이는 스칼라에 좋은 증거testament라고 생각한다. 트위터처럼 인지도 높은 사이트가 새로운 언어를 채택하는 것은 그 언어에 매우 신랄한 테스트가 된다. 만약 그 언어에 커다란 문제들이 있다면 아마도 더 빨리 발견될 것이고 두드러지게 강조될 것이다.

스칼라를 채택하는 다른 잘 알려진 회사들도 많이 있다. 소니 픽쳐스 이미지웍스는 미들티어 소프트웨어 개발에 스칼라를 쓰고 유럽 최대의 에너지 회사인 EDF는 영업 부문에서 계약 모델링에 스칼라를 쓰고 있다. SAP와 지멘스 그들의 오픈 소스 기업 소셜 메시징 실험Enterprise Social Messaging Experiment(ESME) 도구에 스칼라를 쓰고 있다. 이는 많은 예 중에 단지 셋일 뿐이다.

트위터 개발자 중 한 명인 알렉스 페인은 스칼라가 그 새로운 웹 스타트업이 선택하는 언어가 될 수 있고, 매우 인기 있지만 스칼라 만큼 효율적이지 않은 파이선이나 루비 같은 언어보다 더 쓰일 수 있다고 했다. 이에 동의하나? 그리고 스칼라를 개발할 때 웹 2.0 스타트업들을 염두에 두었나?

스칼라가 이 영역에 적합다다고 본다. 이를 깨달은 것은 트위터뿐은 아니고 링크드인도 스칼라를 사용한다.

스칼라가 거기에 제공하는 것은 애자일한 언어를 쓰면서 견고한 고성능 플랫폼 - 자바 가상 머신(JVM) 위에 구축할 수 있는 능력이라고 생각한다. 자이선, J루비, 그루비, 클로저 등도 있지만 이것들은 모두 JVM에서 실행되는 동적 타입 언어이다.

결국 질문은 정적 타입 설정이 더 편하냐는 점에 도달하는데, 많은 에러를 일찍 잡을 수 있기 때문에 그럴 수도 있고, 리팩토링을 위한 안전망을 제공한다는 점에서, 또는 성능에 도움이 된다는 점에서 그럴 수도 있다. 혹은 메타 프로그래밍으로 화려한 것들을 하고 싶어서 완전한 동적 언어를 원할 수도 있다. 궁극적으로 그런 선택에 도달한다. 만약 정적 타입 언어를 원한다면 현재는 스칼라가 가장 좋은 선택이라고 생각한다.

스칼라의 특징 중에서 가장 좋아하는 것을 하나 꼽는다면?

가장 좋아하는 특징 하나를 고를 수 없을 것 같다. 오히려 스칼라의 특징들이 함께 작동하는 방식을 선택하겠다. 예를 들어, 고차 함수high-order functions가 어떻게 객체들과 추상 타입들과 함께 혼합되는지, 또는 스칼라에서는 함수가 상속될 수 있기 때문에 액터가 어떻게 가능해졌는지이다. 스칼라에서 가장 흥미로운 디자인 패턴들은 명확히 객체 지향과 함수형 언어 아이디어 사이의 상호 작용으로부터 유발된다.

앞으로 스칼라가 지향하는 것은?

단기적으로 다음 릴리즈인 스칼라 2.8을 위해 열심히 작업 중인데, 무엇보다도 고성능 배열 연산, 그리고 빠른 영속적인 데이터 구조를 가지고 컬렉션 라이브러리를 재정의하는 데 집중하고 있다. 올해 가을[북반구 기준으로]이면 나올 것이다.

그 후 장기적으로 동시성과 병행성 쪽에서 흥미로운 기회를 보고 있어서 멀티 코어 프로세서와 다른 병행 시스템에서 프로그래밍하는 데 새로운 방법을 찾고 있다. 스칼라는 동시성을 표현하는 고수준 방법을 제공하는, 유명한 액터 시스템을 갖고 있기 때문에 이미 여기에 유리한 점이 있다. 예를 들면 트위터의 메시지 큐에 사용된다. 재미있는 점은 스칼라에서의 액터는 언어 기능이 아니고 순수하게 스칼라 라이브러리로 구현됐다는 것이다. 따라서 이는 스칼라의 유연함에 대한 좋은 증거가 된다. 라이브러리에 적절한 기본 요소primitives와 관념abstractions을 포함시킴으로써 어플리케이션 프로그래머들에게 언어 기능으로 보이는 것들을 프로그래밍할 수 있다.

액터에 대한 작업이 데이터 병행성과 스트림 프로그래밍 등의 다른 동시성 관념concurrent abstractions에도 효과가 있기를 기대한다. 다른 종류의 병행성과 동시성은 다른 도구를 필요로 할 것이기 때문에, 미래에는 아마도 멀티 코어를 제대로 쓰기 위해 몇가지 동시성 관념이 필요할 것이라고 본다. 스칼라의 라이브러리 기반 접근이 여기에 적합하다고 보는데, 스칼라 클래스와 객체로 구현된 개념들을 섞고 매칭시켜서, 모든 것을 언어와 컴파일러에 넣는 것보다 빠르게 나아갈 수 있게 하기 때문이다. 다음 4,5년은 이 작업으로 바쁠 것 같다.