함께 자라기 - 교보문고
애자일로 가는 길 | 다음 문장들을 보고 거짓이라고 생각하는 게 있으면 골라보세요.1. 일반적으로 경력이 많으면 전문성도 높다.2. 수십 년간 같은 수련을 날마다 반복하면 실력이 는다.3. 실수
www.kyobobook.co.kr
🔖 실제 바깥 세상에서는 한 번의 판가름으로 나의 미래가, 우리의 미래가 갈리는 경우보다는 수백, 수천 번의 누적위에 서서히 정해지는 경우가 더 많습니다.
🔖 많은 조직이 사람을 뽑는 것에는 신경을 쓰지 않지만 이 사람들을 차후에 어떻게 교육, 훈련시키고 성장시킬지는 깊이 고민하지 않습니다. 며칠을 고민해서 이것저것 비교하다가 운동 기구를 사놓고는 이후 실제 운동은 잘 안 하는 경우라고 할까요.
🔖 무서운 사실은 이게 축적이 되면 엄청난 차이를 만들 거라는 점이지요. 자기가 습득한 지식이나 능력은 복리로 이자가 붙기 때문입니다. 예를 들어, 하루에 1%씩 이자를 복히로 받는다고 하면 원금의 두 배가 될 때까지 며칠 걸릴까요? 70일이면 굅니다. 1년이면 어떻게 될까요? 약 38배가 됩니다. 여기에서 중요한 부분은 곱하기를 해여 한다는 것. 그리고 꾸준하게 곱해 나가야 한다는 점입니다.
🔖 완벽한 도구와 환경을 갖추는 데에 집착해선 안된다. 그런 식으로는 무엇도 영원히 얻을 수 없다. “방이 조용해지고 배도 안 고프고 온도도 적절해지기만 하면 공부 시작해야지.”라고 생각하는 사람들 중에 1등은 없다. 또한 실제로 그런 환경이 되어도 몸에 배어든 습관 때문에 결국은 공부하지 못할 것이다.
🔖 골프 퍼팅 연습을 하는데, 공이 어디로 가는지 전혀 보지 않고 1,000개의 공을 친다고 생각해 보죠. 이건 도대체 뭘 연습하고 있는 걸까요? 뭔가 연습이 되긴 하겠죠. 하지만 정확하게 퍼팅하는 부분은 연습이 되질 않을 겁니다. 내가 잘 했나 못 했나 알지 못하면 행동을 조정할 수가 없죠. 그래서 학습에서는 피드백이 중요합니다.
🔖 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다. 자신이 올해 몇 권을 읽었다고 자랑하지 말고, 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라.
🔖 - 예컨대 나의 A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라.
- 사이클 타임을 줄여라. 새로운 정보를 얻었다면 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 혹은 1주 후에 작게라도 실험해 보는 것이 좋다. 순환율을 높여라.
🔖 꾸준한 반복으로 달인이 되려면 적어도 실력을 개선하려는 동기가 있어야 하고 구체적인 피드백을 적절한 시기에 받아야 한다.
🔖 언어학자인 크라센(Stephen Krashen)이 입력가설(Input Hypothesis)을 통해 말합니다. i+1 이론이라고 하는데, 현재 학습자의 언어 수준을 i라고 할 때 딱 한 단계 높은 i+1 수준의 입력이 주어질 때에만 언어 능력이 유의미하게 진전하다는 이론이죠.
🔖 새로운 언어를 배우는 비결
1 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다. 튜토리얼을 읽다가도 이 정도면 코드를 작성할 수 있을 것 같다는 생각이 들면 읽기를 멈추고 코딩을 시작한다. 프로그램이 완성되면 다시 자리에 앉아 읽기를 계속한다. 이런 것을 적극적인 읽기라고 한다. 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법을 말한다.
2 공부할 때 표준 라이브러리 소스코드를 읽는다. 튜토리얼을 읽어 나가면서 틈틈이 해당 언어의 표준 라이브러리를 찾아 읽는다.
🔖 아무리 기술적인 실천법이라고 해도 그 기술은 사회적 맥락 속에서 실천되어야 하며 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.
🔖 뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 초보 개발자들에게 조언을 할 때 사회적인 측면(예컨대 “모르면 주변에 물어봐라.”, “남을 도와줘라.” 등)이 포함됩니다. 기술적인 조언만 하는 게 아니라는 뜻입니다.
🔖 예전에는 소프트웨어 개발 전문성과 사회성은 별개로 치부되어 “프로그래밍 실력은 좋은데 의사소통 능력은 부족하다.”든다 하는 이야기를 했다면, 이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 겁니다.
🔖 기술적 요소보다 사회적 요소가 병목이 될 확률이 더 높다는 것이지요. 이 사실을 깨달은 이후로는 어떤 기술적 지식을 전달한다고 해도 그것을 사회적 맥락 속에서 가르치고 경험하게 하려고 노력하고 있습니다. 참고로, 제가 중요하게 다루는 사회적 기술은 도움받기, 피드백 주고받기, 영향력 미치기, 가르치고 배우기, 위임하기 등이 있습니다.
🔖 사람들은 협력이 중요하다고 합니다. 그래서 프로젝트를 할 때 협력적으로 하자고 합니다. 그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋습니다. 그리고 안녕이죠. 각자 진행하고 나중에 만나서 서로 합쳐봅니다. 그 속을 들여다보면 협력은 거의 없습니다.
🔖 복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에서 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정 간의 유사성을 인식하는 데에서, 그리고 이러한 유사성에 집중하고, 차이점은 일시적으로 무시하는 결정에서 추상화가 생겨난다. / 토니 호어
🔖 그러면 우리가 품질을 이야기 할 때에는 ‘누구’를 놓고 하는 말이냐는 걸 생각해 봐야 한다 이겁니다. 이 누구를 빼놓게 되면 고생은 고생대로 해놓고 품질이 형편없다는 소리를 들을 수 있습니다. 왜냐? 당사자가 별로 중요하게, 가치 있게 여기지도 않는 거에만 신경을 썼을 수도 있거든요.
🔖 논문에서는 팀 학습 속도에 대해 리더가 끼치는 영향을 주목합니다. 단순히 기술적 탁월함을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것입니다. 학습이 빠른 팀은 팀원을 뽑을 때부터 달랐습니다. 선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라, 선발 기준도 달랐습니다. 단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았습니다.
🔖 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 학습을 팀의 중대한 목표로 받아들였습니다. 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.
🔖 진정학 학습은 실행 속에서 이뤄지고, 진정한 실행은 학습을 수반합니다. 우선 언제 시작할지 계획부터 짠다고요? 지금 당장 하지 않는다면 장차 할 확률은 절반 이하로 떨어집니다. 새로운 일의 방식을 실험해 봅시다. 일단 30분만 업무 개선을 시도해 보는 겁니다.
🔖 애자일은 좋은 일에 대해서는 ‘그리고’ 확률을 ‘또는’ 확률로 바꾸고, 나쁜 일에 대해서는 ‘또는’ 확률을 ‘그리고’ 확률로 바꾸는 경향이 있습니다. 좋은 일은 공유를 해서 한 사람만이라도 중요한 통찰이 있었다면 이걸 공유해서 ‘또는’ 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서(짝 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 ‘그리고’ 확률로 바꾸는 것입니다.
🔖 학습과 협력은 불확실성이 큰 상황에서 좋은 대응전략이 됩니다. 우리의 삶도 불확실하기 때문에 학습과 협력은 현명한 전략이 될 것이고요. 그런데 마침 애자일의 핵심 구동원리가 학습과 협력, 즉 함께(협력) 자라기(학습)입니다. 그래서 저는 불확실한 삶을 살아나갈 때 애자일적 태도가 도움이 될 것이라고 생각합니다.
🔖 두려워도 중요하다면 시도해 봐야 하지 않겠는가. 이 질문은 그 자체로 참 무섭습니다. 두려운 걸 용기를 갖고 직면해여 한다는 것이니까요.
개발바닥 영상에서도 한 번 들었던 책 같은데 스터디에서 책 추천 리스트 링크를 공유해 주셔서 봤더니 어김없이 <함께 자라기>가 있어서 추석 동안 읽기 시작했다. 개발자가 아니더라도 커리어적으로나 일상적으로 어떤 생각과 태도를 가져야 성장할 수 있는지를 배울 수 있는 책인 것 같다. 여기에는 적지 않았지만 일과 본인의 실력 차이가 어느 수준이고 본인이 느끼는 감정이 지루함인지 아닌지에 따라서 어떻게 행동하는 게 좋을지에 대해서도 나와있는데 모든 개발자가 한 번쯤은 읽어보면 굉장히 좋을 것 같다. 이게 다 알고 있는 얘기 같지만 막상 일을 하다 보면 이 상황에서 내가 어떻게 해야 극복할 수 있을지에 대해 생각을 못하게 된다. 책을 보면서 지난 1년을 더 의미있게 보낼 수 있었는데 그냥 흘려보낸 것 같아서 아쉬웠다.
이직을 준비하면서 어느 채용 공고를 되게 인상깊게 봤는데 공고 내용 중에 회사 운영 혹은 개발 문화의 모티브가 되는 책들이 나열되어 있었다. 거기에도 바로 이 책이 있었다. 물론 책만 읽는다고 이 책에 나온 모든 좋은 예들이 적용되는 회사는 아니겠지만, 최소한 지향점을 이 책으로 삼았다는 점에서 저 회사에 가면 같이 성장하는 기분을 느낄 수 있겠구나 라는 생각이 들었다. 이런 개발 문화를 가진 회사에 가기 위해서 그리고 그 문화 속에서 같이 성장하는 개발자가 되기 위해서는 나부터 많이 성장해야겠지? 욕심이 많아서 정말 큰일이다.
특정 분야의 전문가가 되기 위해서는 1만 시간이 필요하다는 1만 시간의 법칙이 있다. 나는 그 동안 그 시간을 어느 정도 채웠을까 생각해 보면 후회되는 점이 많다. 하루 치는 채웠으려나? 욕심은 많은데 아는 게 없다 보니 어떤 걸 먼저 공부해야 하는지 잘 몰랐고, 어떻게 공부해야 하는지도 잘 몰랐다. 나는 분명히 퇴근하고 항상 공부를 했는데 왜 남은 게 없을까 생각해 보니 책에서 얘기한 것처럼 새로운 걸 유입하는 데에만 집중했지, 그 정보를 어떻게 내 것으로 만들지에 대해서는 생각을 못 했던 것 같다. 지금도 여전히 그 방법을 배우고 있고, 하루 하루 내 것으로 만들기 위해 노력 중이다. 자기계발은 복리라는데 매일 매일 나를 수련하면 언젠가는 1만 시간을 채울 수 있겠지. 나중의 N년차 개발자가 된 내가 이 글을 봤을 때 지난 날들을 후회하지 않게 열심히 살아야겠다.
'노트 > Review' 카테고리의 다른 글
[서적] 실습과 그림으로 배우는 리눅스 구조 | 다케우치 사토루 (1) | 2023.01.18 |
---|---|
[서적] 애자일 회고 | 에스더 더비‧다이애나 라센 (0) | 2023.01.08 |
[서적] 도메인 주도 개발 시작하기 | 최범균 (1) | 2023.01.07 |
[강의] Egoing Lee | 생활코딩 - Linux (0) | 2022.12.31 |
[서적] 혼자 공부하는 컴퓨터 구조+운영체제 | 강민철 (0) | 2022.12.31 |