2025년부터 사내 각 팀 프로젝트의 디자인 통일을 위해 사내 디자인 시스템 구축이 2025년의 프론트엔드의 목표로 잡혔습니다.
우리팀을 포함한 다른 두 개의 개발팀의 프론트엔드 개발자가 1-2명씩 착출되어 팀 내 프로젝트와 병행하여 개발하기로 되었으며, 저는 자원하여 참여하기로 했습니다.
프론트엔드 개발자로써, 아주 좋은 경험이라고 생각하여 블로그로 기록해보려고 합니다.
Brain storming
기술스택은 팀이 사용하고 있는 React + Typescript 코어 기반으로 진행하기로 하였습니다.
먼저, 어떤 식으로 디자인 시스템을 구축할 것 인가? 라는 질문에 대한 브레인 스토밍을 했습니다.
아래는 도출된 3가지의 선택지입니다.
- 각 팀 프로젝트에 통일된 UI 컴포넌트 및 스타일 라이브러리를 적용한다.
- 각 팀의 프로젝트와 UI 관련 컴포넌트를 Monorepo로 구성한다.
- 별도의 registry를 구성하여 UI 컴포넌트를 라이브러리화 한다.
각 팀 프로젝트에 통일된 UI 컴포넌트 및 스타일 라이브러리를 적용한다!
결국, 각 팀의 프론트엔드 개발자가 똑같은 컴포넌트를 동시에 만들어야 하는, 즉 일을 세 번 하는 경우가 되는 것이고, UI 조각의 크기도 서로 다를 확률이 있을 것을 우려하여 반려되었습니다.
각 팀의 프로젝트와 UI 관련 컴포넌트를 Monorepo로 구성한다!
참여한 팀은 총 3개의 팀이였고, 팀 별로 최소 2개 이상의 프로젝트가 있었습니다. 정말 많은 팀은 5개 이상도 넘어갔습니다. 사내에서는 형상관리를
Gitlab으로 하고 있었는데, 만약 UI 코어 패키지를 포함한 모든 팀의 프로젝트가 모노레포로 관리되게 된다면, 후에 git push, pull 이벤트를 수행할 때, 팀 별로 commit 한 소스가 conflict 가 날 확률도 배제할 수 없었습니다. 또한, Repository의 용량이 몹시 커지며, 가장 중요한 것은 우리팀은 프론트 React 프로젝트를 Spring 프로젝트와 함께 젠킨스 CI/CD 파이프라인이 구축되어있었기 때문에 프론트 프로젝트를 따로 분리한다는 것 자체가 일을 두 번하게 되는 비효율적인 리스크가 발생하게 되어 반려되었습니다.
npm registry를 이용하자!
추후 확장성을 고려한다면, 또, 디자인시스템 구축을 위해 참여하고 있는 팀 뿐만 아니라 타 팀에서도 다른 프로젝트가 생겨 동일한 디자인 시스템을 적용해야 한다면, 지속적인 관리가 이루어질 수 있게, 디자인 코어를 별도의 repository로 분류하고 npm registry를 따로 생성하여 모든 팀에서 설치할 수 있게 하자 라는 의견이 나오게 되었고 npm registry를 생성하는 방향으로 채택되었습니다. 😉
다음주까지 어떠한 방법으로 코어를 만들고 배포할 지, 각자의 생각을 준비해오기로 하였습니다!! 처음 도전해보는 분야라 이 과정이 너무 기대되기 시작했습니다.