Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.
RetroTech 팟캐스트 44BITS 팟캐스트

[Book] 해커와 화가

해커와 화가

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

해커와 화가는 2005년도에 출간된 고전(?)이라고 할 수 있습니다. 오랫동안 보고 싶었지만 절판되어서 구할 수가 없었던 관계로 읽지 못하다가 얼마 전에 교보문고에서 이북을 판매한다는 것을 발견하고 잽싸게 구입해서 읽었습니다. 다음 목차에서 보듯이 에세이처럼 쓰인 이 책은 전체가 하나의 큰 흐름을 가지고 있다기보다는 챕터별로 다른 주제의 얘기를 하고 있고 들은 얘기로는 폴 그레이엄이 인터넷에 올린 글을 보아서 낸 책으로 알고 있습니다.

  • 01 공부벌레들은 왜 인기가 없는가
  • 02 해커와 화가
  • 03 우리가 말할 수 없는 것
  • 04 좋은 불량 태도
  • 05 또 하나의 길
  • 06 부자가 되는 법
  • 07 차이에 대한 연구
  • 08 스팸을 위한 계획
  • 09 창조자의 미적 취향
  • 10 프로그래밍 언어에 대한 설명
  • 11 100년 후의 프로그래밍 언어
  • 12 평균을 뛰어넘기
    13 공부벌레의 반격
  • 14 꿈의 언어
  • 15 디자인과 연구
폴 그레이엄은 야후 웹스토어(국내에선 그리 보급되지 못한듯 합니다. 별로 기억에 없네요.)의 근간이 된 비아웹을 만들었으며 그 뒤에는 Y Combinator를 만들었습니다. Y combinator는 현재 Hacker News를 운영하고 있습니다. 이 책을 읽으면서 놀라운 점은 폴 그레이엄의 통찰력입니다. 이미 6년이나 된 책임에도 이 책에서 폴 그레이엄이 예상하고 있는 부분은 대부분 현재 그대로 현실화되었다고 생각됩니다. 가볍게 읽을 수 있으면서 곰곰이 생각해 보면 많은 인사이트를 주는 책이라고 생각합니다. 제가 어떤 문제에 대해서 생각했을 때 관련된 정보를 많이 얻게 되는 것을 자주 경험합니다. 그 타이밍에 그런 고민을 다들 하기 시작한 것인지 아니면 그런 고민을 하다 보니 더 눈에 들어오는 것인지는 정확하지 않지만, 이 책이 제게 그러했습니다. 비록 오래된 책이기는 했지만 제가 고민하는 부분에 대한 정리된 생각을 알 수 있었습니다. 챕터별로 다른 이야기라 전체 요약은 어렵고 인상 깊은 얘기 위주로 정리하겠습니다.

초반부에는 해커에 대한 설명이 나옵니다.

해커와 화가의 공통점은 우선 그들이 둥 다 무언가를 창조한다는 사실이다. ...중략... 사실대로 말하자면 해커들은 표현의 자유에 대한 열망에 사로잡혀 있는 사람들이다.
제목처럼 해커와 화가를 비유하고 있습니다. 해커와 화가가 비슷하다고 얘기하는 것인데 그는 처음부터 끝까지 창조하기 때문입니다.

해커가 수행하는 일은 가끔 "소프트웨어 엔지니어링"이라는 말로 불리기도 하는데 이것은 컴퓨터 사이언스에 못지않게 잘못된 인식을 심어준다 ...중략... 진정한 해킹이란 사실 요구사항 자체를 창조하는 것이다. 요구사항을 만들어 내는 최선의 방법은 그것을 실제로 구현해 보는 것인 경우가 많다.
폴 그레이엄은 컴퓨터 사이언스라는 말이나 스프트 엔지니어링이란 말에 거부감을 가지고 있습니다. 이는 요구사항의 정의와 구현 즉 이는 "무엇"과 "어떻게"라는 개념을 나누는데 이 두 개념은 나누어질 필요가 없다고 말하는 것입니다. 그래서 다음과 같이 얘기합니다.

