[책리뷰] 함께자라기 (1) - 자라기(성장)

함께 자라기 책은 크게 세 파트로 나뉘어 있다. 

첫번째 자라기 파트에서는 전략적으로 성장하고 작업을 분류해서 의도적으로 수련할 수 있는 방법을 안내해준다. 
여담인데 무의식적으로 어려운 게 나오면 문서 보고, 누군가의 도움을 받는 게 자연스러운 행위인데 이런 개념을 정리하고 성장에 도움이 될 수 있게 전략적으로 풀어내는 사람이 있다는 것도 신기하다. 그리고 이 책에 나오는 사례들을 읽다 보면 이런 걸 연구하는 사람들이 있다는 게 놀랍다.

자라기 파트를 다 읽고 들었던 생각은 어떻게 해야 내 삶에 이 인싸이트를 적용시킬 수 있을까? 였다.
일단 나에게 맞는 수련 방법을 좀 더 고도화 시켜야겠다. 오랜 방황(ㅋ)을 통해 나는 나의 성장을 위해 무엇을 공부해야하는 지 알고 있고, 어느 정도 공부 습관을 만들었지만 수련 방법에 대해서는 고민을 하지 않았다. 그래서 2022년부터는 나만의 성장 시스템을 갖추기 위해 회고를 작성했다.
공부할 때에는 사실 책이나 강의를 듣는 걸 선호하는 데, 실무를 할 때에는 그때 그때 필요한 부분을 공부하거나 예제 위주로 사용 방법을 익히고 있다. 공부방법은 1n 년의 교과과정의 익숙함에 길들여진 것 같고, 실무에서의 공부는 생존을 위해 어쩔 수 없는 선택(ㅋ)이 된 거라서, 이 방법들이 나에게 맞고 효율적인가?에 대해서는 생각해 본 적이 없다.
내가 시도했던 공부 방법들은 스터디(파토남), TIL(나랑 안맞음, WIL 정도가 좋다), 블로그(그나마 나에게 맞음), 토이프로젝트(아이디어나 BM, 기술 선택하다가 포기) 이다. 살아남은 건 결국 블로그 뿐... 그리고 최근엔 책을 읽을 때 천천히 읽으면서 내 소감과 궁금한 점을 생각하는 시간을 더 많이 갖고 있다. 이렇게 읽으면 한 권을 읽어도 좀 풍부하게 책을 바라보게 되는 것 같다. (난 좋은 책이라도 한번 읽으면 태만해서 여러 번 안읽어서 제대로 읽어야함)

사실 이 책은 팀에서 같이 읽기로 선정되서 읽게 되었고, 주마다 각 파트를 읽고 난 뒤에 소감과 팀에서 할만한 액션을 정하기로 했다. 이 책에서는 많은 이야기를 하고 있는데, 팀 차원에서 했으면 좋겠다 싶은게 바로 느껴졌다. 저자는 전문가의 직감 향상을 위해 적절한 난이도, 타당성, 피드백이 핵심 요소라고 말했다. 그 중에서 팀에서 제공할 수 있는 건 피드백이 아닐까? 그래서 팀원들간에 피드백을 빠르고 쉽게 주고 받으려면 무엇이 선행되야할까 생각해 봤는데, 역시 질문하기 편한 분위기와 질문자의 배려가 아닐까 싶었다. 그래서 아래 액션을 제의해봤다.
👉 질문하기 편한 분위기
- 나부터 모르는 건 팀 채널에 공개적으로 물어보기 (물론 질문자가 부담스럽다면 DM도 환영)
- 질문할 때에는 문제 배경과 자신이 겪는 문제, 해결하기 위해 시도한 방법을 간단하게 알려주기 (혹은 너무 단순한 질문이더라도 왜 묻는지 정도는 알려주기)
- 뭐 안했다고 놀리지 말기 (ㅋㅋㅋ)
- 놀림당해서 슬퍼지면 놀린사람 타박하기

목차

• 자라기 (현재)
• 함께
• 애자일

---

자라기

자라기 파트 중 인상적인 내용을 요약해서 블럭 처리를 해두었고, 바로 아래에 개인적인 생각을 정리했다.

👉 경력의 양보다 질

