CSS의 역사로 보는 AI 시대: 프레임워크는 무엇을 해결해야 할까?

AI에게 상품 카드 묶음을 만들어 달라고 했다고 가정해 봅시다. 첫 버전에는 이미지, 가격, 구매 버튼이 있고, 데스크톱에서는 세 열, 휴대전화에서는 한 열로 배치됩니다. 이어서 디자이너가 브랜드 색상을 바꾸고 같은 카드를 사이드바에도 넣어 달라고 합니다. 기존 키보드 포커스와 품절 상태는 유지해야 합니다.

두 번째 수정부터 문제가 드러납니다. 어떤 파란색이 브랜드를 뜻하고, 어떤 파란색이 정보를 알릴까요? 카드는 뷰포트와 컨테이너 중 어느 쪽에 맞춰 바뀌어야 할까요? AI가 버튼을 수정하면서 다른 페이지의 상호작용 상태까지 바꾸지는 않았을까요?

이 글에서는 이 가상의 사례를 바탕으로 묻습니다. AI가 스타일 작성 비용의 일부를 낮춘다면, 프레임워크는 변경·검증·협업의 어떤 비용을 줄여 줄 수 있을까요? CSS의 역사를 돌아보면 도구가 실제로 맡아 온 책임을 구분하고, 미래의 예측에도 확인할 수 있는 근거를 마련할 수 있습니다.

CSS의 출발점에는 제어권의 배분이 있었다

1994년 Håkon Wium Lie가 CSS를 제안했고, 이후 Bert Bos가 참여했습니다. CSS1은 1996년 W3C Recommendation이 되었고, CSS2는 1998년에 이어졌습니다. 핵심 설계 중 하나는 cascade입니다. 작성자, 사용자, 브라우저의 표현 요구를 같은 규칙 안에서 조정해야 했습니다. W3C의 역사 정리

이 출발점은 오늘날에도 의미가 있습니다. 스타일시트는 작성자의 의도를 표현하지만, 최종 결과는 사용할 수 있는 공간과 글꼴, 사용자 설정에도 영향을 받습니다. 선언으로 화면을 기술한다고 해서 모든 픽셀을 작성자 혼자 결정하는 것은 아닙니다.

초기 브라우저의 표준 구현도 서로 달랐습니다. 유효한 CSS를 작성하는 일과 여러 브라우저에서 받아들일 만한 결과를 얻는 일은 별개였습니다. 반복되는 차이를 공통 방식으로 정리하면 프로젝트마다 다시 해결할 필요가 없어집니다. 이렇게 호환성 지식도 도구 가치의 일부가 되었습니다.

이후 페이지는 더 많은 화면 크기에 대응해야 했습니다. Ethan Marcotte가 2010년에 제시한 반응형 웹 디자인은 유동 그리드, 유연한 이미지, media queries를 하나의 작업 방식으로 묶었습니다. 디자이너는 조건에 따라 배치가 어떻게 변하는지 설명해야 했고, 분기점과 레이아웃 규칙도 팀이 함께 관리할 자산이 되었습니다. 원문, 발행일 회고

CSS의 어려움은 브라우저가 규칙을 해석하는 방식과 사람이 규칙을 구성하는 방식 모두에 있습니다. 전자가 나아져도 후자가 저절로 해결되지는 않습니다.

팀의 공통 결정을 위해 도구가 성장했다

사이트가 커지면서 중복, 이름, 변경 범위가 중요한 문제가 되었습니다. Sass는 변수, mixin, 모듈, 계산을 빌드 시점에 CSS로 처리해 브랜드 설정과 공통 규칙을 모아 관리할 수 있게 합니다. 컴파일 단계가 추가되는 대신 소스 코드를 구성하는 기능을 얻습니다. Sass 가이드

Bootstrap은 공통 결정을 인터페이스 계층으로 확장했습니다. Twitter 내부 스타일 가이드로 시작해 2011년 공개되었고, 이후 버전들은 반응형 디자인, Flexbox, 사용자 지정 속성을 받아들였습니다. 이런 프레임워크의 도입은 기존 컴포넌트와 기본값의 도입이기도 합니다. 페이지마다 버튼, 폼, 그리드를 다시 결정하는 일을 줄여 줍니다. Bootstrap의 역사

