GitHub가 CSS를 더 보내며 사이트를 더 빠르게 만든 방법

반응형

웹 성능 문제는 눈에 띄는 큰 기능보다 페이지마다 반복되는 작은 런타임 비용에서 시작되기도 합니다. GitHub는 2026년 9월 25일 Primer 디자인 시스템과 GitHub.

com에서 CSS-in-JS를 걷어내고 CSS Modules로 옮긴 과정을 공개했습니다. 단순한 스타일 문법 교체가 아니라, 서버 렌더링과 브라우저 초기화 비용을 줄이면서도 수천 개 컴포넌트를 안전하게 전환한 점이 핵심입니다.

3줄 핵심 요약

• GitHub는 CSS-in-JS 런타임을 줄이고 CSS Modules로 전환해 Primer 컴포넌트의 서버 렌더링 시간을 55%, 초기화를 25% 줄였다고 공개했습니다.
• sx prop 마이그레이션은 8명이 6개월 동안 6,419개를 옮겼고, 이후 Copilot 코딩 에이전트를 활용해 남은 895개를 두 명이 3주 만에 0개로 만들었습니다.
• 핵심은 한 번에 재작성하지 않고 기능 플래그·시각 회귀 테스트·점진 배포로 위험을 나눠 런타임 비용을 없앤 것입니다.

컴포넌트가 늘자 CSS-in-JS 비용이 커졌다

GitHub의 Primer 디자인 시스템은 버튼부터 배너까지 다양한 UI를 제공합니다. 2023년부터 특정 페이지의 컴포넌트 수가 급증하면서 클라이언트에서 스타일을 초기화하는 시간이 늘고, 서버 렌더링 성능이 떨어졌습니다.

페이지에 컴포넌트가 많아질수록 스타일 업데이트와 런타임 작업도 함께 커져 기존 방식의 한계가 분명해졌습니다.

CSS Modules로 런타임을 빌드 타임으로 옮겼다

GitHub는 컴포넌트 옆의 CSS 파일에 스타일을 작성하고 클래스 이름을 기본적으로 로컬화하는 CSS Modules를 선택했습니다. 스타일이 HTML과 함께 CSS 파일로 제공되면서 클라이언트와 서버에서 스타일을 수집·생성하는 런타임 동작이 줄었습니다.

기존 CSS-in-JS와 다른 방식이었지만, 디자인 시스템을 단위로 삼아 컴포넌트별로 점진 전환할 수 있었습니다.

수치로 확인한 성능 개선

Primer 컴포넌트를 CSS Modules로 옮긴 결과 GitHub는 페이지의 서버 렌더링 시간이 55% 줄고 컴포넌트 초기화 시간이 25% 감소했다고 밝혔습니다. 이후 sx prop을 줄이는 작업에서 8명의 엔지니어가 6개월 동안 6,419개를 마이그레이션했고, 일부 페이지의 서버 렌더링 시간은 1~22% 개선됐습니다.

이 수치는 GitHub 내부 페이지와 측정 환경에 대한 결과이지만, 스타일 런타임 비용을 별도 지표로 추적할 필요성을 보여줍니다.

한 번에 바꾸지 않고 실패 범위를 나눴다

각 컴포넌트에 새 스타일 파일을 추가하고 기능 플래그로 이전·신규 스타일을 전환했습니다. 시각 회귀 테스트로 두 방식의 스냅샷이 같은지 확인한 뒤 팀 내부, 직원, 전체 사용자 순서로 점진 배포했습니다.

기존 sx 사용처는 @primer/styled-react 래퍼로 당분간 호환해 새 컴포넌트의 성능 이점을 얻으면서도 전체 제품이 한 번에 깨지는 상황을 피했습니다.

Copilot 에이전트는 반복 마이그레이션을 가속했다

GitHub는 처음에 VS Code 플러그인과 내부 codemod를 사용해 sx prop을 CSS Modules로 바꿨습니다. 2026년 4월에는 남은 895개 sx prop을 두 명의 엔지니어와 Copilot 코딩 에이전트로 3주 만에 정리했다고 설명했습니다.

자동화가 코드를 옮겼지만, 수동 검토와 테스트·점진 배포가 함께 있었기 때문에 속도보다 검증 가능한 반복 작업에 에이전트를 사용한 사례에 가깝습니다.

마지막 단계는 테마와 의존성 제거였다

GitHub는 일곱 가지 테마와 고대비 모드를 지원하므로 스타일 의존성을 바로 삭제하지 않고 테마 변수를 CSS로 분리했습니다. 두 달간의 마이그레이션과 몇 차례 수정, 기능 플래그 검증을 거쳐 2026년 6월 GitHub.

com은 100% CSS Modules 기반으로 실행됐습니다. 결과적으로 sx, styled-components, styled-system을 제품에서 제거할 수 있었습니다.

사용자와 업계에 미치는 영향

대규모 프런트엔드의 성능 개선은 ‘새 프레임워크로 전면 재작성’보다 런타임 비용을 측정하고 작은 단위로 없애는 방식이 현실적일 수 있습니다. 기능 플래그와 시각 회귀 테스트가 있다면 CSS·상태 관리·렌더링 구조의 교체도 사용자 영향 없이 단계적으로 진행할 수 있습니다.

확인할 점

성능 수치와 마이그레이션 기간은 GitHub의 Primer와 GitHub. com 내부 환경에서 나온 결과입니다.

CSS Modules가 모든 제품에서 CSS-in-JS보다 빠르다고 일반화할 수 없으며, 동적 스타일·테마·캐시 전략에 따라 적합한 선택이 달라집니다. Copilot 에이전트 사용도 자동 병합을 의미하지 않으며, 테스트와 코드 리뷰를 생략해서는 안 됩니다.

출처

함께 읽을 글

• AWS EventBridge, 여러 계정을 하나의 이벤트 버스로 묶는다
• 랜섬웨어 이름이 바뀌어도 흔적은 남는다: Storm-2570의 공통 수법
• 구글 워크스페이스, 관리자 권한을 ‘기간 한정’으로 부여한다

• GitHub Blog — Improving site performance by shipping more CSS

728x90