The English version of this article for global developers can be found here!
https://medium.com/@osohyun0224/the-growth-story-of-a-startups-design-system-694f0409ae9e

안녕하세요 👋🏻 프론트엔드 개발자 Garden, 오소현입니다 🌱

저는 현재 Vling을 서비스하는 스타트업에서 근무하고 있는데요!
작년 하반기 저에게 가장 큰 DX 업무였던 사내 디자인 시스템 도입 과정과, 4-5개월 간의 디자인 시스템 성장기를 공유해보고자 합니다 :)

Intro.

저희는 프론트엔드 개발자 3-4명과 프로덕트 디자이너 1명으로 구성된 소규모 서비스 조직입니다. 저희의 디자인 시스템 도입의 주된 목표는 사내 서비스가 사용자에게 일관된 사용자 인터페이스(UI)를 제공함으로써, 사용자 경험을 향상시키고 개발자와 디자이너 간의 협업을 원활하게 하여 전반적인 생산성을 높이는 것입니다. 이를 위해 지난 4-5개월 동안 디자인 시스템을 구축하고, 이를 실제 작업에 적용하여 운영해오고 있습니다.

이번 포스팅에서는 저희 조직에 디자인 시스템이 왜 필요했는지, 그리고 이 시스템을 어떤 과정을 통해 구축했으며, 구축된 시스템이 실제로 어떻게 적용되어 운영되고 있는지에 대해 자세히 소개하고자 합니다. 디자인 시스템 구축 이전과 비교하여 현재 어떤 점이 개선되었는지, 그리고 앞으로 진행할 방향성과 도전 과제를 언급하며 마무리 해보겠습니다 :)

1. 디자인 시스템의 필요성?

🤔 수많은 회사에서 도입을 주저하는 이유

자원이 제한된 소규모 스타트업에서 디자인 시스템을 도입하는 것은 초기 투입 시간 대비 즉각적인 생산성을 기대할 수 없어, 디자인 시스템에 회의적이기도 합니다. 특히 저희처럼 규모가 작은 조직일수록 더욱 도입이 망설여지는데요, 먼저 한정된 인력과 자원으로 인해 디자인 시스템 개발에 할애할 수 있는 시간이 많지 않습니다. 개발자 몇 명으로 구성된 팀이 기존의 개발 업무를 유지하면서 추가적인 디자인 시스템 프로젝트를 진행하기란 쉽지 않은 일입니다.

또한, 디자인 시스템은 단순히 개발자들만 진행할 수 없고 디자이너와의 끊임없는 소통하며 계속 고도화해야하는 작업입니다. 디자이너와 개발자 간에 의사소통의 효율이 떨어질 경우, 디자인 시스템 구축 과정에서 발생하는 불일치가 업무의 속도를 지연시키게 되는데 결과적으로 팀의 역량을 분산시키고, 프로젝트 전반에 걸쳐 효율성을 저하시킬 수 있습니다.

이와 같은 이유들과 다른 이유들로, 많은 작은 스타트업들이 디자인 시스템을 도입하는 것을 쉽게 결정할 수 없지만 저는 다음과 같은 디자인 시스템의 장점과 현재 서비스에 되어야할 필요성을 느끼게 되었습니다.

⛳️ 디자인 시스템을 도입하게 된 목적

📌 서비스 유저에게 일관된 UI 제공 ⭐️

저희 서비스는 어느덧 5년 동안 서비스되어왔고, 그 사이에 수많은 기능들이 출시되었습니다. 현재 메인 서비스의 수가 20개여 가까이 되면서, 이전에 출시된 기능들은 기존의 UI를 유지한 채 새롭게 출시되는 기능들은 새로운 UI 디자인을 적용하게 되었습니다. 이로 인해 서비스 전반에 걸쳐 UI의 일관성이 떨어지는 문제가 발생할 위험이 높았습니다. 특히 사용자들이 자주 이용하는 주요 기능들은 지속적으로 UI가 개선되고 있지만, 그렇지 않은 기능들은 바쁜 운영 일정 중에 개선이 늦어지고 있었습니다.