다른 흐름은 스타일의 소속에 집중했습니다. BEM은 block, element, modifier라는 이름 규칙으로 구조와 변형을 표현합니다. CSS Modules는 class와 애니메이션 이름을 기본적으로 지역화하고 import로 의존 관계를 만듭니다. 전자는 공통 규율에, 후자는 빌드 도구에 의존해 이름 충돌을 줄입니다. 무엇을 공유하고 무엇을 컴포넌트 안에 남길지는 둘 다 팀의 판단이 필요합니다.

컴포넌트화는 CSS-in-JS도 가져왔습니다. styled-components에서는 스타일을 컴포넌트 가까이에 두고 props에 따라 바꿀 수 있습니다. 하지만 이 범주의 실행 모델이 하나인 것은 아닙니다. vanilla-extract는 TypeScript로 스타일을 기술하고 빌드 시점에 정적 CSS를 출력합니다. 작성 인터페이스, 생성물, 실행 시점을 따로 평가해야 비용을 정확히 볼 수 있습니다.

utility-first는 조합하는 위치를 markup으로 옮깁니다. Tailwind는 작은 class, 상태 변형, 디자인 척도를 조합해 사용하는 곳에서 스타일 선택을 볼 수 있게 합니다. 반복 조합은 여전히 정리해야 하고, 의미는 상위 컴포넌트가 맡을 수도 있습니다.

시간축으로 보면 책임이 점차 확장된 모습을 볼 수 있습니다. 아래 표는 맥락을 정리한 것이며, 같은 시기의 도구를 함께 사용할 수도 있습니다.

AI에 대한 시사점은 입력 속도가 도구 가치의 일부일 뿐이라는 점입니다. 프레임워크는 공통 결정을 보존해 다음 유지보수 담당자가 처음부터 추론하지 않도록 돕습니다.

네이티브 CSS가 맡는 일과 도구의 역할 변화

Flexbox는 한 차원에서 공간을 배분하고, Grid는 행과 열을 직접 표현합니다. 브라우저가 더 많은 배치 작업을 맡으면 팀은 그리드 추상화가 얼마나 더 필요한지 다시 판단할 수 있습니다.

사용자 지정 속성도 역할을 바꿉니다. Sass 변수는 컴파일 시점에 처리되지만, CSS 사용자 지정 속성은 출력에 남아 요소와 cascade에 따라 다른 값을 가질 수 있습니다. 브랜드나 테마 전환에서는 둘 다 “변수”라는 이름을 가진다는 사실보다 이 차이가 중요합니다. 함께 쓸 수 있지만 문법만 일대일로 바꿀 수는 없습니다. Sass의 차이 설명

네이티브 nesting은 선택자의 반복을 줄이지만 이름을 격리하지는 않습니다. @layer는 계층의 우선순위를 정할 수 있지만, 어떤 스타일 출처를 어느 계층에 넣을지는 팀이 결정해야 합니다. 출처, 중요도, 계층, 명시도, 순서가 모두 관련되므로 “나중에 쓴 규칙이 항상 이긴다”로 단순화할 수 없습니다.

처음의 카드에는 container size queries가 특히 유용합니다. 뷰포트만 보는 대신 자신이 들어간 컨테이너 너비에 맞춰 배치를 바꾸면, 같은 데스크톱 창 안에서도 본문과 사이드바가 다르게 작동할 수 있습니다. 브라우저가 표현 능력을 제공하더라도 언제 배치를 바꿀지는 설계 결정입니다.

이런 기능을 사용해 본 경험도 확인할 수 있습니다. State of CSS 2026의 All Features 차트와 내보내기 자료에서 :has() 문항은 3,822명 중 3,198명이 사용 경험이 있다고 답했고, 표시 비율은 83.7%입니다. CSS Nesting은 3,820명 중 2,695명, 표시 비율은 70.6%입니다. 분모는 각 기능 문항의 응답자 수이며, 백분율은 공식 표시 정밀도를 따릅니다. 웹사이트 전체의 보급률이나 실제 운영 프로젝트에서 지속해서 쓰는 비율을 뜻하지 않습니다.

