미술처럼 대부분 소프트웨어는 사람들에게 보이는 (쓰이는)것이 목적이다. 그래서 화가처럼 해커도 “동감”할줄 알아야 작품을 만들수 있다. 사용자의 관점에서 사물을 바라볼때 작품이 나온다.

어려서부터 나는 다른 사람의 관점에서 사물을 바라보도록 교육받았다. 실제로 이게 의미했던건 내가 원하는 것 보다는 주변의 사람들이 원하는 것을 먼저 해주게끔 배운 것이다. 물론 “동감”말고 이러한 삶의 방식을 나쁘게 부르는 이름이 있고 (역: 자기희생, 눈치보기), 나중엔 태도를 바꿔 내것을 먼저 챙기려고 노력했다.

그런데 내가 틀렸다. 사물을 다른 사람의 관점에서 바라보는 것이 실제론 성공의 비밀이었다. 그게 꼭 자기 희생을 의미하는 것은 아니었다. 실제론 그것과 거리가 멀었다. 다른 사람이 사물을 어떻게 보느냐를 이해하는 것은 꼭 그 사람의 이해관계를 위해 행동하라는 뜻은 아니다. 어떤 경우, 예를 들어 전쟁중에는 그 반대로 행동해야할 때도 있다.

대부분의 maker들은 사람들을 위해 무언가를 만든다. 그리고 사람들을 끌어들이기 위해서는 그들의 필요를 이해해야 한다. 예를들어, 거의 대부분의 명작 미술품들은 사람을 그린 것인데, 그 이유는 사람들은 그림에서 사람을 보고 싶어하기 때문이다.

“동감”은 아마도 괜찮은 해커와 뛰어난 해커를 나누는 가장 중요한 차이일 것이다. 어떤 해커들은 아주 똑똑하지만 동감의 면에 있어서는 아주 자기중심적이다. 그런 사람들은 사용자의 관점에서 사물을 못 보기 때문에, 위대한 소프트웨어를 디자인 하는것이 불가능하다.

해커가 얼마나 동감을 잘 하는지 알려면 기술적 배경이 없는 사람에게 기술 질문에 대한 답을 하는것을 보면 된다. 아마도 우리는 주변에서 똑똑하지만 그런 설명을 어처구니없이 못하는 사람들을 몇명 알고 있을 것이다. 그런 사람은 누군가 저녁식사 자리에서 프로그래밍 언어가 무어냐고 물으면 이런 식으로 대답할 것이다. “아, 하이레벨 언어는 컴파일러가 그걸 인풋으로 받아서 오브젝트 코드로 만들어주는 거예요” “하이레벨 언어?” “컴파일러?” “오브젝트 코드?” 프로그래밍 언어를 모르는 사람이라면 당연히 그런 용어에 무지할텐데 말이다.

소프트웨어가 해야 하는 일중 하나는 그 자신을 사용자에게 설명하는 것이다. 그래서 좋은 소프트웨어를 짜는 것은 사용자들이 기술에 얼마나 무지한지를 아는게 중요하다. 사람들은 소프트웨어에 아무 준비없이 다가갈 것이고, ‘이 소프트웨어는 이렇게 작동할거야’ 생각하며 실행시킬때 그 기대한대로 동작해야 한다. 사용자들은 매뉴얼을 읽지 않을것이기 때문이다. 이 기준으로 내가 경험한 최고의 시스템은 1985년의 최초 매킨토시 컴퓨터다. 매킨토시는 그전까지 소프트웨어가 한번도 못한것을 했다. 그냥 동작했다. (It just worked).

소스코드 역시 자신을 설명해야 한다. 사람들에게 프로그래밍에 대한 딱 한가지 격언만 소개한다면 책 “컴퓨터 프로그램의 구조와 해석”의 첫장에 나오는 이 구절이다.

“프로그램은 기본적으로 사람들이 읽을 수 있도록, 오직 우연히 컴퓨터에 의해 실행되도록 작성해야 한다”

사용자뿐 아니라 소스코드를 읽을 다른 해커들을 향한 동감을 가져야 한다. 사실 당신 자신을 위한 것이다. 많은 해커들은 자신이 짠 프로그램을 6개월 후에 다시 들여다보고는 전혀 감이 안잡히던 경험이 있을 것이다. 많은 이들이 다시는 Perl로 프로그램 안짠다고 맹세한 이유이기도 하다.

어떤이들은 동감할 줄 모르는게 똑똑해서 그렇다고 생각해서, 일부러 더 동감하지 않으려 한다. 하지만 지식과 동감에 꼭 상호연관이 있다고 생각치 않는다. 자연과학과 수학에 뛰어난 사람들은 흔히 사람들을 잘 이해하는데, 자연과학과 수학을 잘 하는 사람들은 보통 똑똑한 이들이다. 무식한 사람들중에 자기 중심적인 사람도 많다. 토크쇼에 전화를 거는 사람들 이야기를 들어보라. 그들은 자기가 무슨 질문을 하는지도 잘 몰라서 사회자가 그들의 질문을 해석해 다시 묻곤 한다.

