프로그래밍할 때 뇌가 어떻게 동작하는지 인지과학에 따라 설명하는 책이다. 인지과학 혹은 뇌과학에 대해 듣기는 했지만, 자세히 살펴본 적은 없다. 관심 분야가 아니기도 했고 이런 부분을 공부해서 나한테 적용하는 것은 나한텐 꽤 어려운 일처럼 느껴졌기 때문인데 그런 면에서 프로그래머를 대상으로 해서 이러한 분석을 했다는 것 자체가 꽤 흥미로웠고 책이 별로 두껍지 않다는 점도 마음을 가볍게 했다.

이 책의 목적은 우선 두뇌가 코드를 처리하는 방식을 이해하도록 돕는 것이다.

이 책에서 그동안 몰랐던 엄청난 사실을 알려주지는 않았다. 학습이나 성장을 위한 방법 혹은 우리가 일하면서 효율성을 추구하기 위해 하는 방법들과 같은 맥락을 가지고 있지만 이 책에서는 왜 그러한 접근 방법이 유효한지를 설명해 주는 느낌이다. 왜 그런 방법이 유효했는지 나는 왜 어려움을 겪었는지에 대한 설명과 근거를 제공하고 있는데 이를 안다고 더 잘할 수 있는지까지는 아직 잘 모르겠지만 자신이 약한 부분에 대한 훈련의 실마리를 찾는 데 도움은 받을 수 있을 것 같다. 어쨌든 꽤 신선한 접근이라 재미있게 봤다.

Part 1 코드 더 잘 읽기

1부에서는 코드를 읽을 때 우리의 뇌가 어떻게 동작하는지를 설명한다.

지식이 없다는 것은 장기 기억 공간(LTM, long-term memory)에 해당 내용이 없다는 것을 뜻한다. 장기 기억 공간은 기억하는 내용을 반 영구적으로 저장하는 곳이다.
반면에 지식이 아닌 어떤 정보가 부족할 때는 단기 기억 공간(STM, short-term memory)에 해당 내용이 없기 때문이다. 정보를 수집할 때 단기 기억 장소에 일시적으로 저장하지만, 다른 정보를 찾는 과정에서 이미 수집해놓은 정보 중 일부는 잊어버린다.
마지막으로, 많은 정보를 처리할 때는 작업 기억 공간(working memory)에 영향을 미치는데 우리는 사고할 때 이 영역을 사용한다.

LTM, STM, 작업 기억 공간은 이 책 전체에 걸쳐 계속 나오는 가장 중요한 개념이고 대부분의 방법이 이 3가지 공간이 유기적으로 잘 동작하도록 하고 각 공간이 잘 동작하도록 하는데 초점이 있다.

해럴드 아벨슨, 제럴드 제이 서스먼, 줄리 서스먼이 쓴 "컴퓨터 프로그램의 구조와 해석"에 다음과 같은 유명한 문장이 있다. "프로그램은 사람이 읽을 수 있도록 작성해야만 한다. 기계가 실행하는 것은 부차적인 일이다." 이 말이 사실임에도 현실적으로 프로그래머들은 코드를 읽는 법보다 작성하는 법을 훨씬 더 많이 연습한다.

나는 코드를 잘 읽지 못하는데 이 부분이 후회되어서 발표나 멘토링을 할 때 항상 코드 읽는 연습을 하라고 자주 말하고 다녔다. 그래서인지 이 말이 핵심을 찔린 느낌이 들었다.

많은 소프트웨어 개발자는 프로그래밍 언어의 문법을 모르더라도, 인터넷에서 검색하면 되고, 따라서 문법에 대한 지식이 그리 중요한 것은 아니라고 생각한다. 모르는 것이 있을 경우, 검색이 그리 좋은 해결책이 되지 못하는 이유는 두 가지가 있다. 그 첫 번째 이유는 2장에서 다뤘듯, 관련 내용을 미리 알고 있는 것이 코드를 효율적으로 읽고 이해하는 데 상당한 영향을 미치기 때문이다. 개념, 자료구조, 문법을 더 많이 알수록 두뇌는 더 많은 코드를 쉽게 분리하고 기억하고 처리할 수 있다.
두 번째 이유는 두뇌가 작업을 하다 업무 중단을 받게 되면, 우리가 생각한 것보다 훨씬 더 좋지 못한 결과를 초래하기 때문이다.