컴퓨터 사이언스처럼 해커가 하는 일이 과학이라고 불린다면 그들의 행동 역시 과학적이어야 한다는 부담감이 생기기 때문이다. 그래서 대학과 연구소에서 일하는 해커들은 아름다운 소프트웨어를 설계하는 것처럼 진심으로 원하는 일에 몰두하는 대신, 연구논문 같은 것을 작성해야 한다고 느끼게 된다. ...중략... 무언가 아름다운 것을 만드는 방법은 대개 이미 존재하는 것을 살짝 뒤틀거나 아니면 알려진 아이디어 몇 개를 새로운 방식으로 결합하는 것인 경우가 있다. 이와 같은 종류의 일은 연구 논문에서 설명되기 어렵다.
회사라고 해서 해커가 하고 싶은 일을 하도록 그냥 내버려두는 곳은 아니다. 대학과 연구소는 해커에서 모종의 과학자가 될 것을 강요하는 반면, 회사는 그들에게 엔지니어가 될 것을 요구한다. 야후에 해커로 남고 싶다고 대답한 이후 그들이 말하는 해킹은 내가 알고 있는 것처럼 소프트웨어를 디자인하는 것이 아니라 단지 구현하는 것에 불과함을 알게 되었다.
컴퓨터 사이언스라고 불리는 곳에서는 너무 "무엇"에만 집중하고 엔지니어링이라고 불리는 곳에서는 "어떻게"에만 집중하고 있다는 것입니다. 좋은 소프트웨어가 나오려면 "무엇"과 "어떻게"가 함께 이루어져야 한다고 이야기하고 있는데 여기에 무척 공감하고 있습니다. 폴 그레이엄을 비아웹을 만든 뒤 성공해서 야후에 인수된 후 야후 웹스토어로 발전하게 되는데 그 과정에서 스타트업에 대해서 일하다가 대기업에서 일하게 됩니다. 그래서 다음과 같은 이야기가 나옵니다.

대부분의 회사는 소프트웨어의 미래를 한 명의 천재적인 해커에게 맡기기보다는, 소프트웨어가 여러 명으로 구성된 팀에 의해서 설계되도록 하고 해커들은 다만 그것을 구현하도록 만든다. 만약 여러분이 언젠가 큰돈을 벌고 싶다면 이것을 잘 기억해두기 바란다. 왜냐하면 스타트업 회사가 승리할 수 있는 비결 중 하나이기 때문이다. 큰 회사들은 최악의 재난을 피하기 위해서 디자인 산출물에 대한 표준 편차를 줄이려고 노력한다. 하지만 활기차게 진동하는 기운을 억누르면 진동의 저점만이 아니라 고점도 함께 상실하게 됨을 기억해야 한다.
소프트웨어는 그것에 대해서 아무 것도 모르는 사람들이 아니라 그것이 설계된 방식을 잘 이해하고 있는 해커에 의해서 만들어져야 한다.
이는 제가 최근에 많이 생각하는 부분이기도 합니다. 회사라는 구조에서 특히 큰 회사일수록 이상하게도(?) 도저히 좋은 소프트웨어가 나올 수 없는 구조로 되어 있습니다. 이 시스템 혹은 이 프로세스에서는 도저히 좋은 소프트웨어, 창의적인 제품이 나올 수 없다는 생각이 들게 합니다. 저로서는 아무도 말은 그렇게 하지 않지만 목표 자체가 최고의 제품을 만드는 것이 아니라 고만고만한 제품을 만들어서 기존의 인프라를 활용하는 것이 목적이라고까지 생각하고 있습니다. 사람마다 의견이 다르기는 하겠지만(제가 다 옳은 것은 아니니) 이건 웹에 대해서, 제품에 대해서 과연 이해가 있는 것인가 하는 회의감에 빠져들기 일쑤입니다. 그러면 어떻게 해야 하는가에 대한 고민으로 이어질 수밖에 없는데 폴 그레이엄은 자신의 경험을 토대로 어느 정도의 답과 방향을 제시해 줍니다.

결국 훌륭한 소프트웨어를 만드는 방법의 하나는 자기 자신의 스타트업 회사를 만드는 것이다. 그렇지만 여기엔 두 가지 문제가 있다. 우선 스타트업 회사 안에서 당신은 소프트웨어를 작성하는 일 이외에도 여러가지 다른 일을 해야한다.  ...중략... 스타트업과 관련된 또 하나의 문제점은 돈을 벌어주는 소프트웨어와 작성하기에 흥미로운 스프트웨어 사이에는 별로 겹치는 부분이 없다는 사실이다. ...중략... 만약 돈을 벌고 싶다면 자기에게 흥비로운 일을 찾을 것이 아니라 너무나 짜증나는 일이라서 누구도 그것을 공짜로 해결할 엄두를 내지 않는 힘겨운 일을 찾아야 할 것이다.
이 글처럼 스타트업이 어느 정도의 대안이 될 수 있지만 완전한 대안이 되지 못합니다. 대기업의 불필요하고 효율적이지 않은 프로세스만 사라졌을 뿐 스타트업이어도 돈을 벌기 위해서는 자신이 하고 싶은 것이 아닌 고객이 원하는 것을 할 수밖에 없습니다.

