디자인 시스템에서 디자인과 코드의 간극 줄이기

에잇퍼센트 웹 프론트엔드 팀은 사내 디자인 시스템 EDS(Eight Design System) 를 구현하는 과정에서, EDS Figma와 EDS Code(eds-wc) 사이의 간극이 반복적인 커뮤니케이션 비용과 피로도를 만든다고 봤다.

문제는 두 단계에서 두드러졌다.

• 디자인 시스템 개발 단계에서는 디자이너가 모든 컴포넌트 속성을 처음부터 완벽히 예측하기 어려워, 개발자가 명세를 보고 수정 요청을 반복하게 된다.
• 서비스 개발 단계에서는 서비스 디자이너가 만든 Service Figma를 개발자가 해석해야 하는데, 앞 단계에서 이미 Figma와 코드가 어긋나 있으면 명세 확인 시간이 크게 늘어난다.

특히 Figma에서는 속성 명명 규칙과 가이드라인이 명확하지 않아, 같은 의미의 속성도 팀마다 다르게 정의될 수 있다. 예를 들어 disabled와 checked 같은 상태 조합, size의 값 체계, icon 관련 속성 정의가 일관되지 않으면 개발자는 다시 확인할 수밖에 없고, 결국 임의 수정이 발생하면서 EDS Figma와 EDS Code의 차이가 커진다.

이를 줄이기 위해 세 가지 개선안을 적용했다.

• 신규 컴포넌트 명세를 작성할 때 디자이너와 개발자가 인터페이스를 함께 협의한다.
• EDS Figma 규약을 추가해, 개발자가 Figma만 보고도 코드 구현에 필요한 정보를 얻을 수 있게 한다.
• Figma Plugin API로 Figma를 코드 수준까지 추상화해, 명세를 다시 확인하지 않아도 구현 가능한 데이터를 제공한다.

규약의 핵심은 ComponentSetNode와 InstanceNode에서 구현 데이터를 추출할 수 있을 정도로 구조를 표준화하는 것이다. 컴포넌트 기능은 이름이나 property로 구분하고, 컴포넌트 명칭이 식별 가능해야 하며, 동일 기능을 나타내는 property 값은 팀 전체에서 통일해야 한다. 예를 들어 size는 모든 컴포넌트에서 같은 값 체계를 써야 하고, disabled 같은 상태값도 일관되게 정의해야 한다.

이 기준을 바탕으로 두 가지 도구를 만들었다.

• EDS Lint: Figma 플러그인으로, ComponentSetNode가 규약에 맞게 만들어졌는지 검사한다. 필수 속성 누락, 정의되지 않은 속성 사용, 잘못된 값 사용을 실시간으로 알려준다.
• EDS Codegen: Figma의 ComponentSet Instance를 eds-wc가 지원하는 HTML, React, Vue 코드로 변환한다. 개발자는 별도 명세 확인 없이 Figma에서 바로 코드 형태를 받을 수 있다.

결국 핵심은 디자인 시스템을 단순히 "예쁘게 맞추는 일"로 보지 않고, 디자인과 개발이 같은 인터페이스 언어를 쓰도록 만드는 것이다. Figma 규약과 플러그인 기반 자동화가 결합되면, 디자인 시스템과 서비스 개발 사이의 불필요한 왕복을 줄이고 팀 전체의 생산성을 높일 수 있다.