개성있는 프로그래머가 되는길(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)이기 때문에 디자이너여야 한다.
디자이너가 아닌 프로그래머는 단순 코드 입력 인력일 뿐이다.

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

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

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

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

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

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

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

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

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

수식이나 작업을 컴퓨터에 알맞도록 정리해서 순서를 정하고 컴퓨터 특유의 명령코드로 고쳐 쓰는 작업을 총칭해서 프로그래밍이라 하고, 컴퓨터의 명령 코드를 쓰는 작업을 특히 코딩(coding)이라고도 한다.
컴퓨터가 처음 나타난 1950년대 초기까지는 프로그래밍은 숫자를 나열한 명령코드를 쓰는 것이었다. 이것을 기계어(machine language)라 한다. 그러나 기계어에서는 틀리기 쉽고, 또한 틀린 곳을 발견하기가 어렵다는 등 작업하기가 곤란하므로, 그 후 인간이 외우기 쉬운 기호나 언어 ·수식을 사용해서 프로그램을 쓰고, 그것을 일단 컴퓨터에 넣어서 컴퓨터 자신의 명령코드로 고쳐 그것으로부터 계산을 실시하는 방식이 고안되었다. 이것은 프로그램을 만드는 작업의 일부를 컴퓨터 자체에 부담시켜 작업 능률을 향상시키자는 방식이다.

코드란? 기호(記號)의 계열을 다른 기호 계열로 표현할 때의 약속, 또는 그 기호 계열을 말한다. 전신(電信)에서는 한글문자를 전기의 음양 또는 단속(斷續) 등의 전기신호로 바꾸어 보내는데, 그 때의 한글 문자와 전기신호의 대응, 또는 전기신호의 음양을 나타내는 기호계열을 코드라고 한다. 장단(長短) 2종의 전기신호로 모든 문자를 나타내는 모스부호는 오래 전부터 사용되어 왔으며, 데이터통신이 많이 이용되면서부터 0과 1로 나타내는 2종의 기호를 사용한 많은 코드가 고안되어 실용화되었다. 컴퓨터용에서는 정보를 표현하기 위한 기호의 체계를 코드라고 하며, 프로그램을 만들 때는 명령이나 수치를 코드로 나타낸다. 또 개개의 글자는 2진숫자(二進數字)에 의한 코드로 나타낸다. 코드의 종류에는 연번 코드 ·십진 코드 ·그룹 코드 ·블록 코드 ·표의문자 코드 ·표지 코드 ·약자 코드 ·수학식 문자 코드 등이 있다. 코드를 만드는 것은 컴퓨터 등에 의한 기계처리를 가능하게 하기 위해서이다. 천공카드시스템에서는 기계적 제약으로 숫자의 코드가 많았으나 컴퓨터가 이용된 후 문자의 조합도 가능해졌다.

기계어란? 컴퓨터가 직접 해독할 수 있는 2진 숫자(binary digit)로 나타낸 언어로 프로그래밍 언어의 기본이 된다. 즉 컴퓨터를 작동시키기 위해 0과 1로 나타낸 컴퓨터 고유 명령 형식이다. 프로그램은 기계어로 번역되어야만 컴퓨터가 그 내용을 이해하고 작동하는데 기계어로 번역하는 프로그램에는 어셈블러(assembler)와 컴파일러(compiler)가 있다. 기계어의 구조는 컴퓨터에 따라 다른데 컴퓨터 고유의 명령 형식을 인스트럭션 포맷이라고 하며, 여러 개의 입출력 명령, 수치 및 논리 연산(演算) 명령, 자료 이동 및 분기 명령으로 구성된다. 기계어의 명령 단위는 어떤 동작을 지시하는 명령 코드부와 동작의 대상이 되는 데이터가 어느 위치에 기억되어 있는지를 지시하는 주소부로 나누어진다. 컴퓨터 개발의 초기, 즉 스토어드 프로그램방식(stored program system)이 출현하기 전까지의 프로그램은 모두 기계어로 쓰여지고 있었다. 그러나 기계어는 이해하기 어렵고 컴퓨터 구조에 대한 충분한 지식이 없으면 프로그램 작성을 할 수 없기 때문에 범용성(汎用性)이 부족하고 숫자(0과 1)를 사용함에 따라 프로그래머의 수고가 많이 필요하고 시간이 많이 걸린다. 그래서 많은 프로그래밍 언어들이 개발되었으며, 얼마 전부터는 기계어로 프로그램을 작성하는 것은 거의 사라졌다.

1. C와 C++은 다른 언어이다.

C와 C++은 다른 언어입니다. 거의 비슷하다구요? 예! 정말 비슷합니다. 하지만 분명 C와 C++은 다른 언어입니다. 만약 C++이 C의 단순한 확장이었다면 모두가 C++을 써야하는게 맞는거겠죠. 대학교 다니시면서 프로그래밍 언어론을 배우신 분들은 아시겠지만 모든 언어는 각자의 장단점이 있고 그 장점이 퇴색하지 않는 이상 언어는 사장되지 않습니다. 만약 어디서든 "강력한" 언어가 있다면 모르겠지만 말이죠. 예를들면 똑같은 Microsoft에서도 VC++, VB, VJ++, VF 등의 많은 언어를 출시합니다. 물론 MS같은 경우에는 전략적인 목표로 인한 경우도 있지만 실제로 그런 언어들이 그 언어의 장점으로 인해 실제로 사용되고 있습니다.

