해커와 화가

2003년 5월

(이 에세이는 하버드에서 진행된 특강과 노스이스턴에서의 이전 강연을 바탕으로 합니다.)

컴퓨터 과학 대학원을 마쳤을 때, 저는 그림을 배우기 위해 미술 학교에 갔습니다. 컴퓨터에 관심 있는 사람이 그림에도 관심이 있다는 사실에 많은 사람들이 놀라는 듯했습니다. 그들은 해킹과 그림이 매우 다른 종류의 작업이라고 생각하는 듯했습니다. 즉, 해킹은 차갑고, 정밀하며, 체계적인 반면, 그림은 원초적인 충동의 광적인 표현이라고 말입니다.

이 두 가지 생각은 모두 틀렸습니다. 해킹과 그림은 공통점이 많습니다. 사실, 제가 아는 모든 유형의 사람들 중에서 해커와 화가는 가장 닮은 부류에 속합니다.

해커와 화가의 공통점은 둘 다 '만드는 사람'이라는 것입니다. 작곡가, 건축가, 작가와 마찬가지로, 해커와 화가가 하려는 일은 좋은 것을 만드는 것입니다. 그들은 그 자체로 연구를 하는 것은 아니지만, 좋은 것을 만들려 노력하는 과정에서 새로운 기술을 발견한다면 더욱 좋습니다.

저는 "컴퓨터 과학"이라는 용어를 한 번도 좋아해 본 적이 없습니다. 제가 이 용어를 싫어하는 주된 이유는 그런 것이 존재하지 않기 때문입니다. 컴퓨터 과학은 유고슬라비아처럼 역사의 우연으로 인해 어설프게 연결된 분야들을 한데 모아놓은 잡동사니입니다. 한쪽 끝에는 실제로는 수학자이지만 DARPA 보조금을 받기 위해 자신들이 하는 일을 컴퓨터 과학이라고 부르는 사람들이 있습니다. 중간에는 컴퓨터의 자연사와 같은 것을 연구하는 사람들, 예를 들어 네트워크를 통해 데이터를 라우팅하는 알고리즘의 동작을 연구하는 사람들이 있습니다. 그리고 다른 극단에는 흥미로운 소프트웨어를 작성하려는 해커들이 있는데, 그들에게 컴퓨터는 건축가에게 콘크리트나 화가에게 물감과 같은 표현 매체일 뿐입니다. 마치 수학자, 물리학자, 건축가가 모두 같은 학과에 있어야 하는 것과 같습니다.

때때로 해커들이 하는 일을 "소프트웨어 공학"이라고 부르기도 하지만, 이 용어도 마찬가지로 오해의 소지가 있습니다. 훌륭한 소프트웨어 설계자는 건축가 이상으로 엔지니어가 아닙니다. 건축과 공학의 경계가 명확하게 정의되어 있지는 않지만, 그 경계는 존재합니다. 그것은 '무엇'과 '어떻게' 사이에 있습니다. 건축가는 무엇을 할지 결정하고, 엔지니어는 그것을 어떻게 할지 알아냅니다.

'무엇'과 '어떻게'는 너무 분리되어서는 안 됩니다. 어떻게 해야 할지 이해하지 못한 채 무엇을 할지 결정하려고 한다면 문제가 생길 것입니다. 하지만 해킹은 단순히 어떤 사양을 어떻게 구현할지 결정하는 것 이상일 수 있습니다. 최고 수준의 해킹은 사양을 만들어내는 것이며, 가장 좋은 방법은 그것을 직접 구현하는 것으로 드러납니다.

아마 언젠가 "컴퓨터 과학"은 유고슬라비아처럼 구성 요소로 분리될지도 모릅니다. 그것은 좋은 일일 수 있습니다. 특히 그것이 저의 고향인 해킹의 독립을 의미한다면 더욱 그렇습니다.

이 모든 다른 유형의 작업을 한 학과에 묶는 것은 행정적으로는 편리할 수 있지만, 지적으로는 혼란을 야기합니다. 그것이 제가 "컴퓨터 과학"이라는 이름을 싫어하는 또 다른 이유입니다. 중간에 있는 사람들은 실험 과학과 같은 것을 하고 있다고 주장할 수 있습니다. 하지만 양쪽 끝에 있는 사람들, 즉 해커와 수학자들은 실제로는 과학을 하고 있지 않습니다.

수학자들은 이에 대해 개의치 않는 듯합니다. 그들은 수학과에 있는 다른 수학자들처럼 즐겁게 정리 증명에 착수하며, 아마 곧 자신들이 일하는 건물 외부에 "컴퓨터 과학"이라고 쓰여 있다는 사실을 알아채지 못하게 될 것입니다. 하지만 해커들에게 이 명칭은 문제입니다. 자신들이 하는 일이 과학이라고 불리면, 과학적으로 행동해야 한다고 느끼게 됩니다. 그래서 대학과 연구소의 해커들은 정말 하고 싶은 일, 즉 아름다운 소프트웨어를 설계하는 대신 연구 논문을 써야 한다고 느낍니다.

최선의 경우, 논문은 단지 형식적인 것에 불과합니다. 해커들은 멋진 소프트웨어를 작성하고, 그것에 대해 논문을 쓰며, 그 논문은 소프트웨어가 나타내는 성과의 대리물이 됩니다. 하지만 종종 이러한 불일치는 문제를 야기합니다. 아름다운 것을 만드는 것에서 벗어나 연구 논문의 주제로 더 적합한 추한 것을 만드는 쪽으로 쉽게 흘러갈 수 있습니다.

