세상의 중심에서 자유를 외치다. RSS FEED

독일의 다임러 크라이슬러가 만든 세계적인 명차로 마이바흐가 있다.
왠만한 부자라도 쉽게 구입하기 힘들 정도로 고가인데다가, 1년에 1,500대 정도만 완전한 수작업으로 생산하기 때문에 구하기도 힘든 차다.
굉장한 고가임에도 불구하고 마이바흐를 구입하려는 사람들은 마이바흐의 전통, 명예, 가치, 품격, 희소성 등을 구입하는 것이다.
이것은 예술품에서 느껴지는 가치와 비슷하다.
마이바흐는 공장에서 대량 생산하는 자동차가 아니라, 최고의 장인들에 의해서 다듬어지고 엮어져 나오는 예술품이라고 생각하는 것이다.
그들은 예술품을 구입하는 것이다.

공장에서 생산되는 자동차나 마이바흐나 둘 다 철로 만든 기계 장치다.

두 자동차를 완전히 녹여서 철 값을 환산해 본다면 마이바흐나 다른 자동차나 별 차이가 없을 것이다.

마이바흐에 사용된 부품들 중에 철로 만들어지지 않은 부품들도 기실 마이바흐의 가격에 크게 반영되지는 않았을 것이다.

그렇다면 왜 마이바흐는 그렇게 비싸면서도 구매하고자 하는 고객을 만들어 내는가?

이유는 단 하나 '품질' 이다.

자동차의 스타일에서부터 사용된 부품 하나 하나에 최고의 장인들의 정신이 품질로 녹아 있기 때문이다.

이 뛰어난 품질은 예술로 승화되어 나타난다.
나는 여기서 마이바흐를 선전하고자 하는 것이 아니다.
그럴 이유도 없다.

다만, 내가 학생들에게 말하고자 하는 것은 '품질'을 예술로 승화시킬 정도의 프로그램을 작성하자는 것이다.
마이바흐를 제작하는 장인들처럼, 프로그래머들은 자신만의 마이바흐를 만든다는 생각으로 일해 보자는 것이다.

코드는 단순하다.
수만 줄의 코드라도 품질이 조악하면 아무런 가치가 없다.
그러나 정제되고 효율성이 있고 안정된 수 백 줄의 코드는 높은 가격을 받을 수 있다.

프로그래머들은 '쟁이' 이다.
그러나 '쟁이'에 그쳐서는 안 되고, '장인'이 되어야 한다.
기술자에 그쳐서는 안 되고 예술가가 되어야 한다.
청자를 만든 도공처럼, 자기를 굽는 것이 아니라 예술품을 만드는 것이라는 생각을 지녀야 한다.

나는 이것을 '프로그래밍 예술' 이라고 부르고 싶다.
백남준에게 '비디오 아트'가 있었다면, 우리에게는 '프로그램 아트(Program Art)'가 있다.
잘 만들어진 코드는 예술품이라는 생각이 들게 한다.
우리의 입에서 감탄사를 제조해 내게 한다.

이제부터 '프로그램 예술'을 해 보라.
자신의 프로그램을 예술 작품으로 승화시켜 보자.
'부르는 게 값'이 되게 하자.
기왕에 마이바흐 이야기가 나왔으니 이것을 예로 들어서 한가지 더 이야기해 보고자 한다.
마이바흐를 수작업으로 제작하는 강인들과 자동차 공장에서 조립하는 조립공들 또는 자동차 부품 공장에서 부품을 생산해 내는 기계공들의 차이점은 무엇인가?

두 부류의 사람들은 모두 자동차를 생산하는 과정에 참여하고 있다.

그럼에도 불구하고 전자는 최고의 명예와 대우를 받고 있고, 후자는 '그저 그런' 노동의 대가와 대우를 받고 있다.
앞으로 콤포넌트 기반 프로그래밍이라든가 하는 소프트웨어 대량 기술이 더욱 보급될 것이다.

소프트웨어 업체가 제조업체처럼 완전 대량 생산에 이르지는 못할 것이다.
다만, 어느 정도 선까지는 대량 생산에 근접해 갈 것이다.
그렇기 때문에 프로그래머들의 입지는 갈수록 좁아질 것이다.
프로그래머들의 수는 많아지지만 대우는 낮춰질 것이다.

자동차 산업을 생각해 보면 그런 추세가 될 것이라는 것을 쉽게 알 수 있다.
누구나 쉽게 프로그램을 제작할 수 있게 되므로, 예전만큼 프로그래머가 대접받지는
못하게 될 것이다.
그럼에도 불구하고 마이바흐를 제작해 내는 장인과 같은 사람들은 여전히 필요하게 될 것이다.

대량 생산 시대에도 장인은 필요한 것이다.
콤포넌트 기반 프로그래밍 등으로 소프트웨어를 쉽게 대량으로 제작해 낼 수 있다고 해도, 여전히 예술적인 경지의 프로그램 작품을 생산해 낼 수 있는 장인은 필요한 것이다.

