스타트업에서 디자인시스템이란

endmoseung·2025년 1월 11일
디자인시스템
69
post-thumbnail

본인의 회사가 스타트업이고, 사내에서 디자인시스템을 적용하려하거나 현재 적용중이신분들께 도움이 됐으면 하는 마음으로 이 글을 작성합니다.

1. 디자인시스템이란?

디자인 시스템은 목적을 가진 설계를 상호작용하여 통일된 하나의 집합체

디자인시스템을 한 문장으로 정의하면 위와 같습니다.
디자인시스템은 디자인 + 시스템의 합성어입니다.
디자인은 목적을 가진 설계를 하는 행위이고, 시스템은 무언가 상호작용하여 통일된 하나의 집합체를 말합니다.

디자이너와 이를 실제로 소스코드 결과물을 만들어내는 프론트엔드 개발자간의 협업으로 만들어낸 결과물로, 효율성을 증가시키고 많은 서비스들을 마치 하나의 서비스처럼 UI/UX를 제공할 수 있게 해주는 시스템이 디자인시스템입니다.

2. In 디자인시스템

디자인시스템이 언제 필요한지에 대해서 생각해볼 필요가 있습니다.

디자인시스템의 필요성

시스템화를 한다는것은 초기에는 필요 없습니다.
서비스가 고도화되고 많아진다면 이들을 관리해야합니다. 이를 관리할 포인트가 많아지고 복잡해지면 그때 시스템화에 대한 얘기가 나옵니다.
코드를 작성할때도 지역적으로 작성된 코드는 추상화하지 않습니다. 아직 그럴 필요가 없으니까요.
하지만 저는 충분히 전역적으로 사용될법한 코드나 2번이상 반복되는 코드는 추상화합니다.

추상화 : 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 개념 또는 기능을 간추려 내는 것을 말합니다.
목적을 명확히 하여 복잡한 것은 숨기고 핵심만 드러내는 것이 추상화의 목적입니다.

마치 코드를 추상화하는것처럼 사내에서 적용해야하는 UI/UX에서 반복적인것들이 많아지고 이를 관리해야함에 필요이상 피곤을 느끼기 시작하면 그때 디자인시스템을 만들면 좋습니다.

저희 회사에서로 예를들면 디자인시스템을 개발할 당시 7개의 프로젝트에 대한 디자인이 다 달랐습니다.
그리고 디자이너도 두분 계셨고 이를 개발해야하는 3명의 프론트엔드 개발자가 있었습니다. 그러다보니 아래와 같은 문제가 발생했습니다.

  • 그래서 예외케이스가 많이 생김
  • 디자인 파편화, 통일성이 없음
  • 생산성이 떨어짐

그래서 이를 하나로 통합하여 위와 같은 문제들을 해결하고자 했습니다.

배포환경

이렇게 잘 개발해둔 디자인 시스템은 어떻게 배포환경을 구축하면 좋을까요?
정말 운좋게도 우리회사가 모노레포로 존재하거나 그럴 예정이라면 하나의 패키지로 추가하고 그 것을 의존하면 그만입니다.
하지만 그렇지 않다면요? 저희는 멀티레포 환경이라면요?
그럴때는 다음과 같은 방법이 있습니다.
1. Submodule, Subtree를 활용한 Git으로 통합하기.
2. NPM으로 배포해서 이를 참조하기.

Submodule, Subtree

Submodule과 Subtree로 이를 통합하는것은 꽤나 자연스럽습니다.
이 둘은 비슷하지만 조금은 다른것이 있습니다. Subtree는 통합한 곳에서 직접 소스 코드를 변경할 수 있지만, Submodule은 소스 코드를 수정할 수 없습니다.(마치 Readonly인것 처럼) Submodule의 코드를 수정하려면 별도로 저장소에서 변경 후 커밋하여 통합해야합니다.