상반된 의견과 정보 속에서 스스로 생각하는 훈련을 해나가야 함
경력과 업무 수행 능력에 깊은 상관성이 없음
최소한도의 경험치만 넘어가면 경력 연수와 실제 직무 성과의 상관성이 생각보다 낮음
개발자의 경험이 얼마나 폭넓고 다양했는지가 실제 직무성과와 관련이 있음
경력의 양적인 면이 아니라 질적인 면의 중요성을 발견함

너무 공감하는 내용이다.
비슷한 도메인, 같은 기술로 10년의 경력을 보낸 이와 다양한 기술을 다양한 분야에 사용하며 5년의 경력을 쌓은 이를 생각하면 더욱 그렇다. 나 같은 경우에도 개인적인 사정이 있어서 약 6~7년 정도를 동일한 기술 환경에서 근무 했었다.그때는 그게 최선의 선택이라고 생각했는데, 지금와서 보면 차라리 힘들더라도 이직을 했으면 좋았겠다는 생각이 든다. 왜냐면 기술적 성장은 3년차 정도부터 눈에 띄게 느려지기 시작했었다. 기술적 성장에 대한 갈증을 풀기 위해 새로운 언어를 배우거나 프레임워크를 배웠는데 실무에서 쓰지 않으니 결국 자연스럽게 잊혀졌다.

지금 생각해보면 그때는 나에게 맞지 않는 공부방법과 지식, 방향으로 나아가려고 아둥바둥했다. 오랜 시간 공부하고 버티느라 힘은 들었지만 결국 도움은 되지 않았다. 동기가 있다고 해도 나에게 맞는 공부 방법과 무엇을 공부해야할 지 모른다면 열심히해도 시간만 흘러간다. (그리고 이직할때 겁내 힘들었다)

스스로를 다양한 경험을 할 수 있는 환경에 노출하는 것이 중요하다고 생각한다.

👉 내가 당장 할 수 있는 것, 의도적 수련

의도적 수련이란 자신의 기량을 향상시킬 목적으로 반복적으로 하는 수련을 말함
정말 기량 향상을 목적으로 자신의 약점을 개선하려고 애쓰는 수련, 그것만이 의도적 수련임
업무를 하면서도 의도적 수련을 할 수 있는 방법이 있음
피드백을 짧은 주기로 얻는 것, 그리고 실수를 교정할 기회가 있는 것

마냥 주어진 일을 반복적으로 처리한다고 해서 그 작업에 전문성이 높아지지 않는다. 한글 사용 수 십년, 여전히 맞춤법을 틀리는 것과 비슷한 맥락이다.

더 빨리 자라고 싶다면 1) 어떻게 이율을 높일 것인가와 2) 지속적으로 현명한 투자를 하려면 어떻게 할 것인가를 고민해야함
  - A 작업은 원래 그 조직이 하기로 되어 있는 일을 하는 것을 말함
  - B 작업은 A 작업을 개선하는 걸 말함
  - C 작업은 B 작업을 개선하는 것
가장 미묘하고 또 잠재적으로 가장 영향력이 큰 것은 C 작업으로 이는 우리의 사고방식과 상호 작용 방식을 개선함

무엇을 A 작업으로 보느냐에 따라 다른데, 나는 A 작업을 개발자가 기본적으로 해야하는 임무(설계, 개발, 테스트)와 그걸 하기 위한 도구(프로그래밍 언어, 프레임워크 등)를 학습하는 것으로 받아들였다.

B 작업(A 작업을 개선하는 것) 을 코드 리뷰, 회고, 블로그, 사이드프로젝트, 리팩토링으로 생각했다.
현재 상황에 맞고 유연한 설계와 코드를 작성하고 결과물도 꾸준히 개선시키는 것, 여러 학습 방법을 시도하는 것 등이 B 작업이라고 생각한다.

C 작업(B 작업을 개선하는 것) 은 내가 B 작업을 잘 하고 있는 지 회고하고, 정말 B 작업이 A 작업을 개선하는 데에 효과가 있었는 지 생각해보는 주기를 프로세스화하는 걸로 받아들였다.
본인에게 맞는 학습 방법을 더 고도화하고 최적화하는 것도 이런 작업에 포함된다고 생각한다.

