Editor’s note: 프로그래머이자 해커인 박상민님이 폴 그레이엄Paul Graham의 에세이 ’해커와 화가’ 번역을 총 5회에 걸쳐 게재합니다. Y combinator를 창업한 폴 그레이엄은 Dropbox, Reddit, Airbnb등의 스타트업을 키워낸 대가로, 투자자이면서도 뛰어난 프로그래머이며 수필가로도 명성을 떨치고 있습니다. (원문 보기)

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

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

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

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

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

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

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

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

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

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

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

(다음 편에 계속)