2. 그럼 C와 C++이 어떻게 다른가?

C++을 배우신분들은 이미 답을 다 알고 있습니다. 기억이 안나거나 중요하게 생각하시지 않으셨겠지만요. C++은 OOP를 반영한 언어입니다. OOP는 큰 프로젝트나 대형의 프로그램의 설계시 코딩과 디버깅의 효율성을 높이기 위해 나온 개념입니다. 당연히 C++은 큰 프로젝트와 대형의 프로그램의 설계시 유용합니다. C는 당연히 C++에게 위의 사항을 뺏겼고 심지어 위의 사항이 단점이 되었습니다. 하지만 "아직까지 수많이 쓰이는" C는 위의 사항의 반대상황에서는 C++보다 더 강력하고 유용합니다. 실제로 저사양의 시스템이나 제어관련 시스템에서는 C++언어는 포팅되지 않은 경우도 허다합니다. 또한 작은 프로젝트와 저용량 프로그램의 설계시 C는 상당히 직관적이고 빠르고 훌륭한 프로그램이 됩니다. 이런 일에 C++을 사용한다면 10발자국 움직이려고 차를 움직이는 것과 같은 것이죠.

3. 그럼 C와 C++중 어느것이 더 유용한가?

"임베디드 시스템을 공부하는 사람과 범용 시스템을 공부하는 사람과 어느 사람이 더 성공할까요?" 이 질문은 옳은 질문이 아닙니다. 왜냐하면 경우에 따라 다르거든요. "C와 C++중 어느것이 더 유용하느냐? 좋으냐?"는 질문도 별다를바 없습니다. 써야하는 곳 쓰고싶은 곳에 쓰는 것이니까요. 하지만 일반적으로 "하드웨어 의존적이지 않은" 소프트웨어의 길로 나가실 거라면 C++이 조금 더 유용하다는 것을 말씀드리고 싶습니다.

4. C만할줄 아는 사람이 C++프로젝트에 참가했을때

아주 심각합니다. C만 할줄 아는 사람은 프로젝트에 참여하는게 아니라 코더로 전락할 가능성이 높습니다. OOP의 개념조차 서있지 않은 사람에게 프로그램의 설계를 맡길 수는 없죠. 그러니 메쏘드의 기능을 설명해주고 그런 부분을 짜라고 할 수 밖에 없습니다.

5. C++만 할줄 아는 사람이 C프로젝트에 참가했을때

이 경우는 전자보다 더 심각합니다. C는 C++의 중요한 문법을 받아들이지 못합니다. 때문에 C++프로그래머는 자신의 프로그래밍 방식을 포기해야합니다. 결국 프로그램은 번듯한 양복에서 반쪽짜리 너덜너덜한 거지옷이 되어버리기 일쑵니다.

6. 그럼 왜! C와 C++을 다 배워야 하는가?

이 질문을 저는 조금 더 확대하겠습니다. 눈을 좀 넓히셔야 될 것 같아서요. "왜! C, C++, Java, Python, Basic, Pascal, Lisp을 다 배워야 하는가?"라는 질문이 더 좋은 질문인 것 같습니다. 앞에서 말씀드렸다시피 언어는 각자의 특징이 있고 그 특징이 사라지지 않는한 그 언어는 죽지 않습니다. 여러분이 C와 C++의 단점을 그대로 지니고 프로그래밍을 하실거라면 어쩔 수 없지만 그런 단점을 조금이라도 극복하시고 싶다면 여러 언어를 익히는게 더 좋은 방법입니다. 만약 그런 언어들의 장점을 아시고 싶으시다면 프로그래밍 언어론 관련 서적을 읽으시든지 아니면 교수님과 진지한 대화를 한번쯤 나누시는게 좋을 듯합니다. 저도 저 잘난줄 알고 Java를 꼭 배워야 하느냐는 질문을 교수님께 던졌다가 정말 부끄러웠습니다.(패키지 게임만들 내가 Java는 배워서 어디다가 써먹냐는 생각이었쬬.) 교수님 말씀은 "언어를 배울때는 의심하지 마라. 거기서 무엇을 배울지 생각해라" 였죠...

7. 그럼 C와 C++ 어느걸 먼저 배워야 할까요?

여러분이 먼저 배우길 원하시는 방향으로 가닥을 잡으면 됩니다. 높이 나는 새(C++프로그래밍)는 멀리 보지만 가까운 것을 오히려 못볼 수 있고, 낮게 나는 새(C프로그래밍)은 나무는 보되 산은 못볼 수있습니다. 산을 먼저 보시고 싶다면 C++, 나무를 먼저 보시고 싶다면 C를 배우시면 됩니다.

8. 종합

김용의 무협지를 읽으면서 사람들이 토론합니다. 동방불패가 최강이냐 독고구패가 최강이냐? 벽사신검이 최강이냐 독고구검이 최강이냐? 제가 말합니다. 그들이 쓰여야 할 곳에서는 그들이 최강이다. 그들이 쓰여지지 않아야 할 곳에서는 그들은 아무것도 아니다.

처음 블로그를 사용해봅니다.

많이 도와주시고 놀러와주세요~

ㅋㅋㅋ

옛날부터 해야지.. 해야지.. 하던 블로그

오늘에서야 드디어 해보는구만;;

계속해서 잘 만들어가보자고~