1년차때는 나에게 주어진 태스크를 그저 '달성'하는데에 집중했다. 단순히 기능을 '구현'하는게 가장 주요한 관심사였고, 그외의 것들까지 모두 다 챙기기는 쉽지 않았다.
첫 회사에서 딱 6개월 정도 지나니까 기능 구현 그 자체에는 큰 문제가 없기 시작했다. 특별히 어려운 기능이 아니라면, 적절히 비즈니스적으로 필요한 시기까지 기능을 딜리버리하는데에는 무리가 없었다. 이때부터, 기능 구현 이상의 것들을 생각하기 시작했다. 나에게 주어진 기능을 개발하는 것 뿐만 아니라, 팀 동료와 함께 성장할 수 있는 기회를 만들어내는 법, 리소스를 효율적으로 쓸 수 있는 환경을 구축하는 법, 조금 더 좋은 코드, 서비스 운영을 위한 시스템 등을 고민하기 시작했다.
처음 개발자 커리어를 시작했을 때, 데일리 스크럼에서 누군가가 "어제는 회의가 너무 많아서, 일 할 시간이 없었습니다." 라고 자신의 일의 진행상황을 팀에 공유했다. 그 워딩 자체를 듣고 바로 들었던 생각은 "회의는 일이 아닌가?" 라는 생각이었다.
직전 포스트에서 살펴보았듯이, React v18에서 도입된 concurrent feature들은 기본적으로 React의 렌더링 과정을 더 정교하게 설계할 수 있도록 옵션을 준 것이라고 생각할 수 있다.
그 concurrent feature들 중 Suspense는 개발자가 Suspense 경계를 직접 나누면서, 비동기 데이터가 준비되고 있는 동안에는 해당 컴포넌트가 중단(Suspensed)되고, 실제로 데이터가 로드되었을 때 해당 컴포넌트를 렌더링한다.
Suspense의 등장 배경에 대한 자세한 내용은 직전 포스트에서 살펴볼 수 있다. 해당 포스트에서는 Suspense가 어떤 맥락에서 등장했고, 왜 필요한지에 대해 알아 볼 수 있다.
가장 먼저, React Suspense가 등장한 배경을 알기 위해서 React 공식문서로 접근해본다.
2일전, 세분의 사람을 만났다.
한분은 소마 과정에서 우리를 도와주시는 구글 클라우드 아키텍트 멘토님, 한분은 YC에 투자받고 현재 사업을 하고 계신 대표님, 한분은 위 멘토님 소개로 인연을 이어가고 있는 대표님이었다.
나는 지금까지 워크플러그를 만들면서, '어떤 가치를 가진 제품을 만들까?'가 아닌, '어떻게 만들까?'를 훨신 많이 생각했던 것 같다.
어제 가설 검증 방법의 중요성에 대해 이야기하면서, 인터넷을 통해 관련 자료를 찾으면서 공부하기 시작했다.
현재 아이템을 시작하면서 가장 크게 실수한 부분이 있다면, 가설 검증 설계에 시간을 투자하지 않은 것이다.
팀을 리딩하는 사람의 역할은 무엇일까?
아직 유의미한 사용자를 모으지는 못했지만, 서비스를 열어두니 재밌는 일이 일어난다.
3일전, 그동안 준비했던 제품을 출시했다.