그리고 이를 배포에 통합하기 위해서는 조금 더 번거롭습니다.
코드가 직접 소스코드에 통합되기 때문에 빌드파이프라인에 수정이 필요합니다.
예를들어 도커환경에서 이를 도입하려면 추가적인 git을 통합해주는 코드가 추가돼야합니다.
자세한 건 제가 과거에 작성했던 블로그글이 있어서 대신 첨부하겠습니다.

Submodule CI/CD 통합하기

NPM 배포

NPM으로 배포할수도 있습니다. Private하게 배포해야할경우 Private레포로도 관리할 수 있습니다.(추가적인 과금 필요)
위와는 다르게 프로젝트에서 NPM 패키지를 설치하면 바로 사용할 수 있어 설정이 간단합니다.
하지만 결과물을 수정하고 반영하려면 추가적으로 작업해서 NPM에 재배포해야하는 번거로움이 존재합니다.

웹, 앱

만약 우리 서비스가 웹과 앱을 둘 다 개발하고 있다면요?
그러면 이론상 하나의 컴포넌트는 웹과 앱에서 필요한 소스코드 두 벌로 관리될 필요가 있습니다. 각각의 환경은 다르니까요. 안그래도 한정된 자원인데 이를 두 벌로 관리하는것은 쉬운일이 아닙니다.

만약 우리 앱을 토스나 당근처럼 대부분은 웹뷰환경으로 구축한다고 하면 디자인시스템을 웹 환경으로 구축하면 됩니다.(모바일 웹뷰 환경에서 가끔 잘 동작하지 않는다는 스트레스가 존재한다고 합니다.)
하지만 이미 웹과 앱이 있는데 앱은 네이티브 컴포넌트를 활용하여 코드를 작성했다고 하면 결국 두벌로 관리할 수 밖에 없습니다.

문서화

앞서 제가 시스템은 통일된 하나의 집합체라고 설명드렸습니다.
그럼 이를 하나의 집합체로 만드는 과정뿐만 아니라 하나의 집합체로 설명하기 위한 문서는 필수입니다.
똑같은 것이라도 사람마다 다르게 바라볼 수 있고 다른 결과물로 나올 수 있습니다. 그러면 시스템화하려고 했던 의도와는 벗어날 수 밖에 없습니다.
그래서 문서화가 필요합니다.
보통 디자인시스템에서 가장 많이 활용하는 문서 가이드라인은 Figma와 Storybook입니다.
디자인에 대한 문서화는 Figma로 소스코드에 대한 문서화는 Storybook을 활용합니다.
저는 Storybook에 대해서 얘기해보려고 합니다.

Storybook

Storybook 공식문서에서는 다음과 같이 설명하고 있습니다.

Storybook은 UI 컴포넌트와 페이지를 독립적으로 구축하기 위한 프론트엔드 워크숍 도구입니다. 수천 개의 팀이 UI 개발, 테스트, 문서화를 위해 Storybook을 사용하고 있습니다. 이 도구는 오픈 소스이며 무료로 제공됩니다.

Storybook을 활용하면 Figma로 정의된 디자인을 소스코드로 구현환 결과물을 실제 구현체로 확인할 수 있고 이를 테스트하거나 추가적인 설명을 달아줄 수 있습니다.
예를들어 Header컴포넌트를 하나 만들면 아래와 같은 구조를 가집니다.

// 폴더 구조
src/
├── components/             
│   ├── Button/             
│	│	├── Button.tsx	버튼 구현체
│	│	├── Button.stories.tsx  버튼 소스코드를 스토리북에 표현하기 위한 코드

//Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react';
import { fn } from '@storybook/test';

import { Button } from './Button';

// More on how to set up stories at: https://storybook.js.org/docs/writing-stories#default-export
const meta = {
  title: 'Example/Button',
  component: Button,
  parameters: {
    // Optional parameter to center the component in the Canvas. More info: https://storybook.js.org/docs/configure/story-layout
    layout: 'centered',
  },
  // This component will have an automatically generated Autodocs entry: https://storybook.js.org/docs/writing-docs/autodocs
  tags: ['autodocs'],
  // More on argTypes: https://storybook.js.org/docs/api/argtypes
  argTypes: {
    backgroundColor: { control: 'color' },
  },
  // Use `fn` to spy on the onClick arg, which will appear in the actions panel once invoked: https://storybook.js.org/docs/essentials/actions#action-args
  args: { onClick: fn() },
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

// More on writing stories with args: https://storybook.js.org/docs/writing-stories/args
export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
};