A 작업을 개선하려면 두 가지 질문을 해야함
  1. 어떻게 하면 더하기보다 곱하기를 할 수 있을 것인가
  2. 어떻게 해야 곱하는 비율(이자율)을 높일 수 있는가 혹은 이자 적용 주기를 짧게 할 수 있는가

(이 질문들에 대한 저자의 깨달음을 아래 정리함)

* 자신이 이미 갖고 있는 것들을 잘 활용하라
  - 내가 알고 있는 지식을 얼마나 어떻게 활용하는지 반성하라
  - 이미 슥듭한 지식, 기술, 경험 등을 서로 연결 지어서 시너지 효과가 나게 하고 하나의 영역에서 다른 영역으로 왔다갔다하는 것을 자주 해서 다른 여역 간을 넘나들기가 수월해지도록 하라
  - 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라
* 외부 물질을 체화하라
  - 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다.
  - 외부 물질 유입 이후 생긴 내부의 갈등을 해결하는 데에 노력을 기울여야 한다. 무시하고 덮어두지 마라
* 자신을 개선하는 프로세스에 대해 생각해 보라
  - 나의 A 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라 (C 작업)
  - 나를 개선하는 과정(B 작업)을 어떻게 하면 개선할 수 있을 지 고민하라
* 피드백을 자주 받아라
  - 사이클 타임을 줄여라
  - 일찍, 그리고 자주 실패하라. 실패에서 학습하라.
* 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라
  - 점차적으로 자신을 도와주는 환경을 만들어 나가라
  - 완벽한 도구와 환경을 갖추는 데에 집착해선 안된다

- 내가 알고 있는 것들을 곱씹고, 잘못 이해한 것을 파악하고, 내 업무에 어떻게 적용할지 상상해보고, 새로운 지식과 연관지어서 생각해보기
- 새로운 단어나 개념에 대해 듣게 된다면, 그런 게 있구나 끝내지 말고 구글링을 하자. 만약 그게 내 업무를 개선시키는 데에 필요하다고 판단되면 빠른 시일 내로 각잡고 공부하기
- 나를 개선하는 프로세스와 피드백을 자주 받을 수 있는 환경 구축하기
- 내가 겪는 문제들을 살펴보고 패턴을 찾아서 유용한 도구 만들기 (자동화 or 분석용)

👉 경쟁력 있는 개발자

대체 가능한 개발자는 다른 사람이 준 스펙대로 개발하는 것을 주 업무로 하며 그 과정에서 협상, 설득이 필요하지 않음
반면에 대체 어려운 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많음
즉, 개발자는 더 높은 수준의 협상 능력이 필요하다는 뜻
자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것
현재 자신의 업무 상황 속에서 창의적으로, 그리고 사회적으로 일하지 않는 기간이 계속된다면 결국 자신의 커리어에 막대한 손해가 될 수 있다는 점
혼자서 딱 정해진 일만 할 수 있는 환경이 축복이 아니라 저주가 될 수 있음
결론적으로, 미래에는 암묵지와 직관을 잘 학습하는 사람들이 높은 경쟁력을 가질 것임

그런데 여기서 문제가 생김. 이런 것들은 배우기가 어려움. 자신이 얼마나 잘하는지 판단하기도 어려움
지금부터라도 암묵지와 직관을 배우고 수련하는 방법을 배우면 됌
한발 더 나아가, 알파고랑 경쟁하기보다는 협력하는 방법을 배우는 것을 추가할 수 있음
즉, 알파고를 사용하는 데에 필요한 암묵지와 직관, 독창성, 그리고 다른 사람과 협력을 잘하는 것이 알파고를 얼마나 잘 쓰냐를 결정하는 핵심

나중에 AI의 도움으로 개발자가 코딩에 사용하는 업무 시간이 확연히 줄어들더라도, 개발자라는 직업은 여전히 존재할 것이라고 확신한다. 하는 일의 비중만 달라지는 게 아닐까?

사실 지금도 대부분의 코딩을 AWS가...

👉 꾸준한 반복으로 달인이 되려면

1. 실력을 개선하려는 동기
2. 구체적은 피드백을 적절한 시기에
  - 이빨을 매일 닦아도 잘 닦는지 아닌지 정확하고 꼼꼼한 피드백을 받지 못함. 치과에 가서야 알게 됌
  - 적절한 시기에 구체적인 피드백을 받아야 내가 뭘 잘했는지 못했는지 알 수 있고 실력도 늘 수 있음

