How you know – 번역과 생각

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

지금은 하루중 많은 시간을 트위터의 짧은 글, 페이스북의 사진들, 동영상을 즐기는데 소비한다. 물론 짧게 짧게 전파되는 트위터는 정보를 발견(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

[번역] A Letter to the Doctors and Nurses Who Cared for My Wife

뉴욕타임즈에 실린 글이 너무 좋아서 번역해 봤습니다. 비록 원문의 그 미묘하고 슬프면서 아름다운  감정이 다 살아나진 않아도 조금이라도 전달된다면 다행입니다.

원문은 여기에서 읽을수 있습니다: “A Letter to the Doctors and Nurses Who Cared for My Wife” 

(보스톤의 작가인 Peter DeMarco는 34살의 젊은 나이에 급성천식으로 아내를 잃고나서 아내를 치료했던 캠브릿지 병원 중환자실에 이 편지를 보냈다)

그 당시엔 몰랐지만 결국 아내의 마지막 날들이되었던 그 일주일…여러분들이 아내를 얼마나 열심히 간호했는지 친구들, 가족들에게 이야기하곤 합니다. 병원의 의사, 간호사, 호흡기전문의, 사회복지사, 그리고 청소원까지 이름 하나하나를 기억해내면 15번째 이름쯤에서 제게 놀라서 묻습니다.

“아니 어떻게 그 많은 이름들을 다 기억해?” 그럼,

“내가 그분들 이름을 어떻게 잊겠어?” 이렇게 저는 반문합니다. 

여러분 한분 한분은 제 아내가 의식이 없이 누워있을때 전문적으로, 친절하게 그리고 아내의 품위를 지켜주며 치료했습니다. 주사를 맞을때면 아내가 의식이 없어 듣지못해도 조금 아플거라고 미리 이야기해주었습니다. 청진기로 심장과 폐의 소리를 듣다가 아내의 옷이 내려가면 환자복을 다시 올려 그녀의 맨살을 가려주었습니다. 아내의 체온을 조절할때 뿐 아니라 입원실이 조금 싸늘할때도 아내가 더 편안히 잘 거라며 담요를 다시 잘 펴서 덮어주었습니다. 

여러분은 아내의 부모님에게도 최선을 다했습니다. 부모님들이 불편한 간이침대에 올라갈때도, 매 시간 마실 물을 가져다줄때도, 끝없는 질문에 상세하게 설명할때도 여러분의 그 친절이 아내의 부모님을 위로했습니다. 이미 아시겠지만 아내의 아버지 본인도 의사이십니다. 자신이 딸의 치료에 의료진과 함께 하고있다고 느끼셨을때 그게 얼마나 큰 의미가 되었는지 상상할수 없을 것입니다.

그리고 여러분들이 제게 해준 것들이 얼마나 컸는지 모릅니다. 그 일주일동안 당신들의 도움이 없었다면 어디에서 제가 힘을 얻을수 있었을까요?

일주일 내내 제가 아내의 침대곁에서 흐느낄때…그녀의 손등위에 머리를 올려놓고 힘없이 앉아있을때면 기척 하나없이, 마치 투명인간이 된것처럼 조용히 자신의 업무를 해주었습니다. 제가 간이침대를 그녀의 침대곁에 조금이라도 가깝게 붙여보려고 애쓸때면 주사튜브와 의료기기의 복잡한 선들 사이로 들어가 침대를 옮기는것을 몇번이고 도와주었습니다. 

얼마나 자주 제게 다가와 필요한 것이 없는지, 마실물과 먹을것, 갈아입을 옷과 샤워할 물이 필요한지 물어봐 주셨는지 모릅니다. 아내의 상태에대해 좀 더 알고 싶을때, 아니면 그냥 아무 이야기든 하고싶을때에도 여러분은 옆에 있어주었습니다.

깊이 절망해 있었을때 얼마나 많이 저를 안아서 위로해주고 Laura가 어떤 사람이었는지 그녀의 사진을 함께 보며, 제가 그녀에대해 쓴 글을 읽으며 공감해주었는지 모릅니다. 제게 나쁜 소식을 전할때면 얼마나 많이 떨리는 목소리로 슬픔을 눈에담아 이야기해주었는지 모릅니다.

제가 긴급한 이메일을 써야해서 컴퓨터가 필요하면 어떻게해서든 제게 마련해 주었습니다. 중환자실의 특별한 손님이었던 우리 고양이 <콜라>를 몰래 데리고와 마지막으로 Laura의 얼굴을 핥게해주었을때 못본척해 주신것도 알고 있습니다. 

그리고 그 특별한 저녁에 Laura의 친구, 동료, 학교동창과 가족들까지 50명이 넘는 사람들을 중환자실로 부를수있는 특권까지 허락해주었습니다. 그날 저녁 친구들은 기타를 연주하고, 오페라 곡을 불러주거나 춤을 추며 Laura에게 마지막 사랑을 쏟아부었습니다. 제 아내가 그렇게 많은 사람들을 사랑하고 사랑받고있었다는걸 그날에야 알았습니다. 그날 저녁은 우리 결혼생활의 마지막 파티와 같았습니다. 여러분이 도와주지 않았다면 불가능했을 시간입니다.

그리고 마지막 한번의 그 순간, 한시간 뿐이었지만 제가 평생 잊지못할 그 시간이 있었습니다.

마지막 날, Laura의 장기를 기증하기위한 수술을 기다리면서 저는 아내와 혼자있고 싶었습니다. 하지만 가족들과 친구들이 몰려와 그녀에게 작별인사를 하면서 시간이 계속 지나가고 있었습니다. 오후 4시, 이제 모든 사람들이 다 떠난후 저는 정신적으로 육체적으로 너무 지쳐서 잠깐 눈을 붙이고 싶었습니다. 그래서 아내의 간호사 Donna와 Jen에게 간이침대를 옮기는걸 도와줄수 있냐고 물었습니다. 아내 곁에 조금 더 가까이 눕고싶었습니다. 그런데 그분들은 더 좋은 생각을 해내더군요.

간호사들은 제게 잠시만 나가있어달라고 부탁했습니다. 제가 다시 돌아왔을때 그분들은 Laura를 침대의 오른편으로 눕혀서 제가 같이 누울수 있을정도의 공간을 만들어주었습니다. 한시간만 제가 아내와 아무 방해없이 둘만의 시간을 가져도 되냐고 물었을때 고개를 끄덕이며 커튼과 문을 닫고 불을 꺼 주었습니다.

저는 아내를 바라본채로 누웠습니다. 정말 아름다워서 아내의 머리와 얼굴을 어루만지며 아름답다고 속삭였습니다. 아내의 가운을 조금 내려서 가슴에 키스를 하고 머리를 기대니 숨쉴때마다 올라왔다 내려가는 심장소리가 들려왔습니다. 그 순간이 남편과 아내로서의 마지막 교감이었습니다. 지금까지 어떤때보다 가장 자연스럽고 순수하며 위로받을수 있는 그런 느낌이었습니다. 그리고 곧 잠이들었습니다.

전 그 마지막 한 시간을 평생 기억할겁니다. 상상할수 있는 그 어떤것보다 큰 선물이었습니다. Donna와 Jen에게 고마움을 전하고 싶습니다.

진심으로 여러분 모두에게 감사드립니다. 

깊은 고마움과 사랑을 담아서,

Peter DeMarco

06voices-laura-articlelarge

Peter DeMarco 와 아내  Laura Levis

[번역] 일처럼 느껴지지 않는 것들

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

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

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

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

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

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

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

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

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

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

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

Screen Shot 2015-05-28 at 12.58.34 AM

https://twitter.com/sm_park

[번역] 해커와 화가 – 5 (끝)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://twitter.com/sm_park

[번역] 해커와 화가 – 4

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

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

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

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

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

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

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

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

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

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

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

https://twitter.com/sm_park

[번역] 해커와 화가 – 3

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

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

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

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

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

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

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

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

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

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

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

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

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

https://twitter.com/sm_park

[번역] 해커와 화가 – 2

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

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

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

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

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

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

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

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

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

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

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

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

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

https://twitter.com/sm_park