류기현

디자인 시스템 개편이 끝나기 전에 신규 제품 개발이 시작되어야 했습니다. 당시 25%의 컴포넌트만 개발이 완료됐었고, 나머지는 이전 버전 구현이 그대로 실려 있거나 코드가 없었습니다. 팀이 두 명이라 전체를 먼저 완성하는 선택은 제품 일정을 그만큼 미루는 것이었습니다.

컴포넌트마다 Experimental·Preview·Stable 상태를 두고 상태별로 배포 경로를 나눴습니다. 안정된 것은 기본 진입점, 검증이 남은 것은 @maiui/preview 진입점, 제품이 소스를 고쳐 써야 하는 것은 소스를 복사해 가는 레지스트리로 배포했습니다.

제품이 디자인 시스템 완성을 기다리지 않고 개발을 시작했습니다. 제품 쪽에는 디자인 시스템 컴포넌트를 감싸는 UI 레이어를 두어서 변경 범위를 최소화했습니다.

아이콘과 디자인 토큰의 변경 사항을 사람이 확인하고 코드로 옮기고 있었습니다. 변경 이력을 분석해보니 갱신 간격은 평균 90일, 임의 시점의 예상 대기 기간은 64일이었고, 개편 당시 프로덕트 전체에서 사용되던 아이콘 376개 중 245개만 디자인 시스템에 반영된 상태였습니다.

변경 감지부터 코드 생성, 변경 내역 작성, PR 생성까지 이어지는 파이프라인을 만들고 디자인 자산을 코드와 전체 동기화했습니다.

분기 단위로 발생하던 반영 대기를 며칠 수준으로 줄였습니다. 해당 시스템 구축에는 12작업일이 들었고, 반복 작업 절감을 고려하면 1년 이내에 구축 비용을 회수할 수 있습니다.

공통 모달 개편을 앞두고, 리뷰와 QA의 완성도를 높이고자 제품에서 영향을 받는 화면을 조사했습니다. 단순 사용처는 코드 검색으로 찾을 수 있었지만, 실제 진입 경로와 노출 조건, 제품별 수정 정도, 변경 위험도는 코드를 직접 읽어야 판단할 수 있었습니다.

사람이 리뷰할 때 확인하던 내용을 몇가지 항목으로 나누고, AI가 저장소의 코드 맥락을 읽어 같은 형식으로 결과를 작성하도록 했습니다. 사용 위치, 진입 경로, 노출 조건처럼 코드 맥락이 필요한 부분을 AI에게 위임했습니다.

3일 동안 4개 제품의 모달 사용 사례를 모았고, 그중 4분의 1이 넘는 사례가 서버 오류, 시간 초과, 유효성 검사 실패처럼 정상적인 화면 흐름만 따라가서는 놓치기 쉬운 사용처였습니다. 결과는 유형과 위험도, 확인 여부로 탐색하는 대시보드로 만들어 코드 리뷰와 디자인 QA가 같은 범위를 검토하도록 했고, AI가 판단한 내용에는 근거와 확신도를 함께 남겼습니다.