블루엣 인터내셔널의 기술 이사로 재직중이며 개발 환경과 온라인 교육 시스템을 결합한 소프트웨어를 설계하고 있다. 소프트웨어 공학 기술이나 관련 이론을 실천하도록 만드는 것이 개발자로서의 목표. 현재 동명 정보기술원과 함께 분야별 표준 교육 과정. 전문 개발자 양성 및 인증을 위한 교육 시스템‘Theory Into Practice’를 설계하고 있으며, 인도 Vinayaka 대학 IT Parks 소프트웨어 개발팀과 함께 기업형 솔루션 교육과정 및 소프트웨 어 개발 기술을 연구하고 있다.
Haskell은 지금까지 프로그래밍 분야에서 연구된 여러 가지 성과를 충실하게 반영하고 있다. Haskell로 프로그래밍을 배우면 ‘잘하는 프로그래밍이 무엇인지 알게 되는 것’은 물론이고, 시중에서 유행하는 언어에서는 찾아보기 힘든 여러 개념과 기법을 미리 맛볼 수 있다.
벌써 Haskell을 소개한 지 3개월이 지났다. 바쁜 와중에 글을 쓰다 보니 뒤돌아볼 여가도 없이 여기까지 와버렸다. 필자의 바람은 더 많은 사람들이 올바르게 프로그래밍하는 가치와 즐거움을 함께 느꼈으면 하는 것이다. 하지만 이 글이 얼마나 많은 사람들에게 감흥을 주었는지 알 길이 없다 보니 이런 저런 걱정이 앞선다. 혹시나 이 글이 제 가치를 제대로 알려주지 못하고, 잘못된 선입관이나 섣부른 지식만 소개한 것은 아닌지 아주 조마조마하다. 그런 사태(?)를 미리 막기 위해 꼭 하고 싶은 말이 있다. 만에 하나 이 글이 프로그래밍의 재미를 떨어지게 만들었거나‘역시 이런 언어는 내가 배울 게 못돼’하는 느낌을 갖게 만들었다면 그 모든 잘못은 오로지 이 글이 못난 탓이다. 더 재미있고 바르게 소개할 방법이 얼마든지 있는데, 시간과 재주가 모자라 이 정도 글 밖에 나오지 못했기 때문이다. 그러므로 이 글만 보고 이 기법의 가치를 섣부르게 짐작하지 말았으면 좋겠다. 온전한 재미를 한껏 느끼고 싶다면 더 잘 쓴 책을 가져다가 진지하게 공부하는 게 좋다.
많은 사람들이 잘 만든 언어로 프로그래밍을 배우거나 소프트웨어를 만드는 일을‘정말 재미있다’고 말한다. 물론 쉬워서라기보다 분명히‘틀을 갖추어 제대로’한다는 데서 오는 즐거움일 것이다. 그러나 올바로 프로그래밍하는 재미를 알기가 그렇게 쉽지 않다는 걸 먼저 깨달아야 한다. 당연한 얘기지만 뭐든지 제대로 하려면 쉬운 일이 없다. 특히 단 한번도 이런 식으로 프로그래밍을 해본 경험이 없다면‘황당’하다는 생각을 떨쳐버리기 쉽지 않을 것이다. 오랫동안 올바르게 해보려고 노력하지 않았다면 참된 가치를 제 것으로 만들기 힘들다. 이런 황당함을 위로하기 위해 한 마디 하자면, 필자 역시 처음에는 마찬가지였다. 필자의 경우는 아주 최악의 상황이었다. 너무 일찍 프로그래밍 언어를 공부한 죄로 온 몸에 잘못된 습관이 가득 배어 있었는데 다시 바탕을 뒤엎고 바로 잡자니 무척 힘이 들었다. 그러니까 아주 똑똑하거나 너무 익숙해서 금방 이런 프로그래밍 기법을 익히게 된 경우는 결코 아닌 것이다.
이번에 새로 Haskell를 익히고자 하는 독자를 위해 이번 호에는 이런 기법을 배우기까지 지나간 필자의 고생담을 풀어 놓기로 했다.물론 이 글의 목적은 지난 호에서 소개하지 못했던 Haskell만의 독특한 기능을 소개하는 것이다. 지난 호에서 ‘함수를 써서 프로그래밍’하는 일반 상식을 다루었기 때문에 이번에는 Haskell과 같은 함수형 언어가 보여주는 재미있는 기능을 다룰 것이고, 자연스런 이해를 돕기 위해 이야기 형식으로 풀어 쓴 것이라고 보면 된다. 특히 지난 호에 강규영 씨가 쓴‘자바에 대한 몇 가 지 오해에 대한 변론 ’을 읽고 어떻게든 필자 의견을 더해야겠다고 생각했는데, 이 연재의 의도를 벗어날 수는 없기 때문에 중간 중간 충분히 답이 될 만한 얘기 거리를 풀어 놓았으니 뜻하는 바를 비교하며 읽어봐도 좋을 것이다.
지금부터 언어가 프로그래밍을 배워야 하는 누군가의 사고력에 어떤 영향을 주는지 필자의 경험을 빌어 말하고자 한다. 프로그래밍 언어마다 제각기 풀어내는 문제의 성격이 다르기 때문에 어떤 언어를 열심히 공부하면 그 언어의 사고에 젖게 된다는 사실을 말하고 싶다. 물론 이미 자기 나름대로 ‘프로그래밍하는 방법’을 어떻게든 갖게 됐다면 새로운 언어를 어떤 식으로 배우든 큰 차이는 없다. 다만 그 새로운 언어가 정말 새로운 것인지 자기보다 더 나은 사람으로부터 바른 조언을 듣는 것이 좋다. 아니라면 그저 비슷한 언어를 갖고 매번 같은 문제를 문법만 바꿔가며 옮겨 쓰는 효과밖에 없다.
지난 1980년대 초, 그러니까 필자가 중학교 시절 애플에서 처음 프로그래밍을 공부할 때 배운 언어는 베이직(BASIC )이었다. 지금과 같이 편리한 운영체제라는 것이 없던 때였지만 별로 불편하다는 생각을 하지 못할 만큼 환경이 단순했기 때문에 프로그래밍에만 집중할 수 있어서 정말 재미있었다. 그 당시에 컴퓨터를 배우는 어린 학생들은 누구나 게임을 만들고 싶어 했고, 필자도 유행하던 만화 주인공으로 게임을 만들고 있었다. 열심히 모눈 종이에 캐릭터를 그리고 비트맵 데이터로 표현한 다음에 이리 저리 움직이는 프로그램을 짜느라 날 새는지를 몰랐다.
다음에 고등학교 시절, 학원에서 익힌 포트란과 코볼(COBOL)이다. 포트란은 문법만 다를 뿐 베이직과 문제를 풀어나가는 방법이 크게 다르지 않았기 때문에 쉽게 익힐 수 있었다. 베이직 인터프리터를 쓸 때처럼 간편하게 프로그래밍할 수는 없었지만 그럭저럭 배우는 재미가 있었다. 그러나 포트란은 베이직과 문제의 성격이 달랐다. 베이직을 쓸 때도 수치 계산을 하지만 게임 속의 그래픽 객체를 움직이거나 벽돌을 쓰러뜨리기 위해 만들던 것과는 목적이 달라 보였다. 포트란 교재에 수록된 문제는 어떤 제3의 목적이 있다기보다 오로지 그 문제 자체의 답을 더 정확하고 빠르게 계산하는 방법에 초점을 맞추었고, 또 그렇게 하는 것이 잘하는 프로그래밍이라는 쪽으로 이끌어 가고 있었다. 어쨌거나 분명한 것은 그 당시에도 포트란으로 게임을 만드는 예제는 찾아볼 수 없었으며, 필자 역시 포트란으로 게임 프로그램을 만들 생각은 애초에 하지도 않았다.
한 해가 지난 다음 이번에는 코볼을 배우게 됐다. 이 언어는 앞서 배운 언어처럼 간결하지 않았다(다른 사람들과 달리 필자에게는 솔직히 좀 지저분해 보였다). 실제 문제를 풀어내는 코드는 얼마 되지 않았고 포트란처럼 문제를 푸는 논리가 복잡하게 전개되는 것도 아닌데 프로그램을 완성하려면 어쩔 수 없이 이런 저런 이해하지 못할 구문을 외워야 했다. 포트란으로 프로그래밍을 배울 때까지만 해도 나름대로 재미가 있었는데 코볼은 정말 지루한 언어였다. 실제로 언어보다 푸는 문제가 더 지겨웠다고 해야 맞다. 어쨌든 수업 시간에 졸지 않고 버티기가 힘들 정도로 따분했다. 당장에 문제를 푸는 데 별 필요도 없어 보이는 여러 기능(각 Division마다 괴상망측한 구문과 여러 종류의 파일 시스템)에다 문장처럼 풀어쓴 식을 배우다 보니 ‘프로그래밍이 이렇게 재미없는 일이었나’하는 회의마저 들었다. 나중에 포트란으로 풀던 문제가 수치해석 알고리즘 공부고, 코볼의 이런 저런 기능은 메인프레임에서 경영 정보를 대량으로 처리하는 데 꼭 필요한 기능이라는 걸 깨닫게 됐지만 두 언어로 프로그래밍하면서 베이직을 배울 때만큼 재미를 느끼지 못한 것은 사실이다.
나중에 대학에 들어가서는 C 로 시작해 파스칼(Pascal ), C++, 스몰토크(Smalltalk) , Scheme, CAML, Gofer 등 정말 많은 언어를 동시에 접하게 됐다. Haskell 은 졸업 후에 Gofer를 익히다 자연스럽게 알게 된 언어다. 그리고 그 학습의 순서를 패러다임의 이동으로 보면 명령형(Imperative) 언어, 객체지향(Object-oriented) 언어, 함수형(Funcitonal) 언어를 순서대로 익힌 셈이다. 그리고 그 변화에는 나름대로의 이유가 있었다.