실무에서 검증된 디자인, 개발, AI workflow 강의를 제공합니다.

인프라

# 브라우저 렌더링 파이프라인
브라우저가 HTML 텍스트를 화면의 픽셀로 바꾸는 과정을 렌더링 파이프라인이라고 합니다. 이 섹션에서는 각 단계가 무엇을 하고, 어디서 성능 비용이 생기는지 살펴봅니다.

## 브라우저는 HTML을 어떻게 화면에 그리나요?
브라우저는 크게 여섯 단계를 거칩니다. HTML을 파싱해 {tip:DOM}(Document Object Model, 문서 구조를 나타내는 트리)을 만들고, CSS로 {tip:CSSOM}(CSS Object Model, 스타일 규칙을 담은 트리)을 만든 뒤 둘을 합쳐 렌더 트리를 구성합니다. 이어서 레이아웃(위치·크기 계산), 페인트(픽셀 채우기), {tip:컴포지팅}(여러 레이어를 합쳐 최종 화면을 만드는 단계) 순으로 진행됩니다.

![렌더링 6단계](ph:파싱 → DOM·CSSOM → 렌더 트리 → 레이아웃 → 페인트 → 컴포지팅){size=large align=center caption="HTML이 픽셀이 되기까지의 여섯 단계"}

> 참고: 이 여섯 단계는 한 번 실행되고 끝나는 것이 아니라, 화면이 바뀔 때마다 일부 또는 전체가 다시 실행됩니다.

### DOM과 CSSOM은 어떻게 만들어지나요?
HTML 파서는 바이트 → 문자 → 토큰 → 노드 → DOM 트리 순으로 변환합니다. CSSOM도 비슷하게 CSS 텍스트를 파싱해 만들어집니다. 두 트리는 독립적으로 구성되지만, 렌더 트리를 만들려면 둘 다 필요합니다.

#### 파싱 중 스크립트를 만나면 어떻게 되나요?
기본적으로 스크립트 태그는 파서를 멈춥니다(파서 블로킹). 스크립트가 DOM을 조작할 수 있기 때문에, 브라우저는 스크립트를 내려받아 실행할 때까지 HTML 파싱을 중단합니다. 그래서 스크립트의 위치와 `async`·`defer` 속성이 중요합니다.

### 렌더 트리는 DOM과 무엇이 다른가요?
렌더 트리는 화면에 실제로 그려지는 노드만 포함합니다. 따라서 `display:none` 요소나 head 같은 비시각 요소는 렌더 트리에 들어가지 않습니다.

#### display:none과 visibility:hidden은 렌더 트리에서 어떻게 다른가요?
`display:none`은 렌더 트리에서 완전히 제외되어 공간을 차지하지 않습니다. 반면 `visibility:hidden`은 렌더 트리에 남아 공간은 차지하되 그려지지만 않습니다. 그래서 둘은 레이아웃에 미치는 영향이 다릅니다.

# 리플로우와 리페인트
화면이 바뀔 때 어떤 단계가 다시 실행되는지에 따라 성능 비용이 크게 달라집니다.

## 리플로우는 언제 발생하나요?
{tip:리플로우}(요소의 위치·크기를 다시 계산하는 과정. 레이아웃(layout)이라고도 함. | 비유하면 가구를 옮길 때마다 방 전체 배치를 다시 재는 것과 같음 — 그래서 비쌉니다. | 리페인트는 색·그림자처럼 “다시 칠하기”만 하는 더 가벼운 작업으로, 리플로우와 구분해야 함.)는 요소의 크기나 위치에 영향을 주는 변경이 있을 때 발생합니다. 리플로우가 일어나면 뒤따르는 페인트·컴포지팅도 함께 다시 실행되므로 가장 비싼 작업에 속합니다.

