태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
BLOG main image
Not so Simple World (251)
이생각 저생각 (92)
이클립스 RCP (10)
Books (15)
잊기전에 회고 (7)
Better SW Development (83)
node.js (OctoberSkyJs) (32)
[뭘, 이런걸 다?] (12)
bảng giá máy tính xách tay
bảng giá máy tính xách tay
Beer Brewing Tutorials
Beer Brewing Tutorials
harga alat kesehatan spirometri
harga alat kesehatan spirometri
air max pas cher
air max pas cher
veste parajumpers
veste parajumpers
«   2017/11   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
847,657 Visitors up to today!
Today 214 hit, Yesterday 611 hit
rss
tistory 티스토리 가입하기!
Recent Entries
2010.09.27 08:30

IBM dW 기사중에 바쁜 자바 프로그래머를 위한 스칼라 입문 이라는 멋지고 재미있는 연재글이 있습니다. 함수형 언어 중 하나인 스칼라에 대한 소개글인데, 바로 읽기에는 조금 어렵거나 지루할 수 있습니다. 특히나 처음 함수형 언어를 접하면 저와 동일하게 '으응? 뭐래?' 라는 식으로 제대로 읽기 어려울 것도 같다는 생각이 들었습니다. 관련해서 조금 돌아가지만 대신 차분히 접근할 수 있기 위해서 추가 글을 남겨봅니다. 군데군데 개인적인 사견이 많은 글이니 혹시라도 울컥!하진 마시고 적절히 걸러가면서 보세요. :)


붉게 빛나던 루비(Ruby)는 우리 곁을 어떻게 지나갔던가?

2000년대 중반, 그러니까 2005~2007년 정도쯤에 새로운 언어로써의 루비의 인기는 대단했다. 루비 온 레일즈(Ruby on Rails)라는 걸출한 프레임워크의 인기와 함께 언어 자체가 새롭게 조명되었고 많은 엔지니어들이 루비를 배웠다. 그 안에는 나도 있었다. 물론 나의 경우는 '호기심 천국'이라는 성격이 크게 한몫 했지만 유행이라는 파도에 휩쓸려 두둥실 떠다녔던 건 부정할 수 없다.

개인적으로는 적지 않은 시간을 루비에 투자했었는데, 이젠 기억도 잘 안난다. 배웠지만 안쓰다 보니 무민(無民)과 동급이 되어버린 고등학교시절의 제2외국어 같이 변했다. 아쉽다. 손은 근질 거리는데, 루비로 한 것이 없다. Toy Program만 짜다 말았다. 사무실에 함께 할 사람이라도 있었더라면 좀 달랐을까?

글쎄.. 사무실 동료들에게 루비 써 본적 있냐고 물어보면 새로 나온 마스크팩이냐고 되물음 당할 가능성이 농후하다. 그게 현실이다. (비난의 의도는 전혀 없다.)


[미안. 난 너의 베프가 되진 못했네..]


아쉽지만 적어도 우리나라에서 루비는 주류가 되지 못했다.

루비뿐인가? .net도 마찬가지다. 우리나라에서 닷넷을 처음 런칭하던때, 난 큰 정부 사이트의 운영팀소속 사원이었는데 부장님께 이야기 드리고 참석했던 기억이 난다. 그때 부장님은 닷넷이 서버이름인지 새로 오픈한 PC방 이름인지도 잘 모르셨을테지만 믿고 보내주셨다. 사원입장에선 참 감사했다. 어쨌든 그때 초대형 국어사전 크기의 C#책을 받아와서 한동안 공부했었던 기억이 난다. 한동안은 개발자들 사이에서 'C# vs JAVA, 뭘 선택할거냐'에 대한 논쟁과 토론도 참 많았었는데, 지금 생각해 보면 그런 논쟁할 시간에 책이나 한 권 더 읽었더라면 조금은 더 도움이 되었었지 싶다. 어쨌든,

.net도 주류가 되지 못했다.

그저 자바가 그 때도 지금도 쭉 대세(였)기 때문이다.

