[개발서적] 프로그래머, 열정을 말하다 핵심 내용 정리 및 요약

 

 

 

1. 당신의 시장을 선택하라

---

큰 투자를 하려고 한다. 큰돈을 투자하는 게 아니라 자신의 시간, 바로 자신의 삶을 투자하는 것이다. 경력이라는 흐름에 그저 떠다니기만 하면서 그 흐름이 가는 대로 자신을 내맡겨 버리는 사람이 많다.

그렇다면 왜 개발자들은 대부분 경력 선택에 이와 같은 주의를 기울이지 않을까? 경력을 사업이라고 생각한다면(사실은 그렇다), 자신이라는 “상품”은 자신이 제공해야만 하는 서비스로 구성된다.

그러면 서비스는 무엇인가? 서비스를 누구에게 팔려고 하는가? 서비스에 대한 수요가 향후 몇 년간 늘어날 것인가, 즐어들 것인가? 이러한 선택에 얼마나 큰 모험을 기꺼이 할 것인가?

 

 

[ 1. 그냥 앞서 갈 것인가, 위험까지 무릅쓸 것인가? ]

위험과 보상을 절충하는 것은 어느 기술과 영역에 투자할지 신중하게 고르는 데 중요한 부분이다.

지금까지 최첨단인 기술과 확고하게 기반이 닦인 기술을 선택하는 것에는 차이가 있음을 얘기했다. 세계적으로 기업 생산 시스템에 자리 잡은 안정된 기술을 선택하는 것이 아직 더 안전하다. 그러나 아무도 활용하지 않은 화려한 신기술을 고르는 것보다는 보상이 적을지도 모르는 선택이다.

 

 

[ 2. 수요와 공급 ]

소프트웨어 개발이 해외로 이전되는 추세 때문에 수많은 저임금 IT 종사자가 미국 경제권으로 들어왔다. 프로그래머들은 직장을 잃을까 걱정했지만 프로그래머 임금이 떨어지자 실제 수요는 전체적으로 늘어났다. 가격이 떨어짐과 동시에 수요가 늘어나는 현상이 생긴 것이다. 수요가 많은 제품끼리 경쟁이나 서비스 시장에서 발생하는 경쟁은 가격에 달려 있다. 고용 시장에서 이는 임금을 의미한다.

수요와 공급 모델에서 배울 수 있는 가장 중요한 교훈은 수요가 늘어나면 가격 경쟁도 따라서 심해진다는 것이다. 검증된 일자리를 따라가는 전략 때문에 해외 개발자들과 가격 경쟁에 처할 것이다.

 

 

[ 3. 코딩만으로는 이제 충분하지 않다 ]

회사에서 계속 쓸모 있는 사람으로 남고 싶다면 자신이 속한 사업 분야에 뛰어들어야 한다.

실제로 소프트웨어 개발자는 사업 분야를 이해하고 그에 해당하는 소프트웨어를 잘 개발할 수 있어야 할 뿐 아니라 그 분야 권위자가 되어야 한다.

사업 분야 경험을 자신의 능력 중 중요한 부분으로 생각해야 한다.

습득할 기술을 고를 때처럼 종사할 산업을 고를 때도 같은 관심을 기울여야 한다.

산업 분야를 잘 선택해야 하는 중요성에 비춰보면 포트폴리오를 완성할 대 여러분이 선택한 회사나 업계는 자신에게 중요한 투자처다.

 

 

[ 4. 가장 못하는 사람이 되라 ]

누구와 일하느냐는 것만으로도 기술이 엄청나게 늘거나 퇴보할 수 있다는 것을 배웠다. 사람이 집단을 이뤄 오래 일하면 업무 수행 능력에 지속적으로 영향을 받을 수 있다.

가장 못하는 사람이 되려고 하면 실제로는 자신을 과소평가하지 않게 된다. 사람들은 A급 밴드에 속할 수도 있지만 항상 B급 밴드에 들어간다. 두렵기 때문이다. 자신이 최고가 아님을 솔직히 인정하면 자신이 최고가 아니라는 사실이 알려지는 데 대한 두려움을 씻어낼 수 있다. 사실은 가장 못하는 사람이 되려고 할 때 실제로는 가장 못하는 사람이 되지 않을 것이다.

 

 

[ 5. 지성에 투자하라 ]

우리는 경험이 천편일률적인 사람보다는 다양한(아주 특이하더라도) 응시자에게 점수를 더 많이 준 것 같다. 유능한 사람은 다양성을 찾는다. 그런 사람들은 새로운 것을 배우기 좋아하기 때문이다. 또한 이질적인 경험이나 환경을 통해 더 성숙하고 다재다능한 소프트웨어 개발자가 되기 때문이다.

 

 

[ 6. 부모님 말씀을 듣지 말라 ]

부모님은 여러분이 크나큰 개인적 위험을 감수하고 남다른 경력을 만들기보다는 무난하게 살기를 바라실 것이다. 여러분이 의지하는 그 누구보다도 부모님은 두려움에 이끌리는 충고를 할 것이다. 두려움에 이끌리는 충고는 지지 않는 데 맞춰져 있다. 지지 않으려고 생각하는 것은 이기는 방법이 아니다. 승자는 위험을 감수한다. 승자는 자신이 어디에 가고 싶어 하는지 생각하지, 나머지 사람들이 어디에 있는지 생각하지 않는다.

한 세대 전, 재미는 경력 선택에 대해 이야기할 때 결정적인 요소가 아니었다. 일은 재미있을 필요가 없었다. 일은 생활비를 버는 것이었다. 재미는 쉬는 날에 하는 활동이거나 저녁이나 주말에 생기는 것이었다. 그러나 우리가 깨달았듯이 일이 재미있지 않다면 멋진 일을 하지 않는 것이다. 지금도 사정이 그다지 다르지는 않지만 일에 대한 문화적 이해가 점점 나아지고 있다. 열정이 우수함으로 이끈다는 점을 이해하는 사람이 더 많아지고 있다.

한 회사에 머물며 출세하는 것은 개발자로서 성장하는 데 제한된 환경이다. 전체 경력을 위해 큰 회사에 들어가 자리 잡고 “평생을 바치는 사람”의 시대는 갔따. 나라면 일을 하는 한 가지 방법만 아는 사람보다는 서로 다른 환경에서 다양한 성공과 실패를 겪은 사람을 고용할 것이다.

