2026년의 CSS는 이미 다른 언어다. Container Queries, :has(), Scroll-driven Animations, View Transitions—이 기능들은 단순한 문법 추가가 아니라 UI 설계 방식 자체를 바꾸는 패러다임 전환이다. 그리고 마침 이 전환점에서 Claude Code 같은 AI 코딩 도구가 급속도로 현장에 들어오고 있다. 두 흐름이 만나는 지점에서 현실적인 질문이 생긴다. "최신 CSS를 AI로 빠르게 프로토타이핑하면 좋은 건데, 그 비용은 어떻게 제어할 것인가?"
먼저 CSS 쪽부터 짚어보자. dev.to에 올라온 CSS in 2026 기사가 정리한 현대 CSS의 핵심은 컴포넌트가 스스로 맥락을 읽는다는 것이다. Container Queries는 그 상징적인 기능이다. 뷰포트가 아니라 부모 컨테이너의 크기에 반응하는 이 기능은, 디자인 시스템에서 오랫동안 골칫거리였던 문제를 해결한다. 같은 카드 컴포넌트가 사이드바에 들어갈 때와 메인 콘텐츠 영역에 들어갈 때 다르게 보여야 하는 상황—이걸 미디어 쿼리로 억지로 잡다 보면 결국 변형 클래스가 늘어나고 컴포넌트 추상화가 깨진다. Container Queries가 있으면 컴포넌트 자체가 그 맥락을 알아서 처리한다.
:has() 역시 마찬가지다. 자식 요소 상태에 따라 부모를 스타일링할 수 있게 됐다는 건, 이제 JavaScript로 클래스를 토글하던 패턴의 상당 부분을 CSS로 흡수할 수 있다는 뜻이다. 폼 유효성 에러 상태, 배지 유무에 따른 카드 강조, 검색 포커스 시 나머지 네비게이션 흐리기—이런 마이크로 인터랙션들이 JS 없이 선언적으로 처리된다. View Transitions와 Scroll-driven Animations까지 더하면, 예전엔 복잡한 JS 애니메이션 라이브러리가 필요했던 페이지 전환 효과나 스크롤 연동 리빌 애니메이션을 CSS 몇 줄로 구현할 수 있다.
문제는 이 기능들이 아직 개발자들에게 충분히 내면화되지 않았다는 점이다. 브라우저 지원은 됐지만, 손에 익지 않은 문법이 많다. cqw, cqh 같은 Container Query 단위, color-mix(), oklch(), light-dark() 같은 색상 함수들은 MDN을 뒤지지 않으면 바로 쓰기 어렵다. 바로 이 지점에서 Claude Code 같은 AI 코딩 도구가 진짜 쓸모를 발휘한다. ":has()를 써서 폼 에러 상태를 부모 컨테이너에 반영하는 CSS 짜줘" 같은 요청에 즉각적으로 정확한 코드가 나온다. 최신 CSS 프로토타이핑의 마찰을 크게 낮춰준다.
그런데 여기서 또 다른 현실 문제가 끼어든다. AI 도구의 비용이다. Claude Code: I Had 10 Plugins Active at Once 라는 제목의 dev.to 기사는 아주 구체적인 교훈을 전한다. 저자는 €200 플랜에서 크레딧이 예상의 두 배 속도로 소진되는 이유를 추적했고, 범인은 동시에 활성화된 10개의 Claude Code 플러그인이었다. Claude Code 플러그인은 브라우저 확장처럼 필요할 때만 작동하는 것이 아니다. 활성화된 플러그인은 매 교환마다 시스템 프롬프트에 컨텍스트를 주입한다. 사용 여부와 무관하게.
수학은 단순하다. Sonnet 4.6 기준 입력 토큰은 백만 개당 $3. 플러그인 하나가 메시지당 약 2,000토큰을 주입한다면, 10개 플러그인은 교환 한 번에 2만 토큰을 추가한다. 50회 교환짜리 세션 하나에서 플러그인만으로 100만 토큰, 즉 $3이 조용히 빠져나간다. 자동화 모니터링 시스템까지 돌리고 있다면 복리로 쌓인다. 가장 불편한 진실은 인터페이스가 이걸 전혀 보여주지 않는다는 것이다. 기사의 표현을 빌리면, "플러그인을 켜고 잊어버리면 그것은 모든 교환에 조용히 무게를 얹는다."
이 두 흐름을 하나의 워크플로우로 연결해보면 실용적인 설계 원칙이 나온다. 최신 CSS 프로토타이핑에 AI를 쓸 때는 컨텍스트를 작업 단위로 제어해야 한다. Container Queries 레이아웃을 짜는 세션이라면 frontend-design 플러그인만 활성화하고 나머지는 꺼둔다. View Transitions 애니메이션 작업이라면 해당 기능 문서를 참조하는 플러그인만 켠다. 반복적으로 쓰는 CSS 패턴이나 디자인 토큰 규칙은 CLAUDE.md에 넣되, 최소한으로 유지한다. 파일 크기가 곧 비용이다.
더 넓게 보면, 이것은 CSS와 AI 도구 모두에 흐르는 같은 원칙이다. 선언적 최소화. Container Queries가 강력한 이유는 컴포넌트에 필요한 컨텍스트만 명시적으로 선언하기 때문이다. AI 플러그인을 효율적으로 쓰는 방법도 같다—필요한 컨텍스트만 명시적으로 활성화한다. 뭉뚱그려 다 켜두면 컴포넌트가 예측 불가능해지듯, 플러그인을 다 켜두면 토큰 소비가 예측 불가능해진다.
전망은 긍정적이다. 2026년의 CSS는 JavaScript 의존도를 낮추면서도 더 풍부한 인터랙션을 가능하게 하는 방향으로 진화했다. 그리고 AI 도구는 이 새 문법의 진입장벽을 실질적으로 낮춰주고 있다. 다만 그 도구를 제대로 쓰려면 비용 구조를 이해하고, 컨텍스트를 의도적으로 설계하는 습관이 필요하다. CSS가 맥락을 읽는 컴포넌트를 만들어주는 것처럼, 개발자는 AI가 읽을 컨텍스트를 의도적으로 설계해야 한다. 도구가 강력해질수록 설계의 책임은 더 선명해진다.