export const Secondary: Story = {
  args: {
    label: 'Button',
  },
};

export const Large: Story = {
  args: {
    size: 'large',
    label: 'Button',
  },
};

export const Small: Story = {
  args: {
    size: 'small',
    label: 'Button',
  },
};

이처럼 Storybook을 활용하면 컴포넌트를 실제 서비스에서 사용하기 위한 코드 외에, 이를 Storybook에서 표현하기 위한 별도의 코드를 작성해야 합니다. 따라서 이로 인해 추가 작업이 불가피하며, 팀의 리소스가 더 요구될 수 있습니다.

만약 디자인 시스템을 실제로 웹에 배포한다고 가정하면, 관리 포인트가 크게 늘어납니다.

  1. 디자인 시스템이 Private 환경에서만 사용 가능하다면, 내부 VPC를 구축하고 접근 권한을 관리해야 합니다. 이 과정은 시간과 비용이 추가적으로 소모됩니다.
  2. 회사에 DevOps를 잘 아는 사람이 없거나 시스템이 자동화되어 있지 않다면, 매번 수동으로 배포해야 할 수 있습니다.

이처럼 Storybook을 활용한 디자인시스템은 또 하나의 서비스여서 이를 유지보수하기위한 추가적인 작업이 발생할 수 밖에 없습니다.

물론 문서화의 용도로 너무 잘 동작하지만 제가 쓴 글의 목적은 스타트업에서 디자인시스템이니 다시한번 생각해볼 필요가 있습니다.

완성도

완성도 높은 디자인 시스템을 구축하기 위해서는 팀 간의 끊임없는 소통과 지속적인 개선이 필요합니다.
특히, 디자인 시스템에서는 디자인 토큰을 활용하여 소통의 효율성을 높일 수 있습니다.

예를 들어, 우리 디자인 시스템에서 A 서비스의 Primary 색상은 blue 계열, B 서비스의 Primary 색상은 green 계열이라고 가정해보겠습니다.
각 서비스의 색상을 디자인 토큰으로 정의해두면, 색상을 참조하는 요소들을 한 번의 수정으로 업데이트할 수 있습니다.(마치 코드에서 상수를 참조하는것 처럼) 이는 디자인 변경이 필요할 때 발생하는 반복 작업을 줄여주고 통일된 명칭으로 협업 효율성을 늘려줍니다.

3. 효용성

체계적으로 관리하면 좋다는것은 누구나 알고 장점에 대해서도 충분히 이해했습니다.
그럼 정말 이걸 관리하면서 제품을 만들어가는 것이 스타트업에서 충분히 효용성이 있을까요?
시스템은 트레이드오프가 존재합니다. 체계적으로 관리할수록 그 결과물로 인한 생산성은 증가합니다. 하지만 관리해야할 포인트가 많아진다는것은 곧 유지보수에 시간을 많이 할애할 수 밖에 없습니다.
왜냐하면 디자인시스템에 컴포넌트를 추가하거나 수정해야할때마다 디자이너와 개발자가 회의를 해야하고 이를 실제 소스코드로 구현해야합니다.
그리고 이 구현된 시스템을 실제로 활용할 수 있도록 사내에 홍보해야합니다.

  1. 그럼 누가 이 시스템을 관리해야할까요?
  2. 이 시스템을 유지하고 신규 개발해서 효용성이 있다는것을 어떻게 드러낼 수 있을까요?
  3. 비즈니스를 개발하는것보다 시스템을 개발하는것이 더 중요하다는것은 어떤 수치로 증명할 수 있을까요?

