김재우 동명 정보대학교 정보기술원 교육 시스템 연구개발 팀장 [email protected]
블루엣 인터내셔널의 기술 이사로 재직중이며 개발 환경과 온라인 교육 시스템을 결합한 소프트웨어를 설계하고 있다. 소프트웨어 공학 기술이나 관련 이론을 실천하도록 만드는 것이 개발자로서의목표. 현재 정보기술원과 함께 분야별 표준 교육 과정, 전문 개발자 양성 및 인증을 위한 교육 시스템‘Theory Into Practice’를 설계하고 있으며, 인도 Vinayaka 대학 IT Parks 소프트웨어 개발팀과 함께 기업형 솔루션 교육과정 및 소프트웨어 개발 기술을 연구하고 있다.
이번 연재에서 소개할 프로그래밍 언어 Haskell은 한마디로 우아한 언어다. 작고 가벼우면서도 표현력을 끝없이 확장할 수 있어 프로그래밍이 진정 무엇인지를 제대로 보여주는 언어라 할 수 있다. 그저 기능이 적은 단순한 언어와 의미의 바탕이 충실해 알맹 이가 작은 언어의 차이를 느끼고 싶다면 Haskell을 꼭 다뤄봐야 한다. 특히 처음 프로그래밍을 공부하는 사람에게 의심없이 배우 라고 권할 수 있는 언어다. 다른 종류의 프로그래밍 언어를 오랫동안 사용한 사람이라면 상업적인 언어와 많이 다르기 때문에 조 금 혼란스럽고 황당할 수도 있을 것이다. 그러나 그런 변화는 아주 바람직한 것이므로 아무쪼록 이 글을 통해 Haskell 같은 아름다 운언어를즐길수있게되기바란다.
지난호 특집‘프로그래밍의 숨겨진 진실과 거짓’을 쓴 뒤, 다른 어떤 글을 썼을 때보다 많은 메일을 받았다. 주장이 강한 글이다 보니 자바 기술을 폄하하는 것으로 받아들이는 사람도 있었고, C#이나 C++를 은근 슬쩍 칭찬하는 것이 아니냐고 오해하는 이도 있었다. 또, 자바에 포괄 프로그래밍(Generic Programming) 기법을 도입하면 그나마 순수하고 단순했던 언어를 C++처럼 복잡하고 어렵게 만드는 것이 아니냐고 걱정하는 사람도 있었다.
먼저 필자의 의도를 오해한 독자에게 답한다면(물론 그 글 앞머리에서 이미 밝혔지만) 자바를 ‘빌려’ 객체지향성에 대한 맹신과 프로그래밍 언어에 대한 지나친 집착을 우려했을 뿐이다. 또한 우리 프로그래밍 교육이 실무를 익힌다는 미명 아래 프로그래밍의 기본을 무시하고, 지나치다 싶을 정도로 유행과 상품성에 휩쓸리는 점을 꼬집고 싶었다. 그리고 현재 그런 분위기를 몰고 가는 기술이 꼭 자바가 아니더라도 필자는 똑같은 방법으로 강하게 비판했을 것이다. 예로 든 기술이 자바였을 뿐이다.
나머지, 기술이나 철학에 관한 질문에는 이번 연재로 답이 되리라 여겨진다. 이번 연재 역시 방법이 다를 뿐 그 목적은 같다. 처음에는 단순히 Haskell이란 언어를 입문 수준에서 소개하는 정도로 그치고자 했지만, 글을 읽는 독자 중에는 기술 자체 보다 그 기술이 나타난 이유를 알고 싶어하는 사람들이 더 많을 것이다. 아무래도 기술이나 기법에 대한 자료는 쉽게 구할 수 있는 반면, 바탕이 되는 원리를 중심으로 프로그래밍이 무엇인지 다시금 생각하게 만드는 글은 드물다. 그래서 이번 호에서는 프로그래밍의 세계에서 묵직하게 흘러가는 기술의 흐름을 얘기하고 난 뒤, Haskell을 간단히 소개하고자 한다.
프로그래밍의 세계에서 패러다임이란 말이 유행처럼 번지게 된 것은 아무래도 객체지향 프로그래밍 때문이다. 그리고 객체지향을 닫힌 세계에서 끌어내어 세상의 도마 위에 올린 것은 누가 뭐래도 C++의 공헌이다. C++가 C의 인기를 업고 프로그래밍 세계를 한바탕 뒤집어 놓으면서‘패러다임의 이동’의 시대를 이끌었을 때, 그 혼란의 강도는 지금의 자바에 비할 바가 아니었다. 떠들지는 않았지만 묵직했기 때문에 프로그래머는 물론이고 관련 기술자 대부분이 어쩔 수 없이 ‘생각하는 관점’을 바꿔야 한다는 생각에 휩싸여 있었다. 그 영향으로 지금까지 정말 많은 종류의 객체지향 언어와 객체지향 소프트웨어가 쏟아져 나왔다. 객체지향이란 꼬리표가 붙어 있지 않으면 좋은 제품과 기술이 아니었던 적도 있었다.
지난 시절이 어떠했든, 그리고 얼마나 많은 프로그래머들이 고생을 했던 간에 이런 굵직한 변화는 박수를 받아 마 땅한 일이다. 새로운 개념이 유행하지 않으면 산업은 좀처럼 관행을 바꾸려하지 않는다. 그러나 객체지향이 당당한 소프트웨어 개발 기법으로 자리잡고 과학과 산업 전반에 커다란 영향을 주고 있는 이 마당에, 한 번쯤은 뭔가 빠뜨리고 지나가지 않았나 되짚어봐야 할 것이다. 필자는 많은 프로그래머와 입문자들이 낡은 관점을 그대로 답습하고 있어서 걱정이다. 객체지향에 대해 이론과 실용 양쪽의 생각을 냉정히 정리하면 따로 책 한권을 쓸 수 있을 만큼 긴 얘기가 나오겠지만, 여기서는 객체지향 대란의 시기를 거치면서 한 가지 잘못된 점만 짚고 넘어가기로 하겠다.
필자가 보기에 가장 심각한 병은 패러다임과 그 변화를 받아들이는 사람들의 자세다. 객체지향이 뜨는 바람에 이전보다 이런 개념의 유입과 변화에 대해 보다 부드러워진 것도 사실이지만, 현실에서 기술로‘먹고사는’사람들은 이런 가벼운 변화를 즐겁게 받아들일 수만은 없다. 그러므로 새로운 개념을 소개할 때는 득실을 분명히 따져보고, 장점과 한계를 명확히 밝혀 이론이나 실용 양쪽의 균형을 맞춰 받아들이도록 배려해야 한다. 어떤 개념이 잘못 전달되는 경우 일부는 분명 받아들이는 자세에 문제가 있어 그렇겠지만, 그 개념을 가르치고 전파하는 방법에도 어느 정도 책임이 따른다. 어떤 개념을 너무 강조하다 보면 배우는 이들은 이를 나머지 세계와 동떨어진 어떤 것으로 받아들이게 되 고, 심하게는 그 세계에 갇혀서 다른 개념을 완강하게 거부하게 될 뿐만 아니라 자기 것을 제외한 다른 방식은 가치 없고 복잡하며 어려운 것으로 간주한다. 특히 입문자에게서 이런‘패러다임 중독성’을 쉽게 찾아볼 수 있다.
객체지향성의 경우를 예로 들어 설명해 보자. 객체지향성을 설명하는 사람들이 클래스니 메시지니 메쏘드니 하는 이질적인 용어를 써서 이미 있던 프로그래밍 개념과 완전히 다른 어떤 것으로 오해를 유도한 덕분에(물론 고의로 그런 것은 아니겠지만), 다른 언어를 공부하다가 새로 이 개념을 익히는 이들은 패러다임 충격으로 한 동안 고생하게 된다. 은유(METAPHORE)를 써서 한 패러다임을 체계 있게 설명하는 시도야 나쁠 것이 없지만, 그 은유를 지나치게 강조하면 문제가 발생한다. 은유는 단지 무언가를 설명하는 수단일 뿐인데, 너무 무게를 실어 설명하다보면 주객이 전도 돼 준수해야 할 규칙과 원칙으로 둔갑한다. 한 패러다임에 입문한 사람은 대개 그 맛을 느끼면 무슨 철학의 한 유파처럼 행동하는 경향이 있어 실제 구현 기법을 제대로 이해하고 연습하는 데 오히려 방해되는 경우가 더 많다. 은 유는 처음 배우는 이들에게 부드럽게 개념을 이해하도록 도와주는 역할을 하는 것이고, 그 단계가 지나면 그 은유를 깨뜨리고 본질을 바라볼 수 있도록 도와주는 것에서 끝나야 한다고 생각한다. 예를 들어 객체지향 개념에 대한 이해가 깊어지면 클래스∙메쏘드∙메시지는 그저 설명하기 좋은 용어일 뿐이고, 그 껍질을 벗겨내면 모듈∙함수∙형(Type) 등, 다른 언어에서 잘 써왔던 용어와 개념상으로 별반 차이가 없다는 걸 알게 해줘야 한다. 소프트웨어를 설계할 때는 또 다시 그 은유의 힘을 잘 써먹어야 하지만, 본질을 알고 있다면 은유와 실제의 차이에서 개념을 정립하지 못하고 방황하거나 잘못된 길로 들어서지는 않을 것이다. 객체지향의 클래스란 용어 하나가 잘못되어서 생긴 피해만 따져 보더라도 결코 무시할 일이 아닌 것이다.
어쨌든 패러다임은 그렇게 뜬구름 잡는 어떤 것이 아니다. 어떻게 문제를 잘라서 추상화하고, 전체 프로그램의 구조를 결정하는지 판단 기준을 잡아주는 개념일 뿐이다. 그런데 많은 책이나 글에서 패러다임을 설명하는 걸 보면, 마치 딱딱한 철학 입문서를 보는 것 같다. 객체지향성을 멋지게 쓰는 게 어렵기는 하지만 신념을 갖고 순수성을 지켜내야 할 가치관이나 철학 같은 것이 아니기 때문에 어디에 중심을 두고 이해해야할 지를 잘 판단해야 한다. 단어의 본 뜻이 어떠하든 프로그래밍의 세계에서 패러다임은 그리 무겁게 받아들일 대상도 아니고, 닫힌 마음으로 지켜내야 할 원칙도 아니다. 다시 말하지만 패러다임은 그저 한 가지 표현 기법일 뿐이다. 그저 어떤 유형의 문제를 더 잘 푸는 데 도움되는 표현 방법이다. 그래서 한 가지 패러다임만으로 작업한다는 얘기는 되려 표현력에 결점이 있다는 것을 스스로 인정하는 것과 다를 바 없다. 따라서 여러 가지를 섞어 사용하는 것은 아주 자연스런 일이다. 패러다임 역시 즐겁게 갖고 놀면서 이리 저리 굴리고 붙여야 할 도구에 지나지 않다.
소프트웨어는 한 가지 기법만 써서는 잘 만들기 어렵다. 각 패러다임이 그 표현 기법과 특성에 따라 서로 맞아떨어지는 응용분야가 다르다는 것은 잘 알려진 사실이다. 그런 이유로 오래 전부터 많은 학자나 기술자들이‘패러다임 묶어 쓰기’를 시도하고 실천해 왔으며 1990년대에 이르러 그런 연구 결과가 눈에 띄게 드러나기 시작했다. 서로 다른 응용 분야가 하나의 소프트웨어로 합쳐져 마치 종합예술 같은 성향을 보이는 요즘, 한 가지 언어나 기법만으로 좋은 소프트웨어를 만들겠다는 고집은 고루한 욕심일 수 있다. 그리고 이런 추세를 부정하고 싶어도 이런 현상을 증명할 자료는 도처에 얼마든지 있기 때문에 닥쳐서 걱정하느니 일찌감치 이런 변화를 받아들일 준비를 해두는 게 현명하다. 지금부터는 잘 알려진 사례를 들어 그런 추세를 읽어보기로 하겠다.
먼저 80~90년대에 패러다임 대란의 주인공인 C++부터 살펴보자. 1990년대 초부터 시작해서 1998년 표준이 제정되기까지 C++ 프로그래밍 세계는 포괄 프로그래밍을 도입하느라 열병을 앓았다. A. Stepanov, M. Lee의 연구와 B. Stroustrup의 지원으로 STL(Standard Template Library)이란 작품이 나오지 않았다면, C++ 표준은 1990년대 초에 끝났을 것이다. 이 STL을 표준 라이브러리로 받아들이려면 C++ 언어를 크게 확장하지 않을 수 없었고, C++는 1998년에 이르러서야 겨우 표준 작업을 마무리하게 된다. 그런데 도대체 STL이 뭐길래 표준 제정을 수년이나 뒤로 미뤄가면서까지 도입하려고 노력했을까? 표준 위원회란 보통 보수 성향을 보일 수밖에 없기 때문에, 아무 리 좋은 연구 결과물이라고 해도 커다란 진보를 단번에 그리 쉽게 수용하지 않는 것이 정상이다. 더구나 C++는 이미 산업에 도입돼 한참 많이 쓰고 있는 언어인데, 개혁에 가까운 변화를 받아들였다는 것 자체가 보기 드문 사례라 할 수 있다.
당시 가장 주목받는 언어 중 하나였던 C++에 이 독특한 라이브러리가 도입됐다는 사실은 단순히 언어 기능의 확장을 넘어선 의미가 있다. 알다시피 STL이 제안되기 전에도 C++에는 템플릿(template)이 있었고 실험 수준의 포괄 프로그래밍은 어느 정도 가능했다고 할 수 있다. 그러나 C++다운 포괄 프로그래밍 구현 기법을 찾아볼 수 없을 뿐만 아니라, 당시의 템플릿 기능은 그런 고급 기법을 실현해낼 만큼 완성도가 높지 않았기 때문에, 그야말로 템플릿은 ‘계륵’같은 기능이었다. 그러나 C 언어의 문제점을 고스란히 내려 받은 데다가, 그 전체 기능이 정교하다 못해 어지러울 만치 복잡한 언어라 해도 STL은 또 하나의 굵직한 기법(포괄 프로그래밍이 멋지게 실현될 수 있음을 보여준 역작)이라 할 수 있다. 이것으로 C++는 객체지향성에 이어 포괄 프로그래밍까지 세상에 끌어다 주면서 또 한번 커다란 공헌을 하게 된 셈이다. 또한 템플릿 기능이 제자리를 잡은 덕분에 ‘패러다임을 섞어 쓰는 프로그래밍 언어’의 하나로 자리 매김하게 되었다.
자바의 JGL(http://www.objectspace.com/products/voyager/libraries.asp) 역시 STL의 영향을 받아 자바에서 비슷한 수준의 라이브러리를 쓰고 싶어하는 사람들의 요구를 반영한 것이라 할 수 있다. 그러나 JGL이 STL의 자바판이라 해도 너무 다른 언어의 것을 흉내냈기 때문에 STL이 잡아낸 두 마리의 토끼(성능과 유연성)를 따라잡을 수는 없었다. 사실, STL은 C에서부터 확장된 C++의 특성을 놀라우리만치 현명하게 이용해서 만든 것이다 보니, 그 철학은 빌리더라도 STL 만의 독특한 설계나 구현 기법을 다른 언어에서 흉내내기가 쉽지 않다. 하지만 자바에 처음부터 포괄 프로그래밍을 지원하는 기능이 들어갔거나, 최소한 JDK에 컬렉션 프레임워크가 들어가기 전에, GJ(Generic Java) 제안이 채택됐다면 상황은 크게 달라졌을 것이다. 최소한 STL과 같은 명작은 아니더라도 지금과 같이 빈약한 컬렉션 라이브러리는 나오지도 않았을 것이며, JGL도 지금보다 더 세련되고 쓸모 있게 설계됐을 것이다.