프로그래머의 뇌 정리 및 리뷰

te-ing·2022년 5월 23일

📝 리뷰 요약

프로그래밍에 인지과학을 접목한 책이다. 학습방법이나 심리학 책을 자주 읽었던 사람이라면 비슷한 내용이 등장하는 것도 볼 수 있을 것이다.

뇌의 인지과학에 대한 것 외에도 사회과학(심리학) 실험을 예시로 든 듯한 예시들이 나오는데, 이는 무조건 정답이 될 수 없다고 생각하므로 비판적인 시각으로 수용할 필요가 있을 것 같다.

심리학적인 측면 외에도 더 좋은 코드나 프로그래밍을 더 잘할 수 있는 방법에 대해 고민하고 연구한 것들이 많이 나와있으므로, 아주 기초적인 프로그래밍 수준이 아니라면 누구나 읽어보기 좋은 책이다.

1~3장 코드를 잘 읽을 수 있는 기법 with LTM, STM, 작업기억공간

코드를 읽을 때에는 장기기억을 보관하는 Long term Memory인 LTM, 단기기억을 보관하는 STM, 그리고 현재 처리하는 작업을 기억하는 작업기억공간을 사용한다.

function square = (a, b) => {
	return (a + b)**2;
}
function pam = (r, k) => {
	let ek;
	ek = ek+r*k+r*k+(r**2)+(k**2);
	return ek
}

책의 코드를 자바스크립트로 극단적으로 각색해보자면 위의 코드를 5초간 보여주고 다시 작성하라 한다면 모두가 쉽게 작성할 수 있는 반면, 두번째에는 어려움이 따른다.

square 이라는 단어의 뜻과 자바스크립트 문법에 대한 LTM을 통해 쉽게 작성할 수 있지만, 두번 째에는 같은 기능을 하는 함수임에도 의미없는 단어까지 기억해야 하기 때문에 STM의 많은 공간을 사용해야 한다. 또한 ek의 대한 값을 구할 때 수식을 머릿속에서 컴파일하면서 차례로 ek의 값을 추적하며 작업기억공간까지 사용해야 한다.

즉 읽기 쉬운 코드를 위해서는 STM과 작업기억공간은 제한적이기 때문에 LTM과 연관시킬 수 있도록 구조를 만들어야하며, LTM이 많이 축적되어 있을수록 코드를 이해하기 편하다. 이는 숙련된 프로그래머가 코드를 빠르게 읽을 수 있는 이유 중 하나다. 숙련된 프로그래머는 여러 디자인패턴과 다양한 문법을 알고 있기 때문에, LTM과 연결할 수 있는 다양한 경로를 생성할 수 있다.

4장 작업기억공간에 부하가 오면 사용할 수 있는 보조 기억수단

의존그래프

모든 변수마다 동그라미 표시
비슷한 변수끼리 선으로 연결하기
모든 메서드나 함수호출을 다른 색깔의 동그라미로 표시
메서드나 함수호출을 정의와 연결
클래스의 모든 인스턴스를 다른 색깔의 동그라미로 표시
클래스와 그 클래스의 인스턴스 연

상태표

각 변수를 열로 설정한 후, 변수의 변경사항을 해당 행에 채워넣으며 변수가 어떻게 변해가는지를 기입

5장 코드를 더 깊이 이해하기

코드가 하는 역할에 따라 11가지의 표식을 부여한 후 읽는 방식은 코드를 읽는 것에 도움을 준다
또한 숙련된 프로그래머는 코드를 읽을 때 초보 프로그래머에 비해 전체적으로 스캔하는 비율이 높았다. 반면 초보 프로그래머들은 순차적으로 코드를 읽는 비율이 높았다.

이는 수능영어에서 빠르게 지문을 읽는 방식과 비슷해 보인다. 빠르게 영어지문을 읽기 위해서는 순차적으로 자세히 읽기보다는 빠르게 스캔하며 중요한 정보만을 습득하는 것이 중요하며 동사, 명사, 목적어 등을 V, N, O 로 표시하며 읽는데, 이는 책에서 이야기하는 코드 읽는 연습과 흡사하다.

6장 정신모델

변수라는 개념을 설명할 때 실생활을 예시로 들기 위해 박스를 예로 들곤 한다. 박스를 메모리로, 박스 안의 물건을 변수로 이야기하곤 하는데, 이렇게 정신모델을 설정하게 되면 박스에 여러개의 물건을 넣을 수 있다는 특성으로 인해 한 메모리에 여러 개의 값을 넣을 수 있다는 잘못된 생각을 하게된다.

또, 두개의 테이블에 나이프와 포크를 어떻게 놓는지에 대해 설명할 때, 한가지 공통된 조건과 여러 개의 조건을 구체적으로 설명한 그룹과, 여러 공통된 조건들과 함께 구체적인 사항을 설명한 그룹이 있다. 이때 정답률은 한가지 공통된 조건만을 설명한 그룹이 정답률이 높았다.

이처럼 정신모델로 인해 잘못된 이해를 하지 않도록 주의해야 하며, 쉬운 이해를 할 수 있도록 해야 한다.

7장 생각의 버그

숙련된 프로그래머는 LTM 덕분에 새로운 프로그래밍 언어를 빠르게 익힐 수 있다. 하지만 LTM으로 인한 부정적인 결과를 초래할 수 있는데, 앞선 기억과 잘못 연결될 경우 잘못된 정보로 기억할 수 있기 때문이다.