자 그럼 해킹이 그림, 글쓰기와 같은 것이라면 과연 그런 직업처럼 쿨한 것일까? 당신은 딱 한번 인생을 사는데, 쿨하고 위대한 일에 시간을 보내고 싶을 것이다.

아쉽지만 이 질문에는 답이 어렵다. 멋진 것에는 항상 시간의 차이가 존재한다. 마치 먼 우주속 별이 보내는 빛과 같다. 지금 미술이 사람들 사이에 명망높은 이유는 500년전에 위대한 작품을 만든 사람들 덕분이다. 그 당시에는 지금 우리가 떠받드는 작품들이 대단치 않은 소장품이었다. 그 당시 사람들에게 우르비노의 공작 Federico da Montefeltro이 현 시대 사람들에겐 프란체스카의 그림에 나오는 이상한 코쟁이 인물로만 알려지는게 신기할 것이다.

지금은 해킹이 미술만큼 그렇게 쿨한 것으로 인정받지 못하는게 아쉽지만, 미술 역시 그 영광스런 시대엔 보잘 것 없는 직업으로 취급받았다는 사실을 기억해야한다.

그러나 우리가 확신할 수 있는것은 지금이 해킹의 영광스런 시대라는 사실이다. 대부분 분야에서 가장 훌륭한 작품들은 초기에 만들어졌다. 1430년에서 1500년 사이에 그려진 미술품들은 여전히 최고의 가치를 지닌다. 셰익스피어는 막 사설 극장이 세워지던 시절에 활동했었는데, 그 이후에 모든 극작가들이 그의 그늘 아래에서 작품을 써야만 했다. 알베르트 뒤러는 판화에서, 제인 오스틴은 소설에서 그랬다.

시간이 지나면 지날수록 우리는 같은 패턴을 본다. 새로운 매체가 출현하고 사람들은 그것에 흥분해서 매체의 가능성을 처음 몇 세대동안 모두 탐구해본다. 해킹이 바로 그 시점에 있다.

다빈치는 그의 작품들로 인해 훗날 미술을 쿨한 직업으로 인정받게끔 했지만 그 시대엔 그 영광을 누리지 못했다. 해킹이 얼마나 쿨한 직업으로 훗날 인정받을까의 여부는 지금 우리가 이 매체로 무엇을 만들어낼까에 달려있다.

https://twitter.com/sm_park

역설적으로 들리겠지만 명작은 훌륭하다고 인정받는 그 수준보다 더 뛰어나야 한다. 예를들어 레오나르도 다빈치가 국립 갤러리의 Ginevra de Benci 초상화를 그릴때 그녀의 머리 뒤편으로 향나무 수풀을 그렸다. 거기에서 각각의 잎을 아주 정교하게 그려냈다. 많은 화가들은 그런 수풀을 그저 인물 머리의 테두리 역할을 하는 배경으로 생각했을 것이다. 누구도 그 부분을 그리 자세히는 안볼테니까.

그러나 다빈치는 아니었다. 남들이 그 부분을 얼마나 자세히 볼런지는 그가 그 부분을 그릴때 중요한 고려대상이 아니었다. 그건 마이클 조단의 태도와 같다. 바로 끈질김이다.

부분들이 합해지면 보이지 않던 디테일이 선명히 드러나기 때문에 결국 끈질김이 이긴다. 사람들이 Ginevra de Benci의 초상화를 지나쳐갈때면 미쳐 다빈치라는 작가 이름을 알아채기도 전에 곧바로 그 그림에 빨려들어가곤 한다. 보이지 않던 디테일들이 모두 모여서 놀라운 형상을 만들어내는 것은 마치 가냘픈 목소리로 천명이 함께 부르는 합창과 같다 .

뛰어난 소프트웨어 역시 아름다움에 대한 광적인 집착을 필요로 한다. 당신이 훌륭한 소프트웨어의 안을 들여다 볼때면 사람들이 관심갖지 않을 부분까지도 아름답게 짜여져있는걸 발견할 것이다. 내가 대단한 소프트웨어를 만든다는 뜻은 아니지만, 나는 코드에 대한 집착이 지나쳐서 삶의 다른 부분까지 비슷한 태도로 대한다면 두통으로 인해 약을 달고 살아야 할 수준이다. 띄어쓰기가 엉망인 코드나 이상한 변수 이름을 사용한 코드를 볼때면 머리가 돌아버릴 지경이다.

해커가 단순히 스펙을 코드로 바꾸는 구현만 하는 개발자였다면, 하수구 구멍 파는 사람처럼 이쪽 끝에서 저쪽 끝까지 땅만 파내려갈 것이다. 하지만 해커가 창조하는 사람이라면, 예술가와 같은 해커의 영감(inspiration)까지도 생각해야 한다.

미술처럼 해킹엔 주기가 있다. 어떤 날에는 새로운 프로젝이 너무 흥분돼 하루 16시간씩 일하기도 한다. 또 다른 날에는 아무것도 흥미로워 보이질 않는다.

