제텔카스텐의 엔트리포인트 메모는 글의 주제가 될 수 있는 뼈대이자, 주제 색인에서 링크되는 특정 주제에 대한 개요를 제공하는 메모이다(ref5). 더 좋은 개요가 생각난다면, 이 메모는 언제든지 바뀔 수 있다(ref3,ref4).
주제애 대한 개요를 바꾸고 싶다면, 주제 색인에서 엔트리포인트 메모로 가는 링크만 수정하면 된다.
엔트리포인트 메모는 또다른 엔트리포인트 메모나 세부 메모로 연결된다. 이렇게 여러 메모로 향하는 허브가 메모들 중간중간에 존재한다면 검색 없이도 메모를 찾는 좋은 이정표가 될 수 있다. 물론 꼭 개요가 아니더라도 원자적인 메모 하나가 아주 훌륭한 엔트리포인트가 되는 것도 가능하다(ref1).
엔트리포인트 메모는 왜 필요할까? 사람은 구체적인 것을 모두 기억하지 못하기 때문이다. 사람의 머리는 언제나 추상적인 감상만 남기고 삭제함으로써 최적화된 상태를 유지한다. 소프트웨어 공학에서도 유사한 특징이 나타난다. 좋은 변수 이름을 짓거나 코드를 함수와 클래스로 감싸는 이유는 바로 복잡한 것을 단순하게 바라보고, 기억할 필요가 없는 것을 추상적으로 바라보기 위함이다.
엔트리포인트 메모를 앞서 말한 추상화 수준의 관점에서 바라본다면, 엔트리포인트 메모는 어떤 문제든 추가 레이어를 만들음으로써 어떤 문제도 풀 수 있다고 시사하는 소프트웨어공학의 기본 정리와도 밀접한 연관이 있음을 발견할 수 있다.
We can solve any problem by introducing an extra level of indirection.(ref2)
엔트리포인트 메모는 우리가 기억하기 어렵지만 실질적이고 구체적인 메모에 빠르게 도달하기 위해 필요한 사고의 시작점이므로, 추상적인 의미를 가질 것이라고 해석할 수 있지 않을까.
책에서는 어떤 주제에 대해서 생각 줄기의 시작점은 정말 신중하게 잘 선택된 최대 2~3개의 메모가 되어야 한다고 강조한다. 나도 이 글을 처음 작성한 2021년부터 이 원칙을 이해하고 지키고자 노력하고 있다.
하지만 소프트웨어의 역사는 막무가내로 추상화 계층을 쌓아올리는 경우 어떤 문제가 있을 수 있는지를 적나라하게 보여주기도 한다. 이러한 고통을 극복하기 위한 학문 소프트웨어공학은 개발자가 어떻게 수많은 코드 더미에서 더 쉽고 빠르게 코드를 읽고 쓸 수 있는지에 대해 연구했다. 소프트웨어공학에서는 이를 디자인패턴이라는 이름으로 설계한다.
소프트웨어공학의 패턴을 개인의 메모에 그대로 사용할 수 있으리라 생각하지는 않는다. 그럼에도 불구하고 소프트웨어공학이 추구하는 실용적 재사용이라는 방향이 메모와 어떤 연관이 있는지 고민해 본다면 이들 둘의 본질적 공통점과 차이점을 이해했을 때 메모에는 새로운 지평이 열릴 것이라고 믿는다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
1.
•
앞의 글은 제텔카스텐이라는 것을 내가 흉내만 내고 있다는 공포감과 고민이 깊어지던 순간, 본질을 이해하기 위해 자신을 돌아보기 시작했던 순간의 엔트리포인트다.
2.
•
어떤 사람이 Makefile 로부터 CMake 라는 도구가 나타나는 과정을 소프트웨어공학의 기본 정리를 이용해 설명한 글에서 영감을 받았다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
1.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
ref : 생각에 참고한 자료입니다.