본문 바로가기

Books in Life/2009

해커와 화가

해커와 화가해커와 화가 - 10점
폴 그레이엄 지음, 임백준 옮김/한빛미디어

드디어 해커와 화가를 읽었습니다. :-)

그토록 사고 싶었지만 품절인 관계로 Lisp을 좋아하는 사람들의 그룹(한국 리스퍼)의 별파란님께서 빌려주셔서 읽었습니다.

폴 그레이엄(Paul Graham)이란 분의 독특하지만 새로운 시각으로 프로그래밍 언어와 IT 세계를 바라볼 수 있었습니다.
Lisp이란 언어를 기반으로 만든 쇼핑몰 웹 어플리케이션을 Yahoo에 판매하여 많은 수익을 얻은 인문학적인 프로그래머 및 해커로 기억되길 원하는 폴 그레이엄(Paul Graham)!!

한번쯤 읽어보면 프로그래밍 언어와 IT를 바라보는 새로운 시각에 대하여 알 수 있게 될 것 같습니다.
다만 저자의 독특한 사고 체계에 대하여 너무 심각하게 생각할 필요는 없을듯 합니다.

그와 우리는 서로 다르기 때문이죠 :-)

여튼 중요한 내용은 다음과 같습니다.



2장. 해커와 화가

해커와 화가의 공통점은 우선 그들이 둘 다 무언가를 창조한다는 사실이다.

나는 "컴퓨터 사이언스"라는 말이 마음에 들지 않는다. 세상에는 컴퓨터 사이언스라는 것이 존재하지 않기 때문이다. 컴퓨터 사이언스라는 말은, 예전에 유고슬라비아가 그랬던 것처럼, 그저 겉으로 보기에 서로 연관된 것처럼 보일 뿐인 영역을 한꺼번에 쓸어 담는 그룻에 불과하다.

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

건축과 공학의 경계선이 분명한 것은 아니지만 아무튼 그것은 존재한다. 그 경계선은 "무엇"과 "어떻게"라는 두 개념 사이에 놓여있다.

건축가는 무엇을 할지를 결정하고 엔지니어는 어떻게 할지를 알아낸다. "무엇"과 "어떻게"가 지나치게 분리되어야 할 이유는 없다.
다만 어떻게 해야할지를 이해하지 못한 채 무엇을 할지를 결정하면 심각한 문제에 부딪힐 가능성이 있다.

하지만 해킹이라는 것은 분명 주어진 요구사항(Spec)을 단순히 어떻게 구현할 것인지 정하는 일이 아니다. 진정한 해킹이란 사실 요구사항 자체를 창조하는 것이다. 요구사항을 만들어 내는 최선의 방법은 그것을 실제로 구현해 보는 것인 경우가 많다.


아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외적인 방법은 시간이다. 시간이 지남에 다라서 아름다운 것은 번창하고 못난 것은 사라진다.

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

결국 훌륭한 소프트웨어를 만드는 방법의 하나는 자기 자신의 스타트업 회사를 만드는 것이다.

거의 모든 창조자들은 자신의 경력을 처음 쌓기 시작하는 무렵에는 임시방편적인 일을 갖기 마련이다. 화가와 소설가는 특히 더 그런 것으로 유명하다. 운이 좋다면 본업과 관련있는 일을 얻을 수 있다. 해커들은 임시직을 갖는 한편 뭔가 멋진 소프트웨어를 개발하기 위한 일을 진행해야 한다는 게 새로운 아이디어는 아니다. 오픈 소스 해커들이 하는 일이 바로 그것이기 때문이다. 내가 말하고자 하는 것은 결국 오픈 소스야 말로 올바른 모델이 아닌가 하는 점이다. 다른 분야의 창조자들이 이미 그점을 확인해주고 있다.

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


하지만 레오나르도는 달랐다. 그가 자신의 그림에 열과 성을 쏟아 붓는 정도는 다른 사람들이 얼마나 자세히 그림을 들여다 볼 것인가와 아무런 상관이 없었다. 그런 점에서 그는 마이클 조던과 닮았다. 두 사람 모두 자기 일에 대해서 만큼은 가차없이 냉혹한 것이다.
보이지 않는 섬세함이 모이고 쌓이면 마침내 준에 보이게 되는 법이기 때문에 냉정한 사람은 결국 승리하기 마련이다.

이와 마찬가지로 위대한 소프트웨어는 아름다움을 향해서 뜨겁게 타올라야 한다. 좋은 소프트웨어의 내부를 들여다 보면 아무도 들여다 볼 것이라고 생각되지 않는 곳조차 아름답다는 사실을 알게 될 것이다.


