개성있는 프로그래머가 되는 길
================================================================================
For a computer guru
개성있는 프로그래머가 되는길(1)
저자 : 이만용(프로그램 세계 기사)
================================================================================
모든 사람이 컴퓨터를 좋아하는 것은 아니다. 더 나아가 컴퓨터를 유용하게 사용할 수 있도록 해주는
프로그래밍을 좋아하는 것도 아니다. 일반적으로
프로그래밍을 좋아하거나
프로그래밍이 왠지 자기에게 맞을 것 같은 사람들은 그렇지 않은 사람들과 분명히 다른 개성을 가지고 있다. 그 차이가 그렇게 크지는 않다 하더라도 결과물은 다르다. 한 사람은 프로그래머이거나 프로그래머라고 부를 수 있는 사람이고 다른 사람은 프로그래머가 전혀 아니다.
================================================================================
프로그래밍은 다음과 같은 몇가지 마음의 작용이 일어날 때 좋아지고 시도하게 만든다.
================================================================================
- 정말 훌륭한 소프트웨어를 사용해 보았으며 “언젠가는...” 자신도 그 정도 또는 그에 가까운 수준의 소프트웨어를 만들고 싶다는 존경심으로부터 나온 욕구
- 지금 현재하고 있는 작업이 불만스럽고 더욱 단순화시키고 싶다는 매우 현실적인 욕구
- 예전에는 이 둘 중 하나였으나 직업적인 말단 프로그래머가 되어 상부 팀장의 지시에 따라 어쩔 수 없이 해야 하는 의무
처음 자신을
프로그래밍하게 또는
프로그래밍 공부를 하게 만든 요인에 따라 앞으로의 선택 방법이 크게 달라진다.
참고로 필자는 겔로그와 제비우스(Xevious)와 같은 오락이 나오던 시절, 험상궂은 아저씨들이 담배를 피워대던 오락실에서 우두커니 서서 그 오락들에 매료되어
프로그래밍을 시작했다. 당연히 그 시절에는 베이직(BASIC)...
프로그래밍을 한다고 해서 모두가 똑같은
프로그래밍을 하는 것은 아닌 듯 하다. 사람이 다르면
프로그래밍 방식도 다르고
프로그래밍 방식이 다르면 나오는 작품도 천차만별이다. 소프트웨어는 크든 적든 어느 정도 프로그래머의 개성을 반영한다.
이 부류에 드는 사람들은 “대책이 없는(?)” 사람들이며 어느 누구도 말릴 수 없다. 누가 간섭하지 않아도 혼자서 바람도 안 부는데도 잘 도는 바람개비인 사람들이다. 이 사람들은 종종 “특별히 아무도 위하지 않는 자신만을 위한 프로그램”을 만들기 좋아한다. 그 사람의 개인적인 취향을 닮은 프로그램이 많으며 그 프로그램에는 프로그램을 만든 사람의 “인격(Character)”이 들어있다 해도 과언이 아니다.
프로그래밍이 원래 좋아서 코딩하는 사람은 아니라 하더라도, 이 세상에 태어나 자기 인격을 가지고 있으며 자기와 동일시 할 수 있는 프로그램 하나 만들어 보는 것이 프로그래湛?간절한 소원이 아닐까? 여러분은 어떠한가?
프로그래밍하는데 그런 희망 내지는 야망 하나 없다면 얼마나 밋밋하겠는가? 오늘도 버거운
프로그래밍 과제를 부여받는 말단 프로그래머의 마음 한 구석에는 자기를 표현해주는
프로그래밍 과제가 조용히 끓고 있을 것이다.
요즘 전세계적인 열풍을 몰고 있는 리눅스(Linux)는 “
프로그래밍이 좋아서” 만들어진 대표적인 작품 중 하나다.
일반 응용 프로그램과 달리 운영체계 커널이라는 것은 사람들에게 화려하게 보이지도 않으며 관심을 많이 끌지 않는다. 리누스(Linus)가 현재와 같은 성공을 예견하고 리눅스를 코딩하기 시작했다고 신화화시킬 수 있을까?(리누스 그 자신이 거세게 항의하고 나올 것이다. 리누스는 항상 리눅스 디자인의 핵심은 재미(fun)여야 한다고 강조한다).
예를 들어 인텔(Intel) 플랫폼이 아닌 알파(Alpha) 플랫폼과 같은 이 기종에 리눅스가 돌아갈 수 있을 것이라고는 리누스 자신도 생각하지 못했다고 한다. 신(God)은 예견했는지 몰라도, 신이 리누스나 다른 커널 개발자들의 손을 빌렸다고 말할 수 있을 지는 몰라도, 직접 손을 사용하여 코딩을 한 사람은 모르고 한 일이며 그 주위에 있는 사람들은 더더욱 모르고 한 일이다. 우리 중 예언자가 있으면 모를까……
리눅스는 리누스가 가지고 있던 386PC를 위한 개인 취미 프로젝트라는 사실을 많은 사람이 알고 있다.
그 후 지금까지 성장하기 위해서는 “단지 좋아서 자발적으로 열심히”라는 조건 이상의 것이 있었다는 게 분명하다(조금 뒤에 다룰 것이다). 그러다 다음 사실은 분명하다.
“단지 좋아서”, “자기의 인격을 닮은” 무엇인가를 만들어서 “자기 자신을 즐겁게“ 하기 위해 만들어진 프로그램에는 임시 땜질과 같은 거짓 요소가 없고 오히려 순도와 완성도가 높을 때가 많다. 이는 기본적으로 자기 좋아서 하는 일에 대하여 프로그래머가 자기를 속이는 일은 없으며 무엇보다 데드라인(dead line)이 없기 때문에 미봉책을 쓸 이유조차 없기 때문이다. 문제에 봉착하면 포기하거나 자기 에너지를 모두 소비할 때까지 붙어있으면 그만이지 대충 마무리 지을 이유는 없다.
좋아서 만드는 프로그램이 장난감 수준의 소프트웨어라고 말하고 싶은 사람도 있을 지 모른다. 이미 전문가적인 수준의 프로그래머들이 그렇게 볼 지 모르지만 실상은 그렇지 않다!
감히 리차드 스톨맨(Richard M. Stall man, 줄여서 rms라고 많이 부른다. FSF 회장이며 GNU 프로젝트의 창시자)씨의 이맥스(Emacs)는 “좋아서” 만든 소프트웨어라고 생각하며 여러분도 알다시피 순도높고 리차드 스톨맨씨의 인격을 닮은 프로그램이라 말하고자 한다.
리눅스도 기본적으로 그러하다.
좋아서 만드는 프로그램은 둘 중 하나가 된다. 정말로 원래 의도했던 그대로 자기 자신만을 위한 무명의 소프트웨어가 되거나 컴퓨터 역사상 길이 남을 명작이 되거나……
어디에서 들은 말인지 기억이 가물가물하지만 필자는 이런 말하기를 좋아한다.
“못하는 사람이 잘하는 사람 이기지 못한다. 이는 원래 당연하다. 그러나 잘하는 사람이라도 좋아하는 사람 이기기 어렵고 좋아하는 사람이 미친 사람 절대 못 이긴다!”
필요는 발명의 어머니이다. 그러나 좋아하고 미칠 때에만 명작을 낳는다.
프로그래밍과 별 연관이 없는 사람인데
프로그래밍을 하기 시작할 때가 있다. 이런 종류의 사람들이 요즘 많아지는데 이는 바로 리눅스(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)이 되어 좋은 문서만 발견하면 “일단 찍어놓고 보자”는 식의 사람들도 적지 않다. 사무실 한 쪽에 쌓여만 가는 깨끗한 출력 문서를 보면 부담스러워진다. 이 에 대해서는 여러분의 판단에 맡긴다. |
프로그래밍이 마냥 좋아서 시작하던 사람들은 언젠가 자연스레 “
프로그래밍을 해야하는 사람”으로 지위 변신을 하게 된다. 학생에서 사회인이 되었다는 말이다. 이제부터는 본격적으로 “지배받는”
프로그래밍이 시작된다.
어느 프로젝트 팀원에 속해 있다면 프로젝트 설계자가 아닌 이상 전체를 위한 일부가 되어 유기적으로 움직여야 한다. 이 때 가장 중요한 것은 당연히 여러분 자신의 개성과 창의성보다 서로 간의 교류와 협력이다.
프로그래밍 규칙이 완전히 바뀌게 되었음을 의미한다. 재미있어 보이는가?
만약 주문에 따라
프로그래밍을 하는 경우라면, 기존
프로그래밍 성과에 대한 고객의 신뢰, 신속, 약속 이행이 무엇보다 중요하다. 그 중 고객이 제일 중요하게 생각하는 것은 약속 이행일 것이다. 약속한 시간과 구현하겠다고 하는 기능에 대한 약속을 지켜야 한다.
이러한 부담 아래서 코딩해야 할 때에는 주어진 작업에 대하여 프로그래머로서의 능력을 “준비해 둔 상태인가”가 중요하다. 코딩을 시작하면서 새로운 것을 배운다는 것은 이미 실패(절반의 실패 또는 완전한 실패, 어찌 되었든 실패)를 예견한다. 데드라인까지 새로운 것을 배울 시간은 없다.
중간중간 기발한 아이디어와 디자인이 떠오를지는 몰라도 그것을 실현할 무기는 “이미 배워둔 언어와 현실 팁”뿐이다. “
프로그래밍을 좋아하는” 단계에서 충분히 배우고 실습하지 않았다면 고통의 나날이 시작될 것이다.
4. 가장 완벽한 상황
가장 완벽한 상황은
프로그래밍을 좋아해서 시작했는데 공교롭게도 자기 주변 작업에서
프로그래밍의 필요성이 있고 따라서 필요한 소프트웨어를 좋아서 추진하는 상황이다.
어느 정도 언어도 충분히 많이 익히고 실전의 경험(코딩하고 디버깅하고 코딩하고 디버깅하고……)을 쌓아 인간이라면 누구나 빈번하게 저지를 수밖에 없는 문제를 피해 가거나 금방 눈치챌 수 있는 상태가 되기 바로 직전에 본업 프로그래머로 뛰어든다.
좋아하는 일이 있고 좋아하는 일을 잘 하며 좋아하는 일을 통해 삶을 꾸려 나갈 수 있을 때 가장 완벽하다고 생각한다. 그렇지 않을 사람이 있을까?
그러나 이런 완벽한 상황을 누리고 있는 프로그래머가 전 세계적을 얼마나 될까?
열악하다고 말하는 국내에는 도대체 이렇게 행복한 프로그래머가 있기는 있는 것일까?
현실 세계에서는 행복해지려는 찰나에 방해하는 요소들이 적지 않다. 따라서 전투에서처럼 교두보를 하나씩 점령해나가는 것이 필요하다.
젊고 유능한 프로그래머가 되기 위해 그리고 행복한 프로그래머가 되기 위해 어떤 것부터 시작해야 할까?
================================================================================
프로그래머가 되고 싶다!
================================================================================
필자도 그러했지만 여전히 많은 젊은 친구들(필자가 어른이라서 내려 부르는 의미로 부르는 것이 아니다. 우리 나이 또래는 친구다!)은 몇몇 매스컴과 사업상의 성공 모델을 보고 그렇게 “성공적인 프로그래머”를 어렴풋하게 꿈꾸는 듯 하다.
만약 마이크로소프트 사의 빌 게이츠(Bill Gates)와 같은 사람을 모델로 선정했다면 필자는 약간의 코멘트를 달지 않을 수 없다.
빌 게이츠는 “프로그래머”였겠지만 “프로그래머로서 성공”한 것은 아니다. 이 말이 프로그래머로서의 빌 게이츠를 깍아 내리는 것은 아니다. 하지만 동시에 뛰어난
프로그래밍 능력을 갖추었기 때문에 성공했다고 “위험하게“ 말할 수 없다는 것이다. 현실 세계에서
프로그래밍만 잘해서 금전적인 성공을 거둔 사례가 있는지 의심스럽다.
성공적인 프로그래머, 따라서 더 이상은 프로그래머가 아닌(왜냐하면
프로그래밍할 시간도 없는 비즈니스맨이 되어버리기 때문에) 성공적 인간이 되기 위해서는 빌 게이츠나 기타 다른 사람처럼 프로그래머로서의 자질 이외의 알파 요인이 있어야 한다.
예를 들어 사업 수완, 용병술 등은 다른 비즈니스 수업이나 비즈니스맨에게 들어야 할 내용이다.
이 글은 “성공적인” 프로그래머가 되기 위해
프로그래밍 기술과 자신감 이외의 다른 요소를 강조하기 위해 쓰고 있지 않다. 필자는 아직 그런 말을 할 경험과 자격을 갖추지 않았다.
앞으로 “프로그래머로서 성공적”이라는 의미는 원하는 일을 잘 설계하고 가장 효율적으로 그리고 즐겁게
프로그래밍 기술을 이용하여 원하는 소프트웨어를 만들 수 있는 능력과 개성을 갖추었다는 사실을 뜻한다.
그래도 나는 프로그래머가 되고 싶다!
훌륭한 선택이다. 왜냐? 이 세상에는 재미있는 일로 가득차 있는데 그 중에서 다른 것 못지 않게 재미있는 것이
프로그래밍이기 때문이다. 그리고 현실 세계보다 훨씬 정직한 세계라는 사실에 매료되기도 한다.
글 뒤에서 안내하겠지만 화가가 그림을 그리기 위해서는 주체할 수 없는 창작의 욕구를 받쳐 줄만한 그리기 기술(캔버스, 붓, 물감 사용법)이 필요한데
프로그래밍에서는
프로그래밍 설계,
프로그래밍 언어가 그에 해당된다. 이 기본 기술을 익히지 않으면(정확히 말해서 항상 익혀나가지 않으면) 창작 욕구는 표현될 수 없다.
여러분의 머릿속에 있는 아이디어는 어떤 식으로든 프로그램 소스 코드의 형태로 표현되어야만 의미를 갖는다. 그냥 머릿속이나 또는 광고를 위해 있지도 않은 것을 나올 것처럼 얘기할 때 그 소프트웨어를 Vaporware 또는 Dreamware라고 부른다.
프로그래머는 구체적인 결과물을 내야 하는 구체적인 활동의 인간이다.
따라서 프로그래머가 되겠다는 마음을 계속 간직하면서 다음 내용들을 잘 익혀나가야 한다.
프로그래머는 정신적인 디자이너다
필자가 단순 코딩을 해가면서 뼈저리게 느끼는 것이 바로 이 말이다.
프로그래머는 디자이너(designer)이기 때문에 디자이너여야 한다.
디자이너가 아닌 프로그래머는 단순 코드 입력 인력일 뿐이다.
프로그래밍의 시작은 항상 두뇌에서 시작하며 어떤 일인가를 어떤 논리적인 순서대로 해야 한다는 가장 간단한 수준의 구상부터 확실하게 시작해야 한다. 아이디어를 떠올리는 방법은 특별히 배우지 않아도 누구나 만들어낼 수 있지만 아이디어를 유지하는 일은 누구나 할 수 있는 일이 아니다.
아이디어가 나오면 필자는 적어둔다. 필자의 두뇌는 약간의 휘발성을 가진 메모리이기 때문이다. 항상 가지고 다니는 아이디어 수첩에 적어도 좋다. 필자는 요즘 커다란 스케치북을 구입하여 그 안에 시원스럽게 도표를 그리곤 한다.
작업간의 관계를 그림으로 표현해도 좋다. 프로그램의 목표를 구체적인 표현으로 만든 다음, 그 일을 해내기 위해 필요한 작업을 세분한다. 원도 그리고 화살표로 원들을 잇기도 하고 옆에 부연 설명을 적기도 한다.
생각을 덜 하고 코딩에 달려들면 몸이 고생한다. 때로 풀리지 않은 문제는 키보드 앞을 떠나 다시 디자인 수준에서 해결해야 할 때가 있다.
남의 코드를 많이 읽어봐야 한다
베스트셀러를 내는 작가들중 책을 많이 읽지 않은 사람이 있을까?
좋은 프로그램을 만들기 위해서는 좋은 프로그램을 많이 사용해 보아야 한다. 인간의 아이디어라는 것은 무(無)에서 만들어지지 않는다. 아이디어는 경험한 것 안에서 맴도는 경향을 갖는다. 많은 경험의 축적만으로도 자동적으로 아이디어가 떠오르기도 한다.
전통적으로 프로그램의 소스 코드는 볼 수 없었으므로 프로그램의 외형만 경험할 수 있었으나 리눅스를 비롯하여 오픈 소스 소프트웨어들이 많이 나오면서 풍부한 소스 코드를 읽을 수 있는 훌륭한 여건이 만들어졌다. 이는 얼마나 다행인지 모른다. 이제 코드를 읽어 배우는 직접 경험이 많아져서 좀 더 다양하고 질 높은 소프트웨어들이 나올 것이라 기대하고 있다.
아무리 짧고 어색한 코드라도 중요하다. 여러분의 해결책에 앞서 어떤 문제를 풀기 위한 코드가 있을 때 그 코드를 우선 존경할 필요가 있다. 이 세상 그 누군가가 적어도 나보다는 먼저 어떤 문제에 대한 해결책을 고민했고 최소한 나보다 먼저 실제 코딩에 나섰기 때문이다. 항상 어려운 것은 개척 또는 선두주자이다. 중세 전쟁 영화를 보면 병사들이 성벽에 사다리를 놓고 기어올라가는 장면을 볼 수 있다. 얼마나 많은 병사들이 희생되는가? 난공불락의 요새처럼 보이던 성도 한두 명의 병사가 올라가기만 하면 금방 함락된다.
남의 코드를 존경하며 마음에 들지 않은 부분이 있다면 개선해서 이용하면 된다.
이유를 막론하고 남이 보여주는 소스 코드 보기를 게을리하지 말자.
다음 호에는 가장 중요한 부분인
프로그래밍 언어를 배우는 방법을 중심으로 보다 구체적인 이야기를 하고자 한다.
================================================================================
For a computer guru
개성있는 프로그래머가 되는길(2)
저자 : 이만용(프로그램 세계 기사)
================================================================================
인간이란 특히 기술자인 경우 목표 말고도 목표를 달성하는데 사용하는 도구의 그 자체의 매력에 빠지기도 한다. 도구의 매력에 일정 정도 빠지는 일은 전혀 해롭지 않다. 도구를 이리저리 사용해 보면서 도구를 매우 정교하게 사용할 수 있게 되기 때문이다.
프로그래밍 언어 하나를 하나부터 열까지 정교하게 다룰 수 있다는 것은 분명히 장점이다.
그러나
프로그래밍 언어를 하나 잘 알고 있다고 해서 모든 일을 한
프로그래밍 언어에 의존하는 것은 경계해야 할 습성이다. 아무리 멋진 도구라 할 지라도 결국에는 도구이다.
새로운 언어를 열심히 배운다
언어는 도구일 뿐이다. 많이 알수록 좋다. 새로운 언어 배우기에 인색하지 말라!
언어는 도구이며 이상도 아니고 이하도 아니다. 이 세상에 C나 C++ 이외에도 많은 언어가 존재하는 이유는 무엇일까? 각 언어마다 자기 전공이 확실하게 존재한다.
다목적이긴 하지만 시간이 적게 걸리는 언어가 있는 반면, 일부 목적에 사용되지만 그 용도 하나만큼은 확실히 빠르게 처리해주는 언어가 있다.
리눅스에서라면 여전히 C 언어의 인기가 높지만 Qt등의 훌륭한 툴킷이 나오면서 윈도우에서처럼 C++ 언어의 인기도 높아가고 있다.
프로그래밍을 하는 사람이라면 아주 기본적으로 bash, tcsh 사용법을 잘 알고 있어야 한다. 쉘
프로그래밍은 기본이다.
그 외에도 펄(Perl), Python(파이썬), Tcl/Tk 등 전세계적으로 적지 않게 사용되고 있는 언어들도 있다. 특히 펄(Perl)과 같은 언어는 실용성과 언어학적 측면에서 매우 흥미로운 언어라고 생각하며 리눅스 개발자라면 꼭 권장하고 싶다(필자는 요즘 펄이라는 도구의 매력에 빠져 있는 단계이다. 숙련되고 나면 누구보다도 빠른 속도로 관리/웹 애플리케이션을 만들 수 있으리라 기대한다).
- 쉘 사용법, 쉘 프로그래밍 언어(본쉘, C쉘 모두)
- C 언어 & 유닉스 명령
- C++ 언어
- 펄(Perl)
- 기타 Tcl/Tk, Python, Java
리눅스/유닉스 애플리케이션 개발자라면 무조건적으로 쉘을 잘 사용해야 한다. 쉘
프로그래밍 언어를 C 언어 배우기와 병행하면 상당히 도움된다. 언어가 다양하다고는 하나 현대적인 언어의 구조적 뿌리가 되어 주는 언어가 C 언어이기 때문에 서로 매우 유사하고 한 언어를 잘 하면 다른 언어를 쉽게 익힐 수 있다.
쉘의 경우 본쉘(Bourne)과 C쉘의 양대 산맥이 있는데 경험상 두 가지에 대하여 모두 알아두는 것이 좋다. 대신 개인의 취향상 한 가지 쉘을 특별히 잘 할 필요는 있다. 리눅스에서라면 단연 본쉘 계열의 GNU bash이다.
C 언어는 기본 중의 기본이다.
“C Programming Language”라는 C 저자의 책부터 시작해서 어마어마하게 많은 C 관련 책들이 있다. C 언어는 특히 유닉스와의 관련성이 밀접하므로 유닉스
프로그래밍에 관련된 책이라면 어떤 책이든 상관없다. 유닉스 == C, C == 유닉스이기 때문에 유닉스 명령을 잘 알면 C 언어를 배우는데 도움이 되고 C 언어를 잘하면 유닉스를 잘 다루게 된다.
유닉스 명령을 어느 정도(완전히는 아니고... 원래 불가능하다) 익힌 후, C 언어 공부를 시작하면 좋다. C 언어 공부와 유닉스 명령 공부는 무조건 병행한다.
C 언어의 경우에는 한 번 끝날 수 있는 성질의 것이 아니므로 몇 십 번이고 반복할 것이라고 미리 생각하자(필자라면 다른 언어와 상관없이 죽을 때까지 익히게 될 것 같다).
하지만 C 언어 지상주의로는 빠지지 않기 바란다. C 언어가 뿌리이기는 해도 더 좋은 언어들이 많으며 목표한 것을 빨리 이룰 수 있도록 여러분을 도와준다.
그 다음은 C++이다. Java와 같은 언어에서 강력하게 지적하듯 C++ 언어는 C 언어보다 대형 애플리케이션 그리고 윈도우 환경과 같은 이벤트 처리 방식의 시스템에서 생산성이 높지만 이에 비해 복잡성이 너무 크다. 개인적으로 Java 보다 덜 선호하는 언어이다.
그러나 피해갈 수 없는 언어라고 생각한다. C++ 책을 작은 것 하나, 굵은 것 하나 구입해서 예제를 익혀가면서 어느 정도 알아두는 것이 좋다.
펄(Perl)을 익힌 지는 얼마 안되지만(필자는 리눅스에서만큼은 C 언어 도구 중독증의 전형적인 예였다) “문제를 해결하는데 있어 한 가지 이상의 방법이 존재한다 (There’s more than one way to do it)”는 모토를 갖는 펄은 실용성과 함께 도구 중독성을 갖고 있는 흥미로운 언어라고 생각한다. Write Once Run Everywhere라는 환상적인 모토를 갖고 있는 Java보다 선호하는 언어가 있다면 단연 펄이다. 현실 세계의 불완전성 때문에 완벽한 WOWE는 불가능하다. 현실 세계의 문제가 복잡하기 때문에 펄도 복잡하다고 이야기하는 솔직함이 더욱 마음에 든다.
숙련자든 비숙련자든 같은 문제를 서로 다른 펄 코드로 해결할 수 있다.
특히 펄 버전 5에서 OOP(객체 지향
프로그래밍) 스타일의 모듈(Module)이 도입되면서 단순 관리용 스크립트가 아니라 C 언어가 할 수 있는 거의 모든 일을 해내는 다목적 언어로 발돋움하였다는 점에 주목하고 싶다.
< Java? >
등장과 함께 모든 언어를 평정할 듯 위세가 당당했던 Java는 자바 가상머신 JVM, 자바
프로세서와 관련된 성능 문제라는 악성 문제를 안고 있으며 요즘에는 Jini 등 Java 본
연의? 정보가전, 이동형 장치로 돌아가고 있다는 인상을 지울 수 없다. 썬 스팍/솔라
리스 조합이 Java 프로세서/운영체계로 바뀔 것이라 생각하는 사람은 없을 것이다
여러분의 생각은 어떠한가?
< DataBase >
마이크로소프트사의 마이크로소프트 SQL 서버도 중요한 서버라고 하겠지만 리눅스에서
사용할 수 없다는 이유로 누락시켰다. 앞으로 회사의 데이터베이스 인프라를 윈도우
NT 플랫폼으로만 국한시키겠다는 생각이 아니라면 리눅스/유닉스에서 운영 가능한 데
이터베이스를 선택할 수밖에 없다.
역시 특정 제품이 중요한 것은 아니다. 데이터베이스 제품에 지배를 받아서야 되겠는
가? 두루두루 사용될 수 있는 데이터베이스를 배우는 것이 현실적인 선택이다.
리눅스에서 사용 가능한 경량급 데이터베이스 중 mSQL을 사용하고 있는 사람이 있다면
MySQL(http://www.mysql.com) 또는 PostgreSQL(http://www.postgresql.org)를 고려해
보기 바란다.
리눅스 사용자라면 오라클, 인포믹스 중 하나, 그리고 MySQL, PostgresQL 중 하나 이
렇게 두 가지를 익혀두면 현재와 미래에 도움이 되리라 생각한다.
언어는 무조건 많이 익힐수록 좋다!
영어 잘 하는 사람이 일어를 배우면 해가 될까?
영어, 일어, 불어, 독어 얼마든지 많이 알아두는 것이 좋다. 모든 언어는 배울 만큼의 가치를 충분히 가지고 있다. 무엇보다 여러 언어를 알아야 언어에 대한 비판도 가능하다.
웹 애플리케이션이라면 요즘에는 다음 두 가지를 익혀야 한다.
인터넷을 비롯한 네트워크화가 진행되어 감에 따라 데이터베이스의 중요성이 놀라울 정도로 높아졌다. 모든 자료는 데이터베이스화되기 시작했다. 이때 필요한 것은 역시 SQL이라는 사실에 대부분의 사람들이 동의할 것이다. 오라클(Oracle), 인포믹스(Informix)와 같은 유명한 SQL 데이터베이스가 있으며, 리눅스에서는 mSQL,
MySQL,
PostgreSQL 등 일반인들에게는 잘 알려져 있지 않으나 오픈 소스 공동체 사이에 잘 알려진 중소규모 SQL 데이터베이스도 있다.
SQL 데이터베이스에서 중요한 것은 SQL 자체가 아니라 데이터베이스 디자인이다. 무조건 이것저것 자료 구조를 만들어 보고 실습하는 방법밖에 없다. 이론적인 서적을 잘 소화하는 사람은 데이터베이스 이론 서적을 읽으면 좋다. 데이터베이스는
프로그래밍 분야 중에서 가장 이론적인 분야 중 하나이다.
PHP는 리눅스 등 오픈 소스 공동체에서 유명한 웹 서버 쪽 스크립트 언어로 마이크로소프트사의 ASP에 비유할 수 있다. 그러나 스크립트 언어의 본고장인 유닉스/리눅스에서 개발된 PHP는 ASP를 기능이나 다양성, 그리고 속도 모든 면에서 능가한다는 평가를 받고 있다. 최근 리눅스 서버이면서 동적인 페이지를 만들어 내고 있는 곳이라면 거의 모두 PHP 아니면 펄(Perl)을 사용하고 있다.
끝으로 다시 한 번 강조할 것은 “언어 자체는 절대로 중요하지 않다”는 것. 언어 중심적으로 사고하면 특정 언어의 노예가 되고 만다. 프로그래머란 디자이너라는 사실을 잊지 않기 바란다. 중요한 것은 디자인,
프로그래밍에 앞선 조사와 분석이다.
Hello World를 여러 가지 언어로 나타낸다면? 이라는 질문에 몇 가지 언어의 예가 있다.
기타 언어들이 많지만 하나의 문제를 해결할 수 있는 여러 가지 방법을 알고 선택할 수 있는 프로그래머가 되길 바란다.
프로그래밍 언어에 지배되지 말고
프로그래밍 언어를 확실하게 지배하길 바란다.
무조건 많은 코드 애플릿을 작성한다
무조건 많은 소스 코드를 읽는다! 영어를 잘 하려면 무조건 영어로 된 글을 많이 읽고 영어로 말하는 것을 많이 듣고 영어로 말해야 한다. 그 밖의 방법은 없다. 우리가 한국어를 잘 하는 이유는 단 한 가지 매일매일 쉼 없이 사용하고 있기 때문이 아닌가?
프로그래밍 “언어”도 마찬가지다.
다음은 많은 사람들의 공통 경험일 것이다. 쓰지 않으면 잘 알았다고 생각했던 것도 잊어 먹는다. 필자의 경우 C 언어야 정말 오랫동안 사용해 왔고 시행착오를 많이 겪었기 때문에 잘 잊지 않지만 BASIC, FORTRAN, CLIPPER 등의 언어는 이미 잊은 지 오래이다. 잘 사용하지 않은 C쉘에 대한 것은 가장 기본적인 것 이상은 기억하지 못한다. Java도 마찬가지다. Java를 배우기는 했으나 실전에서 응용하지 않기 때문에 Java를 배웠다는 기억만 있을 뿐이다.
애플릿(applet) 코드, 즉 매우 작은 크기의 코드를 작성하는 습관이 중요하다고 본다. 큰 욕심에는 커다란 노력이 드는 법. 작은 코드를 자주 작성하도록 하자. 이런 면에 있어 펄(Perl)과 같은 스크립트 언어는 최고의 선택이라는 것이 개인적인 생각이다(그래서 펄을 열심히 다시 배우고 있다).
또는 최소한 남의 코드 읽는 일을 게을리 하지 말자. 가장 표준적인 남의 코드로는 유명 유닉스
프로그래밍 서적의 예제가 있다. 그 다음은 여러분이 관심 있는 영역의 오픈 소스 프로그램의 소스 코드를 분석하는 일이다. 이 모든 것이 직접 코드를 짜보는 일보다 확실하지는 않지만 직접 코딩하는 일이 아닌 최선의 방법은 이것밖에 없다.
커널 해커, 컴파일러 설계자가 아닌 이상 응용 소프트웨어를 만들기 원하는 사람은
프로그래밍, 컴퓨터가 아닌 완전히 다른 주제의 인생을 즐길 필요가 있다.
전혀 관계없는 책도 많이 보고 영화도 많이 본다. 영화를 보면서 우와~ 저런 이미지처리를 나도 해볼 수 있다면 하고 생각해 본다. 그리고 돌아와서는 이미 나와 있는 성과를 조사하기 시작한다. 이미 잘 만들어져 있는 바퀴를 다시 발명하는 일(reinvent the wheel)은 없도록 하자. GIMP나 POVRAY와 같은 프로그램이 있다는 것을 알아내고 분석에 들어간다. 기여할 바가 있으면 기여한다.
게임 프로젝트에서 스토리를 짜는 것은 전문적인 사람의 몫이긴 하지만 환타지(fantasy)류의 소설이나 기타 흥미로운 소설을 읽고 그것이 재미있다고 생각하지 않는 프로그래머라면 단순 게임
프로그래밍이 재미있을까?
프로그래밍 언어가 소프트웨어를 위한 도구이듯 결국 컴퓨터 소프트웨어도 결국에는 그 어떤 것에 대한 도구이다. 컴퓨터만을 위한 소프트웨어도 있지만 이 세상에서 제일 쓸모 있는 것은 실생활을 위한 또는 환상을 채워 줄 수 있는 소프트웨어라고 생각한다(썰렁해 보여도 공장 자동화(FA)에 사용되는 소프트웨어를 만드는 일은 매우 의미가 있다.)
그리고 시리얼 장치나 기타 다른 인터페이스 장치를 이용하여 어떤 기계 장치를 제어하는 소프트웨어는 그 나름의 엄청난 매력을 지니고 있다).
진정한 해커(hacker, not cracker)가 되고 싶다
우선 해커와 크래커를 구별할 줄 알아야 한다. 해커는 나쁜 의도를 가진 녀석들 정도라고 생각한다면 아직 리눅스 문화에 익숙하지 않은 초보자일 뿐이다.
Hacker is good, but cracker is bad.
유치한 의도로 남의 시스템을 침입하고 싶어하고 각 운영체계의 보안 버그 족보를 뒤지는 사람은 크래커라 부른다. 이런 사람들의
프로그래밍 실력은 사실 보잘 것 없다. 생쥐와 같은 얍삽이 능력을 가졌을 뿐이다.
보통 “리차드 스톨맨 씨를 이 시대 진정한 마지막 해커”라고 부를 때의 그 해커 개념을 생각해주기 바란다. 해커의 기본 자질이라면 유닉스를 자유자재로 쓰는 것은 물론이고
프로그래밍 언어라는 도구를 잘 다루고 그 내부에 대해서도 잘 아는 수준.
진정한 해커, 즐기는 프로그래머가 되려면 대화, 협력하면서 코딩하는 습관을 가져야 한다.
바로 리눅스, 오픈 소스 소프트웨어가 성장한 방식이다.
해커는 항상 온라인 상태여야 한다. 뉴스그룹(예를 들어 comp.os.lang류의 개발 언어 관련 뉴스 그룹)에 참여하거나 웹 페이지(예를 들어 국내의 경우라면 최준호(junker)씨의 홈페이지(
http://www.kr.freebsd.org/~cjh/)를 가지는 것이 일반적이다. 메일링 리스트를 만들어 사람들의 의견을 나누면서 개발하는 것도 좋은 방법이다.
기존의 프로젝트에 열심히 참여하는 것은 정말 훌륭한 일이다.
특히 리눅스 세계에서는 현재 커널 이외에도 GNOME, KDE 등 능력 있는(어느 정도 여유도 있는) 젊은 고등학생/대학생 개발자를 항상 필요로 하고 있다.
물론 어느 공개 프로젝트에 참여하여 일한다는 것은 아무리 작은 프로그램이라 할지라도 상당한 관심을 필요로 한다. 이런 점에서 필자는 빵점이다.
모든 사람이
프로그래밍을 해야 할 필요는 없다. 또는
프로그래밍에서 자연스럽게 멀어져 가기도 한다.
프로그래밍을 하지 않고 많은 시간을 허송세월하고 있다면
프로그래밍이 자기에게 별로 맞지 않는다는 자연스런 반증이다.
그리고 의무여서도 안된다.
프로그래밍도 생계의 한 좋은 수단인 것은 분명하지만 앞서 이야기한 무엇인가를 갖추지 못하면 특히 “
프로그래밍에 빠져” 있지 않으면
프로그래밍 의무는 창조력 없는 단순 노동이다. 재미없는 프로그램의 디버깅은 사람의 피를 말리기까지 한다. 여러분의 건강을 심각하게 고려하기 바란다.
잘 진행되지 않는 프로젝트에 대해서는 곰곰이 생각해 봐야 한다.
프로그래밍은 완력으로 해결할 수 있는 성질의 것이 아니다. 컴퓨터가 제대로 작동하지 않는다고 해서 TV에서 보는 것처럼 손으로 한 번 탁 쳐서 문제가 해결되지는 않는다.
어떤 프로젝트를 제대로 끌고 갈 수 없다면 두 가지 중 하나이다. 원래부터 여러분의 현재 능력으로는 불가능한 프로젝트이므로 잠시 접어두어야 할 필요가 있다. 또는 처음 생각과 달리 진행함에 따라 흥미를 잃은 경우이다.
끈기도 중요하지만 안되는 것을 되게 하려고 하거나 흥미롭지 않은 일을 밀어붙이려고 하지는 말자. 일단 접어두고 그 이유를 분명히 하자. 여러분이 할 수 없는 일에 집착하는 것은 시간 낭비이다. 희망 사항은 원대할 지라도 아직
프로그래밍을 해야 하는 사람이 아닌 경우에는 자기가 할 수 있는 범위의 일을 찾아서 해내길 바란다.
꼭 어려운 과제를 풀어야 느는 것은 아니다. 자기가 잘 할 수 있는 것을 공고하게 구축하는 것도 좋은 전략 중 하나이다.
원하면 할 수 있다!
프로그래머가 되겠다는 생각은 누구로부터의 강압으로는 만들어질 수 없는 자유의지이다. 프로그래머가 되겠다는 생각을 갖는 사람 자신은 확실한 자기 체험을 하지 않으면 안된다. 직접 컴퓨터를 사용하면서 훌륭한 소프트웨어를 경험하던가 아니면 스타크래프트(Starcraft)와 같은 명작 오락을 해보는 수밖에 없다. 그리고 소프트웨어라는 이 무형의 물건에 감동해야 한다.
원하기만 하면 누구나 프로그래머가 될 수 있다. 특히 리눅스와
FreeBSD와 같은 오픈 소스 환경이라면 프로그래머가 되겠다는 생각을 먹자마자 그 자리에서 즉시
프로그래밍을 시작할 수 있다. C/C++/쉘/Perl 등 모든
프로그래밍 도구가 준비되어 있지 않은가?
이리저리 친구들에게 돌아다니면서 비주얼 C++/비주얼베이식 불법 복사본을 구할 필요가 없다. 사실 오픈 소스 소프트웨어 환경은 일반 사용자라기보다는 “여러분처럼
프로그래밍하고 싶어하는 사람들”을 위해 나온 것이다. 그리고 앞으로도 그러할 것이다.
=========================================================
게으름(laziness), 성급함(impatience), 자기 과신(hubris)
=========================================================
펄 언어의 저자인 래리 월씨는 상당한 이야기꾼으로 유명하다. 성공적인(
프로그래밍을 잘한다는 점에서) 프로그래머가 되기 위해서 갖추어야 할 덕목으로 3가지를 꼽고 있다.
1. 게으르지 않으면 안된다?
~~~~~~~~~~~~~~~~~~~~~~~~~~
모든 발명과 창조는 게으름에서 나오는 것일까? 일의 처리 과정을 조금 더 편하게 해보자는 생각이 없다면, 즉 좀더 게을러지고 싶지 않다면 “좋은 프로그램”은 나오지 않는다.
2. 성급해야 한다?
~~~~~~~~~~~~~~~~~
어떤 일 처리 결과가 여러분의 생각보다 늦게 나오면 이를 참을 수 없어야 한다! 왜 빨리 안 나오는 거야? 컴퓨터 세상에 관한 한 성인군자는 별 도움이 되지 않는 듯 그리고 무엇보다도 자기 과신(확신?)이 있어야 한다. 필요 이상의 겸손은 추진력을 주지 못한다. 여러분의 소스 코드에 대하여 확신을 가지라. 만약 목표한 일을 어떤 식으로든 문제없이 해결했다면 소스 코드가 아마추어적인 수준이든 아니든 간에 없는 것과는 비교할 수 없을 정도로 가치가 있다. 주저하지 말고 현재 배운 기술만 가지고 코딩을 시작하라. 실제로 코딩을 하지 않은 사람의 비판을 너무 진지하게 받아들일 필요 없다.
한 줄이라도 코딩하느냐 않느냐는 천지차이이다. 어떤 소프트웨어든 버전업이 있기 마련이다. 그리고 일정 시점에 가면 모든 것을 다시 디자인해야 할 때가 오고야 만다. 디자인이 2-3차례 변화되고 나면 그때에서야 안정적인 프로그램이 나온다.
여러분이 작성한 소스 코드는 지금 당장 생각으로는 자기 과신할 수 있을 정도로 잘 짜여 보일 지 모르나 처음 소스 코드가 끝까지 남아있는 경우는 없다고 확신하라. 소프트웨어는 근본적으로 패치 레벨업과 버전업으로 진화하는 무형의 생물이다.
3. 기왕 하는 것 즐겁게 하자!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
프로그래밍을 너무 진지하게 생각할 이유는 없다. 생계를 꾸려가야 하는 문제는 그때 가서 생각해도 늦지 않는다. 여러분이 갖추어야 할 것은 프로그램 디자인 능력, 기술, 무엇보다도 활력이라고 생각한다.
자기가 좋아하는 주제를 가지고 자신을 만족시키는 프로그램 코드를 만들어 보자. CPU 자원만 잡아먹을 뿐인 예쁘장한 프로그램을 만들면서도 얻을 수 있는 것은 많다. 마우스 화면을 따라 뛰어다니고 화면에서 낮잠을 자는 공양이 프로그램, 네코(Neko)를 아는가? 필자가 좋아하는 쓸모 없는(?) 프로그램 중 하나는 GNOME 프로젝트의 패널(panel)에서 물방울만 뻐끔대는 완다(Wanda)라는 이름의 물고기 애플릿이다. 적어도 그 사람은 그 프로그램을 만들면서 즐거워했을 것이 분명하다. 그리고 필자와 같이 만족하는 사람들이 있으니 성공한 것 아닌가?
우선 여러분을 위한 코드를 만들자. 이 세상에는 여러분과 같은 관심을 갖는 사람들이 있기 마련. 그러다 보면 어느새 상당히 많은 사람을 즐겁게 하는 소프트웨어로 진화하기 마련이다. 필자가 좋아하는 리눅스가 바로 그러한 전형적인 예이다.
이미 리눅스 설치와 함께 X 윈도우가 설치되어 있으며 컴파일러인 gcc(또는 최신 egcs)가 설치되어 있기 때문에
프로그래밍 준비가 되어 있다.
우선은 간략하게 최하위 레벨의
프로그래밍 API인 Xlib
프로그래밍을 아주 짤막하게 마친다(자료가 많지는 않지만 구식 정보이기는 해도 나우누리나 KLDP에서 Xlib
프로그래밍에 대한 필자의 글을 찾을 수 있을 것이다. 너무 큰 기대는 하지 말기 바란다).
실제로 본격적인 X 윈도우
프로그래밍은 모티프(Motif), Qt, Gtk+ 등의 라이브러리를 이용하게 된다. 이 중 모티프는 비싼 비용을 주고 구입해야 하는데다 최근에 나온 Qt, Gtk에 비해 고물에 가까울 정도로 구식이어서 피하길 권장한다.
Qt, Gtk를 사용하여 진행되고 있는 KDE, GNOME 프로젝트 결과물을 보고 어떤 프로그램을 만들 수 있는지 감을 잡아 보라. 어리고 젊은 많은 프로그래머들이 KDE, GNOME과 같은 대형 공개 프로젝트에 뛰어들기를 바란다.
지금 당장 하자!
앞서 말한 것처럼 조급할 필요가 있다.
- 리눅스 시디를 구입하거나 다운로드 받아서 일단 리눅스를 설치하고 본다 리눅스 설치 자체가 상당한 훈련일 것이다.
- 리눅스 서적, 온라인 문서, 프로그래밍 서적을 구할 수 있는 대로 구해서 닥치는 대로 읽고 실험해본다.
- 마음껏 망쳐도 좋은 하드디스크 하나를 큰 맘 먹고 구입하는 것이 좋다. 리눅스를 만지다가 리눅스가 이상해지면 처음 2-3번은 편하게 지우고 다시 설치하면 그만이다. 리눅스가 망가지지 여러분이 망가지지는 않는다.
- C 컴파일러인 gcc 사용법을 간단하게 익힌다.
KLDP 사이트 또는 나우누리 리눅스 동호회에 가보면 상당히 오래 전에 작성한 글이지만 필자가 작성한 gcc 안내서가 있을 것이다. 오래 되긴 했어도 변한 것은 거의 없다. 아니면 여자 친구 또는 남자 친구와의 데이트를 한 번 줄이고(아프다고 거짓말하든 말든) 리눅스 프로그래밍에 관련된 책을 하나 큰 맘 먹고 구입한다.
- 얇은 C 책부터 굵은 책으로 전진하며 정복한다.
필자의 경험상 굵은 책부터 하면 사람의 집중력 수준상 일부 천재를 제외하고는 자연스럽게 흐지부지 포기하고 만다. 여러분이
프로그래밍을 좋아하지 않아서가 아니라 단지 인간적인 집중력이 떨어지기 때문이다. 그래서 필자는 얇은 책부터 시작한다. 그리고 좀더 굵은 책으로 전진한다. 그러면 책들이란 서로 비슷한 부분을 많이 가지고 있기 때문에 두 번째 책부터는 훨씬 빨리 읽어 내려갈 수 있다. 세 번째, 네 번째도 마찬가지이다.
필자의 책꽂이에는 C
프로그래밍 책이 10권 정도 되는 것 같다. 하지만 앞으로도 계속 구입할 것이다. 또는 계속 프린팅할 것이다.
쉘, 특히 펄은 유닉스다운 멋을 지닌 언어이다. 펄의 경우 많은 사람들의 다양한 코드를 쉽게 보고 익힐 수 있는 문화가 잘 조성되어 있다.
- 무조건 컴파일 많이 하고 설치도 많이 해본다.
프레쉬 미트(http://freshmeat.net) 사이트에 가보면 리눅스와 기타 오픈 소스에 관련된 소프트웨어가 매일매일 발표된다. 그것을 가져다 컴파일하여 설치해본다.
여러분 마음에 드는 소프트웨어가 있을 것이다. 우선 시작한지 얼마 안되는 프로젝트에 참여하라. 소스 크기 아직 크지 않을 때부터 참여하는 것이 이해하는데 도움이 될 것이다.
운좋게 버그를 발견했다면 패치를 만들어 저자에게 보내본다(안되는 영어라도 힘겹게 써본다. 몇 번 보내보면 매번 똑같은 영어를 사용하기 때문에 그렇게 어렵지 않을 것이다).
모든 것을 여러분이 처음 시작할 필요는 없다. 여러분이 버그 보고나 패치를 통해 기여하면 그 소프트웨어는 여러분의 것이다.
- 소스를 많이 본다.
현실 세계의 프로그램 소스는 책에서 본 것보다 훨씬 지저분하고 체계적이지 않다. 왜냐? 현실 세계의 문제는 책에서보다 훨씬 더 복잡하기 때문이다. 남의 소스를 읽다보면 주석(comment) 문제나 들여 쓰기 문제(indent)에 대하여 자연스럽게 고민하게 되고 상대방의 악습을 통해 반사적인 학습이 가능하다.
행운을 빈다. 앞으로 여러분을 온라인에서 즐겁게 만날 수 있기 바란다.