자신의 경력에서 계산할 수 있는 위험을 감수하라. 두려움이 자신을 파괴하게 두지 말라. 그리고 재미있지 않다면 탁월해지지도 않을 것이다.

 

 

[ 7. 다재다능한 사람이 되라 ]

자신의 목표가 구조 조정과 해외 이전의 한 가운데에서 살아남는 마지막 사람이 되는 것이라면 여러 방면에서 유용해지는 것이 좋다. 한때 붐볐던 개발 사무실이 국내 기간 사원 “수용 시설”이 될까봐 두려워한다면 팀에 자리가 얼마 남지 않았을 때, “단순 테스터”나 “단순 코더”는 많이 필요하지 않다는 것을 알아야 한다.

다재다능한 사람이 되려면 특정한 역할이나 기술에 매여서는 안 된다. 경력으로 해야 할 역할을 정하는 방법은 경력에 따라 다양할 것이다.

모두 자기 취향이 있지만 자신의 이상은 잠시 보류해야만 할 것이다. 하나를 습득하고 다른 하나에 능숙해지라. 자신의 기술이 기술 플랫폼을 넘나들어야한다. 기술은 단지 도구일 뿐이다.

 

 

[ 8. 진정한 전문가가 되라 ]

그러나 불행히도 소프트웨어 산업은 깊이가 얕은 전문가를 아주 많이 배출했다. 이들은 전문가라는 말을 “한 가지만 안다는 것에 대한 변명”으로 사용한다.

변화하는 컴퓨터 산업에서 살아남을 전문가는 이런 종류의 사람이다. 닷넷 전문가라는 것은 닷넷과 관계가 있는 일에 권위가 있다는 의미다.

 

 

[ 9. 자신의 달걀을 전부 다른 사람의 바구니에 넣지 말라 ]

지금은 매력적인 기술이지만 회사가 망해서 나중에 쓸모없어지면 어떻게 할 것인가? 왜 특정 회사의 특정 기술에 자신의 경력을 맡기고 싶어할까?

 

 

[ 10. 사랑하지 않으면 떠나라 ]

자신의 일에 “탁월”해지고 싶다면 자신의 일에 열정이 있어야 한다. 좋아하지 않으면 티가 날 것이다.

여러분을 신나게 하는 것이 기술일 수도, 사업 분야일 수도 있다. 반대로 특정 기술이나 사업 분야 또는 어떤 조직 형태 때문에 우울할 수도 있다. 작은 팀에 잘 맞을 수도, 큰 팀에 잘 맞을 수도 있다. 경직된 프로세스에 어울릴 수도 있고, 기만한 프로세스에 어울릴 수도 있다. 그런 것들이 어떻게 섞여 있든지 시간을 들여 자신만의 것을 찾으라.

열정이 충만한 것처럼 한동안은 속일 수 있겠지만 열정 부족은 자신과 자신의 일에 나쁜 결과를 가져올 것이다.

 

 

 

 

 

2. 자신에게 투자하라

---

[ 11. 물고기 낚는 법을 배워라 ]

노자가 말했다. “사람에게 물고기 한 마리를 주면 그에게 하루 먹을 양식을 준 것이다. 그러나 물고기 잡는 법을 가르치면 그에게 평생 먹을 양식을 준 것이다.” 훌륭한 말이다. 하지만 노자는 그 사람이 낚시 배우기를 싫어해서 내일 물고기를 또 잡아달라고 요구할 경우를 고려하지 않았다. 교육은 가르치려는 사람과 배우려는 사람 둘 다 필요하다. 그러나 마지못해 배우는 사람이 너무 많다.

다른 사람에게 좌지우지되기를 바라는 사람이 어디 있을까? 더욱 좋지 않은 상황은 다음과 같다. 여러분을 위해 일할 사람을 뽑으려고 하는데 전문가의 말에 끌려 다니는 사람이 필요할까? 나한테는 필요 없다. 나는 스스로 알아서 할 수 있는(self-sufficient) 사람을 원한다.

 

 

[ 12. 사업이 실제로 어떻게 돌아가는지 배우라 ]

우리는 회사를 위해 일하고 우리 일은 회사가 돈을 벌거나 절약하는 데 기여하는 것이었다. 그러나 우리는 사업에서 수익을 내는 방식의 기본을 이해하지 못했다. 더욱 심각했던 점은 그걸 아는 게 우리 일이 아니라고 생각했다는 것이다. 우리는 프로그래머이고 시스템 관리자였다. 우리 일은 우리가 몰두하는 주제들에 관한 것이라고만 생각했다. 하지만 사업이 어떻게 돌아가는지 이해하지 못하면서 사업에서 수익을 내도록 어떻게 창의적으로 도울 수 있겠는가?

우리가 진짜 IT 전문가라면 비즈니스 마인드를 지녀야 한다는 시각을 갖는 것이 합리적이다. 프로젝트를 올바르게 수행하고 리더십을 갖추는 것과 같은 비중으로 사업을 돕는 일에 노력을 쏟아야 한다. 그렇다고 사업이 어떻게 운영되어 가치를 창출하는지 완전히 이해할 필요는 없다.

 

 

[ 13. 멘토를 찾아라 ]

멘토가 존재하는 가장 중요한 첫 번째 목적은 역할 모델(role model)이다. 자신의 좁은 한계를 벗어나 더 발전하게 해줄 사람을 만나기 전까지는 뭐가 가능한지 알기 어렵다.

멘토는 또한 배우는 과정에 체계를 세워줄 수 있다. 이전 장에서 본 것처럼 어느 기술과 영역에 투자할지 정말 선택을 많이 해야 한다. 때로는 선택할 게 너무 많아서 어찌 해야 할지 모를 수도 있다. 합리적으로 생각해보면 가만히 앉아 있는 것보다는 한 방향으로 움직이는 편이 낫다. 멘토는 여러분의 에너지를 어디에 집중할지 선택하는 데 도움을 줄 수 있다.

멘토는 또한 신뢰할 수 있는 사람으로서 도움을 준다. 멘토는 여러분의 결정과 방법을 관찰하고 판단해 줄 수 있다. 프로그래머라면 멘토에게 코드를 보여 주고 멘토링을 얻을 수 있다.

마지막으로 재즈 음악에서처럼 멘토에게 개인적인 애정과 신뢰를 표하는 것뿐 아니라 그 반대도 가능하다. 관계 속에서 다른 사람을 돕는 역할을 한다는 것은 그 사람의 성공을 위해 힘쓴다는 뜻이다. 내가 옳은 방향이라 믿는 길로 그 사람들의 진로를 유도할 수 있다. 그 길을 통해 성공한다면 그것은 내 성공이기도 하다.

