브라우저가 화면을 그리는 과정은 생각보다 정교하다. HTML 파싱 → CSSOM 생성 → Render Tree 조합 → Layout → Paint → Composite. velog의 '브라우저 렌더링과 DOM' 아티클이 이 Critical Rendering Path를 단계별로 정리했는데, 읽다 보면 한 가지 불편한 진실이 눈에 들어온다. DOM을 건드릴 때마다 이 파이프라인이 다시 돌아갈 수 있다는 것. Reflow는 요소의 크기나 위치가 바뀔 때 주변 요소까지 끌어들여 재계산하고, Repaint는 그보다 가볍지만 여전히 비용이 있다. 루프 안에서 offsetWidth를 읽고 쓰기를 반복하는 코드가 왜 성능 지옥인지, 이 흐름을 이해하면 바로 납득된다.
React의 Virtual DOM은 이 문제에 대한 답으로 등장했다. 변경 사항을 가상 트리에 모아두고 실제 DOM과 비교(Diffing)해 바뀐 부분만 한 번에 업데이트한다. 하지만 Virtual DOM이 항상 빠른 건 아니다. 단순한 UI라면 오히려 오버헤드가 된다. 핵심은 '복잡한 상태 변화가 많은 UI에서 DOM 직접 조작보다 효율적'이라는 맥락이고, React Compiler가 메모이제이션을 자동화하는 방향으로 진화하는 것도 같은 맥락의 연장선이다.
여기서 시선을 조금 돌려보자. dev.to에 올라온 'Making SVG social-media templates rebrandable in 6 lines with CSS classes'는 전혀 다른 문제처럼 보이지만, 같은 레이어를 건드리고 있다. 저자는 SNS용 SVG 템플릿 28개를 만들면서 모든 색상을 SVG 내부 <style> 블록의 CSS 클래스로 관리했다. .bg, .accent, .ink, .muted 같은 시맨틱 클래스 6개만 바꾸면 전체 28개 파일이 동시에 리브랜딩된다. Figma 변수나 디자인 토큰과 구조적으로 동일한 발상이다.
두 기사가 교차하는 지점이 흥미롭다. 렌더링 성능 관점에서 'el.style.width = '100px'를 세 번 쓰는 것보다 el.className = 'box-active'로 한 번에 처리하라'는 권고는, SVG 디자인 토큰 관점에서 'fill="#FF6B5C"를 노드마다 인라인으로 박지 말고 .accent 클래스 하나로 묶어라'는 권고와 본질적으로 같다. CSS 클래스는 브라우저에게는 Reflow 최소화 수단이고, 디자인 시스템에게는 토큰의 물리적 표현이다. 둘 다 '변경을 한 곳으로 모은다'는 원칙 위에 서 있다.
AI 워크플로우에서 이 연결이 더 중요해진다. v0.dev나 Cursor로 컴포넌트를 빠르게 생성할 때 AI는 대부분 인라인 스타일이나 Tailwind 임의값(w-[317px])으로 색상과 크기를 박아버린다. 빠르게 화면을 만들어주지만, 나중에 디자인 토큰 시스템을 얹으려 하면 전체를 뜯어내야 한다. SVG 템플릿 사례처럼 처음부터 시맨틱 클래스 변수로 설계해두면, AI가 생성한 코드를 교체·확장할 때 변경 범위가 극적으로 줄어든다. Playwright로 SVG를 정확한 픽셀 크기의 PNG로 렌더링하는 파이프라인도 같은 논리다. 렌더링 결과물의 일관성은 설계 단계의 토큰 구조에서 결정된다.
실무 시사점은 명확하다. 첫째, AI에게 컴포넌트 생성을 시킬 때 프롬프트에 '색상과 간격은 반드시 CSS 변수(또는 Tailwind 토큰) 참조로 작성할 것'을 명시하라. 인라인값 하나가 나중에 Reflow 유발 코드와 결합되면 디버깅 비용이 두 배가 된다. 둘째, Reflow를 줄이는 className 교체 전략과 디자인 토큰의 단일 수정 전략은 같은 팀 언어로 문서화하라. 개발자가 성능 관점에서 쓰는 패턴이 디자이너가 토큰 관점에서 원하는 패턴과 같다는 걸 공유하면, 협업 마찰이 줄어든다.
앞으로의 방향은 더 흥미롭다. React Compiler가 렌더링 최적화를 자동화하듯, 디자인 토큰 레이어도 Style Dictionary 같은 도구를 통해 점점 자동화되고 있다. CSS 클래스 6줄로 28개 파일을 리브랜딩하는 SVG 기법은 오늘의 수작업이지만, 내일은 AI 에이전트가 토큰 정의 파일 하나를 읽고 전체 UI 컴포넌트와 에셋을 동기화하는 파이프라인으로 진화할 것이다. 렌더링 파이프라인을 이해하고 디자인 토큰 구조를 함께 설계하는 개발자가, 그 자동화의 설계자가 될 수 있다. 지금 이 두 가지를 따로 공부하고 있다면, 한 번쯤 같은 맥락으로 묶어서 바라볼 타이밍이다.