어떻게 해야 성장할 수 있을까
왜 나는 공부하는데 제자리인걸까?
성장에 목말라 있는 개발자들은 항상 고민한다. 어떻게 해야 성장할 수 있을까? 어떻게 해야 폭발적으로 효과적으로 성장할 수 있을까? 어떻게 하면 효율적으로 전문적인 개발자가 될 수 있을까?
자동적으로 획득되는 것은 없다. 개선하기 위해서는 의도적으로 행동해야 한다. 업무량을 제외하고 의도적으로 수련하는 시간이 필요하다.
세계적인 프로 운동선수들을 보면 실제 경기를 한 시간보다 그 경기를 위해 연습하는 시간이 몇 배는 많다. 경기를 뛰는 와중에도 연습이 되고 경험이 쌓이겠지만, 그 경기를 위한 연습이 충분히 뒷받침돼야 폭발적인 성장의 시너지가 발휘된다.
그렇다면, 무작정 학습하면 될까? 아니다. 몇 년 전 유명했던 1만 시간의 법칙을 기억하는가? 여기에는 간과하면 안 되는 사실이 있다. 많은 사람들은 대부분 그냥 1만 시간을 보낸다는 것이다. 1만 시간을 채웠다고 해서 전문가가 될 수 없다.
구현 실력과 시간은 상관없다. 경력과 실력은 상관관계가 없다. 경력이 20년이라고 해서 1년 차 수준의 지식을 20년 한 사람과 경력이 3년이지만 의도적 수련을 통해 깊이 학습한 사람이 있다고 하자. 경력 20년 차 개발자가 더 실력자라고 할 수 있을까?
일반적 연습과 의도적 수련은 다르다. 의도적 수련이란 약한 부분을 집중적으로 연습하는 것이다. 세계적으로 유명한 프로 선수들은 자기가 약하고 잘 못하는 부분을 수련한다. 약점을 보완하는 것이다. 그러나 일반 선수들은 자기가 잘하는 것만 수련한다. 자기가 잘하는 것만 수련한다면 발전이 아니라 머무르게 된다.
그렇다면 의도적 수련은 어떻게 하는 것인가?
의도적 수련은 아무거나 막하는 것이 아니라 수련하기 위해 어떤 것을 할 것인지 잘 정의 해야한다. 4가지 항목이 적절히 갖춰져야 한다.
- 잘 정의된 작업(well defined task)
- 적절한 난이도 (appropriate difficulty)
- 정보가 풍부한 피드백 (informative feedback)
- 반복과 실수 교정의 기회 (opportunities for repetition and correction of errors)
잘 정의된 작업
어떤 것을 수련할 지 구체적으로 동사형태로 구체적으로 적어야한다. 막연하게 적으면 안된다.
예시
- 트위터, 인스타그램 클론 코딩해야지 (X)
-
트래픽이 이정도일 때, 서비스를 안정적으로 유지하기 위해 부하테스트를 해봐야지 (O)
- 디자인 패턴에 대해 책을 읽고 공부해야지 (x)
-
디자인 패턴에서 나온 전략 패턴을 실제 코드에 적용해봐야지(o)
- aws가 뭔지 알아봐야지 (x)
- aws ec2를 이용해서 서버를 띄우고 배포 자동화를 해봐야지(o)
이렇듯 구체적으로 어떤 행동이나 과정으로 결과가 나오는 목표를 설정해야한다.
적절한 난이도
적절한 난이도도 무척 중요하다. 엄청 쉬운 문제는 도움이 되지 않는다. 너무 쉬운 문제는 지루함을 유발하고 더 이상 공부하지 않아도 된다는 이만하면 됐다는 위안을 삼게 된다. 반대로 너무 어려운 문제 또한 도움이 되지 않는다. 쉽게 지치고 포기하게 된다.
그래서 메타인지가 중요하다. 나의 상태가 나의 수준이 어느 정도인지 파악하고 적절한 난이도를 부여해야 한다. 쉽지 않다. 쉽게 하는 방법은 없을까?
익숙한 언어로 새로운 문제를 푼다. 또는 새로운 언어로 익숙한 문제를 푼다. 문제가 쉬우면 어렵게 만들어서 공부하고, 문제가 어렵다면 쉽게 만들어서 공부해야 한다. 너무 추상적인가? IDE나 라이브러리 도움으로 쉽게 구현했던 기능을 이번에는 라이브러리를 이용하지 않고 구현하는 등의 방법이 있다.
또, 한 번에 높은 난이도를 학습하는 것보다는 점진적으로 학습하는 것이 더 빠르게 학습할 수 있다. 예를 들어, 매일 한 번에 5km 달리기를 연습하는 것보다는 매일 2km 달리기를 연습하고 수월해지면 5km 달리기를 하는 것이 능숙해지는데 더 빠르다.
정보가 풍부한 피드백
피드백은 중요하다. 잘하고 있는지, 잘못하고 있다면 어떻게 개선해야 하는지 피드백이 있어야 한다. 코드 리뷰가 한 달 뒤에 달린다면? 작성한 사람에게 도움이 될까? 운동선수가 폼을 봐달라고 피드백을 요청했는데, 한 달 뒤에 피드백이 온다면 그 피드백은 유효한가? 아니다. 피드백은 짧은 시간 내에 이뤄져야 한다.
이 부분에서 좋은 학습 방법에는 짝 프로그래밍이 있다. 짝 프로그래밍이라고 무조건적으로 좋은 것은 아니다. 효과적인 짝 프로그래밍은 어떻게 해야 하는가?
짝 프로그래밍
짝 프로그래밍은 짧은 텀을 두고 돌아가며 해야 한다. 실력자와 한다면 암묵지를 배울 수 있다. 또 버그를 줄이는 효과도 있다 짝 프로그래밍 시 실력 차이가 클 때 주의해야 하는 것은 잘하는 사람이 주도하면 안 된다. 키보드를 뺏어도 안된다. 잘하는 사람이 주도하면 둘 다 지친다. 잘하는 사람은 강의 형식이 되기 때문에 지치고, 따라가는 사람은 알아듣기 힘들다.
3~5분 간격으로 키보드를 주고받으며 프로그래밍을 한다. 더 잘하는 사람은 설명을 하지 않는다. 상대적으로 못하는 사람 차례에서 자세히 설명해 줄 수 있다. 짝 프로그래밍 전에 미리 밑그림을 그리면 비전문가가 따라가기 쉽다. 큰 그림을 머릿속에 가질 수 있다.
반복과 실수 교정의 기회
다양한 문제집을 3권 푸느니 같은 문제집을 3번 푸는 게 낫다. 같은 걸 다르게 같은 맥락에서 여러 번, 조금씩 개선하고 실수도 많이 해봐야 한다.
비효과적인 학습법 & 효과적인 학습법
비효과적인 학습법에는 깜지, 밑줄 치기 등이 있다. 같은 자료를 너무 짧은 텀으로 반복적으로 읽는 것도 학습 효과가 떨어진다. 그렇다면, 효과적인 학습법은 무엇일까? 왜 그런지 질문하고 답해야 한다. 같은 문제를 계속 푸는 것이 아니라 살짝 식 변경을 가하는 것도 효과가 좋다. 사람의 집중력은 길지 않다. 한 가지 과목만 공부하면 초반에는 집중력이 높지만 2~3시간 아니 1시간만 지나도 급격히 효율이 떨어지는 것을 경험해 봤을 것이다. 그럴 때, 다른 과목으로 환기를 시켜줘야 한다. 프로그래밍 공부도 마찬가지다. 자바만 미친 듯이 4개월 공부하고 그다음 네트워크 4개월 공부하면 자바 공부한 거는 이미 머릿속에서 휘발되어 많이 사라졌을 것이다.
또, 좋은 학습법에는 시험 보기가 있다. 단순히 책을 읽는 행위는 많은 착각을 불러일으킨다. 내가 이 책 내용을 다 알고 있다는 착각에 빠뜨린다. 시험 본다는 생각이 머릿속에 있으면 단순히 책을 읽는 것으로 끝나는 게 아니라, 왜 이렇게 되는지 이해를 하려 하고 암기를 하게 된다. 책을 눈으로 읽는 게 아니라 머리로 읽게 된다. 이 또한 분량이 중요하다. 공부 중간중간시험을 봐주는 것이 더 효과적이다.
현실
실질적으로 프로그래머들의 일주일간 공부하는 시간은 일주일에 10시간 미만이다. 이 시간에 대부분이 책 읽기와 강의 듣기다. 반대로 사람들이 가장 투자를 적게 한 학습에는 1시간도 학습하지 않았다. 또 경력이 높을수록 학습을 게을리한다.
- 이미 개발한 프로그램을 더 잘 만들 요량으로 다른 방법으로 처음부터 다시 개발해 보기
- 이미 개발했고, 기능상 문제가 없지만 리팩터링 등을 통해 코드 구조를 더 개선하거나, 성능상 문제가 없으나 자신만의 더 나은 성능기준을 목표로 개선하기
- 반복되는 작업을 자동화해서 거기에 드는 시간과 노력, 실수여지를 줄이기
위와 같은 의도적 수련은 실제로 일주일에 1시간도 하지 않는다. 왜? 실수와 다른 사람의 비난, 고정적 사고관에 갇혀 있을수록 의도적 수련을 하지 못한다.
평소 나는 어떤 학습을 하고 있는지 생각해 보자. 일주일 동안 업무 외 학습시간에서 의도적 수련을 한 시간이 얼마인가? 의도적 수련을 하기 위해 나는 무엇을 하고 있는가? 고민해 보자
의도적 수련 그거 어떻게 하는 건데???? -> 코드숨에서 경험하세요
나는 의도적 수련을 하고 있는가? 어떻게?
책을 읽는다는 게 큰 성장률을 보여주지 않는다는 것을 안다. 다 읽고 조금만 지나면 다 안다고 생각했던 내용들이 모래알을 손에 쥔 듯 다 빠져나간다. 그래서, 스터디나 같이 읽기 등을 할 때 최대한 지금 업무에 적용할 수 있는 혹은 당장 실행해 볼 수 있는 것들에 대한 내용의 책을 선정한다. 책을 읽을 때, 읽고 끝나는 것이 아니라 왜?라는 질문을 적는다. 그리고 그 왜라는 질문에 답을 하기 위해 또 다른 학습을 한다. 책을 읽다 보면 모르는 내용이나 개념들이 나온다. 구글링을 해보면 대부분 그냥 책의 내용을 복사 붙여넣기 한 요약 글들이 많다. 단순 요약과 깜지와 같은 것들은 효과가 크지 않다. 그래서 요즘 시도하고 있는 스터디 공부법은 책을 읽을 때 생기는 의문을 적는다. 질문을 스터디원들과 공유하고 같이 해답을 찾는다. 그 해답을 정리해서 공유한다. 더 나아가서 실제 적용할 수 있는 부분이 있는지 찾고 있다면 적용한다.
관계형 데이터베이스 실전 입문 스터디를 할 때도, 책에 나온 내용을 그대로 받아들이는 것이 아니라 저자는 왜? 이렇게 설명했을까? 이 내용은 어떻게? 이렇게 되는 것이지?라는 질문을 머릿속에서 답하며 학습하고, 실무에서 적용할 수 있는 부분들은 실제로 적용했다.
현재 진행 중인 [모던 자바 인 액션] 스터디도 당연하게 넘어갈 법한 내용들에도 의문을 품으며 다소 불친절한 설명에는 “왜 이렇다는 거지?”라는 질문을 하고, 함께 고민하며 설명을 덧붙이고 있다.
또, 사이드 프로젝트를 기획, 설계, 진행하면서 코드 리뷰, 짝 프로그래밍 등을 진행하고 있다. 적절한 피드백을 주고받으면서 당연하게 작성하던 코드가 이유 있는 코드로 변해감을 느끼고 있다. 나는 성장하고 있고, 더 성장하기 위해 꾸준히 노력한다.
위 내용은 코드숨에서 프로그래밍 심리학 회고 시간에 공유 내용을 토대로 저의 개인적인 의견을 첨가하여 작성하였습니다.
반박 시, 코드숨으로 오세요~ 