Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

5.9 KiB

Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, inferred_by, tech_stack

title

Reflow와 Repaint

📌 한 줄 통찰 (The Karpathy Summary)

Reflow(리플로우)는 요소의 크기나 위치 등 레이아웃 구조가 변경될 때 브라우저가 문서의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 레이아웃에 영향을 주지 않는 시각적 속성(색상 등)이 변경될 때 화면을 다시 그리는 작업입니다 [1, 2]. 두 과정 모두 브라우저의 연산 리소스를 많이 소모하므로, 쾌적한 사용자 경험과 웹 성능을 유지하려면 이를 최소화해야 합니다 [1, 3, 4]. 유지보수와 성능을 모두 고려한 CSS 실전 설계에서는 이러한 브라우저 렌더링 파이프라인의 특성을 이해하고 효율적인 스타일링과 애니메이션 전략을 채택해야 합니다 [3, 5].

📖 구조화된 지식 (Synthesized Content)

개념과 차이점 및 발생 원인
- Reflow (Layout): 브라우저 창 크기 조절, 폰트 변경, 새로운 DOM 요소 추가/제거, width, height, margin, padding, top 등 기하학적 형태나 레이아웃에 영향을 주는 속성이 변경될 때 발생합니다 [3, 6, 7]. 한 요소의 Reflow는 자식 및 조상 요소, 그리고 DOM에서 그 뒤에 나타나는 모든 요소의 연쇄적인 Reflow를 유발하므로 매우 큰 비용이 듭니다 [2, 4].
- Repaint: color, background-color, outline, visibility 등 요소의 레이아웃에는 영향을 주지 않으면서 겉모습만 변경될 때 발생합니다 [2, 3, 6].
성능 최적화 및 유지보수를 위한 CSS 설계 기법
- 레이아웃 스래싱(Layout Thrashing) 방지 및 DOM 조작 최소화: JavaScript를 통해 다수의 인라인 스타일을 설정하면 개별적으로 Reflow가 발생합니다 [5, 8]. 변경 사항을 외부 CSS 클래스에 그룹화하여 한 번의 조작으로 DOM 트리의 클래스 속성을 변경하는 방식이 성능과 유지보수에 훨씬 유리합니다 [8, 9]. DOM을 읽고 쓰는 과정을 철저히 분리하여 레이아웃 스래싱을 방지해야 합니다 [10].
- 클래스 변경의 범위 제한: Reflow의 파급 범위를 줄이려면 DOM 트리에서 가능한 가장 낮은 위치(하위 노드)에 있는 요소의 클래스를 변경해야 합니다 [5, 11].
- 올바른 애니메이션(transition/keyframes) 전략: width, height, box-shadow 등의 속성을 애니메이션으로 처리하면 지속적으로 Reflow와 Repaint를 유발해 화면이 끊길 수 있습니다 [6, 12, 13]. 대신 레이아웃을 다시 계산하지 않는 transform과 opacity, filter 속성만 사용하여 애니메이션을 작성해야 GPU 가속(Compositing)을 통한 부드러운 렌더링이 가능해집니다 [3, 13, 14].
- 요소의 위치 및 속성 분리: 애니메이션이 들어간 요소에 position: fixed 또는 absolute를 적용하면 해당 요소가 문서의 흐름에서 분리되어 주변 요소의 레이아웃에 영향을 주지 않으므로, 비용이 큰 전체 Reflow 대신 Repaint만 발생시킬 수 있습니다 [5, 8, 15].
- 선택자 및 레이아웃 구조 단순화: 다중 경로를 요구하는 복잡한 CSS 선택자를 피하고 [9], 전체 노드의 Reflow를 자주 유발하는 테이블(table) 기반의 레이아웃을 피해야 합니다 [5, 16].

🔗 지식 연결 (Graph)

Related Topics: CSS 애니메이션 성능 최적화 (transition / keyframes), CSS 구조 설계 방식, DOM 렌더링 파이프라인
Projects/Contexts: 실무에서 CSS 관리하는 방법, 유지보수 가능하게 CSS 아키텍처 구축
Contradictions/Notes: 빈번하게 변경되는 요소에 대해 브라우저가 미리 최적화를 준비할 수 있게 하는 will-change 속성은 성능 향상에 큰 도움이 됩니다 [10, 17, 18]. 하지만 이 속성을 불필요하게 너무 많은 요소에 남용할 경우 도리어 브라우저의 리소스를 과도하게 소모시켜 성능 저하(Performance issues)를 일으킬 수 있으므로 최후의 수단으로만 신중히 사용해야 합니다 [17, 18].

Last updated: 2026-04-26

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

⚠️ 모순 및 업데이트 (Contradictions & Updates)

과거 데이터와의 충돌: 없음
정책 변화: 없음

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

5.9 KiB Raw Blame History