책 '프로그래머의 길, 멘토에게 묻다' 정리

‘프로그래머의 길, 멘토에게 묻다’ 라는 책을 몇달전에 읽었다. 책의 내용이 좋아 그냥 머릿속에서 휘발시켜버리기에는 아까워 블로그에 (내가 생각하는) 핵심 내용을 간단히 요약 정리해보고자 한다. 앞으로는 읽었던 책 중에서 블로그에 올릴만한 좋은 책들은 비슷하게 정리해서 올려볼까 한다.

이 책의 원제는 ‘Apprenticeship Patterns : Guidance for the Aspiring Software Craftsman (견습생 패턴: 소프트웨어 장인을 꿈꾸는 이들을 위한 지침)’ 이다. 원제를 보면 알 수 있듯이, 이 책은 소프트웨어 장인정신에 대해 이야기하는 책이다. 프로그래머로서의 커리어를 걷는 이들이 마주하게 되는 상황, 문제, 해결방법을 마치 소프트웨어 패턴과 같이 정리해둔 책이다.

개인적으로 좋다고 생각하는 파트에는 제목에 * 을 붙여두었다.

1. 들어가는 글

소프트웨어 장인정신이란 무엇인가?

‘당신은 더 나아질 수 있으며 당신이 제대로 할 준비가 되어 있다면 모든 것은 개선될 수 있다’는 믿음
“당신을 영리하고 재능있게 만드는 것은 노력이며, 실패란 단지 다음번에 다른 방법을 시도해 볼 수 있도록 하는 보상이다.”
이러한 생각은 우리가 정해진 만큼의 재능을 가지고 태어났고, 실패란 재능이 부족하다는 표시라는 통념과는 정 반대이다.
피드백을 바탕으로 항상 적응하고 변화해 갈 필요성. “자신의 행위에서 적합하지 못한 면을 깨닫고 그 해결책을 찾으려는” 자발성
독단적이기보다는 실용적이려는 욕구. 일을 잘 하기 위해서 이론적인 순수함이나 앞날의 완벽함을 준비하는 것을 양보하는 태도
지식을 쌓아두기만 하여 희소하게 만들기 보다는, 서로 나누는 편이 더 낫다는 신념
자신이 틀렸다고 증명될지라도 기꺼이 실험하는 자세. 우리는 흔히 실패하지만, 얻은 교훈을 다음 실험에 활용할 수 있다.
‘내적 통제위치’에 대한 헌신. 스스로 운명을 지배하고 책임지고자 하는 태도를 갖는 것
프로세스 중심적이기 보다, 역량 중심적

견습생이 된다는 것

내가 지금 하고 있는 일을 항상 좀 더 좋고 세련되고 빠르게 해결하는 방법이 있을거라고 생각하는 태도
발전해 가면서 더 나은 방법을 찾아 가는, 그리고 더 좋고 세련되고 빠른 방법을 배우도록 만드는 사람, 회사 혹은 상황을 찾는 상태이자 과정
해답을 건네줄 누군가에게 의존하지 않으며 문제를 해결하는 건설적인 방법을 찾도록 하는 내적 추진력을 갖는다는 것은 커다란 가치가 있다.

2. 잔을 비우다

첫 번째 언어

언어를 배우는 과정을 향상시킬 수 있는 방법 하나는, 실제 문제에 그 언어를 적용하는 것. 책같은 데 수록된, 규모가 작고 미리 잘 고안해둔 그런 예제만 가지고 공부하는 것은 어차피 한계가 있다.
학습을 할 때에는 길이가 짧은 피드백 루프를 만들어, 자신의 진척 상황을 측정하는 것이 좋다. 피드백 루프를 만들기 좋은 방법은 TDD.
언어를 혼자서 배울 수 있겠지만, 전문가들과 교류하지 않으면 그 언어의 진수를 깨우치는 데 오랜시간이 걸릴 수 있다. 특히, 공동체 내에 축적된 경험, 코드의 관용적 표현 방식등은 어떤때는 구전되는 것 밖에 없어 커뮤니티에 소속될 필요가 있다. 단, 최근에는 Effective ~ 와 같은 책들이 이런 미묘한 부분을 다뤄주기도 하므로, 가급적 빨리 이런 책들을 읽는다면 학습 속도도 빨라지고, 흔한 실수를 피하는데에도 도움이 될 것이다.

💬 이펙티브 코틀린을 사두고 몇달동안 읽지를 않았는데, 근 시일내로 읽어보는게 좋겠다.

흰 띠를 매라

새로운 지식을 받아들이려면 우리는 과거의 경험과 선입견을 한 켠으로 밀어 둘 수 있어야 한다.
새로운 지식이 충분히 흡수될 때 까지는 새 지식과 옛 지식이 섞이는 것을 피하고, 새로운 지식에 초보자의 마음가짐으로 접근해야한다. 관용적인 표현에 열려있으면, ‘어떤 언어를 가지고도 포트란처럼 코딩하기’와 같은 문제를 해결할 수 있고, 새로운 지식에 대한 깊은 이해를 얻게 된다.
새로운 지식과 오래된 지식을 잘 융화시키면, 양쪽으로부터 생산적인 통찰력을 이끌어낼 수 있다.

열정을 드러내라 *