뛰어난 일을 지속하기 위해서는 이러한 주기를 염두에 두어서 적절하게 대응해야 한다. 매뉴얼 기어 자동차를 운전하다가 언덕을 만나면 클러치를 때때로 떼어서 엔진이 서는것을 피해야 한다. 비슷하게 잠시 물러설줄 알아야 큰 목적을 이루다가 멈추어 버리는 상황을 피할 수 있다. 그림과 해킹에는 너무 거대해 보이는 작업들이 있고 때로는 편안하게 해결할 수 있는 쉬운것들이 있다. 쉬운 일들을 남겨놓아 당신이 힘든 작업들로 중간에 멈추었을때 쉬운 작업으로 시간을 보내는 것도 좋은 방법이다.

해킹에서는 이러한 것들을 “버그”라고 부른다. 나는 디버깅을 좋아한다. 사람들이 생각하는 해킹의 이미지에 가장 걸맞는 단순 작업일 것이다. 당신 앞에는 완전히 잘 정의된 문제가 있고 오로지 해결만 하면 된다. 프로그램이 x의 일을 해야 하는데, 지금 y를 하고 있을 뿐이다. 무엇이 잘못됐을까? 이 문젠 결국 해결할 수 있다는 것을 안다. 이런 디버깅은 화가에게 벽을 칠하는 것과 같은 휴식이다.

미술에서 개인의 일뿐 아니라 함께 일하는 방법도 배운다. 한 사람의 이름만 박물관에 쓰여져 있지만 사실 과거 작품은 여러 사람의 손에 의해 만들어진 것이 많다. 다빈치는 한때 베로치오의 제자로서 “그리스도의 세례”에서 천사중 하나를 그렸다. 그런 식의 공동 작업은 예외가 아니라 룰이었다. 미켈란젤로는 특이하게 시스티나 성당 벽화의 모든 인물들은 자신이 그리겠다고 우기기도 했다.

내가 아는 한 화가들은 일하면서 그림의 같은 부분을 여러명이 함께 그리는 경우가 없다. 일반적으로 거장 화가가 가장 중심인물을 그리고 조수뻘되는 화가들이 배경을 그린다. 하지만 한 화가가 다른 사람의 작업 위에 덧칠하는 경우는 없다.

나는 이것이 소프트웨어의 협업에 있어 적합한 모델이라고 생각한다. 코드의 한 부분을 세네명의 사람이 같이 해킹하다보면 아무도 코드를 소유하지 않고 결국엔 공동 화장실처럼 되어 버린다. 빛바래고 버려진 것 같으면서 불쾌한 냄새만 쌓여간다. 프로젝을 같이 할땐 프로젝을 정밀하게 모듈로 나누어 해커들에게 모듈을 소유하게끔 해야한다. 모듈간의 인터페이스는 가능하다면 프로그래밍 언어 수준으로 정교하게 디자인하는 것이 필요하다.

https://twitter.com/sm_park

해커는 과학자라기 보다는 maker이기 때문에, 영감을 얻을 수 있는 분야는 과학보다는 다른 종류의 maker일 것이다. 그 관점에서 미술보다 해킹에 대해 더 잘 드러낼 분야가 또 있을까?

우리가 미술에서 배울 수 있는것 아니 최소한 확인할 수 있는 것은 어떻게 해킹을 처음 배우는가 하는 점이다. 당신은 그림을 직접 그려가며 미술을 배운다. 딩동뎅! 해킹 역시 그렇다. 대부분 해커들은 대학에서 프로그래밍 과목을 수강한후 해킹을 배우지 않는다. 13살때쯤 스스로 프로그램을 만들어보며 해킹을 배운다. 사실 대학 수업역시 진짜 만들어보면서 배우기 마련이다.

화가들은 자신만의 독특한 흔적을 남기기 때문에, 그림을 그려나가며 배웠다는 사실을 알수 있다. 어떤 화가의 작품을 시간순으로 나열해 보면 각각의 작품들이 그 전의 그림들 토대 위에서 만들어진것을 볼 수 있다. 회화에서 특별히 뛰어나게 잘 표현된 부분이 있다면 그 표현의 버전 1을 그 전의 그림들에서 발견할 수 있을 것이다.

대부분의 maker들이 이런 방식으로 일한다. 작가와 건축가 역시 마찬가지다. 아마도 해커는 화가와 비슷한 방식으로, 한가지 프로젝트에 몇년간 계속해서 일하기 보다는 자주 처음부터 프로젝을 새로 시작하면서 기존의 아이디어를 통합해서 발전시켜나가는 것이 좋을 것이다.

해커들은 직접 코딩하면서 배운다는 사실이 바로 해킹과 과학이 별개의 것이라는 증명이된다. 과학자들은 과학을 랩과 문제풀이를 통해 배운다. 과학자들은 처음 배울때 완벽한 것에서 시작한다. 이미 잘 증명된 문제를 실험으로 재현하며 배우고 훗날 자신의 이론을 세우고 실험하는 단계에 이른다. 반면 해커는 처음 시작부터 자신의 일을 한다. 그냥 아직 아주 어설플 뿐이다. 해커들은 처음에 독창적인 것을 하고, 시간이 갈수록 더 나아지는 반면 과학자들은 처음에 완전한 것에서 시작하고 시간이 갈수록 독창성을 가미한다.

