donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.4 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

Tailwind CSS — Styling with Utility Classes (Core Concepts)

Layer: raw/ — 외부 자료(공식 문서 / 대기업 기술 블로그)의 원문 발췌·출처 기록.

source_type 허용값

official-doc — Tailwind Labs 공식 레퍼런스 문서(Core Concepts 섹션).

Parent / 활용 branch

특정 branch 없이 foundational 조사로 수집 — ca-skeleton-frontend project-note hub 의 styling 스택 결정(§6 기술 결정) 근거 자료.

Branch/Project	이 자료가 정당화하는 결정
raw/project-notes/ca-skeleton-frontend-operational-contract	프로젝트 styling 스택으로 Tailwind CSS(utility-first) 채택의 공식 근거 — utility-first 접근 방식의 정의, 테마 기반 design constraint 메커니즘, 그리고 Tailwind 스스로 인정하는 "전통적 CSS best practice 와 상충한다"는 트레이드오프를 문서화

출처 / Source

원본 URL: https://tailwindcss.com/docs/styling-with-utility-classes
아카이브 URL: (미제공)
저자 / 조직: Tailwind Labs (공식 문서, Core Concepts 섹션)
발행일: 명시 없음 (페이지 상단 버전 표기: v4.3 — 조사 시점 최신 버전)
마지막 확인일: 2026-07-18

왜 저장했는지 / Why archived

ca-skeleton-frontend 프로젝트의 styling 스택으로 Tailwind CSS 를 선택하는 결정의 1차 공식 근거. utility-first 접근이 무엇인지, 이 방식이 (inline style 과 달리) 테마 기반 design token 제약을 통해 시각적 일관성을 보장한다는 점, 그리고 이 접근이 "전통적 best practice 와 상충"한다는 점을 Tailwind 스스로 인정하는 부분을 근거로 보존한다.

핵심 인용 / Key quotes (verbatim, 4문장)

[페이지 부제, H1 하단 — line 176] "Building complex components from a constrained set of primitive utilities."

[§Overview — line 176] "You style things with Tailwind by combining many single-purpose presentational classes (utility classes) directly in your markup:"

[§Overview, 5개 benefit 목록 직전 — line 197] "Styling things this way contradicts a lot of traditional best practices, but once you try it you'll quickly notice some really important benefits:"

[§Why not just use inline styles? — line 203] "Designing with constraints — using inline styles, every value is a magic number. With utilities, you're choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
TAILWIND-UTIL-C1	Tailwind 는 "제약된 primitive utility 집합"으로 복잡한 컴포넌트를 구성하는 접근을 공식적으로 표방한다	[페이지 부제] "Building complex components from a constrained set of primitive utilities."	`official-vendor-doc`	Tailwind CSS 전반의 설계 철학 서술 (버전 v4.3 시점)	이 표현만으로 성능/번들 크기/생산성 이점을 수치로 증명하지 않음
TAILWIND-UTIL-C2	Tailwind 의 utility-first 스타일링은 마크업에 직접 단일 목적(single-purpose) presentational class 를 조합하는 방식으로 정의된다	[§Overview] "You style things with Tailwind by combining many single-purpose presentational classes (utility classes) directly in your markup:"	`official-vendor-doc`	utility-first 방식론 자체의 정의 — 프레임워크 설명 문서	특정 프로젝트(ca-skeleton-frontend)에서 이 방식이 팀 생산성을 실제로 높인다는 것은 증명하지 않음(별도 실측 필요)
TAILWIND-UTIL-C3	Tailwind 공식 문서는 utility-first 방식이 "전통적인 CSS best practice 와 상충한다"는 점을 스스로 인정한다	[§Overview] "Styling things this way contradicts a lot of traditional best practices, but once you try it you'll quickly notice some really important benefits:"	`official-vendor-doc`	utility-first 채택 시 감수해야 할 관습적 반발/학습 곡선의 공식 인정 근거	"전통적 best practice"가 구체적으로 무엇인지(BEM, separation of concerns 등) 이 문장 자체는 명시하지 않음 — 일반적 진술
TAILWIND-UTIL-C4	inline style 과 달리 utility class 는 값이 "미리 정의된 디자인 시스템(predefined design system)"에서 선택되므로 임의의 magic number 를 방지하고 시각적 일관성 확보에 유리하다고 Tailwind 는 주장한다	[§Why not just use inline styles?] "using inline styles, every value is a magic number. With utilities, you're choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs."	`official-vendor-doc`	inline style 대비 utility class 의 design-token 제약 이점에 대한 공식 주장	이 페이지는 spacing/color scale 의 구체적 수치·구조를 서술하지 않음 — "predefined design system" 은 `/docs/theme` 페이지로 링크될 뿐, 본 raw 문서는 그 하이퍼링크 대상 페이지의 내용을 발췌하지 않았음(별도 조사 필요)

