Posted by 大山
Tue, 18 Jul 2006 22:57:00 GMT
대학생 때 수학 교과서를 읽다 보면 종종 짜증이 났더랬다. 이해하고 보면 별 내용도 없는데 이해하기가 무척이나 어렵게 쓰여진 경우가 많아서다. 무슨 Obfuscated Math Textbook 콘테스트도 아닌데 말이다.
근데 Barnes & Noble(미국의 교보문고)에서 프로그래밍/컴퓨터책을 종종 들여다 보면 어찌나 잘 쓰여진 책이 많던지. 개념적으로 상당히 어려운 내용도 직관적으로 잘 설명이 되어 있었다. 수학책 한권 볼 시간에 컴퓨터책은 다섯권이 읽히더라. 삶은 유한한데 짧은 시간에 많이 배우는 것도 중요하다는 생각이 들었다.
그런 이유로 컴퓨터 책을 읽기 시작한지가 6년이 조금 넘었다. 읽고 나서 소장 가치가 있는 책이 아니면 정기적으로 정리하는데도 지금 내 책장엔 컴퓨터책이 서른권 정도 꽂혀있다. 컴퓨터에는 한계효용체감의 법칙이 적용되지 않는 것인지.
잘 쓰여진 컴퓨터책이 왜 많을까를 언제나 궁금해 했는데 블로깅을 시작해 보니 대강 이유를 알 것 같다. 글을 쓰는 일과 코드를 작성하는 일은 별반 다르지 않더라. 그래서 SICP의 서문에는 이런 글귀가 적혀져 있었나 보다.
컴퓨터 프로그램은 언제나 사람에게 읽히기 위해 쓰여져야 합니다. 프로그램이 컴퓨터에서 실행된다는 것은 부차적인 일일 뿐입니다.
프로그래밍을 익히고 나니 이제는 무엇을 개발할 것인지가 고민이다. 프로그래밍은 결국 누군가를 위한 도구를 만드는 일이고 사람들이 필요로하는 것을 이해하려면 사람을 이해해야만 한다. 인문학을 공부할 차례일까?
Posted in 프로그래밍 | Tags 수학, 컴퓨터, 프로그래밍 | 3 comments | no trackbacks
Posted by 大山
Mon, 17 Jul 2006 06:59:00 GMT
중학교 3학년때 쯤이었나, 통일장 이론을 완성하면 삶에 대한 모든 깨달음을 얻게될 거라고 굳게 믿었던 시절이 있었다. 뭐 대학생 때도 크게 다르진 않았던 것 같다. 인간이 자유의지가 있는지 없는지를 계산 가능성 문제로 이해한답시고 자바로 튜링머신을 구현해 놓고 한참을 끙끙댔었으니. (로저 펜로즈의 황제의 새마음 참고)
근데 학부때 교수랑 프로젝트를 잠깐 해보니까 대학원에 가도 내가 하고싶은 연구를 맘대로 할 수 있는게 아닌 것 같더라. 아카데미아에 대한 환상을 깨고 돈부터 벌기로 했다. 빨리 돈벌고 은퇴해서 통일장 이론 연구해야지, 뭐 지금도 계획은 그렇다.
수학, 물리 빼놓으면 할 줄 아는게 컴퓨터밖에 없으니 돈 벌려면 이걸로 뭔가 해야겠는데, 수학하던 버릇이 어디 가려나. 처음에는 알고리즘에만 관심이 있었다. 그냥 단순한 계산 알고리즘 말고 뭔가 심오한 깨달음을 줄 수 있는 그런 알고리즘을 찾아 헤맸다. 사실 재귀함수나 메타프로그래밍은 그런 느낌을 일부 주기도 했다. 이들의 피드백 루프는 인간이 스스로의 존재를 깨닫는 자아 인지 과정과 뭔가 유사한 면이 있기도 하니까.
근데 거기쯤에서 끝이더라. 프로그래밍에 그보다 더 심오한 것은 없었다. 실무에서는 퀵소트 보다 더 복잡한 알고리듬을 구현할 일도 없다. 몇달 전에는 루비 BBCode 파서 라이브러리를 구현하다 참고하려고 PunBB의 파서 코드를 들여다보다 깜짝 놀랐다. 재귀함수를 써서 트리 파싱을 하는게 아니라, 여는 태그와 닫는 태그 갯수를 세어서 숫자가 일치하나 안하나만 확인하더라. HTML로 변환하는 것도 정규식을 써서 앞태그 따로 뒷태그 따로 대치하는 식이었다. (솔직히 알고리듬 자체는 꽤나 촘촘하게 구현되어 있었다. 에러나는 예외 케이스 생각해 내려고 5분 정도 고민하다가 그만둬 버렸으니까.)
지난 30년간 Lisp으로 인공지능을 구현한다던 MIT의 천재들도 결국은 실패했다. (실패가 아니라고 이뤄낸 것도 많다고 우기는 사람도 있는데 실패라는 관점이 우세하다. AI의 그랜드 플랜은 인간 지능의 재현이었지 지식 구조의 설계가 아니었다.)
요지는 이거다. 프로그래밍은 공학이 아니고 과학은 더더욱 아니다. 해커와 화가에서 말하듯 프로그래밍은 공학보다는 미술에 가깝다. 작업 내용만 놓고 보면 건축에 더 가깝지만, 전 과정을 거의 혼자서 작업한다는 측면에서는 미술에 더 가깝다. 하지만 단순히 감상하기 위해서 만드는게 아니라 도구로써 사용하기 위해 만드는 것이니 공예에 가장 가깝다고 할 것이다.
물론 보통의 공예 작품을 만드는 것보다는 수학적, 공학적 지식이 엄청나게 많이 요구된다. 하지만 대부분의 프로그래머들이 이공계 출신이니 이것이 큰 문제는 아니다. 오히려 대부분의 개발자에게는 예술적 균형감각이 부족하다는게 문제이다.
더 이상 개발자의 경쟁력은 알고리즘 구현이나 복잡한 코드를 해독하는데 있지 않다. 해독하기 힘든 코드를 작성하는 개발자는 어디서도 환영받지 못할 테니까 말이다. 나는 앞으로 개발자의 경쟁력이 다음 세가지에 있다고 생각한다.
- 기술적으로 옳바르게 설계하는 능력
- 몇만 줄의 코드로 작성된 프로젝트도 쉽게 이해할 수 있게 직관적으로 설계하는 능력
- 사용성이 뛰어난 소프트웨어를 설계하는 능력
프로그래밍 언어가 발전할수록 개발에 요구되는 기술적 전문성은 급격히 줄어든다. 더 이상은 포인터를 이해하지 못해도 개발에 지장이 없다. 메모리 관리도 직접 할 필요가 없다. 기술적 전문성이 중요하지 않다는 이야기가 아니다. 기술적 전문성은 기본이되 그것만으로는 충분하지 않다는 얘기이다.
요즘 프로그래밍에서 눈에 띄는 추세 중의 하나는 아마추어의 부상이다. Linux는 학부생이 만들어 냈다. 루비는 일본의 한 아마추어가 취미 삼아 만든 프로그래밍 언어이다. 레일스의 개발자는 PHP로 아르바이트를 하던 학부생이었다. 엘리트 개발자들은 무엇을 하고 있었을까? 윈도우 NT, 자바, 그리고 스트럿츠를 만들어내고 있었다.
오늘날 개발자의 최대 경쟁력은 균형감각이다. 어셈블리어를 이해하는 능력이 경쟁력이던 시대는 이미 지나갔다. 정신을 바짝 차리고 미술 감각도 익히고 마케팅도 공부해야 한다. 안그러면 아마추어에게 밀릴지도 모를 일이다.
Posted in 프로그래밍 | Tags 프로그래밍 | 5 comments | no trackbacks
Posted by 大山
Sun, 16 Jul 2006 16:34:00 GMT
언제나 그렇지만 새로운 기술은 끊임없이 쏟아져 나온다. 영업자는 '유닉스'란 단어 하나만 알아도 마치 그 기술을 전부 아는양 말하지만, 개발자는 터미널 앞에서 수천시간을 씨름하고 나서야 비로소 유닉스를 조금 이해하게 된다. 기획자에게 '웹 2.0'의 도입은 새로운 단어를 하나 익히는 것만큼 쉬울지 모른다. 개발자는 웹 표준, Ajax, RSS, 태그, 웹서비스 등 한무리의 새로운 기술을 익혀야 하는데 말이다.
불과 이삼년 전만 하더라도 마이크로소프트는 영원할 것만 같았다. 수많은 개발자들이 비쥬얼 스튜디오를 익히고 마이크로소프트에서 쏟아내는 신기술을 소화해 내느라 정신이 없었다. 그런데 이제는 개발자는 맥을 써야 한다는 말이 공공연하다.
다들 자바가 대세인 줄 알았다. 프로그래밍의 미래라고 모두가 생각했다. 그런데 자바가 세상에 나온지 불과 10여년이 지난 지금 많은 개발자들이 자바의 마지막이 멀지 않음을 체감하고 있다.
어쩔수 없었던 것일까? 그런데 진작부터 자바가 별 볼일 없다는 걸 알고 있던 사람도 있었더라. 마이크로소프트의 이후를 일찍이 준비해온 사람들도 있고 말이다. Paul Graham은 진작에 알았으면 좋았을 것들이라는 글에서 이런 말을 했다.
인생은 엔진이 없는 행글라이더를 타는 것과 같습니다. 가능하면 맞바람을 타서 최대한 하늘 위로 올라가려고 하십시요. 멋있어 보이는 곳이 있으면 뒷바람을 타고 빠르게 그쪽으로 날아가고 싶은 유혹이 생기기도 합니다. 그런데 뒷바람을 타면 순식간에 지면에 너무 가까운 곳으로 내려가 버립니다. 나중에 내가 원하던 곳은 여기가 아니라는 것을 깨달았을 땐 이미 너무 늦어버리죠.
어떤 것이 맞바람을 타는 일일까? Graham은 경제학 대신에 수학을 전공하라고 말한다. 프로그래밍에 비유하면 자바 대신에 Lisp을 공부하는 일이리라. 당장 돈이 되는 것 보다는 미래를 위해 투자해야 한다.
개발자에게 전문성은 황금 알을 낳는 거위와 같다. 알을 빨리 낳게 하려고 무리수를 두면 거위가 일찍 죽어 버린다. 왜 국내의 수많은 개발자가 마흔도 안되어 개발을 포기하겠는가?
10년 뒤를 생각하고 그때도 유용할 지식을 배우는데 시간을 최대한 투자해야 한다. 물론 10년 뒤를 내다보는 것은 쉬운 일이 아니다. 내가 생각하는 10년 뒤 개발자에게 쓸모 없을 지식과 유용할 지식은 다음과 같다.
- 거의 쓸모 없을 지식: MFC, COM, ActiveX, 자바 관련 모든 것, Perl, SOAP, XML, 윈도우 서버
- 여전히 유용할 지식: Unix, 정규식, 관계형 데이터베이스, 메타프로그래밍, emacs/vi, HTTP, HTML XHTML/CSS, 루비, C
앞으로 10년 동안에도 수많은 기술이 나오고 또 사라질 것이다. 아무쪼록 개인의 전문성을 잘 관리해서 개발을 오래오래 즐기도록 하자.
Posted in 프로그래밍 | Tags 개발자, 마이크로소프트, 자바, 프로그래밍 | 6 comments | 2 trackbacks
Posted by 大山
Sat, 15 Jul 2006 14:48:00 GMT
다이내믹 프로그래밍 언어란 프로그램 실행중(런타임)에 프로그램 코드 자체가 변경될 수 있는 프로그래밍 언어를 말한다. 대표적인 다이내믹 언어에는 Lisp이 있으며 최근에 많이 사용되는 언어에는 루비, 파이썬 정도가 있다.
혹시 Lisp 개발자로부터 Lisp으로는 프로그램을 짜는 프로그램을 작성할 수 있다는 이야기를 들어 보았는지? Lisp의 이런 특징이 바로 언어의 다이내믹함에서 오는 것이다.
관련성은 있지만 이와 구분되는 개념에는 다이내믹 타이핑, 자동 메모리 관리 등이 있다. 꼭 그런 것은 아니지만 다이내믹 프로그래밍 언어는 보통 자동 메모리 관리, 다이내믹 타이핑 등의 기능도 가지고 있는 경우가 많다. 재미있는 점은 이러한 다이내믹함이 프로그래밍 언어에 추가될 때마다 개발자의 개발 생산성은 획기적으로 높아진다는 것이다.
자동 메모리 관리에는 보통 Garbage Collection이나 레퍼런스 카운팅이 쓰이는데, 이 기능이 있고 없고가 바로 자바와 C++의 가장 큰 차이점이라고 볼 수 있다. 메모리를 수동으로 지정하여 사용하고 해제할 경우 프로그램의 속도를 조금 더 빠르게 할 수는 있지만 이로 인해 손해보는 개발 생산성이 너무 크다. 바로 자바가 성공한 이유이다. 앞으로 자동 메모리 관리를 지원하지 않는 새로운 프로그래밍 언어가 성공할 확률은 제로에 가까울 것이다.
다이내믹(Dynamic) 타이핑에는 얽힌 오해가 있다. C 언어의 경우 포인터 타입 에러로 인해 개발자들이 고생을 많이 하곤 했는데, 이 때문에 자바 언어의 설계시에 스태틱(Static) 타이핑이라는 기능이 들어갔다. 당연히 자바 입문서들은 스태틱 타이핑을 예찬하곤 했었다. 문제는 객체지향 프로그래밍이 도입된 이상 스태틱 타이핑은 사실 중요하지 않게 되었다는데 있다. 결국 자바의 스태틱 타이핑은 불필요한 기능에 가까운 것이다. (물론 이러한 사실을 개발자들이 깨닫는 데 10년에 가까운 시간이 걸리긴 했다.) 다이내믹 타이핑을 사용하면 코드 작성이 훨씬 간편해지기 때문에 개발자의 생산성이 상당히 올라간다. 최근들어 루비나 파이썬 등이 인기를 얻고 있는 이유 중의 하나이다.
마지막으로 언어 자체의 다이내믹함인데, 이런 기능을 지원하는 프로그래밍 언어는 보통 eval이라는 함수를 가지고 있다. eval은 문자열로 전달되는 프로그램 코드를 프로그램 내에서 실행시켜주는 함수이다.
처음 접하는 사람에게 쉽게 이해가 가는 개념은 아니니, 심호흡을 한 번 하고 계속 읽으시길. 도대체 왜 프로그램 코드를 문자열로 받아서 실행시키느냐는 의문이 들 것이다. 이런 기능은 어떨까? 프로그램이 자신이 돌아가는 컴퓨터에 연결된 데이터베이스에 접속해서 데이터베이스 내부의 데이타 구조를 들여다본 다음 그런 데이타를 접근할 수 있는 API 함수들을 동적으로(다이내믹하게) 만들어서 개발자가 바로 쓸 수 있게 해준다면?
바로 루비로 만들어진 레일스 프레임워크의 핵심 모듈인 액티브 레코드의 기능이다. 이러한 프로그래밍 기법을 흔히 메타프로그래밍이라고 부르는데 개발자의 생산성을 획기적으로 높여주는 실로 대단한 기능이다.
위에서 설명한 이유로 인해 다이내믹 프로그래밍 언어는 개발자의 생산성을 무지막지하게 높여준다. 자바의 끝이 보이기 시작하는 이유이다.
Posted in 프로그래밍 | Tags 루비, 자바, 파이썬, 프로그래밍, Lisp | no comments | no trackbacks
Posted by 大山
Fri, 14 Jul 2006 15:29:00 GMT
가끔 모든 프로그래밍 언어는 다 똑같다고 줄기차게 주장하는 사람들이 있다. 이 사람들의 공통점은? 바로 사용할 줄 아는 프로그래밍 언어가 하나 밖에는 없다는 사실이다.
분명히 말하지만 프로그래밍 언어는 절대로 평등하지 않다. 그럼 왜 위와 같은 주장이 나오게 되었을까? '모든 컴퓨터 알고리듬은 어떠한 프로그래밍 언어로도 구현이 가능하다'는 이론을 잘못 이해해서 그렇다. 이 이론은 '모든 아이는 피카소가 될 잠재력이 있다' 정도의 수준에서 이해하는게 옳다. 같은 알고리듬을 구현하는데 1시간이 걸리는 언어와 1달이 걸리는 언어가 있다면 당신은 어떤 언어를 선택하겠는가?
실제로는 수백개의 프로그래밍 언어들이 매우 넓은 스펙트럼에 분포되어 있다. 이 스펙트럼의 한쪽 끝을 차지하고 있는 언어는 바로 어셈블리어다. 어셈블리어는 컴퓨터의 작동 원리를 배우게 된다는 측면에서 공부해볼만한 언어이긴 하다. 하지만 어셈블리어로 웹사이트를 구축하려는 사람은 아마 정신병원에도 없을듯.
스펙트럼의 보다 흥미로운 쪽은 Lisp이 위치하고 있는 반대쪽이다. 여기서 이 스펙트럼의 분포 기준은 무엇일까? Paul Graham은 이를 응축성(succinctness)이라고 설명한다. 복잡한 개념을 얼마나 작은 유닛에 응축시켜 담을 수 있는지가 기준이라는 것이다. 바로 이 응축성 때문에 Lisp으로 한시간이면 작성할 수 있는 프로그램을 어셈블리어로 짜면 1달이 넘게 걸리게 되는 것이다.
프로그래밍 언어는 평등하지 않지만 한 언어가 언제나 다른 언어보다 우월하다는 것은 아니다. 언어의 선택은 필요에 달라지는게 맞다. 보통은 실행속도가 중요할수록 어셈블리어 근처의 언어를 사용하게 되고 개발 생산성이 중요할수록 Lisp 근처의 언어를 사용하게 된다. 하지만 이미 컴퓨터의 성능이 무어의 법칙을 따라 기하급수적으로 발전해 버렸기 때문에 성능 중심의 언어가 점점 메리트를 잃어가고 있는게 사실이다.
주류 언어만 놓고 보면 프로그래밍 언어는 "어셈블리어 => C => C++ => 자바 => ?", 이렇게 발전해 오고 있다. 당연히 ?에는 Lisp과 유사한 언어가 들어갈 것이다. 많은 사람들이 ?가 루비일 것이라고 생각한다. 나도 물론 같은 생각이다.
Posted in 프로그래밍 | Tags 루비, 어셈블리어, 자바, 프로그래밍, C | 2 comments | 1 trackback
Posted by 大山
Wed, 12 Jul 2006 20:06:00 GMT
이 글은 해커라는 단어의 본래 의미에 관한 글이다. 영어로는 비교적 많이 볼 수 있는 내용이지만 한글로는 아직 보지 못한 것 같아 한 번 적어본다.
우선 해커라는 단어는 원래 불법적인 활동과는 하등의 관련이 없는 단어라는 것 부터 분명히 말해두고 싶다. 시스템에 불법적으로 침입하는 활동을 지칭하는 단어에는 크래킹(cracking)이라는 표현이 있고 이런 활동을 하는 사람은 크래커(cracker)라고 부르는 것이 옳다.
해커(hacker)라는 단어는 핵(hack)을 하는 사람이라는 의미인데, 여기서 핵(hack)이란 단어는 '천재적인 방법으로 어려운 문제를 해결하다' 정도의 의미를 가지고 있다. 즉 해커란 '천재적인 방법으로 어려운 문제를 즐겨 해결하는 사람'이란 의미이다.
원래 이 단어는 컴퓨터 프로그래머들간에 천재 프로그래머를 지칭하는 표현으로 쓰였다. 해커라는 불리우는 것은 프로그래머로서 영예로운 일이며 아무나 함부로 사용할 수 없는 표현이었다.
해커라는 단어에 부정적인 이미지가 덧씌워진 것은 컴퓨터의 보안 문제와 결부되면서 부터이다. 디지털 정보는 그 특성상 복제가 용이하기 때문에 민감한 정보에 접근을 차단하는 것은 상당히 중요한 이슈 중에 하나이다. 1980년대에 들어 업무가 점차 전산화 되어가는 과정에서 미국의 회사들은 컴퓨터 네트워크에 보안 시스템을 도입하기 시작한다.
그런데 보안이라는 개념이 거의 없던 환경에서 어느 순간부터 이곳 저곳에 보안 시스템이 설치되기 시작하자 해커들 중 일부는 이런 보안 시스템에 침투하는 것을 마치 게임처럼 즐기게 된다. 대부분의 경우는 범죄의 목적이 아니라 단지 재미 삼아 하는 경우가 많았다. 하지만 회사들 입장에서는 이러한 활동을 민감하게 받아들일 수 밖에 없었다. 이런 사건들이 미디어에 보도되면서 해킹이란 단어에는 보안 시스템에 침투하는 활동이란 의미가 추가되어 버린 것이다.
혹자는 프로그래머들이 왜 그런 활동에 흥미를 느끼느냐고 반문할 지도 모르겠다. 하지만 역사적으로 천재들이 이런 종류의 반항적 도전을 즐겨했다는 증거는 컴퓨터 분야 외에도 수없이 많다. 가장 널리 알려진 예는 노벨 물리학상을 받은 물리학자인 리처드 파인만의 일화이다. 금고를 여는 취미를 가지고 있던 파인만은 심지어 맨하탄 프로젝트[1]가 진행되던 연구소에서 조차도 기밀서류가 들어 있는 금고를 열곤 했었다고 전해진다.
물론 오늘날에는 대부분의 프로그래머들이 보안 시스템을 침투하는 것이 법률적으로 심각한 문제를 초래한다는 것을 잘 이해하고 있고, 이런 불법적인 행위에 가담하는 일은 수준 낮은 개발자나 하는 일이라고 치부하고 있다.
최근 들어서는 오픈소스 개발자들을 중심으로 해킹 및 해커의 원래 의미를 복원시키려는 노력이 줄을 잇고 있다. 대표적인 예로 미국의 O'Reilly 출판사는 Hacks란 이름의 컴퓨터 책 시리즈를 출간했는데 O'Reilly사의 사장인 Tim O'Reilly는 핵(Hack)이라는 단어의 원래 의미를 복원하는 차원에서 Hacks를 시리즈명으로 선정했다고 밝히고 있다. 지금 읽고 계신 이 글도 이와 같은 노력의 일환으로 이해해 주시면 되겠다.
정리하자면 해커란 최고의 경지에 오른 프로그래머를 지칭하는 영예로운 표현이다. 이는 포부를 지닌 개발자라면 누구나 욕심내어야 할 지향점이 되어야 할 것이다. 그리고 해킹 및 해커란 단어가 부정적인 의미로 잘못 사용되는 경우에 대해서는 다같이 힘을 합쳐 고쳐나가도록 해야겠다.
Posted in 프로그래밍 | Tags 프로그래밍, 해커, 해킹 | no comments | 1 trackback