Maker들이 배우는 또 다른 방법은 예제를 통해서이다. 화가에게 있어 미술관은 기교를 참조하는 라이브러리다. 수백년간 지속되온 전통적인 미술 교습법은 거장의 작품들을 모방하는 것인데, 그 이유는 모방을 통해서 작품이 만들어진 방식을 유심히 관찰하게 되기 때문이다.

작가역시 그렇다. 벤자민 프랭클린은 Addison과 Steele이 쓴 수필들을 요약해가면서 글쓰는 법을 배웠다. Raymond Chandler역시 같은 방식으로 탐정 소설을 배웠다.

해커 역시 마찬가지로 훌륭한 프로그램을 참조하면서 프로그래밍을 배운다. 단순히 프로그램의 돌아가는 것을 보는것 뿐 아니라 소스 코드를 참조하면서 말이다. 오픈소스 운동의 덜 알려진 혜택중 하나는 프로그램을 배우기 쉽게 한다는 점이다. 내가 처음 프로그램을 배울때는 대부분 책에 소개된 예제를 통해서였다. 그 당시 예제중 가장 큰 소스 코드는 Unix였는데, 그땐 오픈소스가 아니였다. 소스코드를 읽은 대부분 사람들은 John Lions의 책을 복사한 해적판을 읽었는데, 1977년에 쓰여진 그 책은 1996년까지 출판이 금지되었었다.

미술을 통해 얻을 수 있는 또 다른 예제는 점진적인 개선을 통해 작품을 창조해가는 점이다. 그림은 대부분 스케치에서 시작한다. 구체적인 것은 점차 채워져 나간다. 하지만 그 과정이 단지 채워나가는 것만이 아니다. 때때로 처음 계획은 실수로 판가름난다. xray를 통해 보면 수도 없이 많은 그림들이 테두리가 옮겨져있거나 표면 형태들이 새로 적용된 것을 볼 수 있다.

그것이 바로 미술에서 배울 수 있는 점이다. 해킹또한 이렇게 이루어져야 한다고 생각한다. 프로그램의 스펙이 완벽하다고 기대하는건 비현실적이다. 처음부터 그 사실을 인정하고, 프로그램을 만들며 스펙을 고쳐나가는 것이 훨씬 낫다.

(큰 회사의 구조는 이것이 힘들게 되어있는데, 이것이 스타트업의 잇점중 하나다.)

아마 지금쯤 대부분 사람들은 미성숙한 최적화 (premature optimization)의 위험에 대해 알 것이다. 내 생각에 우리는 미성숙한 디자인 (프로그램이 해야하는 일을 너무 일찍 결정하는 것)에 대해서 역시 걱정해야 한다.

올바른 툴은 이런 위험을 피하는데 도움을 줄 수 있다. 좋은 프로그래밍 언어는 유화가 그러하듯이 해커가 마음을 쉽게 바꿀수 있게끔 도와야 한다. 그점에서 동적 타이핑이 승자라고 할 수 있는데 처음부터 특정한 데이터 표현에 묶이지 않기 때문이다. 하지만 그러한 유연성의 핵심은 언어를 아주 추상적으로 만드는 것이라고 생각한다. 바꾸기 가장 쉬운 프로그램은 아주 짧은 것이다 (역: 언어가 추상적일수록 소스코드가 짧다).

https://twitter.com/sm_park

대학교와 연구소가 해커가 원하는 일들을 못하게 한다면, 아마도 그들이 있을곳은 일반 기업일 것이다. 그런데 불행히도 회사들 역시 해커가 원하는 것들을 하게끔 허락치 않는다. 학교와 연구소가 해커를 과학자가 되도록 강요한다면, 회사들은 그들을 엔지니어로 남도록 강요한다.

나는 이 사실을 최근에서야 알았다. 야후!가 내가 세운 회사 Viaweb을 사고 나서, 내게 무엇을 하기 원하는지 물었다. 나는 비지니스쪽엔 관심이 없었으니까 그저 해킹을 계속하고 싶다고 이야기 했다. 내가 야후에서 일하기 시작한 후에야 그들에게 해킹이 의미하는건 그저 소프트웨어를 구현하는 것이지 디자인하는 것은 아니라는 걸 알았다. 프로그래머는 그저 프로덕트 메니저의 머릿속 비전을 구현하는 기술자일 뿐이다.

그런데 이게 큰 회사들의 기본 구조인 것 같다. 큰 회사들이 이런식으로 운영하는 이유는 예측가능한 결과를 얻고 싶어하기 때문이다. 작은 퍼센트의 해커만이 실제 소프트웨어를 디자인할 수 있는데 회사를 운영하는 사람들은 그들을 전면에 내세우기가 어렵다. 그래서 소프트웨어의 미래를 뛰어난 해커 한 사람에게 맏기기 보다는 대부분 회사는 소프트웨어를 위원회(committee)에서 디자인하고 해커들은 단순히 디자인을 구현하게끔 한다.

