제목: 해커와 화가 (원제: Hackers & Painters)
지은이 : 폴 그레이엄
들어가며
해커와 화가는 어떤 연관이 있을까? 이 책에서 작가는 해커는 과학자보다 화가, 소설가와 같은 창조자에 더 가깝다고 말한다. 반복되는 실험을 통해서 완벽한 일을 수행하는 과학자와 달리, 해커는 처음부터 직접 해킹을 하면서 해킹을 배워나가기 때문이다. 이 과정 속에서 점진적으로 좋은 코드를 작성하고 발전한다.
이 책은 '해커'에 대한 정의를 시작으로, 스타트업을 성공시키는 법, 개발 업계의 짤막한 역사들을 훑는다. 뒷부분은 '스타트업'이나 '돈버는 법'에 초점이 맞춰져 있어서, 상대적으로 집중도가 낮았기 때문에 앞부분에 나온 구절 중 몇가지만 정리해본다.
소프트웨어 엔지니어링 p.41
건축과 공학의 경계선이 분명한 것은 아니지만, 아무튼 경계는 존재한다. 그 경계선은 '무엇'과 '어떻게'라는 두 개념 사이에 놓여있다. 건축가는 무엇을 할 지 결정하고 엔지니어는 어떻게 할지를 아라낸다. '무엇'과 '어떻게'가 분리되어야 할 이유는 없다. 다만 어떻게 해야 할지를 이해하지 못한 채 무엇을 할 지 결정하면 심각한 문제에 부딪힐 가능성이 있다. 하지만 해킹이라는 것은 분명 주어진 스펙을 단순히 어떻게 구현할지 정하는 일이 아니다. 진정한 해킹이란 사실 스펙 그 자체를 창조하는 것 이다. 스펙을 만족시키는 최고의 방법은 대부분 그것을 실제로 구현해보는 것이다.
스케치 p.45
나는 내게 다가오는 영감의 원천이 "컴퓨터"라는 말이 포함된 학과에 존재하는 것이 아니라 창조자들이 모여드는 영역에 존재함을 알게 되었다. 다시 말하면 그림은 내게 그 어떤 계산 이론보다 풍부한 영감의 원천이 되어주었다. 예를 들어 대학 시절에 어떤 문제를 풀 때에는 그것을 우선 종이 위에서 완전하게 푼 다음 컴퓨터 앞에 앉아야 한다고 배웠다. 하지만 나는 프로그래밍을 그런 식으로 하지 않았다. 나는 종이 한 장보다는 컴퓨터 앞에 앉아서 프로그래밍 하는 것을 더 즐겼다. 또 전체적인 프로그램을 미리 신중하게 적어서 생각하는 방향이 옳은지 여부를 확인하기 전에 조각난 코드부터 대첵 없이 늘어놓은 다음 그것의 모양을 조금씩 잡아 나가는 방법으로 프로그래밍을 했다. 그리고 나는 디버깅이란 틀린 철자나 부주의한 실수를 잡아내는 최후의 과정이라고 배웠다. 그러나 내가 일한 방식대로라면 프로그래밍 자체가 완벽하게 디버깅으로 이루어져있다.
(...중략..)
소설가, 화가,그리고 건축가의 작업이 그런 것 처럼 프로그램이란 전체 모습을 미리 알 수 있는 것이 아니라 작성해 나가면서 이해하게 되는 존재다.
감정 이입 p.58
대부분의 소프트웨어는 그림과 같이 사람을 위해서 만들어진다. 해커가 위대한 작품을 남기기 위해서는 화가와 마찬가지로 감정이입을 할 줄 알아야한다. 즉, 사물을 사용자의 입장에서 바라볼 줄 알아야 한다.
(..중략)
소스코드도 마찬가지로 스스로를 잘 설명해야 한다. 당신은 단지 사용자를 위해서 감정이입을 하는 것이 아니라 당신의 소스코드를 읽는 독자를 위한 감정이입도 해야한다. 당신 스스로가 얼마 후에는 그 소스코드를 읽는 독자 가운데 한 사람이 될 것이기 때문이다.
이단자 p.78
과학 분야에서는 특히 주어진 가정에 질문을 던지는 습관이 엄청난 무기다. 대부분의 과학자, 최소한 훌륭한 과학자들은 확실히 그런 습관을 가지고 있다. 그들은 전통적인 지혜가 제대로 작동하지 않는 지점을 찾아낸 다음, 그 아래에 무엇이 숨어 있는지 보기 위해서 살짝 벌어진 틈을 캐는 노력을 하는 것이다. 바로 그와 같은 지점에서 새로운 이론이 탄생한다.
나가며
이 책을 읽으면서 과거의 나와 현재의 나를 떠올릴 수 있었다. 나는 왜 개발을 시작했는가?
떠올려본다면 자료구조와 알고리즘, 그리고 프로그래밍 언어가 동작하는 방식이 재미있었기 때문이다. 그래서 관련 수업을 들었고 무언가를 만들기보다는 동작 원리를 파악하고 '실험'하는 것을 즐겼다. 처음의 나는 해커라기 보다 '과학자'가 되고싶었던 것 같다.
하지만 동아리에서 처음 직접 프로그래밍을 해서 결과물을 도출해냈을 때의 짜릿함, 만들면서 배워간다는 성취감이 과학자가 아닌 '개발자'를 꿈꾸게 했다.
그럼에도 불구하고 개발자가 되기로 결심하고 처음의 나는 '과학자 같은' 개발자가 되야한다고 믿고 늘 완벽함을 추구하고자 했다. 당장 필요하지도 않은 공학 개념들을 익히느라 시간을 쓰면서 '완벽한 개발자'를 꿈꾸었던 것 같다.
그것이 잘못되었다는 것은 아니고 물론 추후에 큰 도움이 될 수도 있겠지만, 그러한 완벽주의적 사고방식이 나를 갉아먹고 개발자로서의 꿈을 지치게 만든게 아닌가 생각해본다.
그것보다는 끊임없이 스케치 형식으로 개발하면서 '왜?'라는 질문을 나에게, 그리고 소스코드에게 던져보는 것이 더 발전적이지 않을까 생각한다.
