폭스바겐 Lisp

Posted by 大山 Sat, 06 Jan 2007 06:57:00 GMT

폭스바겐 Lisp

Lisp 프로그래밍 언어의 유연함을 폭스바겐 비틀에 빗대어 표현했네요. 보시다가 내용이 잘 이해가 안되는 부분이 있으면, 댓글로 물어보셔도 좋습니다. :)

Posted in  | Tags ,  | 1 comment | no trackbacks

JSON vs XML

Posted by 大山 Tue, 26 Dec 2006 23:30:00 GMT

지난 9월쯤에 XML에 태클을 거는 글을 쓴적이 있었습니다. 그에 이어지는 글에서도 많은 분들이 토론에 참여해 주셔서 저도 생각의 폭을 넓히는 계기가 되었구요. (그때의 토론을 기반으로 제가 짧은 글마소에 기고하기도 했습니다.)

이제 미국쪽 블로고스피어에서도 비슷한 토론이 시작된 것 같습니다. 관심있으신 분들은 참고하시면 좋을 것 같습니다.

Posted in  | Tags ,  | 2 comments | no trackbacks

루비 vs PL/I

Posted by 大山 Fri, 17 Nov 2006 17:53:00 GMT

최근에 한 시중 은행의 전산망을 총괄하시는 부장님을 만나뵐 기회가 있었다. 일반 엔터프라이즈 환경이야 특별히 궁금할 것도 없지만, 엔터프라이즈 중에서도 가장 보수적이라는 은행의 전산망 인프라는 예전부터 궁금해했던 참이라 신나게 이것저것을 여쭤볼 수가 있었다.

여기서 질문 하나. 은행의 전산실에서 주로 쓰이는 프로그래밍 언어는 무엇일까?

자바? 땡!

C++? 땡!

정답은 PL/I과 COBOL이다.

올해 초에 한 네덜란드 PL/I 개발자와 작업을 같이 한적이 있는데, 사실 그전까지는 나도 PL/I이라는 언어가 있는지도 몰랐었다. PL/I은 1960년대 초에 COBOL과 Fortran의 역할을 하나의 언어에서 해결하기 위해 IBM에서 만든 언어로, 은행의 전산실에서 PL/I이 많이 쓰이는 것은 아마도 IBM 메인프레임이 아직도 많이 사용되기 때문인 듯.

여기서 질문 하나 더. 왜 은행에서는 아직도 유닉스 서버 대신에 메인프레임이 사용되는 것일까?

답: 유닉스 서버는 다운이 잘되서.

윈도우에 비하면 철옹성같아 보이는 유닉스도 은행의 기준에서는 다운이 잘되는 편이라니, 할말을 잃었음. 최근에는 유닉스도 충분히 안정적이라는 판단이지만, 아직은 업체들의 지원 수준이 미덥지 못하다고 한다.

이번에는 다소 쉬운 질문. 은행에서 주로 사용되는 데이터베이스 서버는?

답: 오라클이 대세. Sybase도 가끔 눈에 띄는 정도. DB2는 찾아보기도 힘들다고.

1959년에 나온 COBOL과 1964년에 나온 PL/I이 아직도 지배하는 은행의 전산실, 과연 이곳에 변화의 기미는 없을까? 그렇지만은 않다고 한다. 요새는 PL/I 인력이 전혀 양성되지 않는 이유로 신규 인력은 모두 내부적으로 교육을 하는데, 요즘의 젊은 개발자들은 PL/I을 배우길 꺼려한다고.

Web 2.0이다 Ajax다 해서 나날이 변해가는 웹 개발에 비하면, 조선시대 만큼이나 먼 옛날의 기술이 아직도 점령하고 있는 은행의 전산실이지만, 시스템 안정성을 최우선하는 그곳의 보수적인 문화에서 배울 점도 적잖이 있었다. 데스크톱 애플리케이션이 다운되듯이 전산망이 다운된다면 큰일일테니 말이다. ;)

나의 루비 이야기에 아직도 프로그래밍 언어에 그만한 발전의 여지가 남아 있었냐고 놀라워 하시던 그분도 루비의 계보가 Lisp과 Smalltalk로 이어진다는 말에는 곧 고개를 끄덕이셨다. 언어는 달라도 SQL을 사용해서 데이터베이스 프로그래밍을 하는 것은 크게 다르지 않아, 레일스의 생산성이 어떻게 가능한지를 설명하는 것도 생각보다 어렵지는 않았다.

