Performance

trace 하나는 여러 서비스의 span으로 구성됩니다. 초당 1,000건의 요청을 처리하는 서비스라면 초당 1만 3만 개의 span이 발생합니다. Span 하나를 평균 2KB의 직렬화된 데이터로 잡으면 하루에 수 TB가 쌓입니다. Collector 파드는 span을 수신하고, 배치로 묶고, 압축하고, 백엔드로 전송합니다.

구분 Lighthouse(Lab) CrUX(Field) ------ --------------- ------------ 측정 환경 에뮬레이션 실제 Chrome 사용자 세션 집계 기간 단일 측정 28일 롤링 평균 백분위수 없음 p75 기준 접근 방법 Lighthouse CLI CrUX API, BigQuery 즉각 반영 즉시 최대 28일 지연 두 데이터를 함

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

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

WebAssembly가 2017년 표준화된 이후 9년이 흘렀습니다. 초창기에는 "C++로 짠 게임을 브라우저에서 돌린다" 정도의 마케팅 메시지에 머물렀지만, 2026년 현재의 풍경은 완전히 다릅니다. Figma의 렌더 엔진, 1Password의 암호화 코어, Google Earth의 지오메트리 처리, Photoshop Web의 필터 파이프라인이 모두 WAS

구글이 정의한 Core Web Vitals는 웹 페이지의 사용자 경험을 측정하는 세 가지 핵심 지표입니다. - LCP (Largest Contentful Paint) : 페이지의 주요 콘텐츠가 로드되는 시간입니다. 2.5초 이하가 목표입니다. - CLS (Cumulative Layout Shift) : 시각적 안정성을 의미합니다.

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

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