the elegant anivurse

제 1부. 초등학교(당시에는 국민학교) 5학년 겨울

GW-BASIC
5학년 겨울 방학 때 즈음해서 아버지의 권유로 컴퓨터 학원에 다니기 시작했는데(아버지는 이때의 일을 후회하고 계실지도 모르겠지만), 그 당시에 컴퓨터를 배운다는 아이들은 GW-BASIC부터 시작하는 것이 보통었다. 이것이 그대로 내가 프로그래밍의 세계에 발을 들여놓 계기가 되었다. (지금은 나도 이때의 일을 후회하고 있는지도 모르겠다)

GW-BASIC은 심플한 문장구조와 더불어 인터프리트형 언어라서 제법 가지고 놀기 좋은 도구였다. 특히나 당시에는 GW-BASIC용 예제들도 풍부했고. 그런데 이때는 집에 PC가 없었기 때문에, 아쉽게도 코딩은 학원에서 밖에 할 수가 없었다. 그래서 학원 수업이 끝나도 그대로 저녁때까지 눌러 앉아있기도 하고, 집에서는 종이에다 행번호를 붙여가면서 코딩을 하기도(심지어는 디버깅도) 했다.

그러다 나중에 MS-DOS가 버전업 되면서 좀 더 편리한 Q-BASIC이 추가되어서 나중엔 그걸로 갈아타게 되었다. Q-BASIC은 GW-BASIC에 비해 좀 더 구조화된 문법을 가지고 있었고, 행번호도 옵션이 되었다. 그리고 무엇보다도 이전에 비해 강력해진 소스 에디터와 도움말 기능이 있다는 것이 큰 매력이었다.

참고로 BASIC은「Beginner's All-purpose Symbolic Instruction Code」의 약자로, 말하자면 "초보자의 다용도 기호 명령 코드" 라고 하는 조금 거창한(?) 의미를 담고 있다. 이 때문인지는 몰라도, 지금까지도 "저는 BASIC 프로그래머입니다"라고 말하는 프로그래머는 단 한명도 본 적이 없다. 설령 자신이 Visual Basic을 주 도구로 쓰고 있다 할지라도... 제 아무리 MS의 노력에 의해 Visual Basic.NET까지 발전해 왔어도, BASIC이라는 이름을 달고 있는 한 아무래도 프로의 세계에서는 무시 당하는 것인가 보다.

FORTRAN77
포트란?
항구(port)다...

재미없는 농담은 그만하기로 하고... 요것은 학원에서 정보처리기능사 2급(현재의 정보처리산업기사) 시험을 준비하면서 배우게 된 언어인데, 컴파일러는 어떤 제품이었는지 기억이 나지 않는다. 당시의 정보처리기능사 실기시험은 말이 실기 시험이었지, 사실은 주어진 소스 코드에서 빈칸을 찾아 알맞는 코드를 써넣는 거였다. 그런데 문제는 내 기억이 맞다면 실기 시험에 나오는 소스 코드는 GW-BASIC, COBOL, FORTRAN의 세 종류였던 걸로 기억한다. 거기에 덤으로 순서도 문제가 딸려나왔다.

어쨌거나 당시의 FORTRAN의 경우는 열(Column)에 매우 민감한 언어였는데, 몇 번째 열부터 문자가 시작되느냐에 따라 각각 특별한 의미가 있었다. 예를 들면 첫번째 컬럼이 C로 시작하면 주석이라든가... 그런데 문장 구조를 보면 오히려 BASIC과 닮았다라는 느낌이어서 생각외로 쉽게 배울 수 있었다. 행번호 비슷한 개념도 있었고. (그런데 사실은 BASIC이 FORTRAN의 영향을 받은 것으로 알고 있다)