반세기에 가까운 기술의 간극에서 이런 대화가 가능하다는 것이 기술이 얼마나 빨리 변하는지를 웅변해 주는 듯한 느낌이다. 뭐 이미 루비로 구현된 신용카드 결제 모듈도 여럿 있는데, 언젠가는 은행의 전산실에서 루비가 쓰이는 것도 아주 꿈만은 아닐지도. :)

Posted in  | Tags , , ,  | 8 comments | no trackbacks

실용적 함수형 프로그래밍 세미나 후기

Posted by 大山 Sat, 14 Oct 2006 17:49:00 GMT

오늘은 실용적 함수형 프로그래밍 세미나에 다녀 왔다. 대안언어축제 2006에서 같은 방을 사용했던 유재명님이 '다시 보는 디자인 패턴' 그리고 'Parsec 사용법 가이드'라는 주제로 발표를 하셨는데, 역시 Haskell은 매력적인 언어라는 생각이다. 대안언어축제때 재명님께 pair로 가르침을 받은 덕분에 이제 왠만한 Haskell 코드는 대강 이해가 가더라는~ :D

얼마전에 Mark Dominus가 1972년의 디자인 패턴이라는 글에서 디자인 패턴 무용론을 주장하여 한동안 영어권 웹에서 논쟁이 후끈 달아오르기도 했지만, GoF 책에 소개된 디자인 패턴 중 상당수가 자바나 C++의 언어적 제약을 극복하기 위해서 고안된 것만은 분명해 보인다. '다시 보는 디자인 패턴'은 Haskell과 같은 함수형 프로그래밍 언어에서 어떻게 많은 디자인 패턴이 패턴이라는 이름이 무색할 정도로 손쉽게 코딩될 수 있는 지를 잘 보여주는 발표였다.

두번째 발표였던 'Parsec 사용법 가이드'도 무척 흥미로웠는데, Parsec 같은 라이브러리만 있으면 왠만한 파서의 구현은 무척 간단한 작업이라는 생각이 들었다. 루비 코드 파서를 구현해보는 것도 그리 어려운 일은 아닐듯.

Haskell이 메인스트림 언어가 되지는 못할 것이라는 재명님의 언급이 있었지만, 길게 내다보는 개발자라면 함수형 프로그래밍 언어 한둘은 익혀야 한다는 생각이다. 멀리가지 않고 루비만 제대로 익히려 해도, 함수형 언어의 개념들이 필수적이다. 이론적인 것을 좋아하는 사람이라면 Haskell, 쉽게 배우고 싶다면 Lisp, 실무에 활용하고 싶다면 OCaml 등을 공부해 보는 것은 어떨까?

다른 약속이 있어서 마지막 발표인 'C++ 함수형 프로그래밍'은 참석하지 못했다. 다소 아쉽긴 했지만, 이건 다른 분들의 후기를 참고해야 할듯.

Posted in  | Tags , ,  | 4 comments | no trackbacks

Re: 내가 XML을 싫어하는 이유

Posted by 大山 Tue, 12 Sep 2006 17:44:00 GMT

내가 XML을 싫어하는 이유에 답글을 쓰다가 너무 길어지는 것 같아 별도의 글로 엮어 봅니다.

우선 XML, Lisp 리스트, 해시 리터럴, JSON, YAML 등은 모두 트리형 데이타를 기록하기 위한 포맷입니다. 이 점에서 이들 포맷은 모두 같은 위상을 가지고 있습니다. 이들은 모두가 다 구조적이며 얼마든지 확장이 가능하지요. (XML의 차이점은 이렇게 확장된 포맷을 DTD, XML Schema, RELAX NG 등으로 엄밀하게 정의할 수 있다는 점인데, 이 때문에 validation도 가능합니다.)

XML 포맷의 가독성이 떨어지는 이유는 크게 두가지인데 첫째로는 오픈(open) 태크와 클로즈(close) 태그에서 태그 이름이 중복되어 표시되고 있고, 둘째로는 자동으로 생성된 XML 마크업 코드의 Indentation이 임의적이 경우가 많기 때문이죠. 물론 attribute 값을 표시하는 방법이 두가지인 등, 불필요하게 복잡한 요소가 있기도 하구요. 저는 XML의 가독성 문제가 기본적으로 신택스에 있다고 생각합니다.

