[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,92 +2,138 @@
|
||||
id: wiki-2026-0508-main-thread
|
||||
title: Main Thread
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Browser Main Thread, UI Thread, JS Main Thread, Event Loop Thread]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.94
|
||||
verification_status: applied
|
||||
tags: [web-performance, browser, event-loop, inp, web-worker, rendering, javascript]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack: { language: javascript|typescript, framework: browser|web-worker }
|
||||
---
|
||||
|
||||
# [[Main Thread|Main Thread]]
|
||||
# Main Thread
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> Main Thread(메인 스레드)는 웹 브라우저에서 자바스크립트 실행, 렌더링, 이벤트 처리 등 핵심 작업이 순차적으로 실행되는 단일 작업 흐름을 의미합니다 [1, 2]. [[WebGL|WebGL]]과 같은 환경에서는 그래픽 명령어 제출을 비롯한 무거운 연산이 메인 스레드에서 이루어질 경우 렌더링 파이프라인이 차단되어 지연(Latency)과 병목 현상이 발생할 수 있습니다 [1, 2]. [[Chrome DevTools|Chrome DevTools]]와 같은 성능 분석 도구를 통해 메인 스레드의 활동을 시각적으로 추적하고 병목 지점을 최적화할 수 있습니다 [3-5].
|
||||
> 한 줄: 브라우저에서 JS 실행·DOM 파싱·layout·paint·이벤트 처리가 모두 도는 단일 스레드 — 막히면 INP·반응성 즉사.
|
||||
|
||||
---
|
||||
## 핵심
|
||||
- **Single-threaded**: JS는 main thread 위 event loop. 한 task가 길면 모두 정지.
|
||||
- **Long task**: ≥50ms 작업 → INP 악화. Core Web Vitals 핵심 지표.
|
||||
- **Pipeline**: parse HTML → CSSOM → JS 실행 → layout → paint → composite. 매 frame 16.7ms (60fps) 안에 끝나야.
|
||||
- **분리 가능 작업**: heavy compute (CSV parse, image proc, crypto, ML) → Web Worker. DOM은 worker 불가.
|
||||
- **도구**: Chrome DevTools Performance, `PerformanceObserver('longtask')`, `scheduler.yield()` (2025+).
|
||||
|
||||
메인 스레드는 브라우저가 HTML을 파싱하여 DOM 트리를 구축하고, 자바스크립트를 실행하며, 페이지의 레이아웃과 페인트를 포함한 렌더링을 처리하는 핵심 단일 스레드입니다 [1-4]. 브라우저는 기본적으로 단일 스레드 구조이므로, 메인 스레드가 작업을 진행 중일 때는 다른 요청이나 사용자 상호작용을 동시에 처리할 수 없습니다 [1, 5]. 따라서 메인 스레드의 점유 시간을 최소화하고 책임을 줄이는 것이 빠르고 반응성 높은 웹 성능을 확보하는 핵심 요건입니다 [1].
|
||||
## 결정 기준
|
||||
| 작업 | 처리 |
|
||||
|---|---|
|
||||
| DOM 조작 | main thread (필수) — batch + virtual DOM |
|
||||
| JSON parse < 1MB | main, OK |
|
||||
| JSON parse > 5MB | Web Worker |
|
||||
| 이미지 리사이즈 | OffscreenCanvas + Worker |
|
||||
| ML 추론 | Worker + WebGPU/WASM |
|
||||
| 큰 list 렌더 | virtualization (react-window, TanStack Virtual) |
|
||||
| 긴 루프 | `scheduler.yield()` 또는 chunked + `setTimeout(0)` |
|
||||
| 우선순위 제어 | `scheduler.postTask({priority:'background'})` |
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **단일 스레드 구조와 병목 현상:** WebGL은 단일 스레드(Single-threaded) 환경에서 작동하므로 모든 드로우 콜([[Draw Call|Draw Call]]), 상태 변경, 리소스 업로드가 메인 스레드에서 순차적으로 실행됩니다 [2]. 이로 인해 자바스크립트 실행에 과도한 시간이 소요되면 메인 스레드가 차단(blocked)되고 렌더링 파이프라인이 지연되는 병목 현상이 발생하며, GPU는 다음 명령을 기다리며 유휴 상태(idle)로 남게 됩니다 [1, 2, 6, 7].
|
||||
* **성능 모니터링 및 진단:** [[Chrome|Chrome]] DevTools의 Performance 패널에서 'Main' 트랙을 사용하면 메인 스레드의 활동을 시간의 흐름에 따른 플레임 차트([[Flame Chart|Flame Chart]]) 형태로 분석할 수 있습니다 [3-5]. 개발자는 이를 통해 16.67ms의 프레임 예산을 초과하여 메인 스레드를 차단하는 구체적인 자바스크립트 함수를 식별하고 [8], 50ms를 초과하는 긴 작업([[Long Tasks|Long Tasks]])을 파악하여 성능 저하의 원인을 진단할 수 있습니다 [9, 10].
|
||||
* **최적화 및 [[WebGPU|WebGPU]]로의 전환:** 메인 스레드의 차단을 방지하여 상호작용성(Responsiveness)을 높이려면, 무거운 자바스크립트 작업을 더 작은 비동기 조각으로 나누거나 웹 워커(Web Workers)를 활용하여 메인 스레드에서 작업을 분리해야 합니다 [9]. 최근에는 이러한 메인 스레드 병목 현상을 근본적으로 해결하기 위해, 애니메이션 로직과 명령어 생성을 다중 스레드(Multi-Threaded)로 분산하고 작업을 GPU로 오프로드할 수 있는 WebGPU 기술이 도입되고 있습니다 [11, 12].
|
||||
## 💻 패턴
|
||||
|
||||
---
|
||||
### Long task 측정
|
||||
```js
|
||||
new PerformanceObserver((list) => {
|
||||
for (const e of list.getEntries()) console.warn("longtask", e.duration, e);
|
||||
}).observe({ type: "longtask", buffered: true });
|
||||
```
|
||||
|
||||
- **주요 역할 및 병목 현상**
|
||||
메인 스레드는 DOM 트리 생성, 자바스크립트 컴파일 및 해석(웹 워커 등 일부 예외 제외), 화면 렌더링 등 브라우저의 대부분의 주요 작업을 전담합니다 [2-4]. 초기 로드 과정이나 무거운 자바스크립트 파싱 및 실행으로 인해 메인 스레드가 오랫동안 점유될 경우, 사용자의 클릭이나 스크롤과 같은 상호작용 이벤트에 50ms 이내로 반응하지 못하게 되어 UI가 지연(Jank)되거나 멈춘 것처럼 느껴지게 됩니다 [6, 7]. 특히 초기 로드 중 메인 스레드에서의 과도한 처리는 코어 웹 바이탈([[Core Web Vitals|Core Web Vitals]]) 수치 하락과 검색 순위(SEO) 페널티로 이어질 수 있습니다 [8].
|
||||
### Yield to main thread (2025+ standard)
|
||||
```js
|
||||
async function processItems(items) {
|
||||
for (const item of items) {
|
||||
doWork(item);
|
||||
if (navigator.scheduling?.isInputPending() || performance.now() % 50 < 1) {
|
||||
await scheduler.yield(); // 또는 await new Promise(r => setTimeout(r, 0))
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **성능 예산(Frame [[Budget|Budget]])과 반응성**
|
||||
애니메이션과 스크롤을 60fps로 부드럽게 유지하려면, 메인 스레드를 차지하는 스타일 계산, 리플로우(Reflow), 페인트(Paint) 등의 작업이 16.67ms 이내에 완료되어야 합니다 [9, 10]. 규모가 큰 애플리케이션에서 렌더링이 이 16.6ms 프레임 예산을 초과하면 메인 스레드가 블로킹되어 UI가 사용자 입력에 반응할 수 없게 됩니다 [9].
|
||||
### Web Worker (module)
|
||||
```js
|
||||
// main.js
|
||||
const worker = new Worker(new URL("./heavy.worker.js", import.meta.url), { type: "module" });
|
||||
worker.postMessage({ csv: largeText });
|
||||
worker.onmessage = (e) => render(e.data);
|
||||
|
||||
- **메인 스레드 부하 완화 및 최적화 전략**
|
||||
- **[[React Fiber|React Fiber]]와 동시성 렌더링([[Concurrent Rendering|Concurrent Rendering]]):** 기존의 동기적 렌더링이 메인 스레드를 장시간 차단하는 문제를 해결하기 위해, React는 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위로 나누어 실행하고 우선순위가 높은 작업이 있을 때 브라우저에 제어권을 양보(Yield)하는 아키텍처를 도입했습니다 [9].
|
||||
- **[[React 19|React 19]] 동시성 훅:** `useTransition`이나 `[[useDeferredValue|useDeferredValue]]`를 사용하여 무거운 상태 업데이트를 지연시킴으로써, 타이핑이나 클릭 등 긴급한 사용자 상호작용을 위해 메인 스레드를 비워두어 INP(Interaction to Next Paint) 점수를 향상시킵니다 [11, 12].
|
||||
- **서버 컴포넌트(RSC):** 상호작용이 없는 컴포넌트를 서버에서 렌더링함으로써 클라이언트 브라우저로 전송되는 자바스크립트 번들 양을 줄이고, 결과적으로 상호작용 시 메인 스레드가 처리해야 할 자바스크립트의 양을 줄여줍니다 [13].
|
||||
- **GPU 컴포지팅(Compositing):** 애니메이션이나 전환 효과 등을 브라우저가 개별 레이어로 분리하여 메인 스레드(CPU) 대신 GPU에서 그리도록(Paint) 승격시키면, 메인 스레드를 해방시키고 성능을 크게 향상할 수 있습니다 [4, 14].
|
||||
// heavy.worker.js
|
||||
import Papa from "papaparse";
|
||||
self.onmessage = ({ data }) => {
|
||||
const parsed = Papa.parse(data.csv, { header: true });
|
||||
self.postMessage(parsed.data);
|
||||
};
|
||||
```
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** AI 분야의 자동 자산화 수행.
|
||||
### OffscreenCanvas (이미지/그래픽 워커화)
|
||||
```js
|
||||
const canvas = document.querySelector("canvas").transferControlToOffscreen();
|
||||
const w = new Worker("draw.worker.js");
|
||||
w.postMessage({ canvas }, [canvas]); // transfer
|
||||
```
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[WebGL|WebGL]], [[WebGPU|WebGPU]], Total Blocking Time (TBT), [[Interaction to Next Paint (INP)|Interaction to Next Paint (INP)]], [[Long Tasks|Long Tasks]]
|
||||
- **Projects/Contexts:** Chrome DevTools [[Performance Panel|Performance Panel]], [[Core Web Vitals|Core Web Vitals]]
|
||||
- **Contradictions/Notes:** 소스는 WebGL이 메인 스레드에서 순차적으로 그래픽 명령을 처리하여 CPU 병목을 유발한다고 주장하는 반면, 새로운 WebGPU는 다중 스레드 명령 생성(Multi-Threaded Command Generation)을 지원하여 메인 스레드의 오버헤드를 대폭 줄일 수 있다고 대조하여 설명합니다 [2, 11, 12].
|
||||
### Scheduler API 우선순위
|
||||
```js
|
||||
scheduler.postTask(() => analytics.flush(), { priority: "background" });
|
||||
scheduler.postTask(() => updateBadge(), { priority: "user-blocking" });
|
||||
```
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
### React 18+ transitions (cooperative)
|
||||
```jsx
|
||||
import { useTransition, useDeferredValue } from "react";
|
||||
const [isPending, startTransition] = useTransition();
|
||||
const onChange = (v) => {
|
||||
setQuery(v); // urgent
|
||||
startTransition(() => setResults(filter(v))); // non-urgent
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
### Long task 분할 (chunk)
|
||||
```js
|
||||
function chunked(items, fn, chunkSize = 100) {
|
||||
return new Promise((resolve) => {
|
||||
let i = 0;
|
||||
function step() {
|
||||
const end = Math.min(i + chunkSize, items.length);
|
||||
for (; i < end; i++) fn(items[i]);
|
||||
if (i < items.length) setTimeout(step, 0); else resolve();
|
||||
}
|
||||
step();
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
## 🔗 Graph
|
||||
- 상위: [[Web-Performance]] · [[Browser-Internals]] · [[Event-Loop]]
|
||||
- 관련: [[Web-Worker]] · [[Service-Worker]] · [[OffscreenCanvas]] · [[INP]] · [[Core-Web-Vitals]] · [[React-Concurrent]] · [[Scheduler-API]]
|
||||
- 도구: [[Chrome-DevTools-Performance]] · [[Lighthouse]] · [[WebPageTest]]
|
||||
|
||||
- **Related Topics:** 단일 스레드 (Single-threaded), [[React Fiber|React Fiber]], [[동시성 렌더링 (Concurrent Rendering)|동시성 렌더링 (Concurrent Rendering]]
|
||||
- **Projects/Contexts:** 웹 성능 최적화 (Web Performance [[Optimization|Optimization]]), Core Web Vitals (INP, TTI)
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
## 🤖 LLM 활용
|
||||
- DevTools flame chart를 LLM에 붙여 "어떤 long task가 INP를 망치는지" 해석 요청.
|
||||
- 코드 리뷰 prompt: "이 함수가 main thread를 블록할 가능성 분석".
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
## ❌ 안티패턴
|
||||
- **`while(true)` 폴링** — 메인 스레드 점유. requestAnimationFrame/setInterval/이벤트.
|
||||
- **거대 JSON sync parse** — Worker로 이동, streaming JSON (oboe, JSON.parseAsync 제안 등).
|
||||
- **DOM 조작을 루프 안에서 N번** — DocumentFragment/배치 + IntersectionObserver.
|
||||
- **무거운 라이브러리 main bundle** — code split, dynamic import.
|
||||
- **Worker 남용** — 작은 작업은 postMessage 오버헤드가 손해. 임계값 측정.
|
||||
- **`alert/confirm/prompt`** — modal sync block. 커스텀 dialog로 대체.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
## 🧪 검증 / 중복
|
||||
- 중복: [[Event-Loop]], [[Web-Worker]] 별도 — 본 문서는 main thread 관점 허브.
|
||||
- 검증: Lighthouse INP, RUM (web-vitals lib), Chrome DevTools "Performance" 탭 long tasks bar.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
## 🕓 Changelog
|
||||
- 2026-05-08 | Phase 1 — 자동 시드.
|
||||
- 2026-05-10 | Manual cleanup — scheduler.yield, Worker, OffscreenCanvas, React transition 패턴 정리, INP 결정 기준 추가.
|
||||
|
||||
Reference in New Issue
Block a user