대부분의 소프트웨어는 그람과 마찬가지로 사람을 위해서 만들어진다. 그리고 해커가 뭔가 위대한 작품을 남기기 위해서는 마찬가지로 감정이입을 할 줄 알아야 한다. 즉 여러분은 사람을 사용자 입장에서 바라볼 줄 알아야 하는 것이다.


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

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

당신은 단지 사용자를 위해서 감정이입하는 것이 아니라 당신의 소스코드를 읽는 독자를 위한 감정이입도 해야 한다. 당신 스스로가 얼마후에는 그 소스코드를 읽는 독자 가운데 한 사람이 될 것이기 때문이다.

해킹이 결국 그림이나 소설과 비슷하다면 또한 그림이나 소설만큼 멋진 일일까? 우리의 인생은 단 한번분이다. 그래서 인생을 뭔가 멋진 데에 쓰는 것은 중요하다.

어느 정도 확신을 갖고 말할 수 있는 것은 "해킹의 전성기는 바로 지금"이라는 사실이다.



3장. 우리가 말할 수 없는 것

좋은 과학자는 전통적인 지혜를 무시하는 것이 아니라, 그 지혜를 깨뜨리기 위해 노력을 기울이는 사람이다.

이유가 무엇이든지 머릿속에 충격적인 생각을 떠올리는 데 있어서 지성과 의지가 뚜렷한 연관성을 보여준다.




4장. 좋은 불량 태도

대부분의 언론 매체들은 "해커"를 누군가 남의 컴퓨터에 침입하는 사람이라는 의미로 사용한다. 하지만 프로그래머 사이에서는 좋은 프로그래머라는 의미다.
이 두가지 의미는 서로 연결되어 있다. 프로그래머에게 있어서 "해커"란 문자 그대로 어떤 것에 정통했다는 의미를 담고 있다. 즉 컴퓨터가 원하든 말든 컴퓨터를 원하는 대로 조작할 수 있는 사람이라는 의미이다.

미국을 세웠던 아버지 세대가 그들 자신에게 했던 말을 읽어보면 그들은 꼭 해커처럼 보인다.
"정부에 저항하는 영혼은", 이라고 제퍼슨은 썼다. "매우 소중하기 때문에 나는 그 영혼이 언제나 깨어 있기를 희망합니다."



5장. 또 하나의 길

이제 "당신의 컴퓨터"라는 개념은 사라져가고 있으며 대신 "당신의 데이터"라는 개념이 도래하고 있다. 그 데이터는 어떤 컴퓨터에서도 접근이 가능해야 한다. 사실 꼭 컴퓨터일 조차 없는 어떤 클라이언트에서 접근이 가능해야 한다고 말하는 것이 더 정확할 것이다.

소프트웨어도 이와 똑같다. 어떤 생각을 구현하기 위해서 일하는 동안 더 많은 생각이 떠오르는 것이다.
그래서 어떤 생각을 창고에 넣어 둔다는 것은 그 생각의 구현을 연기한다는 문제뿐만이 아니라 그것을 구현하는 동안 떠 올렸을지 도 모르는 수 많은 다른 좋은 생각 역시 창고에 넣어 둔다는 문제를 낳는다. 따라서 그것은 새로운 생각들이 밖으로 나오지 못하게 억누르는 결과를 가져온다. 뭔가 새로운 기능에 대한 상각이 막 떠오르려고 하는 무렵에 창고 안을 힐끔 보고서 "하지만 다음 릴리즈를 위해서 해야할 일이 창고 안에 저렇게 만은걸"하고 생각하는 것이다.

프레드 브륵수(Fred Brooks)가 "신기한 맨먼스(The Mythical Man-Month)"에서 지적한 것처럼, 프로젝트에서 사람을 더 많이 투입하는 것은 오히려 프로젝트의 진행 속도를 둔화시킨다. 개발자 사이에 연결할 수 있는 선의 수는 팀의 크기가 증가함에 따라서 기하급수적으로 늘어난다. 그룹이 커질수록 그들은 소프트웨어가 어떻게 동작하해야 하는지에 대한 논의에 더 많은 시간을 투여해야 하고, 미처 예상하지 못한 버그가 끊임없이 출현하는 것을 목격하게 된다. 그룹의 크기가 작을수록, 소프트웨어 개발은 기하급수적으로 효율성이 높아진다.



7장. 차이에 대한 연구

테크놀로지가 우리의 생산성을 향상시켜주는 비율은 선형 곡선이 아니라 다항 곡선의 모습으로 증가한다. 테크놀로지는 수입과 수입사이에 존재하는 차이를 증가시키지만, 다른 종류의 차이는 감소시키는 것으로 보인다. 물질적으로나 사회적으로나, 테크놀로지는 부자와 가난한 사람 사이에 존재하는 차이를 넓히는 것이 아니라 좁히는 것으로 보인다.