여러분이 혹시 언젠가 큰 돈을 벌고 싶다면 이 사실을 꼭 명심해라. 왜냐하면 이것이 스타트업이 이기는 이유이기 때문이다. 큰 회사들은 재앙을 피하기 위해 소프트웨어 결과물의 표준편차를 줄이는 것에만 골몰한다. 하지만 표준편차를 줄이다보면 저점과 함께 고점도 모두 지워나가기 마련이다. 큰 회사들에겐 이런게 큰 문제가 안된다. 그들은 훌륭한 제품을 만들어서 마켓에서 이기는게 아니라 다른 큰 회사보다 조금 더 낫기 때문이다.

그래서 프로덕트 메니저가 소프트웨어를 디자인하는 그런 회사가 여러분의 제품과 디자인 싸움에 뛰어들게끔 한다면, 그들은 절대 여러분을 쫓아오지 못할 것이다. 하지만 그런 기회를 포착하는 것은 쉽지 않다. 큰 회사를 디자인 싸움에 뛰어들게 하는 것은 성벽 안쪽의 적과 싸우는 것만큼 어렵다. 예를들어, 어쩌면 MS 워드보다 더 나은 제품을 만드는건 쉬운 일일지 모른다. 하지만 마이크로소프트는 운영체제 독점이라는 성벽안에서 싸우려 들것이고, 아마도 여러분의 제품이 존재한다는 사실자체도 모를것이다. (역: 큰 기업은 제품보다는 브랜드로 스타트업을 제압한다).

디자인 싸움을 펼쳐야 하는 곳은 그래서 아직 아무도 성벽을 세우지 못한 새로운 마켓이어야 한다. 그곳만이 용감하게 디자인에 접근하면서 구현과 디자인을 함께하는 당신이 크게 이길 수 있는 싸움터다. 마이크로소프트는 시작할때 그랬다. 애플과 HP역시 마찬가지다. 아마 모든 성공한 스타트업이 그랬을 것이다.

그래서 훌륭한 소프트웨어를 만드는 방법은 자신의 스타트업을 시작하는 것이다. 그런데 여기엔 두가지 문제가 있다. 첫째로 스타트업은 소프트웨어 만드는 것 말고도 훨씬 많은 일들을 해결해야 한다. 나는 Viaweb에서 시간의 25% 정도만 코딩하는데 사용해도 그날은 운 좋다고 느꼈었다. 나머지 75%는 지루하거나 다루기 겁나는 일들에 허비해야 했다. 어느날엔가 나는 이사회 회의 중에 나와 충치치료를 할 일이 있었다. 그날 치과 의자에 누워 드릴을 기다리니 마치 휴가지에 와 있는 것 같은 착각이 들 정도였다.

또 다른 스타트업의 문제는 돈벌이가 되는 소프트웨어와 만들기 재미있는 소프트웨어가 그다지 겹치지 않는다는 사실이다. 프로그램 언어는 만드는것이 재미있고 마이크로소프트의 첫 제품이 사실 그거였는데, 지금 시대엔 아무도 프로그램 언어를 돈주고 사지 않는다. 돈을 벌고 싶다면 아무도 공짜로는 해결해주지 않는 그런 지저분한 문제를 파고들어야 한다.

모든 maker들이 이 문제를 겪는다. 가격은 수요와 공급에 의해 결정되는데, 작업이 재미있는 그런 작품들보다는 시시하지만 고객의 개별적인 문제를 해결하는 그런 작품들에 수요가 따르기 마련이다. 언더에서 연극하는 것은 무역박람회 부쓰에서 고릴라 복장하고 있는 것보다 돈을 받지 못한다. 소설보다는 쓰레기통으로 들어갈 광고지 문구 작성하는게 밥벌이에 낫다. 프로그래밍 언어를 해킹하는 것보다는 큰 회사의 옛날 데이터베이스를 웹서버에 연결시켜주는 일이 돈이 된다.

소프트웨어의 경우에 이 문제에 대한 해결은 거의 모든 maker들에게 잘 알려진 개념이다. 그것은 “낮 일 (day job)”을 갖는 것이다. 이 문구는 밤에 직업을 위해 무대를 뛰는 음악가들에게 처음 붙여졌다. 좀 더 넓게 적용하자면, 당신이 돈을 위해 하는 한가지 일과, 사랑해서 하는 다른 한가지 일이 있어야 한다는 뜻이다.

거의 모든 maker들의 커리어 초반기엔 낮 일이 있다. 화가와 작가들에겐 이 용어가 씁쓸한 현실이다. 당신이 운좋다면 당신의 진짜 일과 관련된 낮 일을 얻을 것이다. 음악가들은 종종 레코드 가게에서 일하곤 한다. 프로그래밍 언어나 운영체제를 하는 해커들은 종종 같은 언어나 os를 사용하는 낮 일을 하곤 한다.

해커는 낮 일을 하면서 아름다운 소프트웨어를 만들어야 한다는게 사실 새로운 개념은 아니다. 오픈소스 해커들이 오랫동안 지속한 삶의 방식이다. 이야기 하려고 하는것은, 다른 직업의 maker들에게서 확인되었듯이 오픈소스 방식이 스타트업을 하고자 하는 해커들의 올바른 모델이라는 점이다.