네임스페이스가 구분되어 있다보니까, 한 파일에서 여러 XML 규격을 mix & match하는 것이 가능한데, 과연 이게 필요한 것인지 저는 다소 회의적이네요. 새로 합쳐진 통합 규격을 지원하는 애플리케이션이 아니라면, 어짜피 이런 포맷을 처리할 수는 없겠죠. 이러한 애플리케이션 군이 필요하다면 서민구님이 언급하신 것처럼 두가지 XML 규격이 합쳐진 새로운 규격을 만드는게 더 적합한 해결책이라고 생각합니다.

포맷 validation과 HTML 렌더링이 브라우저마다 달라지는 이슈는 별도의 문제인 것 같습니다. 렌더링이 달라지는 것은 브라우저마다 각 태그를 렌더링할 때 사용하는 default 값이 다르기 때문으로, validation으로 해결될 문제는 아니라는 생각입니다. validation이 체크해 주는 것은 신택스일 뿐이고, 시맨틱적인 해석에는 별 도움을 줄 수 없지요. 사실 DTD 등이 없이도 기본적인 XML 신택스는 검증할 수 있기 때문에, 실질적인 validation의 역할은 해당 파일에서 허가된 키워드만을 쓰고 있느냐를 확인하는 역할에 제한됩니다.

이원구님의 말씀처럼 XML이 복잡해진 이유는 범용적이기 때문이라고 생각합니다. 지나치게 범용적인 도구는 막상 적합한 용처가 드물 수 있지요. XML의 장점은 분명하지만, killer 애플리케이션이 그렇게 많지는 않은 것 같습니다.

공성식님께서 YAML의 장점과 단점을 잘 지적해 주셨는데, 사실 제가 하고 싶었던 이야기도 크게 다르지 않습니다. 상황에 따라 여러 적합한 포맷이 있는데 맹목적으로 XML을 고집하지는 말자는 것이죠. 설정파일에는 YAML이 편리하지만, 문서 파일에는 YAML이 적합하지 않을 수 있습니다. (depth-level 변경 정도는 텍스트 편집기에서 지원할 수 있지 않을까요?) 빌드 파일에서는 rake처럼 아예 프로그래밍 코드를 직접 사용하는게 더 편리하다는 생각이고, Ajax에서는 JSON의 사용이 더 자연스럽다고 생각합니다. 애플리케이션에서 데이타를 저장할때는 그냥(오픈 형식의?) 바이너리 파일을 사용하는 것이 어떨까요? 파일이 열리는 속도가 훨씬 빨라질텐데 말이죠.

자바 프레임워크의 설정 파일, ant의 빌드 파일, Ajax에서의 XML, 애플 Keynote의 파일 포맷, SOAP 등은 모두 XML을 잘못 활용한 예였다고 생각합니다. 반대로 RSS, DocBook 등의 경우에는 XML이 딱이라는 생각이 들더군요. 다른 분들의 생각은 어떠신지요? :)

관련글: JSON vs XML

Posted in  | Tags , , ,  | 16 comments | 1 trackback

내가 XML을 싫어하는 이유

Posted by 大山 Sat, 09 Sep 2006 13:45:00 GMT

내 생각에 XML이 가져온 효과는 단 한가지이다. 바로 오픈 포맷의 확산에 기여했다는 것. 그런데 그렇게 확산된 오픈 포맷이 하필 XML이라는 것은 다행중 불행인 것 같다.

우선 XML 마크업은 가독성이 매우 낮다. XML의 주요 설계 목적 중 하나가 사람 눈에 읽힐 수 있어야 한다는 것이었는데, 말 그대로 읽히기만 한다. 차라리 Lisp 코드의 가독성이 더 나을듯.

