개발자의 삶이라는 항해의 방향키가 흔들리는 원인은 근본적으로 자기 자신과 조직에 대한 무지로부터 비롯된다. --- p.4

적지 않은 개발자들이 새로운 도전과 경험을 통해 또 다른 이름을 얻거나, 기존의 이름을 버리고 전혀 새로운 이름을 얻는다. 하지만 그보다 더 많은 이들이 처음 얻었던 이름과 프레임에 갇힌 채 천형과도 같은 개발자의 삶을 이어나간다. --- p.15

그 어떤 명칭에도 나를 대변하는 고유함은 들어 있지 않다. 개발자로서 내가 얻고자 하는 이름은 ‘소프트웨어 개발문화 전문가’다. 생소할 것이다. 이런 명함을 가졌거나 그렇게 불리는 사람을 여태 본 적이 없으니, 아직은 유일무이한 이름이다. --- p.19

오만함은 곳곳에서 나타난다. 가장 큰 오만은 자신이 짠 코드가 오류가 없을 것이라고 가정하는 것이다. --- p.38

먼저 버그와 이슈를 예방하고 선해결하는 프로메테우스 개발자들 대신 사후에 떠들썩하게 소 잃고 외양간 고치는 에피메테우스 개발자들에게 공로가 돌아가는 경우가 많다.. --- p.51

고통의 원인은 시들어가는 꽃이 아니라 바로 꽃이 시들지 않기를 바라는 비현실적인 욕망이라는 틱닛한의 말처럼 우리를 힘들게 하는 것은 이슈 자체가 아닌 이슈에 대한 걱정과 공포와 그리고 두려움이다. --- p.58

그 시간 속에서 나만의 특별한 순간의 시간 - 카이로스를 찾아 나서야 한다. 통제할 수 없는 크로노스의 시간들 대신 내가 만들어 낼 수 있는 카이로스의 시간에 주목해보자. 어디에서든 일상의 소소한 행복과 기쁨은 존재한다. 눈 덮인 담벼락 밑에도 봄을 기다리는 한송이 꽃은 피어나고 있다.--- p.85

코딩이나 글쓰기는 도구일 뿐이다. 그 자체로 몰입할 수 있고 좋아하는 일이 될 수 있지만 그것만으로는 부족하다. 쉽게 말해 밥 먹고 살기 어렵다. 코딩이나 글쓰기의 대상이 될 수 있는 ‘타겟’이 필요하다. 다시 말해, 전문적인 영역을 그 위에 덧붙여야 한다. --- p.92

좋아하는 일은 직접 해보지 않고는 모른다. 또한 깊숙이 들어가보지 않고는 확신할 수 없다. 그러니 어느 날 가슴 떨리는 공명이 찾아오면 주저하지 말고 작은 것부터라도 시작해보자. --- p.94

개발자들이 내리막길을 걷는 근본적인 이유는 다른 곳에 있다. 경력이 늘어갈수록 쌓이는 경험만큼 일에 능숙해진다. 하지만 그에 비례해서 사라지는 것들이 있다. 바로 열정과 무식함이다. --- p.101

십 수 년을 개발자로 살아오면서, 지금까지의 삶에 만족하지 못했다면 이제 결단을 내려야 하지 않을까? 외면하지 말아야 한 사실은 앞으로 더 힘들면 힘들어졌지, 더 좋아지지는 않는다는 것이다. --- p.103

한번쯤은 의지를 열정으로 착각해도 좋다. 의지가 정녕 열정이 되지 않는다면 지금 이 길이 나의 길이 아니라는 것이 확실해지는 것이니 이 길을 과감히 버려도 후회는 없을 것이다. 만에 하나 의지가 열정이 된다면, 그 또한 나 자신의 가능성을 보여주는 것이니 환영할 만하다. --- p.114

진정한 개발문화는 프로세스와 사람이 공존한다. 서로가 서로의 위에 군림하지 않고 유기적으로 맞물려 돌아간다. CTO, CEO와 같은 최상의 접점에 있는 사람들의 역할이 더욱 중요해진다. 결국 가장 중요한 것은 사람이다. --- p.125

아이러니하게도 현장에서 멀어질수록 현장을 더 객관적으로 이해하고 있다는 착각에 빠지게 된다. 현장을 이해하지 못하는 답답한 탁상공론은 관료집단만의 전유물은 아니다. --- p.139

