프로그래머의 길, 멘토에게 묻다 책을 읽고 정리한 내용입니다.

1장 들어가는 글

  • 더 나은 일자리, 프로젝트 끝내기, 훌륭한 개발자 되기와 같은 목표를 달성하려면 무엇을 어떻게 배워가야 좋을지 알기 위해 애쓰며 전장에 나가 있는 사람들인 소프트웨어 개발의 초심자들을 위한 것이다.
  • ‘견습과정 패턴’은 경력을 발전시키기 위해 소프트웨어 장인 모델을 적용하고자 하는 이들에게 길잡이가 되고자 한다.
  • ‘패턴 언어’의 틀로 구성되어 있다. 패턴 언어란 특정한 분야에서 흔히 발생하는 문제를 다루는 한 묶음의 서로 연관된 해법들을 일컫는 말이다.
  • 소프트웨어 디자인 패턴에 대한 책 중 가장 유명한 것은 ‘The Gang of Four’가 쓴 Design Patterns이지만, 패턴’언어’의 예로는 마틴 파울러의 Refactoring이 더 나은 것 같다.
  • 견습과정은 당신의 경력에서 다른 무엇보다도 자신의 성장에 초첨을 맞추게 되는 시기다.

2장 잔을 비우다

  • 이전에 비해서 새 기술을 익히는 일이 힘들어 질 때
    • ‘알지 못하는’ 태도를 취한다.
    • 배운 것을 잊어버릴 수 있는 기회를 찾아보라. 이전의 경험을 일시적으로 잊어야 하는 상황이라면 이상적일 것이다. 예를 들면, 특정 프로그래밍 패러다임(명력적, 객체 지향적, 함수형, 배열/벡터 지향적 등)으로 작성했던 프로그램을 하나 골라서 다른 패러다임에 속한 언어로 구현해 보자.
  • 현재보다 더 나은 학습 기회를 얻고자 재능 있는 장인들이 모인 팀에 들어가서 할 수 있는 역할을 찾고 싶을 때
    • 구체적인 기술을 습득해서 유지하라.
    • 구체적 기술의 예를 들면, 여러가지 대중적인 언어로 빌드 파일 작성하기, 하이버네트 같이 잘 알려진 오픈소스 프레임워크에 대한 지식, 기초적인 웹 디자인, 자바스크립트, 그리고 당신이 선택한 언어의 표준 라이브러리 등이 있을 것이다.
    • 여기에 직접 작성한 토이 프로그램을 들고 갈 정도면 더할 나위 없다.
  • 깊은 쪽으로 뛰어 들어라. 다 준비될 때까지 기다리다가는 아무 일도 못 할수가 있다. 그러므로 당신에게 두드러지는 역할이나 어려운 문제가 주어진다면, 그 기회를 놓치지 말고 두 손으로 꽉 잡아라.

