최근들어 나 자신을 돌아보며 발견한 사실은 더이상 긴 글을 읽지 않는다는 것이다.

지금은 하루중 많은 시간을 트위터의 짧은 글, 페이스북의 사진들, 동영상을 즐기는데 소비한다. 물론 짧게 짧게 전파되는 트위터는 정보를 발견(discovery)하는데 최고의 툴이다. 그러나 그 툴 자체에 중독돼 링크의 목적지가 담고있는 유용한 정보들, 어쩌면 내 삶의 방향을 바꿀지도 모를 그런 내용들은 놓치고 있는지 모른다.

이제 페이스북에 긴 글을 올려서는 반응이 별로 없다는것도 알았다. 나 역시 누군지도 모르는 <페친>이 like한 유머스런 동영상에 손이가지 내 지인이 몇시간동안 생각하고 올렸을 긴 글을 파싱할 엄두는 나지 않는다. 짧은 글, 동영상은 탄산음료같은 짜릿한 맛은 있을지 몰라도 우리의 사고와 행동을 변화시키는 그런 실제적인 영양가치는 없다.

이번에 번역하는 Paul Graham의 How You Know를 읽고나서 이 생각이 더 분명해졌다. 내가 읽는 글들은 비록 얼마후엔 그 내용이 잊혀질지라도 그 글이 남겨놓은 <세상을 바라보는 모델>은 계속해서 나의 행동과 가치관을 결정할 것이다. 140자 트윗들로만 내 머릿속 모델이 채워진다면 10년후에 나는 얼마나 정신없는 사람이 되어있을까?

How You Know 

http://paulgraham.com/know.html

나는 Villehardouin의 연대기를 그동안 두세번은 더 읽은것 같다. 그런데 그 책에서 읽었던 내용을 기억해서 요약하라면 한 페이지를 간신히 채울수 있을까싶다. 내 책장에 꽂혀있는 몇백권의 책들에 시선이 옮아가면 덜컥 불안한 마음이든다. 이렇게 많은 책을 읽고도 기억을 다 못한다면 나는 왜 그리 시간을 낭비했던 것일까?

몇달전에 Constance Reid가 쓴 힐버트의 전기를 읽다가 이렇게 불안한 마음에 답이 될수있는 한 구절을 찾았다. 거기엔 이렇게 적혀있다:

힐버트는 수학강의들이 사실들만 나열하지, 학생들이 문제를 스스로 정의하고 해결하는 훈련이 없는점에 질색했다. 힐버트는 학생들에게 문제를 잘 정의하는것이 이미 절반의 해답이다라고 이야기하곤했다.

이 말은 나 역시 그동안 중요하다고 느꼈던 부분인데 힐버트가 그렇게 이야기했다는걸 읽으니 내 생각에 더 확신이 생겼다.

그런데 난 처음에 어떻게 그런 생각(문제가 절반의 답이다)을 갖게된 걸까? 내 자신의 경험에 더해 그동안 읽었던 글들을 통해서일것이다. 그런데 지금은 그런 글을 읽었던 바로 그 순간은 전혀 기억에 없다. 힐버트가 이렇게 얘기했다는 구절도 결국엔 잊고말것이다. 그러나 힐버트의 예화는 <그 생각이 맞다>는 내 믿음을 증가시켰고, 후에 힐버트의 말은 잊더라도 그 확인된 믿음은 여전히 내 안에 남아있을 것이다.

읽기와 경험은 우리가 세상을 바라보는 모델을 훈련시킨다. 읽었던 바로 그 순간, 정확한 내용은 잊을지라도 읽기가 우리의 모델링에 남겨놓은 영향은 여전히 지속된다. 그래서 마치 우리의 마음은 소스코드는 잃어버렸지만 컴파일된 프로그램과 같다. 우린 마음이 동작하지만 왜 그렇게 움직이는지는 모른다.