불행히도, 아름다운 것들이 항상 논문의 가장 좋은 주제가 되는 것은 아닙니다. 첫째, 연구는 독창적이어야 합니다. 박사 학위 논문을 써본 사람이라면 누구나 알듯이, 미개척지를 탐험하고 있다는 것을 확실히 하는 방법은 아무도 원하지 않는 땅을 차지하는 것입니다. 둘째, 연구는 실질적이어야 합니다. 그리고 어설픈 시스템은 더 풍성한 논문을 낳는데, 왜냐하면 일을 완수하기 위해 극복해야 할 장애물에 대해 쓸 수 있기 때문입니다. 잘못된 가정에서 시작하는 것만큼 풍성한 문제를 낳는 것은 없습니다. AI의 대부분이 이 규칙의 예시입니다. 만약 지식이 추상적인 개념을 나타내는 인자들을 가진 술어 논리 표현식의 목록으로 표현될 수 있다고 가정한다면, 이것을 작동하게 만드는 방법에 대해 쓸 논문이 많을 것입니다. 리키 리카르도가 말했듯이, "루시, 설명할 게 많겠어."

아름다운 것을 창조하는 방법은 종종 이미 존재하는 것에 미묘한 조정을 가하거나, 기존 아이디어를 약간 새로운 방식으로 결합하는 것입니다. 이러한 종류의 작업은 연구 논문에서 전달하기 어렵습니다.

그렇다면 왜 대학과 연구소는 계속해서 출판물로 해커를 평가할까요? "학업 적성"이 단순한 표준화된 시험으로 측정되거나, 프로그래머의 생산성이 코드 라인 수로 측정되는 것과 같은 이유입니다. 이러한 시험들은 적용하기 쉽고, 어느 정도 작동하는 쉬운 시험만큼 유혹적인 것은 없습니다.

해커들이 실제로 하려는 일, 즉 아름다운 소프트웨어를 설계하는 것을 측정하는 것은 훨씬 더 어려울 것입니다. 좋은 디자인을 판단하려면 좋은 디자인 감각이 필요합니다. 그리고 좋은 디자인을 인식하는 사람들의 능력과 그들이 할 수 있다는 자신감 사이에는 부정적인 상관관계 외에는 아무런 상관관계도 없습니다.

유일한 외부 시험은 시간입니다. 시간이 지나면서 아름다운 것들은 번성하는 경향이 있고, 추한 것들은 버려지는 경향이 있습니다. 불행히도, 관련된 시간은 인간의 수명보다 길 수 있습니다. 새뮤얼 존슨은 작가의 명성이 수렴하는 데 백 년이 걸린다고 말했습니다. 작가의 영향력 있는 친구들이 죽고, 그들의 모든 추종자들이 죽을 때까지 기다려야 합니다.

저는 해커들이 자신의 명성에 큰 무작위적 요소가 있다는 것을 받아들여야 한다고 생각합니다. 이 점에서 그들은 다른 창작자들과 다르지 않습니다. 사실, 비교하자면 그들은 운이 좋은 편입니다. 해킹에서 유행의 영향력은 그림에서만큼 크지 않습니다.

사람들이 당신의 작업을 오해하는 것보다 더 나쁜 것이 있습니다. 더 나쁜 위험은 당신 스스로 당신의 작업을 오해하게 되는 것입니다. 관련 분야는 아이디어를 찾으러 가는 곳입니다. 만약 당신이 컴퓨터 과학과에 있다면, 예를 들어 해킹이 이론 컴퓨터 과학의 이론에 대한 응용 버전이라고 믿고 싶은 자연스러운 유혹이 있습니다. 제가 대학원에 다니는 내내, 저는 더 많은 이론을 알아야 한다는 불편한 느낌을 마음속에 가지고 있었고, 기말고사 후 3주 안에 그 모든 것을 잊어버린 것이 매우 부주의하다고 생각했습니다.

이제 저는 제가 틀렸다는 것을 깨달았습니다. 해커는 화가가 물감 화학을 이해해야 하는 만큼만 계산 이론을 이해하면 됩니다. 시간 및 공간 복잡도 계산 방법과 튜링 완전성에 대해 알아야 합니다. 또한 파서나 정규 표현식 라이브러리를 작성해야 할 경우를 대비하여 최소한 상태 기계의 개념은 기억해두는 것이 좋습니다. 사실 화가들은 물감 화학에 대해 그보다 훨씬 더 많은 것을 기억해야 합니다.

저는 아이디어의 가장 좋은 원천이 이름에 "컴퓨터"라는 단어가 들어간 다른 분야가 아니라, 창작자들이 거주하는 다른 분야라는 것을 발견했습니다. 그림은 계산 이론보다 훨씬 더 풍부한 아이디어의 원천이었습니다.

예를 들어, 저는 대학에서 컴퓨터 근처에도 가기 전에 종이에 프로그램을 완전히 구상해야 한다고 배웠습니다. 저는 제가 이런 식으로 프로그래밍하지 않는다는 것을 알았습니다. 저는 종이 앞에서가 아니라 컴퓨터 앞에 앉아서 프로그래밍하는 것을 좋아한다는 것을 알았습니다. 더 나쁜 것은, 인내심을 가지고 완전한 프로그램을 작성하고 그것이 정확하다고 확신하는 대신, 저는 절망적으로 망가진 코드를 그냥 쏟아내고 점차 그것을 다듬어 나가는 경향이 있었습니다. 디버깅은 오타와 실수를 잡아내는 일종의 최종 검토라고 배웠습니다. 제가 일하는 방식으로는 프로그래밍이 디버깅으로 이루어진 것처럼 보였습니다.

