꾸준함
- 무라카미 하루키의 달리기를 말하는 책에서 가장 큰 핵심은 꾸준함이지 않을까
- 달리기 싫은 하루에도 그래도 밖으로 나가 한발자국 움직이며 다시 달리는 것
- 글쓰기에만 해당되는 것이 아니라 모든 것에 해당되는 이야기
- 꾸준하게 하는 것에 가장 큰 어려운 점은
- 기대한만큼 결과가 나오지 않아 실망스러울때
- 그래도 다시 리셋하고 계속 해야한다는 것
- 리셋 하는 방법에는 다양할 것 같다
- 그냥 잊어버리거나 되새기며 내딛음의 근원으로 삼아가거나
- 그 중간에 힘들어 내려놓아버리면 리셋이 아닌데
- 왜 여기까지 왔지 싶은데
- 지름길은 없으며, 결국 노력과 시간, 그리고 꾸준함
- 이 문장이 하루키 까지 가버렸다
- (추가) 그렇게 시간이 흘러 어느날
- 달리기로 배운 성장의 법칙 🥺
- 잘못된 노력
- 단순히 노력을 했다고 결과를 얻으리라는 착각
- 발전은 체감되지 않음
- 발전은 항상 몰래 다가옴
- 도전하지 않으면 발전하지 않는다
- 너무 자극적이기는 하지만
적절한 피드백은 목적지에 빠르게 도달하게 하지만, 과도한 피드백은 속도를 늦추고 원하는 곳에 도달하지 못할 위험에 빠지게 함- 협업은 드라이버가 속도를 늦추고 배경, 맥락, 생각을 설명하도록 강제
- 무엇을 원하는지 필요한지 전달하지 않고 그냥 요청해버리기 때문
누구에게 구체적으로 무엇을 원하는지 명확하게 요청하도록- 무엇을 질문하는 것인지 알지 못한게 그냥 질문을 던져
- 불필요한 설명이나 핑퐁으로 속도라 늦춰지는 것을 방지하는 의미
- 버그를 확실하게 재현해내어야 고칠 수 있다
- 재현한 시나리오로부터 확실하게 버그가 사라졌다고 끝나는게 아니라
- 또 다른 시나리오에서도 문제가 되지 않는지 확인되어야한다
- 스크롤을 아래로 내릴때 발생하던 문제를 수정했다면 위로 올릴때 다른 문제가 생기지는 않았는지 추가 확인하는 느낌이랄까
- 문제가 되는 부분을 좁혀가며 재현해보는 것
- 어디가 문제인지 정확하게 모르겠지만
- 이 코드를 추가한 뒤로 문제가 발생했다면 그 코드의 범위를 좁혀가며 재현하는 방법
- 수작업을 필요로 하지만 이만큼 확실한 방법이 또 없나보다
코드를 하나씩 제거하면서 버그가 여전히 남아 있는지 확인하는 방법
- 이 글에서는 AI 툴을 이용해 바이브 코딩하면서 발생한 문제를 해결하기 위한 과정으로
- 문제 재현을 AI 에게 전달하기 위한 고민과 문제 해결에 대한 접근 방법에 대한 고민
- 모노레포 vs 멀티레포 형태로 구성된 각각의 서비스에 대한 AI 도입 시 생산성 향상 비교
- AI가 컨텍스트를 이해하는데 모노레포가 훨씬 좋기 때문에 높은 생산형 향상이 기대되는 반면
- 멀티레포 형태에서는 분할된 컨텍스트로 접근 어려움
- 모두 가져와 이해하도록 하면 되지 않을까 싶은데 🤔
- 여기서 비교하는 것은 모노레포와 멀티레포 각각 PR 갯수로
- 분리된만큼 각각의 레포에 작업해야하는 양이 많기에 갯수가 많아지기 때문이라고 하는데
- 컨텍스트를 하나의 레포에서 찾아보는게 조금 더 유리할 수 있으나
- 너무 극단적으로 분리가 많이 되어있다면 이해도가 낮아진다는 것에 대한 동의하면서도
- 하지만 분리가 잘 되어있다면 서로 의존성이 낮아 하나의 목적으로 여러 수정을 필요로하지 않을 것 같다는 생각
- CSR, SSR, RSC 각각 성능 지표 비교해보고 어떤 것이 좋은지 알아보는 내용
- 첫번째 페인트 까지의 시간을 측정한 FCP
- 가장 큰 컨텐츠를 노출하기 까지의 시간을 측정한 LCP
- 무언가 인터랙션을 통해 다음 페인트까지의 시간을 측정한 INP
- (참고) Initial load performance for React developers: investigative deep dive
- 여기서는 LCP(1)와 그 다음 데이터 패칭된 페인트(2), 그리고 무언가 인터랙션을 할 수 있게 되는 순간(3) 을 지표로 삼았다
- CSR
- js를 로드하는 시간이 필요하기에 LCP까지의 시간은 조금 길게 소요된다
- 로드가 끝난 시점에 바로 인터랙션 가능해지기에 (3) = (1) 이 된다
- 만약 js가 한번 캐싱되어있다면 이후에 접근할때엔 (1) 자체가 빨라진다
- SSR
- 서버에서 미리 HTML 을 구성해서 넘어오기에 (1) 자체는 빠르다
- 하지만 가져온 js를 읽고 나서야 인터랙션이 가능해지기에 (3)은 여전히 시간이 필요하다
- 만약 서버에서 데이터 패칭까지 처리해준 뒤 응답을 주는 방법이라면
- 데이터 패칭을 기다린 뒤 HTML 이 넘어오기에 (1) 자체가 다시 느려진다
- 데이터가 포함되어있기 때문에 (2) = (1) 이 되고
- CSR의 (2) 보다는 이미 한번에 서버에서 처리해왔기 때문에 조금 빠르다
- RSC
- 데이터 필요하지 않은 것은 서버를 통하지 않도록 번들에 포함하여 (1)이 빠르게 나타나도록 한다
- 데이터 필요한 것만 서버 비동기 요청하며 이때 컴포넌트는 Suspense로 감싸져 아무것도 노출하지 않는 것이 아닌 무언가 노출되도록 하므로써 (1)과 (2) 사이의 간극을 줄일 수 있다
사용자에게 가장 좋은 것이 무엇인지에 대한 여러분의 이해를 바탕으로 내리는 제품 결정(product decision)이 될 것입니다.
- 어떤 것을 가장 주요한 지표로 삼는지에 따라 CSR, SSR, RSC 각각의 장점을 활용하도록
- 서버에서 미리 데이터 패칭하고 렌더링 하는 것은 초기 렌더링 성능에 좋으나
- 페이지가 이미 보이지만 js를 아직도 불러오고 있는 상태인 경우가 있어 인터랙션까지의 시간이 길어진다
- 서버로부터 무언가 가져와야 한다는 것이 동기로 동작하기 때문에
- 컴포넌트 단위로 작게 분리된 각각의 페인트가 각각 서버로부터 가져와 그리도록 하여 최대한의 효율을 얻어낼 수 있다