Villehardouin 연대기를 읽고나서 내 마음속에 남겨지는것은 정확한 내용이 아니라 십자군, 베니스, 중세문화, 포위전쟁등에 대한 내 마음의 모델이다. 내가 아주 집중해서 읽지 않더라도 책이 내게 끼치는 영향이 결코 작지 않다는점은 분명하다.

나 뿐 아니라 많은 사람들이 읽은것들을 너무 쉽게 잊어버린다고 걱정한다. 그런데 읽기가 실제로 이렇게 우리 생각에 중요한 영향을 미친다는걸 발견하면 모두 나처럼 놀랄것이다.

그리고 때로는 잊는다는것이 어떤면에서 다른 중요한 작용을 한다는것도 알게된다.

예를들어 어떤 경험을 하거나 어떤 책을 읽는다면 그 경험은 바로 그 순간의 두뇌 상태에 따라 컴파일되어 기억에 남는다. 그렇다면 같은 책을 다른 시점에 읽으면 그 책은 다르게 컴파일될것이다. 즉 다시 말해서 좋은 책들은 여러번 읽는것이 가치가 있다는 뜻이다. 그동안 책을 다시 읽을때마다 사실 기분이 좋지는 않았다. 마치 나무를 잘못 잘라서 다시 작업해야 하는 목수의 마음이랄까… 그런데 읽을때마다 다르게 컴파일된다면 어쩌면 <이미 읽었는데>라는건 맞지않는 표현일지도 모른다.

좀더 나아가서 이게 꼭 책에만 국한된게 아닐지도 모른다. 기술이 발달할수록 우리가 가지고있는 과거의 경험을 다시 재생할수 있게될 것이다. 오늘날엔 사람들이 즐기기 위해서, 즉 여행 사진을 다시 본다든지, 아니면 두뇌의 버그를 고치기 위해서 (Stephen Fry가 노래를 못하게 만들었던 어렸을적 트라우마를 기억해낸것처럼) 예전의 경험을 다시 들추어본다. 그러나 경험을 기록하고 다시 재생하는 기술이 발달하면 사람들은 마치 읽은 책을 다시 읽는것처럼 예전의 기억들을 다시 현실에서 재생하고 그것들에서 다시 배우게 될런지도 모른다.

어쩌면 우리는 단순히 기억을 재생하는것뿐 아니라 기억을 다시 정렬하고 고칠수있게 될런지도 모르겠다. 미래엔 그럼 사람들이 세상을 바라보는 모델 자체도 바꿀수 있게될것이다.

https://twitter.com/sm_park

오랜만에 폴 그레이엄의 짧은 에세이를 읽고 동감이 되어서 번역해 봅니다.
적성, 진로에 대해 고민하는 사람들에게 좋은 내용이라고 생각합니다.
원글: http://paulgraham.com/work.html
————————————————————————–

나의 아버지는 수학자였다. 내가 어린시절 내내 아버지는 Westinghouse사에서 핵융합 모델링을했다.

아버지는 어릴적부터 무엇을 하고싶은지 알았던 운좋은 사람중 하나였다. 아버지는 어린 시절을 이야기할때마다 “12살때쯤 수학에 관심이 생기던 시절”이 가장 중요한 터닝포인트였다고 한다. 아버지는 영국령 웨일즈 지방의 Pwllheli라는 작은 시골에서 자랐다. 우리가 구글 스트리트뷰를 사용해 아버지의 어린 시절 시골길을 다시 찾아봤을때 그는 시골에서 자란게 행복했다고 회상했다.

“15살쯤 되면 시골이 지겹지 않았어요?” 내가 물었다.

“아니” 아버지가 말했다. “그때쯤에 나는 수학에 푹 빠져있었거든.”

