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

10_Wiki/Topics/AI_and_ML/Tailwind vs 일반 CSS 비교.md

@@ -1,9 +1,26 @@
+---
+id: wiki-2026-0508-tailwind-vs-일반-css-비교
+title: Tailwind vs 일반 CSS 비교
+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)
+---
+
 # [[Tailwind vs 일반 CSS 비교|Tailwind vs 일반 CSS 비교]]
 
-## 📌 Brief Summary
+## 📌 한 줄 통찰 (The Karpathy Summary)
 [[Tailwind CSS|Tailwind CSS]]는 미리 정의된 유틸리티 클래스를 HTML에 직접 조합하여 빠르게 UI를 구축하는 '유틸리티 퍼스트(Utility-first)' 프레임워크로, 개발 속도와 디자인 일관성을 극대화합니다 [1-3]. 반면, 일반 CSS(Vanilla CSS 및 [[SCSS|SCSS]] 같은 전처리기 포함)는 별도의 스타일시트에 커스텀 규칙을 작성하는 전통적 방식으로, 픽셀 단위의 정밀한 제어와 깔끔한 HTML 마크업 유지에 유리합니다 [4-6]. 두 방식은 각각 HTML의 장황함(Tailwind)과 전역 스코프 제어 및 파일 크기 증가(일반 CSS)라는 명확한 장단점을 가지며, 프로젝트의 규모와 요구사항에 따라 선택되거나 실무에서 혼합되어 사용됩니다 [7-13].
 
-## 📖 Core Content
+## 📖 구조화된 지식 (Synthesized Content)
 **1. 접근 방식 및 철학**
 *   **일반 CSS 및 SCSS:** 전통적인 CSS는 전역 선택자(Global selectors)를 기반으로 작동하며, BEM과 같은 방법론을 통해 의미론적인 클래스명을 작성하여 요소를 스타일링합니다 [14, 15]. SCSS 등의 전처리기를 사용하면 변수, 중첩(Nesting), 믹스인 등을 통해 재사용 가능하고 고도로 커스텀 가능한 스타일 로직을 작성할 수 있습니다 [4, 16]. 
 *   **Tailwind CSS:** 기존의 '관심사의 분리([[_뇌와 팔다리의 분리_ - 관심사의 분리 (Separation of Concerns)|Separation of Concerns]])' 원칙을 깨고 기능적이고 단일 목적을 가진 작은 클래스(예: `flex`, `pt-4`)들을 HTML 내에 직접 작성하는 유틸리티 퍼스트 접근법을 취합니다 [1, 17, 18].
@@ -19,10 +36,41 @@
 **4. 실무 적용 및 하이브리드 전략**
 *   2025~2026년의 실무 개발 환경에서는 프로젝트 특성에 맞춰 두 접근법을 혼합(Hybrid)하는 경우가 많습니다. 예를 들어, 레이아웃과 간격 등 일관성과 개발 속도가 중요한 부분에는 Tailwind를 사용하고, 복잡한 애니메이션이나 세밀한 선택자 제어가 필요한 개별 컴포넌트에는 SCSS나 CSS Modules를 사용하는 전략이 채택되고 있습니다 [11, 13, 22].
 
-## 🔗 Knowledge Connections
+## 🔗 지식 연결 (Graph)
 - **Related Topics:** [[CSS 구조 설계 방식|CSS 구조 설계 방식]], [[디자인 시스템 개념|디자인 시스템 개념]]
 - **Projects/Contexts:** 대규모 프론트엔드 아키텍처 및 React 생태계에서의 스타일링 전략
 - **Contradictions/Notes:** Tailwind CSS는 개발 생산성과 CSS 용량 최적화 측면에서 훌륭하지만, 일각에서는 과거의 '인라인 스타일(Inline styles)'로 회귀하는 것과 같으며 HTML을 가장 못생기게(Ugliest possible code) 만든다는 강한 거부감과 논쟁이 커뮤니티 내에 지속적으로 존재합니다 [21, 23-25].
 
 ---
-*Last updated: 2026-04-26*
+*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 |