General

• 누구나 팀장이 되고 싶진 않아 
  • “팀장은 팀장 역할을 맡을 자격이 있는 사람 중에 팀장이 되고 싶어 하는 사람이 맡는 것이 가장 좋다” 라는 종합 정리가 무척 마음에 와닿았던 글이다.
  • 보통 그 분야에서 일을 오래 했거나, 그 회사에서 일을 오래 했다고 으레 팀장이 되는 경우도 있을텐데 그런 방식으로 팀장이 임명된다면 조직에게 크게 이득이 되지 않을 수도 있다.
  • 또한 팀장은 그 업무를 잘 수행한다고 팀장이 되는 것이 아니라 그 팀의 팀장으로서 역할을 잘 수행할 수 있는 사람이 해야 한다고 한다. 단순히 업무를 잘 하는 것과 팀장으로서 팀원을 이끄는 것은 별개의 업무다.
  • 그리고 이 시간에도 고군분투하는 팀장님들을 응원한다. 언젠가 미래에는 그게 내가 될 수도 있다. 그 때 나는 준비된 팀장이 될 수 있도록 노력하는 수밖에.

Developer

• Product Management for Engineers | GeekNews 
  • 엔지니어 출신 글쓴이가 프로덕트 매니징을 맡게 되면서 관련된 글을 수집한 노션 페이지이다.
  • 엔지니어 뿐 아니라 프로덕트 오너 / 매니저 등의 역할에 참여하는 초보들이 참고하기 좋은 글들의 묶음이었다.
  • 커뮤니케이션, 마인드셋, 타인과 일하기 등은 어느 정도 경험을 통해서 익숙해지고 있는 분야라고 생각했는데 사용자 온보딩, 마케팅, 그로쓰 등은 단어의 뜻만 대충 알지만 내가 일하면서 직접 접해볼 일이 없다보니 흥미를 가지고 읽어볼 수 있었다. 특히 제품 개발에 참여하는 엔지니어라면 가볍게 이런 내용들이 있다는 것을 파악하기 위해서라도 읽어보기 좋아 보인다.
• 개발자, 트렌드를 버리다 
  • 사이드 프로젝트로 무려 웹 디자인 툴을  만들고 계시는 박진호님의 소회에 가까운 글 1편.
  • 기본적으로 브라우저는 어떤 방식으로 DOM을 그리고, 우리가 그 DOM을 다룰 때 유의해야 할 점은 무엇인가? 등등을 고민하고, 최적화를 위해 어떤 고민이 따라가야 하는지 고민한 내용을 담담하게 풀어내셨다.
  • ‘트렌드를 버리다’ 라는 제목과 연관지어 결말 부분에서 개발자로서 항상 머리속에 달고 살아야하는 ‘왜?’ 라는 질문을 조금 구체화해주신 내용이 좋았다. 잘 나가는 라이브러리들은 어떤 필요에 의해서 나왔는지, 그게 정말 나의 문제를 해결하는 해결책이 되는지, 왜 나는 남들이 만들어 놓은것만 쓸 수 밖에 없는지 등등
  • 1년 후 소감 뿐 아니라 올해 최신판인 2년후 소감  도 있다. 주로 오픈소스로 제작하고 계시는 웹 디자인 에디터의 개발 디테일에 대한 이야기이지만, 구현을 위한 고민과 열정을 피부로도 느낄 수 있을 정도여서 존경스럽다.
• OKKY - SI가 코드레벨이 우수해야 되는 이유가 있습니다. 
  • 일단 SI 업계 안에서 코드 퀄리티의 중요성에 대해 이야기를 하고 계시지만, 그냥 어떤 회사에서 일을 하더라도 개발자로서 반드시 신경써야 하는 부분을 잘 짚어주셨다고 생각한다.
  • ‘코드 레벨’ 이라는 단어가 조금 추상적으로 보였는데 본문을 읽으면서 추측해보면 “자신이 생각하는 로직을 프로그래밍 언어에 가리지 않고 잘 구조화된 코드로 끌어내는 능력” 이라고 보여진다.
  • 툴에 능숙한 개발자가 좋은 개발자가 아니며, 폴더 구조부터 상당한 Context를 전달할 수 있는 개발자, 천 줄짜리 로직을 신입이 쭉쭉 읽으면서 바로 이해가 되게 만들어 놓는 개발자, 함수명을 보고 주석을 처리하면 딱 그 기능만 제외될 정도로 모듈화를 시켜놓는 개발자 등이 잘 하는 개발자라는 이야기다.
  • 결국 잘 짜여진 코드, 이해하기 쉬운 코드, 모듈화 잘 되는 코드 등 개발 관련하여 추천되는 기본서들에 한 번쯤은 언급되는 내용들이지만 말처럼 쉽게 잘 하기 어렵다는 내용일지도.