'에라이~ 대세가 뭐 그리 중요하더냐? 재밌고 즐거웠고, 견문을 넓히는데 도움이 되었으면 되었지~'

라고 자기위안을 하지만, 역시나 씁쓸한건 .net으로도 변변히 만들었던 제품에 대한 기억이 없다는 거다. 그저 in-house 레벨의 토이프로그램 수준이 고작이었고, 또 마찬가지로 몇 달 배우다 그만둬버린 '살사춤(헉!)' 같은 존재가 되었다. 차라리 그 시간에 자바나 더 들어 팔걸 하는 생각이 들었다.


[알아. 인정할게. 비쥬얼 스트디오는 끝내줬었어. 그 당시엔 특히나 말이지]


JAVA, 주류이나 지루하다

자바가 나온지 15년이다. 우리나라에서 본격적으로 쓰이기 시작한지도 10년이 훌쩍 넘었다. 자바는 java 2라고 불린1.2 버전이 98년에 나왔고, 그 뒤로 매 2년마다 정확히 잰듯 Major 버전업을 해왔다. 그게 JAVA 6(=1.6)이 나온 2006년까지의 일이다. (java 6 - java 2 = 4, 4 * 2 = 8년. 1.2가 98년 + 8년은 2006년. 칼같이 맞추고 있다!)

현재는 2010년이다. 제대로 왔다면 java 8이 나왔어야 할 시기지만 갈팡질팡 자바는 7버전 조차도 언제 나올지 미지수다. 적지 않은 사람들이 답답하고 지루해 했다. 그래서 프레임워크를 다량으로 만들어 내기 시작했다. 언어가 부족하거나 한계가 느껴지면 자연스레 '프레임워크'가 많아지는 법이다.


[자바 프레임워크만 적은 거래요. - from apache wicket ]


그래도 갈증은 가시지 않았다.

복잡도가 높은 시스템은 점점 많아져 갔다. 소프트웨어를 더더 잘 만들기 어려워졌다. 시스템이 감당해야 하는 규모도 점점 증가해 갔다. 마찬가지로 더더 잘 만들기는 더더더 어려워졌다. 디자인패턴도 써보고, POJO로 돌아가도 보고, 스레드 프로그래밍을 위한 패키지도 증가해 나갔고, 상태저장을 배제하는 immutable에 대해서도 관심이 높아져 갔다. 그래.. 클로저(closure)... 루비를 비롯해서 다른 언어들에선 지원해 주는 클로저 개념은 자바를 계속 괴롭혀갔다. 도메인 스페... 아. 뭐더라. 맞다. DSL(Domain Specific Language)! 누군가가 도메인주도설계(DDD)와 DSL 이야기만 하면 자바는 자꾸만 작아져 갔다. 그때마다 많은 사람들이 말했다.

'자바언어의 한계가 왔다.'

아니, 한편으로는 그랬으면 좋겠다고 믿기 시작했는지도 모르겠다. 그래서 대안언어 중에서 차세대 주류언어감을 찾기 시작했다. 한때, 자바진영에서 프레임워크의 춘추전국시대라고 말했다면, 지금은 JAVA 대안언어의 춘추전국시대가 아닌가 싶다. 특히, 함수형 언어(Functional Language)가 그 선봉에 서 있는 것처럼 보인다. 적어도 나에겐 말이다.

그래! 함수형 언어(Functional Language)는 어때?

일반적으로 함수(function)라는 개념은 '상태를 가지지 않고 각각의 호출이 상호 간섭없이 배제적으로 실행가능하다'는 특징을 갖는다. 따라서 함수는 클래스와 달리 병렬호출시에 부작용이 적다. 따라서 이런 방식을 지향하는 함수형 언어는 필요한 만큼 분할해서 처리하도록 만드는 스케일업(Scale-up)이 용이하다. 대용량처리, 스레드 처리에 강점을 갖을 수 밖에 없다.

