프론트엔드 개발에서 '좋은 코드'와 '좋은 경험'은 종종 별개의 목표처럼 취급된다. DX(개발자 경험)는 내부 문제고, UX(사용자 경험)는 외부 문제라는 식으로. 그런데 최근 velog에 올라온 두 편의 글을 나란히 읽으면서, 이 구분이 생각보다 훨씬 얇다는 걸 다시 확인했다. 하나는 ESLint 커스텀 룰로 Tailwind className을 자동 정리하는 이야기고, 다른 하나는 브라우저 렌더링 파이프라인을 기반으로 CSS 애니메이션 성능을 분석한 이야기다. 주제는 달라 보이지만, 두 글이 공유하는 핵심 질문은 하나다. '이 선택이 시스템 전체에 어떤 영향을 미치는가?'
핵심 이슈 ① — className이 길어질수록 가독성은 무너진다
Tailwind CSS의 유틸리티 퍼스트 철학은 강력하지만, 그 대가로 className이 기하급수적으로 늘어나는 문제를 안고 있다. flex flex-col items-center justify-center min-h-screen gap-6 bg-amber-300처럼 8개 이상의 클래스가 한 줄에 쌓이는 건 Tailwind를 쓰는 팀이라면 누구나 경험하는 일이다. shadcn/ui 컴포넌트에 커스텀 스타일을 얹기 시작하면 10개, 12개도 금방이다.
이걸 cn() 유틸로 의미 단위로 쪼개는 패턴은 이미 많은 팀이 쓰고 있다. 문제는 이 정리 작업이 항상 수동이라는 것이다. 처음 코드를 쓸 때는 일단 한 줄로 쭉 적고, 나중에 길어진 걸 발견하면 그때 가서 cn()으로 감싸고, import도 추가하고, 줄바꿈도 잡아야 한다. 이 작업이 번거로우면 '그냥 두고 넘어가는' 일이 생기고, 코드베이스 전체에 걸쳐 일관성이 무너지기 시작한다.
velog 글(@doctorsean)이 제안한 해법은 ESLint 커스텀 룰로 이 정리 작업을 자동화하는 것이다. 임계값(threshold)을 넘는 className을 ESLint가 경고로 잡고, --fix 한 번으로 cn() 래핑과 import 추가까지 자동 완료되도록 만든다. 핵심은 여기서 '무엇을 자동화하고, 무엇을 자동화하지 않을지'를 명확히 선을 긋는 것이었다.
맥락 해석 ① — AST가 그어주는 안전의 경계
단순히 className 문자열의 길이를 grep으로 세는 것과, AST(Abstract Syntax Tree)를 통해 코드 구조를 파악하는 것은 차원이 다른 접근이다. 전자는 cn() 내부에 있는지, 조건부 표현식 안에 있는지, 템플릿 리터럴인지를 구별하지 못한다. 잘못된 위치에 자동 수정을 적용하면 cn() 안에 cn()이 중첩되거나, 런타임 값을 정적으로 변환하려다 동작이 깨질 수 있다.
그래서 이 룰은 className 값의 AST 형태를 정밀하게 분류한다. 단순 문자열 리터럴(Shape A)과 JSX 표현식 컨테이너 안의 리터럴(Shape B)만 자동 수정 대상으로 삼는다. 이 두 형태는 컴파일 타임에 값이 확정되기 때문에 변환 전후의 동작이 100% 동일함을 정적으로 보장할 수 있다. cn() 호출, 삼항 연산자, 템플릿 리터럴, 변수 참조는 경고만 띄우거나 아예 건드리지 않는다.
이 설계 원칙은 '자동화의 안전 경계는 정적 분석 가능성의 경계와 일치해야 한다'는 말로 요약된다. 그리고 이 경계를 지키기 위해 className 교체와 cn import 추가를 하나의 fix() 배열로 묶어 원자적으로 적용한다. 두 변경이 분리되면 cn 호출은 있는데 import가 없는 깨진 중간 상태가 생길 수 있기 때문이다. 작은 디테일이지만, 이런 배려가 자동화 도구에 대한 신뢰를 만든다.
다만 이 룰은 @typescript-eslint/parser와 cn 유틸, Prettier 후처리가 갖춰진 환경을 전제로 한다는 점도 솔직하게 인정한다. JSX 속성 문자열에 literal 개행을 넣으면 파서가 parse error를 내기 때문에 cn() 래핑 방식으로 우회했고, 그 결과 cn 유틸에 대한 종속성이 생겼다. 이 룰은 범용 npm 패키지가 아니라, 특정 컨벤션 위에 올린 팀 내부 보조 도구라는 결론이다. 이런 솔직한 트레이드오프 공개가 오히려 이 글의 신뢰도를 높인다.
핵심 이슈 ② — 눈에 보이지 않는 렌더링 비용
애니메이션 성능 이야기는 더 근본적인 층에서 시작된다. top: 100px을 변경하는 것과 transform: translateY(100px)을 변경하는 것, 눈으로 보면 같은 결과다. 그런데 브라우저 내부에서 일어나는 일은 완전히 다르다.
velog 글(@msm4167)은 브라우저 렌더링 파이프라인의 세 단계—Layout, Paint, Composite—를 명확히 설명하며 이 차이를 풀어낸다. top/left 같은 위치 속성을 바꾸면 브라우저는 해당 요소뿐 아니라 주변 요소의 크기와 위치를 다시 계산하는 Layout(Reflow) 단계를 실행한다. 이어서 영향을 받은 영역을 픽셀로 다시 그리는 Paint(Repaint)가 뒤따른다. 60fps 애니메이션에서 한 프레임은 16ms다. 이 짧은 시간 안에 Layout과 Paint가 매 프레임마다 실행되면 프레임 드랍은 피하기 어렵다.
반면 transform은 요소의 실제 위치나 크기를 레이아웃 관점에서 바꾸지 않는다. 이미 페인트된 레이어를 GPU가 이동시킬 뿐이다. Layout과 Paint를 건너뛰고 Composite 단계만 실행되고, 이 단계는 CPU가 아닌 GPU가 처리하기 때문에 메인 스레드가 바빠도 독립적으로 동작한다. opacity도 같은 이유로 Composite만 트리거한다.
맥락 해석 ② — GPU 레이어로의 승격
will-change: transform은 이 최적화를 한 단계 더 밀어붙이는 속성이다. 브라우저에게 '이 요소는 곧 변할 것'이라고 미리 알려 GPU 레이어를 사전에 생성하게 한다. 레이어로 승격된 요소는 다른 요소와 완전히 독립적으로 합성되어, 애니메이션 중에도 나머지 페이지의 렌더링에 전혀 영향을 주지 않는다.
실제 검증도 인상적이다. 크롬 개발자 도구의 Rendering 탭에서 'Paint flashing'을 켜면 top 기반 애니메이션은 매 프레임마다 해당 영역이 녹색으로 깜빡이는 반면, transform 기반 애니메이션은 깜빡임이 전혀 없다. 이론을 코드로 직접 검증하는 이 과정은 Core Web Vitals 중 INP(Interaction to Next Paint)와 CLS(Cumulative Layout Shift) 최적화와 직결된다. 애니메이션이 Layout을 유발하면 CLS 점수에도 악영향을 미칠 수 있다.
시사점 — 두 선택이 가리키는 같은 방향
두 글을 관통하는 공통점은 '선택의 비용을 시스템 전체에서 계산한다'는 태도다. ESLint 룰 설계에서는 '어디까지 자동 수정해도 안전한가'를 AST 구조로 정의했고, CSS 애니메이션 최적화에서는 '이 속성 변경이 렌더링 파이프라인의 어느 단계를 트리거하는가'를 물었다. 둘 다 표면적인 결과가 아니라 내부 메커니즘을 이해하고 설계한 결과다.
Tailwind + shadcn/ui 스택을 쓰는 팀이라면 이 두 관점을 동시에 가져가는 게 실질적으로 유리하다. className 가독성이 높아지면 코드 리뷰에서 스타일 의도를 빠르게 파악할 수 있고, 렌더링 비용을 아는 개발자는 컴포넌트 설계 단계에서 애니메이션 구현 방식을 처음부터 올바르게 잡는다. DX가 좋아진 팀은 UX 디테일을 다듬을 여유를 확보하고, 그 여유가 사용자가 체감하는 부드러움으로 연결된다.
전망 — 자동화와 원칙의 조합
흥미로운 점은 두 최적화 모두 AI 코딩 도구가 쉽게 대체하기 어려운 영역이라는 것이다. GitHub Copilot이나 Cursor는 transform 대신 top을 쓰는 코드를 생성할 수 있고, className을 무한정 늘어뜨리는 코드를 제안하기도 한다. AI가 코드를 빠르게 생성해주는 환경일수록, '이 코드가 시스템에 어떤 비용을 부과하는가'를 판단하는 원칙이 더 중요해진다.
ESLint 커스텀 룰은 그 원칙을 코드베이스에 강제하는 구조적 장치다. 팀 컨벤션을 문서로 남기는 것과, 린트 룰로 자동 적용하는 것은 실효성에서 차이가 크다. 마찬가지로 transform을 써야 한다는 지식은 .cursorrules나 CLAUDE.md에 명시해두면 AI 생성 코드의 품질을 높이는 데 직접 활용할 수 있다. 원칙을 아는 것과 원칙이 실행되는 구조를 만드는 것—프론트엔드 설계의 내공은 결국 이 둘의 거리를 얼마나 좁히느냐에서 드러난다.