• 회색분자의 SW창작 놀이터 :: 좋은 개발자, 어떻게 구할까? 
  • “함께 일을 해 봐서 좋은 개발자라고 남에게 소개할 수 있는 사람” 이 좋은 개발자라는 글
  • 그렇다면 좋은 개발자란?
    • 일을 믿고 맡길만한 개발자
    • 일처리를 똑부러지게 하는 개발자
    • 꼭 결과를 내어주는 개발자
  • “특정 스킬이 뛰어난 사람이 좋은 개발자인가?” 라는 질문은 “좋은 목수가 좋은 건축가인가?” 라는 질문과 비슷하게 의미 없는 질문이다.
  • 그러므로 좋은 개발자 없냐는 질문보다 “이런거 만들고 싶은데 만들 수 있는 개발자 없을까요?” 묻는게 더 현명한 질문이다.
  • (창업을 하는 입장에서) 좋은 개발자를 구하려면 내가 원하는 것을 명확하게 정의하고 이것에 대해 개발자와 30분 정도는 이야기 할 수 있을 정도로 정리가 되어있어야 한다. 그리고 잡코리아보다 아는 사람으로부터 개발자를 구해야 한다.
  • 위의 내용을 보다보면 개발자 1년차에 “어떠한 스킬을 잘 할 수 있는 사람보다 문제를 해결할 수 있는 사람으로서 가치를 높이자” 라고 깨달았던 것을 다시금 되새기게 된다.
• 다른 개발자들은 요즘 잘 나간다는데… ‘패배자같은 개발 직무’ 탈출법 - CIO Korea 
  • 요즘 개발자라는 직업이 변호사보다 잘 나간다고 화제다.  그런데 보통 ‘네카라쿠배당토’ (네카라 다음부터는 적당히 엎치락 뒤치락 하는 것 갓다만) 같은 보상 수준이 선두에 있는 기업들을 제외하고는 글쎄…
  • IT 산업도 시스템 엔지니어링부터 제일 끝단의 클라이언트 개발까지 다양한 분야가 존재하고, 그 안에서도 아주 다양한 소분류가 있다. 그 속에서 특정 직군은 잘 나가는 상황이기도 하고, 그렇지 않아서 “자신에게 적합하지 않은 프로그래밍 일자리를 가지고 있다” 라고 생각하는 사람들도 존재하는 것이다.
  • 그나마 개발자를 채용하는데 필요한 역량은 기술 스택이 전부는 아닌지라, 계속 커리어를 바꾸기 위한 방향 전환을 게을리하지 않으며 본인의 소프트 스킬을 더욱 끌어올릴 수 있다면 원하는 직군으로 갈아타기 쉽지 않을지 조심스럽게 추측해본다. 기사는 외국 기사 번역이라 그게 상대적으로 쉬울지 모르겠으나, 한국은 마냥 쉽지 않겠지만.
  • 그런데 어차피 살아가면서 개발자만 할 확률도 100%는 아니며, 그 중에서도 지금 하고 있는 직무를 유지하고 있을 확률은 더 적다고 생각한다. 결국 ‘소프트웨어를 다루는 스킬로 주어진 문제를 해결하는 사람’ 으로서 개발자의 역량을 끊임없이 갈고 닦아야 ‘잘 나가는 개발자’ 는 아니라도 최대한 업계에서 살아남을 수 있지 않을까? 결국은 살아남는 사람이 승자다.

JS / TS

• 10 bad TypeScript habits to break this year 
  • Geeknews 공유 링크 에는 간단히 10가지 사항을 정리만 해놓긴 했는데, 본문에는 각각 쓰지 말아야 하는 이유가 잘 적혀있어서 따로 정리해두었다. (개인 노트에만)
• GitHub - goldbergyoni/nodebestpractices: The Node.js best practices list (February 2021) 
  • Node.js로 서버 개발을 하는 경우를 위한 Best practice로 보이는 저장소이지만, 그래도 요즘 시대에 자바스크립트로 개발을 하는 모든 개발자가 소제목만 한 번씩 훑어보아도 도움이 될만한 목록이다.
  • 자바스크립트 개발의 모범 사례이기도 하고, 서버 개발 시 신경써야 하는 요소들도 있으니 프론트엔드 개발자도 서버 사이드의 이해를 조금이라도 넓히기 위해 읽어두는 것을 추천한다.

Frontend

