728x90

1. 1만 시간의 법칙 - 안데쉬 에릭손

1만 시간 법칙에서 1만 시간은 '자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련'을 한 시간을 일컫는다

안데쉬 에릭손은 그런 수련을 '의도적 수련' 이라고 정의했다

 

의도적 수련이 필요한 이유는 평생을 걷는다고 해서 또는 평생을 양치질을 한다고해서 점점 더 나아지는게 아니기 때문이다

목표를 가지고 피드백을 반영하는 것이 의도적 수련의 포인트이다


2. 자기계발과 복리의 비밀

더글라스 엥겔바트는 작업을 A, B, C 세가지 수준의 작업으로 구분했다

A작업. 원래 그 조직이 하기로 되어 있는 일

B작업. A 작업을 개선하는 일 (즉, A작업에서 시간과 품질을 개선하는 작업. 시스템과 프로세스 설계 등)

C작업. B 작업을 개선하는 일 (즉, 개선 사이클 자체의 시간과 품질을 개선하는 것. 인프라 설계 등)

 

이것은 복리와 관련이 깊다

출처 - 함께 자라기

C 작업이 없다면 조직에서 동일한 제품을 반복적으로 찍어내는 공장과 다를게 없어진다

매달 같은 결과물을 만들어낸다고 치면 저번 달의 조직과 이번 달의 조직은 차이가 없다는 것 이다

 

출처 - 함께 자라기

하지만 복리 조직이 일하는 구조는 조금 다르다

첫 주기에 만들어낸 결과물을 계단 삼아서 다음 주기에는 조금 더 높은 위치에서 다음 결과물을 만들어 낸다

성장이라는 비유가 떠오르는 구조이다

 

  • 자신이 이미 갖고 있는 것들을 잘 활용하라
    • 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다
      지식을 얼마나 어떻게 활용하는지 반성하라
    • 이미 갖고 있는 것들을 하이퍼링크로 서로 촘촘히 연결하라
      이미 습득한 지식, 기술, 경험 등을 서로 연결 지어서 시너지 효과가 날 수 있도록 하자
    • 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라
    • 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라
  • 외부 물질을 체화하라
    • 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다
      주기적인 외부 자극을 받으면 좋다
      단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다
      자신의 일부로 체화해야 한다
    • 외부 물질 유입 이후 생긴 내부의 갈등을 해결하려는 데에 노력을 기울여야 한다
      무시하고 덮어두지 말라
    • 내가 가진 것들의 상생적 관계를 끌어내도록 하라
  • 자신을 개선하는 프로세스에 대해 생각해 보라
    • A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라(C 작업)
    • 나를 개선하는 과정(B 작업)을 어떻게 개선할 수 있을지 고민해라
  • 피드백을 자주 받아라
    • 사이클 타임을 줄여라
      새로운 정보를 얻었다면 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 1주 후에 작게라도 실험해 보는 것이 좋다
      순환률을 높혀라
    • 일찍, 그리고 자주 실패하라
      실패에서 학습하라
  • 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라
    • 완벽한 도구와 환경을 갖추는 데에 집착해선 안 된다
    • 그런 식으로는 무엇도 얻을 수 없다

3. 학습 프레임과 실행 프레임

실행 프레임에서는 '잘하기'에 초첨을 맞추게 하고,

학습 프레임에서는 '자라기'에 초점을 맞추게 한다면

실행 프레임은 목표가 학습을 통한 성장이라면 불리한 선택이다

학습 프레임에서 훨씬 더 많은 학습이 가능하다


4. 무엇에 집중할 것인가

자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것이다

혼자서 딱 정해진 일만 할 수 있는 환경은 축복이 아니라 저주이다

미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가질 것이다

다른 사람과 경쟁하기 보다는 협력을 잘하는 것이 핵심

개발자는 더 높은 수준의 협상 능력이 필요하다


5. 달인이 되는 비결

1만 시간의 법칙에서 언급했듯이 양치를 10년동안 한다고해서 양치의 달인이 되는 것은 아니다

그럼 역량을 기르기 위해서는 무엇이 필요할까

 

- 실력을 개선하려는 동기

- 적절한 시기에 구체적인 피드백

 

이 두가지가 중요하다


6. 전문성 형성에서 타당성과 피드백의 중요성

믿을 수 있는 직관이 형성되기 위해서는 특정 조건이 필요하다

바로 타당성과 피드백 이다

 

타당성이 떨어지는 영역은 장기적 정치판도 예측과 주가 예측이 대표적이다

역사나 정치학의 전문가와 일반인이 장기적인 정치 판도를 예측했는데 결과에는 별 차이가 없었다

주가를 예측한 실험에서도 펀드 매니저나 원숭이나 큰 차이가 없었고, 오히려 전문가가 더 못 한 경우도 있었다