흔히 FORTRAN하면 산술계산용 언어라는 인식과 함께, 비인기 언어, 그리고 구시대적 언어라는 인상이 있다. 그런데 당시에는 몰랐지만 FORTRAN77까지만 해도 사실은 구조적 프로그래밍의 개념까지도 포함된 상당히 발전된 언어였던 것이다. BASIC이 죽지않고 결국에 Visual Basic.NET까지 발전해 온것처럼, 포트란도 Fortran 90 이후로 많은 개량을 거듭해서 객체지향과 제너릭 프로그래밍 개념까지 포함된 Fortran 2003, 그리고 Fortran 2008까지 나와있다고 한다.

참고: Fortran examples - Wikipedia

RM/COBOL
이거 역시 시험을 준비하면서 배운건데, COBOL이라고 하면 아직도 'IDENTIFICATION DIVISION', 'ENVIRONMENT DIVISION', 'DATA DIVISION', 'PROCEDURE DIVISION'의 4대 DIVISION이 생각이 난다. COBOL이 다른 언어와 확연하게 다른 점은 영어 문장과 흡사한 문법적 특성 이외에도 이렇게 4개의 부분으로 나눠진 프로그램의 구조적인 특징도 있다. 어쨌거나 덕분에 영어공부는 되었다.

새삼스럽지만, 처음 COBOL을 봤을 때의 소감을 말하자면 "무슨 코드가 빌어먹게 길어!" 라는 거였다. 게다가 모두 대문자로 타이핑해야 하니 더욱 빌어먹었다. 덤으로 Turbo-C처럼 편리한 IDE환경이 있는 것도 아니어서(FORTRAN때도 그랬지만) 컴파일하고 디버깅 하는 데도 애를 먹고... 어쨌든 지금도 굉장히 싫어하는 언어 중 하나다.

하지만 무슨 운명의 장난인지...
훗날 대학에 들어가서 다시 COBOL을 배우게 된다.

C
초등학교 6학년에 올라와서 GW-BASIC을 접고 본격적으로 파고들기 시작한 것이 바로 C 언어였다. Turbo-C라는 근사한 IDE가 있었고, 간결하면서도 강력한 기능을 포함하는 문법 등이 굉장히 마음에 들었다. 어찌어찌해서 '터보C 특강'이라는 책 한권을 손에 넣고 처음부터 끝까지 혼자서 독파해 나갔는데, 어렵사리 '포인터'의 개념에 대해 깨우쳤을 때에는 정말이지 감동이었다. 나중에, C에 도전했지만 포인터의 벽을 넘지 못하고 좌절한 이들이 한둘이 아님을 알게 되었을 때, 일찌감치 포인터의 개념을 이해했던 것은 굉장히 럭키였다고 생각했다.

말하자면 C는 처음으로 거의 독학으로 공부한 최초의 언어였다고 할 수 있겠다. 그리고 게임 같은 걸 만들어 봐야겠다고 생각해 본 것도 C를 공부하고 있을 때였다. 그만큼 C는 가능성을 보여주었다고나 할까.


제 2부. 중,고등학생 시절

Assembly
C는 고급언어이면서도 사실은 하드웨어에도 친숙한 저급언어의 특징도 가지고 있다. 그래서 '중급언어'라고도 표현하곤 하는데, 그런 영향에서인지 왠지 모르게 '어셈블리'에도 관심이 생기기 시작했고, 관련 책도 두 권을 사서 보기 시작했다. 그렇다고는 해도 어셈블리로 프로그래밍을 할 정도는 못되었고, MS-DOS의 debug.com 프로그램을 이용해서 간단한 것을 만들어 볼 수 있는 정도였을 뿐이다. 하지만 이때 어셈블리를 공부한 것은 나중에 대학에 가서 큰 도움이 되었다.

Borland C++
C에다 객체지향 개념을 접목시킨 C++이란 언어가 있다는 얘기를 듣고 시작한 것이 Borland C++. 단지 Turbo-C를 만든 회사의 제품이었다는 것이 선택의 이유였다. 하지만 복잡해진 객체지향 문법과 함께 윈도우 프로그래밍에 제대로 적응을 못하고 곧 포기하고야 만다.