• CSS in JS is like replacing a broken screwdriver with your favorite hammer. 
  • 트위터로 CSS-in-JS에 대해 질답이 오갈 일이 있었다. 대화 과정 속에서 내가 생각했던 결론은, CSS-in-JS 자체가 나쁜 것이 아니라 이를 잘못 사용하는 사람들이 애플리케이션의 효율적이고 잘 구조화된 스타일링을 못하는 것이 문제라는 것이다.
  • 링크된 글은 트윗이 오가는 중에 인용된 것이었다. 자바스크립트로 작성되는 구조적/행위적 기반 스타일링과 CSS로 이루어지는 그래픽 기반의 스타일링의 차이에 대해 이야기하고, CSS-in-JS가 애플리케이션의 시각적 일관성을 해치고 코드의 재사용성이 기대와 다르게 떨어질 수 있다는 이야기를 한다. 결론으로 더 나은 CSS 모범 사례를 활용하는 것을 결론으로 내 놓았는데, CSS 구조화를 잘 해두었다면 충분히 코드 재사용성을 높일 수 있긴 하다. 어려워서 그렇지. 그래서 CSS-in-JS에 대한 비판보다는 스타일링을 제대로 하지 못하는 개발자들이 비판의 대상이 되어야 한다고 생각하게 만드는 글이었다. 나도 그 못난 개발자 중 한명이다.
  • Cascading이라는 특징을 활용할 수록 요즘 주된 개발 방식인 ‘컴포넌트 기반 개발’ 이 어려워지는 부분이 있는데, ‘애초에 내가 개별 컴포넌트를 잘 구조화하고 재사용성 높은 쓸모있는 녀석으로 만들고 있는가?’ 라고 반성하게 되기도 했다.
• 코딩 플레이그라운드 만들며 맛보는 요즘 FE 개발 환경 Part 1 · shiren the creator 
  • 코딩 플레이그라운드 만들며 맛보는 요즘 FE 개발 환경 Part 2 · shiren the creator 
  • Lerna 를 활용하여 모노레포 플레이그라운드를 만드는 연재글이다.
  • 1~2편을 통해 자바스크립트, 타입스크립트 + 리액트 개발환경까지 직접 만들어볼 수 있다. ESLint + Babel, Prettier, Webpack 등을 설정하는 방법을 알 수 있다. 기왕 하는거 husky나 다른 라이브러리를 활용한 git hooks 설정도 추가되었으면 더 좋았겠다.
  • 보일러플레이트를 사용하지 않고 새로운 프로젝트를 세팅 해 본다고 할 때 어떤 식으로 해야할지 감이 잡히지 않는 사람들에게 아주 좋은 정보가 될 것이다. 이미 한 번 정도는 해볼 사람이라면 가장 최신 버전 기준으로 어떻게 새 프로젝트를 구성해야 하는지 참고가 될 것이다.

React

• GitHub - dai-shi/katachidraw: SVG based drawing tool and react-native component 
  • Excalidraw 의 아쉬운점을 보완하여 만들어진 SVG 기반 드로잉 툴.
  • Recoil과 유사한 API를 가진 대안으로 알려진 jotai 를 활용한 프로젝트라 흥미가 생겼었다. 이 프로젝트를 통해 jotai로 상태 구조를 잡고, 어떤 식으로 활용하는지 참고할 수 있을 것이다.
• CSS in JS 라이브러리에서 Typesafe하게 Theme 관리하기 
  • styled-components 와 비슷하게 큰 인기를 끌고 있는(그리고 요즘은 처음 프로젝트를 만드는 경우라면 더욱 추천되는) emotion 라이브러리를 이용하는 경우 타입스크립트 + Context API를 활용하여 효과적으로 테마를 관리하는 방법을 소개하는 글이다.
  • styled 컴포넌트와 ThemeProvider 를 리턴하게 만드는 makeTheme 같은 함수 활용이 무척 흥미로웠다. 나 자신은 보통 별도로 프로바이더를 리턴시키는 함수를 굉장히 제한적으로만 알고 사용해왔는데, 저런 방식으로 사용하는 것을 보니 식견이 넓어지는 기분이었다.
  • 또한 리액트 애플리케이션의 구조를 잡는 방법론 중에 Fractal 이 있다는 것도 배웠다.
• Fix the slow render before you fix the re-render 
  • Before You memo() — Overreacted 
  • 리액트 앱의 퍼포먼스 문제 혹은 버그를 잡다 보면 굉장히 많이 접하거나 떠오르는 단어가 있다. 바로 ‘리랜더링’(혹은 리랜더)이다.
  • 위 두 글은 ‘리랜더링 자체는 큰 문제가 아니고, 랜더링 자체가 느리지 않은지 잘 점검해보라’ 라는 팁을 주고 있다. 애초에 랜더링이 빠른 경우라면 리랜더링 수를 줄이기 위한 최적화를 덜 신경써도 충분히 앱은 잘 동작한다는 것이다.
  • 그런데 느린 랜더링을 방치하게 되면 약간의 상태 변경만 일어나도 컴포넌트 트리의 느린 랜더링 때문에 불편한 사용자 경험을 줄 수 있다. 따라서 브라우저 기본 도구의 퍼포먼스 탭, 리액트 개발자 도구의 프로파일링 기능을 적극적으로 활용하여 느린 랜더링이 발생하는 부분을 잘 잡아내려는 노력도 필요하다.

