쉬운 설명
같은 회사 제품인데 페이지마다 버튼 모양이 다르고 색이 미세하게 다르면, 사용자는 무의식적으로 '엉성하다'고 느낍니다. 디자인 시스템은 이 불일치를 막기 위해 '우리 회사는 이 색, 이 글꼴, 이 버튼 스타일을 쓴다'를 한곳에 정리해 둔 것입니다.
왜 따로 만들어야 하나 하면, 회사가 자랄수록 화면 수가 빠르게 늘기 때문입니다. 디자이너 3명, 개발자 10명일 때는 회의로 일관성을 유지할 수 있지만, 디자이너 20명, 개발자 100명이 되면 회의로는 불가능합니다. 시스템 형태로 명문화하지 않으면 같은 회사 안에 미묘하게 다른 버튼이 십수 종류가 생깁니다.
보통 세 층으로 이루어집니다. 가장 아래는 토큰(색·간격·글꼴 크기 같은 원시값), 그 위는 컴포넌트(버튼·입력칸·카드처럼 토큰을 조합한 부품), 가장 위는 패턴(여러 컴포넌트가 모인 폼·대시보드 같은 화면 단위 사용법). 이 세 층을 문서·코드·디자인 파일이 함께 공유합니다.
도구 측면에서는 Figma(디자인)와 Storybook(코드)이 사실상 표준이 됐습니다. 디자이너는 Figma의 컴포넌트 라이브러리에서 부품을 가져와 화면을 만들고, 개발자는 Storybook에서 같은 이름의 컴포넌트를 코드로 가져옵니다. 두 도구가 같은 이름·같은 토큰을 공유할 때 시스템이 실제로 살아 움직입니다.
좋은 디자인 시스템의 효과는 단순히 보기 좋다는 게 아닙니다. 새 화면을 더 빨리, 더 일관되게 만들 수 있게 하고, 접근성·반응형·다크 모드 같은 가로지르는 요구사항을 한 번에 처리할 수 있게 합니다. 다만 도입 비용도 큽니다 — 만드는 사람과 사용하는 사람 사이에 끊임없는 소통과 갱신이 필요합니다. 회사 규모가 일정 이상일 때 진가가 드러납니다.
비유로 보면
디자인 시스템은 한 출판사의 편집 매뉴얼과 비슷합니다. 어떤 책을 만들든 같은 글꼴·여백·각주 스타일을 쓰고, 표지·속표지·차례의 모양이 일정합니다. 매번 처음부터 결정하지 않아도 되니 책 한 권을 만드는 시간이 줄고, 독자는 출판사의 스타일을 한눈에 알아봅니다.
어디에서 만나나
앱·웹·태블릿·키오스크를 동시에 운영하는 회사, 여러 팀이 같은 브랜드 아래 다른 제품을 만드는 그룹사, 외부 파트너에게 자기 브랜드를 입혀야 하는 플랫폼 사업자(쇼피파이·구글 클라우드 콘솔)에서 진가가 큽니다. Material·HIG·Polaris·Carbon 같은 공개 시스템을 참고로 자체 시스템을 만드는 경우도 많습니다.
작은 예시
당근·토스·우아한형제들처럼 화면 수가 많은 서비스는 모두 자체 디자인 시스템을 운영합니다. 새 기능을 만들 때 디자이너가 처음부터 그리지 않고 시스템에 등록된 컴포넌트를 가져다 조립하고, 개발자도 같은 이름의 컴포넌트를 코드로 가져다 씁니다. 새 화면이 출시 첫날부터 '회사 같은 모양'으로 나옵니다.
자주 하는 오해
한 줄 정리
좋은 디자인 시스템은 '예술가의 손'을 줄이고 '동료의 시간'을 살립니다. 회사 화면 수가 늘기 시작했다면 도입할 가치가 있습니다.