This month I Learned - 2020년 11월2020/11/29

General

• 에이미 커디(Amy Cuddy): 신체언어가 여러분의 모습을 만듭니다 | TED Talk Subtitles and Transcript | TED

  • 일단 결론부터 이야기하면 이 영상에서 말하는 이론은 아직 논란의 여지가 있다. 그런데 이 영상을 링크한 것은 몸의 자세를 바꾸는 것으로 인생이 바뀐다는 것을 이야기하기 위해서가 아니다.
  • 최근에 회사 내부 강연에서 ‘성공이란 무엇인가’ 라는 주제로 내 마음가짐에 대해 다시 생각할 계기를 마련할 수 있었다. 그 때 강연 말미에 추천되었던게 이 영상이다. 이 영상을 통해 배울 수 있는 것은 영상 그 자체의 내용보다는 아래의 심플한 내용이다.
  • “(자신이 될 수 없다고 여기는 모습을)그럭저럭 따라할 수준까지만 너 자신을 꾸며내지 말고, 너 자신이 되고자 하는 모습에 도달하고 내재화 될 때까지 꾸며내라.”
  • 말을 다시 옮기니 좀 어려운 말이 되긴 했지만, Imposter syndrome(가면 증후군)에 대처하는 방법 중 하나로 제안할만 하다고 생각했다.

Developer

• 안희종님의 ‘기억에 남는 개발 관련 영상’ 리스트

  • 나는 개발 관련한 내용의 영상을 별로 보지 않는 편이다. 학습할 때도 안그런데 쉴 때는 더더욱 그렇다. ‘나중에 봐야 할 영상’ 으로 체크를 해놓아도 잘 안보게 된다.
  • 그러다 간만에 희종님의 추천 트윗을 보았고, 한 두개는 이전에 보고 좋은 영감을 얻었던 영상이었다는 것이 떠올랐다.
  • 아마 DHH와 Dan Abramov의 영상은 봤었을 것이다. 거기에 더해 Patrick Winston의 “How To Speak” 이라는 영상은 꼭 살펴보고 싶어졌다.

• 소프트웨어는 녹이 슨다 — 洪民憙 블로그

  • 이전에 봤던 글이라고 생각하는데 내 노트의 검색 결과에는 나오지 않길래 다시 살펴보았다.
  • 언제부턴가 나는 회사 프로젝트에 이런저런 핑계를 대며 근근이 유지보수를 하고 있는 수준이라고 생각하고 있었다. 물론 새로운 기능 개발은 하고 있지만 더 나은 제품을 위한 근본적인 개선은 쉽사리 손대고 있지 못했다.
  • 이 글을 보면서 쉽사리 손대고 있지 못하더라도, 녹슬지 않게 계속 조이고 기름칠하고 괜찮은 가치를 전달하는 노력을 포기하지 않는다면 조금씩 잘 수정된 인터페이스에 맞추어 F1 차량 타이어 교체하듯 슥 발전할 수 있는 날도 언젠가 오지 않을까 기대하게 되었다.

• 일 잘 하는 개발자는 왜 비즈니스까지 신경쓸까? | Evans Library

  • 머리로는 알고 있지만, 사용자를 위한 더 높은 가치를 전달하기 위해 지금의 코드를 도저히 견디지 못하겠다는 생각이 언제나 나 자신을 하루하루 옥죄어왔었다.
  • 하지만 조금 더 생각해보면 요즘같이 많은 서비스가 난립하고 빠른 배포 사이클을 돌리지 않으면 제품이 살아남기 어려운 시대에, ‘방망이 깎는 노인’ 마냥 살아가는 태도도 경계해야 할 필요가 있다는 영감을 받았다.
  • 개발자 혼자서 제품을 만드는게 아닌 만큼 팀 플레이어로서 자신의 역할에 조금 더 고민을 할 필요가 있겠다.
  • 또한 “이게 정말 설계를 고민할 가치가 있을까?” 를 생각해보고 과감히 앞으로 나아갈 수 있는 태도에 앞서, 내 자신이 어떤 작업을 수행하기 위한 속도를 얼마나 정확하게 알고 있는지 측정해두는 것도 중요하겠다.

