디자인 시스템을 만든다는 것: 무엇을 만들고, 어떻게 운영하나

디자인 시스템은 더 이상 가이드 문서에 머물지 않습니다. 팀이 같은 언어로 만들고 같은 기준으로 검증하기 위한 공유 자산이자 운영 체계로 확장되었습니다. 따라서 “디자인 시스템을 도입했다”는 말은 예쁜 문서가 생겼다기보다, 반복 작업을 줄이고 재사용성을 끌어올리는 UI 개발·운영 방식이 정립됐다는 의미로 이해하는 편이 정확합니다.

디자인 시스템, 결국 무엇을 만들어야 할까?

디자인 시스템의 활용 범위가 넓어지면서 접근 방식도 다양해지고 복잡해졌습니다. 그러다 보니 디자인 시스템을 도입하는 조직은 자연스럽게 어디까지 만들 것인지를 두고 고민하게 됩니다. 토큰, 컴포넌트, 문서, 스토리북처럼 후보는 많지만, 팀의 규모와 협업 방식에 따라 어디까지 산출물을 만들어야 하는지 헷갈리기 쉽습니다.

이 글에서는 피그마(Figma) 중심의 예시로, 디자인 시스템이 프로젝트에서 어떤 산출물로 구현되고 어떻게 운영되는지 핵심 흐름을 정리합니다. 아래 순서로 이어집니다.

• 디자인 토큰으로 재료를 표준화
• 컴포넌트 라이브러리로 꺼내 쓰는 구조 구성
• 스타일 가이드·API 가이드로 사용 원칙 문서화
• 코드 연결로 토큰을 플랫폼에 전파
• 디자인 시스템 QA로 디자인–구현 일치 검증
• 변경 영향 관리로 안전한 업데이트 운영

1. 디자인 토큰 (Design Tokens) : 디자인 시스템의 재료 표준 만들기

디자인 토큰 예시: 피그마 배리어블로 토큰을 구조화한 화면. 출처 : Material Design 3

디자인 시스템의 출발점은 화면이 아니라 재료의 규격을 통일하는 일이며, 그 역할을 하는 것이 디자인 토큰입니다. 디자인 토큰은 색상, 타이포그래피, 간격처럼 UI를 구성하는 최소 단위의 시각 속성에 이름을 붙여 표준화한 값입니다. (예: Primary/500, Spacing/8)

“왜 굳이 값에 이름을 붙여야 할까요?”

반복적으로 쓰이는 값을 뽑아 정의 → 이름 부여 → 공유해두면, 팀은 그 ‘이름표가 붙은 값’을 조합해 빠르게 인터페이스를 만들 수 있습니다. 레시피를 공유할 때 “소금 한 꼬집” 대신 1티스푼처럼 기준을 맞추는 것과 비슷합니다. 토큰은 디자인 시스템의 기반이자, 재사용성의 출발점입니다.

피그마에서 토큰을 정의하는 방법은 여러 가지가 있지만, 추천은 피그마 기본 기능인 배리어블(Variables)입니다.

방법	특징	권장
배리어블(Variables)	다양한 속성 지원, 비용·호환성 리스크 없음	✓
스타일 팔레트	기본 속성에 적합, 업무 맥락에 따라 선택
토큰 관리 플러그인	기능 풍부하나 비용·호환성 리스크 존재

2. 컴포넌트 라이브러리 (Component Library) : UI를 꺼내 쓰는 구조

컴포넌트 라이브러리 예시: 재사용 컴포넌트를 모아 배포하는 피그마 라이브러리

컴포넌트 라이브러리는 자주 쓰는 UI를 매번 제작하지 않고 ‘꺼내 쓰게’ 만드는 구조입니다. 토큰이 재료라면, 컴포넌트 라이브러리는 그 재료를 조합해 만든 재사용 가능한 완제품 묶음입니다. 디자인 시스템이 실제로 “속도”를 만들기 시작하는 지점은, 토큰을 넘어서 컴포넌트가 라이브러리로 배포되는 순간입니다.

버튼, 입력창, 카드처럼 자주 쓰이는 UI를 컴포넌트로 표준화해두면, 새 프로젝트에서도 그대로 불러와 일관된 화면을 빠르게 만들 수 있습니다. 예를 들어 ‘기본 버튼/보조 버튼/위험 버튼’을 매번 새로 그리는 대신, 정해진 버튼을 골라 끼우는 방식으로 속도가 붙습니다.