이러한 상황을 다음과 같이 개선되는 것에 기대하게 되었는데요, 저희 회사는 전체적으로 유튜브 마케팅을 위한 광고주, 유튜브 채널을 운영하는 유튜버가 자신이 원하는 유튜브 데이터를 검색하고 그를 바탕으로 각 유저가 서비스 내에서 효율적인 광고를 진행하기 위해, 자신의 채널 운영을 위해 다양한 목적을 가지고 여러 서비스를 이용하게 됩니다. 따라서 유저가 서비스의 다양한 파트를 넘나들 때도 일관된 인터페이스를 경험할 수 있도록 하는게 매우 중요했습니다. 왜냐하면 일관된 UI는 유저의 만족도를 높이고, 브랜드 신뢰성을 강화하는데 중요한 역할을 하기 때문입니다.

📌 개발 - 디자인의 빠른 생산성 ⭐️

저희는 각 업무를 진행 시에 독립적으로 UI 컴포넌트를 개발하고 있었습니다. 이 과정에서 이미 존재하는 공통 컴포넌트의 존재를 모르고 각자 새로운 컴포넌트를 개발하게 되는 경우가 있었습니다. 또한, 비슷한 기능을 가진 기존 컴포넌트가 있음에도 불구하고, 약간의 차이로 인해 새로운 컴포넌트를 만들거나, 기존 컴포넌트를 적절히 재사용하지 못하는 경우가 많았습니다. 이는 각 컴포넌트가 조금씩 다른 UI나 기능을 가지고 있어서, 이를 props로 구분하거나 새로 작성해야 하는 불필요한 개발을 덧붙여서 진행해야했습니다.

이러한 문제를 해결하기 위해 다음과 같이 개선되는 것을 기대하게 되었는데요, 디자인 시스템을 통해 모든 컴포넌트는 시스템 내부에서 관리되게하고, 팀원 각자가 어떤 컴포넌트들이 이미 존재하는지 쉽게 파악할 수 있게 됩니다. 결국은 컴포넌트의 재사용을 증대시키고, 중복 개발을 방지함으로써 전반적인 개발 속도를 높이는 데 크게 기여할 것이라고 기대하게 되었습니다.

📌 불필요한 스타일 QA 시간 단축과 소통의 개선

저희 팀에서 QA 과정에 소요되는 시간이 어느 정도 존재했습니다, 디자이너가 각 기능의 스타일을 직접 검토하는 과정이 있었는데, 기능 QA 외에도 각 컴포넌트의 스타일을 일일이 검사해야 하는 번거로움으로 이어졌습니다. 또한, 디자이너의 입장에서는 개발 팀이 현재 어떤 컴포넌트들이 구현되어 있는지 명확히 파악하기 어려웠습니다.

디자인 시스템과 스토리북의 도입을 결정하면서 스토리북을 통해 개발된 모든 컴포넌트를 한 눈에 볼 수 있게 되었고, 디자이너는 스토리북을 활용하여 실시간으로 각 컴포넌트의 스타일과 기능을 확인할 수 있게 되었습니다. 이로써 QA 과정에서 스타일 검수를 줄여 전체적으로 시간을 단축시키는 동시에, 디자이너와 개발자 간의 커뮤니케이션을 강화하고, 프로젝트 관리의 효율성을 크게 향상시킬 것으로 기대하게 되었습니다. 프론트엔드 개발자는 비즈니스 로직에, 프로덕트 디자이너는 UX에 보다 집중할 수 있게 되는 것이죠 :)

2. 도입 전 고민했던 내용들

작년 하반기 사내 디자인 시스템의 아키텍트를 맡게 되면서, 정말 많은 고민을 했었는데요 ㅎㅎ
전체적으로 아래와 같이 고민했던 내용들의 주제를 잡아보고 한번 정리해보았습니다 !

📚 UI 오픈소스의 사용

디자인 시스템 도입 전에 가장 많이 고민했던 주제는 UI 오픈소스를 사용해서 래핑해 개발해야할까 고민이 있었습니다. 이렇게 고민하게 된 UI 오픈소스의 도입시 제가 생각한 장점은 다음과 같았습니다.