현대 CSS는 한꺼번에 업그레이드하는 단일 버전도 아닙니다. 모듈별로 발전하므로 명세 상태와 브라우저 보급을 구분해야 합니다. CSS Snapshot 2026 역시 명세의 안정성과 구현의 보급 정도를 구분합니다. 네이티브 @mixin은 아직 실험적 초안으로 읽어야 합니다. 규칙 재사용을 다룬 별도 글이 있지만, 이를 곧바로 Sass에서 이전할 수 있다는 보장으로 받아들여서는 안 됩니다.

프레임워크도 네이티브 기능을 활용합니다. Tailwind v4는 CSS-first 설정, 사용자 지정 속성, cascade layers를 채택하고 container queries를 기본 지원합니다. 브라우저의 발전은 도구가 보완해야 할 일을 줄이는 동시에 더 풍부한 조합 인터페이스를 제공하게 할 수도 있습니다.

조사가 보여 주는 현재: 도구는 공존하고 AI가 모든 일을 맡지는 않는다

State of CSS 2026에서 사용하는 CSS 프레임워크를 묻는 문항에는 3,697명이 응답했습니다. 아래는 일부 선택지의 인원입니다. 복수 응답이므로 항목이 겹칠 수 있고, 합쳐서 시장을 나눈 점유율로 볼 수 없습니다. 도구 조사

이 선택들은 서로 다른 계층에 있습니다. shadcn/ui와 Tailwind는 함께 쓸 수 있으며, None을 “아무 도구도 쓰지 않는다”로 해석할 수도 없습니다. 설문의 분류는 응답을 모으기 위한 것이며, 구조를 분석할 때는 스타일 생성, 상호작용 컴포넌트, 코드 배포를 구분해야 합니다.

같은 해의 CSS AI Code Generation 문항은 자신이 만드는 CSS 가운데 AI가 생성한 비율을 묻습니다. 3,732명이 보고한 비율의 공식 중앙값은 약 13%입니다. 980명이 0%라고 답해 이 문항 응답자의 약 26.3%를 차지합니다. 이 중앙값은 개인별 비율을 설명하며, 전 세계 CSS 코드의 AI 생성량을 추정하는 수치는 아닙니다.

예측의 출발점은 이처럼 구체적이어야 합니다. AI는 일부 사람들의 작업에 들어왔지만, 이 조사만으로 대부분의 CSS 작업을 맡고 있다고 주장할 수는 없습니다. 생성 품질에 대한 의견도 통제 실험이 아니므로 모델이 일반적으로 잘한다거나 못한다고 단정할 근거가 되지 못합니다.

주최 측이 프레임워크를 사용하지 않는 선택과 LLM을 연결한 논평도 하나의 해석입니다. 프로젝트 유형, 팀의 선호, 네이티브 기능의 발전 같은 요인은 배제되지 않았습니다. 숫자만으로 AI가 프레임워크 사용의 변화를 일으켰다고 증명할 수 없습니다. 이 글은 이를 바탕으로 가설을 세우고, 성립에 필요한 엔지니어링 조건을 살펴봅니다.

두 번째 수정은 규칙을 알아볼 수 있는지 시험한다

상품 카드로 돌아갑시다. 다음은 테두리와 여백만 보여 주는 가상의 첫 버전입니다.

.site-product-card {
  border: 1px solid #45687d;
  padding: 1.5rem;
}

“브랜드 색상을 바꿔 달라”는 요청을 받아도 이 코드는 테두리 색의 역할을 설명하지 않습니다. AI가 프로젝트 전체를 검색할 수 있어도 같은 색상 값을 쓰는 다른 부분까지 바꿀지 판단해야 합니다. 같은 값이 같은 의도를 보장하지는 않습니다.