Delphi
내가 본격적으로 객체지향 프로그래밍을 하게 된 것은, 특이하게도 C++이 아닌 델파이(Delphi)였다. 델파이는 본래 형이 시작한 거였는데, 나중에 나도 형을 따라서 시작하게 되었다. 그리고 수년간 나의 델파이 사랑은 시작되었다.

내가 본격적으로 델파이를 시작한 것은 3.0버전부터 였는데, 일단 윈도우API 따윈 몰라도 손쉽게 윈도우 프로그래밍을 할 수 있다는 것과, 객체지향적 설계의 모범이라 할 수 있는 VCL 라이브러리, 그리고 무엇보다 내 마음을 사로 잡은 건 Objet Pascal의 멋들어진 문법이었다. C 특유의 기호가 많은 암호같은 문법은 처음에는 꽤 마음에 들었지만 나중에 시간이 지나서 코드를 들여다 볼 때는 좀 짜증이 나곤했다. 그런데 Delphi의 코드를 본 순간 느낀 것은 '아름다움'이었다. 단지 이 하나의 차이로 인해 나는 미련없이 C를 버렸다.

정리하자면, Visual Basic처럼 쉬우면서도 C++ 만큼 강력한 개발도구.
그것이 바로 델파이였다.

나중의 일이지만, 결국 나는 델파이 덕분에 취업을 할 수 있었다.


제 3부. 대학 시절

대학에 들어와서 COBOL과 C를 다시 공부하게 되었다. 이유야 당연히 수업 과목이었기 때문에... 그런데 사실 나는 이미 예전에 배운 것들이라서 별로 새삼스레 다시 배울 것도 없었다. (그래도 역시 COBOL은 좀 재활훈련이 필요했지만...)

그러고보니 COBOL 시험중에 기억에 남는 건, COBOL 소스 코드를 통채로 외워서 시험지에 쓰는 것이 있었다. 사실 코드를 외우는 건 그리 어렵지는 않았다. 하지만 문제는 COBOL의 특성상 아무리 간단한 내용의 소스라도 길이가 무진장 길다는 것. 외우는 것보다 답안지에 글자를 채워 쓰는 것이 더 힘들었다...

그리고 '마이크로 프로세서' 였던가 하는 과목에서 예전에 공부한 어셈블리가 크게 도움이 되었다. 그리고 어셈블리에 대한 이해도 더욱 깊어졌고, 이것은 C의 더욱 깊은 부분을 이해하는 데도 도움이 되었다. 역시 뭐든 배워두면 써먹을 데는 있는가 보다.

Visual Basic
C를 공부한 이후로 BASIC 따윈 다신 거들떠 보려하지도 않았는데, 대학에 와서 어쩔 수 없이 Visial Basic을 만지게 되었다. 그런데 생각외로 Visual Basic은 잘 만들어진 툴이고, 언어 차원에서도 많이 다듬어졌다는 인상을 받았다. 그렇다고 해도 나는 이미 Delphi에 푹 빠져있었기 때문에 Visual Basic으로 프로그래밍을 할 생각은 눈꼽만치도 없었지만... 어쨌거나 덕분에 Visual Basic 소스도 읽을 수 있게 되었다.

JAVA
대학에서 배운 것 중, 정말 유익했다고 생각하는 것 중 하나가 JAVA였다. 주변에서 하도 자바, 자바, 자바... 해서 대체 뭔가 싶었는데, 그저 C++을 닮은 언어라고만 생각하고 말았지만, 이게 의외로 재미있는 녀석이었다.