오랫동안 저는 이것에 대해 죄책감을 느꼈습니다. 마치 초등학교 때 배운 대로 연필을 잡지 못해서 죄책감을 느꼈던 것처럼 말입니다. 만약 제가 다른 창작자들, 즉 화가나 건축가들을 살펴보았다면, 제가 하고 있는 일에 이름이 있다는 것을 깨달았을 것입니다: 스케치. 제가 아는 한, 대학에서 저에게 프로그래밍을 가르친 방식은 완전히 틀렸습니다. 작가, 화가, 건축가가 그러하듯이, 프로그램을 작성하면서 구상해야 합니다.

이것을 깨닫는 것은 소프트웨어 설계에 실제적인 영향을 미칩니다. 이는 프로그래밍 언어가 무엇보다도 유연해야 한다는 것을 의미합니다. 프로그래밍 언어는 이미 생각한 프로그램을 표현하기 위한 것이 아니라, 프로그램을 생각하기 위한 것입니다. 그것은 펜이 아니라 연필이어야 합니다. 정적 타이핑은 사람들이 대학에서 저에게 가르친 방식대로 실제로 프로그램을 작성한다면 좋은 아이디어일 것입니다. 하지만 제가 아는 해커 중 누구도 그렇게 프로그램을 작성하지 않습니다. 우리는 무릎에 타입 찻잔을 올려놓고 엄격한 컴파일러 할머니와 공손한 대화를 나누어야 하는 언어가 아니라, 낙서하고, 번지게 하고, 문지를 수 있는 언어가 필요합니다.

정적 타이핑에 대해 이야기하는 김에, 창작자들과 자신을 동일시하는 것은 과학을 괴롭히는 또 다른 문제, 즉 '수학 부러움'으로부터 우리를 구할 것입니다. 과학계의 모든 사람들은 수학자들이 자신들보다 똑똑하다고 은밀히 믿습니다. 저는 수학자들도 그렇게 믿는다고 생각합니다. 어쨌든 그 결과는 과학자들이 자신들의 작업을 가능한 한 수학적으로 보이게 하려는 경향이 있다는 것입니다. 물리학과 같은 분야에서는 이것이 큰 해를 끼치지 않을 수 있지만, 자연 과학에서 멀어질수록 더 큰 문제가 됩니다.

공식 한 페이지는 정말 인상적으로 보입니다. (팁: 더 인상적으로 보이려면 그리스 변수를 사용하세요.) 그래서 중요하다고 할 수 있는 문제보다는 형식적으로 다룰 수 있는 문제에 매달리고 싶은 큰 유혹이 있습니다.

만약 해커들이 작가나 화가와 같은 다른 창작자들과 자신을 동일시한다면, 이런 유혹을 느끼지 않을 것입니다. 작가와 화가는 수학 부러움에 시달리지 않습니다. 그들은 자신들이 완전히 관련 없는 일을 하고 있다고 느낍니다. 해커들도 마찬가지라고 저는 생각합니다.

만약 대학과 연구소가 해커들이 하고 싶은 종류의 일을 하지 못하게 한다면, 아마 그들을 위한 곳은 회사일 것입니다. 불행히도, 대부분의 회사들도 해커들이 원하는 대로 하게 두지 않습니다. 대학과 연구소는 해커들을 과학자로 만들고, 회사들은 그들을 엔지니어로 만듭니다.

저는 이 사실을 비교적 최근에야 깨달았습니다. 야후가 Viaweb을 인수했을 때, 그들은 제가 무엇을 하고 싶은지 물었습니다. 저는 사업적인 측면을 별로 좋아하지 않았기 때문에, 그냥 해킹을 하고 싶다고 말했습니다. 야후에 가보니, 그들에게 해킹이란 소프트웨어를 설계하는 것이 아니라 구현하는 것을 의미한다는 것을 알았습니다. 프로그래머들은 제품 관리자의 비전(만약 그 단어가 적절하다면)을 코드로 번역하는 기술자로 여겨졌습니다.

이것이 대기업의 기본 계획인 듯합니다. 그들은 결과의 표준 편차를 줄이기 위해 그렇게 합니다. 소수의 해커만이 실제로 소프트웨어를 설계할 수 있으며, 회사를 운영하는 사람들이 이들을 선별하기는 어렵습니다. 그래서 소프트웨어의 미래를 한 명의 뛰어난 해커에게 맡기는 대신, 대부분의 회사는 위원회에서 설계하고 해커들은 단순히 그 설계를 구현하도록 시스템을 구축합니다.

언젠가 돈을 벌고 싶다면 이것을 기억하십시오. 이것이 스타트업이 성공하는 이유 중 하나이기 때문입니다. 대기업은 재앙을 피하기 위해 설계 결과의 표준 편차를 줄이려 합니다. 하지만 진동을 억제하면 낮은 지점뿐만 아니라 높은 지점도 잃게 됩니다. 이것은 대기업에게 문제가 되지 않는데, 그들은 훌륭한 제품을 만들어 이기는 것이 아니기 때문입니다. 대기업은 다른 대기업보다 덜 형편없음으로써 이깁니다.