특정 영역에서 자신의 실력을 향상시키고 싶은 사람이라면 혹시 그 일을 내가 양치질하듯이 수십 년을 단순히 반복해 온 것은 아닌지 반문해보고,
내 일에서 매 양치질 직후 구강 거울이나 치면착색제의 역할을 하고 있는 것은 무엇인지,
없다면 어떻게 만들어낼지 고민해봐야 함

그래서 동료분들과 함께 하는 코드리뷰나 페어코딩이 즉각적으로 피드백을 받고 나도 질문할 수 있어서 효과적인 것 같다. 그리고 내 친구 인텔리제이는 사랑입니다.

👉 직관 형성하기 : 타당성, 피드백, 적절한 난이도

수십 년 동안 한가지 일을 하면서 전문가가 안 되는 비결이 있다면 이 타당성과 피드백이 부족한 환경에서 일하는 것
ex) 복잡한 상황에서 뒤죽박죽으로 일하거나 오늘 실수한 것을 몇 달 뒤에 알거나 혹은 영영 모르거나 하는 환경

* 타당성
  - 직관이 적용되는 영역에 어느 정도 인과관계와 규칙성이 존재해야 함. 예측가능성이라고도 말할 수 있음
  - 타당성을 높이려면 변수를 제한하고 실험하면서 규칙성과 인과관계를 찾으려는 노력을 하면 됨
* 피드백
  - 자신이 내린 직관적 판단에 대해 빨리 피드을 받고 이를 통해 학습할 기회가 주어지는 환경이 갖춰져야 한다는 뜻
  - 동료나 상사, 고객에게서, 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하면 됨
* 적절한 난이도
  - 불안함(어려운 난이도)이나 지루함(쉬운 난이도)를 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것임
  - 의도적 수련의 필수 조건은 적절한 난이도임

소프트웨어 개발은 전반적으로 타당성도 낮고 피드백도 낮은 편이라고 생각함
안타깝게도 타당성과 피드백이 부족한 환경에서는 오래 일해도 전문성이 신장되지 않음

그래서 타당성을 높이고 피드백을 구체적으로 자주 받으려면 스스로 찾아 나서야한다. 안타깝게도 모든 팀과 조직이 이런 문화를 잘 갖춰져 있다면 땡큐지만 현실은 녹록하지 않지. 내가 원하는 데로 생겨있지 않지.

개발할 때에 피드백을 받을 수 있는 도구나 기법은 많이 나온 것 같다. IDE, 의존성 검사, 성능 검사툴, 테스트코드를 통한 테스트나, 코드리뷰, 페어코딩, 회고 같은 것들을 통해 피드백을 받을 수 있다.

근데 타당성은 설명은 이해가 가는데 예제가 떠오르지 않는 걸 보면 이해를 못한 것 같다.

적절한 난이도에 대해서는 아래 내용에 이어서 말해보겠다.

👉 난이도 조절하기

본인의 하루가 불안하거나 지루한 때가 대부분이라면 이 전략들을 사용해야함

* 지루함을 느끼는 경우 : 실력 낮추기
  - 작업의 난이도는 그대로 두고 실력을 낮추는 전략
  - 평소 사용하는 유용한 보조 도구를 안 쓴다던가 해서 좀 더 집중하고 머릿속에서 좀 더 많은 연산을 할 수 있도록

* 지루함을 느끼는 경우 : 난이도 높이기
  - 실력은 그대로 두고 난이도를 높이는 전략 (자신만의 제약을 추가함)
  - 자기에게 요구되는 수준을 더 높게 여기는 것 (개발 일정을 단축시키기, 새로운 언어로 해보기, 성능 높이기, 평소보다 버그 많이 찾기 등)
  - 공식적으로는 안 해도 되는 업무를 자신의 의지로 추가하는 것 (리팩토링, 자동화 테스트 추가, 자신만의 도구나 방법을 개발 등)
  - 남들보다 일을 좀 더 효율적/효과적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구나 방법을 찾거나 만들기 (이런 도구는 크게 내가 아는 단계를 자동으로 진행하게 해주는 실행적 도구와 현 상황 파악을 쉽게 해주는 탐색/분석적 도구 두 가지로 나뉨)

