해커와 화가

|

2003년 5월 (이 에세이는 하버드에서의 초청 강연을 토대로, 이전에 노스이스턴 대학에서 했던 강연을 포함해 작성되었습니다.)

나는 컴퓨터 과학으로 대학원 과정을 마친 후, 미술 학교에 가서 회화를 공부했다. 많은 사람들이 컴퓨터에 관심 있는 사람이 회화에도 관심을 갖는다는 사실에 놀라는 듯했다. 그들은 해킹과 회화가 매우 다른 종류의 일이라고 생각하는 것 같았다 — 해킹은 차갑고, 정확하며, 체계적이고, 반면 회화는 어떤 원초적 충동의 광란 어린 표현이라는 식으로 말이다.

이 두 이미지는 모두 틀렸다. 해킹과 회화는 매우 비슷한 점이 많다. 실제로, 내가 아는 다양한 유형의 사람들 중에서 해커와 화가는 가장 닮은 부류다.

해커와 화가의 공통점은, 이들 모두 창작자(maker)라는 데 있다. 작곡가, 건축가, 작가들과 마찬가지로, 해커와 화가는 좋은 무언가를 만들어내고자 한다. 이들은 엄밀히 말해 연구를 하는 것은 아니지만, 좋은 것을 만들려는 과정에서 새로운 기법을 발견하게 된다면 그보다 좋은 것은 없다.

나는 "컴퓨터 과학"이라는 용어를 별로 좋아하지 않는다. 가장 큰 이유는 그런 학문은 실제로 존재하지 않기 때문이다. 컴퓨터 과학은 관련성이 약한 여러 분야를 우연히 한데 뭉쳐놓은, 역사의 산물 같은 것이다. 예를 들어 한 쪽 끝에는 수학을 하는 사람들이 있지만, 그들은 DARPA의 연구 지원을 받기 위해 자신들이 하는 일이 컴퓨터 과학이라고 말한다. 중간에는 네트워크 데이터 라우팅 알고리즘의 동작처럼 컴퓨터의 자연사를 연구하는 사람들이 있다. 그리고 또 다른 극단에 해커들이 있는데, 이들은 흥미로운 소프트웨어를 쓰려고 애쓰며, 컴퓨터는 이들에게 건축가의 콘크리트나 화가의 물감처럼 하나의 표현 매체일 뿐이다. 마치 수학자, 물리학자, 건축가가 모두 같은 학과에 있는 격이다.

때때로 해커의 일을 "소프트웨어 엔지니어링"이라고 부르기도 하는데, 이 용어 역시 오해를 불러일으킨다. 훌륭한 소프트웨어 디자이너가 엔지니어라기보다 건축가에 가깝다. 건축과 엔지니어링의 경계가 뚜렷하지는 않지만 분명히 존재한다. 그것은 바로 무엇을(what) 할지와 어떻게(how) 할지의 차이이다: 건축가는 무엇을 할지 결정하고, 엔지니어는 어떻게 할지 도출한다.

'무엇'과 '어떻게'를 지나치게 분리하는 것은 좋지 않다. 어떻게 할지도 모르는 상태에서 무엇을 할지 결정하려 한다면 곤란해질 수 있다. 하지만 해킹은 사양을 구현(how)하는 것에 그치지 않는다. 해킹의 진수는 종종 사양 자체를 창조(what)하는 데 있으며, 가장 좋은 방법은 곧바로 구현해보는 것이다.

어쩌면 언젠가 "컴퓨터 과학"도 유고슬라비아처럼 각 구성 요소로 분해될지 모른다. 아마 그게 더 나을 수도 있다. 특히 나의 본향인 해킹이 독립할 수 있다면 더욱 그렇다.

이렇게 서로 다른 유형의 일을 하나의 학과에 묶는 것은 행정적으로는 편리하지만, 지적으로는 혼란스럽다. 이것이 내가 "컴퓨터 과학"이라는 명칭을 좋아하지 않는 또 다른 이유다. 어쩌면 중간에 있는 사람들은 실험 과학과 비슷한 일을 하고 있다고 볼 수 있다. 하지만 양 극단의 사람들, 해커와 수학자들은 엄밀히 말해 과학을 하고 있지 않다.

수학자들은 이런 점을 별로 개의치 않는다. 그들은 그냥 수학과의 다른 수학자들처럼 정리를 증명하는 데 열중하고, 아마 곧 자신들이 일하는 건물 간판에 "컴퓨터 과학"이 적혀 있음을 잊고 지낼 것이다. 그러나 해커들에게는 이 꼬리표가 문제다. 자신들의 열정이 과학으로 분류되면, 뭔가 과학적인 태도를 취해야 할 것만 같게 만든다. 그래서 해커들은 자신들이 정말로 하고 싶은 "아름다운 소프트웨어 디자인" 대신, 대학이나 연구소에서는 연구 논문을 써야 한다는 의무감을 갖게 된다.

