개발자 블로그

들어가는 말

최근 오랜만에 오키에서 신세 한탄이나 돈 문제가 아닌 기술 이야기로 활발한 논쟁이 불붙는 것을 보고 한 편으로는 반가운 마음도 들었지만, 내용에 대해서는 아쉬움이 훨씬 크게 남는 토론이었다고 생각합니다.

스칼라(Scala)를 홍보하는 분의 다소 편협한 태도와 빈약한 근거로 인해 오히려 스칼라에 대한 반감만 늘어난 것 같고, 이를 반박하는 분들의 주장을 보아도 스칼라의 장점들에 대한 오해에서 비롯된 내용이 자주 보여서 상당히 안타까웠습니다.

하지만 이 문제에 대해 본격적으로 글을 쓰기에는 바쁜 일정 탓에 많은 시간을 할애할 수 없었습니다. 그리고 무엇보다 제 자신이 아직 스칼라를 배워가는 단계라고 생각하기 때문에 스칼라나 함수형 패러다임에 대해 다른 분들에게 도움이 될만한 글을 쓸 자격이 있는지도 의문입니다.

또한, 이번 토론의 내용을 보더라도 아마 많은 자바 개발자 분들이 굳이 스칼라와 같은 생소한 언어를 새로 배워야 한다는 데 큰 공감을 하지 못하고 있다는 느낌을 받았습니다.

자바가 주류 언어가 되기까지 - 오픈소스 진영과의 불편한 동거

90년대 중반 처음 등장한 이래 많은 곡절이 있었지만, 자바 언어는 최근까지 특히 엔터프라이즈 응용프로그램 분야에서 독보적인 위치를 유지하고 있습니다. 그렇기 때문에 특히 자바의 입지가 절대적인 우리나라의 자바 개발자의 입장에서 다른 언어를 본격적으로 배워야할 필요성을 절감하기 어려운 것이 사실입니다.

하지만 우리나라의 개발 환경은 항상 세계적인 흐름을 시차를 두고 따라가는 형태로 변화해왔다는 점을 감안한다면, 최근 세계적으로 자바의 위상이 급격하게 위협 받고 있는 추세를 무시해선 안된다고 봅니다.

세계적인 웹 기술의 추세는 구글이나 페이스북 같은 몇몇 기술력 있는 기업과 오픈소스 진영을 중심으로 생겨나고 발전해 나가고 있습니다. 자바의 경우도 메이븐에 존재하는 수 많은 오픈소스 프로젝트 라이브러리가 증명하는 것처럼 오픈소스 진영의 영향력은 절대적이라고 할 수 있습니다.

하지만 자바를 중심으로 하는 오픈소스 진영은 시작부터 기존 리눅스를 중심으로 하는 오픈소스 진영과 다소 껄끄러운 관계를 유지하고 있었습니다. 여기에는 여러 이유가 있는데, 썬(Sun Microsystems) 사가 자바의 오픈소스화에 대한 약속을 몇 차례 번복했던 일도 있고, 무엇보다 근본적으로 자바가 지향하는 식의 운영체제와 무관하게 모든 것을 자바로만 거대하고 복잡하게 쌓아 올리는 접근이 일반적인 리눅스/유닉스 철학과 호환되지 않는다는 점도 크게 작용했습니다.

여기에 더해 기존 C/C++ 개발자들이 자바 언어에 대해 가지는 우월감이나 반감, 혹은 '해커'들이 이른바 '기업형 프로그래머'에 대해 느끼는 비슷한 감정 등이 더해져서 같은 오픈소스라고는 하지만 오픈소스 자바 진영과 기존 리눅스 중심의 오픈소스 진영 사이에는 묘한 감정적 괴리가 항상 존재했던 것이 사실입니다.

물론 시간이 지나면서 자바와 리눅스의 결합이 시장에서 힘을 얻고, 자바 자체도 오픈소스화 되면서 이런 반감이 어느 정도 완화되긴 했습니다. 하지만 이런 갈등이 전면적으로 부각되지 않았던 가장 큰 이유는 오픈소스 진영에 있어서 썬보다는 마이크로소프트가 보다 진정한 '악의 축'에 가까웠고, 무엇보다 엔터프라이즈 환경에서 유닉스/리눅스와 자바의 조합에 대한 마땅한 대체제가 없었기 때문입니다.

하지만 이 모든 상황은 최근 몇 년 동안 급격하게 변화하기 시작합니다.

오라클 시대의 자바, 그리고 자바 스크립트의 반격

2010년, 자바 진영을 이끌던 썬 사가 오라클에 인수 합병되면서 자바의 미래에도 어둠의 그림자가 드리우기 시작합니다. 한편, 거의 비슷한 시기에 node.js나 angular.js와 같은 본격적인 자바스크립트 프레임워크 프레임워크들이 등장함으로 인해, 루비 온 레일즈(Ruby on Rails: RoR)에서 가능성을 보였던 엔터프라이즈 시장에서 자바를 밀어낼 대안이 다시 한 번 빠른 속도로 구체화 되기 시작합니다.

