사내 디자인 시스템 배포

배포를 위한 첫 걸음

나는 Saas 프로젝트의 시작이 다가올 때 사내 디자인 시스템을 배포해야겠다고 마음먹었다. 컴포넌트들이 완성은 되었지만 실제로 라이브러리를 통해 사용해 본적은 없었기 때문이다. Saas 프로젝트 시작 전에 배포를 마치지 못한다면, 여태 만들었던 컴포넌트들의 코드를 새로 시작하는 프로젝트의 레포에 붙여넣어 사용해야 하는 슬픈 상황을 마주칠 것이 분명했다. 그러나 다른 팀원들은 이에 별 걱정을 안하는 것 같은 눈치였다. 그래서 나 홀로 디자인 시스템 배포에 나섰다.🥲

현재 상황 파악

그래도 사내 디자인 시스템을 처음 구축할 때 다른 팀원이 배포를 위한 작업을 해두셨다. 사설 패키지 배포에 가장 많이 사용되는 Verdaccio 설정을 해두셨다. 나는 이것을 보고 금방 끝날 것 같다는 안일한 생각을 했다. Verdaccio로 배포하여 팀원들이 라이브러리를 사용하기 위해서는 Verdaccio를 운영하는 서버가 필요했지만 서버는 구축되어있지 않았다. 그래서 나는 일단 기존에 설정이 제대로 작동하는지 로컬에서 확인하기 시작했다.

기존에 작성되어있는 스크립트 명령어로 컴파일을 하고 내 로컬 Verdaccio에 배포한 후 다른 레포나 프로젝트에서 다운받아서 사용해 보았다. 이 과정에서 나는 몇 가지 단점을 느꼈다.

1. npm의 registry를 매번 바꿔줘야한다.
2. Verdaccio 운영 서버도 비용이 든다.

두가지 단점이 계속 눈에 밟혔지만 일단 라이브러리가 제대로 작동하는지 확인하기로 했다. 하지만 라이브러리를 배포하고 설치해서 확인했지만 팀원들이 힘들게 작성했던 컴포넌트들은 import 되지 않았다. 이 때 뒤통수를 한대 얻어맞은 기분이었지만 문제가 무엇인지 찾기 시작했다.

무엇이 문제인가?

우선 Verdaccio에 빌드한 파일들이 제대로 업로드 되고 해당 파일들이 다운로드 되는지 확인하기로 했다. 확인 결과 Verdaccio에는 컴파일된 파일이 잘 들어가 있었고 라이브러리를 다운로드 받으면 node_modules에 해당 파일들이 잘 들어가 있었다. 이를 통해 빌드 방식에 문제가 있다는 가설을 세웠다.

그렇다면 antd나 다른 사람들은 도대체 어떻게 빌드해서 배포하고 있는지 궁금해졌다. 그리고 팀원들이 작성했던 코드들의 빌드와 차이점이 무엇인지 확인해야 했다. 우선 기존 사내 디자인 시스템의 구성은 아래와 같다.

   ├─ .storybook
   ├─ public
   ├─ build(해당 폴더의 하위 파일들을 배포)
   └─ src
      ├─ @types
      ├─ assets
      ├─ components
      ├─ hooks
      ├─ pages
      └─ styles 

보통의 리액트 프로젝트의 구조와 다른점이 없다. 생각해 보면 리액트 프로젝트를 빌드해서 업로드하고 다운받으니 개별 컴포넌트를 import할 수 없는 것은 어떻게 보면 당연했다.

디자인 시스템 빌드 방법

위와 같은 문제가 있었기 때문에 다른 라이브러리나 개발자들은 디자인 시스템을 어떻게 배포하는지 알아보았다. 그 결과 rollup을 이용하여 빌드한 코드를 배포하였다. 아예 빌드 방법이 다르다는 사실을 깨닫고 사내 디자인 시스템에 바로 적용하기 시작했다.

내가 rollup을 적용하며 많이 참고했던 글은 아래와 같다. 생각보다 참고 자료가 많지 않아서 문제가 생길때 마다 매우 고생했다.

Rollup을 사용하여 디자인 시스템 번들 후, npm 라이브러리로 배포하기
Rollup.js+ Typescript + Storybook으로 구축하는 디자인 시스템

Rollup은 무엇인가?

rollup.js의 공식문서에 따르면 아래와 같이 정의되어있다

Rollup is a module bundler for JavaScript which compiles small pieces of code into something larger and more complex, such as a library or application.

자바스크립트에서 사용되는 모듈 번들러라는 뜻이다. 사내에서는 타입스크립트를 사용하기 때문에 rollup.js를 사용하기 위해서는 추가적인 세팅이 필요했다.

// rollup.config.js
import { nodeResolve } from '@rollup/plugin-node-resolve';
import typescript from 'rollup-plugin-typescript2';
import peerDepsExternal from 'rollup-plugin-peer-deps-external';
import commonjs from '@rollup/plugin-commonjs';
import image from '@rollup/plugin-image';
import svgr from '@svgr/rollup';
import url from 'rollup-plugin-url';