운이 좋으면 논문은 단순한 형식적인 절차에 그치기도 한다. 해커는 멋진 소프트웨어를 만들고 그에 대해 논문을 쓴다. 논문은 소프트웨어의 성취를 대신하는 역할을 한다. 하지만 종종 이 불일치로 문제가 생긴다. 아름다운 것을 만드는 대신, 논문 쓰기에 더 적합한 어정쩡한 것을 만드는 쪽으로 표류하기 쉽다.

안타깝게도 아름다운 것이 좋은 논문 주제가 되지는 않는다. 첫째, 연구는 반드시 독창적이어야 한다 — 그리고 박사 논문을 써 본 사람은 누구나 알듯, 미개척 영역을 확실히 탐험하는 방법은 아무도 원하지 않는 땅을 먼저 차지하는 것이다. 둘째, 연구는 실질적이어야 한다 — 어색한 시스템일수록 논문 분량이 많다. 그 과정에서 어떤 벽을 어떻게 넘어야 했는지를 쓸 수 있기 때문이다. 처음부터 잘못된 전제를 세우면 좋은 연구 문제거리가 쏟아진다. AI 분야가 그 예다. 지식을 추상 개념을 표현하는 술어 논리의 목록 형태로 표현할 수 있다고 가정하면, 이 가정을 실현하는 방법에 관해 쓸 논문거리가 무수히 많아진다. 리키 리카르도 식으로 말하자면, "설명할 게 참 많다(Lucy, you got a lot of explaining to do)."

아름다움을 만드는 길은 기존 것을 미묘하게 변형하거나, 기존 아이디어를 약간 새로운 방식으로 조합하는 것이 많다. 이런 일은 논문으로 전달하기 어렵다.

그렇다면 왜 대학이나 연구소는 여전히 해커를 논문 실적으로 평가할까? '학업 적성'을 단순 표준화 시험으로 측정하거나, 프로그래머 생산성을 코드 라인 수로 재는 것과 같은 이유에서다. 이런 평가는 적용하기 쉽고, 어느 정도는 통하는 쉬운 평가 방법이기에 유혹적이다.

해커의 진짜 임무인 아름다운 소프트웨어 설계를 측정하는 것은 훨씬 더 어렵다. 좋은 설계를 평가하려면 디자인 감각이 필요하다. 그리고 좋은 디자인을 알아보는 힘과 자신의 판단에 대한 확신은, 어쩌면 음의 상관관계가 있을 만큼 별 상관이 없다.

외부에서 쓸 수 있는 유일한 평가는 시간뿐이다. 시간이 지남에 따라 아름다운 것은 살아남고, 추한 것은 버려진다. 하지만 이 과정에 필요한 시간은 한 세대를 넘길 수 있다. 사무엘 존슨은 작가의 명성이 자리를 잡으려면 100년이 걸린다고 말했다. 작가의 영향력 있던 친구들이 다 죽고, 그들의 추종자들까지 모두 죽어야 한다는 말이다.

해커들은 자신의 평판에 상당한 무작위 요소가 포함되는 것을 받아들여야 할 듯하다. 이는 다른 창작자와 다르지 않다. 오히려 해킹은 비교적 운이 좋은 편이다. 유행의 힘이 해킹에서는 회화에서만큼 강력하지 않다.

다른 사람의 오해보다 더 심각한 위험은 자신이 자기 일의 본질을 오해하는 것이다. 관련 분야는 아이디어를 찾는 곳이다. '컴퓨터 과학'이라는 이름 아래 있다 보면, 해킹이 이론적 컴퓨터 과학의 응용판이라는 착각을 하기도 쉽다. 대학원 내내 나는 컴퓨터 과학 이론을 더 알아야 한다는 불편한 의무감을 떨치기 어려웠다. 기말고사 후 3주 만에 관련 내용을 모두 잊었습니다만.

지금 생각해 보면 내 착각이었다. 해커가 컴퓨터 이론을 이해해야 하는 정도는 화가가 안료 화학을 알아야 하는 정도와 비슷하다. 시간/공간 복잡도와 튜링 완전성 개념 정도는 알아야 하겠지만, 그 정도면 충분하다. 실제로 화가가 알아야 할 물감의 화학은 그보다 훨씬 많다.