따라서 만약 당신이 소프트웨어가 제품 관리자에 의해 설계되는 충분히 큰 회사와 디자인 전쟁을 벌일 방법을 찾아낼 수 있다면, 그들은 결코 당신을 따라잡을 수 없을 것입니다. 하지만 이런 기회는 찾기 쉽지 않습니다. 대기업과 디자인 전쟁을 벌이는 것은 성 안에 있는 적과 백병전을 벌이는 것만큼 어렵습니다. 예를 들어, 마이크로소프트 워드보다 더 나은 워드 프로세서를 작성하는 것은 꽤 쉬울 것이지만, 마이크로소프트는 운영체제 독점이라는 성 안에서 당신이 그렇게 하더라도 아마 알아채지 못할 것입니다.

디자인 전쟁을 벌일 곳은 새로운 시장입니다. 아무도 아직 요새를 구축하지 못한 곳 말입니다. 그곳에서 당신은 디자인에 대한 과감한 접근 방식을 취하고, 동일한 사람들이 제품을 설계하고 구현하게 함으로써 크게 승리할 수 있습니다. 마이크로소프트 자신들도 초창기에는 이렇게 했습니다. 애플도 그랬고, 휴렛팩커드도 그랬습니다. 거의 모든 성공적인 스타트업이 그랬을 것이라고 저는 생각합니다.

따라서 훌륭한 소프트웨어를 만드는 한 가지 방법은 자신만의 스타트업을 시작하는 것입니다. 하지만 여기에는 두 가지 문제가 있습니다. 하나는 스타트업에서는 소프트웨어 작성 외에도 해야 할 일이 너무 많다는 것입니다. Viaweb에서 저는 시간의 4분의 1이라도 해킹을 할 수 있다면 운이 좋다고 생각했습니다. 그리고 나머지 4분의 3 동안 해야 했던 일들은 지루한 것부터 끔찍한 것까지 다양했습니다. 저는 이에 대한 기준점이 있는데, 언젠가 이사회 회의를 떠나 충치를 치료해야 했기 때문입니다. 저는 치과 의자에서 드릴을 기다리며 앉아 있는데, 마치 휴가 온 것 같은 기분이 들었던 것을 기억합니다.

스타트업의 또 다른 문제는 돈을 버는 소프트웨어와 작성하기에 흥미로운 소프트웨어 사이에 겹치는 부분이 많지 않다는 것입니다. 프로그래밍 언어는 작성하기에 흥미롭고, 사실 마이크로소프트의 첫 제품도 프로그래밍 언어였지만, 지금은 아무도 프로그래밍 언어에 돈을 지불하지 않을 것입니다. 돈을 벌고 싶다면, 아무도 무료로 해결하고 싶어 하지 않을 만큼 지저분한 문제들을 다루도록 강요받는 경향이 있습니다.

모든 창작자들이 이 문제에 직면합니다. 가격은 수요와 공급에 의해 결정되며, 개별 고객의 일상적인 문제를 해결하는 것만큼 작업하기 재미있는 것에 대한 수요는 많지 않습니다. 오프 브로드웨이 연극에 출연하는 것은 무역 박람회에서 누군가의 부스에서 고릴라 복장을 입는 것만큼 돈이 되지 않습니다. 소설을 쓰는 것은 음식물 처리기 광고 문구를 쓰는 것만큼 돈이 되지 않습니다. 그리고 프로그래밍 언어를 해킹하는 것은 어떤 회사의 레거시 데이터베이스를 웹 서버에 연결하는 방법을 알아내는 것만큼 돈이 되지 않습니다.

저는 소프트웨어의 경우 이 문제에 대한 해답이 거의 모든 창작자들에게 알려진 개념, 즉 '주간 직업(day job)'이라고 생각합니다. 이 용어는 밤에 공연하는 음악가들로부터 시작되었습니다. 더 일반적으로 말하면, 돈을 위해 하는 일과 사랑을 위해 하는 일이 따로 있다는 것을 의미합니다.

거의 모든 창작자들은 경력 초기에 주간 직업을 가집니다. 화가와 작가들은 특히 그렇습니다. 운이 좋다면 자신의 진짜 작업과 밀접하게 관련된 주간 직업을 얻을 수 있습니다. 음악가들은 종종 음반 가게에서 일하는 것처럼 보입니다. 어떤 프로그래밍 언어나 운영 체제를 작업하는 해커도 마찬가지로 그것을 사용하는 주간 직업을 얻을 수 있을 것입니다. [1]

해답이 해커들이 주간 직업을 가지고 부업으로 아름다운 소프트웨어를 작업하는 것이라고 말할 때, 저는 이것을 새로운 아이디어로 제안하는 것이 아닙니다. 이것이 바로 오픈 소스 해킹의 본질입니다. 제가 말하는 것은 오픈 소스가 아마도 올바른 모델일 것이라는 점인데, 이는 다른 모든 창작자들에 의해 독립적으로 확인되었기 때문입니다.

어떤 고용주라도 해커들이 오픈 소스 프로젝트에 참여하는 것을 꺼린다는 것이 저에게는 놀랍습니다. Viaweb에서는 그렇게 하지 않는 사람을 고용하는 것을 꺼렸을 것입니다. 프로그래머를 면접할 때, 우리가 가장 중요하게 생각한 것은 그들이 여가 시간에 어떤 종류의 소프트웨어를 작성했는지였습니다. 당신이 그것을 사랑하지 않는 한 어떤 것도 정말 잘할 수 없으며, 해킹을 사랑한다면 필연적으로 자신만의 프로젝트를 작업하게 될 것입니다. [2]

해커는 과학자라기보다는 창작자이기 때문에, 비유를 찾을 올바른 장소는 과학이 아니라 다른 종류의 창작자들 사이입니다. 그림은 해킹에 대해 우리에게 또 무엇을 가르쳐줄 수 있을까요?

