- 저자
- 김창준
- 출판
- 인사이트
- 출판일
- 2018.11.30
이번에 잘하냐 못 하냐 하는 것은 그렇게 중요하지 않습니다. 앞으로 기회가 수백, 수천 번 더 있다면 말입니다. 그런 경우 더 중요한 것은 지금 잘하냐가 아니라 지금 자라냐는 것입니다. 실제 바깥세상에서는 한 번의 판가름으로 나의 미래가, 우리의 미래가 갈리는 경우보다는 수백, 수천 번의 누적 위에서 서서히 정해지는 경우가 더 많습니다.
- 6p
야생 학습의 특징은 다음과 같습니다.
- 야생 학습은 대부분 협력적이다.
- 야생 학습은 대부분 비순차적이다.
- 야생 학습은 대부분 자료에 한정이 없다.
- 야생 학습은 대부분 명확한 평가가 없다.
- 야생 학습은 대부분 정답이 없다.
- 야생 학습은 대부분 목표가 불분명하고 바뀌기도 한다.
- 12p
요즘 세상은 많은 것이 불확실해진 것 같습니다. 기술이 발전할수록 우리의 관심은 더욱 불확실한 쪽으로 옮겨가게 되었죠.
- 13p
수파리, 도인 메타포
- 13p
저는 이 글을 통해,
1. 경력 연차라는 것으로부터 이 사람이 초급인지 아닌지 정도의 정보만 기대할 수 있으며
2. 초급이 아닌 사람들에 대해서는 경력 연차가 오히려 혼동을 불러일으키는 잘못된 정보로 작용할 수 있고
3. 고로 경력 연차로 채용 여부나 임금 수준을 결정하는 것은 판단 편의적이고 관료주의적이며 결과적으로 조직에 손해를 줄 수 있는 방식
이라고 이야기하려고 합니다.
- 17p
작업 샘플 테스트가 0.54, 아이큐 같은 지능 테스트가 0.51, 구조화된 인터뷰가 0.51이었습니다. 성실성이나 꼼꼼함 같은 성격 테스트도 0.41이나 0.31 정도의 상관성이 있었습니다.
- 19p
구조화된 인터뷰(특별히 구조화된 행동중심적 인터뷰를 권함)와, 실제 작업을 해보도록 하는 작업 샘플 테스트, 그리고 가능하다면 실제 업무를 주고 시험적으로 짧은 기간 동안 일을 해보게 하는 것 등을 권합니다.
- 23p
피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것.
-28p
자기 계발은 복리로 돌아온다.
- 31p
자기가 습득한 지식이나 능력은 복리로 이자가 붙기 때문입니다.
- 33p
자신이 이미 갖고 있는 것들을 잘 활용해라
- 이미 갖고 있는 것들을 하이퍼링크로 서로 촘촘히 연결하라.
- 39p
일찍, 그리고 자주 실패하라. 실패에서 학습하라.
- 40p
자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.
- 40p
컴퓨터 프로그래머는 다른 사람이 준 스펙대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 크게 필요하지 않습니다. 반면에 소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많습니다. 앞서 이야기한 독창성, 협상, 설득 등에서 차이가 나는 것이죠.
- 51p
미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가질 것입니다.
- 52p
꾸준한 반복으로 달인이 되려면 적어도
1. 실력을 개선하려는 동기가 있어야 하고
2. 구체적인 피드백을 적절한 시기에 받아야 한다고
말할 수 있겠습니다.
- 55p
여기에서 주목해야 할 부분은 C 영역입니다. 난이도와 실력이 엇비슷하게 맞는 부분이죠. 미하이는 이 부분에서 인간이 몰입을 경험한다고 합니다. 그리고 바로 이때 최고 수준의 집중력을 보이고, 그 덕분에 퍼포먼스나 학습 능력이 최대치가 될 수 있다고 합니다. 또한 그때 최고 수준의 행복감을 경험한다는 흥미로운 사실을 발견하기도 했습니다.
- 63p
자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 겁니다.
- 64p
동적인 균형 -> 지속적으로 자신의 감정 상태를 살피면서 지금 지루한지 불안한지를 알아채고 만약 지루함이나 불안함을 느낀다면 앞의 네가지 전략을 적절히 사용해야 한다는 겁니다. 이렇게 감정 상태를 살피고 조취를 취하는 사이클을 계속 돌아야 합니다.
- 73p
튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다
공부할 때 표준 라이브러리 소스코드를 읽는다
공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다
- 83 ~ 85p
교육 쪽에서는 실수 훈련이라는 개념이 있습니다. 보통 교육에서는 학생들이 실수를 최소화할 수 있도록 설계합니다. 교육 중에 실수를 적게 해야 실전에서 실수가 적을 거 아니겠냐는 논리죠. 하지만 연구결과는 반대입니다. 교육 중에 실수를 더 유도해야 오히려 학습 전이가 더 잘 일어납니다. 다양한 실수를 경험하는 걸 격려하고, 실수 사례를 배우고, 실수 시에 어떻게 대처하는가를 가르치는 교육이 더 효과적이라는 연구 결과가 많습니다.
- 92p
전문가가 간단한 수술을 가르칠 때에도 자신이 이 수술에 대해 알고, 실천하는 것의 30% 정도밖에 가르치지 못합니다.
- 96p
나홀로 전문가에 대한 미신
- 98p
한 분이 자신이 속한 조직의 형상 관리 도구를 서브버전에서 깃으로 성공적으로 안착시킨 사례를 이야기하고 있었습니다. 잘 아시겠지만 조직의 형상 관리 시스템을 바꾼다는 것은 그리 쉬운 일이 아닙니다. 그 후배는 대리 직급에서 그 일을 했는데, 상대적으로 낮은 직급에서 이런 조직적 전환을 만들었다니 더 놀라운 일이었죠. 사례 공유가 끝나자 청중 한 분이 손을 들고 묻더군요. "이해가 되지 않습니다. 저 역시 그렇게 하려고 깃의 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는 데에 실패했습니다. 사람들이 너무 수동적이고 보수적이에요." 발표자가 뭐라고 답을 했던 것 같은데, 옆에서 지켜보던 제가 호기심이 생겨서 질문하셨던 분과 발표자에게 각기 동일한 질문을 드렸습니다. "그 조직원들이 선생님을 좋아하나요?" 질문자와 발표자가 상반된 답을 했으리라는 건 여러분도 짐작할 수 있지 않을까 하네요.
- 105p
앞의 <나홀로 전문가에 대한 미신>에서 언급한 "초보에거 어떤 조언을 하시겠습니까?"를 물었을 때 "뛰어난 프로그래머가 사회적인 면을 더 언급했다. 고로 협력을 더 중요하게 여긴다"는 것 외에도 다양한 연구 결과가 있습니다. 일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어납니다. 우리가 생각하는 전형적 영웅 프로그래머와는 이미지가 정반대입니다. 게다가 실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 오랜 시간을 들입니다. 반면 설계나 코딩, 테스팅에 들이는 시간에는 통계적으로 큰 차이가 없었습니다.
- 120p
둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 됩니다. 서로 다른 것들을 하나로 묶어야 하기 때문입니다. 반면 혼자서 작업할 경우에는 이런 추상화의 필요가 덜합니다.
- 124p
창발적 추상화
-125p
전산학의 모든 문제는 또 다른 차원의 간접성으로 해결할 수 있다. - 버틀러 램슨
전산학은 추상화의 과학이다. - 알프레드 아호와 제프리 울먼
... 소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특정지을 수 있다. - 그레디 부치
복잡한 현상에 대한 이해를 발전시켜 나갈 때, 인간 지성에서 가장 강력한 도구는 추상화다. 실세계의 특정한 대상체, 상황, 과정 간의 유사성을 인식하는 데에서, 그리고 이러한 유사성에 집중하고, 차이점은 일시적으루 무시하는 결정에서 추상화가 생겨난다. - 토니 호어
- 126p
우리는 조금 전 추상화를 높일 수 있는 방법을 하나 찾아냈습니다. 무엇이었을까요? 바로 '다른 시각을 가진 두 사람이 협력하기'입니다.
- 126p
켄트 벡과 함께 익스트림 프로그래밍의 짝 프로그래밍 개념을 형상화한 워드 커닝햄이 말했습니다.
익스트림 프로그래머는 작업하면서 프로그래밍 각 단계에 대해 함께 이야기한다.
그리고 워드 커닝햄은 다음과 같은 말도 했습니다.
주의해서 생각하지 않으면 프로그래밍은 특정 프로그래밍 언어로 명령문을 타이핑해 넣는 것에 지나지 않는다고 생각할 수 있다.
- 127p
결국 결정하는 것은 사람입니다. 그 사람 마음에 드냐 안 드냐, 이겁니다. 안 들면 어떤 이유를 들어서든 반대하게 됩니다. 도대체 '누구'의 객관이냐 이거죠. 가만히 보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저질러 왔습니다.
- 139p
감정을 배제할 수 없다.
-140p
결론은 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말입니다. 그런 이유로 설득을 하기 위해 '객관적' 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 합니다.
- 144p
두 개의 팀을 상상해 봅시다. 한 팀은 서로 잘 물어보지 않고, 물어봐도 "이것도 모르세요?"의 수준으로 대답해 줍니다. 반대로 다른 팀은 서로 코칭을 해주면서 함께 동기와 의지를 붇돋워주고 같이 고민해줍니다. 어느 팀의 사람들이 성장할까요?
- 152p
전문가들은 추상과 구상을 오르락내리락했습니다. 특히 '아하 순간'은 방향이 꺾이는 지점에서 왔습니다. 뭔가 설계에 기똥찬 개선이 이뤄지는 순간이었다는 말이죠.
- 156p
이와 반대로 비전문가들은 거의 깨끗한 탑다운 선을 그렸습니다. 그런에도 우리는 이렇게 말합니다. "이번 일은 복잡하고 불확실하니까 철저하게 계획하고 단계적으로 접근하자!" 이 말은 곧, 이번 일은 불확실하니까 초보처럼 일하자는 말과 똑같습니다.
- 156p
간단히 말해, '개발 오래한 사람=전문가'로 보고 연구를 했던 것입니다. 하지만 이제는 더 이상 이렇게 접근하는 연구가 흔치 않습니다. 왜냐하면 개발에서 경력과 실력은 상관성이 낮다는 결론이 났기 때문입니다. 개발자 중에는 10년 경력자 중에서도 3년 경력자보다 못한 사람이 많습니다. 그래서 이제는 비슷한 경력을 가진 전문 프로그래머 중에서 성과나 생산성을 갖고 직접 비교하는 연구들이 조명받고 있습니다.
- 157p
연구에 따르면, 프로그램을 이해할 때 고수는 상호 참조 전략을 쓰는 반면, 하수는 그렇지 않았습니다. 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역합니다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다. 이를 상호 참조 전략이라고 합니다. 추상과 구상의 차원을 자주 오가는 것이죠.
- 158p
삼투압적 의사소통... 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 겁니다.
그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리하겠죠. 예를 들어, 프로그래밍하다가 "저기 이거 뭐뭐 안 되는데 아는 사람 있어요?"라고 외칩니다. 테이블 건너편에 있던 디자이너가 답을 해줍니다. 옆에 앉아 자기 일을 하던 기획자는 프로그래머 둘이 하는 대화를 우연히 듣습니다. 그러다가 "아 그런 문제가 있었나요? 저는 어쩌구..." 하면서 끼어들어 새롭고 가치 있는 정보를 줍니다.
- 159~160p
협력을 고취하기 위해 10분간 개입하지 않고 자기들이 알아서 하게 놔둔 전문가팀은 비전문가로만 구성된 팀보다도 훨씬 못한 결과가 나왔습니다. 다순히 전문가들을 모아둔다고 해서 높은 성과가 나오지 않은 것입니다. 이런 경향은 필요한 협력의 정도가 높은 일일수록 도드라집니다.
- 165p
정리하자면,
1. 전문가들 모아서 팀 만든다고 잘하는 것 아니고
2. 오히려 성과가 떨어질 수 있고
3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다
정도의 이야기가 되겠네요.
- 166p
여기에서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음을 말합니다.
- 168p
성공적으로 기술을 도입한 개발팀은 뭐가 달랐을까요. 우선 해당 팀에 자바를 잘하는 사람이 있는지, 혹은 리더가 자바 실력이 있는지는 큰 작용을 하지 못했습니다. 대신, 리더와 팀원들의 학습에 대한 태도에 근본적인 차이가 있었습니다. 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 학습을 팀의 중대한 목표로 받아들였습니다. 리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.
반면 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다. 학습보다는 단기 퍼포먼스를 중요시했습니다. 리더는 낙오의 위험성을 강조하고, 팀원들의 실력이 부족하다고 불평했습니다.
- 177p
학습과 실행은 하나입니다. 진정한 학습은 실행 속에서 이뤄지고, 진정한 실행은 학습을 수반합니다.
- 178p
제가 선호하는 접근법은 관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다. 그 일들이 완료되면 관리자는 할 일을 3개 더 만들어 냅니다. 사람들은 작업을 완료하기 위해 자기 조직화할 수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 동라가는 이유는 사람들이 '관심사의 섞임'을 통해 서로에 대해 엄청나게 많은 것을 빨리 배울 수 있기 때문입니다. 이런 식으로 학습한 지식은 관리자나 혹은 누구든 딱 한 사람이 모델링한 것의 위험을 피할 수 있는데 그런 한 사람에 의한 모델링 때문에 모델 주도 접근법은 불리해집니다.
- 186p *(-워드 커닝햄, 우리는 팀인가요?의 인용문 재인용)
고전적 방법에서는 내가 일을 빨리 끝내는 것이 이 프로젝트에 큰 도움이 되지 않습니다. 내 일은 내 일이고 다른 사람 일은 다른 사람 일이기 때문입니다. 그래서 마감 시간에 맞춰 끝나도록 일부러 일을 늘리는 경향도 생깁니다. 하지만 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와줍니다. 가장 일이 밀려 있는 사람이 누구인지가 확연히 보이기 때문에 프로젝트에서 병목이 되는 사람을 도와주기 쉽습니다. 이렇게 먼저 일을 끝낸 사람이 나머지 사람들을 도와주게 되기 때문에 해당 시점에 나머지 사람들이 일을 제시간에 끝낼 확률이 높아질 겁니다.
- 187p
애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾸는 경향이 있습니다. 좋은 일은 공유를 해서 한 사람이만이라도 중요한 통찰이 있었다면 이걸 공유해서 '또는' 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서(짝 프로그래밍, 코드 공유, 퀵 디자인 세션, 코드 리뷰 등) 모두가 실수해야지만 구멍이 나게 '그리고' 확률로 바꾸는 것입니다.
- 189p
우리의 삶에 애자일을 어떻게 적용할 수 있을까요? 이미 눈치채셨는지 모르겠지만, 사실 우리가 이제까지 이야기했던 학습과 협력이 애자일이 불확실성을 다루는 핵심적인 구동원리입니다. 다시 말해, 학습과 협력을 증진해서 우리 삶에 애자일을 적용하고, 또 이를 통해 불확실성과 친구가 될 수 있습니다.
- 195p
저는 그 씨앗을 한 문장으로 압축해 다음과 같이 표현해 봤습니다.
-198p
우선 학습적 면에서 보면, '매일' 하는 것은 학습의 빈도를 말합니다. 불확실성이 높을수록 빈도가 자주 있어야 합니다. '매일'에는 빈도와 동시에 이른 시점부터 시작한다는 의미가 있습니다. 이러면 학습의 복리 효과를 얻을 수 있습니다.
- 199p
협력이라는 면에서는 '고객에게'라는 부분이 그 중요성을 말하고 있습니다. 소프트웨어 개발이건 뭐건 간에 홀로 결과물이 나오는 경우는 드뭅니다. 협력을 통해서 결과물이 나옵니다.
- 199p
'Book' 카테고리의 다른 글
| [독서 기록] 도메인 주도 설계로 시작하는 마이크로서비스 개발, 1~2장 (5) | 2023.05.30 |
|---|---|
| [독서 기록] 소프트웨어 장인, 산드로 만쿠소 (0) | 2023.05.28 |
| [독서 기록] 그림과 실습으로 배우는 도커 & 쿠버네티스, 오가사와라 시게타카 (0) | 2023.05.18 |
| [독서 기록] 1만 시간의 재발견, 안데르스 에릭슨 (0) | 2023.05.17 |
| [독서 기록] 오브젝트 14장 일관성 있는 협력 (0) | 2023.01.18 |
