fender
16k
2015-04-04 15:22:16
27
52858

자바가 아닌 다른 언어를 배워야 하는 이유


들어가는 말


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

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

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

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

그래서 처음부터 진지하게 스칼라 언어의 기술적 장점들에 대한 강좌를 쓰는 것보다는 우선 시간을 내서 자바 개발자로서 자바가 아닌 다른 대안 언어를 배워야 하는 이유를 먼저 되짚어 보는 것도 의미가 있을 것 같다는 생각이 들어 글을 쓰게 되었습니다. 그런 만큼 내용에 두서가 없거나 다소 깊이가 부족하더라도 미리 양해 부탁드리겠습니다.


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


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

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

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

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

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

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

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


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


2010년, 자바 진영을 이끌던 썬 사가 오라클에 인수 합병되면서 자바의 미래에도 어둠의 그림자가 드리우기 시작합니다. 한편, 거의 비슷한 시기에 node.jsangular.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), 실론, 코틀린 등 소수만이 자바스크립트로 컴파일해서 브라우저에서 구동할 수 있으며, 또한 자바스크립트에 비해 정적인 언어의 장점을 극대화하기를 원한다면 그루비와 같은 동적인 언어는 좋은 선택이 되지 않을 것입니다.

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


글을 마치며


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

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

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

