Linear StyleX 마이그레이션, 탐색 속도 30% 빨라져
Linear StyleX 마이그레이션은 회사의 React 애플리케이션을 styled-components에서 1,000건이 넘는 풀 리퀘스트로 옮긴 작업으로, 2026년 8월 초에 끝났다고 엔지니어 Kenneth Skovhus가 2026년 8월 26일에 밝혔어요. 결정론적 코드모드와 코딩 에이전트, 사람의 검토를 함께 썼어요. Linear에 따르면 화면이 복잡한 페이지의 메인 스레드 작업량이 20%에서 35% 줄었고, 중급 기기에서 탐색이 약 30% 빨라졌어요. 전체를 다시 만들지 않고도 고객에게 더 빠른 제품을 내놓은 셈이에요.
Linear가 styled-components를 떠난 이유
Linear는 기존 스타일링 라이브러리에서 속도와 제어라는 두 가지 문제를 겪었어요. 런타임 CSS-in-JS는 앱이 렌더링되는 동안 브라우저가 스타일을 만들고 CSS 규칙을 삽입하게 하는데, Linear는 React 18의 동시 렌더링으로 올린 뒤 이 비용을 크게 느꼈어요. styled-components가 유지보수 모드에 들어간 시기와 비슷해요. Sanity의 Cody Olsen이 최적화한 포크를 내놓아 Linear의 렌더링 시간을 40% 줄였지만, 그는 이를 마지막 수단이라고 불렀어요.
두 번째 문제는 캡슐화였어요. styled(Button) 같은 패턴은 컴포넌트를 바깥에서 쉽게 다시 꾸밀 수 있게 해 줬고, 리디자인 뒤 Linear는 길게 이어지는 UI 회귀를 쫓아다니게 됐어요. 엔지니어 Kenneth Skovhus는 코딩 에이전트가 코드베이스에 더 많이 기여할수록 명확한 경계가 더 중요해진다고 썼어요.
Linear가 대신 고른 것과 그 이유
팀은 다음 라이브러리의 조건을 정했어요. 빌드 시점의 스타일 생성, 멀리서 스타일을 바꾸기 어렵게 만든 구조, 파일 간 예측 가능한 병합, 좋은 React 지원, 활발한 유지보수예요. 대부분의 React 스타일링 옵션을 살펴봤고, 가장 가까운 대안이던 vanilla-extract는 API가 흩어져 있고 스타일 파일이 따로 있다는 이유로 탈락했어요.
승자는 Meta의 오픈소스 아토믹 CSS-in-JS 라이브러리 StyleX였어요. 스타일 생성을 빌드 시점으로 옮기고, 충돌 없는 작은 아토믹 클래스를 만들며, 웹에서 Facebook, Instagram, WhatsApp을 움직이는 기술이에요. 스타일을 컴포넌트 옆에 두고, API가 작고, 타입 안전한 스타일링 계약을 줘요. 대가는 경직성이에요. 부모에 의존하는 선택자, 전역 선택자, 래퍼를 통한 재스타일링이 어려워지고, Linear는 전역 선택자를 위한 비상구로 CSS Modules를 남겼어요.
코드모드, 에이전트, 엔지니어의 역할 분담
작업은 에이전트가 아니라 결정론적 코드모드로 시작했어요. Skovhus는 큰 테스트 스위트를 바탕으로 styled-components-to-stylex-codemod를 만들었고 에이전트가 이를 확장하는 데 도움을 줬어요. 온라인 플레이그라운드도 있고, InfoQ에 따르면 지금은 풀 리퀘스트 500건, 약 10만 줄을 넘었어요.
팀은 StyleX 변수와 공용 기본 요소를 먼저 정하고, 코드모드 실행기, 예시, 검증 스크립트, 체크리스트와 함께 에이전트에게 좁은 범위를 맡겼어요. 공용 컴포넌트보다 말단 컴포넌트를 먼저 옮겼고요. 에이전트는 호버 상태나 테마처럼 시각적 차이를 확인하는 데서 자주 막혔고, 프로젝트 중간에 새 모델 두 가지인 Fable과 Sol이 나오기 전까지는 수동 테스트가 많이 필요했어요.
"지금 이 마이그레이션을 시작한다면, Fable과 Sol에 훨씬 더 의존해서 직접 처리하게 할 거예요." Kenneth Skovhus, Linear 엔지니어
몇 달 동안 마이그레이션을 이어 간 방법
Linear는 두 시스템이 공존하는 동안에도 제품 작업을 멈추지 않았고, 도구로 사람들이 계속 옮기도록 이끌었어요. 개발자 툴바의 카운터는 페이지마다 styled-components가 몇 개인지 보여 줬고, 하이라이터는 어떤 컴포넌트가 옮겨졌는지 표시했으며, 봇은 풀 리퀘스트에 새로 들어온 styled-components를 알렸어요. 지금은 Oxlint 규칙이 새 규칙을 강제해요.
진행 차트가 곡선을 보여 줘요. React 스타일링 파일 중 styled-components 파일의 비중은 2026년 3월 8일 주에 100%, 6월 7일에 49%, 8월 6일에 0%였어요. 새 styled-components 파일은 4월 19일 주의 최고치 22개에서 줄어, 5월 31일 이후 대부분의 주에 0개였어요.
Linear StyleX 마이그레이션이 가져온 결과
측정된 결과는 Linear 자체 수치예요. 마이그레이션에는 1,000건이 넘는 풀 리퀘스트와 약 5개월이 들었고, 2026년 8월 초에 끝났어요. Linear는 화면이 복잡한 페이지에서 메인 스레드 작업이 20%에서 35% 줄었고, 중급 기기에서 탐색이 약 30% 빨라졌으며, 페이지 전환 중 삽입되는 CSS 규칙이 0개라고 밝혔어요.
대형 웹 앱을 가진 기업에 주는 의미
소프트웨어 기업에 이 사례의 과제는 크고 활발한 코드베이스에서 제품 작업을 멈추지 않고 핵심 프런트엔드 라이브러리를 바꾸는 일이에요. Linear의 답은 세 부분이었어요. 반복적인 대부분은 결정론적 코드모드, 나머지는 좁은 범위의 에이전트, 판단과 시각 확인은 엔지니어가 맡았어요. Linear 스스로는 지금이라면 에이전트가 더 많은 일을 맡을 것이라고 봐요.
시장 전체도 같은 방향으로 움직여요. InfoQ에 따르면 Cursor는 Tailwind에서 StyleX로 옮겼고, Syntax 팟캐스트는 추가된 경직성이 사람에게는 별로 재미없지만 에이전트는 오히려 잘 해낸다고 결론 내렸어요.
질문과 답변
Linear의 StyleX 전환에는 얼마나 걸렸나요?
약 5개월 동안 1,000건이 넘는 풀 리퀘스트가 들었어요. Linear는 2026년 8월 초에 끝냈고, Skovhus는 2026년 8월 26일에 프로젝트를 소개했어요.
Linear는 왜 vanilla-extract 대신 StyleX를 골랐나요?
vanilla-extract는 정적 추출과 타입 안전성을 제공했지만, Linear는 API가 흩어져 있다고 보았고 스타일 파일이 따로 있는 점을 싫어했어요. StyleX는 스타일을 컴포넌트 옆에 두고 API가 더 작아요.
AI 에이전트가 마이그레이션을 했나요?
일부만 했어요. 반복 작업 대부분은 결정론적 코드모드가 했고, 에이전트는 범위가 정해진 작업을 맡았으며, 프로젝트 중간에 Fable과 Sol 모델이 나오기 전까지 시각 확인은 엔지니어가 했어요.
MOZGII의 시각
우리라면 이렇게 만듭니다
이 사례는 대규모 코드 마이그레이션의 좋은 본보기예요. Linear는 처음부터 에이전트에게 일을 넘기지 않았기 때문이에요. 먼저 큰 테스트 스위트를 갖춘 규칙 기반 변환기를 만들었고, 변환기가 처리하지 못하는 부분에 에이전트를 썼으며, 화면이 제대로 보이는지 판단하는 일처럼 기계가 아직 서툰 작업은 사람이 맡았어요. 저희도 같은 순서를 따를 거예요.
이런 마이그레이션을 직접 맡는다면 공통 기반부터 시작할 거예요. 변환된 모든 파일이 써야 하는 디자인 토큰과 기본 컴포넌트예요. 변환기는 흔한 패턴을 처리하고 알아보지 못하는 것은 거부해서, 특이한 경우가 잘못 변환되지 않고 에이전트나 사람에게 가도록 해요. 에이전트에게는 한 번에 작고 분명한 작업 하나를 예시와 결과를 검사하는 스크립트와 함께 줄 거예요. 눈에 보이는 카운터와 모든 풀 리퀘스트의 검사가 옛 방식 코드가 다시 슬며시 들어오는 것을 막아 줘요.
시각 확인에서 막힐 거예요. 코드는 컴파일되고 테스트도 통과하는데 호버 상태나 다크 테마가 잘못 보일 수 있고, Linear는 에이전트가 바로 그 부분에서 어려워했다는 것을 확인했어요. 변환한 컴포넌트마다 스크린샷 비교를 넣고, 차이가 나면 사람에게 보낼 거예요. 지켜볼 지표는 하나예요. 아직 옛 라이브러리를 쓰는 스타일링 파일의 비중을 주 단위로, 옛 방식으로 새로 추가된 파일과 함께 보는 거예요.
다음으로는 린트 규칙을 새 코드의 표준으로 삼아 다음 리디자인이 깨끗하게 시작되도록 할 거예요.
출처
이 기사의 사실은 다음 출처에서 가져왔습니다.