개성있는 프로그래머가 되는길(1)

개성있는 프로그래머가 되는길(1)

저자 : 이만용(프로그램 세계 기사)

================================================================================

모든 사람이 컴퓨터를 좋아하는 것은 아니다. 더 나아가 컴퓨터를 유용하게 사용할 수 있도록 해주는 프로그래밍을 좋아하는 것도 아니다. 일반적으로 프로그래밍을 좋아하거나 프로그래밍이 왠지 자기에게 맞을 것 같은 사람들은 그렇지 않은 사람들과 분명히 다른 개성을 가지고 있다. 그 차이가 그렇게 크지는 않다 하더라도 결과물은 다르다. 한 사람은 프로그래머이거나 프로그래머라고 부를 수 있는 사람이고 다른 사람은 프로그래머가 전혀 아니다.

==============================================================
프로그래밍은 다음과 같은 몇가지 마음의 작용이 일어날 때 좋아지고 시도하게 만든다.
==============================================================

정말 훌륭한 소프트웨어를 사용해 보았으며 “언젠가는...” 자신도 그 정도 또는 그에 가까운 수준의 소프트웨어를 만들고 싶다는 존경심으로부터 나온 욕구
지금 현재하고 있는 작업이 불만스럽고 더욱 단순화시키고 싶다는 매우 현실적인 욕구
예전에는 이 둘 중 하나였으나 직업적인 말단 프로그래머가 되어 상부 팀장의 지시에 따라 어쩔 수 없이 해야 하는 의무
처음 자신을 프로그래밍하게 또는 프로그래밍 공부를 하게 만든 요인에 따라 앞으로의 선택 방법이 크게 달라진다.

참고로 필자는 겔로그와 제비우스(Xevious)와 같은 오락이 나오던 시절, 험상궂은 아저씨들이 담배를 피워대던 오락실에서 우두커니 서서 그 오락들에 매료되어 프로그래밍을 시작했다. 당연히 그 시절에는 베이직(BASIC)...

프로그래밍을 한다고 해서 모두가 똑같은 프로그래밍을 하는 것은 아닌 듯 하다.
사람이 다르면 프로그래밍 방식도 다르고 프로그래밍 방식이 다르면 나오는 작품도 천차만별이다. 소프트웨어는 크든 적든 어느 정도 프로그래머의 개성을 반영한다.


1. 프로그래밍이 좋아서 하는 사람
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

이 부류에 드는 사람들은 “대책이 없는(?)” 사람들이며 어느 누구도 말릴 수 없다.
누가 간섭하지 않아도 혼자서 바람도 안 부는데도 잘 도는 바람개비인 사람들이다.
이 사람들은 종종 "특별히 아무도 위하지 않는 자신만을 위한 프로그램"을 만들기 좋아한다. 그 사람의 개인적인 취향을 닮은 프로그램이 많으며 그 프로그램에는 프로그램을 만든 사람의 “인격(Character)”이 들어있다 해도 과언이 아니다.

프로그래밍이 원래 좋아서 코딩하는 사람은 아니라 하더라도, 이 세상에 태어나 자기 인격을 가지고 있으며 자기와 동일시 할 수 있는 프로그램 하나 만들어 보는 것이 프로그래머의 간절한 소원이 아닐까? 여러분은 어떠한가? 프로그래밍하는데 그런 희망 내지는 야망 하나 없다면 얼마나 밋밋하겠는가? 오늘도 버거운 프로그래밍 과제를
부여받는 말단 프로그래머의 마음 한 구석에는 자기를 표현해주는 프로그래밍 과제가 조용히 끓고 있을 것이다.

요즘 전세계적인 열풍을 몰고 있는 리눅스(Linux)는 “프로그래밍이 좋아서” 만들어진 대표적인 작품 중 하나다.

일반 응용 프로그램과 달리 운영체계 커널이라는 것은 사람들에게 화려하게 보이지도 않으며 관심을 많이 끌지 않는다. 리누스(Linus)가 현재와 같은 성공을 예견하고 리눅스를 코딩하기 시작했다고 신화화시킬 수 있을까?(리누스 그 자신이 거세게 항의하고 나올 것이다. 리누스는 항상 리눅스 디자인의 핵심은 재미(fun)여야 한다고 강조한다).