멘토링을 받은 사람이 성공한다면 멘토에게는 고무적인 일이다. 이미 많은 경험을 통해 성공한 사람은 일반적으로 인간관계에서 존경을 받는다. 멘토를 통해 멘토의 인맥과 긍정적으로 더 나은 관계를 맺을 수 있다. 이러한 관계의 중요성을 과소평가할 수 없다. 결국 “무엇을 아느냐보다 누구를 아느냐가 더 중요하다”라는 문구는 아무 의미 없는 진부한 표현이 아니다.

 

 

[ 14. 멘토가 되라 ]

무엇인가를 정말 배우고 싶다면 그것을 다른 누군가에게 가르쳐 보라. 어떤 것에 대한 이해를 구체화하는 데 가장 좋은 방법은 다른 사람이 이해할 수 있도록 그것을 표현하는 것이다. 말을 한다는 것은 단순한 행동이지만 불분명한 사고를 다루는 데는 특효약이다.

우리는 가르치면서 배운다. 선생이라면 이미 알고 있다고 생각하기 때문에 역설적으로 들릴지도 모른다. 물론 다른 사람들에게 새로운 사실을 가르쳐야만 그것을 배울 수 있다는 뜻은 아니다. 그러나 단순히 어떠한 사실을 안다는 것은 그것의 원인과 결과를 깊이 이해한다는 것과는 다르다. 다른 사람을 가르쳐 봄으로써 그것을 더 깊이 이해할 수 있다.

따라서 멘토를 찾아서 도움을 얻을 수 있는 것처럼 다른 사람에게 멘토가 되어도 자신에게 많은 도움이 된다.

멘토링은 긍정적인 사회적 효과도 있다. 멘토와 멘티의 유대는 강력하다. 멘토와 멘티가 집단적으로 교차하는 지점에서 빈틈없고 강력한 사회적 네트워크가 형성된다.

멘티를 얻는 것은 밖에 나가 자신을 고수(guru)라고 거창하게 선언한다고 되는 것이 아니라 해당 분야의 지식을 쌓고 그 지식을 참을성 있게 공유함으로써 가능하다. 자신이 어떤 주제에 관해 완벽한 전문가가 아니어도 불안해 할 필요는 없다.

 

 

[ 15. 연습, 연습, 또 연습 ]

컴퓨터 산업에서 개발자들이 자신의 한계를 뛰어 넘으려고 노력하는 것은 흔히 볼 수 있다. 불행히도 개발자들은 맡겨진 업무에 비해 자신의 자질이 떨어진다고 생각할 때 일반적으로 이렇게 한다. 컴퓨터 산업에서는 근무 중에만 연습을 하려는 경향이 있다. 전문 연주자가 무대에 올라 대학 연습실에서처럼 소음만 되풀이하는 모습을 상상할 수 있을까? 너그럽게 넘길 일이 아닐 것이다.

우리는 평소에 연습에 쓸 시간을 배치할 필요가 있다.

 

 

[ 16. 일하는 법 ]

소프트웨어 프로세스가 성공적으로 만들어지려면 프로세스를 사용하는 사람들이 그 프로세스를 받아들여야 한다. 바로 여러분 같은 사람들이다.

이 프로세스에 주인 의식을 느끼는 가장 좋은 방법은 프로세스를 만드는 일을 돕는 것이다. 자신이 속한 조직에 아무 프로세스도 없다면 자신에게 맞는 방법론을 조사하라. 점심 도시락을 싸가지고 와서 동료들과 함께 먹으면서 현재 개발 문제와 그것들을 완화할 수 있는 표준 프로세스를 채택하는 방법을 토의해 보라. 선택한 프로세스를 조직에 적용하고 모든 사람이 받아들일 수 있게 계획을 구성하고 수행하라.

가장 높은 생산성과 가장 좋은 제품을 동시에 만족하는 유일한 방법은 가능한 대안을 공부해 여러분과 팀이 이행할 수 있는 부분을 골라 실제 경험에 바탕을 두고 지속적으로 다듬는 것이다. 결과적으로 프로세스를 만들 수 없다면 제품을 만들 수 없다.

 

 

[ 17. 거인의 어깨 위에서 ]

패턴과 비법을 배우려면 많은 분량의 기존 코드를 파고 들어야 한다.

특정 문제에 대한 해결 방법을 찾는 것보다 더욱 중요한 것은 기존 코드를 자신의 스타일과 능력을 점검하는 확대경으로 삼는 것이다.

위대한 소프트웨어 개발자의 코드를 읽어도 마찬가지로 겸손해지는 효과를 본다. 그렇지만 그저 겸손해지는 것만은 아니다. 코드를 읽으면서 전에 해 본 적이 없는 것들과 결코 생각해 보지도 못했던 것을 발견할 것이다. “왜일까? 이 개발자는 무슨 생각을 하고 있었을까? 동기가 무엇이었을까?” 기존 코드를 이처럼 비판적으로 의식하며 탐구한다면 나쁜 코드에서도 배울 수 있다.

감사하게도 소프트웨어 개발자로서 우리는 오픈 소스 소프트웨어라는 형태의 거의 무한대의 기존 소프트웨어 모음에 접근할 수 있다.

코드 읽기의 긍정적인 부수적 효과는 기존의 것에 대해서도 더 많이 배운다는 점이다. 풀어야 할 새로운 문제가 생기면 “아, 어떤 프로젝트에서 MIME 타입 핸들링을 구현한 라이브러리를 봤어”하고 기억을 떠올릴 것이다.

아이작 뉴턴은 “내가 더 멀리 봤다면 그것은 ‘거인의 어깨 위에 서’있어서다.”라고 말했다. 뉴턴처럼 통명한 사람이라면 앞 세대로부터 배울 점이 많다는 사실을 알 것이다. 뉴턴처럼 되라.

 

 

[ 18. 자동화 기술을 이용해 일자리를 찾으라 ]

자동화는 IT 산업 DNA의 일부분이다. 어떤 이유 때문에 우리는 소프트웨어 개발자로서 우리 일을 자동화하려 하지 않았다. 해외 외주 경쟁자보다 소프트웨어를 더 빠르고 싸고 좋게 만들 수 있음을 어떻게 증명할 수 있을까? 로봇을 만들라. 자동화 기술을 이용해 일자리를 찾으라.

 

 

 

 

