스칼라의 미래, 자바와 코틀린 사이에서

프로그래밍 언어 ‘스칼라’는 2010년대 개발자 세계에서 큰 주목을 끌었다. 객체 지향 프로그래밍 언어에 함수형 프로그래밍 요소를 결합해 자바를 주로 다루던 개발자에게 신선한 충격을 줬다.

스칼라는 개발자의 의도를 표현하기 좋고, 간결하게 기능을 구현할 수 있다. 강력한 타입 시스템, 병렬 처리와 동시성 지원 등도 강점이었다. 무엇보다 새로운 개발 패러다임의 이점을 활용하면서도 자바와 호환된다는 점이 매력 포인트였다.

스칼라는 2003년 스위스 로잔 연방공과대학교의 마틴 오더스키 교수에 의해 만들어졌다. 마틴 오더스키는 제네릭 자바 컴파일러를 만들면서 느낀 자바의 단점을 극복하고, 객체지향 기법과 함수형 기법을 하나의 언어 속에 녹이고자 했다. 스칼라란 이름은 이탈리어로 ‘계단’을 뜻하는데, 실제론 ‘확장 가능한 언어(Scalable Language)’에서 유래됐다.

스칼라는 2010년대 중반 주요 오픈소스 프로젝트 다수에 활용됐다. 빅데이터 프레임워크인 ‘아파치 스파크’와 이벤트 스트리밍 플랫폼 ‘아파치 카프카’가 스칼라로 작성됐다. 기업의 주요 백엔드 시스템에서도 스칼라 활용이 활발히 시도됐다.

“세련미는 떨어지지만 풍부한 기능으로 틈새 시장에서 선두”

초기 선풍적인 유행을 만들었지만, 탄생 후 20년을 넘긴 현재 스칼라의 지위는 여전히 비주류다. 스칼라를 배우기에 초기 진입장벽이 높다는 점, 함축적인 표현력 때문에 장기적인 유지보수가 힘들다는 점, 경쟁 플랫폼의 등장 등이 주류 등극의 발목을 잡았다.

지난달 24일 마틴 오더스키와 스칼라 유지관리자인 데이터브릭스의 하오이 리는 ‘진화하는 스칼라(Evolving Scala)’란 제목의 글을 올리고, 스칼라의 현재 상황과 미래에 대한 의견을 내놨다.

마틴 오더스키와 하오이 리는 “스칼라는 더 이상 2010년대 중반에 있었던 과대광고의 물결을 타고 있지 않지만, 대부분의 조사에서 주류 언어 목록 바로 밖에 그 위치를 유지하고 있다”며 “기술적 관점에서 핵심 언어와 생태계는 지난 10년동안 크게 개선됐고, 스칼라는 오늘날 10년 전보다 훨씬 더 나은 기반 위에 있다”고 밝혔다.

창시자와 유지관리자는 현재의 스칼라 위치를 ‘주류는 아니지만 틈새 시장 언어 대비 훨씬 더 많이 채택됐다’고 설명했다. 레드몽크 언어 순위에서 스칼라는 2014년 14위를 기록한 뒤 계속 14위 내외를 유지하고 있다.

레드몽크의 프로그래밍 언어 순위에서 스칼라는 계속 하락세였다가 작년 오랜만에 반등했다. 스칼라와 경쟁하는 언어인 코틀린은 17위에 오른 지 3년만에 상승해 스칼라와 공동 14위를 차지했다.

마틴 오더스키와 하오이 리는 “스칼라는 신규 온보딩 경험에 초점을 맞춰 강점과 약점을 모두 개선해야 하다”며 “IDE 지원과 생태계의 학습 가능성과 관련된 지속적 문제가 있으며, 언어 진화에 따른 툴링, 호환성, 마이그레이션 비용 등의 우려가 항상 있다”고 진단했다.

배우기 어렵고, 너무 함축적인 코드, IDE 지원 부족

창시자와 유지관리자의 진단처럼 스칼라는 생태계 확장에 어려움을 겪고 있다.

스칼라는 함수형 프로그래밍을 객체지향 프로그래밍에 결합한 언어다. 문법이 복잡하기에 초급 개발자가 배우기 어렵다. 기존 자바 개발자도 패턴 매칭, 모나드 같은 생소한 개념을 익혀야 한다.

함수형 패턴을 사용할 수 있다는 점은 장점이면서 단점이다. 함수형 패턴을 과도하게 사용하면 너무 함축적으로 코드를 표현하게 돼 가독성이 떨어진다. 코드작성자 외에 타인이 코드를 읽거나 유지보수하기 힘들고, 작성자 본인도 주석을 꼼꼼하게 달지 않으면 애초의 의도를 파악하지 못할 수 있다.