프로젝트 운용에서 팀원이 재능을 충분히 발휘하여 성과를 내게 하려면 가장 자기다운 방식을 택하도록 도와주어야 한다. 적합한 사람들로 팀을 구성하는 것, 그 다음 목표는 정하되 수단은 그들에게 맡겨두는 것, 이것이 프로젝트 성공의 비결이다. --- p.159

좋은 프로세스란 마치 공기와도 같이 그 존재를 의식할 수는 없지만, 자연스럽게 그 흐름에 동조될 수 있는 것이어야 한다. 오차 없는 치밀한 정교함은 조직에 완벽하게 동화된 프로세스의 결과다. --- p.163

목표를 설정할 때 무엇보다도 목표의 타당성을 검토하는 일을 우선해야 한다. 그것은 팀이나 전사 차원에서는 물론 개인의 차원에서도 이루어져야 한다. 일을 하다 보면 우리는 원래의 문제가 무엇이었는지는 잊어버린 채 지금 찾고 있는 답에만 집중하는 경향이 있다. 질문을 잊은 채로 답을 찾을 수는 없다. --- p.174

공학이나 프로세스를 혁명과 혁신으로 착각하는 순간 실패 확률은 높아진다. 공학이 혁신이 되기 위해서는 수많은 고개를 넘고 또 넘어야 한다 --- p.189

사전에 확정할 수 있는 요구 사항조차도 제대로 도출하지 않은 채 프로젝트를 시작하는 것이 진짜 문제다. 꿈을 이루기 위해서 도달하려는 그곳을 생생하게 그릴 수 있어야 하듯이, 명확한 요구 사항은 프로젝트 성공의 필수 조건이다. --- p.191

일을 하면서 결핍과 부족함을 피부로 느껴야 한다. 조직과 개인 모두 그 결핍을 메울 필요성을 절감해야 한다. 소프트웨어 공학의 수많은 방법론과 기술들에 관심을 가지는 것은 그때부터라도 결코 늦지 않다. 무엇이 문제인지도 모르는 상태에서는 아무리 비싼 수업료를 내더라도 결코 답을 알아낼 수 없는 법이다. --- p.195

이 모든 것이 깨진 유리창 하나, 즉 '나중에 시간 날 때 제대로 해놓아야지'하며 저질러 놓은 임시 코드 한 줄에서 시작된다. ‘나중’이라는 시간은 결코 나지 않는다. --- p.202

리팩토링을 언제 해야 하는가에 대한 정답 역시 없다. 굳이 정의하자면 ‘가장 적절하다고 판단될 때’이다. 상황에 따라 판단해야 한다. 따로 특정한 기간을 잡아서 리팩토링을 하는 것이 정답은 아니다. --- p.208

좋은 코드는 결국 이타적인 코드다. 그리고 그 이타성은 결국 자기 자신을 위함이라는 사실을 잊지 말아야 한다. --- p.212

타협할 수 없는 하나의 품질 속성이 출시까지 멀고도 길고 긴 소프트웨어 개발 주기를 버텨내기 위해서는 해당 품질에 대한 개발자들의 신념 체계는 필수적이다. 그리고 그 신념체계는 명확한 목표와 비전으로부터 온다. --- p.217

경험의 축적은 불가능과 가능을 구분하는 인식률을 향상시킨다. 무지로 가능했던 열정을 잃는 대신 사물을 판단할 수 있는 혜안을 얻게 되는 것이다. --- p.225

개발 도중 한번이라도 발견된 소프트웨어 이상 동작은 언젠가 어떤 형태로든 꼭 다시 나타난다는 것이다. 경험이 없는 개발자들은 이런 신호를 포착하지 못한다. 타성과 관성에 젖은 개발자들은 이런 신호를 무시한다. --- p.228

사실 주위를 둘러보면 1년의 경험을 10년 동안 반복하고 있는 사람들 천지다. 진정으로 나아지고자 하는 욕망이 있다면 환경이나 상황 탓은 이제 그만하고 작은 변화부터 시도해 봐야 한다. --- p.234

너와 나의 소통의 오류 또는 부재가 기술의 부재나 버그의 존재보다 더 심각하다. 조직 유지의 기본 바탕은 커뮤니케이션이며, 이는 서로가 어떤 언어를 사용하느냐에 달려 있다. --- p.238

철학을 가진 개발자라면 지엽에 얽매여서 전체의 균형을 잃어서는 안 된다. 또한 너무 일반론으로 흘러서 뜬 구름 잡는 이야기를 해서도 안 된다. 멀리 보고 일관적이어야 한다. 그런 매의 눈은 철학 없이는 만들어지지 않는다. --- p.252