UI 오픈소스 도입 시 장점

✅ 해당 오픈소스를 개발하는 전담 개발 팀이 있는 만큼, 수준 높은 라이브러리를 경험해보면서 설계, 구현된 코드를 보며 코드 품질을 높게 유지할 수 있을 것 같았습니다.

✅ 이미 사용하는 유저들이 있는 검증된 라이브러리로, 컴포넌트의 퀄리티가 특정 수준 이상으로 잘 유지될 것 같았습니다.

✅ 디자인 시스템 구축 속도가 오픈소스 기반으로 래핑되어 개발되다보니 빠른 속도로 개발 및 안정화될 것 같았습니다.

위와 같은 장점으로 생각했던 UI 오픈소스들을 (대표적으로 Radix, chakra, MUI, Mantine 을 많이 공부했습니다 📚) 학습하면서 저희 서비스의 맞게 가장 최적화된 오픈소스 UI를 고민했습니다.

UI 오픈소스 도입 전 중요하게 생각했던 것

1. 디자이너의 디자인 시스템을 구현하기 위한 커스터마이징이 잘 되는지와
2. 디자이너의 고유한 디자인 시스템을 해치지 않는지(디자이너가 따로 오픈소스를 학습해야하는지)를 고민했는데요,

수 많은 고민 끝에 팀원 모두가 오픈소스를 학습해야하고 이를 바탕으로 커스터마이징 규약을 정하면서 시간에 많이 할애할 수 없는 점을 이유로 들며 개발하는데 시간이 걸리더라도 UI 오픈소스를 직접적으로 사용해서 구현하지 않기로 하고, 처음부터 만들기 시작했습니다.

UI 오픈소스를 기반으로 제대로 구축하여 만들어가는 회사의 블로그 글 인프랩 - 플랫폼 팀 없는 오픈 소스 기반의 디자인 시스템 구축 회고을 참고하면 좋을 것 같아요! UI 오픈소스를 사용해 제대로 구현하려면 개발, 디자이너들도 많은 학습과 시간을 쏟아야 함을 깨닫게 된 계기가 되었습니다. 현재 각 디자인 시스템 컴포넌트를 개발하면서 참고용으로 Radix를 대표적으로 참고하여 구현하고 있습니다!

🗣️ 어디까지 커스터마이징 할 수 있을까?

디자인 시스템을 공부하고 도입하면서 어려운 고민 중 하나였던 어디까지 커스터마이징 할 수 있을까? 이었습니다.
초반에 디자인 시스템을 잘 잡으면서 컴포넌트를 구현하다가도 새로운 프로덕트들이 기획되면서 처음에 만들어 둔 디자인 시스템만으로는 개발하기 쉽지 않아 다양하게 커스터마이징을 고려하게 되기 쉬운 상황에 놓이게 됩니다.

이렇게 사용하는 모든 사람의 커스터마이징 요구를 반영하게 되면 점점 원래 시스템화 했던 디자인 시스템의 본질을 잃어가고, 본 목적을 잃게 되기 때문에 저희는 다음과 같이 커스터마이징의 규약을 정해보기로 했습니다.
디자인 시스템을 처음 설계할 때 시스템의 본래 원칙과 커스터마이징 간격을 잘 유지하는게 매우 중요했습니다 :)

우리의 커스터마이징 규약

저희는 우선 디자이너의 의견을 적극 반영하는 것을 최우선으로 두었습니다. 디자이너의 요청대로 개발을 우선적으로 진행하며 필요한 부분에 대해서는 추가적으로 고민하게 됩니다.

그러다가 커스터마이징을 처음 고민했던 상황이 있었습니다. 한 번은 모바일 사이즈의 버튼 컴포넌트가 기존 디자인 시스템의 버튼 사이즈 규약과 달라 문제가 생겼습니다. 이때 개발팀에서는 모바일 사이즈에 대한 props 옵션을 추가하여 우선 이슈를 해결했습니다. 이렇게 꼭 필요한 상황에서, 디자인 시스템의 기본 원칙을 유지하면서도 필요한 커스터마이징을 할 수 있는 유연성을 발휘하고자 했습니다.

