프로그래머의 뇌를 다 읽고, 난 후의 내 뇌를 돌아보는 시간

const job = '프론트엔드';·2024년 1월 19일

프로그래머의 뇌

입사 후 사내 개발자들과 책 1권을 정해서 일정 분량을 읽고, 그 생각을 교류하는 시간을 가져왔다(스터디라 쓰고, 친목이라 읽음).

첫번째 책은 프로그래머의 뇌 이걸 다 읽으면 내 뇌도 프로그래머의 뇌가 될 수 있겠지? 라는 기대로 읽었고, 마지막 챕터를 읽을 때 까지도 나는 그런 기대를 했다.

다 읽고 난 후, 내 뇌는?
그냥 가영이의 뇌다.

책이 별로였나? 아님. 내가 별로라고 생각함.

스터디 방식

일정분량을 각자 읽고 깃에 자유롭게 이슈를 남긴다. 그리고 일주일에 한 번 읽었던 내용에 대해 토론한다.

감상문의 형식은 자유로웠다. 나는 어렸을 때 방학숙제로 쓰던 감상문 형식에 독후감을 썼고, 다른 스터디원들은 짧게 내용을 요약하기도 했다.

지금 다시 내가 이 책을 읽으며 쓴 감상문을 순서대로 읽어보는데, 저 당시에 내가 느끼던 고민과 좌절 그리고 자기합리화(이게 제일 많음)가 다시금 떠올랐다. 그리고 챕터 마지막으로 갈수록 나는 반성문을 쓰고있었다.

챕터 01
첫번째 챕터에서 다른 사람의 코드를 보고 '어? 잠깐.. 이 부분은 뭐지?'라고 했던 내가 '몰라서'가 아닐 수도 있다는 생각을 했고, 약간의 마음의 위안이 됐다. 왜냐하면 개념을 몰라서(지식의 부족, 정보의 부족)가 아니라, 이해하려고 노력할 때(처리 능력의 부족) 발생할 수 있었던 혼란 이었을지도 모르기 때문이다. 처리 능력의 부족이 잘했다는 것은 아니지만 코드를 작성한 사람이 이해하기 어렵게 코드를 짰을 것이다....라는 그런 합리화를 했다. 그리고 이 책에서도 언급하고 있듯이 최근에는 라이브러리, 모듈, 패키지 등이 다양하기 때문에 모든걸 다 아는 개발자는 있을 수 없다고 생각한다. 아무튼 그렇기 때문에 LTM(장기기억장치)와 STM(단기기억장치)을 적절히 활용해서 코드를 보는 능력을 키우면 좋겠지만 그게 되려나 모르겠음

챕터 02
두번째 챕터에서 앞서 느꼈던 내용이 등장했다. '개발 경험이 많더라도 코드를 빠르게 이해하기 어렵다.' 첫번째 챕터에서 느꼈던대로 원인을 미리 찾아보자면 첫번째, 라이브러리, 모듈 등이 다양해졌기 때문에, 두번째, 코드를 작성한 사람이 자기만 알아보게 코드를 작성했기 때문에 정도로 생각했고, 정확히 일치했다. "프로그램은 사람이 읽을 수 있도록 작성해야 한다.", 특히 협업의 경우 필수라고 생각한다. 그래서 보통 협업에서는 본격적으로 개발에 앞서 변수명을 정할때 규칙부터 정해놓는 것이 일반적이다. 그러면 코드를 읽는 속도가 빨라질 수 있다. 예를 들어 규칙대로 만든 변수명만 보더라고 '아 이거는 어떤 목적을 위해 만들어진 변수구나'라고 넘어갈 수 있기 때문이다(이것이 바로 LTM을 활용하는 방법). 이밖에도 이 챕터에서는 주석을 다는 방법, 디자인패턴을 만드는 방법, 표식을 하는 방법 등을 소개하고 있다.

챕터 03
지난 챕터 1, 2에서는 코드 이해가 어려운 이유에 대한 합리화 시간이었다면, 이번 챕터3에서는 반성의 시간이었다. 마치 나를 CCTV로 지켜보고 있다가 문제점을 책으로 써낸 기분이었다. 예를 들어, 새로운 코드를 처음봤을때는 당연히 모를 수 있다. 하지만 다음에 또 봤을 때는 개선된 모습이 보여야 한다. 그 개선을 위한 노력이 필요하단 의미다. 이 챕터에서도 지적하듯이 '구글에 검색'이 너무나 생활화 되어있다는 생각이 들었다. 어쩌다 한 번 쓰거나 앞으로도 쓸 일이 없지만 현재 업무나 과제를 위해 필요한 경우를 제외하고는 늘 사용하는 기능은 검색을 하지 않고도 잘 알고 있어야 한다. 그냥 언젠가 익숙해 지겠지~라고 생각한게 벌써 오늘이다..

