8 minute read

자라기

당신은 몇 년 차?

연차라는 허상

대학교를 갓 졸업한 사람과 2년 차 프로그래머 중에서 는 후자의 실력이 높을 확률이 크다. 하지만 5년 차와 10년 차의 연차 차이는 실력을 판단하는 데 있어 큰 의미가 없다.

톰 드마르코와 티모시 리스터의 개발자의 프로그래밍 생산성 비교

  • 개발자 개개인의 능력 차이에서 최고는 최악보다 열 배 정도 업무 능력이 뛰어나다.
  • 중간 이상의 업무 능력을 가진 사람들은 그렇지 못한 나머지 절반보다 두 배쯤 뛰어나다.
  • 경력이 10년인 개발자가 2년인 개발자보다 더 우수하지 않았다. 경력과 생산성은 아무 상관관계가 없었다.
  • 하지만 언어를 접한 경험이 6개월 미만인 개발자들은 전반적으로 나머지 개발자들보다 성적이 저조했다.

경력이란 경력 연차를 말하는게 아니다. 개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과 관련이 있다. 경력의 양적인 면이 아니라 질적인 면이 중요하다.

1만 시간 법칙의 진실

평생을 양치질을 해도, 평생을 걸어도 양치질 전문가, 걷기 전문가가 되지는 않는다. 1만 시간 법칙을 만든 주인공 안데쉬 에릭손이 말하는 1만 시간은 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련, 즉 의도적 수련을 한 시간이다. 다시 말해 정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련이다.

피드백

일반적인 프로젝트에서는 모든 피드백의 주기가 느리다. 설계 단계에서 했던 결정의 피드백을 몇 달 후 테스트 단계에서 받는다. 그때쯤 되면 왜 그런 결정을 했었는지조차 가물거리고 아무렇지 않게 지나치기 쉽다. 피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것. 이 두가지가 의도적 수련의 키 포인트이다.

자기계발은 복리로 돌아온다

지식이나 능력은 복리로 이자가 붙는다. 현명한 투자자는 1. 어떻게 이율을 높일 것인가2. 지속적으로 현명한 투자를 하려면 어떻게 할 것인가를 고민한다.

복리의 비밀

더글러스는 작업을 세 가지 수준으로 구분한다.

  • A 작업 : 원래 그 조직이 하기로 되어 있는 일
    • 자동차 공장이면 자동차를 만드는 것
  • B 작업 : A 작업을 개선하는 것
    • 제품을 만드는 사이클에서 시간과 품질을 개선하고, 제품을 만드는 시스템을 잘 설계하는 것
  • C 작업 : B 작업을 개선하는 것
    • 개선 사이클 자체의 시간과 품질을 개선하는 것. 개선하는 인프라를 설계하는 것.
    • 한마디로 개선하는 능력을 개선하는 것

일반적인 조직은 조직은 그대로이고 결과물을 주기마다 찍어낸다. 매달 결과물을 만든다고 치면 저번달의 조직과 이번 달의 조직은 차이가 없는 것이다.

하지만 복리 조직이 일하는 구조는 첫 주기에 만들어낸 결과물을 계단 삼아 다음 주기에는 더 나은 결과물을 만들어낸다. 이를 통해 조직은 다시 성장하고 다음 주기에는 더 나은 결과물을 만들어내는 선순환을 만들어낸다. 이 조직은 복리의 효과로 성장한다.

B나 C 작업이 거의 없다면 후퇴하는 셈이 된다.

  1. 자신이 이미 갖고 있는 것들을 잘 활용하라.
    1. 내가 갖고 있는 지식들을 얼마나 어떻게 활용하는지 반성하라.
    2. 이미 갖고 있는 것들을 서로 촘촘히 연결하라.
    3. 현재 내가 하고 있는 일이 차후에 밑거름이 될 수 있도록 하라.
  2. 외부 물질을 체화하라.
    1. 일정 수준에 수렴하지 않도록 주기적인 외부 자극이 필요하다.
    2. 외부 자극을 받으면 재빨리 자기화해야한다.
  3. 자신을 개선하는 프로세스에 대해 생각해 보라.
    1. 나의 A 작업을 되돌아보는 회고, 반성 활동을 주기적으로 하는 프로세스를 만들어라.
    2. 나를 개선하는 과정을 어떻게 하면 개선할 수 있을지 고민하라
  4. 피드백을 자주 받아라
  5. 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.