저희는 디자인 시스템을 일종의 제약이자 룰로 존중하면서, 커스터마이징은 꼭 필요한 경우에만 한정하여 수행하는 것을 규약으로 정의하고 개발했습니다.

그 정도의 선은 시스템을 운영하면서 점차 감을 잡아가며 최적의 방향을 찾아가고 있습니다!

저희는 디자인 시스템의 본질을 잃지 않으면서도 각 상황에 맞는 최선의 해결책을 항상 고민하면서 개발해오고 있는 것 같습니다

3. 디자인 시스템 구축하기

본격적으로 저희가 개발하고 있는 디자인 시스템을 구축하는 과정을 함께 알아보겠습니다 :)

📦 1) 컴포넌트 단위로 관리하기

저희 팀은 현재 모노레포 구조로 프론트엔드 코드를 운영하고 있습니다. 이 구조를 통해 design-system 패키지 내에서 각 컴포넌트를 독립된 패키지로 개발하고 배포하는 것을 목표로 하고 있습니다. 이러한 방식으로 구현 했을 때의 장점은 각 패키지를 개별적으로 설치하여 사용할 수도 있고, 디자인 시스템을 구성하는 각 컴포넌트가 개별 패키지로 개발, 배포될 수 있기 때문인데요! 아래에서 더 자세히 살펴보겠습니다:)

✅ 독립적 개발 및 유지 관리 가능하기 때문입니다.

저희는 모든 컴포넌트를 직접 개발하며, 이렇게 하면 각 컴포넌트를 보다 쉽게 관리할 수 있습니다. 특히 디자인 시스템 개발 초기 단계에서는 컴포넌트들이 잦게 수정될 수 있으므로, 각각을 독립적으로 관리하는 것이 훨씬 더 좋게 생각되었습니다.

✅ 유연한 버전 관리를 진행할 수 있습니다.

각 컴포넌트를 개별적으로 버전 관리할 수 있다는 점은 우선 매우 큰 장점이라고 생각합니다. 개별 컴포넌트에 특화된 커스터마이징 로직이나 수정 사항을 독립적으로 적용할 수 있게 되고, 전체 디자인 시스템에 미치는 영향을 최소화하기 때문입니다.

현재는 저희가 직접적으로 개별 컴포넌트들에 대해 버전을 두어 관리하는 구조는 아니고, 컴포넌트 수정 시 팀 슬랙 채널을 통해 변경 사항을 공지하고, 스토리북에 이를 반영하는 방식을 사용하고 있습니다.

저희가 조금 더 큰 조직이 되거나, 디자인 시스템이 안정화된다면 각 컴포넌트를 개별적으로 버전 관리 할 수 있도록 목표로 두고 있습니다 :)

📁 2) 폴더 관리

현재 저희는 디자인 시스템 폴더 관리를 다음과 같이 진행하고 있습니다.
바로 피그마 디자인 시스템 파일 구조를 기준으로 이와 동일하게 코드 구조와, 스토리북 내부에서도 스토리 파일들을 동일하게 구성하고 있습니다.

그 이유는 모두 동일시하여 저희끼리도 수 많은 컴포넌트 폴더들을 동일하게 관리하고, 더 빠르게 원하는 컴포넌트를 찾기 쉽도록 하기 위해서 위와 같은 구조로 운영해오고 있습니다!

🎨 3) 커스터마이징

디자인 시스템을 기반으로 프로덕트를 개발하다보면 커스터마이징의 요구사항이 생기기 마련인데요,
앞서 저희의 커스터마이징 규약에 말씀드렸던 모바일 사이즈의 버튼 컴포넌트가 기존 디자인 시스템의 버튼 사이즈 규약과 달랐던 예시로 설명해보겠습니다.

먼저 커스터마이징이 필요한 상황을 인지한 개발자는 디자이너와 먼저 논의 후 추가적인 디자인 후속 작업이 필요할지 논의합니다. 해당 상황에서는 디자인 후속 작업이 필요하지 않은 상황이었는데요!