챕터 04
이번 챕터는 소제목부터 혹하게 만들었다. 뭔가 '이 챕터를 읽으면 복잡한 코드를 읽는 노하우를 배울 수 있겠지?'라고 생각했다. 제시된 방법 중 하나, 하나를 나라면 할 수 있을까? 라고 대입해 보았다. 아니, 안되겠다. 특히 의존 그래프 생성에서는 깜짝 놀랐다. 마치 영어 독해를 하는 느낌이었다. 또 처음 자바로 알고리즘을 공부할 때 알고리즘의 예상 결과를 하나씩 그리면서 다음 코드를 한 줄, 한 줄 적어본 적이 있고, sql을 공부하면서도 데이터의 결과를 하나 하나 적어가며 작성해 본 기억이 있다. 이런 것도 하나의 방법이 될 수 있을까?라는 생각을 잠시 하긴했다.

챕터 05
이번 챕터 5는 쉽지 않은 여정이었다. 와 닿는 문장은 '기억은 따로 저장되는 것이 아니라 다른 기억들과 연결되어 있다.' 이 부분이었다. 뇌가 그렇게 구조화 된 것 같다. 그래서 외우려고만 하지말고 연상기억법을 이용하라고 했던 말도 생각난다. 아 그리고 사야니에미가 정의한 11개의 역할을 보고 개발자는 코드를 짤때 그냥 로직만 생각해야 하는게 아닌게 몸소 와닿았다. 왜 코드를 짜다가 갑자기 화면을 뚫어지게 쳐다보는지에 대한 이유가 이러한 과정때문이 아닐까 조심스럽게 생각해보았다.

챕터 06
역시 호락호락 하지 않았다. 코드를 작성할 때 고려해야 할 요인이 너무 많다는 대목에서는 공감했다. 그렇지만 코드는 완벽한 완성이 없기 때문에 지속적인 유지보수가 늘 필요하다. 얼마전에 나도 진짜 완벽하게 모듈을 짰다고 생각했다. 하지만 갑자기 여러가지 변수가 나타나면서 내가 생각했던게 엉망이 되었다. 이 책에서는 사용의 용이함, 성능, 변경 가능성 중 어느것에 비중을 더 둬야 하는지를 고민하지만, 아마 대부분의 개발자는 코드를 짜면서 이 세가지 요소를 한꺼번에 고민하 것이다. 재사용을 하는 것도 '미래의 나', 성능 최적화도 '미래의 나', 유지보수 역시 '미래의 나'의 몫이기 때문이다. 그리고 희망적인 것은 이 책이 전반적으로 뭘 중요시 하는지 눈치챘다는 것이다. 이 책은 '관계'에 중점을 두고 있다. 그러니까 코드를 빠르고 쉽게 이해하려면? 코드안 요소간의 관계를 중점적으로 보라는 얘기를 하는 것 같다. 그냥 나만의 생각일 수 있지만 그런 느낌을 강하게 받다가 갑자기 챕터 6이 끝나버렸다.

챕터 07
이번에는 뭔가 와닿는 부분이 조금 있었다. 특히 두번째로 배우는 언어가 더 쉽게 느껴진다는 부분, 나는 지금까지 만나는 사람들에게 '자바가 세상에서 제일 어렵다.'라고 했다. 자바는 내가 개발을 함에 있어서 처음으로 배웠던 프로그래밍 언어다. 이후 다뤘던 자바스크립트도 어려웠지만 자바에 비하면 별거 아니라는 생각을 했고, 파이썬은 지금까지 다뤘던 언어중에 제일 쉽게 느껴졌다. 이게 바로....전이?아닐까? 여기 까지가 전이의 순기능 이라면, 역기능은 아마도 '편견'이 아닐까 생각해 보았다. 프로그래밍 언어는 유사하지만 자세히 보면 다른 부분이 어마무시하게 많다. 예를 들어 R에서는 배열의 인덱스가 1부터 시작하는데 반해, 자바스크립트 등등의 배열 인덱스 시작은 0부터 시작하는 것 처럼 ! 애초에 자바스크립트를 배우고 R을 배우는 사람은 별거 아닌 인덱스 시작 순서에 생각보다 혼란스러워 할 수 있기 때문이다. 그렇지만 이 챕터에서 '이미 알고 있다는 것은 저주인가, 축복인가?'라는 질문에 나는 그래도 모르는 것 보다 하나라도 아는게 더 낫다고 생각해버림 하하