* 불안함을 느끼는 경우 : 실력 높이기
  - 장기적으로 실력을 높이는 방법은 많음 (책 읽기, 스터디 참가, 교육 듣기 등) 하지만 지금 당장 불안함을 느끼고 있다면 실력을 높이기 위해 크게 세 가지 접근이 가능함
  - 사회적 접근 : 나보다 뛰어난 전문가의 도움을 얻는 것. 잘하는 사람에게 짝프로그래밍을 해달라고 부탁하거나 인터넷에서 전문가의 도움을 얻거나, 괜찮은 튜토리얼 문서를 보며 진행해보거나 등
  - 도구적 접근 : 내 능력을 확장시켜 줄 수 있는 도구 사용 (괜찮은 디버거, 자동 통합 도구, 코드 분석툴, REPL 환경 등을 사용하거나 오픈소스 라이브러리를 빌려 쓰는 것 등)
  - 내관적 접근 : 비슷한 일을 했던 경험을 머릿속에서 되살려 보는 것. 그때 그 일을 어떻게 했는지 떠올려 보면서 비유적으로 문제를 해결

* 불안함을 느끼는 경우 : 난이도 낮추기
  - 난이도를 낮춰서 몰입 영역으로 들어가는 전략
  - 간단하면서 효과적인 방법은, 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전(0.0.1)을 첫 번째 목표로 삼는 것
  - 난이도를 낮춘 결과 학습 효과, 동기 강화, 스트레스 감소, 자기 효능감 증가 등의 긍정적인 효과가 생겨 이득을 얻을 수 있음

동기나 실행의 문제가 아니라 방향성과 전략의 문제라고 생각한다. 사실 지루함이나 불안함을 느낀 경험이 많지만 사회 초년생 때에는 이렇게 전략적으로 접근하며 생각해보지 않아서 내가 했던 실행들이 효과적이지 않았다(공부하는 방법도 몰랐음). 그러다 보니 업무에 지루함을 느끼는 경우 새로운 기술을 쌓고 결국 안쓰는 지식이라 까먹는다거나, 지루함에 매몰되어 있는 경우가 많았다.

이후에 개발 환경을 전환하면서 모르는게 너무 많으니까 내가 개발하는 기능을 구현하기 위한 베스트 프락티스나 적용되면 좋은 세부 기능을 스스로 구현하게 됐는데, 이게 자연스러운 난이도 높이기 전략을 사용하게 된 것 같다.

실력 높이기 전략의 내관적 접근 시 자기효용감이 증대하면서 스스로 인식하는 자기 실력이 향상되기 쉽고, 몰입 영역에 들어가기 좋다고 한다. 나는 내가 겪었던 문제가 또 반복될 가능성이 있으면 그 해결과정을 노션 문서로 정리해놓는다. 그래서 다음번에 그 일을 해결할 때 필요한 부분만 스윽 읽어서 해결하는 편인데, 이렇기 때문에 처음으로 시도한 방법을 개선하지 않고 그대로 답습하게 된다. 효율적이지만 문서의 내용을 갱신하거나 내가 시도한 방법을 더 개선시키지 않게 된다. 나도 노션 문서를 바로 보지 않고 과거 경험을 먼저 되새김질 해봐야겠다.

👉 하지만 작업의 난이도나 나의 실력은 동적으로 변화함

자신의 실력이나 작업의 난이도가 계속 조금씩 요동을 치고 있음
애매해서 잘 안 되던 게 이해가 되니까 진도가 쑥 나간다거나, 코딩을 시작할 때에는 쉬운 일로 생각했는데 갑자기 버그가 나서 난이도가 확 올라간다거나 하는 일 등이 있을 수 있음

현재 자신의 업무 처리 속도가 외부적으로 문제가 되지 않는 범위 내에서 적절하게 난이도와 실력을 조정해나가야 함
이 말은 곧, 지속적으로 자신의 감정 상태를 살피면서 지금 지루한지 불안한지를 알아채고 만약 지루함이나 불안함을 느낀다면 앞의 네 가지 전략을 적절히 사용해야 한다는 것
감정 상태를 살피고 조치를 취하는 사이클을 계속 돌아야 함
그런 면에서 자기가 어떤 상태인지 살피는 알아차림(mindfulness)이 꼭 필요함 (메타인지 전략이라고도 함)