종종 어떤 회사들은 직원들이 오픈소스 프로젝에 참여하는 걸 꺼리는데, 나는 그 사실이 놀랍다. Viaweb에서는 오픈소스 프로젝 경험이 없는 직원을 채용하는걸 꺼렸다. 우리는 인터뷰하며 사람들이 여가시간에 무슨 소프트웨어를 만들었는가를 가장 관심있어했다. 어떤 일을 사랑하지 않고는 정말 잘할 수가 없다. 해킹을 사랑한다면 당신은 분명히 자신의 프로젝을 가지고 일했을 것이다.

https://twitter.com/sm_park

http://paulgraham.com/hp.html

지난번에 올린것과 같이 폴 그레이엄의 명 에세이 “해커와 화가”를 번역해서 올립니다. 최근에 읽은 글중 가장 좋은 것이기 때문에 번역했습니다. 글이 길어서 2-3회에 걸쳐서 올려야 할 것 같습니다.

—————————————————–

해커와 화가

2003년 5월

나는 컴퓨터 사이언스로 대학원을 마치자마자 미대에 진학해 회화를 공부했다. 주변의 많은 사람들이 컴퓨터를 좋아하는 사람이 그림에도 관심이 있다는 사실에 놀랐다. 아마도 해킹과 미술이 완전히 다른 종류의 일이라고 생각하기 때문인듯 싶다. 해킹이 차갑고, 정밀하고 기술적인 일이라면 그림은 어떤 현상, 사물에 대해 흥분된 감정을 주체못해 표현하는 예술이라고 생각하기 때문이다.

이 두가지 이미지는 사실은 모두 틀리다. 해킹과 미술은 많은 공통점이 있다. 사실 내가 경험했던 모든 사람들 중 그 두가지 직업의 사람들이 가장 서로 닮았다.

해커와 화가의 공통점은 둘 다 maker(만들어내는 사람들)이라는 점이다. 작곡가, 건축가, 작가처럼 해커와 화가는 둘 다 작품을 만들어낸다. 엄밀히 따지면 두 직업의 사람은 연구를 한다고 하긴 어렵다. 하지만 훌륭한 작품을 만들어 내는 과정에서 종종 새로운 기법(technique)을 발견해내는 경우가 있다.

(역: maker 에 맞는 적절한 한국어 단어가 없어 이후 maker를 그대로 사용합니다).

나는 컴퓨터 사이언스라는 용어를 좋아한적이 없다 (역: 미국대학교에서는 컴퓨터전공을 컴퓨터사이언스로 통칭). 가장 큰 이유는 그런 분야가 사실 존재하지 않기 때문이다. 컴퓨터 사이언스는 여러가지 분야가 한 가방안에 역사적인 우연에 의해 뭉뚱그레진것과 같은 학문이다. 이를테면 유고슬라비아 같은 나라와 같다. 한쪽편엔 실제론 수학자면서 자신의 일을 컴퓨터 사이언스라 부르며 국방부의 연구비를 따내는 사람들이 있다. 중간엔 컴퓨터의 자연스런 발전과정에서 실험적 연구를하는 사람들이 있는데 예를들면 네트웍의 라우팅 알고리즘을 하는 사람들이 그렇다. 그리고 다른 극단에는 그저 재미있는 소프트웨어를 만들며, 건축가에게 콘크리트, 화가에겐 물감처럼 컴퓨터를 단지 자신의 생각을 표현하는 수단으로 이용하는 해커 그룹이 있다. 이런 조합은 마치 수학자, 물리학자, 건축가를 모두 한 전공안에 몰아넣은 것과 같다.

종종 해커들이 하는 일을 소프트웨어 공학 이라고 부르는데 이것은 용어의 잘못된 사용일 뿐이다. 뛰어난 소프트웨어 디자이너는 엔지니어보다는 건축가(architect)에 가깝다. 건축과 엔지니어링 사이의 경계가 뚜렷한것은 아니지만 분명히 둘은 구분된다. 무엇을 하느냐와 어떻게 하느냐의 차이라고 생각할 수 있는데, 아키텍트가 무엇을 하느냐를 결정한다면 엔지니어는 어떻게 하느냐를 찾아낸다.

이 “무엇”과 “어떻게”의 관계가 완전히 동떨어진것은 아니다. 당신이 어떻게 만드는지도 모르면서 무언가를 하려고들면 문제만 일으킬게 뻔하다. 하지만 해킹은 그저 스펙을 어떻게 구현할까 생각하는 것 이상의 행위다. 뛰어난 해킹은 스펙 자체를 만들어내고 그 자신이 스펙을 구현할 최적의 기술 또한 선보인다.

어쩌면 유고슬라비아가 그랬듯이 컴퓨터 사이언스는 여러개의 분야로 분리될지도 모르겠다. 아마 그건 좋은 일일 것이다. 특히 그게 나의 “조국” 해킹의 독립을 의미한다면 말이다. 이러한 여러 분야를 한 전공안에 몰아넣은것이 관리의 측면에서 편할런지 몰라도 지적인 면에선 혼란만 일으킨다. 그게 내가 컴퓨터 사이언스라는 용어를 싫어하는 또 다른 이유다. 논란의 여지가 있지만, 중간영역에 있는 사람들 (역: 예를들어 네트웍 알고리즘)은 어떤 실험적 과학을 하는 셈이다. 하지만 양쪽 끝편에 있는 사람들, 즉 수학자와 해커들은 사실 과학을 한다고 말하긴 어렵다.