그림의 예시에서 우리가 배울 수 있거나, 적어도 확인할 수 있는 한 가지는 해킹을 배우는 방법입니다. 그림은 주로 직접 해보면서 배웁니다. 해킹도 마찬가지입니다. 대부분의 해커는 대학에서 프로그래밍 강좌를 수강하여 해킹을 배우지 않습니다. 그들은 열세 살에 자신만의 프로그램을 작성하면서 해킹을 배웁니다. 대학 수업에서도, 당신은 주로 해킹을 하면서 해킹을 배웁니다. [3]

화가들은 작업의 흔적을 남기기 때문에, 그들이 직접 해보면서 배우는 것을 지켜볼 수 있습니다. 화가의 작업을 연대순으로 살펴보면, 각 그림이 이전 그림에서 배운 것들을 기반으로 발전한다는 것을 알 수 있습니다. 그림에서 아주 잘 작동하는 부분이 있다면, 보통 이전 그림에서 더 작은 형태로 그 첫 번째 버전을 찾을 수 있습니다.

저는 대부분의 창작자들이 이런 식으로 작업한다고 생각합니다. 작가와 건축가도 마찬가지인 듯합니다. 아마 해커들이 화가처럼 행동하여, 하나의 프로젝트를 몇 년 동안 계속 작업하고 나중에 떠오른 모든 아이디어를 수정으로 통합하려고 하는 대신, 정기적으로 처음부터 다시 시작하는 것이 좋을 것입니다.

해커들이 직접 해보면서 해킹을 배운다는 사실은 해킹이 과학과 얼마나 다른지를 보여주는 또 다른 신호입니다. 과학자들은 직접 해보면서 과학을 배우는 것이 아니라, 실험실 실습과 문제 풀이를 통해 배웁니다. 과학자들은 다른 사람이 이미 해놓은 작업을 재현하려는 의미에서 완벽한 작업을 하는 것으로 시작합니다. 결국 그들은 독창적인 작업을 할 수 있는 지점에 도달합니다. 반면에 해커들은 처음부터 독창적인 작업을 합니다. 단지 그것이 매우 서툴 뿐입니다. 그래서 해커는 독창적으로 시작하여 능숙해지고, 과학자는 능숙하게 시작하여 독창적이게 됩니다.

창작자들이 배우는 또 다른 방법은 예시를 통해서입니다. 화가에게 박물관은 기술의 참고 도서관입니다. 수백 년 동안 위대한 거장들의 작품을 모사하는 것은 화가들의 전통 교육의 일부였습니다. 왜냐하면 모사는 그림이 만들어지는 방식을 면밀히 살펴보게 하기 때문입니다.

작가들도 마찬가지입니다. 벤저민 프랭클린은 애디슨과 스틸의 에세이 요점을 요약한 다음 그것을 재현하려고 노력하면서 글쓰기를 배웠습니다. 레이먼드 챈들러도 탐정 소설로 같은 일을 했습니다.

해커들도 마찬가지로 좋은 프로그램을 보면서 프로그래밍을 배울 수 있습니다. 그 프로그램이 무엇을 하는지뿐만 아니라 소스 코드도 말입니다. 오픈 소스 운동의 덜 알려진 이점 중 하나는 프로그래밍을 배우는 것을 더 쉽게 만들었다는 것입니다. 제가 프로그래밍을 배울 때, 우리는 주로 책에 있는 예시에 의존해야 했습니다. 당시 이용 가능했던 큰 코드 덩어리는 유닉스였지만, 이것조차 오픈 소스는 아니었습니다. 소스 코드를 읽은 대부분의 사람들은 존 라이언스의 책의 불법 복사본으로 읽었는데, 이 책은 1977년에 작성되었음에도 불구하고 1996년까지 출판이 허용되지 않았습니다.

그림에서 얻을 수 있는 또 다른 예시는 그림이 점진적인 정교화를 통해 만들어진다는 방식입니다. 그림은 보통 스케치로 시작합니다. 점차 세부 사항이 채워집니다. 하지만 단순히 채워 넣는 과정만은 아닙니다. 때로는 원래 계획이 잘못된 것으로 판명되기도 합니다. 수많은 그림들이 엑스레이로 보면 팔다리가 움직였거나 얼굴 특징이 재조정된 것으로 드러납니다.

여기 그림에서 배울 수 있는 사례가 있습니다. 저는 해킹도 이런 식으로 작동해야 한다고 생각합니다. 프로그램의 사양이 완벽할 것이라고 기대하는 것은 비현실적입니다. 이 점을 미리 인정하고, 사양이 즉석에서 변경될 수 있도록 프로그램을 작성하는 것이 더 낫습니다.

(대기업의 구조는 이를 어렵게 만들므로, 이것이 스타트업이 이점을 가지는 또 다른 지점입니다.)

이제는 모두가 조기 최적화의 위험에 대해 알고 있을 것입니다. 저는 우리가 조기 설계, 즉 프로그램이 무엇을 해야 할지 너무 일찍 결정하는 것에 대해서도 똑같이 걱정해야 한다고 생각합니다.

올바른 도구는 이러한 위험을 피하는 데 도움이 될 수 있습니다. 좋은 프로그래밍 언어는 유화처럼 마음을 바꾸기 쉽게 만들어야 합니다. 동적 타이핑은 특정 데이터 표현에 미리 구속될 필요가 없으므로 여기서 이득입니다. 하지만 유연성의 핵심은 언어를 매우 추상적으로 만드는 것이라고 생각합니다. 가장 쉽게 변경할 수 있는 프로그램은 매우 짧은 프로그램입니다.