라이브러리는 보통 디자인 파트와 개발 파트가 각각 구축하며, 디자인 파트는 피그마의 팀 라이브러리를 통해 배포·관리할 수 있습니다.

배포된 라이브러리는 아래 흐름으로 새 문서에서도 쉽게 사용할 수 있습니다.

1. 새 문서 만들기
2. 팀 라이브러리 불러오기
3. 탐색/검색
4. 드래그 앤 드롭
5. 컴포넌트 사용

3. 스타일 가이드 (Style Guide) : 어떻게 써야 하는지 정리한 문서

스타일 가이드 예시: 사용 원칙과 규칙을 문서로 정리한 화면. 출처 : Material Design 3

스타일 가이드는 컴포넌트를 “제공”하는 것을 넘어, 팀이 같은 기준으로 판단하고 같은 방식으로 적용하도록 돕는 문서입니다. 라이브러리가 무엇을 쓸지를 제공한다면, 스타일 가이드는 언제/어떻게 쓸지를 정의합니다.

“라이브러리가 있으면 끝 아닌가요?”

디자인 시스템을 사용하는 인원이 많지 않다면, 컴포넌트 라이브러리만으로도 충분한 경우가 많습니다. 반대로 가이드를 별도로 구축하면 활용도는 낮은데 관리 부담만 커져, 오히려 번거로워질 수 있습니다. 하지만 조직이 커질수록 일관성은 자산 자체보다 사용 원칙의 합의에서 갈립니다. 스타일 가이드는 그 합의를 문서로 고정하는 장치입니다.

가이드는 크게 ① 스타일 가이드와 ② API 가이드로 나눌 수 있습니다.

• 스타일 가이드
  • 기획자·디자이너가 일관된 UI를 만들기 위한 기준(톤, 사용 원칙, 구성 규칙)
  • 예: “모달은 중요한 결정에만”, “에러 메시지는 한 문장 + 해결 행동”
• API 가이드
  • 개발자가 컴포넌트를 올바르게 쓰기 위한 문서(Props, 상태, 동작, 제약)
  • 예: size, variant, disabled, loading 같은 옵션과 사용 규칙

스타일 가이드 작성 도구는 선택지가 다양합니다.

도구	특징
zeroheight	스타일 가이드 전문 도구, 학습 곡선·비용 있음
피그마	별도 학습 없이 활용 가능
노션(Notion)	팀 친화적, 가볍게 시작 가능

4. API 가이드 : 컴포넌트를 정확하게 쓰게 만드는 문서

API 가이드 예시: 스토리북으로 Props·상태·동작을 명세한 화면. 출처: Adobe Spectrum UI

API 가이드는 개발자가 컴포넌트를 오해 없이, 일관되게, 안전하게 사용하도록 돕는 명세 문서입니다. 컴포넌트가 코드에서는 하나의 함수/모듈처럼 동작하는 만큼, 입력(Props), 상태, 동작, 제약 조건을 명확히 정의해두는 것이 중요합니다.

대표 도구인 Storybook을 활용하면 컴포넌트 단위의 문서를 만들고, 마우스를 올리거나 클릭하며 상태 변화를 즉시 테스트할 수 있습니다. 무엇보다 웹 브라우저에서 누구나 쉽게 접근할 수 있다는 점이 강점입니다.

5. JSON→플랫폼별 스타일 변환 : 토큰을 코드로 연결하기

토큰 변환 예시: 디자인 토큰(JSON)을 CSS 변수 등 코드 형식으로 변환

토큰을 코드로 연결한다는 것은, 디자인 값을 사람이 옮겨 적는 방식이 아니라 단일 원본(Source of Truth)에서 플랫폼별 스타일을 생성·배포하는 구조를 만든다는 뜻입니다. 운영 단계에서 토큰의 힘은 ‘정의’보다 ‘전파’에서 나옵니다. 토큰을 JSON 같은 형식으로 관리하면 변환과 자동화가 쉬워지고, 디자인 시스템이 변경되어도 코드에 반영하는 일이 수월해집니다.

토큰 원본을 한 곳에서 관리한 뒤, 도구(예: Style Dictionary)가 iOS/Android/Web에서 쓰는 형식(Swift, XML, CSS 변수 등)으로 자동 생성·변환해주도록 구성할 수 있습니다. 이렇게 연결해두면 디자인–개발 연결의 완성도는 산출물의 개수보다, 토큰이 변경에 강한 파이프라인으로 운영되는지에서 드러납니다.