개념자체는 나온지가 적잖이 되었지만, 소위 말하는 아카데믹한 수준에서의 사용이 대부분이었다. 그러다가 근래에 들어서면서 산업영역에서도 응용해서 사용하기 시작했다. 그 대표적인 예가 스웨덴 통신사 에릭슨의 fault-tolerant(내고장성) 시스템 구축을 위해 만들어진 얼랭(Erlang)이다. Erlang의 경우 Facebook의 chat 서비스에서도 사용되고 있다. multi-core cpu환경에서 heavy trasaction처리에서 확실히 우위를 갖는다고 한다. 요즘 한참 NoSQL중 하나로 주가를 올리고 있는 Apache CouchDB 도 얼랭으로 만들어졌다. 뭐, 그 뒤로 해스켈(Haskell)을 비롯한 언어들이 만들어지고 사용되고 있다. 최근에는 JVM위에서 동작하는 스칼라(Scala)와 클로저(Clojure, j에 주의!)가 자바 개발자들 사이에서 각광받고 있다. 이에대해서는 뒤에서 따로 더 살펴볼 예정이다.

[어얼~ 랭?]


함수형 언어는 현재 주류를 이루고 있는 언어를 imperative (명령형) 프로그래밍 언어로 규정한다. (명령형 프로그래밍이라는 단어는 이전부터 있었다고 말하는 사람도 있지만, 함수형 언어의 대두 전까지는 그렇게 부르는 경우가 많지 않았다는 점에 주의를 기울이자.)

델파이, C, C++, JAVA, C# 등등은 각각의 프로그래밍 명령어가 프로그램의 상태를 변경시키는 형식으로 일을 처리하는 대표적인 명령형 프로그래밍 언어이다. functional과 imperative, 둘 사이를 가로짓는 특징은 state(상태)와 mutable(변화하는)이라는 단어로 표현된다.

state : 상태를 전역(static)으로 저장가능하게 할 것인가? 아니면 로컬 영역 한정으로 최소화 할 것인가?
mutable : 데이터를 주고 받을 때 전달되는 값 자체를 변경가능하게 할 것인가? 아니면 변경불가하게 하거나 클론복사(clone copy)하는 형태로 오리지널을 훼손하지 않게 만들 것인가?

물론 기존 언어(자바 등)에서도 선택이 가능한 부분도 있지만, 언어 차원에서 제약을 가하는 형태로 지원할 것인가는 좀 다른 이야기다. 그 외에는 언어부류 구분 자체를 가로지을 만한 요소라기 보다는 부수적인 특징이라고 생각한다. (좀 더 복잡하게 나가자면 일급객체(First-class object)일급함수(First-class function)등의 개념도 나오는데, 그건 우선 넘어가자. 다음에 좀 더 이야기 할 예정이다.) 함수형 언어에 대해 의욕이 생긴다 싶으면 위키피디아를 검색해 보자. 좀 더 즐거운 자료들이 기다리고 있다. 만약 영어글과 링크들이 부담스럽다면 서점에 가서 아래 소개할 책을 들고 10분정도 시간을 들여 해당 부분을 살펴 볼 수도 있다.

조엘온 소프트웨어를 넘어서(more Joel on SoftWare, 이해일 옮김)의 스물 두번째 이야기 제목 "여러분 프로그래밍 언어는 이런거 됩니까?"

(중략)
함수형 언어를 이해하지 못한다면, 구글에게 엄청난 확장성을 제공한 맵리듀스(MapReduce)같은 멋진 알고리즘을 절대 생각해내지 못합니다. 사실 "맵"과 "리듀스"라는 용어부터가 리스프(Lisp)와 함수형 언어에서 왔습니다. (중략) 순수 함수형 언어로 작성된 프로그램은 사이드 이펙트가 없어서 쉽게 병렬 처리가 가능하다는 사실을 기억하는 사람에게 맵리듀스는 그다지 어려운 알고리즘이 아닙니다.

(하략)

7페이지 남짓의 짧은 글이지만, 함수형 언어의 필요성과 장점을 적절하고 재미있게 설명해 주고 있다. 거기에다 덤으로 구글의 맵과 리듀스에 대한 개념도 살짝 볼 수 있는 좋은 글이라 생각한다.


(중편으로 계속)
저작자 표시 비영리 동일 조건 변경 허락
신고