단지 사람답게 살기 위해서 인문학은 필요하다. 상사와의 갈등에 대해 기술은 어떠한 해답도 제시해주지 못한다. 애인의 변심에 대해 스마트폰은 어떠한 분석 결과도 보여주지 못한다. 웅장한 자연과 불멸의 예술 작품 앞에서 프로그램의 버그 따위는 사소한 일이다. 빌게이츠에게도 코드를 이해하는 일보다는 사람을 이해하는 일이 더 중요하고 가치 있는 일이다. --- p.256

인문학은 책에만 있는 것이 아니다. 길 위에 있고, 옆 자리에서 거북목을 하고 코딩에 열중하고 있는 동료의 가슴속에도 있다. 말했듯이, 인문학을 공부하는 이유는 자신의 삶을 구원하고 삶의 촉수를 더욱 예민하게 만들기 위한 통찰력을 키우기 위함이다. --- p.257

나침반의 바늘 끝은 떨면서 북쪽을 가리킨다. 그 떨림이 멈춘다면 그것은 더 이상 나침반이 아니다. 끊임없이 자기 자신의 위치를 확인하고, 방향을 결정하는 것 - 그것이 인생이고 개발자의 삶이다.
이 땅의 모든 개발자들의 건투를 빈다.

<b>대상 독자</b><br/>_개발자로서 슬럼프에 빠져 가야 할 길을 잃어버린 당신<br/>_개발자로서 어떻게 성장 맵을 그려나가야 할지 막막할 때<br/>_개발자의 삶에 관해 진지하게 고민하게 되는 때<br/>_아무 생각 없이 프로젝트 톱니바퀴에 허우적대고 있을 때<br/>_주변에 당신을 이해하는 사람이 한 명도 없다고 생각될 때<br/><br/><b>개발자가 된 것을 후회한 적이 있습니까?<br/>기술과 사람, 그리고 나 자신을 알아가는 여정</b><br/><br/>저자는 소프트웨어 개발문화 전문가를 꿈꾸는 개발자다. 20년 개발자 인생을 살아오면서 기술이 “다”가 아님을 깨닫고 더 나은 개발자의 삶이란 무엇인지를 알기 위해 오늘도 고군분투 중이다. 이 책은 최근 수년동안 고민하고 연구한 저자의 항해일지인 셈이다.<br/><br/><b>[주요 내용]</b><br/>자신이 누구인지 모르는 상태로 어디를 가고 싶은지 정하는 것은 아무 의미가 없다. 자신이 가고자 하는 그곳이 정말 본연의 내가 원하는 그곳인지 깊게 생각해봐야 한다. _”프롤로그”<br/><br/>여정의 시작에 앞서 자기 자신을 제대로 알고 있다면 불필요한 문제와 고난들은 피할 수 있지 않을까? “당신은 어떤 개발자인가?”<br/>_”1장. 출항”<br/><br/>썩 괜찮은 개발자 생활에 만족하는 이들도 있을 것이다. 하지만 개발자의 삶은 대체로 녹록하지 않다. 이제 지금 하고 있는 일을 돌아볼 시간이다.<br/>_”2장. 끝없는 바다”<br/><br/>이제 항로를 결정할 시간이다. 자신이 어떻게 일을 해왔고 어떤 상황에 있는지 살펴보았다면, 이제 내면을 들여다 볼 시간이다.<br/>_”3장. 항로 찾기”<br/><br/>바다에는 풍랑도 있고 조류도 있다. 어떤 조류를 타고 항해하고 있는지에 따라 개발자의 삶 자체가 바뀔 수도 있음을 명심해야 한다.<br/>_”4장. 풍랑과 조류”<br/><br/>이제 목적지를 향해 항해를 시작했으니, 동료들과 프로세스를 이해할 차례다.<br/>_”5장. 함께 가는 길”<br/><br/>목표와 요구사항이라는 큰 그림을 그리는 것부터 변수명을 짓는 세부적인 방법<br/>까지의 방식을 스스로 점검해 볼 시간이다.<br/>_”6장. 항해 기술”<br/><br/>이제 항해를 마무리해야 할 때이다. 보다 나은 개발자의 삶을 위해 몇 가지 이야기를 전하려 한다. 독자 여러분에게 와 닿는 이야기가 있다면, 깊은 사색과 작지만 굳건한 한걸음이 필요한 시점이다.<br/>_”7장. 이타카”<br/><br/>이 땅의 모든 개발자들의 건투를 빈다.<br/>