Strength 허용값 참고

본 문서의 모든 claim 은 official-vendor-doc — Tailwind Labs 공식 문서(Core Concepts 섹션)에서 직접 발췌. company-tech-blog 아님.

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- TAILWIND-UTIL-C1~C2: Tailwind CSS 의 utility-first 철학의 공식 정의
- TAILWIND-UTIL-C3: Tailwind 스스로 "전통적 best practice 와 상충"함을 인정한다는 사실
- TAILWIND-UTIL-C4: inline style 대비 "predefined design system(테마)" 기반 값 선택이라는 공식 주장
이 자료가 증명하지 않는 것:
- spacing/color scale 의 구체적인 토큰 값·구조 (해당 내용은 /docs/theme 별도 페이지 — 본 raw 에는 미포함, 하이퍼링크만 확인됨)
- ca-skeleton-frontend 프로젝트에서 Tailwind 채택이 실제 생산성·유지보수성을 개선했다는 실측 근거 (그건 wiki/projects/ 의 locally-verified/prod-verified 등급으로 별도 입증 필요)
- "전통적 CSS best practice"가 구체적으로 어떤 방법론(BEM, CSS Modules 등)을 가리키는지에 대한 상세 비교
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- /docs/theme 페이지를 별도 raw-source 로 발췌해 spacing/color scale 의 정확한 토큰 정의를 근거로 추가할 것
- ca-skeleton-frontend 실제 구현에서 Tailwind 채택 후 CSS 파일 크기·클래스 재사용 패턴을 로컬 검증할 것

메모 / Notes

검증되지 않은 추론은 여기에만. 인용 섹션은 verbatim only.

본 페이지는 Next.js App Router 기반 클라이언트 렌더링 페이지라 최초 WebFetch 결과가 원문을 paraphrase 하는 리스크가 확인됨(예: WebFetch 출력은 "Tailwind uses a utility-first approach where you style elements..."라고 표현했으나, 실제 원문은 "You style things with Tailwind by combining many single-purpose presentational classes (utility classes) directly in your markup:"). 이에 따라 curl 로 raw HTML 을 받아 Next.js RSC flight payload(self.__next_f.push)를 JSON 디코드하여 원문을 직접 추출 후 self-grep 검증함. 상세는 리포트의 "URL Fetch" 절 참고.
인용 4(TAILWIND-UTIL-C4)는 원문에서 "predefined design system" 부분이 <a href="/docs/theme"> 하이퍼링크로 감싸여 있어, 렌더링된 문장은 하나로 이어지지만 원본 JSON 구조상 두 조각으로 분리되어 있음 — self-grep 은 앞뒤 조각을 각각 독립적으로 대조(같은 <li> 블록 내 인접 텍스트임을 확인)하여 fabrication 이 아님을 검증함.
추가로 봐야 할 동일 출처 페이지: /docs/theme (spacing/color scale 토큰 정의), /docs/hover-focus-and-other-states, /docs/responsive-design

같은 주제 다른 official-doc: (아직 없음 — /docs/theme 페이지 발췌는 후속 raw 문서 후보)
이 자료를 인용한 wiki 요약: [[wiki/concepts/...]] (생성 시)

8.4 KiB Raw Permalink Blame History