내가 보기엔 훌륭한 아이디어는 컴퓨터 관련 분야가 아니라, 다른 창작자가 있는 분야에서 더 많이 얻어진다. 회화는 내게 컴퓨터 이론보다 훨씬 풍부한 영감의 원천이었다.

예를 들어, 대학에서는 컴퓨터 앞에 앉기 전에 종이에 프로그램을 모두 설계하라고 배웠지만, 실제 나는 그런 방식으로 프로그래밍하지 않았다. 나는 컴퓨터 앞에 앉아서 프로그램을 썼고, 차근차근 완성도 높은 코드를 쓰면서 생각하기보다는, 처음은 완전히 망가진 코드를 쏟아내고 그것을 점차 다듬어 가는 방식을 선호했다. 디버깅은 오타나 실수를 잡는 최종 단계라고 배웠으나, 실상 내게 프로그래밍은 거의 디버깅이나 마찬가지였다.

한동안 이런 내 방식이 잘못되었다고 생각했다. 초등학교에서 배운 대로 연필을 잡지 않는 것처럼, 뭔가 잘못하고 있다는 죄책감이 있었다. 하지만 다른 창작자—화가, 건축가—들을 봤다면 내가 하는 방식에 이름이 있다는 사실을 알았을 것이다: 스케치(sketching)다. 내가 대학에서 배운 프로그래밍 방식이 전혀 잘못되었다고 본다. 작가, 화가, 건축가처럼 프로그램도 쓰면서 만들어가야 한다.

이런 깨달음은 소프트웨어 디자인에 직접적인 영향을 미친다. 프로그래밍 언어는 무엇보다 유연(malleable)해야 한다. 프로그래밍 언어란 이미 생각해놓은 프로그램을 표현하기 위한 수단이 아니라, 프로그램을 떠올리기 위한 도구여야 한다. 펜이 아니라 연필이어야 한다. 사람들이 대학에서 배운 방식대로 프로그램을 짠다면 정적 타이핑이 괜찮을 수 있지만, 내가 아는 해커들은 아무도 그렇게 하지 않는다. 우리는 낙서하고 지우고 반복할 수 있는 언어가 필요하지, 비유하자면 다기 위에 찻잔을 올려놓은 채 엄격한 숙모님 같은 컴파일러와 조심스럽게 대화해야 하는 언어가 필요하지 않다.

정적 타이핑 얘기가 나온 김에, 창작者(=maker)로서의 정체성은 과학 분야에서 흔한 문제, 즉 '수학 열등감(math envy)'을 예방해준다. 과학계 사람들은 은밀히 수학자가 자신들보다 똑똑하다고 믿는다. (아마 수학자들조차 그렇게 생각한다.) 그래서 과학자들은 자신의 연구를 가능한 한 수학적으로 보이게끔 만들고 싶어한다. 물리학처럼 자연과학에선 별 문제될 게 없지만, 자연과학에서 멀어진 분야로 갈수록 심각한 일이 벌어진다.

수식 한 페이지는 무척 그럴듯해 보인다. (팁: 그리스 문자 변수로 더 그럴듯하게 보일 수 있다.) 그러다 보니, 실제로 중요하거나 흥미로운 문제가 아니라 형식적으로 다룰 수 있는 문제를 택하는 유혹에 빠진다.

해커가 작가나 화가 같은 창작자로서의 소속감을 강하게 느낀다면 이런 유혹을 받지 않을 것이다(작가나 화가는 수학 컴플렉스를 겪지 않는다). 자신이 완전히 다른 일을 한다고 느끼니까. 해커도 그렇다고 본다.

대학과 연구소가 해커들에게 자기가 원하는 연구를 하지 못하게 한다면, 해커의 자리는 회사여야 할 것이다. 안타깝게도 대부분의 기업도 해커를 자기 뜻대로 일하게 두지 않는다. 대학과 연구소는 해커를 과학자로 강요하고, 회사는 엔지니어로 강요한다.

나는 이를 최근에야 몸소 알게 되었다. 야후가 Viaweb을 인수했을 때 나는 뭘 하고 싶은지 물었고, 사업 쪽은 별로였으니 그냥 코딩만 하고 싶다고 했다. 그런데 야후에서의 해킹이란 의미는, 소프트웨어를 "만드는 것"이 아니라, 구현하는 것이었다. 프로그래머는 제품 매니저의 '비전'(정말 비전이 있다면)에 따라 코드를 쓰는 기술자로 여겨졌다.

대기업에선 이 방식이 디폴트다. 결과의 표준편차(위험)를 줄이기 위해서다. 소프트웨어 설계를 제대로 할 수 있는 해커는 소수이고, 경영진이 그들을 골라내기도 힘들다. 그래서 대개 위대한 해커 한 명에게 미래를 맡기기보다는 모든 설계를 위원회 방식(=기획자 중심)으로 하고, 해커는 단순히 구현만 담당하도록 한다.