이것은 역설처럼 들리지만, 위대한 그림은 그래야 하는 것보다 더 뛰어나야 합니다. 예를 들어, 레오나르도가 국립 미술관에 있는 지네브라 데 벤치의 초상화를 그릴 때, 그녀의 머리 뒤에 노간주나무 덤불을 그렸습니다. 그 안의 잎사귀 하나하나를 세심하게 그렸습니다. 많은 화가들은 '이것은 그저 그녀의 머리를 액자처럼 둘러싸는 배경일 뿐이야. 아무도 그렇게 자세히 보지 않을 거야'라고 생각했을지도 모릅니다.

레오나르도는 그렇지 않았습니다. 그가 그림의 한 부분에 얼마나 열심히 작업했는지는 그 누구도 얼마나 자세히 볼 것이라고 예상했는지에 전혀 달려 있지 않았습니다. 그는 마이클 조던 같았습니다. 끈질겼죠.

끈질김이 승리하는 이유는, 총체적으로 볼 때 보이지 않는 세부 사항들이 드러나기 때문입니다. 사람들이 지네브라 데 벤치의 초상화 옆을 지나갈 때, 그들은 레오나르도 다 빈치라고 쓰인 라벨을 보기도 전에 종종 즉시 그림에 시선을 빼앗깁니다. 그 모든 보이지 않는 세부 사항들이 합쳐져 천 개의 거의 들리지 않는 목소리가 모두 조화롭게 노래하는 것처럼, 그저 놀라운 것을 만들어냅니다.

마찬가지로 훌륭한 소프트웨어는 아름다움에 대한 광적인 헌신을 요구합니다. 좋은 소프트웨어 내부를 들여다보면, 아무도 볼 필요가 없는 부분조차 아름답다는 것을 알 수 있습니다. 제가 훌륭한 소프트웨어를 작성한다고 주장하는 것은 아니지만, 코드에 관해서는 제가 일상생활을 같은 방식으로 접근한다면 처방약이 필요할 정도로 행동한다는 것을 알고 있습니다. 들여쓰기가 엉망이거나 추한 변수 이름을 사용하는 코드를 보면 미칠 것 같습니다.

만약 해커가 사양을 코드로 바꾸는 단순한 구현자라면, 그는 마치 도랑을 파는 사람처럼 한쪽 끝에서 다른 쪽 끝까지 작업을 해나갈 수 있을 것입니다. 하지만 해커가 창작자라면, 우리는 영감을 고려해야 합니다.

해킹에서도 그림과 마찬가지로 작업은 주기적으로 이루어집니다. 때로는 새로운 프로젝트에 흥분하여 하루에 16시간씩 작업하고 싶을 때도 있습니다. 다른 때에는 아무것도 흥미롭게 느껴지지 않을 때도 있습니다.

좋은 작업을 하려면 이러한 주기를 고려해야 합니다. 왜냐하면 그것들은 당신이 어떻게 반응하는지에 영향을 받기 때문입니다. 수동 변속기 차량으로 언덕을 운전할 때, 시동이 꺼지는 것을 막기 위해 때때로 클러치에서 발을 떼야 합니다. 마찬가지로 물러서는 것은 야망이 멈추는 것을 막을 수 있습니다. 그림과 해킹 모두에는 엄청나게 야심 찬 작업과 편안하게 일상적인 작업이 있습니다. 다른 때라면 멈춰버릴 순간을 위해 쉬운 작업을 남겨두는 것이 좋습니다.

해킹에서 이것은 말 그대로 버그를 모아두는 것을 의미할 수 있습니다. 저는 디버깅을 좋아합니다. 그것은 해킹이 사람들이 생각하는 것처럼 간단한 유일한 시간입니다. 당신은 완전히 제약된 문제를 가지고 있고, 당신이 해야 할 일은 그것을 해결하는 것뿐입니다. 당신의 프로그램은 x를 해야 하는데, 대신 y를 합니다. 어디서 잘못된 것일까요? 당신은 결국 이길 것이라는 것을 압니다. 그것은 벽을 칠하는 것만큼 편안합니다.

그림의 예시는 우리에게 자신의 작업을 관리하는 방법뿐만 아니라 함께 작업하는 방법도 가르쳐줄 수 있습니다. 과거의 위대한 예술 작품 중 상당수는 여러 사람의 손으로 만들어졌지만, 박물관 벽에는 한 사람의 이름만 있을 수 있습니다. 레오나르도는 베로키오의 작업실에서 견습생이었고 그의 그리스도의 세례에 나오는 천사 중 한 명을 그렸습니다. 이런 종류의 일은 예외가 아니라 규칙이었습니다. 미켈란젤로는 시스티나 성당 천장의 모든 인물을 직접 그리겠다고 고집하여 특히 헌신적인 인물로 여겨졌습니다.

제가 아는 한, 화가들이 그림을 함께 작업할 때, 그들은 결코 같은 부분을 작업하지 않았습니다. 스승이 주요 인물을 그리고 조수들이 다른 인물과 배경을 그리는 것이 일반적이었습니다. 하지만 한 사람이 다른 사람의 작업을 덧칠하는 경우는 없었습니다.

