[해커와 화가] 해커, 프로그래밍 그리고 아름다운 소프트웨어 설계 방법

해커? 프로그래머?

해커라고? 그들은 남의 컴퓨터를 침범하는 족속들이 아닌가? 문외한에게는 그렇게 받아들여질 것이다. 하지만 컴퓨터 세상에서는 사물에 정통한 프로그래머들이 자신을 스스로 해커라고 부른다. 

 

컴퓨터 프로그램이라는 것은 순수한 텍스트다. 그리고 우리가 선태가는 언어는 어떤 내용을 말할 수 있는지 결정한다. 프로그래머는 프로그래밍 언어의 틀 안에서 생각하게 된다. 그러므로 당연히 프로그래밍 언어는 프로그래머의 생각에 큰 영향을 끼친다.

 

(역주) 우리가 사용하는 언어도 마찬가지라고 생각한다. 영어와 한국어만 비교해봐도 그렇다. 한국어는 수직적인 관계를 확실하게 표현하여 유교사상이 묻어나오는 반면에 방면에 영어는 그렇지 않다. 

 

건축과 공학의 경계선

나는 "컴퓨터 사이언스"라는 말이 마음에 들지 않는다. 세상에는 컴퓨터 사이언스라는 것은 존재하지 않기 때문이다. 해커들에게 있어서 컴퓨터는 자기를 표현하기 위한 매체에 불과하다. 건축가에게는 콘크리트가, 화가에게는 그림이 그런 역할을 하는 것과 마찬가지다. 결과적으로 한 학과 안에 수학자, 물리학자, 그리고 건축가를 뒤섞어 놓은 것이 같이 된다.

 

해커가 수행하는 일은 가끔 "소프트웨어 엔지니어링"이라는 말로 불리기도 하는데 이것은 컴퓨터 사이언에스에 못지않게 잘못된 인식을 심어준다. 훌륭한 소프트웨어 설계자가 엔지니어가 아니라는 것은 건축가가 엔지니어가 아닌 것처럼 자극히 자명하다.

 

건축과 공학의 경계선. 그 경계선은 '무엇'과 '어떻게'라는 두 개념 사이에 놓여있다. 건축가는 무엇을 할지를 결정하고 엔지니어는 어떻게 할지를 알아낸다.

 

'무엇'과 '어떻게'가 완전히 분리되어야 할 이유는 없다. 다만 어떻게 해야 할지를 이해하지 못한 채 무엇을 할지 결정하면 심각한 문제에 부딪힐 가능성이 있다. 하지만 해킹이라는 것은 분명 주어진 스펙을 단순히 어떻게 구현할 것인지 정하는 일이 아니다. 진정한 해킹이랑 사실 스펙 자체를 창조하는 것이다. 스펙을 만족시키는 최고의 방법은 대부분 그것을 실제로 구현해 보는 것이다.

 

아름다운 소프트웨어 설계 방법

해커가 진짜로 하는 일을 측정하는 것, 즉 그가 아름다운 소프트웨어를 설계하는지를 가리는 것은 훨씬 어려운 일이다. 좋은 설계를 판단하기 위해서는 판단하는 사람이 좋은 설계에 대한 감각을 가지고 있어야 하기 때문이다. 좋은 설계를 인식하는 것과 인식할 수 있다고 스스로 확신하는 것은 별도의 문제이다.

 

아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외적인 방법은 시간이다. 시간이 지남에 따라 아름다운 것만 은은히 세상에 퍼져있을 것이다.

 

나는 내게 다가오는 영감의 원천이 "컴퓨터"리는 말이 포함된 학과에 존재하는 것이 아니라 창조자들이 모여드는 영역에 존재함을 알게 되었다. 다시 말해 그림은 내게 어떤 계산 이론보다 풍부한 영감의 원천이 되어 주었다.

 

나는 오랫동안 프로그래밍 방식에 대해서 남몰래 부끄러워했다. 하지만 내가 그 당시에 화가나 건추가 같은 다른 창조자들이 일하는 방식을 알았더라면, 내가 프로그래밍하는 방식을 지칭하는 특별한 이름이 있다는 사실을 알 수 있었을 것이다. 그 이름은 바로 '스케치'다. 소설가, 화가, 그리고 건축가의 작업이 그런 것처럼 프로그램이란 전체 모습을 미리 알 수 있는 것이 아니라 작성해 나가면서 이해하게 되는 존재다.

 

