Oxlint 플러그인이 Tailwind CSS 클래스 표기를 자동으로 정규화함

이 플러그인의 가장 큰 가치는 새로운 스타일 기능을 추가하는 데 있지 않고, 팀마다 달라지기 쉬운 Tailwind 클래스 표기를 저장소 전체에서 일관되게 만드는 데 있다고 봅니다. mt-[16px]을 mt-4로, [@media_print]:flex를 print:flex로 바꾸는 작업은 사람이 일일이 검토하기에는 작지만 반복적인 비용이 큽니다. oxlint --fix 한 번으로 이를 자동화한다는 점은 코드 리뷰의 관심을 더 중요한 UI 구조와 동작에 집중하게 만들 가능성이 큽니다.

특히 Tailwind 언어 서버와 동일한 제안을 적용한다는 점이 신뢰도를 높입니다. 개발자가 에디터에서 보던 권장 표기와 CI 또는 일괄 수정 단계에서 적용되는 표기가 달라지면 자동화 도구는 오히려 혼란을 낳을 수 있습니다. 이 플러그인은 그 간극을 줄이는 방향으로 설계됐고, text-[red]/50처럼 의미는 유지하면서 더 표준적인 형태로 바꾸는 데 초점을 둡니다. 이런 일관성은 클래스 문자열을 검색하거나 리뷰할 때도 분명한 이점이 있습니다.

다만 이 도구를 Tailwind 전체 정리 도구로 이해하면 안 됩니다. 플러그인이 바꾸는 것은 개별 클래스의 표기뿐이며, 유틸리티 순서 변경과 중복 제거, 유틸리티 병합은 수행하지 않습니다. 따라서 저장소의 클래스 품질을 완성하려면 oxfmt의 sortTailwindcss 같은 별도 도구가 필요합니다. 정규화와 포맷팅을 한 도구가 모두 해결해 줄 것이라는 기대를 미리 차단한 점은 오히려 장점일 수 있지만, 도입 전에 두 도구의 책임 범위를 팀 규칙으로 분명히 해야 합니다.

도입 장벽은 분명합니다. Tailwind CSS v4와 Node 22 이상이 필요하고, Tailwind v4 진입 CSS를 가리키는 cssPath도 반드시 설정해야 합니다. 이미 최신 Node와 v4를 사용하는 프로젝트라면 개발 의존성 설치 후 비교적 빠르게 적용할 수 있겠지만, 구버전 Tailwind를 유지하는 대규모 저장소에는 이 플러그인만을 위해 생태계를 올리는 선택이 부담스러울 가능성이 큽니다. 결국 기술적 효용보다 프로젝트의 업그레이드 일정이 채택 여부를 결정하게 될 겁니다.

설정의 세밀함은 실제 적용 범위를 넓혀 줍니다. class와 className뿐 아니라 attributes로 JSX 속성을 추가할 수 있고, cn, clsx, cva 같은 헬퍼 함수도 calleeFunctions에 등록할 수 있습니다. 반면 ${} 보간이 포함된 문자열은 건너뛰므로 동적 클래스가 많은 코드베이스에서는 자동 수정률이 낮을 수 있습니다. 이것은 안전한 보수성으로 볼 수 있지만, 정적 문자열과 동적 문자열을 구분해 관리하지 않으면 팀이 도구의 적용 범위를 과대평가할 수 있습니다.

결국 이 플러그인은 거대한 리팩터링 도구라기보다 작고 반복적인 규율을 자동화하는 린트 확장에 가깝습니다. CI에서 검사만 수행하고 개발자가 명시적으로 --fix를 실행하게 하거나, 변경량을 먼저 검토한 뒤 저장소에 적용하는 방식이 현실적입니다. Tailwind v4를 이미 채택한 팀이라면 낮은 위험으로 표기 불일치를 줄일 수 있어 도입 가치가 높고, 앞으로는 동적 클래스 분석이나 순서 정리 도구와 결합될 때 프런트엔드 스타일 품질 관리의 기반으로 자리 잡을 가능성이 있습니다.