연구자들은 경험 수준이 다양한 사람들로 구성된 팀이 실제로 더 건강하다는 사실을 발견했다.
“전반적인 이해력은 서로 다른 여러 수준의 경험이 상호 연관될 때 더욱 높아질 수 있다. 그 무엇도 당연하게 여기지 않는 신참들과, 알 것은 다 안다고 생각하는 고참들이 더 자주 밀접하게 소통할 때가 거기에 해당된다.”
열정을 드러내는 것이야말로 견습생이 맞아야하는 책무이며, 팀에 열정을 불어넣고 모든것에 대해 질문하는 것이 본분이다. 팀에는 이런 신선한 관점을 지닌 독특한 위치에 있는 사람이 필요하다.

구체적인 기술

구체적인 기술을 습득해서 유지하라.
당신이 우러러보는 역량을 가진 사람들의 이력서를 모아보고, 다섯가지 대표적인 역량을 뽑아보라.
해당 역량이 당신이 들어가고 싶어하는 팀과 유사한 환경에서 쓸모가 있을지 판단해보고, 토이 프로젝트에 대한 계획을 세우고 실행하라.

무지를 드러내라 *

팀에게 자신이 성장하는 모습을 보여주어라.
사람들에게 그들이 무엇을 원하는지 이제 당신이 이해하기 시작했고, 그것을 해낼 방법을 배워 가고 있는 중이라고 알려라.
사람들을 안심시키기 위해 아는 척 하기 보다, 당신이 얼마나 잘 배울 수 있는지를 보여주어라. 당신의 평판은 어떤 지식을 알고 있느냐가 아니라, 학습하는 능력이 얼마나 좋은가를 기반으로 쌓여갈 것이다.
무지를 드러내는 가장 확실한 방법은 질문하는 것이다. 이는 자존심에 상처를 받는 어려운일일 수 있다. 자존심에 상처를 입지 않는 방법으로 우회하는 것 보다, 질문하는 방법이 가장 가깝게 질러가는 길이다.
질문하는 과정을 통해 팀에서 자신의 학습 능력을 보여주어라. 그리고 가끔은 사람들이 질문에 대답하는 과정에서 자기가 가진 지식을 새로이 명확하게 할 수 있다.
“당신의 본능은 당신에게 무지를 숨기고 아는 척하라고 시키지만, 그렇게 하면 당신의 성장을 방해 받으며 성취해야 할 일도 가로막히게 될 뿐입니다”
이러한 학습 과정에 익숙해져라. 이것이 장인 정신이다.
장인에게 가장 중요한 특성 중 하나는 학습하는 능력, 즉 무지의 영역을 파악해서 이 영역을 줄이려 애쓰는 것이다.

💬 나는 무지를 드러내는 것에 아직도 익숙치 않다. 하지만, 최근에는 의식적으로 연습하고 있다. 모르는 것이 있다면 (설령 쉬워 보이는 것이라도), 주변에게 도움을 청하고 지식을 얻는 방식에 익숙해져가고 있다.

무지에 맞서라

도구나 기법을 하나 고른 다음에 그것과 관련된 지식의 빈틈을 능동적으로 메워라.
단, 이 패턴은 ‘무지를 드러내라’ 패턴과 함께 적용해야한다. 모든 이들이 몰래 공부하게 되면, 실패와 학습이 용납되지 않은 문화라는 폐단을 가져올 수 있다. 공개적인 학습은 견습생이 숙련공 단계로 발전해 가는 길 중 하나임을 기억해야한다.

💬 내 전문성을 기르기 위해 기술에 대해 끊임없이 공부하자.

깊은 쪽 *

당신에게 두드러지는 역할이나 어려운 문제가 주어진다면, 그 기회를 놓치지 말고 두 손으로 꽉 잡아라.
오히려 실패가 눈앞에 번히 보인다 할지라도 승진이나 해외 발령 같은 제안이 들어왔을 때 그것을 받아들이라는 말이다. 실패를 준비하고 그 실패로부터 일어설 때, 소심한 자들은 결코 볼 수 없는 문이 당신에게 열릴 것이다.
이 패턴을 적용할 때는 무모하다기보다는 용감한 느낌이 들도록 해야 한다.

💬 용기를 갖자. 성장하기 위해 지금까지 해온 것 보다 더 어려운 문제를 풀어내자.

한발 물러서라

너무나 광대한 자신의 무지에 직면하면서 압도당했다면, 평정을 되찾기 위해 자신이 지닌 익숙한 능력 속으로 잠시 후퇴하라.
견습과정은 롤러코스터를 타는 것과 같다. 새로운 기술을 배우거나, 고객에게 가치를 제공할 때 짜릿함을 느낄 수도 있지만, 그 과정에서 만나는 장인이나 전문가들에 비해 자신이 얼마나 보잘것없는 지식을 가졌는지를 깨닫는, 숨막히는 두려움의 시간도 경험할 것이다. 이것은 긴 여정에 따르는 정상적이고도 회피할 수 없는 현상이다.
이 패턴은 자신의 능력을 벗어난 데까지 뻗어 보려고 한 사람들과 관련이 깊다. 얼마나 오래, 멀리 후퇴해 있을지 의식적으로 한계를 지어두지 않으면, 두려움과 실패에 굴복하게 된다. 이 패턴은 다시 튀어 오르는 힘을 모으는 동안 필요할 뿐인 단기적인 처방책임을 알아야한다.

3. 긴 여정을 걷다

긴 여정