9장. 창조자의 미적 취향

좋은 디자인은 간명하다. 이런 이야기는 수학에서 그림 그리기에 이르기까지 어디에서나 들을 수 있다.

좋은 디자인은 시간을 뛰어 넘는다. 수학에서 실수 없이 증명된 내용이라면 특정한 시대에 구애받지 않는다.

좋은 디자인은 올바른 문제를 해결한다.

좋은 디자인은 무언가를 암시한다.

항상 그런 것은 아니지만 좋은 디자인은 조금 우습기도 하다. 유머란 힘과 관련이 있기 때문일 것이다.

좋은 디자인의 완성은 어렵다. 위대한 작품을 탄생시킨 사람들이 가진 공통점은 그들이 엄청난 노력을 기울였다는 사실이다. 당신이 지금 엄청난 노력을 기울이고 있지 않다면, 스스로 시간을 낭비하고 있는 것이다.

좋은 디자인은 간단해 보인다.

좋은 디자인은 대칭을 이용한다. 대칭은 그저 단순성을 담보하기 위한 방법 중의 하나로 보이지만, 따로 언급할 필요가 있을 정도로 중요하다. 대칭에는 주가지 종류가 있다. 반복과 재귀가 그것이다.

좋은 디자인은 자연을 닮았다. 자연을 닮은 것이 본질적으로 좋은 이유는 자연이 이미 오랜 세월동안 문제를 해결하기 위해서 노력해 왔기 때문이다. 그렇기 때문에 어떤 답이 자연을 닮았다면 그것은 항상 좋은 신호다.

좋은 설계란 재설계이다. 무엇이든 맨 처음 제대로 만들어 내기는 어려운 법이다. 실수는 자연스러운 것이다. 그것을 재난으로 간주하는 대신, 실수를 쉽게 인정하고 쉽게 고칠 수 있도록 허용해야 한다.

좋은 디자인은 복사가 가능하다. 복사는 대게 극과 극을 오가는 왕복운동을 통해서 진행된다.

좋은 디자인은 종종 이상하다. 가장 훌륭한 작품은 어딘가에 기이한 특질을 가지고 있다. 오일러의 공식, 브뢰겔의 "눈속의 사냥꾼", SR-71, Lisp 그들은 그냥 아름다운 것이 아니라, 기이한 방식으로 아름답다.

좋은 디자인은 뛰어난 사람들 틈에서 나온다.

아름다움을 상상하는 것보다 추함을 지켜보는 것이 쉽다. 아름다운 것을 만들어 낸 사람들은 자기 눈에 추하게 보이는 것을 고치는 과정을 거쳤다.




10장. 프로그래밍 언어에 대한 설명

정말로 새로운 언어의 이름을 하루에도 몇 개씩 듣게 되는 것 같다. 조나단 에릭슨은 이런 현상을 일컬어서 "프로그래밍 언어의 르네상스"라고 말했다.
사람들이 사용하는 또 다른 말은 "언어의 전쟁"이다. 이런 표현에 모순은 없다. 르네상스란 사실 전쟁으로 가득 찬 시대였기 때문이다.

사실 많은 역사가들은 당시 일어난 전쟁은 르네상스를 일으킨 힘의 부산물이라고 생각한다.

지금 프로그래머들이 바벨탑이 무너진 후에 살고 있어서 사실 좋은 일인지도 모른다. 우리가 모두 동일한 언어를 사용하고 있었다면, 그것은 별 볼 일 없는 엉뚱한 언어였을 것이기 때문이다.



11장. 100년 후의 프로그래밍 언어

프로그래밍 언어는 생명의 종과 마찬가지로 사방에 막다른 길이 존재하는 진화의 가지를 그려 나갈 것이다.

모든 프로그렘 언어는 두개의 부분으로 나누어질 수 있다. 공리의 역활을 담당하는 근본적인 연산자의 집합과, 이러한 연산자를 이용해서 작성할 수 있는 언어의 나머지 부분이 그것이다. 공리는 잘 선택되는 것만으로는 부족하고, 수도 적어야 한다.

100년뒤에 컴퓨터가 어떻게 만들어지든 그것이 지금보다 훨씬 빠르게 동작할 것은 거의 확실하다. 무어의 법칙이 계속 적용될 수 있다면 그들은 지금보다 74에 백만 세제곱을 곱한것(73,786,976,294,838,206,464)만큼 빠르게 동작할 것이다.

대부분의 데이터 구조는 속도 때문에 존재한다. 오늘날의 많은 언어는 문자열(Strings)과 리스트(Lists)를 별도로 가지고 있다. 의미론적으로 보았을때 문자열이란 내부 항목이 문자인 리스트에 불과하다. 그런데 왜 두개의 독자적인 데이터 구조가 필요할까? 사실 두개의 데이터 구조가 필요하지 않다. 문자열이란 다만 효율성을 위해서 존재할 뿐이다.

