#rendering
노트 19개
Frontend › Architecture
컴포넌트를 분리하는 기준과 방법컴포넌트를 나누는 이유는 재사용, 복잡성, 렌더링 범위 세 가지다. 재사용할 컴포넌트는 주변 HTML 문맥에 기대지 않을 만큼 일반적이어야 하고, 쓰는 곳마다 조건문이 붙는다면 중복이 아니므로 고유한 부분은 props로 넘긴다. 복잡한 컴포넌트는 책임과 변경 빈도(UI vs 비즈니스 로직)를 기준으로 나누고, 서로 무관한 상태는 각자의 컴포넌트로 내린다.
Frontend › Architecture
UI 변경 감지: 상태가 바뀌면 화면은 어떻게 따라 바뀌나UI 프레임워크의 핵심 문제는 상태를 화면으로 투영하고, 상태가 바뀌었을 때 최소한의 DOM만 고치는 것이다. 전부 새로 그리기, 수동 재렌더, 데이터 바인딩(관찰 가능한 모델·Proxy), 더티 체킹(AngularJS digest·zone.js), 가상 DOM 비교, 불변 데이터로 비교 건너뛰기, 시그널, 컴파일러까지 변경을 '언제·어떻게 아는가'로 나눠 비교하고, React Fiber가 렌더링을 쪼개 우선순위를 매기는 방식을 정리한다.
Frontend › CSS
CSS Houdini: 렌더링 엔진에 끼어드는 API브라우저 CSS 엔진의 파싱·스타일·레이아웃·페인트·합성 단계에 개발자 코드를 걸 수 있게 하려는 저수준 API 묶음. CSS 폴리필이 왜 어려운지에서 출발해 워크릿, Properties and Values(@property), Typed OM, Paint·Layout·Animation Worklet의 역할과 2026년 기준 지원 상태를 정리한다. 모든 브라우저에 들어간 것은 @property와 일부 Typed OM뿐이다.
Frontend › CSS
CSS가 동작하는 방식: 핵심 개념과 픽셀이 되기까지속성 암기보다 먼저 익혀야 할 CSS의 핵심 개념(캐스케이드·상속·특정도, 박스 모델, 일반 흐름, 서식 맥락, 흐름 안팎, 정렬, 크기 결정)과, 브라우저가 CSS를 해석·캐스케이드·계산해 레이아웃으로 넘기는 과정.
Frontend › Mobile
Flutter의 구조와 위젯 트리Flutter는 Dart 프레임워크·C++ 엔진·플랫폼 임베더의 세 층으로 이루어져, OS의 UI 컴포넌트를 빌리지 않고 화면을 직접 그린다. 프레임워크 라이브러리(Material, Cupertino, Widgets, Rendering 등)의 역할, Widget·Element·RenderObject 세 트리, StatefulWidget 순서를 바꿀 때 Key가 필요한 이유, 패키지·플러그인을 만들어 pub.dev에 배포하는 법을 정리한다.
Frontend
Next.jsReact 위에 라우팅·렌더링 전략·캐싱을 얹은 프레임워크. 왜 쓰는지, App Router가 데이터를 어떻게 가져오는지, 서버·클라이언트 컴포넌트를 어떻게 섞는지 정리한 노트 모음.
Frontend › Next.js
서버 컴포넌트와 클라이언트 컴포넌트 조합 규칙React Server Components에서 서버·클라이언트 컴포넌트를 어떻게 섞을 수 있는지 한 장으로 정리한다. 클라이언트는 서버 안에 넣을 수 있지만 서버를 클라이언트에서 import할 수는 없고, 대신 children·props로 넘길 수 있다. 클라이언트에서 서버 코드를 부르는 Server Function과 그 주의점까지 Next.js 16 문서 기준으로 확인했다.
Frontend › Next.js
Next.js App Router의 내비게이션과 데이터 가져오기App Router는 서버가 라우팅하고 클라이언트가 내비게이션한다. Link·useRouter, prefetch와 클라이언트 캐시, 서버 컴포넌트의 병렬·순차 fetch, 요청 중복 제거, React cache()와 preload 패턴을 정리한다.
Frontend › Next.js
Next.js를 쓰는 이유SSR·SSG·파일 기반 라우팅·자동 코드 스플리팅을 제공해 React 앱의 초기 로딩과 SEO를 개선하는 프레임워크. App Router의 fetch 캐싱과 재검증, Next.js 16의 'use cache'까지.
Frontend › Next.js
React Server Components의 동작 원리서버가 컴포넌트 트리를 렌더링해 HTML이 아니라 직렬화된 React 트리(RSC Payload)를 스트리밍하고, 브라우저가 클라이언트 컴포넌트 참조를 실제 코드로 바꿔 트리를 재구성하는 과정을 정리한다. SSR과의 차이, 요청 왕복을 줄이려고 나온 배경과 서버 컴포넌트 모델(XHP)에서 출발한 역사, 다시 렌더링되지 않는다는 성질과 클라이언트 경계, 갱신 방식, 제약까지.
Frontend › React
리렌더링 원인과 추적리렌더링을 일으키는 원인, React.memo가 효과 없는 경우, useQuery가 최소 두 번 렌더링하는 이유, DevTools로 추적하고 줄이는 순서.
Frontend › React
리스트 가상화(Windowing)항목이 수천 개인 목록에서 화면에 보이는 항목만 DOM에 그리고 나머지는 높이만 차지하게 하는 기법. 원리(전체 높이 + 보이는 구간 계산 + 절대 위치), TanStack Virtual·react-window 사용법, 가변 높이·접근성·찾기 기능 같은 한계와 content-visibility 대안을 정리한다.
Frontend › React
재조정(Reconciliation)과 state 보존React가 리렌더링 때 이전 엘리먼트 트리와 새 트리를 비교해 DOM 변경을 최소로 계산하는 과정. render 단계와 commit 단계, 타입이 다르면 하위 트리를 통째로 리마운트하고 같으면 속성만 고치는 비교 규칙, state가 트리의 '위치'에 묶여 보존·초기화되는 원리와 key로 초기화하는 법을 정리한다.
Frontend › Web
브라우저 렌더링 과정브라우저의 구성 요소와, HTML을 DOM으로·CSS를 CSSOM으로 파싱해 렌더 트리로 레이아웃(리플로우)·페인팅·합성을 거쳐 화면을 그리는 과정. HTML 파서의 특성, 스크립트·스타일 시트의 차단, 더티 비트와 강제 동기 레이아웃, 변경마다 다시 도는 단계까지.
Frontend › Web
브라우저 아키텍처: 다중 프로세스, 내비게이션, 렌더러 스레드, 입력 처리Chrome을 예로 브라우저가 프로세스를 어떻게 나누는지(브라우저·렌더러·GPU·네트워크 등, 사이트 격리), 주소를 입력한 뒤 어느 프로세스가 무엇을 하며 페이지를 커밋하는지, 렌더러 안의 메인·컴포지터·래스터 스레드가 프레임을 만드는 방식, 입력 이벤트가 컴포지터를 거쳐 메인 스레드로 가는 길과 passive 리스너·이벤트 병합까지.
Frontend › Web
스트리밍 SSRHTML을 한 번에 다 만들어 보내지 않고 Suspense 경계 단위로 나눠 흘려보내는 SSR. React 18에서 도입됐고, 지금은 React 19의 부분 사전 렌더링과 Next.js Cache Components의 기반이 되어 기본 동작으로 자리 잡았다.
Frontend › Web
정적 사이트 생성기와 Jamstack정적 사이트 생성기(SSG)는 마크다운 콘텐츠와 템플릿을 빌드 때 HTML로 합쳐 CDN에 올린다. 서버·DB가 없어 빠르고 안전하며, Git push가 곧 배포다. 콘텐츠 사이트는 JS를 거의 보내지 않는 Eleventy·Hugo·Astro가 맞고, 상호작용이 많으면 Next.js 같은 프레임워크를 쓴다. WordPress에서 옮기는 흐름도 정리한다.
Frontend › Web
SPA와 CSR·SSR한 페이지에서 필요한 부분만 다시 그리는 SPA와, 렌더링 주체·시점에 따른 CSR·SSR·SSG·ISR의 차이.
Computer Science
컴퓨터 그래픽스 렌더링 기초: 프레임버퍼에서 3D 래스터화까지화면이 메모리의 어떤 내용을 비추는지(래스터 스캔과 벡터 스캔, 텍스트 모드, 프레임버퍼)에서 시작해, 3D 장면을 2D 픽셀로 바꾸는 래스터화 렌더링의 단계(투영, 삼각형 메시, 스캔라인 채우기, 안티앨리어싱, 화가 알고리즘과 Z 버퍼, 후면 컬링, 플랫·고러드·퐁 셰이딩, 텍스처 매핑)와 GPU가 이 일을 병렬로 하는 이유를 정리한다.