XML을 둘러싼 hype이 워낙에 거셌다 보니까, ant처럼 빌드 파일 포맷에 XML이 사용되기도 하고, 각종 설정 파일에도 XML이 단골이다. 개중에는 SOAP처럼 원격 프로시져 호출에 XML을 사용한 경우도 있다. 그런데 사실 따지고 보면, XML 포맷이란 트리 구조의 데이타를 단순히 텍스트 형태로 나타낸 것에 불과하다. 트리 구조를 표현하기에 적합한 텍스트 포맷은 XML 말고도 여럿 있다. 위에서 살짝 언급한 Lisp의 리스트도 좋은 예이고, 해시 리터럴(literal), YAML, JSON 등도 있다. 이들은 가독성도 뛰어나고, 파싱도 쉽고, 처리속도도 빠르고, 저장 공간도 더 적게 차지한다.

물론 XML에는 네임스페이스나 문서 검증 기능도 있지만, 자바에서 네임스페이스 충돌을 원천적으로 막겠다고 네임스페이스 이름에 도메인 주소를 집어넣는 만행을 저지른걸 떠올려 보면, XML의 네임스페이스도 다소 오버한 느낌이다. 지난 10여년간 HTML이 발전해온 과정을 보면 문서 검증 기능도 그다지 중요한 것 같지는 않고.

결과적으로 XML은 가독성도 나쁘고, 핸드 코딩도 힘들고, 파싱도 복잡하고, 처리속도도 느리다. 과연 XML은 어디에 유용할까?

관련글: Re: 내가 XML을 싫어하는 이유, JSON vs XML

Posted in  | Tags , , ,  | 6 comments | no trackbacks

자바 7은 클로저를 지원할 듯

Posted by 大山 Sun, 20 Aug 2006 06:14:00 GMT

자바 7에서는 드디어 클로저를 지원하려나 보다. 지금이 자바 5이니, 자바 7이 언제 나오게 될지는 모를 일이지만.

모르는 분들을 위해 살짝 귀뜸하면, 클로저(Closure)는 코드 중에 함수를 직접 정의해서 객체로 변환시킨 걸 이르는 용어이다. 우리말로 하면, 익명 함수 정도가 될까? 흥미로운 건 이걸 다른 메소드에 인자로 넘길 수 있다는 거다. 예를 들면, 다음과 같은 식이다.

>> [1, 2, 3, 4, 5].map(&lambda {|i| i * 3})
=> [3, 6, 9, 12, 15]
 

위에서 lambda { ... } 부분이 클로저인데, 이는 i에 해당하는 수를 넘겨주면 그의 3배수를 리턴하는 익명 함수 객체이다. 위의 코드에서는 이 클로저를 배열의 map 메소드에 인자로 넘겨주고 있다. map 메소드는 배열의 각 원소에 넘겨받은 클로져를 적용해서, 새로운 배열을 만들어 리턴해준다. 이를 보다 루비스럽게 작성하면 다음처럼 되겠다.

>> [1, 2, 3, 4, 5].map {|i| i * 3}
=> [3, 6, 9, 12, 15]
 

루비에서는 클로저란 어려운 이름 대신, 이를 블록이라고 부른다. 다른 예를 하나 들어보자.

>> ["banana", "kiwi", "apple", "water melon"].sort
=> ["apple", "banana", "kiwi", "water melon"]
 

위의 코드에서 sort 메소드는 배열의 원소를 알파벳 순서로 정렬해준다. 그런데 sort에 블록을 붙여주면 정렬 법칙을 바꿀 수 있다. 다음 코드를 한번 보자.

>> ["banana", "kiwi", "water melon", "apple"].sort {|i, j| i.length <=> j.length}
=> ["kiwi", "apple", "banana", "water melon"]
 

위에서는 문자열의 길이를 비교하는 블록을 sort 메소드에 넘기고 있다. 결과적으로 리턴되는 배열도 문자열의 길이대로 정렬되어진다.

자바 5에서는 generic이 추가되더니 7에서는 클로져를 지원하는 등 자바도 갈수록 루비스러워지는 듯. 자바 7을 기다리는 그대 지금 루비로 오라. ;)

Posted in  | Tags , , , ,  | 22 comments | 2 trackbacks

객체지향 프로그래밍에 대한 오해와 진실 2

Posted by 大山 Thu, 17 Aug 2006 07:56:00 GMT

[참고: 이 글은 객체지향 프로그래밍에 대한 오해와 진실에 이어지는 시리즈임.]