### 어떤 속성이 리플로우를 유발하나요?
`width`, `height`, `margin`, `top`, `left`, 폰트 크기처럼 레이아웃에 영향을 주는 속성이 리플로우를 유발합니다. 또한 `offsetTop`이나 `getBoundingClientRect()` 같은 값을 읽는 것도 강제 동기 리플로우를 일으킬 수 있습니다.

#### transform과 top의 성능 차이는 무엇인가요?
`top`을 바꾸면 리플로우가 발생하지만, `transform: translate`는 레이아웃을 건드리지 않고 컴포지팅 단계에서만 처리되어 훨씬 저렴합니다. 그래서 애니메이션에는 `transform`과 `opacity`를 권장합니다.

### 리플로우를 줄이는 방법은?
DOM 변경을 한 번에 모아서 처리하고, 레이아웃 값을 읽고 쓰는 순서를 분리하며, 애니메이션에는 transform/opacity를 사용합니다. 잦은 변경이 있는 요소는 레이어 분리를 고려할 수 있습니다.

# 임계 렌더링 경로
첫 화면을 최대한 빨리 보여주려면 렌더링을 막는 리소스를 이해해야 합니다.

## 첫 화면을 빠르게 그리려면 무엇을 봐야 하나요?
{tip:임계 렌더링 경로}(Critical Rendering Path, 첫 픽셀을 그리기까지 거치는 리소스와 단계의 묶음)를 최소화해야 합니다. 핵심은 렌더링을 막는 리소스를 줄이고, 꼭 필요한 것만 먼저 로드하는 것입니다.

![임계 렌더링 경로](ph:HTML · CSS · JS 로드 타임라인){size=medium align=center caption="클릭하면 크게 보기" modal}

### render-blocking 리소스란 무엇인가요?
브라우저가 첫 렌더를 시작하기 전에 반드시 처리해야 하는 리소스입니다. 대표적으로 CSS와 동기 스크립트가 있습니다.

#### CSS는 왜 render-blocking인가요?
CSSOM이 완성되어야 렌더 트리를 만들 수 있기 때문입니다. CSS가 일부라도 빠지면 잘못된 스타일로 화면이 깜빡일 수 있어, 브라우저는 CSSOM이 준비될 때까지 렌더를 미룹니다.

### async와 defer는 어떻게 다른가요?
`async`는 내려받는 즉시 실행되어 순서가 보장되지 않고, `defer`는 HTML 파싱이 끝난 뒤 문서 순서대로 실행됩니다. 의존성이 있는 스크립트는 보통 `defer`가 안전합니다.

# 웹 성능 지표
사용자가 체감하는 성능을 수치로 측정하는 지표들입니다.

## Core Web Vitals는 무엇을 측정하나요?
{tip:LCP}(Largest Contentful Paint, 가장 큰 콘텐츠가 그려지는 시점), {tip:CLS}(Cumulative Layout Shift, 예상치 못한 레이아웃 이동량), {tip:INP}(Interaction to Next Paint, 상호작용 반응 속도) 세 가지가 핵심입니다.

### LCP를 개선하려면?
가장 큰 콘텐츠(보통 히어로 이미지나 큰 텍스트 블록)가 빨리 그려지도록 이미지 최적화, 우선순위 지정, 서버 응답 시간 단축을 적용합니다.

### CLS를 줄이려면?
레이아웃이 갑자기 밀리지 않게 해야 합니다. 폰트 로딩과 동적 삽입 영역도 함께 관리합니다.

#### 이미지에 width와 height를 지정해야 하는 이유는?
크기를 지정하면 브라우저가 로드 전에 공간을 미리 확보해, 이미지가 도착했을 때 아래 콘텐츠가 밀리는 레이아웃 이동을 막을 수 있습니다.

HTML이 화면의 픽셀이 되기까지의 여섯 단계와, 리플로우·임계 렌더링 경로·Core Web Vitals까지 성능의 큰 그림을 잡습니다.

브라우저 렌더링 파이프라인 완전 정복

