[책 후기] 프로그래머의 뇌
프로그래머의 뇌
펠리너 헤르만 / 출판사 제이펍
📙 책을 읽고 📙
초반 2~3챕터 정도 읽었을 때는 코드를 읽는데 이렇게까지 해야한다고? 라는 의문이 있었는데 나머지를 읽으며 좋은 책이구나, 라는 생각을 많이 했다. 이 책은 개발을 처음 접하는 사람, 전과 다른 새로운 분야에서 일하게 된 사람, 뉴비들을 이끌어야하는 사람들이 읽으면 좋을 것 같다. 무언가 새로 배우거나 가르쳐야하는 개발자들이 어떤 식으로 학습하는게 더 효율적일지 고민하게 만들어주는 책이었다. 크고 작은 팁을 얻어갈 수도 있다고 생각한다.
이 책의 가장 아쉬운 점을 꼽자면 용어가 너무 어렵다. 뇌에 대한 정신 분석 이야기 같은게 나오니 당연할수도 하지만 프로그래밍 측만 생각하더라도 영단어가 훨씬 이해하기 쉬운 번역이 있어서 아쉽다. 그래도 부담없이 읽을 수 있는 책이고 가벼운 스터디나 독서 모임으로 시작해도 괜찮은 책이라고 생각한다.
📘 인상 깊은 구절 📘
인상 깊었던 구절과 해당 부분을 읽고 들었던 생각에 대해 정리한다.
| 로 표시된 부분은 책을 인용해온 글이다.
📄 더 오래 기억하는 방법
오랫동안 학습한 만큼 더 오래 기억한다. 이것은 더 많은 시간을 학습해야 한다는 것을 의미하는 게 아니라 더 오랜 간격을 두고 학습해야 한다는 것을 의미한다.
당장 기억나지 않더라도 이런 기억하려는 노력은 기억을 강화하고 다음번에 기억해내는 데 도움이 될 것이다.
더 오래 기억하기 위해서는 수많은 반복적인 학습이 필요하다고 생각해왔다. 많은 연습을 통해 몸이 기억하게 될거라 생각했는데 많이 한다고 코딩을 더 잘할 수 있는건 아니었다는 연구 결과를 보고 조금 놀랐다.😨 공부를 어떻게 더 효율적으로 할 수 있을지에 대한 고민하는 계기가 되었다. 어떻게 하면 새로운 개념을 스스로에게 반복적으로 노출시키며 장기간 리마인드할 수 있을지.
이 책에서는 플래시 카드를 제안하는데 중고등학교 때 흔히 사용하던 영단어 암기 카드 같은 활용법이었다. 플래시 카드는 지식을 테스트하고 기억하는데 이용할 수도 있지만, 이해가 안 되는 어려운 코드를 읽을 때 사용할 수 있다. 플래시 카드에 있는 개념들 중에서 현재 나의 코드에 적용할 만한 것이 있는지 찾아보는 과정을 통해 새로운 개념을 코드에 도입시킬 수 있다는 설명이 흥미로웠다. 여태껏 이론적으로 새로운 개념에 대해 학습하면 그래서 이걸 언제 써먹어?라는 생각을 많이 했다. 나중에 (우연히) 활용하고 나서야 아 이게 그 개념이었구나~ 를 깨닫기 일쑤였는데 이런 식의 접근 방법이 있다는 것이 신기했다.
여러분이 가지고 있는 모든 인지 부하가 내재적 부하*와 외재적 부하*로 가득 차면, 본유적 부하*를 위한 여지는 남아 있지 않게 된다. 즉 문제와 그 해결책을 기억할 수 없다. 힘든 코딩 작업을 마친 후 때때로 자신이 한 일을 기억하지 못하는 경우가 있을 것이다. 이것이 바로 이런 이유 때문이다. 두뇌가 해결책을 저장할 수 없을 정도로 몰입해 있었던 것이다.
* 내재적 부하: 문제 자체가 얼마나 복잡한지
* 외재적 부하: 내재적 부하에 더해 문제에 추가되는 인지 부하
* 본유적 부하: 생각을 LTM에 저장하는 과정에서 일어나는 인지 부하
단어가 많이 어려운데 간단한 말로 풀어쓰면 문제가 너무나도 어려워서 모든 정신을 문제 푸는데에만 쏟게 된다면 문제를 푸는 과정을 머릿속에 기억할 여력이 없다는 뜻이다. 예전에 정말 힘겹게 풀었던 코테 문제가 있었는데 당시에는 어떻게든 풀어냈으나 지금은 어떻게 풀었는지 정말 단하나도 기억나지 않는다. 그런 케이스를 의미하는게 아닐까 추측해본다.
📄 코드 더 잘 읽는 방법
복잡한 소스코드를 읽을 때, 정신 모델의 구체적인 사례를 만들기보다는 정신 모델을 더 활용하기 위해 잠재적 정신 모델의 어휘를 더 많이 쌓아야 한다.
이 책에서는 문제를 더 잘 이해하기 위해서 정신 모델을 잘 알아야한다고 생각한다. 정신 모델에 대한 정확한 개념이 정리되어 있지는 않으나 하드 드라이브는 0과 1만을 가지는 전기 신호지만 우리가 파일 시스템에 대해 생각할 때는 폴더 안에 파일 따위가 들어있는 구조 등을 떠올릴 때 이런걸 정신 모델이라고 표현하고 나는 도메인 지식을 의미한다고 이해했다. 신입으로서 입사한지 약 2주차, 나의 주요 업무는 위키 읽기이다. 처음에는 코드부터 읽으려고 했으나 이건 왜 여기서 데이터를 가져와야하고 저건 왜 그런식으로 이어지는지 이해하기 정말 힘들어서 포기하고 위키를 읽었다. 도메인 지식을 쌓기 위함이었는데 아직도 모르는 단어가 대부분이지만 회의 때 알아들을 수 있는 단어가 조금씩 늘어나고 있다.
작은 것들을 알아내는 데 시간을 많이 쓰지 않을수록 어려운 문제들을 더 쉽게 풀 수 있다.
요즘은 자동화된 것이 정말 많다. 그래서 사소한 것 하나하나를 알지 못하더라도 클릭 몇 번에 단번에 해결되기도 한다. 심지어는 AI가 나 대신 코딩도 해주는 시대인데 어디까지를 '작은 것'으로 분류할 수 있을까? 나는 Java의 스트림을 애용하는 편이다. 하지만 IntelliJ 없이 스트림을 자유자재로 쓸 수 있냐고 물어본다면 솔직히 자신 없다. 요즘 같이 자동화된 도구가 쏟아져나오는 시대에서 나는 어디서부터 어디까지를 '작은 것'이라고 분류하고 나머지에 시간을 투자해야할까? 좋은 고민이 될 것 같다.
📄 문제 해결 능력을 높이는 방법
문제 해결 능력을 높이는 두 가지 방법에 대해 알아보겠다. 첫 번째 기술은 자동화다. 어떤 기술을 여러 번 연습한 후에 아무 생각 없이 할 수 있을 정도가 되면 이 기술을 자동화했다고 한다. (중략) 두 번째 방법은 다른 사람들이 문제를 어떻게 해결했는지 의도적으로 연구하는 것이다.
이 글을 읽고 옛날에 교복 입던 시절 수학을 싫어하게 된 계기가 생각났다. 나는 이과, 공대 출신이지만 웃기게도 수포자였는데 당시 다니던 학원에서는 수학 문제를 혼자 힘으로 풀어내기 전까지는 다음 문제를 못 풀게 했기 때문이다. 다른 사람들은 몇십 문제씩 풀어나가는데 나 혼자 풀어내지 못한 문제를 계속 붙들고 있었고 수학을 포기하는 결정적 계기가 되지 않았나 싶다. 물론 이 책에서는 이런 사유로 다른 사람들의 풀이를 의도적으로 연구하라는 의미는 아니었겠지만🤣
언젠가 코테를 잘하시는 분께서 주셨던 팁이 생각났다. '코테를 2시간 풀고 안 풀리면 다른 사람의 풀이를 보세요. 그리고 나중에 다시 풀어보세요' 당시에는 안 보고 푸는게 더 기억에 남지 않나..? 라는 의아함이 있었는데 이렇게 실제 연구 결과에서도 증명된 일이라 하니 신기했다.
📄 더 잘 설명하는 방법
개념을 설명할 때는 그 설명을 듣는 사람이 친숙한 비유를 고르는 것이 중요하다.
정말 중요하다고 생각하면서도 지키기 어려운 말이라고 생각한다. 듣는 사람이 친숙한 비유를 해야한다는 것은 설명을 잘해야한다는 것과 동시에 내가 그 사람에 대해서 잘 알고 있어야한다는 것을 의미한다. 송파구에서 일 잘하는 11가지 방법에서 '잡담을 많이 나누는 것이 경쟁력이다.'라는 문구가 있다. 잡담을 통해서 상대방에 대해 이해하고, 그로 인해 더 원활한 커뮤니케이션을 할 수 있게 된다라는 의미가 아니었을까?
📄 잘못된 정보를 바로잡는 방법
첫째, 자신이 옳다고 확신하더라도 여전히 틀릴 수도 있다는 것을 아는 것이 중요하다. 열린 마음을 유지하는 것이 핵심이다. 둘째, 흔하게 발생하는 오개념에 대해 의도적으로 연구해봄으로써 그런 오개념에 빠지는 것을 방지할 수 있다. (중략) 마지막 조언은 같은 프로그래밍 언어를 같은 순서로 학습한 다른 프로그래머들에게 조언을 구하는 것이다.
같은 프로그래밍 언어를 같은 순서로 학습한 다른 프로그래머들과 이야기하는 기회는 정말 드물기에 쟁취하기 위해 많은 노력을 해야하는 것 같다. 나는 정말 운이 좋게도 우테코가 그런 기회를 가져다주었고 최대한 활용하기 노력했던 기억이 난다. 지식 수준이 큰 차이가 나는 사람들에게만 조언을 구하면 일방적인 정보 전달이 되기 쉽다. 이런 식의 대화는 대부분이 머릿속에 남지 않는다. 비슷한 지식 수준을 가진 사람들과만 조언을 구하면 토론을 하다가도 어느 순간 막히는 포인트가 온다. 지식 수준이 비슷하기 때문에 문제를 더 넓은 시야로 바라보지 못하기 때문이다. 그래서 난 다양한 사람들과 대화해보는게 중요하다고 생각한다.