저는 이것이 소프트웨어 협업에도 올바른 모델이라고 생각합니다. 너무 과하게 밀어붙이지 마십시오. 세 명 또는 네 명의 다른 사람들이 코드를 해킹하고 있고, 그 누구도 진정으로 소유하지 않는다면, 그것은 공동 휴게실처럼 될 것입니다. 황량하고 버려진 느낌이 들 것이고, 불필요한 것들이 쌓일 것입니다. 협업의 올바른 방법은 프로젝트를 명확하게 정의된 모듈로 나누고, 각 모듈에 명확한 소유자를 두며, 그들 사이의 인터페이스는 프로그래밍 언어만큼 신중하게 설계되고, 가능하다면 명확하게 표현되어야 한다고 생각합니다.

그림과 마찬가지로, 대부분의 소프트웨어는 인간 사용자를 대상으로 합니다. 따라서 해커는 화가처럼 진정으로 훌륭한 작업을 하려면 공감 능력을 가져야 합니다. 사용자의 관점에서 사물을 볼 수 있어야 합니다.

어렸을 때 저는 항상 다른 사람의 관점에서 사물을 보라고 들었습니다. 실제로 이것이 항상 의미하는 바는 제가 원하는 것이 아니라 다른 사람이 원하는 것을 하는 것이었습니다. 물론 이것은 공감에 대한 나쁜 인식을 심어주었고, 저는 공감 능력을 키우지 않으려 노력했습니다.

아, 제가 틀렸습니다. 다른 사람의 관점에서 사물을 보는 것이 사실상 성공의 비결이라는 것이 밝혀졌습니다. 그것이 반드시 자기희생을 의미하는 것은 아닙니다. 전혀 그렇지 않습니다. 다른 사람이 사물을 어떻게 보는지 이해한다고 해서 당신이 그의 이익을 위해 행동할 것이라는 의미는 아닙니다. 어떤 상황에서는, 예를 들어 전쟁에서는, 정반대로 행동하고 싶을 것입니다. [4]

대부분의 창작자들은 인간 사용자를 위해 물건을 만듭니다. 그리고 사용자의 마음을 사로잡으려면 그들이 무엇을 필요로 하는지 이해해야 합니다. 예를 들어, 거의 모든 위대한 그림들은 사람들의 그림입니다. 왜냐하면 사람들은 사람들이 관심 있어 하는 대상이기 때문입니다.

공감 능력은 아마도 좋은 해커와 위대한 해커를 가르는 가장 중요한 차이점일 것입니다. 어떤 해커들은 상당히 똑똑하지만, 공감 능력에 있어서는 거의 유아론자(solipsists)에 가깝습니다. 그런 사람들은 사용자의 관점에서 사물을 볼 수 없기 때문에 훌륭한 소프트웨어를 설계하기 어렵습니다. [5]

사람들이 공감 능력이 얼마나 뛰어난지 알 수 있는 한 가지 방법은 기술적 배경이 없는 사람에게 기술적인 질문을 설명하는 것을 지켜보는 것입니다. 우리는 아마도 다른 면에서는 똑똑하지만, 이 부분에서는 우스꽝스러울 정도로 서툰 사람들을 모두 알고 있을 것입니다. 만약 누군가가 저녁 파티에서 그들에게 프로그래밍 언어가 무엇인지 묻는다면, 그들은 "아, 고급 언어는 컴파일러가 객체 코드를 생성하기 위해 입력으로 사용하는 것입니다."라고 말할 것입니다. 고급 언어? 컴파일러? 객체 코드? 프로그래밍 언어가 무엇인지 모르는 사람은 당연히 이런 것들도 모를 것입니다.

소프트웨어가 해야 할 일 중 하나는 스스로를 설명하는 것입니다. 따라서 좋은 소프트웨어를 작성하려면 사용자가 얼마나 적게 이해하는지 알아야 합니다. 그들은 아무런 준비 없이 소프트웨어에 다가갈 것이고, 매뉴얼을 읽지 않을 것이기 때문에 그들이 예상하는 대로 작동해야 합니다. 이 점에서 제가 본 최고의 시스템은 1985년의 오리지널 매킨토시였습니다. 그것은 소프트웨어가 거의 하지 않는 일을 해냈습니다. 그냥 작동했습니다. [6]

소스 코드 또한 스스로를 설명해야 합니다. 만약 제가 사람들에게 프로그래밍에 대한 단 하나의 인용구만 기억하게 할 수 있다면, 그것은 컴퓨터 프로그램의 구조와 해석 서두에 나오는 구절일 것입니다.

프로그램은 사람이 읽기 위해 작성되어야 하며, 기계가 실행하는 것은 부수적인 일이다.

사용자뿐만 아니라 독자에게도 공감 능력을 가져야 합니다. 그것은 당신의 이익에 부합합니다. 왜냐하면 당신도 그들 중 한 명이 될 것이기 때문입니다. 많은 해커들이 프로그램을 작성한 후 6개월 뒤에 다시 돌아와서 그것이 어떻게 작동하는지 전혀 모른다는 것을 발견했습니다. 저는 그런 경험 후에 Perl을 포기한 몇몇 사람들을 알고 있습니다. [7]

공감 능력 부족은 지능과 연관되어, 어떤 곳에서는 심지어 유행처럼 여겨지기도 합니다. 하지만 저는 아무런 상관관계도 없다고 생각합니다. 공감 능력을 배우지 않고도 수학과 자연 과학에서 잘할 수 있으며, 이 분야의 사람들은 똑똑한 경향이 있어 두 가지 특성이 연관되게 되었습니다. 하지만 공감 능력이 서툰 멍청한 사람들도 많습니다. 토크쇼에 전화해서 질문하는 사람들의 말을 들어보세요. 그들은 질문을 너무 우회적으로 해서 진행자들이 종종 그들을 위해 질문을 다시 말해야 합니다.