이 문제에 해단 답은 적어도 소프트웨어의 경우에는 모든 창조자들에게 이미 잘 알려져 있는 해법으로 구해야 할 것이다. 그것은 임시직(day job)이다. 임시직이라는 표현은 사실 밤무대에서 공연하는 음악인들로부터 시작되었다. 좀 더 일반적으로 말하자면 임시직이란 돈을 벌기 위해서 하는 일과 열정을 위해서 하는 일이 별개의 것임을 의미한다. ...중략... 한편으로 뭔가 멋진 소프트웨어를 개발하기 위한 일을 진행해야 한다는 게 새로운 아이디어는 아니다. 오픈소스 해커들이 하는 일이 바로 그것이기 때문이다. 내가 말하고자 하는 것은 결국 오픈 소스야말로 올바른 모델이 아닌가 하는 점이다.
사실 이 방법이 제가 최근 1,2년 사이에 다다른 결론입니다. 임시직을 뛰고 있다는 얘기가 아니라 돈을 벌기 위한 일과 제가 하고 싶은 일을 완전히 분리해 버렸다는 것입니다. 처음에는 의도한 것은 아니고 회사에서 하고 싶은 일을 못하다 보니 다른 곳에서 그럴 수 있는 것을 찾게 되었고 그런 것을 어느 정도 찾게 되자 거기에 열정을 퍼붓게 되었습니다. 그러면서 회사라는 조직에서 과연 하고 싶은 일을 할 수 있느냐는 고민을 하게 되었고 어차피 두 가지가 결국 합쳐질 수 없다면 차라리 너무 바쁘지 않은 안정적인 직장으로 돈을 벌고 제가 하고 싶은 것을 따로 하는 게 낫겠다는 결론에 이르렀습니다. 알란 케이의 말을 약간 패러디한다면 "열정을 가질 수 있는 일과 회사의 업무가 일치하는 것이 가장 좋다고 생각합니다. 하지만 아직 그러한 회사를 한 번도 보지 못했기 때문에 둘을 분리했습니다." 물론 이는 회사에 업무에 대해서 일정 수준이 상은 열정을 들이지 않는 결과(문제인가요?)가 되기도 합니다.

해킹을 정말로 좋아한다면 뭔가 자기 자신의 프로젝트를 수행하지 않고는 견딜 수가 없는 것이다. ...중략... 그림은 무언가를 그림으로써 학습한다. 해킹도 마찬가지다. 대부분의 해커들이 대학에서 프로그래밍 수업을 받는 것으로 해킹을 배우지 않는다.
하지만 당신이 사실은 노란색의 권리보다 다른 일에 더 관심이 있다면, 노란색주의자라는 딱지는 방해가 될 것이다. 바보들과 논쟁을 하면 당신도 바보가 되는 것이다. 가장 중요한 점은 당신이 원하는 것을 말하는 것이 아니라, 그냥 생각하는 것이다. 그리고 만약 당신이 스스로 생각하는 모든 것을 입 밖으로 내어 말한다면, 그것은 파격적인 생각을 사색하는 데 방해가 된다. 정반대의 노선을 취하는 것이 옳다는 게 내 의견이다.
폴 그레이엄은 대형 기업의 문제점을 정확하게 지적하고 있습니다.(아마 이 문제들은 대형 기업들은 문제라고 생각하지 않을 것 같습니다.)

