기차니즘 초절정 고수 일탈을 꿈꾸며... - 스팟

유닉스 혹은 리눅스를 사용해본 경험이 있다면 당연히 한번쯤 봐야할 도서다. 구구절절 내 느낌을 말하는것 보다 책 내용을 그대로 옮기는게 원래 뜻을 변질시키지 않을 것 같다.

「The Magical Number Seven, Plus or Minus Two: Som Limits on Our Capacity for Processing Information」[Miller]는 인지 심리학 분야에서 근간이 되는 논문 중 하나이다(덧붙이자면, 미국의 전화 번호는 이러한 이유에서 일곱 자리다). 사람이 단기간에 기억하는 낱개 정보의 개수는 일곱 개에서 한두 개 많고 적은 정도이다. 이는 API의 압축성을 평가할 때 좋은 척도가 된다. 프로그래머가 엔트리 포인트를 일곱 개 이상 기억해야 하는가? 일곱 개보다 많은 API는 엄밀한 압축성과 거리가 멀 가능성이 아주 크다.

p. 125

디버깅 툴을 뒤늦게 설계에 반영하지 말고, 쓰고 버리는 장치 정도로 여기지 마라. 디버깅 툴은 코드를 들여다 볼 수 있는 창문과 같다. 이벽에 되지도 않는 구멍을 함부로 뚫지 말고, 마감을 한 다음 판유리를 끼워라. 정녕 코드를 유지할 수 있게 만들고 싶은 생각이 든다면 항상 이 창문에 불을 켜 두어야 할 것이다.

p.180

언어 설계자의 입장으로, 에러 메시지를 내주지 않고 뭔가 다른 대안을 생각해보는 것은 상당히 훌륭한 원칙이라고 생각한다. 프로그래머의 의도에 정말로 애매함이 있다면 에러 메시지는 적절할지도 모른다. 그러나 대부분의 경우에 의도는 명확한 편이다. 그리고 언어가 조심스레 올바로 일을 처리하는 것은 큰 행운이다. 좋은 예 하나를 소개하겠다. C 언어는 배열의 초기값 리스틀 적어줄 때 맨 끝에 콤마를 덧붙여도 괜찮은데, 이렇게 하면 편집할 때도 좋고 배열 값을 자동 생성하는 경우에도 훨씬 간편하게 처리할 수 있다. 반례로 여러 HTML 리더의 까탈스러움을 들 수 있다. 특히나 비일비재한 중첩 태그 에러 때문에 문서의 일부분을 슬쩍 버리는 행위가 그러하다.

- 스티브 존슨

p. 256

젠트너와 닐슨(Gentner & Nielsen)은 「The Anti-Mac Interface」[Gentner-Nielsen]에서 위의 상관관계를 잘 요약하였다. "비주얼 인터페이스는 소수의 객체에 대해 간단한 연산을 할 때 가장 적합하지만, 연산 또는 객체의 숫자가 증가함에 따라 이들을 직접 조작하는 일은 즉시 반복적인 괴로움으로 바뀐다. 직접 조작 인터페이스의 어두운 면은 사람이 모든 것을 다 다루어야 한다는 사실이다. 사용자는 상위 수준의 지시를 내리는 관리자는커녕 공장의 조립라인에 붙어서 같은 작업을 끊임없이 해야 하는 노동자로 전락해버린다." 저명한 과학 소설 작가 닐 스테판슨(Neal Stephenson) 역시 그이 날카롭고 추론적인 에세이 「In the Beginning Was the Command Line」[Stephenson]에서 이렇게 직접적이지 않게 다소 가벼운 분위기로 동일한 지적을 했다.

p. 317

보다 일반적으로, 사용자와 나머지 세계를 중재하는 프로그램들은 어떤 기능에 집착하는 성향이 강하다. 이것은 편집기뿐만 아니라 웹 브라우저도 해당하며, 메일과 뉴스그룹 리더, 또는 다른 통신 프로그램도 마찬가지이다. 이 모두는 자윈스키의 법칙이라고 부르는 소프트웨어 포위의 법칙(the Law of Software Envelopment)을 따라 진화하는 경황이 있다. "모든 프로그램은 메일을 읽을 때까지 진화하려 한다. 프로그램들이 이러한 기능을 갖추지 못하면 그 기능을 갖춘 프로그램이 대신한다."

이 법칙을 발견한 제임 자윈스키(Jamie Zawinski)는 보다 일반적인 원칙으로 모든 쓸만한 프로그램들은 스위스 군용 칼로 탈바꿈하려는 경향이 있다고 말했다. UNIX 세계의 바깥에서 상업적으로 큰 성공을 거둔 통합 응용 모음은 이 원칙을 착실하게 따르고 있고, UNIX의 미니멀리즘 철학에 도전하고 있다.

p. 377

프레임워크를 작성할 때에는 분리의 규칙을 기억하라. 프레임워크란 메커니즘이어야 하고 정책이 되어서는 안 된다. 대부분의 경우에 정책은 찾아볼 수 없다. 프레임워크를 작성하고 재사용하는 이점 한 가지를 소개하면, 다른 방법으로는 분리된 모듈, 모드, 또는 툴에 제 각각 다른 정책을 넣어야 할 상황에도 이들을 분리해서 다른 용도에 다시 재조합할 수 있다는 점이다.

p.381

유닉스의 역사를 배울때 C가 어쩌구 누가 만들었고라는 이야기는 이미 학교에서 수도없이 들었을 것이다. 왜 이렇게 만들었고, 이렇게 발전될 수 밖에 없는지 알게 된다면 자신만의 무기를 만들수 있을 것이다.

아주 강추한다.