Draft

src/_drafts/scratchpad.md

@@ -0,0 +1,86 @@
+
+일단 어떻게 구독하지?
+
+뉴스레터를 쳐내게 된 계기
+
+## Tip:
+1. Gmail을 사용하고 있다면 <handle>+<identifier>@gmail.com 포맷으로 입력을 받는 것을 적극적으로 권장
+
+2. 이메일 클라이언트의 분류 기능을 적극적으로 이용한다.
+3. Glasp 이라는 Web Highlighter를 이용해서 인상 깊은 부분은 줄치고, 한 곳에 모아둔다.
+4. 아카이빙 된 것들 일부는 계속 모아두었다가, 필요할때 인용할 수 있도록 한다.
+
+## 뉴스레터를 구독하는 이유
+1. 지속적으로 내가 접하지 않은 관점을 얻기 위해서
+2. 지속적으로 새로운 지식을 접하기 위해
+3. 지속적으로 트렌드가 어떠한지 타임라인을 파악하기 위해서
+4. 업계에서는 어떤 목소리가 주로 언급되고 있는지 파악하기 위해서
+
+## 뉴스레터를 쳐내면서 느끼는 것
+1. 좋은 글을 알아볼 수 있는 능력
+	• 당연하다. 추천수를 많이 받은 게시글,  추천수를 많이 받은 프로젝트 들이 중심이 되어서 소개가 되고, 뉴스레터를 발행하는 사람들은 개인의 부수입 수단으로 운영하는 경우가 많기 때문에 최대한 양질의 글을 큐레이션 하려는 경향이 있다. TLDR 뉴스레터는 이미 그런식으로 사이드잡으로 큐레이션할 사람을 주당 100달러 이상 페이를 준다는 조건으로 모집하고 있다.
+2. 여러 출처에서 봤던 것을 또 보게 되는 경향이 있다.
+	• 1과 유사한 이유인데, 하루 동안에 좋은 글이 올라오거나, 레딧/해커뉴스 등지에서 소개되는 글의 양은 한정되어있다.  그 중에서 높은 Upvote를 받은 게시글들이 뉴스레터에서도 소개되는 경향이 있기 때문에, 어딘가에서 봤던 아티클이 다른 뉴스레터에서도 관찰되는 현상을 자주 목격할 수 있다.
+3. RSS 리더 같은 시작과 끝이 없는 타임라인이 아닌, 매주/격주/혹은 수시로 발행되는 딱 정해진 수량만큼의 소식들이 소화할 수 있는 chunk 단위로 흘러들어온다.
+4. 어차피 지금 읽어봤자 이해하기 어려운 것들이 많다. 마치, 들을 준비가 되어있지 않았는데 누군가의 조언을 억지로 듣고 있는 것과 같다. 우리는 실감이 되는 것도 아니기에, 당장 필요로 하는 것도 아니기에, 준비가 되지 않았기 때문에 시간을 들여서 읽는것이 무의미할 수 있다. 당장 필요하면 그때는 달라질 순  있다.
+5. 모든 것을 다 하려고 할 필요가 없다. 목적없는 수용은 오히려 불필요한 인지자원을 소모할 뿐이다. 이건 내가 이러이러한 강력한 동기부여가 있기 때문에 읽어야 한다라는 생각이 드는게 아닌 이상 너무 주입하려고 할 필요가 없다.
+
+
+
+## 뉴스레터를 쳐내는 마인드셋
+1. 무엇보다도 중요한  것은 어떤 것이 중요한가?
+2. 뉴스레터를 쳐내는데 걸리는 시간은 아무리 오래 걸려도 1시간
+3. 당장 읽는게 의미있을 것 같은데, 이후에 좋은 참고자료가 될 것 같다면? 일단 분류함으로 죄다 때려박아!
+4. 바로바로 스키밍하기 어렵다고 판단되는 글이라면 ChatGPT에 요약 질의를 넣어보고 판단을 유보할 수도 있음.
+5. TLDR  같은 뉴스레터는 읽는데 얼마 정도 시간이 소요되고, 어떤 내용이 주로 설명되어 있는지 서술하기 때문에 바로바로 넘길지 일단 읽을지 혹은 backlog에 넣을지 전략적인 판단에 도움이 된다.
+##주기적으로 해야하는 다른 일과의 줄다리기
+
+우리에게 시간은 한정되어 있다. 하루에 쓸 수 있는 시간은 고작 24시간이다.
+사실 뉴스레터를 읽는 행위는 24시간 중 일부를 희생할 수도 있다는 것이다.
+
+1. 독서는 어떻게 시간을 확보할 건데?
+2. 사이드프로젝트할 시간은 어떻게 확보할 건데?
+3. 블로그에 글을 정리할 시간은 어떻게 확보할 건데?
+4. 직무를 위한 공부는 어떻게게 확보할 건데?
+
+적당히 선택과 집중을 해야할 필요가 있다.
+
+## 느끼는 점
+
+
+===========
+
+
+신호 대비 잡음을 계속해서 가려낼 수 있는 능력을 키우기 위한  의도적인  휸련
+영어로 된 정보가 넘쳐나는 와중에도 그 중에서 옥석을 가려내는 것을 의도적으로  해낼  수  있는 리터러 키우기
+학부생 시절때 하던 뉴욕타임즈/테크크런치 등등의 출처를 일단 막 읽어보기를 했던 것과는 다른 목적성이 있는 뉴스 수집
+
+정보의 홍수? 오히려 내가 어떤 정보를 받아들일지 의도적으로 통제하는 것.
+SNS를 모니터링하는 것보다는 나름 엄선된 컨텐츠가 많이 흘러들어오고 있음.
+
+인공지능에는 당장 손을 댈 일은 없지만, LLM에 대해 이것저것 재밌는 시도를 하고 있는 사무엘 윌슨의 글은 정기적으로 챙겨보고 있음
+
+디자인에는 그렇게 큰 관심은 없지만, 디자인 하는 사람들은 어떤 생각을 하는지 살펴보기 위한 목적의 글은 간간히 챙겨보고 있음
+
+
+난 애초에 React 쪽 외에는 어지간하면 관심을 가지지 않는 성향.
+그래서 Svelte 걸러.
+Vue 해봤지만 깊게까지는 해보고 싶지 않아서 걸러.
+Angular 개발경험 좀 구렸던게 기억나서 걸러.
+Solid? Signal이라는 개념이 Preact에도 들어가있는 것 같아서 안테나는 열지만 Reactivity를 원론적으로 접근해서 설명하는 것 외에는 일단 관심을 안 기울여
+Astro? 일단 뭐 진입장벽은 크게 있지는 않아서 일단 귀는 열어.
+
+근데?  어쩌다보니 Island 아키텍쳐라는걸 알게 되었는데?  JS 프레임워크를 쓰지 않는 내 블로그 엔진이 아일랜드 아키텍쳐를 지원하네? 그래서 그때부터 좀 기술적인 호기심은 생겼지. less JS를 지향하는 블로그엔진이 아일랜드 아키텍쳐를 지원한다니
+
+마침, 내 블로그는 매번 페이지를 빌드할때마다 문서 갯수의 제곱에 비례하는만큼 빌드타임이 늘어날 수  밖에 없는 구조를 가졌어.  왜냐면, 페이지 랜덤 이동을 지원하는 어떤 기능이 있었는데 그 기능에 대한 자바스크립트 코드가 모든 위키 페이지 문서마다 박혀있었고, 문서가 100개가 있으면 100개의 문서에  대한 랜덤이동을 지원하는 코드가 100개의 페이지에 깎여져 나가는 문제가 생길 수 밖에 없었어.
+
+내부 문서 간의 연관관계를 그래프로 시각화하는 코드도 역시, JSON 오브젝트가 하나의 HTML 파일에 그대로 들어가서 HTML 코드 자체의 사이즈가 방대해지는 문제가 있었는데,  JSON OBject도 하나의 파일로 분리할 필요가 있었고,  그래프로 시각화하는 자바스크립트 코드도 역시 별도의 스크립트 파일로 분리될 필요가 있었어.
+
+태클 걸릴만한거
+	• 자바스크립트 파일로 따로 분리해도 되지 않았나?
+	• 굳이 왜 아일랜드를 이용해야만 했나?
+	• 그냥 자바스크립트 import + 웹컴포넌트가 아닌가?
+	• 사실상 웹 컴포넌트가 아닌가?
+	• 웹컴포넌트와는 어떤차이점이 있지?
+
+