• 삶을 편하게 해주는 Git 팁 들 | GeekNews

  • 내가 쓰는 Git 워크플로우 안에서 Sublime Merge를 충분히 잘 쓰고 있다보니 CLI를 본격적으로 쓰지 않은지 꽤 오랜 시간이 지났다. 그래도 언제나 해결이 잘 안되는 가려운 부분은 CLI로 해결할 수밖에 없다.
  • git grep 외에는 다 몰랐던 커맨드인데, 특히 git gc 라는 커맨드가 있었다는게 아주 충격적이었다. git rev-list 도 어떻게 써먹을 수 있을지 문서를 더 살펴봐야겠다.

• GitHub - headllines/hackernews-weekly: Hacker News weekly top 10 posts

  • 간단히 이 저장소를 Watching 해두고 있으면 GitHub 메일로 해커뉴스 주간 Top 10 포스트를 받아볼 수 있다. Daily, Monthly 저장소도 제공을 해 주지만 Weekly 정도가 낫지 않을까 싶어서 체크해두었다.
  • 텔레그램 기반의 개발 그룹도 있긴 한데 중국 분들이 개발하시는지 중국어만 가득 쓰여있다. 그냥 저장소 구독만 하는걸로.

• GitHub - microsoft/Web-Dev-For-Beginners: 24 Lessons, 12 Weeks, Get Started as a Web Developer

  • 쉽게 비유하자면 ‘MS에서 운영하는 생활코딩’ 아닐까?
  • 물론 생활코딩이 한국 사용자에게 더 친숙하고 커버하는 범위가 더 넓을 수는 있지만, 영어가 된다면 이 과정을 한번 살펴보는 것도 아주 좋겠다는 생각이 들었다. 코스 형태로 되어있고 각 강좌마자 퀴즈와 복습도 제공하는 것이 심플하고 알차 보인다.
  • 저장소 번역도 받고 있으니 관심 있으신 분들은 참여를 해보는 것도 어떨지? 물론 나도 하면 좋겠지만… 개인 리소스가 심히 부족하다.

• 신입 개발자 연봉 이야기

  • 연봉 편차라는게 회사마다 많이 다르고, 그냥 막연히 ‘우리 회사정도면 괜찮은 편이지’ 라고 생각하며 지내고 있지만, 적어도 ‘신입급 연봉에는 어느정도 정형화된 흐름이 있지 않을까’ 하고 생각하고 있었다. 글에서 이야기하는 연봉 분포에는 대강 공감한다.
  • 또 하나 짚고 넘어가는 것이 ‘대부분의 중소기업이나 작은 스타트업’ 이라는 넓은 범주의 예외 영역이다. 연봉도 적은데 워라밸까지 없는 수준인 경우도 있겠고, 워라벨이라는게 있긴 한데 연봉이 없는 수준인 곳도 있고. 내가 후자의 회사에서 이직했던 것이 생각난다.
  • 결국은 좋은 연봉으로 시작하는 것이 좋긴 한데, 본인이 하기에 따라 드라마틱하게 이를 끌어올리는 것은 가능하다. 하지만 어지간한 노력으로 이루기는 힘들 것이다. 노력+운이다. 이 부분은 이 글의 글쓴이가 남긴 또 다른 포스팅도 흥미로운 내용이 담겨있었다.

  • 신입 개발자의 성장에 관련하여 숟가락을 하나 더 얹자면 최대한 빨리 ‘내가 어디까지 모르는 상태인지’ 를 자각한다음 이를 어떻게 하루하루 반복적으로 개선해나갈 수 있을지 방안을 찾는게 좋다고 생각한다.

    • 실질적으로 접었지만 여전히 격투게임의 팬으로서 ‘우메하라 다이고’ 의 “하루에 하나씩 강해지기”라는 구절이 생각난다. 저 책은 그 실천법을 옮기고 있는 듯 한데 나도 구절만 어디서 줏어듣고 책을 보진 않았다.

• 좋은 코드란 무엇일까? | JBEE.io

  • “좋은 코드는 좋지 않은 코드가 없는 코드를 말한다” 라는 구절이 중요하게 느껴졌다.
  • 그 좋지 않은 코드를 제거하기 위해 “단순 추출이 아닌 추상화”, “삭제하기 쉬운 코드와 삭제하기 어려운 코드의 분리”, “일관성 있는 코드”, “확장성 있는 코드” 가 제안되었다.
  • 추상화 부분이 특히 눈에 많이 들어왔는데 여기서 보이는 괜찮은 예와 나의 코드는 얼마나 맞닿아 있을지 다시 살펴보게 된다.

