모든 개발자가 읽어야할 책이 있을까?
개발 분야는 다채롭고, 개발자의 경력과 실력에 따라 필요한 책이 다르기에
'예'라고 말하기는 어렵다. 하지만 모든 개발자에게 권할 만한 책이 나왔다.
바로 '프로그래머의 뇌'이다.
뇌와 프로그래밍의 관계, 우리가 코딩을 하고 디버깅을 할때 두뇌에서 무슨 일이 일어나는지 적은 거의 유일한 책이다. 왜 어떤 코딩은 더 어렵고 어떤 코딩은 더 쉬운가와 같은 개발자가 항상 마주치는 의문을 이 책은 해소해준다.
책 내용 중 버릴 게 없어 전부 다 인용하고 싶을 정도지만 공간이 협소하니
책에 적힌 각종 과학적 사실, 코딩 테크닉 중 경험한 부분을 바탕으로 책을 읽은 후기를 적어보려고 한다.책에 설명된 뇌 관련 내용 중 중요한 것만 짧게 적어보겠다. 뒷내용을 이해하기 위해 필요하다.
0. 간단한 뇌 구조 설명
우리 뇌에는 크게 3가지 기억이 있다.
a.장기 기억(Long term memory, LTM )
b.단기 기억 (Short term memory, STM )
c.작업 기억 (Working memory )
'장기 기억'은 우리 두뇌 깊숙이 저장되어 있는 기억이다. 초등학교때 배웠던 것이나, 계속해서 반복적으로 배운 것들이 주로 장기기억에 저장이 된다.
'단기 기억'은 잠깐 기억할 필요가 있는 것을 말한다. 처음 듣는 전화번호나 처음 만나는 사람의 이름 같이 짧게 기억하는 정보가 단기 기억이다.
'작업 기억'은 어떠한 일을 하기 위해서 임시로 기억을 하는 것을 말한다. 뇌의 메모장이라고 보면 된다. 함수를 만들때 함수 이름을 기억하는 것 같은게 작업 기억이 하는 일이다.
'작업 기억'과 '단기 기억'은 헷갈릴 수 있다. 똑같이 숫자를 기억하는 상황을 떠올려보자. '단기기억'은 '010-123-4567' 처럼 단순히 전화번호를 기억하는 것이고, '작업기억'은 '456 + 23 - 85 + 1200'같은 숫자계산을 하기 위해 기억하는 걸 말한다.
전화번호를 기억할때는 숫자만 차례대로 기억하면 되지만, 숫자 계산을 할때는 앞의 숫자와 뒤의 숫자가 어떻게 변하는지를 다 기억하고 있어야한다.
한마디로 작업기억이 할일이 더 많은 셈이다. '단기기억'과 '작업기억'은 둘 다 잠시 기억한다는 공통점이 있는데 이에 반해 '장기 기억'은 자고 나서, 며칠이나 몇달 뒤에도 기억하는 걸 말한다.
우리가 어떤 문제를 해결할때는 3가지를 다 쓰게 되는데 보통 '장기 기억'을 먼저 확인하고 그 다음에 '단기 기억'을 본 뒤 필요할때 '작업 기억'을 활용하게 된다. '작업기억'을 쓰는 건 상당한 에너지가 필요하기 때문이다.
가장 중요한 기억이 어떻게 분류 되는지 알았으니 책에 나온 방법을 일부 적어보겠다. 책내용 요약과 경험담이 섞여있다.여기 적힌건 내용의 1/10도 안되니 꼭 책을 구해서 읽어보기를 바란다. 그럴만한 가치가 있다.
1.간단한 문법부터 외우며 수련하라
책에서는 상당수 개발자가 검색을 하면서 시간을 보낸다고 말한다. 이는 얼핏 보기에는 아무것도 아닌 것 같지만 상당히 비효율적이다.
검색하는 데 작게 나마 시간이 들뿐더러, 뇌의 작업기억에 부하를 주기 때문이다.
뇌가 쓸 수 있는 에너지는 한정적인데 장기 기억을 쓰는데는 별로 에너지가 안 들고
단기 기억은 적게 들고 작업 기억은 많이 든다.
작업 기억이 많이 필요한 일일수록, 두뇌가 다른 일을 하지 못한다. 문법이나 기초적인 기능을 머리에 담고 있느라 막상 중요한 문제를 해결하지 못하는 셈이다. 이렇기에 기본적인 문법이나 사용중인 프레임워크에서 자주 쓰는 기능은 외워버리는 게 좋다. 두뇌의 남는 에너지를 문제 풀이나 기능 개발에 쓸 수 있게 되기 때문이다.
원래 나는 개발 문법 정도는 다 외웠지만 특별히 프레임워크의 기능 같은 걸 외우지는 않았다. 그러나 코딩 과외를 하게 되면서 라이브 코딩을 2-3시간은 해야되었고, 어떤 질문이 나올지 몰라 문법과 프레임워크의 기능을 외워서 갔다. 그런데 이상하게도 수업을 하면 할수록, 원래 본업으로 돌아와 개발을 하는 시간이 단축되었고 디버깅이 잘 되었다. 추측건데 단기기억에 머물렀던 문법들이 장기기억으로 넘어가면서 두뇌가 더 편하게 코딩을 할 수 있게 되었던 걸로 보인다. 남을 가르치다보면은 실력이 는다고 하는데 이런 원리이기 때문인걸로 보인다.
2.두뇌는 개발툴의 온갖것을 다 참고해서 코드를 기억한다
두뇌는 코드를 기억할때 코드만 기억하지 않는다. 개발툴의 화면 구조나 색깔 등도 참고한다는 뜻이다.비주얼 스튜디오, 이클립스, XCode 같은 개발 툴을 쓰다보면 함수나 클래스, 폴더 등의 색이 다르다. 뇌는 이런 색, 구조도 같이 기억해두었다가 코드를 찾을때 활용한다. 장기기억이 작업의 환경까지도 기억하는 셈이다.
fun add() {
var age = 35;
}위와 같은 함수가 있다면 'fun'과 'add'를 읽고 무슨 함수일거라고 추측하는 게 아니라 'fun'과 'add'의 색깔을 보고 추측한다는 소리다. 노란색이면 변수고, 파란색이면 함수구나라고 두뇌에서 미루어 짐작하는 것이다. 평소 쓰던 개발툴이 아니라 다른 개발툴로 넘어가면 생산성이 급감하는데는 단순히 단축키가 달라서만은 아닌 것이다. 또한 상당수 개발자가 '종이, 화이트 보드에 코딩'을 하면 실력이 확 줄어드는 이유를 알 수 있다. 평상시 코딩 참고했던 것들이 화이트보드에는 없기 때문이다. 아마도 장기기억에 색깔 같은 것도 들어있는게 아닐까.
실제로 개발툴을 바꾸면은 생산성이 떨어지는 경우가 많고, 개발툴의 테마를 바꾸면 이상하게 느려진듯한 느낌을 받곤 했는데 이때문인 걸로 보인다.
3. 새로운 개발자는 왜 느리게 개발할까? 개발자 끼리도 서로 알고 있는 것에 대한 착각과 오해가 많다.
새로 개발자가 팀에 합류하게 되면 기존의 코드에 대한 정보가 0인 상태이다. 반면 기존 개발자는 기존 코드를 대부분 파악하고 있다. 새로운 개발자가 아는 게 0이라면, 기존 개발자는 10,000정도 안다고 보면 된다. 새로운 개발자는 함수간의 연관 관계나 클래스는 어떤 식으로 구성되어 있는지, 어떤 식으로 개발을 해나갔는지를 모른다. 기능 추가 하는데도 상당히 오래걸린다. 새회사에서 1-2주는 코드 파악하느라 바쁘다. 기존 개발자는 어떤 함수가 어떻게 돌아가는지, 환경 세팅은 어떻게 하는지 알고 있기에 기능 추가하는데 오래 걸리지 않는다. 기존 개발자는 새로운 개발자가 버벅이는 모습을 보고 능력이 부족하다고 생각한다.
"나는 기능 추가하는데 3일이면 되는데, 새로운 친구는 2주나 걸리네, 실력이 없구만."
이는 일반적인 개발회사에서 벌어지는 일이다. 실제 개발 능력은 비슷할 수 있지만 새로 들어온 개발자는 작업해야될 코드에 대한 지식이 없다. 반면 기존 개발자는 변수 이름, 폴더 구조, 코드들이 어떻게 연결되어 있는지 등에 대한 지식이 장기 기억에 들어 있다. 지식 차이를 인식하지 못하기에 오해가 생기는 셈이다.
이런 오해를 줄이는 방법이 있다. 일반적으로 많이 쓰는 아키텍처를 사용해서 새로운 개발자가 학습하는데 걸리는 시간을 줄이면 된다. 디자인 패턴이나 일반적인 아키텍처를 쓰는 경우 코드 수정을 하는데 시간이 적게 들었다고 한다. 또 새로운 코드에 빨리 적응할 수 있게 코드 구조를 다룬 문서나 작업 기록을 공유할 필요가 있다. 일정 시간 기다리는 건 필수이다. 참고로 IT 선진국인 미국도 1/3 가량 회사가 '신규 개발자 적응 과정'이 없다고 한다. 우리나라에서는 더 적은수만이 적응과정이 있지 않을까. 이런 걸 보면 구글이 오픈소스를 많이 하는게 미리 구글 스타일 코드를 잘 아는 사람을 늘리기 위해서는 아닐까 하는 생각이 문득 든다.
4.함수, 클래스 이름 등을 보며 어떤 기능인지 추측을 한다.
못 보던 변수, 함수나 클래스를 보면 그 이름을 읽으며 얘가 어떤 기능이겠구나 예상을 한다.경험이 쌓이면 코드를 다 읽기 전에 일종의 '예측'을 하는 셈이다.
'예측'과 실제 기능이 일치한다면 빠르게 코드를 읽고 넘어갈 수 있지만 함수가 예측과 다른 일을 많이 하면은 할수록 문제가 생긴다. 예를 하나 들어 보자.
밑의 함수는 이메일이 제대로 되었는지 확인하는 함수이다.
fun isValidEmail() {
// 블라블라
}'isValidEmail' 은 함수 내부를 보기 전에도 이메일을 검증하는 함수일거라고 대강 추측할 수 있다.그런데 추측과는 다르게 이메일을 수정하는 내용이 있다고 해보자. 이 경우에 이 함수에 문제가 있을거라고 생각하기도 어렵고 디버깅하는데 걸리는 시간도 오래 걸리게 된다. 이름을 잘 정하는 게 길게 보았을때 매우 중요한 일인 셈이다.
5.초기 프로젝트 세팅이 끝까지 간다.
윈도우즈를 개발할때 택했던 명명법은 '헝가리안 표기법'이었는데 이 방식은 한 논문에서 나온 것이었으나 막상 논문에 적힌 내용과는 조금 달랐다. 윈도우즈의 초기 개발진들이 논문의 일부를 잘못 이해했고, 찰즈 페졸즈가 쓴 '윈도우즈 프로그래밍'이 널리 팔리면서, 이 방식이널리 퍼지게 되었다.
이건 윈도우즈만의 문제가 아니라 어떤 프로젝트든 초반의 구조가 끝까지 영향을 미치는 경우가 대단히 많다고 한다. 일단 구조가 한번 잡히면 이를 바꾸기는 상당히 어렵고 새로 합류하는 개발자들은 큰 고민없이 기존의 구조나 명명법을 따르기 마련이다.
나중에 고치기 어렵다는 걸 감안하면 초반에 많은 공을 들이는게 낫다.
6.개발자 간에도 이름 짓는 방식이 아주아주 다양하다.
동일한 기능을 하는 함수를 설명하고 개발자들에게 이름 짓기를 했는데 30여건에서 단하나도 동일한 이름이 나오지 않았다.
초반에 프로젝트를 설계할때 '이름짓는법'(네이밍)을 개발자끼리 정해 놓는 게 꼭 필요하다.
개발자들에게 "매달 최대로 받을 수 있는 혜택"을 변수로 만들도록 했는데 10가지가 넘는 변수명이 나왔다.
max_benefit
max_benefit_per_month
max_benefit_num
max_monthly_benefit
benefits
benefits_per_month
max_num_of_benefit
benefit_max_num
max_number_of_benefit
max_benefit_amount
max_acc_benefit
max_allowed_benefit
montly_benefit_limit
이에 대한 해결책은 이름짓기에 대한 규칙을 정하는 것이다. 변수 이름이 비슷하면 동일한 이름틀을 사용한다는 의미다.
예를 들어 최대 이자 금액을 계산하는 변수에 "max_interest_amount"라는 이름을 주었다면, 최대와 관련된 변수는 "max_benefit_amount" , "max_cost_amount" 같은 식으로 짓는게 좋다. "interest_maximum"같은 식으로 이름을 지으면 두뇌의 장기기억에서 기존의 지식을 활용하기 어려워진다.
7. 코드 정렬도 중요하다.
코드 블록을 어떻게 만드는가에 따라서 코드를 파악하는 정도도 달라진다고 한다. 코드 블록은 탭은 얼마나 쓸지, 각종 열고 닫기는 어떤 시점에서 할지를 말한다.
익숙한 코드 블록으로 된 코드를 보면 더 빠르게 코드를 파악하지만, 익숙하지 않다면 파악하는데 오래 걸린다. 여럿이서 하는 프로젝트라면 코드 블록도 정해놓고 하는게 좋다.
C와 Java는 코드 블록이 미묘하게 다른데, 한쪽 언어를 주로 쓰다가 다른 언어를 쓰게 되면 주로 쓰던 언어의 스타일을 따라 가려는 경향이 있다. 한번 학습된 것을 잊기가 쉽지 않은 것이다.
마무리
한분야의 전문지식을 다룬 분야와 연결하기는 매우 어렵다. 그런데 저자는 이 놀라운 일을 해냈다. 뇌과학과 프로그래밍이라는 하나도 알기 어려운 것을 연결시킨 것이다. 덕분에 우리 두뇌가 근본적으로 어떻게 코딩을 하는가, 어떻게 두뇌를 잘 활용해서 코딩할 수 있을까를 근본적으로 알수 있게 되었다. 경력 있는 개발자라면 꼭 한번 읽어보기를 권한다. 뇌과학적 용어 (fMRI 같은것)이 나오기는 하는데 검색 하면서 읽을 가치가 있다.
인상깊은 구절
"생소한 코드를 처음 접하면 누구나 어느정도 혼란을 느끼기 마련이다. 이러한 혼란은 3가지로 나눌 수 있다. 첫째는 지식의 부족이다. 프로그래밍 언어나 알고리즘 혹은 업무 영역에 대한 지식이 없는 경우 혼란이 생길 수 있다. 둘째는 정보의 부족이다. 코드를 이해하기 위해 필요한 정보를 충분히 가지고 있지 못하는 경우다. 요즘은 코드가 다양한 라이브러리를 사용하기 때문에 코드를 잘 이해하기 위해서는 이들에 대한 정보를 많이 찾아봐야하고, 찾아보는 일을 하기 전에 무엇을 하고 있었는지도 기억해야한다. 셋째, 처리 능력의 부족이다. 코드를 따라가다보면 어떤 동작들이 수행되는지 알기 어려울 때가 있다. 코드가 너무 복잡해서 혼란이 생기는 경우이다."
"전문가는 초보자보다 코드를 더 잘 기억한다. 전문가는 청크(덩어리) 단위로 기억을 한다."
"심지어 다른 프로그래밍 언어를 잘 아는 뛰어난 프로그래머조차, 아직 장기기억(LTM, long term memory)에 저장되지 않은 익숙하지 않은 키워드, 구조, 도메인 개념을 기억하는데 어려움을 겪는다"
"프랑스어를 배울 수 있다면 파이썬도 배울 수 있다. "
"fMRI 스캔을 통해 작업 기억 공간과 언어 처리에 관련 있는 두뇌의 영역이 프로그래밍과 연관된다는 것을 살펴봤다. 이 사실은 작업 기억 공간 용량이 크고 언어 능력이 좋은 사람이 더 뛰어난 프로그래머가 된다는 것을 암시하는 것일까?"
"프랫의 연구팀이 발견한 사실이 어떤 프로그래머들에게는 놀라운 것일 수 있다. 계산 능력, 즉 수학적 능력을 적용해야 하는 지식과 기술은 프로그래밍 능력에 대한 예측력이 작았다. 실험 참여자들 사이에서 겨우 2의 분산(편차)이 나타났다. 언어 능력이 더 나은 예측요인으로 17% 분산이 나왔다. 이것은 흥미로운 결과다. 개발자들은 보통 수학 능력을 중요시하고, 필자가 아는 많은 프로그래머는 자신들이 언어에 소질이 없다고 말했기 때문이다. 세 가지 테스트 중에서 가장 뛰어난 예측력을 보인 요인은 작업 기억 공간 용량과 추론 능력이었다. 실험 참여자들 사이 분산이 34%였다." - p87
"학습률에 대한 측도는 언어 능력이 가장 큰 요인이었다. 학습률과 프로그래밍 능력은 서로 비례하는 상관관계를 보였다. 물론 이 연구에서 읽기 능력이 뛰어난 학생이 일반적으로 학습 성과가 좋고 반면에 읽기 능력이 부족한 학생은 빠르고 쉽게 학습하지 못한다는 사실이 근원적인 요인일 수 있다" - p87