언젠가 돈을 벌고 싶다면, 이 점을 꼭 명심해야 한다. 이 점이 스타트업이 대기업을 이기는 이유 중 하나다. 대기업은 설계 결과의 표준편차를 낮춰 참사를 피하려 한다. 하지만 진폭을 깎으면 최악뿐 아니라 최고도 함께 잃는다. 이게 대기업에겐 문제가 안 되는데, 동종 대기업보다 덜 구린 게 승리의 요인이기 때문이다.

따라서 대기업의 소프트웨어 설계 방식이 제품 매니저에 의해 이루어진다면, 스타트업이 그들과 디자인 전쟁을 벌인다면 대기업은 결코 따라올 수 없다. 물론 이런 기회는 별로 많지 않다. 성 안에 적을 끌어들여 육박전을 하기는 힘든 것처럼, 대기업과 정면 승부하기 어렵기 때문이다. 예컨대 마이크로소프트보다 나은 워드 프로세서를 쓰기란 쉬울지 몰라도, 그들이 OS 독점이라는 성에 안주하기 때문에 제대로 경쟁 자체가 성립되지 않는다.

따라서 진짜 디자인 승부는 아직 뚜렷한 성벽이 없는 신생 시장에서 가능하다. 바로 그 곳에서 용감한 방식으로, 설계와 구현을 한 팀이 동시에 진행하며 대박을 칠 수 있다. 마이크로소프트도 처음엔 그렇게 했다. 애플도, 휴렛팩커드도 마찬가지다. 웬만한 성공한 스타트업은 모두 그랬을 것이다.

그러니 뛰어난 소프트웨어를 만들고 싶다면, 직접 스타트업을 만드는 길이 있다. 하지만 여기엔 두 가지 문제가 있다. 하나는 스타트업을 하면 코딩 말고도 할 일이 너무 많다는 것. Viaweb에서 나는 운이 좋으면 해킹에 하루의 1/4은 투입할 수 있었다. 나머지 3/4은 지루한 것부터 아찔한 것까지 각종 잡일이 이어졌다. 이걸 체크할 수 있을만한 경험담이 있는데, 이사회 미팅을 하다가 충치 치료를 받으러 치과에 간 적이 있다. 치과 의자에 누워 드릴을 기다릴 때, 나는 마치 휴가를 온 기분이었다.

두 번째 문제는, 돈이 되는 소프트웨어와 재미있는 소프트웨어가 거의 겹치지 않는다는 점이다. 프로그래밍 언어를 만드는 건 재미있지만 돈 되지 않는다. 마이크로소프트의 첫 제품은 프로그래밍 언어였으나, 지금은 아무도 그런 걸 사지 않는다. 돈을 벌려면, 누구도 공짜로 풀고 싶어하지 않는 진짜 골치 아픈 문제를 해결해야 한다.

모든 창작자가 이 문제를 겪는다. 가격은 수요와 공급에 의해 결정되기에, 작업하는 재미가 큰 것보다 개별 고객의 평범한 문제를 해결하는 것에 수요가 더 많다. 오프 브로드웨이 연극에 출연해도, 무역 전시회에서 고릴라 탈을 쓰고 부스에 들어가는 것만큼 돈이 안 된다. 소설 쓰는 것보다 음식물 처리기 광고 카피 쓰는 게 더 잘 벌린다. 프로그래밍 언어 해킹은 기업의 레거시 데이터베이스를 웹서버와 연결해주는 일보다 돈이 안 된다.

이 문제에 대한 답은 거의 모든 창작자들이 이미 아는 콘셉트, 즉 '주간 직업(day job)'에 있다. 이 말은 원래 밤에 공연하는 뮤지션에게서 나온 표현이다. 한마디로 돈을 벌기 위한 일 하나, 사랑하는 일 하나, 두 가지 일을 동시에 한다는 뜻이다.

거의 모든 창작자는 경력 초반에 일과 작업을 병행한다. 화가와 작가는 특히 그렇다. 운이 좋으면 본업과 비슷한 주간 직업을 가지게 된다. 뮤지션이 음반점에서 일하는 것처럼, 해커도 언어/OS를 본업으로 만들면서 주간 직업으로 관련된 일을 할 수도 있다. [1]