• 공개 구글 스프레드시트 문서를 이용하여 내가 원하는 형태의 mock API 응답받기 | FUREWEB

  • 클라이언트 개발을 하면서 Mock API를 만드는데 여러가지 방법을 사용하게 된다. 테스트에 사용한다면 MSW를 사용하면 될 것 같지만, 일단 실제 개발을 들어가는데 데이터가 뭐라도 보이도록 뷰 레이어를 개발하고 싶은 경우라면 이 글의 내용이 도움이 되리라 본다.

• 중니어의 고뇌: 1인분 개발자, 다음을 찾아서

  • 자신이 ‘1인분 몫을 하는 개발자’ 가 되었다고 느끼고 뒤를 돌아보았을 때, 만족스럽지 못한 부분이 많다. 뭔가 팀에서 역할 하나는 차지하고 있어 시간은 부족한데 내가 개발자로서 성장하고 싶은 목표는 아직 까마득하게 느껴지기 때문이다.
  • 여기서 ‘팀의 생산성을 올리는 개발’ 이라는 키워드가 동작한다. ‘함께 자라기’ 책이 생각난다. 짧은 내용의 슬라이드이지만 문제 의식을 공유하고 자신만의 컴포트 존을 벗어나기 위한 다양한 방안을 제시하고 있는 좋은 발표 슬라이드이다.
  • 특히 ‘해본 방법으로 빠르게 개발하자’ 라는 집착을 내려놓는 것과 ‘멘토가 되기’ 부분이 나도 겪어보고 공감하게 되는 부분이다.

JS / TS

• 로우 레벨로 살펴보는 Node.js 이벤트 루프 | Evans Library

  • 회사 내부 Dev Weekly에서 이벤트 루프에 대한 세션이 열렸었다. 그 때 이벤트 루프에 대해 조금 더 깊게 복습해볼 시간이 있었는데, 원래 발표자분이 발표를 안 하시고 이 글만 추천하려고 하셨다고 한다. (어딜 도망가!)
  • 자바스크립트에는 여러가지 독특한 부분이 있지만, 그 중 하나가 비동기 처리와 그 비동기 처리를 위한 이벤트 루프라고 생각한다. 이 내용을 모두 숙지할 필요는 없지만 이벤트 루프가 무엇인지 가볍게 알고 글을 한번 쭉 읽어보면 족므 더 깊은 부분을 이해하는데 많은 도움이 될 것이다.
  • 다만 Node.js 환경에 조금 더 집중적으로 이야기하고 있기 때문에 브라우저 환경의 이벤트 루프와는 조금 다른 점이 있을 수 있다는 점을 인지하고 있어야 한다.

• 자바스크립트에서 AbortController 를 활용하여 비동기 작업 중단하기 | 오르막길

  • fetch 로 캔슬 하는 동작에 대한 질문에 대한 답변으로 AbortController 를 답변해주다가 MDN 문서로는 뭔가 이해가 아주 힘들다는 기분이 들어서 조금 더 검색을 해 보았다.
  • 그러다 발견한게 이 글인데, 조금 더 현실적인 예제를 기반으로 되어 있어서 예제 코드를 따라가며 한번 동작시켜보면 훨씬 수월하게 이해를 할 수 있었다.

Frontend

• GitHub - tomayac/dark-mode-email: This repo shows how to create emails that support dark mode.

  • 이메일용 마크업은 여러가지로 브라우저에 랜더링되는 마크업과 다르다고 알려져있다. 다크 모드도 그 중 하나인데, 여기서는 meta 태그를 활용하여 폴백까지 가능하며 다크 모드를 지원하는 이메일 템플릿 예제를 볼 수 있다.

• 앱 셸 모델  |  Web  |  Google Developers

  • 페이스북 그룹에서 ‘토스 안의 웹뷰는 어떻게 최적화 되어 있는가?’ 라는 질문을 지나가다 보았는데, 답변 중 하나에 ‘앱 셀 모델’ 이라는 키워드가 나왔다. 이때까지 몰랐던 개념이었지만, 알게 되면서 머리를 탁 치게 되었다. 거기다 나온지 꽤 오래된 개념이었다. (2016년 정도)
  • 서비스를 구동하는데 필요한 최소한의 HTML, CSS, JS를(보통은 네비게이션 등의 UI 뼈대) 오프라인 캐싱하여 사용자에게 최적의 경험을 제공하는 것을 말한다.
  • 글의 내용이 한글 자막까지 붙은 영상으로 공개되어 있다.