챕터 08
변수명을 짓는 것이 최대 난제이기도 하고, 최고의 고민거리다. 진짜 변수명을 지어주는 기계가 있었으면 좋겠다고 생각할 때가 한 두번이 아니다. 이번 챕터에서는 정말 당연하고 옳은 말 뿐이었다. 이 책에서 만큼은 아니더라도 비스무리하게 변수명은 이렇게 지어야해 ! 라는 사실은 언뜻 알고 있었다. 하지만 막상 닥치면 그게 생각대로 와 미쳤는데? 나 이거 변수명 엄청 잘 지은듯? 이런건 없었다. 언제나 변수명을 짓고 다음 코드를 써내려 가면서 찝찝함이 함께 였다. 이론적으로 알더라도 그 이론이 내제화되어 나 스스로가 변수명을 짓는 기계가 되기까지 그동안 수 많은 찝찝함을 거쳐야 할 것 같다.

챕터 09
9번째 챕터를 읽으면서 처음부터 끝까지 '오...아...오ㅏ..'를 멈출 수 없었다. 내가 항상 추구하는건 나도 쉽고, 다른 사람이 봤을때도 그냥 읽히는 코드 였으면 좋겠다는게 나의 바람이다. 그런데 나의 코드는 이 챕터에서 설명하는 코드 스멜이 넘쳐난다. "작동은 하지만 개선의 여지가 있는 코드" 앞서 다른 챕터를 읽을 때에도 '세상에 완벽한 코드가 어디 있겠어.' 라는 생각을 했지만 내가 그동안 작성했던 코드는 합리화하면서 흐린눈 하기엔 너무 코드 스멜이 굉장히 많다. 물론 머리로는 '지금 이게 그때 그 로직이나 코드랑 비슷하니까 이거를 이렇게 해서 이렇게 하고 저렇게 리팩토링 해야지!'라고 생각한다. 하지만 코드를 계속 작성하다보면 그런 상황의 연속이다. 아무튼 이거는 나의 문제점이고 다시 본론으로 넘어가자면 파울러가 정한 22가지 코드 스멜에 하나도 빠짐 없이 내가 포함되는 기분이라 책을 빠르게 읽을 수 없었다. 나아가 현재 이 책에서 설명하는 언어적 안티패턴 역시 이름을 잘 지어야 한다는 또 다시 죄책감이 들게 했다.

챕터 10
10번째 챕터 제목은 '복잡한 문제 해결을 더 잘 하려면'이다. 나는 제목을 읽고 '또.....제목으로 플러팅하는구나' 생각했다. 그러다가 LTM 학습법 부분에서 왜 이 책은 계속 맞는 말만 하는데, 왜 거부감이 잔뜩 들었는지 이유를 찾았다. 첫번째, 나는 정보가 들어왔을때, 혹은 활용할 때 뇌가 하는 일이 궁금하지 않았다. 두번째, 나는 노력없이 문제를 쉽게 해결하거나 쉽게 코드를 작성하거나 쉽게 이름을 짓고 싶었다. 하지만 여기에서는 '노력해야 한다. 꾸준히 학습해야 한다.'라고 하기 때문에 나는 스스로 거리를 둔 것이다. 그러던 와중에 '자...동...화??'이게 가능할까? 라는 생각을하며 이 부분을 읽었고, 엄청 큰 공감을 했다. 일전에 이 책에서도 소개되었던 에빙하우스의 망각곡선에서도 처음에는 30분만에 다음에는 4시간만에 뭐 이런식으로 간격을 두고 같은 것을 반복하면 무슨일이 있어도 잊지 않는다는 것이 이 원리이다. 나도 혼자 공부할 때 다들 리덕스가 필수라고 하니, 해보긴 해봐야겠고, 과거 리덕스를 써봤다고 면접에서 얘기했더니 리덕스에 대한 프로세스를 설명해달라는 질문을 받은적 있었기 때문에 어쩔 수 없이 혼자서 작은 프로젝트에(리덕스 상태관리가 전혀 필요없는)리덕스로 상태관리를 했었다. 내재화 될 정도로 여러번 했었다. 근데 막상 리덕스를 쓸 기회가 없었고 지금은 '그치 이런게 있었어. 맞아맞아 거기에 넣고 뭐 보관하고 그랬었지' 이 정도의 스치는 기억이 되었다. 이 외에도 api 통신을 해봐야 하는데, 하면서 온갖 공공데이터 포털에서 공공api로 혼자 통신해보고 그랬던 기억이 있다(어찌보면 암시적 기억 개선 행위이기도). 하지만 이 또한 늘 반복되는 일이 아니라 자동화시키지 못했다. 아무튼 두가지 경험 다 자동화 실패사례닼ㅋㅋㅋ하핳 하지만 인수분해 예시를 보고 기억나는거 보면 우리나라 교육 좀 하네?라고 생각했다.