즉, 해커가 낮에는 직장에서 일하고, 비는 시간엔 아름다운 소프트웨어를 만든다는 게 새로운 제안은 아니다. 오픈소스 해킹이란 바로 그것이다. 내가 하고 싶은 말은, 오픈소스라는 모델이 아마 올바른 모델일 것이라는 점이며, 이는 다른 창작자에게서 독립적으로 확인된 방식이라는 뜻이다.

고용주가 해커가 오픈소스 프로젝트에 참여하는 것을 꺼린다는 사실이 오히려 신기하다. Viaweb에서는 오히려 오픈소스 경험이 없는 해커는 채용을 꺼렸을 것이다. 면접에서 우리가 가장 신경 썼던 것은 이 사람이 남는 시간에 어떤 소프트웨어를 만드는가였다. 정말로 사랑하지 않으면 어떤 일도 제대로 할 수 없다. 해킹을 사랑한다면, 자기도 모르게 무언가를 만들고 있게 마련이다. [2]

해커는 과학자가 아니라 창작자이므로, 해킹을 설명할 비유나 은유를 찾으려면 과학 대신 창작자들의 영역에서 찾아야 한다. 회화에서 해킹이 배울 수 있는 게 뭐가 있을까?

회화의 예에서 얻거나 다시 확인할 수 있는 것 중 하나는 해킹의 학습 방법이다. 회화는 주로 직접 해보면서 배운다. 해킹도 마찬가지다. 대부분의 해커는 대학에서 프로그래밍 과목을 들어서가 아니라, 13살 때부터 자기 프로그램을 써 보며 해킹을 배운다. 대학 과정마저도 해킹은 해킹을 하면서 배운다. [3]

화가는 작품의 연대별 변화를 살펴보면, 각 그림이 이전 그림에서 배운 것을 기반 위에 지어졌음을 알 수 있다. 한 그림의 어떤 부분이 아주 뛰어나게 작동한다면, 그 요소의 초기 버전이 이전 작은 그림에 보통 나타난다.

대부분의 창작자는 이런 식으로 작업하는 것 같다. 작가, 건축가도 그렇다. 해커들도 화가처럼 한 프로젝트에 몇 년씩 계속 덧붙이기보다는, 때때로 처음부터 다시 시작해서, 새롭게 재정립하는 것이 좋지 않을까 싶다.

해커가 해킹을 하면서 배운다는 점은, 해킹과 과학이 얼마나 다른지를 보여주는 또 다른 예다. 과학자는 과학을 실험실 실습(lab)이나 문제집을 풀면서 배운다. 즉, 이미 입증된 일을 완벽하게 따라한다. 그러다 점점 진짜 독창적인 일에 도전한다. 반면 해커는 처음부터 독창적인 일을 한다. 다만 아주 형편없을 뿐이다. 해커는 독창적으로 시작해서 점차 실력을 키우고, 과학자는 완벽하게 출발해 점차 독창적으로 발전한다.

다른 한 가지 방법은 예제를 통해 배우는 것이다. 화가에게 미술관은 테크닉의 참고 도서관과 같다. 수백 년 동안 화가의 전통 교육엔 대가의 작품을 모작하는 과정이 포함됐다. 모작 과정에서 그림의 제작 방법을 면밀히 살펴보게 된다.

작가도 그랬다. 벤저민 프랭클린은 에디슨과 스틸의 수필 주요 논점을 요약하고, 나중에 그 글을 다시 재현함으로써 글쓰기를 배웠다. 레이먼드 챈들러도 탐정 소설로 같은 똑같이 따라 했다.

해커 또한 훌륭한 소프트웨어(혹은 소스 코드) 예제를 보고 프로그램을 배울 수 있다. 오픈소스 운동이 '배우는 방식'을 통해 해킹을 쉽게 만들었다는 점은 아직 잘 알려지지 않았다. 내가 프로그래밍을 배울 때는 책에 실린 예제에 의존해야 했다. 당시 유일한 대형 코드베이스는 유닉스였지만, 이것조차 오픈소스가 아니었다. 대부분은 1977년에 쓰인 존 라이언스(John Lions)의 책의 불법 복사본을 몰래 읽었으며, 이 책은 1996년까지 공식 출판이 허가되지 않았다.

회화에서 배울 수 있는 또 한 가지는 회화가 점진적으로 다듬어지는 방식이다. 그림은 보통 스케치로 시작해서 점차 디테일이 채워진다. 하지만 단순히 채워 넣는 과정만은 아니다. 가끔 애초의 계획이 틀렸다는 게 드러난다. X-ray로 살펴보면 수많은 그림이 팔이나 얼굴 등 세부를 나중에 옮기고 고친 흔적이 나온다.

