"이거 왜 클래스가 이렇게 길어요?" — Tailwind 마이그레이션의 진짜 시작점
처음 Tailwind를 팀에 도입하자고 꺼냈을 때, 백엔드 개발자가 class="flex justify-between items-center gap-4 px-6 py-3 md:flex-col lg:flex-row" 를 보고 눈을 찡그렸던 기억이 납니다. "이게 더 가독성이 좋다고요?" — 네, 처음엔 저도 그랬습니다. 그런데 Figma 시안에서 spacing을 px 단위로 맞추다 보면, 결국 Tailwind의 4px 베이스 스케일이 얼마나 설계자 친화적인지 느끼게 됩니다.
핵심 이슈: 기계적 치환 vs. 구조적 재설계
dev.to에 최근 올라온 마이그레이션 가이드(CSS to Tailwind: The Complete Migration Guide for 2026)는 속성별 대응표를 꼼꼼하게 정리해뒀습니다. display: flex → flex, margin: 0 auto → mx-auto, position: sticky → sticky 같은 1:1 매핑은 사실 DevToolBox 같은 컨버터로 자동화할 수 있어요. 문제는 그 이후입니다.
Figma에서 padding: 24px를 확인하고 p-6으로 옮기는 건 5초짜리 작업이에요. 그런데 디자이너가 padding: 20px을 썼다면? Tailwind의 기본 스케일엔 없습니다. p-5는 20px이 아니라 1.25rem(20px) 이니 맞긴 한데, 프로젝트 기준이 px냐 rem이냐에 따라 1px짜리 오차가 생깁니다. 이거 px 단위로 봐야 해요, 진짜로.
맥락 해석: 반응형 전략이 바뀌는 순간
개인적으로 Tailwind의 가장 큰 가치는 인라인 반응형입니다. 기존 CSS에서 미디어 쿼리를 3개 파일에 나눠 쓰다 보면, @media (min-width: 768px) 블록이 어디 있는지 찾느라 파일 탐색기를 헤매게 되죠. Tailwind는 이걸 text-sm md:text-base lg:text-lg 한 줄로 압축합니다.
이 방식이 진짜 빛나는 건 모바일 퍼스트 원칙이 코드 레벨에서 강제된다는 점입니다. Tailwind의 브레이크포인트(sm: 640px, md: 768px, lg: 1024px, xl: 1280px)는 접두사 없는 클래스가 모바일 기본값이 되도록 설계되어 있어요. Figma에서 모바일 프레임 먼저 잡고 데스크탑을 확장하는 워크플로우와 딱 맞습니다. 디자이너와 협업할 때 "이 컴포넌트 모바일 먼저 봐주세요"를 코드로 강제할 수 있다는 건 생각보다 팀 컨벤션에 큰 영향을 줍니다.
그런데 a11y는요? — Tailwind가 침묵하는 영역
가이드가 색상 스케일(gray-700, blue-50, red-500)과 다크모드(dark:bg-gray-900)를 다루는 방식은 깔끔합니다. 그런데 WCAG 컬러 대비 기준은 Tailwind가 보장해주지 않습니다. text-gray-400 bg-white 조합은 Lighthouse에서 접근성 점수를 갉아먹는 대표적인 패턴이에요.
사용자 입장에서는 text-red-500이 에러 메시지인지 강조 텍스트인지 색상만으로 구분하기 어렵습니다. Tailwind를 도입한다고 aria-live, role="alert", aria-label 같은 시맨틱 마크업이 자동으로 따라오진 않아요. 클래스가 아무리 유틸리티 퍼스트여도, HTML 구조가 의미를 잃으면 스크린리더 사용자는 그냥 배제됩니다. Tailwind는 스타일 레이어만 건드립니다. a11y는 개발자 몫입니다.
커스텀 컬러를 임의값으로 쓸 때(bg-[#1a73e8])는 특히 조심해야 해요. 디자인 토큰으로 관리하지 않으면 나중에 브랜드 컬러가 바뀔 때 grep으로 하드코딩된 헥스값을 전부 찾아야 합니다. 이건 그냥 기술 부채입니다.
시사점: 점진적 마이그레이션이 답인 이유
가이드에서 가장 현실적인 조언은 리프 컴포넌트부터 전환하라는 것입니다. 버튼, 뱃지, 인풋 같은 원자 단위부터 Tailwind로 바꾸고, 레이아웃 컴포넌트는 나중에 올라가는 전략. 이게 맞습니다.
- 설계 우선:
tailwind.config.js에 디자인 토큰(색상, 폰트, spacing 스케일)을 먼저 정의하세요. Figma Dev Mode에서 추출한 값을 그대로 넣으면 디자이너와 개발자 간 싱크가 훨씬 쉬워집니다. - 컴포넌트 격리: 신규 컴포넌트는 Tailwind, 레거시는 기존 CSS.
@layer디렉티브로 충돌을 방지하세요. - 번들 확인: Tailwind v4부터 CSS-native 방식으로 바뀌면서 번들 최적화 방식도 달라졌습니다. PurgeCSS 설정 대신 content 경로 설정이 핵심이에요. 빌드 후 번들 사이즈 꼭 체크하세요.
- Storybook 연동: 컴포넌트 단위 전환 시 Storybook에 먼저 올려서 반응형과 다크모드, 포커스 스타일까지 검수하는 게 나중에 QA 비용을 아낍니다.
참고로 가이드에서 Tailwind를 쓰지 말아야 할 케이스도 명시하고 있는데, 복잡한 키프레임 애니메이션, JavaScript로 런타임에 동적으로 바뀌는 스타일, 서드파티 컴포넌트 오버라이드, 이메일 HTML은 여전히 인라인 CSS나 별도 클래스가 현실적입니다.
전망: Tailwind는 도구가 아니라 '협업 언어'다
결국 Tailwind 전환의 핵심은 CSS 문법을 교체하는 게 아니라, 팀이 디자인을 이야기하는 언어를 맞추는 것입니다. 디자이너가 spacing-4라고 말하고 개발자가 p-4로 받아치는 순간, Figma 시안과 코드 사이의 갭이 줄어들기 시작합니다.
다만 a11y는 어떤 CSS 방법론을 써도 개발자가 의식적으로 챙겨야 합니다. 로딩 스켈레톤에 aria-busy="true" 넣고, 에러 메시지에 role="alert" 달고, 포커스 링 스타일 focus-visible:ring-2 focus-visible:ring-blue-500 빠뜨리지 않는 것 — 이런 디테일이 Lighthouse 접근성 점수와 실제 사용자 경험 사이의 거리를 좁힙니다. 1px 어긋난 여백만큼, 놓친 aria 속성 하나가 누군가의 사용 경험을 망가뜨릴 수 있습니다.