Check Designs는 Figma를 검증합니다. 그렇다면 당신의 코드는 무엇으로 검증하나요?
요약
Figma의 Check Designs 출시로 디자인 시스템 검증이 쉬워졌으나, 코드 구현 단계에서 발생하는 '코드 드리프트' 문제는 여전히 해결되지 않았습니다. 시각적 회귀 테스트나 수동 QA의 한계를 지적하며, 코드와 디자인 시스템 간의 일관성을 체계적으로 검증할 도구의 필요성을 강조합니다.
핵심 포인트
- Figma Check Designs는 디자인 단계의 오류를 잡아내지만 코드 단계의 드리프트는 포착 불가
- 코드 드리프트는 리팩터링이나 급한 수정 과정에서 디자인 토큰과 실제 코드 간의 불일치를 유발
- 시각적 회귀 테스트는 겉모습은 잡아내도 잘못된 토큰 사용(예: 헥스 값 직접 사용)은 놓침
- 수동 QA와 코드 리뷰는 비용이 높고 확장성이 떨어져 체계적인 검증이 어려움
Figma가 방금 Check Designs를 출시했습니다. 이 기능은 레이어를 스캔하여 디자인 시스템 (design system)을 따르지 않는 항목, 하드코딩된 색상 (hardcoded colors), 잘못된 타이포그래피 (typography), 부정확한 간격 (spacing), 잘못된 라이브러리의 컴포넌트 (components) 등을 찾아냅니다.
그것으로 문제의 절반은 해결되었습니다. 나머지 절반은 더 어렵습니다.
Check Designs가 다루지 못하는 것
Check Designs는 디자인이 엔지니어에게 전달되기 전에 Figma 내에서의 드리프트 (drift)를 포착합니다. 이는 해결해야 할 올바른 문제이며, Figma의 접근 방식 — 즉, 토큰 (tokens)을 추측하는 생성형 AI (generative AI)가 아니라 사용자의 디자인 시스템 데이터로 학습된 머신러닝 (machine learning) 모델을 사용하는 방식 — 은 정확합니다.
하지만 핸드오프 (handoff) 이후에는 다음과 같은 일이 발생합니다.
디자이너가 완벽하게 검증된 Figma 컴포넌트를 전달합니다. 엔지니어는 이를 올바르게 구축합니다. 3주 후, 누군가 리팩터링 (refactor) 도중 토큰의 이름을 변경합니다. 다른 엔지니어는 급하게 간격 값을 조정합니다. Figma에서 테두리 반경 (border radius)이 업데이트되었지만 아무도 컴포넌트를 건드리지 않습니다. 마감 기한에 쫓기다 색상 참조가 하드코딩됩니다.
이러한 변화 중 그 어느 것도 Check Designs에 의해 포착되지 않습니다. 왜냐하면 이 변화들은 Figma가 아닌 코드 (code)에서 발생하기 때문입니다. 이제 디자인 시스템은 Figma와 코드베이스 (codebase)라는 두 개의 진실의 원천 (sources of truth)을 갖게 되었으며, 이 둘은 서서히 어긋나기 시작합니다. 디자이너가 프로덕션 (production) 화면을 스크린샷으로 찍어 왜 다르게 보이는지 묻기 전까지는 아무도 알아차리지 못합니다.
이것이 코드 드리프트 (code drift)입니다. 그리고 이에 상응하는 Check Designs와 같은 도구는 아직 없습니다.
검증의 격차 (The verification gap)
코드 드리프트를 포착하기 위한 현재의 옵션은 다음과 같습니다:
**시각적 회귀 테스트 (Visual regression testing)**는 스크린샷을 찍어 비교합니다. 다르게 보이는 것은 잡아내지만, 겉보기에는 맞지만 잘못된 토큰을 사용하는 것은 놓칩니다. 컴포넌트가 borderRadius: 8을 borderRadius: '8px' 대신 사용하거나, 의미론적 토큰 (semantic token) 대신 생(raw) 헥스(hex) 값을 사용하거나, 간격이 2px 정도 차이 나더라도 시각적 회귀 테스트를 통과할 수 있습니다. 스크린샷 차이(diff)를 통과하기에는 충분히 비슷하지만, 디자인 시스템을 깨뜨리기에는 충분히 틀렸기 때문입니다.
**수동 디자인 QA (Manual design QA)**는 디자이너가 주기적으로 프로덕션을 검토하는 것을 의미합니다. 비용이 많이 들고, 빈도가 낮으며, 드리프트가 이미 머지 (merge)된 한참 후에 발생합니다.
**코드 리뷰 (Code reviews)**는 엔지니어가 PR (Pull Request)에서 디자인 시스템 위반 사항을 찾아내도록 요구합니다. 리뷰어가 디자인 시스템을 깊이 있게 알고 있어야 하며, 확인하는 것을 잊지 않아야 합니다. 이는 확장성이 없습니다.
이 중 어느 것도 체계적이지 않습니다. 이 모든 방식은 근사치이거나 간헐적입니다. 놓친 드리프트 (drift)가 발생할 때마다 향후의 드리프트를 포착하기가 더 어려워지기 때문에 문제는 더욱 심화됩니다.
체계적인 코드 검증 (systematic code verification)의 모습
올바른 접근 방식은 Figma 파일을 코드의 소스 오브 트루스 (source of truth)로 취급하는 것이며, 단순히 생성 시점에만 하는 것이 아니라 지속적으로 수행하는 것입니다.
작동하는 아키텍처는 다음과 같습니다:
1단계: 시각적 해석이 아닌 정확한 데이터로부터 생성하십시오.
AI에게 해석할 스크린샷을 주는 대신, Figma의 REST API를 직접 읽으십시오. 노드 데이터 (node data)는 정확한 값, 특정 크기/두께/줄 간격 (line-height) 조합으로서의 타이포그래피 (typography), 픽셀 측정값으로서의 간격 (spacing), 정밀한 헥스 코드 (hex codes)로서의 채우기 (fills)를 제공합니다. AI가 디자인을 보기 전에 모든 결정론적 값 (deterministic value)을 알고리즘적으로 해결하십시오. 해당 값들을 사실로서 주입하십시오. AI는 구조와 판단을 처리합니다. 당신이 이미 모든 토큰 (token)을 해결했기 때문에 AI는 토큰 이름을 추측할 필요가 전혀 없습니다.
2단계: 파일을 작성하기 전에 출력 품질을 강제하십시오.
무엇인가 디스크에 쓰여지기 전에 생성된 코드를 스캔하여 금지된 패턴을 확인하십시오. 가공되지 않은 헥스 값 (raw hex values), 문자열 리터럴 (string literals)이 필요한 곳에 사용된 가공되지 않은 테두리 반경 (border-radius) 숫자, 누락된 토큰 임포트 (token imports) 등이 대상입니다. 하나라도 발견되면 중단하십시오. 근사치에 기반한 그 어떤 것도 코드베이스 (codebase)에 들어올 수 없습니다.
3단계: CI에서 지속적으로 검증하십시오.
모든 풀 리퀘스트 (pull request) 시, 각 컴포넌트에 대한 실시간 Figma 데이터를 다시 가져오십시오. 이를 현재 소스와 비교하십시오. 드리프트가 발생했거나, 잘못된 토큰이 사용되었거나, 간격이 변경되었거나, 반경이 업데이트되었다면 검증은 실패하며 PR은 머지 (merge)되지 않습니다. 게이트 (gate)가 모든 머지 시도 시 실행되기 때문에 디자인 시스템이 조용히 드리프트되는 일은 발생할 수 없습니다.
4단계: Figma로 루프를 다시 닫습니다.
컴포넌트 검증에 실패하면, 드리프트 (drift) 보고서를 Figma의 해당 컴포넌트 노드에 직접 댓글로 게시하여 디자이너가 정확한 레이어에 고정된 상태로 확인할 수 있게 합니다. 디자이너가 댓글을 해결하면, 다음 CI 실행 시 탐지가 다시 활성화됩니다. 디자이너는 3주 뒤에 회의나 Slack 메시지를 통해 알게 되는 것이 아니라, 자신이 사용하는 도구 내부에서 이를 알게 됩니다.
이를 통해 얻는 결과물
첫날뿐만 아니라 시간이 지나도 정직함을 유지하는 컴포넌트들입니다.
저는 Fixel을 구축하기 전, 프로덕션 환경에서 이 접근 방식을 검증했습니다. 35일 동안 3,077개의 테스트를 통해 60개 이상의 React 컴포넌트를 출시했습니다. 원시 헥스 값 (raw hex values)은 0개였습니다. 토큰 환각 (token hallucinations)도 0개였습니다. 모든 컴포넌트는 매 PR마다 라이브 Figma 파일과 대조하여 검증되었으며, 이는 디자인 시스템이 단 한 번도 조용히 드리프트되지 않았음을 의미합니다.
그 결과는 단순히 더 빠른 생성에 그치지 않습니다. 코드베이스가 계약적으로 준수해야만 하는 디자인 시스템을 구축하는 것입니다.
Check Designs와 코드 검증을 함께 사용하기
Check Designs는 Figma가 디자인 시스템을 따르는지 검증합니다.
코드 검증 (code verification)은 코드가 Figma를 따르는지 검증합니다.
이 둘은 함께 완전한 루프를 형성합니다:
디자인 시스템 (Design system) → Figma (Check Designs가 이를 강제함)
Figma → 코드 (Code) (CI 검증이 이를 강제함)
오늘 이전까지는 이 루프의 절반만이 존재했습니다. 이제 양쪽 모두에 툴링 (tooling)이 갖춰졌습니다.
만약 당신이 2026년에 디자인 시스템을 출시하면서 Check Designs만 실행하고 있다면, 당신은 핸드오프 (handoff)의 한쪽 면에서만 드리프트를 잡아내고 있는 것입니다. 다른 한쪽은 여전히 매 PR마다 조용히 드리프트되고 있습니다.
당신의 팀은 현재 핸드오프 이후 코드 드리프트를 어떻게 잡아내고 있나요? 시각적 회귀 (visual regression), 수동 QA, 또는 완전히 다른 무언가에 의존하고 있나요? 무엇이 잘 작동하고 무엇이 그렇지 않은지 듣고 싶습니다.
작성자: Amrutha Kollu, Socratics.ai의 소프트웨어 엔지니어.
Part 1: 내가 5주 만에 60개의 디자인 시스템 컴포넌트를 출시한 방법
Part 2: 왜 AI는 계속해서 잘못된 디자인 토큰 (design tokens)을 생성하는가
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기