이미 소프트웨어는 대량 생산의 시대로 접어들고 있다.
완전한 대량 생산은 불가능하겠지만 어느 정도까지는 대량 생산 체제로 변화될 것이다.
그러므로 프로그래머들은 지금부터 자신의 실력을 장인의 수준으로 높여갈 준비를 해야 한다.
'이 분야에서만큼은 그 사람만 있으면 돼' 라는 말을 들을 수 있도록, 한 분야를 정하여 최고의 권위자가 되어야 한다.

조립공 수준의 프로그래머는 5년차 경력자라도 지금 시점에서 연봉이 1,500만 원에서 2,500만 원 정도에 불과하다. 물론, 회사마다 급여 수준의 차이가 많이 나므로 이것이 정답은 아니겠지만, 왠만한 중견 기업이 이 정도 수준이다.

벤처 기업에서 근무하는 장인 수준의 프로그래머는 연봉 4,000만 원에서 7,000만 원 정도를 받는다.
프리랜서로 활동하는 어떤 사람은 연소득이 1억 원이 넘는다.
내가 업계 종사자들로부터 들은 이야기이다.
앞으로 이 격차는 더욱 커질 것이다.

2010년 10월 23일 18시 54분 43초

투자 격언에 '대중이 가지 않는 길로 가라'는 말이 있다.
대중이 주식을 팔고자 할 때 사고, 대중이 주식을 사고자 할 때 팔라는 말이다.
주식 시장은 대중인 95%의 사람들이 돈을 잃고, 5%의 소수가 돈을 버는 곳이라고 한다.
그렇기 때문에 대중이 되어서는 안 되는 것이다.

 9.11 테러 때 주식이 휴지 조각이 될 것처럼 보인 적이 있었다.
이 때 대중의 심리를 따르지 않고 주식을 산 사람들은 큰 돈을 벌 수 있었다.
결국 주가는 다시 원 상태를 회복하였기 때문이다.

프로그래머들이 가는 길도 마찬가지다.
프로그래머의 세계도 95%의 보통 프로그래머와 5%의 엘리트 프로그래머로 나누어 볼 수 있다.

95%의 보통 프로그래머들이 가는 길로 가면 희망이 없다.
항상 많은 프로그래머들이 가지 않는 길로 가는 편이 낫다.
지금부터 약 20 여 년 전, 막 PC가 보급되기 시작할 무렵에 워드프로세서라든가 각종 패키지 프로그램에
대한 기사가  컴퓨터 전문 잡지 이곳 저곳에 나타나기 시작하였다.
기술적인 내용부터 상품성을 다룬 기사까지 포함되어 있었다.
그러나 그 당시 프로그래머들의 최대의 관심은 '전산화' 였다.

요즘 말로 하면 시스템 통합(SI)이다.
그 당시에 돈이 되는 것은 바로 전산화였다.
중소기업이나 대기업의 전산화 업무를 맡아 그 대가로 돈을 버는 것이었다.

게임을 비롯한 패키지 시장은 아직 열리지 않았으므로 사업성이 없어 보였다.
소프트웨어 개발 업체의 대부분이 바로 이 전산화에 매달렸다.
패키지 소프트웨어를 개발하려는 업체들에게 지원도, 사업성도, 희망도, 낙관도,
그 어떤 등대도 보이지 않던 시절이었다.

그럼에도 불구하고 끝까지 외로운 길을 고집했던 패키지 개발 업체들은 그 후에 벤처 붐을 타고 큰 성공을
거두게 되었다.
패키지 소프트웨어 개발에 열정을 걸었던 프로그래머들은 스톡 옵션 등으로 후한 보상을 받았음은 물론이다.
지금부터 약 10여 년 전, 막 인터넷 세상이 열리려고 하던 시절도 그랬다.
90년대 중반에서 하반기로 기억이 되는데, 그 당시에도 인터넷에 관한 기사들이 여기 저기 떠돌아다녔다.
그러나 여전히 업체나 프로그래머들은 SIS(전략 정보 시스템)나 MIS(경영 정보 시스템) 또는 멀티미디어와
같은 정보화 용어에 매달려 있었다.
그 당시에는 그것들이 돈을 벌어다주는 테마였다.

그럼에도 불구하고 인터넷이라는 외로운 길을 걸어가는 업체들이나 프로그래머들이 일부 있었고, 이들은
인터넷 시대의 본격적인 전개와 함께 큰 보상을 받았다.
지금 이 시점에서도 프로그래밍 전문 잡지에서는 낯설어 보이는 테마들을 다룬다.

바이오매틱스라든가 홈서버라든가 유비쿼터스라든가 하는 것들이 그 예이다.
이 분야의 사업들은 아직 돈이 안 되고, 일부 사업체들은 열매도 맺어 보지 못한 채 중도에 하차하기도 한다.
그러나 끝까지 견디는 업체나 프로그래머들은 먼 훗날에 큰 보상을 받게 될 것이다.

대중이 가지 않는 곳에 황금이 깔려 있다.

14)패키지 프로그램(package program)：하나의 포장 단위로 묶어서 팔 수 있는 프로그램.
대표적인 예가 워드프로세서이며, CAD 프로그램이라든가 게임 프로그램도 패키지 프로그램이라고 한다.
패키지 프로그램은 한 번 개발하면 대량으로 판매할 수 있다.
반면에 용역 계약을 맺고 개발해 주는 전산화 프로그램은 패키지 단위로 팔 수 없고, 프로젝트 단위로만 팔 수 있다.
매 번 프로젝트마다 다시 개발하여야 하기 때문에 대량 판매가 불가능하다.

