Performance

100% 수집이라는 환상이 운영 비용을 잡아먹는다 분산 아키텍처로 전환하고 나면 팀은 자연스럽게 모든 요청을 추적하고 싶어합니다. 우리 팀 역시 초기에 OpenTelemetry SDK를 붙이고 모든 trace를 Jaeger로 내보내는 설정을 처음 기본값으로 택했습니다. 당시에는 이 결정이 합리적으로 보였습니다.

필드 데이터 없이 성능 개선을 논하는 것은 환자 없이 처방을 쓰는 것과 같다 Lighthouse 점수 100점을 받아도 CrUX(Chrome User Experience Report) 대시보드에 "Poor" 판정이 뜨는 경험을 해봤을 것입니다. 내부 팀에서는 대형 이커머스 프로젝트에서 정확히 이 상황을 겪었습니다. 로컬 Lighthouse에서는 LCP 1.

캐시는 서버 앞에 놓는 성능 예산이다 웹 서비스가 느려질 때 가장 먼저 떠올리는 해결책은 서버 증설입니다. 하지만 모든 요청을 오리진까지 보내는 구조라면 서버를 늘려도 같은 종류의 비용이 반복됩니다. 정적 자산, 공개 API, 변경 빈도가 낮은 문서, 상품 목록 일부는 매번 데이터베이스와 애플리케이션 서버를 거치지 않아도 됩니다.

클릭했는데 화면이 늦게 반응하는 이유 웹 성능을 이야기할 때 오랫동안 LCP와 CLS가 중심이었습니다. 첫 화면이 빨리 뜨고 레이아웃이 흔들리지 않는 것은 여전히 중요합니다. 하지만 사용자가 실제로 서비스를 "빠르다"고 느끼는 순간은 버튼을 눌렀을 때 화면이 즉시 반응하는가에 달려 있습니다.

캐시는 빨랐지만 장애는 더 빨리 왔다 캐시는 백엔드 성능 최적화에서 가장 먼저 떠올리는 도구입니다. Redis를 앞에 두면 데이터베이스 조회를 줄이고, p95 응답 시간을 낮추고, 트래픽 피크를 흡수할 수 있습니다. 그런데 캐시는 제대로 설계하지 않으면 장애를 막는 장치가 아니라 장애를 증폭시키는 장치가 됩니다.

들어가며 — gzip을 "당연히 켜는 것"으로 다뤄온 우리의 착각 Nginx 설정 파일을 열고 gzip on; 한 줄을 추가한 뒤 "자, 압축 완료"라고 PR을 닫은 경험이 있다. 어느 날 저녁 CDN 로그를 보다가 JPEG 이미지 응답에 Content-Encoding: gzip 이 찍혀 있는 걸 발견했을 때는 등이 오싹해졌다.

JavaScript의 한계가 드러나는 순간: 핫패스를 Rust로 옮긴 1년의 기록 우리 프론트엔드 개발자들은 V8 엔진의 JIT 컴파일러를 신뢰합니다. 평범한 폼 검증, 라우팅, 상태 관리 같은 일반 워크로드라면 굳이 더 빠른 무언가를 찾을 이유가 없습니다. 그러나 어느 화면에든 한두 군데의 핫패스(hot path) 가 도사리고 있습니다.