요즘은 인터넷이 발달하니 코딩할 때도 구글 검색이나 Stackoverflow를 끼고 개발하게 되는데 그 부분을 지적하고 있다. 현재 작업에는 영향을 끼치지 않는 것처럼 보이지만 두뇌가 제대로 활용되지 않기 때문에 더 큰 문제나 어려운 문제에 접근할 때 영향을 줄 수 있고 검색하면서 중단된 업무 자체도 영향을 미친다고 한다. 그래서 뇌를 사용해서 외우고 학습하는 노력이 필요하다고 한다.

너무 쉽게 정보를 찾고 또 그것이 너무 일상적으로 이뤄지다 보니 우리 두뇌는 문법을 기억할 필요가 없다고 느낀다. 따라서 프로그래밍 문법에 대한 인출 강도가 강화되지 않고 계속 약한 상태로 남아 있게 된다.

연습하지 않고서는 내용을 오랫동안 기억할 수 없다는 것이 LTM의 가장 큰 문제점이다.
오랫동안 학습한 만큼 더 오래 기억한다. 이것은 더 많은 시간을 학습해야 한다는 것을 의미하는 게 아니라 더 오랜 간격을 두고 학습해야 한다는 것을 의미한다.

캘리포니아 대학교의 심리학과 교수인 로버트 비요크와 엘리자베스 비요크는 LTM으로부터 기억을 가져오는 두 가지 서로 다른 기제, 즉 저장 강도와 인출 강도를 구분했다.
저장 강도는 무언가를 LTM에 얼마나 잘 저장하고 있는가를 나타낸다. 어떤 것을 더 많이 학습할수록 그 내용을 잊어버리는 것이 거의 불가능해질 때까지 기억은 점점 더 강해진다.
인출 강도는 무언가를 얼마나 쉽게 기억할 수 있는지를 나타낸다.

또한 복잡한 코드를 이해하는 게 왜 어려운지도 설명하고 있다.

STM과 같이 작업 기억 공간도 한 번에 2개에서 6개까지만 기억할 수 있다. 작업 기억 공간의 맥락에서 이 용량을 인지 부하라고 부른다. 너무 많은 요소가 있어 청크로 나뉘지 않는 문제를 풀려고 할 때 작업 기억 공간은 '과부하'상태가 된다.

복잡한 구조의 코드는 두 가지 방식으로 작업 기억 공간에 과부하를 유발한다.
첫 번째로, 정확히 코드의 어디를 파악해야 하는지 모를 때이다. 이 경우 필요 이상으로 많은 코드를 읽게 되고 이것은 작업 기억 공간이 처리할 수 있는 것보다 많은 양이 될 수 있다.
두 번째로, 코드가 서로 밀접하게 연결되어 있는 경우 두뇌는 두 가지 작업을 동시에 수행한다. 코드의 개별 라인을 이해하면서 어느 부분을 계속 읽어야 하는지 판단하기 위해 코드의 구조를 이해해야 한다.

Part 2 코드에 대해 생각하기

2부에서는 코드에 대한 여러 가지 사실을 알려준다.

LTM에 저장된 프로그래밍 지식은 새로운 프로그래밍 개념을 배우는 데 두 가지 방식으로 도움이 될 수 있다. 첫째, 프로그래밍(또는 다른 과목)에 대해 이미 많이 알고 있다면 그것에 대해 더 많이 학습하는 것이 쉬어진다. LTM에 저장된 정보를 사용해서 새로운 내용을 쉽게 배우는 이 과정을 학습 도중 전이라고 부른다.
LTM에 저장된 지식이 학습을 지원하는 두 번째 방법은 학습 전이다. 학습 전이는 완전히 낯선 상황에 이미 알고 있는 내용을 적용할 때 일어난다. 인지과학에서 '전이'(전달)라는 용어를 사용할 때는, 거의 대부분의 경우 학습 전이를 의미한다.

자동화된 기술의 전이와 의식적으로 습득한 기술의 전이는 차이가 있다. 자동화된 기술을 이전하는 것을 저도 전이라고 한다.
보다 복잡한 작업이 전이되는 것을 고도 전이라고 한다. 고도 전이가 일어나는 경우에는 그러한 상황이 발생하고 있음을 인지하는 경우가 많다.