15)바이오매틱스(biomatics)：생명 공학을 나타내는 바이오(bio)와 정보기술을 의미하는 인포매틱스(infomatics)를 결합한 용어.
생체의 정보 시스템을 연구하고 응용하는 분야.

16)홈서버(home server)：가정의 정보화를 담당하는 컴퓨터.
이 홈서버를 통해 영화를 다운로드하여 보거나, 각종 전자 기기들을 조정할 수 있다.

2010년 10월 22일 12시 29분 24초

세상의 철학이나 이념 또는 사조는 이래 저래 변한다.
한때 유럽에서는 중농주의 사조가 유행한 적이 있었다.
농사가 국가를 부강하게 하는 최선의 길이라고 믿는 사조였다.
그러다가 중상주의가 대두하면서 유럽 각국은 무역이 더 좋은 길이라고 믿었다.
이후에도 여러 가지 사조가 휩쓸고 지나갔고 지금은 공산주의와의 대립을 승리로 이끈 자본주의가 휩쓸고 있다.
그러나 이 사조도 언젠가는 퇴보하고 또 다른 사조가 나타날 것이다.
사람들이 목숨을 걸 만큼 중요하다고 여긴 이념이 긴 역사를 놓고 보면 얼마나 덧없는 것인지 모른다.
잠시 잠깐 동안에 지나갈 세상의 물결 때문에 사람들은 국가와 국민의 운명을 건다.
프로그래머의 세계에도 이런 현상이 있다.
신기술의 물결들이 밀려올 때마다 그 물결에 요동치는 것이다.
고바(CORBA)가 한 때 기술적 문제들을 해결할 것처럼 등장하더니 이내 잠잠해졌다.
지금은 UML이나 RUP, 애자일 개발이나 익스트림 프로그래밍과 같은 것이 거대한 물결로 다가왔다.
어떤 사람들은 이런 신기술 또는 신방법론의 조류를 타지않으면 뒤쳐진다고 여기기도 한다.
물론 이런 것들을 온전히 무시하는 것이 바람직한 것은 아니다.
그러나 여기에 조직 전체를 걸지 말라.
언젠가 이런 것들을 대체할 기술이나 방법론이 또 나타난다.
여기에 인생을 걸지 마라.
이런 것들은 이념과 마찬가지로 자신을 살찌우기 위한 방편에 불과하다.
이념에 목숨을 거는 어리석은 사람들처럼, 방편에 자신의 운명을 걸지 않는 편이 좋다.
지금 잠시 기다리면 곧 새 물결이 다가온다.
물결은 물결일 뿐 바다가 아니다.
언제나 물결은 다가오게 마련이다.
잠시 잠깐 동안에 이용하면 그 뿐이지, 그 물결을 따라갈 생각은 하지 않는 편이 좋다.

2010년 10월 17일 18시 51분 54초

우리나라의 개발 용역 단가는 낮은 편이다.
가끔 외국 업체의 개발 비용을 국내의 것과 비교해 보면 보통 국내보다 2배 이상이고, 많게는 10배가 넘는
차이를 보이는 경우도 보았다.
왜 이렇게 개발 단가가 낮은 것일까?

우선, 첫째 원인으로 오픈소스(open source)를 들 수 있다.
인터넷에 가 보게 되면 오픈소스가 넘쳐난다.
소스(source)가 공개되어 있기 때문에, 그것을 가져다가 유사한 프로그램을 만들기가 쉽다.
그러다보니, 오픈소스로 구현할 수 있는 시스템의 개발 단가는 매우 낮아진다.
이것은 비단 우리나라에만 해당되는 현상은 아닐 것이지만 유난히 우리나라에서 오픈소스로 인한 개발 단가
인하가 심화되고 있다.

개발 단가를 낮추는 둘째 요인은 '지나친 경쟁' 이다.
시장은 좁고 개발 업체는 넘쳐난다.
조직의 생존을 위해서, 개발 업체는 떡고물 가격에라도 수주를 하려고 한다.
어떤 업체는 0원에 수주를 한다.
0원에 수주하면 손해가 날 듯 싶지만, 대규모 프로젝트라면 향후에 발생하는 유지보수(maintenance) 비용으로
개발 비용을 충당할 수가 있다.
이익을 적게 가져 가더라도 일단 계약을 할 수만 있으면, 유지보수를 할 가능성이 높을 뿐만 아니라, 다른 연계
프로젝트를 계약할 가능성이 높아지기 때문이다.

세 번째 원인은 개발 환경이 좋아졌다는 것을 들 수 있다.
예전에 코볼(COBOL)로 프로그램을 작성하던 시절에는 코볼로 개발하기가 쉽지 않아서 비교적 높은 단가를
책정해도 계약하기가 쉬웠다.
코볼로 작성된 프로그램들의 소스를 보유한 업체는 그것을 수정해서 납품하면 되므로 계약 기간을 짧게 할
수 있다.
그렇지 않은 회사는 단가를 낮추더라도 개발 기간이 길어지게 되므로 계약하기가 불리했다.
덕분에 어떤 업무를 개발해 본 경험이 있어 소스코드를 보유한 업체는 향후에 늘 유리한 단가로 계약을 맺을 수
있었던 것이다.