이 여행(소프트웨어 장인이 되기 위한 과정)이 얼마나 길어질지에 대해서는 준비가 되어 있어야한다. 자신만의 지도를 그릴 때는 중년의 나이가 되어서도 여전히 현역 소프트웨어 개발자일 것이라는 점을 마음에 새기고 있어야 한다.
앞으로 10년, 20년, 30년, 40년 뒤를 생각해보며, 그 때 당신이 어떤 종류와 경험을 쌓아왔으면 좋겠는지 상상해보라.

💬 나는 40대가 되어서도 현역 프로그래머로 살고 싶다. 그때 쯤이면 나도 누군가에겐 존경받는 실력과 영향력 있는 프로그래머가 되어 있겠지? 하지만, 10년 ~ 40년 뒤의 이야기는 아직 잘 상상이 안된다.

예술보다 기예 *

한 사람의 장인으로서, 예술적 표현에 탐닉하기보다는 다른 이들의 필요를 충족시키는 무언가를 만드는 것이 먼저다.
만약 당신이 만든것이 너무 아름다워서 실제로 쓰기는 어렵다는 이유로 끼니를 굶는다면, 당신은 장인의 길에서 벗어난 것이다. 사람들에게 유용한 무언가를 만드는것이 프로페셔널한 소프트웨어 개발이다.
비록 마음에 차지 않더라도, 고객들이 만족할 만한 품질을 지닌 결과물이라면 내놓아야한다.
“스스로 만족하기 위해서가 아니라 현실 사람들이 당면한 현실적인 문제와 씨름할 때 기량은 연마되는 것”
고객의 요구(유용성)와, 당신을 장인이게 하는 내면적 기준(아름다움) 사이에서 균형을 잘 맞추어야 한다.
시스템을 바닥부터 다시 짜려들기 보다는, 리팩터링을 통해 수정해 나가는 능력을 개발해야한다. “우리는 수리를 하면서 그것이 동작하는 원리를 이해하는 경우가 종종 있다.”

💬 나는 가끔 일을 할 때 우선순위를 생각지 않고 아름다운 코드에 집착할 때가 있다. 성급한 추상화로 되려 이해가 어려운 코드를 짤 때도 있다. 우선순위를 잘 판단하고, 균형을 잡자.

지속적인 동기 부여

“돈을 벌기 위한 소프트웨어와, 만들기에 재미나는 소프트웨어 사이에는 서로 겹치는 부분이 그다지 많지 않다. (중략) 당신이 돈을 벌고자 한다면, 너무 지저분해서 누구든 공짜로는 해결하려 들지 않는 그런 문제를 안고 씨름해야 할 때가 많다.”
황금 족쇄: “뭔가 새로운 걸 배우고는 싶지만, 내가 이미 알고있는 것만으로도 벌이가 너무 좋다.”
긴 여정을 자유로이 갈 것인지 황금 족쇄에 묶일 것인지 택해야 하는 힘든 결정의 시기를 맞게 된다.
당신이 긴 여정을 걷고 있다면, 당신 삶의 다양한 측면과도 조화를 이루면서도 소프트웨어 장인정신에 대해 열정을 키워 가는 태도가 반드시 필요하다.

열정을 키워라 *

당신이 좋아하는 일을 하라. 일에서 흥밋거리를 찾고, 그 중 즐길 수 있는 것들을 분별하고, 그 일에 자신을 쏟아 부어라.
퇴근 후에 시간을 할애하여 부숴도 괜찮은 장난감을 만들어보라.
“위대한 해커가 되기 위한 열쇠는 좋아하는 일을 하는 것. 무언가를 잘 하고 싶으면 그 일을 좋아해야한다.”
마음이 맞는 사람을 찾고, 배운 것을 공유하고, 고전을 공부하고, 자신만의 지도를 그려라.
긴 여정을 걷는 사람들은 몇 년 정도 전력 질주한 후에 그냥 소진되어 버리는 사람이 아니라, 수십 년은 지속할 수 있는 걸음걸이로 움직이는 사람들이다.
열정을 키우고자 한다면, 당신이 기꺼이 일할 수 있는 주변 환경에 대해 미리 명확한 경계를 지어라. 팀의 다른 사람이 야근할 때 먼저 퇴근하거나, 험한 말이 오가는 회의에서 빠져 나오거나, 냉소적인 대화를 할 때 건설적인 주제로 대화를 돌리려 하거나, 자신의 최저 기준에 부합하지 않는 코드의 배포를 거부하는 것들을 의미한다. 이는 연봉 인상, 승진, 명성, 인기와는 거리가 멀어질 수 있지만, 자신의 열정을 굳게 지키고자 한다면 경계를 명확히 지어야한다.
“열네 살 때 당신이 프로그래밍에서 느꼈던 경이로움, 그 느낌을 계속 지니도록 노력하기 바랍니다.”

💬 오래 프로그래머로 일하기 위해, 항상 지속 가능성을 염두해두자.

자신만의 지도를 그려라

고용주가 제시하는 경력 관리 방향이 모두 당신에게 맞지 않는다면, 논리적이면서 의욕적으로 경력의 다음 단계를 준비하라.
그 일은 당신의 고용주, 경력 카운슬러, 교수님이 도와줄 수 있는 일이 아니다.
다음 단계에 도달하고, 궁극적으로 당신이 꿈꾸는 목적지에 이르는 진로를 계획하는 일은 당신 책임이다.
더 나은 프로그래머가 되고자 하는 목표에 회사의 기대나 문화 같은 것이 방해가 되도록 두지 말라.