3. 실행

---

여러분은 대부분 돈을 벌려는 조직에서 일한다. 여러분이 할 일은 조직이 목표를 이루는 데 기여하는 무언가를 만드는 것이다.

 

 

[ 19. 지금 바로 ]

프로젝트를 경주라고 생각한다면 감옥살이처럼 지겨움 없이 훨씬 더 빨리 마칠 수 있을 것이다. 계속 움직이라. 밀어붙이는 사람이 되라. 편해지면 안 된다.

 

 

[ 20. 마음 읽기 ]

마법 같은 그만의 비밀은 내가 필요하다고 전에 스치듯 말했던 것을 그냥 묵묵히 했던 것뿐이었다. 내가 이야기했던 것들은 스스로도 분명히 파악하지 못한 미묘하고 민감한 내용이었다.

 

 

[ 21. 매일의 성과 ]

간단하게 목표를 세우고 이러한 성과를 추적하다 보면 자신의 행동이 근본적으로 바뀔 수 있다. 두드러진 성과가 무엇인지 찾을 때, 자신의 활동이 사업 가치에 바탕을 두고 있는지 평가하여 우선순위를 정하는 과정을 자연스럽게 거치게 된다.

적절한 빈도로 성과를 추적하면 확실히 정체되지 않을 수 있다. 날마다 성과를 하나씩 내겠다고 마음먹었다면, 완벽하게 태스크를 마무리하는 데 2주가 채 걸리지 않을지도 모른다. 이러한 방식으로 생각하며 일하는 것은 굳이 주된 생산의 과정이라기보다는 일종의 습관을 기르는 것이다.

 

 

[ 22. 누구를 위해 일하는지 기억하라 ]

“자신의 목표와 일을 사업 목표에 맞춰야 한다”라고 말하기는 정말 쉽다. 말은 정말 쉽지만 정작 실천하기는 정말 어렵다. 특히 프로그래머라면 매우 큰 조직 구조 밑에 묻혀 있어서 자신이 속한 사업이 무엇인지 거의 알지 못한다.

이는 프로그래머 잘못이 아니다. 우리에게 너무 많은 것을 요구하는 것일지도 모른다. 아마 회사의 손익에 직접 좋은 기여를 하려고 마음먹더라도 바다를 끓이려는 것처럼 막막하게 느껴질 것이다.

시작하기에 가장 확실한 웅덩이는 여러분이 속한 팀이다.

구조가 잘 갖춰진 환경에서 관리자의 목표는 결국 팀의 목표다. 관리자가 갖고 있는 문제를 풀라. 그러면 팀의 문제를 푸는 것이다.

작은 부분부터 시작함으로써 회사의 목표 달성에 기여할 수 있다.

 

 

[ 23. 현재 위치에 충실하라 ]

현재에 집중하다 보면 일과 생활의 작은 성취를 즐길 수 있게 된다. 예를 들면 일을 잘 했을 때의 느낌, 중요한 사업 문제에 전문가로서 참여할 때의 느낌, ‘잘 나가는’ 팀의 필수 멤버가 되는 느낌 같은 것들이다.

많은 사람이 항상 큰 것만을 바라보면서 자신의 일을 돋보이게 할 일상의 작은 것들은 무시하고 있다.

 

 

[ 24. 오늘은 얼마나 잘할 수 있을까? ]

우리는 재미있으면 일을 더 잘한다. 그래서 일에 아무런 흥미가 없을 때 우리는 지겨워하고 또 그 결과 때문에 고통스러워한다.

하루 일과를 보고 스스로 물어보라. “나는 오늘 얼마나 일을 잘할 수 있을까?” 아마 자신의 일을 더 좋아하게 될 것이다. 그리고 일도 여러분을 좋아할 것이다.

 

 

[ 25. 자신이 얼마나 가치가 있는가 ]

얼마나 많은 가치를 냈는가? 그 가치의 양을 가장 잘 잴 수 있는 방법에 대해 관리자와 이야기해 보라. 자신이 기여한 가치의 양을 재고 싶다는 사실 자체는 좋게 받아들여질 것이다. 어떻게 하면 회사 비용을 독창적으로 절약할 수 있을까? 어떻게 하면 개발 팀이 좀 더 효율적으로 변화될 수 있을까? 또는 소프트웨어의 최종 사용자는 어떤가? 이런 질문들을 하기 시작한다면 얼마나 많은 기회를 발견할 수 있는지 놀랄 것이다. 이제 그것들 중 몇 가지를 실천해 보라.

 

 

[ 26. 물 양동이 속 자갈 ]

직장에서 여러분의 존재는 회사로서는 물 양동이 속 자갈과 같다. 정말이다. 자갈 때문에 물 높이는 더 올라간다. 일을 다 하면 자기 몫을 다 한 것이다. 그러나 양동이에서 자갈을 꺼내고 되돌아서 물을 보면 실제로는 차이를 별로 느낄 수 없을 것이다.

자신을 대신할 수 없다고 자만하는 것은 나쁜 징조다. 특히 소프트웨어 개발자에게는 더욱 그렇다. 여러분을 대신할 수 없다면 그것은 여러분이 다른 사람이 할 수 없는 방식으로 일을 한다는 것을 의미한다. 우리는 모두 자신을 “특별한 천재”라고 주장하지만 아무리 탁월해도 그를 대신할 수 없는 개발자는 거의 없다.

 

 

[ 27. 유지보수를 즐기라 ]

회사에서 특정 업무가 어떻게 처리되는지 완전히 이해하는 사람은 유지보수 프로그래머뿐인 경우를 많이 봐 왔다. 유지보수 프로그래머만이 신뢰할 수 있게 인코드된 비즈니스 규칙을 직접 다룬다.

 

 

[ 28. 8시간 열중하기 ]

일에 관해서라면 적게 하는 것이 실제로는 더 많이 하는 것이 될 수 있다. 익스트림 프로그래머들이 이렇게 언급한 주된 이유는 피곤하면 쉬었을 때만큼 효과적으로 생각할 수 없기 때문이다. 힘이 빠지면 작업 품질이 눈에 띄게 떨어져 창조적일 수 없다. 어리석은 실수를 하기도 한다. 결국 시간과 돈을 낭비하는 것이다.

신중하게 근무 시간 계획을 세우라. 적게 일하면 더 많은 것을 성취할 것이다. 쉬어야 일도 즐겁다.

 

 