나는 갑자기 큰 회사를 위해서 일하고 있는 스스로를 발견하게 되었는데, 그것은 마치 허리까지 물에 잠긴 상태에서 달리려고 하는 기분과 비슷했다. ...중략... 작은 회사에 비해서 10분의 1정도만 생산적이다. 큰 회사는 이보다 더 나을 수 없다.
당신이 수행한 일이 다른 사람들이 수행한 일과 함께 하나의 평균값으로 뭉뚱그려지는 것이다. ...중략... 내가 보기에 큰 회사들이 가지고 있는 제일 심각한 문제는 바로 개개인의 업무를 어떻게 제대로 평가하는 가이다. 그들은 대개 정확하게 평가하는 것을 포기해 버린다. ...중략... 눈에 뜨일 정도로 무능하거나 게으르다면 곤란하겠지만, 그렇다고 해서 당신의 삶 전체를 회사에 바칠 필요도 없다. ...중략... 그보다 더 심각한 문제는 회사 입장에서 보았을 때 당신이 수행한 일의 진정한 가치를 정확하게 측정할 수 있는 방법이 전혀 없다는 것이다.
대기업은 무겁고 느립니다. 퀄리티만 떨어지는 것이 아니라 효율도 같이 떨어집니다. 폴 그레이엄의 말처럼 두 번째 문제가 더 큰데 평가할 수 없는 것을 평가할 수 있다고 착각하고 있습니다. 제 기준에서만 봤을 때는 좋은 평가를 위해서는 오히려 가치가 없거나 불필요한 일을 엄청나게 해야 하는 것처럼 느껴질 정도입니다.(저는 KPI라는 평가제도가 세상에서 제일 멍청한 제도 중 하나라고 생각합니다. 다른 분야는 모르겠지만, 개발에는 분명합니다.) 프로그래머가 하는 일은 어떻게 평가해야 하는가에 대해서 어떻게 평가할 수 있는가를 고민했었는데 폴 그레이엄이 어느 정도의 의견을 제시하고 있습니다.(실제 회사에서 적용할 제도적인 기준은 아니라고 할지라도...)

해커가 진짜로 하는 일을 측정하는 것, 즉 그가 아름다운 소프트웨어를 설계하는지 여부를 가리는 것은 훨씬 어려운 일이다. 좋은 설계인지 여부를 판단하기 위해서는 판단하는 사람 자신이 이미 좋은 설계에 대한 감각을 가지고 있어야 하기 때문이다. ...중략... 아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외적인 방법은 시간이다. 시간이 지남에 따라서 아름다운 것은 번창하고 못난 것은 사라진다.
그리고 이 책은 해커의 특성에 대해서 잘 설명하고 있습니다.

말하자면 순수한 호기심 인 것이다. 어쨌든 나는 금지된 것이라면 무엇이든지 궁금해서 견딜 수가 없다. 내가 보고 결정하게 하라. 두 번째로, 나는 잘못 이해되는 관념이 존재한다는 게 마음에 들지 않기 때문이다. ...중략... 세 번재로, 이런 사고방식은 두뇌 활동에 도움이 되기 때문이다. 훌륭한 일을 수행하기 위해서는 우선 당신의 두뇌가 가볼 수 있는 모든 곳을 열심히 가보는 것이 좋다. 특히 누군가 거기는 안 된다고 말하는 곳에 가보는 습관은 두뇌 활동에 더더욱 도움이 된다.
권력을 가진 사람들은 대개 해커들이 가지고 있는 고분고분하지 않은 태도때문에 불편함을 느낀다. 하지만 불복종이라는 것은 훌륭한 프로그래머를 만들어 내는 특성의 부산물이다.
감시는 나쁜 아이디어가 승리하는 세상을 만들어 낸다. 해커에게 옳은 아이디어가 승리하는 사회를 갖는 것이 너무나 중요하기 때문에 그런 조짐들에 대해서 남보다 민감하다.
테크놀로지가 가져온 변화에 대해서 설명한 부분은 꽤나 인상적이었습니다. 일반적으로 세상의 부를 고정된 파이에 비유해서 누군가 부를 늘리면 다른 사람의 부가 줄어든다는 말을 하고 있지만 그렇지 않다고 강조하고 있습니다.

