할 수 있다는 자신감은 기술보다도 낫고,
해내고야 말겠다는 굳은 결심에서 나오는 강한 의지는
이 세상 어떤 지혜보다도 뛰어나다.
운명은 내 전부를 바치지 않고서는
한 발자국도 밀려나지 않는다는 것을 잘 알기에,
(문전박대라는 말을 뼛속으로 실감할 만큼 수없는 거절을 당했지만)
한 두번의 시도로 되지 않으면
백만번이라도 고객의 가슴을 두드렸다.
- 조용모, ‘백만번의 프로포즈’에서
출처: 행복한 경영이야기
구매자들은 거의 모두 처음에는 ‘노’라고 말합니다.
진짜 세일즈맨은 구매자가 ‘노’라고 말하는 것에 지칠 때까지,
끈덕지게 매달리는 특성을 가지고 있습니다.
위대한 일은 열정 없이 성취되지 않습니다.
무엇보다도 큰 적은 의심과 두려움입니다.
스스로 할 수 없다고 생각하지 않는다면 사람은
무슨 일이든 성취할 수 있습니다.
1부 | 개발자의 새로운 키, 웹2.0 | 김중태
2부 | 웹2.0 구현의 핵심, 태그 | 박영욱
3부 | RSS 포맷과 구독기 만들기 | 서성렬 <<<이달의 디스켓>>>
4부 | 웹 API와 Ajax 활용 프로그래밍 | 도흥석 <<<이달의 디스켓>>>
5부 | 플렉스로 만드는 웹2.0 | 옥상훈 <<<이달의 디스켓>>>
DEVELOPER NOTE
마소지기 65
INSIDE DEVELOPER | MSDTC 설정과 RPC 이해하기 66
SW로 여는 세상 | 하드 코어 프로그래머 72
이달의 테크 기법 | 스크립트 언어 사용법 76
프로그래밍 노트 | MIME 파서 구현하기 82
이 달에 만난 사람 | (주)트라이콤 김 정 대표 88
마소 퀴즈 | 디비코 티빅스 미니 C-2000U 라이트 외 110
마소 송곳상 | 다이요유덴 8배속 DVD-R 미디어 외 112
마소의 옆자리 | 콘텐츠를 담는 기업, 그래텍 158
INFORMATIOM
이달의 기자 수첩 | 스토로지 시장 공세 펴는 하이브리드 서버 OS 91
MASO INFORMATION | 오라클, 테크놀로지 부문 성과와 향후 전략 공개 92
MIBILE REVOEW | 소니 바이오 TX26LP 외 104
HARDWARE REVIEW | 디비코 티빅스 C-2000.U) 라이트 외 106
SOFTWARE REVIEW | 빗디펜더 9 인터넷 시큐리티 109
SPECIAL REPORT
데이터베이스 시장 변화의 도화선
MM DBMS 161
1부 | MM DBMS로 눈을 돌리자 | 유경용
2부 | MM DBMS의 튜닝과 적용 사례 | 원훈
3부 | 하이브리드 MM DBMS | 원훈
실전강의실
커널 모드 프로그래밍 3 | 김주생
파일 모니터링 디바이스 드라이버 만들기 202 <<<이달의 디스켓>>>
ASP.NET 개발자를 위한 1 | 이광수
Ajax 프로그래밍 208
비트 파워프로젝트-KaZaAqkdtlr의 P2P 기반 블로그 서비스 | 김현우
KaZaA 토폴로지와 하이퍼큐브 214
소규모 프로젝트를 위한 데이터베이스 모델링과 설계 1 | 곽중선
데이터베이스 모델링 220
마소와 삼성 SW 멤버십이 함께하는 개발자 육성 프로젝트 | 김민찬
홈 네트워크와 센서 네트워크를 잇는 vKernel2 226
비주얼 스튜디오 2005로 ASP.NET 2.0을 위한 팀 공동 개발환경 구축 1 | 우영식
웹 사이트 프로젝트 이해 236
TECH POINT
델파이로 풀어보는 애플리케이션 개발 테크닉 1 | 양병규 <<<이달의 디스켓>>>
네이트온 플러그인 활용한 메신저 게임 구현 258
리눅스원 2005 체인지 무브먼트-임베티드 프로그래밍 | 전재성
‘다중 태그 인식 RFID 냉장고’ 구현 264
통합 계정 관리를 위한 또 하나의 대안 | 김병철
오픈소스 활용한 가상 디렉토리 서버 구축 272
웹 관리자를 위한 응급처치법 | 김훈
HTML 태그를 이용한 침입과 대응 280
홈 네트워크 개발자를 위한 | 최정용
Asterisk를 이용한 IP PBX 구현 292
마소 주니어
리눅스 커널 프로그래밍 1 | 이기현
나만의 커널 만들기 298
네트워크 패턴을 이용한 채팅 서버 구현 2 | 강대명
Reactor를 이용한 채팅 서버 구현 <<<이달의 디스켓>>>
닷넷 프로그래머로 가는길 | 서우석
C++로, NET에서 살아남기 316
임베디드 시스템 프로그래밍(2) | 오수형
실습보드와 개발환경 324 <<<이달의 디스켓>>>
개발자를 위한 윈도우 후킹 테크닉 1 | 신영진
키보드 모니터링 프로그램 만들기 332 <<<이달의 디스켓>>>
행복한 이웃 만들기 통장 안내 90
정기구독 안내 169
DEVELOPER PLUS | 시스템 통합에 필요한 개발자의 지혜 | 유영창 178
한용희 정보노트 | C#을 확장한 Spec# 184 <<<이달의 디스켓>>>
Step by SteP | 지속적인 통합(Continuous Integration) | 최재훈 190
독자가 편집자에게 192
DEVELOPER STORY | 아시아 최초 MS DDK MVP 곽태진 194
마소 게시판 196
IT 교육센터 소식 198
디벨로퍼 플러스 | Mono와 아파치 FTP서버 프로젝트 250
랜덤박스 254
개발자 토론방 | 관점 지향 프로그래밍, 얼마나 유용한가 | 전도영 기자 284
이 책의 발견 | 웹2.0을 이끄는 방탄웹 외 288
신간안내 | Rational XDE로 하는 UML 객체지향 모델링 외 290
개발자 Q&A 341
편집 후기 343
=> 수질오염 방지(소독)차원에서 락스를 수시로 풀고, 이로인해 수영복이 쉽게 상하게 된다. 그러므로 마른 상태에서 곧장 입수하는것보다는 일단 수돗물에 한번 적신 후 들어가는 것이 좋다.
수영이 끝나면 곧바로 세탁을 하되, 세재를 사용한다거나 비벼빠는 등의 방법은 변형 및 수명을 단축시키므로 바람직하지 못하다. 그냥 흐르는 물(샤워기)에서 충분히 행궈내는것이 좋다.
=> 보통 집에서 세탁시에도 소량 의 락스는 사용하듯,그 성분만 잔류하지
않을 정도의 헹굼만으로 충분하다.
물세탁을 마치고 탈수를 시킬때,탈수기를 이용하는 방법은 절대적으로 좋지 않다. 탈수시에 생기는 마찰등으로 옷의 수명 및 변형의 원인이 되기 때문이다. 여성 원피스의 경우 어깨부분과 엉덩이부분을 함께 쥐고 일단 굵은 물을 뿌려서 뺀다.
=> 어느 한쪽만 잡고 뿌릴경우,물의 무게로 인해 축 늘어지는 현상이 발
생되므로 유의한다.
집에 돌아오는 즉시,다시한번 흐르는 물에 헹구어 건조시킨다.
=> 이때 햇볕에 말리지 말고 통풍이 좋은 그늘에서 말릴것. 햇볕에 직접
건조를 시키면,탈색 및 변형으로 수명이 단축된다.
수영모
같은 방법으로 충분히 헹군다음, 역시 그늘에서 자연건조 시킨다.
수경
수영을 마친후,같은 방법(흐르는 물)으로 충분히 헹군다. 김서림이 심할경우,면봉에 계면활성제(중성세재)를 조금 묻혀 부드럽게 닦고 세재 잔류가 남지 않도록 충분히 헹군다.
=> 대다수의 수경들이 김서림방지 코팅이 되어있지만,사용하다보면 여러 요인들(얼굴 표면의 체온과 수경 외부 물의 온도차,여러 이물질 흡착,안티포그액이 물에 녹는 성분이라는 점등등)로 인해 점점 김서림의 빈도가 높아지게 된다.
시중에 판매하는 안티포그액을 이용하는 방법도 좋다.
수경 또한 반드시 그늘에서 자연건조 시킨다.
*** 그밖의 유의할 점! ***
- 세탁 및 헹굼은 반드시 찬물로 한다.(특히 수경의 경우는 필수임)
- 수경은 항상 수경집에 넣어서 보관한다.(건조시에도 마찬가지로 넣어서 말리되수경집 뚜껑을 열어둔다)
돈은 기업을 통치하는 최종적인 이념이 될 수 없다.
세상과 사회를 위해 일하는 것이
기업을 경영하는 이념이고 기업문화이어야 한다는
사고방식이 결국 기업을 장기적 발전으로 이끌고
주주의 장기적 이익에도 부합된다.
- 니이하라 히로아키, '기업성공 6가지 핵심조건'에서
출처: 행복한 경영이야기
물론 이익은 중요합니다.
이익을 경시하는 것은
경영의 책임을 포기하는 것과 같습니다.
그러나 이익은 기업이 세상과 사회에
계속 공헌하기 위해서 필요한 수단입니다.
기업은 나쁜 이익은 과감히 배제하고
좋은 이익만을 추구할 수 있어야 합니다.
많은 이들이 당신이 하는 일에 대해
갈채를 보내고 비난하는 사람은 별로 없다면,
당신이 잘못된 길을 가고 있다고 확신해도 좋다.
바보들이 동의하고 있는 일을 하는 것이기 때문이다.
많은 사람들이 당신을 조롱하고 무시한다면
적어도 이것 한 가지는 확신해도 좋다.
적어도 당신이 현명한 행동을 하고 있을 가능성이 있다는 것이다.
- E. W. 스크립스
출처: 행복한 경영이야기
대중의 갈채를 갈망하는 것은 인간의 본능 중 하나라 할 수 있습니다.
그러나 현명한 사람은 본능보다는 이성에 따라
자신의 행동을 규제할 수 있는 사람입니다.
일반 사람들의 반대 속에서 혼돈과 불안이 아닌
편안함을 느낄 수 있는 경지에 이르도록 노력해야 합니다.
언젠가 신문기사 중에서 10대들이 가장 선호하는 직업 중에 프로그래머도 끼어 있었던 기억이 난다. 그리고 국내에서도 프로그래밍에 관련된 잡지가 적지 않은 것을 보면 이제 프로그래밍이라는 것은 결코 낯선 말이 아니다. 이제 프로그래밍을 시작하는 사람이나 이미 직업으로써 일을 하고 있는 사람들과 이 프로그래밍이라는 것에 대해 생각해 보면 좋을 것 같다. 일단은 현재의 PC가 탄생하기까지의 과정을 잠시 살펴 보자.
사실 필자가 처음 컴퓨터라는 것을 접했을 80년도 중반 당시에는 프로그래밍이라는 것은 이상한 사람들이나 하는 것으로 여겨지던 시절이었다. 물론 당시에는 지금은 너무나도 친숙한 컴퓨터인 IBM PC라는 것이 컴퓨터 선진국이라는 미국에서조차 대중화 되지 않았던 시절이니 당연하다. 물론 이미 1981년에 IBM-PC는 세상에 첫 선을 보였고 그전에 나온 Apple II가 상업적으로 성공을 거두고 있던 시절이지만 대부분 상업적인 목적으로 사용되고 있었고 그때까지 일반인들에게는 컴퓨터에 관한 얘기는 먼 나라 얘기 였다.
일반인들이 알 수 있는 수준으로 보자면 만화뿐만 아니라 백과사전 같은데도 컴퓨터는 커다란 눈(사실은 자기테이프지만 모르는 사람에게는 눈처럼 보였고 필자도 그런 느낌을 받았었다.)이 달린 집채만한 아주 고가의 장비라서 그것을 만지는 사람은 대단한 사람으로 그려지던 당시에는 프로그래밍을 한다는 것은 생각하지도 못할 뿐만 아니라 프로그래머는 전세계를 통틀어도 많지 않았으므로 프로그래밍을 한다는 것은 특정 연구소의 연구원이나 대학의 교수진 등 극 소수의 사람만이 생각해 볼 수 있었다. 그때 쯤 국내에서는 겨우 대형 시스템에 터미널을 통해서 접속할 수 있는 기회를 학생들에게 제공하기 시작 했다. 비로소 국내에서 일반인들도 컴퓨터를 접해 볼 기회를 갖게 된 것이다. 물론 이전에도 천공카드를 통하여 작업은 이루어 지고 있었으나 터미널을 통하여 다수의 사람이 동시에 사용하게 된 것은 나름대로 중요한 의미를 갖는다. 하지만 이러한 대형 시스템은 프로그래밍이 대중화된 개념으로 다가오는데 큰 도움을 주지는 못했다.
반면에 지금도 많은 사람들이 기억하고 있을 Apple II는 전세계적으로 성공을 거둔 제품일 뿐만 아니라 컴퓨터의 대중화에 기여한 바가 크다. 스티브 워즈니악과 스티브 잡스가 창고 구석에서 만들어낸 애플이 태어나기 전에 이미 만들어진 알테어(Altair)라고 불리는 최초의 상업적인 컴퓨터는 의미가 크다. 그때가 1975년이었다. 폴 앨런과 빌 게이츠가 이 시절에 알테어를 위한 BASIC을 만들었다는 것은 우연일까? 그리고 그때 마이크로소프트를 설립했다. 그리고 워즈니악과 잡스도 그때쯤 Apple의 초기 모델을 만들고 그것을 1977년에 Apple II로 시장에 내 놓은 것이다. 그리고 그 이후 비지칼크(VisiCalc)라는 최초의 스프레드쉬트 (Spreadsheet)가 발표되면서 PC의 업무를 위한 제품으로서의 상업적 가치에 대하여 인정받기 시작하였으며 이런 가능성에 힘입어 1981년에는 IBM-PC가 첫 선을 보이고 마이크로소프트의 MS-DOS, 로터스의 Lotus 1-2-3 등이 시장에 나왔으며 그 이후로는 비약적인 발전을 거듭하여 지금의 PC까지 오게 된 것이다. 물론 다른 컴퓨터들도 있었으나 대중적인 인기를 얻은 Apple II와 IBM-PC는 그에 상응하는 많은 프로그래머들을 탄생하게 하는 기회를 제공해 주었으므로 그 가치가 더 높다고 보는 것이다. 많은 프로그래머가 없었다면 애플의 그 많은 게임과 IBM-PC의 그 많은 사무용및 개인용 어플리케이션과 게임들이 세상에 나올 수 없었을 것이다.
자 이제 다시 프로그래밍이라는 원래의 이야기로 돌아가 보자. 필자는 프로그래밍을 하는 사람을 크게 두 가지로 본다. 하나는 본인의 취미로 즉, 프로그래밍이라는 것 자체가 재미가 있어서 그렇고 다른 하나는 생계의 수단으로 자신의 프로그래밍 능력을 보수를 받고 제공하는 직업의 경우다. 물론 직업이자 취미일 수도 있다. 그리고 프로그래밍을 통하여 자신의 메시지를 전달하고자 하는 더 큰 목적이 있을 수도 있다. 하지만 취미와 직업으로 분류한 것은 책임을 지느냐 마느냐라는 것을 기준으로 하는 분류이므로 이런 기준을 가진다고 생각하며 얘기를 해 보겠다.
일단 취미로 프로그래밍을 하는 경우 대부분의 사람들은 재미있다고 한다. 그 이유는 단순하다. 어떤 취미든지 본인이 선택한 경우 재미 없을 리가 있겠는가. 프로그래밍이라도 예외는 아니다. 본인이 취미로 선택한 것이라면 아무리 어려운 일이라도 재미 있을 것은 당연하다. 등산을 취미로 하는 사람이 높은 산에 오르는 것이 힘들어서 그만두는 경우가 얼마나 있을까? 취미 생활에 심취한 사람일 수록 오히려 더 높은 산 힘든 코스를 고르는 경우가 많다. 따라서 프로그램이 취미인 사람도 신기술, 새로운 테크닉이 알려지면 하나라도 더 알려고 노력하는 경우가 많은 것이다. 하지만 취미로 프로그래밍을 하는 경우에 한계가 있을 수 있다. 모두 그런 것은 아니지만 너무 어려운 것은 피하려는 성향과 누구에게나 편하게 만들기 위한 노력을 덜 한다. 전문 산악인이 되기 위해서는 단지 취미로 등산을 좋아 하는 것으로는 부족한 것과 같은 경우라고 볼 수 있다. 본인이 취미로 만든 프로그램의 경우 대다수가 일반인이 사용하기에는 불편한 부분이 존재한다. 흔히 이야기 하는 UI부분에 신경을 많이 못쓰는 것도 그렇고, 예상하지 않는 동작에 대한 예외 처리가 미흡하며 특정한 환경에서만 동작하는 등 일반적이지 못하다는 평가를 많이 받게 된다. 하지만 이렇게 취미로 프로그래밍을 하는 경험 많은 아마추어 프로그래머들이 직업적인 프로그래머보다 기술적으로 뒤 떨어 진 것이라고 보기는 힘들다. 정확하게 표현하자면 직업 프로그래머로서의 훈련이 부족하다 라고 하는 것이 옳다.
그렇다면 직업 프로그래머는 취미로 프로그래밍을 하는 아마추어 프로그래머와 어떤 점이 다를까? 이외로 단순하다. 프로그래밍을 한다는 것은 같지만 그 프로그램이 상품적 가치가 있어야 하므로 기본 기능 이외에 훨씬 많은 곳에 신경을 쓴다는 것이다. 그리고 본인이 생각보다 타인의 생각이 제품에 많이 반영된다는 것도 다른 점일 것이다. 특히 최근의 제품들을 보면 편리한 UI라는 것을 강점으로 내세우는 것들이 많다. 하지만 이러한 UI에 관련된 코딩은 보기보다 시간이 많이 걸린다는 것을 안다면 직업적인 프로그래머의 고충을 짐작 할 수 있을 것이다. 프로그래밍을 조금 배우고 나서 누구나 한번쯤은 만들어 보게 되는 전화번호부 같은 프로그램을 예로 보자. 취미로 만든 경우에는 기본 기능과 본인이 특별히 원하는 기능에 치중하게 된다. 즉, 원하는 사람을 쉽게 찾을 수 있는 것이 가장 기본적인 기능이므로 이 기능을 구현하고 나면 이제 다 되었군 하는 생각을 하기가 쉽다. 하지만 그게 상업적 가치를 가지는 제품을 만드는 경우라면 얘기는 다르다. 나는 일년에 한번쯤 쓸까 말까 한 기능이지만 어딘가에 있을지 모르는 사용자의 요구를 위하여 여러 기능이 추가된다. 편지 봉투 찍기 같은 기능은 개인이 친구 몇 명의 전화번호를 관리하는데는 크게 필요하지 않은 기능이겠지만 전문적으로 광고문을 발송하는 업체 들에게는 꼭 필요한 기능이므로 추가 해야 할 것이며 전화번호로 찾기 등은 호출기를 많이 사용하는 사람에게는 필요할 것이며, 전자 우편 주소를 입력하는 난은 전자우편을 사용하지 않는 사람에게는 전혀 필요하지 않지만 그렇지 않은 사람에게는 꼭 필요한 데이타 일 것이다. 또한 마우스보다 키보드를 사용하는 게 더 편한 사람들을 위하여 단축키를 적절히 배치하고 보다 편리하게 사용하기 위하여 단축키 설정을 바꿀 수 있게 하기 위하여서는 그 만큼 더 시간과 노력이 필요하다.
이처럼 두 가지의 경우를 구분해서 얘기 해 놓았지만 실제는 조금 다르다. 많은 소프트웨어 회사는 뜻이 맞는 몇 사람이 모여 시작하게 된다. 그리고 그 뜻 이라는 것은 이미 서로 공감하는 어떤 제품이나 기술인 경우가 많다. 따라서 이런 경우 취미와 직업이 같은 경우가 되며 국내의 여러 소프트웨어 회사는 이러한 프로그래머가 많다고 보인다. 위의 구분을 가지고 보면 프로그래밍 그 자체에 대한 재미는 가지고 있지만 생존하기 위한 직업이 된 경우다. 사실 필자가 얘기 하고 싶은 것은 이러한 사람들에 대한 얘기다. 어차피 취미이거나 직업인 경우가 분리된다면 특별히 할 얘기도 없기 때문이다. 취미인데 뭐라고 한다는 것은 웃기는 얘기고 직업인데 좋다 나쁘다를 얘기한다는 것도 말이 안되기 때문이다.
컴퓨터를 좋아하고 프로그래밍이 취미인 많은 전문 프로그래머들은 가끔 혼자만의 고민에 빠지는 경우가 많다. "나는 취미와 직업이 같은 항상 재미 있는 일을 하고 있어", "훌륭한 프로그램을 만들어 성공해야지". 등 긍정적이고 미래지향적인 생각은 현실에 부딪혀 깨지기가 쉽기 때문이다. 대부분의 회사는 회사 나름대로의 독특한 색깔을 가지고 있다. 따라서 대부분이 그러한 색깔을 파악하고 취업하지만 실제 맡게 되는 일은 그러한 일과는 거리가 먼 작업이 되는 경우가 많다. 그래서 분명히 컴퓨터를 좋아하고 취미가 프로그래밍인 것도 맞지만 분야가 다른 일, 자신의 취향과 맞지 않는 일을 맡게 되는 경우 스스로의 벽에 부딪히게 된다.
그렇다면 이런 경우를 근본적으로 해결하는 방법은 없을까? 서로 다른 생각을 가진 사람이 워낙 많기 때문에 딱 부러지게 결론을 내릴 수는 없지만 필자의 생각으로는 가능하다고 생각한다. 흔히들 취미와 직업이 같은 경우 당연히 직업이 취미를 따라와 주길 바라게 된다. 하지만 이런 생각은 세상은 나를 중심으로 서 있다는 신세대의 생각으로는 당연한 것 일지 모르나 무엇인가는 만들어 내고 그 제품이 회사를 운영하는 밑거름이 된다는 일반적인 직업 논리와는 어울리지 않는 생각이다. 물론 방법론 중의 하나로서 회사가 그러한 개인의 취향을 십분 이해하여 그러한 방향으로 제품을 만들어 낸다면 문제는 없을 것이다. 하지만 더 중요한 것 중의 하나가 성공할 만한 제품을 기획해 내고 그 프로젝트를 추진하기 위해서 시행착오를 많이 겪어 왔던 선배들의 생각을 존중해 주고 선배는 후배들의 새로운 아이디어를 새로운 프로젝트에 접목하는 포용력을 발휘해 주는 서로간의 이해해 주는 마음가짐이다.
즉, 서로의 입장을 이해하고 조금씩 양보를 할 필요가 있다. 지금 당장 원하는 것을 해 줄 수 없다면 언제는 가능한지를 미리 이해 시켜주는 회사는 무조건 주어진 일을 정해진 시간 내로 해 놓기 만을 바라는 회사보다는 더 좋은 회사일 것이다. 물론 원하는 것을 들어줄 여력이 안되는 경우라면 그럴 수 없다고 미리 말 해 주는 것도 좋을 것이다. 프로그래머들이 재산인 소프트웨어 회사가 능력 있고 미래에 대한 생각이 뚜렷한 프로그래머들에게 비전도 심어주지 않고 적절한 보상도 해 주지 않고서 그 회사의 밝은 미래를 그릴 수는 없을 것이다. 물론 반대의 입장으로 프로그래머는 여러 가지 능력을 배양해야 한다. 그렇지 않고서는 쏟아지는 프로그래머들 중 더 나은 프로그래머를 선택할 수 있는 것이 회사의 고유 권한이기 때문이다.
자 다시 취미 얘기로 돌아와 보자. 사실 이 책을 읽고 있는 독자라면 이미 취미건 직업이건 프로그래밍에 대하여 관심이 있는 사람들일 것이다. 하지만 어떤 일을 하든지 그 일을 재미 있게 처리하기 위해서는 관심과 노력이 필요하다. 다른 말로 그 일에 취미를 가져야 한다. 어차피 관심은 가지고 있다면 강제로 취미를 갖기는 힘들기 때문에 노력이 필요한 것이다. 또 예전에는 취미가 있다고 생각했는데 지금은 직업이 되어서 재미가 없다는 사람도 있을 것이다. 역시 노력이 부족하다고 볼 수 있다. 취미라면 잘하든지 못하든지 재미가 있어야 한다. 다시 말해 재미를 찾는 것이 취미를 갖는데 혹은 다시 취미가 되기 위해 필요하다. 그럼 어떻게 재미를 가질까? 혹은 어떻게 재미를 되찾을 수 있을까?
프로그래밍이 재미가 없다고 하는 독자들은 한번쯤 같이 생각해 보자. 원래 처음부터 재미가 없다면 다른 프로그래머들이 재미 있다고 하는 일을 한번쯤은 해 보는 것이 좋다. 이미 다른 사람에 의해서 만들어진 프로그램을 아무것도 없는 상태에서 똑같이 만들어 보는 것, 아니면 조금 바꾸어서 만들어 보는 것, 혹은 세상에서 하나뿐인 새로운 프로그램을 만들어 보는 것 그 어떤 것이라도 좋다. 중요한 것은 직접 내 시간을 투자하여 만들어 본다는 것이다. 그리고 직업 프로그래머들인 경우에는 업무 시간이 아닌 혼자만의 시간에 해야 한다. 영화나 등산, 독서 등은 왜 내 시간을 투자하면서 취미를 갖고 싶은 프로그래밍에는 시간 투자를 하지 않는가? 그저 시간이 지나면 훌륭한 프로그래머가 될 수 있는 것은 아니다. 그것이 취미거나 아니거나 투자한 시간 만큼 더 숙련된 프로그래머가 되는 것이다. 그리고 예전에는 취미를 가졌었지만 지금은 아니라고 하는 사람들에게 물어 보고 싶은 것이 있다. 최근에 스스로 생각하고 혼자만의 시간을 투자해서 혼자만의 프로그래밍을 해 본 경험이 있는가? 그렇다면 다른 취미 생활 역시 하지 않았는가? 아니라면 스스로 프로그래밍이라는 취미를 놓아 버린 것은 아닐까?
많은 사람들이 취미를 직업으로 삼으면 취미를 잃는다고 한다. 하지만 좀 더 생각해 보면 그 만큼 행복한 경우가 또 없을 것이다. 그것은 사랑하는 연인과 결혼한다고 그 연인이 미워지는 것은 아닌 것과 같은 이유다. 단지 살아가는데 부딪히는 여러 가지 어려움들을 슬기롭게 극복하지 못하는 이유라면 그것을 당연하게 받아 들이지 말고 이겨나가야 되는 것이다. 필자는 특히 프로그래밍은 영원한 취미로 삼을 만 한 것이라고 생각한다. 어렸을 적에는 내가 즐기기 위한 게임을 만들 수 있고, 커서는 업무나 일상생활에 필요한 나만의 도구를 만들고, 나이가 들어서는 가물가물 해가는 기억을 도와주는 도구를 스스로 만들어 사용할 수 있다고 생각하기만 해도 얼마나 뿌듯한가. 물론 사서 쓰면 된다. 하지만 직접 해 먹는 요리가 나름대로 맛이 있듯이 프로그래밍이 취미라면 틈틈이 만들어 쓰는 것이 재미 있을 것이다.
세상에는 많은 취미 생활이 있다. 그리고 프로그래밍도 그 중의 하나다. 프로그래밍을 취미로 갖고 싶어하는 사람들, 취미를 잠시 잃어 버린 사람들 그리고 취미인 사람들 이제부터 자기 소개서에 당당하게 쓰자 내 취미는 프로그래밍이라고...
