흔히 CSS에서 tailwindcss 같은 유틸리티 우선 방법론(Utility-First)은 HTML에 클래스를 주렁주렁 매달아 놓는 것으로 생각하곤 함. 그러나 그것은 겉모양일 뿐이고 유틸리티 우선에서 핵심은 컴포넌트 구성 타이밍 문제. CSS 등장 초기 유행한 방법은 유지보수 악몽을 일으킴. OOCSS 조류는 컴포넌트 구성으로 문제를 해결하려 함. 재사용성이 올라갔지만 컴포넌트 범위 설정의 어려움이라는 문제에 부딪힘. 컴포넌트는 재사용성을 위한 것인데, 미래에 무엇이 재사용될지 알 수 없다는 문제 Atomic CSS 조류는 하나의 속성에 하나의 클래스만 할당함으로써 문제를 해결하려 함. 초기 개발 속도가 빨라졌지만 유지보수성 문제가 다시 등장. 단일 진실 공급원(Single Source of Truth)이 너무 쉽게 깨짐 - 전체 찾기 바꾸기에 의존 (외부 템플릿 의존은 번거롭고 한계 있음) 유틸리티 우선은 아토믹과 달리 컴포넌트를 긍정. 또한 OOCSS와 달리 유틸리티로 시작. 컴포넌트는 실제 필요할 때 구성하면 됨 무엇을 컴포넌트로 만들 것인가 하는 질문을 언제 만들 것인가 하는 질문으로 전환함 즉, 유틸리티 퍼스트는 둘을 종합, 계승/발전시킨 것으로 봐야 함. 따라서 유틸리티 퍼스트 방법론에서 컴포넌트는 좀더 강조될 필요가 있음. "우리는 컴포넌트를 허용한다"가 아니라 “우리는 컴포넌트가 정말로 필요한 시점까지 미룸으로써 재사용성을 극대화한다”가 돼야 함.

4 hours ago
1
![[인턴십] 2026 NAVER AI CHALLENGE를 소개합니다.](https://www.it.peoplentools.com/site/assets/img/broken.gif)









English (US) ·