해결책
2023년까지 일부 GitHub 페이지의 컴포넌트 수가 급증했고, 기존 CSS-in-JS 솔루션은 그 대가를 치르고 있었습니다. 클라이언트에서 스타일이 초기화되면서 초기 페이지 로드가 느려졌고, 스타일 수집이 서버로 옮겨가면서 서버 측 렌더링이 저하되었으며, 스타일 업데이트는 통제 불능으로 커졌습니다. Primer 팀은 마이그레이션 중에 GitHub이 절대 중단되어서는 안 된다는 강력한 제약 아래 문제를 근본적으로 해결하기로 했습니다.
해답은 CSS Modules였습니다. 각 컴포넌트와 함께 배치되는 네이티브 CSS 파일로, 클라이언트나 서버 런타임이 전혀 없습니다. 형식이 근본적으로 달랐기 때문에 팀은 컴포넌트 단위로 마이그레이션했습니다. 변환된 스타일시트를 추가하고, 이전 스타일과 새 스타일을 전환하는 플래그 뒤에 컴포넌트를 두고, 시각적 회귀 스냅샷으로 픽셀이 동일한지 확인한 다음, 플래그를 팀에, 스태프에, 마지막으로 모든 사람에게 롤아웃했습니다. 2024년 12월까지 모든 Primer 컴포넌트가 마이그레이션되었고, 페이지의 서버 측 렌더링은 55% 빨라졌으며 컴포넌트 초기화는 25% 빨라졌습니다.
더 어려운 절반은 GitHub 자체 코드베이스였습니다. 여기서는 sx prop이 수년간 스타일링 표준이었고, 수천 개의 인스턴스가 런타임 없는 @primer/react로의 전환을 막고 있었습니다. 팀은 @primer/styled-react를 만들었습니다. 이는 sx를 사용하는 코드가 동일한 컴포넌트를 이 패키지를 통해 임포트할 수 있게 하면서, 다른 모든 코드는 빠른 경로를 임포트할 수 있게 하는 전이적 래퍼 패키지입니다.
그다음 변환은 패키지 단위로 진행되었습니다. 2025년 4월 약 7,760개의 sx prop을 마이그레이션해야 하는 정점에서 VS Code 플러그인과 내부 코드모드가 대부분의 작업을 처리했고, 8명의 엔지니어가 6개월 동안 6,419개의 prop을 옮겨 페이지당 1%에서 22%의 SSR 이득을 얻었습니다. 2026년 4월에는 Copilot 코딩 에이전트를 활용한 두 명의 엔지니어가 남은 895개를 3주 만에 0으로 줄였습니다. 2026년 6월까지 GitHub은 100% CSS Modules로 운영되었으며, sx, styled-components, styled-system은 모두 사라졌습니다.
달성한 것
시각적 회귀 스냅샷과 함께 기능 플래그 뒤에서 마이그레이션하고, 전이적 래퍼 패키지가 기존 sx 사용자를 계속 작동시키면서 새 임포트는 속도를 얻습니다.
CSS-in-JS의 런타임 비용은 페이지 복잡도에 비례해 증가했기 때문에, 해결책은 런타임을 조정하는 것이 아니라 런타임 자체를 제거해야 했습니다.
기능 플래그와 시각적 회귀 스냅샷은 모든 마이그레이션 단계를 되돌릴 수 있고 픽셀 단위로 동일하게 만들었으며, 이것이 디자인 시스템 팀이 다른 팀이 의존하는 컴포넌트를 변경할 수 있게 한 요인이었습니다.
@primer/styled-react 래퍼는 두 마이그레이션을 분리했습니다. 컴포넌트 내부는 현대화되는 동안 수천 개의 sx 호출 지점은 차례가 올 때까지 그대로 유지될 수 있었습니다.
코드모드, 전용 VS Code 플러그인, 그리고 마지막으로 Copilot 코딩 에이전트가 7,760개 prop의 고된 작업을 대부분 자동화된 작업으로 바꾸어 두 사람이 완료했습니다.
디자인 시스템은 플랫폼 전반의 변화를 위한 가장 저렴한 수단입니다. 컴포넌트를 고치면 제품이 따라오며, 플래그와 스냅샷 테스트가 있으면 다년간의 마이그레이션도 프로덕션을 중단시키지 않습니다.
그 이후
GitHub은 2026년 6월부터 전적으로 CSS Modules로 운영되고 있습니다. 마이그레이션을 위해 구축된 안전장치인 플래그, 스냅샷, 단계적 롤아웃은 4년간의 아키텍처 변화를 프로덕션 중단 없이 견뎌냈으며, 동일한 플레이북이 이제 향후 Primer 플랫폼 작업을 뒷받침합니다.
근거 확인하기
출처
- Improving site performance by shipping more CSS GitHub Engineering Blog · github.blog ·