이러한 깨달음은 소프트웨어 설계에 있어서 실질적인 의미를 갖는다. 그것은 프로그래밍이라는 것이 부드럽고 말랑말랑한 존재라는 엄연한 사실에 대한 재확인이다. 프로그래밍 언어는 당신이 이미 머릿속으로 생각한 프로그램을 표현하는 도구가 아니라, 아직 존재하지 않는 프로그램을 생각해 내기 위한 도구다. 볼펜이 아니라 연필인 셈이다. 정적인 타이핑은 내가 대학에서 배운 식으로 프로그래밍하는 경우라면 별로 나쁘지 않은 방법이다. 하지만 나는 내가 배운 식대로 프로그램을 작성하는 해커를 본 적이 없다. 해커에게 필요한 언어는 마음껏 내갈기고, 더럽히고, 사방에 떡칠할 수 있는 언어다. 엄격한 컴파일러 숙모와 마주 앉아 데이터 타입을 채운 찻잔을 무릎 위에 다소곳이 놓고 대화할 때 쓰는 언어가 아니다.

 

해킹은 과학과 다르다

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

 

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

 

소설가들도 같은 방법을 사용한다. 벤자민 프랭클린은 에디슨과 스틸리의 에세이에 담겨있는 논점을 요약하고 그것을 재구성하는 방법을 통해 글쓰기를 배웠다. 추리 소설의 거장 레이몬드 챈들러가 추리 소설의 기법을 배운 것도 이와 같다. (역주) 음악도 마찬가지이다. 그들은 초기에 표절이라는 소리를 들을 만큼 좋은 샘플을 차용하여 자신의 것으로 재해석한다. 그러한 과정을 겪으면서 결국 좋은 아티스트가 탄생하는 순간을 몇몇 봤다.

 

마찬가지로 해커들도 좋은 프로그램을 들여다봄으로써 프로그래밍을 배운다. 겉핥기식이 아닌 내부의 소스코드를 들여다보는 것이다. 오픈소스 운동의 장점 중에서 충분히 언급되지 않는 것 하나가 바로 이 운동이 프로그래밍을 배우는 과정 자체를 쉽게 만들었다는 점이다. 

 

프로그래밍. 그림 그리기.

우리가 그림 그리기에서 생각해 볼 수 있는 것 또 하나는 그림이 점진적으로 세공의 과정을 거쳐서 완성이 된다는 점이다. 그림은 대개 스케치에서 시작되어 세밀한 부분이 조금씩 더해진다. 하지만 단순 덧칠의 과정이 아니다. 때로는 처음의 구상이 잘못된 것으로 드러나기도 한다.

 

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

 

올바른 도구는 우리가 이러한 위험을 피하도록 도와준다. 좋은 프로그래밍 언어는 마치 유화 물감처럼 생각이 중간에 바뀌는 것을 쉽게 만들어 주어야 한다. 동적인 타이핑은 특정한 데이터 표현을 처음부터 고민할 필요가 없기 때문에 바로 이런 상황에 적합하다. 하지만 이와 같은 유연성을 위해서는 언어를 매우 추상적으로 만들어야 한다. 수정하기에 가장 쉬운 프로그램은 결국 짧은 프로그램이기 때문이다.

 

레오나르도 다빈치의 그림은 보이지 않는 섬세함이 모이고 쌓여 마침내 사람들 눈에 보이게 되어 결국 빛을 발했다. 마찬가지로 위대한 소프트웨어는 아름다움을 향해서 뜨겁게 타올라야 한다. 좋은 소프트웨어의 내부를 들여다보면 아무도 들여다볼 것이라고 생각되지 않는 곳조차 아름답다는 사실을 알게 될 것이다. 

 

해킹이라는 것은 그림을 그리는 일과 마찬가지로 일종의 순환 구조를 가진다. 떄론 새로 시작되는 프로젝트에 감격해서 하루에 열여섯 시간을 일하기도 한다. 그렇지만 어떤 때에는 재미라고는 도대체 눈곱만큼도 없을 때도 있다. 그림이든 해킹이든 격정적인 열망을 요구하는 순간이 있는가 하면, 조용히 반복되는 잔잔한 업무도 있다. 그래서 열정이 아주 식는 것을 방지하기 위해서 조용히 쉬는 순간이 왔을 때 할 만한 단순한 일들을 남겨두는 것도 좋은 방법이다.

 

함께 그리기

그림은 일을 어떻게 해야 할 것인가와 함께 어떻게 함께 일해야 하는지에 대해서도 가르쳐준다. 훌륭한 예술작품 중에서 많은 수가, 비록 많은 박물관의 벽에는 한 사람의 이름을 담고 있는 설명이 붙어있을지라도, 사실은 여러 사람에 의해서 만들어진 경우가 많다.

 

내가 알기에 화가들이 공동 작업을 통해서 그림을 그릴 때 여러 사람이 같은 부분에 대해서 겹치지 않도록 작업한다. 마스터가 주요한 부분을 그리고 나면 그의 조력자 들이 나머지 부분과 배경을 그리는 것이 일반적이었다. 하지만 어떤 사람에게 다른 사람이 이미 그린 부분 위에 덧칠을 하는 경우는 절대로 없었다.

 

