서론
요즘 컨퍼런스에서 자주 등장하는 주제는 디자인 시스템인 거 같습니다. 어느 정도 규모가 있는 회사들은 회사의 특성을 고려한 디자인 시스템을 개발하여 사용하는데요. 관련 영상을 보다보니까 저도 디자인 시스템에 대한 관심이 생겨서 나만의 디자인 시스템을 만들어보려고 합니다.
이번 글에서는 제가 디자인 시스템에 사용하기로 한 기술 스택을 소개하고 왜 해당 기술 스택을 선택했는지에 대한 이유를 설명드리겠습니다. 제 글만이 정답은 아니지만 앞으로 디자인 시스템을 만들기
TypeScript
이제는 JavaScript로 개발된 프로젝트를 찾아보기 힘든 만큼 TypeScript는 사실상 표준이 되어버린 거 같습니다. 최근에는 TypeScript에서 다시 JavaScript로 돌아가자는 의견도 보이지만 TypeScript는 JavaScript의 Superset이기 때문에 JavaScript 사용자도 별 무리 없이 사용할 것이라고 생각해 TypeScript로 언어를 정했습니다.
React
현재 프론트엔드에서 가장 많이 사용하는 UI 라이브러리이고 제가 즐겨쓰는 라이브러리이기 때문에 React를 선택했습니다. 저는 React 뿐만아니라 Vue도 사용해봤는데요. 프로토 타입으로 React 버전을 완성하고 여유가 된다면 Vue 버전도 만들어 보고 싶네요.
Vite
보통 라이브러리를 개발할 때는 Rollup이라는 번들러를 사용합니다. 트리 쉐이킹이 가능하고, Webpack보다 더 작은 번들 사이즈로 만들어준다고 하네요. 하지만 저는 여러 컴포넌트 간에 상호작용을 테스트해볼 예정이라 HMR을 지원하는 Vite를 선택했습니다. 또한 Vite는 빌드를 진행할 때 내부적으로 Rollup을 사용하기 때문에 Rollup을 사용하는 이점도 가질 수 있다는 점이 매력적입니다.
Vanilla Extract
저는 디자인 시스템 같은 라이브러리의 내부에서는 당연히 순수 CSS를 사용할 것이라고 생각했습니다. 하지만 Chakra UI라는 대표적인 디자인 시스템 라이브러리를 확인해보니 Emotion을 사용하고 있더라고요. 그래서 저도 좀 더 편하게 라이브러리를 사용해보려고 합니다. 대신! js가 css로 변하는 것이 런타임에 일어나는 Emotion 대신 컴파일 때 변환되는 Vanilla Extract를 사용해 성능적인 면도 가져가고 싶어서 해당 라이브러리를 선택했습니다.
Storybook
Storybook은 컴포넌트의 UI를 테스트하고 문서화할 수 있는 라이브러리입니다. 제가 만들려고 하는 디자인 시스템에서는 필수적인 라이브러리라고 생각합니다. 제가 참고하고 있는 Chakra UI에서도 Storybook을 통해 컴포넌트를 문서화해서 제공하는데요. Storybook만 있어도 간단한 UI 라이브러리는 별도의 개발 서버 없이 개발할 수 있습니다.
Jest
일반적인 웹 애플리케이션 프로젝트 뿐만 아니라 대부분의 유명 라이브러리에도 Test Code가 있는데요. 라이브러리인 만큼 단위 테스트만 있으면 충분하기 때문에 가장 많이 사용되는 Jest를 사용하려고 합니다. Vite를 사용하기 때문에 Vitest와 고민을 했는데요. 사실 Vitest와 Jest는 대부분의 문법이 동일하기 때문에 추후에 라이브러리를 변경해도 마이그레이션을 하는 데 많은 시간이 들 거 같지는 않기 때문에 일단 레퍼런스가 많은 Jest로 선택했습니다.