[ 29. 실패하는 법을 배우라 ]

우리는 모두 실수하기 때문에 다른 사람들도 실수한다고 생각한다. 따라서 우리가 저지르는 실수에 대해 서로를 비난하지 않는 것이 합당하다. 판단해야 할 것은 그러한 필연적인 실수를 어떻게 잘 처리할 것인가이다.

기술적 실수이든, 의사소통 실수이든, 프로젝트 관리 실수이든 다음과 같은 규칙이 적용된다.

• 알게 되자마자 문제를 제기하라. 오래 숨기려 하지 마라. 소프트웨어 개발과 테스트에서처럼 실수를 일찍 잡아내면 늦게 잡아내는 것보다 문제가 줄어든다. 더 일찍 문제를 끄집어내 자신이 한 것을 드러낼수록 부정적인 영향이 줄어들 것이다.
• 책임을 지라. 할 수 있더라도 속죄양을 찾으려 하지 말라. 혼자서 다 비난 받는 게 아니더라도 책임을 지고 나아가라. 목표는 최대한 빨리 이 시점을 지나가는 것이다. 문제는 해결해야 한다. 누구 잘못인지 책임자를 가리지 못해 질질 끄는 것은 논쟁만 오래 갈 뿐이다.
• 해결책을 제시하라. 자신에게 해결책이 없으면 해결책을 찾기 위한 착수 계획을 제안하라. 구체적이고 예측할 수 있는 기간으로 말하라. 팀을 궁지에 몰아넣었다면 문제를 되돌리는 데 필요한 노력이 얼마나 필요한지 판단해 그 기간을 알려주라. 작고 하찮더라도 구체적으로 달성할 수 있는 목표가 이 단계에서 중요하다. 목표가 있으면 상황을 계속 호전시킬 수 있을 뿐 아니라 프로세스에서 다시 신뢰를 쌓는 데 도움이 된다.
• 도움을 구하라. 문제에 대한 비난을 혼자서 받는다 하더라도 자존심 때문에 해결 과정에서 도움을 거절해 상황을 악화시키지 말라. 팀이 상황을 헤쳐 나가는 것을 돕는 동안 겸손한 태도로 자의식을 잠시 제쳐 둔다면 팀원, 경영진, 고객은 훨씬 더 긍정적인 눈으로 여러분을 볼 것이다. 책임감을 지나치게 느껴 많은 부담을 어깨에 올려놓고는 결국, 다른 누군가가 강제로 개입할 때까지 헛수고하는 일을 하지 말아야 한다.

 

 

[ 30. “아니오”라고 말하라 ]

약속을 지키지 못하는 지름길(?)은 지킬 수 없는 약속을 하는 것이다. 당연한 소리임을 안다. 그러나 우리는 매일 그런 약속을 한다. 우리는 곤란한 상황에 처해도 리더를 실망시키고 싶어 하지 않는다. 그래서 불가능한 일정으로 불가능한 일을 하는 데 동의한다.

“예”가 항상 바른 대답이 아니라는 점을 사람들은 받아들이지 못한다. “아니오”가 잘못된 대답이 아닐 때도 있는데 말이다. 이 사실을 내면화하라고 말하고 싶다.

 

 

[ 31. 당황하지 말라 ]

균형감을 잃어버리면 우리는 당황한다. 뭔가 잘못되면 문제에 모든 주의를 집중하게 된다. 어느 정도까지는 그게 문제를 푸는 좋은 방식이다. 불행히도 그것은 문제도 만들어낸다. 문제가 아무리 작아도 실제보다 더 중요하게 보인다는 것이다. 문제가 부풀려지고 긴장 수준이 높이 올라가면 우리의 뇌는 작동을 멈춘다.

자, 당황하지 않는 법을 내가 어떻게 배웠는지 이제 설명하겠다. 뭔가 나쁜 일이 생기면, 쳐지고 스트레스로 지친 느낌이 당황함으로 이어진다고 생각하기 시작한다. 내 자신을 좌절한 컴맹과 비교하고 조용히 웃는다. 워드 프로세서를 쓰다 재앙을 당한 가족을 돕는 것처럼 제3자 관점에서 상황을 분석한다. 어려워 보이던 문제가 갑자기 더 쉬워진다. 나빠 보이는 상황이 갑자기 그다지 나쁘지 않게 된다. 그리고 해법이 단순함을 발견하고 에러 대화 상자가 다음에 무엇을 할지 정확히 알려주는 것과 같은 방식으로 자신을 응시한다. 그냥 침착하게 에러 메시지를 읽기만 하면 문제가 풀릴 것이다.

 

 

[ 32. 말하고 행하고 보여주라 ]

계획은 억지로 삼키려고 숨을 가다듬어야 할 정도로 입에 쓴 약이 아니다. 계획을 세우면 오히려 자유로워지는 경험을 할 수 있다. 할 일이 너무 많을 때 계획을 세우면 오히려 자유로워지는 경험을 할 수 있다. 할 일이 너무 많을 대 계획을 세우면 하루 일을 헷갈리거나 애매하지 않게 시작할 수 있고, 일을 미리 착수할 때 명료한 확신이 생긴다.

계획을 세울 때 명심해야 할 가장 중요한 요소는 나중에 언제든지 설명할 수 있어야 한다는 점이다. 모든 항목은 마무리되거나 연기되거나 빠지거나 대체되는 것이 반드시 뚜렷이 드러나야 한다. 설명할 수 없는 항목이 있어서는 안 된다. 어떤 항목이 계획에 올라왔는데 다시 언급되지 않는다면 사람들은 여러분의 계획을 신뢰하지 않을 것이고 여러분이 짠 그 계획이 오히려 관련 계획을 효율적으로 짜는 일을 방해하게 될 것이다. 결과가 나빠도 그대로 알려야 한다. 우리는 모두 실수한다. 자신을 구별 짓는 방법은 자신의 실수와 무능력을 공개적으로 알리고, 그것들을 해결하는 데 도움을 구하는 것이다.

계획에 관하여 의사소통하면 사람들이 여러분을 더욱 신뢰하게 되는 이점이 있다. 계획을 말하고 그것을 실천하면 여러분은 “실천가”라는 평판을 얻을 것이다. 신뢰가 쌓이면 영향력도 생긴다.

 

 

 

 

4. 마케팅은 높으신 분들만 하는 게 아니다

---