그러나 지금은 상황이 달라졌다.

비주얼 베이직이나 델파이와 같은 통합 개발 환경(IDE)이 보급되면서 개발 기간이 짧아졌다.
어지간한 프로그래머라면 이런 IDE를 사용하여 왠만한 업무를 수 개월 이내에 전산화할 수 있다.
간단한 프로그램이라면 단 하루만에도 작성할 수 있는 것이다.

이 외에도 개발 단가를 낮추는 원인들이 존재하겠지만, 어찌 되었든 개발 단가가 내려가는 추세는 계속될
것으로 보인다.
이렇게 되면 전산 업체들과 거기에 소속된 프로그래머가 곤란을 겪게 된다.
개발 과정이 단순화되고 빨라지며, 소스를 구하기가 쉬워 쉽게 개발을 할 수 있다면 좋아하여야 할 현상일텐데
상황은 그 반대다.
금을 캐내기가 어렵던 시절에 광부는 좋은 대우를 받을 수 있다.
굴착기와 같은 신기술이 개발되어 보급되는 초기에도 광부는 그런대로 대접을 받는다.
그러나 일단 굴착기의 성능이 뛰어나게 좋아지면 광부들의 임금 단가는 내려간다.
게다가 몇몇 광부는 해고를 당할 것이다.
이런 현상이 지속되면 결국에는 광부가 필요없게 되는 상황이 오게 된다.
광부 대신에 굴삭기 운전 기사가 필요하게 되는 것이다.

이렇게 금을 생산하기가 쉬워지면, 그 때부터는 금을 탐지해 내는 기술을 지닌 기술자의 임금이 올라간다.
먼저 탐지를 해내기만 하면 금을 캐내기는 쉽기 때문이다.
지금 우리는 소프트웨어 개발의 굴삭기가 개발된 초기 상황에 와 있다.
프로그래머들은 금을 캐내는 광부라고 할 수 있다.
그리고 IDE나 신속 개발 도구(RAD) 같은 것들은 일종의 신형 굴삭기다.
앞으로도 한 동안은 프로그래머와 IDE 조작자가 공존할 수 있을 것이다.
궁극적으로는 IDE 조작자는 살아남고 프로그래머는 사라져 갈 것이다.
IDE를 사용해 프로그램을 작성하는 사람도 프로그래머이기는 하지만, 전통적인 의미의 프로그래머는 아니다.
내가 사라진다고 하는 사람들은 전통적인 방식으로 에디터(editor)를 사용해 소스 코드를 작성하는 프로그래머를 말한다.

반면에,
시스템 설계 능력을 갖춘 사람이나 개발 프로젝트를 총괄할 수 있는 사람들은 더 좋은 대우를 받게 될 것이다.
IDE와 같은 굴삭기로는 도무지 해결할 수 없는 일을 담당할 최고 기술을 지닌 프로그래머들도 좋은 대우를
받게 될 것이다.

결국, 경력과 기술을 갖춘 프로그래머, 시스템 분석 및 설계자, 프로젝트 매니저, 아키텍트와 같은 사람들의
대우가 좋아질 것이다.
그러나 그 밑의 광부들은 사라질 것이고, 굴삭기 노동자 또한 좋은 대우를 받지 못할 것이다.
이런 현상은 비단 개인에게만 한정되는 것은 아니다.

개발 업체들 또한 새로운 경쟁 환경에서 도태되기도 하고, 성장하기도 할 것이다.
굴삭기가 보급되면 그런 굴삭기를 구입할 수 있고, 고급 지질 탐사 능력을 갖춘 대형 업체는 살아 남고, 인력에
만 의존해 채광하던 소규모 업체들은 사라지게 되는 것이다.

마찬가지로 소프트웨어 업계도 자금 능력과 고급 인력을 보유한 업체들은 살아남고, 그렇지 못한 영세 업체들은
사라져 갈 것이다.
영세 업체들은 사라지거나 대형 업체의 하청 업체로 남는 길 중에 하나를 선택해야 할 것이다.
그렇기 때문에 프로그래머가 살아 남으려면 고급 기술자가 되어야 한다.
금을 캐내는 기술을 배우고, 지금부터라도 금을 탐지해낼 수 있는 능력을 길러야 한다.
아니면 굴삭기 운전 기사가 되어야 한다.

IDE와 같은 통합 개발 환경을 이용해 빠른 속도로 프로그램을 작성할 수 있게 되든가, 통합 개발 환경만으로는
절대로 해결할 수 없는 부분을 프로그래밍 할 수 있는 능력을 갖추든가 해야 한다.
예를 들면 창조적으로 알고리즘을 고안해 내는 것과 같은 능력 말이다.
개발 업체가 살아남으려면 자금을 확보해야 한다.
굴삭기와 같은 IDE 등의 통합 개발 도구를 확보할 자금, 0원에 수주하여 개발이 완료되고, 유지 보수 비용이
들어올 때까지 회사를 운영할 수 있는 자금과 같은 것들을 확보할 수 있어야 한다.