💬 내 스스로의 커리어는 내 자신이 결정하고 책임지자.

직위를 지표로 이용하라

직위에 비해 다신이 과대 평가 받거나, 과소 평가 받는다는 생각이 들 수 있다.
그럴 듯한 직함에 속지 마라.
당신의 직책이 어떤 것인지 기로 상세하게 적어보고, 실제 당신이 하는 일과 당신의 역량 수준을 정확히 반영하라.
이것을 꾸준히 업데이트하고, 때때로 이런 직책에 있는 낯선 사람을 당신이 어떤 눈으로 바라볼지 상상해보라.

전장에 머물러라

숙련됨은 연습을 중단하는 그 시점부터 퇴보하기 시작한다. 프로그램을 짜지 않는 하루하루마다 숙련공으로 가는 길은 점점 더 멀어간다.
만약 기술 관리직 승진 제안을 받았지만 장인의 길에서 벗어나지 않으려면, 다른 형태의 보상 방안(연봉 상승, 기술 리더 역할)을 고용주와 논의하라.
만약 당신의 조직이 경직된 곳이라면, 승진을 받아들여서 이 길에서 멀어지기보다 다른 곳에서 기회를 찾는 편이 더 나을 것이다.

💬 나 또한 관리자로 승진해서 코딩과는 멀어지는 커리어를 밟고 싶지 않다. 회사나 인터넷에서 정말 오랜 기간 동안 현업 프로그래머의 커리어를 유지하는 분들을 종종 볼 수 있는데, 정말 멋지고 존경스럽다고 생각한다.

또 다른 길

만약 당신이 긴 여정 중 자신만의 지도를 그린 결과 이 길은 더이상 당신에게 적절한 선택이 아님을 깨달았다면.
행여 이 길을 영원히 떠난다고 할지라도, 길을 걸어가며 키워나갔던 가치관과 원칙은 늘 당신과 함께할 것이다.
교사나 윈드서핑 강사가 되거나, 아이를 키우기 위해 소프트웨어 개발을 떠난 동료들이 있다. 그리고 이렇게 잠시 떠났던 동료가 다시 돌아올 수도 있다.
하지만 유감스럽게도 대개의 소프트웨어 조직은 이런 경우를 그다지 환영하지 않는듯 하다. 이런 경우 경력상 공백의 정당성을 증명해야 했다.
이런 위험이 있지만 당신의 삶에서 무언가 다른 일을 해 보는 것을 두려워 하지 말았으면 한다.

4. 정확한 자기 평가

빠르게 학습하는 사람들이 마주하는 위험 중 하나는 좁은 연못 속 커다란 물고기가 되어버리는 것이다. 작은 연못이나 큰 물고기에게 잘못은 없지만, 큰 물고기가 광대한 연못 네트워크에 속한 다른 연못의 존재를 아는 것은 중요하다.
재능있고 열심히 일하는 견습생이라면, 그가 이룬 작은 성공에 자족하지 말아야한다. 또한 자기가 제법 능력 있다는 생각 같은 것은 떨쳐버리고, 지금껏 긴 여정에서 얼마 되지 않는 거리를 걸어왔음을 깨달아야한다.
당신의 목표는 자신의 능력을 평가하고 어제의 자신보다 더 나아질 수 있는 방법을 찾는 것이다.

가장 뒤떨어진 이가 돼라 *

당신의 배움이 더이상 진전이 없다면, 주변을 당신보다 뛰어난 개발자들로 채워라. 당신이 가장 뒤떨어진 멤버가 되며, 그 안에서 더 성장할 여지가 있는 팀을 찾아라.
당신의 목표는 가장 못한 사람으로 머무르는 것이 아니라, 밑바닥부터 시작해서 위로 올라가는 것이기 때문이다.
팀의 다른 사람들과 같은 수준이 될 때까지 의식적으로 개선할 방법을 찾으며 더 뛰어난 개발자들을 모방해 가야 한다.
팀에서 배우려는 의식적인 노력이 없다면, 팀 전체를 끌어내리거나, 쫒겨날 위험도 감수해야한다.
이는 가능한 한 빨리 우월한 지위를 얻는 것이 좋다는 시대 문화적 규범과는 배치된다. 하지만 한 사람의 견습생으로서, 당신은 권위를 늘리고 공고히 할 기회보다는 기예를 학습할 기회에 더 가치를 두어야 한다.
제일 뒤처진 멤버로 의도적으로 팀에 합류하는 것에는 이기적인 면이 있다. 바닥을 쓸어라(팀에 기여하기 위해 하찮은 일을 찾아 나서는 것)와 구체적인 기술 패턴으로 이런 면을 보완해야한다. 이런 기여가 없다면, 이 패턴은 유능한 팀이 치명적으로 약화되는 사태를 불러올 수 있다.
유능한 팀이 당신과 함께 일하는 리스크를 감수하는 이유는, 당신이 팀에 기여하는 바가 급속히 증가하기 때문이다.
“내가 가야 하는 길을 이미 지나갔고, 앞에 놓인 구덩이를 피해 갈 방법을 아는 사람들 곁에 있으면서 배우는 기회라면 놓쳐서는 안 된다. 훌륭한 소프트웨어 개발자들과 곁에 있으면서 배우는 기회라면 놓쳐서는 안된다. 훌륭한 소프트웨어 개발자들과 짝을 이뤄 일한다는 것은 헤아릴 수 없는 가치를 지녔다.”