예를 들어 눈사람에 스웨터를 입히면 대부분의 사람들은 스웨터의 따뜻함이라는 특성 때문에 눈사람이 빠르게 녹을거라 생각하지만, 스웨터는 단열재의 역할을 하여 우리의 체온을 유지시켜주는 것이며, 이때문에 눈사람의 온도를 유지시켜 오히려 녹는 속도를 늦춰주게 된다.

때문에 새로운 언어를 익힐 때면 원래 알던 지식과 다를 수 있다는 것을 명심해야 하며, 체크리스트 등을 작성하여 기존 개념으로 인한 오개념이 생기지 않도록 조심해야 한다.

8~9장 이름을 잘 짓는 방법과 잘 지어야 하는 이유

대체로 익숙한 이야기. 단일 문자나 의미없는 짧은 문자보다 의미가 담긴 단어의 조합이 좋다.

더 나은 변수명을 위한 페이텔슨의 3단계 모델

이름에 포함할 개념을 선택한다
각 개념을 나타날 단어를 선택한다.
이 단어들을 사용하여 이름을 구성한다.

함수 명을 지을 때 주의할 점

함수의 기능보다 더 많은 기능이 담기거나 함수의 기능을 담지 못하는 이름을 피해야 한다.

boolean 값을 반환하면서 get… 함수명을 짓거나 반환값이 boolean값이 아님에도 is… 와 같은 변수명을 지어서는 안된다.

10장 복잡한 문제 해결을 더 잘하려면

새로운 수학 공식을 가르칠 때 A그룹에는 자세한 풀이과정을 함께 주었고, B 그룹에는 스스로 터득하도록 하였다. 이후 해당 수학공식을 이용한 문제를 풀 때 A그룹의 정답률이 당연히 높았으며, 놀라운건 풀이속도가 B그룹보다 5배 빨랐다. 또한 해당 수학공식을 응용한 다른 문제를 풀 때에도 A그룹이 우수한 성과를 보였다. 이러한 학습방법을 프로그래밍에도 사용하기 위해서는 자주 사용하는 라이브러리의 깃허브를 보는 것이 유용하다.

11장 코드를 작성하는 행위

작업을 방해받았을 때 원래 작업으로 바로 돌아오는 사람은 10%도 되지 않았고, 원래 작업으로 돌아오기까지 평균 25분이 걸렸다. 하지만 협업을 하다보면 작업을 방해받을 때가 많은데, 이 때 빠르게 작업으로 되돌아오기 위해서는 정신모델(6장 참조)을 기록해두거나, 작업을 하위 작업로 세분화하면 작업에 다시 복귀하는데에 도움을 준다.

13장 새로운 개발자 팀원의 적응 지원방법

동시에 너무 많은 것을 교육하는 방식은 인지 과부하를 유발하기 때문에 좋은 성과를 내지 못하며 기억에도 잘 남지 않으니 주의해야 한다.

활성화, 모니터링, 중요도 결정, 추론, 시각화, 질문, 요약 등을 팀과 함께 다같이 코드 함께 읽기를 하며 적응 지원을 할 수 있다.

느낀 점

작업방해요소 차단하기

모든 문법을 완벽히 이해할 필요는 없지만 문법을 외워야 하는 이유를 설명할 때, 문법을 떠올리기 위해 인터넷 검색을 한 후, 원래 작업까지 돌아오는데 평균 25분이 걸린다는 것을 예시로 들었다. 너무나도 찔리는 예시였으며, 작업을 할 때 카톡알림을 끄는 등 최대한 작업의 몰입을 깨뜨리는 일을 지양해야겠다는 생각이 들은 예시였다.

프로그래밍도 결국 사람이 하는 것

효율적인 학습방법을 설명하는 여타 학습책이나 심리학 책에서 자주 나오는 용어와 내용이다. 그럼에도 이 책이 인기를 끄는 이유는 이러한 방법이 프로그래밍에도 적용된다는 생각을 잘 하지 않기 때문이기도 한 듯 하다. 플래시카드를 이용해서 영단어를 외우는 사람은 많아도 프로그래밍 문법을 외우려는 사람이 얼마나 있을까.

스스로 배우는 것이 무조건 좋지 않을 수 있다.

새로운 수학 공식을 가르칠 때 A그룹에는 자세한 풀이과정을 함께 주었고, B 그룹에는 스스로 터득하도록 하였다. 이후 해당 수학공식을 이용한 문제를 풀 때 A그룹의 정답률이 당연히 높았으며, 놀라운건 풀이속도가 B그룹보다 5배 빨랐다. 또한 해당 수학공식을 응용한 다른 문제를 풀 때에도 A그룹이 우수한 성과를 보였다.

스스로 배우는 것이 당연히 좋다고 여기는 관념이 있다. 나도 당연히 스스로 터득하는 것이 기억에도 오래 남고, 응용도 더 잘할 것이라 여겼다. 때문에 알고리즘 문제를 풀 때에도 3시간씩 끙끙대며 문제를 풀기도 했고, 문제를 해결할 때에도 검색보다는 혼자서 이런저런 해결방안을 시도해 볼 때가 많았다. 지금까지는 당연히 이렇게 해결하는 것이 좋다고 생각했는데, 책의 예시를 보니 지금까지 했던 방식이 잘못된 것은 아닐까 하는 생각이 든다.

이러한 학습방법을 프로그래밍에도 사용하기 위해서는 잘한 코드를 보며 배워야 하는데, 이는 자주 사용하는 라이브러리의 깃허브를 보는 것이 유용하다고 한다. 한국 도메인의 유명한 라이브러리를 찾아봐야 겠다.

💡 총 소감