많은 소프트웨어 개발자들, 특히 자만심이 강한 사람들은 실력이란 것이 뭘 좀 아는 관리자나 경영진에게는 그냥 드러나게 마련이라고 오해하며 사는 거 같다. 그런 사람들은 겸손한 척하는 것이 도덕적이라고 생각한다. 너무 “겸손해서” 자기 능력을 팔지 못한다.능력을 굳이 알리려는 것은 잘 보이려고 “아부”하는 것이라고 생각한다. “그분”에게 잘 보이려고 하는 프로그래머들은 자신의 자긍심을 버린 사람들이라고 생각한다.

전부 핑계일 뿐이다. 사실 그사람들은 두려워하는 것이다.

 

 

 

[ 33. 인식이 대수롭지 않다고? ]

여러분이 일을 아주 잘 하는데 아무도 보지 않으면 정말 일을 잘한 것일까? 누가 신경이나 쓸까? 아무도 안 쓴다.

우리는 남에게 잘 보이려고 하는 것이 다소 지저분하고 부끄러운 행동이라고 인식하도록 문화적으로 길들여졌다. 그러나 여러분이 본 것처럼 다른 사람에게 좋은 인상을 주려는 것은 실용적이다. 어떤 요소가 사람들에게 자신을 인식시키게 하는지 분명하게 주의를 기울이면 고객을 만족시키는 법을 더 확실하게 알 수 있을 것이다.

 

 

[ 34. 모험 여행 안내자 ]

개발자는 IT 세계라는 까다로운 세계를 여행하는 고객의 안내자다. 개발자는 고객이 낯선 곳을 여행하는 동안 편안하게 안내해야 한다. 개발자는 고객에게 전망을 보여주고 고객이 가고 싶어 하는 곳으로 데리고 다녀야 하지만 자신이 전에 만났던 불편한 곳은 피해야 한다.

 

 

[ 35. 나를 글이 잘 정말 써 ]

말수가 적은 프로그래머의 시대는 갔다.

따라서 의사소통 문제가 중요하다. 회사에 계속 다니기 위해 해야 할 일 목록에 “의사소통 능력 향상”이 있다니 작위적이고 어리석고 하찮게 느껴질 것이다. 그러나 이번에는 정말 주의를 기울여야 한다.

실제로 한 발짝 물러서서 전체를 보면 작문 능력이 필요하지만 작문 실력이 좋은 사람은 별로 없다.

알다시피 노동력은 세계적으로 분산되고 있다. 이러한 경향이 계속되면 회사에서 대부분 인스턴트 메시징이나 이메일을 통해 글로써 의사소통을 하는 때가 올 것이다. 현재 실제 그렇게 하고 있는 경우도 많다.

글을 많이 쓰게 될 것이다. 일 중 많은 것이 글쓰기와 관련 있다면, 당연한 얘기지만 글을 잘 쓰는 것이 못 쓰는 것보다 낫다. 그 어느 때보다 자신에 대한 인식이 글쓰기 능력에 바탕을 두고 형성될 것이다.

 

 

[ 36. 현장에서 부대끼라 ]

직접 보고 이야기하면 믿을 수 없을 정도로 효과적이다. 상대방 이야기를 좀 더 분명하게 들을 수 있다. 핵심을 이해시키기 위해 손동작을 쓰거나 화이트보드에 그리는 것 같은 시각적인 것을 사용할 수 있다. 우리는 의식적으로 깨닫지 못해도 많은 내용을 은연중에 얼굴로 표현한다.

마주 보고 대화를 하면 생산성이 올라가고 관계가 나아질 뿐 아니라 개인적인 유대도 더 단단해진다. 누군가를 직접 만나지 않는다면 우정이라는 것을 만드는 데 시간이 더 오래 걸릴 것이다.

효과적이고 활발한 의사소통으로 맺어진 강력한 팀 관계는 더 좋은 소프트웨어를 더 빨리 전달하는 데 기여한다. 대부분의 환경에서 중요한 프로젝트 결정은 커피를 마시며 쉬면서 가벼운 대화를 나눌 때 이루어진다.

 

 

[ 37. 적절한 표현으로 말하기 ]

준비할 시간이 몇 분이라도 주어지면 자신이 하고 있거나 최근에 했던 일의 사업적 이익을 설명할 수 있는가? 기술적으로는 비전문가인 고위 경영진이 “이해”할 수 있을 뿐 아니라 “판단”할 수 있는 말로 설명할 수 있는가?

 

 

[ 38. 세상을 바꾸라 ]

그러나 고임금 국가에서 소프트웨어 개발자가 되고 싶다면 사명감을 가지고 일해야 한다. 여러분이 변화를 가져와야 한다. 자신의 변화나 일의 변화가 아니다. 팀이나 조직, 회사에 눈에 보이는 변화를 가져와야 한다.

물론 세상을 바꾸려고 애쓰면 몇몇 사람을 화나게 할 수밖에 없다. 그러나 의도가 올바르면 괜찮다. 서두르면 안 되지만 빙빙 돌리지도 말라. 항상 신중하면 된다.

 

 

[ 39. 자신의 목소리가 들리게 하라 ]

시선을 더 높게 두라. 자신을 특정 회사에서 일하는 프로그래머가 아니라 업계의 정회원으로 생각하라. 결국 한 회사에 영원히 있지 않는다는 말이다. 여러분은 장인이거나 예술가다.

회사는 전문가를 고용하고 싶어 한다. 프로젝트 목록이 충실하게 들어 있는 이력서도 경력을 선전하는 좋은 방법이지만, 그 면접관이 여러분에 대해 이미 알고 있는 것이 가장 좋다. 면접관들이 여러분의 기사나 책을 읽었거나 컨퍼런스에서 발표하는 것을 보고 알았다면 특히 좋다.

소프트웨어 개발자를 고용하는 객관적인 등급 평가 시스템은 없다. 실력이 좋다고 해서 항상 취업이 잘되지는 않는다. 컴퓨터 산업도 음악 산업처럼 사람들이 서로 거미줄처럼 연결되어 있는 크고 복잡한 네트워크다. 네트워크에 연결된 곳이 많을수록 완벽한 일자리나 경력 전환점에 연결될 가능성이 더 높아진다. 스스로 자신을 현재 일하는 회사에 묶어두면 형성할 수 있는 네트워크 연결 수에 심각한 한계가 생긴다.

