디자인 시스템 개발일지 1 ( 시작 배경 )
1. 디자인 시스템 기획 배경
기존 시스템의 문제
- 기존의 레포에서는 디자인 시스템이 불규칙하게 자리잡아 있었음.
- 초기 서비스를 구축할 떄 빠른 개발 진행, 디자인 토큰 구축 미흡, 인원 부족 등 여러 상황으로 인해 기존의 레포에서 작업을 함에 있어서 많은 어려움이 있었음.
- tailwind css로도 유틸리티 클래스를 제대로 구성해놓으면 깔끔하면서도 빠른 속도로 스타일 코드를 작성할 수 있을 것 같은데, 과한 인라인 스타일 코드가 많아지는 점이 너무 아쉬웠음.
리디자인
- 새롭게 디자이너분이 합류하게 되면서 페이지 전반적인 리디자인이 이뤄짐.
- 기획도 크게 변경됨에 따라 기존 디자인을 거의 활용하지 못하게 되었고, 새로운 레포지토리에서 작업을 하게 됨.
- 새롭게 디자인 시스템을 zero부터 구축할 수 있는 기회.
온보딩의 명확성
- 컴포넌트 설계 관련해서 온보딩 문서를 명확하게 만들기가 어려웠음. 기존 컨벤션도 제각기 다른 느낌이었기 때문에
- 그래서 토대가 되는 컴포넌트들을 storybook을 활용해서 문서화함으로써 신규 부원의 온보딩을 조금 더 용이하게 하고싶었음.
2. 디자인 시스템 관리 구조에 대한 논의
- 그렇게 해서 디자인 시스템을 미리 쌓아올리는 것은 구성원 모두가 동의를 한 상황.
- 이 때, 디자인 시스템 레포를 따로 둬서 npm 활용하여 배포하는 방식을 택할 것인지, 모노레포 환경에서 디자인 시스템 패키지를 구축할 것인지, 아니면 디자인 시스템을 아예 fsd구조의 shared 레이어에 둬서 아예 같이 번들링되는 상태로 관리할 것인지 논의가 필요했음.
- 총 3가지 안이 나왔었음.
1. npm으로 배포 및 레포 분리하는 방식
- 각자 다른 레포로 관리해서 npm으로 배포하는 방식을 생각했다.
- 그리고, 서비스 레포에서는 npm에 올린 라이브러리를 가져와서 패키지로 사용하게 된다.
장점
- 기존에 fsd관련 eslint-rule을 만들어보면서 npm으로 배포하는 방식은 경험해본 상황이었음.
- 레포가 명확하게 나뉘어지기 때문에 디자인 시스템 작업, 웹 서비스 레포에서의 작업이 명확하게 분리됨.
- 추상화 수준이 명확하게 분리가 된다. Flex, Grid 같은 레이아웃 컴포넌트와 Dialog, Dropdown과 같은 추상화된 컴포넌트들은 디자인 시스템에서 관리가 되고, 이를 활용한 HeaderWithPrevButton, AlertDialog
단점
- 디자인 시스템은 eslint-rule과 달리 개발의존성이 아닌 런타임 의존성이라는 점에서 번들링 & 트리셰이킹 부분에서 신경써야할 부분이 많아보였음
- 레포가 분리되어있기 때문에 ui 상으로 문제가 생겼을 때 변경사항 파악이 어렵다는 점이 있음.
- 전반적으로 잘 관리하면 좋지만, 구조에 대한 이해가 없을 경우 난이도가 높을 것 같다는 의견이 있었음.
2. 동일 레포에서 모노레포로 관리하는 방식
- 동일 레포에서 apps 하위에 서비스 레포를 두고, packages 하위에 디자인 시스템 레포를 둬서 참조하는 방식이다.
- pnpm-workspace를 활용해서 workspace 참조를 통해서 디자인 시스템을 가져와서 서비스 레포에서 활용하게 된다.
장점
- 디자인 시스템 레포가 명확하게 분리가 되면서도, 단일 레포에서 작업할 수 있다.
- npm에 올리지 않아도, 서비스 레포에서 변경사항을 바로 반영할 수 있다.
단점
- 관리의 복잡성이 늘어나게 된다. 스토리북 배포, 디자인 시스템 배포, 디스코드 pr 웹훅,
- 최근에 토스에서 모노레포 환경이 커짐에 따라서 발생하는 레포 체크아웃 시간 등등 다양한 문제를 확인헀었다. 현재는 2000분의 깃허브 무료 action를 활용하고 있는데 만약 특정 달에 변경사항이 많이 발생하게 되면, 예기치 못한 상황이 발생할 수도 있을 것 같다.
3. 아예 서비스 내부로 넣는 방식 ( shared 레이어 )
- shared 레이어에 두는 방식이다.
- 프로젝트의 공용 컴포넌트, ui와 함께 두는 방식이다.
장점
- 가장 간단하게 구현할 수 있음.
- 디자인 시스템을 끌어다가 쓰면서, 작업하는 데에 문제가 생기면 바로바로 수정 가능.
단점
- 바로바로 수정할 수 있는게 오히려 악영향이 될 수 있음. shared 레이어에 존재하기 때문에 변경하기가 용이하고 타 구성원이 잘못 변경했을 떄 생길 수 있는 영향이 클 것 같았음.
- 확장에 불리함. 현재 동문 네트워크 서비스에서 관리자 기능을 분리해서, 학생회 측에서 더 적극적으로 활용할 수 있는 방안을 논의중인데 같은 레포에 둘 경우에는 추후 신규 레포에서 작업할 때 확장성이 제한됨.
3. 디자인 시스템 관리 구조에 대한 결정
- 결론부터 말하자면 npm으로 배포 및 디자인 시스템 레포 분리를 하는 방식으로 결정되었음.
- 이유는 다음과 같다.
레포 관리의 복잡성
- 2번 모노레포로 관리하는게 깔끔하고 좋아보이긴 했지만 관리의 복잡성이 매우 커질것으로 생각되었음.
- 특히나 이전에 언급된 것처럼 다양한 워크플로우 파일들이 들어가게 될 것 같은데, 이 부분이 혼동이 많이 될 것 같음.
추상화 수준의 명시
- 새로 온보딩하는 부원의 경우 모노레포 환경을 접하지 않았을 수도 있는데, 웹 내부에서 컴포넌트 수정을 해야하는걸 실수로 디자인 시스템의 컴포넌트를 수정하게될 수도 있다고 생각함.
- 디자인 시스템 컴포넌트 변경사항은 서비스에 크게 영향을 미칠 수 있는데, 레포지토리의 분리는 구성원들이 더 명확하게 구조를 파악할 수 있게 해줄 것 같음.
- 이외에도 웹 서비스 내부의 shared 레이어가 갖는 추상화 수준, 그리고 디자인 시스템이 갖는 추상화 수준이 다름을 레포지토리의 분리에 의해서도 명확하게 알 수 있을 것 같았음.
레퍼런스 참고
- 이번 디자인 시스템을 구상하면서 seed design(당근), vapor ui (구름) 레포지토리를 많이 봤었고, 다양한 글들을 확인한 결과 디자인 시스템 레포를 개별적으로 관리하는 부분을 확인할 수 있었음.
- 물론 기업 규모의 서비스는 규모가 확연하게 차이가 나지만, 우리 서비스에서도 스토리북 문서화 및
변경의 용이성
- 사실 디자인 시스템을 이렇게 각잡고 구축해보는 것은 처음이라서 지금까지 나왔던 의견 이외에도 다양한 상황이 생길 수 있다고 생각했음.
- 장점처럼 보였던 것이 장점이 아닐 수도 있고, 단점 또한 마찬가지일 수도 있다는 생각에 선뜻 선택하기가 어려웠음.
- 따라서, 잘못되었을 경우에 변경하기 용이한 구조를 택하기로 결정함.
- 아예 shared 레이어에 두거나, 모노레포로 관리하게 될 경우에는 이미 레포 내부적으로 웹 서비스 -> 디자인 시스템의 의존이 생겨버리기 때문에 잘못되면 분리하기 어렵다고 생각함.
- 반면 레포를 분리해서 시작하면 추후 모노레포로 합치게 되더라도 workflow 파일과 라이브러리 참조만 내부 workspace 참조로 변경하면 되지 않을까 싶어서, 변경에 용이한 구조라고 생각했음.
4. 느낀 점
- 디자인 시스템 레퍼런스를 찾으면서 다양한 글들을 많이 봤었는데, 읽었던 글들의 링크를 저장하고 글을 보면서 배운 점들을 정리하는 습관을 길러야 할 것 같다.
- 마구잡이로 보다보니 읽었던 내용들이 뒤죽박죽 섞이기도 하고, 예전 레퍼런스를 다시 참고하려고 할 때 매우 찾기가 어려웠다.
- 디자인 시스템 구축을 시작하게 되면 타입 관련 처리부터, 스타일 관련 라이브러리 등등 생각할 점들이 많을 것 같은데 컴포넌트 설계 관련해서 딥한 경험을 해볼 수 있다는 생각에 좋으면서도 잘 마무리할 수 있을지 걱정도 된다.