한빛출판네트워크

저자: 폴 그레이엄 / 임백준 역
출처: 해커와 화가(폴 그레이엄 저 / 임백준 역, 2005) 중에서 chapter 2. 해커와 화가



• 해커와 화가 (1)
• 해커와 화가 (2)
• 해커와 화가 (3)

해커는 과학자라기보다 창조자에 가깝기 때문에 적절한 메타포를 찾을 수 있는 곳은 과학 분야가 아니라 다른 종류의 창조자들 자신이다. 그림 그리기가 우리에게 가르쳐 주는 것이 해킹 말고 다른 무엇이 있겠는가?

우리가 그림을 그리는 예에서 배울 수 있는 것은, 혹은 적어도 확인할 수 있는 것은 바로 해킹을 어떻게 할 것인가 하는 점이다. 그림은 무엇인가를 그림으로써 학습한다. 해킹도 마찬가지다. 대부분의 해커들이 대학에서 프로그래밍 수업을 받는 것으로 해킹을 배우지 않는다. 그들은 예를 들어서 13살이었을 때 자기 자신이 직접 프로그램을 만들어 봄으로써 해킹을 배운다. 심지어 대학의 수업에서조차, 당신은 가만히 앉아서 설명을 듣는 것이 아니라 직접 해킹을 해봄으로써 해킹을 배운다.

화가들이 그들의 작품에 남기는 흔적을 보면, 그들이 직접적인 행위를 통해서 배워나간다는 사실을 확인할 수 있다. 어느 한 화가의 작품을 시간 순서대로 확인해 보면 하나의 작품은 바로 이전 작품에서 학습한 내용을 토대로 구축되어 있음을 알게 된다. 완성도가 매우 높은 작품이 있다면 대개 그 작품의 버전 1에 해당하는 작품이 조금 작은 크기로 전에 시도된 적이 있을 때가 많다.

대부분의 창조가 이런 방식으로 이루어진다. 소설가나 건축가도 마찬가지다. 그래서 해커가하나의 프로젝트를 붙들고 몇 년 동안 일하면서 나중에 새롭게 떠오르는 생각을 프로젝트에 부분적으로 적용하여 개정판을 만들어나가는 것보다는, 화가와 같이 처음부터 새롭게 시작하는 프로젝트를 규칙적으로 반복하는 것이 더 바람직할 것이다.

해커들이 실제적인 행동을 통해서 해킹을 배운다는 사실은 해킹이 과학과 다르다는 점을 시사하는 또 하나의 증거가 된다. 과학자들은 직접적인 행동이 아니라 실험과 일련의 연습문제를 통해서 배워나간다. 과학자들은 다른 사람이 그들을 위해서 해놓은 일을 반복한다는 의미에서 언제나 완벽한 일만 수행한다. 이러한 과정들을 통해서 그들은 궁극적으로 독창적인 일을 할 수 있는 지점에 도달하게 된다. 하지만 해커들은 시작부터가 독창적이다. 이것은 다소 불공평하다. 해커들은 독창적으로 시작해서 점점 좋은 상황으로 전진하고, 과학자들은 좋은 상황에서 출발해서 차츰 독창적이 되어간다.

창조자들이 학습하는 다른 방법으로는 예를 통한 학습 방법이 있다. 화가에서 있어서 박물관이란 여러 가지 다양한 기법을 참조할 수 있는 도서관에 해당한다. 위대한 작품을 그대로 모방하는 것은 수백 년 동안 전통적인 교육의 일부였다. 모방의 과정은 그 작품을 매우 자세하게 들여다보도록 강제하기 때문이다.

소설가들도 동일한 방법을 사용한다. 벤자민 플랭클린은 애디슨(Addison)과 스틸리(Steele)의 에세이에 담겨있는 논점을 요약하고 그것을 재구성하는 방법을 통해서 글쓰기를 배웠다. 레이몬드 챈들러가 추리 소설의 기법을 배운 것도 이와 동일하다.

이와 마찬가지로 해커들도 좋은 프로그램을 들여다봄으로써 프로그래밍을 배운다. 프로그램이 겉으로 볼 때 어떤 일을 하는지만 보는 것이 아니라 내부의 소스 코드를 들여다보는 것이다. 오픈 소스 운동이 가진 장점 중에서 충분히 언급되지 않는 것 하나가 바로 그것이 프로그래밍을 배우는 과정 자체를 쉽게 만들었다는 점이다. 내가 프로그래밍을 배우던 시절에는 모든 것이 책 안에 담긴 예제에 국한되었다. 당시에 접근할 수 있었던 커다란 소스 코드는 유닉스였는데 그것조차 오픈 소스가 아니었다. 사람들은 대개 글씨를 식별하기조차 어려운 존 라이온스의 복사본을 통해서 유닉스 소스를 읽었는데, 그 책은 1977년에 쓰여졌음에도 불구하고 1996년까지 출판이 허락되지 않았다.

우리가 그림 그리기로부터 생각해 볼 수 있는 다른 예는 그림이 점진적인 세공(refinement)의 과정을 거쳐서 완성된다는 점이다. 그림은 대개 스케치로부터 시작되어 세밀한 부분이 조금씩 더해진다. 하지만 그것은 단순한 덧칠의 과정이 아니다. 때로는 처음의 구상이 잘못된 것으로 드러나기도 한다. 엑스레이를 통해서 들여다보면 많은 그림들이 팔다리를 여기저기로 옮기고 얼굴 표정을 셀 수 없이 고친 흔적을 고스란히 드러낸다.

우리가 그림으로부터 배울 수 있는 것이 이것이다. 나는 해킹도 이와 같은 방식으로 진행되어야 한다고 생각한다. 프로그램을 위한 요구사항이 완벽할 것이라고 기대하는 것은 환상이다. 그것을 처음부터 인정하고, 개발 도중에 요구사항이 바뀌는 것을 수용할 수 있는 방식으로 프로그램을 짜는 것이 현명할 것이다.

(커다란 회사의 구조는 이것을 어렵게 만든다. 그래서 이것은 스타트업 회사가 큰 회사를 앞지를 수 있는 또 하나의 영역에 속한다.)

이제는 대부분의 사람들이 성능의 최적화를 지나치게 일찍 시도하는 것이 위험하다는 사실을 알게 되었다. 내 생각으로는 너무 이른 디자인도 성능의 최적화와 똑같은 정도로 비판의 대상이 되어야 옳다. 다시 말해서 프로그램이 수행해야 하는 일을 너무 일찍 결정해 버리는 것 말이다.

올바른 도구는 우리가 이러한 위험을 피하도록 도와준다. 좋은 프로그래밍 언어는 마치 유화 물감처럼 여러분의 생각을 나중에 번복하는 것을 용이하게 만들어 주어야 한다. 동적인 타입 체크는 특정한 데이터 표현을 처음부터 고민할 필요가 없도록 만들기 때문에 바로 이와 같은 역할을 담당해준다. 하지만 이와 같은 유연성과 관련된 핵심적인 사항은 언어를 매우 추상적으로 만드는 것으로 보인다. 수정하기에 가장 용이한 프로그램은 결국 짧은 프로그램이기 때문이다.