DSLint 구축 배경: Figma용 디자인 시스템 린터

반복되는 디자인 검토 피드백이 제가 디자인 시스템 드리프트(design-system drift)를 감지하고, 수정 방법을 안내하며, 개선 사항을 추적하고, 디자이너가 통제권을 유지하도록 돕는 플러그인을 만들게 된 계기가 되었습니다.

저의 매니저와 선임 디자이너들로부터 자주 들었던 코멘트에서 시작되었습니다:

“디자인에 디자인 시스템 컴포넌트를 사용하세요.”
이는 좋은 조언이었고, 대규모 제품 전반에 걸쳐 일관성을 유지하는 데 필수적이었습니다.

Designers

저희의 디자인 시스템에는 이미 재사용 가능한 컴포넌트, 타이포그래피 스타일, 색상 변수(color variables), 간격 토큰(spacing tokens), 상호작용 패턴이 포함되어 있었습니다. 이는 디자이너들에게 공유된 기반을 제공하고 개발자들이 일관된 경험을 구축하는 데 도움을 주었습니다.

하지만 디자인 시스템이 있다는 것이 모든 디자인이 자동으로 그것과 연결되어 있음을 의미하지는 않았습니다.

저희 팀이 서로 다른 여정(journeys), 모듈, 파일, 마감 기한에 걸쳐 작업하면서도, 디자인 시스템 드리프트가 계속 발생했습니다.

디자이너가 빠른 조정을 위해 컴포넌트를 분리할 수 있었습니다. 색상을 변수를 사용하지 않고 수동으로 입력할 수도 있었습니다. 텍스트는 시각적으로 시스템과 일치하지만 연결된 스타일이 없을 수도 있었습니다. 간격 값은 승인된 스케일에서 서서히 벗어날 수 있었습니다.

Designers

디자이너들은 빠르게 움직이며, 제품 문제를 해결하고, 피드백에 대응하며, 마감 기한을 맞추려고 노력했습니다.

진짜 문제는 검토 전에 모든 것을 확인할 수 있는 빠르고 신뢰할 수 있는 방법이 없었다는 것이었습니다.

그것이 저에게 이런 질문을 던지게 했습니다:

디자이너가 검토를 위해 보내기 전에 자신의 작업을 직접 감사(audit)할 수는 없을까?

Designers

그 질문이 DSLint가 되었습니다.

디자인 시스템 드리프트의 숨겨진 비용

디자인 시스템은 일관성을 만들고, 협업을 개선하며, 반복적인 결정을 줄이는 것을 목표로 합니다.

하지만 디자인 시스템을 게시하는 것은 시작에 불과합니다. 더 큰 과제는 채택(adoption)입니다.

프로덕션 디자인 파일에서 발견될 수 있는 불일치성에는 다음이 포함됩니다:

• 분리된 컴포넌트 인스턴스 (Detached component instances)
• 승인된 라이브러리 컴포넌트를 대체하는 로컬 컴포넌트
• 하드코딩된 색상 (Hardcoded colors)
• 누락된 텍스트 스타일
• 바인딩되지 않은 변수 (Unbound variables)
• 스케일링 및 패딩이 잘못된 간격
• 자동 레이아웃(auto layout)을 사용해야 할 고정 레이아웃
• 깊게 중첩된 구조
• 대비가 낮은 텍스트
• 작은 터치 타겟 (Small touch targets)
• 일반적인 이미지 레이어 이름
• 이러한 문제들을 수동으로 찾는 것은 느립니다.

리뷰어는 모든 페이지를 열고, 중첩된 레이어를 검사하며, 변수와 값을 비교하고, 컴포넌트 소스를 확인하고, 피드백을 남겨야 합니다.

그러면 디자이너가 그 발견 사항들을 수정하여 파일을 다시 리뷰에 보냅니다.

이 과정은 적은 수의 화면에는 작동할 수 있습니다. 하지만 많은 디자이너, 파일, 여정(journeys), 그리고 제품 팀에 걸쳐 확장하기는 어려워집니다.

상기 알림에서 자동화로 이동하기
반복되는 피드백은 유용했습니다:

“디자인 시스템을 사용하세요.”

하지만 단순한 알림만으로는 문제를 해결할 수 없었습니다.

디자이너들은 몇 일 후에 리뷰를 하는 것이 아니라, 작업하는 도중에 피드백이 필요했습니다.

저는 다음 기능을 할 수 있는 무언가를 만들고 싶었습니다:

• 디자인을 자동으로 스캔하기
• 디자인 시스템의 불일치성을 감지하기
• 무엇이 잘못되었는지 설명하기
• 영향을 받은 레이어로 이동하기
• 적절한 수정 사항 추천하기
• 변경을 하기 전에 물어보기
• 시간이 지남에 따라 파일이 개선되었는지 추적하기

그것이 DSLint의 기반이 되었습니다.

DSLint 소개
DSLint — Design System Linter는 디자인 시스템 드리프트를 위해 디자인을 스캔하는 Figma 플러그인입니다.

디자이너들은 다음을 스캔할 수 있습니다:

• 선택된 레이어 (Selected layers)

• 현재 페이지 (The current page)

• 파일 내 모든 페이지 (Every page in a file)

• 결과는 여덟 가지 집중 영역으로 구성됩니다:

• 개요 (Overview)

• 컴포넌트 (Components)

• 타이포그래피 (Typography)

• 색상 (Colors)

• 변수 (Variables)

• 레이아웃 (Layout)

• 접근성 (Accessibility)

• 히스토리 (History)

목표는 단순히 문제를 보고하는 것만이 아닙니다.

DSLint는 디자이너가 문제가 어디에 존재하는지 이해하고, 해당 위치로 이동하며, 지원되는 발견 사항을 안전하게 해결할 수 있도록 돕습니다.

컴포넌트 (Components)
'컴포넌트(Components)' 탭은 다음을 식별합니다:

• 분리된 컴포넌트 인스턴스 (Detached component instances)
• 로컬 컴포넌트 사용 (Local component usage)
• 사용할 수 없는 라이브러리 소스 (Unavailable library sources)
• 다시 연결할 수 있는 적격 컴포넌트 (Eligible components that can be re-linked)
• 지원되는 경우, DSLint는 텍스트 콘텐츠, 필(Fills), 가시성(Visibility), 불투명도(Opacity), 치수(Dimensions), 위치(Position), 레이어 순서 등 호환 가능한 요소를 유지하면서 분리된 디자인을 해당 소스 컴포넌트에 다시 연결하려고 시도할 수 있습니다:
• 텍스트 콘텐츠 (Text content)
• 필 (Fills)
• 가시성 (Visibility)
• 불투명도 (Opacity)
• 치수 (Dimensions)
• 위치 (Position)
• 레이어 순서 (Layer order)
• 이는 디자이너가 제어권을 유지하면서 반복적인 재구성을 줄여줍니다.

타이포그래피 (Typography)
'타이포그래피(Typography)' 탭은 텍스트를 다음으로 분류합니다:

• 라이브러리 스타일 적용됨 (Library styled)
• 로컬에서 스타일 적용됨 (Locally styled)
• 스타일 미적용 (Unstyled)
• 이는 글꼴 패밀리, 크기, 무게를 사용 가능한 텍스트 스타일과 비교합니다.
• 적절한 일치 항목이 존재할 경우, DSLint는 디자이너가 적용하기 전에 검토할 수 있는 신뢰도 점수가 매겨진 추천을 표시합니다.

색상 (Colors)
'색상(Colors)' 탭은 색상을 다음으로 그룹화합니다:

• 하드코딩됨 (Hardcoded)
• 변수 바인딩됨 (Variable-bound)
• 스타일 바인딩됨 (Style-bound)
• 하드코딩된 색상은 사용 가능한 색상 변수와 비교됩니다.
• DSLint는 동일한 헥스(hex) 값을 반복적으로 보여주는 대신, 일치하는 색상을 그룹화하고 사용 횟수를 표시하며, 근접하게 일치하는 값이 발견되면 관련 변수를 제안합니다.

변수 (Variables)
'변수(Variables)' 탭은 속성이 시스템 변수에 연결되어 있는지 확인합니다.

이는 다음과 같은 속성을 감사합니다:

• 필 (Fills)
• 스트로크 (Strokes)
• 간격 (Spacing)
• 패딩 (Padding)
• 모서리 반경 (Corner radius)
• 스트로크 무게 (Stroke weight)
• 레이어는 다음으로 분류됩니다:
• 완전히 바인딩됨 (Fully bound)
• 부분적으로 바인딩됨 (Partially bound)
• 바인딩되지 않음 (Unbound)
• 계층적 트리는 경고가 부모 레이어에 속하는지 아니면 더 구체적인 중첩된 자식 요소에 속하는지를 식별하는 데 도움이 됩니다.

레이아웃 및 간격 (Layout and spacing)
'레이아웃(Layout)' 탭은 다음을 측정합니다:

• Auto-layout 채택
• 고정 레이아웃 사용
• 간격 값(Spacing values)
• 패딩 조합(Padding combinations)
• 크기 불일치(Sizing inconsistencies)
• 중첩 깊이(Nesting depth)
• 간격 토큰 정렬(Spacing-token alignment)
• 원시 간격 값이 승인된 스케일과 일치하지 않을 때, DSLint는 가장 가까운 토큰 또는 숫자 값을 추천할 수 있습니다.

접근성(Accessibility)
DSLint는 또한 다음 항목과 관련된 잠재적인 접근성 문제를 플래그합니다:

• 텍스트 대비(Text contrast)
• 그라디언트 대비(Gradient contrast)
• 작은 터치 영역(Small touch targets)
• 작은 텍스트(Small text)
• 일반적인 이미지 레이어 이름(Generic image-layer names)
• 그라디언트 대비는 하나의 가정된 배경색에 의존하기보다는 텍스트 뒤의 여러 지점에서 평가됩니다.
• 흰색 텍스트가 어두운 그라디언트에 놓여 있고 대비를 통과하면, DSLint는 이를 변경하지 않습니다.

만약 흰색 텍스트가 밝은 그라디언트에 나타나면, DSLint는 접근성이 좋은 더 어두운 색상을 추천할 수 있습니다.

그라디언트에 매우 밝고 매우 어두운 영역이 모두 포함되어 있고 단일 전경색으로는 모든 곳에서 대비를 통과할 수 없는 경우, DSLint는 안전하지 않은 수정(unsafe fix)을 적용하는 대신 배경 검토 또는 오버레이 추가를 권장합니다.

이러한 발견 사항은 자문 목적이며 완전한 접근성 평가를 대체하지 않습니다.

감지부터 **가이드된 수정(guided remediation)**까지 디자인 시스템 건강 측정하기

DSLint는 컴포넌트 사용, 타이포그래피 커버리지, 색상 변수 채택을 시각적 일관성 점수로 결합합니다. 스캔 기록 및 페이지별 분석은 팀이 시간이 지남에 따라 시스템 채택률이 개선되는지 측정하는 데 도움을 줍니다.

많은 린팅 도구는 문제를 식별한 후 멈춥니다.

저는 DSLint가 감지와 조치 사이의 격차를 줄이기를 바랐습니다.

지원되는 수정 사항에는 다음이 포함됩니다:

• 컴포넌트 재연결(Re-linking components)
• 텍스트 스타일 적용(Applying text styles)
• 색상을 변수에 바인딩(Binding colors to variables)
• 간격을 토큰에 스냅(Snapping spacing to tokens)
• 대비 조정(Adjusting contrast)
• 터치 영역 크기 조정(Resizing touch targets)
• 작은 텍스트 증가(Increasing small text)
• 지원되는 모든 디자인 변경 액션에는 적용/취소 확인(Apply/Cancel confirmation)이 사용됩니다.

분석을 실행한다고 해서 디자인이 수정되는 것은 아닙니다.

이는 디자이너가 구조화되지 않은 목록을 처리하는 대신 높은 영향도의 문제에 집중할 수 있도록 돕습니다.

History 탭에서는 최근 스캔 요약 정보를 저장하고 디자인 시스템의 건전성(health)이 개선되고 있는지 여부를 보여줍니다.

전체 파일 스캔의 경우, DSLint는 팀이 어떤 영역에 먼저 주의를 기울여야 하는지 식별할 수 있도록 페이지별 세부 분석도 제공합니다.

사용자 제어 적응형 학습 (Human-controlled adaptive learning)
DSLint에는 적응형 피드백 시스템이 포함되어 있습니다.

디자이너가 지원되는 권장 사항을 수락하거나 거부할 때, 이 피드백은 다음 요소에 영향을 미칠 수 있습니다:

• 권장 사항 신뢰도 (Recommendation confidence)
• 제안 순위 (Suggestion ranking)
• 선호 색상 변수 매핑 (Preferred color-variable mappings)
• 선호 텍스트 스타일 매핑 (Preferred text-style mappings)
• 간격 선호도 (Spacing preferences)
• 문제 우선순위 (Issue priority)

이는 DSLint가 파일을 자율적으로 변경한다는 의미는 아닙니다.

학습은 지원되는 권장 사항을 개선합니다. 디자이너는 여전히 모든 디자인 변경 사항을 승인해야 합니다.

대규모 Figma 파일 설계 (Designing for large Figma files)
성능은 프로젝트의 중요한 부분이 되었습니다.

대용량 파일에는 수천 개의 레이어, 중첩된 인스턴스, 텍스트 스타일, 변수, 이미지 및 페이지가 포함될 수 있습니다.