객체지향 언어에 대한 입문서를 보면, 상속, 캡슐화, 다형성 외에도 빠지지 않고 등장하는 설명이 하나 있다. 바로 객체는 실제 세상(Real World)의 물체를 모델링한다는 것이다. 물론 이 내용을 다루는 챕터는 모든 객체가 실제 세상의 물체와 대응될 필요는 없다며 어물쩍 마무리를 하기 마련이지만 말이다.

실제 세상에 대한 모델링이란 주장은 얼핏 객체의 필요성에 대한 그럴듯한 설명인 것 처럼 보이지만, GUI 프로그래밍이나 시뮬레이션 설계를 하는게 아니라면 전혀 맞아들어가지 않는 설명이다. 오히려 이 때문에 일부 뛰어난 해커들마저 OOP를 오해하는 경향이 있기 때문에 여기서 짚고 넘어가려고 한다.

객체지향 프로그래밍에 대한 또 한가지 오해는 상속이 코드 재사용의 핵심이라는 말이다. 이는 다분히 과장된 주장이라고 보여진다.

마지막으로 모든 객체지향 언어에 해당되는 것은 아니지만, 많은 개발자에게 '객체지향 언어 == C++ 또는 자바'로 받아들여지므로 이 내용을 같이 다루어도 좋을 성 싶다. 바로 스태틱 타이핑(Static Typing)이 버그를 줄여준다는 오해이다.

하나씩 짚어보자. 어쩌다가 객체지향 언어는 실제 세상의 물체를 모델링한다는 설명이 생기게 되었을까? 바로 최초의 객체지향 언어였던 Simula가 시뮬레이션 용으로 만들어진 언어였기 때문이다. 하지만 여기서 주의할 점은 Simula는 1960년대에 나온 프로그래밍 언어였다는 점이다. 실제로 1971년에 나온 Smalltalk-71은 Simula에서 객체에 대한 메세지 보내기 개념(즉 데이타와 함수를 묶어두는 방식)만 따와서 구현된 것으로 알려져 있다.

시뮬레이션 또는 GUI 프로그래밍에서는 객체지향 프로그래밍이 무척이나 자연스럽게 느껴지는 것이 사실이다. 하지만 프로그래밍의 범주는 이보다 훨씬 더 넓고, 객체지향(데이타에 함수 묶어두기) 프로그래밍은 꽤나 보편적으로 유용하다.

두번째로 상속과 코드 재사용성 부분인데, 상속을 통해서 코드 재사용을 추구하는 것은 프레임워크에서 제공하는 템플릿 클래스를 사용하는 등의 상당히 제한된 경우에만 적합한 것 같다. 이 때문에 Objective-C를 사용하는 Cocoa 같은 프레임워크에서는 조합(Composition)과 위임(Delegation)의 사용을 훨씬 더 강조하고 있다.

그런데 왜 상속을 통한 코드 재사용이 그토록 강조되는 것일까? 아마도 마케팅의 영향이 아닌가 싶다. C++와 자바는 모두 업계 주도적으로 확산된 언어이다. 마케터들은 실제로 중요한 것 보다는 사람들의 머리속에 각인될만한 내용으로 마케팅을 전개하기 마련이다. 이 마케팅이 너무 성공적이어서 수많은 개발자들을 헤매이게 만들기는 했지만 말이다.

마지막으로 스태틱 타이핑 부분인데, 스태틱 타이핑이 컴파일 최적화에 도움을 주기 때문에 프로그램의 성능을 높여주는 것은 사실이다. 무어의 법칙때문에 나날이 덜 중요해지는 요소이기는 하지만 말이다. 하지만 스태틱 타이핑이 개발자의 실수를 방지해서 버그를 줄여준다는 말은 낭설에 가까운 것 같다.

스태틱 타이핑의 옹호자들에게 물어보라. 당신들은 스태틱 타이핑이 자신들의 실수를 줄여준다고 생각하느냐고. 그들은 이렇게 말한다. 자신들은 그런 초보적인 실수를 안하지만, '평균'적인 개발자에게는 그런 안전장치가 필요할 것이라고. 사용자들이 멍청할 것이라고 가정하는건 개발자들이 범하는 가장 흔한 실수 중의 하나이다. 일부 프로그래밍 언어의 설계자들 역시 비슷한 오류에 빠졌던 것은 아닌가 싶다.

Posted in  | Tags ,  | 12 comments | 1 trackback