오라클은 자바를 인수하자마자 구글을 상대로 자바 API의 특허권을 공격적으로 사용함으로써, 가뜩이나 오라클이 관리하는 자바의 미래에 의구심을 품고 있던 기존 오픈소스 진영 개발자들의 마음을 결정적으로 자바에서 돌아서게 만듭니다.

한 편, 마이크로소프트는 닷넷(.NET)을 오픈소스로 공개하고, 역시 오픈소스로 타입 스크립트(TypeScript) 언어를 발표하면서 오픈소스 진영의 호감도를 높이는 동시에 이제 막 시작된 자바 스크립트의 추세에도 발빠르게 올라타는 대조적인 행보를 보입니다.

그 와중에 터진 브라우저 자바 플러그인의 보안 취약성으로 인한 일련의 사고 및 이에 대한 오라클의 뒤늦은 대응은, 개발자 뿐 아니라 기업의 IT 인프라의 아키텍쳐를 결정하는 데 영향을 줄 수 있는 경영자를 포함한 일반인들에게 까지 자바에 대한 부정적인 인식을 퍼뜨리는 치명적인 결과를 가져오게 됩니다.

하지만 무엇보다 자바의 입지를 크게 위협하는 것은 자바 스크립트의 급부상으로, npm으로 관리되는 자바 스크립트 패키지 수가 고작 2년만에 메이븐의 자바 라이브러리 수를 추월해버릴 정도로(참조: modulecounts.com ) 가히 폭발적인 기세로 빠르게 자바와 같은 기존 언어들의 영역을 잠식해나가기 시작합니다.

이처럼 자바가 서버 시장에서 강력한 도전에 직면한 와중에 안드로이드 덕에 모바일 시장에서는 건재한 모습을 보이고 있지만, 안드로이드를 이끄는 구글이 오라클과 자바에 대한 특허 분쟁을 경험한 당사자이며 누구보다 강력하게 자바 스크립트나 고(Go)와 같은 대안 언어에 힘을 보태고 있는 상황을 감안하면 종합적인 면에서 자바 언어의 전망은 과거 어느 때보다 어둡다고 할 수 있습니다.

자바의 미래, 그리고 대안 모색의 시기

이렇듯 자바의 입지가 급격하게 위협 받게 된 것은 최근의 일이지만, 자바 언어에 대한 대안을 찾는 시도는 훨씬 이전부터 꾸준하게 진행되어 왔습니다.

여기에는 여러 이유가 있겠지만, 무엇보다도 자바 언어는 다수 대기업이 참여하는 JCP(Java Community Process)를 통해 관리되는 통에 상대적으로 C# 등과 같은 언어에 비해 발전 속도가 너무 느리다는 것이 결정적이라고 할 수 있습니다.

예컨대, 람다식(lambda expression)을 지원하는 스칼라 언어가 처음 등장한 것은 2003년이지만 JSR(Java Specification Request)의 형태로 자바 언어에 처음 비슷한 개념이 등장한 것은 2010년이고, 이 것이 실제로 완성되어 발표된 것은 작년의 일입니다.

LINQ(Language INtegrated Query)는 2007년에 닷넷 환경에 포함되었지만, 유사한 기능이 포함된 자바의 EL 3.0은 2013년이 되서야 발표되었습니다.

스칼라나 JVM의 또 다른 대안 언어인 실론(Ceylon) 등에서 제공하는 옵셔널 타입(optional type) 또한 작년 자바 8에 포함되어 발표되었지만, 아직도 실무 환경에서 자바 6나 심지어 자바 5를 흔하게 사용하는 것을 감안하면 일반적인 자바 개발자들이 이러한 기능을 널리 사용하기 위해서는 아직도 몇 년의 시간이 더 필요할 것으로 보입니다.

무엇보다, 메이븐에 있는 수 많은 라이브러리의 API가 대부분 람다와 옵셔널 타입을 통해 개선되기까지는 이보다도 많은 시간이 필요할 것이고, 어쩌면 자바의 핵심 API 같은 경우 영원히 바뀌지 않을 가능성이 높습니다. (제가 기억하는 한 자바는 1.0 시절 이래 한 번도 핵심 API에서 deprecation을 제거한 적이 없습니다.)

한 편, 지난 십여 년간 빅데이터의 등장 및 클라우드 서비스의 일반화로 인해 어느 때보다 동시성의 문제가 중요한 화두로 대두되었고, 이러한 문제를 해결하기 위해서는 불변(immutable)의 데이터 형의 활용을 핵심으로 하는 접근이 대세로 떠오르게 되었습니다.

