#performance
노트 100개
Frontend › CSS
CSS 애니메이션: transition과 @keyframes상태 변화를 부드럽게 잇는 transition과, 여러 단계를 스스로 재생하는 @keyframes 애니메이션의 차이와 속성. 부드러운 애니메이션을 위한 transform·opacity 원칙, 움직임 줄이기 설정 존중, Animate.css·Hover.css·Animista 같은 CSS 애니메이션 라이브러리와 JS 라이브러리로 넘어갈 시점을 정리한다.
Frontend › Graphics
Canvas 2D API<canvas>에 JavaScript로 픽셀을 그리는 즉시 모드 그래픽 API. SVG와의 차이(비트맵 vs DOM), getContext의 종류, 상태 스택과 Path2D, 고해상도 화면에서 흐려지지 않게 devicePixelRatio로 키우는 법, 레이어 분리·오프스크린 미리 그리기·정수 좌표·alpha: false 같은 성능 요령, OffscreenCanvas로 워커에서 그리기, 접근성 한계를 정리한다.
Frontend › JavaScript
가비지 컬렉션과 메모리 누수JavaScript 엔진은 루트에서 참조를 따라 닿을 수 있는(reachable) 값만 남기고 나머지를 자동으로 회수한다. 루트와 도달 가능성, 서로 참조해도 닿을 수 없으면 지워지는 '섬', 기본 알고리즘 mark-and-sweep과 순환 참조에 약했던 참조 카운팅, 세대별·점진적·병렬·유휴 시간 수집 같은 최적화(V8의 스캐빈지·mark-compact·쓰기 장벽), 그리고 GC가 막지 못하는 누수 패턴(전역, 잊힌 타이머·리스너, 클로저, 떨어져 나간 DOM, 끝없는 캐시)과 WeakMap·WeakRef·FinalizationRegistry를 정리한다.
Frontend › JavaScript
번들러의 역사와 Vite모듈 없이 태어난 JavaScript가 CommonJS·AMD·ES 모듈을 거쳐 번들러를 필요로 하게 된 이유, 번들러의 느린 빌드를 네이티브 언어 도구와 '개발은 쪼개서, 배포는 합쳐서' 방식이 풀고, Vite가 그 개념을 모아 Rust 번들러 Rolldown 기반의 표준 빌드 도구가 되기까지를 정리했다.
Frontend › JavaScript
정규식 엔진: 탐욕·게으름·전후방탐색·백트래킹JavaScript 정규식 엔진은 백트래킹 방식이다. 탐욕 수량자는 최대한 먹고 한 글자씩 돌려주며, 게으른 수량자는 최소한으로 먹고 하나씩 늘린다. 둘보다 제외 세트가 정확할 때가 많다. 전후방탐색은 결과에 넣지 않고 조건만 건다. 겹치는 중첩 수량자는 실패할 때 경우의 수가 지수적으로 늘어 페이지를 멈추게 하며(재앙적 백트래킹·ReDoS), 경우의 수를 줄이거나 전방탐색으로 원자 그룹을 흉내 내 막는다.
Frontend › JavaScript
책임감 있는 자바스크립트JS는 압축해도 파싱·실행 비용이 그대로 남아 저사양 기기에서 가장 비싼 자원이다. 웹 플랫폼(HTML·CSS)을 먼저 쓰고, 트리 셰이킹·코드 분할·최신 문법 빌드·작은 대체재로 줄이고, 서드파티 스크립트는 담당자를 두고 관리한다. 성능은 저사양 Android와 느린 4G, 표준 지원은 Baseline으로 기준을 잡는다.
Frontend › JavaScript
페이지 생명주기와 리소스 로딩 이벤트문서가 열리고 닫히는 동안 일어나는 이벤트. DOMContentLoaded가 기다리는 것과 기다리지 않는 것, load와 readyState, 떠날 때의 beforeunload·pagehide·visibilitychange와 숨은 탭의 rAF 정지·타이머 제한, 피해야 할 unload, sendBeacon·keepalive로 마지막 데이터 보내기, 스크립트·이미지의 load·error 이벤트와 crossorigin 속성으로 다른 출처 스크립트의 오류 정보 얻기를 정리한다.
Frontend › JavaScript
Debounce와 Throttle연속으로 일어나는 이벤트의 실행 횟수를 줄이는 두 기법. 디바운스는 마지막 호출만, 쓰로틀은 일정 간격마다 한 번만 실행한다.
Frontend › JavaScript
JavaScript 애니메이션: requestAnimationFrame과 Web Animations APICSS로 부족한 애니메이션을 JavaScript로 만드는 두 방법. requestAnimationFrame 위에 duration·timing·draw로 나눈 범용 animate 함수를 짜고, 타이밍 함수(power·back·bounce·elastic)와 easeOut·easeInOut 변환을 직접 만든다. 브라우저 엔진을 그대로 쓰는 element.animate()는 재생 제어, finished 프로미스, commitStyles, 스크롤 타임라인을 준다.
Frontend › JavaScript
SharedArrayBuffer와 Atomics: JavaScript의 공유 메모리 병렬 처리워커끼리 메시지 복사 없이 같은 메모리를 읽고 쓰게 하는 SharedArrayBuffer와, 그 메모리를 경쟁 상태 없이 다루는 Atomics(load·store·add·compareExchange·wait·notify)를 정리한다. 메시지 전달·소유권 이전·공유 메모리의 차이, Spectre 이후 교차 출처 격리(COOP·COEP)가 필수가 된 이유, 메인 스레드에서 wait 대신 waitAsync를 쓰는 규칙, 언제 병렬화가 값을 하는지까지.
Frontend › Mobile
UICollectionView 커스텀 레이아웃채팅방처럼 셀 밖 요소(날짜 구분선, 읽음 표시)가 많은 iOS 목록을 UICollectionView와 커스텀 레이아웃으로 만드는 방법. 레이아웃 객체가 위치를 계산하는 구조, prepare()에서 속성을 미리 계산·캐시하는 법, 화면 영역 질의를 이진 탐색으로 빠르게 답하는 법, 보조 뷰와 증분 오토 레이아웃을 정리했다.
Frontend › Next.js
React Server Components의 동작 원리서버가 컴포넌트 트리를 렌더링해 HTML이 아니라 직렬화된 React 트리(RSC Payload)를 스트리밍하고, 브라우저가 클라이언트 컴포넌트 참조를 실제 코드로 바꿔 트리를 재구성하는 과정을 정리한다. SSR과의 차이, 요청 왕복을 줄이려고 나온 배경과 서버 컴포넌트 모델(XHP)에서 출발한 역사, 다시 렌더링되지 않는다는 성질과 클라이언트 경계, 갱신 방식, 제약까지.
Frontend › React
동시성 렌더링: useTransition과 useDeferredValueReact는 업데이트를 급한 것(입력)과 급하지 않은 것(전환)으로 나눠, 급하지 않은 렌더링은 중간에 끊고 급한 것을 먼저 처리한다. useTransition·startTransition은 상태 업데이트를 전환으로 표시하고(React 19부터 async 함수도 받아 Actions의 바탕이 된다), useDeferredValue는 값의 반영을 늦춘다. Suspense와 use는 기다리는 동안의 화면을 맡는다.
Frontend › React
리렌더링 원인과 추적리렌더링을 일으키는 원인, React.memo가 효과 없는 경우, useQuery가 최소 두 번 렌더링하는 이유, DevTools로 추적하고 줄이는 순서.
Frontend › React
리스트 가상화(Windowing)항목이 수천 개인 목록에서 화면에 보이는 항목만 DOM에 그리고 나머지는 높이만 차지하게 하는 기법. 원리(전체 높이 + 보이는 구간 계산 + 절대 위치), TanStack Virtual·react-window 사용법, 가변 높이·접근성·찾기 기능 같은 한계와 content-visibility 대안을 정리한다.
Frontend › React
리스트와 Key배열을 map으로 엘리먼트 목록으로 바꿔 렌더링하는 방법과, 각 항목을 식별하는 key의 역할. key 값(없음·랜덤·인덱스·id)에 따라 리렌더링과 리마운트가 어떻게 달라지는지, 인덱스 key가 오히려 빠른 경우까지 다룬다.
Frontend › React
리액트 상태 관리의 흐름과 고르는 기준상태를 종류(로컬·서버·URL·폼·전역 클라이언트)로 먼저 나누고, 전역 상태 라이브러리는 읽기·쓰기·리렌더링 최적화·메모리 네 가지 문제를 어떻게 푸는지로 비교한다. Flux·Redux에서 Context, 서버 상태 라이브러리, atom·proxy 기반 라이브러리로 이어진 흐름까지.
Frontend › React
재조정(Reconciliation)과 state 보존React가 리렌더링 때 이전 엘리먼트 트리와 새 트리를 비교해 DOM 변경을 최소로 계산하는 과정. render 단계와 commit 단계, 타입이 다르면 하위 트리를 통째로 리마운트하고 같으면 속성만 고치는 비교 규칙, state가 트리의 '위치'에 묶여 보존·초기화되는 원리와 key로 초기화하는 법을 정리한다.
Frontend › UI Design
UI 모션 디자인: 애니메이션 원칙, 모션 커브, 안무UI 애니메이션을 자연스럽게 만드는 원리. 디즈니의 애니메이션 12원칙을 웹에 옮기는 법, 속도는 모션 커브의 기울기라는 이해와 cubic-bezier 읽기, 축마다 다른 타이밍으로 곡선 경로를 만드는 겹친 애니메이션과 offset-path, 여러 요소를 시차로 움직이는 안무, 60fps를 지키는 구현 규칙을 정리한다.
Frontend › UI Design
UI 밀도: 시각·정보·디자인·시간·가치UI 밀도는 화면에 많이 담는 것이 아니라, 인터페이스가 차지하는 시간과 공간 대비 사용자가 얻는 가치다. 첫인상의 시각 밀도는 믿을 수 없고, 터프티의 데이터-잉크 비율(정보 밀도)과 게슈탈트 원리로 센 디자인 결정의 비율(디자인 밀도)이 더 쓸모 있다. 시간 밀도는 로딩과 대기의 체감(100ms·1초·10초·1분 구간)으로 다루고, 결국 가치 밀도를 최대화하는 것이 목표다.
Frontend › Web
동영상 성능: 형식·poster·자동 재생·임베드동영상은 컨테이너와 코덱을 고르고 FFmpeg로 줄여 여러 source로 준다. 움직이는 GIF는 muted·loop·playsinline 자동 재생 video로 바꾼다. 사용자가 누를 동영상은 preload='none'과 poster, 화면 밖은 지연 로딩, 무거운 서드파티 플레이어는 퍼사드로 늦춘다. poster와 첫 프레임은 LCP 후보다.
Frontend › Web
리소스 힌트와 미리 불러오기: preconnect·preload·fetchpriority·Speculation Rules브라우저가 스스로 늦게 발견하는 자원을 앞당기는 힌트. 다른 출처 연결은 preconnect·dns-prefetch, 늦게 발견되는 중요한 자원은 preload, 우선순위는 fetchpriority로 조정한다. 다음 이동을 위해서는 prefetch, Speculation Rules의 prefetch·prerender, 서비스 워커 프리캐싱을 쓰되 확신이 있을 때만 쓴다.
Frontend › Web
문서 head와 메타데이터<head>는 화면에 보이지 않지만 인코딩·제목·뷰포트·스타일·스크립트·아이콘·대체 버전·대표 URL·검색과 SNS 미리보기 정보를 모두 담는다. 모든 페이지에 넣을 다섯 줄, 성능을 위한 요소 순서, link의 rel 종류, meta의 세 갈래(charset·http-equiv·name)와 이제 쓰지 않는 태그, Open Graph와 SEO의 관계, 미리보기가 안 나오는 이유, base의 함정, 웹 앱 매니페스트로 정리한다.
Frontend › Web
반응형 이미지: srcset·sizes와 picture같은 이미지를 크기만 바꿔 줄 때는 srcset·sizes로 브라우저에 선택을 맡기고(서술형), 자르기·형식 대체처럼 규칙을 강제할 때는 picture를 쓴다(지시형). 크기만 맞춰도 작은 화면의 이미지 용량이 70% 넘게 준다. sizes는 레이아웃에서의 폭이라 도구가 알 수 없으니 근삿값을 주거나, 지연 로딩 이미지는 sizes="auto"에 맡긴다.
Frontend › Web
브라우저 렌더링 과정브라우저의 구성 요소와, HTML을 DOM으로·CSS를 CSSOM으로 파싱해 렌더 트리로 레이아웃(리플로우)·페인팅·합성을 거쳐 화면을 그리는 과정. HTML 파서의 특성, 스크립트·스타일 시트의 차단, 더티 비트와 강제 동기 레이아웃, 변경마다 다시 도는 단계까지.
Frontend › Web
브라우저 아키텍처: 다중 프로세스, 내비게이션, 렌더러 스레드, 입력 처리Chrome을 예로 브라우저가 프로세스를 어떻게 나누는지(브라우저·렌더러·GPU·네트워크 등, 사이트 격리), 주소를 입력한 뒤 어느 프로세스가 무엇을 하며 페이지를 커밋하는지, 렌더러 안의 메인·컴포지터·래스터 스레드가 프레임을 만드는 방식, 입력 이벤트가 컴포지터를 거쳐 메인 스레드로 가는 길과 passive 리스너·이벤트 병합까지.
Frontend › Web
서비스 워커 캐싱과 응답 전략Cache Storage API로 요청·응답 쌍을 저장하고, fetch 이벤트의 respondWith()로 캐시 우선·네트워크 우선·stale-while-revalidate·네트워크 전용·캐시 전용 중 하나를 URL별로 골라 응답한다. 무엇을 언제 프리캐시할지, 불투명 응답과 addAll의 원자성 함정, 오프라인 대체 페이지, Workbox로 줄이는 코드, 페이지를 조각별로 캐시하는 서비스 워커 인클루드와 스트리밍까지 정리한다.
Frontend › Web
성능 측정 API: Navigation·Resource·User Timing과 PerformanceObserver브라우저가 실제 사용자 환경에서 기록하는 성능 항목(performance entry)을 읽는 API들. 문서 요청은 Navigation Timing, 하위 자원은 Resource Timing, 앱이 직접 찍는 구간은 User Timing의 mark·measure로 재고, 모두 PerformanceObserver에 buffered로 구독해 모은다. 교차 출처 자원은 Timing-Allow-Origin 헤더가 있어야 세부 시간이 보인다.
Frontend › Web
스크립트·스타일 로딩 순서와 점진적 렌더링<script>, async, defer, type=module이 HTML 파싱과 실행 순서에 주는 차이, 프리로드 스캐너가 못 보는 늦게 발견되는 자원, CSS는 <head>에 두고 스크립트는 defer로 미루는 이유와 예외, @import를 피하고 중요 CSS만 인라인하는 CSS 경량화, 콘텐츠를 받는 대로 먼저 보여 주는 점진적 렌더링 기법을 정리했다.
Frontend › Web
스트리밍 SSRHTML을 한 번에 다 만들어 보내지 않고 Suspense 경계 단위로 나눠 흘려보내는 SSR. React 18에서 도입됐고, 지금은 React 19의 부분 사전 렌더링과 Next.js Cache Components의 기반이 되어 기본 동작으로 자리 잡았다.
Frontend › Web
웹 성능 지표와 LighthouseFCP·LCP·INP·CLS·TTFB 같은 웹 성능 지표의 뜻과 기준값, Core Web Vitals 세 지표가 무엇을 어떻게 재는지(LCP 후보 요소, INP의 세 구간, CLS의 세션 창), 실험실·필드 데이터와 web-vitals 라이브러리로 재는 법, Lighthouse를 정리했다. 지표별 개선법은 따로 나눈 최적화 노트로 연결한다.
Frontend › Web
웹 워커로 메인 스레드 비우기웹 워커는 JS를 메인 스레드가 아닌 별도 스레드에서 돌린다. DOM과 window에는 접근할 수 없고 postMessage로만 메인 스레드와 대화한다. 가져오기·파싱·대용량 계산처럼 DOM이 필요 없는 무거운 일을 옮기면 긴 작업이 줄어 INP가 좋아지고, 그 일에 쓰는 라이브러리의 다운로드·컴파일 비용도 함께 빠진다.
Frontend › Web
웹 이미지 형식: 벡터·래스터와 GIF·PNG·JPEG·WebP·AVIF·JPEG XL도형으로 된 그림은 SVG, 사진처럼 실제 세계의 디테일이 있는 그림은 래스터다. 래스터는 손실 압축이 가능한 형식을 고르되, 사진은 AVIF·WebP를 먼저 주고 JPEG로 받친다. PNG는 반투명이 필요한 단순 그림과 원본 보관용, GIF는 거의 쓸 곳이 없다. JPEG XL은 크롬·파이어폭스·사파리가 지원하지만 엣지가 빠져 있어 picture로 대체를 둔다.
Frontend › Web
웹 폰트 성능 최적화: 발견·내려받기·렌더링웹 폰트는 레이아웃이 필요로 할 때에야 요청되는 늦게 발견되는 자원이다. preload나 인라인 @font-face로 일찍 발견되게 하고, 자체 호스팅·WOFF2·서브셋으로 빨리 받고, font-display로 글자가 숨거나 밀리는 방식을 고른다.
Frontend › Web
이미지 압축과 인코딩 자동화JPEG는 밝기보다 색을 더 버리고(크로마 서브샘플링) 고주파 디테일을 양자화해 줄인다. WebP는 블록 예측과 영역별 양자화로 같은 품질에서 더 작다. 품질 값은 0~100 하나로 조절하되 도구마다 뜻이 달라 눈으로 확인한다. 실제 서비스에서는 사람이 아니라 빌드 도구·정적 사이트 생성기·CMS가 원본에서 여러 형식과 크기를 만든다.
Frontend › Web
이미지 CDN과 Accept 헤더 협상이미지 CDN은 원본 한 장을 올려 두면 URL 매개변수로 크기·자르기·품질·형식을 바꾼 변형을 만들어 캐시한다. 브라우저의 Accept 헤더를 보고 AVIF·WebP 중 지원하는 가장 효율적인 형식을 주므로 picture·type 없이 srcset·sizes만으로 형식 대체가 된다. 같은 URL이 형식마다 다른 응답이 되므로 Vary: Accept로 캐시를 나눠야 하고, 비용이 주된 단점이다.
Frontend › Web
이미지·오디오·비디오 임베드내용인 이미지는 HTML, 장식은 CSS다. <img>의 필수 src·alt, 레이아웃 이동을 막는 width·height, loading·fetchpriority, figure·figcaption, SVG의 role="img"를 정리하고, <video>·<audio>의 source·type·codecs, poster, controls, autoplay와 muted, track의 다섯 kind, 배경 영상과 사용자 정의 컨트롤의 원칙을 다룬다.
Frontend › Web
자바스크립트 코드 분할시작할 때 받는 JS가 크면 파싱·컴파일·실행 동안 메인 스레드가 막혀 TBT와 INP가 나빠진다. 커버리지로 시작 때 안 쓰는 코드를 찾고, 동적 import()로 나중에 필요한 코드를 별도 청크로 떼어 상호작용할 때 불러온다. 청크 크기는 캐시·압축·평가 시간의 균형으로 정한다. 로딩 전략 전체는 PRPL(Preload·Render·Pre-cache·Lazy load)로 묶는다.
Frontend › Web
정적 사이트 생성기와 Jamstack정적 사이트 생성기(SSG)는 마크다운 콘텐츠와 템플릿을 빌드 때 HTML로 합쳐 CDN에 올린다. 서버·DB가 없어 빠르고 안전하며, Git push가 곧 배포다. 콘텐츠 사이트는 JS를 거의 보내지 않는 Eleventy·Hugo·Astro가 맞고, 상호작용이 많으면 Next.js 같은 프레임워크를 쓴다. WordPress에서 옮기는 흐름도 정리한다.
Frontend › Web
지속 가능한 웹 디자인웹사이트의 에너지 사용은 전송 데이터·CPU·서버 자원으로 어림할 수 있고, 이를 줄이는 일은 곧 성능·접근성·SEO 개선이다. 필요 없는 요청과 기능을 빼고, 이미지·폰트·영상·분석 도구를 의심하고, 서버 캐시와 재생 에너지 호스팅을 쓴다.
Frontend › Web
지연 로딩: 이미지·iframe·퍼사드화면 밖 이미지·iframe은 loading='lazy'로 미뤄 첫 화면 자원에 대역폭을 몰아 준다. 첫 화면 이미지와 LCP 후보에는 절대 쓰지 않는다. 무거운 서드파티 임베드는 가짜 UI(퍼사드)를 보여 주다 상호작용할 때 바꾸고, 네이티브로 미룰 수 없는 video·배경 이미지는 IntersectionObserver 기반 라이브러리로 미룬다.
Frontend › Web
프론트엔드 개발자가 알아야 할 지연 시간 숫자네트워크 왕복, 파싱, 프레임 예산, 사람의 체감 한계를 밀리초 단위로 정리한 표. 지연은 워터폴로 곱해지므로 요청 체인을 서버로 옮기고, JS를 줄이고, 사용자 가까이 배포한다.
Frontend › Web
프론트엔드 성능 최적화: 언제, 무엇을최적화는 측정한 뒤에, 최악의 사용자(p95·p99)를 기준으로, 무엇을 희생하는지 알고 한다. 느림은 초기 로딩(대역폭·지연 시간·JS 실행)과 런타임(실제 성능과 체감 성능)으로 나눠 본다. 캐싱·프리패치·코드 분할, 긴 작업 줄이기와 쪼개기, 파생 상태와 리렌더링 범위 좁히기를 각 원인에 맞춰 고른다.
Frontend › Web
프론트엔드 출시 전 체크리스트웹 페이지를 배포하기 전에 확인할 항목을 head·HTML·CSS·이미지·폰트·JavaScript·보안·성능·접근성·SEO 열 가지로 나눠, 우선순위와 자세한 설명이 있는 노트로 잇는 점검표. 항목은 사람이 외우지 않고 린터·Lighthouse·CI로 자동화하는 것이 기본이다.
Frontend › Web
AMP: 규칙으로 빠르게 만드는 모바일 페이지AMP(Accelerated Mobile Pages)는 HTML에 제약을 걸고(외부 JS 금지, 인라인 CSS 상한, 자원 크기 명시) 전용 런타임과 캐시 CDN으로 페이지를 빠르게 만드는 프레임워크다. 성능 원리는 일반 페이지에도 그대로 쓰이지만, URL 이원화와 플랫폼 종속 때문에 비판을 받았고 검색 우대가 사라진 뒤로는 Core Web Vitals를 직접 맞추는 쪽이 일반적이다.
Frontend › Web
CLS 최적화: 자리를 먼저 잡기레이아웃 이동은 늦게 도착한 것이 자리를 비집고 들어올 때 생긴다. 이미지·동영상에는 width·height나 aspect-ratio, 광고·임베드에는 min-height, 늦게 뜨는 배너는 자리 확보나 오버레이, 애니메이션은 transform, 웹 폰트는 font-display와 대체 폰트 지표 보정으로 막는다. 필드와 실험실 값의 차이로 로딩 중 이동인지 이후 이동인지 가른다.
Frontend › Web
INP 최적화: 긴 작업 쪼개기와 양보INP는 입력 지연, 처리 시간, 표시 지연의 합이다. 필드 데이터로 느린 상호작용을 찾고, 시작할 때의 스크립트 평가를 줄여 입력 지연을, 핸들러를 가볍게 하고 메인 스레드에 양보해 처리 시간을, DOM 크기·content-visibility·클라이언트 HTML 렌더링을 손봐 표시 지연을 줄인다.
Frontend › Web
Intersection Observer와 관찰자 API스크롤 이벤트로 위치를 계산하는 대신, 요소가 화면(또는 스크롤 영역)에 얼마나 보이는지 브라우저가 알려 주는 IntersectionObserver. root·rootMargin·threshold 옵션, 무한 스크롤·지연 로딩·끝까지 읽음 감지 패턴, 크기 변화를 보는 ResizeObserver와 DOM 변화를 보는 MutationObserver를 정리한다.
Frontend › Web
LCP 최적화: 네 구간으로 나눠 줄이기LCP는 TTFB, 자원 로드 지연, 자원 로드 시간, 요소 렌더 지연의 합이다. 두 「지연」 구간은 0에 가깝게, 나머지 둘은 40%씩이 목표다. LCP 자원을 HTML에서 바로 발견되게 하고, fetchpriority로 앞당기고, 지연 로딩하지 않고, 작게 만들고, 막는 CSS·JS와 긴 작업을 걷어 낸다.
Frontend › Web
PWA와 서비스 워커 캐시 전략PWA는 HTTPS·웹 앱 매니페스트·서비스 워커 세 가지를 갖춘 웹사이트일 뿐이고, 사이트 종류와 상관없이 득이 된다. 서비스 워커로 캐시를 직접 다룰 수 있게 된 만큼, 필요한 것만 작게 요청하고 미디어를 중요도별로 나눠 캐시하고, 캐시 크기를 제한해 사용자의 데이터와 디스크를 아낀다.
Frontend › Web
TTFB 줄이기: 리디렉션·HTML 캐시·압축·CDN페이지의 첫 요청인 HTML이 빨리 와야 FCP·LCP가 기준을 넘는다. 리디렉션 체인을 없애고, HTML은 짧게 캐시하거나 ETag로 재검증하고, Server-Timing으로 서버 시간을 재고, 텍스트 자원은 Brotli로 정적 압축하고, CDN 엣지에서 내려 준다.
Frontend › Web
WebAssembly: 브라우저의 두 번째 언어C·C++·Rust 같은 언어를 컴파일해 브라우저에서 거의 네이티브 속도로 돌리는 바이트코드 형식 WebAssembly(Wasm)를 정리한다. JavaScript와 비교해 어디서 시간이 줄어드는지(받기·파싱·컴파일·재최적화·실행·GC), Module·Memory·Table·Instance라는 네 개념과 JS API, 툴체인, MVP 이후 Wasm 2.0·3.0에 들어간 기능, 브라우저 밖 실행(WASI)과 쓸 곳·안 쓸 곳까지.
Frontend
UI 엔지니어링의 열두 가지 문제UI 엔지니어링의 실력은 라이브러리가 아니라 문제를 아는 데서 나온다. 일관성·반응성·지연·내비게이션·낡은 캐시·엔트로피·우선순위·접근성·국제화·전달·복원력·추상화라는 열두 문제는 툴팁부터 대형 SNS까지 어느 규모에서나 나타나며, 각 문제에 오늘날 쓰는 도구와 함께 정리한다.
Backend › Architecture
대규모 웹 크롤러 설계하루 10억 페이지 규모로 웹을 크롤링하는 시스템의 설계 원칙. 예의(robots.txt, 도메인당 지연)를 첫 제약으로 두고, 기능별 머신 풀 대신 도메인 샤드마다 모든 기능을 담은 독립 노드로 나누며, 프런티어·준비 큐·블룸 필터를 인메모리 저장소에 둔다. I/O에 묶인 페처는 비동기로, CPU에 묶인 파서는 프로세스로 늘리고, 요청당 과금되는 객체 스토리지보다 로컬 스토리지를 검토한다. 병목은 네트워크·DNS가 아니라 커진 페이지의 파싱과 TLS 핸드셰이크(CPU)이고, 메모리는 인기 도메인의 프런티어라는 꼬리에서 터진다.
Backend › Architecture
대규모 트래픽에서 서비스를 지키는 설계읽기 위주 서비스가 평소의 몇 배로 치솟는 트래픽을 버티는 방법. CDN과 웹 서버로 WAS 앞단에서 부하를 덜고, 미리 만들어 둔 정적 응답으로 빈 화면을 막고, 서킷 브레이커·서비스 디스커버리로 장애 전파를 끊고, 한계치 모니터링과 자동 방어 모드로 사람 없이도 대응하는 구조를 정리했다.
Backend › Architecture
대기열 시스템(가상 대기실) 설계순간적으로 몰리는 트래픽을 서버 증설 대신 줄 세우기로 흡수하는 가상 대기실의 구조를 정리했다. Redis Sorted Set에 도착 시각을 점수로 넣어 순번을 매기고, 주기 작업이 정해진 유입량만큼 대기→입장→종료 상태로 옮기는 방식이 핵심이다.
Backend › Architecture
라이브 스트리밍의 구조: 인코딩, 세그먼트, ABR, CDN라이브 스트리밍은 캡처한 영상을 압축·인코딩하고, 몇 초 단위 세그먼트로 잘라, 화질별로 여러 벌 만든 뒤(적응형 비트레이트) CDN 엣지로 퍼뜨려 시청자가 가까운 곳에서 받게 한다. 송출은 주로 RTMP·SRT, 시청은 HTTP 기반 HLS·DASH를 쓰고, 1초 미만 지연이 필요하면 WebRTC를 쓴다.
Backend › Architecture
백엔드 지연 시간 줄이기: 숫자 감각과 기법메모리·SSD·네트워크·DB 커밋·LLM 호출이 대략 몇 나노초~초인지 자릿수 감각(Jeff Dean의 원형 표, 해마다 줄지 않는 왕복 지연, 봉투 뒷면 계산)을 먼저 잡고, API 지연을 줄이는 기법(인덱스, 캐시, 페이지네이션, 비동기 로깅·처리, 압축, 커넥션 풀, 로드 밸런싱, CDN)을 무엇을 줄이는지 기준으로 정리한다. 극단적 저지연 시스템의 원칙은 「크리티컬 패스에서 일을 줄인다」 하나다.
Backend › Architecture
비동기 서버의 이벤트 루프: 다중 접속 서버에서 Reactor 패턴까지연결마다 프로세스·스레드를 붙이던 다중 접속 서버가 I/O 멀티플렉싱, Java NIO Selector, Reactor 패턴을 거쳐 이벤트 루프가 되는 과정을 정리한다. 이벤트 루프 스레드 하나가 수많은 연결을 맡기 때문에, 그 스레드를 블로킹 I/O나 긴 계산으로 막으면 같은 루프의 모든 요청이 멈춘다. 블로킹 작업은 별도 스레드 풀로 보낸다.
Backend › Architecture
빠르고 유지보수하기 좋은 DB 조회 패턴서버 코드에서 DB 조회를 빠르게 하면서도 코드는 단순하게 두는 방법. 직렬 조회 → 수동 배치 → 병렬 처리 → 자동 배치 → 값별 독립 함수 → 요청 단위 캐시로 발전시키며, 핵심은 '지역적 추론(local reasoning)'이라는 점을 정리한다. DataLoader의 원리이기도 하다.
Backend › Architecture
시스템 설계의 선택지와 흔한 문제의 해법수직·수평 확장, SQL·NoSQL, 배치·스트림, 정규화·비정규화, 강한·최종 일관성, REST·GraphQL, 상태 유지·무상태, 동기·비동기처럼 설계에서 반복되는 양자택일을 비교하고, 읽기 폭주·쓰기 폭주·단일 장애 지점·지연·대용량 파일·느린 쿼리 같은 흔한 문제를 해법과 짝지었다.
Backend › Architecture
실시간 웹소켓 서버 설계수만 개의 연결을 붙잡고 메시지를 밀어 주는 웹소켓 서버를 설계·검증하는 방법이다. 연결 하나에 여러 메시지 타입을 싣는 법, 방(그룹) 단위 분할과 Pub/Sub로 서버 간 전파하기, 액터 모델로 상태 관리하기, 팬아웃 폭증을 묶음 전송으로 막기, 파일 디스크립터·포트·로드밸런서 한계, 연결 수명 주기를 검증하는 부하 테스트까지 정리했다.
Backend › Architecture
이미지·동영상 처리 서버 설계업로드된 이미지·동영상을 여러 크기와 화질로 바꿔 내보내는 서버를 설계하는 방법이다. 미리 만들어 두기와 요청 시 변환(온디맨드 리사이징)의 비교, 캐시·CDN·HTTP 검증자로 변환 비용을 줄이는 법, 엣지 함수 구성, 트랜스코딩 파이프라인을 단계로 나누고 비동기 완료 알림을 보내는 법, 점진적 다운로드와 적응형 스트리밍을 정리했다.
Backend › Architecture
장애 확산을 막는 복원력 패턴작은 오류가 연쇄 장애로 번지지 않게 하는 여덟 가지 패턴(타임아웃, 재시도, 서킷 브레이커, 속도 제한, 부하 차단, 벌크헤드, 배압, 크래시 허용), 속도 제한 알고리즘의 개요, 벌크헤드 격리 방식과 배압 전략, 재시도를 안전하게 만드는 백오프·지터 전략, 4xx·5xx별 재시도 규칙, 재시도의 전제 조건인 멱등성을 적용해야 하는 곳을 정리했다.
Backend › Architecture
캐시 전략: 계층, 읽기·쓰기 패턴, 교체 정책, 장애 패턴캐시는 요청 경로의 거의 모든 층에 있다. 캐시와 원본을 맞추는 읽기·쓰기 패턴(cache-aside, read-through, write-through, write-around, write-back), 꽉 찼을 때 무엇을 버릴지 정하는 교체 정책(LRU·LFU·FIFO·SLRU·TTL 등), 그리고 캐시가 오히려 DB를 무너뜨리는 네 가지 장애(동시 만료, 관통, 핫 키 만료, 캐시 다운)와 대응을 정리한다.
Backend › Architecture
캐시 클러스터 운영과 장애 대응트래픽 대부분을 캐시가 받는 서빙 계층에서는 캐시의 가용성이 곧 서비스의 가용성이다. 일부 노드 장애를 연결 단위로 빨리 감지하고, 동기화 중인 복제본은 트래픽에서 빼고, 응답 속도 기반 라우팅이 만드는 쏠림을 무작위 선택으로 풀고, 핫 키는 짧은 TTL의 로컬 캐시로 흡수하는 방법을 정리했다.
Backend › Database
데이터베이스 샤딩한 DB에 담기 어려울 만큼 커진 데이터를 같은 스키마의 여러 DB로 행 단위로 나누는 샤딩을 정리했다. 샤드 키와 라우팅 방식(모듈러·범위·디렉터리·일관된 해싱·가상 버킷), 샤딩이 어렵게 만드는 것, ShardingSphere 같은 미들웨어, 기존 DB에서 옮겨 올 때의 동기화와 첫 요청 지연까지 다룬다.
Backend › Database
데이터베이스 확장과 성능 최적화DB가 느려지거나 한계에 닿을 때 싼 것부터 쓰는 수단을 순서대로 정리했다. 인덱스·쿼리 튜닝·커넥션 풀·캐시·구체화된 뷰(갱신 방식)·반정규화·수직 확장·읽기 복제본·파티셔닝(프루닝, 분할 방식, 로컬·글로벌 인덱스)·샤딩의 효과와 대가, 복제 구조(단일 리더·다중 리더·리더 없음)와 동기화 방식, 읽기 복제본 패턴의 복제 지연과 라우팅(애플리케이션 vs 미들웨어)을 다룬다.
Backend › Database
분산 환경의 고유 ID 생성여러 서버가 동시에 겹치지 않는 ID를 만드는 다섯 가지 방법(UUID, Snowflake, DB 자동 증가, DB 세그먼트, Redis)을 비교하고, 시간순 정렬·64비트·저지연 같은 요구 사항에 따라 어떤 방식을 고를지, 시간순 UUID(UUIDv7)가 인덱스 문제를 어떻게 푸는지 정리했다.
Backend › Database
와이드 컬럼 DB와 대규모 메시지 저장: Cassandra·ScyllaDBCassandra·ScyllaDB 같은 와이드 컬럼 DB는 파티션 키로 데이터를 노드에 나누고 파티션 안을 클러스터링 키로 정렬해 둔다. 파티션 키·클러스터링 키 모델, 조절 가능한 일관성, LSM 트리 저장 엔진, Cassandra와 ScyllaDB의 차이를 정리하고, 수조 건 메시지를 저장할 때 생기는 핫 파티션을 데이터 서비스 계층의 요청 병합으로 막는 방법과 로컬 SSD와 네트워크 디스크를 RAID로 묶어 디스크 지연을 줄이는 방법을 다룬다.
Backend › Database
인덱스 설계와 쿼리 튜닝인덱스는 정렬이다. 카디널리티·분포도와 후보 컬럼 고르기, 복합 인덱스 컬럼 순서, 유니크·외래 키 인덱스, 인덱스를 못 타게 만드는 조건, EXPLAIN 접근 유형과 Oracle 인덱스 스캔 방식, 조인 방식(중첩 루프·해시·정렬 병합)과 조인 순서, ORDER BY·GROUP BY·커버링 인덱스, 빠른 쿼리를 위한 체크리스트, NoSQL의 인덱스와 MongoDB의 ESR 규칙까지 정리했다.
Backend › Database
DB 내부 구조: 쿼리 실행과 인덱스 자료 구조SQL 한 문장이 파서·옵티마이저·실행기·버퍼 관리자·트랜잭션·잠금 관리자를 거쳐 처리되는 흐름, Oracle을 예로 본 엔진의 메모리(SGA·PGA)·백그라운드 프로세스·파일 구성과 테이블스페이스→세그먼트→익스텐트→블록의 논리 저장 구조, 그리고 DB가 데이터를 찾는 데 쓰는 자료 구조(B-트리, LSM 트리, 해시, 스킵 리스트, 역색인, R-트리 등)를 정리했다. B-트리는 읽기에, LSM 트리는 쓰기에 강하다.
Backend › Database
DB 커넥션 풀커넥션 풀은 DB 연결을 미리 만들어 빌려주고 돌려받는다. 풀 크기와 처리량의 관계, 대기 시간(maxWait·connectionTimeout)을 짧게 잡아야 장애가 번지지 않는 이유, 유효성 검사와 유휴 연결 정리, DataSource 프록시로 SQL에 출처 주석을 다는 법을 정리했다.
Backend › Database
JPA와 영속성 컨텍스트Java의 ORM 표준인 JPA(Jakarta Persistence)가 객체와 테이블의 패러다임 불일치를 어떻게 메우는지, 영속성 컨텍스트의 1차 캐시·쓰기 지연·변경 감지와 엔티티 상태, N+1 문제의 원인과 해결(페치 조인·배치 크기·엔티티 그래프), 엔티티 설계 관례, 대량 데이터를 읽는 no-offset 배치 리더를 정리한다.
Backend › Express
Node.js 스트림: 데이터를 조각으로 흘려 처리하기큰 데이터나 끝이 없는 데이터를 통째로 메모리에 올리지 않고 조각(chunk) 단위로 처리하는 Node.js 스트림을 정리한다. Readable·Writable·Duplex·Transform 네 종류, 흐름 모드와 일시정지 모드, 백프레셔와 highWaterMark, objectMode, pipe의 함정과 pipeline, for await 비동기 반복, 웹 스트림과의 관계, streams1~3의 변천까지.
Backend › Web Basics
API 테스트의 종류API를 검증하는 아홉 가지 테스트(스모크, 기능, 통합, 회귀, 부하, 스트레스, 보안, UI, 퍼즈)가 각각 어떤 질문에 답하는지, 개발에서 배포까지 어느 단계에서 돌리는지, 부하와 스트레스의 차이와 퍼즈 테스트가 찾는 것을 정리했다.
Backend › Web Basics
API 페이지네이션큰 목록을 나눠 내려 주는 API 페이지네이션의 여섯 가지 방식(오프셋, 페이지 번호, 커서, 키셋, 시간 기반, 혼합)을 요청 모양·DB 쿼리·장단점으로 비교한다. 깊은 페이지에서 오프셋이 느려지는 이유, 데이터가 바뀔 때 생기는 중복·누락, 정렬 키에 동점 깨기를 넣는 규칙, 응답에 다음 페이지 정보를 싣는 법까지.
Computer Science › C Programming
C 저수준 최적화컴파일러가 이미 해 주는 최적화와 프로그래머가 힌트로 도울 수 있는 부분을 구분한다. switch를 룩업 테이블·점프 테이블로 바꾸는 원리, 분기 예측 힌트(__builtin_expect, [[likely]]), 도달 불가 힌트, SIMD 내장 함수, memset 같은 라이브러리 함수를 직접 최적화하지 말아야 하는 이유.
Computer Science › Computer Architecture
캐시를 고려한 코드프로그래머가 캐시를 직접 제어할 수 없는 대신 접근 패턴으로 성능을 끌어내는 방법. 캐시 라인과 하드웨어 프리페처, 행렬 곱의 전치·블로킹, 배열과 연결 리스트의 실제 차이, 넌템포럴 저장과 쓰기 결합 버퍼, 캐시 일관성(MESI)과 거짓 공유, TLB shootdown, 캐시 효과를 걸러 내는 마이크로벤치마크 방법을 정리한다.
Computer Science › Computer Architecture
현대 CPU의 마이크로아키텍처교과서의 5단계 파이프라인과 달리 현대 x86·ARM 코어가 명령어를 μop으로 쪼개 비순차·슈퍼스칼라로 실행하는 구조. 프런트엔드(디코더·μop 캐시·LSD), 재정렬 버퍼와 예약 스테이션, 실행 포트와 포트 압력, 분기 예측과 분기 없는 코드, SMT를 정리한다.
Computer Science › Network
IP QoS: 패킷을 차별해서 보내는 법최선형 IP 망에서 트래픽별로 대역폭·지연·지터·손실을 다르게 대우하는 QoS의 처리 단계(분류, 미터링·마킹, 폐기·큐잉, 스케줄링, 셰이핑)와 DSCP 코드, RED·WRED, 큐 스케줄링 방식, 플로우마다 예약하는 IntServ(RSVP)와 클래스로 묶는 DiffServ를 비교했다.
Computer Science › Operating System
동시성·병렬·비동기·논블로킹과 동시성 모델동시성(논리적으로 함께 진행)과 병렬(물리적으로 동시에 실행), 동기·비동기(완료를 누가 확인하나)와 블로킹·논블로킹(제어권을 바로 돌려받나)을 구분하고, 스레드보다 가벼운 실행 단위(파이버·코루틴·그린 스레드·가상 스레드), async/await와 CPS, Reactor·Proactor, 공유 메모리 대신 메시지를 쓰는 CSP·액터, Go·Tokio·BEAM 런타임의 스케줄링, GIL과 그 대안을 한 지도로 정리한다.
Computer Science › Operating System
리눅스 서버 점검: 부하·메모리·자원 한도서버에 들어가면 보는 순서(부하 평균, 커널 로그, 디스크, TCP 상태, I/O), free의 available과 페이지 캐시·버퍼 캐시, 메모리가 바닥날 때 캐시 회수에서 OOM Killer까지 벌어지는 일, open files·max user processes 같은 ulimit 한도와 systemd 설정, 운영 보안 습관을 정리했다.
Computer Science › Operating System
멀티스레딩 디자인 패턴과 논블로킹 알고리즘생산자-소비자, 스레드 풀, 퓨처·프로미스, 모니터 객체, 배리어, 읽기-쓰기 락 여섯 가지 멀티스레딩 패턴이 각각 어떤 동기화 문제를 푸는지 정리한다. 스레드 안전의 뜻과 락 없이 얻는 방법, 언어별 기본 자료구조의 스레드 안전성과 동시성 해시 테이블 설계(락 스트라이핑, 버킷 단위 CAS), CPU·I/O 바운드에 따른 스레드 풀 크기, 포크-조인과 작업 훔치기도 다룬다. 락을 쓰는 블로킹 알고리즘과 CAS로 짜는 논블로킹 알고리즘의 차이, 진행 보장 단계(락 프리, 기아 없음, 대기 없음)도 함께 다룬다.
Computer Science › Programming Languages
메모리 풀같은 크기의 객체를 자주 할당·해제할 때 큰 블록을 미리 잡아 두고 한 칸씩 나눠 주는 메모리 풀을 정리한다. 고정 크기 풀은 빈 칸 인덱스 스택 하나로 할당과 해제를 O(1)에 끝내고, 가변 풀은 고정 풀을 청크로 이어 붙인다. 클래스의 operator new/delete를 오버로딩하면 호출 코드를 바꾸지 않고 풀을 쓸 수 있다.
Computer Science › Programming Languages
프로그래밍 언어의 계보와 선택기계어·어셈블리에서 고급 언어까지 세대 구분, 1950년대 Fortran·LISP부터 2010년대 Rust·Go·Kotlin·Swift·TypeScript까지 언어가 어떤 문제를 풀려고 이어져 왔는지, C++가 여전히 쓰이는 분야, 언어별 에너지 효율 연구의 결론을 정리한다.
Computer Science › Programming Languages
프로그램이 실행되기까지: 컴파일, 바이트코드, 인터프리터, GC소스 코드가 CPU에서 돌기까지의 세 갈래(네이티브 컴파일, 바이트코드 + VM·JIT, 인터프리터)와, 운영체제가 실행 파일을 띄워 종료하기까지의 단계, 가비지 컬렉션이 관리하는 영역과 추적·참조 카운팅의 비교, 순환 참조와 retain cycle, GC의 장단점과 Java·Python·Go의 방식, 브라우저에서 네이티브 코드를 돌리는 WebAssembly를 정리한다.
Computer Science › Programming Languages
C++ 예외 처리의 내부 동작C++의 throw가 실제로 하는 일을 정리한다. 예외 객체는 힙에 할당되어 참조 카운트로 해제되고, 스택 되감기는 컴파일러가 만든 테이블(.eh_frame, LSDA)을 보고 함수와 call site를 찾아 소멸자를 부른다. 현대 컴파일러의 zero-cost 방식은 try 자체에는 비용이 없지만 throw가 매우 비싸므로, 예외는 진짜 예외 상황에만 쓰고 일상적인 실패는 오류 코드나 std::expected로 돌려준다.
Computer Science › Programming Languages
C++ STL 컨테이너와 시간 복잡도C++ 표준 라이브러리의 vector·deque·list·set·map·unordered 컨테이너가 내부적으로 어떤 자료구조인지, 그래서 연산별 시간 복잡도가 어떻게 되는지 정리한다. vector 끝 삽입은 용량을 배수로 늘리기 때문에 분할 상환 O(1)이고, set·map은 레드-블랙 트리라 O(log n)이다.
Computer Science › Programming Languages
JVM 내부 구조: 실행 엔진, 클래스 로딩, 메모리 영역, GCJVM의 구성 요소(클래스로더·런타임 데이터 영역·실행 엔진)와 계층형 JIT, javac가 만든 바이트코드가 클래스 로딩(로딩·링크·초기화, 부모 위임)을 거쳐 실행되는 과정, 스택과 힙의 역할, 세대별 GC와 Serial·Parallel·G1·ZGC·Shenandoah 비교, GC 로그·힙 덤프로 메모리 문제를 진단하는 방법, GraalVM Native Image와 AOT 캐시를 정리한다.
Computer Science
소프트웨어 비대화하드웨어가 빨라진 만큼 소프트웨어가 느려지고 커져서 사용자가 체감하는 속도는 그대로인 현상. 「개발자 시간이 더 비싸다」는 논리로 쌓인 의존성·계층·임시방편이 원인이다. 효율을 기본값으로 두고, 의존성을 아끼고, 증상이 아니라 원인을 고치고, 재현 가능하게 만든다.
DevOps
서버 장애 진단 패턴서버 장애를 추측이 아니라 계측으로 좁혀 가는 방법과, 자주 반복되는 장애 유형의 증상·원인·해결을 모았다. load average와 CPU·I/O 지표 읽기, 힙 덤프로 메모리 누수 찾기, DB 커넥션 실패와 DNS 역조회, 인덱스를 못 타는 쿼리와 MVCC 죽은 튜플, 세션이 Redis 메모리를 고갈시키는 경우, 선착순 카운터 병목, 피크 트래픽 대비와 사후 분석까지 다룬다.
DevOps
쿠버네티스 스케줄링과 자원 관리, 오토스케일링파드를 어느 노드에 둘지 정하는 nodeSelector·노드 어피니티·파드 (안티)어피니티·토폴로지 분산·테인트와 톨러레이션, CPU·메모리 requests와 limits의 의미와 초과 시 동작, QoS 클래스, LimitRange·ResourceQuota·PriorityClass, 그리고 HPA·VPA·Cluster Autoscaler의 동작 원리와 함께 쓸 때의 주의점을 정리한다.
DevOps
AWS Lambda의 내부 구조서버리스 함수 서비스 Lambda가 요청을 처리하는 과정을 동기·비동기 호출 경로, 실행 환경을 배정하는 Assignment 서비스와 Placement 서비스, 함수마다 격리하는 Firecracker 마이크로VM, 코드·이미지를 청크로 나눠 공유하는 저장 계층, 콜드 스타트를 줄이는 SnapStart로 나눠 정리했다.
AI & Data
웹 AI 플랫폼 고르기: 클라이언트, 서버, 하이브리드웹 AI는 모델이 어디서 도나(브라우저 / 서버)와 얼마나 고칠 수 있나(가중치 접근)로 네 가지 선택지가 생긴다. 내장 AI·커스텀 클라이언트 모델·관리형 API·자체 호스팅을 모델 성능·비용·프라이버시·호환성·유지 보수로 비교하고, 요구 사항에서 플랫폼을 고르는 법과 클라이언트 우선 하이브리드 라우팅을 정리한다.
AI & Data
클라이언트 사이드 웹 AI: 내장 AI API, 라이브러리, 런타임브라우저에서 AI를 돌리는 방법은 브라우저가 들고 있는 모델을 부르는 내장 AI(Chrome의 Summarizer·Translator·Prompt API 등)와, Transformers.js·WebLLM 같은 라이브러리로 직접 고른 모델을 돌리는 방식 두 가지다. Chrome 내장 AI API의 현재 상태와 쓰는 법, 라이브러리별 쓰임, Wasm·WebGPU·WebNN 런타임을 정리한다.
AI & Data
LLM 서빙의 병목: KV 캐시, 배치, GPULLM을 수억 명에게 서비스할 때 병목은 연산보다 GPU 메모리인 경우가 많다. 어텐션 비용과 KV 캐시, 산술 강도와 배치 크기, GPU 사용률이 속이는 지표인 이유, 지역보다 GPU를 따라가는 배치, 오토스케일이 안 되는 상황을 정리했다. PagedAttention·연속 배치·프롬프트 캐싱 같은 지금의 서빙 기법과 H100·H200·B200의 연산 대비 메모리 대역폭도 다룬다.
Tools › Chrome DevTools
DevTools로 성능·메모리 분석하기Performance 패널의 실시간 지표 화면과 트레이스 녹화·읽기(메인 트랙, 플레임 차트, Bottom-up·Call tree, 긴 작업, 인사이트, 주석, 저장·공유, 선택기 통계), 성능 모니터, 렌더링 탭과 레이어 패널, 커버리지, 메모리 패널로 누수·팽창·잦은 GC를 찾는 절차, Lighthouse 실행법을 정리한다.
Tools › Git
대형 저장소에서 Git 빠르게 쓰기: 얕은 클론, refspec, 부분 클론, 희소 체크아웃커밋 이력과 파일이 많은 모노레포에서 clone·checkout·status가 느려지는 원인과 줄이는 방법을 정리했다. 이력을 자르는 얕은 클론, 받을 브랜치를 좁히는 단일 브랜치·refspec, 파일 내용을 나중에 받는 부분 클론, 작업 트리를 일부만 펼치는 희소 체크아웃, 파일 감시와 백그라운드 유지 보수까지 다루고 CI와 개발자 PC에서 각각 무엇을 쓰는지 정리한다.
Tools
워드프레스: 철학, 테마·플러그인 고르기, 속도, 생태계웹의 큰 몫을 차지하는 오픈 소스 CMS 워드프레스. '옵션이 아닌 결정', 80% 규칙 같은 설계 철학, 테마·플러그인을 고르는 기준, 사이트를 빠르게 하는 순서, 실력을 쌓는 길과 GPL 위에서 돌아가는 비즈니스 모델을 정리했다.