50
45
  • 댓글 27

  • gem
    525
    2015-04-04 15:52:15

    이런 글을 원했어요 bbbbbbbb

    자바8, 자바스크립트 외에도 스칼라도 더 공부해보고 싶습니다. 기술적인 이야기 기대할게요 ^^!

    0
  • ranestar
    115
    2015-04-04 16:15:20
    좋은 글 잘 읽었습니다.^^
    0
  • booiljoung
    47
    2015-04-04 17:31:56
    역시 내공이 돋보이는 글! 잘 읽었습니다.
    0
  • smasma
    2k
    2015-04-04 18:14:11
    오옷..정말 주옥같은 글솜씨네요..ㅎㅎ.. 칼럼리스트라고 해도 무방하실 정도로 잘 쓰셨네요..
    0
  • TrustMe
    208
    2015-04-04 20:17:23
    이 언어전쟁의 끝이 Java의 승리일지 스카라의 승리일지 혹은 클로져의 승리일지는 모르겠지만, 앞으로도 자바는 지금처럼 계속 함수형 패러다임을 도입하고 문법표현또한 스칼라를 따라갈거라고 단언할 수 있습니다. 
    0
  • 서비스지향개발자
    7k
    2015-04-04 20:25:57

    1등은 항상 공격받기 마련입니다.

    jQuery도 많은 경쟁 언어로 부터 자기네 것이 훨씬 낫다고 공격을 당하고 있습니다.

    자바도 그만큼 입지가 높기 때문에 공격을 받는 것이라 생각합니다.

    오라클 인수에 대한 문제는 공감을 합니다.

    하지만 지금 무리하게 다른 언어를 해야할 필요는 없다고 생각합니다.

    수요와 공급의 원칙에 따라 급박하게 옮겨갈 필요도 없고 주력이 바뀌면 공급이 딸리기 마련이니 언제든 기회는 있습니다.

    다만 주력이 go가될지 스칼라가될지 

    어떤것이 될지 모릅니다.

    말씀하신 루비처럼 사라져갈지도 모르죠.

    개인적으로는 모든 언어를 조금씩 배워두고 필요에 맞게 활용하고 싶지만 저는 아직 자바도 깊질 않네요.  


    0
  • 하마
    6k
    2015-04-04 23:05:02

    잘 읽었습니다.

    저는 현재 4개언어를 사용해서 사물인터넷분야에서 개발 중이며 함수형 언어등에도 관심을 가지고 있습니다.

    c++ 개발자들이 자바를 공부했으면하는 생각과 동시에 자바 개발자들이 헤스켈 or 클로저를 보면 더 재밌을거 같다라고 생각은합니다.  임백준씨 책 처럼 굳이 머리 안굴려가며 재밌게 읽을수있는 책도 많아 진거 같습니다.

    여서부터는 본문하고 좀 상관없는 내용이어서 좀 죄송하지만 몇자  남겨볼까합니다.

    전에 제가 쓴 글이 이글을 읽고나서 다시 느껴지는게 함수형언어 혹은 함수형쪽에 가까운 멀티패러다임 언어가 자바나 c++을 제치고 대중화되긴 힘들거 같다는  확신이드는건 왜일까요.

    누군가 현재 미국에서는 스칼라가 많이 쓰인다느니..자바,c#,javascript들도 함수형계열 아이디어를 앞다투어 차용하지 않느냐? 다음세대는 함수형 페러다임에 쉽게익숙해질거다.등등

    흠흠 단순하게 생각하면 그럴수도있겠습니다만..

    근데 함수형패러다임은 아시다시피 요즘 튀어나온거도 아닐뿐더러  최근 스칼라로 코딩하는 데 이상한 우월감을 느끼는 몇몇 수준이하의 사람들처럼 옛날부터 Lisp 등에 자부심을 갖고있는 사람들은 존재했었지요.근데 lisp  은?

    최근들어 분산환경이나 멀티코어를 적극적으로 활용해야하는 시대가 되기도 했고 사람이라는게 예전것,오래된것은 쿨하지 못하다고 생각하는것등이 합쳐지면서 함수형패러다임의 고유의 장점들과 합쳐지면서 각광을 받습니다만..

    15 년전에 lisp을 처음봤을때부터 느낀게 함수형은 이질적이다라는거죠. 사고방식 자체가 어려워요. 보통어렵다는 C++ 가 훨씬 코드리딩하는데 쉽게 다가왔었습니다. 자바는 더 정제되서 깔끔하구요.  제가  머리가 안좋아서 그런거겠지만 "해커와 화가" 쓴 그 친구 수준의 개발자가 기준이 될수가 없잖습니까. 글쓴님처럼 경험과 지식이 많은 노련한 개발자조차 고군분투 하시는데요.


    고로 여러언어에서 함수형언어의 아이디어는 가져오겠지만 그리고 스칼라를 예로들면  기존에 C++ 의 boost split 보다 훨씬 파서구현에 용이하기때문에 특화되서 사용된다든지,akka  를 사용하는 솔루션이라든지 사용처는 충분히 존재 하겠지만 그런식의 코드가 대중화되거나 (c++ 에서 단지 함수자,함수형 헬퍼들조차 10년지난 아직까지 대중화 되지 않은 사례,템플릿메타프로그래밍은 말할것도없고) 함수형언어가 객체지향언어를 제치고 메이져가 될꺼라는 생각은 전혀안드네요. (글쓴님이 이런 주장을 했다는건 아닙니다. 글을 안 읽고 댓 다는 사람이 많아서;;) 한 20 년후에 어찌될지 굉장히 기대됩니다. 


    ps.

    다양한언어가 공존해야한다는것을 부정하는글이 아닙니다.

    오해하시는분 계실까봐 적는데..스칼라,클로저 공부 할 필요없다 라는 글도 당연히 아닙니다.

    2
  • fender
    16k
    2015-04-04 23:40:15

    하마 // 물론 스칼라에서도 예컨대 마음먹고 반복문 대신 재귀 호출만 사용하고, API 설계에 고차함수도 적극 활용하고, ShapelessMonocle 같은 라이브러리도 쓰고 그런식으로 본격적으로 함수형에 치우친 접근을 한다면 분명 객체지향에만 익숙한 개발자들에게 익숙하지 않게 느껴질 수는 있다고 봅니다.

    하지만 멀티 패러다임 언어인 스칼라의 특성상 아무도 그런 식의 접근을 강제하지 않으며, 말씀하시는 보통 수준의 개발자들이 람다식이나 컬렉션의 map이나 filter와 같은 간단한 메서드만 주로 활용한다고 가정해도 그 정도만으로도 충분히 의미 있는 이득을 취할 수 있다고 생각합니다.

    어차피 자바에 람다식이 들어가게 것도 최소한 위에서 언습한 수준 이상의 함수형 접근을 전제로 한 것입니다. 단순히 익명 클래스 정의시 한 두 줄 타이핑을 줄이려는 의도였다면, 아마도 람다식이 수 년 간 자바 개발자들이 차기 버전에 가장 크게 기대하는 기능으로 꼽히는 일도 없었을 것이라고 생각합니다.

    사실 저는 스칼라가 진입 장벽이 매우 높은 언어라고 생각합니다. 하지만 그 난해함의 대부분은 함수형 언어의 특징보다는 복잡한 타입 시스템에 기인한다고 보고 있습니다.

    1
  • benelog
    68
    2015-04-05 06:19:38
    다른 대안 언어를 공부해야지 Java도 더 세련되게 쓸 수 있다는 점에 무척 공감합니다. 다만 아직도 Java5의 Enum, Generics도  제대로 활용 못하는 개발자들을 보면  Java5 그 자체만이라도 먼저 제대로 공부한 개발자가 더 많았으면 하는 생각도 듭니다.

    그리고 Java 개발 환경을 더 개선하기를 원하는  SI개발자들이 할 수 있는 가장 현실적인 선택은 프로젝트에서 현재 쓰고 있는 Java의 버전을 Java8로 올리기나, 부분적으로 Groovy나 Scala를 도입해서 Java와 섞여쓰는것이 아닌가하는 생각이 듭니다. 따로 시간을 내어서 개인적인 프로젝트를 하지 않는 한, node.js 처럼 아예 실행환경을 바꾸는 선택보다는 JVM 기반의 언어가 이해당사자 설득이나 레거시코드와의 연결 등에서 유리하니까요.

    현재 쓰는 JVM버전에 있는 버그나 성능 개선의 이유를 들어서 JVM의 버전을 올리는 일이 아예 플랫폼 자체를 바꾸는 것보다 쉬울 것 같습니다. Oracle의 버그리포트를 보면 문법이나 라이브러리 요소 외에도 최신 JVM의 버그픽스, 개선사항들이 꽤나 많습니다. 이미 많은 분들이 아시다 싶이 Java8의 람다는 Java8이전에 나온 라이브러리나 코드에도 적용될 수 있는 인터페이스로 참조되는 방식입니다. Runablle, Callable이나 Spring의 RowMapper처럼, 메서드 1개짜리 인터페이스를 구현한 익명클래스는 람다로 바꿀 수 있습니다. 그래서 수많은 라이브러리가 모두 람다나 Optional을 적극적으로 지원하는 시점이 되어서야 자바개발자들이 Java8을 제대로 쓸 수 있을 것이라는 염려는, 람다에 대해서는 아주 크게 할 필요는 없다고 저는 생각합니다. 물론 기존의 라이브러리에서 여러 메서드를 담은 인터페이스들이 메서드 1개짜리로 쪼개지거나 java.util.function. 패캐지의 인터페이스를 받아주는 형태로 바뀌어야 보다 람다친화적인 라이브러리가 될 수는 있겠습니다. Spring은 4.1에서는  Optional도 적극적으로 지원하고 있기도 합니다.

    또 다른 접근법이라면 Retro-lambda ( https://github.com/orfjackal/retrolambda) 프로젝트를 이용해서 java5,6,7에서도 람다를 쓰는 방법도 있습니다. 안드로이드 같이 익명 클래스를 많이 쓰는 환경에서는 적극 고려해볼만해 보입니다.

    그리고 프로젝트에서 부분적으로 Groovy 등을 가볍게 활용하는 접근도 부작용이 없고 실용적이라고 생각합니다. 예를 들면 Spoke를 이용한 테스트나 템플릿/SQL등 긴문자열의 선언에  Multiline string을 활용하는 것들입니다. 혼자하는 프로젝트가 아닌한, 부분적으로 써서 주변의 지지자를 넓혀야 하나의 컴퍼넌트 전체를 java외의 다른 언어로 개발할 수 있지 않을까 생각합니다.

    개인적인 프로젝트에서 Groovy, Scala, xTend, Kotlin, Ceylon으로 Java코드와 섞어 쓰는 시도를 해봤었는데, IDE지원등 여러가지를 생각하면 Groovy나 Scala가 아직까지는 무난해보였습니다. Kotlin은 Eclipse plugin쪽이, Ceylon는 IntelliJ plugin이 각각의 Plugin 중앙 저장소에 올라가 있지 않나서 소스를 직접 복사해서 빌드해야하고,  xTend은 IntelliJ 플러그인이 아예 없었습니다. 그리고 Ceylon의 독자적인 모듈 시스템은 혁신적이기는 하나 기존의 jar 라이브러리와 섞어 쓰고, Ceylon코드를 Java에서 다시 호출하기에는 처음에 진입 장벽과 불편함이 있었습니다.

    Kotlin이나 Ceylon에서 비슷하게 JVM과 Javascript에서 동시에 실행될수 있는 시도를 한것을 보고 이런 시도가 성숙해진다면 Javascript가 아닌 언어로도 Front와 Backend를 함께 개발할 수 있는 날이 오지 않을까하는 생각도 했습니다. Fender님도 비슷한걸 보신것 같네요.

    4
  • fender
    16k
    2015-04-05 09:59:02

    benelog // 전적으로 공감합니다. 처음 제너릭을 사용하기 위해 자바5로 업그레이드 할 때도 비슷한 전략을 사용하던 기억이 납니다. 소개하신 레트로핏 라이브러리도 또한 유용하게 사용할 수 있을 것 같습니다.

    아마도 업무 환경에서는 우선 말씀하신 방법대로 자바 8이나 레트로 람다 등을 적극 도입하고, 오픈 소스 개인 프로젝트 등을 통해 틈틈히 간단한 프로그램부터 다른 언어를 접해보는 방식이 가장 이상적인 접근이 되지 않을까 싶습니다.

    마지막에 언급하신 프론트엔드와 백엔드를 함께 개발하는 방식은 이미 스칼라.js를 통해 실무 프로젝트에 적용해서 개발 중입니다.

    나름대로 미지의 영역이라 상당히 흥미로운 구석이 많더군요. 간단하게는 우선 VO에 해당하는 케이스 클래스 등 공통 클래스는 모두 클라이언트와 서버가 공유하고, 크로스 컴파일을 통해 테스트 프레임워크 등 몇몇 라이브러리도 양 측에서 동일하게 적용하고 있습니다.

    가장 마음에 드는 점은 서비스 계층을 클라이언트에서 직접 호출할 수 있다는 점인데, 서비스 트레잇을 사이에 두고 내부에서 인자와 반환형은 json 직렬화를 통해 자동 변환하고, HTTP 상태 코드와 예외를 상호 변환하는 식으로 꽤나 깔끔한 통합이 가능했습니다.

    지금은 약간 욕심을 내서 아카의 타입드 액터로 구현한 서비스의 메시지를 클라이언트에 그대로 전달하는 구조도 고민중인데, 다른 사람들을 보니 기술 검증 수준일 뿐이지만 아예 액터 시스템 자체를 통합해버리려는 시도(scala-js-actors)까지 하는 듯 해서 흥미롭더군요.

    아무튼 JVM이나 스칼라의 미래가 어떻게 될지는 모르지만 살아 남는다면 머지 않은 미래엔 꽤나 재밌는 모양으로 발전하게 될 것 같다는 생각이 듭니다.

    2
  • 하마
    6k
    2015-04-05 20:50:18

    fender //

    스칼라를 쓰면서 단지 제공되는 functor util 쓰는것에 대한 이득만으로 스칼라를 사용하는건 낭비라고 보구요. 말씀대로 강제하진 않지요. 잡종인 이유가 그런회유책이니깐요. (C++ 처럼) 자바도 대략 다 지원하는데 굳이..

    결국 C++ 을 제대로 쓰려면 자바등을 공부해야 하는 or  하면 좋은것처럼 스칼라도 제대로 쓰려면 그 실제 철학을 잘알아야 하는데

    아시다시피 스칼라는 이름이 나타내는것처럼 추상을 극대화하는것을 쉽게 해주며  언어를 사용하는 사람이 언어내에서 다른언어를 만들수있을 만큼 자유도를 높여주고자하는 철학을 가지고 태어났으며  그것을 이해하고 사용하려면 

    소위  함수형프로그램의 특성인  상태불변성,일차/고계함수,클로저, 모나드등 뿐만 아니라 트레잇,  타입을 요리할수있는 능력이 필요한데요.

    일단 저런것에 대한 helloworld 로 간단한  파서를 만들어보는게 가장 빠르겠지요.. 굉장히 간결해보이긴 합니다만..

    이 모든것들이 많은 대중적인 소프트웨어에서 필요로 하는것 이상인거 같습니다. 제 짧은 시야로는 저런 자유도가 오히려 부담감으로 다가오면서 객체지향언어와 그 동안 해온 동적언어만(필요한것은 LINQ  처럼 언어안에 포함및 라이브러리 제공)으로 계속가자 라는 분위기속에  점유율은 크게 변동이 없을것이며 더 간단하면서 강력한 이상향의 무기를 기다리며 시대가 흘러가리라 봅니다.

    ps.

    네이버라인에세 얼랭을 쓰고 S모사는 헤스켈을 쓰고 스칼라도 국내에 많이 사용되고있다고 알고 있습니다. 써야할곳은 쓰고있는것이고 대부분 필요없는곳은 안쓰는데 스칼라 or 함수형패러다임 안쓰면 뒤떨어지는 분위기를 구태여 okky 에서 조장할 필요가 없어 보여요. (이 부분은 논쟁의 여지가 많겠습니다만.자극은 중요하기에.. , fender 님이 조장한다는건 당연히 아닙니다. )

    가능할지 모르겠지만 쉽게 즐길수있는 토픽 정도로 종종 보면 그것으로 충분할듯..

    1
  • fender
    16k
    2015-04-05 22:11:59

    하마 // 글쎄요... 저는 여전히 하마님께서 스칼라의 함수형 언어적 요소와 그 난해함을 과장되게 평가하시는 느낌입니다만, '어려운 정도'나 '유용한 정도' 같은 문제는 객관적으로 옳고 그름을 따지기 어려우니 서로 의견이 갈리는 부분으로 남겨둘 수 밖에 없을 것 같습니다.

    시간이 된다면 실제 코드를 예제로 들면서 스칼라의 장점이나 난해함 모두를 다른 분들이 일부라도 직접 보고 판단하실 수 있도록 소개 글을 써보고 싶다는 생각이 듭니다.

    동어 반복을 피하기 위해 그 때까진 하마님과의 같은 주제에 대한 토론은 잠시 미뤄두도록 하겠습니다.


    1
  • smasma
    2k
    2015-04-05 23:59:34
    위에분들 내공이 장난 아니시네요..ㅎㅎ 부럽습니다.. js쪽 파고 있는중이라 그거 끝나면 스칼라도 좀 관심 가져봐야겠네요...
    0
  • otwm
    1k
    2015-04-06 01:16:37
    스칼라를 공부하신 분으로서 스칼라를 써야 하는 이유. 스칼라의 좋은 점에 대해서 개발자의 입장이나 또는 모르는 사람들을(사장님?? 또는 스칼라에 무지한 개발자들??) 설득하기 위한 의견(?)에 대해서 한번 언급해 주시면 좋을 것 같습니다.
    0
  • 아야나미
    2k
    2015-04-06 10:10:10

    본문의 중간에..


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


    아키텍트까지는 아니지만.. 어느정도 제 만족을 누릴 수 있는 수준까지 끌어올리기 위해서는 필수일까요..앞으로의 글 기대하겠습니다!



    0
  • benelog
    68
    2015-04-06 11:02:43

    아, scala.js 이미 쓰고 계시는군요. 써보신 경험을 간단하게라도 말씀해주셔서  흥미있게 읽었습니다. 앞으로도 기대가 되네요.



    0
  • 두둥스
    370
    2015-04-06 11:54:38

    이런글 너무나 좋습니다

    요즘들어 새로운 언어의 방향성에대해 목말라하고 있었는데

    패러다임보다는 코드의 품질/생산성만 고려하던 저를 돌아보게 하네요

    감사합니다 ^^

    0
  • 연구원
    195
    2015-04-06 12:41:46
    ^^ 존경합니다.  실력과 인성을 갖춘 분 인거 같습니다.
    0
  • 두둥스
    370
    2015-04-06 13:11:03

    그러고보니 왠지 처음에 어그로성 글을 쓰신분에게도 고마운 ^^;;

    그분이 혹시 이런 파급 효과를 노리고 일부러 ~

    아무튼 고수님들 난상토론에 눈이 즐겁습니다 ㅎㅎㅎㅎㅎ

    0
  • 초오찌
    5k
    2015-04-06 17:26:54
    뭐든 인성이 받쳐줘야 역시 ㅎㅎㅎ
    0
  • LaZyDev
    301
    2015-04-07 15:38:08

    좋은글 잘봤습니다

    근데 저는 스칼라보단 Python  Go 를 권하고 싶군요

    0
  • 잡초
    1k
    2015-04-08 09:42:36
    감사합니다
    0
  • 100m8cho
    391
    2015-04-08 18:00:13
    좋은글 읽고 갑니다. ~^^
    0
  • kdm3843
    65
    2015-04-10 10:52:45

    scala.js 는 사용해보지 못하였으나 대충 설명 보니... 너무 어렵게 느껴지네요 ㅠㅠ. 언어는 도구인데 너무 어려워요... 이건 뭐 자바스크립트도 아니고, 파이썬 같이 보이기도 하고.... 막 섞여있네요....

    node.js 이 경우 기본적으로 태생이 javascript 로 부터 나왔기 때문에 쓰레드 지원이 되지 않습니다. 현재로서는요. 물론 thread a gogo 나 webworker 등등의 모듈을 통해 지원은 하지만 이벤트 드리븐으로 대부분의 io 를 실행하는 node.js 의 기본 api 에서는 결국 저 모듈들을 써도 의미가 없습니다. 단지 단순하게 DB 호출과 같은게 없고 그냥 자기 로직만을 가지는 부분에서나 쓸 수 있죠. 아니면 아예 다른 언어로 만든 실행파일을 실행시키는 방식 등이 있겠지만 이런식의 프로그램은 아무 의미 없죠.

    아마도 node.js 의 버전이 0.12 정도에 머무르는 것이 아마 이런 이유 때문이 아닌가 합니다. 현재 node.js 의 기본 구조는 이벤트 드리븐, non-blocking io 입니다. 마치 웹브라우저의 javascript 그 모습 그대로인거죠. javascript 의 언어의 특성이 이러한 이유는 프로그램 위에서 돌아가는 언어이기 때문입니다. 가상머신도 없고 컴파일 되지도 않기 때문에 OS 깊숙히 관여할 수 있는 언어가 아닙니다. HTML5 에서 Webworker 나 기타 다른 RIA 엘리먼트들이 지원되기 전에는 Flash, ActiveX, Silverlight 같은 것을 통해서 이러한 것을 해결했었지요. javascript 로 프로그램을 짜다 보면 콜백 헬이라는 문제에 봉착합니다. 이 구조를 좀 이쁘게 변경할 수 있도록 promise 라는 것을 사용할 수는 있지만 근본적인 문제를 해결한 것이 아니기 때문에 어떤 로직을 짜든 조금씩 깊이 들어갈 수록 어려움에 봉착하게 됩니다. 여러개의 io 를 통해서 return 값을 받아서 서로 연산을 하고 반복문도 돌린 다음 웹으로 응답한다거나 하는 작업들이 들어가면 가능은 하지만 코딩 하는데에 있어 굉장히 어려움에 봉착하게 됩니다.

    TJ Holowaychuck 이 node.js 진영을 떠난 계기인 듯 싶습니다.

    하지만 이러한 이벤트 드리븐 방식은 프로그램 위에서 동작하기 위한 목적 외에도 서버 측에서는 굉장한 성능 이점을 가져다 줄 수 있습니다. cpu 를 선점하고 있지 않으며 메모리도 매우 적게 사용하게 되구요. 접속자 수에 따른 성능 이점은 거의 수백배 수천배의 차이를 보일 수 있습니다. 따라서 복잡한 로직이 없는 또한 매우 구조적이지 않은 간단한 개발에는 node.js 가 매우 매우 좋은 언어입니다. java 나 python 등과 같은 언어들과 다르게 환경 설정이나 웹서버 실행 등에 관하여 매우 단순하고 빠르게 작성할 수 있어서요. 아마존 서비스나 LoadBalancer 를 정확히 사용하지 않을 경우에는 서버의 대수는 대역폭이 더욱 중요하기 때문에 또한 결국 서버의 갯수는 늘어나야 할 수 있습니다.

    node.js 는 좋은 언어이며 javascript 는 결국 웹 프론트 엔드에서도 필수 언어이기에 커리어에 매우 좋은 언어임에 틀림 없습니다. 하지만 제 생각엔 아직은 0.12 버전이 적합한 언어인 듯 합니다. 서브로 사용하기에 매우 좋은 언어입니다. thread 없음과 이벤트 드리븐 동작 방식이 성능 이점을 가져오지만 구조화된 프레임웍으로 구성해 나가기에 매우 힘들고 결국 개발 생산성은 떨어지게 됩니다.

    따라서 주 언어는 OS 까지 관여하는 JAVA 나 Ruby 를 하시면서 node.js 는 서브로 하시는 게 맞는 것 같습니다.

    뭐 미래에 node.js 에서 다른 언어들과 비슷한 방식의 프로그램 방식을 추가하게 된다면 주 언어로도 사용할 수 있을 것 같습니다만 그건 더이상 javascript 라는 언어가 아니게 될 것 같습니다. 따로 학습이 필요한 언어가 되겠죠. 기본 문법이 조금 바뀔테니..

    저는 개인적으로 Ruby 를 추천하지만... JAVA 는 분명 좋은 언어입니다. 그런데 자유도가 높은 언어이며 스케일이 큰 작업을 할 때 사용하면 좋은 언어 같습니다.... 하지만 무언가 하나 만들기에 너무 시간이 오래 걸리는...

    python 같은 경우는 언어는 좋은데 웹서버 wsgi 나 장고 등등... 이런 설정이나 그런 부분들이 들어가면 결국 삽질의 연속이 될 거 같습니다.

    일단 웹 기술을 아주 깊이있게 마스터 하신 상황이 아니고 주니어 급이면서 대략적으로 어느정도 수준의 프로그램은 가능하나 아키텍트 수준에 이르지 못한 분이라면 RubyOnRails 를 추천합니다.

    Ruby 라는 언어도 매우 좋은 언어이며 (SmallTalk, LISP, Perl 의 장점을 따서 만든 언어입니다.) RubyOnRails 로 정석적인 웹기술의 틀을 따라가다 보면 올바른 방향으로 나아갈 수 있을 것 같네요. puppet, chef 와 같은 서버 자동화 툴의 경우 모두 ruby 로 만들어졌습니다. 최근 이슈되고 있는 docker 가 go 언어로 만들어졌구요.. 

    새로운 웹플랫폼을 만들고 적용할 수준의 분이라면 Java 가 ㅎㅎ... 물론 오픈 소스 진영의 마찰... 저런걸로 인해 입지가 좁아질 수도 있겠지만요...


    Go 언어는 C 언어 대용인 듯 합니다. 컴파일 되는 언어죠. 대신 스크립트 언어와 같이 GC 도 넣고 좀 더 사용자 친화적으로 만든언어...


    하지만... 뭐가 이리 많은거야!!!! 다들 좋은 점이 있지만 일단 좋은 방향을 선택하고 마스터 해나가는 것이 ...


    node.js 는 OS 에 관여하지만 javascript 라는 언어 자체의 특성에 따르다 보니 쓰레드나 io 호출 후 리턴받는 등의 방식이 현재 지원되지 않고 있다는 말... 을...


    1
  • kon
    1k
    2015-04-10 17:37:18

    이런 좋은 글은 칼럼으로 가야 되는거 아닌가요?

    정말 글부터 댓글까지 버릴게 하나도 없는데요!

    0
  • 리커버리
    4
    2016-02-27 13:11:21

    글쓴이와 댓글 다시 분들의 내공이 상당하시네요.. 좋은 글과 댓글들 잘 읽고 갑니다~^^

    0
  • 뽀롱
    10
    2016-06-23 00:29:41

    정말 공감이 많이 가는 글입니다~

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.