이러한 맥락에서 함수형 패러다임의 접근 방법이나 메시징 기반 아키텍쳐가 빠르게 입지를 넓혀 나가기 시작했고 스칼라나 아카(Akka)와 같은 대안 언어나 기술들이 각광 받게 되는 배경으로 작용하게 되었습니다.

하지만 20년 가까이 발전하면서 수 많은 라이브러리와 프레임워크로 생태계를 구축한 자바를 하루 아침에 대체하는 것은 결코 쉬운 일이 아닙니다. 따라서 JVM 플랫폼 자체와 그 위에서 돌아가는 여러 라이브러리는 그대로 두고, 컴파일을 통해 클래스 파일을 생성하는 원본 언어만을 대체하는 접근이 널리 쓰이고 있으며, 스칼라, 실론, 코틀린(Kotlin), 그루비(Groovy) 등 수 많은 자바의 대안 언어들이 이와 같은 방식을 채택하고 있습니다.

대안 언어를 배워야 하는 이유?

앞서 언급한 대로, 자바 언어의 입지가 빠르게 위협 받고 있고, 이에 대한 대안 또한 활발하게 연구되고 있지만 상대적으로 우리나라, 특히 SI 환경의 개발자들이 이러한 변화를 체감하기까지는 아직도 상당한 시간이 필요할 것으로 보입니다.

그런 환경에서 "당장 필요한 것도 아닌데 굳이 다른 언어까지 배워야 하는가?"하는 의문이 드는 건 어찌보면 자연스러운 현상입니다.

하지만 우리나라의 IT 환경은 안타깝지만 항상 세계적 흐름에 대해 종속적으로만 움직여왔습니다. 개인적으로 처음 스트러츠(Struts)를 도입했을 때도 많은 반발을 경험했고, 이후 스프링(Spring Framework)으로 이행했을 때도 비슷하게 그 필요성에 의문을 제기하는 목소리는 항상 있어왔지만, 결국 몇 년의 시차를 두고 해외의 추세를 고스란히 따라가는 결과가 되었을 뿐입니다.

이미 SI에서 오랜 경력을 쌓고 안정된 일자리를 기술적 호기심보다 중시하는 분들이라면 아마도 새로운 언어를 배우기 보다는 자바를 계속 하는 것이 올바른 선택이 될 것입니다. 설사 우리나라에서도 자바가 몰락하고 대안언어나 자바스크립트가 대세가 되더라도 아마도 그런 개발자들이 은퇴하기 이전에 자바 일거리가 끊기진 않을 가능성이 높습니다.

반면 아직 자바 경력이 오래지 않았거나, 언제라도 스타트업이나 기술 중심 기업, 혹은 해외 취업등으로 일자리를 옮길 의향이 있는 분들, 혹은 SI를 하더라도 아키텍트 수준까지 오르는 것을 목표로 하는 개발자라면 기술 추세의 변화에 보다 민감하게 반응할 필요가 있고, 지금 시점에서 자바 아닌 다른 언어를 배우는 것은 선택이기 보단 거의 필수에 가까운 상황이 되었음을 인식할 필요가 있다고 봅니다.

사실 한 가지 언어만 사용하면 서 다른 언어의 장점을 이해하기는 무척 어렵습니다. 예컨대 자바 언어의 이넘(enum)이나 예외(Exception) 같은 장치들도, 아마 그런 개념이 없는 언어에 익숙한 개발자에게 소개하면 "그냥 문자열 비교하는 게 더 편한데 왜?", "실패하면 그냥 -1을 반환하면 되잖아?"와 같은 반응을 경험하기 십상일 것입니다.

하지만 그런 개념들이 그 언어 고유의 디자인 철학을 만들고 이를 통해 해당 언어를 사용하는 개발자들이 공유하는 원칙(best practice, principles)으로 자리 잡는 것을 감안하면, 자바보다 이후에 등장한 언어들이 새로 도입한 개념들의 중요성을 간과하는 것은 어리석은 일입니다.

더구나 스칼라나 해스켈 등의 함수형 언어적 특성은 이러한 단순한 기능이 아닌 객체지향과 같은 패러다임의 변화이고, 그 만큼 간단히 이해하기 어렵지만 더욱 큰 함의를 지닌 여러 새로운 개념들을 소개하기도 합니다.

자바가 반드시 나쁜 언어는 아니지만, 이러한 새로운 언어들을 공부하면 어렵지 않게 자바만의 '단순 문자열 비교'나 '-1을 반환'하는 시대에 뒤떨어진 여러 관습들을 깨닫게 될 것입니다.

어떤 대안 언어를 선택할 것인가?