OSS

• Husky 사용할 때 주의! - 코드쓰는사람 
  • 현재 시점에서 Husky v5를 사용하게 되면 MIT 라이선스가 아니라 한시적인 기간동안 Parity 라이선스가 적용된다고 한다. 그 ‘한시적인 기간’ 이 언제 끝날지도 모르는 노릇이라, 상용 프로젝트에서는 v4에 머물러 있거나 다른 대안을 사용하는게 나을 것이다.
  • 그런데 어차피 현재 회사 프로젝트에서는 간단한 pre-commit 훅을 사용하는 정도라서 글 안에 추가로 소개되어있던 node-git-hooks 로 쉽게 마이그레이션 할 수 있었다.
• GitHub - fingerprintjs/fingerprintjs: Browser fingerprinting library with the highest accuracy and stability. 
  • 사용자 추적과 관련된 커뮤니티 글을 읽다가 댓글로 이 라이브러리 이야기가 나왔었다. 사이트를 옮겨다니는 경우에도, 브라우저가 Private 모드일 때도 사용자르 특정하고 추적하기 위해서는 어떤 기술이 필요한지 고민해보면서 찾게 된 것인데, 추적을 막기 위한 자와 어떻게든 추적하고자 하는 자의 대결 같아서 코드를 읽으며 가슴이 웅장해지는 느낌이었다.
• 유명한 오픈소스 개발자가 말하는 오픈소스의 어두운 면 
  • fullPage.js 라는 라이브러리를 만든 Álvaro Trigo 의 트윗 스레드이다. 나는 이 정도 프로젝트를 개발하는 개발자라면 충분히 유명한 오픈소스 개발자라고 생각하고 제목을 저렇게 지었다. 아래는 트윗 스레드를 일부 발췌하여 옮긴 것이다.
  • 깃헙에서 높은 인지도를 쌓고 있는 오픈소스 프로젝트들은 대개 기업 주도의 프로젝트들이다. (Angular, Font-Awesome, React, Bootstrap, Tensorflow, Flutter, VSCode 등) 왜 우리 모두는 오픈 소스 프로젝트를 할 수 없을까? 우리 모두가 할 수 있는 것 아니었나?
  • 하지만 메인테이너나 기여자들이 자신의 시간을 내던지고 참여하지 않는 한 프로젝트를 제대로 운영하는 것은 매우 어렵다. 특히 프로젝트가 유명해지고 나면 오히려 유지보수 딜레마에 빠지게 된다. 유지보수를 그만두고 자신의 삶을 살 것인지, 아니면 계속 하던지.
  • 계속 프로젝트를 개발하는 개인의 입장에서는 나름의 원동력이 필요하다. 트윗 작성자의 경우는 풀타임 근로자로 일하는 것을 그만두고 자신의 프로젝트에 유료 라이센스를 도입하여 동기부여를 할 수 있었고, 나름의 성공을 했지만 모두가 이럴 수 있는 것은 아니다.
  • 따라서 정말 마음에 들거나 자신에게 직접적으로 도움이 되는 오픈소스 프로젝트가 있다면, 그 프로젝트가 가져다주는 이득을 유지할 수 있도록 어떤 형태로든 도움을 주는 것이 서로에게 좋지 않을까?

Tools

• explainshell.com - match command-line arguments to their help text 
  • 쉘 스크립트의 명령어를 입력하면 man 페이지 기반으로 각 명령어의 옵션과 인자가 무엇을 뜻하는지 쪼개어 설명해주는 친절한 웹사이트.
  • 불현듯 정규표현식에서는 이런 사이트 가 있다는 것이 생각났다.
• How to choose the right note-taking app: the ultimate guide - Ness Labs 
  • 노트를 사용하는 방법에 따라 건축가, 정원사, 사서 3종류로 나눌 수 있고, 그에 따라 적절한 분류에 해당하는 노트 앱을 소개해주고 있다.
    • 자신의 생각을 쉽게 구조화하기를 원하는 ‘건축가’
    • 자신의 생각을 쉽게 확장시키기 원하는 ‘정원사’
    • 자신의 생각을 쉽게 다시 찾기를 원하는 ‘사서’
  • 지금의 나는 본문의 분류법에서 ‘건축가’ + ‘사서’ 의 유형이 적당히 겹쳐져 있는 듯 한데, 그래서 그런지 추천 앱으로 제안되는 노션과 베어를 3:7 비율정도로 써먹고 있다.
  • 어차피 앱에 자신의 기록 방식을 맞출 필요도 없으니 자신이 어떤 방식으로 생각을 정리하고 활용하는지 충분히 고민해보고 시도한 뒤 그때그때 쓸만한 앱을 활용하면 될 것이라 생각한다.