Chapter 1 자라기
당신은 몇 년 차?
소프트웨어 시장에는 경력(연차)가 높은 사람이 고급 인력이라는 인식이 있습니다. 하지만 저자는 이를 부정하며, 오히려 연차를 기준으로 임금을 결정하는 방식이 관료주의적이며, 결과적으로 조직에 손해를 끼치는 방향이라는 점을 주장하려고 합니다.
존 헌터(John Hunter)는 채용시 고려하는 각 항목들과 실제 직무 수행간에 성과의 상관성을 측정하는 연구를 수행했습니다. 그 결과는
| 항목 |
상관성 |
| 경력 |
0.18 |
| 학력 |
0.10 |
| 필체 |
0.02 |
| 나이 |
-0.01 |
| 관심사 |
0.10 |
| 작업 샘플 테스트 |
0.54 |
| 아이큐 |
0.51 |
| 구조화된 인터뷰 |
0.51 |
| 성실성(성격테스트 기반) |
0.41 |
| 꼼꼼함(성격테스트 기반) |
0.31 |
으로 사실상 경력은 직무 수행능력과 연관성이 낮다는 결과가 나왔습니다. 물론 1~2년차의 경우에는 경력이 크리티컬한 상관성을 보여줬지만, 이는 단편적인 예시일 뿐입니다.
존 헌터의 연구는 소프트웨어 개발자를 대상으로 한 연구가 아닙니다. 하지만 톰 드마르코(Tom DeMarco), 티모시 리스터(Timothy Lister)의 연구 등에서 소프트웨어 개발의 경우에도 경력과 생산성은 아예 무관하다는 사실을 밝혔습니다. 반면 유의미한 상관성을 보인 항목이 있었는데, 이는 바로 개발자의 경험이 얼마나 폭넓고 다양했는지에 대한 것입니다. 이로서 경력의 양적인 면보다 질적인 면이 중요하다는 사실을 알게됩니다.
앞서 언급한 연구들은 '잘 뽑는법'에 관한 연구라면, '잘 키우는법'에 관한 연구에서는 업무 능력 향상에 투자한 시간 이 직무 성과와 유의미한 상관성을 보입니다. 이러한 꾸준한 공부는 IT분야와 같이 지식이 계속 업데이트 되는 경우라면 더더욱 큰 전문성의 성장을 이끌어냅니다. 회사 입장에서는 이러한 성장을 위한 시스템을 잘 구축하는 것이 회사와 개발자 모두에게 윈윈하는 방식입니다.
개발자가 성장(경력이 아닌 실력)을 위해서 할 일은 의도적인 수련 입니다. 하지만 업무를 하는동안에 의도적인 수련은 쉽지 않습니다. 이를 도와줄 수 있는 방법이 바로 피드백을 짧은 주기로, 교정할 기회가 있게 얻는 것 입니다. 이를 위해서 각 판단과 상황을 관찰한 결과를 기록해두고 후에 피드백하더라도, 판단의 이유를 명백하게 기억할 수 있도록 하는 것이 중요합니다.
여기서 하고싶은 말은 연차만으로 좋은 개발자가 될 수 없다! 좋은 개발자가 되기 위해서는 의도적인 수련을 꾸준히, 열심히 해라! 였습니다. 의도적인 수련을 위한 팁으로 꼼꼼한 기록을 통한 피드백과 교정을 언급했습니다. 이러한 방식으로 절차적 지식을 축적하고, 수정 할 수 있도록 하는 것입니다.
자기계발은 복리로 돌아온다
잡코리아의 설문에 따르면 하루의 1~2시간 이상을 자기계발에 투자하는 직장인이 3/2이상입니다. 이정도는 기본이라는 것이지요. 게다가 지식이나 능력은 복리로 이자가 붙기 때문에 더욱 노력해야합니다. 따라서 더 빨리 자라고 싶다면 이율을 높히는 법, 지속적으로 현명한 투자를 하는법 을 고민해야 합니다.
저자는 더글라스 앵겔바트(Douglas Engelbart)의 작업 구분방식을 인용합니다.
A : 제작, 개발, 생산, 판매 등과 같이 표면적이고 직접적인 성과를 내는 작업
B : A를 가능케 하는 시스템/프로세스를 설계하는것(A를 개선하는 것)
C : 사고방식과 상호 작용 방식을 개선하는 것(B를 개선하는 것)
이러한 구분 방식 중에서 B와 C 작업에 투자하는 비율을 늘리는 것을 복리로 성장하는 방식이라고 합니다. 즉, 어떻게 하면 더하기가 아닌 곱하기를 할 수 있을지, 어떻게 하면 곱하기의 비율을 높일 수 있을지를 고민하는 것입니다.
저자의 복리성장을 위한 방식은 치열한 성장을 위한 전략입니다. 저의 학창시절 공부법과 시간관리에 대해서 열심히 찾아봤던 기억이 떠오르네요. 그러한 노력덕분에 투자한 시간 대비 좋은 성적이 나왔던 것 같습니다. 하지만 절대적인 시간의 차이는 극복하지 못했지만요. 최근 인간공학(인지공학)이라는 과목을 공부하면서 이와 관련된 내용을 배웠습니다. 그런 지식들을 잘 활용해서 정리하고 활용해 나가는 것이 저의 성장에 큰 영향을 미치겠지요. 이에 대해서는 다른 포스팅에 꾸준하게 정리해나가겠습니다.
학습 프레임과 실행 프레임
저자는 실행프레임(주어진 과업을 이루어야할 성과로 여기는 생각)과 학습프레임(주어진 과업을 배울 경험으로 여기는 생각)에 관한 이야기를 합니다. 당연히 학습프레임이 실행프레임보다 큰 성장을 이루어 냅니다. 하지만 현실은 녹록치 않을 수 있습니다. 업무하면서 학습이 중요하다는 생각을 가지는 것은 어렵습니다. 이에대해 저자는 1년차 개발자 2명을 비교함으로서 답변합니다. 1년밖에 되지 않아서 책만보고 선임들에게 도움을 요청하지 않는 주니어가 있는가 하면, 1년밖에 되지 않아서 선임들에게 도움을 요청하고, 때로는 도움을 주는 주니어가 있었습니다. 결국 시각차이입니다.
저는 어릴적 자기개발서를 읽는 것을 좋아했습니다. 하지만 나이가 들어가면서 자기개발서가 뻔해지고, 지루해졌죠. 이제는 뻔한 문제를 새롭게 접근하는 자기개발서를 더 선호합니다. 이번 챕터는 오만한 제 생각을 부숴주는 글이었습니다. '매사에 배우는 자세로 임해라'와 같은 뻔한 말들은 이미 졸업한지 오래라고 생각했습니다. 하지만 머리로만 알고있는 이런 지식을 저는 전혀 실천하지 않고 있었습니다. 당연히 배워야겠죠. 당연히 성장해합니다. 뻔한말로 잘난척할 생각은 그만 버리고 몸으로 움직여야할 때 입니다.
가장 학습하기 힘든 직업이 살아남는다
인공지능의 등장은 우리의 방향을 고민하게 합니다. 언젠가 대체될 지도 모르는 능력을 키우는 것은 의미 없는 행위가 될 수도 있으니까요. 저자는 인공지능 시스템에 비해 인간이 유리한 영역을 '암묵지', '직관'이 작동하는 회색 영역이라고 언급합니다.
저자는 컴퓨터로 대체되기 힘든 변수 중에 5가지의 카테고리를 추립니다.
- 독창성 : 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법들을 만들어내기
- 사회적 민감성 : 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
- 협상 : 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
- 설득 : 다른 사람들이 마음이나 행동을 바꾸게 설득하기
- 타인을 돕고 돌보기: 개인적인 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것
이러한 기준에서 우리는 컴퓨터로 대체되기 힘든 변수에 해당하는 능력을 키워야 합니다. 이런 업무를 수행하는 개발자를 프로그래머 가 아니라 소프트웨어 개발자 라고 이야기합니다. 소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많습니다. 앞서 이야기한 독창성, 협상, 설득 등에서 차이가 나는 것입니다.
개발공부를 하면서 자주 듣던 이야기가 코드몽키가 되어서는 안된다 는 것이었습니다. 또한 김범준의장님(배달의 민족)은 개발자란 비지니스 벨류를 만들어 내는 사람이다 라고 말했습니다. 앞서 언급한 내용들과 일맥상통하는 이야기입니다. 이 책이 쓰여진 시점에는 없었지만, 지금은 자동으로 프로그래밍을 해주는 서비스까지 나왔습니다. 아직까지는 여러 이슈가 남아있지만 이러한 서비스들이 상용화 되는 것도 조만간일 것입니다. 제가 어떤 방향으로 나아가야할지는 명확합니다. 대체불가능한 개발자가 되자!
달인이 되는 비결
달인이 되는 비결은 꾸준히 반복하되, 실력을 개선하려는 동기 가 있어야하고 구체적인 피드백을 적절한 시기 에 받아야 합니다.
수십 년 동안 전문가가 안 되는 비결
논문<Conditions for intuitive expertise>에 의하면 전문가의 믿을 수 있는 직관이 형성되려면 타당성 과 피드백 이 필요합니다. 즉, 예측할 수 있는 일정한 규칙(타당성)과 즉각적이고 명확한 결과(피드백)이 필요하다는 것입니다. 하지만 소프트웨어 개발의 경우는 타당성도 낮고 피드백도 낮은 편입니다. 따라서 타당성을 높이기 위해 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려고 노력해야하며, 주변사람들에게 피드백을 적극적으로 구해야합니다.
당신이 제자리걸음인 이유
실력을 높히기 위해서는 의도적 수련이 필요하고, 특히 의도적 수련을 질적으로 발전시키 위해서 동기와 피드백이 필요하다고 언급했습니다. 저자는 이에 추가적으로 적절한 난이도가 필요하다고 말합니다. 이는 미하이 칙센트미하이의 몰입이론과 일치하는 부분입니다. 미하이는 작업 난이도와 실력이 비슷한 부분에서 몰입을 경험하고, 최고 수준의 집중력을 보이며, 학습능력과 퍼포먼스가 최대치가 된다고 이야기합니다. 만약 작업 난이도보다 실력이 뛰어나면 지루함을 느낄 것이고, 작업 난이도보다 실력이 저조하면 불안감을 느낄 것입니다. 둘다 바람직한 상태는 아닙니다. 따라서 우리는 지루하거나 불안한 상황일 때 몰입하는 상황으로 우리의 상태를 이동시킬 필요가 있습니다. 지루할 때는 작업 난이도를 높히거나(추가적인 작업 수행하기/요구 수준 높히기, ex 자동화 테스트 만들기/요청을 100개 처리하는 환경 구축 -> 1000개 처리하는 환경 구축) 실력을 낮추는 방법(제약조건 달기, ex 디버거 안쓰기)으로 몰입 상태로 이동하고, 불안할 때는 작업 난이도를 낮추거나(작업 분할하기, ex 테트리스 만들기 -> 화면 가운데 사각형 그리기) 실력을 높혀서(전문가의 도움/도구 활용/비슷한 경험 복기, ex 페어프로그래밍/괜찮은 디버거 사용) 몰입 상태로 이동합니다. 이렇듯 몰입상태를 유지하는 것은 성장과 생산성 향상에 매우 중요한 요소인데 이를 잘 수행하기 위해서는 본인이 어떤 상태인지 아는 메타인지 가 중요합니다. 이를 위해서 계속해서 본인의 상태를 체크하는 활동이 필요합니다.
적절한 난이도 설정은 개인의 성장에도 중요한 요소이지만, 팀장으로서 팀원들에게 적절한 난이도를 설정해 주는 것도 중요합니다.
의도적 수련의 일상적 에시
프로그래밍 언어 배우기의 달인
전문성에 따라서 업무의 성과는 극명하게 나뉩니다. 미군에서 개발한 지뢰탐지기는 탐지율이 일반군인 10%, 전문가 90%로 80%나 차이가 나기도 했죠. 이러한 전문가의 방법을 배우려면 작업분석 이라는 기법을 활용해서 기술을 뽑아내기도 합니다. 그 방법은 전문가에게 구체적인 사건에 대해 말하도록 유도하는 것 입니다. 예컨데 유명한 개발자에게 언어를 습득하는 방법을 뽑아내기 위해 최근 언어 학습 경험을 물어보는 것이죠. 아래에서는 저자가 개발자에게 전문성을 뽑아낸 과정을 서술합니다.
첫째로, 이 전문가는 해당언어(Go)의 튜토리얼을 읽으면서 어떤 것을 만들고싶은지(단어 갯수 세기 프로그램) 고려하면서 튜토리얼을 읽는다고 합니다. 그리고 만들고 싶은 프로그램을 만들 수준이 되면 튜토리얼을 멈추고 해당 프로그램을 구현하고 다시 튜토리얼을 읽습니다.
둘째로, 이 전문가는 표준 라이브러리 소스코드를 읽습니다. 언어를 배운다는 것은 문법과 키워드를 익히는 것이 아니라 코드 스타일을 익히는 것이라고 생각하기 때문이죠. 이러한 관점에서 언어를 배우기위해 가장 효과적인 교보재는 해당 언어의 표준 라이브러리가 작성된 방식입니다. 즉 전문가는 튜토리얼을 공부하는 것 만으로는 그 언어의 숙어와 패턴, 스타일을 배우기 불충분하다는 것을 알고 있는 것이죠.
셋째로, 다른 사람의 코드에 내가 필요한 기능을 추가합니다. 실제로 해당언어로 구현된 오픈소스를 다운받아서 새 기능을 추가했습니다. 이때 전문가는 아주 작은 기능 하나를 추가합니다. 이러한 방식으로 실제 코드의 감(읽고 쓰기)를 익히는 것입니다. 게다가 피드백은 덤이죠.
첫번째 방법은 적극적 읽기로, 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법을 말합니다. 죽은 공부를 하지말고 적극적으로 질문을 던지고 목적을 가지고 공부하라는 것이죠.
실수는 예방하는 것이 아니라 관리하는 것이다
실수를 대하는 문화는 크게 두가지가 있습니다. '실수 예방', '실수 관리'. 실수 예방은 실수를 저지르지 말라고 요구합니다. 따라서 실수한사람을 비난하고, 처벌하고, 당사자는 실수를 감추게 됩니다. 하지만 실수 관리는 실수가 더 나쁜 결과를 내기전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수를 통해 배우는 분위기입니다. 비용측면에서도 실수관리 문화가 수익성이 높습니다. 그 이유는 실수를 통해 학습해야만 실수를 줄일 수 있기 때문입니다. 개인의 실수를 비난하고 예방하기만 한다면 결국 실수한 경험이 공유되지 못하고, 더욱이 이를통해 무엇인가를 배울 수도 없습니다.
나의 실수를 대처하는 방식은 극명하게 실수예방 이었습니다. 실수가 발생하더라도 수습하기 바쁘고, 없었던 일처럼 지나가게 하기위해서 노력헀죠. 우리학교 교수님께서 디자인띵킹에 대해서 강의하실때도 유의미한 실패를 반복하라고 이야기 하곤 하셨습니다. 이런 이야기들이 같은 맥락에서 있는 것 같Chapter 1 자라기습니다. 실패,실수를 적극적으로 활용하고 관리하도록 합시다. 저자의 홈페이지에 있는 실수노트를 작성하는 것도 좋은 방법같습니다.
실수 노트 양식은 다음을 참고로 합니다.
제목 : 이 실수에 기억하기 좋은 이름을 붙입니다.
관련인 : 해당 실수에 관련있는(결과에 영향을 주거나 받거나) 사람들을 적습니다
타임라인 : 가로로 수평선을 그리고 어느 시점에 실수가 발생했고, 언제 최초 감지 되었고, 언제 최초 회복 작업을 시작했는지 표시합니다. 그 외에 중요 한 사건들이 있으면 역시 표시합니다.
실수 시점 분석: 실수 시점에 대한 자세한 설명입니다. 구체적으로 실수가 무엇이었는지. 원래는 뭘 했어야, 혹은 안했어야 했는지를 적고, 왜 그런 실수가 일어났는지 적습니다.
감지(detect) : 무엇을 보거나 듣고 처음 실수를 감지했는지. 그리고 당시에 어떤 (부정적) 미래가 펼쳐지리라 추측했는지.
회복(recover) : 회복을 위해 무엇을 했는지. 당시 다른 옵션은 무엇이 있었는지. 왜 그 옵션을 선택했는지.
결과 : 그 후에 결과적으로 어떻게 되었나.
교훈 : 다음번에 비슷한 실수를 어떻게 더 빨리 감지할 수 있을지, 어떻게 더 빨리 회복할 수 있을지, 혹은 실수 발생 전 시점의 행동 자체를 어떻게 교정하면 좋을지.
작가 홈페이지
뛰어난 선생에 대한 미신
이제껏 학습의 중요성과 조건 등을 살펴봤습니다. 이 글과 다음 글에는 배워도 별로 효과를 보지 못하는 경우를 알아봅니다.
뛰어난 선생은 많이 알고있는 사람이 아닙니다. 본인의 지식이 익숙해지면서 암묵화 되는 경우가 있기 때문이죠. 실례로 의사가 간단한 수술법을 가르칠 때도 성공적으로 수술을 진행하기 위한 지식의 30%만 가르치고 있다는 연구가 존재합니다. 이러한 현상을 극복하기 위한 방법은 학생과 선생이 인지적 작업 분석 같은 방법을 사용해 보는 것입니다. 학생의 경우 자신과 학생에 대한 분석을 잘하는 선생을 고르는 것이 유리한 전략일 것입니다.
나홀로 전문가에 대한 미신
어떤 기술적 실천 법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요 합니다. 예컨데 상사가 내가 하는 일을 보고 반대하면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하니까요. 세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없습니다.
존 가트맨은 자신의 책 신뢰의 과학에서 신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 연구를 언급합니다. 직장에서도 비슷합니다. 팀장이 선의로 책을 선물해도 팀원들은 '나 보고 이런 거 모르니 공부하라는 얘기야? 지는 뭘한다고..'와 같이 생각할 수 있는 것이죠. 이러한 신뢰를 사회적 자본이라고 합니다. 사회적 자본이 좋은사람은 사회적 기술이 일반적으로 뛰어납니다.
전문가는 도메인지식 뿐만이 아니라 사회적 자본과 기술도 뛰어납니다. 벨 연구소는 뛰어난 연구자의 결정적인 특징은 사회적 자본, 특히 소셜 네트워크의 차이였습니다. 뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간에 타인의 도움을 얻었습니다. 개발자의 경우도 다르지 않습니다. 시니어 개발자에게 초보개발자에게 해줄 조언을 적어보라 했을 때, 뛰어난 개발자들의 70%는 동료와의 협력을 언급하는 반면 실력이 그저그런 개발자들은 20%만 동료와의 협력을 언급했습니다.
그럼 사회적 기술을 키우기 위해선 어떤 방법이 있을까요? 기본적으로 일상에서 하는 인사, 대화, 질문 등에 신경쓰면서 이를 기록하고, 복기하고, 다른 인터랙션을 가정해 보는 것 만으로도 도움이 될 수 있습니다.
취직이 다가올 수록 사회적 기술을 등한시 하게 되는 것 같습니다. 지금 급한건 코딩테스트, 개발능력이라고 느껴지기 때문이겠죠. 하지만 저자는 제게 그렇지 않다고 이야기하고 있습니다. '세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없다고'.