C++과는 다르게 철저하게 객체지향 위주로 된 문법 설계가 인상적이었다. 다만 불행히도 당시에 별로 쓸만한 JAVA용 IDE를 구하지 못했고, JAVA의 동작도 좀 느려터진 편이어서 크게 관심을 가지진 못했지만, C#과 더불어 객체지향에 대한 개념을 한 단계 더 깊이있게 생각해 볼 수 있는 계기가 되었다.

C#
MS에서 타도 JAVA를 외치면서 야심차게 내놓은 새로운 C++의 변종. 마침 그 시절은 C#이 한참 이슈로 떠오르던 시기였다. 그래서 호기심에 'C#과 .NET Platform'이란 책을 사들고서 독파했는데, 사실 C# 보다는 .NET Platform에 대해 더 이해하게 되었다.

여튼 JAVA가 포기했던 C++의 문법요소를 다시 끌어들이고, 어쨌든 최대한 Visual C++ 사용자들을 .NET의 구렁텅이로 빠트리고 싶어한다는 것을 알게되었다. 그런데 그후로 5년도 넘게 시간이 지났건만 아직도 C#으로 갈아타려는 움직임은 크게 눈에 띄지않고 있다.

그래도 여전히 주력은 Delphi 였다.


제 4부. 졸업 후

ASP(Active Server Page)
교수님이 운영하는 회사에서 용돈벌이 겸해서 잠깐 일한 적이 있는데, 그때는 또 쌩뚱맞게 ASP를 하게 되었다. HTML + JavaScript로 웹페이지를 만들고, 서버쪽 스크립트로 VB Script와 DB로는 MS-SQL Server를 썼다. 고등학생 시절에 홈페이지 만든다고 HTML과 JavaScript는 조금 다뤄본 적은 있었는데, VB Script와 SQL은 역시 생소한 것이어서 하루동안 책 한권을 독파해서 겨우겨우 사용할 수 있었다.

이로써 웹프로그래밍에도 발을 살짝 들여놓게 되었다.

그리고 약 27개월간의 군복무(공군) 기간이 왔다. 사실 졸업한 이후로는 거의 프로그래밍에는 손을 떼고 있었다. 게다가 전산병으로 지원하긴 했지만, 프로그래밍을 할 수 있는 일은 아니었기 때문에 군복무 기간 동안에는 좀 더 다른 공부를 해보자고 생각했다. 그래서 시작한 것 중 하나가 일본어였고, 다른 하나는 프로그래밍 분야의 여러 서적들을 사 읽어 보는 거였다.

프로그래밍은 하지 않고 그저 머리속에서 지식을 이해하는 것에만 집중했다. 이때 가장 중점에 두었던 것은 객체지향적 설계에 대한 부분이었는데, 이는 나중에 Smalltalk 언어와 디자인 패턴을 공부할 때 많은 도움이 되었다.

그리고 군복무도 끝나고...

Smalltalk
군복무가 끝나자 마자, 좀 더 색다른 언어에 관심을 가지기 시작했다. 그리고 Smalltalk와의 운명적인 만남. Smalltalk라고 하면 객체지향에 대해 배울 때, "옛날 옛적에 Smalltalk라는 객체지향 언어가 있었데요." 라고 한줄 언급되는 수준이면 다행일 정도의 구닥다리 언어라는 인식이 있지만, 사실 Smalltalk은 아직도 현역일 뿐더러, 현대의 객체지향 언어들 보다도 더 높은 수준의 언어다.

Smalltalk를 공부하면서 언어가 아닌 객체지향의 개념 그 자체를 공부하게 되었다. 정말로 모든 것이 객체, 심지어 개발환경 자체도 객체지향적인 것을 체험하게 된 그 순간의 감동은 이루 말할 수 없었다. 이로써 나는 앨런 케이(Alan Kay)님에 대한 존경이 한층 더 깊어졌다.

Smalltalk를 알고나서 오히려 나는 C++에 대해, JAVA에 대해 이전보다 더 잘 알게 되었다. 왜 이들 언어가 그런 모양새로 객체지향 개념을 구현했는지 그때서야 비로소 알 수 있었던 것이다. 그리고 기존에 가지고 있던 객체지향에 대한 개념도 완전히 포맷했다.