LTM에 가진 지식을 이용해서 새로운 학습을 할 때 이 지식이 도움이 되는 경우가 있고 아닌 경우가 있는데 이러한 것이 어떤 개념이고 무엇을 조심해야 하는지를 설명한다.

미적분학과 대수학 또는 C#과 자바처럼 서로 가까운 영역 사이에서 지식이 전이될 때 근거리 전이가 일어난다. 라틴어와 논리학, 자바와 프롤로그와 같이 서로 먼 영역 간에 일어나는 전이를 원거리 전이라고 한다.

무언가 알고 있어 새로운 것을 배우거나 새로운 작업을 할 때 도움이 되는 전이를 긍정적 전이라고 부른다.
기존 지식이 새로운 것을 배우는 데 방해가 될 때, 이것을 부정적 전이라고 부른다.

대부분 겪어 봤듯이 알고 있는 지식이 항상 도움이 되는 건 아니고 특히 트러블슈팅 시에 이러한 함정에 빠지는 경우도 많았다. 당연하다면 당연한 얘기이지만 이와 관련된 여러 근거와 개념을 자세히 설명해 준다.

이미 알고 있는 프로그래밍 언어 때문에 생긴 오개념을 현재 학습 중인 새로운 언어에 맞는 정신 모델로 대체하는 과정을 개념 변화라고 한다. 이 패러다임에서 기존의 개념은 근본적으로 바뀌거나 대체되거나 새로운 지식에 동화된다. 기존의 스키마에 새로운 지식을 추가하는 대신 지식 자체를 바꾼다는 것이 개념 변화가 다른 유형의 학습과 구별되는 점이다.
이미 학습한 지식을 LTM에서 변경해야 하기 때문에 개념 변화 학습은 일반적인 학습보다 더 어렵다. 이 점 때문에 오개념이 쉽게 사라지지 않고 오랫동안 지속된다. 생각이 왜 잘못되었는지에 대한 정보를 단순히 제공하는 것만으로는 도움이 되지 않고 또 그것만으로는 변경하는 데 충분치 않다.

특히 오개념은 할 수 있는데 많지 않다고 해서 약간 절망하기도 했다. 그래도 할 수 있는 노력이 있다니까...

오개념에 대해 우리가 할 수 있는 것이 많지 않다. 새로운 프로그래밍 언어나 시스템을 배울 때, 부정적 전이를 피할 수는 없다. 하지만 도움이 될 몇가지 방법들이 있다.
첫째, 자신이 옳다고 확신하더라도 여전히 틀릴 수도 있다는 것을 아는 것이 중요하다. 열린 마음을 유지하는 것이 핵심이다.
둘째, 흔하게 발생하는 오개념에 대해 의도적으로 연구해봄으로써 그런 오개념에 빠지는 것을 방지할 수 있다.
마지막 조언은 같은 프로그래밍 언어를 같은 순서로 학습한 다른 프로그래머들에게 조언을 구하는 것이다.

Part 3 좋은 코드 작성하기

3부는 코드 작성에 대한 내용이다.

좋은 변수 이름을 고르는 것은 어렵다. 넷스케이프의 프로그래머 필 칼튼은 컴퓨터 과학에는 난제가 딱 두 가지 있는데, 바로 캐시 무효화와 이름 짓기라는 유명한 말을 했다. 그리고 실제로 많은 프로그래머는 이름을 짓는 것에 어려움을 겪는다.

작명은 항상 어렵고 영어를 잘하지 못하니까 어휘력이 부족해서 더 어렵다. 변수명을 짓는 게 왜 어려운지 사람마다 이름을 얼마나 다르게 하는지, 심지어 카멜 케이스와 스네이크 케이스의 차이가 있는 지 등 다양한 실험 결과를 보여준다.

잘못된 이름 문제를 해결하는 것이 반드시 버그를 고치거나 예방하지는 않지만, 코드베이스를 검사하여 잘못된 이름이 발생하는 위치를 찾아내는 일은 코드를 개선하고 버그 발생 가능성이 있는 위치를 찾는 데 도움이 될 수 있다. 이것이 바로 코드에서 나쁜 이름을 찾아야 하는 또 다른 이유다. 이름을 개선하면 간접적으로 버그가 줄어들거나, 더 나은 이름을 사용한 코드는 이해하기 쉽기 때문에 최소한 수정 시간이 단축될 수 있다.

