juncci 님의 블로그

이전 글에서는 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..

프로필 이미지 하나 때문에 성능이 무너지는 경험을 했다.페이지 자체는 가볍다고 생각했지만,Lighthouse를 확인해보니 LCP가 비정상적으로 길게 측정되고 있었다.원인을 추적해보니 문제는 단순했다.화면에는 작게 보이는 이미지가,실제로는 수백 KB에 달하는 원본 이미지 그대로 전달되고 있었다.이 문제를 해결하기 위해 이미지 최적화를 적용하게 되었고,단순히 용량을 줄이는 수준이 아니라업로드 → 전달 → 렌더링까지이미지 흐름 전체를 다시 설계하게 되었다. ⭐ 이미지 최적화는 단순히 “용량을 줄이는 작업”이 아니다. 사용자가 페이지를 얼마나 빠르게 인지하고 상호작용할 수 있는지를 결정하는 중요한 사용자 경험 요소다. ⭐ 실제 사용자 경험에 영향을 주는 요소는 다음과 같다.얼마나 작은 이미지인가얼마나 빠르게 ..

참고 자료[1] 당근마켓, 「1주 1개 실험하는 프로덕트 팀이 되는 여정」 (링크)[2] 토스, 「진짜 A/B 테스트: 토스의 푸시 생태계를 데이터로 재설계한 방법」 (링크)[3] 토스, TMC25 | Product - 토스 데이터 분석가가 하는 진짜 A/B테스트 - 발표 영상 (링크) 제품을 만들다 보면 끊임없이 선택해야 한다. 버튼 문구, 화면 흐름, 기능 노출 방식까지.이런 결정들은 작아 보이지만 실제로는 사용자 행동과 서비스 지표에 직접적인 영향을 준다. 문제는 이러한 선택들이 종종 명확한 근거 없이 직관이나 경험에 의존해 이루어진다는 점이다.“더 좋아 보인다”는 판단으로 빠르게 실행되지만 결과는 예상과 다르게 나타나는 경우도 많다.이 지점에서 자연스럽게 질문이..