이렇게 Smalltalk에서 받은 인상 덕분에 나는 좀 더 적극적으로 다른 비주류의 언어들에 대한 호기심을 넓혀갈 수 있었다. 새로운 패러다임을 갖는 언어를 공부하는 것이 정말 중요하다는 것을 깨달았기 때문에... C#이나 JAVA같은 C++에서 나온 계열의 언어를 백날 공부한 것 보다 Smalltalk 같은 걸 한번 공부한 것이 훨씬 더 도움이 된다고 생각했기 때문에...

PHP
웹프로그래밍과는 다시는 인연이 없을 것 같았음에도, 어쩌다 보니 PHP도 공부하게 되었다. 아마도 때마침 '마이크로 소프트웨어' 잡지에서 상품으로 받았던 게 PHP 프로그래밍에 관련된 책이었다는 점도 있었을 것이다. 여튼 정말 어쩌다 보니 아파치 + PHP + MySQL 이라는 APM 3종 세트를 만지게 되어버렸다. 거기에 덤으로 이글루스 스킨을 편집하면서 CSS 디자인에 대한 노하우도 생겼다(...)

Haskell
Smalltalk를 어느정도 공부하고 나서, 이번에는 함수형 언어에 도전을 해보자라고 마음 먹었고, 그래서 선택한 것이 Haskell이었다. 그런데 함수형 언어에 적응하는 것은 처음 Smalltalk에 적응하려 했을 때 보다 몇 배는 더 힘들었다. 그나마 Smalltalk는 객체지향 개념으로 이해를 하면 되었지만, Haskell은 기본 바탕에 깔려있는 개념 자체가 달랐다. 암튼 '함수형 프로그래밍'이라는 개념을 이해하게 된 것만으로도 Haskell을 공부해본 가치는 있다고 생각한다.

그리고 Haskell에 대해 좀 더 깊이 들어가 볼까 하고 생각하던 찰나에... 취업을 해버리고 말았다.


제 5부. 취업, 그리고 그후...

한동안 외도(?)를 하던 사이에 손을 놓고 있었던 Delphi를 취업을 하고 나서 다시 잡게 되었다. 내가 다니던 회사에선 특이하게도 Delphi를 주 개발툴로 쓰고 있었던 것이다. 사실 내가 그 회사에 입사할 수 있었던 이유 중 하나는 분명 Delphi 경험자라는 점도 있었을 것이다. (그런데 사실을 말하자면 군 입대 이후로 입사전까지 수년간 Delphi에는 전혀 손을 대고 있지 않았다...) 아마도 내 나이대에서 Delphi를 주력으로, 그렇게 오랫동안 사용해본 사람은 극히 드물것이라는 생각이 든다.

그리고 부끄럽긴 하지만, 회사에 들어가서 처음으로 DLL 프로그래밍을 하게 되었다. (그것도 Delphi로...) 또 처음으로 멀티 스레딩 프로그래밍도 접하게 되었다. 참으로 이것만큼은 쥐약이었다.

그렇다고 회사에서 항상 Delphi만 쓴 것은 아니었는데, 어떤 때는 Visual C++로 작성된 소스도 열어봐야 했다. 예전에 C++을 공부했던 것이 아직 기억에 남아 있었기에 다행이었다. 그리고 어떤 것은 Visual Basic으로 작성된 것도 있었다.