스스로에게도 적용할 수 있지만, 다른사람을 관리하는 사람도 동일한 내용을 응용할 수 있음
팀원들이 현재 어떤 상태를 주로 경험하고 있는지 파악하고 적절한 전략을 구사하게 도와줄 수 있음

하나의 기능을 구현할 때에도 어떤 세부 사항에 막혀서 시간을 잡아먹히기도 하고, 갑자기 이해가 되서 술술 풀리기도 한다. 근데 이럴 때에는 막힌 부분에 대해 공식 문서를 읽거나 구글링을 먼저 해보고, 그래도 안되면 주변 동료분들이나 전문가(AWS 문의, 스택오버플로우 문의)들에게 물어본다. 이렇게 개발하다가 막히는 경우 사용하는 전략은 대부분 ‘실력 높이기' 이고, 가끔 내가 스스로 잡은 목표가 버겁거나 시간이 부족하다면 ‘난이도 낮추기'를 해서 문제 자체를 쉽게 만들기도 한다. 근데 이거는 전략적인 선택이 아니라 본능적으로 살기 위해 하는 것 같다 ㅋㅋㅋ

👉 S 개발자의 프로그래밍 언어 학습법

1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽기
읽다가도 이 정도면 그 프로그램을 작성할 수 있겠다는 생각이 들면 그 자리에서 읽기를 멈추고 코딩을 시작합니다.
프로그램을 완성하면 잠시 멈췄던 자리로 돌아와서 읽기를 계속합니다.
이런 것 처럼 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법을 적극적 읽기라고 합니다.
참고로 이 S 개발자의 첫 번째 목표는 주로 단어 개수 세기 프로그램이라고 합니다.
이 문제를 염두해 두고 '이 언어에서 루프는 어떻게 짜야 하지?', '글자 하나를 읽으려면 어떻게 하지?', '출력은 어떻게 하지?' 와 같은 질문을 갖고 적극적으로 읽는 것.
또, 여러 언어에서 같은 프로그램을 작성하면서 언어 사이의 차이를 쉽게 느낄 수 있음

2. 공부할 때 표준 라이브러리 소스코드를 읽기
S 님은 튜토리얼을 읽으며 틈틈이 해당 언어의 표준 라이브러리를 찾아 읽었습니다.
표준 라이브러리는 보통 해당 언어 발명자가 직접 작성하거나 적어도 해당 언어의 스타일을 따르는 소수의 사람들이 작성합니다.
가장 그 언어다운 코드들의 말뭉치이지요.
S 님은 튜토리얼을 공부하는 것만으로는 그 언어의 숙어와 패턴, 스타일을 배우기 불충분하다는 것을 알고 있는 것이죠.

3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가
여기에서 주요한 점은 그 당시에 자신이 만들 수 있는 작고 간단한 추가 기능을 생각해 낼 수 있었던 점이 아닌가 싶습니다.
유용하면서도 작고 간단한 걸 생각해 내는 것이 앞서의 몰입을 위한 난이도 조절이라고 볼 수 있습니다.
이런 방식을 통해 자신이 튜토리얼을 읽으며 이해한 내용을, 실제로 살아 있는 코드를 수정하고 돌려보고 하는 등 실험하면서 피드백 받을 수 있었습니다.
더 나아가, 해당 오픈소스 커뮤니티와 교류를 통한 피드백 받기도 가능했겠지요.

인상적이었다. 이런 식으로 학습을 하시는 분도 계시는 구나 싶었다.

애초에 처음 언어를 공부할 때 부터 뭘 만들지 생각하고 접근하시는 것도, 공식 문서를 읽어내려가시는 것도, 이미 구현된 다른 사람의 코드에 작은 기능을 추가하는 것도!

나도 사용중인 언어를 다시 공부할 생각인데, 새로운 언어는 아니지만 내가 업무에서 구현한 코드가 어떻게 동작하고 어떤 기능을 추가하면 좋을 지 생각하면서 공부해야겠다.

👉 전문가에게 전문성을 효과적으로 뽑아내기