예를 들어 인텔(Intel) 플랫폼이 아닌 알파(Alpha) 플랫폼과 같은 이 기종에 리눅스가 돌아갈 수 있을 것이라고는 리누스 자신도 생각하지 못했다고 한다. 신(God)은 예견했는지 몰라도, 신이 리누스나 다른 커널 개발자들의 손을 빌렸다고 말할 수 있을 지는 몰라도, 직접 손을 사용하여 코딩을 한 사람은 모르고 한 일이며 그
주위에 있는 사람들은 더더욱 모르고 한 일이다. 우리 중 예언자가 있으면 모를까……

리눅스는 리누스가 가지고 있던 386PC를 위한 개인 취미 프로젝트라는 사실을 많은 사람이 알고 있다.

그 후 지금까지 성장하기 위해서는 “단지 좋아서 자발적으로 열심히”라는 조건 이상의 것이 있었다는 게 분명하다(조금 뒤에 다룰 것이다). 그러다 다음 사실은 분명하다.

“단지 좋아서”, “자기의 인격을 닮은” 무엇인가를 만들어서 “자기 자신을 즐겁게“ 하기 위해 만들어진 프로그램에는 임시 땜질과 같은 거짓 요소가 없고 오히려 순도와 완성도가 높을 때가 많다. 이는 기본적으로 자기 좋아서 하는 일에 대하여 프로그래머가 자기를 속이는 일은 없으며 무엇보다 데드라인(dead line)이 없기 때문에 미봉책을
쓸 이유조차 없기 때문이다. 문제에 봉착하면 포기하거나 자기 에너지를 모두 소비할 때까지 붙어있으면 그만이지 대충 마무리 지을 이유는 없다.

좋아서 만드는 프로그램이 장난감 수준의 소프트웨어라고 말하고 싶은 사람도 있을 지 모른다. 이미 전문가적인 수준의 프로그래머들이 그렇게 볼 지 모르지만 실상은 그렇지 않다!


감히 리차드 스톨맨(Richard M. Stall man, 줄여서 rms라고 많이 부른다. FSF 회장이며 GNU 프로젝트의 창시자)씨의 이맥스(Emacs)는 “좋아서” 만든 소프트웨어라고 생각하며 여러분도 알다시피 순도높고 리차드 스톨맨씨의 인격을 닮은 프로그램이라 말하고자 한다.
리눅스도 기본적으로 그러하다.

좋아서 만드는 프로그램은 둘 중 하나가 된다. 정말로 원래 의도했던 그대로 자기 자신만을 위한 무명의 소프트웨어가 되거나 컴퓨터 역사상 길이 남을 명작이 되거나……

어디에서 들은 말인지 기억이 가물가물하지만 필자는 이런 말하기를 좋아한다.

"못하는 사람이 잘하는 사람 이기지 못한다. 이는 원래 당연하다.
그러나 잘하는 사람이라도 좋아하는 사람 이기기 어렵고
좋아하는 사람이 미친 사람 절대 못 이긴다!"

필요는 발명의 어머니이다. 그러나 좋아하고 미칠 때에만 명작을 낳는다.


2. 자연스럽게 프로그래밍을 하게 된 사람
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


프로그래밍과 별 연관이 없는 사람인데 프로그래밍을 하기 시작할 때가 있다.
이런 종류의 사람들이 요즘 많아지는데 이는 바로 리눅스(Linux)를 통해 유닉스적인 사용 전통이 부활했기(원래 죽지는 않았다. 단지 많은 PC 사용자에 의해 가려졌을 뿐이지) 때문이다.

이들은 대부분 시스템 관리자나 네트웍 관리자로서 실전적인 일에 종사하고 있는 사람들이다. 그리고 절대적으로 리눅스, FreeBSD와 같이 개방적인 운영체계에서 작업하는 사람들이 많다. 이들에게는 매우 기본적인 것만 주어져 있으나 그와 동시에 기본적인 것들을 묶어 사용할 수 있게 해주는 환경이 함께 제공되고 있다. 많은 기본 유닉스 명령을 이용하여 시스템과 네트워크 관리 작업을 할 수 있으며 쉘(Shell), 펄(Perl), Tcl /Tk의 관리/통합 환경이 주어져 있다.