분석 도중에 프로그램이 멈추는(freezes) 플러그인은 채택되지 않을 것입니다.

따라서 DSLint에는 다음 기능들이 포함되어 있습니다:

• 레이어 개수 세기 (Layer counting)
• 스캔 진행률 (Scan progress)
• 경과 시간 (Elapsed time)
• 남은 예상 시간 (Estimated time remaining)
• 페이지별 진행률 (Page-level progress)
• 취소 기능 (Cancellation)
• 배치 처리 (Batched processing)
• 캐시된 조회 (Cached lookups)
• 인덱스 색상 매칭 (Indexed color matching)
• 인덱스 타이포그래피 매칭 (Indexed typography matching)
• 긴 작업 시 주기적인 일시 정지(pause)를 통해 Figma가 반응성을 유지하고 사용자가 스캔을 취소할 수 있도록 합니다.

제가 배운 점 (What I learned)
> DSLint 구축을 통해 디자인 시스템 거버넌스(governance)는 단순히 문서화의 문제만이 아님을 깨달았습니다.

그것은 피드백의 문제입니다.

디자이너들은 여정(journey)을 완료한 후에만 필요한 것이 아니라, 작업하는 도중에 피드백이 필요합니다.

또한 그들은 위반 사항 목록 이상의 것을 필요로 합니다.

좋은 디자인 툴링은 다음을 수행해야 합니다:

• 문제 설명 (Explain the problem)
• 영향받은 레이어 위치 파악 (Locate the affected layer)
• 중요성 제시 (Show why it matters)
• 안전한 대응 방안 추천 (Recommend a safe response)
• 변경 전 확인 요청 (Ask before changing anything)
• 개선 정도 측정 (Measure improvement)
• 제어권을 제거하지 않고 사용자 결정으로부터 학습 (Learn from user decisions without removing control)
• 자동화에도 신중해야 한다는 점을 배웠습니다.
• 기술적으로 유효한 변경이 항상 올바른 제품 결정은 아닙니다. 이것이 DSLint가 자신감(confidence), 투명성(transparency), 확인(confirmation), 그리고 인간의 제어(human control)를 강조하는 이유입니다.

DSLint는 누구를 위한 것인가 (Who DSLint is for)
DSLint는 다음 사용자들을 위해 설계되었습니다:

• 채택률을 추적하는 디자인 시스템 관리자 (Design-system maintainers tracking adoption)
• 검토 전 작업을 확인하는 제품 디자이너 (Product designers checking work before review)
• 핸드오프(handoff) 전에 파일을 검토하는 디자인 리드 (Design leads reviewing files before handoff)
• 반복적인 디자인 시스템 감사를 수행하는 팀 (Teams conducting recurring design-system audits)
• 반복적인 규정 준수 작업을 줄이려는 조직 (Organizations trying to reduce repetitive compliance work)
• 다음으로 올 것들 (What comes next)

향후 기회에는 다음 기능들이 포함됩니다:

• 맞춤형 팀 규칙 (Custom team rules)
• 기준선 대비 현재 비교 (Baseline-versus-current comparisons)
• “새로운 위반 사항만 표시” 기능 (“Only show new violations”)
• 반응형 준비 상태 확인 (Responsive-readiness checks)
• 명명 규칙 감사 (Naming-convention audits)
• 테마 모드 커버리지 (Theme-mode coverage)
• 공유 가능한 보고서 (Shareable reports)
• 디자인 시스템 격차 감지 (Design-system gap detection)
• 강화된 팀 레벨 거버넌스 (Stronger team-level governance)

장기적인 비전은 다음과 같습니다:

▸ 검사(Inspect) → 수정(Remediate) → 추적(Track) → 예측(Predict)

마지막 생각들 (Final thoughts)
DSLint는 반복되는 알림에서 시작되었습니다:

“디자인 시스템을 사용하세요.”

이것은 더 광범위한 질문으로 발전했습니다:

모든 디자이너에게 디자인 시스템 준수를 어떻게 더 쉽고, 빠르고, 유용하게 만들 수 있을까요?

답변은 또 다른 문서나 체크리스트가 아니었습니다.

그것은 디자인 워크플로우에 직접 내장된 도구였습니다.

감사(Audit). 위치 파악(Locate). 개선(Improve).

Designers

DSLint가 Figma Community에 출시됩니다.

플러그인 사용해 보기: Figma Plugin DSLint - Design System Linter
케이스 스터디 읽기: [Coming Soon]

읽어주셔서 감사합니다. 댓글 섹션에 소중한 피드백을 공유해주세요. <3