학습 프레임과 실행 프레임

자라기 VS 잘하기

학습 프레임은 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀이다. 학습 프레임은 현재 주어진 과업이 내가 얼마나 배우느냐로 여기게 되는 틀이다. 다시 말해 실행 프레임에서는 잘하기에 초점을 맞추고, 학습 프레임에서는 자라기에 초점을 맞추게한다.

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

동일한 상황에서도 어떤 사람은 자신의 상황 때문에 학습 프레임을 갖는 것이 힘들다는 생각을 하지만, 어떤 누군가는 상황 덕분에 학습 프레임을 가질 수 있었다고 생각한다.

  • 아직 1년도 되지 않아서 업무를 배워가는 중입니다. 아직 업무 파악이 안 된지라 누굴 돕거나 할 입장도 아닙니다.
  • 아직 1년도 되지 않아서 많이 물어보며 배우고 있습니다. 팀 내 스터디를 운영하며 같이 공부하고 있습니다. 아직 1년도 되지 않아 시간이 있으니까 적극적으로 다른 분들 일을 도와드리려고 나서고 있습니다.

가장 학습하기 힘든 직업이 살아남는다

인공지능 시대에 대비하려면 배우기 힘든 것에 집중해야한다. 일자리가 인공지능으로 대체되지 않으려면 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 하는 상황이 된 것이다.

컴퓨터화에 병목이 되는 카테고리

  1. 지각과 조작
  2. 창의적 지능
  3. 사회적 지능

키워드

  • 독창성
  • 사회적 민감성
  • 협상
  • 설득
  • 타인을 돕고 돌보기

컴퓨터화할 수 있는 확률이 높을수록 해당 임금은 낮았다. 해당 직업에서 위 키워드들이 요구되는 수준이 높을수록 그 직업은 컴퓨터화하기 힘들다는 말인데, 이런 역량들이 학습하기 쉽지 않은 것들이다. 직관이나 암묵지가 많으며, 단순히 오래 한다고 실력이 느는 것도 아니다.

컴퓨터 프로그래머 VS 소프트웨어 개발자

  • 컴퓨터 프로그래머 : 요구사항대로 코드를 만드는 사람 - 컴퓨터화 가능 확률 0.48
  • 소프트웨어 개발자 : 사용자의 요구사항을 분석하고 그에 대한 솔루션을 설계하는 것까지 포함 - 컴퓨터화 가능 확률 0.042

소프트웨어 개발자는 타인과 상호작용하는 업무가 많다. 독창성, 협상, 설득 등에서 차이가 나는 것이다.

달인이 되는 비결

꾸준한 반복으로 달인이 되려면 적어도

  1. 실력을 개선하려는 동기가 있어야 하고
  2. 구체적인 피드백을 적절한 시기에 받아야 한다.

특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스는 경험을 오래한다고 해서 자동으로 얻을 수 있는 것은 아니다.

수십 년 동안 전문가가 안 되는 비결

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

전문성이 형성되려면 타당성과 피드백, 두 가지 조건이 필요하다.

  • 타당성 : 예측가능성, 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야한다.
    • 주사위 던지기에서 다음 눈이 뭐가 나올지 아는 전문가는 없다.
  • 피드백 : 자신이 내린 직관적 판단에 대해 빨리 피드백을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야한다.

복잡한 상황에서 뒤죽박죽으로 일하거나 오늘 실수한 것을 몇 달 뒤에 알거나 혹은 영영 모르거나 하는 타당성과 피드백이 부족한 환경에서는 수십년을 일한다고 해도 전문가가 될 수 없다.

소프트웨어 개발은 타당성도 낮고 피드백도 낮은 편이다..

타당성과 피드백을 높이기

타당성을 높이는 법 : 변수를 제한, 실험을 하면서 규칙성과 인과관계를 찾아야한다.

피드백을 높이는 법 : 동료나 상사, 고객에게서 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구해야 한다.

당신이 제자리걸음인 이유

실력을 높이기 위해서는 의도적 수련이 중요하다. 의도적 수련의 양적인 부분뿐만 아니라 질적인 부분도.

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