객체지향 프로그래밍에 대한 오해와 진실

Posted by 大山 Wed, 16 Aug 2006 08:14:00 GMT

많은 개발자들이 OOP(객체지향 프로그래밍, Object Oriented Programming)를 처음 접하는 것은 아마도 C++나 자바를 통해서일 것이다. 보통 C++/자바 입문서는 OOP란 무엇인가를 설명하는 챕터로 시작되기 마련인데, 하나같이 객체지향 프로그래밍의 핵심을 상속(Inheritance), 캡슐화(Encapsulation), 다형성(Polymorphism)이라고 설명하고 있다.

나중에 Objective-C, Smalltalk, 자바스크립트 등을 접하면서 이같은 설명이 얼마나 엉터리인지 깨닫게 되었다. 이 글에서는 내가 지난 수년간 객체지향 프로그래밍에 관해서 이해하게 된 것을 한 번 정리해 보려고 한다.

조금 규모가 있는 프로그램을 작성하다 보면, 가장 골치아픈 이슈 중의 하나가 소스코드의 복잡성을 관리하는 문제이다. 변수와 함수의 이름을 일관적으로 정리하고 전체 소스코드에 체계적인 구조를 잡아두지 않으면, 자신이 직접 작성한 코드를 들여다 보는 것 조차 막막해지기 십상이다.

프로그래밍 언어는 이러한 소스코드의 복잡성을 보다 체계적으로 관리할 수 있는 방향으로 발전해 왔다. 초기의 프로그래밍 언어에는 함수 개념 조차도 빠져 있었다. 함수는 프로그램을 유닛 단위로 나누어서 관리하기 위해 만들어진 가장 기초적인 개념이다. 루프, 조건문, 케이스문 등 역시 프로그램을 보다 체계적으로 작성하기 위해 생겨났는데 과거에는 이들 대신에 GoTo문이 사용되곤 했었다.

그런데 점차 프로그램에서 사용되는 함수의 수가 늘어나자, 함수의 이름과 그 소스코드를 관리하는 일이 커다란 문제가 되어버렸다. C나 PHP로 개발을 해 본 사람은 잘 알겠지만, mysql_field_name(), mssql_field_name() 식으로 함수 이름 마다 접두사(Prefix)가 필요한 데다가, mb_strlen(), ob_get_length(), mysql_fetch_lengths() 처럼 함수 이름을 명명하는 방식은 개발자마다 제각각이게 마련이다. mailparse_determine_best_xfer_encoding() 처럼 함수 이름이 한도없이 길어지는 문제는 두말할 필요도 없겠다.

객체지향 프로그래밍은 바로 이러한 문제에 대한 해결책을 제시했다. 함수를 아예 데이타에 묶어서 관리하면 그 이름이 짧아지게 될 뿐더러, 함수의 소스코드 또한 데이타 구조의 정리체계에 따라 관리가 가능하다는 것이 바로 객체지향 프로그래밍의 핵심이다. 객체지향 프로그래밍에서는 이렇게 데이타에 묶여진 함수를 메소드(method)라고 부른다.

물론 데이타에 묶어서 관리하는 것이 자연스럽지 못한 함수도 적지 않은게 사실이다. OOP 언어에서는 데이타(객체)에 묶어두기에 적합하지 않은 함수를 클래스나 모듈에 묶어 관리하는 방식으로 이 문제를 비켜가고 있다. 클래스는 함수 이름 관리를 위한 적절한 네임스페이스를 제공해 주기도 하기 때문에, 객체에 묶이지 않은 함수의 경우에도 함수 이름과 그 코드의 관리가 한결 수월하게 되었다.

이 글의 시작에서 언급했던 내용을 다시 한 번 살펴보도록 하자. OOP를 설명하는 일반적인 방법은 상속, 캡슐화, 다형성 등의 개념을 통해서이다. 그런데 캡슐화란 프로그래밍에서는 너무도 보편적인 개념인 추상화(Abstraction)의 또다른 표현일 뿐이고, 다형성은 함수 이름에서 접두사(Prefix)가 빠진다는 것을 어려운 용어로 표현한 것에 불과하다. 상속 조차도 객체지향 시스템을 설계하는 하나의 방식에 불과해서, 자바스크립트 같은 언어에서는 상속 대신 프로토타입(Prototype)이라는 전혀 다른 개념을 사용하고 있다.