우리는 서로 결합하면 매우 재미있는 가능성을 나타나게 되는 두개의 아이디어를 얻게 되었다.
a) 100년 후에 언어는 원리적으로 지금이라도 설계하는 것이 가능하다.
b) 그런 언어가 지금 당장 존재한다면 여전히 좋은 언어로 기능하게 될 것이다.



12장. 평균 뛰어 넘기

에릭 레이본드(Eric Raymond)는 "어떻게 해커가 되는가?(How to Become a Hacker)"란 에세이에서 해커가 되고 싶은 사람이 배워야 하는 언어에 대해서 설명했다.

리스프는 그것을 마침내 손에 넣게 되었을 때 경험하게 되는 심오함을 깨달음을 위해서라도 배울 가치가 있다.
리스프를 이용하는 일이 그렇게 많지 않다고 할지라도 그 경험은 그 자체만으로도 당신을 훨씬 훌륭한 프로그래머로 만들어 줄 것이다.


13장. 공부벌레의 반격

내가 말하고자 하는 것은 리스프가 1958년 존 매카시에 의해서 처음 발견되었는데, 오늘날 유명한 언어들은 그가 당시 고안한 생각을 겨우 따라잡기 시작했다는 이야기이다.

1950년대의 언어 중에서 아직도 살아남은 것으로는 포트란이 있다. 그것은 언어 설계 면에서 리스프와 정 반대의 접근 방식을 보여준다. 리스프는 예상과 달리 프로그래밍 언어로 발전한 하나의 이론이었다. 그에 비해서 포트란은 원래부터 하나의 프로그래밍 언어로 의도적으로 개발되었다. 그렇지만 오늘날 우리는 포트란을 저급수준의 언어로 인식하고 있다.

처음 개발되었을때 리스프는 아홉개의 새로운 아이디어를 구현하고 있었다. 이들 중에서 어떤 것은 이제 당연한 사실로 받아들여졌다. 그럼에도 불구하고 어느것은 가장 최근의 발전된 언어에서 발견된 뿐이며, 그중 두개는 아직도 리스프에서만 존재한다. 그 아이디어를 메인 스트림에 의해서 받아들여진 순서대로 나열해보면 다음과 같다.

1. 조건문
2. 함수의 타입
3. 재귀
4. 동적 타입 체크
5. 가비지 컬렉션
6. 표현으로 이루어지는 프로그램
7. 기호타입
8. 기호와 상수의 트리를 이용하는 코드를 위한 표기 방식
9. 항상 거기에 있는 언어 전체



14장. 꿈의 언어

정리를 하는 의미에서 해커들이 그리는 꿈의 언어에 대해서 이야기를 해보기로 하자.
꿈의 언어는 우선 깨끗하고 간결하다. 그것은 빠르게 시작하는 인터팩티브한 핵심부분을 가지고 있다. 공통적인 문제를 해결하기 위해서 매우 적은 코드만으로도 프로그램을 작성할 수 있다. 프로그램 안에 작성되는 코드는 거의 모두 특정한 어플리케이션이 필요로하는 내용일 뿐이다. 나머지 내용은 언어 내부에 존재하고 있다.
언어의 문법은 실수를 저지르기 어려울 만큼 간단하다. 필요하지 않은 문자를 입력할 필요는 전혀 없으며, 심지어 Shift 키를 사용해야 하는 경우도 거의 없다.
수준 높은 추상화를 이용하기 때문에 당신은 프로그램의 첫번째 버전을 매우 빠르게 작성할 수 있다.
언어를 배울 수 있는 예제가 풍성하게 존재하고 그런 예제를 몇 분만 들여다 보면 그것을 어떻게 사용하는지 금방 알 수 있을 정도로 직관에 충실하다.
언어는 작은 코어를 가지고 있고, 그러한 코어만큼이나 신중하게 설계된 강력하고 날카로운 라이브러리를 가지고 있다.
언어는 층이 이루는 결에 따라서 만들어졌다. 높은 층에 존재하는 추상화는 원하면 안으로 파고 들 수 있는 아래층에 존재하는 추상화로부터 투명한 방식을 통해서 건설되었다.

꿈의 언어는 오픈소스에 그치는 것이 아니라, 오픈 디자인까지 포함하는 것이다.



15장. 디자인과 연구

화가가 작품을 완성하는 경우는 없다. 단지 그는 작업을 멈출 뿐이다.



휴~ 생각보다 정말 긴 독서평이었습니다. 한 2주동안 조금씩 작성해 왔네요~ 덕분에 한번 더 이 책을 읽었습니다. :-)