타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력이 필요하다

 

피드백 조건이 필요하다는 의미는 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경을 말한다

 

타당성과 피드백이 부족한 환경에서는 오래 일해도 전문성이 신장되지 않는다


7. 의도적 수련의 필수조건, 적절한 난이도

의도적 수련이 되려면 나의 실려과 작업의 난이도가 비슷해야 한다

출처 - 함께 자라기

A 영역 - 작업 실력이 난이도를 초과하게 되면 지루함을 느끼게 된다

B 영역 - 작업 실력보다 높은 난이도의 일을하면 불안함 또는 두려움을 느끼게 된다

C 영역(몰입 영역) - 작업 실력과 난이도가 균형이 맞다면 집중력이 높아지고 퍼포먼스나 학습 능력이 최대치가 될 수 있다

 

C 영역의 수련이 의도적 수련이 될 수 있다

반대로 A, B 영역의 일은 의도적 수련이 되지 않고, 실력 향상에 별 도움이 안 된다

 

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것이다

 

결국 핵심은 적절한 난이도 이다


8. 팀장이 할 수 있는 일

앞에 내용들이 개인적으로 적용되는 것일 수 있지만, 다른 사람을 관리하는 사람도 동일한 내용을 응용할 수 있다

팀원들이 현재 어떤 상태를 주로 경험하고 있는지 파악하고 적절한 전략(난이도)을 구사하게 도와줄 수 있다

 

하지만 안타깝게도 몰입 영역(C 영역) 밖으로 팀원들을 몰아내는 행동을 하는 팀장들을 자주 보게 된다

팀원의 상태를 파악하고 그들이 몰입으로 가게 도와주는 것 자체가 고도의 의도적 수련이 될 수도 있다


9. 프로그래밍 언어 배우기의 달인

새로운 언어를 효과적으로 익히고 있는 분들은 이미 비슷한 방법을 쓰고 있을 것 이다

 

- 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다

다음 작성할 프로그램을 염두에 두면서 튜토리얼을 진행한다

튜토리얼을 읽다가도 이 정도면 그 프로그램을 작성할 수 있겠다는 생각이 들면

그 자리에서 읽기를 멈추고 코딩을 시작하고 프로그램을 완성하면 다시 멈췄던 자리로 돌아와서 읽기를 계속한다

이때 다음 프로그램을 목표로 두면서 읽는다

이런 것을 '적극적 읽기'라고 한다

 

- 공부할 때 표준 라이브러리 소스코드를 읽는다

표준 라이브러리는 보통 해당 언어 발명자가 직접 작성하거나 적어도 해당 언어의 스타일을 따르는 소수의 사람들이 작성한다

이런 실제 사례들을 통해 해당 언어의 문화와 스타일을 익히는 것이 중요하다

 

- 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다

실질적인 사용 예를 통해 실제 코드의 감을 익히는 방법

이런 방식을 통해 자신이 튜토리얼을 읽으며 이해한 내용을 바탕으로

코드를 수정하고 돌려보고 하는 등 실험하면서 피드백도 받을 수 있다


10. 실수는 예방하는 것이 아니라 관리하는 것이다

실수는 어떻게든 할 수밖에 없다

대신 그 실수가 나쁜 결과로 발전하기전에 일직 발견하고 빨리 고치면 된다

이 태도를 실수 관리라고 한다

 

이미 결과가 난 실수에 대해서는 학습을 통해 다음 같은 행동에 대해서 계획을 세우기도 한다

이를 2차적 실수 예방이라고 한다

 

실수 예방 문화에서는 실수를 한 사람을 비난하고 처벌하고

따라서 실수를 감추고 그에 대해 논의하기를 꺼리며 문제가 생겼을 때 협력도 덜하게 된다

실수에서 배우지 못한다

 

반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고

실수를 공개하며, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 조성된다

 

불확실한 상황하에서 실수는 피할 수 없으며, 실수가 없으면 학습하지 못한다


11. 뛰어난 선생에 대한 미신

전문가가 가르쳐주는 것이 전부가 아니다

의료계의 연구를 보면 전문가가 특정 수술법을 학생에게 가르칠 때

의료적 지식, 무엇을 어떻게 해야 할지에 대한 행동 단계, 의사결정 단계 등 자신이 해당 과제를 수행할 때 사용하는 지식 중 70%는 가르치지 않는다는 분석이 거듭해 나왔다고 한다

즉, 그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각하는 것이다

 

왜 이런 현상이 벌어지는 것일까?

여러가지가 있지만 대표적인 것이 자동화 이다

전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화되어버려서 결국 암묵적이 되어버린다

그래서 오히려 인식이 없어진다

 

이 현상을 극복하는 방법에는 인지적 작업 분석과 같은 방법이 있다

