같은 기능을 만들 때마다 버튼·입력창·오류 처리를 다시 결정하고 있다면 디자인 시스템을 검토할 때입니다. 팀 인원이나 화면 개수보다 중요한 것은 반복되는 판단의 비용과 앞으로 그 규칙을 관리할 여력입니다. 아직 사용자 흐름이 빠르게 바뀐다면, 전체 라이브러리보다 핵심 업무 하나의 규칙부터 정리하는 편이 출발점으로 적합합니다.
[01]디자인 시스템은 Figma 라이브러리와 어떻게 다른가요?
Figma 라이브러리는 재사용할 시각 요소를 전달하는 수단입니다. 제품에서 같은 결과를 내려면 실제 코드, 사용 조건, 오류·로딩 상태와 변경 절차도 연결되어야 합니다. IBM Carbon 역시 시스템을 코드와 디자인 자료, 인터페이스 가이드라인, 기여자 커뮤니티가 함께 있는 체계로 설명합니다.
작은 팀의 첫 산출물은 거대한 카탈로그일 필요가 없습니다. ‘이 입력 컴포넌트는 어떤 상황에서 쓰고, 어떤 이름으로 가져오며, 실패했을 때 어떻게 안내하는가’를 디자이너와 개발자가 같은 기준으로 설명할 수 있으면 시작할 수 있습니다.
[02]지금 도입해야 하나요, 조금 더 기다려야 하나요?
아래 표는 보이드가 제안하는 판단 기준입니다. 특정 인원수나 화면 수를 넘으면 반드시 도입해야 한다는 규칙은 아닙니다. 최근 변경 작업을 떠올리며 실제로 반복된 문제가 있는지 확인하세요.
| 관찰할 상황 | 권장 출발점 |
|---|---|
| 같은 입력·버튼이 화면마다 다르게 동작한다 | 반복 컴포넌트의 상태와 사용 규칙을 먼저 통일 |
| 여러 담당자가 같은 UI를 따로 수정한다 | 공통 코드와 변경 담당자를 정해 중복을 줄임 |
| 핵심 사용자 흐름 자체가 아직 자주 바뀐다 | 검증된 흐름만 정리하고 나머지는 실험 영역으로 유지 |
| 한 번 쓰는 캠페인 화면이고 후속 운영이 없다 | 필요한 스타일 가이드와 검수 기준부터 확보 |
[03]처음에는 무엇까지 만들면 충분한가요?
USWDS는 원칙·가이드·코드를 단계적으로 적용하는 방식을 안내합니다. 디자인 토큰은 색·간격·서체 같은 반복 값을 이름으로 관리하는 단위입니다. 이 접근을 작은 팀에 적용한다면, 먼저 반복 사용되는 업무 흐름 하나와 그 흐름에 필요한 최소 규칙을 묶는 방법을 제안합니다.
- 기초 값: 주요 텍스트·배경·오류 색, 글자 단계, 간격과 모서리 값을 역할에 따라 명명합니다. 예: color.text.error.
- 반복 요소: 해당 흐름에 실제 필요한 버튼, 입력창, 선택 요소부터 디자인과 코드의 이름을 맞춥니다.
- 상태와 규칙: 기본·포커스·오류·로딩·비활성 상태 중 해당되는 항목과 사용 조건을 기록합니다.
- 운영 방법: 수정 요청 위치, 검토 담당자, 버전과 적용 제품을 남깁니다.
[04]실제 화면 하나에 어떻게 적용하나요?
예시로 견적 문의 폼을 골라보겠습니다. 먼저 이름·이메일·문의 내용 입력부터 전송 성공까지의 흐름을 적습니다. 필수 항목 누락, 잘못된 이메일, 전송 중, 서버 오류, 재시도도 포함합니다. 이 예시는 도입 방법을 설명하기 위한 가상 상황입니다.
- 화면에서 서로 다른 입력창을 모아 차이가 업무상 필요한지 확인합니다. 필요 없는 차이만 공통화합니다.
- 하나의 실제 폼에 공통 입력창을 적용하고 디자인 문서와 코드 예제를 함께 갱신합니다.
- 사용자가 오류 원인을 이해하고 수정한 뒤 다시 전송할 수 있는지 확인합니다. 키보드만으로도 흐름을 검수합니다.
- 다른 폼에 적용할 때 생긴 차이를 기록합니다. 유효한 새 요구인지, 기존 규칙을 쓰면 되는지 검토한 뒤 확장합니다.
[05]모양을 통일하면 접근성도 해결되나요?
시각적 통일만으로 접근성이 보장되지는 않습니다. W3C의 ‘일관된 식별’ 설명은 여러 페이지에서 같은 기능을 하는 요소를 일관되게 식별할 수 있어야 한다는 점을 다룹니다. 모든 문구를 무조건 같게 만드는 것이 아니라, 같은 기능을 사용자가 예측 가능하게 알아볼 수 있도록 하는 데 초점이 있습니다.
공통 컴포넌트에서도 키보드 이동, 보이는 포커스, 입력 레이블, 오류 전달, 색 대비를 실제 사용 맥락에서 확인해야 합니다. 이 항목만 확인했다고 WCAG 전체를 충족했다고 표시해서는 안 됩니다. GOV.UK의 기여 기준 역시 유용성·사용성·일관성·다양한 맥락에서의 활용 가능성과 검증 근거를 중요하게 봅니다.
[06]만든 뒤에는 누가, 무엇을 관리하나요?
새 컴포넌트를 추가할 때는 반복되는 사용자 문제, 기존 요소로 해결할 수 없는 이유, 실제 적용 화면을 함께 남기세요. 담당자는 요청을 검토하고, 바뀐 규칙이 어느 제품에 적용됐는지 확인합니다. 사용 중인 코드와 디자인 자료가 어긋났다면 새 요소를 늘리기 전에 그 차이를 해결하는 것이 우선입니다.
효과를 확인할 때는 라이브러리의 개수보다 반복 수정과 예외 요청의 변화를 살펴보세요. 예를 들어 공통 폼을 쓰는 화면, 별도 구현이 남은 이유, 수정 후 다시 발생한 오류를 기록할 수 있습니다. 생산성이 몇 퍼센트 개선될지는 미리 약속하지 말고 팀의 변경 기록으로 판단하세요.
[07]시작 전 확인할 다섯 가지
- 해결할 반복 문제와 첫 적용 업무 흐름이 명확한가요?
- 디자인 자료와 실제 코드의 담당자가 함께 참여하나요?
- 오류·로딩·키보드 사용까지 포함한 검수 조건이 있나요?
- 공통화할 범위와 실험으로 남겨둘 범위를 구분했나요?
- 변경 요청·검토·배포·적용 확인을 맡을 사람이 있나요?
아직 답하기 어렵다면 현재 화면과 최근 수정 사례부터 모으세요. 새 제품 개발이나 기존 웹 서비스 개편을 준비하고 있다면, 전체 화면을 일괄 교체하기 전에 공통화할 업무와 인계할 자산의 범위를 개발 담당자와 합의하는 것이 다음 단계입니다.
- 디자인 시스템
- UX
- 컴포넌트