💬 내가 생각하기엔, 감사하게도(?) 나는 회사에서 가장 뒤떨어진 이다. 나는 이런 좋은 환경에서 느리더라도 끊임 없이 노력하여 꾸준한 성장을 이뤄낼 것이고, 존경받는 탁월한 프로그래머가 될 것이다.

멘토를 찾아라

당신보다 앞서 지나간 사람들을 찾아서 그들로부터 배우도록 애써라.
잠재적인 멘토에게 거절당하거나 이상하게 비친다고 해도, 그 리스크는 별 것 아닌 반면에 보상은 아주 크다는 점을 기억해 두라. 그 사람이 당신을 풀타임 견습생으로 받아들이는데는 관심이 없다고 해도, 점심식사라도 같이 하기를 청하는 것은 돈과 시간이 아깝지 않은 일이다.
당신이 마스터의 경지에 이르는 것을 진지하게 생각한다면, 당신을 지도해 줄 멘터를 끈질기게 찾도록 하라.

마음 맞는 사람들

추진력을 계속 유지하려면, 특히 전담 멘토가 없는 경우에는, 비슷한 길을 걷고 있는 사람들과 빈번히 교류할 필요가 있다. 그러므로 뛰어난 개발자가 되고자 하는 사람들을 찾아 나서야 한다.
당신이 사용하는 도구, 언어, 같이 일했던 사람들, 구독하는 블로그, 흥미를 느끼는 아이디어 같은 것들에 기초하여 가입할 만한 커뮤니티들을 조사하고 나열하라. 그 모임에 하나씩 참석해보고 당신에게 가장 흥미로운 그룹을 결정하라.

팔꿈치를 맞대고

주기적으로 만나는 멘토나 마음 맞는 사람이 있을지 몰라도, 소프트웨어를 개발할 때면 당신은 혼자다.
다른 소프트웨어 개발자와 나란히 앉아서 실제로 같이 작업할 방법(사이드 프로젝트, 페어 프로그래밍 등)을 찾아보라. 세상에는 다른 개발자와 공통의 목표를 달성하기 위해서 같이 일할때만 배울 수 있는 것이 있다.

바닥을 쓸어라

단순하고 매력도 없지만 반드시 해야 하는 종류의 일에 자원하라. 이것은 꼭 그럴 필요 없는 일이라도 당신이 훌륭하게 해낸다는 것을 보임으로써 팀의 성공에 일찍 기여하는 좋은 방법이다.
예를 들면 빌드 시스템 유지보수, 제품화 지원, 유지보수 요청 응대, 버그 수정, 코드 리뷰, 기술적 부채의 청산, 프로젝트 위키 셋업, 문서화 업데이트, 다른 사람의 아이디어에 대한 홍보 담당자 역할 등이 있다.
이런 종류의 주변적인 일은 주로 팀에 이롭지만, 견습생인 당신 자신에게도 좋은 점이 있다. 학교 수업에서는 대개 허드렛일에 대한 부분은 건너뛰어 버리므로, 이런 일을 맡아 함으로써 당신 지식 사이에 놓인 빈틈을 메울 수 있다.
불행히도 당신이 받은 (대학) 교육은 생각보다 현장에서 쓸모가 적다. 물론 채용할 때 전산학 학위를 중요하게 치는 조직이 많기는 하지마나, 채용되는 것과 팀에 합류하는 것은 다른 이야기다. 일단 발을 들여놓은 뒤에 당신이 받았던 그 온갖 교육이 하는 역할이란, 출근 첫 날 무엇을 보여줄지 사람들의 기대 수준을 높이는 것 뿐이다.
이 패턴을 적용해서 생길 수 있는 부정적인 결과가 몇가지 있는데, 팀 내의 잡일꾼으로 굳어져서 아무도 하려 들지 않는 잡다한 일을 도맡게 되는 상황이다. 이런 상황에 처해있다면, 열정을 키우도록 노력하고, 열정을 드러내며, 스스로를 지지해서, 당신이 더 높은 수준의 업무를 맡을 자격이 있음을 증명해 보일 어떤 기회라도 잡도록 하라.

5. 끊임없는 학습

능력의 폭을 넓혀라

새로운 정보를 얻고자 자기 능력의 폭을 넓히는 단계는 견습생에게 아주 중요하며, 가끔은 압도됨을 느낄 수 있다.
당신은 새로운 지식을 이해하고 간직하며 적용하는 방법 뿐 아니라, 효과적으로 흡수할 수 있는 테크닉도 발전시켜 가야 한다.
이 패턴은 소프트웨어 개발 서적 한 권 읽는 정도를 의미하지 않으며, 다양한 차원에 걸쳐서 새로운 지식과 경험을 찾아가는 활동을 수반한다.
구글 리더와 같은 블로그 모아보기 사이트, 트위터에서 유명인사 팔로우, 메일링 리스트 가입, 로컬 유저 그룹 참여, 기술적 컨퍼런스 참여, 책을 읽은 뒤 저자에게 연락, 온라인 대학 강좌 및 팟캐스트 시청 등 수 많은 방법이 존재한다.