해킹 또한 그래야 한다고 본다. 완벽한 스펙을 기대하는 것은 비현실적이다. 오히려 처음부터 프로그램이 중간에 방향을 바꿀 가능성이 있다는 것을 인정하고, 유연하게 구현하는 편이 현명하다.

(대기업 조직에서는 이런 유연성이 힘들기에, 스타트업이 이점이 있다.)

일찍이 '프리미티브한 최적화(premature optimization)' 위험성에 대해선 누구나 알고 있듯이, 나는 '프리미티브한 설계(premature design)' 위험성— 프로그램이 무엇을 할지 지나치게 빨리 결정해버리는 것 —도 마찬가지로 경계해야 한다고 생각한다.

좋은 프로그래밍 언어는, 유화물감처럼, 맘이 바뀌었을 때 쉽게 고칠 수 있어야 한다. 동적 타이핑이 좋은 것은 초기 단계에서 데이터를 어떤 식으로 표현할지 미리 결정할 필요가 없기 때문이다. 하지만 진정한 유연성의 열쇠는 언어가 매우 추상적이라는 점이다. 가장 고치기 쉬운 프로그램은 아주 짧은 프로그램이다.

이상하게 들릴지 모르겠지만, 훌륭한 그림은 반드시 '그럴 필요 이상으로' 좋아야 한다. 예를 들어, 레오나르도 다빈치는 내셔널 갤러리에 소장된 지네브라 데 벤치 초상화에서 그녀 머리 뒤에 노송나무를 그렸다. 이 나무는 잎사귀 하나하나 세심하게 그려졌다. 평범한 화가라면 배경에 머리띠만 그렸다 하며 대충 처리했을 것이다.

레오나르도는 그렇지 않았다. 그림의 일부가 얼마나 볼 만한 대상인지는 전혀 신경 쓰지 않았다. 그는 마이클 조던처럼 집요했다.

이런 집요함은 결국, 보이지 않는 디테일이 합쳐져 시각적으로 느껴진다. 사람들은 지네브라 데 벤치 초상화를 지날 때 작가가 레오나르도 다빈치인지 확인하기도 전, 그림에 눈길이 딱 멎기도 한다. 수많은 미세한 디테일이 모여 뭔가 놀라운 아름다움을 만든다. 마치 수천 명의 청아한 목소리가 조화를 이루는 합창단처럼.

훌륭한 소프트웨어 역시 아름다움에 대한 집착이 필요하다. 좋은 소프트웨어의 내부는, 아무도 들여다보지 않을 거라고 생각되는 부분까지도 아름답다. 내가 내 코드가 훌륭하다고 단언하는 건 아니지만, 코드에 대해 일상생활에서 그랬다면 약을 처방받았을 행동을 보인다. 들여쓰기가 엉망이거나 변수명이 추하면 미쳐버릴 거 같다.

해커가 단순한 구현자라면, 설계를 차례대로 코드로 옮기는 사람이라면, 순서대로 도랑을 파듯 코딩해도 된다. 하지만 해커가 창작자라면, 영감을 반드시 고려해야 한다.

해킹도, 회화와 마찬가지로 작업이 사이클을 돈다. 어떤 때는 새로운 프로젝트에 흥분해 16시간씩 내리 작업하고 싶고, 어떤 때는 아무것도 흥미롭지 않다.

좋은 작업을 하려면 이 주기를 받아들여야 한다. 오르막길에서 수동 변속 차량의 클러치를 어느 순간엔 살짝 떼듯, 지나친 야심이 멈추지 않게 한발 물러서는 지혜가 필요하다. 회화든 해킹이든 어떤 일은 엄청나게 도전적이고, 어떤 일은 편안히 할 수 있다. 넘치는 원동력이 식을 때를 대비해 쉽고 사소한 작업을 일부 남겨두는 것이 좋다.

해킹에서는 실제로 버그를 아껴 두기도 한다. 난 디버깅을 좋아한다. 해킹이 사람들 상상대로 정말로 단순한 유일한 시간이다. 제약이 명확하고 해야 할 일이 뚜렷하다. 프로그램이 x를 해야 하는데 y를 하고 있다면, 어디서 잘못됐는지 찾기만 하면 된다. 결국 반드시 답을 찾게 된다. 마치 벽에 페인트칠을 하듯 마음이 편하다.

회화의 예는 우리의 작업 방식뿐 아니라, 협업 방식에도 통찰을 준다. 위대한 예술 작품 중 상당수는 여러 명이 만든 작품이라는 점은, 미술관 벽에 이름은 하나만 적혀 있지만, 알고 보면 그렇다. 레오나르도도 베로키오의 공방에서 세례받는 그리스도의 천사 한 명을 그렸다. 이런 협동은 당시에는 표준이었다. 미켈란젤로는 시스티나 성당의 천장 벽화를 직접 다 그려서 특별한 열정을 가진 걸로 여겨졌을 정도다.