툴링도 약점인데, 계속해서 개선되지 못하고 있다. 젯브레인의 인텔리제이 외에 스칼라를 완벽하게 지원하는 IDE가 없다.

자바 생태계 내 경쟁에서도 밀리고 있다. 일단 자바 자체가 자바8 버전에서 ‘람다’를 지원해 함수형 프로그래밍을 할 수 있게 됐다. 이후 스칼라에서 도입했던 함수형 프로그래밍 요소 다수가 자바 언어에 수용됐다. 이는 기존 자바 개발자가 굳이 스칼라 전환에 도전할 동력을 줄였다.

코틀린의 부상도 스칼라의 발목을 잡았다. 코틀린은 구글의 안드로이드 운영체제(OS) 공식 언어로 채택되면서 거대한 개발 생태계에 빠르게 편입됐다. 코틀린은 자바와 100% 호환되고, 스칼라보다 더 간결한 문법을 제공해 배우기도 쉬웠다.

스칼라는 대형 기업의 후원을 받는데도 실패했다. 구글이 코틀린을 선택했고 마이크로소프트나 오라클은 스칼라를 후원하지 않았다. 스칼라의 우군이었던 트위터는 스칼라를 도입했다가 코틀린과 자바로 전환했다.

이런 요인으로 인해 기업 시장에서 스칼라는 쉽사리 도입하기 어려운 언어가 됐다. 개발자 풀이 작기 때문에 스칼라 전문 인력을 확보하기 힘들었다. 함축적 코드 때문에 업무 인수인계도 어렵다. 이는 장기적인 유지보수 기반의 안정성을 중시하는 엔터프라이즈향 시스템에서 서비스 연속성 문제를 야기한다.

‘안전성과 편의성 융합’ 철학은 유지, 문제점 개선 시도

스칼라의 등장 시기는 자바 플랫폼의 새로운 중흥기였다. 2010년대 중반 함수형 프로그래밍을 활용하는 게 전세계 개발자 세계에 유행처럼 번졌다. 스칼라는 그 유행의 맨 앞에 있었다. 스칼라처럼 자바가상머신(JVM)을 활용하는 개발 언어가 다수 생겨났다. 코틀린, 다트, 러스트, 스위프트 등의 언어가 춘추전국시대처럼 발표되던 시기다.

창시자와 유지관리자는 “객체 지향과 함수형 스타일의 융합은 종종 논의됐지만, 다른 융합은 안전성과 편의성이었다”며 “전통적으로 파이썬 같은 스크립트 언어는 안전하지 않지만 편리했고, 자바 같은 애플리케이션 언어는 안전하지만 불편했다”고 설명했다.

이어 “스칼라는 같은 언어로 두 가지를 모두 할 수 있다는 것을 처음으로 증명했다”며 “스위프트나 코틀린 같은 더 현대적인 언어도 이 방향으로 발전했으며, 스칼라가 처음 시작됐을 때 그런 아이디어는 전혀 없었다”고 강조했다.

그러면서 “프로그래밍 환경은 지난 20년 동안 멈추지 않았고, 스칼라에서 고유했던 많은 게 이제 일반적”이라며 “모든 현대 언어는 제네릭, 형식 추론, 람다, 레코드, 패턴 매칭 등의 기능을 제공하고 스칼라는 사용자를 계속 유치하기 위해 양방향으로 혁신을 계속해야 한다”고 밝혔다.

그들의 설명처럼 현대의 프로그래밍 언어는 안전성과 편의성 모두를 충족하는 방향으로 나아가고 있다. 스칼라는 애초에 추구했던 본연의 철학을 유지하면서 단점을 극복해야 지금보다 더 성장할 수 있다.

두 사람은 “스칼라 생태계는 광범위하고 다양하지만 안전성과 편의성이란 두 목표는 공통적인 주제”라며 “JVM에서 아카(Akka) 액터를 사용해 백엔드 서비스를 빌드하든, Scala.js로 브라우저에서 웹 UI를 빌드하든, Chisel을 통해 사용자 정의 실리콘 칩을 빌드하든, 사람들이 스칼라를 선택하는 이유는 안전성과 편의성 때문”이라고 강조했다.

이들은 “다른 언어도 이런 목표를 추구하지만 우리는 스칼라가 대부분보다 더 나은 것을 제공한다고 믿는다”며 “타입 시스템, 패턴 매칭, 컬렉션 라이브러리, 다중 상속 시스템 등 다른 언어에서 자체적으로 제공하는 것이라도 스칼라가 동급 최고”라고 덧붙였다.