사실 냉정하게 이야기하자면 현 시점에서 자바 언어에 대한 대안을 찾는다면 스칼라 같은 JVM 기반 언어 보다는 자바스크립트를 고르는 것이 가장 합리적인 선택이라고 할 수 있습니다. 어떤 언어를 사용하건 클라이언트 환경은 브라우저를 주요 플랫폼으로 고려할 수 밖에 없고, 자바스크립트는 이미 '웹 시대의 어셈블리'라고 불리울 정도로 브라우저 환경에서 유비쿼터스한 존재감을 확보하고 있습니다.

따라서, 단순히 화면에 효과를 주고 Ajax로 내용을 갱신하는 수준을 넘어 클라이언트 환경에서도 자바 스크립트를 활용하는데 있어서 점점 수준 높은 기술을 요구한다면 그런 기술력을 갖춘 개발자나 회사들은 중복 투자없이 동일한 기술을 서버측에도 적용하기를 희망하는 것은 자연스러운 현상입니다.

반면에, 이렇듯 점점 개발 규모가 커지고 복잡할수록 동적 언어로서 자바스크립트의 단점이 장점보다 더 부각되는 것을 감안하면, 아마도 웹 기술의 미래는 컴파일을 통해 자바스크립트를 생성할 수 있고 (transpiler) 서버에서도 편리하게 사용할 수 있는 생태계를 갖춘 정적인 언어가 대세가 되지 않을까 생각합니다.

그런 면에서 node.js 위에서 구동되는 타입 스크립트나 고와 같은 언어가 앞으로 대세가 될 수 있는 후보군이라고 조심스래 예상해 볼 수도 있을 것입니다.

하지만 이를 위해서 이러한 자바스크립트 기반 기술들은 JVM 기반 기술과 치열하게 경쟁해야할 것으로 보입니다. 앞서 흐름에서 뒤쳐진 자바 언어를 비판했지만, 상대적으로 언어가 아닌 플랫폼 자체, 즉 JVM과 그 위에서 구축된 수 많은 라이브러리와 프레임워크의 생태계는 여전히 꽤나 강력한 경쟁력을 유지하고 있습니다.

플랫폼 독립성은 변화된 환경에서도 여전히 중요한 개념이며, 20년 가까이 썬의 기술력이 집약된 결과 성능 면에서도 아직까지는 기타 대안들에 비해 무시 못할 우위를 유지하고 있기도 합니다.

따라서, JVM 환경을 버리지 않으면서 최근 기술 동향을 보다 적극적으로 반영하는 대안 언어를 찾는 것은 여전히 유효한 접근이며, 그런 관점에서 스칼라나 실론 등 JVM에서 구동되며 기존 자바 라이브러리를 그대로 활용할 수 있는 언어들에 주목할 필요가 있습니다.

사실 JVM에서 구동되는 언어는 자바와 스칼라 이외에도 매우 다양하게 찾아볼 수 있습니다(위키 백과 참조 ). 하지만 이들 중 스칼라(Scala.js ), 실론, 코틀린 등 소수만이 자바스크립트로 컴파일해서 브라우저에서 구동할 수 있으며, 또한 자바스크립트에 비해 정적인 언어의 장점을 극대화하기를 원한다면 그루비와 같은 동적인 언어는 좋은 선택이 되지 않을 것입니다.

이러한 점을 종합했을 때 남은 언어들 중 상대적으로 스칼라가 실론 등에 비해서는 훨씬 넓은 저변을 확보하고 있으며 최근 기술적 추세가 된 이벤트 중심 아키텍처나 함수형 접근 등에 보다 최적화된 특성을 보이는 점을 감안하면, 자바의 대안 언어를 찾는 개발자가 스칼라 언어를 우선적으로 고려하는 것은 합리적인 선택이될 수 있다고 봅니다.

글을 마치며

마음 같아서는 논란이 되었던 글에서 언급된 근거들 보다는 좀 더 설득력 있는 내용으로 스칼라의 기술적 장점에 대해 논해보고 싶다는 생각이 듭니다. 하지만 제가 그런 글을 쓸 수 있을 만한 시간적 여유나 기술적 식견을 갖추고 있는 지는 스스로 상당히 의문이 드는 상황이기 때문에 지금 시점에서는 확실한 말씀을 드리긴 어려울 것 같습니다.

하지만 이런 식으로 기술 외적인 측면에서 자바 이외의 언어를 배워야 하는 이유에 대한 생각을 공유해서 이전처럼 무의미한 언어 간의 자존심 대결 대신 좀 더 차분하고 유익한 논의를 이끌어 낼 수 있다면 그 자체로 어느 정도 의미는 있는 시도가 되었으면 하는 바램이 있습니다.

긴 글 읽어 주셔서 감사드리며, 혹시 앞으로 스칼라에 대해 기술적인 이야기를 할 기회가 있다면 계속 관심을 가지고 지켜봐 주시기를 부탁 드리겠습니다.