이것은 소프트웨어에서의 협동 작업을 위해서도 의미 있는 모델이라고 생각한다. 너무 어렵게 생각할 것은 없다. 서너 명이 코드 한 조각을 해킹할 때 어느 한 사람도 그 코드를 배타적으로 소유한 것은 아니다. 따라서 그것은 마치 공동으로 사용하는 방처럼 여겨질 것이다. 황폐하고 버려진 들판 같은 분위기에 휩싸일 것이고, 안에는 조각조각 난 크러프트 코드가 쌓일 것이다. 올바른 방법은 프로젝트를 아주 정밀하게 정의된 모듈로 구분하고, 각 모듈에 주인을 할당하고, 그리고 가능하다면 모듈 사이에 존재하는 인터페이스는 마치 프로그래밍 언어 자체처럼 명확한 수준으로 정의하는 것이다.

 

프로그램은 오직 사람을 읽기 위해 작성된다

대부분의 소프트웨어는 그림과 마찬가지로 사람을 위해서 만들어진다. 해커가 위대한 작품을 남기기 위해서는 화가와 마찬가지로 감정이입을 할 줄 알아야 한다. 즉, 사물을 사용자의 입장에서 바라볼 줄 알아야 한다. 

 

내가 어렸을 때, 사물을 언제나 다른 사람의 시각에서 바라보도록 노력하라는 말을 듣곤 했다. 그땐 이 말에 별로 심각하게 귀 기울이지 않았다. 하지만, 그러지 말았어야 하는 건데! 나는 사물을 다른 사람의 입장에서 바라본다는 것이 곧 성공의 비밀이라는 사실을 나중에 깨달았다.

 

감정이입이라는 것이 자기희생을 뜻하는 것은 아니다. 사물을 다른 사람의 입장에서 바라본다는 것이 다른 사람의 이익을 대변한다는 뜻은 아니다. 예를 들어 백전백승 지피지기로 전쟁 같은 상황에서는 서로의 입장이 되어보려고 노력한다.

 

대부분의 창조자는 관객을 위해 작품을 만들어 낸다. 이때 다른 사람의 주의를 끌기 위해서는 그들이 필요한 것이 무엇인지 이해해야만 한다. 아마도 감정이입이야 말로 좋은 해커와 위대한 해커를 구분하는 결정적인 차이점일 것이다. 어떤 해커들은 영리하지만, 감정이입이라는 면에서는 혼자서 화투를 치는 사람처럼 자기중심적이다. 그들은 사물을 사용자의 관점에서 바라볼 줄 모르기 때문에 위대한 소프트웨어를 디자인하기 어렵다. 

 

어느 사람이 감정이입을 잘하는지 여부를 판별하는 좋은 방법은 기본 지식이 없는 사람에게 어떤 기술적인 내용을 설명해보라고 시키는 것이다. 평소에는 매우 영리함에도 불구하고 뭔가를 설명해주는 일에는 형편없이 서툰 사람을 적어도 몇 명은 알고 있을 것이다. 

 

소프트웨어가 수행해야 하는 일의 일부는 자기 자신을 설며하는 것이다. 따라서 좋은 소프트웨어를 만들기 위해서는 도대체 사용자가 얼마나 조금 알고 있는지를 이해해야 한다. 그들은 아무런 준비 과정도 없이 소프트웨어를 사용하기 시작할 것이고, 매뉴얼 같은 것은 읽을 생각조차 하지 않을 것이기 때문이다. 소프트웨어는 그들이 막연하게 추측할 만한 일을 알아서 수행할 필요가 있다.

 

소스코드도 마찬가지로 스스로를 잘 설명해야 한다. 만약 프로그래밍에 대해서 뭔가 한마디 인용하는 것이 허락된다면 내가 인용하고 싶은 것은 '컴퓨터 프로그램의 구조와 해석'의 시작 부분에 나와있는 다음과 같은 문장이다.

 

프로그램은 오직 사람이 읽기 위해서 작성되어야 한다. 컴퓨터가 그것을 실행하는 것은 부차적인 일이다.

 

당신은 단지 사용자를 위해서 감정이입을 하는 것이 아니라 당신의 소스코드를 읽는 독자를 위한 감정이입도 해야 한다. 당신 스스로가 얼마 후에는 그 소스코드를 읽는 독자 가운데 한 사람이 될 것이기 때문이다. 수많은 해커가 프로그램을 작성한 다음 6개월 뒤에 그 프로그램을 다시 열어보며 도대체 그것이 어떻게 동작하는지 기억나지 않아서 쩔쩔매는 경우가 적지 않다.

 

 

'해커와 화가' 中