상대적으로 윈도우즈NT 관리자 중에서 “필요에 의해 자연스럽게 프로그래밍에 빠져드는” 관리자가 거의 없는 이유는 분명한 듯 하다. 짜맞춰져 있는 메뉴와 버튼 이외 별다른 선택이 없는 유연하지 않은 시스템이며 새로운 조합을 만들고 싶어도 원래부터 조합도 힘들고 거의 모든 개발 환경이 돈을 주고 구입해야 하기 때문이다(게다가 불법 복사를 조장할 만큼 비싸기까지 하다.)

이들에게는 일상의 작업이 많고 반복적이다. 따라서 무기력한 사람이 아니고서야 “조금 더 편하고 게으르게“ 일을 할 수는 없을까라는 생각을 자연스럽게 하게 된다.

가장 기본적인 인터페이스인 유닉스 쉘은 윈도우즈에서의 그래픽한 쉘 환경, 탐색기 또는 파일 관리자에 비교할 수 없을 만큼 초라해 보이고 구석기 시대의 유물처럼 보이지만 풍부한 자체 스크립트 언어를 가지고 아직도 유용성을 가지고 살아있다는 점을 인정해야 한다.

예를 들어 쉘 스크립트 언어는 뭔가 거대한 응용 프로그램을 만드는 언어가 아니다. 원래 그런 목적을 가지고 만든 것이 아니기 때문에 그런 일을 하지 못한다고 비난할 필요조차 없다. 쉘 스크립트 언어는 유닉스/리눅스 관리 사용자의 둘도 없는 친구이다.

처음부터 모든 것을 다 알고 시작할 필요는 없다. 원하는 작업 패턴에 따라 하나씩 익혀 가는 것이 순리이다.

이럴 때에는 이렇게 하고 싶다! (if, case)

반복해서 하고 싶다. (while)

순차적으로 하고 싶다. (for 또는 foreach)

우선 몰라도 쉘에 관련된 것을 처음부터 끝까지 읽어나가는 것이 중요하다. 한 번 읽어서 모두 이해가 되길 바라는 도둑님같은 심보는 버리도록 하자(이 말은 어디에나 적용된다). 쉘에 관한 한 if, while, for를 잘 익혀두자. 사실 모든 언어가 각자의 특성을 가지고 있다 하더라도 조건/반복은 모든 컴퓨터 프로그래밍 언어의 핵심 구조이다.

필자 자신은 “절대로 한 번에 이해할 리 없다”라는 확신을 가지고 첫번째 독서는 마음 편하게 (그러나 빠른 속도로) 읽어 내려가는 편이다. 그리고 나면 충분히 이해하지는 못해도 대충 각 제목에서 “이런 것은 할 수 있다. 이런 것은 못한다”라는 윤곽 정도는 잡게 된다.

이것만으로 큰 수확이지 않은가?
무엇이 가능한지 아닌지 대략 짐작은 할 수 있으므로 헛수고를 피할 수 있다.

이 부류의 사람들은 거의 대부분 계속 “자연스럽게 프로그래밍하는 사람”으로 남는 경향이 많다.

대부분 간단한 쉘 스크립트, 펄 스크립트를 만드는데 그치지만 때로는 현실 경험에 의거하여 정말 쓸모 있는 종류의 소프트웨어(자족적인 소프트웨어가 아니라)를 만들어 내는 경향이 있다. 핵심 프로그램은 아니지만 이들의 기여가 없으면 컴퓨터 세계는 매우 밋밋할 것이 분명하다.

특히나 리눅스에서는 이들의 기여가 엄청나다. 이 부류의 사람들은 전문 프로그래머라고 생각하는 사람보다 오히려 훨씬 개방적이어서 자신의 필요를 빠르고 효율적으로 완성시켜 줄 수 있는 도구, 즉 언어의 새로운 출현에 항상 호기심을 갖고 배운다.
이런 관점에서 전문 프로그래머보다 더 박식하고 행복하게 프로그래밍한다.