Style Dictionary를 사용하면 피그마 배리어블을 추출한 JSON을 플랫폼에 맞는 형태로 변환해 사용할 수 있습니다.

6. 디자인 시스템 QA: 디자인과 구현이 같은지 확인하기

디자인 시스템 QA 예시: 구현 UI를 피그마로 가져와 디자인과 비교·검토

토큰과 컴포넌트가 있어도, 구현 결과가 조금씩 어긋나기 시작하면 시스템의 신뢰가 무너집니다. 따라서 운영 단계에는 비교·검증 루틴이 필요합니다. 디자인–코드가 완전히 통합된 도구를 쓰지 않는 이상, 최종 품질을 담보하려면 일정 수준의 사람 기반 검토가 들어갈 수밖에 없습니다.

검토는 Storybook, 테스트 화면 등 어디서든 가능하지만, story.to.design을 사용하면 구현된 UI를 피그마로 가져와 비교·체크하는 흐름을 빠르게 만들 수 있습니다. 말 그대로 스토리북 코드를 피그마로 불러와 확인하는 방식입니다.

7. 디자인 시스템 변경 영향 관리

변경 영향 관리 예시: UI 스냅샷으로 변경 전·후를 비교

디자인 시스템은 필연적으로 바뀝니다. 중요한 것은 변경 자체가 아니라, 변경이 제품 전반에 미치는 영향을 예측하고 통제하는 일입니다. 업데이트가 누적될수록 리스크는 커지고, 변경 영향 관리는 시스템이 커질수록 반드시 필요한 운영 장치가 됩니다.

문제는 업데이트가 기존 화면에 어떤 영향을 주는지, 얼마나 ‘안전하게’ 바뀌었는지를 추적하기가 쉽지 않다는 점입니다. 이때 Chromatic 같은 도구를 활용하면, UI 스냅샷을 기반으로 변경 전·후를 비교해 전/후 비교 기록을 남길 수 있습니다. 디자인 시스템을 업데이트할 때 이런 비교 흐름을 프로세스에 포함시키면, 기존 화면에 미치는 영향을 관리하고 회귀(regression) 이슈를 더 빠르게 발견하는 데 도움이 됩니다.

디자인 시스템 운영에 자주 쓰이는 도구들(토큰·문서·검증·배포)

디자인 시스템은 ‘정리된 문서’라기보다, 팀이 같은 기준으로 만들고 검증하며 바꾸기 위해 함께 운영하는 공유 자산입니다. 토큰으로 재료의 규격을 통일하고, 컴포넌트로 재사용 구조를 만들고, 가이드로 사용 원칙을 고정하는 것까지가 “구축”이라면, 그 다음부터는 코드 연결·QA·변경 영향 관리처럼 ‘운영 장치’가 시스템의 완성도를 결정합니다. 중요한 것은 특정 도구를 도입하는 일이 아니라, 팀의 규모와 협업 방식에 맞는 수준으로 산출물과 운영 방식을 설계해 지속 가능한 형태로 굴러가게 만드는 것입니다.

디자인 시스템은 팀이 같은 기준으로 만들고 검증하며 바꾸기 위해 함께 운영하는 공유 자산입니다. 디자인 시스템의 완성도는 **무엇을 만들어 두었는가(구축)**와 **그것이 계속 잘 쓰이게 하는가(운영)**가 함께 결정합니다.

다만 여기서 소개한 흐름은 피그마 중심으로 가장 자주 쓰이는 워크플로우의 한 예시일 뿐입니다. 조직에 따라서는 토큰 관리 방식(디자인/코드 중 어디를 원본으로 둘지), 문서화 도구(노션·제로하이트·스토리북 등), 배포/검증 체계(모노레포·패키지 배포·시각 회귀 테스트 등)를 달리 구성해도 충분히 좋은 결과를 만들 수 있습니다.

결국 중요한 것은 특정 툴이나 프로세스를 그대로 복제하는 것이 아니라, 팀의 규모와 협업 방식에 맞는 수준으로 구성원들이 자주, 편리하게 사용할 수 있도록 구성해야 궁극적으로 업무 효율을 높일 수 있습니다.

디자인 시스템 설계나 UX 전략 수립에 도움이 필요하다면 스무타트에 문의해주세요.