Programming in Haskell의 머릿글 원본

작년 12월 12일 즈음, 다음과 같은 편지를 받았다.

안녕하세요, 안기영입니다.

지금 MS에서 PSA로 일하고 계시다고 들었습니다. 제가 이번 겨울에도 한국에 12월 11일에 한국에 도착해서 1월 2일까지 있습니다. 이번에는 서울에 계시니까 제가 만나 뵈러 가기가 더 수월할 것 같습니다.

정훈이 형에게 이미 들으셨겠지만, Programming in Haskell 을 우리말로 다 옮겼고 좋은 리뷰어들이 많이 자원한 덕택에 교정 작업도 거의 끝났습니다.

저희가 하스켈 입문서를 본격적으로 우리말로 옮기게 된 계기도 SICP 우리말 판이 나온 것에 고무되었기 때문이므로 추천사는 김재우 부장님께서 꼭 써 주시면 좋겠다고 생각했습니다.

IT 실무자가 하스켈에 관심을 가질 만한 이유를 중심으로 쓴 옮긴이 머리말도 거의 완성되어 있으니 살펴보시고 오래 전부터 함수형 언어에 관심을 가지고 강의나 업무 등에 적용해 본 경험을 바탕으로 추천사를 써 주시면 많은 도움이 되겠습니다.

곧 연말이라 바쁘시겠지만 추천사를 연말까지 써 주실 수 있으면 제가 한국에 있을 동안에 원고에 추천사까지 포함해서 출판사에 넘길 수 있기 때문에 마무리 작업에 도움이 많이 될 것 같습니다.

그럼 한국에 도착하면 다시 연락드리겠습니다.

감사합니다.

Ahn, Ki Yung

그리고 오랜 시간이 흘렀다. 새로운 일터에 맞추어 살다 보니 글 쓸 샘이 말라 죽었던 것일까. 어쨌거나 이 뜸한 블로그에 글 한 줄 남기기도 벅찼던 게 사실이다. 손도 못 대고 있다가 4월 마지막 밤에, 아래 같은 글로 답신을 보냈다. 곧 출판될 Programming In Haskell이란 책의 머리글 (추천사) 원본.

"Haskell로 프로그램 짜보니까 어떤 느낌 들어요?"

안기영씨에게 짤막한 서평 써달란 부탁을 몇 달 전에 받았지만, 이런 프로그래밍을 해온 지도 벌써 스무 해가 다 되어가는지라 왜 Haskell 같은 언어로 프로그램 짜는 법을 다시 배워야 하는 지를 가슴 벅차게 전할만한 신선한 감정이 좀처럼 일어나질 않았다. 고민 끝에 같은 부서에서 일하는 김부장에게 물었다. 내 꾐에 넘어가서 처음으로 F#나 M같은 언어를 쓰고 있고, 그 가운데 자연스럽게 Scheme이나 Haskell 프로그래밍도 맛보게 된 사람인데다, 지금까지 C#, Java, C/C++ 같은 언어로 십 수년간 프로그램 잘만 짜던 사람이라 그 견해나 평가가 궁금하던 차이기도 했다. 전화기 너머로 한 참 뜸들이는 기척이 느껴지더니, 아주 간단한 답으로 이야기를 시작했다.


"아주 또렷하죠.”

맞다. 그랬다.


“그러니까, 풀려는 문제와 답을 쓰는 일이 아주 가깝다는 느낌이 들어요. 그런데도 자연스럽게 어떤 틀이 잡혀간다는 점이 달라요."

"여태 쓰시던 프로그래밍도 표현력이나… 특히 그저 어떻게 돌아가는 코드를 짜기보다 좋은 설계를 강조한다고 볼 수 있지 않을까요?"

"네, 뭐 그렇기는 하죠. 그런데 다른 점이 뭐냐 하면, 제가 보통 전체 프로그램의 틀을 한 눈에 파악하면서 일하는 것을 좋아하는데, 이 경우는 그런 목표를 이루는 게 훨씬 자연스럽다고 할까… 보통 튼튼한 구조를 갖추려면 문제의 해답을 드러내는 코드보다 구조를 짜맞추는 코드가 늘어나는 경우가 다반사인데…이 경우는 그렇지가 않아서, 문제 푸는 방법을 표현하는 데 애쓰다 보면, 그 과정에서 프로그램이 좋은 구조를 갖출 수 있게 된다는 것이 참 즐거운 경험이랄까…. 그러니까 예전에는 잘 설계된 프로그램을 짜려면, 설계 패턴(Design Pattern)도 정확히 이해하고, 문제도 정확히 이해해야 하는 데, 그 둘이 완전히 나누어 져서 적지 않은 부담이 되거든요. 실제 시간이 촉박한 경우에는 뭐가 옳은 지 알고는 있지만, 실천하기도 쉽지 않고. 한데, 이 번에는 문제 푸는 방식 그대로를 충실히 표현하려는 데 신경을 쓰고, 작든 크든 나눌 수 있는 것은 나누고 불필요한 제약을 차근차근 없애기만 하면, 틀이 잘 잡힌 프로그램을 이끌어낼 수 가 있다는 거죠."