그리고 금을 탐지해 낼 수 있는 고급 인력을 보유해야 한다.
남들이 할 수 없는 것을 할 수 있는 개발자들을 채용해 두어야 한다.
이것은 일종의 차별화 전략이다.
남과 다른 무엇을 갖추는 것, 그것이 차별화이다.
이제부터는 차별화가 생과 사를 결정하는 열쇠다.

6)오픈소스(open source)：누구나 가져다 쓸 수 있게 만든 프로그램.
누구나 가져다 쓸 수 있도록 하기 위해서, 프로그램을 파악할 수 있는 소스코드(source code)의 형태로
제공한다.
그래서 개방된 소스 코드라는 의미를 담고 있기 때문에 오픈 소스라고 부른다.
참고로 컴퓨터에서 실행되는 프로그램은 기계어로 되어 있어 프로그램을 파악할 수 없지만, 소스코드는
프로그래머가 알아볼 수 있는 형태의 프로그래밍 언어로 작성되어 있어 프로그램을 파악하기가 쉽다.
소스코드를 컴파일하면 실행코드가 된다.

7)소스(source)：소스 코드의 줄임말

8)통합 개발 환경(IDE, Integrated Development Environment)：프로그래밍 언어, 그 언어로 프로그램을 입력할
수 있는 에디터, 그리고 라이버리에 포함된 함수를 불러 올 수 있는 기능 등의 프로그램에 필요한 모든 제작
도구를 통합한 응용 프로그램.
프로그래머들은 이것을 사용하여 프로그램을 손쉽게 개발할 수 있어 높은 생산성을 기록한다.

9)에디터(editor)：프로그램의 소스코드를 입력하고 편집할 수 있게 해 주는 프로그램.
일종의 간단한 워드프로세서라고 보면 된다.

2010년 10월 15일 13시 18분 19초

프로그래머를 채용하여 본 사람이라면 몇 가지 공감할 만한 내용이 있다.
우선, 프로그래머들은 대부분 이력서에 자기가 다룰 수 있는 언어들을 중심으로 적는다는 것이다.
예를 들면, 'C, C++, 자바, PHP, C#으로 코딩 가능' 과 같은 식으로 적는 것이다.
어떤 언어를 다룰 수 있느냐는 중요하므로 이렇게 적는 것 자체가 잘못된 것은 아니다.

대개는 다룰 수 있는 언어를 최대한 많이 적는다는 것이다.
이런 프로그래머들의 경우, 물론 아닌 경우도 있지만, 십중팔구는 실력이 좋지 못하다.

대개 이런 프로그래머의 경우에, 해당 언어로 한두 번 코딩해 보거나 그저 그 언어를 이해하는 정도에
머무는 경우가 많다.
이런 프로그래머에게 'C언어를 사용하여, 간단한 연결 리스트를 구현하여 보라!'라는
아주 간단한 예제를 내주어도 풀지 못하는 경우가 많다.

또 한 부류의 프로그래머들은 아주 멋진 포트폴리오를 제시하는 경우이다.

이들이 제시하는 포트폴리오를 보면, 시스템 설계서부터 시작해서 단위 프로그램의 설계서에 이르기까지
포함되어 있는 경우가 많다.
그리고 거기에는 자신이 직접 작성했다는 프로그램 한 두 개가 포함되어 있다.
그렇지만 이들에게 '시스템의 프로세스를 개괄적으로 설명해보라' 라고 질문하게 되면 당황하는 경우가 많다.

'아, 저는 이 단위 프로그램만 제작했기 때문에...' 라든가, '음, 사실은 이것을 전부 제가 작성한 것은 아니고...' 와 같이 변명하기 일쑤다.
이런 프로그래머들은 '할 줄 아는 것' 과 '잘하는 것' 을 구분하지 못하는 듯 하다.
그리고 '참여해 본 것' 과 '직접 만든 것'의 차이도 구분하지 못한다

할 줄 안다고 해서 잘 하는 것이 아니고, 어떤 단위 프로젝트에 참여해 보았다고 해서 그 프로젝트를 직접
진행하였다고 할 수 없는 것이다.

그럼에도 불구하고 여전히 이 양자간에 혼동하는 프로그래머들이 많다.
만약 지금 자신이 할 수 있다고 생각하는 것이 있다면, 제대로 잘 할 수 있는지 점검해 보라.
그렇지 않다면 이력서에 기재할 생각도 하지 않는 것이 좋다.
제대로 잘 할 수 있는 것이 한 두 가지라도 있어야 한다.

그것은 진실하기 때문에 설득력이 있다.

2010년 10월 10일 17시 26분 28초

프로그래밍 능력은 칼에 비유할 수 있다.
똑같은 칼이라도, 잘 다루는 사람이 있는가 하면,
잘 다루지 못하는 사람이 있다.
횟집에서 칼로 무를 써는 사람도 있고, 칼로 회를 뜨는 사람도 있다.
무를 써는 사람이 쓰는 칼이라도, 잘 갈린 칼로는 무를 쉽게 썰 것이고,
무딘칼로는 무를 쉽게 썰지 못할 것이다.
 