전문가들의 전문성을 뽑아내고 적용하는 것이 자신의 전문성을 빨리 높일 수 있는 방법임
저자는 S 님에게 "프로그래밍 언어를 빨리 배우는 비결이 무엇인가요?"라고 묻지 않았음
이런 질문을 받았을 때 전문가들은 너무 일반적인 답을 하거나, 실제 자신의 행동과는 다른 이론적인 답을 하는 경향이 있음
한 가지 비결은 전문가가 구체적인 사건에 대해 말하도록 유도하는 것!
전문가에게 굉장히 구체적인 기억들을 상기하도록 함
S 님의 경우, 가장 최근에 익힌 언어가 Go라고 했는데, 그 언어를 익힌 과정을 시간대별로 짚어가며 어떤 행동을 했는지, 그리고 암묵적인 의사결정과 상황판단이 무엇이었는지를 추출했음

'전문가가 빨리 되기' 위해서는 '전문가에게서 전문성을 효과적으로 뽑아내기'에 대해 전문가가 되어야함

선생이 가진 지식은 학생의 성과를 높여주는 면에 있어 큰 영향을 주지 못했음
전문가는 그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각함
이런 현상이 벌어지는 이유에는 여러 가지가 있지만 대표적인 것이 자동화임
전문가가 되면 자신이 하는 일이 반복적으로 몸에 익고 자동화되어서 결국 암묵적이 되어 버림
그래서 오히려 인식이 없어지는 것

이걸 극복하는 방법은 무엇일까?
앞에서 <프로그래밍 언어 배우기의 달인>의 인지적 작업 분석 같은 방법을 선생과 학생이 쓰는 것임
선생 입장 : 
  - 자신에 대한 메타인지를 높이는 노력을 함
  - "내가 이 문제를 해결할 때 어떤 과정을 거치는가"를 생각하며 자신의 머릿속을 관찰하고, 질문을 던지고 분석하는 것
  - 그리고 학생들이 이걸 배우면서 어떤 생각을 하는가를 직접 관찰하고 질문을 던지고 분석할 수 있음
  - 이런 분석 능력이 뛰어난 선생이 잘 가르치는 사람이라는 이야기
학생 입장 :
  - 선택권이 있다면 자신과 학생에 대한 분석을 잘하는 선생을 고르는 것이 유리한 전략
  - 선생의 메타인지를 돕기 위해 자기가 어떻게 생각하면서 이 문제를 풀었는지 그 인지적 과정을 선생에게 알려주는 것도 매우 효과적
  - 선생이 그 문제를 푼 인지적 과정 자체를 알려달라고 요청할 수도 있음
  - 이런 부분에 능하면, 가르쳐주는 기술은 부족하지만 해당 분야의 실제 전문가인 선생을 만났을 경우 무척 유용함

질문의 중요성. 인상적인 문구는 학생 입장에서 가르쳐주는 기술은 부족하지만 해당 분야의 실제 전문가인 선생을 만났을 경우 무척 유용함 이다. 근데 이거는 너무 어렵다 😂 나같은 경우에는 내가 겪고 있는 문제 상황이나 배경을 설명하고, 내가 시도했던 방법들과 앞으로 시도할 방법들, 그리고 내가 문제의 원인으로 추측하는 것들에 대해서 정리한 다음에 질문하는 편이다. 이러면 그 사람의 인싸이트를 끌어낼 수는 없어도 최대한 친절하게 답변해주시고, 거기에서 궁금한 게 생기면 다시 질문하면서 도움을 받는 편이다.

👉 실수 관리

실수는 어떻게든 할 수 밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 됨
이미 결과가 난 실수에 대해서는 학습을 통해 "다음 행동할 때 이렇게 하자"는 계획을 세우기도 함
실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생김
실수 관리를 하는 문화일수록 학습을 더 잘함
다양한 실수를 경험하는 걸 격려하고, 실수 사례를 배우고, 실수 시에 어떻게 대처하는가를 가르치는 교육이 더 효과적이라는 연구 결과가 많음
그래서 전문가에게 실수 대처법을 배우는 것이 중요함

자신의 실수 문화를 예방에서 관리로 옮겨가려면 어떻게 해야 할까?
스스로에게 이 질문을 묻는 것이 불확실한 상황에서 학습을 높이기 위한 첫걸음이 될 것임

