위 질문들을 작성해주신 작성자분께서는 혼자 일을 하는 사람들을 위한 글을 쓰시는 분이다보니 다소 개인적인 영역에 대한 질문들도 포함되어있는 것 같지만, 사실 일과 삶의 경계가 모호하다고 생각하는 나의 입장에서 이런 질문들은 삶을 복합적으로 이해하는 면에서 유익하다 느껴진다.
그럼 질문을 따라 답을 작성해봐야겠다.
건강
•
2023년 중반정도부터 풋살 / 수영을 시작하게 되었고, 이제는 풋살만 꾸준히 진행하고 있다. 앉아서만 일하는 직업이다보니 최대한 주말이나 평일 중에 활동적인 취미를 가져야겠다는 생각에 꾸준히 해오고 있고 좋아하는 운동이어서 스트레스 관리에도 꽤나 도움이 많이 되는 것 같다.
•
작년 말부터 식이 조절을 통한 다이어트를 해왔는데, 그 때 식습관과 수면에 대한 중요성을 굉장히 많이 느꼈다. 정제당이 우리 몸의 면역과 균형을 무너뜨리게 되는 부분들과 영양의 불균형이 가져오는 문제 / 수면의 질이 삶에 미치는 영향들에 대한 영상들이 한동안은 유튜브에 지속적으로 노출되었다. (요즘에는 유튜브나 인스타그램의 추천 목록을 살펴보면 한 사람이 꽤나 파악되는 것 같다.)
•
관심을 가져서인지 지속적으로 건강한 상태의 몸과 정신을 유지하고 있는 것 같다. 지속적으로 더 나은 건강을 유지하기 위해 이제는 PT도 등록하여 한달가량 몸을 단련하려 한다. 아이가 곧 출생하게 되는 것 때문에라도 열심히 체력을 기르려는 참이다.
지난 회고 에서는 벤디트로 이직 후의 1년을 되돌아보다보니, 22-23년을 걸쳐 회고하게 되었었는데, 이제 1년 단위로 다시 한 해를 반추해봐야겠다.
Events
Concierge Product Release
올해 초, 컨시어지 제품의 개발에 갑작스레 참여하게 되어 제품의 백엔드를 맡아 만들게 됐다. 한 제품의 온전한 뒷단을 맡은 건 처음이었지만 많은 도움들 덕에 다행히 프로덕트가 릴리즈 될 수 있었다.
린 고객 개발에서 말하는 유효한 비즈니스 모델을 위한 조사 방식
하지만 전달된 제품이 고객의 가려운 부분을 긁어주기엔 기획단계에서부터 엉성한 부분이 많았던 제품이 아니었나 싶다. 제품을 만드는 과정에서 개발자분의 리텐션이 떨어져 떠나보내게 되는 결과를 낳기도 하였고, 힘겹게 출시하였음에도 실제 제품을 통해 매출이 발생하는 건은 손에 꼽았었을 정도(현재는 다행히도 활용하는 고객이 나타나서 이슈를 가끔씩 처리하곤 한다.. 🥹)로 아쉬움이 많이 남는 프로덕트다.
Working As Squad(6 Sprints & 1 Kanban)
이전 직장에서부터 스쿼드로 애자일하게 일하고 싶다는 열망을 가졌었던 나에게 벤디트에서 조직 변경은 무척이나 임팩트가 있던 사건이다. 그러나 진정한 스쿼드로 일하기 위해서는 많은 요소들이 갖춰져야 했다.
스쿼드 구성하기
팀 변경 시점에 프로덕트 팀은 두 개의 스쿼드로 분리하기로 결정했다. 당시 프로덕트 팀의 조직 구성은 다음과 같았다.
풀스택 3명 / 백엔드 1명 / 프론트 2명 / 디자이너 1명 / PM 1명
디자이너와 PM이 각각 1명씩 뿐이었기 때문에 두 스쿼드에서는 개발자가 PM 역할을 맡기도 했고, 프론트엔드 엔지니어가 디자인을 담당하기도 했다. 이는 한 명이 여러 역할을 수행하는 어려움을 야기했다.
ECMAScript 스펙에 따르면 실행 컨텍스트를 실행 가능한 코드를 형상화하고 구분하는 추상적인 개념
이라고 정의한다. 좀 더 쉽게 말하자면 실행 컨텍스트는 실행 가능한 코드가 실행되기 위해 필요한 환경
이라고 말할 수 있겠다. 여기서 말하는 실행 가능한 코드는 아래와 같다.
Yarn Berry는 기존의 “깨져 있는” NPM 패키지 관리 시스템을 혁신적으로 개선합니다.
NPM 뭐가 문제야?
NPM은 Node.js 설치 시에 기본으로 제공되어 범용적으로 사용되고 있으나, 비효율적이거나 깨져 있는 부부이 많습니다.
비효율적인 의존성 검색
NPM은 파일 시스템을 이용하여 의존성을 관리합니다. 익숙한 node_modules 폴더를 이용하는 것이 특징인데요. 이렇게 관리했을 때 의존성 검색은 비효율적으로 동작합니다.
예를 들어, /Users/toss/dev/toss-frontend-libraries 폴더에서 require() 문을 이용하여 react 패키지를 불러오는 상황을 가정합시다.
라이브러리를 찾기 위해 순회하는 디렉토리의 목록을 확인하려고 할 때, Node.js에서 제공하는 require.resolve.paths() 함수를 사용할 수 있습니다. 이 함수는 NPM이 검색하는 디렉토리의 목록을 반환합니다.
목록에서 확인할 수 있는 것처럼, NPM은 패키지를 찾기 위해서 계속 상위 디렉토리의 node_modules 폴더를 탐색합니다. 따라서 패키지를 바로 찾지 못할수록 readdir, stat과 같은 느린 I/O 호출이 반복됩니다. 경우에 따라서는 I/O 호출이 중간에 실패하기도 합니다.
TypeScript 4.0까지는 node_modules를 이용한 패키지 탐색이 너무 비효율적인 나머지, 패키지를 처음으로 import 하기 전까지는 node_modules 내부의 타입 정보를 찾아보지 않기도 했습니다. (TS 4.0 Changelog)