프로그래밍 기술도 마찬가지여서,
프로그래밍 기술을 갈고 닦은 사람은 프로그램을 쉽게 제작할 수 있고,
그렇지 못한 사람은 어렵게 제작할 것이다.
프로그래밍 기술을 키운다는 것은 칼을 가는 것과 같은 것이다.
그런데 아무리 칼이 잘 갈려 있어도 그것을 다루는 사람의 능력이 더 중요하다.
 
여기 아주 잘 갈린 칼이 있다고 하자.
이것을 사용하면 무는 쉽게 썰어진다.
그렇지만 처음 무를 썰게 되는 사람이 그 칼을 사용한다면 무는 쉽게 썰어질지언정,
빠르게 무채를 만들 수는 없다.
 
반면에, 무를 많이 썰어본 사람은 무채를 아주 빠른 속도로 예쁘게 썰어낼 수 있을 것이다.
동일하게 잘 갈린 칼을 쓰는 데에도 무채를 빠르게 써는 사람은 따로 있는 것이다.
이처럼 잘 계발된 프로그래밍 실력이 있다고 하여도,
경험이 없다면 프로그램을 빨리 제대로 제작하기가 어렵다.
 
예를 들어 자바 언어로 아주 능숙하게 코딩하는 사람들이 있다고 하자.
한 사람은 자바 언어를 사용하여 게임을 여러 차례 만들어 보았고,
한 사람은 자바 언어로 주로 업무용 프로그램을 제작하였다고 하자.
이제 두 사람이 모두 게임을 만들어야 한다면,
동일한 자바 실력을 갖추었어도 게임을 개발해 본 사람이 프로그램을 더 잘 만들 수 있을 것이다.
이것은 '프로그래밍 능력' 과는 별개로 '해당 분야에 대한 경험' 이 매우 중요함을 보여준다.
 
해당 분야에 대한 경험은 다른 말로 하면 해당 분야에 대한 지식과 기술이라고 말할 수 있다.
즉, 프로그래밍 기술에 못지 않게 필요한 것은 어떤 특정 분야에 대한 전문 기술이라는 것이다.
 
그렇기 때문에 프로그래머는 게임의 3D 그래픽 처리, 소켓 프로그래밍,
게임의 인공 지능 엔진 제작, 컴파일러 제작 등과 같이 특정 분야에 대한 전문 기술을 갖추어야만 한다.
자기만의 전문분야를 갖추어야 한다.
프로그래밍 기술은 누구나 어느 정도 노력하면 갖출 수 있다.
 

칼은 누구나 갈 수 있고 누구나 다룰 수 있는 것처럼 말이다.
하지만 회를 뜨는 기술이라든가 무채를 빠르게 써는 기술을 쉽게 익혀지는 것이 아니다.
마찬가지로, 데이터베이스 구성 능력이라든가,
시스템 설계 능력이라든가 하는 것은 쉽게 익힐 수 있는 것이 아니다.
그렇기 때문에 어느 정도 진입 장벽이 있으며,
이 분야의 능력을 키운 사람은 좋은 대우를 받을 수 있다.

4)소켓 프로그래밍(socket programming)：전구의 소켓은 전구와 전선을 이어주는 부분이다.
마찬가지로 특정 컴퓨터와 다른 컴퓨터를 연결할 수 있게 해 주는 프로그램을 소켓 프로그램이라고 부르며, 이것을 제작하는 것을 소켓 프로그래밍이라고 한다.
5)인공 지능 엔진(Artificial Intelligent engine)
게임에서 활동하는 캐릭터의 행동 규칙을 정한 코드를 인공 지능 엔진이라고 하며, 흔히 AI라고 부른다.
예를 들면, '게이머가 브레이크를 걸면, 브레이크를 건 순간에는 급속히,
그 후에는 완만하게 속도를 줄여 나간다.' 와 같은 규칙들의 집합을 인공 지능이라고 할 수 있다.

2010년 09월 24일 12시 37분 36초

컴퓨터 기술의 발전 속도는 너무 빨라서 마치 돌 위에 꽃이 피는 듯하다.
불가능해 보이고, 기적처럼 보이던 일들이 어느덧 현실 속에 이루어지고 있는 것이다.
컴퓨터를 업으로 하는 사람들은 이런 현실 속에서 자괴감을 느끼게 된다.
기껏 배워 놓은 기술이 2-3년 후에는 구식이 되어 버릴 수 있다는 사실.
 
10년 후에는 잊혀진 기술이 될 것이라는 사실이 우리를 두렵게 한다.
이런 현실을 견뎌내지 못하고, 중도 탈락하는 프로그래머들을 많이 보아왔다.
나도 예외는 아니어서, 한 때는 공장에서 매일 반복되는 일만 하는 사람들이 미치도록 부러웠던 적도 있다.
그 사람들은 늘 새로운 기술을 익혀야 하는 중압감은 없을 것 아닌가.
 
비록, 기름이 옷에 묻는 한이 하더라도 그 사람들은 행복할 것이라는 생각을 하고는 했다.
당시에 내가 경험했던 '자괴감'을 지금도 누군가는 느끼고 있을 것이다.
그렇다면 지금은 어떻게 사는가?
나는 이제 프로그래머의 일을 조금 접어 두고, 대학 교수라는 직업을 택하여 일하고 있으므로,
  예전의 두려움과 압박감에서는 한 걸음 물러서 있다.