실수를 밝히고 질문하는 것이 부담이 되지 않게 팀 분위기를 조성하고 싶다. 이미 어느정도 그렇게 되어있다고 느끼긴 하지만, 앞으로 새로 입사하시는 분들도 부담감이나 두려움이 없으셨으면 좋겠다. 이거는 우리 팀장님과 CTO님이 장애 상황에 대해서 해결과 개선을 중심으로 바라보시기 때문이 아닐까? 물론 장애 원인도 알아보지만 그게 누군가의 잘못으로 돌리기 위함이 아니라는 걸 알아서 나는 안정적으로 느낀다.

👉 결국은 사회적 자본과 기술 (나홀로 전문가에 대한 미신)

1) 아무리 기술적인 실천법이라고 해도
2) 그 기술은 사회적 맥락 속에서 실천되어야 하며
3) 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요함
하지만 안타깝게도 현실에서는 팀원들이 맘에 안 들고, 그들도 나를 맘에 들어 하지 않는 상황,
즉 사회적 맥락이 나쁜 상황에서 타개책으로 TDD와 기술적 측면에만 매몰되는 경우가 있음.
사실 그런 상황에서는 무엇을 골라도 실패가 보장되어 있음
설사 나 혼자 하는 실천법이라고 해도, 상사가 내가 하는 일을 보고 반대하면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하므로

신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보임
이 신뢰를 사회적 자본의 일종이라고 함. 소위 말하는 사회 연결망도 사회적 자본의 일종임

전문가는 사회적 자본과 사회적 기술 또한 뛰어남
뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간 안에 타인의 도움을 얻었음
뛰어난 소프트웨어 개발자일수록 타인과 인터렉션에 더 많은 시간을 쓰며,
초보 개발자들에게 조언을 할 때 사회적인 측면이 포함됨. 기술적인 조언만 하는 게 아니라는 뜻

이제는 프로그래밍을 잘한다는 정의 안에 의사소통 능력을 그 일부로 보게 된 것
사회적 자본과 기술이 없이 해당 도메인 지식만 높으면 해당 지식의 확산과 성공에 오히려 장애가 되기도 함

희망적인 소식은 이런 사회적 기술을 훈련으로 개선할 수 있다는 것
지금 당장 개인이 실천할 수 있는 간단한 방법은 주변 사람들과 매일 주고받는 마이크로 인터랙션에 신경을 쓰는 것
그걸 기록하고, 복기하고, 다르게 인터랙션한다고 하면 어떻게 했으면 좋았을까를 생각해 보는 것 만으로도 훈련이 될 수 있음

저자의 경험에서는 TDD 도입에 실패하는 경우, TDD를 도입하는 데에 필요한 사회적 자본과 ㅈ사회적 기술이 없어서가 훨씬 더 많았음
이 사실을 깨달은 이후로 어떤 기술적 지식을 전달한다고 해도 그것을 사회적 맥락 속에서 가르치고 경험하게 하려고 노력함
저자가 중요하게 다루는 사회적 기술은 도움받기, 피드백 주고받기, 영햑력 미치기, 가르치고 배우기, 위임하기 등이 있음

책 내용 중 새로운 기술을 조직에 도입하려고 했을 때 어려움을 겪는다는 사람이 있었는데, 이 분에게 저자가 던진 질문이 참 공감이 간다. “그 조직원들이 선생님을 좋아하나요?”

어디서 읽었는데 사람은 감정을 먼저 느낀 뒤에 이성적으로 판단한다고 한다. 그 사람이 느끼는 감정이 의사결정이 생각보다 많은 영향을 끼친다는 것이다. 지난 날의 나를 되돌아 보았을 때 내 경험과 유사했다. 최대한 선입견과 감정을 덜어내고 현상을 보려고 해도 그 것에 대해 선호가 있으면 판단하기 어려워졌다.

새로운 기술이든, 혁신적인 프로세스든 함께 잘 일하기 위해서 일텐데, 그것을 이루기 위해 사람을 배제하는 순간 도입이 실패하게 되는 것 같다.

---

두 번째 파트 '함께' 는 작성되면 맨 위에 링크해놓겠다.