자신의 능력보다 쉬운 난이도의 일은 지루함을 느낀다. 자신의 능력보다 어려운 난이도 일은 불안함이나 두려움을 느낀다. 난이도와 실력이 엇비슷하게 맞아야 몰입을 경험할 수 있고, 퍼포먼스나 학습 능력이 최대치가 될 수 있다.

자신의 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면 실력이 도무지 늘지 않는 환경에 있는 것이다. 점차 이런 환경에 익숙해지고 행동이 습관화 되어 자기 인식도 잘 되지 않게 된다.

뛰어난 피겨 스케이터는 자기 기량보다 어려운 기술을 연마하지만 그렇지 못한 선수는 이미 잘하는 걸 더 연습한다. 결과적으로는 더 뛰어난 스케이터가 엉덩방아를 더 자주 찧을 수 있다.

제자리 걸음에서 벗어나기

  1. 지루함을 느끼는 경우 : a1 실력 낮추기
    1. 모래주머니 운동법
    2. 프로그래머의 예를 들면 평상시 즐겨 쓰던 보조 도구를 일부러 안쓰기
    3. 키보드로만 개발하기, 디버거를 안쓰기, 컴파일 주기 늘리기…
    4. 실력이 팍 떨어진 느낌이 들지만 의도적 수련이 되어 몰입하는 작업이 될 수 있다.
  2. 지루함을 느끼는 경우 : a2 난이도 높이기
    1. 100rps면 되는 시스템을 1,000rps 기준으로 만들기
    2. 평소 코드를 컴토할 때 버그를 시간당 하나 찾았다면 오늘은 두 개 찾기
    3. 익숙한 작업을 새로운 언어로 진행하기
    4. 공식적으로 안 해도 되는 업무를 자신의 의지로 추가로 하기
      1. 전문가는 남들보다 일을 좀 더 효율적, 효과적으로 하기 위해 나만의 도구, 방법을 만들어 사용한다.
  3. 불안함을 느끼는 경우 : b1 난이도 낮추기
    1. 가장 간단하면서 핵심적인 결과물, 즉 아기 버전 (0.0.1 버전)을 첫 번째 목표로 삼기
    2. 테트리스를 만든다면 일단 화면 한가운데에 네모난 사각형 하나 그리기를 목표로
      1. 쉬운 문제를 먼저 풀고 어려운 문제를 푸는 것이 어려운 문제를 먼저 풀고 쉬운 문제를 푸는 것보다 절반 이하의 결함을 만든다.
  4. 불안함을 느끼는 경우 : b2 실력 높이기
    1. 사회적 접근 : 나보다 뛰어난 전문가의 도움을 얻기
    2. 도구적 접근 : 내 능력을 확장시켜 줄 수 있는 좋은 디버거, 자동 통합 도구, 코드 분석툴, REPL 환경, 오픈소스 라이브러리 사용
    3. 내관적 접근 : 비슷한 일을 했던 경험을 머릿속에서 되살려보기

동적인 균형

자신의 실력이나 작업의 난이도는 계속 조금씩 요동친다. 적절하게 난이도와 실력을 조정해나가야한다. 이런 면에서 자기가 지금 어떤 상태인지 살피는 알아차림이 꼭 필요하다. 메타인지라고도 하는데 공부를 넘어서 모든 분야의 전문성에 있어서도 메타인지는 핵심적인 요소이다.

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

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

튜토리얼을 읽다가도 이 정도면 특정 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작한다. 프로그램을 완성하면 멈췄던 자리로 돌아와 다음 프로그램을 목표로 두며 읽기를 계속한다. 이러한 읽기를 적극적 읽기라고 한다. 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있으면 이해도나 기억력 측면에서도 긍정적인 효과를 가진다.

새 언어를 공부할 때 첫 목표를 단어 개수 세기 프로그램으로 정하면 좋다. (wc)

표준 라이브러리 소스코드를 읽는다

중요한 것은 문법뿐만 아니라 해당 언어의 문화와 스타일을 익히는 것이다. 표준 라이브러리 소스코드는 보통 해당 언어 발명자가 직접 작성하거나 적어도 해당 언어의 스타일을 따르는 소수의 사람들이 작성하므로 가장 그 언어다운 코드들이다. 이를 통해 언어의 스타일을 익혀야한다.

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

