This month I Learned - 2021년 2월
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
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
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 등) 왜 우리 모두는 오픈 소스 프로젝트를 할 수 없을까? 우리 모두가 할 수 있는 것 아니었나?
- 하지만 메인테이너나 기여자들이 자신의 시간을 내던지고 참여하지 않는 한 프로젝트를 제대로 운영하는 것은 매우 어렵다. 특히 프로젝트가 유명해지고 나면 오히려 유지보수 딜레마에 빠지게 된다. 유지보수를 그만두고 자신의 삶을 살 것인지, 아니면 계속 하던지.
- 계속 프로젝트를 개발하는 개인의 입장에서는 나름의 원동력이 필요하다. 트윗 작성자의 경우는 풀타임 근로자로 일하는 것을 그만두고 자신의 프로젝트에 유료 라이센스를 도입하여 동기부여를 할 수 있었고, 나름의 성공을 했지만 모두가 이럴 수 있는 것은 아니다.
- 따라서 정말 마음에 들거나 자신에게 직접적으로 도움이 되는 오픈소스 프로젝트가 있다면, 그 프로젝트가 가져다주는 이득을 유지할 수 있도록 어떤 형태로든 도움을 주는 것이 서로에게 좋지 않을까?