연습, 연습, 또 연습

지금 하는일에 더 능숙해지고 싶고, 새로운 분야에서 구체적인 기술 개발을 하고자 하지만, 일상적인 프로그래밍 환경에는 실수해 가면서 배울만한 여지가 없다면, 실수해도 마음 편한 환경에서 방해받지 않고 기예를 연마할 시간을 확보하라.
“소프트웨어를 만들면서 우리는 업무 중에 연습을 하는데, 그것이 업무 중에 실수를 하게 되는 원인이다. 우리는 직업적인 일과 연습을 구분할 방법을 모색해야 한다. 우리에게는 연습 시간이 필요하다.”
의도적인 수련 기법을 적용하고, 코드 카타를 사용하라.
“초심자는 강의가 아니라 실제로 해보면서 배운다. 그들은 연습하고 연습하고 또 연습한다. (중략) 이처럼 같은 과제를 거듭 반복함으로써 우리는 자신의 기술을 연마하며, 우리 몸과 마음이 TDD와 단순한 설계의 규율에 감응하도록 훈련한다.”

부숴도 괜찮은 장난감 *

우리는 실패가 용납되지 않는 환경에서 일하고 있지만, 실패는 종종 무언가를 배울 수 있는 가장 좋은 방법이 된다.
업무 때와 비슷한 도구를 써서, 개인적인 공간에 토이 시스템을 설계하고 구현하여 실패해 볼 수 있는 여지를 만들어라.
예를 들면 위키, 캘린더, 주소록을 만드는 것이다.
단, 이것들은 본디 장난감이며, 재미있어야한다는 것을 잊지 말아야 한다.
이런 장난감들은 종종 업계 표준이라 할 도구들을 간단하게 재구현한 경우가 많은데, 그렇게 재구현하면서 당신은 그 도구가 지금의 설계에 이를 수 밖에 없었던 여러 이유를 한결 깊이 이해할 수 있게 된다.
그러던 중 장난감 하나가 생명력을 얻어서 당신 외의 사용자가 생길 수도 있다.

💬 단순히 프로그램을 구현하는 것을 넘어서, 의도적으로 설계나 성능등에 빈틈을 찾고, 실패시킬 수 있는 (버그를 찾거나, 스트레스 테스트를 하는 등) 일종의 샌드박스를 만든다는 의미에서 이 패턴이 좋다고 생각한다. 실무에서는 의도적으로 실패시키면 큰일나니까.

소스를 활용하라

프로그래머가 되고자 준비하는 가장 좋은 방법은 프로그램을 짜는 것이며, 다른 사람들이 작성한 뛰어난 프로그램을 공부하는 것이다.
다른 사람의 코드를 찾아서 읽어라. 그 사람들의 코드를 읽고서 당신은 그들처럼 프로그래밍하는 법을 배우게 되고, 더 중요하게는, 당신을 둘러싼 인프라를 만들어 낸 사고 과정이 어떤 것이었는지 이해하게 된다.
“프로그래밍 능력을 테스트하는 가장 좋은 방법 중 하나는, 프로그래머에게 30페이지 정도의 코드를 건네주고서 그 사람이 얼마나 빨리 그 코드를 통독하고 이해하는지 보는 것이다.”
코드에서 신속히 지식을 흡수할 수 있는 사람은 머지 않아 더 우수한 프로그래머가 된다.

일하면서 성찰하라 *

사색하는 소프트웨어 개발자가 되어라.
당신 팀의 나머지 사람들이 당연하게 여기는 것들에 대해 스스로 질문을 던져 보라. 만약 자신의 현재 업무 중에서 특별히 괴롭거나 기분 좋은 것이 있다면 왜 그런지 자문해 보라. 만약 괴로운 것이 있다면 그것을 개선할 방법에는 무엇이 있겠는가?

💬 재직중인 회사의 코어 밸류 중 하나는 ‘Question Every Assumption (모든 기본 가정에 근원적 물음을 제기한다)’ 이다. ‘기존에 하던 대로’ 관성적으로 일을 하게 되면, 발전이 없어진다. 생각 하면서 일하자.

배운 것을 기록하라 *

과거로부터 배우지 못하는 이들은 같은 일을 되풀이하도록 되어 있다.
당신이 걸어가는 여정의 기록을 일지나 개인 위키, 블로그 등으로 남겨라.
이 패턴을 사용하는 사람들은 조만간 까다로운 문제의 해답을 찾을 때 검색엔진의 검색 결과에 자기 위키나 블로그가 나오는 순간을 경험하게 될 것이다.
당신의 공책, 블로그, 위키 같은 것은 보육원이 되어야지 묘지가 되어버리면 곤란하다. 교훈들이 죽을 자리를 찾아오는 것이 아니라 이 기록으로부터 생겨나도록 해야한다. 그렇게 만들려면 당신이 썼던 글을 정기적으로 다시 읽어라.

💬 실제로 내 블로그는 종종 구글 검색 결과에 등장하는데, 이럴 때면 기분이 좋다.

배운 것을 공유하라 *

배운 것을 정기적으로 공유하는 습관(블로그, 모임, 발표 등)을 견습과정 초기에 들여 놓아라.
누군가를 가르친다는 것은 가르침을 받는 사람보다도 가르치는 사람에게 더 강력한 학습 도구가 된다.

피드백 루프를 만들어라