export default {
  input: './index.ts',
  output: [
    {
      dir: 'build',
      format: 'esm',
      exports: 'named',
      sourcemap: true,
    },
  ],
  plugins: [
    peerDepsExternal(),
    image(),
    nodeResolve(),
    commonjs({
      include: /node_modules/,
    }),
    typescript({ useTsconfigDeclarationDir: true }),
    url(),
    svgr({
      svgoConfig: {
        plugins: [
          {
            name: 'removeViewBox',
            active: false,
          },
        ],
      },
    }),
  ],
};

rollup은 rollup.config.js의 설정을 바탕으로 모듈을 번들링한다. 타입스크립트를 사용하기 위해 rollup-plugin-typescript2가 필요하며 svg와 img를 사용하기 위해 다른 라이브러리를 추가로 설치하고 설정파일에 추가해주어야 한다. 여기서 제일 황당했던 것이 svgr이었다. svgr의 plugin을 처음에 따로 설정하지 않았다. 그런데 라이브러리를 통해 아이콘을 사용할 때 문제가 발생했다.

아이콘의 크기를 변경하면 아이콘이 짤리는 현상이 발생했다. 왜 아이콘이 잘리는 지 확인했다. 배포한 svg파일에는 viewbox가 설정되어 있었다. 하지만 배포가 되는 과정에서 viewbox 속성이 삭제되면서 아이콘이 잘려버렸다. 그래서 svgr에만 해당 설정을 추가했다.

배포 마무리

처음 계획은 사내에서만 디자인 시스템을 사용하게끔 배포하려했다. 하지만 처음 느꼈던 단점들을 참을 수 없어 디자이너분들과 CTO에게 npm에 public으로 배포하기를 건의했다. 이전 회사라면 결정하는데 2주 정도 걸렸을텐데 스타트업이라 하루만에 결정을 해주셨다. 그래서 public으로 무사히 배포하여 지금도 잘 사용중이다.

배포하면서 몇가지 아쉬운 점이 있었다. 우선 배포하기 위해서는 작성한 컴포넌트들을 index.ts에서 export 해주어야한다. 그러나 코드 양이 많아지고 디렉토리 구조가 복잡해지면 export하는 것도 일이다. antd의 코드를 보면 미친 양의 export 코드를 볼 수있다. 지금은 방법을 몰라 일일이 작성하지만 누군가 자동화했을 것 같다는 생각이 들었다. 우리 사내 시스템에도 적용이 시급하다. 디자인 시스템 뿐만아니라 모든 프로젝트에서 컴포넌트와 타입 export, import가 너무 귀찮다.

그리고 디자인 시스템의 구조가 문제였다. 컴포넌트를 개발할 때는 React에서 진행하지만 rollup은 리액트 폴더와 공존이 안되는 것 같았다. 내가 잘 모르는 것일 수 있지만 보통 분리해 사용하는 것 같았다. 이를 사내 디자인 시스템에 적용하였고 현재 구조는 아래와 같다.

├─ library
│  ├─ @types
│  ├─ assets
│  ├─ components
│  ├─ hooks
│  └─ styles
│
└─ project
   ├─ .storybook
   ├─ public
   └─ src
      ├─ @types
      ├─ assets
      ├─ components
      ├─ hooks
      ├─ pages
      └─ styles  

project에서 컴포넌트를 개발하고 스토리북 코드를 완성하면 library에 개발한 코드를 붙여넣어 rollup을 이용하여 빌드하고 배포하는 방식이다. 문제는 여기에서 발생했다. 프로젝트에서 변경한 내용이 라이브러리 코드에 반영이 되지않아 코드는 작성했는데 배포가 되지않는 상황이 발생했다. 그래서 임시로 library의 package.json에 project/src/components를 복사하여 library/components에 붙여넣는 명령어를 만들었지만 불안한 것은 똑같았다. 얕은 복사를 통해 매번 복붙을 안해도 되게끔 해보았지만 마음대로 되지 않았다. github actions를 통해 자동화를 해야할 것 같다.

위 두 아쉬움은 모두 자동화를 하지 못해 발생한 이슈들 같다. 이전에는 자동화에 대해 별 생각이 없었는데 해당 이슈들을 마주하며 자동화가 꼭 필요하다는 것을 느꼈다.

마무리

처음 배포하고 난 후 팀원들이 직접 사용하면서 여러 문제가 있다는 것을 알아채고 수정을 매우 많이했다. 추가로 지정해줘야하는 props들이 생기기도 하고 css가 깨지는 경우도 있었다. 지속적으로 수정해 나가며 디자인 시스템이 안정화 되는 것을 보며 뿌듯함을 느낀다. 그리고 개발자로서 첫 배포를 담당하여 설정하는 기회는 쉽게 오지 않을까 하는 생각이 들었다. 아직 개선해야할 점은 많지만 그래도 뿌듯하다.