102 lines
5.7 KiB
Markdown
102 lines
5.7 KiB
Markdown
---
|
|
id: wiki-2026-0508-scss
|
|
title: SCSS
|
|
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
|
|
---
|
|
|
|
# [[SCSS|SCSS]]
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
SCSS(Sassy CSS)는 일반 CSS에 프로그래밍 기능을 추가하여 능력을 확장하는 CSS 전처리기(Preprocessor)인 Sass의 한 구문(Syntax)입니다 [1, 2]. 변수, 중첩(Nesting), 믹스인(Mixins), 함수 등의 기능을 제공하여 보다 효율적이고 유지보수가 용이한 스타일시트를 작성할 수 있게 해줍니다 [1-3]. 세밀한 맞춤형 디자인 시스템과 복잡한 스타일 로직이 필요한 대규모 프로젝트에서 강력한 제어력을 제공합니다 [4].
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
* **핵심 기능 및 장점**
|
|
* **변수(Variables) 및 믹스인(Mixins):** 색상, 폰트 크기, 간격 등의 값을 변수로 저장하여 재사용할 수 있으며, 믹스인과 함수를 통해 매개변수가 있는 코드 스니펫이나 동적인 값을 생성할 수 있습니다 [1, 3, 5].
|
|
* **코드 조직화:** HTML 구조를 반영하는 중첩(Nesting)을 지원하며, 부분 파일(partials)과 import를 활용해 스타일시트를 작고 관리하기 쉬운 모듈로 나눌 수 있어 코드의 가독성과 유지보수성이 향상됩니다 [1, 6]. BEM 네이밍 컨벤션과 함께 사용하면 긴 클래스 이름 작성을 단순화할 수 있습니다 [7].
|
|
* **설계의 유연성:** 픽셀 퍼펙트(pixel-perfect)한 요구사항을 충족하거나 유니크한 맞춤형 디자인 시스템을 구축해야 할 때, 깨끗한 HTML 마크업(유틸리티 클래스 배제)을 유지하면서도 완벽한 디자인 제어가 가능합니다 [4, 8].
|
|
|
|
* **단점 및 한계점**
|
|
* **빌드 종속성 및 스코프 문제:** SCSS는 컴파일러나 빌드 도구 설정이 필요하며 컴파일 시간이 추가됩니다 [9, 10]. 모든 처리가 빌드 타임에 발생하므로 런타임 상태 변화에 동적으로 반응할 수 없습니다 [11].
|
|
* **글로벌 스코프(Global Scope):** 일반 CSS와 마찬가지로 스코프가 전역적이므로, 클래스 이름 충돌을 막기 위해서는 BEM과 같은 네이밍 규칙을 엄격하게 지키거나 [[CSS Modules|CSS Modules]]와 결합해야 합니다 [11-13].
|
|
* **복잡성 증가:** 구조를 체계적으로 잡지 않으면 프로젝트가 커질수록 코드를 관리하기 힘들어지고 최적화하지 않을 경우 CSS 파일 크기가 비대해질 수 있습니다 [9, 14]. 최근 JS 생태계에서는 이런 이유로 인기가 다소 하락하는 추세도 있습니다 [11].
|
|
|
|
* **[[Tailwind CSS|Tailwind CSS]]와의 비교 및 결합(Hybrid Approach)**
|
|
* Tailwind CSS는 유틸리티 클래스를 사용하여 빠른 개발과 일관성을 보장하지만 HTML이 지저분해지는 단점이 있는 반면, SCSS는 스타일 작성에 시간은 더 걸려도 완전한 디자인 제어와 깔끔한 마크업을 제공합니다 [4, 8, 15].
|
|
* 두 가지의 장점을 취하기 위해 SCSS 내에서 Tailwind의 `@apply` 디렉티브를 사용하거나 디자인 토큰(변수)을 공유하는 하이브리드 방식을 채택할 수 있습니다 [9, 16].
|
|
* 그러나 두 시스템을 혼합하면 빌드 설정이 복잡해지고, 학습 곡선이 가파라지며, 불필요한 번들 크기 증가(Bloat)가 발생할 수 있다는 단점이 있습니다 [10, 16, 17].
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
- **Related Topics:** [[Tailwind CSS|Tailwind CSS]], CSS Modules, [[BEM|BEM]]
|
|
- **Projects/Contexts:** 대규모 프론트엔드 코드베이스, 복잡한 커스텀 UI 컴포넌트 개발, 픽셀 퍼펙트(pixel-perfect) 디자인 요구사항이 있는 프로젝트, 레거시 스타일 시스템 통합 [4].
|
|
- **Contradictions/Notes:** SCSS는 강력하지만 본질적인 전역 스코프(Global scope) 문제를 가지고 있어 네이밍 충돌 위험이 있습니다. 이를 해결하기 위해 많은 실무 팀들은 SCSS 단독 사용보다는 `SCSS Modules`의 형태로 CSS Modules 기능과 결합하여 컴포넌트 단위의 로컬 스코프를 확보하는 방식을 선호합니다 [13, 18, 19].
|
|
|
|
---
|
|
*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: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)* |