rinae's devlog

Dohyung Ahn

General
역사가 말해주는 포스트 팬데믹 경제 호황의 교훈
막연하게 ‘팬더믹이 끝나면 경기가 활성화 될 것이다’ 라고 생각은 해 왔지만, 역사적으로 짚어보며 그 형태에 대해 구체적으로 파악하는데 도움이 되는 글이었다.
소비의 증가, 새로운 사업 시도, 더 적극적인 자동화 도입, 정치적 변화가 일어날 것이라 분석한다.
Progressive Summarization: A Practical Technique for Designing Discoverable Notes - Forte Labs
‘태그로 노트를 정리하는 방법은 그다지 효율적이지 못하다’ 라는 글 내용에 붙어있던 링크 글이었다. 내용이 꽤 길고 3부작이다. (3부는 유료 컨텐츠) 하지만 1부만으로 대략적인 아이디어는 얻을 수 있었다.
지식을 습득하는 것은 요즘 같은 시대에 약간의 검색만으로 매우 쉽게 할 수 있게 되었다. 문제는 ‘언제 읽느냐’ 이다. 정말로 필요할 때에 해당 지식의 묶음을 다시 꺼내들려면 다시 찾기 쉬운 형태로(발견하기 쉬운 형태로) 노트가 정리되어야 한다.
P.A.R.A.(Projects, Areas, Resources, and Archives ) 형태로 데이터를 정리할 수 있다고도 하는데, 자세한 내용은 본문 참조. 이 글의 핵심 내용은 아니다.
보통 노트 작성 프로그램을 활용하게 되면 두 가지 형태로 노트를 만들게 된다. 태그 중심(ex. Bear) 혹은 노트의 묶음인 노트북 중심(ex. Evernote)으로 작성하는 것이다. 필자는 태그 중심의 노트 작성 방식이 너무 관리하기 어렵고 깨지기 쉬워서 주력 방법으로 사용하기 어렵다고 주장한다. 너무 많은 노트의 연결을 통해 이 노트가 정말 가치가 있는 것인지 아닌지 분간하기도 어렵다. 나도 그런 의미에서 Bear로 노트를 작성할 때 한 노트에 한개 이상의 태그를 사용하는 것을 지양하고 있다.
그러면 노트북 단위로 노트를 정리하는 것이 낫냐고 볼 수 있겠지만, 여기서 한발짝 더 나아가 Note-first 접근을 할 수 있다. 마치 조합 가능한 작은 함수가 되는것처럼 하나의 노트가 잘 구성되도록 계속 생산하는 것이다.
노트를 구성할 때 발견이 쉽느냐(Discoverability), 이해하기 쉽느냐(Understanding)는 상충되는 부분이 있다.
발견이 쉬운 노트는 작고 간단하며 요약이 되어있다.
이해하기 쉬운 노트는 디테일과 예시 등 모든 문맥이 다 담겨있다.
“미래의 내가 이 노트를 읽을 때 어떻게 해당 지식을 효과적으로 취할 수 있을 것인가?” 를 핵심 가치로 삼아야 한다.
그래서 5가지 계층을 두어 발견하기 쉬운 노트를 만드는 방법이 제안된다.
Layer 1: 모든 내용이 다 담겨있다. 스크랩 도구 등을 통해 통채로 가져오는 것이다.
Layer 2: 중요하다 생각하는 부분에 Bold 처리를 한다.
Layer 3: 볼드 처리된 문맥 중 더 추려서 ::하이라이팅::을 한다. Best of Best인 셈이다.
Layer 4: 하이라이팅 된 내용들을 가지고 나 자신의 표현으로 간추려본다.
Layer 5: 내용을 리믹스하여 내가 이 내용에 대해 어떻게 생각하고 어떻게 즉시 활용할 수 있을지 정리한다.
Bear + Apple Notes로 제텔카스텐 구축하기
Apple Notes(애플 노트)를 Inbox로 사용한다.
Bear(베어)가 제텔카스텐이 된다.
왜 Bear를 제텔카스텐으로? 는 이미 Bear에 익숙한 사람들이라면 충분히 공감할만한 내용들이다.
애플 생태계를 이용하는 사람들에게는 안정적인 싱크, 미려한 UI, 빠른 반응 속도 등
[[ 를 사용한 노트의 링크도 쉽고, 태깅이 가능하다.
Bear 뿐 아니라 다른 도구로 제텔카스텐을 사용하고자 할 때 고려할만한 점은 다음과 같다.
필요할 때 정보를 손쉽게 꺼내어 활용할 수 있는가? (Export 기능)
사용하는 모든 기기에서 이용할 수 있는가? (모바일 활용성)
노트와 노트 사이를 연결하는 것이 가능한가? (제텔카스텐을 구축하는데 가장 중요한 기능 중 하나)
태깅을 지원하는가?
보기에 좋은가? (Optional)
제텔카스텐 워크플로우
정보를 수집한다.
애플 노트를 활용하여 단순 링크나 PDF, 혹은 iOS Shortcut을 활용한 스크래핑
보통은 링크를 활용하며, 애플 노트는 인박스 역할만 한다.
가공하고 작성한다.
더 깊게 보고 정리할만한 내용이 있다면 애플 노트에서 베어로 옮긴다.
자신만의 언어로 해당 정보의 키 포인트를 정리한다.
iOS 킨들 앱을 이용하여 책을 읽다가 바로 해당 구문을 긁어서 정리하기도 한다. 추가로 iOS 킨들 앱은 이미지로 구문을 따는 것도 가능하다.
다시 강조되지만 정보를 가공하면서 단순히 해당 내용을 반복하는 것이 아니라 자신만의 언어를 사용해야 한다.
연결한다.
연관있는 노트는 [[ 를 활용하여 적극적으로 연결한다.
베어에서 백링크가 자동생성되진 않지만, 활용도에 따라 크게 불편하거나 어렵진 않을 것이다.
발행한다(내보낸다).
제텔카스텐을 만드는 이유 중 하나는 아이디어를 생성하고 연결하여 그 결과물을 세상 밖으로 꺼내는 것이다. 그래서 가공된 정보의 최종 목적지는 어딘가에 공유되는 것이 될 수 있다.
다시 본다(그리고 지운다).
주기적으로 다시 보고 아카이브하거나 노트를 지워야 한다.
가끔은 예전 정보가 유용할 때도 있고, 어떤 때는 작성하다 만 노트를 발견하고 지워야 할 떄도 있다.
베어는 아카이빙을 지원하니까 활용하면 되고, 혹시나 다시 볼 확률도 있기 때문에 어지간해서는 지우는 것보다 나을 것이다.
Developer
10년차 이상의 개발자는 어떤 준비를 하면 좋을까?
자바지기 박재성님의 영상
SI업계에서 경력 10년차가 넘어가고 여차저차 해서 스타트업으로 이직하여 개발을 하고 계신 분의 사례이다. SI 업계의 답없음을 탈피해야한다는 느낌이 강하게 느껴진다.
15년~20년차가 되면 더 이상 개발만으로는 먹고 살 수 없다. 리더십 역량을 발휘해야 한다. 이 리더십이라는 것이 관리자가 되라는 것이 아니다. 다른 개발자의 성장을 이끌어내고 더 효과적으로 일할 수 있는 환경을 만들어낼 수 있는 사람이 되어야 한다.
동료에게 프로그래밍의 재미를 느끼게 하거나, 코드 리뷰 등의 문화를 정착시키는 등 개발 리더로서의 역량이 갖춰질 수 있도록 해야한다. 문제는 이런 역량을 팀장급이 되고 나서 쌓으려고 한다면 너무 늦다는 것이다.
경력이 적을 때부터 꾸준히 이런 역량을 쌓기 위해 점진적으로 팀에 영향을 미치면서 변화를 이끌려는 노력이 필요하다. 그래야 개발 리더가 되었을 때 잘 할 수 있다.
10년차라고 보았을 때 어느정도 기술적인 완성도가 올라가 있어야 하는 것은 기본이다. 그리고 거기에 더해 ‘팀 단위로 같이 잘 할수 있도록 만들어야’ 한다. 어떻게 이런 환경을 이끌어낼 수 있을지 치열하게 고민하자.
React Ruined Web Development | by Ivan Lučin | Building Productive | Building Productive
제목은 꽤 도발적이다. 그런데 이 글은 본질적으로 리액트 이야기를 하려는 것은 아니다. 그래서 리액트와 아주 약간 관련이 있는 서두는 넘어간다.
개발자들이 어떤 프레임워크가 다른 프레임워크보다 좋네 마네 하는 성능을 논하는데, 대부분은 이 논쟁이 무의미하다. 느린 앱은 느린 JS 프레임워크 때문에 느려진 것이 아니라 대부분 나쁜 코드때문에 느려진 것이기 떄문이다. 심지어 요즘 세대 개발자들의 이력서는 ‘리액트 훅 다룰 줄 앎’ 같은, 무언가 본질을 뺴먹은 듯한 내용으로 차 있다. 대신 정말로 개발자로서 중요한 가치를 끌어올려보자.
어떻게 단순하고 읽기 좋은 코드를 만드는가?
어떻게 상태를 관리하는가?: 상태 관리 라이브러리를 쓰는 방법 이야기가 아니다. 설계 이야기에 가깝다.
코드를 어떻게 테스트하는가?: 테스팅 프레임워크 쓰는 법 말고 E2E 테스트를 자동화하는게 어렵고, 최소한의 의미있는 랜더링 기반으로 테스트를 하는것이 효율적인 이유를 알고 있는가?
코드를 어떻게 배포하는가?: CI/CD 어떻게 쓰는지 말고, 배포와 릴리즈가 적절히 분리되어 내가 새로이 작성하는 코드가 원격지에 있는 예전 코드에 영향을 주지 않으려면 어떻게 관리해야할지 등
어떻게 리뷰하기 좋은 코드를 작성하는가?: 코드 리뷰는 형식적으로 하는게 아니다.
어떻게 다른 사람의 코드를 리뷰하는가?: 코드 리뷰는 통해 제품의 퀄리티를 보장하고 버그나 기술 부채를 갚는데 도움을 주는데다, 팀 단위로 공유되는 지식을 형성할 수 있다. 하지만 사려깊게 리뷰가 진행되었을 때만 가능하다.
어떻게 단단한 프로젝트 표준을 구축하는가?
어떠한 JS 프레임워크 속에서도 갈피를 잡을 수 있는가?
MVP를 어떻게 만드는가?: 기술적인 부분을 고민하는 것도 좋지만 ‘기술’ 은 제품을 만들기 위한 도구라는 것을 잊으면 안된다.
어떻게 최적화 하는가?: 너무 서두르지 말고, 너무 늦지도 않게. 대부분은 최적화가 필요 없을 수 있다.
페어 프로그래밍을 어떻게 하는가?
어떻게 지속적으로 리팩터링 하는가?: 모든 프로젝트에는 기술 부채가 있으니, 그 상황에서 징징대지 말고 리팩터링을 해야한다. 모든 새 기능은 약간의 마이너 리팩터링과 함께 해야하고, 큰 리팩터링이나 전면 재작성은 대개 잘 되지 않는다.
다시 제목으로 돌아와서 ‘Ruined’ 라는 단어도 어울리지 않거니와 리액트도 충분히 좋은 도구이다. 하지만 그 대신 우리가 소프트웨어 엔지니어로서 하고 있는 일 에 조금 더 생산적인 논의를 해 보자는 글이었다.
JS / TS
Template Literal Types로 타입 안전하게 코딩하기
템플릿 리터럴 타입이 적용되고 나서 굉장히 다양한 유형의 타입 서커스를 봤는데, ‘당장은 이걸 어떻게 써먹는거지?’ 라는 생각만 하고 잊고 있다가 이 글을 접했다.
템플릿 리터럴 타입이 문자열 기반 타입을 다루는데 굉장히 강력한 도구가 될 수 있다는 것을 다시 한번 배웠고, 조건부 타입을 되짚으며 더 유용한 활용 방법에 대해 배울 수 있었다.
조금이라도 관심이 있다면 여기 있는 내용을 타입스크립트 플레이그라운드에서 그대로 타이핑해보는 것도 좋겠다.
Event Listeners: Delegation VS Direct Binding - Jason Format
Preact를 실무에서 다루게 되면서 이벤트 바인딩에 관련된 고민을 하게 되었다. 기본적으로 리액트랑 달리 직접적으로 노드에 addEventListener 를 바인딩하는 방식이라고만 알고 있었는데, 이 부분 때문에 특정 상황에서 이벤트 위임을 어떤 식으로 해야할지, 아니면 퍼포먼스를 고려하여 꼭 해야할지 고민하며 좀 더 구체적인 설명을 찾아보려 했다.
마침 Preact의 제작자가 이벤트 리스너에 대한 포스팅을 올렸고, 여기에 Preact에 관련된 내용도 약간 있어서, 내가 알고 있는 개념을 조금 더 견고하게 만들어보고자 글을 정독해보았다.
일단 이벤트 위임의 개념이 없고, 이게 직접적인 이벤트 바인딩과 어떤 차이가 있는지 알고 싶다면 아주 추천할만한 글이다.
추가로 모던 웹의 addEventListner API의 발전에 대한 내용도 있다. 이벤트가 한번만 발생하고 바로 제거되도록 만든다거나, passive 옵션을 활용하여 사용자 인터렉션을 보장한다던가. 이벤트 위임과 직접 바인딩에 대한 담론에서 상호 운용성(interoperability)을 언급하기도 한다. 만약 한 페이지가 마이크로 프론트엔드로 제작되어있는 경우 각 프레임워크별로 이벤트를 처리하는 방법이 달라 이벤트 위임을 사용했을 때 의도하지 않은 동작이 일어날 수도 있다는 것이다.
직접 바인딩과 이벤트 위임은 어느것이 나은지 (아주 명백한 경우를 제외하고) 직접적으로 측정하고 비교하는 것이 어렵다.
글을 통해 설명하는 것 중 하나는 이벤트를 실행 시 타겟 노드를 찾는데 들어가는 런타임 비용도 무시하지 못한다는 것인데, 이벤트가 일어날 당시 안정적인 DOM 노드 참조가 있으면 적은 비용으로 직접 바인딩을 운용할 수 있다는 것이다.
그리고 Preact의 이벤트 바인딩 시스템은 이를 잘 활용하고 있어서, 업데이트 시 이벤트 등록과 해제를 최소 비용으로 처리한다. addEventListener, removeEventListener 에 들어가는 비용을 최소화하기 위해 DOM 노드마다 프록시 리스너에 모든 이벤트를 등록하고 바뀌어야 할 부분만 적절하게 교체하는 방식이라고 한다.
Frontend
드래그 앤 드롭과 마우스 이벤트
새로운 회사에서 교욱과정의 막바지에 TodoList 앱 구현을 하고 거기에 덧붙여 Drag & Drop(D&D)로 아이템의 위치를 바꾸는 것 까지 구현하는 스펙이 있었다. D&D를 구현할 때는 HTML5의 Drag & Drop API를 사용하지 말고 구현해야 한다는 제약이 있었다.
이런 부류의 구현을 거의 해본 적이 없다보니 어디서부터 시작해야할까 막막해하며 검색을 해 봤는데, 보기만 해도 정답지같아보이는 내용이 딱 눈앞에 펼쳐졌다.
기본 알고리즘은 엘리먼트의 mousedown 이벤트부터 시작하여 document 의 mousemove 이벤트에서 움직임을 핸들링하고, 마지막에 엘리먼트의 mouseup 에서 뒷정리를 하는 식으로 흘러간다.
또한 document.elementFromPoint  함수를 통해 특정 좌표 바로 아래에 있는 요소도 건질 수 있어서 이를 추가적으로 활용할 수도 있다.
GitHub - ismay/stylelint-no-unsupported-browser-features: Disallow features that aren’t supported by your target browser audience.
스타일린트를 통해 옵션으로 설정한 브라우저 지원 범위에서 벗어나는 CSS 속성을 사용할 시 경고를 띄워주는 플러그인. doiuse 라는 라이브러리를 활용하는데, 이 라이브러리가 caniuse 와 browserslist 를 활용하여 CSS 프로퍼티의 사용 가능 여부를 검사한다.
스타일린트로 기본 린트와 프로퍼티의 순서 정렬하는 정도의 플러그인을 써왔었다. 그런데 이런 방식으로 활용할 수 있다는데서 놀랐다.
Introducing Astro: Ship Less JavaScript
Snowpack 팀에서 만든 정적 사이트 생성기. 대부분의 모던 프론트엔드 프레임워크를 지원하고 어지간한 기본 툴셋은 다 포함되어 있는데다 결과물이 100% HTML로 나오게 만들 수 있다고 한다. 물론 원하면 별도의 스크립트도 불러오도록 만들 수 있다.
Snowpack이 좋긴 하지만 커스터마이징을 하는데 있어 어려운 부분이 있는 것처럼 Astro도 비슷하게 기본적인 부분을 넘어서서 복잡하게 다룰 일이 있을 때는 생각보다 다루기 껄끄러울 수도 있겠다.
React
New Suspense SSR Architecture in React 18 · Discussion #37 · reactwg/react-18 · GitHub
리액트 18버전에서 새로이 도입되는 SSR 아키텍쳐를 쉽게 설명해주는 글이다. 그런데 이 글은 단순히 ‘앞으로 어떻게 할 것이다’ 를 설명했을 뿐 아니라 ‘여태까지 어떠한 문제를 해결하기 위해 SSR이 도입되고 사용되었는지’ 먼저 설명해주고 있다. 그래서 리액트로 하는 SSR이 무엇인지 궁금하다면 반드시 읽어야 할만한 글이라고 느낀다.
기존 SSR은 워터폴 방식으로 서버에서 데이터를 가져오고, 서버에서 HTML을 만들어 주고, 클라이언트가 HTML을 받아 그리고 난 뒤 클라이언트 사이드 코드를 다 그리고 난 뒤 최종적으로 리액트 컴포넌트로서 동작할 수 있도록 하이드레이션 과정을 다 거쳐야 한다. 이 모든 과정은 순차적으로 일어나야 하고, 앞의 과정이 끝날때까지 다음 과정을 실행할 수 없는 상태라 비효율적이다.
리액트 18에서는 이를 HTML 스트리밍 + 선택적 하이드레이션을 통해 부분적으로 쪼개어 해결하려고 한다. 사용자가 보는 페이지 전체에 대해 위의 모든 과정을 하는 것이 아니라 하나의 스크린의 부분부분마다 각각의 과정을 따로 수행할 수 있도록 만드는 것이다.
특히 선택적 하이드레이션은 흥미로운게, 사용자의 인터렉션이 일어나는 부분을 우선적으로 하이드레이션 한다고 한다.
리액트 기반으로 SSR을 하는 웹앱이 서버에서 데이터를 불러오거나 할 때 초기 로딩이 꽤나 느려진다고 비판하는 사용자들의 목소리를 종종 보았는데, 이후 어떤 방식으로 발전할 수 있을지 기대된다.

This month I Learned - 2021년 6월

댓글