요구가 “주요 상품에만 브랜드색 테두리를 쓰고 나머지는 중립색을 유지한다”로 확인되었다면 공통 규칙과 변형을 표현할 수 있습니다. 다음 코드는 앞의 코드를 대체합니다. 카드는 .site-product-slot 안에 있고, 주요 카드에 data-featured가 있으며, 브랜드 속성은 조상 요소에 있다고 가정합니다.

:root {
  --border-neutral: #777777;
  --accent-brand: #45687d;
  --space-card: 1.5rem;
}
 
[data-brand="forest"] {
  --accent-brand: #406b57;
}
 
.site-product-slot {
  container: product / inline-size;
}
 
.site-product-card {
  display: grid;
  gap: 1rem;
  padding: var(--space-card);
  border: 1px solid var(--border-neutral);
}
 
.site-product-card[data-featured] {
  border-color: var(--accent-brand);
}
 
@container product (width >= 30rem) {
  .site-product-card {
    grid-template-columns: minmax(0, 1fr) 2fr;
  }
}

카드의 직접 자식은 이미지 영역과 내용 영역 두 개라고 가정합니다. 30rem은 이 사례에서 정한 조건입니다. 바깥 컨테이너를 조회하므로 너비가 부족하면 한 열을 유지합니다. 테두리, 간격, 배치만 보여 주며, 버튼 포커스와 품절 동작은 기존 컴포넌트가 담당합니다.

상위 계층에서 컴포넌트를 조합한다면 더 좁은 API를 제공할 수도 있습니다. 다음은 기존 패키지에 속하지 않는 가상의 컴포넌트 API입니다.

<ProductCard
  product={product}
  emphasis="featured"
  availability="sold-out"
/>

이 이름들은 구현이 실제로 emphasis를 스타일에, availability를 문구와 동작에 연결할 때 가치가 있습니다. 타입은 전달할 값을 제한할 수 있지만 품절 버튼, 키보드 조작, 화면이 올바르다는 사실까지 증명하지는 못합니다. 임의의 값에 이름을 붙이는 일도 그 이름이 안정적인 공통 결정을 나타낼 때 다음 수정의 모호함을 줄여 줍니다.

네이티브 CSS, utility class, 컴포넌트 라이브러리 모두 이런 규칙을 담을 수 있습니다. AI가 필요로 하는 맥락에는 문법뿐 아니라 이미 존재하는 컴포넌트, 유효한 조합, 변경이 범위를 벗어나지 않았는지 확인하는 방법도 포함됩니다.

그래서 비용을 나누어 봅니다. 작성 비용은 낮아질 수 있지만 기존 규칙의 이해에는 여전히 맥락이 필요합니다. 변경은 공통 출처에 영향을 줄 수 있고, 검증은 테마·크기·상태를 포함해야 하며, 유지보수에는 업그레이드와 예외도 있습니다. 이는 분석 방법이지 실측한 시간 배분이 아닙니다. 생성이 빨라져도 검토가 느려진다면 팀은 전체 과정을 계산해야 합니다.

2026–2029년에 지켜볼 세 가지 변화

문법을 줄이는 것만으로는 도입 이유가 약해질 수 있다

AI가 네이티브 CSS를 안정적으로 생성하고 수정할 수 있다면, 별도 문법으로 줄이는 입력 시간이 학습과 빌드 비용을 정당화하지 못할 수 있습니다. 기능이 단순하고 디자인 차이가 큰 사이트라면 의존성을 줄인 구성을 검토할 이유가 늘어날 것입니다.

하지만 utility-first에는 국소적인 조합, 디자인 척도, 팀의 관례도 있습니다. 성숙한 도구는 AI가 기존 예제를 따르기 쉽게 만들 수도 있습니다. 제가 압박을 받을 것으로 보는 것은 “몇 글자 덜 쓸 수 있다”는 이유이며, Tailwind나 다른 프레임워크의 쇠퇴를 단정하는 것은 아닙니다.