3장 긴 여정을 걷다

  • 우리가 고객을 위해 만드는 그 무엇인가가 아름다울 수는 있겠지만, 반드시 쓸모 있어야 한다.
    • 비록 당신 마음에 차지는 않더라도 고객들이 만족할 만한 제품을 지닌 결과물이라면 내놓아야 한다는 것이다.
    • 스스로 만족하기 위해서가 아니라 현실적인 문제와 씨름할 때 기량은 연마되는 것이다.
  • 돈을 벌기 위한 소프트웨어와 만들기에 재미난 소프트웨어 사이에는 서로 겹치는 부분이 그다지 많지 않다. 당신이 돈을 벌고자 한다면, 너무 지저분해서 누구든 공짜로는 해결하려 들지 않는 그런 문제를 안고 씨름해야 할 때가 많다.
    • 황금 족쇄: 뭔가 새로운 걸 배우고 싶지만, 내가 이미 알고 있는 것만으로도 벌이가 너무 좋다.
    • 삶의 다양한 측면과 조화를 이루면서 소프트웨어 장인정신에 대해 열정을 키워 가는 태도가 반드시 필요하다.
  • 열정을 질식시키는 환경에서 일하고 있을 때
    • 부서도 괜찮은 장남감을 만들어 보자.
    • 마음 맞는 사람들을 찾아라.
    • 배운 것을 공유하라.
    • 고전을 공부하라.
    • 숙달의 경지로 가는 길과 경력, 생계가 일치되는 여행자들은 운이 좋다. 그렇지 못한 사람들은 근무 시간을 피해서 연습할 시간과 장소를 찾아야 한다.
  • 자신만의 지도를 그려라.
    • 고용주가 제시하는 경력 노선이 당신의 필요나 목표, 포부와 상반될 때 당신이 가려는 방향과 맞아 떨어지게 경력을 쌓을 수 있는 조직으로 옮겨라.
    • 주변 환경에 대해 미리 명확하게 경계를 지어라.
      • 다른 사람들이 야근할 때 먼저 퇴근
      • 험한 말이 오가는 회의에서 나오기
      • 냉소적 대화를 건설적 주제로 전환
      • 자신의 최저 기준에 부합하지 않는 코드의 배포를 거부
      • 그 결과, 당신은 연봉인상, 승진, 명성, 인기 같은 것과는 거리가 멀어질 수 도 있다. 하지만 당신이 해로운 환경에서 벗어나서 자신의 열정을 굳게 지키고자 한다면, 이렇게 경계를 지어야 한다.
    • 구성원들이 스스로 설정한 목표를 이루려는 노력을 뒷받침해 주는 조직도 있을 것이다. 하지만 또 다른 조직에서는 그렇지 않을 곳이다. 만약 당신이 속한 곳이 이런 조직이라면, 능력의 폭을 넓히고 길잡이가 되어 줄 멘토를 찾음으로써 다른 직장을 알아보기 시작할 필요가 있다.
  • ‘선임’, ‘아키텍트’, ‘수석’같은 단어가 붙은 직위로 (공식적이든 비공식이든) 고용되거나 승진되었다. 하지만 이런 직위와 당신은 잘 맞지 않는 듯 하다. 공식적인 자리에서 자신을 소개할 때면, 왠지 당신의 역량과 직무 내용이 차이 나는 데 대해 사과하거나 변명이라도 해야 할 것 같은 생각이 든다.
    • 그럴 듯한 직함에 속지 말라. 그런 직위와 책임이 당신의 견습과정이 끝났음을 나타내는 것은 아니다. 그것은 단지 우리 업계에 얼마나 장인이 부족한지 일깨워주는 역할을 할 뿐이다.
  • 숙련됨은 연습을 중단하는 그 시점부터 퇴보하기 시작한다. 당신이 프로그램을 짜지 않는 하루하루마다 숙련공으로 가는 길은 점점 더 멀어진다.
  • 당신의 삶에서 무언가 다른 일을 해 보는 것을 두려워하지는 말았으면 한다. 소프트웨어 개발로부터 멀어진다고 해도, 엄격한 사고방식과 다량의 데이터 관련 작업을 자동화하는 습관 자체는 당신이 어디를 가게 되든지 유용할 것이다. 소프트웨어 장인으로서 지냈던 과거는 당신이 택한 어떤 미래든지 더 풍요롭게 해줄 것이다.

4장 정확한 자기 평가

  • 멘토를 찾아라
    • 당신보다 훨씬 많이 알 거라는 이유로 자신의 멘토는 마스터야 한다는 생각에 빠지기 쉽다. 당신은 이러한 유혹에 저항해야 하는데, 그러지 않는다면 멘토가 가진 어쩔 수 없는 약점이나 맹점에 대해 환멸을 느낀 나머지, 아직 가르침 받을 것이 많음에도 불구하고 더 배울 것이 없다고 여길 우려가 있기 때문이다.

