27개짜리 클래스 문자열, 누가 책임지는가
inline-flex items-center justify-center gap-2 rounded-md border border-transparent bg-blue-600 px-4 py-2 text-sm font-medium text-white shadow-sm hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:ring-offset-2 disabled:cursor-not-allowed disabled:opacity-50
이 문자열을 생성하는 데 AI는 0.3초도 걸리지 않는다. ChatGPT Codex는 이제 모바일에서도 실행되고, Claude Code는 백그라운드에서 조용히 PR을 올린다. 문제는 생성 속도가 아니다. 이 문자열이 6개월 뒤 무엇을 의미하는지, 아무도 설명할 수 없다는 것이다.
유틸리티 수프가 만들어내는 세 가지 부채
dev.to에 올라온 CSS 아키텍처 분석 글은 Tailwind 프로젝트가 유지보수 불능 상태로 빠져드는 패턴을 세 가지로 정리한다. 패턴 드리프트, 시맨틱 앵커 부재, 리팩터링 세금이다.
패턴 드리프트는 단순하다. 버튼 컴포넌트를 복사해서 클래스 두 개를 바꾸면, 코드베이스에 95% 닮은 버튼이 두 개 생긴다. 1년 뒤엔 열두 개가 된다. 시맨틱 앵커 부재는 더 치명적이다. 디자이너가 "primary 버튼을 조금 덜 강하게"라고 하면, bg-blue-600을 grep으로 전수 수색해야 한다. 리팩터링 세금은 CSS 변수가 해결하려고 발명된 바로 그 문제를 다시 불러온다. 색상 토큰 하나를 바꾸려면 템플릿 전체를 find-and-replace해야 한다.
핵심은 유틸리티 클래스 자체가 나쁜 게 아니라는 점이다. 문제는 이름 짓기라는 단계를 건너뛰었다는 것이다.
AI 코드 생성이 이 문제를 증폭시킨다
OpenAI는 최근 ChatGPT 모바일 앱에 Codex를 통합했다. iOS와 Android 모든 플랜에서 사용할 수 있고, 다른 기기에서 실행 중인 Codex 워크플로를 폰으로 모니터링하고 승인까지 할 수 있다. 두 달 사이 세 번의 연속 업데이트다. Anthropic의 Claude Code 역시 전문 개발자 사이에서 빠르게 점유율을 넓히고 있다.
이 경쟁의 결과는 명확하다. AI 코딩 에이전트는 Tailwind 클래스를 점점 더 빠르게, 점점 더 많이 생성할 것이다. 그리고 그 결과물은 각자의 컨텍스트 안에선 완벽하게 작동하는 유틸리티 수프다. AI는 '이 버튼이 지금 어떻게 보여야 하는가'는 알지만, '이 버튼이 우리 디자인 시스템에서 무엇인가'는 묻지 않는다.
설계 원칙: 레이어드 CSS 구조
앞서 언급한 분석 글이 제안하는 구조는 사실 새롭지 않다. 2015년에도 있던 CSS 아키텍처다. 다만 @layer, CSS 커스텀 프로퍼티, 네이티브 네스팅이 안정 브라우저에 모두 올라온 지금은, 그 설계가 훨씬 명쾌하게 구현된다.
1단계: 토큰을 시맨틱하게 정의한다.
--color-blue-600이 아니라 --color-accent로 이름 짓는다. 리브랜딩이 올 때 바꿀 곳이 한 곳이다.
2단계: @layer로 캐스케이드를 명시한다.
reset → base → components → utilities 순서를 선언하면, 특이성 전쟁이 사라진다. 레이어 순서가 특이성을 이긴다.
3단계: 컴포넌트에 이름을 돌려준다.
.button--primary라는 클래스 하나가 27개짜리 문자열을 대체한다. 마크업이 다시 읽힌다.
4단계: 유틸리티는 20개 이하로 제한한다. 진짜 one-off에만 쓴다. 2000개짜리 유틸리티 레이어가 아니라.
이름 짓기는 개발자만 할 수 있는 판단이다
Phil Karlton의 유명한 말처럼 이름 짓기는 컴퓨터 과학에서 가장 어려운 문제 중 하나다. Tailwind는 이 문제를 "이름 필요 없이 시각을 기술하라"는 방식으로 우회했다. AI 에이전트는 그 우회로를 더 빠르게, 더 많이 달린다.
그러나 코드베이스는 단일 컴포넌트가 아니라 어휘(vocabulary) 다. .card, .button--primary 같은 이름은 그 요소가 우리 디자인 시스템에 개념으로 존재한다는 선언이다. 그 선언이 있어야 팀원이, 그리고 6개월 뒤의 나 자신이 클래스 27개를 하나씩 읽지 않고도 변경 범위를 추론할 수 있다.
AI가 코드를 빠르게 생성할수록, 이 어휘를 설계하는 판단은 오히려 더 중요해진다. 에이전트는 기존 어휘를 그대로 따라간다. 어휘가 없으면 에이전트는 매번 자기만의 방언을 만들어낸다.
실천 가이드: 내일 당장 시작하는 두 가지
전체 마이그레이션이 부담스럽다면 작은 것부터 시작할 수 있다.
첫째, 토큰 파일 하나를 만든다. 프로젝트에서 가장 자주 쓰는 색상 5개와 spacing 스케일을 --color-accent, --space-4 형태로 옮긴다. 이것만 해도 리브랜딩 비용이 극적으로 줄어든다.
둘째, 신규 컴포넌트부터는 이름을 붙인다. AI가 생성한 Tailwind 클래스 덩어리를 받았다면, 그것을 컴포넌트 CSS로 추출하고 의미 있는 클래스명을 붙이는 것을 PR의 완료 조건으로 삼는다.
기존 컴포넌트를 당장 바꾸지 않아도 된다. 새로 만드는 것부터 다르게 하면 코드베이스의 어휘가 점진적으로 회복된다.
전망: 설계 판단력이 희소 자원이 된다
Codex와 Claude Code의 경쟁은 AI 코드 생성의 속도와 접근성을 계속 높일 것이다. 모바일에서도, 백그라운드에서도, 브라우저 안에서도. 그 흐름은 막을 수도 없고, 막을 이유도 없다.
단, AI가 쏟아내는 코드의 품질은 그 코드가 놓이는 시스템의 품질에 수렴한다. 디자인 토큰이 없는 프로젝트에 AI를 붙이면 하드코딩된 hex 값이 더 빠르게 쌓인다. 레이어 설계가 없으면 특이성 충돌이 더 빠르게 번진다. 컴포넌트 어휘가 없으면 방언이 더 빠르게 늘어난다.
AI 시대 프론트엔드 개발자의 핵심 역량은 코드를 타이핑하는 속도가 아니다. 시스템이 어떤 어휘를 가져야 하는지, 어디서 이름을 부여해야 하는지, 레이어를 어떻게 나눠야 하는지 판단하는 설계 원칙이다. AI가 빠를수록, 그 판단을 명확하게 가진 개발자와 그렇지 않은 개발자의 차이는 더 빠르게 벌어진다.