함수형 프로그래밍 올인이나 특정 프레임워크 집중은 안 한다

스칼라는 지난 20년 간 기본적인 디자인과 철학을 유지했지만, 지속적으로 다듬어져왔다. 마틴 오더스키와 하오이 리는 스칼라의 여러 문제점을 개선하고 다듬고 있다고 밝혔다.

앞으로 스칼라의 미래를 말하면서 처음으로 언급된 게 초급 개발자 유입이다. 두 사람은 “스칼라를 신규 사용자가 더 쉽게 익힐 수 있다고 믿는다”며 “모든 고급 스칼라 사용자는 어느 시점엔 신규 사용자였고, 오늘날 모든 대규모 스칼라 프로젝트는 신규 사용자 집단에서 시작됐다”고 밝혔다.

이어 “고급 사용자는 스스로 문제를 해결하고 자신의 문서를 작성하며, 자신의 언어 변경 사항을 제안하지만, 신규 사용자는 핵심 스칼라 유지관리자에게 의존해 좋은 경험을 보장받아야 한다”며 “스칼라 툴킷과, com-lihaoyi 플랫폼 같은 더 간단하고 사용하기 쉬운 라이브러리에 대한 코드와 문서 지원을 우선시 한다”고 적었다.

또 “불필요하게 갈라진 다른 언어와 스칼라 신택스를 정렬한다”며 “와일드카드 가져오기와 vararg 스플라이스가 이미 적용됐다”고 덧붙였다.

두 사람은 “다음의 큰 스칼라 프로젝트는 이전에 아무도 해결하려 생각하지 못했던 문제를 해결하기 위해 언어를 배우는 신입생에 의해 시작될 가능성이 크다”며 “그들은 학교에서 자바나 파이썬, 자바스크립트를 알고 있을 것이고, 그들이 스칼라 언어로 쉽게 진입할 수 있게 해야 한다”고 강조했다.

스칼라의 방향성에 대해 여러 논의가 있다. 마틴 오더스키와 하오이 리는 프레임워크 올인, 기능구현 중단 등 두가지 아이디어에 대해 의견을 밝혔다.

스칼라 커뮤니티 내부에선 순수 함수형 프로그래밍 언어로서 모든 것을 투자해야 한다거나, 순수 함수형 프로그래밍에서 사용하는 IO모나드를 애플리케이션 구조화 방법으로 올인해야 한다는 주장이 있다. 이에 대해 두 사람은 부정적 입장이다.

두 사람은 “스칼라는 자연스러운 진화를 지원할 만큼 일반적이어야 하며, 수년에 거려 흥망성쇠하는 특정 프레임워크에 전념할 수 없다”며 “핵심 스칼라 개발자들은 프레임워크 전문가도 아니고 IO모나드 전문가도 아니기에 그 하위 커뮤니티에서 필요한 언어 개선을 추진해야 한다”고 밝혔다.

이어 “스칼라는 모든 프레임워크나 라이브러리가 혜택을 볼 수 있는 기능을 구축해 일반적이어야 한다”며 “프레임워크 애호가들이 스칼라 언어에 대한 개선 사항을 제안하도록 권장하며, 모든 특정 아이디어가 수용되진 않지만 피드백은 모든 프레임워크에 이로운 언어 변경을 주도한다”고 강조했다.

일부에선 스칼라의 모든 기능 구현을 중단해야 한다는 주장도 한다. 도구 지원이나 일자리 문제가 주된 이유다.

이에 대해 두 사람은 “그 감정은 이해할 수 있지만, 현실적으로 기능 개발을 동결하면 스칼라 언어는 망할 것”이라며 “스칼라는 자바보다 항상 기능은 더 풍부하지만 세련미와 안정성은 떨어졌고, 스칼라의 핵심 가치 제안은 그 대가로 다른 언어에 없고 10~15년 후에야 얻을 수 있는 미래의 언어 기능을 받았다는 것”이라고 적었다.

이어 “스칼라는 안정성과 세련미 만으로 주류 언어와 경쟁할 수 없으므로 오늘 기능 개발을 중단하면 스칼라는 더 나쁜 기능, 더 나쁜 세련미와 안정성을 가진 언어로 끝나고 존재할 이유가 없어진다”며 “스칼라는 지속 가능하고 사람과 프로젝트가 언어를 선택할 이유를 제공하기 위해 꾸준한 개선이 필요하다”고 덧붙였다.