• Website Accessibility Made Easy: Your 2020 Ultimate Guide

  • 월초에 뜬금없이 영어로 메일이 왔었다. ‘너의 TIL 포스트 잘 보았는데, 그 중에 접근성에 관련된 내용이 있었다. 혹시 이 글도 널리 추천해줄 수 있냐’ 같은 내용이었다. 다분히 광고성이 짙어 보이는 느낌이지만, 여태까지 받아 본 관련 메일 중 가장 덜 광고같았던데다 글 내용도 실제로는 괜찮았다.
  • 웹사이트의 접근성을 구현할 필요성, 그리고 어떤 요소를 고려해야 하는지를 항목별로 간단명료하게 짚어주는 글이었다. 그것도 2020년에 맞추어서(?)

React

• SWR Tips | Euihyun Slides

  • useSWR 혹은 react-query 사용을 해보고 경험에 대해 글을 쓰는 분들이 점점 늘어나고 있다. 특히 국내에서는 useSWR 을 사용해본 분들의 글이나 슬라이드가 더 많이 올라오는 느낌이다.
  • ‘대체 이게 뭔데?’ 라고 생각하는 경우 이 슬라이드를 보면 쉽게 이해가 될 것이다. 나는 react-query 를 고려중이지만. 특히 이 슬라이드를 공유했을 때 실제로 react-query 의 제작자가, ‘(SWR 쓰면서)몇 kb의 번들 줄이자고 더 많은 것을 잃을 수 있다’ 라고 직접 댓글을 달아주었길래 조금 더 자세히 살펴볼 예정이다.

• 싱페어 (SPA) 의 피로감

  • 이제 React.js 를 버릴 때가 왔다
  • 둘 다 같은 분이 쓰신 글인데 개인적으로 공감을 못하겠다. 그럼에도 불구하고 공유를 하는 이유는, “이런 시각이 있구나” 와 “나는 그럼 리액트를 얼마나 이해하고 쓰고 있길래 이 글에 공감을 못하겠는가” 를 고민해보기 위해서이다.
  • 아마 글을 읽는 분들 각자의 포인트가 있을 것이다. 화두만 던지는 정도만 해 보았다.

Tools

• Cheers to another year of Bear

  • 지금 이 글의 초안도 Bear로 작성하고 있을 정도로 나는 Bear를 잘 쓰고 있다.
  • 더 많은 가능성이 열려있는 도구인데 내가 활용을 잘 못하고 있다고 생각하여, 앞으로도 더 잘 활용해보고 싶다.
  • 내가 유료 구독을 시작한지 3년째애 접어드는 것으로 기억한다. 다양한 소프트웨어가 구독제를 운영하고 있지만 $15/year 로 이만한 만족도를 주는 도구도 드물다. 새로운 에디터가 알파 단계에 있는데 잘 적용되어 더 즐거운 글쓰기 경험을 얻을 수 있기를 바라고 있다.

• Choosy: A smarter default browser for macOS

  • 회사 Q&A 채널에 구글 닥스 문서 일부가 사파리에서 제대로 동작하지 않는 이슈 때문에 손쉽게 다른 브라우저에서 여는 방법이 없냐는 질문이 올라왔다. 나는 기존에 Keyboard maestro나 PopClip같은 도구를 활용하여 특정 URL을 드래그하거나 보고있는 브라우저의 창에있는 URL을 바로 다른 브라우저에서 열도록 만드는 단축키를 사용했었다. 혹은 업무 시간에만 기본 브라우저를 구글 크롬으로 설정하고, 업무가 끝나면 다시 사파리로 돌리곤 했다. 이건 알프레드 워크플로우로 비교적 손쉽게 가능하다.
  • 그러다 다른 동료분이 특정 조건을 설정하여 모든 URL 링크 클릭 시 규칙에 따라 원하는 브라우저가 열리도록 설정할 수 있는 앱을 소개해 주셨다. UI도 깔끔하게 잘 되어있고, 기능도 잘 동작하기 때문에 $10을 바로 지불하여 쓸 뻔 했으나…

  • GitHub - johnste/finicky: A macOS app for customizing which browser to start

    • 트위터로 이런 오픈소스 도구도 있다는 제보를 받았다. 직접 js파일로 설정을 해야 하는 약간의 번거로움이 있지만, 내가 필요한 수준의 기능은 충분히 잘 동작하여 만족스럽게 정착할 수 있겠다.