____________________
| 책 구입, 프린팅에 |
| 인색하지 말자 |----------------------------------------+
+~~~~~~~~~~~~~~~~~~~~+ |
| |
| 개인적으로 책을 모으는 취미가 있기도 하지만 다음과 같은 생각은 매우 위험하다고 |
| 생각하며 하나의 주제에 대해서도 최소 2개 이상의 책이나 문서를 가지고 있어야 |
| 한다고 주장한다. |
| |
| 적지 않은 사람들이 어떤 한 주제에 대한 훌륭한 책 한 권에 만족하려는 듯 하다. |
| 그러나 어떠한 훌륭한 책도 모든 것을 담을 수 없다. 예를 들어 펄(Perl)이라는 |
| 언어에 관한 한 펄의 원저자인 래리 월(Larry Wall)씨의 책은 당연히 |
| 뛰어난 내용과 설명, 재치가 들어있다. 그러나 경험적으로 원저자보다 조금은 |
| 다른 관점에서 더 잘 설명하는 저자들이 많으며 그들로부터 실전적인 경험을 |
| 더 많이 얻을 수 있다. 어떤 때에는 원저자가 아닌 저자의 글을 읽고 나서 |
| 원저자의 글을 잘 이해할 수 있게 되는 경우도 있다. |
| |
| 풍부한 지식을 얻고 실전적인 지식을 얻으려면 여러 권의 책 또는 웹 상의 |
| 문서를 경험하는 방법 이외에는 없다. |
| |
| 리눅스를 사용하면서 질 좋은 내용은 문서 또한 프리 매뉴얼(Free Manual)의 |
| 형태로 풍부하다는데 놀라지 않을 수 없었다. LDP |
| (국내에서는 KLDP, http://kldp.org)와 같은 노력이 그러하다. PS(포스트스크립트) |
| 문서로 되어 있는 매뉴얼들을 포스트스크립트 프린터가 없다 하더라도 |
| 리눅스에서 고스트스크립트(ghostscript)라는 것을 이용하여 일반 프린터에서도 |
| 예쁘게 찍어 놓을 수 있어 좋다. |
| |
| 물론 초보자에게는 별로 적합하지 않은 실전적인 매뉴얼들이다. 따라서 여러분이 |
| 감당할 수 있는 문서만 출력한다. (지금은 상당히 많이 개선되었지만) 필자처럼 |
| 출력광(print mania)이 되어 좋은 문서만 발견하면 “일단 찍어놓고 보자”는 |
| 식의 사람들도 적지 않다. 사무실 한 쪽에 쌓여만 가는 깨끗한 출력 문서를 |
| 보면 부담스러워진다. 이에 대해서는 여러분의 판단에 맡긴다. |
|____________________________________________________________________________________|



3. 프로그래밍을 해야 하는 사람
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

프로그래밍이 마냥 좋아서 시작하던 사람들은 언젠가 자연스레
“프로그래밍을 해야하는 사람”으로 지위 변신을 하게 된다. 학생에서 사회인이
되었다는 말이다. 이제부터는 본격적으로 “지배받는” 프로그래밍이 시작된다.

어느 프로젝트 팀원에 속해 있다면 프로젝트 설계자가 아닌 이상 전체를 위한
일부가 되어 유기적으로 움직여야 한다. 이 때 가장 중요한 것은 당연히 여러분
자신의 개성과 창의성보다 서로 간의 교류와 협력이다. 프로그래밍 규칙이 완전히
바뀌게 되었음을 의미한다. 재미있어 보이는가?

만약 주문에 따라 프로그래밍을 하는 경우라면, 기존 프로그래밍 성과에 대한
고객의 신뢰, 신속, 약속 이행이 무엇보다 중요하다. 그 중 고객이 제일 중요하게
생각하는 것은 약속 이행일 것이다. 약속한 시간과 구현하겠다고 하는 기능에 대한
약속을 지켜야 한다.

이러한 부담 아래서 코딩해야 할 때에는 주어진 작업에 대하여 프로그래머로서의
능력을 “준비해 둔 상태인가”가 중요하다. 코딩을 시작하면서 새로운 것을 배운다는
것은 이미 실패(절반의 실패 또는 완전한 실패, 어찌 되었든 실패)를 예견한다.
데드라인까지 새로운 것을 배울 시간은 없다.

중간중간 기발한 아이디어와 디자인이 떠오를지는 몰라도 그것을 실현할 무기는
“이미 배워둔 언어와 현실 팁”뿐이다. “프로그래밍을 좋아하는” 단계에서
충분히 배우고 실습하지 않았다면 고통의 나날이 시작될 것이다.


4. 가장 완벽한 상황
~~~~~~~~~~~~~~~~~~~

가장 완벽한 상황은 프로그래밍을 좋아해서 시작했는데 공교롭게도 자기 주변
작업에서 프로그래밍의 필요성이 있고 따라서 필요한 소프트웨어를 좋아서
추진하는 상황이다.

어느 정도 언어도 충분히 많이 익히고 실전의 경험(코딩하고 디버깅하고
코딩하고 디버깅하고……)을 쌓아 인간이라면 누구나 빈번하게 저지를 수밖에
없는 문제를 피해 가거나 금방 눈치챌 수 있는 상태가 되기 바로 직전에 본업
프로그래머로 뛰어든다.

좋아하는 일이 있고 좋아하는 일을 잘 하며 좋아하는 일을 통해 삶을 꾸려
나갈 수 있을 때 가장 완벽하다고 생각한다. 그렇지 않을 사람이 있을까?

그러나 이런 완벽한 상황을 누리고 있는 프로그래머가 전 세계적을 얼마나 될까?
열악하다고 말하는 국내에는 도대체 이렇게 행복한 프로그래머가 있기는 있는 것일까?

현실 세계에서는 행복해지려는 찰나에 방해하는 요소들이 적지 않다. 따라서
전투에서처럼 교두보를 하나씩 점령해나가는 것이 필요하다.

젊고 유능한 프로그래머가 되기 위해 그리고 행복한 프로그래머가 되기 위해 어떤
것부터 시작해야 할까?

================================================================================
프로그래머가 되고 싶다!
================================================================================

필자도 그러했지만 여전히 많은 젊은 친구들(필자가 어른이라서 내려 부르는 의미로
부르는 것이 아니다. 우리 나이 또래는 친구다!)은 몇몇 매스컴과 사업상의 성공
모델을 보고 그렇게 “성공적인 프로그래머”를 어렴풋하게 꿈꾸는 듯 하다.

만약 마이크로소프트 사의 빌 게이츠(Bill Gates)와 같은 사람을 모델로 선정했다면
필자는 약간의 코멘트를 달지 않을 수 없다.

빌 게이츠는 “프로그래머”였겠지만 “프로그래머로서 성공”한 것은 아니다.
이 말이 프로그래머로서의 빌 게이츠를 깍아 내리는 것은 아니다. 하지만 동시에
뛰어난 프로그래밍 능력을 갖추었기 때문에 성공했다고 “위험하게“ 말할 수
없다는 것이다. 현실 세계에서 프로그래밍만 잘해서 금전적인 성공을 거둔 사례가
있는지 의심스럽다.

성공적인 프로그래머, 따라서 더 이상은 프로그래머가 아닌(왜냐하면 프로그래밍할
시간도 없는 비즈니스맨이 되어버리기 때문에) 성공적 인간이 되기 위해서는
빌 게이츠나 기타 다른 사람처럼 프로그래머로서의 자질 이외의 알파 요인이
있어야 한다.

예를 들어 사업 수완, 용병술 등은 다른 비즈니스 수업이나 비즈니스맨에게 들어야
할 내용이다.

이 글은 “성공적인” 프로그래머가 되기 위해 프로그래밍 기술과 자신감 이외의 다른
요소를 강조하기 위해 쓰고 있지 않다. 필자는 아직 그런 말을 할 경험과 자격을
갖추지 않았다.

앞으로 “프로그래머로서 성공적”이라는 의미는 원하는 일을 잘 설계하고 가장
효율적으로 그리고 즐겁게 프로그래밍 기술을 이용하여 원하는 소프트웨어를 만들 수
있는 능력과 개성을 갖추었다는 사실을 뜻한다.


그래도 나는 프로그래머가 되고 싶다!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

훌륭한 선택이다. 왜냐? 이 세상에는 재미있는 일로 가득차 있는데 그 중에서 다른
것 못지 않게 재미있는 것이 프로그래밍이기 때문이다. 그리고 현실 세계보다 훨씬
정직한 세계라는 사실에 매료되기도 한다.

글 뒤에서 안내하겠지만 화가가 그림을 그리기 위해서는 주체할 수 없는 창작의
욕구를 받쳐 줄만한 그리기 기술(캔버스, 붓, 물감 사용법)이 필요한데 프로그래밍에서는
프로그래밍 설계, 프로그래밍 언어가 그에 해당된다. 이 기본 기술을 익히지
않으면(정확히 말해서 항상 익혀나가지 않으면) 창작 욕구는 표현될 수 없다.

여러분의 머릿속에 있는 아이디어는 어떤 식으로든 프로그램 소스 코드의 형태로
표현되어야만 의미를 갖는다. 그냥 머릿속이나 또는 광고를 위해 있지도 않은 것을
나올 것처럼 얘기할 때 그 소프트웨어를 Vaporware 또는 Dreamware라고 부른다.

프로그래머는 구체적인 결과물을 내야 하는 구체적인 활동의 인간이다.
따라서 프로그래머가 되겠다는 마음을 계속 간직하면서 다음 내용들을 잘
익혀나가야 한다.

프로그래머는 정신적인 디자이너다
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

필자가 단순 코딩을 해가면서 뼈저리게 느끼는 것이 바로 이 말이다.
프로그래머는 디자이너(designer)이기 때문에 디자이너여야 한다.
디자이너가 아닌 프로그래머는 단순 코드 입력 인력일 뿐이다.

프로그래밍의 시작은 항상 두뇌에서 시작하며 어떤 일인가를 어떤 논리적인
순서대로 해야 한다는 가장 간단한 수준의 구상부터 확실하게 시작해야 한다.
아이디어를 떠올리는 방법은 특별히 배우지 않아도 누구나 만들어낼 수 있지만
아이디어를 유지하는 일은 누구나 할 수 있는 일이 아니다.

아이디어가 나오면 필자는 적어둔다. 필자의 두뇌는 약간의 휘발성을 가진
메모리이기 때문이다. 항상 가지고 다니는 아이디어 수첩에 적어도 좋다.
필자는 요즘 커다란 스케치북을 구입하여 그 안에 시원스럽게 도표를 그리곤 한다.
작업간의 관계를 그림으로 표현해도 좋다. 프로그램의 목표를 구체적인 표현으로 만든
다음, 그 일을 해내기 위해 필요한 작업을 세분한다. 원도 그리고 화살표로
원들을 잇기도 하고 옆에 부연 설명을 적기도 한다.

생각을 덜 하고 코딩에 달려들면 몸이 고생한다. 때로 풀리지 않은 문제는
키보드 앞을 떠나 다시 디자인 수준에서 해결해야 할 때가 있다.

남의 코드를 많이 읽어봐야 한다
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

베스트셀러를 내는 작가들중 책을 많이 읽지 않은 사람이 있을까?
좋은 프로그램을 만들기 위해서는 좋은 프로그램을 많이 사용해 보아야 한다. 인간의
아이디어라는 것은 무(無)에서 만들어지지 않는다. 아이디어는 경험한 것 안에서 맴도는
경향을 갖는다. 많은 경험의 축적만으로도 자동적으로 아이디어가 떠오르기도 한다.

전통적으로 프로그램의 소스 코드는 볼 수 없었으므로 프로그램의 외형만 경험할 수
있었으나 리눅스를 비롯하여 오픈 소스 소프트웨어들이 많이 나오면서 풍부한
소스 코드를 읽을 수 있는 훌륭한 여건이 만들어졌다. 이는 얼마나 다행인지 모른다.
이제 코드를 읽어 배우는 직접 경험이 많아져서 좀 더 다양하고 질 높은 소프트웨어들이
나올 것이라 기대하고 있다.

아무리 짧고 어색한 코드라도 중요하다. 여러분의 해결책에 앞서 어떤 문제를 풀기
위한 코드가 있을 때 그 코드를 우선 존경할 필요가 있다. 이 세상 그 누군가가 적어도
나보다는 먼저 어떤 문제에 대한 해결책을 고민했고 최소한 나보다 먼저 실제 코딩에
나섰기 때문이다. 항상 어려운 것은 개척 또는 선두주자이다. 중세 전쟁 영화를 보면
병사들이 성벽에 사다리를 놓고 기어올라가는 장면을 볼 수 있다. 얼마나 많은
병사들이 희생되는가? 난공불락의 요새처럼 보이던 성도 한두 명의 병사가 올라가기만
하면 금방 함락된다.

남의 코드를 존경하며 마음에 들지 않은 부분이 있다면 개선해서 이용하면 된다.
이유를 막론하고 남이 보여주는 소스 코드 보기를 게을리하지 말자.

다음 호에는 가장 중요한 부분인
프로그래밍 언어를 배우는 방법을 중심으로 보다 구체적인 이야기를
하고자 한다.