https://waylog.pages.dev/category/performance Waylog Blog의 Performance 카테고리에 속한 글 모음 ko-KR Thu, 21 May 2026 13:50:29 GMT Tue, 31 Mar 2026 00:00:00 GMT Next.js https://waylog.pages.dev/posts/distributed-tracing-sampling-strategy-cost https://waylog.pages.dev/posts/distributed-tracing-sampling-strategy-cost Tue, 31 Mar 2026 00:00:00 GMT Performance 100% 수집이라는 환상이 운영 비용을 잡아먹는다 분산 아키텍처로 전환하고 나면 팀은 자연스럽게 모든 요청을 추적하고 싶어합니다. 우리 팀 역시 초기에 OpenTelemetry SDK를 붙이고 모든 trace를 Jaeger로 내보내는 설정을 처음 기본값으로 택했습니다. 문제는 트래픽이 늘면서 빠르게 드러났습니다. DAU가 20만을 넘어서는 시점에 Jaeger Elasticsearch 클러스터 비용이 APM 예산의 절반 이상을 차지하기 시작했고, Collector 파드의 메모리 사용량이 예측 불가능 https://waylog.pages.dev/posts/web-vitals-cls-lcp-field-data-crux https://waylog.pages.dev/posts/web-vitals-cls-lcp-field-data-crux Tue, 24 Mar 2026 00:00:00 GMT Performance 필드 데이터 없이 성능 개선을 논하는 것은 환자 없이 처방을 쓰는 것과 같다 Lighthouse 점수 100점을 받아도 CrUX(Chrome User Experience Report) 대시보드에 "Poor" 판정이 뜨는 경험을 해봤을 것입니다. 우리 팀은 대형 이커머스 프로젝트에서 정확히 이 상황을 겪었습니다. 로컬 Lighthouse에서는 LCP 1.8초, CLS 0.02로 "Good" 범위였는데, PageSpeed Insights의 필드 데이터 탭을 열었더니 LCP p75가 4.3초였습니다. https://waylog.pages.dev/posts/frontend-inp-optimization-long-tasks-react https://waylog.pages.dev/posts/frontend-inp-optimization-long-tasks-react Sun, 21 Sep 2025 00:00:00 GMT Performance 클릭했는데 화면이 늦게 반응하는 이유 웹 성능을 이야기할 때 오랫동안 LCP와 CLS가 중심이었습니다. 첫 화면이 빨리 뜨고 레이아웃이 흔들리지 않는 것은 여전히 중요합니다. 하지만 사용자가 실제로 서비스를 "빠르다"고 느끼는 순간은 버튼을 눌렀을 때 화면이 즉시 반응하는가에 달려 있습니다. Interaction to Next Paint, 즉 INP는 이 상호작용 지연을 측정하는 지표입니다. INP가 나쁜 페이지는 로딩이 끝난 뒤에도 답답합니다. 사용자가 필터를 클릭했는데 선택 표시가 늦게 바뀌고 https://waylog.pages.dev/posts/redis-cache-stampede-invalidation-patterns https://waylog.pages.dev/posts/redis-cache-stampede-invalidation-patterns Mon, 08 Sep 2025 00:00:00 GMT Performance 캐시는 빨랐지만 장애는 더 빨리 왔다 캐시는 백엔드 성능 최적화에서 가장 먼저 떠올리는 도구입니다. Redis를 앞에 두면 데이터베이스 조회를 줄이고, p95 응답 시간을 낮추고, 트래픽 피크를 흡수할 수 있습니다. 그런데 캐시는 제대로 설계하지 않으면 장애를 막는 장치가 아니라 장애를 증폭시키는 장치가 됩니다. 특히 트래픽이 높은 서비스에서 특정 키가 동시에 만료되는 순간, 수천 개의 요청이 한꺼번에 데이터베이스로 쏟아지는 캐시 스탬피드(cache stampede)는 생각보다 자주 발생합니다. https://waylog.pages.dev/posts/rust-wasm-frontend-hotpath-optimization https://waylog.pages.dev/posts/rust-wasm-frontend-hotpath-optimization Tue, 06 May 2025 00:00:00 GMT Performance JavaScript의 한계가 드러나는 순간: 핫패스를 Rust로 옮긴 1년의 기록 우리 프론트엔드 개발자들은 V8 엔진의 JIT 컴파일러를 신뢰합니다. 평범한 폼 검증, 라우팅, 상태 관리 같은 일반 워크로드라면 굳이 더 빠른 무언가를 찾을 이유가 없습니다. 그러나 어느 화면에든 한두 군데의 핫패스(hot path) 가 도사리고 있습니다. 100MB CSV를 브라우저에서 직접 파싱해야 하는 BI 대시보드, 사용자가 업로드한 RAW 이미지를 곧장 4K로 리사이즈해야 하는 사진 편집기, WebGL 셰 https://waylog.pages.dev/posts/56 https://waylog.pages.dev/posts/56 Mon, 23 Dec 2024 00:00:00 GMT Performance 웹 성능은 사용자 경험과 비즈니스 성과를 좌우하는 핵심 요소입니다. 구글의 연구에 따르면 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가하고, 5초가 되면 90%까지 치솟습니다. 이 글에서는 프론트엔드 개발자가 반드시 알아야 할 웹 성능 최적화 기법들을 체계적으로 정리해 봅니다. 1. Core Web Vitals 2026 (INP 업데이트) 구글이 정의한 Core Web Vitals는 웹 페이지의 사용자 경험을 측정하는 세 가지 핵심 지표입니다. - LCP (Largest Con https://waylog.pages.dev/posts/http-compression-gzip-brotli-zstd-deep-dive https://waylog.pages.dev/posts/http-compression-gzip-brotli-zstd-deep-dive Wed, 09 Oct 2024 00:00:00 GMT Performance 들어가며 — gzip을 "당연히 켜는 것"으로 다뤄온 우리의 착각 Nginx 설정 파일을 열고 gzip on; 한 줄을 추가한 뒤 "자, 압축 완료"라고 PR을 닫은 경험이 있다. 어느 날 저녁 CDN 로그를 보다가 JPEG 이미지 응답에 Content-Encoding: gzip이 찍혀 있는 걸 발견했을 때는 등이 오싹해졌다. gzip이 적용된 JPEG가 원본보다 23% 더 컸다. 잘못된 설정이 몇 주째 운영되고 있었던 것이다. 문제는 그뿐이 아니었다. 해당 서비스는 응답 본문에 CSRF 토큰을 https://waylog.pages.dev/posts/edge-caching-cache-control-stale-revalidate https://waylog.pages.dev/posts/edge-caching-cache-control-stale-revalidate Mon, 23 Sep 2024 00:00:00 GMT Performance 캐시는 서버 앞에 놓는 성능 예산이다 웹 서비스가 느려질 때 가장 먼저 떠올리는 해결책은 서버 증설입니다. 하지만 모든 요청을 오리진까지 보내는 구조라면 서버를 늘려도 같은 종류의 비용이 반복됩니다. 정적 자산, 공개 API, 변경 빈도가 낮은 문서, 상품 목록 일부는 매번 데이터베이스와 애플리케이션 서버를 거치지 않아도 됩니다. HTTP 캐시는 이런 요청을 사용자 가까운 곳에서 끝내는 장치입니다. 문제는 캐시를 단순히 "오래 저장하면 빠르다"로 이해할 때 생깁니다. 잘못된 Cache-Contro