챕터 11
이 챕터에서는 뇌가 프로그래밍을 '더' 잘하게, 그러니깐 더 잘 기억해내고, 더 잘 인지해 낼 수 있도록 여러 단계의 방법을 설명하고 있었다. 예를 들어 노트를 하면서 하던지, 혹은 주석을 적는 등의 방법을 설명한다. 며칠간 이 방법처럼 노트를 하기도했고, 주석을 달아 보기도 했다. 확실히 노트를 하면 마치 todo 리스트를 작성한 것인가? 라는 생각을 하기도 했지만 어쨌든 안하는 것보다 낫다는 생각을 했다. 물론 이번 챕터와 논외의 얘기지만 중간에 '리팩터링'이라는 키워드가 나왔고, 갑자기 리팩터링의 객관적인 기준이 있을까? 라는 생각도 스치듯이 해봤다. 아무튼 본론으로 돌아와서 며칠간 이 책에서 문제를 더 깊이 생각할 수 있는 마음의 여유를 확보할 수 있다는 얘기에 설계의 방향과 결정 사항을 노트에 적어내려 갔었고,�그래도 굉장히 만족스러웠다고 스스로 평가할 수 있었다. 하지만 마음의 여유는 아쉽게도 확보하지 못했다.. 더 인상 깊었던 내용은 '업무 중단'이다. 뭔가 사장님이 보면 좋아할 것 같은 주제였다고 생각한다. 그 이상 그 이하도 아니었고, 일단 공감하지 못해서 아쉽다. 공감할 때가 된다면 내가 사장이 되었을 때가 아닐까...? 크흠

챕터 12
역시나 '일관성' 함수를 표시할 때, '함수명()'이런 형태면 함수다! 라는 우리 끼리의 암묵적인 합의 같은 것들이라고 할 수 있는 부분이다. 이건 모든 개발자들(아마도..?)과의 약속이지만 협업을 할 때는 우리끼리만의 이러한 일관성 있는 코드 형식이 중요하다는 사실을 마지막까지 강조하는 부분이 아닐까 싶었다. 또 숨겨진 의존성......이 부분에서 의존성을 채택하고 '문서화'얘기가 나와서 조금 소름이 돋았다. 또 공감할만한 이야기는 IDE의 색상 기능이 아닐까 싶다. 그냥 메모장에 코드를 작성하거나 cmd창에 코드를 작성했다면 아마도 나는 코딩을 시작도 하지 않았을 것이라고 단언한다. 익숙해서 지금은 느끼지 못하지만 진짜 코드를 작성하기에 엄청 편리한 기능이 아닐 수 없다. 이 챕터도 마냥 읽어 내려가다가 공감하지 못할 소제목이 있었다. '힘든 정신 활동'...내가 이해한 바로는 시스템을 이해하기 위해 많은 생각할 해야 한다는 표현을 힘든 정신 활동이라고 할 것일까? 그렇다면 공감해보겠다. '아무튼 많은 시간과 노력없이도 코드를 단번에 쉽게 알아 볼 수 있는 방법(그것에 IDE 익스텐션도 포함)으로 코드를 짜자! 는 것이 이 챕터의 핵심으로 생각된다.

챕터 13
마지막 챕터. 새로운 개발자 팀원의 적응 지원. 이 부분에 대해서는 아직 먼 미래라 생각되어 그냥 마음속에 저장만 해둘 생각이다. 제일 처음 개발자로 취업을 했을때, 전체 서비스 코드를 받았고, 이 서비스가 어떤 구조로 되어있는지, 어떤 언어를 사용하는지 모든걸 스스로 혼자 파악하고 파일 구조도 혼자 다 확인했어야 했다. 만약에 처음 회사에서 선임 개발자가 이 책에서 말하는 정도의 무슨 라이브러리 인지 어떤 프레임워크고 데이터 구조는 어떠했는지를 좀 더 친절하게 지원해줬다면 현재도 그 회사에 다니고 있지 않았을까? 뭐 그런 생각을 하게 하는 마지막 챕터였다.