하지만, 컴퓨터공학과 교수라는 직업 또한 늘 새로운 기술을 받아들여야 하고,
  어떤 면에서는 프로그래머들보다 한 걸음 앞서서 최신 정보를 소화해 두어야 하기 때문에
여전히 긴장 속에서 살고 있다.
 
그럼에도 불구하고 이전과 달라진 점이 있다면 덜 긴장한다는 것이다.
이전처럼 직업을 그만 두고 싶다던가, 어디론가 떠나고 싶다는 생각이 덜 든다.
왜 그럴까?
나 나름대로 새 기술을 소화해 내는 요령을 익혔기 때문이다.
 
그 새 요령이란 단 두 가지이다.
 
1. 기본기를 익혀 두면 기교, 즉 테크닉은 쉽게 익힐 수 있다는 생각
2. 새 기술은 파악만 해두고 꼭 필요할 테만 본격적으로 익힌다는 방침
 
이 두 가지의 요령을 익히고 나니 신기술을 익혀야만 한다는 강박 관념에서 벗어날 수 있었고,
새 기술도 의외로 쉽게 익힐 수 있었다.
 
우선 나는 기본기에 충실하려고 노력한다.
프로그래머나 대학 교수에게 있어서 기본기는 어떤 것일까?
우선 프로그래머라는 직업의 측면에서 보면, 운영체제론, 컴퓨터구조, 알고리즘과 자료구조,
데이터베이스, 소프트웨어 공학과
 같은 것이 해당된다.
 
주로 학부 과정에서 배운 내용들이다.
대학 교수라는 직업의 측면에서 기본기라고 할 수 있는 것들은 문장력, 교정 기술, 저작권법 해석 및
  적용, 계약서 작성 요령, 출판 기획력, 시장 및 수요의 발견 능력,
그리고 무엇보다 중요한 기초 프로그래머의 양성 등이 해당된다.
 
이 두 가지 분야의 기본기를 놓치지 않고, 연마하기 위해 늘 관련 도서를 읽는다.
 
이미 읽었던 책들도 다시 들쳐보며 회상한다.
이런 과정을 통해서 나의 기본기는 더욱 탄탄해 지는 것을 느낀다.
이렇게 되니 자신감도 생기고, 응용력도 생긴다.
 
그래서 신기술이 소개되어도 기본기를 바탕으로 해석하고 응용할 수 있게 되었다.
기본기가 깊어질수록 신기술을 소화할 능력이 커진다.
 
둘째로, 나는 신기술을 무조건 배워야 한다고 생각하지 않는다.
컴퓨터 분야는 매우 다양해지고 넓어졌다.
관련 직업군도 다양해졌다.
 
이 모든 분야에서 생성되는 새로운 주제와 새로운 기술을 모두 알 필요는 없다.
한 해에 발생되는 컴퓨터 서적만도 수백에서 수천 종에 이를 것으로 추산된다.
 
그리고 새롭게 발표되는 논문들, 신기술과 신제품들, 이것들을 모두 소화해 낼 수 있는 능력을 가진 사람은 없다.
그렇다면 어떻게 하는 것이 좋은가?
나의 경우를 예로 들면,
신기술이나 신제품 등에 대해서는 관련 서적이나 잡지 또는 관련 학회지에서 목차를 열람하는 정도로 그친다.
목차를 외울 생각도 하지 않는다.
 
그저, '이런 기술이 나왔구나'라는 정도로 생각한다.
그러다가 현업에 적용할 만한 기술이 필요하다고 생각할 때에 비로소 그 기술을 본격적으로 찾아본다.
 
이 시점에서도 바로 기술을 습득하지는 않는다.
기본기가 되어 있으므로, 관련 기술을 파악하는 정도로만 그친다.
그 후에 본격적인 개발이나 저술에 들어갈 때에 해당 기술을 집중적으로 학습한다.
해당 기술만 학습하는 것이 아니라, 관련 지식과 관련 기술을 통째로 학습한다.
이런 방식은 두뇌에 '기억과 이해의 갈고리'를 만들어 두는 것에 비유할 수 있다.
두뇌 과학에 의하면 우리 두뇌는 사전 지식이나 정보가 기억되어 있는 상태에서
새 지식과 정보를 더 잘 흡수한다고 한다.
그런 의미에서 나처럼 지금 당장 필요하지 않아 보이는 지식이나 기술이더라도
대충 훑어 보는 정도로 이해해 두면,
그것이 일종의 갈고리가 되어 그 후에 기술을 습득하는 일에 큰 도움이 되어준다.

2010년 09월 04일 16시 20분 18초

재귀 호출(recursive call)문제는 프로그래머들을 힘들게 한다.
재귀 호출이란 프로그램이 자신을 실행하게 하는 것이라고 할 수 있다.
A라는 프로그램이 있다고 하자.
이 A라는 프로그램이 실행되고 있는 중간에 A 안에서 다시 A를 실행하도록 하는 것이다.
 