자신의 주장을 널리 알리고 이름을 알리는 데 명심해야 할 것은 자신이 준비됐다고 생각할 때까지 기다리지 말고 바로 시작하라는 것이다. 사람들은 대부분 자신을 너무 낮춘다. 분명 타인에게 도움을 줄 만한 구석이 있을 것이다. 어떤 경우라도 100% 완벽한 준비는 없다. 시작이 반이다. 지금 시작하라.

 

 

[ 40. 자신의 브랜드를 만들라 ]

브랜드를 만드는 데는 두 가지 측면이 있다. 사람들이 쉽게 알아볼 수 있게 자신의 로고를 실제로 만든다. 이 로고는 사람들에게 반드시 긍정적으로 인식되어야 한다. 즉, 올바르게 인지되어야 하고 또 인정받아야 한다.

여러분의 이름이 곧 여러분의 브랜드다.

가장 중요한 점은 자신이 선택한 것과 관련된 것이 자신의 이름으로는 지속적인 영향을 끼침을 기억해야 한다는 것이다. 그리고 이러한 상호 작용 중 아주 많은 것이 인터넷의 공개 토론장, 웹 사이트, 메일링 리스트에서 일어나기 때문에 많은 행동이 공개적으로 기록되고 캐시되고 색인되고 검색될 수 있다. 영원히 말이다.

사람들은 잊어버릴지 모르지만 구글은 절대 그렇지 않다.

할 수 있는 한 자신의 브랜드를 지켜야 한다. 자기 스스로 보호하라. 브랜드가 중요하다.

 

 

[ 41. 자신의 코드를 공개하라 ]

여러분이 짠 소프트웨어에 이미 의지하고 있는 회사가 있다면 일자리를 찾기가 얼마나 쉬울지 상상해 보라.

그 사람은 자기 힘으로 명성을 쌓고 업계에서 평판을 만든다. 의도적으로 하는 게 아닐지도 모르지만 그 과정에서 자신을 적극 선전한다.

자기 힘으로 명성을 쌓는 것은 제쳐 놓더라도 오픈 소스 소프트웨어에 기여하는 것은 자신의 분야에 대한 열정을 보여주는 것이다. 회사가 여러분의 소프트웨어를 쓰지 않거나 들어보지 않았더라도 소프트웨어를 만들고 발표했다는 사실은 그 자체로 눈에 띈다.

오픈 소스에 대한 기여는 실력을 실제로 보여주는 것이다. 좋은 코드를 짜서 실제 프로젝트에 기여한다면 어떤 기술을 안다고 그냥 말하는 것보다 이력서를 쓰는 데 훨씬 좋을 것이다.

 

 

[ 42. 주목받는 남다른 능력 ]

남달라지려면 주변 것들과는 크게 달라야 한다. 이 장에서 논의한 여러 가지 자가 마케팅 전략은 남달라지기 위한 것이다. 성공적인 오픈 소스 소프트웨어 발표, 책과 기사 쓰기, 컨퍼런스에서 발표하기를 통해 더욱 남달라질 수 있을 것이다.

가장 똑똑하거나 빠른 사람이 되는 것으로는 충분치 않다. 실행해내야 한다.

 

 

[ 43. 어울리라 ]

정말 좋은 사람들은 여러분이 그 사람들을 알고 싶어 하는 걸 꺼려하지 않는다. 사람들은 인정받기를 좋아하고 자기가 열정을 품은 주제에 이야기하기를 좋아한다. 그 사람들이 전문가, 고수, 리더, 유명한 작가라는 사실 때문에 다른 사람들과 사귀기를 좋아한다는 사실이 바뀌지는 않는다.

덧붙여 말하자면 평범한 사람과 우리가 존경하는 사람 사이의 가장 심각한 장벽은 우리 자신의 두려움이다. 여러분을 가르칠 수 있거나 여러분이 일을 찾을 수 있게 도울 수 있는 똑똑하고 배경 좋은 사람들과 어울리는 것은 스스로를 개선할 가장 좋은 방법인데도 시도해 보기를 두려워 하는 사람이 많다.

고수는 전문적인 사회적 네트워크에서 슈퍼노드다. 스스로를 너무 비하하지 않는다면 관계를 맺는 것은 어렵지 않다.

 

 

 

 

5. 자신의 강점을 유지보수하라

---

[ 44. 이미 구식 ]

알고 있는 지식이 주류일수록 “기술 석기 시대”에 남겨질 위험이 크다는 사실을 말하려는 것이다.

오늘날의 흐름에서는 첨단에 있더라도 다음에는 뒤에 있을지도 모른다는 사실을 깨닫는 것으로 시작해야 한다.

 

 

[ 45. 이미 일자리를 잃었다 ]

자, 프로그래머로 고용됐따면 스스로를 프로그래머로 생각하지 말라. 더는 프로그래머가 아닐지도 모른다고 생각하라. 일을 계속 하지만 편해지지는 말라. 프로그래머나 디자이너 아니면 테스트라는 “정체성”에만 안주하려고 하지 말라.

 

 

[ 46. 목적없는 길 ]

결과에 집중하다 보면 과정을 개선하는 데 게을러질 수 있다. 사실 과정이 나쁘면 나쁜 제품을 만들어낸다. 제품이 최소 요구 사항을 충족했는지 모르지만 그 속은 추할 것이다. 단기 목표만 최적화했지, 필연적으로 계속될 제품 개발의 미래는 최적화하지 않은 것이다.

나쁜 과정이 나쁜 제품을 만들 뿐 아니라 나쁜 제품이 나쁜 과정을 만든다. 제품 중 하나가 속이 엉망이더라도 과정은 그에 맞춰진다. 제품의 “깨진 창문”이 과정에서도 깨진 창문을 만들어낸다. 악순환이다.

따라서 “아직 안 됐나요? 아직 안 됐어요?”라고 계속해서 물을 때, “아직, 안 됐습니다.”라고 대답하는 것만이 올바른 태도임을 깨달으라. 중요한 것은 길을 가는 과정이지, 목적지가 아니다.

 

 

[ 47. 로드맵을 만들라 ]

개인 성과 로드맵으로 “자신의 움직임”을 알 수 있다. 날이면 날마다 같은 사무실에 나가 수많은 똑같은 일을 한다고 자기 주변 환경이 바뀌지는 않는다. 앞으로 나아갈 지점을 정할 필요가 있다.

 

 

[ 48. 시장을 주시하라 ]

현재 실력으로 현재 일자리에 만족하다 보면 차세대 대박 기술이 몰려올 때 그에 대해 완전히 무지한 사람이 되어 있을 것이다.

