이직
최근에 이직을 준비하면서 내가 했던 일들에 대하여 정리해보고 예상 질문도 스스로 해보고 하는 시간을 가졌었다. 결론부터 말하자면 이직에 성공 하였고 요즘 뜨고 있는 B2B 서비스를 하는 회사로 결정 하게 되었다.
먼저 프로덕트가 마음에 들었고, 테크 면접, 동료 면접, 대표님 면접 3가지를 진행 하게 되었는데 각 면접 마다 특별히 불편하다는 점이 없었고 면접 보다는 내가 했던 일에 대하여 토론하고 앞으로 이 개발 또는 일하는 방법, 회사에 대하여 어떻게 생각하는지 핏을 맞춰 보는 자리라고 해두는 것이 더 바람직해 보였다.
특히 이 회사는 아직 베일에 쌓여져 있어서 정보들이 없었는데 개발자인 만큼 프로덕트 위주에 사업, 조직 역시 프로덕트 위주로 조직이 구성된 점이 매력적으로 느껴졌고 프로덕트 위주인 곳에서 개발자가 프로덕트를 만들려면 어떻게 해야하고 많은 노력들이 필요한가에 대하여 궁금하기도 했고 약간 설레기도 해서 결정을 하게 되었다. (간만에 사업했던 열정이 불타오르는...)
무튼 서론이 길었지만 면접을 준비하는데 가장 어려운 점은 내가 알고 있는 것을 얼마나 정리하냐였다. 물론 알고 있는 개념인데 무언가 뜬구름 처럼 내 머리속을 해짚고 다니는데 정확하게 정리가 안되면서 면접에서 대답 못한 것들도 분명 있었기 때문이다.
먼저 나는 기본적으로 3가지 방법으로 내가 아는 분야에 대하여 정리하고 기록한다.
1. 블로그
2. github read-contents
3. github tip-til
기록
1. 블로그
당연하게도 velog 외에는 쓰지 않고, 기본적으로 진행한 토이프로젝트나 사실 회사에 들어가면 회사에 기술 스택을 미니멀하게 따라서 구성해보기도 하는데 그런것들을 기록해본다.
하지만 블로그다 보니 써야할 내용도 많고 정리해야할 내용도 많아서 사실 쫌 습관적으로 쓰기란 힘들다.
2. github read-contents
여러가지 뉴스레터 또는 카톡방, 슬랙 등 다양하게 인사이트를 얻으려고 노력하고, 인사이트를 얻는 부분에 대해서는 github 에 짤막한 요약과 함께 기록한다.
월별로 기록하고 기록하다가 조금 감명 깊거나 오래보고 싶은 내용이 있으면 README 로 올리게 된다.
3. github tip-til
이부분은 어디에 쓰기도 애매하고 짤막하게 개발하다가 얻은 지식들을 기록하기 위함인데, 어디선가 보고 나도 해봐야 겠다 싶어서 따라서 해보고 있다.
뭐 나름 괜찮고 정리도 잘 되어가는듯 하다.
문제
그런데 위와 같이 3가지를 진행 하다보면 여러가지 문제들이 생긴다.
content 를 읽다가 엇 이게 뭐지? 하는 부분이 나오면 찾아 본 다음에 tip-til 에 기록 하기도 하는데 아 그런거구나 하면서 넘어가는 부분도 있다. 그럼 기억속에 잊혀지고 나중에 다시 찾기가 어려워진다.
또한 개발하다가 모르는 개념들이 나오면 기록은 하지만 개발 특성상 연관된 개념들이 있다. 이런것들 까지 따로 기록 하다보면 정보가 너무 산발적이라 내 머리속에 정리가 안되는 경향이 있다.
이렇게 정리가 되지 않은 문제들은 나중에 면접을 보거나 대화를 할때 자신감 있게 나오지 못하게 되고 개발을 할때에도 나에 온전한 지식이 아니기 때문에 바로 사용할 수 가 없다 (흔히 말하는 LTM 에 저장 되어있지 않기 때문에 바로 적용 할 수 없다)
또 책도 읽게 되는데 그럼 책을 읽고 나면 어디다가 정리해야하지? 이런 생각이 들기도 한다. 지금은 노션을 이용하고 있긴 하지만 사실 공개된 부분은 아니기 때문에 적진 않았다.
그러다가 우연하게 같이 일했던 팀 동료에게 제텔카스텐 이라는 것을 알게 되었다.
내가 정말 원하고 찾던 것이였다. 그래서 이 제텔카스텐 을 간략하게 소개해보려고 한다.
해결
모든 문제가 그렇듯 만능 해결책은 없다.
하지만 제텔카스텐 은 개발자에게 정말 많은 도움이 되는 메모 방법론? 정도라고 할 수 있겠다.
먼저 제텔카스텐 에 대한 배경 지식은 따로 정리하지 않겠다.
제텔카스텐 이라는 책도 있고 검색해보면 수많은 블로그글들 있다.
물론 글을 쓰기 위한 메모 방법론이라고 하지만 어차피 개발자들도 글을 쓰는 사람이고 대부분의 사람들이 글을 쓴다. (흔히 말하는 일기라고도 할지라도...)
하지만 일단은 글을 쓰기 위해서는 상당한 정리가 필요한데 이 정리 부분을 잘 이야기해주고 있고 이 정리부분이 개발과 정말 잘 맞는다 라는 생각이 들어서 한번 해보는 중이다. (역시 개발자인 만큼 똥인지 된장인지 먹어봐야 적성에 풀린다)
간략하게 방법을 설명해 보겠다. (물론 나만의 방법이 살짝 섞여있다)
- 책을 읽거나 다양한 곳에서 얻는 지식에서 필요한 부분은
임시 메모에 메모한다.- 2 ~ 3 일 내외에 이
임시 메모를 바탕으로영구 보관용 메모를 작성해야한다.영구 보관용 메모는 반드시 나의 글로 작성해야하고 단순히 글을 복사하거나 해서는 안되고 나의 생각과 나의 의견으로 한 문단이 되도록 작성해야한다.영구 보관용 메모를 작성하고 나면 기존에 있던영구 보관용 메모와 관련되어있는 메모이면 이 메모들을 연결 시켜준다.
여기서 핵심은 나의 글 과 연결 이다.
일단 나의 글 이란 단순히 어떤 내용을 보고 옮겨 적는것이 아니라 이 주제가 어떤 의미를 가지고 있지? 이 주제가 어떤 부분과 연관 되어있지? 라고 생각을 하면서 나의 글로 적는 것이다. 책에서도 어떤 강의를 들을때 메모하는 방법에서 타이핑과 글쓰기를 예로 들고 있는데 두가지 방법다 단기적인 이해도에는 차이가 없지만 나중에 기억속에 오래 남는건 글쓰기라고 이야기하고 있다.
그 이유는 단순히 글을 써서가 아니라 타이핑은 속도가 빠르기 때문에 강의의 내용을 온전히 다 받아 적을 수 있지만 단순히 그 역할 만 할 뿐이고, 손으로 글을 쓰게 되면 아무래도 나의 의견, 나의 생각이 들어가기 때문에 그 글이 온전히 나의 것이 될 확률이 높아지기 때문이라고 이야기하고 있다.
이 이야기에 많이 공감을 하였고, 그동안 나또한 어떤 개념에 대하여 검색하여 찾아내면 단순히 복붙을 통해서 기록을 한 경험이 많았다. 물론 임시 메모 를 작성 할때에는 그래도 되지만 영구 보관용 메모 를 작성 할 때에는 나의 글 로 작성하는 것이 핵심이다
두번째 핵심은 연결 이다. 어떤 특정한 주제에 관해서 나의 글 로 작성 했다면 이 글이 기존에 작성된 글과 어떤 연관성이 있을까를 고민 한 후에 연결 시켜야 한다고 한다.
즉, 연결 이 되면 어떤 개념에 대하여 다시 찾을때 그와 연관된 여러가지 개념들을 볼 수 있게 되고, 이를 통하여 새로운 사고? 또는 잘못 기록된 메모들을 수정 할 수 있는 기회가 된다고 한다.
특히, 이 연결 이라는 부분에 대하여 고민을 좀 하고 있었다. 실제로 github tip-til 여기서는 tag 를 통하여 비슷한 개념들 끼리 묶고 있었는데 실제 연결을 하면 더 보기 편하고 개념을 쉽게 찾아갈 수 있을거란 생각이 든다.
마지막으로 이건 온전히 개인적인 생각인데 어떠한 지식이 온전히 나의 것이 되려면 적당한 시간을 두고 반복해야 한다고 한다. 그런데 이 제텔카스텐은 임시 메모 를 통하여 빠르게 내용을 메모하고 영구 보관용 메모 를 작성 할 때 또 그에 대한 개념을 다시한번 보게 되고 이 메모들을 연결 시키려고 할 때에 또 그와 연관된 메모를 찾기 위해 메모들을 다시 보게 되니 엄청난 반복이 반복되고 있는 셈이라고 생각한다. 그렇게 되면 기억도 오래 남을 거라고 감히 예상해 본다.
실제로 나는 임시 메모는 관리하기 편하고 사용하기 쉬운 노션을 이용하고 있고 영구 보관용 메모는 이번에 알게된 옵시디언을 이용하고 있다.
옵시디언에 장점은 다음과 같이 시각적으로 연결을 볼 수 있다는 것이다.
실제로 제텔카스텐 을 만든 루만 교수는 이러한 툴들이 없었기 때문에 각 메모마다 인덱스를 부여하여 연결을 시켰다고 하는데 우리는 너무 많은 툴들을 사용할 수 있기 때문에 루만 교수 보다는 좋은 환경에 처했다고 생각한다.
단지 우리가 할것은 실행 일 뿐이다.
이런식으로 내가 어떠한 개념에 대하여 온전히 생각하고 연결 짓는 다면 나중에 큰 자산이 될거라고 생각하고 책에서는 두번째 뇌 라고 표현하고 있다.
물론 기억은 휘발성이지만 최대한 오랫동안 기억속에 남겨 놓아야 개발을 할 때에 쉽게 꺼내쓸 수 있고, 이런 기억들을 바탕으로 다양한 인사이트를 얻을 수 도 있을거라고 생각한다.
그렇기 때문에 단순히 내가 보고 기억해야할 것들을 기록하기 보다는 이 방법론을 한동안 써보려고 한다.