테크놀로지는 부를 창출하는 것이 그것을 훔치는 것보다 더 빠를 수 있는 길을 열어 놓았다. ...중략... 잡스와 워즈니악은 부자가 되기 위해서 다른 사람을 가난하게 만들 필요가 없었다. ..중략.. 확실한 것은 그것이 생산적인 사람과 그렇지 않은 사람사이의 차이를 더욱 넓힐 것이라는 점이다. 그것이 테크놀로지의 핵심이다. ...중략... 테크놀로지가 값싸게 만들 수 없는 유일한 대상은 브랜드다. 우리가 요즘 브랜드에 대해서 많이 듣게 되는 이유가 바로 이것이다. 브랜드는 그러니까 부자와 가난한 자 사이에 존재하는 실질적인 차이가 증발하면서 남게 된 찌꺼기와 같은 것이다.
현대 사회에서 수입에 있어서의 차이가 늘어나는 것이 오히려 사회가 건강하다는 사실을 나타내는 것이라고 주장하고 싶다. 테크놀로지는 생산 능력에 있어서의 차이를 선형 비율보다 빠르게 증가시키고 있다. 만약 수입에 있어서의 차이가 그 증가속도를 따라가지 않는다면 거기엔 세 가지 설명이 가능할 것이다.
(a) 기술적인 혁신이 중단되었다.
(b) 가장 많은 부를 창출할 만한 사람들이 일을 하지 않는다.
(c) 부를 창출하는 사람들이 제대로 보답 받지 않는다.
이 책에서는 회사의 윗사람을 머리 솟은 보스에 비유하면서 비판을 하고 있습니다. 이는 사실 프로그래밍 언어의 선택에 대해서 이야기하면서 나온 부분으로 적재적소에 맞는 기술을 사용하지 않고 보편적인 기술만을 사용하게 되는 데 대한 이야기를 하면서 나오는 부분입니다.

극히 드문 두 개의 성질을 불가사의하게 한 몸에 결합하고 있다. (a) 그는 테크놀로지에 대해서 아무 것도 아는 것이 없다. 그리고 (b) 그는 테크놀로지에 대해서 매우 강한 의견을 가지고 있다. ...중략... 소프트웨어가 어떻게 동작하는지 알지 못하고, 어떤 프로그래밍 언어를 다른 언어와 구별하지도 못한다. 그럼에도 불구하고 그는 당신이 어떤 언어를 사용해야 하는지 잘 알고 있다. ...중략... 그에게 자바는 곧 표준이다. ...중략... 세상에 존재하는 프로그래밍 언어가 모두 동일한 것이라고 착각하고 있는 것이다.
덜 유명한 언어를 사용하는 데 따르는 문제로 세 가지 정도로 생각해 볼 수 있다. 우선 프로그램이 다른 언어로 작성된 프로그램과 함께 어울려서 동작할 때 제대로 동작하지 않을 수 있다. 사용할 수 있는 라이브러리가 제한될 수도 있다. 그리고 프로그래머 고용이 어려울 수도 있다. ...중략... 첫 번째 문제의 의미는 당신이 시스템 전체를 통제할 수 있는가 이다. ...중략.. 호환성 문제가 발생하면 다신 스스로 문제를 해결할 수 있다. 서버기반 어플리케이션에서는 가장 진보적인 테크놀로지를 사용할 수 있는데, 조나단 에릭슨이 말한 "프로그래밍 언어의 르네상스"의 의미가 여기에 있지 않은가 생각한다. ...중략...라이브러리에 대해서 말하자면, 중요성은 어플리케이션에 달려있다. ...중략.. 그정도 규모의 프로젝트라면 강력한 언어의 기능이 미리 존재하는 라이브러리의 편리함을 앞지르기 시작할 것이다. ...중략.. 우리는 이제 최고의 소프트웨어는 열 명 이하의 사람으로 이루어진 팀에 의해서 만들어질 수 있다는 사실을 분명히 알게 되었다. 열 명 정도의 수준이라면 누구라도 한 번 쯤 들어본 언어를 사용하는 프로그래머를 고용하는 데 아무런 문제가 있을 수 없다.
좋은 해커가 되기 위한 자세 혹은 스타트업으로써 취해야 할 자세를 다음과 같이 이야기 합니다.