페이텔슨은 개발자들이 더 나은 이름을 선택하는 데 도움이 되도록 3단계 모델을 설계했다.
1. 이름에 포함할 개념을 선택한다.
2. 각 개념을 나타낼 단어를 선택한다.
3. 이 단어들을 사용하여 이름을 구성한다.

본유적 부하는 두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력을 의미한다. 여러분이 가지고 있는 모든 인지 부하가 내재적 부하와 외재적 부하로 가득 차면, 본유적 부하를 위한 여지는 남아 있지 않게 된다. 즉 문제와 그 해결책을 기억할 수 없다.
힘든 코딩 작업을 마친 후 때때로 자신이 한 일을 기억하지 못하는 경우가 있을 것이다. 이것이 바로 이런 이유 때문이다. 두뇌가 해결책을 저장할 수 없을 정도로 몰입해 있었던 것이다.

LTM에 저장하기 위한 여유가 필요하다는 점은 꽤 흥미로웠다. 어쩌면 자고 일어나서 문제가 해결되거나 일할 때 휴식도 도움 된다고 하는 말이 이런 부분과 관련이 있을 것 같은 느낌인데 이렇게 명확하게 설명하니 생각이 많이 들었다.

Part 4 코딩에서의 협업

안타깝게도, 사람들이 깊은 인지 작업을 하는 동안 여러 가지 일을 할 수 없다는 증거가 압도적으로 많다.
흥미로운 점은, 멀티태스킹을 하는 사람들은 종종 자신이 매우 생산적이라고 느낀다는 점이다.
학생들이 온라인 메시지를 사용하여 파트너와 의사소통하면서 과제를 수행하는 통제된 실험에서 학생들 본인은 자신의 수행 능력이 만족스럽다고 느꼈지만, 그들의 파트너는 그들에게 훨씬 더 낮은 점수를 주었다. 이것은 슬랙에서 채팅을 하며넛 프로그래밍하는 것이 일을 끝내기 위한 좋은 방법이 아닐 수도 있다는 것을 의미한다.

이 책에서 가장 뜨끔했던 부분이다. 나는 멀티태스킹을 많이 하는 편이다. 코딩하면서도 귀에 뭔가를 항상 꼽고 있고 집에서는 TV를 틀어놓고 일하면서 트위터하고 슬랙 메시지도 실시간으로 다 확인하면서 일한다. 물론 몰입해서 하는 일과 멀티태스킹 하는 일의 차이는 알고 있었지만 멀티태스킹에 최적화된 인간이라고 나름 생각하고 있었지만 그냥 나 혼자 합리화할 뿐이었나 싶었다.

신규 입사자 혹은 신입에 대한 교육에 대해서도 나왔는데 나한테는 실제로 고민해 보고 적용해 보기에 가장 도움이 될만한 내용이었다.

가장 심각한 문제는 새 팀원에게 동시에 너무 많은 것을 교육함으로써 작업 기억 공간의 용량을 과도하게 늘린다는 점이다.

팀의 선임자들이 효과적으로 가르치고 설명하는 데 어려움을 겪는 이유 중 하나는 많은 경우 '전문가의 저주' 때문이다. 어떤 기술을 충분히 익히고 나면, 그 기술이나 지식을 배우는 것이 얼마나 어려웠는지 잊어버린다. 따라서 새 팀원이 동시에 처리할 수 있는 새로운 작업의 수를 과대평가하게 된다.

처음에 오면 전체를 아키텍처나, 구조나 의도 등 한번 다 설명해 주게 되는데(물론 한번 훑어주고 몰라도 괜찮다고 말은 하지만...) 이 책을 통해서 어느 부분을 어렵게 하는지 좀 더 체계적으로 생각해 볼 수 있지 않나 기대해 본다.

여러분이 할 수 있는 첫 번째이자 가장 중요한 것은 교육을 받는 사람들의 인지 부담을 의도적으로 관리하는 것이다.

적응 지원 과정의 문제 중 하나는 새 팀원에게 최소 네 가지 서로 다른 활동, 즉, 기능을 구현할 수 있는 적절한 장소 또는 관련 정보 검색, 새로운 소스 코드 이해, 코드베이스 탐구, 새로운 기능으로 코드베이스 수정을 수행하도록 요구하는 점이다.