화가들이 한 그림에 여러 명이 참여해도, 같은 부분을 함께 그리지 않는다. 마스터가 주요 등장인물을 그리고, 조수들이 다른 부분과 배경을 그렸지만, 서로가 서로 작업 위에 덧칠하지는 않았다.

이 점을 소프트웨어 협업에도 적용할 수 있다고 본다. 너무 극단으로 몰고가선 안 되며, 세세한 부분까지 여러 사람이 다 같이 만지는 건 방이 공용 휴게실처럼 곧 황폐해지고 방치된다. 모듈을 명확하게 나누고, 각 모듈에 확실한 주인을 두고, 모듈 간 인터페이스를 프로그래밍 언어처럼 명료하게 설계하는 것이 바람직하다.

회화처럼, 대부분 소프트웨어도 인간 관객을 위한 것이다. 그래서 해커 역시 좋은 작품을 만들려면 공감 능력(empathy)이 반드시 필요하다. 사용자의 입장에서 생각할 수 있어야 한다.

어릴 때, 내게 항상 남의 입장에서 생각하라고 했지만, 진짜 의미는 결국 남이 원하는 대로 따르라는 뜻이었다. 그래서 공감이란 것을 일부러 무시하며 살았다.

그러나 그건 내 큰 오산이었다. 남의 입장에서 사물을 보는 것은 거의 모든 성공의 비결이다. 내 이익만 챙기는 게 아니라, 이해관계를 거꾸로 생각하는 상황(가령 전쟁)엔 남의 시야를 이해하는 것이 더욱 유리하다. [4]

대부분 창작자는 인간 관객을 염두에 두고 작품을 만든다. 관객에게 깊이 다가가려면 그들이 무엇을 원하는지 알아야 한다. 역사상 거의 모든 명화는 인물을 그린 것이다. 사람에게는 사람이 가장 흥미로운 법이다.

공감 능력은 훌륭한 해커와 위대한 해커를 가르는 가장 중요한 차이일 것이다. 머리는 비상하지만 공감 능력이 전혀 없는 해커도 많다. 그런 사람은 사용자의 관점에서 문제를 이해하지 못해 위대한 소프트웨어를 설계하기 힘들다. [5]

공감력의 수준은 기술 용어를 모르는 사람에게 기술적 질문을 설명하는 모습을 보면 쉽게 알 수 있다. 다들 그런 사람을 몇 명 떠올릴 수 있을 것이다. 예를 들어, 누가 프로그래밍 언어가 뭐냐고 물으면 "고급 언어란 컴파일러가 받아서 오브젝트 코드를 만들어내는 소스 언어"라고 답한다. 고급 언어? 컴파일러? 오브젝트 코드? 프로그래밍 언어가 뭔지 모르는 이라면 이런 용어는 당연히 알지 못한다.

소프트웨어가 해야 하는 일 중 하나는 자신을 스스로 설명하는 일이다. 좋은 소프트웨어를 쓰려면 사용자가 얼마나 이해도가 낮은지 항상 염두에 둬야 한다. 사용자는 아무런 준비 없이 소프트웨어와 마주하며, 처음 기대한 대로 동작하지 않으면 매뉴얼도 거들떠보지 않는다. 이 점에서 내가 여태 봤던 최고의 시스템은 1985년 출시된 맥킨토시이다. 이 제품은 거의 유일하게, 알아서 "제대로 동작"했다. [6]

소스 코드 자체도 설명 가능해야 한다. 내가 프로그래밍에 관해 남에게 꼭 한 구절을 남겨야 한다면 Structure and Interpretation of Computer Programs 첫머리 글귀일 것이다.

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

사용자뿐만 아니라 코드를 읽게 될 사람(=미래의 나)을 위해서도 공감이 필요하다. 나도 포함해서, 많은 해커들이 과거에 자신이 쓴 코드를 6개월 후 보면 무슨 코드를 썼는지 도통 이해하지 못했다는 경험담을 갖고 있다. 이 경험 이후 Perl을 포기한 사람도 많다. [7] 공감력 부족은 지능과 어울려, 일부 집단에선 오히려 그것이 미덕처럼 여겨지기도 한다. 하지만 상관관계는 없다. 수학이나 자연과학을 잘하려면 공감력은 거의 배울 필요조차 없고, 이 분야 사람들은 똑똑하다 보니 둘 사이에 연관성이 있는 듯 비친 것이다. 하지만 둔한데 공감력도 없는 부류 역시 많다. 예컨대 라디오 쇼에 전화하는 사람들의 장황한 질문을 들어보라. 종종 진행자가 질문을 알아듣고 재정리해야만 핵심을 알 수 있다.