감정이입이라는 것이 자기희생을 뜻하는 것은 아니다. 그것과는 거리가 상당히 멀다. 사물을 다른 사람의 입장에서 바라본다는 것은 곳 다른 사람의 이익을 대변한다는 뜻은 아닌 것이다. ...중략... 다른 사람의 주의를 끌기 위해서는 그들이 필요한 것이 무엇인지 이해해야 한다. ...중략... 아마도 감정이입이야 말고 그냥 좋은 해커와 위대한 해커를 구분하는 결정적인 차이점일 것이다.
쉽게 생각할 수 없는 것을 생각할 수 있도록 자신을 훈련시키는 일은 평상시의 생각을 뛰어넘도록 도와준다. 달리기 전에 몸을 충분히 푸는 것은 달리는 행위 그 자체보다 몸을 훨씬 더 유연하게 준비시킨다. 다른 사람의 머리가 곤두설 정도로 파격적인 생각을 자유자재로 할 수 있다면 흔히 혁신이라고 부르는 수준의 미미한 파격을 시도하는 것은 문제도 아닐 것이다.
우리가 일부러 어려운 문제를 찾으려고 노력했다는 사실이다. 우리는 소프트웨어에 더할 수 있는 기능이 두 가지 있을 때, 그리고 기능이 가진 가치가 어려운 정도에 비례한다고 했을 때, 언제나 어려운 쪽을 선택했다. 더 많은 가치를 위해서가 아니라, 더 어렵기 때문이다. ...중략... 우리에게 어려움이라는 것은 경쟁자에게는 불가능을 의미했기에 우리는 그렇게 힘든 날에도 즐거움을 잃지 않았다.
좋은 작품을 만드는 데 필요한 자기만의 미적 취향을 가지고 있어야 한다. ...중략... 진정한 문제는 단순해지도록 강제되었을 때 만나게 된다. 더 이상 무의미한 장식물을 동원할 수 없게 되었을 때, 실질적인 내용을 보여주어야 하기 때문이다. 좋은 디자인은 시간을 뛰어넘는다. ..중략... 유머가 결여된 채 좋은 디자인으로 불리는 것을 상상하기가 쉽지는 않다.
시간의 벽을 뛰어넘는 것을 목표로 삼는 일은 최선의 해결책을 발견하기 위한 하나의 방법이 될 수 있다. 어느 누군가가 당신의 일을 뛰어넘는 것을 상상할 수 있다면 그 일을 스스로 해야 한다. 인류의 위대한 스승들을 바로 그러한 일을 철저하게 추구했기 때문에 자기 뒤를 이은 사람이 할 수 있는 일의 여백을 별로 남겨 놓지 않은 사람들이었다.
좋은 소프트웨어를 작성하려면 두 개의 상반되는 생각을 머릿속에 동시에 가지고 있어야 한다. 초짜 해커가 갖는 자신의 능력에 대한 순진한 확신과 베테랑이 품는 회의감을 모두 가지고 있어야 하는 것이다. 그리하여 한쪽 머리로는 도대체 그것이 어려워 봤자 얼마나 어렵겠어? 라고 생각하고, 다른 쪽 머리로는 아냐, 그건 절대로 동작하지 않아. 라고 생각할 수 있어야 한다. 이러한 과정에는 아무런 모순이 없다는 점을 깨닫는 것이 포인트다. 당신은 두 개의 다른 사물에 대해서 낙관과 비관을 하고 있는 것이다. 문제를 해결할 가능성에 대해서는 낙관해야 하지만, 당신이 그 시점까지 개발한 해결책의 가치에 대해서는 끊임없이 회의를 해야 하는 것이다. 좋은 작품을 산출하는 사람들은 대개 그들이 일하는 동안에는 자기가 현편없는 작품을 만들고 있다고 생각한다. ...중략.. 근심이 좋은 작품을 만드는 것이다.
무엇이든 맨 처음에 제대로 만들어 내기는 어려운 법이다. 전문가들은 처음에 만든 작품은 내다 버리게 될 것이라고 생각한다. 그들은 항상 변화를 염두에 둔다.
마지막으로 이 책을 읽고 나면 리스프(Lisp)를 배워보고 푼 생각이 들게 되면서 내년에는 Clojure를 배워볼까라는 망상을 잠시 해 봅니다. ㅎ 참고로 폴 레이몬드가 만든 비아웹은 리스프로 만들었습니다.

리스프가 대단한 이유는 리스프가 가장 강력한 언어이기 때문이다. 다른 사람들이 그것을 이용하지 않는 이유는 프로그래밍 언어라는 것이 단순히 테크놀로지가 아니라 습관이기 때문이다.
" 리스프는 그것을 마침내 손에 넣게 되었을 때 경험하게 되는 심오한 깨달음을 위해서라도 배울 가치가 있다. 리스프를 이용할 일이 그렇게 많지 않다고 할지라도 그 경험은 그 자체만으로도 당신을 훨씬 훌륭한 프로그래머로 만들어줄 것이다." - 에릭 레이몬드의 "어떻게 해커가 되는가(How to Become a Hacker)"
그동안 구할 수가 없어서 못 읽기는 했지만, 과연 사람들이 추천할 정도의 책이구나 하는 생각이 들게 하는 책입니다. 이런 책이 절판되어서 더 이상 구할 수가 없다는 건 정말 안타까운 일이군요.
2011/12/31 20:00 2011/12/31 20:00