공통 디자인 시스템 설계와
단계적 제품 도입
기존 제품을 유지하면서 공통 개발 기준 도입
여러 UI 패키지를 함께 사용하던 웹 서비스에서 디자인 토큰과 공통 UI를 개발하고 기존 서비스에 적용했습니다. 컴포넌트를 만드는 것뿐 아니라, 제품마다 다른 스타일과 동작을 어디까지 공통화할지 정하고 기존 화면을 유지하면서 교체할 방법이 필요했습니다.
공통 API와 제품별 컴포지션 분리
상태와 접근성, 반복되는 동작은 공통 컴포넌트가 담당하고, 제품 고유의 배치와 업무 로직은 서비스 레이어에 남겼습니다. 여러 사용처에 반복되는 요구만 공통 API에 반영하고, 단일 화면의 표현을 위해 variant나 파생 컴포넌트를 늘리지 않았습니다.
적용 예시: 비동기 액션의 로딩 상태, 중복 실행 방지와 접근성 처리는 공통 컴포넌트에서 제공했습니다. 화면별 크기와 간격은 제품에서 조합하고, 기존 표현을 유지해야 하는 부분은 호환 레이어로 처리했습니다.
공통 패키지와 실제 제품 사이의 도입 방식
공통 패키지 변경, 서비스 설정, 실제 화면 교체를 단계별로 나눴습니다. 마이그레이션의 완료 기준은 기존 UI와 동작을 유지하는 것으로 정하고, 리디자인은 별도 변경으로 분리했습니다. 스타일 차이는 공통 스타일 recipe를 임의로 덮는 대신 도입용 호환 레이어에 모았습니다.
공통 패키지, 컴포넌트 검증 화면(Playground)과 서비스의 Panda 클래스 생성 규칙을 맞췄습니다. 패키지 테스트만으로 끝내지 않고, 사용하는 서비스의 타입 검사와 production 빌드에서도 공통 UI가 동작하는지 확인했습니다.
제작, 도입, 사용을 구분한 하네스와 스킬
신규 컴포넌트 제작, 기존 제품 도입, 일반 화면 개발을 서로 다른 작업 모드로 정의하고, 진입 조건과 검수 순서를 하네스와 재사용 스킬에 정리했습니다. 문서의 목표 스펙보다 대상 브랜치에 실제 제공되는 export, props와 서비스 설정을 먼저 확인하도록 했습니다.
아직 없는 API가 필요하면 제품 코드에서 임시 구현하지 않고 공통 패키지의 선행 작업으로 분리했습니다. 개발자와 에이전트가 같은 스펙과 검수 절차를 사용하도록 작업 기준을 관리했습니다.
제품 적용과 회귀 검증
캠페인 신청, 프로필 관리, 채팅 등 실제 업무 화면에 공통 UI를 적용하고, Playground의 상태별 예제와 실제 화면을 함께 검증했습니다. 동일한 브라우저, viewport, 계정과 데이터 조건에서 이미지 diff, computed style과 인터랙션을 비교하고 차이가 발생한 부분에 회귀 테스트를 추가했습니다.
공통 UI와 호환 레이어, 제품 도입 절차를 함께 남겨 이후 화면도 같은 기준으로 교체하고 검토할 수 있도록 했습니다.