디자인 시스템 개발일지 2 ( 구조 설정 )

  • 8/1/2026
  • 3-minute read

1. 구조 설정 과정

전반적으로 참고한 문서

https://devblog.kakaostyle.com/ko/2024-12-13-1-rebuilding-frontend-design-system/

중요하게 생각하는 것

  • 트리셰이킹 및 번들링이 제대로 이뤄져야 한다.
  • 아이콘, foundation token, 디자인 시스템들이 독립적으로 활용될 수도 있으면 좋을 것 같다.

구조 결정

  • 구조에 대해서는 모노레포로 components, icons, tokens 패키지를 분리해서 관리하는 구조와 전부 다 같은 패키지로 관리하는 구조를 생각했었다.
  • 그런데 아이콘, tokens만 따로 사용하는 케이스도 함께 생각을 해보니 패키지들을 분리해서 관리하는게 더 좋다고 생각했다.
  • 이외에도, 패키지들을 각각 관리하면 npm에 패키지의 변경사항을 기재할 때에도 훨씬 더 깔끔해지지 않을까 싶었다.

2. 레포 관리 및 빌드 도구 설정

pnpm

  • 패키지 매니저로 pnpm을 활용했다.
  • npm은 유령 의존성 이슈 때문에 선택하지 않았다.
  • 당근 디자인 시스템을 보면 bun을 활용하던데 나중에 개인적으로 써보고 싶다.
    • bun이 가진 장점은 충분히 매력적이지만 프로젝트 마감기한이 3월 이내로 여유가 있지 않아서 어렵다고 생각했다.
    • 아직 생태계가 크지 않다는 것과 나 포함 팀원들의 학습 기간을 산정하여 익숙한 기술스택이 더 낫다고 판단했다.
    • yarn berry 또한 zero install로 브랜치를 옮겨가면서 작업할 때 매우 편한 것으로 알고있는데, 같은 이유로 pnpm을 선택하게 되었다.

pnpm-workspace

  • 모노레포 관리 매니저이다.
  • workspace 참조를 통해 내부 패키지간 참조를 쉽게 구성할 수 있다.
  • 이외에도 catalog를 활용해서 의존성 버전을 중앙에서 쉽게 관리할 수 있다.

turborepo

  • 모노레포 빌드, 실행 최적화를 돕는 라이브러리이다.
  • 빌드, 린팅, 포메팅 등등의 작업을 모든 패키지 전역적으로 실행해야 할 때, turbo.json에 정의된 방식대로 각 패키지 스크립트가 병렬적으로 실행이 된다.
    • 이 때 의존관계가 turbo.json에 명시되어 있으면 반영해서 빌드 순서를 조정한다.
  • 이후 결과물을 캐싱하여, 변경사항이 없는 패키지들은 캐시를 활용한다.

changeset

  • npm에 배포할 떄 각 패키지의 버전관리를 돕는 도구이다.
  • pnpm changeset 명령어를 통해 변경사항을 계속 기록할 수 있다.
  • major, minor, patch 여부도 쉽게 선택할 수 있게 되어있으며, 어떤 패키지의 변경사항인지도 손쉽게 선택할 수 있게 커멘드창에서 간략한 ui를 제공한다.
    • 특히 좋은 점은 changeset을 포함한 여러 pr이 메인에 합쳐지더라도 버전이 충돌되지 않고 자동으로 처리된다.
    • package.json 버전을 바로 올리는 것이 아니라, ./changeset 하위에 변경사항들을 모아뒀다가, changeset publish를 하게 되면 package.json의 버전을 알맞게 올려주고 릴리즈한다.

tsup

  • esbuild 기반으로 작동하는, 가볍고 트리셰이킹 지원되는 번들러이다.
  • 4 버전 이후로 zero config로 설정이 가볍다고 해서 선택하였다.
    • 우선은 개발에 치중하고 트리셰이킹, 번들 사이즈 교체하려고 생각했다.
  • rollup이라는 옵션도 존재했지만.. 우선은 복잡성을 올리지 않는 간단한 세팅을 중요하게 생각했다.

3. 스타일 관리 방식 및 ui 구현 방식 설정

Tailwind css

선택한 이유

  • css 작성 방식은 tailwind css를 활용해서 작업하기로 하였다.
  • 기존 프로젝트가 tailwind css를 활용했기 때문에, 기본적으로 팀원들이 모두 알고있는 기술 스택이라서 큰 고민은 없었다.
  • tailwind-variant에서 slots 구조를 지원하기 때문에 compound component 패턴에서도 스타일 작성을 깔끔하게 할 수 있고, props 타입도 깔끔하게 처리할 수 있을 것 같다.

걱정되는 점

  • 걱정되는 점은 해당 디자인 시스템을 사용하는 레포에서 반드시 tailwind css 의존성을 안고 가야한다는 점이다.
  • 바닐라 css를 활용하거나, css in js 방식을 채택할 경우 이 문제를 해결할 수 있다.
    • 하지만 다른 문제 때문에 선택하지는 않았다.
    • css in js 방식은 런타임 오버헤드 & 서버사이드 렌더링 호환성 문제가 생길 수 있다.
    • 바닐라 css 방식은 클래스네임 지정 및 기본 세팅에 많은 시간이 소요될 것 같고, 타입 관련 처리도 어렵지 않을까 라는 생각이 들었따.

4. 느낀 점

  • 그럼에도 불구하고, tailwind css를 선택했기 때문에 tailwind css가 갖는 장점을 최대한 활용하고자 한다.
  • 나중에 바꾸게 된다면 조금 큰 작업이 되겠지만, 추후 바꾸게 되더라도 좀 더 쉽게 바꿀 수 있도록 style 관련 코드를 깔끔하게 잘 작성해놓으면 좋을 것 같다.
    • 해당 디자인 시스템 추상화도 잘되고, 동문 네트워크도 더 잘되서 라이브러리를 동문 네트워크 외부 사용자도 활용할 수 있게끔 확장한다면 css in js 방식으로 추가 의존성을 갖지 않는 방향으로 리팩토링이 필요하지 않나 싶다.
개발일지