당신이 자기 능력에 대해 느끼는 감(자신이 유능해 보이거나, 자신감이 무너지거나)은, 같이 일하는 팀이란 존재에 의해 쉽사리 왜곡될 수 있다.
다신의 수행 능력을 평가하는 데 어느 정도 객관성 있는 외부 데이터를 정기적으로 수집할 방안을 마련하라. 일찍, 자주, 효과적으로 피드백을 얻으려 애쓰면, 당신은 적어도 자신의 무능함을 자각할 가능성은 높일 수 있을 것이다.
피드백을 얻는 방법은 TDD, 코드 리뷰, 시험, 자격 증명, 사람들에게 직접 물어보는 방법 등이 있다.
유용한 피드백이란, 그것을 기반으로 삼아 실천할 수 있는 데이터이며, 특정한 행위를 더 하거나 덜 하도록 선택의 여지를 주는 데이터이다.

실패하는 법을 배워라 *

“천재성은 종종 잘못 이해된다. 그것은 탁월한 지적 능력의 문제가 아니라 성격의 문제다. 천재성은 무엇보다도 기꺼이 실패를 인지하고, 미봉책으로 가리려 하지 않으며, 변화하고자 하는 의지를 필요로 한다. 그것은 실패에 대한 의도적이고 심지어는 강박적인 성찰과, 새로운 해법에 대한 지속적인 탐색에서 비롯된다.”
실패는 불가피한 것이다. 그것은 늦든 이르든 간에 모든 이에게 일어난다. 한 번도 실패해 본 적이 없는 사람이라면, 그는 자기 능력의 한계치까지 밀어붙이기를 피해 왔거나 자기 실수를 대수롭지 않게 여기도록 배운 사람이다.
당신이 어떤 식으로 실패하곤 하는지 확인하고 고칠 부분은 바로 잡아라.

6. 학습 과정의 구성

독서 목록 *

읽기로 한 책들을 추적해 갈 독서 목록을 유지하고, 다 읽은 책은 기억해두라.
배운 것을 공유하라 정신에 따라서, 공개된 장소에 당신의 독서 목록을 올려두는 것을 한번 고려해 보라.
책에서 얻는 가장 귀중한 것 중에 하나는 읽을 가치가 있는 다른 책의 목록이다. 시간이 지나면서 특정한 책이 계속해서 참고 문헌에 나타는 것을 발견하면, 그 책을 독서 목록에 가장 위에다 올려 놓아라. (Code Complete 35장과 The Pragmatic Programmer 의 참고 도서 목록에서 훌륭한 책들을 찾을 수 있다)
이렇게 만들어낸 독서 목록은 당신의 것임을 기억하라. 당신의 현재 상황은 당신만이 올바르게 알고 있다. 그러므로 다음에 무엇을 학습할지 결정하는 사람은 바로 당신이어야 한다. 그리고 적절한 책을 적절한 시점에 읽는 것 역시 중요하다. 그렇게 하는 것이 현재의 경험과 지식으로는 제대로 이해하지 못할 책들을 쌓아 놓고 우왕좌앙하는 것보다 훨씬 효과적이다.

💬 적절한 책을 적절한 시점에 읽는 것이 중요하다는 조언은 유용하다. 지금 현재 내가 처해있는 상황에서, 어떤 것을 학습해야 가장 효과가 좋을지 생각하고 학습하는 것이 중요하다.

꾸준히 읽어라

책을 다 읽은 후에도 그 추진력을 유지하라. 이 다음에 무슨 책을 읽을지, 지금 결정하라. 그 책을 사든지 빌리든지 해서 이 책을 끝내자마자 바로 그 책으로 넘어갈 수 있도록 하여라.
두껍지 않은 책을 한 권 늘 지니고 다녀. 이렇게 해서 일상생활중에 잠깐식 비는 시간을 학습에 활용할 수 있다.

고전을 공부하라 *

독학으로 공부했거나 이론보다 기술 훈련을 더 중요시 하는 상당히 실무 중심적인 교육을 받았다면, 고전을 공부하라.
무지를 드러내서 잘 모르는 개념이 어떤 뜻이며, 어떤 책에서 비롯되었는지 물어보고, 그 책을 당신의 독서 목록에 추가하라.
성공적인 견습생들은 ‘수명이 긴 책’ (훌륭한 책)에 집중하는 경향이 있다.

더 깊이 파고들어라 *

