feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
id: wiki-2026-0508-component-based-architecture
|
||||
title: Component Based Architecture
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Component-Based Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
컴포넌트 기반 아키텍처(Component-Based [[Architecture]], CBA)는 소프트웨어 시스템을 모듈화되고 독립적이며 재사용 가능한 단위인 '컴포넌트(Component)'로 나누어 구축하는 설계 방법론입니다 [1, 2]. 레고 블록을 조립하듯 각 컴포넌트를 결합하여 크고 복잡한 애플리케이션을 완성할 수 있으며, 이로 인해 개발 속도와 시스템 확장성을 크게 향상시킵니다 [3, 4]. 각 컴포넌트는 내부 로직과 상태를 캡슐화하고 명확히 정의된 인터페이스를 통해서만 상호작용하도록 설계되어, 유지보수성과 팀 간의 협업 효율을 극대화합니다 [5, 6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **핵심 원칙 및 특징:**
|
||||
- **모듈성 및 캡슐화 ([[Modularity]] & Encapsulation):** 컴포넌트는 특정한 목적을 위해 기능과 데이터를 내부로 숨기고(캡슐화), 외부에 필요한 부분만 잘 정의된 인터페이스로 노출합니다 [5, 7].
|
||||
- **재사용성 및 독립성 (Reusability & Independence):** 한 번 개발된 컴포넌트는 수정 없이 여러 프로젝트에 재사용될 수 있으며, 전체 시스템을 파괴하지 않고 독립적으로 개발, 테스트, 배포 및 교체가 가능합니다 [8-10].
|
||||
- **상호운용성 ([[Inter[[Opera]]bility]]):** 서로 다른 기술이나 플랫폼으로 구축된 컴포넌트라도 표준화된 인터페이스와 API를 통해 원활하게 통신하고 결합될 수 있습니다 [6, 11].
|
||||
|
||||
- **아키텍처의 주요 이점:**
|
||||
- **개발 속도 향상 및 비용 절감:** 기존 컴포넌트를 재사용하여 코드를 처음부터 다시 작성하는 수고를 덜어 제품 출시 기간(Time-to-Market)을 앞당깁니다 [12, 13].
|
||||
- **확장성 및 유지보수 용이성:** 전체 시스템을 재구성할 필요 없이 트래픽이나 요구사항에 따라 특정 컴포넌트만 독립적으로 확장하거나 업그레이드할 수 있으며, 버그 수정 시 다른 시스템에 미치는 영향을 최소화합니다 [8, 14-16].
|
||||
- **병렬 개발 (Parallel Development):** 시스템이 명확하게 나뉘어 있어 여러 개발 팀이 동시에 각기 다른 컴포넌트를 분담하여 작업할 수 있습니다 [8, 17].
|
||||
|
||||
- **설계 시 당면 과제 및 단점:**
|
||||
- **복잡성 및 의존성 관리:** 컴포넌트의 수가 증가할수록 컴포넌트 간의 상호작용, 호환성, 버전 관리 등 의존성을 통제하고 통합하는 것이 복잡해집니다 [18-20].
|
||||
- **성능 오버헤드:** 시스템을 지나치게 작은 컴포넌트로 나눌 경우(Over-engineering), 컴포넌트 간 통신(네트워크 호출 및 RPC 등)으로 인한 지연(Latency)과 오버헤드가 발생하여 성능을 저하시킬 수 있습니다 [18, 21, 22].
|
||||
- **보안 관리의 어려움:** 각 컴포넌트가 각기 다른 라이브러리와 업데이트 주기를 가질 경우, 제때 업데이트되지 않은 구식 컴포넌트가 전체 애플리케이션의 보안 취약점이 될 위험이 존재합니다 [23].
|
||||
|
||||
- **실제 활용 및 대안 아키텍처:**
|
||||
- **활용 사례:** 사용자 로그인, 결제 게이트웨이, 쇼핑카트와 같은 모듈이 독립적으로 필요한 전자상거래 플랫폼, CRM 시스템, 모바일 앱 등에서 활발히 사용됩니다 [24, 25]. 프론트엔드 라이브러리(React, Angular, Vue.js)뿐만 아니라 백엔드 플랫폼(Java EE, .NET 등)에서도 이 방식을 채택하며, PayPal, Walmart, Spotify, Uber 등의 기업들이 이 아키텍처를 도입해 확장성을 입증했습니다 [3, 26, 27].
|
||||
- **대안 아키텍처:** 프로젝트의 규모와 팀 구조에 따라 하나의 코드베이스로 구성된 Monolithic Architecture, 서비스 단위로 결합도를 낮춘 Microservices Architecture, 기업 환경에 맞춘 Service-Oriented Architecture (SOA), Layered Architecture 등과 비교되거나 혼합되어 사용됩니다 [28-31].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Modularity]], Encapsulation, Monolithic Architecture, Microservices Architecture, Service-Oriented Architecture (SOA)
|
||||
- **Projects/Contexts:** React, Angular, Vue.js 기반 프론트엔드 UI 구축, 전자상거래 플랫폼 및 CRM 시스템 설계, Java EE 및 .NET 엔터프라이즈 애플리케이션
|
||||
- **Contradictions/Notes:** 컴포넌트 기반 아키텍처는 유연성과 재사용성을 극대화하지만, 모듈화를 극대화하려는 목적으로 시스템을 너무 잘게 쪼개는 것(Over-engineering)은 오히려 통합 비용과 통신 오버헤드를 발생시키고 디버깅을 어렵게 만들 수 있으므로 적절한 세분화(Granularity) 수준을 결정하는 것이 핵심입니다 [18, 22, 32].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
id: wiki-2026-0508-compound-components
|
||||
title: Compound Components
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Compound Components]]
|
||||
|
||||
## 📌[[ brief]] 단기 요약
|
||||
합성 컴포넌트(Compound Components)는 여러 개의 연관된 하위 컴포넌트들이 암시적으로 상태를 공유하며 하나의 응집력 있는 단위로 동작하도록 설계하는 React 컴포넌트 패턴입니다 [1, 2]. 단일 컴포넌트에 수십 개의 Prop을 밀어 넣어 비대해지는 것을 방지하고, 기능과 책임을 여러 컴포넌트에 분산시킵니다 [3, 4]. 이는 HTML의 `<select>`와 `<option>` 태그처럼 직관적이고 선언적인 API를 형성하여 뛰어난 유연성과 재사용성을 제공합니다 [1, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **설계 철학 및 멘탈 모델의 전환**
|
||||
* 기존의 Prop 기반(Prop-Driven) API는 요구사항(레이아웃 변경, 조건부 동작 등)이 추가될 때마다 Prop이 폭발적으로 증가하여 유지보수가 어렵고 컴포넌트 내부가 파악하기 힘든 '블랙박스'가 되는 문제가 있습니다 [5-7].
|
||||
* 합성 컴포넌트는 이를 '구성 중심(Composition-Driven)' 모델로 전환하여, 컴포넌트는 상태와 규칙만 관리하고 레이아웃과 구조의 결정권은 이를 사용하는 소비자(Consumer)에게 일임합니다 [7, 8].
|
||||
|
||||
* **[[React Context]]를 활용한 암시적 상태 공유**
|
||||
* 이 패턴의 핵심 기술은 React Context를 내부 상태 관리의 '계약(Contract)'으로 사용하는 것입니다 [9]. 부모(Root) 컴포넌트가 Context를 통해 상태를 제공하고, 하위 컴포넌트들은 [[Prop Drilling]] 없이 필요한 상태만 구독하여 동작합니다 [1, 10].
|
||||
* 내부 구현이 추상화되어 있으므로, 소비자는 내부가 어떻게 작동하는지 몰라도 하위 컴포넌트들을 자유롭게 조립할 수 있습니다 [9].
|
||||
|
||||
* **주요 장점**
|
||||
* **뛰어난 유연성과 가독성:** 특정 기능을 쉽게 포함하거나 제외할 수 있으며, 개발자는 하위 요소의 렌더링 순서와 구조를 자유롭게 재배치할 수 있습니다 [4, 7, 8].
|
||||
* **접근성(A11y) 자동화:** 컴포넌트 내부 Context에서 상태와 ID를 제어하므로, `aria-controls`나 `aria-labelledby` 같은 접근성 속성을 소비자가 수동으로 연결할 필요 없이 자동으로 처리할 수 있습니다 [11].
|
||||
|
||||
* **성능 최적화 기법**
|
||||
* 복잡한 시스템이나 대규모 렌더링이 필요한 경우, 불필요한 리렌더링을 방지하기 위해 빈번하게 변경되는 상태와 정적인 구성을 각각 다른 Context로 분리(Split Contexts)하여 최적화할 수 있습니다 [12, 13].
|
||||
* 필요한 곳에만 하위 컴포넌트를 전략적으로 메모이제이션(Memoization)하여 성능을 유지합니다 [14].
|
||||
|
||||
* **사용 시 주의사항 및 한계**
|
||||
* 패턴을 구현하기 위해 초기에 작성해야 할 코드가 많아지고, Context 기반 렌더링 비용이 발생하며, 디버깅이 다소 까다로워질 수 있습니다 [11].
|
||||
* 버튼, 배지, 아바타, 아이콘처럼 구조가 단일하고 레이아웃이 고정된 컴포넌트에는 불필요한 추상화(Overusing)가 될 수 있으므로 피해야 합니다 [15, 16]. 탭, 아코디언, 모달, 드롭다운과 같이 레이아웃과 조립 방식이 다양한 복잡한 UI에 가장 적합합니다 [17-19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Render Props]], [[Headless Components]], [[Context API]], [[Atomic Design]]
|
||||
- **Projects/Contexts:** [[Radix UI]], [[Headless UI]], [[MUI]]
|
||||
- **Contradictions/Notes:** 합성 컴포넌트는 매우 유연하고 강력한 패턴이지만, 하위 컴포넌트의 구성을 소비자가 자유롭게 바꿀 수 있기 때문에 의도치 않게 접근성이나 일관된 UX를 해칠 수 있습니다. 따라서 디자인 시스템에서는 안전한 조합의 경계(Safe composition [[Boundaries]])를 정의하고 문서화하는 것이 필수적입니다 [15, 17]. 또한 단순하고 고정된 레이아웃을 가진 컴포넌트에서는 일반적인 Prop 기반 접근법이 훨씬 간단하고 안전합니다 [16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
id: wiki-2026-0508-concurrent-rendering
|
||||
title: Concurrent Rendering
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Concurrent Rendering]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Concurrent Rendering(동시성 렌더링)은 메인 스레드를 블로킹하지 않고 UI의 여러 부분을 병렬로 렌더링할 수 있게 해주는 React의 핵심 아키텍처 기능입니다 [1]. 렌더링 작업을 '[[Time Slicing]](시간 분할)'을 통해 작은 단위로 쪼개고 중요도에 따라 우선순위를 부여하여, 긴급한 사용자 입력에 반응하기 위해 렌더링을 일시 중지하거나 재개할 수 있습니다 [1, 2]. 이를 통해 무거운 연산 중에도 UI가 멈추지 않고 즉각적으로 반응하도록 하여 애플리케이션의 체감 성능을 극대화합니다 [3, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Fiber 아키텍처와 Work Loop**
|
||||
Concurrent Rendering은 React 16에서 처음 도입된 Fiber 아키텍처를 기반으로 작동합니다 [5, 6]. 기존의 단일 재귀 호출 기반 동기식 렌더링과 달리, 렌더링 작업을 'Fiber 노드'라는 작은 작업 단위(Unit of Work)로 분할합니다 [2, 7]. React는 Work Loop를 통해 이 트리를 점진적으로 순회하며, 각 작업 단위가 끝날 때마다 브라우저에 제어권을 양보(yield)하여 클릭과 같은 고우선순위 상호작용을 처리할 수 있는지 확인합니다 [8, 9].
|
||||
* **우선순위 기반 스케줄링 ([[Lane Model]])**
|
||||
동시성 작업의 우선순위는 'Lane'이라는 비트마스크 시스템을 통해 체계적으로 관리됩니다 [10, 11]. 타이핑이나 클릭처럼 사용자가 즉각적인 반응을 기대하는 긴급한 업데이트(Sync Lane)는 최우선으로 즉시 처리되며, 스크롤(InputContinuous Lane), 네트워크 응답(Default Lane), 백그라운드 렌더링(Idle Lane) 등은 각각 낮은 우선순위를 부여받아 스케줄링됩니다 [12-14]. 이 과정에서 렌더링 단계(Render phase)는 중단 가능(Interruptible)하므로, 더 높은 우선순위의 작업이 도착하면 기존의 렌더링 작업을 일시 중지, 폐기 또는 재시작할 수 있습니다 [15, 16].
|
||||
* **Concurrent Hooks 활용 (`[[useTransition]]`, `[[useDeferredValue]]`)**
|
||||
[[React 18]] 및 19에서는 개발자가 동시성 렌더링을 직접 제어할 수 있는 훅을 제공합니다 [17, 18]. **`useTransition`**은 개발자가 상태 업데이트를 직접 긴급하지 않은 것(low-priority)으로 지정하여, 수천 개의 데이터 필터링 연산이 백그라운드에서 도는 중에도 사용자의 타이핑 입력이 즉시 반영되도록 돕습니다 [17, 19, 20]. **`useDeferredValue`**는 외부에서 전달받는 값 자체의 렌더링을 지연시켜, 새로운 결과가 준비될 때까지 UI가 동결되는 것을 막고 이전 결과를 표시하게 해줍니다 [19, 21].
|
||||
* **성능 최적화 메커니즘 (체감 성능 향상)**
|
||||
Concurrent Rendering의 핵심은 코드의 실제 연산 속도를 물리적으로 가속하는 것이 아닙니다 [3]. 무거운 연산이 즉각적인 사용자 피드백을 방해하지 않도록 처리 순서를 최적화하여 앱이 **"더 빠르게 느껴지게(feel faster)"** 만드는 데 목적이 있습니다 [3]. 이러한 비차단형(Non-[[Blocking]]) 렌더링 방식은 사용자의 입력이 다음 화면 페인트로 이어지는 속도를 측정하는 핵심 웹 지표인 **INP(Interaction to Next Paint)**를 향상시키는 데 직접적으로 기여합니다 [21, 22].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** `[[Fiber Architecture]]`, `[[Time Slicing]]`, `[[Lane Model]]`, `[[useTransition]]`, `[[useDeferredValue]]`
|
||||
- **Projects/Contexts:** `[[React 18 & 19 Performance Optimization]]`
|
||||
- **Contradictions/Notes:** 소스에 따르면 `useTransition` 및 `useDeferredValue`와 같은 동시성 훅은 코드 자체의 속도를 높여주지는 않지만, 무거운 연산이 사용자 피드백을 방해하지 않도록 스케줄링하여 앱의 "체감 성능"을 개선하는 방식으로 작동한다는 점을 명확히 하고 있습니다 [3].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
id: wiki-2026-0508-container-queries
|
||||
title: Container Queries
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Container Queries]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Container Queries(컨테이너 쿼리)는 브라우저 창(뷰포트) 전체 크기가 아닌, 컴포넌트가 속한 부모 컨테이너의 가용 너비에 따라 요소의 스타일을 유동적으로 조정할 수 있게 해주는 최신 CSS 기능입니다 [1, 2]. 이는 기존 미디어 쿼리의 한계를 극복하여 페이지 중심에서 컴포넌트 중심의 반응형 설계로 패러다임을 전환시켰습니다 [1, 3]. 디자인 시스템 및 모듈식 아키텍처와 완벽하게 결합하여, 다양한 문맥(Context)에서 독립적으로 재사용할 수 있는 유지보수성 높은 UI를 구축하는 데 핵심적인 역할을 합니다 [1, 4, 5].
|
||||
|
||||
## 📖 Core 소스 Content
|
||||
- **기존 미디어 쿼리의 한계와 도입 배경:**
|
||||
기존의 뷰포트 기반 미디어 쿼리(Media Queries)는 브라우저 창의 크기에만 반응하는 근본적인 한계가 있었습니다 [1]. 이로 인해 좁은 사이드바에 위치한 카드와 전체 너비의 히어로 섹션에 위치한 카드가 동일한 뷰포트 너비 기준을 공유하여 스타일링에 어려움이 있었습니다 [1, 5]. 컨테이너 쿼리는 컴포넌트가 부모 요소의 크기를 기준으로 스스로 프레젠테이션을 결정하게 하여 이러한 문제를 해결합니다 [1, 6].
|
||||
|
||||
- **구현 방식 및 문법:**
|
||||
컨테이너 쿼리를 사용하려면 먼저 부모 요소에 `container-type: inline-size;` 속성을 정의하여 컨테이너로 지정해야 합니다 [4, 5]. 그 후 `@container (min-width: 600px)`와 같은 조건문을 사용하여 해당 컨테이너 크기에 도달했을 때 자식 요소(예: 카드 레이아웃의 컬럼 변경)의 스타일을 변경합니다 [1, 2, 4]. 또한, `cqi`나 `cqw`와 같은 컨테이너 인라인 크기 기준의 상대 단위를 사용하여 타이포그래피나 여백을 유동적으로 제어할 수 있습니다 [7-9].
|
||||
|
||||
- **설계 패러다임의 변화:**
|
||||
컨테이너 쿼리의 도입으로 반응형 디자인의 철학이 '뷰포트 중심(Viewport-centric)'에서 '컴포넌트 중심(Component-centric)'으로 이동했습니다 [3]. 이 접근 방식은 컴포넌트가 독립적이고 문맥을 인식(context-aware)할 수 있게 만들어 주어, 복잡한 대규모 애플리케이션의 여러 부분에서 컴포넌트를 재사용할 때의 복원력(resilient)을 높여줍니다 [1, 5]. 이는 독립적인 UI 단위로 구성되는 최신 디자인 시스템의 구조와 완벽하게 일치합니다 [1, 5].
|
||||
|
||||
- **실무 활용과 업계 표준:**
|
||||
2024년 이후 모든 최신 브라우저에서 완벽히 지원되며, 2026년 기준으로는 고급 기술을 넘어 컴포넌트 수준의 반응형 디자인을 위한 기본 표준(Default practice)으로 자리 잡았습니다 [10, 11]. 특히 데이터가 많은 [[SaaS]] 대시보드나 이커머스에서 좁은 너비일 때 차트를 단순한 숫자 카드로 변환하거나, 데이터 테이블을 카드 스택으로 바꾸는 등의 복잡한 레이아웃 처리에 탁월하게 활용됩니다 [4, 12].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Responsive Web Design]], Media Queries, [[Design[[ system]]s]], [[Fluid Typography]]
|
||||
- **Projects/Contexts:** SaaS 대시보드 레이아웃 설계, [[컴포넌트 기반 아키텍처([[Component-Based Architecture]])]]
|
||||
- **Contradictions/Notes:** 소스에서는 컨테이너 쿼리를 뷰포트 기반 미디어 쿼리의 한계를 극복하는 필수적인 대체재 및 보완재로 설명하며, 모듈식 설계와 유지보수성 측면에서 2026년 기준 반응형 CSS 설계의 가장 중요한 표준으로 강조하고 있습니다 [1, 3, 11].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
---
|
||||
id: wiki-2026-0508-critical-rendering-path
|
||||
title: Critical Rendering Path
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Critical Rendering Path]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Critical Rendering Path (CRP)]]는 브라우저가 HTML, CSS, [[JavaScript]]를 수신하여 화면의 픽셀로 변환하기 위해 거치는 일련의 단계적 과정을 의미합니다[1]. 이 과정은 DOM 트리 및 [[CSSOM]] 트리 구축, [[Render Tree]] 합성, Layout(Reflow), 그리고 Paint(Repaint) 및 Compositing 단계로 진행됩니다[1, 2]. CRP를 이해하고 최적화하는 것은 렌더링 차단 요소를 줄이고 불필요한 Reflow 및 Repaint를 최소화하여 빠른 초기 렌더링과 매끄러운 사용자 상호작용을 보장하는 프론트엔드 성능 엔지니어링의 핵심입니다[3, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **[[DOM (Document Object Model)]] 구축:** 브라우저는 서버로부터 HTML 데이터를 점진적으로 파싱하여 DOM 트리를 구축합니다[2, 5]. 수신된 바이트는 토큰 및 노드로 변환되어 계층 구조를 형성하며, 노드의 수가 많을수록 이후 렌더링 경로의 연산 시간이 길어집니다[2, 5, 6].
|
||||
* **CSSOM (CSS Object Model) 구축:** DOM과 달리 CSSOM 구축은 점진적으로 이루어지지 않으며, 파싱이 완료될 때까지 렌더링을 차단(Render-[[Blocking]])합니다[6-8]. 이는 스타일이 뒤늦게 덮어씌워지면서 스타일이 적용되지 않은 콘텐츠가 화면에 번쩍이는 현상(FOUC)을 방지하기 위함입니다[6, 7].
|
||||
* **Render Tree 합성:** DOM과 CSSOM이 완성되면, 브라우저는 이 둘을 결합해 화면에 실제로 그려지는 가시적 노드(Visible nodes)만 포함하는 Render Tree를 만듭니다[9-11]. `<script>`, `<meta>` 요소나 `display: none` 스타일이 적용된 노드는 렌더 트리에서 완전히 제외되지만, 레이아웃 공간을 차지하는 `visibility: hidden` 요소는 포함됩니다[9-12].
|
||||
* **Layout (Reflow):** Render Tree를 기반으로 뷰포트 크기와 박스 모델에 맞춰 각 요소의 정확한 기하학적 위치와 크기를 계산하는 단계입니다[13-15]. 창 크기가 변하거나, DOM 요소의 추가/제거, 혹은 너비나 여백 등 레이아웃에 영향을 주는 속성이 변경될 경우 Reflow가 발생하며 이는 매우 큰 연산 비용을 수반합니다[16-19].
|
||||
* **Paint (Repaint) 및 Compositing:** Layout 계산이 끝나면 각 요소를 픽셀로 화면에 그리는 Paint(또는 Rasterizing) 과정이 진행됩니다[20-23]. 레이아웃 변화 없이 배경색 등 시각적 속성만 변할 때는 Repaint만 촉발됩니다[18, 20, 24]. 이후 서로 다른 레이어들을 하나의 화면으로 합치는 Compositing 단계를 거치며, 특정 효과(예: transform)는 GPU로 오프로드하여 성능을 최적화할 수 있습니다[20, 25].
|
||||
* **React 도입과의 연관성:** 전통적으로 브라우저의 DOM을 직접 조작하는 것은 필연적으로 비용이 큰 Reflow와 Repaint 과정을 연쇄적으로 유발하여 속도 저하를 일으킵니다[26]. React는 이 한계를 극복하기 위해 메모리에 경량화된 [[Virtual DOM]]을 구축하고, 상태 변경 시 휴리스틱 Diffing 알고리즘([[Reconciliation]])을 통해 변경된 최소한의 노드만 실제 DOM에 반영하여 렌더링 경로의 비효율을 크게 줄입니다[3, 26, 27].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[브라우저 렌더링 과정 (HTML → CSSOM → Render Tree)]], Reflow / Repaint 최소화 방법, [[DOM vs Virtual DOM]]
|
||||
- **Projects/Contexts:** [[렌더링 최적화 개념 설명 자료]], [[“React가 빠른 이유”]]
|
||||
- **Contradictions/Notes:** CSS 선택자(Selector)의 복잡도는 파싱 속도에 영향을 주지만, 최신 브라우저 엔진은 매우 빠르기 때문에 선택자 구체성을 최적화해서 얻는 성능적 이득은 마이크로초 단위에 불과합니다. 따라서 실질적인 최적화를 위해서는 선택자 구조 개선보다는 불필요한 렌더링 차단 리소스 크기를 줄이거나 로딩 순서를 제어하는 것이 성능 개선(CRP 최적화)에 훨씬 효과적입니다[28, 29].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
---
|
||||
id: wiki-2026-0508-dom-document-object-model
|
||||
title: DOM (Document Object Model)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[DOM (Document Object Model)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[DOM(Document Object Model)]]은 브라우저가 수신한 HTML 문서 데이터를 파싱하여 생성하는 페이지 구조의 계층적 트리 표현입니다 [1-3]. 브라우저는 HTML 태그의 포함 관계를 바탕으로 부모 및 자식 노드의 트리를 형성하며, `<html>` 요소를 루트 노드로 갖습니다 [4, 5]. DOM은 페이지의 모든 콘텐츠 정보를 담고 있으며, 스타일 정보를 담은 [[CSSOM]]과 결합해 최종 화면 출력에 필요한 렌더 트리([[Render Tree]])를 형성하는 브라우저 렌더링 과정의 핵심 기반입니다 [6-8].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **DOM 트리의 점진적 구축 (Incremental Construction)**
|
||||
브라우저는 네트워크를 통해 HTML 문서의 전체 데이터를 다 받기 전부터 점진적으로 DOM 트리를 구축할 수 있습니다 [1, 4]. 초기 14KB의 데이터 패킷이 수신되면 바이트를 문자로, 문자를 토큰(startTag 및 endTag 등)으로 변환한 뒤, 최종적으로 노드(Node)로 변환하여 트리를 조립합니다 [1, 4]. 이 점진적 생성 메커니즘 덕분에 네트워크 요청이 진행 중인 상태에서도 브라우저는 렌더링 준비를 시작할 수 있습니다 [9].
|
||||
|
||||
* **렌더링 파이프라인에서의 DOM과 CSSOM**
|
||||
DOM은 문서의 '콘텐츠'를 표현하는 반면, CSSOM은 해당 콘텐츠의 '스타일'을 정의하는 독립적인 트리 구조입니다 [9, 10]. 이 두 모델은 브라우저에 의해 결합되어 화면에 시각적으로 출력되어야 하는 노드만을 포함하는 '렌더 트리(Render Tree)'로 합성됩니다 [6, 11, 12]. 이 과정에서 `<script>`, `<meta>` 또는 `display: none`이 적용된 요소처럼 시각적 영향을 주지 않는 DOM 노드는 렌더 트리에서 제외됩니다 [8, 11-13].
|
||||
|
||||
* **크기와 복잡성이 성능에 미치는 영향**
|
||||
DOM 트리의 깊이와 생성된 노드의 개수는 웹 성능과 직결됩니다 [5, 9]. 노드의 수가 많아질수록 렌더 트리 합성, 레이아웃(Reflow), 페인트 단계에서 브라우저가 처리해야 할 계산의 양과 시간이 증가하여 애플리케이션의 성능이 저하될 수 있습니다 [5, 7, 9, 14]. 불필요한 래퍼를 줄이고 React Fragment 등을 사용하여 DOM 노드 수를 최소화하는 것이 성능 향상에 도움이 됩니다 [15].
|
||||
|
||||
* **DOM 조작의 비효율성과 최적화**
|
||||
[[JavaScript]]를 사용해 DOM을 직접 조작하고 크기나 위치 등을 변경하면, 브라우저는 문서 전체의 레이아웃(Reflow)과 페인트(Repaint) 과정을 다시 실행해야 하므로 처리 비용이 매우 높습니다 [16-18]. 이를 최적화하기 위해서는 사용된 DOM 노드나 속성값을 캐싱하고, DOM의 읽기 및 쓰기 작업을 분리하여 레이아웃 스래싱([[Layout Thrashing]])을 방지해야 합니다 [16, 19, 20]. React와 같은 프레임워크는 실제 DOM을 직접 수정하는 비효율성을 피하고자 메모리 내에 가벼운 사본인 가상 DOM([[Virtual DOM]])을 생성하여 조작을 추상화합니다 [17, 21, 22].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** CSSOM (CSS Object Model), [[Render Tree]], [[Virtual DOM]], [[Critical Rendering Path (CRP)]], Reflow (Layout), Repaint
|
||||
- **Projects/Contexts:** 프론트엔드 성능 최적화(DOM 접근 최소화 및 렌더링 파이프라인 관리), React의 렌더링 엔진 구조 및 재조정([[Reconciliation]]) 과정 이해 [6, 17, 23, 24].
|
||||
- **Contradictions/Notes:** DOM 구축은 HTML을 파싱하면서 '점진적(incremental)'으로 이루어지지만, CSSOM 구축은 렌더링을 차단(render-[[Blocking]])하며 점진적으로 처리되지 않는다는 구조적 차이가 있습니다 [1, 7, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+99
@@ -0,0 +1,99 @@
|
||||
---
|
||||
id: wiki-2026-0508-dom-document-object-model
|
||||
title: DOM(Document Object Model)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[DOM(Document Object Model)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
DOM(Document Object Model)은 브라우저가 HTML 마크업을 내부적으로 표현하기 위해 생성하는 계층적인 트리 구조의 객체 모델입니다 [1, 2]. 브라우저가 HTML 데이터를 수신하면서 점진적으로 생성하며, 웹 페이지의 모든 콘텐츠와 요소 간의 구조적 관계를 담고 있습니다 [1, 3, 4]. 자바스크립트([[JavaScript]]) 내의 다양한 API를 통해 DOM에 접근하고 이를 동적으로 조작할 수 있습니다 [2].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **DOM 생성 과정 (DOM Construction Process)**
|
||||
브라우저는 서버로부터 HTML 문서를 수신하면 즉시 파싱(Parsing)을 시작합니다 [5]. 이 과정은 전체 문서가 도착하기를 기다리지 않고 점진적(incremental)으로 이루어집니다 [1]. 수신된 데이터(바이트)는 문자로 변환되고, 이후 토큰(tokens)으로 변환된 다음 최종적으로 노드(nodes)로 변환되어 계층적인 DOM 트리를 형성합니다 [1, 6]. 시작 태그(startTag)와 종료 태그(endTag) 사이에 다른 태그들이 포함되는 방식으로 노드 간의 계층 구조가 정의됩니다 [6].
|
||||
|
||||
- **트리 구조와 구성 (Tree Structure and Composition)**
|
||||
DOM 트리는 문서의 콘텐츠를 묘사하며, `<html>` 요소가 트리 구조의 첫 번째 요소이자 루트(root) 노드가 됩니다 [4]. 다른 요소 안에 중첩된 요소들은 자식 노드(child nodes)가 되어 트리 내부에서 각 요소의 관계와 계층을 반영합니다 [4]. 생성된 DOM 트리는 이후 스타일 정보를 담고 있는 [[CSSOM(CSS Object Model)]]과 결합하여 화면에 그려질 요소를 결정하는 렌더 트리([[Render Tree]])를 구축하는 데 사용됩니다 [7, 8].
|
||||
|
||||
- **성능에 미치는 영향 (Performance Implications)**
|
||||
DOM 트리의 깊이와 복잡성은 브라우저의 성능과 직결됩니다 [9]. DOM에 존재하는 노드의 수가 많아질수록 렌더 트리 생성, 레이아웃(Layout), 페인트(Paint)와 같은 중요 렌더링 경로([[Critical Rendering Path]])의 후속 작업에 소요되는 시간과 연산 부담이 커지게 됩니다 [3, 4, 9].
|
||||
|
||||
- **직접적인 DOM 조작의 한계 (Limitations of Direct DOM Manipulation)**
|
||||
자바스크립트 등을 통해 DOM을 직접 변경하는 작업은 브라우저의 레이아웃(Reflow)과 페인트 단계를 지속적으로 트리거하기 때문에 본질적으로 속도가 느리고 비용이 많이 듭니다 [10]. 애플리케이션이 복잡해질 경우 여러 노드를 개별적으로 업데이트하면 중복 연산이 발생하며, 이는 React와 같은 프레임워크가 가상 DOM([[Virtual DOM]])을 도입하게 된 핵심 배경이 되었습니다 [10].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSSOM(CSS Object Model)]], Critical Rendering Path(CRP), [[Render Tree]], [[Virtual DOM]], Reflow / Repaint
|
||||
- **Projects/Contexts:** 브라우저 렌더링 과정 ([[Browser]] Rendering Process), 프론트엔드 성능 최적화 및 React의 Virtual DOM 도입 배경 이해 [7, 10, 11]
|
||||
- **Contradictions/Notes:** 소스 간의 모순된 정보는 없습니다. 참고로 DOM의 생성은 점진적(incremental)으로 진행되어 문서를 파싱하는 동안에도 화면을 그리기 시작할 수 있지만, [[CSSOM]]의 생성은 렌더링을 차단(render-[[Blocking]])한다는 점에서 두 모델의 구축 방식에 차이가 있습니다 [3, 9].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,96 @@
|
||||
---
|
||||
id: wiki-2026-0508-e-commerce-platforms
|
||||
title: E commerce Platforms
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[E-commerce Platforms]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
E-commerce Platforms(이커머스 플랫폼)은 제품 카탈로그, 장바구니, 결제 처리 등의 기능을 제공하여 온라인 상거래를 지원하는 시스템입니다 [1, 2]. 이 시스템의 핵심은 검색 엔진 최적화(SEO)를 통한 제품 발견, 빠른 페이지 로딩을 통한 구매 전환율 향상, 그리고 재고 및 가격 변동을 반영하는 최신 데이터의 유지입니다 [3-5]. 소스 자료에 따르면, 이커머스 플랫폼은 성능과 확장성을 극대화하기 위해 SSR(서버 사이드 렌더링), ISR(점진적 정적 재생성)과 같은 최적화된 웹 렌더링 전략과 컴포넌트 기반 아키텍처(CBA)를 적극적으로 채택합니다 [2, 6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **이커머스 플랫폼을 위한 웹 렌더링 전략 (Web Rendering Strategies):**
|
||||
* **SSR (Server-Side Rendering):** 이커머스 플랫폼의 제품 목록 페이지, 카테고리 탐색 및 개별 제품 상세 페이지에 가장 이상적인 렌더링 방식 중 하나입니다 [3]. 서버에서 제품의 세부 정보, 가격, 구매 버튼이 포함된 완전한 HTML을 즉시 제공하므로, 자바스크립트 로딩을 기다릴 필요 없이 사용자에게 콘텐츠를 보여주어 구매 전환율을 크게 향상시킵니다 [5]. 또한 훌륭한 SEO를 제공하여 제품 검색 노출에 유리하며, 항상 최신의 실시간 데이터를 요구하는 결제(Checkout) 페이지에 적합합니다 [3, 7].
|
||||
* **SSG (Static Site Generation):** 제품 라인이 변동 없이 안정적이고 콘텐츠 업데이트 주기가 규칙적인 제품 카탈로그 페이지에 적용될 수 있습니다 [8].
|
||||
* **ISR (Incremental Static Regeneration):** 이커머스 플랫폼에 최적의 균형(성능과 최신성)을 제공하는 고도화된 접근 방식입니다 [4, 6]. 대규모 제품 카탈로그를 초고속으로 로딩하는 동시에, 전체 사이트를 다시 빌드하는 오버헤드 없이 백그라운드에서 재고 정보와 가격을 주기적으로 업데이트하여 최신 상태로 유지할 수 있습니다 [4, 6, 9].
|
||||
|
||||
* **컴포넌트 기반 아키텍처 적용 ([[Component-Based Architecture]]):**
|
||||
* 이커머스 플랫폼은 제품 목록(Product listings), 결제 게이트웨이(Payment gateways), 장바구니(Shopping c[[Arts]]), 고객 리뷰 모듈 등 명확히 분리된 기능을 가진 재사용 가능한 소프트웨어 컴포넌트들의 조립으로 구축됩니다 [2].
|
||||
* 이러한 모듈식 접근 방식을 통해 비즈니스가 확장됨에 따라 새로운 결제 옵션을 추가하거나 제품 추천 기능을 갱신해야 할 때, 플랫폼 전체에 중단을 일으키지 않고 특정 컴포넌트만 쉽게 교체하거나 확장할 수 있는 유연성을 확보합니다 [2, 10].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Server-Side Rendering (SSR)]], Incremental Static Regeneration (ISR), [[Component-Based Architecture]], [[Search Engine [[Optimization]] (SEO)]]
|
||||
- **Projects/Contexts:** 대규모 트래픽을 처리하면서도 검색 엔진 노출을 극대화하고 실시간 재고/가격 변동을 반영해야 하는 프론트엔드 웹 성능 최적화 및 렌더링 아키텍처 구축 맥락 [3, 4, 7].
|
||||
- **Contradictions/Notes:** 제공된 소스는 이커머스 플랫폼의 백엔드 비즈니스 로직이나 운영 모델보다는 주로 프론트엔드의 화면 렌더링 최적화(SSR/ISR)와 아키텍처(컴포넌트화) 측면에 초점을 맞추고 있어, 결제 시스템의 내부 동작 원리 등에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+97
@@ -0,0 +1,97 @@
|
||||
---
|
||||
id: wiki-2026-0508-feature-driven-architecture
|
||||
title: Feature Driven Architecture
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Feature-Driven Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Feature-Driven [[Architecture]](또는 기능 주도 아키텍처, [[Feature-Sliced Design]])는 파일 유형이 아닌 실제 비즈니스 기능이나 도메인을 기준으로 프론트엔드 프로젝트 코드를 그룹화하는 구조 설계 방식입니다 [1-3]. 특정 기능에 필요한 UI 컴포넌트, 비즈니스 로직, 스타일(CSS)을 독립적인 기능 폴더(예: `features/`) 내에 함께 캡슐화하여 관리합니다 [4, 5]. 이를 통해 결합도를 낮추고 모듈 경계를 명확히 하여 대규모 애플리케이션에서의 유지보수성, 확장성 및 팀 간 병렬 협업을 획기적으로 개선합니다 [1, 3].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **기능 기반의 코드 분리와 캡슐화**
|
||||
초기 웹 개발이나 소규모 프로젝트에서 흔히 쓰이는 컴포넌트(components), 훅(hooks), 유틸(utils) 등 파일 유형별 폴더 그룹화 대신 비즈니스 기능이나 도메인을 기준으로 구조를 구성합니다 [3, 6]. 예를 들어, [[Next.js]] 환경에서는 라우터 기능을 담당하는 폴더(`app/`)는 라우팅과 레이아웃 용도로만 최소화하여 사용하고, 실제 비즈니스 로직과 복잡한 상태 관리는 `features/` 디렉토리(예: `market-data`, `user-profile`, `auth`) 내부로 이동시킵니다 [4, 6]. 이러한 캡슐화는 버그 발생 시 개발자가 방대한 전역 폴더를 탐색할 필요 없이 해당 기능 폴더만 확인하게 해주어 문제 해결을 직관적으로 만듭니다 [4].
|
||||
|
||||
* **유지보수성 및 확장성 향상**
|
||||
관심사의 분리([[Separation of Concerns]])를 실현하는 이 구조는 대규모 프로젝트 확장에 매우 유리합니다 [2-4]. 기능 단위로 코드가 분리되어 있어 코드 소유권이 명확해지고, 여러 팀이 병렬로 작업하기 쉬워지며 리팩토링이 안전해집니다 [3]. 또한, 네트워크 호출 등 API 연동 로직도 기능 폴더 내의 전용 서비스로 묶어 두어 프론트엔드 요소와 백엔드 API 간의 의존성을 깔끔하게 분리할 수 있습니다 [4, 6].
|
||||
|
||||
* **CSS 구조 설계와의 강력한 시너지 (스타일 모듈화)**
|
||||
기능 주도 아키텍처는 스타일 시스템의 확장성을 설계하는 데 필수적입니다 [7]. 비즈니스 관련 컴포넌트와 그에 연결된 [[CSS Modules]], [[SCSS]] 파일을 같은 기능 디렉토리 내에 함께 위치시킵니다(co-location) [5]. 이러한 모듈화는 애플리케이션에서 특정 기능을 삭제할 때 해당 기능의 스타일 코드 역시 자동으로 폐기될 수 있게 보장하여, 레거시 프로젝트에 쌓이기 쉬운 사용되지 않는 '유령 스타일(ghost styles)'이나 데드 코드의 축적을 방지합니다 [5].
|
||||
전반적인 프로젝트 구조를 Feature-Sliced Design(FSD) 같은 기능 기반으로 구성하고, 개별 CSS 구조는 BEM 같은 방법론을 통해 관리하면 기술 부채를 크게 줄일 수 있는 강력한 아키텍처가 형성됩니다 [1, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Feature-Sliced Design (FSD)]], [[CSS Modules]], [[BEM]]
|
||||
- **Projects/Contexts:** [[Next.js Modular and Scalable Project Structure]], [[Large [[Frontend]] Projects]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 애플리케이션 초기에는 파일 유형별 구성이 빠르고 편할 수 있으나, 데이터 대시보드나 복잡한 사용자 흐름을 다루게 될수록 관리 불능 상태에 빠지게 됩니다. 따라서 프로젝트 장기 스케일링을 위해 일찍부터 Feature-Driven Architecture 멘탈 모델을 채택하는 것이 거대한 리팩토링의 두통을 막는 방법으로 강력하게 권장됩니다 [2, 6, 9].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
id: wiki-2026-0508-fiber-architecture
|
||||
title: Fiber Architecture
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Fiber Architecture]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
React 16에서 도입된 Fiber [[Architecture]]는 동시성 렌더링([[Concurrent Rendering]])을 지원하기 위해 근본적으로 재작성된 React의 재조정([[Reconciliation]]) 엔진입니다 [1-3]. 기존의 동기식 렌더링이 메인 스레드를 차단하여 UI가 멈추던 문제를 해결하고자, 렌더링 작업을 '파이버(Fiber)'라는 작은 단위의 노드로 쪼개어 점진적으로 처리합니다 [4, 5]. 이를 통해 React는 렌더링을 일시 중지하거나 브라우저에 제어권을 양보하고, 우선순위가 높은 작업을 먼저 처리한 후 다시 렌더링을 재개하는 타임 슬라이싱([[Time-Slicing]]) 스케줄링을 구현할 수 있게 되었습니다 [4-6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동기식 차단(Synchronous [[Blocking]])의 한계 극복:**
|
||||
Fiber 도입 이전의 React는 '스택 재조정자(Stack Reconciler)'를 사용하여 전체 컴포넌트 트리를 단일 재귀 호출로 동기 처리했습니다 [4]. 이 방식은 대규모 애플리케이션에서 브라우저의 프레임 예산(16.6ms)을 초과할 경우 메인 스레드를 차단하여 사용자 입력이나 애니메이션을 지연시켰습니다 [4]. Fiber는 작업을 작은 단위로 나누어 브라우저가 높은 우선순위의 작업을 가로채 처리할 수 있게 함으로써 이 문제를 해결합니다 [4, 5, 7].
|
||||
* **작업 루프(Work Loop)와 두 가지 렌더링 단계:**
|
||||
Fiber의 재조정 과정은 작업 중단과 우선순위 관리를 위해 두 가지 명확한 단계로 나뉩니다 [8].
|
||||
* **렌더링 단계 (Render Phase):** 이 단계는 비동기적이며 중단할 수 있습니다 [8]. 실제 DOM을 변경하지 않고 메모리 상의 파이버 트리를 순회하면서 이전 상태와 새로운 상태의 차이를 계산하고, 변경이 필요한 파이버들의 목록(Effect list)을 구성합니다 [8, 9]. 더 높은 우선순위 작업이 들어오면 일시 중단, 폐기 또는 재시작될 수 있으므로, 이 단계에서는 사이드 이펙트가 발생해서는 안 됩니다 [8-10].
|
||||
* **커밋 단계 (Commit Phase):** 이 단계는 동기적이며 중단할 수 없습니다 [11]. 렌더링 단계에서 만들어진 변경 사항(삽입, 삭제, 업데이트)을 한 번에 실제 DOM에 적용합니다 [9, 11, 12]. 이 시점에 실제 DOM이 변형되며 각종 생명주기 메서드나 레이아웃 이펙트(`useLayoutEffect`)가 실행됩니다 [11, 12].
|
||||
* **레인(Lane) 모델을 통한 우선순위 스케줄링:**
|
||||
Fiber는 32비트 정수 비트마스크 시스템인 '레인(Lane)'을 사용하여 작업의 우선순위를 정밀하게 관리합니다 [13, 14]. 클릭이나 타이핑 등 즉각적 반응이 필요한 작업(Sync Lane), 스크롤링(InputContinuous Lane), 일반적인 상태 업데이트(Default Lane), 백그라운드 작업(Idle Lane)으로 업데이트를 분류합니다 [6, 15]. 이를 통해 사용자 상호작용과 같은 '긴급한' 업데이트가 데이터 렌더링 같은 '비긴급' UI 전환보다 먼저 처리되도록 보장합니다 [6, 16].
|
||||
* **작업 진행 상태(WIP) 트리 관리:**
|
||||
React는 현재 화면에 그려진 상태를 추적할 뿐만 아니라 작업 중인 상태를 나타내는 WIP(Work-in-progress) 트리를 별도로 관리합니다 [10]. 스케줄러의 우선순위에 따라 메인 스레드가 바쁘면 이 WIP 트리의 작업을 일시 중지하고, 브라우저가 유휴 상태일 때 다시 재개할 수 있습니다 [10].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Virtual DOM]], [[Reconciliation]], [[Concurrent Rendering]], [[Critical Rendering Path]]
|
||||
- **Projects/Contexts:** [[React 16+ Core Engine]], [[브라우저 메인 스레드 최적화 및 타임 슬라이싱]]
|
||||
- **Contradictions/Notes:** Fiber의 동시성 렌더링 기능(예: `[[useTransition]]`, `[[useDeferredValue]]`)은 코드의 물리적인 실행 속도를 높이는 것은 아닙니다 [17]. 무거운 연산으로 인한 병목이 즉각적인 사용자 상호작용을 방해하지 않도록 뒤로 미룸(Deferring)으로써, 체감 성능(Perceived Performance) 측면에서 애플리케이션이 훨씬 "더 빠르게 느껴지도록" 만드는 것이 핵심입니다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
id: wiki-2026-0508-fluid-typography
|
||||
title: Fluid Typography
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Fluid Typography]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Fluid Typography(유동적 타이포그래피)는 고정된 미디어 쿼리 중단점(breakpoint)에서 폰트 크기가 갑자기 변하는 대신, 뷰포트나 컨테이너의 크기에 비례하여 폰트 크기가 매끄럽고 연속적으로 변하도록 만드는 반응형 웹 디자인 기법입니다 [1, 2]. 최신 CSS에서는 `clamp()` 함수와 상대 단위(`vw`, `rem` 등)를 조합하여 사용하며, 기기마다 다른 화면 크기에 맞춰 최적의 가독성을 제공합니다 [1, 3]. 수동으로 여러 개의 중단점을 계산하거나 지정할 필요가 없다는 것이 가장 큰 장점입니다 [4].
|
||||
|
||||
## 📖 Core 기Content
|
||||
* **작동 원리와 필요성:**
|
||||
기존의 하드 브레이크포인트(hard breakpoint) 기반 타이포그래피는 화면 크기가 변경될 때 폰트 크기가 갑작스럽게 도약(jarring jumps)하는 문제를 발생시킵니다 [1]. 반면 Fluid Typography는 `vw`, `vi`, `cqi`와 같은 뷰포트 및 컨테이너 단위를 활용하여 지정된 범위 내에서 일정한 비율로 폰트 크기를 보간(interpolate)하여 부드러운 전환을 만들어냅니다 [2, 4]. 이를 통해 스마트폰에서는 너무 작지 않고, 데스크톱에서는 너무 크지 않은 균형 잡힌 텍스트 크기를 유지할 수 있습니다 [3].
|
||||
* **핵심 구현 방법 (`clamp()` 함수):**
|
||||
가장 현대적이고 권장되는 구현 방식은 CSS의 `clamp(min, preferred, max)` 함수를 사용하는 것입니다 [1, 5, 6]. 이 함수는 최소 폰트 크기(floor), 뷰포트 기반의 선호 크기(scaling value), 그리고 최대 폰트 크기(ceiling)를 설정하여 브라우저가 공간에 맞춰 자동으로 크기를 계산하게 합니다 [1, 3]. 예를 들어 `font-size: clamp(1.5rem, 2vw + 1rem, 3rem);`와 같이 작성하면, 아무리 화면이 작거나 커져도 폰트가 지정된 최소/최대 범위를 벗어나지 않습니다 [1, 3, 7].
|
||||
* **접근성([[Accessibility]])을 위한 주의사항:**
|
||||
폰트 크기를 `1vw`나 `100vw`와 같은 순수 뷰포트/컨테이너 단위로만 설정하는 것은 사용자에게 매우 적대적인(hostile) 방식입니다 [8]. 브라우저 창을 줄이는 것과 돋보기(zoom) 기능을 사용하는 것은 사용자 의도가 다름에도 불구하고 CSS 뷰포트 단위에서는 동일하게 계산되어, 사용자가 브라우저 설정을 통해 화면을 확대하더라도 폰트 크기가 커지지 않게 됩니다 [9, 10]. 이는 "보조 기술 없이 텍스트를 200%까지 확대할 수 있어야 한다"는 웹 콘텐츠 접근성 지침(WCAG 1.4.4)을 직접적으로 위반합니다 [8].
|
||||
* **안전한 Fluid Typography 설계 (Best Practices):**
|
||||
사용자의 기본 폰트 설정과 브라우저 확대/축소 기능을 존중하기 위해, 뷰포트 단위와 사용자의 선호 단위(`rem`, `em`)를 `calc()` 함수로 결합해야 합니다(예: `calc(16px + 1vw)`) [11]. 또한 `clamp()`를 사용할 때 최소값과 최대값을 모두 `em` 또는 `rem` 단위로 지정하고, 최대 폰트 크기가 최소 폰트 크기의 2.5배를 초과하지 않도록 설정해야 WCAG SC 1.4.4 기준(200% 확대 보장)을 안전하게 통과할 수 있습니다 [12, 13].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Responsive Web Design]], [[CSS Media Queries]], [[Container Queries]], [[Web Content Accessibility Guidelines (WCAG)]]
|
||||
- **Projects/Contexts:** [[모바일 퍼스트 및 다양한 디바이스 환경을 위한 반응형 레이아웃 구축]], [[디자인 시스템의 타이포그래피 토큰 확장 및 최적화]]
|
||||
- **Contradictions/Notes:** 뷰포트 단위(`vw` 등)는 화면 크기에 반응하여 유동성을 주지만, 단독으로 사용할 경우 사용자의 브라우저 확대(Zoom) 및 기본 폰트 설정을 무시하게 되어 접근성(WCAG)을 심각하게 훼손한다는 점에 주의해야 합니다. 따라서 반드시 `clamp()` 및 `rem`/`em` 단위와 혼합하여 사용해야 합니다 [8, 13].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
---
|
||||
id: wiki-2026-0508-large-frontend-projects
|
||||
title: Large Frontend Projects
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Large [[Frontend]] Projects]]
|
||||
|
||||
## 📌[[ brief]] 대요
|
||||
대규모 프론트엔드 프로젝트(Large Frontend Projects)란 수백 개의 컴포넌트, 동적인 상태 관리, 재사용 가능한 디자인 시스템을 포함하며 다수의 개발 팀이 동시에 참여하는 복잡한 규모의 애플리케이션을 의미합니다 [1]. 이러한 프로젝트에서는 UI를 단순히 "예쁘게" 렌더링하는 것을 넘어, 다수 개발자의 협업과 지속적인 반복 작업, 기술 부채의 축적을 견뎌낼 수 있는 견고한 아키텍처적 무결성과 유지보수성이 핵심 목표가 됩니다 [2]. 따라서 전역 네임스페이스 충돌이나 '스파게티 스타일(spaghetti styles)'과 같은 CSS 비대화(CSS bloat) 현상을 방지하기 위해 BEM, [[CSS Modules]], [[Tailwind CSS]] 등과 같은 체계적인 CSS 아키텍처와 명확한 폴더 구조 설계가 필수적입니다 [1-4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **대규모 프로젝트에서의 CSS 엔지니어링 문제**
|
||||
대규모 시스템에서는 CSS가 전역적으로 적용된다는 특성 때문에 예기치 않은 스타일 덮어쓰기(Overrides), 선택자 특이성(Specificity) 충돌, 중복 스타일, 그리고 새로운 개발자의 온보딩 지연 등의 문제가 발생합니다 [1, 5]. 이는 개발 생산성과 장기적인 확장성에 직접적인 악영향을 미치므로, CSS를 단순한 데코레이션 레이어가 아닌 엄격한 엔지니어링 규율로 접근해야 합니다 [2, 5].
|
||||
|
||||
* **확장 가능한 폴더 구조 및 아키텍처 ([[Feature-Sliced Design]])**
|
||||
대규모 프로젝트가 통제 불능 상태가 되는 것을 막기 위해 명확한 폴더 구조(예: API, Components, Context, Hooks, Pages, Services 등 역할별 분리)가 요구됩니다 [6-11]. 더 나아가 **[[Feature-Sliced Design (FSD)]]** 같은 아키텍처를 도입하여 애플리케이션을 여러 계층으로 나누고 각 계층에 엄격한 의존성 규칙을 적용해 모듈 간 경계를 명확히 설정합니다 [12]. 관련 로직과 CSS 컴포넌트를 기능(Feature) 기반 디렉토리에 함께 배치하면, 특정 기능을 제거할 때 관련 스타일도 자동으로 제거되어 레거시 코드(Ghost styles)가 쌓이는 것을 막을 수 있습니다 [13].
|
||||
|
||||
* **유지보수성을 위한 CSS 구조 설계 방식**
|
||||
대규모 프로젝트에서는 스타일에 캡슐화를 제공하여 전역 네임스페이스 충돌을 방지하는 전략이 필수적입니다 [2].
|
||||
* **[[BEM (Block Element Modifier)]]:** 컴포넌트를 독립적인 블록(Block), 하위 요소(Element), 상태(Modifier)로 나누어 직관적이고 평면적인(Flat) 클래스 명명 규칙을 적용합니다 [5, 14-16]. 깊은 DOM 중첩에 의존하지 않으므로 결합도가 낮고 컴포넌트 응집도를 높여주지만, 사람의 수동 관리에 의존하므로 실수로 인한 충돌 위험이 존재합니다 [17, 18].
|
||||
* **CSS Modules:** 빌드 타임에 고유한 해시(Hashed) 클래스명을 자동으로 생성하여 완전한 로컬 스코핑(Local scoping)을 보장합니다 [19-22]. 표준 CSS 문법의 장점을 그대로 유지하면서도 개발자의 명명 규칙 기억 부담을 덜어주어 대규모 협업에 유리합니다 [19, 21].
|
||||
* **Tailwind CSS (Utility-First):** 유틸리티 클래스를 사용하여 일관된 디자인 시스템을 강제하고, 사용된 클래스만 빌드에 포함시켜 대규모 프로젝트에서도 CSS 파일 크기가 일정 수준에서 유지되도록(Plateau) 돕습니다 [23, 24]. 다만 HTML 코드가 길어지는 단점이 있어, 최근 엔터프라이즈 팀들은 **레이아웃과 간격에는 Tailwind를 사용하고 복잡한 개별 컴포넌트에는 CSS Modules나 [[SCSS]]를 결합하는 하이브리드 전략**을 많이 채택합니다 [25-27].
|
||||
|
||||
* **성능 최적화 및 레이아웃 관리 (Performance & Layout)**
|
||||
대규모 시스템에서는 렌더링 파이프라인 최적화가 필수입니다. 레이아웃 리플로우(Reflows)와 리페인트(Repaints)를 최소화하기 위해 DOM 조작을 일괄 처리하거나 위치/크기 변경 대신 GPU 가속이 가능한 `transform`이나 `opacity` 위주로 애니메이션을 구성해야 합니다 [28-32]. 또한 예측 가능한 UI 구조를 잡기 위해 컴포넌트 내부 정렬에는 **[[Flexbox]](1차원)**를, 전체 페이지 뼈대 및 구조에는 **[[CSS Grid]](2차원)**를 조합하여 불필요한 래퍼(Wrapper) 요소 중첩을 줄입니다 [33-35].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS 구조 설계 방식]], [[BEM]], [[CSS Modules]], Tailwind 전략, [[디자인 시스템 개념]], [[Feature-Sliced Design]]
|
||||
- **Projects/Contexts:** 대규모 엔터프라이즈 플랫폼 개발, 컴포넌트 기반 프레임워크(React, Vue 등) 환경의 협업
|
||||
- **Contradictions/Notes:** Tailwind CSS의 유틸리티 클래스 방식은 빌드 크기를 최적화하고 일관된 디자인 시스템 적용에 뛰어나 대규모 프로젝트에 이상적이라는 주장이 있습니다 [23, 24]. 그러나 과도하게 길어지는 클래스명으로 인해 HTML 가독성이 떨어지고 컴포넌트 유지보수가 힘들어질 수 있다는 반론도 존재합니다 [36, 37]. 이 때문에 대규모 환경에서는 전역 레이아웃 및 디자인 토큰에는 Tailwind를, 세밀하고 복잡한 스타일 제어에는 CSS Modules 또는 SCSS를 결합하는 하이브리드 방식이 실무적 타협안으로 제시되고 있습니다 [26, 27, 38]. BEM 역시 유용하나 인적 오류로 인한 한계 때문에 점차 CSS Modules나 Zero-runtime [[CSS-in-JS]] 같은 자동화 캡슐화 툴로 대체되는 경향을 보입니다 [18, 21, 39].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
|
||||
> *(TODO: 한 문장으로 핵심 통찰을 작성. "X는 Y 조건에서 Z 효과를 낸다" 구조 권장.)*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
id: wiki-2026-0508-layout-thrashing
|
||||
title: Layout Thrashing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Layout Thrashing]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
레이아웃 스래싱(Layout Thrashing)은 브라우저가 페이지의 구조를 다시 계산해야 하는 리플로우(Reflow)와 리페인트(Repaint)를 과도하게 반복할 때 발생하는 성능 병목 현상입니다 [1, 2]. 주로 자바스크립트가 DOM을 읽고 쓰는 작업을 좁은 루프 안에서 번갈아 수행하거나 레이아웃에 큰 영향을 미치는 CSS 속성을 애니메이션화할 때 유발됩니다 [1, 2]. 이 현상은 프레임 속도를 심각하게 저하시키고 애니메이션을 끊기게 만들어 전반적인 사용자 경험을 훼손합니다 [1, 2].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**발생 원인**
|
||||
* **DOM 읽기/쓰기의 반복**: 자바스크립트 스크립트가 좁은 루프 내에서 DOM 속성에 대한 읽기와 쓰기를 번갈아 수행할 때 흔히 발생합니다 [2, 3]. 예를 들어 `offsetWidth`나 `offsetHeight` 같은 크기 관련 속성을 읽을 때, 브라우저는 정확한 치수를 제공하기 위해 내부 레이아웃 큐(Queue)를 강제로 비우고 동기적 리플로우(Synchronous reflow)를 수행해야 하므로 프레임 속도에 악영향을 미칩니다 [2].
|
||||
* **무거운 레이아웃 속성 변경**: `width`, `height`, `margin`, `padding`, `left/top/right/bottom`과 같이 기하학적 형태나 레이아웃에 직접적인 영향을 주는 속성을 애니메이션 처리하면 브라우저가 레이아웃을 지속적으로 재계산하게 되어 레이아웃 스래싱을 유발합니다 [1, 4, 5].
|
||||
|
||||
**최적화 및 해결 방법**
|
||||
* **DOM 읽기와 쓰기 분리**: 레이아웃 스래싱을 방지하기 위해서는 DOM 값을 읽는 작업(Read)과 쓰는 작업(Write)을 엄격히 분리하여 수행해야 합니다 [3].
|
||||
* **DOM 변경 일괄 처리([[Batching]])**: 다수의 DOM 변경을 한 번에 묶어 처리하면 리플로우와 리페인트를 줄일 수 있습니다 [2, 6]. `classList.add()`나 `cssText`를 사용하여 단 한 번의 렌더링 주기만 유발하거나 `innerHTML`을 사용하여 여러 요소를 동시에 업데이트할 수 있습니다 [2, 6].
|
||||
* **가상 DOM 활용**: 새로운 요소를 라이브 DOM에 직접 추가하기 전에 `DocumentFragment`를 활용하여 추가하거나, 노드를 복제하여 변경한 후 원본과 교체하는 방식을 쓰면 요소당 한 번씩 일어날 리플로우를 단 한 번으로 줄일 수 있습니다 [2, 6, 7].
|
||||
* **애니메이션 속성 대체**: 애니메이션을 구현할 때는 레이아웃을 변경하는 속성 대신 GPU 가속의 이점을 얻을 수 있는 `transform`과 `opacity` 속성을 사용하여 리플로우 발생을 피해야 합니다 [5, 8, 9]. 또한 자바스크립트 기반 애니메이션에서는 `requestAnimationFrame`을 사용하여 브라우저의 네이티브 리페인트 주기와 동기화시킴으로써 끊김 없는 모션을 구현해야 합니다 [2, 3, 6].
|
||||
* **스타일 적용 방식 최적화**: 자바스크립트로 직접 인라인 스타일을 조작하기보다는 CSS 클래스를 추가/제거하는 방식을 사용해야 합니다 [6]. 렌더링 속도를 늦추는 깊고 복잡한 CSS 선택자의 사용을 피하고, 자주 변경될 요소에는 `will-change` 속성을 통해 브라우저가 미리 렌더링을 최적화할 수 있는 힌트를 제공하는 것도 방법입니다 [3, 6, 10].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** Reflow, Repaint, [[CSS Animations]], [[Performance Optimization]]
|
||||
- **Projects/Contexts:** [[Frontend]] [[Architecture]], [[실무에서 CSS 관리하는 방법]]
|
||||
- **Contradictions/Notes:** `will-change` 속성은 브라우저가 변경 사항에 미리 대비하게 해주어 성능을 향상할 수 있지만, 너무 많은 요소에 불필요하게 적용할 경우 오히려 브라우저 자원을 낭비하여 성능 문제를 일으킬 수 있으므로 신중하게 사용해야 합니다 [10].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
id: wiki-2026-0508-reflow-repaint
|
||||
title: "Reflow & Repaint"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Reflow & Repaint]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
리플로우(Reflow)는 브라우저가 렌더 트리를 기반으로 문서 내 요소들의 정확한 위치와 크기(기하학적 구조)를 계산하여 배치하는 과정이며, 리페인트(Repaint)는 계산된 레이아웃을 바탕으로 화면에 실제 픽셀을 그리는 시각적 업데이트 과정이다 [1-6]. 리플로우는 요소의 추가/삭제나 크기 변경 시 발생하며 계산 비용이 매우 높은 반면, 리페인트는 배경색이나 그림자 등 시각적 속성만 변경될 때 발생한다 [5-7]. 이 두 과정은 브라우저의 중요 렌더링 경로([[Critical Rendering Path]])의 핵심 단계로, 과도하게 발생할 경우 브라우저 성능 저하와 화면 끊김(Jank) 현상을 유발하므로 웹 프론트엔드 성능 최적화에 있어 필수적으로 관리해야 하는 요소이다 [5, 8-10].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**렌더링 파이프라인 내의 역할**
|
||||
브라우저는 수신된 HTML과 CSS를 파싱하여 [[DOM(Document Object Model)]]과 [[CSSOM]]을 구축한 후, 가시적인 콘텐츠만 포함하는 렌더 트리([[Render Tree]])를 생성한다 [11-14]. 이 렌더 트리가 완성되면 요소들을 화면에 나타내기 위해 리플로우(Layout)와 리페인트(Paint) 단계가 순차적으로 실행된다 [1, 13].
|
||||
|
||||
**리플로우 (Reflow / Layout)**
|
||||
* 리플로우는 렌더 트리의 루트부터 아래로 탐색하며 뷰포트 크기와 박스 모델을 기반으로 모든 표시되는 요소의 정확한 너비, 높이, x/y 위치 좌표를 계산하는 과정이다 [1, 3, 7, 15].
|
||||
* HTML 요소들은 연속적인 문서 흐름의 일부이기 때문에, 특정 요소 하나의 기하학적 변화만으로도 트리 전체에 걸친 연쇄적인 재계산(Cascade of recalculations)을 유발할 수 있다 [1, 5, 16].
|
||||
* 브라우저 창 크기 조절, DOM 노드의 추가 및 제거, `width`, `height`, `margin`, `padding` 등의 레이아웃 관련 속성을 조작할 때 발생한다 [5, 7, 17, 18].
|
||||
* 이는 매우 계산 집약적인 작업이며, 실행되는 동안 브라우저 메인 스레드에서 사용자의 상호작용을 차단(User-[[Blocking]])할 수 있다 [5, 7, 16].
|
||||
|
||||
**리페인트 (Repaint / Paint)**
|
||||
* 레이아웃 계산이 완료된 후, 기하학적 구조와 스타일을 바탕으로 텍스트, 색상, 그림자 등의 시각적 요소를 화면에 픽셀로 래스터화(Rasterize)하여 그리는 단계이다 [2, 4, 6, 7].
|
||||
* `background-color`, `box-shadow`, `visibility`, 텍스트 색상 등 레이아웃이나 요소의 크기에 영향을 주지 않는 시각적인 속성만 변경될 때 독립적으로 발생한다 [6, 7, 18].
|
||||
* 기하학적 계산을 수반하지 않기 때문에 리플로우보다는 계산 비용이 적게 들지만, 시각적 변경이 과도하게 발생할 경우 (예: 배경색 애니메이션) 렌더링 파이프라인을 방해하여 프레임 드롭(Jank)을 일으킬 수 있다 [2, 19, 20].
|
||||
|
||||
**성능 최적화 전략**
|
||||
* **불필요한 연산 최소화:** DOM 트리의 깊이를 줄이고, 복잡한 CSS 선택자(특히 자손 선택자)나 사용하지 않는 CSS 규칙을 제거하여 브라우저의 매칭 및 계산 부담을 줄여야 한다 [21, 22].
|
||||
* **배칭([[Batching]]) 및 레이아웃 스래싱 방지:** DOM 변경 사항을 가급적 일괄 처리하고, 리플로우를 유발하는 속성을 읽고 쓰는 작업을 코드 내에서 번갈아 실행하여 발생하는 '레이아웃 스래싱([[Layout Thrashing]])' 현상을 피해야 한다 [7, 10, 23].
|
||||
* **문서 흐름 분리:** 복잡한 렌더링 변경이나 애니메이션을 수행할 때는 대상 요소에 `position: absolute` 또는 `position: fixed`를 적용하여 일반적인 문서 흐름에서 분리(Out of the flow)시킴으로써 다른 요소들에 미치는 연쇄적인 리플로우를 방지할 수 있다 [22].
|
||||
* **GPU 가속 활용:** `top`이나 `left` 대신 `transform: translate()` 속성을 활용하거나 `opacity`를 제어하면, 레이아웃이나 페인트 사이클을 유발하지 않고 GPU를 활용한 컴포지팅(Compositing) 단계에서 화면을 업데이트할 수 있어 60fps의 부드러운 애니메이션을 유지할 수 있다 [2, 20, 24, 25].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Critical Rendering Path]], DOM & CSSOM, [[Render Tree]], GPU Compositing
|
||||
- **Projects/Contexts:** [[Frontend]] Performance [[Optimization]], React [[Virtual DOM]] and [[Reconciliation]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 리페인트(Repaint)는 레이아웃 재계산이 없기 때문에 리플로우(Reflow)보다 상대적으로 시스템 비용이 덜 드는 작업으로 설명된다 [2, 20]. 그러나 두 작업 모두 과도하게 트리거될 경우 메인 스레드를 점유하고 배터리 소모 및 버벅임(Jank)을 유발하므로, 성능 최적화 시에는 둘 중 어느 하나를 무시하지 않고 두 과정 모두를 최소화하는 것이 브라우저 렌더링 최적화의 핵심이다 [19, 20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
id: wiki-2026-0508-reflow-repaint
|
||||
title: Reflow Repaint
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# Reflow / Repaint
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
**Reflow(레이아웃)**는 브라우저가 화면에 표시될 DOM 요소들의 정확한 위치와 기하학적 크기를 재계산하는 과정이며, **Repaint(페인트)**는 레이아웃의 변화 없이 요소의 색상이나 그림자 같은 시각적 속성만을 화면에 다시 그리는 과정입니다 [1-6]. 이 두 과정은 웹 페이지 렌더링에 필수적이지만 연산 비용이 높아 과도하게 발생할 경우 애플리케이션의 성능 저하와 버벅거림(Jank)을 유발하므로 프론트엔드 최적화의 핵심 대상이 됩니다 [7-9].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Reflow (Layout) 개념 및 발생 원인**
|
||||
* Reflow는 문서 흐름 내에서 요소의 위치, 크기(width, height, margin, padding, border 등)를 계산하는 과정입니다 [1, 4, 6].
|
||||
* DOM 요소의 추가 및 제거, 브라우저 창 크기 조절, 폰트 크기 변경, 또는 레이아웃에 영향을 주는 CSS 속성 변경 시 트리거됩니다 [4-6, 10].
|
||||
* 웹 문서는 연속적인 흐름으로 구성되어 있어, 단일 요소의 구조적 변화가 부모나 자식 요소 등 DOM 트리 전체에 걸친 재계산을 연쇄적으로 유발할 수 있으므로 연산 비용이 매우 높은 사용자 차단(User-[[Blocking]]) 작업입니다 [1, 3, 5, 6].
|
||||
|
||||
* **Repaint (Paint) 개념 및 발생 원인**
|
||||
* Repaint는 레이아웃에 영향을 주지 않고, 요소의 가시성, 배경색, 텍스트 색상, 그림자 등의 시각적 스타일만 변경될 때 발생합니다 [2, 4, 6].
|
||||
* 기하학적 재계산이 필요하지 않아 Reflow보다는 상대적으로 비용이 적지만, 애니메이션 처리 중 불필요하게 자주 발생하면 여전히 프레임 드랍이나 성능 저하를 초래할 수 있습니다 [7, 9, 11].
|
||||
|
||||
* **Reflow / Repaint 최소화 및 렌더링 최적화 방법**
|
||||
* **DOM 조작 일괄 처리([[Batching]]) 및 레이아웃 스래싱([[Layout Thrashing]]) 방지**: DOM 읽기 및 쓰기 작업을 혼합하지 않고 한 번에 처리하여 브라우저가 레이아웃을 여러 번 재계산하는 것을 방지해야 합니다 [2, 8, 9, 12, 13].
|
||||
* **GPU 가속 활용 (Compositing)**: `top`, `left`와 같은 레이아웃 속성 대신 `transform`을, 색상 변경 대신 `opacity`를 사용하여 애니메이션을 구현하면 Reflow나 Repaint 없이 브라우저가 별도 레이어에서 요소를 처리할 수 있습니다 [8, 9, 11].
|
||||
* **구조 및 스타일 최적화**: DOM 트리의 깊이를 줄이고, 연산이 많이 필요한 복잡한 CSS 선택자(특히 자손 선택자)의 사용을 지양해야 합니다 [14]. 레이아웃 변화 없이 요소를 숨기려면 `display: none` (Reflow 유발) 대신 `visibility: hidden`을 사용하는 것이 좋습니다 [15].
|
||||
* **문서 흐름(Flow)에서 분리**: 애니메이션 등 복잡한 렌더링 변경이 일어나는 요소는 `position: absolute` 또는 `position: fixed`를 사용하여 주변 요소의 Reflow에 영향을 주지 않도록 격리해야 합니다 [14].
|
||||
|
||||
* **React의 렌더링 메커니즘과 성능 최적화**
|
||||
* 기존의 직접적인 DOM 조작은 매 변경마다 비용이 높은 Reflow와 Repaint를 유발하기 때문에 느릴 수밖에 없습니다 [16].
|
||||
* React는 **[[Virtual DOM]]**을 사용하여 메모리 상에서 이전 상태와 새로운 상태를 비교(Diffing)한 뒤, 변경된 최소한의 부분만 실제 DOM에 일괄 반영함으로써 렌더링 파이프라인의 낭비를 방지합니다 [16, 17].
|
||||
* 또한 [[React 18]]부터 도입된 **자동 일괄 처리([[Automatic Batching]])** 기능은 비동기 작업(Promise, setTimeout 등) 내에서 발생하는 여러 상태 업데이트를 단 한 번의 리렌더링으로 묶어서 처리하여 DOM 연산 횟수를 획기적으로 줄여줍니다 [18-20].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[브라우저 렌더링 과정 (HTML → [[CSSOM]] → [[Render Tree]])]], [[DOM vs Virtual DOM]]
|
||||
- **Projects/Contexts:** [[React 기반 싱글 페이지 애플리케이션(SPA)의 렌더링 최적화]], [[Automatic Batching을 통한 React 18 성능 최적화]]
|
||||
- **Contradictions/Notes:** 소스 문서들에 따르면 `display: none`은 요소를 렌더 트리에서 완전히 제거하므로 전체적인 레이아웃 계산(Reflow)을 유발하지만, 시각적으로만 보이지 않게 처리하는 `visibility: hidden`을 사용하면 Reflow를 피할 수 있다고 권장하고 있습니다 [15, 21].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,104 @@
|
||||
---
|
||||
id: wiki-2026-0508-reflow-and-repaint
|
||||
title: Reflow and Repaint
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Reflow and Repaint]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Reflow(리플로우)는 요소의 너비, 높이 등 레이아웃에 영향을 미치는 변경이 발생할 때 브라우저가 페이지의 구조를 다시 계산하는 과정이며, Repaint(리페인트)는 배경색 등 시각적 요소만 변경될 때 레이아웃 계산 없이 화면을 다시 그리는 작업입니다 [1, 2]. 이 두 과정은 비용이 많이 드는 작업으로 브라우저 렌더링 성능에 큰 영향을 미치며, 특히 애니메이션이나 동적 UI를 구현할 때 성능 저하와 버벅거림(Jank)의 주된 원인이 됩니다 [1, 3, 4]. 따라서 유지보수 가능하고 확장성 있는 CSS를 설계하기 위해서는 리플로우와 리페인트를 최소화하는 렌더링 최적화 전략이 필수적입니다 [5-7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **Reflow와 Repaint의 개념**
|
||||
* **Repaint:** 요소의 가시성(visibility), 배경색(background color), 윤곽선(outline) 등 레이아웃에 영향을 주지 않는 시각적 스킨의 변화가 생길 때 발생합니다 [1, 2]. 브라우저는 DOM 트리에 있는 다른 노드들의 가시성까지 확인해야 하므로 비용이 발생합니다 [2].
|
||||
* **Reflow:** 요소의 크기(width, height), 여백(margin, padding), 위치(left, top 등) 등 레이아웃 기하학이 변경될 때 발생합니다 [3, 8]. 해당 요소뿐만 아니라 자식 요소, 조상 요소, 그리고 DOM 트리에서 그 뒤에 오는 요소들까지 연쇄적으로 리플로우를 유발하므로 전체 페이지를 다시 배치하는 것과 맞먹는 높은 비용이 듭니다 [2, 4].
|
||||
|
||||
* **성능 저하를 유발하는 주요 원인**
|
||||
* 창 크기 조절, 폰트 변경, DOM 스크립트 조작, CSS 가상 클래스(`:hover` 등) 활성화, 클래스 속성 변경, `offsetWidth` 및 `offsetHeight` 계산 등 다양한 작업이 리플로우를 유발합니다 [9, 10].
|
||||
* DOM을 읽고 쓰는 작업을 짧은 루프 안에서 연속적으로 실행하면 브라우저가 강제로 동기적 리플로우를 수행해야 하는 레이아웃 스래싱([[Layout Thrashing]])이 발생하여 프레임 속도가 크게 저하됩니다 [11, 12].
|
||||
* 크기나 여백 같은 레이아웃 속성을 애니메이션으로 처리하면 브라우저가 렌더링 엔진을 매 프레임마다 호출해야 하므로 성능에 치명적입니다 [1, 3].
|
||||
|
||||
* **Reflow 및 Repaint 최적화(감소) 기법**
|
||||
* **GPU 가속 활용:** 레이아웃을 변경하는 속성 대신 `transform`과 `opacity`를 애니메이션에 사용하면 브라우저가 값비싼 Layout과 Paint 단계를 건너뛰고 GPU에서 합성(Compositing)만 처리하므로 성능이 크게 향상됩니다 [8, 13, 14].
|
||||
* **DOM 변경 및 스타일 적용 최소화:** 여러 개의 인라인 스타일을 각각 설정하는 것을 피하고, 변경 사항을 묶어 CSS 클래스로 처리해야 합니다 [15, 16]. 또한 리플로우의 파급 범위를 줄이기 위해 DOM 트리의 가능한 가장 낮은 하위 노드에서 클래스를 변경해야 합니다 [17].
|
||||
* **문서 흐름(Flow) 분리:** 애니메이션이 적용되는 요소에는 `position: fixed` 또는 `absolute`를 적용하여 주변 요소의 레이아웃에 영향을 주지 않고 리페인트만 발생하도록 유도할 수 있습니다 [15].
|
||||
* **테이블 레이아웃 지양:** 테이블은 아주 작은 변화에도 내부의 모든 노드가 리플로우를 일으킬 수 있고, 전체 콘텐츠를 파악하기 위해 여러 번의 렌더링 패스가 필요하므로 레이아웃 목적으로 사용해서는 안 됩니다 [18].
|
||||
* **렌더링 힌트 제공:** 변경이 빈번하게 일어날 요소에는 `will-change` 속성을 사용하여 브라우저가 미리 렌더링 최적화를 준비하도록 지시할 수 있습니다 [12, 19].
|
||||
* **애니메이션 주기의 동기화:** `requestAnimationFrame`을 사용하여 자바스크립트 애니메이션을 브라우저의 기본 리페인트 주기와 동기화해야 합니다 [11, 12].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS Animations]], [[Layout Thrashing]], [[GPU Acceleration (Compositing)]], [[CSS Architecture]]
|
||||
- **Projects/Contexts:** 애니메이션 (transition / keyframes) 성능 최적화, [[실무에서 CSS 관리하는 방법]]
|
||||
- **Contradictions/Notes:** 브라우저 성능 최적화를 돕는 `will-change` 속성은 유용하지만, 최후의 수단으로만 사용해야 합니다. 이를 성능 문제 예측용으로 무분별하게 너무 많은 요소에 남용할 경우, 과도한 메모리 사용 등 그 자체로 심각한 성능 저하를 초래할 수 있다고 경고하고 있습니다 [19, 20].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-render-props
|
||||
title: Render Props
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Render Props]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Render Props는 React에서 함수 형태의 자식(child)이나 prop을 사용하여 렌더링할 내용을 결정함으로써 로직을 최대한 재사용하는 컴포넌트 설계 패턴입니다 [1]. 이 패턴은 컴포넌트의 외형을 강제하지 않고 상태와 규칙만 제공하여 소비자가 UI 구조를 직접 제어할 수 있게 합니다 [2]. 새로운 API를 추가하지 않고도 고급 사용자에게 완전한 제어권을 부여하는 '탈출구(escape hatch)' 역할을 하여 유연하고 확장 가능한 UI 구축에 기여합니다 [3, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **작동 원리 및 목적**: Render Props 패턴은 컴포넌트의 렌더링 메커니즘을 함수로 구현하여 자식으로 전달(Function as a child/prop)하는 방식입니다 [1]. 컴포넌트가 어떻게 보여야 할지 지시하는 대신, 내부 상태와 규칙을 전달하고 렌더링 구조 자체는 이를 사용하는 소비자가 결정하게 하여 최대한의 로직 재사용(Maximum [[Logic]] reuse)을 가능하게 합니다 [1, 2].
|
||||
- **특징과 장점**: 이 패턴은 결코 구식(outdated) 기술이 아니며, 특수화(specialized)된 목적을 위해 사용됩니다 [3]. 일반적인 JSX 방식과 Render Props를 모두 지원하는 하이브리드 접근법을 구성하면, 초보자는 깔끔한 JSX를 사용하고 고급 사용자는 내부 상태에 접근해 완전한 제어권(Total Control)을 얻을 수 있습니다 [4]. 이를 통해 API를 불필요하게 분기하거나 기존 코드를 망가뜨리지 않고도 유연성을 확보할 수 있습니다 [4, 5].
|
||||
- **실제 구현 사례**: `[[styled-components]]` 라이브러리의 `ThemeConsumer` 컴포넌트는 이 패턴을 활용하여 렌더링 중 테마 객체에 동적으로 접근하도록 설계되었습니다 [6]. 또한 Accordion이나 File input 같은 복잡한 UI 컴포넌트에서도 사용자가 내부 상태(예: `isOpen`)를 인자로 넘겨받아 버튼이나 미리보기 화면의 마크업을 원하는 대로 구성하게 만들 때 그 진가를 발휘합니다 [4, 7, 8].
|
||||
- **주의점 및 한계**: 제어권을 사용자에게 넘겨주기 때문에, 사용자는 ARIA 접근성 속성(A11y), 버튼의 `type` 지정, 키보드 네비게이션 제어 등의 상호작용 요소를 직접 구현해야 하는 책임을 지게 됩니다 [4, 5]. 아울러 로직이 컴포넌트의 컨텍스트(Context), 훅(Hooks), Render Props 전반에 흩어지게 되면 버그를 추적하기 어려워지는 단점이 있습니다 [9]. 따라서 Render Props는 그 자체가 목적이 아니라 유연한 API 설계를 돕는 여러 도구 중 하나로 신중하게 사용되어야 합니다 [10].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Component API Design]]
|
||||
- **Projects/Contexts:** [[React Component Architecture]], [[styled-components]]
|
||||
- **Contradictions/Notes:** 소스는 Render Props 패턴이 낡은 패턴이 아니며, [[Compound Components]]나 Hooks와 함께 복잡한 UI 및 유연한 API 설계를 위해 적절히 혼합하여 사용할 수 있는 강력한 무기임을 강조합니다 [3, 10].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+96
@@ -0,0 +1,96 @@
|
||||
---
|
||||
id: wiki-2026-0508-server-side-rendering-ssr
|
||||
title: Server Side Rendering (SSR)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Server-Side Rendering (SSR)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Server-Side Rendering (SSR)은 사용자의 요청이 있을 때마다 서버 측에서 웹 페이지의 전체 HTML을 렌더링하여 클라이언트 브라우저로 전송하는 웹 렌더링 방식입니다 [1-3]. 브라우저는 완성된 HTML을 받아 즉시 화면에 표시하며, 이후 [[JavaScript]]를 다운로드하여 페이지를 상호작용 가능하게 만드는 하이드레이션([[Hydration]]) 과정을 거치게 됩니다 [1, 4-6]. 이 방식은 검색 엔진 최적화(SEO)와 초기 화면 표시에 매우 유리하지만, 서버 부하 증가와 상호작용 지연(TTI)이라는 성능적 트레이드오프를 동반합니다 [1, 7-9].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 원리와 하이드레이션 (Hydration):**
|
||||
SSR 환경에서 사용자가 페이지를 요청하면, 서버는 라우팅 로직을 처리하고 데이터베이스나 API로부터 데이터를 가져와 완성된 HTML 문서를 생성하여 응답합니다 [2, 6]. 브라우저는 이 HTML을 즉시 화면에 렌더링하므로 사용자는 콘텐츠를 바로 볼 수 있지만, 이 시점의 페이지는 상호작용할 수 없는 정적인 상태입니다 [6]. 이후 브라우저가 JavaScript 번들을 다운로드하고 실행하면, React와 같은 프레임워크가 가상 DOM([[Virtual DOM]])을 렌더링된 HTML 구조에 매핑하여 이벤트 리스너를 연결하고 상태를 동기화합니다. 이 과정을 '하이드레이션'이라고 부릅니다 [1, 5, 10].
|
||||
|
||||
* **성능 및 사용자 경험적 이점:**
|
||||
SSR의 가장 큰 장점 중 하나는 탁월한 검색 엔진 최적화(SEO)입니다. 검색 엔진 크롤러가 JavaScript 실행을 기다리거나 빈 화면을 볼 필요 없이 완전히 렌더링된 HTML 콘텐츠에 즉시 접근하여 색인을 생성할 수 있기 때문입니다 [1, 11, 12]. 또한 첫 콘텐츠 풀 페인트(FCP) 성능이 우수하여 사용자가 빈 화면 대신 즉각적으로 시각적 요소를 볼 수 있으며, 이는 대역폭이 제한된 모바일이나 느린 3G 네트워크 환경에서 사용자 경험을 크게 개선합니다 [9, 11, 12]. 매 요청마다 서버에서 렌더링이 이루어지므로, 뉴스 사이트나 전자상거래의 제품 페이지처럼 항상 최신의 동적 데이터를 제공해야 하는 환경에 이상적입니다 [13-15].
|
||||
|
||||
* **인프라 한계 및 성능 트레이드오프:**
|
||||
모든 사용자 상호작용이나 페이지 요청 시 서버가 렌더링 연산을 수행해야 하므로 트래픽 급증 시 서버 컴퓨팅 부하가 급격히 커지며, 이는 호스팅 인프라 비용 증가와 복잡성 확대로 이어집니다 [7, 8, 16]. 서버 측에서의 HTML 생성 작업으로 인해 첫 바이트 도달 시간(TTFB)이 약 100~300ms가량 늘어날 수 있습니다 [9, 17]. 무엇보다 사용자가 가장 불편함을 느낄 수 있는 단점은 '상호작용 지연'입니다. 화면의 시각적 요소는 빠르게 로드되지만, JavaScript가 다운로드되고 하이드레이션이 완료될 때까지(기기에 따라 2~5초가량 소요될 수 있음) 페이지가 클릭이나 입력 등의 상호작용에 반응하지 않는 상호작용 시간(TTI) 저하 현상이 발생합니다 [1, 9, 10, 16].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Static Site Generation (SSG)]], [[Hydration]], [[Virtual DOM]], [[Search Engine [[Optimization]] (SEO)]], [[First Contentful Paint (FCP)]], [[Time to Interactive (TTI)]]
|
||||
- **Projects/Contexts:** [[Next.js]], [[React [[Server Components]] (RSC)]], [[E-commerce Platforms]]
|
||||
- **Contradictions/Notes:** 소스 문헌들은 공통적으로 SSR이 시각적 로드(FCP)를 빠르게 만들어 사용자에게 즉각적인 응답을 제공하지만, 하이드레이션 병목 현상으로 인해 실질적인 상호작용(TTI)은 CSR보다 지연된다는 성능적 역설을 주의해야 한다고 지적합니다 [9, 18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+93
@@ -0,0 +1,93 @@
|
||||
---
|
||||
id: wiki-2026-0508-static-site-generation-ssg
|
||||
title: Static Site Generation (SSG)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Static Site Generation (SSG)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Static Site Generation (SSG)은 사용자가 페이지를 요청하기 전인 애플리케이션의 빌드(Build) 타임에 전체 웹사이트의 HTML을 미리 생성하는 렌더링 방식입니다 [1-3]. 빌드 시 생성된 정적 파일들은 콘텐츠 전송 네트워크(CDN)를 통해 배포되며, 사용자의 요청이 있을 때 런타임에서의 추가적인 서버 연산 없이 즉각적으로 제공됩니다 [3-5]. 뛰어난 성능과 검색 엔진 최적화(SEO) 이점을 제공하여, 블로그나 마케팅 페이지처럼 콘텐츠가 자주 변경되지 않는 웹사이트에 이상적인 전략입니다 [2, 5-7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **작동 원리**: 애플리케이션을 배포하기 위한 빌드 과정에서 각 페이지를 구성하는 완전한 HTML 파일이 생성됩니다 [2, 3]. 방문자가 웹사이트를 요청하면 서버는 페이지를 실시간으로 다시 생성하거나 데이터를 새로 가져오는 대신, 이미 만들어진 정적 HTML 파일을 그대로 전송합니다 [2, 3, 8].
|
||||
- **성능 및 SEO 최적화**: 서버 측의 연산과 데이터베이스 조회가 생략되므로 초기 로드 시간과 첫 바이트 도달 시간(TTFB)이 모든 렌더링 방식 중 가장 빠릅니다 [4, 5, 8, 9]. 또한, 검색 엔진 크롤러가 자바스크립트의 실행을 기다릴 필요 없이 완전히 렌더링된 HTML을 즉시 읽을 수 있어 뛰어난 SEO 성능과 LCP(Largest Contentful Paint) 점수를 달성할 수 있습니다 [6, 10, 11].
|
||||
- **주요 장점**: 생성된 정적 파일은 CDN을 통해 글로벌하게 캐싱되어 서비스되므로, 무한대에 가까운 트래픽 확장이 가능하며 호스팅 비용을 크게 줄일 수 있습니다 [5, 12, 13]. 작동 중인 라이브 서버나 데이터베이스와 직접 연결되지 않으므로 공격 대상이 될 표면이 없어 보안성 또한 극대화됩니다 [5].
|
||||
- **한계 및 단점**: 빌드 시점에 콘텐츠가 고정되므로, 실시간 데이터(예: 라이브 스코어, 맞춤형 대시보드)가 필요한 서비스에서는 데이터가 쉽게 구식(stale)이 되는 한계가 있습니다 [5, 12, 14]. 콘텐츠를 수정하거나 업데이트하려면 사이트 전체를 다시 빌드하고 배포해야 하며, 페이지 수가 수천 개 이상인 대규모 사이트의 경우 빌드 시간이 지나치게 길어질 수 있습니다 [5, 14, 15].
|
||||
- **활용 사례**: 콘텐츠의 변경 빈도가 낮고 사용자마다 동일한 정보를 보여주는 문서(Documentation) 사이트, 블로그, 포트폴리오, 마케팅 웹사이트 및 안정적인 제품 카탈로그 페이지에 완벽하게 부합합니다 [2, 5-7, 16].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Client-Side Rendering (CSR)]], [[Server-Side Rendering (SSR)]], Incremental Static Regeneration (ISR), Content Delivery Network (CDN), [[Search Engine [[Optimization]] (SEO)]]
|
||||
- **Projects/Contexts:** [[Next.js]], Gatsby, Qwik과 같이 정적 사이트 생성을 특화 지원하는 프레임워크 환경 [2, 8, 17] 및 블로그, 문서화 플랫폼 구축 맥락 [2, 5-7].
|
||||
- **Contradictions/Notes:** 소스 전반에 걸쳐 모순되는 주장은 없으나, SSG의 압도적인 로드 속도 이면에는 '실시간 동적 데이터 처리의 어려움'과 '잦은 콘텐츠 업데이트 시 빌드 비용 증가'라는 명확한 트레이드오프가 존재함이 공통으로 지적됩니다 [5, 14]. 이를 보완하기 위해, 전체 사이트를 다시 빌드하지 않고도 특정 주기나 조건에 따라 백그라운드에서 정적 페이지를 업데이트하는 Incremental Static Regeneration (ISR) 기술을 SSG와 혼합하여 사용하는 대안이 폭넓게 채택되고 있습니다 [4, 6, 12, 18].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
id: wiki-2026-0508-styled-components
|
||||
title: Styled Components
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Styled Components]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Styled Components는 React 및 [[Next.js]] 환경에서 사용되는 대표적인 [[CSS-in-JS]] 라이브러리로, 자바스크립트 파일 내에서 태그된 템플릿 리터럴(tagged template literals)을 사용하여 CSS를 직접 작성할 수 있게 해줍니다 [1, 2]. 이 방식은 컴포넌트와 스타일 코드를 같은 곳에 위치(co-location)시키고 자동으로 고유한 클래스명을 생성하여 스타일의 전역 충돌을 방지합니다 [3, 4]. 프롭스(props)와 상태([[State]])를 기반으로 한 동적 스타일링에 매우 강력하지만, 런타임 CSS 생성으로 인한 성능 오버헤드와 최근의 [[React Server Components]](RSC) 환경에서의 호환성 처리라는 과제를 안고 있습니다 [4-6].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동적 스타일링 및 테마 시스템**: Styled Components는 프롭스와 상태, 그리고 테마를 활용해 자연스러운 동적 스타일링을 가능하게 합니다 [4, 6]. 라이브러리에 내장된 `ThemeProvider`는 [[Context API]]를 통해 앱 하위의 모든 컴포넌트에 테마를 주입할 수 있어 다크 모드나 다중 브랜드 테마를 구축하는 데 유용합니다 [4, 7].
|
||||
* **주요 컴포넌트 API**:
|
||||
* **`as` 프롭스**: 컴포넌트에 적용된 스타일은 그대로 유지하면서, 런타임에 렌더링되는 실제 HTML 태그나 React 컴포넌트를 변경할 수 있는 다형성(polymorphism)을 제공합니다 [8].
|
||||
* **트랜지언트 프롭스 (Transient props)**: 스타일링 컴포넌트 전용으로 사용되며 실제 DOM 노드에는 전달되지 않기를 원하는 프롭스의 경우, 이름 앞에 달러 기호(`$`)를 붙여 필터링할 수 있습니다 [9, 10].
|
||||
* **성능 및 번들 사이즈의 한계**: 런타임에 CSS 문자열을 생성하고 브라우저에 주입해야 하기 때문에 CPU 및 [[JavaScript]] 실행 비용(런타임 텍스)이 발생합니다 [4, 6]. 라이브러리 추가로 인해 번들 사이즈가 약 30kb(gzipped) 증가하며, 대규모 렌더링(예: 10,000개 리스트 아이템) 시 빌드 타임 기반의 [[Tailwind CSS]](85ms)보다 렌더링 시간(148ms)이 더 오래 걸리는 등 성능 최적화 면에서 한계를 보입니다 [5, 6, 11].
|
||||
* **[[React [[Server Components]] (RSC)]] 호환성과 Next.js 통합**: Styled Components의 테마 기능은 [[React Context]]에 의존하므로, Context가 없는 서버 컴포넌트(RSC) 환경에서는 기본적으로 작동하지 않습니다 [12, 13]. [[Next.js 15]]의 App Router에서 사용하기 위해서는 렌더링 중 CSS 규칙을 수집하여 `<head>`에 주입하는 '스타일 레지스트리([[Style Registry]]) 패턴'을 적용해야 합니다 [14]. 또한 서버와 클라이언트 간의 하이드레이션([[Hydration]]) 불일치를 막기 위해 컴파일러 설정(`styledComponents`)을 활성화해야 합니다 [15]. 최신 버전(v6.3.0 이상)에서는 RSC 환경에서 자동으로 인라인 `<style>` 태그를 방출하여 [[React 19]]의 호이스팅 및 중복 제거 기능을 지원하도록 업데이트되었습니다 [16].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[React Server Components]], [[Dynamic Theming]]
|
||||
- **Projects/Contexts:** [[Next.js App Router]], [[Component Library Architecture]]
|
||||
- **Contradictions/Notes:** 소스 [6, 17, 18] 및 [19]는 런타임 비용이 없는 Tailwind CSS가 대규모 프로덕션이나 [[Core Web Vitals]](FID, INP 등) 최적화에 훨씬 뛰어나며, App Router 환경에서는 Tailwind나 [[CSS Modules]]를 사용하는 것을 권장한다고 주장합니다. 반면, 소스 [20]는 테마가 사용자 데이터나 복잡한 런타임 상태와 깊게 결합된 '고도로 동적인 대시보드 형태의 애플리케이션'에서는 Styled Components가 여전히 매우 강력한 도구라고 강조하며 상반되면서도 보완적인 시각을 제공합니다.
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
id: wiki-2026-0508-time-slicing
|
||||
title: Time Slicing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Time Slicing]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Time Slicing(타임 슬라이싱)은 React에서 대규모 렌더링 업데이트 작업을 더 작은 단위(청크)로 분할하여 UI의 반응성을 유지하는 최적화 기법입니다 [1, 2]. 이 기능을 통해 React는 렌더링 작업을 일시 중지하고 사용자 입력 등 우선순위가 높은 작업을 위해 브라우저에 제어권을 넘긴 후, 중단된 위치부터 렌더링을 다시 재개할 수 있습니다 [3]. 결과적으로 동시성 렌더링([[Concurrent Rendering]])과 함께 작동하여 복잡한 업데이트 상황에서도 애플리케이션이 멈추지 않고 원활하게 동작하도록 보장합니다 [4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작업의 분할과 제어권 양보 (Yielding):** Time Slicing은 긴 시간이 소요되는 대규모 업데이트를 더 작은 청크(chunk) 단위로 쪼개어 처리합니다 [1, 2]. 이를 통해 React는 렌더링 작업을 수행하는 도중에 브라우저로 제어권을 양보(yield)할 수 있어 메인 스레드가 장시간 차단되는 것을 방지합니다 [2].
|
||||
* **우선순위 기반 렌더링 (Lane-Based Priority):** 이 과정은 React의 Fiber 아키텍처 내에서 "Lanes(레인)"라고 불리는 우선순위 기반 시스템을 통해 관리됩니다 [3]. 클릭 이벤트나 타이핑 같은 우선순위가 높은 작업이 발생하면, 진행 중이던 렌더링을 일시 중지하고 긴급한 작업을 먼저 처리한 뒤 남은 렌더링을 이어서 진행합니다 [3].
|
||||
* **성능 및 UI 반응성 향상:** Time Slicing은 동시성 렌더링(Concurrent Rendering) 및 점진적 렌더링(Incremental Rendering) 아키텍처와 긴밀하게 결합되어 작동합니다 [4]. 이들의 조합은 복잡하고 무거운 UI 업데이트가 수행되는 동안에도 앱의 응답성을 유지시켜 사용자 경험을 크게 향상시킵니다 [4].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Fiber Architecture]], [[Concurrent Rendering]], Lanes
|
||||
- **Projects/Contexts:** React
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-time-slicing
|
||||
title: Time Slicing
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Time-Slicing]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
타임 슬라이싱(Time-Slicing)은 대규모 렌더링 작업을 더 작은 조각(chunk)으로 분할하여 사용자 인터페이스(UI)의 반응성을 유지하는 React의 최신 기능입니다 [1, 2]. 이 기능을 통해 React는 렌더링 프로세스를 일시 중지하고, 클릭 이벤트 처리와 같은 우선순위가 높은 작업을 위해 브라우저에 제어권을 양보(yield)한 뒤 중단된 부분부터 다시 렌더링을 재개할 수 있습니다 [3]. 타임 슬라이싱은 메인 스레드가 차단되는 것을 방지하고 동시성 렌더링([[Concurrent Rendering]])을 가능하게 하는 핵심 메커니즘입니다 [1, 3, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **렌더링 작업의 분할 및 양보(Yielding):** React의 타임 슬라이싱은 크고 복잡한 상태 업데이트를 단일 통째로 처리하는 대신 작은 단위로 쪼갭니다 [2]. 이를 통해 React는 작업 중간마다 브라우저에 제어권을 양보할 수 있으며, 사용자 입력(타이핑, 클릭 등)과 같은 긴급한 상호작용이 렌더링 작업으로 인해 지연되거나 멈추는 현상을 방지합니다 [2, 3].
|
||||
- **Fiber 아키텍처와의 연계:** 타임 슬라이싱은 React 16에서 동기식(synchronous) 렌더링의 한계를 극복하기 위해 도입된 파이버(Fiber) 아키텍처에 의해 활성화됩니다 [3, 4]. 파이버 아키텍처 하에서 렌더러는 작업을 관리 가능한 '작업 단위(units of work)'로 나누어 스케줄러가 렌더링 과정을 더 유연하게 제어할 수 있도록 합니다 [3, 5].
|
||||
- **Lanes 기반 우선순위 시스템:** 타임 슬라이싱을 통한 작업의 일시 중지 및 재개는 'Lanes'라고 불리는 우선순위 기반 시스템을 통해 관리됩니다 [3]. 예를 들어, 사용자의 클릭이나 타이핑처럼 즉각적인 반응이 필요한 작업은 'Sync Lane'으로 분류되어 즉시 처리되며, 화면 밖 렌더링과 같은 비긴급 작업은 'Idle Lane'에 할당되어 브라우저가 유휴 상태일 때만 처리되도록 우선순위를 지정합니다 [6, 7].
|
||||
- **동시성 및 점진적 렌더링 달성:** 타임 슬라이싱은 동시성 렌더링(Concurrent Rendering) 및 점진적 렌더링(Incremental Rendering)과 결합하여, 복잡하고 무거운 업데이트가 발생하더라도 애플리케이션이 항상 부드럽고 응답성 있게 동작하도록 보장합니다 [1, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[React Fiber Architecture]], [[Concurrent Rendering]], Lanes Priority[[ system]], Incremental Rendering
|
||||
- **Projects/Contexts:** React Scheduler
|
||||
- **Contradictions/Notes:** 소스 내에서 타임 슬라이싱과 관련하여 상충되는 정보는 없습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+111
@@ -0,0 +1,111 @@
|
||||
---
|
||||
id: wiki-2026-0508-virtual-dom과-reconciliation
|
||||
title: Virtual DOM과 Reconciliation
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Virtual DOM과 Reconciliation]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Virtual DOM]]은 UI의 이상적인 가상 표현을 메모리에 유지하는 프로그래밍 개념입니다 [1]. [[Reconciliation]](재조정)은 이 Virtual DOM을 실제 DOM과 동기화하여 변경된 부분만 파악하고 효율적으로 업데이트하는 React의 핵심 프로세스입니다 [1, 2]. React는 O(n) 복잡도를 가진 휴리스틱 Diffing 알고리즘을 사용하여 실제 DOM 조작으로 인해 발생하는 비싼 렌더링 비용과 성능 저하를 최소화합니다 [3-5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**Virtual DOM의 개념과 도입 배경**
|
||||
* 브라우저의 실제 DOM을 직접 수정하는 작업은 레이아웃(Reflow)과 페인트(Repaint) 단계를 반복적으로 트리거하기 때문에 본질적으로 매우 느립니다 [2].
|
||||
* React는 이 문제를 추상화하기 위해 가볍고 메모리 내에 존재하는 UI 표현인 Virtual DOM을 도입했습니다 [2].
|
||||
* 이를 통해 개발자는 원하는 UI 상태를 선언적으로 명시하기만 하면 되며, React의 ReactDOM과 같은 라이브러리가 내부적으로 속성 조작, 이벤트 처리 및 수동 DOM 업데이트를 알아서 관리하게 됩니다 [1, 2].
|
||||
* React 세계에서 Virtual DOM은 일반적으로 사용자 인터페이스를 나타내는 객체인 'React Elements'를 의미하며, 컴포넌트 트리에 대한 추가 정보를 담고 있는 내부 객체인 'Fiber' 역시 그 구현의 일부로 간주될 수 있습니다 [6].
|
||||
|
||||
**Reconciliation과 휴리스틱 Diffing 알고리즘**
|
||||
* 상태([[State]])나 속성(Props)이 업데이트되면 `render()` 함수는 새로운 React Element 트리를 반환하며, React는 이를 가장 최근의 트리와 비교하여 UI를 어떻게 효율적으로 업데이트할지 계산합니다 [4].
|
||||
* 두 트리를 비교하여 변환하기 위한 최소한의 연산을 찾는 일반적인 알고리즘은 O(n^3)의 복잡도를 가지므로 실제 애플리케이션에 적용하기에는 비용이 너무 높습니다 [4].
|
||||
* 따라서 React는 다음 두 가지 가정에 기반한 **O(n) 휴리스틱 알고리즘**을 구현했습니다 [3-5]:
|
||||
1. 서로 다른 타입의 요소(Elements)는 본질적으로 다른 트리를 생성한다 [3, 5].
|
||||
2. 개발자가 `key` 속성을 제공하여 여러 렌더링 간에 어떤 자식 요소가 안정적인지 힌트를 줄 수 있다 [3, 5].
|
||||
|
||||
**비교(Diffing) 프로세스 상세 처리**
|
||||
* **다른 타입의 요소:** 루트 요소의 타입이 다르면(예: `<a>`에서 `<img>`로, 혹은 `<div>`에서 `<span>`으로 변경), React는 기존 트리를 완전히 파괴하고 처음부터 새 트리를 구축합니다 [3, 7]. 이 과정에서 이전 DOM 노드는 파괴되며 연관된 모든 컴포넌트의 상태(State)가 유실됩니다 [7].
|
||||
* **같은 타입의 DOM 요소:** 동일한 타입의 React DOM 요소를 비교할 때는 기본 DOM 노드를 유지한 채, `className`이나 `style` 등 변경된 속성(Attributes)만을 업데이트합니다 [8, 9].
|
||||
* **같은 타입의 컴포넌트 요소:** 컴포넌트가 업데이트될 때 인스턴스는 동일하게 유지되어 렌더링 간에 상태가 보존됩니다. React는 새 요소와 일치하도록 기본 컴포넌트 인스턴스의 props를 업데이트하고 수명 주기(Lifecycle) 메서드를 호출한 뒤, 자식 노드에 대해 재귀적으로 처리합니다 [9, 10].
|
||||
* **자식 노드 처리와 Key 속성:** 자식 노드를 순회할 때 리스트의 맨 앞에 요소를 추가하면 전체 트리가 변경된 것으로 인식해 매우 비효율적으로 작동할 수 있습니다 [10, 11]. 이를 해결하기 위해 `key` 속성을 사용하여 원본 트리와 후속 트리의 자식을 정확히 매칭시킵니다 [3, 11]. `key`는 형제 노드 사이에서 안정적이고 예측 가능하며 고유해야 성능 저하와 상태 유실을 방지할 수 있습니다 [12].
|
||||
|
||||
**[[React Fiber]] 아키텍처를 통한 렌더링 최적화**
|
||||
* 과거 동기적인 스택 재조정자(Stack reconciler)는 대규모 애플리케이션 처리 시 메인 스레드를 차단([[Blocking]])하여 UI의 반응성을 떨어뜨리는 문제가 있었습니다 [13, 14].
|
||||
* React 16은 이를 해결하기 위해 동시성 렌더링([[Concurrent Rendering]])을 지원하는 **Fiber 아키텍처**로 재조정 엔진을 완전히 재작성했습니다 [15-17].
|
||||
* Fiber는 렌더링 작업을 '작업 단위(Unit of work)'로 나누고, 우선순위(Lanes) 시스템을 통해 긴급한 상호작용(클릭, 타이핑 등)을 위해 작업을 일시 중단, 양보(Yield), 및 재개할 수 있도록 지원합니다 [14, 16, 18, 19]. 이로 인해 Virtual DOM의 재조정 과정 중에도 UI 반응성을 유지할 수 있습니다 [16, 18].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[React Fiber Architecture]], [[Critical Rendering Path (CRP)]], [[Concurrent Rendering]]
|
||||
- **Projects/Contexts:** React Application Performance [[Optimization]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 Virtual DOM 트리는 설계상 불변(immutable)으로 취급되지만, 단일 자식 노드를 여러 위치에서 사용하는 경우 복사 비용 문제가 발생할 수 있습니다. 이를 해결하기 위해 React는 현재 설치된 상태를 나타내는 가변적인 형태의 "Augmented DOM" 구조를 구축하며, 이것이 바로 React의 Fiber 데이터 구조가 수행하는 역할입니다 [20].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-25*
|
||||
|
||||
## 🤖 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-styled-components
|
||||
title: styled components
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[styled-components]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
styled-components는 [[JavaScript]] 파일 내에서 태그된 템플릿 리터럴(Tagged Template Literals)을 사용하여 React 컴포넌트의 스타일을 지정하는 대표적인 [[CSS-in-JS]] 라이브러리이다 [1-3]. 스타일을 개별 컴포넌트에 지역적으로 캡슐화하여 전역 네임스페이스 충돌이나 스타일 누수 현상을 방지한다 [3-5]. Props나 상태([[State]]), 테마를 활용한 동적 스타일링 측면에서 뛰어난 개발자 경험을 제공하지만, 런타임에 CSS를 생성하고 주입하는 방식 때문에 성능 오버헤드와 번들 크기 증가라는 트레이드오프가 존재한다 [6, 7].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **작동 원리 및 개발자 경험(DX):** styled-components는 ES6의 태그된 템플릿 리터럴을 통해 컴포넌트와 해당 스타일을 함께 배치(Co-location)한다 [1, 5, 6]. `ThemeProvider`를 이용한 내장 테마 시스템을 지원하며 [6, 8], TypeScript와 원활하게 통합되어 Props 기반의 타입 안전한 동적 스타일링을 구현할 수 있다 [6, 9]. DOM으로 전달되지 않아야 하는 스타일 전용 Props를 필터링하기 위해 이름 앞에 `$`를 붙이는 "Transient props" 기능이나 `shouldForwardProp` API를 제공하여 깔끔한 DOM 트리를 유지할 수 있다 [10-12].
|
||||
* **런타임 성능 및 확장성 이슈:** 스타일이 자바스크립트에 내장되어 런타임에 동적으로 주입되므로 앱의 CPU 사이클 소모와 JS 번들 크기(약 30kb 추가)가 증가하는 단점이 있다 [6, 13, 14]. 이 런타임 오버헤드는 복잡한 대규모 애플리케이션이나 저사양 기기에서 렌더링 성능 병목(예: 10,000개 리스트 렌더링 테스트 시 Tailwind 대비 약 63% 더 느린 148ms 소요)을 유발할 수 있다 [7, 14, 15].
|
||||
* **[[React [[Server Components]] (RSC)]] 및 [[Next.js 15]] 호환성:** 전통적인 CSS-in-JS 라이브러리는 [[React Context]]에 의존하기 때문에, Context가 존재하지 않는 서버 컴포넌트(RSC) 환경과 근본적으로 호환되지 않는 문제가 있었다 [13, 16-18]. 이를 해결하기 위해 [[Next.js App Router]]에서는 렌더링 중 CSS 규칙을 수집하는 '[[Style Registry]]' 패턴과 `useServerInsertedHTML` 훅을 사용해야 하며, 하이드레이션 불일치를 막기 위해 `next.config.js`의 `styledComponents` 컴파일러 옵션을 활성화해야 한다 [18, 19]. 최신 v6.3.0 이상에서는 RSC 환경을 자동 감지하여 인라인 `<style>` 태그를 주입하는 기능을 지원하지만, `ThemeProvider`는 여전히 RSC에서 동작하지 않으므로 [[CSS Variables]](사용자 지정 속성) 기반의 테마 적용이 권장된다 [8, 20].
|
||||
* **버전 6(v6)의 주요 변경 사항:** v6부터는 코드베이스가 TypeScript로 완전히 다시 작성되어 라이브러리 자체적으로 타입을 제공하며, 내부 파서로 Stylis v4를 사용한다. 또한, 기존에 지원되던 자동 Prop 필터링을 제거하고 Transient props(`$`) 사용을 표준으로 강제한다 [21, 22].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[React Server Components]], [[Dynamic Theming]], [[Design Tokens]]
|
||||
- **Projects/Contexts:** [[Next.js App Router]], Scalable [[Frontend]] [[Architecture]]
|
||||
- **Contradictions/Notes:** 소스에 따르면, styled-components는 모듈화와 동적 스타일링에 매우 강력한 도구이지만, 런타임 비용 문제와 RSC 호환성의 한계로 인해 최근의 확장 가능한 프론트엔드 아키텍처에서는 제로 런타임(Zero-runtime) CSS-in-JS(예: [[vanilla-extract]])나 유틸리티 클래스 기반인 [[Tailwind CSS]]로 전환(마이그레이션)하여 [[Core Web Vitals]] 최적화를 꾀하는 추세가 확인된다 [16, 17, 23-25].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
---
|
||||
id: wiki-2026-0508-리플로우-및-리페인트-reflow-repaint
|
||||
title: "리플로우 및 리페인트(Reflow & Repaint)"
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[리플로우 및 리페인트([[Reflow & Repaint]])]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
리플로우(Reflow)는 요소의 너비, 높이 등 레이아웃이나 기하학적 구조가 변경될 때 브라우저가 문서의 구조를 재계산하는 과정이며, 리페인트(Repaint)는 레이아웃에 영향을 주지 않는 시각적 요소(색상, 배경 등)가 변경될 때 발생하여 화면을 다시 그리는 과정입니다 [1-3]. 두 과정 모두 연산 비용이 높고 렌더링 성능을 저하시켜 화면 끊김(Jank) 현상을 유발할 수 있으므로, CSS 및 애니메이션 구현 시 이들의 발생을 최소화하는 최적화 전략이 필수적입니다 [1, 4, 5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**리플로우와 리페인트의 개념 및 비용**
|
||||
* **리플로우(Reflow):** 요소의 레이아웃, 크기, 위치 등에 영향을 주는 변경 사항이 있을 때 발생합니다. 한 요소에서 리플로우가 발생하면 해당 요소의 자식, 부모 노드는 물론 DOM 트리에서 그 뒤에 오는 모든 요소까지 재계산되어야 하므로 성능 측면에서 매우 비쌉니다 [3, 5]. 심한 경우 페이지 전체를 다시 레이아웃하는 것과 같습니다 [5].
|
||||
* **리페인트(Repaint):** 윤곽선(outline), 가시성(visibility), 배경색 등 레이아웃에는 영향을 주지 않지만 시각적인 스킨이 변경될 때 일어납니다 [3]. 브라우저는 시각적 변화를 반영하기 위해 다른 모든 노드의 가시성을 확인해야 하므로 이 또한 비용이 듭니다 [3]. 브라우저는 렌더 트리 생성 후 레이아웃을 계산하고 그 후에 페인트를 수행합니다 [6].
|
||||
|
||||
**발생 원인**
|
||||
* 창 크기 조절, 폰트 변경, 스타일시트 추가/제거, 사용자의 입력(텍스트 타이핑 등), DOM 조작, `:hover`와 같은 가상 클래스 활성화, `offsetWidth` 및 `offsetHeight` 속성 계산, 인라인 스타일 설정 등이 리플로우를 유발합니다 [7, 8].
|
||||
* 애니메이션 적용 시 `width`, `height`, `margin`, `padding`, `top`, `left`, `box-shadow` 등의 속성을 변경하면 레이아웃 스래싱([[Layout Thrashing]])과 리페인트 주기를 촉발하여 성능이 급격히 저하됩니다 [4, 9, 10].
|
||||
|
||||
**최적화 및 감소 기법**
|
||||
* **DOM 및 스타일 조작 최소화:** 여러 개의 인라인 스타일을 각각 적용하는 것을 피하고, 변경 사항을 외부 클래스로 결합하여 한 번의 클래스 속성 조작으로 리플로우가 한 번만 발생하게 해야 합니다 [8, 11]. DOM 트리의 가능한 가장 낮은 계층(하위)에서 클래스를 변경하여 리플로우의 영향을 받는 노드 수를 줄이는 것이 좋습니다 [12]. DOM 변경 시에는 `documentFragment`를 사용하여 일괄 업데이트해야 합니다 [11, 13].
|
||||
* **애니메이션 최적화:** 레이아웃을 건드리는 속성 대신 `transform`, `opacity`, `filter` 속성을 사용하여 애니메이션을 처리하면 리플로우를 방지하고 렌더링 성능을 높일 수 있습니다 [2, 10, 14]. 또한 `position: fixed` 또는 `absolute`인 요소에 애니메이션을 적용하면 전체 문서의 리플로우 대신 부분적인 리페인트만 유발할 수 있습니다 [15].
|
||||
* **브라우저 힌팅(Hinting) 및 동기화:** 잦은 변경이 예상되는 요소에 `will-change` 속성을 부여하여 브라우저가 렌더링을 미리 최적화하도록 유도할 수 있습니다 [16-18]. 아울러 애니메이션은 브라우저의 리페인트 주기와 동기화되는 `requestAnimationFrame`을 사용하여 일괄 처리해야 합니다 [13, 18].
|
||||
* **레이아웃 스래싱 방지 및 기타 주의사항:** DOM을 읽고 쓰는 작업을 명확히 분리하여(배칭) 브라우저가 강제로 동기식 리플로우를 발생시키는 레이아웃 스래싱을 방지해야 합니다 [13, 18]. 또한 렌더링을 지연시키고 작은 변경에도 모든 노드의 리플로우를 발생시키는 테이블(Table) 레이아웃 사용을 피하고 [19], 너무 복잡하고 깊게 중첩된 CSS 선택자를 사용하지 말아야 합니다 [11].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[CSS 애니메이션 최적화([[CSS Animations]] [[Optimization]])]], [[레이아웃 스래싱(Layout Thrashing)]], [[렌더링 파이프라인(Rendering Pipeline)]]
|
||||
- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트(Large [[Frontend]] Projects)]], [[반응형 디자인 및 인터랙티브 UI(Responsive and Interactive UI)]]
|
||||
- **Contradictions/Notes:** 소스에 따르면 `will-change` 속성은 성능 향상에 도움이 되지만, 과도하게 사용할 경우 오히려 브라우저의 시스템 리소스를 많이 소모하여 성능 저하를 유발할 수 있으므로 꼭 필요한 요소(최후의 수단)에만 신중하게 사용해야 한다고 경고합니다 [16, 17].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-미디어-쿼리-media-queries
|
||||
title: 미디어 쿼리 (Media Queries)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[미디어 쿼리 (Media Queries)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
미디어 쿼리(Media Queries)는 화면 크기, 방향, 해상도 등 특정 조건에 따라 다른 CSS 규칙을 적용하게 해주는 반응형 웹 디자인의 핵심 기술이다 [1, 2]. 브라우저의 뷰포트 너비에 반응하여 모바일, 태블릿, 데스크톱 등 다양한 기기에서 단일 코드베이스로 일관된 레이아웃을 제공할 수 있게 한다 [3, 4]. 최근에는 브라우저 렌더링 성능 최적화와 모바일 우선(Mobile-first) 설계의 필수적인 논리로 사용되며, 컴포넌트 단위의 반응형 제어를 위한 컨테이너 쿼리([[Container Queries]])와 함께 현대 CSS 설계의 주요 기반으로 활용된다 [5-8].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **반응형 디자인의 핵심 논리:** 미디어 쿼리는 유동형 그리드(Fluid grids), 유연한 미디어(Flexible media)와 함께 반응형 웹 레이아웃을 구성하는 3대 핵심 기초 기술이다 [3, 9]. 화면 크기(뷰포트 너비)뿐만 아니라 고해상도 디스플레이, 다크/라이트 모드 설정, 사용자의 애니메이션 축소 선호(`prefers-reduced-motion`) 환경 등 다양한 조건에 맞춰 세밀하게 스타일을 조정할 수 있다 [10, 11].
|
||||
* **모바일 우선(Mobile-First) 설계 전략:** 모바일을 위한 기본 스타일을 먼저 작성하고, 뷰포트가 커짐에 따라 `min-width` 미디어 쿼리를 사용하여 레이아웃의 복잡성을 확장해 나가는 방식이 권장된다 [7, 8]. 중단점(Breakpoint)은 특정 기기의 고정된 픽셀 크기에 맞추기보다는, 콘텐츠의 레이아웃이 깨지기 시작하는 지점(예: 360px, 768px, 1024px 등)을 기준으로 설정해야 한다 [2, 11, 12].
|
||||
* **성능 최적화 및 렌더링 차단 방지:** 브라우저는 기본적으로 모든 CSS 파일을 렌더링 차단(Render-[[Blocking]]) 리소스로 취급한다 [13, 14]. 하지만 HTML의 `<link>` 태그에 미디어 속성을 부여하여 조건별로 CSS를 분리하면(예: 인쇄용 스타일시트), 브라우저가 당장 사용하지 않을 스타일의 렌더링 차단을 방지하여 크리티컬 렌더링 패스를 최적화하고 로딩 속도를 높일 수 있다 [5, 13, 14].
|
||||
* **한계 및 최신 대안 기술과의 결합:** 미디어 쿼리는 '부모 컨테이너의 가용 공간'이 아닌 '브라우저 뷰포트 창 전체'에만 반응한다는 구조적인 한계가 있다 [6]. 2026년 기준으로는 이를 극복하기 위해 컴포넌트가 놓인 부모 요소의 크기에 반응하는 **컨테이너 쿼리(Container Queries)**가 컴포넌트 단위 설계의 새로운 표준으로 사용된다 [6, 15, 16]. 또한, 글꼴 크기 변경을 위해 수많은 미디어 쿼리를 작성하는 대신 `clamp()` 함수를 활용한 유체 타이포그래피([[Fluid Typography]])를 사용하면 코드를 크게 간소화할 수 있다 [17-19].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 웹 디자인 ([[Responsive Web Design]])]], 모바일 우선 설계 (Mobile-First), [[컨테이너 쿼리 (Container Queries)]], 렌더링 차단 최적화 (Render-Blocking [[Optimization]])
|
||||
- **Projects/Contexts:** 현대적인 CSS 실전 설계, 모듈형 컴포넌트 시스템 구축, 웹 성능 최적화 (Web Performance)
|
||||
- **Contradictions/Notes:** 미디어 쿼리는 뷰포트 창 크기 기준이기 때문에 맥락에 따라 크기가 달라지는 모듈형 컴포넌트의 재사용성을 완벽하게 보장하기는 어렵다. 소스에서는 이러한 한계를 보완하기 위해 현대 디자인 시스템에서 컨테이너 쿼리를 결합하여 사용할 것을 강하게 권장한다 [6, 16, 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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
id: wiki-2026-0508-미디어-쿼리-media-queries
|
||||
title: 미디어 쿼리(Media Queries)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[미디어 쿼리(Media Queries)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
미디어 쿼리(Media Queries)는 화면 크기, 해상도, 방향 등 뷰포트의 특정 조건에 따라 각기 다른 CSS 규칙을 적용하게 해주는 반응형 웹 디자인의 핵심 기술이다 [1-3]. 별도의 기기별 사이트를 구축하지 않고도 단일 코드베이스로 모바일, 태블릿, 데스크톱 화면에 맞춰 유연하게 적응하는 레이아웃을 만들 수 있게 해준다 [2, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **반응형 웹 디자인의 논리적 기반:** 미디어 쿼리는 화면의 너비나 해상도뿐만 아니라 가로/세로 방향(orientation), 다크 모드/라이트 모드 선호도 등 다양한 조건에 반응하여 레이아웃을 조정한다 [3, 5]. 여러 고정된 중단점(Breakpoints)보다는 콘텐츠가 자연스럽게 흐르도록 설계하는 것이 중요하며, 일반적으로 480px(모바일), 768px(태블릿), 1024px(소형 데스크톱), 1200px 이상 등의 중단점을 기준으로 활용한다 [5].
|
||||
* **모바일 우선(Mobile-First) 설계:** 디자인 및 CSS 작성 시 가장 작은 모바일 화면을 기준으로 기본 스타일을 먼저 구축한 후, `min-width` 미디어 쿼리를 사용하여 화면이 커짐에 따라 레이아웃의 복잡성을 추가하는 방식이 권장된다 [6, 7]. 이 방식은 불필요한 코드를 줄이고 렌더링 성능을 높이는 데 기여한다 [8].
|
||||
* **렌더링 블로킹(Render-[[Blocking]]) 방지 및 성능 최적화:** 미디어 쿼리는 주요 렌더링 경로([[Critical Rendering Path]])를 최적화하는 데 중요한 역할을 한다 [9]. CSS 파일을 조건(예: 인쇄용 등)에 따라 여러 모듈로 분할하고 HTML의 `<link>` 태그에 `media` 속성을 부여하면, 브라우저는 파일을 다운로드하되 불필요한 상황에서는 렌더링을 차단하지 않아 초기 로딩 속도를 개선할 수 있다 [9, 10].
|
||||
* **접근성([[Accessibility]]) 제어:** `prefers-reduced-motion` 미디어 쿼리를 사용하면 사용자의 운영체제(OS) 수준의 애니메이션 선호도(예: 전정기관 장애가 있는 사용자를 위한 모션 감소)에 맞춰 애니메이션을 선택적으로 제공하거나 비활성화할 수 있다 [11, 12].
|
||||
* **뷰포트 쿼리의 한계와 컨테이너 쿼리([[Container Queries]])의 부상:** 기존 미디어 쿼리는 브라우저 창 전체(뷰포트)의 크기에만 반응하므로, 좁은 사이드바나 넓은 메인 영역과 같이 개별 컴포넌트가 처한 실제 공간의 크기 변화에는 대응하기 어려운 근본적인 한계가 있다 [13]. 2026년 현재는 이를 극복하기 위해 부모 컨테이너의 크기에 반응하는 컨테이너 쿼리(`@container`)가 새로운 표준으로 함께 사용되고 있다 [13-15].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 디자인(Responsive Design)]], [[컨테이너 쿼리(Container Queries)]], [[모바일 우선 설계([[Mobile-First Design]])]], [[CSS 성능 최적화(CSS Performance [[Optimization]])]], [[웹 접근성(Web Accessibility)]]
|
||||
- **Projects/Contexts:** 단일 코드베이스를 통한 멀티 디바이스(모바일/데스크톱) 웹 인터페이스 구축, [[렌더링 블로킹 방지를 위한 CSS 분할 및 로딩 최적화]]
|
||||
- **Contradictions/Notes:** 미디어 쿼리는 반응형 웹 디자인을 위한 훌륭한 도구이지만 브라우저의 전체 뷰포트 크기에만 의존한다는 한계가 있다. 따라서 최신 설계 시스템에서는 컴포넌트 수준의 맥락을 인지해야 하는 경우, 미디어 쿼리 대신 혹은 미디어 쿼리와 함께 컨테이너 쿼리(Container Queries)를 결합하여 사용하는 것이 모범 사례로 권장된다 [13, 15, 16].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+100
@@ -0,0 +1,100 @@
|
||||
---
|
||||
id: wiki-2026-0508-유동적-타이포그래피-fluid-typography
|
||||
title: 유동적 타이포그래피 (Fluid Typography)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[유동적 타이포그래피 ([[Fluid Typography]])]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
유동적 타이포그래피(Fluid Typography)는 미디어 쿼리나 중단점(breakpoint)에 따라 텍스트 크기가 갑자기 변하는 대신, 뷰포트(viewport)나 부모 컨테이너의 너비에 비례하여 폰트 크기가 매끄럽고 일정하게 크기가 조정되는 기법입니다 [1]. 이 기법은 모바일에서 제목이 과도하게 커지거나 데스크톱에서 본문 텍스트가 너무 작아지는 문제를 해결해 주며, 모든 화면 크기에서 편안한 가독성을 제공합니다 [2, 3]. 최신 반응형 디자인에서는 주로 CSS의 `clamp()` 함수와 상대 단위(rem, em, vw 등)를 결합하여 구현되며, 복잡한 미디어 쿼리의 필요성을 줄여 유지보수성을 높여줍니다 [2, 4, 5].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **동작 원리 및 `clamp()` 함수의 활용**
|
||||
* 유동적 타이포그래피는 주로 `vw`(뷰포트 너비), `vi`(뷰포트 인라인 크기), 또는 컨테이너 너비인 `cqi` 단위를 활용하여 구현됩니다 [6, 7]. 이를 통해 수많은 중단점을 수동으로 계산할 필요 없이 모든 크기에서 보간(interpolate)된 폰트 크기를 제공할 수 있습니다 [8].
|
||||
* 크기를 제어하기 위해 CSS `clamp(최솟값, 선호값, 최댓값)` 함수가 널리 사용됩니다 [3, 5, 9]. 예를 들어 `font-size: clamp(1.5rem, 2vw + 1rem, 3rem);`으로 설정하면, 브라우저가 화면의 가용 공간에 따라 지정된 최솟값과 최댓값 사이에서 폰트 크기를 유동적으로 조정합니다 [4].
|
||||
|
||||
* **사용자 접근성([[Accessibility]])과 단위 선택**
|
||||
* 순수하게 뷰포트 단위(`vw` 등)만 사용하여 폰트 크기를 고정하면, 사용자의 브라우저 확대/축소(Zoom) 기능이나 기본 폰트 크기 설정이 무력화되는 접근성 문제가 발생합니다 [10, 11].
|
||||
* 이를 해결하기 위해 `px` 대신 `em`이나 `rem` 같은 상대 단위를 사용하여 최솟값과 최댓값을 정의해야 합니다 [5, 12]. 이는 사용자의 기본 폰트 설정을 존중하면서도 유동적인 크기 조절을 가능하게 합니다 [5].
|
||||
* 웹 콘텐츠 접근성 지침(WCAG 1.4.4)에 따라 텍스트가 200%까지 확대될 수 있도록 보장해야 하며, 이를 위해 최대 폰트 크기가 최소 폰트 크기의 2.5배를 초과하지 않도록 설정하는 "2.5x 규칙(2.5x Rule)"을 따르는 것이 업계의 모범 사례입니다 [11, 13, 14].
|
||||
|
||||
* **CSS 아키텍처 및 유지보수 측면의 이점**
|
||||
* 유동적 타이포그래피는 픽셀 기반의 고정된 너비 리스트를 관리하고 중단점마다 폰트 크기를 재정의해야 했던 기존의 방식과 비교할 때 작성해야 할 CSS 코드 양을 크게 줄여줍니다 [4].
|
||||
* 최신 프론트엔드 환경에서는 화면 전체 뷰포트 기준의 반응형 설계에서 컴포넌트 중심의 설계로 사고가 전환됨에 따라, 컨테이너 쿼리([[Container Queries]])와 유동적 타이포그래피를 결합하여 부모 컨테이너의 크기에 맞게 텍스트가 유연하게 적응하도록 만듭니다 [7, 15].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 웹 디자인 ([[Responsive Web Design]])]], [[컨테이너 쿼리 (Container Queries)]], 웹 접근성 (WCAG 1.4.4), CSS 함수 (clamp, calc)
|
||||
- **Projects/Contexts:** 현대적 반응형 웹 디자인 및 컴포넌트 중심 CSS 아키텍처 환경
|
||||
- **Contradictions/Notes:** 뷰포트 단위를 사용하여 타이포그래피를 반응형으로 만드는 것은 시각적으로 부드러운 전환을 제공하지만, `100vw`와 같이 뷰포트 단위만 단독으로 사용할 경우 브라우저 줌이나 사용자의 기본 폰트 크기 설정을 무력화시켜 접근성에 심각한 악영향을 미치므로 반드시 `calc()`나 `clamp()`와 함께 상대 단위(`rem`/`em`)를 조합하여 사용해야 한다고 여러 소스에서 강하게 경고하고 있습니다 [10-12, 16].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
+92
@@ -0,0 +1,92 @@
|
||||
---
|
||||
id: wiki-2026-0508-컨테이너-쿼리-container-queries
|
||||
title: 컨테이너 쿼리(Container Queries)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[컨테이너 쿼리([[Container Queries]])]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
컨테이너 쿼리는 브라우저의 전체 뷰포트(창) 크기가 아닌, 해당 컴포넌트를 감싸고 있는 **부모 컨테이너의 크기(사용 가능한 공간)**에 따라 스타일을 조정할 수 있게 해주는 모던 CSS 기능입니다 [1-3]. 이를 통해 페이지 레벨이 아닌 진정한 의미의 **컴포넌트 레벨 반응형 디자인**이 가능해지며, 2026년 현재 모듈식 UI 및 디자인 시스템 구축의 필수 표준 기술로 자리 잡았습니다 [1, 4].
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **기존 미디어 쿼리의 근본적 한계 극복:** 전통적인 반응형 웹 디자인은 화면(뷰포트)의 너비에 의존하는 미디어 쿼리를 사용했습니다. 하지만 이 방식은 동일한 카드 컴포넌트가 좁은 사이드바에 있을 때와 넓은 메인 영역에 있을 때 각기 다르게 렌더링되어야 하는 상황을 효율적으로 처리하기 어렵다는 치명적인 한계가 있었습니다 [1, 3]. 컨테이너 쿼리는 화면 크기가 아니라 부모 요소의 크기에 반응함으로써 이 문제를 해결합니다 [1-3].
|
||||
* **작동 방식 및 구현:** 컨테이너 쿼리를 사용하려면 먼저 부모 요소에 `container-type: inline-size;`와 같은 속성을 지정하여 쿼리의 기준이 될 컨테이너를 정의해야 합니다 [2, 3]. 그런 다음 `@container (min-width: 600px)`와 같은 구문을 사용하여 컨테이너의 크기 조건에 맞는 스타일을 하위 요소에 적용합니다 [1, 2].
|
||||
* **모듈화 및 재사용성의 극대화:** 컨테이너 쿼리의 도입은 반응형 디자인의 패러다임이 '페이지 중심'에서 '컴포넌트 중심'으로 이동했음을 의미합니다 [1, 5]. 컴포넌트가 자신이 놓인 환경(Context)을 스스로 인식하고 독립적으로 레이아웃을 조정하게 되므로, 대규모 애플리케이션의 다양한 맥락에서 컴포넌트를 재사용할 때 유연성과 탄력성이 크게 향상되며 이는 디자인 시스템의 작동 방식과 완벽히 일치합니다 [1, 3, 6].
|
||||
* **브라우저 지원 및 실무 적용 현황:** 2024년부터 모든 최신 브라우저에서 완벽히 지원되어 프로덕션 환경에 안전하게 사용할 수 있는 2026년의 반응형 웹 표준 기술입니다 [4, 7]. 실무에서는 복잡한 [[SaaS]] 대시보드나 이커머스에서 부모 너비가 좁아질 때 차트를 단순한 숫자 카드로 변경하거나, 데이터 테이블을 카드 스택 형식으로 자동 변환하는 등의 컨텍스트 기반 컴포넌트를 설계할 때 핵심적으로 활용됩니다 [6, 8].
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[반응형 디자인(Responsive Design)]], [[미디어 쿼리(Media Queries)]], [[디자인 시스템(Design[[ system]]s)]], [[모듈식 CSS(Modular CSS)]]
|
||||
- **Projects/Contexts:** [[대규모 프론트엔드 아키텍처(Scalable [[Frontend]] [[Architecture]])]], [[SaaS 대시보드 및 이커머스 UI 개발]]
|
||||
- **Contradictions/Notes:** 컨테이너 쿼리는 미디어 쿼리를 완전히 없애는 것이 아니라 그 한계를 보완하는 역할을 합니다. 반응형 디자인의 철학이 '뷰포트 중심'에서 '컴포넌트 중심'으로 진화하는 것을 보여주는 대표적인 기술 변화입니다 [5].
|
||||
|
||||
---
|
||||
*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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user