관찰할 신호는 같은 요구와 후속 수정을 더 적은 의존성으로, 같은 품질을 유지하고 사람의 보정도 줄이면서 수행할 수 있는지입니다. 네이티브 방식에 더 많은 맥락과 회귀 대응이 필요하다면 예측을 좁혀야 합니다. 설문에서 None의 순위가 오르는 것만으로는 충분하지 않습니다.

설계 제약과 검증 능력의 가치가 커질 수 있다

열 가지 카드 변형을 쉽게 만들 수 있다면 팀은 어떤 것을 남길지 더 분명히 결정해야 합니다. token, 유효한 변형, 상태별 예제, 회귀 검사는 기대하는 모습과 정확성의 기준을 재사용 가능한 근거로 만들 수 있습니다.

이 가치는 대형 프레임워크만의 것이 아닙니다. 작은 팀에는 명확한 CSS, 몇 개의 컴포넌트, 확인 절차면 충분할 수 있습니다. 여러 브랜드의 제품에는 더 완전한 디자인 시스템이 필요할 수 있습니다. 공통 전제는 규칙이 실제 요구에 맞고, 이를 유지할 사람이 있어야 한다는 것입니다.

새 인터페이스를 추가할 때 디자인 이탈과 회귀 문제가 줄고 검토 시간이 짧아지는지 보겠습니다. 규칙이 많아질수록 예외가 어려워지거나 테스트 갱신 비용이 이득을 넘는다면 무거운 제약은 가치가 없을 수 있습니다. AI가 검증을 도와 가벼운 구성만으로 충분해질 가능성도 있습니다.

프레임워크는 agent가 찾고 사용하는 방법에 더 신경 쓸 것이다

shadcn MCP는 이미 registry 컴포넌트를 찾아보고 검색하고 설치하는 인터페이스를 제공하며, 비공개 출처에도 연결할 수 있습니다. 맥락을 얻는 경로를 마련하고 있다는 증거지만, agent가 올바른 컴포넌트를 선택하고 수정한다는 보장은 아닙니다.

도구 제작자는 버전이 명확한 문서, 접근 가능한 소스, 조합 예제, 실행 가능한 검사에 더 신경 쓸 것으로 예상합니다. 사람이 배우기 쉬운지에 더해 agent가 올바른 버전을 찾고 제한을 이해하며 기존 프로젝트에 결과를 통합할 수 있는지도 평가하게 될 것입니다.

주류 생태계는 기본 통합에서 이익을 얻을 수 있지만, 검색의 개선은 작은 도구가 모델의 사전 지식에 의존하지 않게 할 수도 있습니다. 연결 후 API 오용, 기존 컴포넌트의 불필요한 재구현, 사람의 재작업이 줄어드는지가 관찰 지표입니다. 범용 코드 이해만으로 충분해지면 전용 인터페이스의 이점은 작아질 수도 있습니다.

다음 선택은 남겨야 할 책임에서 시작한다

엔지니어에게 cascade, 크기 계산, 레이아웃에 대한 이해는 여전히 유용합니다. 생성 결과가 예상에서 벗어날 때 문제를 실제 규칙으로 좁힐 수 있기 때문입니다. 프레임워크 제작자는 어떤 변경을 더 쉽게 만들고 어떻게 검증할 수 있는지 다시 설명할 수 있습니다.

기존 프로젝트에는 이전 비용도 있습니다. 새 방식으로 코드가 줄더라도 실제 변경 하나에서 이득을 확인한 뒤 안정적으로 운영 중인 공통 방식을 교체해야 합니다.

그 카드의 두 번째 수정에서는 브랜드 색상을 어디서 바꾸고, 사이드바 배치를 누가 결정하며, 품절과 포커스 상태를 어떻게 확인할지 분명히 답할 수 있기를 바랍니다. 이런 책임을 보존하고 전달하고 검증해야 하는 한 도구에는 역할이 있습니다. 앞으로 경쟁할 만한 가치는 한 번의 변경을 더 이해하기 쉽게 만들고, 요구를 충족했다고 더 쉽게 보여 주는 능력입니다.