엔지니어 출신 글쓴이가 프로덕트 매니징을 맡게 되면서 관련된 글을 수집한 노션 페이지이다.
엔지니어 뿐 아니라 프로덕트 오너 / 매니저 등의 역할에 참여하는 초보들이 참고하기 좋은 글들의 묶음이었다.
커뮤니케이션, 마인드셋, 타인과 일하기 등은 어느 정도 경험을 통해서 익숙해지고 있는 분야라고 생각했는데 사용자 온보딩, 마케팅, 그로쓰 등은 단어의 뜻만 대충 알지만 내가 일하면서 직접 접해볼 일이 없다보니 흥미를 가지고 읽어볼 수 있었다. 특히 제품 개발에 참여하는 엔지니어라면 가볍게 이런 내용들이 있다는 것을 파악하기 위해서라도 읽어보기 좋아 보인다.
기본적으로 브라우저는 어떤 방식으로 DOM을 그리고, 우리가 그 DOM을 다룰 때 유의해야 할 점은 무엇인가? 등등을 고민하고, 최적화를 위해 어떤 고민이 따라가야 하는지 고민한 내용을 담담하게 풀어내셨다.
‘트렌드를 버리다’ 라는 제목과 연관지어 결말 부분에서 개발자로서 항상 머리속에 달고 살아야하는 ‘왜?’ 라는 질문을 조금 구체화해주신 내용이 좋았다. 잘 나가는 라이브러리들은 어떤 필요에 의해서 나왔는지, 그게 정말 나의 문제를 해결하는 해결책이 되는지, 왜 나는 남들이 만들어 놓은것만 쓸 수 밖에 없는지 등등
1년 후 소감 뿐 아니라 올해 최신판인 2년후 소감 도 있다. 주로 오픈소스로 제작하고 계시는 웹 디자인 에디터의 개발 디테일에 대한 이야기이지만, 구현을 위한 고민과 열정을 피부로도 느낄 수 있을 정도여서 존경스럽다.
일단 SI 업계 안에서 코드 퀄리티의 중요성에 대해 이야기를 하고 계시지만, 그냥 어떤 회사에서 일을 하더라도 개발자로서 반드시 신경써야 하는 부분을 잘 짚어주셨다고 생각한다.
‘코드 레벨’ 이라는 단어가 조금 추상적으로 보였는데 본문을 읽으면서 추측해보면 “자신이 생각하는 로직을 프로그래밍 언어에 가리지 않고 잘 구조화된 코드로 끌어내는 능력” 이라고 보여진다.
툴에 능숙한 개발자가 좋은 개발자가 아니며, 폴더 구조부터 상당한 Context를 전달할 수 있는 개발자, 천 줄짜리 로직을 신입이 쭉쭉 읽으면서 바로 이해가 되게 만들어 놓는 개발자, 함수명을 보고 주석을 처리하면 딱 그 기능만 제외될 정도로 모듈화를 시켜놓는 개발자 등이 잘 하는 개발자라는 이야기다.
결국 잘 짜여진 코드, 이해하기 쉬운 코드, 모듈화 잘 되는 코드 등 개발 관련하여 추천되는 기본서들에 한 번쯤은 언급되는 내용들이지만 말처럼 쉽게 잘 하기 어렵다는 내용일지도.
IT 산업도 시스템 엔지니어링부터 제일 끝단의 클라이언트 개발까지 다양한 분야가 존재하고, 그 안에서도 아주 다양한 소분류가 있다. 그 속에서 특정 직군은 잘 나가는 상황이기도 하고, 그렇지 않아서 “자신에게 적합하지 않은 프로그래밍 일자리를 가지고 있다” 라고 생각하는 사람들도 존재하는 것이다.
그나마 개발자를 채용하는데 필요한 역량은 기술 스택이 전부는 아닌지라, 계속 커리어를 바꾸기 위한 방향 전환을 게을리하지 않으며 본인의 소프트 스킬을 더욱 끌어올릴 수 있다면 원하는 직군으로 갈아타기 쉽지 않을지 조심스럽게 추측해본다. 기사는 외국 기사 번역이라 그게 상대적으로 쉬울지 모르겠으나, 한국은 마냥 쉽지 않겠지만.
그런데 어차피 살아가면서 개발자만 할 확률도 100%는 아니며, 그 중에서도 지금 하고 있는 직무를 유지하고 있을 확률은 더 적다고 생각한다. 결국 ‘소프트웨어를 다루는 스킬로 주어진 문제를 해결하는 사람’ 으로서 개발자의 역량을 끊임없이 갈고 닦아야 ‘잘 나가는 개발자’ 는 아니라도 최대한 업계에서 살아남을 수 있지 않을까? 결국은 살아남는 사람이 승자다.
트위터로 CSS-in-JS에 대해 질답이 오갈 일이 있었다. 대화 과정 속에서 내가 생각했던 결론은, CSS-in-JS 자체가 나쁜 것이 아니라 이를 잘못 사용하는 사람들이 애플리케이션의 효율적이고 잘 구조화된 스타일링을 못하는 것이 문제라는 것이다.
링크된 글은 트윗이 오가는 중에 인용된 것이었다. 자바스크립트로 작성되는 구조적/행위적 기반 스타일링과 CSS로 이루어지는 그래픽 기반의 스타일링의 차이에 대해 이야기하고, CSS-in-JS가 애플리케이션의 시각적 일관성을 해치고 코드의 재사용성이 기대와 다르게 떨어질 수 있다는 이야기를 한다. 결론으로 더 나은 CSS 모범 사례를 활용하는 것을 결론으로 내 놓았는데, CSS 구조화를 잘 해두었다면 충분히 코드 재사용성을 높일 수 있긴 하다. 어려워서 그렇지. 그래서 CSS-in-JS에 대한 비판보다는 스타일링을 제대로 하지 못하는 개발자들이 비판의 대상이 되어야 한다고 생각하게 만드는 글이었다. 나도 그 못난 개발자 중 한명이다.
Cascading이라는 특징을 활용할 수록 요즘 주된 개발 방식인 ‘컴포넌트 기반 개발’ 이 어려워지는 부분이 있는데, ‘애초에 내가 개별 컴포넌트를 잘 구조화하고 재사용성 높은 쓸모있는 녀석으로 만들고 있는가?’ 라고 반성하게 되기도 했다.
1~2편을 통해 자바스크립트, 타입스크립트 + 리액트 개발환경까지 직접 만들어볼 수 있다. ESLint + Babel, Prettier, Webpack 등을 설정하는 방법을 알 수 있다. 기왕 하는거 husky나 다른 라이브러리를 활용한 git hooks 설정도 추가되었으면 더 좋았겠다.
보일러플레이트를 사용하지 않고 새로운 프로젝트를 세팅 해 본다고 할 때 어떤 식으로 해야할지 감이 잡히지 않는 사람들에게 아주 좋은 정보가 될 것이다. 이미 한 번 정도는 해볼 사람이라면 가장 최신 버전 기준으로 어떻게 새 프로젝트를 구성해야 하는지 참고가 될 것이다.
styled-components 와 비슷하게 큰 인기를 끌고 있는(그리고 요즘은 처음 프로젝트를 만드는 경우라면 더욱 추천되는) emotion 라이브러리를 이용하는 경우 타입스크립트 + Context API를 활용하여 효과적으로 테마를 관리하는 방법을 소개하는 글이다.
styled 컴포넌트와 ThemeProvider 를 리턴하게 만드는 makeTheme 같은 함수 활용이 무척 흥미로웠다. 나 자신은 보통 별도로 프로바이더를 리턴시키는 함수를 굉장히 제한적으로만 알고 사용해왔는데, 저런 방식으로 사용하는 것을 보니 식견이 넓어지는 기분이었다.
리액트 앱의 퍼포먼스 문제 혹은 버그를 잡다 보면 굉장히 많이 접하거나 떠오르는 단어가 있다. 바로 ‘리랜더링’(혹은 리랜더)이다.
위 두 글은 ‘리랜더링 자체는 큰 문제가 아니고, 랜더링 자체가 느리지 않은지 잘 점검해보라’ 라는 팁을 주고 있다. 애초에 랜더링이 빠른 경우라면 리랜더링 수를 줄이기 위한 최적화를 덜 신경써도 충분히 앱은 잘 동작한다는 것이다.
그런데 느린 랜더링을 방치하게 되면 약간의 상태 변경만 일어나도 컴포넌트 트리의 느린 랜더링 때문에 불편한 사용자 경험을 줄 수 있다. 따라서 브라우저 기본 도구의 퍼포먼스 탭, 리액트 개발자 도구의 프로파일링 기능을 적극적으로 활용하여 느린 랜더링이 발생하는 부분을 잘 잡아내려는 노력도 필요하다.
사용자 추적과 관련된 커뮤니티 글을 읽다가 댓글로 이 라이브러리 이야기가 나왔었다. 사이트를 옮겨다니는 경우에도, 브라우저가 Private 모드일 때도 사용자르 특정하고 추적하기 위해서는 어떤 기술이 필요한지 고민해보면서 찾게 된 것인데, 추적을 막기 위한 자와 어떻게든 추적하고자 하는 자의 대결 같아서 코드를 읽으며 가슴이 웅장해지는 느낌이었다.
fullPage.js라는 라이브러리를 만든 Álvaro Trigo의 트윗 스레드이다. 나는 이 정도 프로젝트를 개발하는 개발자라면 충분히 유명한 오픈소스 개발자라고 생각하고 제목을 저렇게 지었다. 아래는 트윗 스레드를 일부 발췌하여 옮긴 것이다.
깃헙에서 높은 인지도를 쌓고 있는 오픈소스 프로젝트들은 대개 기업 주도의 프로젝트들이다. (Angular, Font-Awesome, React, Bootstrap, Tensorflow, Flutter, VSCode 등) 왜 우리 모두는 오픈 소스 프로젝트를 할 수 없을까? 우리 모두가 할 수 있는 것 아니었나?
하지만 메인테이너나 기여자들이 자신의 시간을 내던지고 참여하지 않는 한 프로젝트를 제대로 운영하는 것은 매우 어렵다. 특히 프로젝트가 유명해지고 나면 오히려 유지보수 딜레마에 빠지게 된다. 유지보수를 그만두고 자신의 삶을 살 것인지, 아니면 계속 하던지.
계속 프로젝트를 개발하는 개인의 입장에서는 나름의 원동력이 필요하다. 트윗 작성자의 경우는 풀타임 근로자로 일하는 것을 그만두고 자신의 프로젝트에 유료 라이센스를 도입하여 동기부여를 할 수 있었고, 나름의 성공을 했지만 모두가 이럴 수 있는 것은 아니다.
따라서 정말 마음에 들거나 자신에게 직접적으로 도움이 되는 오픈소스 프로젝트가 있다면, 그 프로젝트가 가져다주는 이득을 유지할 수 있도록 어떤 형태로든 도움을 주는 것이 서로에게 좋지 않을까?