그래서 팀 내 다른 개발자들과 1명 이상과 함께 논의를 진행하여 기존의 디자인 시스템의 구조를 어떻게 변경할지 고민합니다. 기존 변수들을 최대한 유지하고, 새로운 props를 추가하여 대응해야할지 토론 후, 저희는 결국 모바일 사이즈에 대한 옵션을 추가하는 방식으로 결정하게 되었습니다.

type ButtonProps = ComponentPropsWithRef<"button"> & {
..
  size: "XL" | "L" | "M" | "S"
  mobileSize?: "XL" | "L" | "M" | "S"
..

위와 같이 기존 디자인 시스템 컴포넌트 코드를 수정했다면, 팀 슬랙에 변경사항을 공지하고 스토리북에도 반영하는 방식으로 커스터마이징 상황에 대응하고 있습니다.

📜 4) 스토리북으로 문서화하기

저희는 모든 컴포넌트들을 직접 구현하면서 당연하게도 자체 UI 문서의 필요성이 높아졌습니다.
원래 디자인시스템이 있기 전에는 스토리북을 사용해서 개발하지 않았었기 때문에 디자인 시스템을 도입하면서 함께 스토리북도 같이 구축하게 되었습니다 :)

스토리북으로 UI 문서를 관리해야하는 이유는 개발자들끼리 쉽게 어떤 컴포넌트가 있는지 파악하기 쉬워야 했고,
가장 중요한 디자이너가 실제 컴포넌트의 모습과 동작을 확인할 수 있는 플레이그라운드가 필요했기 때문입니다.

저희는 개발이 완료되면 각 컴포넌트의 스토리북을 꼭 작성하여 모두가 확인할 수 있도록 구성하고 있습니다.

스토리북은 기능이 워낙 다양하지만, 저희는 기본적으로 개발하면서 디테일하게 다양한 옵션을 도입하여 구현하기는 어렵기에 각 옵션에 대한 설명, 테스트해볼 수 있는 환경 정도로만 만들어주고 확인하는 정도로 스토리북 문서를 작성하고 있습니다.

스토리북 스토리 코드는 다음과 같이 작성해주고 있는데요, 스토리북을 작성하기 위해 해당 기능을 사용하기 위한 추가 작업이 불가피하기 때문에 최대한 팀의 리소스를 줄이기 위해 핵심 옵션만 추가하여 구현하고 있습니다.

import type { Meta, StoryObj } from "@storybook/react"
import { Button } from "./Button"

const meta: Meta<typeof Button> = {
  title: "design-system/Button",
  component: Button,
  args: {
    label: "버튼",
    appearance: "default",
    size: "M",
  },
  argTypes: {
    appearance: {
      control: { type: "select" },
      options: ["primary", "default", "subtle", "link"],
      defaultValue: "default",
    },
    size: {
      control: { type: "select" },
      options: ["XL", "L", "M", "S"],
      defaultValue: "M",
    },
    label: {
      control: { type: "text" },
    },
    fluid: {
      control: { type: "boolean" },
      defaultValue: false,
    },
    isSelected: {
      control: { type: "boolean" },
      defaultValue: false,
    },
    isLoading: {
      control: { type: "boolean" },
      defaultValue: false,
    },
    isDisabled: {
      control: { type: "boolean" },
      defaultValue: false,
    },
    iconOnly: {
      control: { type: "boolean" },
      defaultValue: false,
    },
  },
}

export default meta
type Story = StoryObj<typeof Button>

export const Default: Story = {
  args: {
    label: "기본 버튼",
    appearance: "default",
    size: "M",
  },
}

.....

🌟 5) 타입스크립트의 도입

디자인 시스템을 도입하기 전 저희의 기술 스택은 Nextjs 였지만 Javascript를 사용하여 개발하고 있었습니다.
개발하면서 주로 jsdoc- (JSDoc으로 타입 힌트 제공하면서 주석 예쁘게 달기) 를 사용해서 자동으로 타입 힌트를 지원하도록 따로 만든 컴포넌트나, 커스텀 훅에 주로 작성해주는 방식을 택해왔습니다.