객체지향이란 함수를 관리하는 하나의 프로그래밍 기법에 불과할 뿐이다. 매우 효과적이고 편리한 방법임에는 틀림이 없지만, 그렇게 거창하지도 또 이해하기에 복잡한 개념도 아니다.

관련글: 객체지향 프로그래밍에 대한 오해와 진실 2

Posted in  | Tags ,  | 9 comments | 1 trackback

오픈소스가 바꾸어 놓은 것

Posted by 大山 Mon, 24 Jul 2006 01:44:00 GMT

오픈소스가 가져온 변화는 물론 한두가지가 아니다. 여기서는 프로그래머 입장에서 보았을 때 오픈소스가 게임의 법칙을 어떻게 바꾸어 놓고 있는 지를 한 번 살펴보려고 한다.

오픈소스의 일차적인 효과는 무료로 수많은 프로그램을 사용할 수 있게 되었다는 점, 그리고 해당 프로그램의 소스코드를 들여다 볼 수 있게 되었다는 것이다.

물론 컴퓨터를 쓰다가 커널 패닉이 났다고 해서 리눅스 커널을 디버깅 하겠다고 덤비는 개발자는 많지 않을 것이다. 하지만 라이브러리를 사용하려다가 한글 지원이 미비한 것을 보고 유니코드 인코딩 지원을 추가 하는 정도는 어떨까? 프레임워크를 신버젼으로 업데이트 했을 때, 호환이 안되는 구버젼 라이브러리 코드를 업데이트 하는 정도라면?

실제로 해보니까 별 것 아니더라. 필요한 프로그램을 찾아 쓰고, 고쳐서 쓰고 하다 보면, 나중에는 왠만한 건 새로 만들어서도 잘 쓰게 된다. 책의 예제를 아무리 따라해 봤자 실력이 늘지는 않는다. 제대로 익히려면 역시 소스코드를 직접 들여다 봐야만 한다.

이런 관점에서 보면, 옛날에는 미국의 커다란 IT 회사의 연구소나 유명한 대학원에 들어가지 않으면 접근할 수 없던 것을 이제는 누구나 손쉽게 접할 수 있게 되었다고 하겠다. 소수의 회사와 대학이 독점하던 것들이 이제는 밖으로 풀려져 버렸다는 얘기이다.

어느 대학이나 회사도 더 이상 소프트웨어 혁신의 중심지이지는 못하다. 리눅스는 핀란드의 한 학부생에 의해 만들어지고, MySQL은 스웨덴의 작은 회사가 만들었으며, 루비는 한 일본 개발자의 취미생활에서 시작되지 않았는가? 최근에 웹 개발 커뮤니티를 뒤집어 놓고 있는 레일스 역시 덴마크 한 학부생의 아르바이트 프로젝트에서 시작되었다. 이제 소프트웨어 혁신의 중심지는 인터넷이며 방식은 오픈소스이다.

프로그래밍에 있어 게임의 법칙은 분명히 바뀌었다. 다행인 점은 더 이상 소프트웨어 산업이 어느 한 국가나 회사에 종속적이지 않게 되었다는 것이다. 우리도 뒤쳐지지는 말아야 하지 않을까?

Posted in  | Tags , , , , ,  | no comments | no trackbacks

내가 프로그래밍을 공부한 이유

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 , , , ,  | 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 , , , ,  | 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를 시리즈명으로 선정했다고 밝히고 있다. 지금 읽고 계신 이 글도 이와 같은 노력의 일환으로 이해해 주시면 되겠다.

정리하자면 해커란 최고의 경지에 오른 프로그래머를 지칭하는 영예로운 표현이다. 이는 포부를 지닌 개발자라면 누구나 욕심내어야 할 지향점이 되어야 할 것이다. 그리고 해킹 및 해커란 단어가 부정적인 의미로 잘못 사용되는 경우에 대해서는 다같이 힘을 합쳐 고쳐나가도록 해야겠다.

  1. 맨하탄 프로젝트(1942~1946): 미국의 핵폭탄 개발 프로젝트. 여기서 개발된 핵폭탄이 일본 히로시마와 나가사키에 투하됨.

Posted in  | Tags , ,  | no comments | 1 trackback