다른날엔 아버지에게 수학 문제를 푸는 것이 얼마나 즐거웠는지를 들었다. 내게는 수학책의 챕터 마지막에 있는 문제리스트 (exercise)는 항상 “일”일 뿐이거나 좀 더 좋게 말해도 챕터에서 배운것을 다시 복습하는 절차일 뿐이었다. 하지만 아버지에겐 그 문제들이 일종의 보상(reward)이었다. 챕터의 내용들은 그저 문제를 푸는데 도움을 조금 주는것들 뿐이다. 아버지는 수학책을 받자마자 챕터 마지막의 모든 문제들을 다 풀었고 책의 진도를 조금씩 나가야 했던 수학 선생님의 눈총을 받기도 했다.

소수의 사람들만이 아버지처럼 일찌감치 자신이 무엇을 하고 싶어하는지 알게된다. 하지만 아버지와의 대화에서 자신의 적성찾는 한가지 알고리즘을 떠올렸다. 다른 사람들에게 일처럼 보이는 것이 당신에게는 일이 아니라면 그것이 당신의 적성이다. 예를들어 나를 포함해 많은 프로그래머들이 (투덜대면서도) 사실은 디버깅을 좋아한다. 어떤 사람들은 디버깅을 스스로 찾아하는데 그게 사실 자원해서 할만큼 그렇게 즐거운 성격의 일은 아니다. 그렇지만 어떤 사람들은 여드름 짜내며 희열을 느끼는것처럼 디버깅을 좋아한다. 그런데 프로그래밍에 디버깅이 얼마나 중요한 역할을 하는지를 따져보면 프로그래밍을 좋아하려면 디버깅 역시 좋아해야만한다.

당신의 취향이 다른 사람에게 이상하게 느껴질수록 그 취향이 당신이 계속 해나가야할 적성일 가능성이 높다. 나는 대학교때 친구들 대신해서 수업 논문들을 써주곤했다. 내가 듣지도 않는 수업의 논문을 쓰는게 꽤 재미있는 일이었다. 게다가 친구들 역시 아주 좋아했고…

내게는 그렇게 즐거웠던 일이 다른 사람에겐 고통스러울수 있다는게 흥미로웠지만 이러한 상호간 인식 차이가 무슨 의미인지는 그당시에 잘 몰랐다. 누군가에겐 자신이 어떤 적성이 있는지를 찾고 결정하는것이 이렇게 힘든 일이란걸 알지 못했다. 미스테리 소설의 탐정이 사건을 해결해가는 것처럼 그런 미묘한 단서들을 통해서만 한 사람의 적성을 찾을수 있다는걸 지금은 안다. 그래서 스스로 이 질문을 던져보는것이 많은 이들에게 도움이 될 것이다: “다른 사람들이 일처럼 느끼지만 당신에게는 일이 아니었던 (즐거움이었던)것은 무엇이었는가?”

————————————————————————-

역자: 초등학교 MS-DOS 시절엔 PC게임 하나를 돌리는데 많은 해킹이 필요했다. 게임 디스켓을 친구들에게서 빌릴때면 공책 한장을 부욱 찢어 게임을 실행하기 위한 도스 커맨드를 빽빽하게 함께 적어가야했다. 하지만 커맨드를 따라해도 안될때가 많아 다음날 다시 다른 커맨드를 적어와실행하고를 반복했다. 며칠간 커맨드라인과 설정을 바꾸어가며 게임을 실행해보려고 노력하다 드디어 도스의 까만 텍스트창이 사라지고 화려한 그래픽이 모니터를 가득 채울때면 그 희열은 이루말할수 없었다. 그런데 이상하게도 게임은 몇분 해보다가 재미가 없어 끄고 말았다. 친구들은 재밌다고 난리인 게임들을 이런 식으로 실행만 시켜보고 끝내곤 했다. 사실 그때는 깨닫지 못했지만 게임을 실행하기까지의 반복되는 설정, 도스 커맨드라인 그리고 이런 디버깅을 마쳤을때의 희열이 내겐 “일”이 아닌 즐거움이었다. 그래서 내게도 프로그래밍은 천직이다.

https://twitter.com/sm_park

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

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

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

대부분의 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