하지만 디자인 시스템을 도입하기전에 기존의 방식에 대한 한계를 느껴왔고, Jsdoc을 사용하면서의 문서화하는 게 쉽지 않았습니다. 이미 작성된 jsdoc을 수정사항이 생길때마다 챙겨서 수정해야하고 지속적으로 문서가 내용에 대해 업데이트되기가 어려웠기 때문입니다. 따라서 타입스크립트를 처음으로 도입하여 디자인 시스템을 구현하기로 하였습니다. 이에 저희는 명시적인 타입 사용으로 개발자들끼리의 디자인 시스템 코드 파악이 원활하도록 되었습니다 !

이를 계기로 디자인 시스템에 타입스크립트를 사내에 처음으로 도입한 이후, 점점 기존의 컴포넌트 코드들에도 적용하여 타입 스크립트로 전체 마이그레이션을 진행하게 되는 좋은 이점을 가져다주었습니다 :)

⚡ 6) Chromatic으로 배포하기

구축한 디자인 시스템을 배포하는 파이프라인을 어떻게 구축해야할까 고민이 많았습니다. 디자이너가 스토리북을 외부에서 확인할 수 있어야했기에 배포를 지원하는 기술 스택을 여러개 리서치 했습니다.

외부 URL로 공개 배포를 하게 되면 보안상의 이슈도 있기 때문에 스토리북을 내부에서만 볼 수 있도록 하고자 노력했는데요, 이를 만족시킬 방안을 chromatic에서 찾게 되었어요!

제가 디자인 시스템 배포 도구로 chromatic을 선택한 이유는 다음과 같았는데요!

✅ 손 쉽게 디자인시스템으로 빌드 배포가 가능하다. 파이프라인으로도 자동화하기 좋다.

✅ 크로마틱 내부 배포와, 외부 URL 배포 둘 다 지원한다.

저희는 보안상으로 외부 배포를 하지 않았기에 모두 크로마틱 레포 내부에서 스토리북을 배포하는 방식으로 진행하고 있습니다.

디자이너도 함께 크로마틱 내부에서 디자인 시스템을 확인하고, 쉽게 테스트할 수 있습니다.
저희는 현재 External collaborators 기능을 사용해서 디자인 시스템을 배포, 리뷰, QA하고 있습니다.

4. 디자인 시스템 운영하기

이번에는 구축된 디자인 시스템을 어떻게 개발하고 운영하고 있는지 FLOW를 중심으로 설명해보려고 합니다.

서비스 운영성 업무와 병행

우선 디자인 시스템에만 몰두하어 그것만 만들 수 있는 상황이 아니기도 했고, 디자인 시스템을 먼저 다 만들고 > 서비스에 적용하려면 많은 시간이 소요되었습니다. 따라서 저희는 기존 서비스 하나하나 개선해나거나, 디자인 시스템 기반으로 구성되어있는 신규 기능 UI를 개발할때 다음과 같은 방식으로 빠르게 디자인 시스템을 개발해 나아갔습니다.

위와 같은 방식으로 개발해나가아니 디자인 시스템 업무를 병행하면서 단독 개발보다는 확실하게 더 빠른 속도로 개발할 수 있었고, 팀 내부에서도 빠르게 공유되어 사용될 수 있었습니다.

지속적인 QA 진행

기능에 대한 QA가 진행될 때마다 해당 업무에 신규로 반영된 디자인 시스템 검수도 함께 진행되면서 QA도 개발과 같은 방식으로 진행되었습니다 :) QA 사항도 함께 고민하면서 디자인 시스템을 점점 고도화해나가아게 되는 계기가 되었습니다!

더 못 다한 운영성 이야기는 아래의 앞으로 남은 작업들에서 조금 더 해보기로 해요 :)

5. 앞으로 남은 작업들

첫 도입부터 현재 까지 4-5개월의 시간이 지났는데요, 이제는 어느정도 디자인 시스템이 성공적으로 자리를 잡았다는 생각이 들어 다음과 같은 고도화 작업들을 계획하고 있습니다.