그렇다면 해킹이 그림이나 글쓰기처럼 작동한다면, 그것도 그만큼 멋진 일일까요? 결국, 우리는 한 번뿐인 삶을 살아가니까요. 위대한 일에 시간을 보내는 것이 좋을 것입니다.

불행히도, 이 질문에 답하기는 어렵습니다. 명성에는 항상 큰 시간 지연이 있습니다. 그것은 먼 별에서 오는 빛과 같습니다. 그림은 500년 전 사람들이 한 위대한 작업 덕분에 지금 명성을 얻고 있습니다. 당시에는 아무도 이 그림들이 오늘날 우리가 생각하는 만큼 중요하다고 생각하지 않았습니다. 당시 사람들에게는 우르비노 공작 페데리코 다 몬테펠트로가 언젠가 피에로 델라 프란체스카의 그림 속 이상한 코를 가진 남자로서 주로 알려질 것이라는 사실이 매우 이상하게 보였을 것입니다.

따라서 저는 지금 해킹이 그림만큼 멋져 보이지 않는다는 것을 인정하지만, 그림 자체도 전성기에는 지금만큼 멋져 보이지 않았다는 것을 기억해야 합니다.

우리가 어느 정도 확신을 가지고 말할 수 있는 것은 지금이 해킹의 전성기라는 것입니다. 대부분의 분야에서 위대한 작업은 초기에 이루어집니다. 1430년에서 1500년 사이에 만들어진 그림들은 여전히 타의 추종을 불허합니다. 셰익스피어는 전문 연극이 막 탄생할 때 등장하여 매체를 너무나 발전시켜 그 이후의 모든 극작가들은 그의 그림자 속에서 살아야 했습니다. 알브레히트 뒤러는 판화로, 제인 오스틴은 소설로 같은 일을 했습니다.

우리는 계속해서 같은 패턴을 봅니다. 새로운 매체가 등장하고, 사람들은 그것에 너무 흥분하여 처음 몇 세대 동안 대부분의 가능성을 탐구합니다. 해킹은 지금 이 단계에 있는 것 같습니다.

레오나르도 시대의 그림은 그의 작업이 그림을 그렇게 멋지게 만드는 데 기여한 만큼 멋지지 않았습니다. 해킹이 얼마나 멋진 것으로 판명될지는 우리가 이 새로운 매체로 무엇을 할 수 있느냐에 달려 있을 것입니다.

주석

[1] 사진이 그림에 끼친 가장 큰 해악은 최고의 주간 직업을 없앴다는 사실일 수 있습니다. 역사상 위대한 화가들 대부분은 초상화를 그리며 생계를 유지했습니다.

[2] 마이크로소프트는 직원들이 여가 시간에도 오픈 소스 프로젝트에 기여하는 것을 만류한다고 들었습니다. 하지만 지금은 너무나 많은 최고의 해커들이 오픈 소스 프로젝트에 참여하고 있어서, 이 정책의 주된 효과는 그들이 일류 프로그래머를 고용할 수 없게 만드는 것일 수 있습니다.

[3] 대학에서 프로그래밍에 대해 배우는 것은 책이나 옷, 데이트에 대해 배우는 것과 많이 비슷합니다. 고등학교 때 당신이 얼마나 나쁜 취향을 가졌었는지 말이죠.

[4] 여기 응용된 공감 능력의 예시가 있습니다. Viaweb에서 우리는 두 가지 대안 중 하나를 결정할 수 없을 때, "우리 경쟁자들이 가장 싫어할 만한 것은 무엇일까?"라고 물었습니다. 한때 경쟁사가 자신들의 소프트웨어에 기본적으로 쓸모없는 기능을 추가했지만, 우리가 가지지 못한 몇 안 되는 기능 중 하나였기 때문에 그들은 업계 언론에서 이를 크게 홍보했습니다. 우리는 그 기능이 쓸모없다고 설명하려 할 수도 있었지만, 우리가 직접 구현하는 것이 경쟁사를 더 짜증 나게 할 것이라고 판단하여 그날 오후 우리만의 버전을 급조했습니다.

[5] 텍스트 편집기와 컴파일러는 예외입니다. 해커들은 이것들을 설계하는 데 공감 능력이 필요하지 않습니다. 왜냐하면 그 자신이 전형적인 사용자이기 때문입니다.

[6] 음, 거의 그랬습니다. 사용 가능한 RAM을 다소 초과하여 불편한 디스크 스와핑을 많이 유발했지만, 몇 달 안에 추가 디스크 드라이브를 구매함으로써 해결할 수 있었습니다.

[7] 프로그램을 읽기 쉽게 만드는 방법은 주석으로 가득 채우는 것이 아닙니다. 저는 아벨슨과 서스먼의 인용구를 한 단계 더 나아가고 싶습니다. 프로그래밍 언어는 알고리즘을 표현하기 위해 설계되어야 하며, 컴퓨터에게 그것을 어떻게 실행할지 알려주는 것은 부수적인 일이어야 합니다. 좋은 프로그래밍 언어는 영어보다 소프트웨어를 설명하는 데 더 뛰어나야 합니다. 도로에 예상치 못한 급커브가 있는 부분에만 화살표가 있듯이, 독자들에게 경고해야 할 일종의 꼼수가 있을 때만 주석이 필요합니다.

감사합니다

이 초안을 읽어준 Trevor Blackwell, Robert Morris, Dan Giffin, Lisa Randall에게, 그리고 저를 강연에 초대한 Henry Leitner와 Larry Finkelstein에게 감사드립니다.