수학자 그룹은 이런 용어의 문제에 그리 신경쓰지 않는다. 그들은 옆 건물 수학과 사람들처럼 그저 열심히 정리(theorem)를 증명할 뿐이고 아마도 자신들의 건물에붙은 컴퓨터 사이언스 간판을 언젠가부터 인식도 못했을 것이다. 하지만 해커들에게 컴퓨터 사이언스라는 딱지는 문제가 된다. 자신들이 일하는 것을 사이언스라고 부르기 시작하면서 스스로 과학자같은 일을 해야한다고 느끼기 시작한다. 그래서 자신들이 정말 원하는 것, 즉 아름다운 소프트웨어를 디자인하지 못하고 학교와 연구소에서 해커들은 논문 쓰는것을 강요받는 것이다.

좋게 보자면 논문은 그저 형식일 뿐이다. 해커는 쿨한 소프트웨어를 만들고 그것에 대해 논문을 제출할 뿐이다. 논문은 그저 소프트웨어에 대한 소개 그 정도로 한정지을수 있다. 하지만 잘못된 용어는 빈번히 문제를 일으킨다. 아름다운 것을 만드는 자신의 본래 꿈에서 빗겨나가, 추하지만 연구 논문의 주제로 쓰기에 적합한 것들을 만들어내는게 참 쉬운 선택이기 때문이다.

안타깝지만 아름다운 것들은 논문으로서 최고의 주제가 되지는 못한다. 연구의 제1 기준은 독창성이다. 박사 논문을 써본 사람은 알겠지만 누구도 개척하지 않은 분야를 탐험하는 간단한 방법이 있다. 그건 아무도 원하지 않는 곳으로 가는 것이다 (역: 필요없는 연구를 하는 것이다). 두번째로 연구는 무게가 있어야 한다. 다루기 힘든 분야를 하면 많은 논문을 배출하는데 그 이유는 목표를 이루기 위해 많은 벽들을 넘어서야 하기 때문이다. 그래서 풍성한 문제들을 배출하는 최고의 방법은 잘못된 가정에서 시작하는 것이다 (역: 즉 불가능한 목표). 대부분의 인공지능 연구가 그 예다. 당신이 지식이란 논리의 나열로 표현할 수 있고, 나열된 논리가 추상적인 개념마저 표현할 수 있다고 가정하기 시작하면 당신은 풍성한 논문들을 여기에서 만들어낼 수 있다. Ricky Ricardo가 이렇게 이야기 했듯 말이다: “루시, 그거 설명할 게 아주 많아!”

아름다운 것들은 종종 이미 존재하는 것들을 미묘하게 조작하거나 이미 알려진 아이디어를 작게 변형해 조합하면서 만들어진다. 이런 종류의 일은 연구 논문에서 다루기가 어렵다.

그런데 왜 학교와 연구소는 해커를 논문의 수로 평가할까? 이유는 간단한데, 학생의 학습능력을 표준화된 시험으로 평가하는 것이나 프로그래머의 생산성을 코드의 라인수로 측정하는 이유와 같다. 골치 썩힐 필요없이 이렇게 단순한 잣대로 평가하는 것이 달콤한 유혹이기 때문이다.

해커가 진짜로 하려는 것, 즉 아름다운 소프트웨어를 평가하는 것은 훨씬 어렵다. 당신이 훌륭한 디자인을 판별할만한 눈이 있어야 한다. 자신이 그럴만한 안목이 있다고 자신만만해 하는 사람들은, 사실은 그 반대의 소질을 갖고 있는 경우가 많다.

유일한 평가의 기준은 시간이다. 시간이 지나면서 아름다운 것들은 번성하고, 추한 것들은 버려진다. 그런데 어떤 경우엔 사람의 수명보다 더 긴 시간을 요할때도 있다. 사무엘 존슨은 작가의 명성을 수렴하는데는 100년이 걸린다고 이야기 했다. 작가의 영향력있는 친구들과 그 추종자들이 모두 죽고난 후에야 진정한 명성을 이야기할수 있다고 했다.

그래서 내 생각에 해커들은 명성을 그저 행운의 결과라고 치부하는 그런 마음가짐을 가져야 한다. 그런 면에서 다른 분야의 maker들과 다르지 않다. 사실, 비교적 다른 분야에 비해 좀 나은편이다. 해킹에 비해 미술은 훨씬 더 유행에 민감하다.

다른 사람들이 당신의 일을 오해하는 것보다 더 나쁜것이 있다. 그 위험은 당신이 자기의 일을 스스로 오해하는 것이다. 우리는 가까운 곳에서 아이디어를 찾기 마련이다. 그런데 당신이 컴퓨터 사이언스과에 있다면, 자연스레 해킹이란 결국 컴퓨터 사이언스 이론을 응용한 것일 뿐이라는 그런 생각에 빠지게 된다. 나는 대학원에 있으면서 머릿속에 늘 불편한 생각을 가지고 있었다. ‘컴퓨터 이론을 좀 더 많이 알아야 하는데…’ 그런데도 시험을 보면 3주안에 다 까먹어버리는 그 사실에 대한 불안함 말이다.