5장 끊임없는 학습

  • 소스를 활용하라
    • 주변에 좋은 코드와 나쁜 코드를 구별할 만한 사람이 없는 환경에서, 당신이 짜 놓은 코드가 제대로 짠 것인지를 어떻게 알 수 있을까?
    • 다른 사람의 코드를 찾아서 읽어라.
      • 오픈소스 프로젝트를 들어다볼 때는 가장 최신 버전의 소스를 다운로드해서, 과거 이력을 조사하고 차후의 진행을 따라갈 수 있도록 하라.
      • 소스 트리의 구조를 살펴보고, 파일들이 왜 그런 식으로 배치되었는지 알아내 보라.
      • 개발자들이 코드를 그런 식으로 모듈화한 이면에 무슨 이유라도 있는지 찾아보고, 당신이라면 어떻게 했을지 비교해 보라.
      • 프로그래머들이 어떤 까닭에서 그런 선택을 했는지 이해하기 위해서, 그리고 만약 당신이 그 코드를 작성한 사람 중 하나였다면 어땠을지 보기 위해서 코드의 리팩터링을 시도해 보라. 이렇게 하면 이 프로젝트에 대한 이해가 높아진다.
    • 다른 이들의 소스코드를 읽는 것에도 열린 태도여야 함을 기억해 두라.
      • 프로그래머들은 실무에서 코드 작성보다 코드 읽는 데 훨씬 더 많은 시간을 소비한다는 사실을 간과하는 경향이 있다.
      • 다른 사람들이 작성한 갖은 종류의 좋거나 나쁘거나 그저 그런 코드를 읽음으로써, 당신은 특정한 언어 커뮤니티에서 쓰는 관용적인 어법이나 미묘함을 배울 수 있다.
      • 사람들이 작성한 코드로부터 그 의도를 꿰뚫어 보는 능력을 키울 수 있을 것이다. 왜냐면 기존 코드가 무슨 일을 하는지 몰라서 늘 새로 작성하게 되는 일 없이, 타인이 이미 작성해둔 코드를 가지고 작업할 수 있기 때문이다.
    • “프로그래밍 능력을 테스트하는 가장 좋은 방법 중 하나는, 프로그래머에게 30페이지 정도의 코드를 건네주고서 그 사람이 얼마나 코드를 통독하고 이해하는지 보는 것이다” (빌게이츠)
    • 패턴, 관용 어법, 우수한 사례들에 대해 배우는 가장 좋은 방법은 오픈소스 코드를 읽는 것입니다.
    • 프로젝트의 소스를 둘러보면서, 생소한 알고리즘이나 자료구조, 설계 사상 같은 것들을 기록해 두라.
  • 배운 것을 기록하라
    • 배운 것을 기록만 하고 그냥 잊어버리는 덫에 빠지지 않게 노력하라. 당신이 썼던 글을 정기적으로 다시 읽어라. 글을 리뷰할 때마다 새로운 연관 관계를 만들어 보라. 이렇게 창조적인 리뷰를 함으로써, 전에 내렸던 결정이 새 데이터에 기초해서 재평가될 수도 있고, 모호했던 신념이 확고해질 수도 있다.

  • 좋은 프로그래밍 책을 두 달에 한 권, 즉 일주일에 대략 35페이지 정도만 읽어도 당신은 이내 이 분야에 대해서 확실한 감을 갖게 될 것이며 주변의 거의 모든 이들과 구별되는 수준으로 올라설 것이다.

  • 수많은 도구들에 대한 피상적인 지식만 있다면, 미묘한 버그가 발생하거나 깊은 지식이 필요한 일을 할 때 늘 어쩔 줄 몰라 허둥대야 한다는 것을 알게 되었다.
    • 도구나 기술 분야, 각종 기법 같은 것을 깊이 파고드는 법을 배워라. 왜 그런 식으로 되어 있는지 알게 될 때까지 지식의 깊이를 더해 가라. 여기서 깊이라함은 세부적인 설계보다는 그런 설계에 이르게 한 요인을 이해하는 것을 의미한다.
    • 디버깅하고, 역컴파일하고, 리버스 엔지니어링하는 사람들이며, 당신이 사용하는 기술 분야에 대한 명세서, RFC(Request for Comments), 표준 문서 같은 것을 읽는 사람들이다.
    • 당신이 친숙해져야 하는 도구들로는 실행 중인 프로그램의 속을 들여다 볼 수 있게 해주는 (GDP, PDB, RDB 같은) 디버거들과 네트워크 트래픽을 볼 수 있는 (Wireshark 같은) 통신 레벨 디버거들, 그에 더해서 명세서를 기꺼이 읽고자 하는 태도가 있다. 코드뿐 아니라 명세서를 읽을 수 있게 된다는 것은, 이제 당신에게 모든 것이 드러나게 되었음을 의미한다.
    • 근원적인 곳으로부터 정보를 얻는 것이다.
      • 예를 들어 REST에 대해 얘기하면, 원 개념이 정의된 로이 필딩의 박사 학위 논문을 읽을 생각을 해야 한다는 것이다.
      • 유용한 개념들의 근원을 따라가는 일은 중요한 연습이며, 앞으로 새로운 것을 학습할 때 많은 도움을 주는 습관이 될 것이다.
    • 튜토리얼을 읽을 때는, 복사해서 갖다 쓸 코드를 찾지 말고 새로 습득한 지식을 마음 속 어디에 두면 좋을지 찾도록 하라. 당신의 목표는 그 개념의 역사적인 맥락이 어떤 것인지, 그것이 다른 무언가의 특별한 경우에 해당하는지 이해하는 것이 되어야 한다. 당신이 학습 중인 주제의 이면에 혹시 어떤 전산학적 개념이 깔려 있을지, 그리그 그 개념과 당신이 사용 중인 구현본 사이에는 어떤 절충이 이루어졌는지 알아보라.
    • 표면적인 지식만 가졌을 때 초래될 수 있는 또 다른 결과는 풀려고 하는 문제에 대해 잘 알려진 해법이 있는지 혹은 실질적으로 해결이 불가능한 문제인지 젼혀 모를 수가 있다는 것이다.
    • 단지 알고리즘이나 자료구조를 바꿨을 뿐인데, 몇 달씩 걸리던 배치(batch) 작업이 마우스 버튼을 다 누르기도 전에 끝날 수도 있다. List, Set, HashMap만 알던 사람이라면, 당명한 문제를 해결하기 위해서 트라이(trie) 자료구조가 필요하다는 사실은 깨닫지 못한다. 그러는 대신에 ‘최장 일치 접두어 검색(longest-prefix matching)’ 같은 문제는 원래 너무나 어려운 거라고 단정짓고서, 그냥 포기해 버리거나 그 기능의 우선순위를 낮출 수 있는지 알아보려 할 것이다.