당신은 수많은 도구들에 대한 피상적인 지식만 있다면, 미묘한 버그가 발생하거나 깊은 지식이 필요한 일을 할 때 늘 어쩔 줄 몰라 허둥대야 한다는 것을 알게 되었다. 당신의 지식이 너무나 피상적이라서, 어떤 계기나 누군가 때문에 시험에 들기 전까지는 자기가 아는 바가 얼마나 없는지 자각조차 못하는 것이다 (더닝 크루거 효과의 우매함의 봉우리).
어떤 분야에 깊이 있는 지식을 가졌다는 사실은 당신에게 자신감을 준다. 더 중요한 것은 이런 지식의 깊이가 새로운 분야에 도전할 때 기댈 언덕이 되어주며 앞으로 나갈 힘을 부여한다는 것이다.
또한 어떤 기술 분야를 깊이 파고든다면, 당신이 작업하고 있는 시스템의 물밑에서 무슨 일이 일어나고 있는지 설명할 수 있게 된다는 것이다.
관점이 변화하면, 시스템의 여러 층위를 뚫고 문제를 쫒아가서 ‘모든 것이 뜻이 통하는’ 수준의 지식을 얻으려는 태도가 생겨난다. 이를테면 싱글코어에서 멀티코어로 노트북을 바꾼 뒤에 자바로 짠 동시성 테스트의 동작이 달라질 수 있다. 어떤 이들은 그저 어깨 한번 으쓱하고서 이제 그 테스트는 예측할 수 없게 동작한다고 생각하고 말 것이다. 하지만 다른 이들은 동시성 라이브러리, 자바 메모리 모델, 물리적 하드웨어 명세 같은 것을 통해 CPU 수준까지 문제를 쫒아갈 것이다.
우리에게 필요한 것은 실행 중인 프로그램의 속을 들여다 볼 수 있게 해주는 디버거, 네트워크 트래픽을 볼 수 있는 통신 레벨 디버거, 명세서를 기꺼이 읽고자 하는 태도가 있다.
근원적인 곳으로부터 정보를 얻자. 예를 들자면, 누군가 REST에 대한 이야기를 한다면, 이 경험을 REST의 원 개념이 정의된 로이 필딩의 박사 학위 논문을 읽을 이유로 생각해야 한다는 것이다. 이렇게 알게 된 것을 명확히 하거나 공유하기 위해서 블로그에 글로 정리해 보라.
어떤 개념을 정말로 이해하려면 위키 백과, 알기 쉽게 풀어서 써 놓은 책, 그것을 인용한 블로그 등의 말을 그대로 받아들이지 않고, 그 개념이 최초로 언급된 당신의 전후 맥락을 재구성해 볼 필요가 있다. 이렇게 해야 개념의 정수가 그 모든 중간자들을 거치고도 살아남았을을 확인할 수 있다.
그 아이디어를 누가 처음 생각해냈는지 조사하고, 그들이 풀려고 했던 문제가 무엇인지 이해하라. 이와 같은 역사적인 맥락에 관한 내용은 보통 그 개념이 전달되는 과정에서 사라진다.
이와 같이 심도있는 이해에 초점을 맞출 때는, 뜻하지 않게 좁은 한 가지 분야에 대한 전문가의 길로 빠져버리는 일이 없도록 해야한다. 당신의 목표는, 소프트웨어 개발의 여러 측면이 지닌 상대적인 중요도에 대한 관점을 잃지 않으면서, 어떤 문제를 해결하는 데 필요한 지식을 가능한 한 많이 습득하는 것이다.
표면적인 지식만 가졌을 때 초래될 수 있는 또 다른 결과는, 풀려고 하는 문제에 대해 잘 알려진 해법이 있는지 혹은 실질적으로 해결이 불가능한 문제인지 전혀 모를 수 있다는 것이다.
수박 겉핥기식으로만 해서는 지금 모르는 것을 앞으로도 모를 것이며, 자기 지식의 한계가 어디까지인지 이해하지 않고 새로운 것을 깨달을 수는 없다.
어떤 문제에 대해 모든 층위를 통틀어 조사하는 과정에서 밑바닥에 깔려 있던 전산학적 개념들이 드러나는 일이 흔하다. 단지 알고리즘이나 자료구조를 바꿨을 뿐인데, 몇 달씩 걸리던 배치 작업이 마우스 버튼을 다 누르기도 전에 끝날 수도 있다 (다른 사람에게는 마법처럼 보이는 일).
이 패턴을 정기적으로 실천한다면, 당신은 자기 도구가 어떻게 동작하는지 진정으로 이해하는 사람들 중 하나가 될 것이다. 당신은 더 이상 코드 조각을 짜깁기 해놓고서 일이 되게 하려고 다른 사람들이 마법을 부려 주기를 바라지는 않을 것이다.

💬 최근에 왜 깊이 있는 지식을 알고 있어야 하는지 이해했다. 깊이 있는 지식을 많이 알고 있는 사람일수록, 문제가 발생할때의 문제 해결 능력과 잠재적인 문제를 예방하는 예측 능력이 뛰어나다. 나는 이를 ‘문제 해결의 해상도가 높다’ 라고 표현한다. 문제 해결의 해상도가 높은 사람은, 문제 상황에서 자신이 택할 수 있는 선택지가 그렇지 않은 사람들보다 높다. 현대의 소프트웨어는 규모가 매우 크고, 복잡하고, 무겁다. 이런 소프트웨어를 잘 다루기 위해서는 깊이 있는 지식과 이해를 겸비해야겠다.

익숙한 도구들

익숙한 도구들을 선별해서 거기에 집중하라. 시간이 흐르면서 당신은 도구들이 편안하게 느껴질 것이다.
이것은 생산성이 높아진다는 점에서 유익한 일이지만, 위험도 또한 존재한다. 조심하지 않는다면 당신은 이런 익숙한 도구들을 어떤 문제라도 해결할 수 있는 도깨비 방망이로 여기기 시작할지도 모른다.
장담하건대, 당신이 견습생 때 쓰던 도구들은 숙련공이 되고 나서는 더이상 소용이 없다. 때가 되면 당신이 즐겨 쓰는 도구들은 모두 폐물이 될 것이다.
당신의 경력이 성공적이려면, 익숙한 도구들을 쉽게 얻고 쉽게 버리는 법을 배워야한다.