지금에서야 깨달았지만 그건 실수였다. 화가가 물감의 화학 성분을 이해하는 것 그 수준으로만 이론을 이해해도 괜찮다. 시간과 공간의 복잡도 (BigO) 정도와 튜링 테스트정도만 이해하면 된다. 아마 상태기계(state machine)을 이해하면 Parser나 정규식 라이브러리를 만들때 도움이 될 것이다. 화가는 사실 물감의 화학성분보다 기억해야 할 더 많은 것들이 있다.

한가지 발견한 사실은 아이디어를 찾는 가장 좋은 곳은 이름에 컴퓨터가 붙지 않았지만 maker들로 구성된 분야라는 점이다. 미술은 그래서 내게 컴퓨터 이론보다 훨씬 많은 아이디어를 제공했다.

예를들어 학부 시절에는 컴퓨터 근처에 가지 않고도 프로그램을 완벽히 종이에 써 낼수 있어야 한다고 배웠다. 하지만 나는 이런식으로 코딩하지 않았다. 나는 컴퓨터앞에 앉아 프로그래밍하는게 종이에 하는것보다 더 좋았다. 끈기있게 내가 맞다고 믿으며 완벽한 코드를 종이에 써내려가는 것보다는, 처음에는 완전히 망가진 형태의 코드를 모니터에 타이핑하고 조금씩 모양을 만들어나가는게 더 좋았다. 학교에선 디버깅이 타이포나 부주의한 실수를 잡아내는 마지막 테스트라고 배웠다. 하지만 내게 코딩은 그저 디버깅의 연속이었을 뿐이다.

이런식으로 코딩하면서, 초등학교에서 연필을 이상하게 잡는다고 지적받으며 느꼈던 불편한 감정을 계속 느꼈다. 그 당시 화가, 건축가의 작업 방법을 알았더라면 이런 식의 코딩에 이름이 있다는걸 깨달았을 것이다: 그건 “스케치”다. 내가 분명히 말할 수 있는건 대학들에서 가르치는 프로그래밍 방법은 모두 틀렸다는 것이다. 프로그램은 만들어가면서 배우는 것이다. 작가, 화가, 건축가들이 모두 그러하듯이.

이 사실을 깨달으면 소프트웨어 디자인에 다른 관점을 갖게 된다. 프로그래밍 언어에있어 가장 중요한 것은 변화를 줄 수 있어야 한다는 사실이다. 프로그래밍 언어는 프로그램을 생각하는 과정을 위한 것이지, 이미 당신 머릿속에 그려진 지도를 표현하기 위한 것이 아니다. 즉, 볼펜이 아니라 연필이어야 한다. 정적 타입 (역: static type-c, java 언어)은 대학들에서 가르치는 방법으로 코딩한다면 괜찮은 방법이다. 하지만 내가 아는 한 해커들은 그런식으로 코딩하지 않는다. 우리에게 필요한 언어는 대충 끄적여보면서 고쳐나갈 수 있는 것이다. 조신하게 찻잔(type)을 무릎위에 올려놓고 먼친척 아줌마 “컴파일러”와 공손하게 대화하는 그런식의 프로그램 언어는 틀렸다.

(역: Graham은 2003년에 이 에세이를 썼는데 그 후 지금껏 10년간 해커, 스타트업 세계에서 가장 각광받은 언어는 Python, Ruby, Javascript와 같은 동적 타이핑 언어다. 그레엄이 정확하게 문제를 짚었다는걸 알 수 있다.)

지금까지 정적 타이핑에 대해 이야기 했지만, 우리 자신을 maker라고 생각할때 과학이 주는 또 다른 고통으로부터 자유로워진다. 그것은 수학에 대한 질투다. 과학계의 모든 사람들이 비밀스럽게 믿는 한가지 사실은 수학자가 자신보다 더 똑똑하다는 것이다. 수학자 자신도 그렇게 믿는다고 생각한다. 그래서 결과적으로 과학자들은 자신의 일을 수학처럼 보이게 하길 좋아한다. 물리학과 같은 분야에선 그리 문제가 안되겠지만 자연과학에서 멀어질 수록 이게 큰 문제가 된다.

한 페이지에 가득 채워진 수학 공식은 아주 인상적이다 (팁: 더 인상적으로 보이려면 그리스 기호를 쓰라). 그래서 여러가지 문제중 수학 공식으로 표현 할 수 있는 문제를 다루려는 큰 유혹이 생긴다. 더 중요한 문제들을 앞에 두고도 말이다.

해커가 스스로를 작가나 화가와 동일시했다면 그런 유혹은 받지 않았을 것이다. 작가와 화가는 수학에 질투하지 않는다. 완전히 다른 종류의 일을 하고 있다고 느낄 뿐이다. 해커도 마찬가지여야한다.

— 다음 편에 계속 —

https://twitter.com/sm_park