사내 모든 서비스 UI 개선 반영

현재는 신규로 출시되는 서비스 외에 40% 정도의 기존 서비스 UI에서 디자인 시스템 기반으로 개선된 UI 개발 작업이 반영되었는데요! 앞으로 남은 모든 서비스의 UI를 전체 디자인 시스템 기반으로 반영하는 것을 목표로 두고 있습니다.

예시로 저희 서비스의 가장 많은 이용자 수를 자랑하는 수익계산기 서비스의 변화를 가져왔는데요,

기존에 비해 사용자에게 직관적이고 깔끔한 UI로 개선되었습니다 (멋지게 디자인 해주신 chans 감사해요!)

버전 관리

각 컴포넌트는 현재 버전을 따로 두면서 관리하고 있지는 않은데, 디자인 시스템 기반으로 개선 작업이 전체적으로 70% 이상 진행된다면 각 컴포넌트의 변경 사항을 잘 추적해야하는 필요성이 높아질 것이라 생각되었습니다. 따라서 앞으로 변경사항에 대한 버전을 따로 관리하고자합니다.

수많은 컴포넌트의 버전을 수동으로 관리하기보다, 다른 SemVer 등의 서비스에 의존하여 각각의 의존 관계를 자동으로 계산하여 안정성을 높이고 개발자들의 관리 비용을 줄이는 방안으로 생각해보고 있습니다 :)

6. 마무리하며,,

우선 소규모의 인원, 제한된 자원으로 짧은 시간 내에 도전적인 상황을 해결하는 회사 스타트업 내부에서 단위에서 디자인 시스템을 구축하는 것은 정말 쉽지 않았던 것 같습니다. 이렇게 도전을 함께 해주신 우리 팀 Glen, David 그리고 작년 초기 작업을 함께 해주셨던 Harry에게 너무 감사드리고, 디자인 시스템 컴포넌트들을 잘 설계해주신 디자이너 Chans께 정말 감사의 말씀을 드립니다.

디자인 시스템 후기를 쓰려면 너무 글이 길어지에 성과적으로 정리해보면, 저희가 도입하고자 했던 목적인 일관된 UI를 제공할 수 있게 된 것, 더 빠른 UI 작업 속도 등등 전체적으로 워크로드가 굉장히 빨라졌습니다. 스타일 QA 시간도 어느정도 줄었으니 서비스 안정성에 큰 기여를 하게 되었습니다.

전체적으로 저희 프로덕트 개발자, 디자이너가 비즈니스 본질 더 중요한 것에 집중할 수 있게 되었습니다.

저희는 5명 이하의 조직으로 이번 경험으로 저희와 같은 스타트업에서 디자인 시스템 도입을 고민하시는 분들에게 큰 도움이 되시기를 바랍니다. 저도 이번 업무로 더 나은 시스템화 컴포넌트를 설계하는데 많이 성장했던 것 같습니다.

다시한번 더 쉽지 않은 도전을 함께해 준 Glen, David, Harry, Chans 에게 정말 감사드립니다.

7. Thanks to.

추가로, 제가 반년 동안 디자인 시스템을 공부하면서 여러 회사의 디자인 시스템 관련 자료를 여러 번 학습했었습니다 ㅎㅎ 특히 정말 많은 도움을 받았던 영상과, 글, 그리고 개발자 분들을 소개합니다.

디자인 시스템에 관한 좋은 경험을 컨퍼런스 영상, 블로그로 공유해주신 모든 분들께 진심으로 감사합니다 :)

Toss - UX와 DX, 그 모든 경험을 위한 디자인 시스템
Toss - FEConf 2024 [B1] 바퀴 대신 로켓 만들기
Flex - FECONF 2022 [B1] 디자인 시스템, 형태를 넘어서
인프랩 Tech - 플랫폼 팀 없는 오픈 소스 기반의 디자인 시스템 구축 회고
에잇퍼센트 - 디자인 시스템, 디자인과 코드의 간극 줄이기
우아한테크코스 5기 - 행록 디자인 시스템