뇌의 동작 원리
개발 공부를 하면서 구글에 가장 많이 검색하게 되는 키워드는 OO의 동작 원리다. 새로운 기술이나 유틸 클래스를 접하면 동작하게 되는 원리를 먼저 알아야 두려움 없이 사용할 수 있고 기억에 오래 남는다. 동작 원리에 대한 학습은 더 시간이 오래 걸리는 듯 하지만, 길게 봤을 때 더 빠른 길이라고 생각하고 있다. 그러면, 평소에 별 생각 없이 사용하는 뇌의 동작 원리는 어떨까? 뇌가 동작하는 원리를 알 수 있으면 전반적인 학습의 생산성이 높아지지 않을까 생각해서 "프로그래머의 뇌"를 읽었다.
책은 프로그래밍 중에 겪게 되는 다양한 상황을 제시 하고 이때 뇌가 어떤 식으로 활동하는지 설명한다. 그리고 더 효율적인 방식을 제시한다. 다양한 실험과 이론들이 등장하는데 앞으로 어떤 방식으로 학습해야 할지 대략적인 방식을 정하는데 도움이 됐다.
조금 아쉬웠던 점은, 저자가 제시하는 구체적인 방법들은 실현가능성이 낮아 보였다는 점이다. 플래시 카드로 문법에 대해 학습하기, 소스코드를 프린트 해서 파악하기, 변수 역할 프레임워크를 도입하기 등의 방법들은 실제로 사용하기에 다소 무리가 있어 보였다.
아래는 정리한 내용.
두뇌의 기억 공간
두뇌에는 세 가지 기억(memory) 공간이 있다. LTM(Long-Term Memory), STM(Short-Term Memory), 작업 기억 공간(working memory). 코드를 읽는 동안 이 세 가지 인지 과정은 다 같이 일어나며 보완적으로 작용한다. LTM은 오랜 시간 동안 저장하는 하드 드라이브, STM은 잠깐 동안 값을 저장하는 메인 메모리, 작업 기억 공간은 인지적으로 복잡한 작업을 할 때 사용되는 프로세서라고 볼 수 있다.
알고 있는 지식의 경우 LTM에서 인출(자바에 대한 사전 지식)되어 사용되고 STM은 새로 접하는 정보(변수 등)를 인지하는 데 사용된다. 하지만 STM의 용량에는 제한이 있기 때문에 생소한 코드를 읽는 것은 늘 어렵다. STM은 연구에 의하면, 저장되는 시간이 30초를 넘지 않으면서 용량은 몇 개 정도 밖에 되지 않는다.
STM이 가지는 한계를 극복 하기 위해 청크(chunk)라는 개념이 있다. 청크는 몇 개의 그룹으로 묶은 정보를 뜻하는데, STM에 저장되어야 하는 10가지 정보를 그룹으로 묶는 과정을 통해 기억해야 하는 가짓수를 줄이는 것이다. 이때 LTM에 저장되어 있는 지식을 활용해서 STM을 더 큰 그룹으로 묶을 수 있다.
프로그래머는 디자인 패턴을 사용하거나 의미 있는 주석문과 표식(변수명)을 남기는 것으로 청크로 묶을 수 있는 코드를 작성하는 것이 좋다.
기억을 강화하기
LTM은 한 시간만 지나도 반 정도가 사라지고, 이틀 후에는 75%가 사라진다. 그리고 실험을 통해 증명된 사실은, 오랫동안(더 많은 시간을 학습하는 것)보다는 오랜 간격을 두고 학습하는 것이 LTM에 지식을 축적하는 좋은 방법이다.
능동적으로 사고하는 것도 좋은 방법이 된다. 구글에서 프로그래밍 문법에 대해 검색하려고 할 때, 검색 이전에 먼저 그것을 능동적이고 의도적으로 기억하려고 시도해야 한다. 또한, 정보에 대해 능동적으로 생각하고 그것을 반추해보아야 한다. 이런 노력은 기억을 강화하고 다음번에 기억해내는 데 도움이 된다.
새로운 정보를 학습할 때 정보는 LTM에 저장되기 전에 먼저 스키마(사고나 생각이 서로 관련되어 조직된 방식)의 형태로 만들어진다. 어떤 숫자 목록(연결고리가 없는)은 목적에 따라 'OO을 하기 위한 숫자 목록'과 같은 이름으로 스키마에 저장되는 것이다.
기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하고, LTM에 이미 저장되어 잇는 스키마에 맞춰서 새로운 기억을 저장하면 효율적인 학습을 할 수 있다.
두 번째 프로그래밍 언어가 첫 번째보다 쉬운 이유
자바를 이미 알고 있다면 변수,루프 클래스, 메서드와 같은 기본 프로그래밍 개념을 이미 알고 있기 떄문에 파이썬을 더 쉽게 배울 수 있다. 또한 디버거나 프로파일러와 같이 프로그래밍 작업을 하면서 습득한 기술 중 일부는 또 다른 프로그래밍 언어를 배울 때 유용하게 사용할 수 있다.
새로운 정보를 접하면 감각 기억에서 STM으로 이동하고, 작업 기억 공간으로 들어가 처리되는데 새로운 프로그래밍 개념에 대해 생각하면 작업 기억 공간이 활성화되고 LTM 또한 활성화되면서 관련 정보 인출이 시작된다.
예를 들어 자바를 알고 있는 상태에서 파이썬의 메소드에 대해 배운다면, 조금 다르게 동작하더라도 훨씬 더 빨리 학습할 수 있다. 하지만 이러한 학습 전이는, 긍적적인 방향만 있는 것이 아니라 부정적 전이 또한 존재한다. 이미 LTM에 저장되어 있는 지식이 새로운 것을 배우는 데 방해가 될 수도 있다.
하나의 프로그래밍 언어를 숙달했다는 사실이 새로운 언어를 배우는 데 항상 도움이 되는 것은 아니다. SQL에서 자바스크립트로의 원거리 전이는 일어날 가능성이 낮으며, 새로운 프로그래밍 언어에서도 전문가 수준을 갖추려면 새로운 전략뿐만 아니라 새로운 문법도 많이 배워야 한다.
공통점과 차이점에 의식적으로 주의를 기울이면 새로운 언어를 배우는 일이 쉬워진다.
좋은 이름 짓기
이름을 짓는다는 것은 변수이름에 대한 올바른 단어를 선택하는 것 그 이상의 일이다. 변수 이름은 감각 기억에 의해 처리되고 STM으로 전송된다. STM은 크기가 제한되어 있기 떄문에 변수 이름을 단어별로 구분하려고 하는데, 이름이 체계적일수록 변수명의 각 부분을 식별하기 쉽다. nmcntrlst 같은 이름은 구성 요소를 찾고 이해하는데 상당한 노력이 필요하지만, nameCounterList 같은 변수 이름은 훨씬 쉽게 확인할 수 있다. 길이는 두 배 정도 길지만, 정신적인 노력은 아주 적다.
요하네스 호프마이스터의 연구 결과에 따르면, 코드를 이해하고 버그를 쉽게 찾기 위해서라면 명확한 의미의 단어를 사용해야 하는 반면, 기억을 잘하기 위해서라면 간결한 약자를 사용하는 것이 좋다. 좋은 이름 짓기를 위해서는 이 둘 사이의 주의 깊은 균형이 필요하다.
코드 스멜이 인지 과정에 악영향을 미치는 방식
긴 매개변수 목록이나 복잡한 스위치 문은 작업 기억 공간의 용량 초과를 야기한다. 작업 기억 공간은 6개 정도로 작기 때문에 6개를 넘는 매개변수 리스트는 사람들이 기억하기에 무리가 있다.
신의 클래스, 긴 메서드는 효율적인 청킹이 불가능하다. 코드를 빨리 이해하기 위해 결정적 특징이 많지 않아 코드를 한 줄 한 줄 읽어야 하기 때문이다.
클론 코드가 많은 경우는 청킹이 잘못 된다. 매우 유사한 goo()와 foo() 메소드가 있을 경우 두 메소드를 하나의 범주로 묶어 오개념이 생겨날 수 있다.
코드와 해설에서 배우기
문제 해결 능력을 향상하기 위해 사용할 수 있는 방법은, 다른 사람들이 문제를 어떻게 해결했는지 의도적으로 연구하는 것이다. 다른 사람들이 문제를 어떻게 해결했는지 연구함으로써 얻는 해결책을 풀이된 예제라고 부른다.
일반적으로 문제 해결을 잘하기를 바란다면 문제를 많이 해결해야 한다는 생각은 합리적으로 보인다. 프로그래밍 커뮤니티에서도 더 나은 프로그래머가 되고 싶다면, 프로그램을 많이 작성하라고 한다. 부수적인 프로젝트를 통해 여러 가지를 시도해보면 배우는 것이 많을 것이고, 문제 해결을 잘 할 수 있기를 바란다면 스스로 문제를 해결하도록 내버려두어야 한다고 말하지만, 스웰러의 실험 결과 이것은 사실이 아닌 것으로 보인다.
프로그램을 읽고, 이에 대한 설명을 통해 배우는 것이 더 많다는 것이다. 이는 본유적 부하와 연관이 있는데, 문제를 해결할 떄 모든 인지 부하(작업 기억 공간의 용량)가 내재적 부하(문제 그 자체가 갖는 특성 때문에 발생하는 인지 부하)와 외재적 부하(외부적 요인에 의해 문제에 추가된 것)로 가득 차면, 본유적 부하(두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력)를 위한 여지는 남아있지 않게 된다. 즉, 문제와 그 해결책을 기억할 수 없다는 것이다. 즉, 레시피를 제공받고 문제 해결에 들어가는 것이 이닞 부하가 높지 않았기 때문에 레시피를 자세히 검토하고 이후에 기억할 수 있다는 것이다.
깃허브를 탐구하거나, 소스 코드에 대한 책 또는 블로그 게시물 읽기, 동료와의 협업을 통해서 코드와 해설에서 배울 수 있다.
'Reading > 책 후기' 카테고리의 다른 글
자바 성능 튜닝 이야기 후기 (0) | 2022.06.06 |
---|---|
스프링 입문을 위한 자바 객체지향의 원리와 이해 후기 (0) | 2022.05.18 |
개발자의 글쓰기 후기 (0) | 2022.04.24 |
객체지향의 사실과 오해 후기 (0) | 2022.04.19 |
테스트 주도 개발 시작하기 후기 (0) | 2022.04.16 |
댓글