한번은 화면에다 Delphi(Borland Developer Studio), Visual Studio 6.0, Visual Basic을 동시에 띄워놓고 작업하기도 했다. 가끔은 Visual Studio 2005 버전이 대신 올라오기도 했지만... 또 한때는 '디자인 패턴'관련 프리젠테이션을 위한 예제를 만들기 위해 Eclips를 열어놓고 JAVA 코딩을 하기도 했다. 어떤 분은 내가 Delphi에 C++에 VB, JAVA까지 쓰는 것을 보고 "넌 대체 뭐하던 놈이냐?" 라고 얘기를 하기도(...) 결국에 회사를 나갈 때 즈음해서는 C#에서 XAML로 폼을 만들고 거기에 DirectDraw를 이용해 멀티분할 영상을 출력하는 예제도 만들었다... 아, 그러고 보니 JavaScript 디버깅도 했었네.

그리고 회사를 나온 후...

Visual C++, C++ Builder with STL
동인 게임제작팀에 몸담으면서 부터는 그간 애용하던 Delphi를 버렸다. 게임 제작에서는 거의 C++을 쓰게 되는 것도 이유였지만, 결정적인 계기는 무엇보다 STL을 제대로 쓰기 시작하면서 부터였다.

Smalltalk를 알게 되고나서 부터, 동적타입 언어의 유용성을 확실하게 실감했다. 그런데 Delphi나 기존의 C++에서는 그런식의 제너릭 프로그래밍이 매우 어려웠다. 고작해서 C++에서는 #define 매크로를 이용하는 것이 고작이었고, 그나마 Delphi에서는 문법적으로 약간 유연성을 둘 수 있는 방법이 있긴 했다.

그런데 C++에서 Template과 STL 라이브러리를 쓸 수 있게 되면서부터, C++에 인상이 완전히 달라졌다. C++같은 정적타입검사 언어에서 제너릭 프로그래밍을 흉내내면서 방대한 자료구조와 알고리즘을 제공해주는 라이브러리의 편리함은 C++의 그 끔찍한 문법에도 불구하고, Delphi를 버리기에 충분한 이유가 됐다. 그리고 무엇보다, Delphi만큼 편리한 RAD툴인 C++ Builder(Delphi와 같은 회사 제품)가 있으니까.

그래서 지금은 Visual C++과 C++ Builder를 함께 쓰고 있다. 기존에 Delphi로 작성했던 라이브러들(Xml 파서 같은...)도 현재는 모두 C++ 기반 라이브러리로 재작성되고 Visual C++, C++ Builder 양쪽에서 모두 동작할 수 있게 되어있다.


이런식으로 이런 저런 프로그래밍 언어들을 갈아타면서 지금까지 왔지만, 여러가지 패러다임을 경험해 보았다는 것에 나름대로 자부심이 있지만, 한편으론 하나의 환경에서 깊이있게 파고 내려가보질 못했다는 문제도 있다. 어쩌면 내가 지금까지 계속 프로그래밍을 하고 있는 이유는 '무언가를 만들고 싶다'라기 보단 외국어를 하나 배우듯이 '언어를 배운다'는 것 자체가 재미있어서 일지도 모르겠다.

학창시절에서도 이과계열(특히 수학, 물리) 보다는 문과계열 과목의 점수가 더 높았던 것에 비춰봐도, 프로그래밍 언어를 프로그래밍을 위한 '도구'라기 보단, '언어' 자체로서의 가치에 더 매력을 느끼는 것 같은... 조금 포장해서 말하자면 엔지니어적인 프로그래밍 보단 문학적 프로그래밍을 하는 것이 내 스타일인 것 같다.

앞으로도 언어에 대한 내 호기심은 멈추지 않을 것 같다.

그리고, 앞으로 공부해 보고 싶은 언어들...

- Ruby, Phython, Lua 등의 스크립트 언어: 이미 관련 책들은 구해놓았다.
- Haskell, LISP(혹은 Scheme): 함수형 언어에 대해 더 깊이 파고 들고 싶다.
- F#: OCaml을 기반으로한 .NET Framework 환경에서 돌아가는 객체지향 + 함수형 언어. 무엇보다 .NET Framework에서 실행된다는 것이 꽤 재미있어 보인다.