IDE와 개발도구 개선, 초급 개발자 진입 장벽 제거에 집중

두 사람은 스칼라 생태계에서 해결해야 할 시급한 문제에 대해 언급했다. IDE 등 툴링과, 빌드 툴링, 학습 용이성 등이 제시됐다.

스칼라를 사용하는 개발자는 주로 인텔리제이와 비주얼스튜디오코드(VS코드)를 사용하고 있다. 스칼라는 2021년 ‘스칼라 3.0’으로 업그레이드됐는데, 아직 IDE 차원에서 스칼라 3.0의 새 기능을 제대로 지원하지 않는다. 스칼라 유지관리자들은 스칼라 3.0에서 ‘미리보기’ 개념을 도입하고, IDE와 개발도구 생태계가 언어의 진화를 따라잡을 수 있는 시간을 벌도록 했다.

그리고 젯브레인이 스칼라 센터 자문위원회에 합류했다. 이를 통해 젯브레인과 스칼라 컴파일러 팀의 협력이 개선됐다고 한다. 앞으로 인텔리제이의 스칼라 지원 속도 개선에 도움을 줄 것으로 기대된다.

VS코드에서 추천이나 자동 완성 같은 코드 인텔리전스 기능을 제공하게 해주는 ‘언어 서버’도 개선될 것으로 예상됐다. 스칼라 언어 서버인 ‘메탈(Metals)’은 스칼라 컴파일러를 사용하고 항상 실제 언어와 동기화된다. 이는 안정성 문제를 일으킨다. 다중 프로세스 아키텍처와 복잡성, 스칼라3 통합 등이 원인으로 지목된다.

인텔리제이와 스칼라3 컴파일러 개발자가 메탈의 문제를 인지하고 있으며, 메탈 유지관리자와 인텔리제이 개발진의 협력으로 컴파일러와 IDE 간 통합을 개선할 것이라고 두 사람은 밝혔다.

빌드 도구인 sbt는 스칼라 커뮤니티에서 오랫동안 골치거리였다.

마틴 오더스키와 하오이 리는 “터널 끝에 빛이 있다”며 “sbt 자체가 시간이 지나면서 개선되고 프로젝트에서 훌륭한 대안을 제공하는 다른 도구를 선택함으로써 문제가 스스로 해결될 것으로 기대한다”고 적었다.

하나는 스칼라의 기본 런처인 ‘Scala-CLI’다. 이 도구에 대해 두 사람은 거의 모든 단일 모듈 프로젝트에 필요한 모든 것을 갖췄고, 소규모 프로젝트와 실험에서 탐색적 코딩을 위한 훌륭한 도구라고 설명했다. 다른 도구인 ‘Mill’을 비롯해 ‘메이븐(Maven)’, 그레이들(Gradle)’도 sbt의 대안으로 언급된다. sbt 자체도 ‘유니파이드 슬래시 신택스’, ‘sbt 프로젝트 매트릭스’ 같은 개선 사항이 있었다. 곧 출시될 sbt 2.0의 경우 빌드 쿼리, 원격 캐싱 등을 제공할 예정이다.

생태계 학습 용이성도 개선될 것이라고 한다. 초보자 친화적인 플랫폼을 강화하고, 문서화 부족도 해결할 것이라고 했다.

스칼라의 아카, 캣츠, ZIO 같은 프레임워크는 고급 사용자에게 용이하다. 반면, 학생 프로젝트, 스타트업 코드베이스, 비엔지니어 주도의 데브옵스, 데이터분석 스크립트 등의 영역에서 스칼라의 프레임워크는 사용하기 어렵다.

스칼라 생태계는 부족한 문서화를 계속 지적받아왔다. HTTP 요청하기, 서버 시작하기 같은 간단한 작업을 하려해도 액터, IO 모나드 같은 고급 주제를 익혀야 하는데 문서와 학습자료가 부족하다.

두 사람은 “스칼라 툴킷과 많은 동일한 라이브러리를 포함하는 com-lihayoi 플랫폼은 거의 완전하고 사용가능한 초보자 친화적 플랫폼을 제공한다”며 “더 정교한 프레임워크만큼은 아니지만 많은 프로덕션 배포에 충분하며 필요한 경우 더 정교한 프레임워크로 쉽게 전환할 수 있다”고 적었다.

이어 “최근 스칼라 센터와 록더JVM의 파트너십은 스칼라의 교육 측면을 개선할 것”이라며 “이 파트너십이 록더JVM의 도달 범위를 확장하고 스칼라 초보자가 훌륭한 비디오와 과정을 발견해 혜택을 얻는 데 도움을 받길 기대한다”고 덧붙였다.