스타트업은 제한된 자원으로 혁신적인 아이디어를 구현하려는 도전적인 상황을 해결하는 회사입니다.
제한된 자원이라는것이 중요한 핵심인데요.
어느 회사나 활용하는 자원을 최대한 효율적으로 해야하는것은 맞지만 스타트업은 더 효율적으로 활용해야한다고 생각합니다.
그래서 디자인시스템을 활용한다는것도 생각보다 비효율적일수도 있습니다. 비즈니스가 더 중요하고 당장에 살아남는게 더 중요할때가 많으니까요.

그럼 어떻게 효율적으로 해보면 좋을까요?

제가 생각한 좋은 방법은 이미 잘 구축된 UI라이브러리를 상속해서 구현하는 방법입니다.
이미 잘 구축된 많은 컴포넌트를 제공할뿐더러 Storybook이나 Figma로도 이미 오픈소스로 제공하는 경우가 많습니다.
물론 장점만 있는것은 아닙니다. 우리 회사만의 독창적인 디자인 결과물 대신 이미 개발된 디자인을 채택해야하기 때문입니다.

그래서 제가 생각한 방법은 기능만 잘 구현해둔 HeadlessUI를 래핑하는것입니다.
최근 2024년 자바스크립트 생태계에서 가장 인기가 많은 순위 1등은 Shadcn이라는 UI 라이브러리였습니다. 무려 38.0K개의 Star수를 받은 라이브러리입니다.
보통 다른 UI 라이브러리는 이를 install하고 이것이 빌드시 혹은 직접 빌드 결과물에 포함됩니다.
그래서 이를 직접 커스터마이징하려면 복잡하고 번거롭습니다.
하지만 Shadcn은 다릅니다. 아래와 같이 터미널에서 명령어를 작성해주면 해당 컴포넌트가 우리 소스코드 내에 통합됩니다.
그래서 이를 직접 수정하거나 관리하기에 유리합니다.

// yarn, npm
npx shadcn@latest add {필요한 컴포넌트(ex: Button)}
//pnpm
pnpm dlx shadcn@latest add {필요한 컴포넌트(ex: Button)}
// 이처럼 필요한 컴포넌트만 통합가능

Shadcn은 아니지만 오픈소스를 활용해서 디자인 시스템을 구축한 얘기가 잘 정리된 글이 있어서 같이 첨부드립니다.
인프런 디자인 시스템 구축기 (a.k.a. 4개의 디자인시스템 관리하기)

4. 끝으로

디자인시스템이 회사에서 일의 효율성을 올려주고 프론트엔드 개발자의 커리어에서 의미있는것은 사실입니다.
그리고 실제로 큰 회사들은 이를 잘 활용하고 때로는 오픈소스로도 관리할정도로 멋진일들을 하는것만 같습니다.
하지만 스타트업에서 이것을 잘 활용하는것은 쉬운일이 아닙니다. 우아하고 잘 활용된다는 그 양면에는 그것의 퀄리티를 올리고 유지보수한다는것이 있으니까요.

그래서 스타트업에서 디자인시스템을 도입한다면 많은 논의를 해보셨으면 좋겠습니다.

  1. 정말로 우리는 디자인시스템을 도입하고 개발할 의지가 있는가?
  2. 앞으로 꾸준히 디자인시스템에 대한 학습과 내부 공유를 하며 퀄리티를 올리는데 기꺼이 관심을 쏟을것인가?
  3. 현재 우리 상황에서 충분히 효용성이 있는가?

그리고 도입하기를 결정하셨다면 고독하고 힘들겠지만 끊임없이 논의하고 공유해서 좋은 결과를 얻으셨으면 좋겠습니다.

저도 아직 디자인시스템을 공부하고 있습니다. 그래서 글이 부족하거나 잘못된 부분이 있으면 편하게 피드백 주시면 감사하겠습니다! 감사합니다.

profile
endmoseung
Walk with me
이전 포스트

혐오를 혐오하고 나를 사랑하자

다음 포스트

최신 모듈 번들러의 진화(NextJS, React)

2개의 댓글

comment-user-thumbnail
호두파파
2025년 1월 13일

너무나 멋진 글 잘 읽었습니다.

1개의 답글

관련 채용 정보