알스솔루션
사내 백오피스 리팩토링 (Antd 마이그레이션)
차기 BI 프로젝트의 Antd 도입 리스크를 운영 중인 백오피스에서 사전 검증한 파일럿. 자체 Monorepo 디자인 시스템 → Antd 컴포넌트 단위 점진적 교체
주요 성과
- 배경: 사내 차기 신규 프로젝트(BI 서비스)에서 Antd 디자인 시스템 도입을 결정한 상황. 신규 프로젝트에 본격 적용하기 전, 운영 중인 백오피스에서 먼저 마이그레이션을 선행하여 Antd 기반 개발 워크플로우·사내 정체성 디자인 적용 가능성·운영 리스크를 사전 검증
- 자체 Monorepo 디자인 시스템에서 Antd 기반 디자인 시스템으로 약 4주간 컴포넌트 약 40종을 무중단 점진 전환, 화면별 회귀 결함 0건
- 기존 컴포넌트의 디자인 토큰을 Antd 컴포넌트 props·테마로 매핑하는 변환 가이드를 정의하여 화면별 영향 범위 최소화 (화면당 평균 수정 범위 약 50% 축소)
파일럿 전략 자세히 보기
새 디자인 시스템을 신규 프로젝트에 바로 넣지 않고 운영 중인 백오피스에서 먼저 갈아끼운 이유 — 리스크를 어디서 만날지 고른 판단과, 40종을 무중단으로 옮기기 위해 먼저 만든 것.
약 4주
전환 기간
약 40종
전환 컴포넌트
0건
화면별 회귀 결함
약 50% 축소
화면당 수정 범위
1. 리스크를 어디서 만날지 고른다
차기 BI 서비스에 Antd 도입이 결정된 상황이었다. 그대로 신규 프로젝트에서 처음 써보면 라이브러리 부적합이나 사내 정체성 적용 한계 같은 문제가 신규 개발 한복판에서 드러난다. 그 시점엔 이미 화면이 쌓여 있어 되돌리기가 비싸다.
그래서 운영 중인 백오피스를 파일럿으로 삼았다. 요구사항이 이미 확정된 화면들이라 “기능이 바뀐 건지 전환이 깨진 건지”를 구분할 수 있다는 게 결정적이었다 — 신규 개발에서는 이 둘이 섞여서 전환의 문제인지 판단할 기준 자체가 없다.
2. 옮기기 전에 변환 규칙부터
컴포넌트 40종을 하나씩 옮기면서 그때그때 판단하면, 같은 회색이 화면마다 다른 값이 된다. 전환은 끝나도 정체성은 흩어지고, 그 차이를 되돌리는 비용이 뒤에 남는다. 그래서 기존 토큰을 Antd의 props·테마로 옮기는 변환 가이드를 먼저 정의하고, 화면 작업은 그 규칙을 따르기만 하도록 했다.
3. 파일럿이 넘긴 것
4주간 40종을 무중단으로 옮기며 화면별 회귀 결함 0건으로 마쳤다. 다만 이 프로젝트의 산출물은 전환된 백오피스 그 자체가 아니라 신규 프로젝트가 물려받은 자산이다 — 토큰 매핑 규칙, 컴포넌트 사용 패턴, 그리고 “Antd로 사내 정체성이 표현된다”는 확인된 사실.
→ 이 자산이 BI 서비스의 화면 초기 셋업에 그대로 쓰였다. 전체 흐름은 디자인 시스템 스토리에 정리해 뒀다.