실질적인 사용 예를 통해 실제 코드의 감을 익혀야한다. 자신이 만들 수 있는 작고 간단한 추가 기능을 생각해 내는 능력이 필요하다. 이런 방식을 통해 읽고 이해한 내용으로 실제 살아 있는 코드를 수정하고 돌려보는 등 실험하면서 피드백을 받을 수 있다.

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

실수 예방 VS 실수 관리

실수를 저지르지 않는 것은 불가능에 가깝다. 전문가도 1시간에 평균 3~5개의 실수를 저지른다. 하지만 전문가들은 실수를 조기에 발견하고 빠른 조치를 취할 수 있다.

실수는 어떻게든 할 수밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 된다.

이미 결과가 난 실수에 대해서는 학습을 통해 다음 행동할 때 이렇게 하자는 계획을 세우자. (2차적 실수 예방)

실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 실수를 감추고 그에 대해 논의하기 꺼린다. 따라서 실수에서 배우지 못한다.

실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공해하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기를 만든다.

불확실한 상황하에서 실수는 피할 수 없다. 그 상황에서 학습을 잘 하려면 실수를 격려해야 하기도 한다.

뛰어난 선생에 대한 미신

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

전문가는 자신이 해당 과제를 수행할 때 사용하는 지식 중 70%는 가르치지 않는다. 전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화되어서 결국 암묵적이 되어 버린다. 이런 이유로 내가 지식이 많고 수업을 잘하는 뛰어난 선생에게 배웠다고 해서 무조건 잘 배웠다고 말할 수 없는 것이다.

인지적 작업 분석으로 극복하기

선생 입장에서는 자신에 대한 메타인지를 높여야한다. 내가 이 문제를 해결할 때 어떤 과정을 거치는가를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석해야한다. 학생들이 이걸 배우면서 어떤 생각을 하는가를 직접 관찰하고 질문을 던지고 분석해야한다.

학생 입장에서는 그 선생이 가진 지식의 양만 보는 것이 아닌 자신과 학생에 대한 분석을 잘하는 선생을 골라야한다. 또한 선생의 메타인지를 돕기 위해 자기가 어떻게 생각하면서 문제를 풀었는지 인지적 과정을 선생에게 알려주어야한다.

나홀로 전문가에 대한 미신

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

사회적 자본과 기술

신뢰가 깨져있는 상태에서는 어떤 행동을 해도 악의적으로 보인다. 이 신뢰를 사회적 자본의 일종이다. 소위 말하는 사회연결망도 사회적 자본의 일종이다. 사회적 자본이 좋은 사람은 사회적 기술이 뛰어나고, 쉽게 말해 신뢰 구축을 보다 잘한다.

고독한 전문가라는 미신

전문가는 해당 도메인 지식이 뛰어난 것 뿐만 아니라, 사회적 자본과 사회적 기술 또한 뛰어나다. 뛰어난 전문가는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻는다.

뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓰며, 뛰어난 개발자들은 동료와의 협력을 중요시한다. 전문가는 혼자서 일하는 고독한 천재따위가 아니다.

이전에는 프로그래밍 실력은 좋은데 의사소통 능력이 부족하다라는 이야기가 통했지만, 이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 본다.

조직적 전환을 만들고 싶지만 사람들이 너무 수동적이고 보수적이에요 ⇒ 그 조직원들이 선생님을 좋아하나요?

코멘트

읽는 동안 많은 반성을 하게 하는 책이다. 보통 뭔가를 처음 배울 때 익숙하지 않다라는 핑계로 시간이 지나면 더 잘해지겠지라는 안일한 접근을 하는 경우가 많았는데, 그 점을 정확하게 찌르는 문장이 많았다. 의도적 수련이라는 표현이 참 좋은 것 같다. 잘하기 보다 자라기가 낫다는 표현도 그렇고 작가가 본인 생각의 표현력이 좋은 것 같다는 생각을 하며 책을 읽었다. 전문성을 형성하기 위해 어떤 태도를 견지해야하는지 그 방향성을 깨닫게 해준 좋은 책이다. 특히 개발자 관점의 이야기를 많이 해주어서 많은 도움이 된 것 같다. 어서 마저 읽고 생각과 느낌을 정리해야겠다.

Leave a comment