GitHub이 자사 엔지니어링 블로그에서 github.com을 CSS-in-JS 방식에서 완전히 벗어나도록 전환했다고 밝혔다. 글의 제목은 "더 많은 CSS를 배포해 사이트 성능을 개선하기"로, 흔히 성능 최적화라고 하면 전송량을 줄이는 것을 떠올리는 통념과는 정반대의 방향을 내세운다. 이 작업은 GitHub의 디자인 시스템 Primer 팀 소속 엔지니어들이 주도했으며, github.com이라는 대규모 서비스 전반에 걸친 스타일링 아키텍처의 전환이라는 점에서 프런트엔드 실무자들이 눈여겨볼 만하다.
CSS-in-JS가 풀려던 문제와 남긴 비용
CSS-in-JS는 컴포넌트 코드 안에 스타일을 함께 선언하는 접근으로, styled-components나 Emotion 같은 라이브러리를 통해 지난 몇 년간 리액트 생태계에서 널리 쓰였다. 스타일을 컴포넌트 단위로 캡슐화하고, 자바스크립트 변수와 props에 따라 동적으로 스타일을 조합할 수 있다는 점이 매력이었다. 클래스 이름 충돌을 걱정할 필요가 없고, 사용하지 않는 스타일을 자연스럽게 걷어내기 쉽다는 장점도 있었다.
문제는 이 편의가 런타임 비용을 대가로 얻어진다는 데 있다. 많은 CSS-in-JS 구현은 브라우저에서 컴포넌트가 렌더링될 때 스타일을 계산하고 문자열로 직렬화한 뒤 스타일 태그를 문서에 주입한다. 이 과정은 사용자의 기기에서 자바스크립트가 실행되어야 비로소 스타일이 완성된다는 뜻이고, 페이지가 무거워지고 인터랙션이 많아질수록 이 계산이 반복적으로 발생한다. 결국 다운로드하는 CSS 파일의 크기는 줄었을지 몰라도, 그만큼 자바스크립트 번들이 커지고 실행 시간이 늘어나는 형태로 비용이 옮겨간 셈이다.
'더 많은 CSS'가 더 빠른 이유
제목이 역설적으로 들리지만 원리는 단순하다. 스타일을 빌드 시점에 미리 정적인 CSS 파일로 뽑아 두면, 브라우저는 그 파일을 받아 곧바로 적용하기만 하면 된다. 스타일을 만들어내기 위한 런타임 자바스크립트가 사라지므로, 전송되는 CSS의 바이트 수 자체는 늘어나더라도 실제 사용자 기기에서 소모되는 연산은 오히려 줄어든다. CSS는 브라우저가 가장 잘 최적화해 처리하는 자원이고, 자바스크립트 실행에 비해 파싱과 적용 비용이 훨씬 저렴하다는 점을 활용한 것이다.
이는 최근 프런트엔드 진영에서 확산되는 '제로 런타임' 스타일링 흐름과 맞닿아 있다. 빌드 단계에서 스타일을 추출해 정적 CSS로 전달하고, 런타임에는 스타일 계산을 하지 않는 방식이다. GitHub 같은 규모의 서비스에서는 수많은 사용자와 페이지에 이 비용이 곱해지기 때문에, 개별 컴포넌트 단위에서는 미미해 보이는 런타임 오버헤드가 전체 지표에서는 무시할 수 없는 차이로 누적된다.
실무자가 가져갈 시사점
이 사례에서 얻을 교훈은 성능 최적화의 기준을 단순히 '전송량'에서 '사용자 기기의 총 작업량'으로 옮겨야 한다는 점이다. 번들 크기라는 하나의 숫자만 보면 CSS-in-JS가 유리해 보일 수 있지만, 메인 스레드에서 벌어지는 스타일 계산까지 포함하면 그림이 달라진다. 특히 초기 렌더링 성능이나 상호작용 반응성이 중요한 서비스라면, 스타일을 언제 어디서 계산하는지를 아키텍처 결정의 핵심 변수로 놓아야 한다.
동시에 이 전환이 모든 팀에 그대로 정답이 되는 것은 아니다. CSS-in-JS가 제공하던 동적 스타일링과 컴포넌트 캡슐화의 편의를 정적 CSS 체계에서 어떻게 대체할지는 별도의 설계 과제이며, GitHub이 Primer라는 성숙한 디자인 시스템과 전담 팀을 갖췄기에 대규모 마이그레이션을 감당할 수 있었다는 점도 감안해야 한다. 공개된 블로그 요약만으로는 구체적인 전환 도구, 측정된 성능 개선 폭, 마이그레이션 기간 같은 세부 수치가 드러나지 않으므로, 자신의 프로젝트에 적용하려는 팀이라면 원문 기술 문서를 직접 확인하고 자체 환경에서 벤치마크로 검증하는 과정이 필요하다.