그렇다면 해킹이 회화나 문학처럼 멋진 일일까? 인생은 한 번뿐이니 정말 멋진 무언가에 인생을 걸고 싶지 않은가?

불행히도 이 질문에 정답을 내리긴 어렵다. 명성에는 항상 큰 시차(time lag)가 존재한다. 마치 먼 별에서 오는 빛같다. 지금 회화가 현재의 위상을 갖게 된 건 500년 전 예술가들 덕분이다. 그 당시는 지금 우리가 갖는 만큼 명화가 중요하다고 아무도 생각지 않았다. 우르비노 공작 페데리코 다 몬테펠트로가 훗날 기이한 코의 초상화 속 주인공으로 더 소문나리라곤 당시 사람들이 상상도 못했을 터다.

지금 해킹이 회화만큼 멋져 보이지 않는 것은 사실이지만, 회화 역시 그 절정기에 오늘만큼 멋진 예술로 평가받지는 않았다.

한 가지 확실히 말할 수 있는 건, 바로 지금이 해킹의 영광시대라는 점이다. 대부분의 분야는 초창기 위대한 작업이 쏟아진다. 1430~1500년 사이에 제작된 그림들은 아직도 따라올 자가 없다. 셰익스피어는 전문 연극이 막 태동하던 시점에 등장했고, 그 한계까지 밀어붙여 이후 모든 극작가들이 그 그늘 아래 살아가게 됐다. 뒤러는 판화에서, 제인 오스틴은 소설에서 마찬가지였다. 새로운 매체가 등장하면, 사람들은 전 세대 내에 거의 모든 가능성을 탐구한다. 해킹 역시 이 단계에 있다.

회화도 레오나르도의 시대에는 지금만큼 멋진 예술이 아니었다. 해킹이 얼마나 멋진 매체가 될지는 앞으로 우리가 이 매체로 무엇을 하느냐에 달려 있다.

주

[1] 사진술이 회화에 끼친 최대 피해는, 최고의 밥벌이(job)를 없앤 것이다. 역사상 대다수 위대한 화가는 초상화로 생계를 꾸렸다.

[2] 마이크로소프트는 직원이 여가에 오픈소스 프로젝트에 참여하는 것조차 막는다고 들었다. 그런데 현재 최고의 해커 대다수가 오픈소스 프로젝트에서 활동하기 때문에, 이런 정책은 당장 1급 프로그래머 채용을 오히려 힘들게 할 수도 있다.

[3] 대학에서 배우는 프로그래밍 지식은 학생들의 고교 시절 '구린 감각'을 깨닫게 해준다는 점에서, 문학/의상/연애에 관한 대학 강의와 비슷하다.

[4] 공감력의 실제 활용 사례. Viaweb에서는 정책 결정에서 두 대안 중 못 고르겠으면 "경쟁사가 가장 싫어할 것은 무엇일까?"를 물었다. 예컨대, 경쟁사가 우리에게 없는 기능을 추가했고, (사실 쓸데없는 기능이었지만) 우리보다 자랑거리라며 언론 플레이를 했다. 우리는 그 기능이 쓸데없다는 설명하는 대신, 그냥 우리도 즉석에서 그 기능을 구현했다. 이것이 경쟁사를 더 자극할 거라 생각했기 때문이다.

[5] 단, 텍스트 에디터나 컴파일러는 예외다. 해커는 이런 도구의 전형적 사용자이기 때문에 공감력 필요 없이 설계할 수 있다.

[6] 단, 그 당시 RAM 용량을 약간 초과해서 불편한 디스크 스왑이 있었고, 이것은 몇 달만 기다리면 추가 드라이브 구매로 해결할 수 있었다.

[7] 프로그램을 읽기 쉽게 만드는 비결은 주석을 잔뜩 다는 것이 아니다. Abelson과 Sussman의 명언을 한 발 더 나아가 프로그램 언어 자체가 알고리즘을 설명하기에 영어로 설명하는 것보다 나아야 한다고 본다. 단지 예상치 못한 꼼수(kludge)가 있을 때만 주석이 필요하다. 이건 도로에서 예기치 않은 급커브 구간만 화살표 표시가 있는 것처럼.

감사의 글 - Trevor Blackwell, Robert Morris, Dan Giffin, 및 Lisa Randall는 이 글의 초고를 읽어주었고, Henry Leitner와 Larry Finkelstein이 강연 기회를 주신 데 감사드립니다.