juncci 님의 블로그

웹 페이지에서 이미지는 전체 네트워크 리소스 중 큰 비중을 차지한다. 특히 상품 이미지나 배너처럼 고해상도 원본 이미지를 그대로 전달하면 사용자가 실제로 보는 크기보다 많은 데이터를 다운로드하게 되고 이미지가 화면에 표시되는 시간에도 영향을 줄 수 있다. Next.js는 이러한 문제를 줄이기 위해 next/image의 컴포넌트를 제공한다.처음에는 를 사용하면 이미지를 자동으로 압축해주는 정도로 생각하기 쉽다. 하지만 실제 동작을 살펴보면 이미지 압축 하나로 끝나지 않는다. Next.js는 브라우저가 적절한 이미지를 선택할 수 있도록 여러 이미지 후보를 제공하고 선택된 요청에 맞는 이미지를 생성한다. 생성된 결과는 캐시를 통해 재사용할 수 있으며 이미지의 위치와 중요도에 따라 로딩 시점도 조절할 수 있다..

프로젝트에서 홈 화면의 추천 데이터를 Server Component에서 가져오는 과정에서 추천 API의 응답 지연이 전체 SSR 응답 시간에 영향을 주는 문제가 있었다. https://juncci.tistory.com/28 홈은 계속 보여야 한다: SSR 환경에서 AI 추천 API의 지연과 실패에 대응하기RE-FIT 서비스 홈에는 사용자에게 적합한 전문가를 보여주는 AI 기반 추천 영역이 있습니다. 추천 데이터를 첫 화면부터 제공하기 위해 해당 영역은 클라이언트에서 별도로 요청하는 구조가 아니juncci.tistory.com 추천 데이터는 홈 화면에서 반드시 필요한 핵심 콘텐츠는 아니었기 때문에 추천 API가 느려지거나 일시적으로 장애가 발생했다는 이유로 홈 전체의 응답이 영향을 받는 구조를 줄이고자 했..

이전 글에서는 Web Worker가 무엇인지, 일반적인 비동기 처리와 어떤 차이가 있는지 정리했습니다. [EP.1][Web Work] Web Worker의 개념과 동작 원리프로필 이미지 업로드 기능을 구현하면서 클라이언트에서 이미지를 리사이즈하고 WebP 형식으로 변환하는 작업을 추가했습니다.사용자가 선택한 이미지를 그대로 서버에 업로드하지 않고, 다음juncci.tistory.com Web Worker는 무거운 JavaScript 연산을 메인 스레드와 분리된 워커 스레드에서 처리할 수 있도록 해줍니다. 그러나 Web Worker를 생성했다고 해서 이미지 리사이즈나 포맷 변환이 자동으로 가능해지는 것은 아닙니다. 이미지 크기를 조절하고 다른 포맷으로 변환하려면 이미지를 실제 픽셀 데이터로 디코딩하고, 새..

프로필 이미지 업로드 기능을 구현하면서 클라이언트에서 이미지를 리사이즈하고 WebP 형식으로 변환하는 작업을 추가했습니다.사용자가 선택한 이미지를 그대로 서버에 업로드하지 않고, 다음과 같은 과정을 거치도록 구현했습니다.원본 이미지 선택 → 이미지 디코딩 → 최대 크기에 맞게 리사이즈 → WebP 형식으로 인코딩 → 원본과 용량 비교 → 더 작은 파일을 업로드 이 과정에서 이미지 처리가 메인 스레드를 점유할 가능성을 줄이기 위해 Web Worker와 OffscreenCanvas를 사용했습니다. 구현 내용을 정리하던 중, 어느 순간부터 Web Worker와 Service Worker라는 용어를 혼용해서 사용하고 있다는 사실을 발견했습니다.둘 다 이름에 Worker가 들어가고 브라우저에서 메인 JavaScr..

프론트엔드나 Node.js 프로젝트를 시작하면 거의 반드시 마주치는 도구가 있다. 바로 패키지 매니저(package manager) 다.패키지 매니저 필요한 라이브러리를 설치하고, 의존성 버전을 관리하고, 팀원이나 CI 환경에서도 같은 결과가 나오도록 재현성을 확보하는 역할을 한다. npm 공식 문서도 npm을 “Node JavaScript 플랫폼의 패키지 매니저”라고 설명하며, lockfile은 이후 설치에서도 동일한 의존성 트리를 재생성할 수 있도록 exact tree를 기록한다고 설명한다. 패키지 매니저는 단순히 install 명령을 실행하는 도구가 아니라, 다음 세 가지를 동시에 책임지는 인프라에 가깝다.패키지 검색 및 설치의존성 버전 해석과 잠금(lock)로컬, CI, 배포 환경의 재현성 유지J..

이전 글에서는 캐싱을 감으로 결정하지 않기 위해 먼저 판단 기준을 정의했다.2026.04.07 - [[FE]] - [TanStack Query] Lv.1 수치 기반 선택 [TanStack Query] Lv.1 수치 기반 선택프론트엔드에서 캐싱은 흔하다.기존 프로젝트에서는 이미 TanStack Query나 SWR 같은 라이브러리를 사용하고 있고,“어디에 캐싱을 적용할 것인가”에 대한 나름의 기준도 가지고 있다.하지만 그 기juncci.tistory.com2026.04.08 - [[FE]] - [TanStack Query] Lv.2 코드로 구현한 수치 기반 캐싱 [TanStack Query] Lv.2 코드로 구현한 수치 기반 캐싱이전 글에서는 캐싱을 감이 아니라 수치로 판단하기 위해2026.04.07 - [..

이전 글에서는 캐싱을 감이 아니라 수치로 판단하기 위해2026.04.07 - [[FE]] - [TanStack Query] Lv.1 수치 기반 선택 [TanStack Query] Lv.1 수치 기반 선택프론트엔드에서 캐싱은 흔하다.기존 프로젝트에서는 이미 TanStack Query나 SWR 같은 라이브러리를 사용하고 있고,“어디에 캐싱을 적용할 것인가”에 대한 나름의 기준도 가지고 있다.하지만 그 기juncci.tistory.com calls요청 발생 시 count 증가endpoint별 총 호출 수duplicateRateduplicateCalls / calls동일 endpoint 중복 요청 비율rehitWithin30sRaterehitCalls / (calls - 1)30초 내 재호출 비율avgMstot..

프론트엔드에서 캐싱은 흔하다.기존 프로젝트에서는 이미 TanStack Query나 SWR 같은 라이브러리를 사용하고 있고,“어디에 캐싱을 적용할 것인가”에 대한 나름의 기준도 가지고 있다.하지만 그 기준을 자세히 들여다보면 대부분 이런 식이였다.자주 쓰이니까 캐싱하자느리니까 캐싱하자중요한 데이터니까 최신으로 유지하자이 판단들은 틀린 말은 아니다. 실제로 많은 상황에서 유효하다.문제는 이 기준들이 정량적인 근거 없이도 항상 그럴듯하게 들린다는 점이다. 실제 프로젝트에서도 비슷한 문제가 있었다.프로필을 수정해도 화면에는 즉시 반영되지 않았고, 새로고침을 해야만 변경 사항을 확인할 수 있었다.기술적으로는 TanStack Query의 캐시를 업데이트하거나 invalidate 하면 해결되는 문제였다.queryCl..