이 대답에 마치 모르던 것을 알게 된 것처럼 연거푸 '그렇구나'하는 추임새를 넣어가며 얘기를 듣다가, 맨 처음 이런 언어로 프로그램을 배우게 되었을 때 느꼈을 법한 옛 느낌이 가물가물해서 뻔하다 싶은 질문을 이어 던졌다.


"처음 만져 봤을 때는 어땠어요? 받아들이기가 쉬웠어요?"

"에이, 아니죠. 처음에는 엄청 충격이었죠, 이건 뭐, 줄곧 상태를 바꾸어가며 프로그램 짜던 게 몸에 배인 사람인데, 일부 가능하다고는 하지만, 변수 값 그러니까 상태를 아예 바꾸지 않는 것이 이런 방식의 기본기라고 하니까… 그런 이상한 (웃음) 생각으로 프로그램을 짜려니까 처음에는 참…"

"이런 프로그래밍 방식을 처음 익히는 사람에게 어떤 얘기를 해주고 싶어요?"

왜 난데 없이 밤에 전화를 걸어, 이런 질문을 던지는 지 앞뒤 연유를 찬찬히 설명한 다음 마지막으로 던진 질문이다.


"간단하죠. 알던 것은 잊어라. 그 편이 배우기 쉽다. 뭐 그런 말? (웃음)"

그럴 법도 하다. 나도 처음에는 그랬다. 하지만, 모두는 곧 알게 될 것이다. 이런 낯선 과정이 지나고 나면, 끝내 프로그램이란 것은 문제 푸는 방법을 옮겨 담는 일이요, 언어의 표현력이란 그 방법 그 자체를 있는 그대로 표현하는데 얼마나 큰 공을 들이느냐로 판단할 수 있다는 사실을. 그에 이르면 문제를 보고 언어를 고르는 법이지, 문제를 언어에 맞추지 말아야 한다는 데 동의할 수 밖에 없다. 그리고 어는 순간 모든 게 같아진다. 알던 것이나 알게 된 것이나 모두 같게 보이는 때가 온다. 공부를 멈추지 않는다면 반드시 말이지.

이 책은 Haskell이란 언어로 프로그램 짜는 법을 일러주는 책이다. 하지만, Haskell이란 언어에만 집중하지 않았으면 한다. 프로그램 짜는 법을 공부할 때, 생각의 틀을 잡는 방법보다 언어 배우기에 골몰하는 것은 언제나 바람직하지 않다. 물론, Haskell이란 언어가 돋보이기는 한다. 비할 데 드문 수준 높은 표현력을 갖추고 있으면 서도, 언어의 알맹이는 지극히 작고 그 의미가 명료하여, 애매하게 짠 프로그램에서 답이 나오는 경우가 드물고 언어의 허점을 교활하게 활용하여 잔재주 부리는 코드를 쓰기가 쉽지 않다. 하지만, 이런 장점을 갖추고 이런 식으로 프로그램을 짜는 언어는 Haskell 하나가 아니다. 이와 견줄만한 언어도 얼마든지 많다. 다만, Haskell은 연구 공동체에 의하여 설계되고 실현되었으며, 다른 언어에 비해 좀더 많은 관심을 받아 널리 알려지는 운을 타고 났을 뿐이다. 따라서 이미 이런 프로그래밍에 익숙해진 사람이라면 굳이 이 책을 읽으라 강요하기는 어렵다. 물론, Haskell이란 언어를 빨리 익히려 한다면 괜찮다.

하지만, 그와 달리, 지금 까지 이런 식으로 프로그램을 짜본 경험이 전혀 없었다면, 이 책에서 쓰고 있는 언어를 돋보이게 하지 않고서는 굳이 이런 책으로 공부할 까닭을 스스로 일깨우기가 쉽지는 않다. 왜냐면, 말은 생각을 드러내는 수단이기도 하지만, 동시에 생각을 가능하게 하는 수단이기도 하기에, 생각은 말에 갇히고, 말은 다시 생각에 갇히기 마련이다. 언어에는 문화와 경험과 이론과 사상이 담겨있기에, 아무리 자유로운 생각도 그 표현 수단인 언어의 영향권을 벗어나기 어렵기 때문이다. 다시 말해, 재료의 성질과 품질이 음식의 맛과 품질을 가늠하듯이, 생각의 색깔과 품질은 그 재료가 되는 언어의 장단점을 벗어나서 논하기 어렵다. 알맞은 재료, 싱싱한 재료는 좋은 음식을 만드는 데 기본이다. 프로그램도 마찬가지다. 물론 알던 것을 깨부수고, 새로운 것을 배우는 일은 어렵다.