'내가 이 문제를 해결할 때 어떤 과정을 거치는가'를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석하는 것이다


12. 나홀로 전문가에 대한 미신

전문가가 되기 위해서는 사회성이 중요하다

TDD(테스트 주도 개발) 프로그래밍 기법의 전문가를 예로 들어보자

 

일반적인 TDD 교육을 통해 사람들이 기대하는 과정은 보통 이럴 것이다

  1. TDD를 제대로 이해하고 조직에 돌아간다
  2. 나 스스로 TDD를 제대로 실천해서 객관적 성과를 낸다
  3. TDD가 좋다고 사람들을 설득한다
  4. TDD를 가르쳐 준다
  5. 모두가 TDD를 열심히 한다
  6. 좋은 성과를 낸다

 

여기에서 보통 문제가 되는 부분은 3, 4, 5, 6번 이다

그리고 1, 2번을 잘한다고해서 3번 이후가 꼭 쉬워지는 것이 아니다

하지만 교육에서는 통상 1번에만 집중 한다

 

이럴 경우 실무로 돌아갔을 때 흔히 접하는 문제는 예컨대 다음과 같다

  1. 회사로 돌아가서 실무에 적용하려고 하는데 상사나 동료의 지원 없이 추가적으로 일을 하려니,
    시간이 모자라 계속 미루게 되어 결국 적용하지 못한다
  2. 팀원/팀장들에게 전파 교육을 하려 하지만 팀원/팀장들 가운데 몇몇은 추가 업무를 왜 하는지 필요성을 못 느끼는 상태에서 강제로 해야 한다는 스트레스를 받아서 부작용이 생긴다
    그래서 결과적으로 해당 기법은 실무에 써먹을 수 없다는 평가가 나온다
  3. 배운 것을 팀 내에서는 열심히 적용했으나 지원해주는 임원이 없어 확대하는 데 실패하고, 조직 내에서는 한 팀의 별난 문화로 치부되어 실행 범위가 축소된다
  4. 배운 대로 팀에서 실천했더니 "다른 부서는 그런 거 없이도 잘하는데 너희는 왜 그런 거 하면서 제때 아웃풋이 안 나오냐"며 이해할 수 없다고 말하는 상사나 협력 팀의 리더와 갈등을 겪는다
  5. 기술적으로 어떻게 해야 할지 모르겠는데, 주변에 물어볼 사람이 없어 인터넷 검색하느라 몇 시간씩 보낸다
    하지만 결국 원하는 정보를 찾지 못해서 적용을 포기한다
  6. 회사에서는 여력이 없어 배운 것을 집에서 시도해 보려 했더니, 가족들의 여러 요구로 인해 집중할 수 없어 화를 내거나, 가족의 요구대로 하느라 내가 할 일은 시작도 못 하거나, 그냥 포기하고 잠을 자게 된다

 

이런 문제들은 보통 사회적 측면에 대한 것이다

뭘 하든지 나 혼자가 아니라 항상 누군가 등장하고, 일의 성패에 다른 사람이 관련되어 있기 때문이다

 

어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다


13. 사회적 자본과 기술

신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다

예를 들어 팀장과 팀원 사이의 신뢰가 이미 깨져 있는 상태라면 TDD 적용 등의 책을 선물했을 때

'나 보고 이런 거 모르니 공부하라는 얘기야? 자기는 쥐뿔도 모르면서..." 라고 생각할 수 있다는 것 이다

 

이 신뢰를 사회적 자본의 일종이라고 한다

소위 말하는 사회 연결망도 사회적 자본의 일종이다

 

전문가는 사회적 자본과 사회적 기술 또한 뛰어나야한다

뛰어난 전문가는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻는다

뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 기술적인 측면 뿐 아니라 사회적인 측면을 강조한다

 

뛰어난 개발자들은 약 70%가 동료와의 협력을 언급하는 반면,

실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협력을 언급했다고 한다

 

무언가 회사에서 기술적인 영향을 끼치고 싶다면 

그 조직원들이 나를 좋아하는가를 먼저 생각해보자


마무리 느낌점

 

전에 카네기 인간관계론이나 인간본성의 법칙과 같은 책을 읽었을 때와 비슷한 내용들을

개발자를 기준으로 또는 직장인을 기준으로 쓰여진 인문학 책같다는 느낌을 받았다

애자일 방법론을 배우는 것도 좋지만 살아가는데 필요한 경험도 배우는 느낌이라 술술 읽힌 것 같다

1부에서 강조한 내용인 의도적인 수련과 실수 관리론, 복리 성장, 사회적 자본과 기술 내용 등 인상깊은 부분이 많았다

꼭 개발자 뿐만아니라 직장인 특히 리더급이라면 더 읽기 좋은 책이라는 느낌을 받았다

 

728x90
복사했습니다!