1. 주요 내용
•
생략 / WIP
2. 감상평
이책은 2004년에 작성된 Y Combinator의 공동 창업자인 폴 그레이엄의 생각이 담긴 에세이 모음집이다. 약 20년전에 쓰인 책임에도 불구하고, 최근에 출간한 책이라고 해도 전혀 이상하지 않을 정도로 디자인, 프로그래밍 언어, 부 등 다양한 주제에 대하여 깊이있는 인사이트를 보여주는 것이 놀라웠다.
그러나 옮긴이인 임백준님이 작성하신 것처럼, 폴 그레이엄의 세계관과 전형적인 백인 미국인의 관점에 다소 동의되지 않는 부분도 존재 했다. 대표적 예시가 첫번째 에세이인 "공부벌레는 왜 인기가 없을까" 이다. 현대 사회에서 학교가 하는 순기능은 고려하지 않은 채, 학교를 감옥에 비유하며 학생들이 단편적이고 무의미한 시간만을 보낸다는 내용은 너무 비판적인 시각에 치우쳐 있다고 생각이 들었다.
둘, 해커와 화가
[해커는 창조자다]
나는 보통 소프트웨어 개발을 보통 수학문제 푸는 것이라고 많이 비유한다. 마케팅처럼 정답이 없는 채 마치 망망대해를 헤어치는 것이 아니라, 정답이 늘 존재하며 인과관계가 매우 분명한 일이라고 생각했다. 그리고 어려운 문제를 만났을 때, 문제를 풀어가는 과정을 즐기고 정답을 도출했을 때 느끼는 보람과 성취감이 나에겐 크게 다가왔다.
[해커와 화가] 편에서 폴 그레이엄은 해커(개발자)를 수학자나 과학자가 아니라 화가나 건축가 처럼 창조자라고 말했다. 마치 연필로 그림그리듯 해커는 프로그래밍 언어를 통해 다양한 창의적인 방법으로 프로그램을 구현하며 소프트웨어를 창조하는 존재라고 설명했다.
“프로그래밍 = 수학” 라고 지금까지 스스로 생각했던 것이 책의 내용과 역행하며 다소 딱딱하고 닫힌 사고방식이 아닌가 스스로 질문을 던지게 되었다. 단지 기획단의 요구사항을 구현화 하는 기술자가 아니라, 좀더 유연하고 자유로운 생각을 바탕으로 디자인(설계)를 해 나가는 창조자의 사고방식을 더 가지려고 노력해야겠다는 생각이 들었다.
[감정이입]
내가 작성한 프로그램/소스코드를 다른 사람의 입장에서 바라보고 그들이 잘 이해할 수 있게끔 잘 작성되어야한다는 것은 코드 퀄리티를 높이기위해서는 Readability를 높여야한다는 나의 생각과도 잘 일치되었다. 미주를 보면, 프로그램을 읽기 쉽게 만드는 방법은 그안에 주석을 잔뜩 집어 넣지 않는 것이며, 독자에게 꼭 전달해야할 사항이 있을 때만 적어야한다는 내용을 보며, 최근에 코드를 작성할 때 특히 내가 지향하는 방향성이 틀리지는 않았구나 생각이 들었다.
[그 외]
그 외에도 “여유시간에 작성한 소프트웨어가 무엇인가를 면접에서 집중적으로 물어본다. 해킹을 정말 좋아한다면 자기 자신의 프로젝트를 수행하지 않고는 견딜수가 없을 것이다” 라는 내용이 상당히 인상깊었다. 과연 나는 해킹(개발)을 정말로 좋아하고 사랑하는 사람이가? 나 자신을 돌이켜보는 구절이었다.
여섯, 부자가 되는 법
부는 근본적인 것이며 우리가 원하는 것이다. 돈은 단지 부를 움직이기 위한 수단에 불과하며 프로그래머는 실질적인 부를 창출하여 그에 상응하는 대가를 받으며 부자가 될 수 있다.
책에서는 부자가되기위해서는 “정당한 평가” 와 “영향력” 두가지의 환경이 갖춰져있어야 한다고 한다. 그리고 스타트업에서는 그것이 가능하다고 한다. 스타트업은 규모가 작기 때문에 “정당한 평가”를 받기가 수월하며, 프로그래밍을 통해 “영향력”을 행사할 수 있다는 내용이 크게 공감되었다. 규모가 큰 회사에서도 근무를 해보았지만, 나의 성과와 노력이 평가와 비례하지 않는다는 것을 깨닫았을 때 힘이 많이 빠졌었다. 그러나 스타트업에서는 내가 노력한 것과 이룬 것이 좋은 결과로도 이어질 수 있음을 직접 경험해보니, 어떤 곳이 나에게 더 적합한 곳인지를 깨달을 수 있었다.
무엇보다도 스타트업은 누구보다도 열정적이고 자기 주도적으로 일하는 사람들이 대부분이기에 지금도 주변의 여럿 사내 구성원분들께 서로 좋은 영향력을 행사하고 동기부여를 줄 수 있는 것이 너무나도 만족스러웠다. 이부분은 타성에 젖은 채 책임 전가하기 바쁜 직원들이 많았던 이전 회사 구성원들과 매우 다른 점이었다.
이 에세이를 읽으면서, 앞으로도 스스로 부를 창출하는 방법을 끊임 없이 모색하며 부자가 될 수 있는 날을 즐거운 마음으로 상상할 수 있었다.
3. 북토크
1장. 저자는 인기보다는 지적 능력이 좋다고 말합니다. 그러나 인기는 대부분의 경우 선택의 문제는 아닙니다. 여러분은 키를 키우거나 얼굴을 잘생기게 하기 위해서 지능을 낮출 용의가 있으신가요? 만약 여러분이 만나는 상대방이 외모를 올리고 지능을 낮추려고 한다면 막으시겠어요?
•
키/외모가 인기의 모든 척도는 아니라고 봄. 성격, 사교성, 유머, 운동 능력 등으로도 충분히 평균 수준 유지할 수 있다고 생각함
•
물론 키가 너무 작다면 지능을 낮출 것인지를 고민해볼 수 도 있겠지만… 웬만히 작지 않고서는 낮추지 않을 것 같음.
•
높은 수준의 지능이 어떻게 살아가야할 지, 더 나은 사람이 되기 위한 고민등의 중요한 재료가 될 수 있을거라고 생각함. 따라서 상대방에게도 지능을 낮추는 것을 권하지 않을 것 같다.
2장. 저자는 프로그래밍이 학문보다는 예술적 성격을 가지고 있다고 말하면서 그에 대해 설명합니다. 다른 무엇이 프로그래밍하고 닮아 있다고 느끼신 적이 있다면 알려주세요.
•
수학문제 풀기, 도시 계획, 롤러코스터 타이쿤/심시티, 도서관 사서의 일 (책분류, 도서관 구성 등)
3장. 저자는 생각의 자유를 가지고, 자유를 공유할 사람을 찾는 것이 중요하다는 이야기를 하는데요. 동시에 Y combinator 내부 게시판은 비 윤리적인 글이 종종 올라와 논란이 되기도 했습니다. 저자의 관점에 동의하시는지, 또 그렇다면 어떤 경우에 그런 감정을 느끼셨는지 궁금해요.
•
바보들과 논쟁을 하면 당신도 바보가 된다. 입밖으로 내어말한다면 파격적인 생각에 방해가 된다. 정반대이 노취해라, 입을 다물고, 공개적으로 털어놓을 수 있는 친구를 사귀어라 는 저자의 생각에 동의되지 않음
•
다양한 생각과 아이디어를 바탕으로, 왜 그렇게 생각하는지 근거를 가지고 솔직한 태도로 사람들과 토론하는 문화는 어딜가나 중요하다고 생각함
•
또한 만약 그 생각이, 특정 의사결정에대한 불만이나, 함께일하는 사람에 대한 부정적인 견해라면 더욱더 앞에서 얘기하고 오해가 있다면 풀고, 어떻게 하면 더 개선된 방향이 있을지를 함께 고민하는 자세를 가져야한다고 봄.
•
특정 집단에만 내 생각을 교류한다면, 이건 결국 뒷말, 소문이 더 무성해지고 하나의 팀, 조직이 여럿으로 나뉘게 되는 지름길이되지 않을까?
4장. 저자는 해커를 특이한 사람이면서 마법적인 해결사(다른 사람보다 현상에 대해 더 정확한 그림을 가진)로 그리고 있습니다. 저자의 관점(해커가 문제 해결이라는 면에서 다른 직종보다 유리하다)에 동의하시나요?
•
4장에 이러한 내용이 있었던가…?
◦
규제는 새로운 아이디어를 얻기 위한 행동들을 제약할 것
◦
해커는 다스릴 수 없는 존재다. 자유스러움의 본질 그자체
◦
미국이 이륙한 부와 권력의 원천은 과감하게 규칙을 깨뜨리는 데 있음
6장. 저자는 사람들이 원하는 것은 돈이 아니라 부라고 말합니다. 부를 얻기 위해서 시간을 많이 쓰는 편이신가요? 아니면 부가 아닌 동기부여가 있나요? 그 동기부여는 부로 얻을 수 있는 것인가요?
•
실질적인 부를 창출해서 그에 상응하는 대가를 받는 것 → 스타트업에서 일하는 이유
◦
스타트업은 우체국에서 50년 동안 일하는 수준의 스트레스를 3-4년의 세월에 압축시켜 경험가는 것을 의미한다.
•
부는 근본적인것. 내가 원하는 것
◦
돈은 부를 창출하기 위한 수단이다.
◦
프로그래머는 컴퓨터에 앉아서 부를 창출 할 수 있음 (좋은 소프트웨어를 만드는 것 = 부)
•
부자가 되기 위해서 필요한 환경
◦
정당한 평가
◦
영향력
•
부 = 행복 = 자기만족 = 인정 욕구 = 영향력이라고 한다면, 적게 쓰고 있는 것 같지는 않음
◦
회사에서 높은 퍼포먼스와 높은 수준의 결과물을 내기 위해 많은 시간과 노력을 쏟는 것
◦
지속적으로 나라는 사람을 발전시키고, 성장하기 위해 다양한 고민들을 바탕으로 실천 하는 것
◦
이러한 행위들을 꾸준히 수행한다면, 부를 창출하는데 한발짝 더 가까워 질것이고 돈은 자연스레 따라오지 않을까?
7장. 저자는 불평등한 소득분배가 오히려 좋은 결과를 불러올 수 있다고 말합니다. 불균등 분배가 뛰어난 사람들에게 동기부여/부를 주고 사회를 변화시킨다는 관점에서요. 저자의 관점에 동의하시나요? ex) 신입보다 일을 3배하는 경력자는 연봉을 세배 받아야 할까요?
•
저자의 신자유주의, 자유 시장 경제의 논리 다소 강하게 느껴짐
•
미시적 관점
◦
물론, 본인이 노력한 만큼 더 많은 소득을 가지는 것은 자연스럽고 당연한것이겠지만, 반드시 100% 1:1 비율로 정비례하진 않을 것…
◦
업무 퍼포먼스 및 성과에 따라 인센티브를 초과 지급하여 열심히 한만큼 평가 및 보상을 받을 수있게 함
◦
그리고 기본급을 제공하여 성과가 다소 낮은 직원들에게 안전장치를 주면 어떨지?
•
거시적 관점
◦
정부의 역할, 복지, 부의 불균형, 소득격차를 위한 최소한의 거시적인 정책들도 수반되어야한다고 생각함
▪
모든 사람들이 동일한 조건에서 평등하게 동일선상에서 출발하진 않음
▪
그들을 위한 복지 정책을 펼쳐 더 많은 사람들이 사회를 더욱 긍정적으로 변화시킬 수 있는 방향도 고민해봐야하지 않을까?
9장. 저자는 아름다움을 인식할 수 있어야 아름다움을 만들 수 있다고 말합니다. 똑같은 말이 코드에도 성립할 수 있을텐데요. 코드가 아름답다! 라고 느껴본 경험이 있으신가요?
•
클린 코드, 주석없이 매우 잘 읽히는 코드
•
Code Navigation이 뛰어나고, Readability가 높고 확장성과 유지보수성이 뛰어난 코드
•
딱히 떠오르지 않음
◦
함수명이 직관적이고 명시적임
◦
도메인의 전략적 설계가 잘 작성됨
◦
클린 코드가 잘적용되어있음
◦
테스트 코드가 적절함
◦
확장성에 용이한 코드 (매우 타이트하지 않은 코드, 특정 로직에 종속적이지 않은 코드)
11장. 저자는 미래의 언어를 생각하면 지금의 언어가 가져야 할 방향을 알 수 있다고 말합니다. 100년은 아니더라도 20년 후의 언어에 꼭 들어가 있으면 하는 기능이 있나요?
•
함수명, 변수명을 자동으로 지어주는 기능..?
•
고성능의 언어
◦
현재의 컴파일 언어 + 인터프리터 언어의 장점을 조합하여 성능의 극대화를 이룬 것..?
•
내가 원하는 기능들이 언어레벨에서 처리가능한건지 모르겠음
◦
함수형 프로그래밍
◦
모킹, 테스트 방법론
◦
의존성 관리
13. “나는 프로그램 안에서 패턴을 발견하면 그 것을 뭔가 문제가 발생하고 있다는 신호로 받아들인다.” 평소에 자주 사용하시는 디자인 패턴이 있나요? 저자가 인식하는 문제점 처럼 이러면 위험하다! 라고 생각하는 코드 패턴도 궁금합니다.
•
기술서적에서 지칭하는 말 그대로의 디자인 패턴이 아니라, 구현 방식의 관점에서 본다면….
◦
너무 많은 책임을 가진 함수/메서드/클래스
◦
외부 의존성이 매우 높은 모듈
◦
도메인 고민 + 전략적 설계가 이루어지지 않은 비즈니스 규칙들
◦
관심사 분리가 제대로 되지 않은 코드들
기타. 이 사람이 개발자스럽다고 생각이 드는 순간이 있으신가요? 그 기준이 합리적인가요? (판별에 혹은 그 사람의 직무능력과의 연관성이라는 관점에서) 또, 저자가 제시한 해커(혹은 뛰어난 프로그래머)는 이런 사람이고 이래야 한다는 관점에 동의하시나요?
•
인생 그자체가 개발인 사람..