스칼라 언어는 두 그룹에서 이뤄지고 있다. 스칼라 센터가 핵심 언어와 컴파일러 개발과 커뮤니티 지원 등을 담당하며, 버투스랩(VirtusLab)은 메탈이나 스칼라-CLI 등 스칼라 툴링의 개발을 수행한다.

마틴 오더스키와 하오이 리는 스칼라센터와 버투스랩에 재정적으로 지원하거나, 수정이나 개선을 자유롭게 요구하라고 주문했다. 오픈소스 프로젝트이므로 코드를 수정하거나 개선하는 작업에 직접 참여할 수 있다고도 강조했다. 스칼라3, 인텔리제이, 메탈 등의 버그를 자유롭게 수정할 수 있고,, 컴파일러와 툴링 개선에도 참여할 수 있다. 스칼라 개선 프로세스에도 핵심 기여자 외에 누구나 의견을 개진할 수 있다고 강조했다.

두 사람은 “스칼라 언어의 핵심 매력이 안전성과 편의성의 조합이라고 믿으며, 강력한 타입 시스템과 컴파일러는 실수를 방지하고 뛰어난 런타임 성능을 제공하고, 간결한 구문과 유형 추론은 모든 스크립팅 언어만큼 유연하고 표현력이 풍부하다”고 밝혔다.

또 “의심할 여지 없이 다른 언어도 같은 목표를 지향하고 있으며, 고유한 하이브리드 함수형-객체 지향 디자인을 갖춘 스칼라는 사용자를 유치하고 유지할 만큼 충분히 더 나은 방식으로 이를 수행할 수 있다고 생각한다”고 덧붙였다.

그리고 “스칼라 언어와 생태계의 세부 사항은 진화할 것이고, 우리는 익숙해진 우연적 복잡성에 지나치게 집착해서는 안 된다”며 “스칼라를 개선하기 위해 변경할 수 있는 영역을 계속 찾을 것이고, 이전 버전과 호환성, 마이그레이션, 학습 가능성에 대한 우려는 항상 있을 것이지만, 그럼에도 불구하고 스칼라는 지속적이고 비판적으로 자체를 검사하고 지난 20년 동안 다른 언어가 개발자 경험을 개선하기 위해 배운 것을 활용해야 한다”고 강조했다.

자바와 코틀린 사이에서, 급진성과 일자리 문제

스칼라 창시자와 유지관리자의 목표는 합리적이다. 그러나 미래에 스칼라가 과거의 인기를 회복할 지는 불확실하다. 스칼라3는 스칼라2와 호환성이 부족하고, 2023년 스칼라 설문조사에서 스칼라 사용자 중 49%는 스칼라3를 전혀 사용하지 않는 것으로 조사됐다. 과거 파이썬2에서 파이썬3로 넘어갈 때 발생한 생태계 분열이 우려되는 상황이다.

스칼라의 현재 위치는 애매하다. 자바와 코틀린 사이에 낀 상태다.

자바란 언어는 여전히 자바 플랫폼 생태계에서 중심을 잡고 있다. 코틀린은 모바일 생태계 개발자 집단을 가져갔다. 자바와 코틀린 사이에서 객체지향과 함수형의 융합이란 스칼라의 기본적 가치는 독보적이지 않다. 20년이나 지나버린 지금 스칼라는 LISP, 헤스켈처럼 특정 소수의 전유물로 고정될 수 있다.

대형 기업의 스칼라 기반 엔터프라이즈향 시스템 유지보수를 지원하려고 마틴 오더스키가 창업한 ‘타입세이프’는 2016년 회사명을 ‘라이트벤드(Lightbend)’로 바꾸고 자바 시스템 유지보수를 주력 사업으로 삼았다. 스칼라를 현업 시스템으로 운영하는 고객이 적고, 이는 스칼라를 주력으로 하는 개발자의 일자리 문제를 낳는다. 이런 풍토가 고착화되면 점차 신입 개발자의 스칼라 생태계 진입도 줄어든다. 악순환이다.

라이트벤드는 작년 회사명을 ‘아카(Akka)’로 변경했다. 아카는 스칼라나 자바로 액터 모델 기반의 분산 애플리케이션을 개발할 수 있는 툴킷이기도 하다. 액터 모델은 수십년 전 나온 소프트웨어 개발 방법이지만 대중적이지 않다.

글. 바이라인네트워크

<김우용 기자>yong2@byline.network