# 브랜치 전략의 기본
여러 사람이 같은 코드베이스를 동시에 고칠 때 충돌을 줄이고 배포를 안정적으로 만드는 약속이 브랜치 전략입니다.

## 왜 main에 직접 커밋하지 않나요?
main은 항상 배포 가능한 상태를 유지해야 하기 때문입니다. 기능은 별도 {tip:브랜치}(특정 시점에서 갈라져 나온 독립된 작업 라인)에서 작업하고, 리뷰를 거쳐 합칩니다.

### 기능 브랜치는 얼마나 작게 유지해야 하나요?
하나의 목적만 담아 며칠 안에 합칠 수 있는 크기가 이상적입니다. 브랜치가 오래 살수록 main과 멀어져 충돌과 리뷰 부담이 커집니다.

#### 그래도 브랜치가 길어지면 어떻게 하나요?
주기적으로 main을 끌어와(rebase 또는 merge) 차이를 줄이고, 큰 작업은 기능 플래그 뒤에서 잘게 나눠 합치는 방법을 씁니다.

## merge와 rebase는 어떻게 다른가요?
merge는 두 갈래의 역사를 합치는 새 커밋을 만들고, rebase는 내 커밋을 main 위로 옮겨 역사를 일직선으로 다시 씁니다. 공유된 브랜치에는 보통 merge가 안전합니다.

### 언제 rebase를 피해야 하나요?
이미 다른 사람과 공유된(푸시된) 브랜치를 rebase하면 역사가 어긋나 협업자에게 충돌을 일으킵니다. 그래서 rebase는 보통 아직 혼자만 쓰는 로컬 브랜치에 한정합니다.

main을 안전하게 지키는 브랜치 운영, merge와 rebase의 차이, 그리고 충돌을 줄이는 실무 습관을 질문으로 익힙니다.

협업을 위한 Git 브랜치 전략 입문

# 좋은 프롬프트의 구조
LLM에게 일을 맡길 때 결과 품질은 모델보다 프롬프트 설계에 더 크게 좌우될 때가 많습니다. 검수 가능한 구조를 먼저 만드는 것이 핵심입니다.

## 무엇부터 명확히 적어야 하나요?
역할, 목표, 출력 형식 세 가지를 먼저 고정합니다. {tip:역할 지정}(모델에게 관점·전문성을 부여하는 문장. 예: “당신은 기술 에디터입니다.”)은 톤과 판단 기준을 잡아 주고, 출력 형식을 명시하면 후처리가 쉬워집니다.

### 예시를 넣는 게 정말 효과가 있나요?
네. 한두 개의 좋은 예시({tip:few-shot}(원하는 입력→출력 쌍을 몇 개 보여 주어 패턴을 학습시키는 방식))는 길게 설명하는 것보다 형식과 톤을 더 정확히 전달합니다.

#### 예시가 너무 많으면 문제가 되나요?
예시가 많으면 토큰이 늘고, 특정 예시의 표면적 패턴에 과하게 끌려갈 수 있습니다. 보통 2~3개의 대표 예시로 충분합니다.

## 답이 자꾸 장황해질 때는 어떻게 하나요?
출력 길이와 형식을 수치로 제약합니다. “3문장 이내”, “불릿 5개”처럼 명시하면 모델이 분량을 스스로 조절합니다.

### 형식을 강제하는 더 확실한 방법은?
JSON 스키마나 템플릿을 제시하고 “이 형식만 출력하라”고 못 박는 것입니다. 후처리에서 파싱할 거라면 특히 효과적입니다.

역할·목표·출력 형식부터 few-shot 예시와 길이 제약까지, 흔들리지 않는 LLM 결과를 만드는 프롬프트 구조를 정리합니다.

튜토리얼

인프라

브라우저 렌더링 파이프라인 완전 정복

협업을 위한 Git 브랜치 전략 입문

검수 가능한 프롬프트 설계의 기본