'자신이 자신을 부른다' 또는 '프로그램이 자신을 다시 실행하게 한다' 라는 것이 재귀 호출의 개념이다.
재귀 호출이 워낙 다양한 해법을 만드는 일에 쓰이기 때문에 프로그래머라면
재귀 호출의 중요성을 모르지는 않을 것이다.
문제는 이 재귀 호출의 개념을 정립하기가 쉽지 않다는 데에 있다.
 
비교적 훈련된 프로그래머들도 재귀 호출을 제대로 이용하지 못하는 경우가 있다.
재귀 호출을 사용하면 간단하게 해결 될 문제를, 재귀 호출을 제대로 사용할 줄 몰라서
수천 줄이나 되는 복잡한 프로그램으로 만드는 경우도 있는 것이다.
이 재귀 호출에 대한 개념을 프로그램을 많이 작성하였다고 정립되는 것은 아닌 것 같다.
 
그럴 것 같으면 오랜 경력을 지닌 프로그래머가 재귀 호출을 잘 활용하여야 하는데 그렇지는 않기 때문이다.
그렇다면 어떤 프로그래머가 재귀 호출에 대한 개념을 정확히 이해하고 잘 활용할까?
나의 관측으로는 놀랍게도 게임을 즐기는 사람들이 그러했다.
 
게임 속에는 재귀 호출이 다양하게 숨어 있다.
이런 게임 중에서도 하노이 탑 게임을 재귀 호출의 진수를 보여준다.
하노이탑 게임을 즐기는 사람은 자신도 모르게 재귀 호출에 대해서 익히는 것이 된다.
자, 지금부터 하노이탑 게임을 즐겨보자.
그리고 만약 시간이 있다면 하노이탑 프로그램을 직접 작성해 보도록 하자.

2010년 08월 30일 18시 02분 49초

수학을 공부해 본 경험이 있는 사람이라면,
어려운 문제를 자신의 힘으로 풀었을 때에 부쩍 실력이 늘어난 것을 느낀 적이 있을 것이다.
쉽다고 느껴지는 문제를 수 백개씩 풀어도 실력이 늘지 않지만,
아주 난해한 문제를 몇 개 풀고 나면 확실하게 실력이 늘어난다.
이런 현상은 수학에만 나타나는 것이 아니다.
거의 모든 기술 분야에서 나타난다.
 
프로그래밍도 마찬가지이다.
자신의 실력으로 능히 짤 수 있는 프로그램,
이전에 짜 본 경험이 있는 알고리즘으로 된 프로그램은 작성하기 쉽다.
이런 프로그램을 수 백개 작성해 보아도 실력이 늘지 않는다.
자신의 실력으로 풀기 어려운 문제를 힘을 다해 풀어 보았을 때, 실력이 부쩍 부쩍 늘어난 것을 느낄 수 있다.
 
후배 프로그래머들은 나에게 어떻게 하면 실력을 늘릴 수 있느냐고 묻고는 한다.
해답은 여러 가지이다.
전문 지식을 늘릴 것, 전문 분야 외의 교양도 쌓아야 한다는 것,
영어나 수학의 기초를 지닐 것 등도 그런 해답 중의 하나이다.
 
그러나 가장 핵심적이고 확실한 효과를 볼 수 있는 방법은 '난해한 프로그램을 혼자의 힘으로 작성하는 것'이다.
그렇다면 무엇이 난해한 프로그램인가?
'난해하다'는 지극히 추상적인 단어로는 정확히 어떤 대상을 골라낼 수가 없다.
그리고 이 어휘는 매우 주관적인 것이다.
 
어떤 프로그램이 한 사람에게는 난해할 수 있어도, 모든 사람에게 난해한 것은 아니다.
그러므로 난해한 프로그램은 스스로 골라야 한다.
자신의 힘에 부치는 문제를 고를 수 있는 것은 오직 자신뿐이다.
 
자신의 실력은 그 누구보다 자신이 더 잘 안다.
  '이 문제를 해결하기에는 좀 힘들 것 같은데'라든가,
  '이 문제에 대한 알고리즘이 떠오르지 않아' 라든가,
  '내가 다룰 수 없는 분야의 프로그램이야'라는 말을 할 정도의 프로그램이 바로 난해한 프로그램이고,
  이런 판단은 사람마다 다르게 나타난다.
 
일단 난해한 프로그램을 고른 후에는 혼자의 힘으로 작성하는 것이 중요하다.
누군가의 도움을 받는다면 실력이 늘지 않는다.

프로그램을 작성하는 것은 수학 문제를 푸는 것과 비슷해서 답을 알고 풀면 실력이 늘지 않는다.
수학 문제를 과외 선생과 함께 공부할 때에는 다 풀 수 있을 것 같은데,
막상 시험장에 가면 문제에 대한 해법이 전혀 떠오르지 않는다는 점을 경험했을 것이다.
프로그래밍 실력도 마찬가지다.
 
누군가의 도움을 받아서 프로그램을 작성하면,
작성할 당시에는 프로그램이 잘 만들어지지만 혼자의 힘으로 풀려하면 안 된다.
실력이 늘지 않았기 때문이다.

2010년 08월 29일 19시 10분 23초