눈과 귀를 항상 열어 두어야 한다. 기술 소식을 사업 측면과 순수하게 기술적인 측면에서 보면서 어떤 파문이 일어나는지 주시하라.

 

 

[ 49. 거울 속 그 뚱뚱한 남자 ]

비유했듯이 거울 속 자신을 매일 보기 때문에 몸무게가 약간 느는 건 알 수 없는 것과 같다. 예전처럼 적당해 보일 것이다. 예전과 같이 경쟁력 있게 보일 것이다. 기술 역시 예전처럼 최신으로 보일 것이다.

그러다 어느 날 일이 갑자기 맞지 않는다.

자신을 측정하기 쉬운 방법은 신뢰할 만한 제3자를 이용하는 것이다. 멘토나 가까운 동료는 여러분이 어디에 서 있는지 좀 더 객관적으로 볼 수 있다.

자기 점검 일정을 잡으라. 반영 시간을 분명히 잡지 않으면 아무 소용없다. “조언을 구하는 것을 잊지 말라”라고 말하는 것은 그다지 강한 메시지가 아니다. 알림 기능이 있는 달력 프로그램이 있으면 스스로 자가 평가를 위한 약속을 잡으라.

회사에 적절한 프로세스가 이미 있다면 인적자원 관리부서의 허튼 짓이라고 무시하지 말라. 그것을 진지하게 받아들여 좋은 결과를 만들라. 엉성하게 만들어졌을지도 모르지만 동기는 올바른 것이다.

 

 

[ 50. 남인도 원숭이의 덫 ]

가치 경직성이란 어떤 것의 가치를 너무 단호하게 믿어 그것에 대해 더는 객관적으로 의문을 품을 수 없을 때 생기는 현상이다.

그러나 경직되게 믿는 가치는 전부 좋지는 않다. 또 어떤 환경에서 좋은 것이 다른 환경에서는 좋지 않을 때가 많다.

경력에서 선택할 방향이든, 옹호하고 투자할 기술이든 원숭이 덫을 주의하라. 원래는 의도적으로 선택한 기술이었찌만 한 움큼의 쌀이 되어 경력이 끝장나게 될지도 모른다.

 

 

[ 51. 폭포수 모델 방식의 경력 계획은 피하라 ]

소프트웨어 개발에서 일군의 전문가들이 어떤 방식을 따르느냐에 따라 소프트웨어 프로젝트가 실패하기도 하고 성공하기도 하는 경향이 형성되고 있음을 깨닫기 시작했다.

당시 산업은 소프트웨어 프로젝트를 개발하는 방법은 하향식에, 빽빽하게 계획되고 엄밀한 프로세르를 따느는 것뿐이라고 믿도록 유도됐다.

이러한 프로세스를 폭포수 프로세스(waterfall process)라고 하며 요즘 이 용어는 나쁜 프로세스와 일반적으로 거의 똑같이 취급된다.

애자일 연합 구성원들은 당시 대부분 조직이 따르던 무거운 프로세스가 잘 테스트되고 문서가 꼼꼼하게 작성된 소프트웨어를 만들지만, 이는 소프트웨어 사용자가 원하는 것이 아님을 깨달았다. 이 혁명은 애자일 방법론 일가를 만들어냈다. 애자일 방법론들은 쉽게 변경하는 데 적합한 소프트웨어 개발 프로세스다. 사전 계획과 설계에 시간을 덜 쓰는 것이다. 소프트웨어는 잘 변하므로 소프트웨어를 바꾸는 것도 손쉬워야 한다. 애자일 방법론은 변경을 소프트웨어 개발에서 거듭되는 부분으로 가정하고 변경을 될 수 있으면 싸고 쉽게 할 수 있게 방법론을 조정했다.

그러다 그 동기부여와 영향력이 그냥 소프트웨어 개발만이 아니라 좀 더 일반적인 상황에도 적용됨을 알았다. 복잡한 문제를 풀어야 할 때마다 반복적이고 변경이 쉬운 문제 해결 접근 방식이 항상 스트레스가 덜 하고 내게 더욱 효과적임을 깨달았다.

하지만 웬일인지 내가 관리해야 했던 가장 복잡하고 긴장되고 중요한 프로젝트는 내 경력이었음을 깨닫는 데 긴 시간이 걸렸다.

깨달아야 할 중요한 점은 경력에서 변화는 가능할 뿐 아니라 필요하다는 점이다. 소프트웨어 개발자로서 고객이 원하지 않는 것을 개발하는 데 결코 자신을 쏟아 붓고 싶지는 않을 것이다. 애자일 방법론이 그런 일을 피하는 데 도움이 된다. 경력에서도 마찬가지다. 목표를 크게 세우더라도 꾸준히 수정하라. 경험에서 배우고 일해 나가면서 목표를 바꾸라.

 

 

[ 52. 어제보다 나은 ]

따라서 여러분이 애쓰는 크고 까다로운 목표 대부분을 위해서는 목표에 더 가까워지는 것을 생각하지 말고, 어제보다 그 목표를 향한 노력을 좀 더 잘했는지 생각하는 것이 중요하다.

 

 

[ 53. 독립하라 ]

문제는 회사의 계층 구 조라는 안전망 때문에 사람이 쳐진다는 점이다. 기억 부서에서 대부분 교묘하게 이용하는 병범함이라는 방패 뒤에 숨는다면 탁월해질 동기가 그닥 없다.

여러분에게는 기술이 있고 그것을 연마해 왔다. 자신이 얼마나 가치 있는지도 안다. 독립 계약자가 되는 것은 결정적인 테스트다.

독립은 어렵다. 전문가로서 자신의 기술을 전부 시험대에 올려야 한다. 아직 준비되지 않았을지도 모른다. 좋은 소식은 완전히 독립할 필요는 없다는 것이다.

 

 

 

이번에 읽은 책은 프로그래머, 열정을 말하다라는 책입니다. (2012년 출판) 나온지 10년이 넘었음에도 불구하고, 오늘날에도 아주 유효한 내용들을 다루고 있고, 그 내용들이 장황하지 않고 핵심만 간결하게 전달하며 읽기 좋았던 것 같네요! 개인적으로 읽은 개발책에 대한 도서 평가 시트를 작성중인데, 5점 중 만점을 줄 정도로 내용이 좋은 것 같습니다ㅎㅎ 한번쯤 읽어보시면 좋을 것 같네요:)