그래서, 선의 격언 가운데 이런 말이 있다.


"처음 차를 마실 적엔 차는 차요, 찻잔은 찻잔이다. 차를 배우기 동안에는 더 이상 차는 차가 아니고, 찻잔도 찻잔이 아니다. 끝내, 차를 알게 된 다음엔 차는 다시 차요, 찻잔은 다시 찻잔이다."

(기가 막힌 글귀다. 이 보다 배움이 무엇인지를 또렷한 알려주는 표현을 찾기란 쉽지가 않다.) 새로운 것을 배우는 것은 언제나 이러하다. 그리고 이런 배움에는 용기가 아닌, 재미가 필요하다. 재미없는 것은 노력으로 익숙해 질 수는 있을 지 언정, 진짜로 배울 수가 없다.

이 책을 옮겨 쓴 사람도 그러했을 것이다. 이런 책을 옮겨 쓰기로 마음 먹는 데는 용기만 가지고는 어렵다. 두 사람 모두 나와 특별한 인연을 맺고 있고 그 것 바로 이런 프로그래밍 방식에 대한 즐거움을 같이 하는 데서 비롯되었기 때문이다. 내가 몇 해 앞서, "프로그램의 구조와 해석"이란 책을 옮겨 쓴 데서 용기를 얻어, 이런 일을 벌였다고 말하기는 하였지만, 나는 안다. 이런 일은 용기로 마무리하기에는 너무 번거롭다. 용감한 자도 부지런한 자도 재미있어서 일하는 자를 넘어서지 못하는 법니다.

이제 무슨 말을 더 보태야 할까? 여기까지 내가 쓴 글을 읽었는지 아닌지, 알 길은 없지만, 이제 이런 책으로 공부하기를 여전히 머뭇거리다가, 갑자기 이 나라 소프트웨어 기술자의 현실을 생각나서 괜한 욕심 부린다 싶어 쓴웃음을 머금는 이 적지 않으리라. 부질 없어 뵈는 미련을 접고 곧장 책을 덮으려다, 뭔가 아쉬움에 열었다 덮었다 서성대고 있을 분들에게 솔직한 내 마음을 전한다.

본디 처음 이 글을 풀어 낼 적에는, 현재 산업에서 즐겨 쓰고 있는 기술 속에 벌써부터 이 책에서 집중하는 기술과 경험들이 오래 전부터 녹아 들어가 있었고, 앞으로 프로세서의 병행/병렬 아키텍처가 더욱 일반화되고 소프트웨어 품질이 산업의 성패를 가늠할 만치 중요해 지는 마당에서는, 이렇듯 작고 견고한 언어로 튼튼할 뿐더러, 되 쓰임새 띄어난 소프트웨어 개발 기술이 중요하다는 말을 꺼내며, 그 증거를 요목 조목 들이대려고도 하였다. 한데, 그런 식의 논리는 솔직히 나조차 지겹다. 새 기술이 나올 때마다 안 배우면 뭔가 큰일 나는 듯 호통치며 억지로 산업에 밀려나온 엉성한 기술과 제품들이 어디 한 둘이던가. 이 척박한 소프트웨어 산업의 불모지에서는 더욱 그러하다.

더욱 속내를 털어 놓자면, 앞으로 이 나라 이 땅의 소프트웨어 기술자들이, 스스로 애써 갖춘 실력과 공부에 투자한 만큼 대접을 받고, 오랫동안 기술자로 살아남아서 그 경험의 깊이와 안목 때문에, '대목'으로 우러름 받는 세상은 쉽사리 오기 어려울 것 같다. 이게 한 참 딴 세상을 기웃거리다, 다시 한 해 남짓 산업을 둘러본 뒤 느낀 감정의 요약이다. 따라서, 이 책으로 뭔가를 배우겠다고 마음 먹었다면 그것은 오로지 재미 때문이어야 한다. 그 말고, 감히 다른 어떤 까닭으로 이런 공부를 해야 할 이유를 댈 수 있겠는가? 재미 말고 그 어떤 다른 이류로 젊은 피에게 뜻을 같이 하자 소리칠 수 있겠는가? 다행히, Haskell로 프로그램을 짜면 재미있다. 처음 얼마쯤 낯설어서 헤매는 시간을 넘기고 나면 갈수록 깊은 맛이 우러나오는 재미가 있다. 내가 아직도 틈나는 대로 프로그램을 짜고, 기술을 공부하고, 생각을 멈추지 않으며 소프트웨어 기술을 떠들고 다니는 이유가 그 때문이다. 오로지 그 뿐이다.

서울 살이 시작한지 딱 1년 째 되는 날

한국 마이크로소프트 개발자 플랫폼 총괄 부서 내, 양로원 식구들을 대표하여

김재우