URL: https://dzone.com/articles/the-rise-and-fall-of-scala
5년 전만 해도 스칼라는 객체지향 패러다임 안에서 함수형 프로그래밍을 우아하게 가능하게 해준다는 이유로 차세대 유망 언어처럼 보였다. 하지만 오늘날 스칼라의 인기는 사그라드는 듯하며, LinkedIn과 Yammer 같은 기업들은 스칼라에서 벗어나고 있다. 소프트웨어 언어 인기 지표인 TIOBE 인덱스(www.tiobe.com)에서 스칼라는 2012년에 13위였지만, 2016년 8월에는 32위로 떨어졌고 전체 프로그래밍 커뮤니티의 0.6% 미만만이 사용하고 있다.
스칼라에 대한 또 다른 불길한 신호가 있다. 스칼라의 모회사인 Lightbend가 이제는 스칼라 버전보다 Java API를 먼저 제공하는 새 프레임워크들을 출시하고 있다는 점이다. 일화로, 선도적인 소프트웨어 제품 엔지니어링 회사의 CTO로서 많은 소프트웨어 개발 매니저들을 만나는데, 그중 최소 두 명은 1년 넘게 도입해 사용한 뒤 고통스러운 결정을 내려 스칼라를 포기했다. 무슨 일이 있었던 걸까? 스칼라는 무엇 때문에 처음 인기를 얻었고, 무엇이 쇠퇴를 불러왔을까? 스칼라가 여전히 최선의 선택인 사용 사례는 남아 있을까?
스칼라의 초기 인기를 이해하려면 먼저 현대 프로그래밍 패러다임의 진화를 이해해야 한다. 처음에는 절차적 프로그래밍이 있었고, 프로그램은 한 문장이 다음 문장으로 이어지며 순차적으로 실행되어야 하는 일련의 문장으로 여겨졌다. 그다음에는 객체지향 프로그래밍이 등장했는데, 프로그램은 객체에 대해 연산을 수행하는 방법을 알고 서로 대화하며 작업을 완수하는 ‘행위자(actors)’로 여겨졌다.
이에 비해 함수형 프로그래밍은 프로그램을 결과 값을 산출하기 위해 평가되는 수학적 함수로 본다. 그 함수는 중첩된 함수를 호출할 수 있고, 그 중첩 함수는 또 더 중첩된 함수를 호출할 수 있다. 중첩 함수는 평가되어 결과를 만들어낸다. 그 결과는 바깥(포함) 함수로 전달되고, 바깥 함수는 중첩 함수들의 값을 사용해 자신의 반환 값을 계산한다. 함수들이 서로에게 데이터를 쉽게 전달하도록 하기 위해 함수형 언어들은 보통 데이터 구조를 가능한 한 가장 일반적인 방식, 즉 (어떤) 것들의 컬렉션으로 정의한다. 또한 함수 자체를 데이터 매개변수인 것처럼 다른 함수에 전달할 수 있게 한다. 이 패러다임에서 함수는 상태 정보를 유지하는 전역 변수를 수정하는 것 같은 부작용(side effect)을 일으키면 안 된다. 대신 매개변수를 받아 그 위에서 어떤 연산을 수행해 반환 값을 만들어내기만 허용된다. 함수형 프로그램을 실행한다는 것은 가장 바깥쪽 함수를 평가하는 것을 의미하며, 이는 가장 기본적인(더 이상 중첩 함수를 갖지 않는) 함수들까지 재귀적으로 모든 중첩 함수의 평가를 유발한다.
함수형 프로그래밍이 중요한 이유는?
- 명확성(Clarity): 부작용 없이 프로그래밍하면 코드를 따라가기 쉬워진다. 함수는 입력과 출력으로 완전히 설명되기 때문이다. 오늘 올바른 답을 내는 함수는 내일도 올바른 답을 낸다. 이는 디버깅, 테스트, 재사용이 더 쉬운 코드를 만든다.
- 간결성(Brevity): 함수형 언어에서는 일반 목적의 컬렉션 데이터 타입을 통해 중첩 함수에서 부모 함수로 데이터가 암묵적으로 전달된다. 이 때문에 함수형 프로그램은 다른 패러다임보다 훨씬 더 압축적이며, 다른 패러다임에서 함수 간 데이터 전달을 위해 필요한 상당한 ‘관리(하우스키핑)’ 코드가 줄어든다.
- 효율성(Efficiency): 함수에 부작용이 없기 때문에 성능을 최적화하려고 연산의 순서를 바꾸거나 병렬로 수행할 수 있고, 어떤 연산 결과가 다른 함수에서 사용되지 않는다면 아예 생략할 수도 있다.
함수형 프로그래밍 언어는 1950년대 MIT에서 John McCarthy가 만든 LISP에서 시작해 수십 년 동안 존재해 왔다. 하지만 이런 언어들은 주로 학자와 이론가들의 관심사인 틈새(niche) 언어로 여겨졌다. 스칼라도 학술 프로젝트로 시작했는데, 2001년 스위스 로잔연방공과대학(EPFL)에서 Martin Odersky가 만들었다. 그러나 스칼라 설계자들은 스칼라를 함수형 프로그래밍을 주류로 끌어올릴 ‘돌파구 언어’로 자리매김하게 만든 몇 가지 중요한 결정을 내렸다.
- 스칼라는 함수형 프로그래밍과 객체지향 프로그래밍을 결합한다. 다중 패러다임 언어로서, 객체지향 프로그래머가 함수형 세계로 들어갈 때 다리 역할을 할 수 있다.
- 스칼라 코드는 자바 가상 머신(JVM)에서 실행된다. 이는 자바가 실행되는 어떤 머신에도(PC의 약 85%) 쉽게 배포할 수 있음을 뜻한다. 또한 이론적으로는 스칼라 코드가 자바 코드와 상호 운용될 수 있어, 자바 개발팀이 스칼라로 천천히 전환하는 데 교두보가 될 수 있다.
- 스칼라는 문법적으로 자바와 비슷하며, 자바처럼 런타임이 아니라 컴파일 시점에 타입 체크를 수행한다. 따라서 타입 불일치로 인한 런타임 오류 가능성을 제거한다. 이러한 유사성은 자바 프로그래머의 초기 학습 부담을 줄인다.
- 스칼라는 패턴 매칭을 내장 지원한다. 임의의 데이터 타입을 값 패턴에 따라 매칭해, 매칭된 각 패턴에 대해 서로 다른 연산을 수행할 수 있다.
- 스칼라는 표준 라이브러리로 Akka를 포함하여 풍부한 동시성 모델을 지원한다. 이를 통해 스트리밍 데이터의 복잡한 생성·처리 과정을 액터 그래프로 구현하기 쉽고, 각 액터가 데이터를 병렬로 처리할 수 있다.
그렇다면 스칼라가 처음에 열광적으로 환영받았고 함수형 프로그래밍을 주류로 가져올 언어로 여겨진 것도 무리는 아니다. 하지만 William H. Calvin의 말처럼 “개척자들은 늘 등 뒤에 꽂힌 화살로 알아볼 수 있다.” 스칼라는 함수형 프로그래밍을 대중화하는 데 분명 개척자였다. 그런데 왜 지금은 조류가 바뀌어, 오늘날 스칼라 개발자 기반이 꾸준히 줄어드는 상황에 이르렀을까?
- 자바는 2014년 초에 출시된 Java 8부터 함수형 프로그래밍 구문(constructs)을 도입했다. 스칼라와 자바가 함수형을 지원하는 방식에는 미묘한 차이가 있고, 스칼라 접근이 더 낫다는 주장도 가능하다. 하지만 프로그래머들이 이미 자바를 알고 있기 때문에 자바가 스칼라를 제치고 사실상 대표적인 함수형(구문을 갖춘) 프로그래밍 언어가 되었다. 이는 웹 UI 프로그래머들 사이에서 적지 않은 추종자를 보유했던 Adobe Flex와 Microsoft Silverlight가 HTML5 출시 이후, HTML5가 충분한 웹 UI 기능을 제공하면서 지배적 기술이 된 흐름을 떠올리게 한다.
- 스칼라는 수학적 타입 이론에 기반한 원칙들을 가지고 있어, 이를 온전히 이해하는 사람은 가장 학술적이고 수학적 성향이 강한 프로그래머들에 한정되기 때문에 마스터하기 어렵다. 또한 implicits와 macros를 포함한 스칼라의 많은 언어 기능은 프로그램의 제어 흐름이 코드베이스의 다른 부분으로 예기치 않게 이동하게 만들 수 있어, 대부분의 프로그래머가 코드를 따라가거나 디버깅하는 일을 어렵게 한다. 이를 모두 이해하는 뛰어난 프로그래머라면 자바보다 스칼라에서 더 생산적일 수 있지만, 구현된 기능을 기준으로 측정한 평균적인 프로그래머의 생산성은 자바에서 스칼라로 전환할 때 아마도 떨어질 것이다. 이는 학습 곡선으로 인한 단기 하락만이 아니다. 어떤 개발팀에서는 스칼라 도입 후 1년이 지난 시점에도 생산성 하락이 관찰되었다.
- 자바와 달리 스칼라는 유연한 문법을 가지며, 같은 결과를 얻는 방법을 여러 가지로 제공하는 경우가 많다. 이것이 평균적인 프로그래머에게 스칼라를 더 쓰기 좋게 만들기보다는, 스칼라 커뮤니티가 기능적으로 동등한 여러 해법 중 무엇이 ‘정답’인지 논쟁하는 데 많은 시간을 보내게 만드는 듯하다. 이런 논쟁은 실익보다 소모가 크며, 자바처럼 더 제한적인 언어에서 존재하는 검증된 구현 패턴의 등장을 방해한다.
- 스칼라는 이전 버전의 스칼라와의 호환성, 그리고 자바와의 호환성을 유지하는 데 좋은 성과를 내지 못했다.
이런 문제들 때문에 스칼라는 자바 같은 주류 프로그래밍 언어로 발전하지 못할 가능성이 크다. 하지만 스칼라가 너무도 이상적으로 들어맞아, 프로그래밍 언어 선택에서 최우선이 되어야 하는 특정 사용 사례는 여전히 존재한다.
- 빅데이터 조작(Big Data manipulation): 스칼라의 강점은 빅데이터 프로그래밍 모델에 매우 잘 맞는다. 이 모델에서 작업은 불변(immutable) 컬렉션을 입력으로 받아, map과 reduce 연산으로 컬렉션을 변환하고, 새로운 결과 컬렉션을 생성한다. Spark 같은 빅데이터 도구의 경우, 스칼라를 사용하면 이점이 압도적이다. 스칼라 버전 프로그램은 보통 동등한 자바 프로그램보다 5~10배 더 짧기 때문이다.
- 도메인 특화 언어(DSL) 만들기: 많은 문제는 사용자가 스크립트를 작성할 수 있는 도메인 특화 언어(DSL)를 제공하는 방식으로 가장 잘 해결된다. 예를 들어 사용자가 자동화 QA 테스트를 스케줄링하고 실행하는 도구를 요구한다고 해보자. 사용자가 실행해야 할 테스트 조합을 모두 예측할 수 없으므로, 어떤 시나리오에서도 테스트의 순서와 위치를 정의할 수 있는 스크립팅 언어를 제공해야 한다. 스칼라는 패턴 매칭, 문법 유연성, 연산자 오버로딩 같은 기능 덕분에 DSL 개발에 특히 적합하다.
요약하자면, 스칼라는 함수형 프로그래밍을 대중화하는 촉매로서 핵심적인 역할을 했고, 자바의 함수형 프로그래밍 설계에도 강한 영향을 미쳤다. 스칼라가 차세대 거대 프로그래밍 언어가 될 가능성은 아마 크지 않다. 그러나 빅데이터 프로그래밍 같은 틈새 문제 영역에서 선택 언어로서 앞으로도 수년간 살아남을 것이다.
스칼라(프로그래밍 언어) 자바(프로그래밍 언어) 빅데이터 함수형 프로그래밍
DZone 기고자들이 표현한 의견은 기고자 개인의 견해이다.