Stack Mirroring
코드를 위한 디자인 그리고 디자인을 위한 코드
** This article has been translated from its original source (link to source) with approval by the original author, John Choura (link to https://john.design).
** 원작자의 동의를 구하고 번역하였습니다. 좀 더 명확한 내용은 위의 원문 링크를 통해 확인 가능하며 오역 있다면 언제든 댓글로 알려주세요!
솔직히 말해서, 디자인 시스템은 오랫동안 코드 단에서 해오던 일을 의미합니다.
본래 프로그래밍이란, 기능적이고, 재사용 가능하며, 확장 가능하고, 버전을 관리합니다.
현대의 디자인 시스템도 똑같이 그리고 더 많은 것을 해내는 것을 목표로 하고 있기 때문에
기존에 프로그래밍이 작동하는 방식에서 그 방향성을 잡을 수 있습니다.
디자인 시스템은 보다 보다 빠른 디자인 반복, 팀 및 제품의 확장성, 그리고 프로그래밍적 사고를 가능하게 하기 때문에 중요합니다. 저는 항상 앞선 두 가지에 집중했으나 현재는 프로그래밍적 사고에 가장 관심이 많습니다. 디자인 시스템을 구축하고 구현할 때 프로그래밍적으로 생각하는 것은 제품 디자인 팀에게 엄청난 파워를 줍니다.
디자인 파일에서 코드 구조를 미러링하기
여기 예시가 있습니다. 웹앱을 위해 Figma에서 UI 컴포넌트 라이브러리를 구축하고 있던 중이었습니다.
엔지니어링 팀은 이미 이 컴포넌트 라이브러리를 React에서 npm dependency로 구축했습니다.
저는 React에 익숙했기 때문에, React 컴포넌트 코드를 Figma 인스턴스 구축을 위한 영감으로 삼아 작업을 시작했습니다. 모든 크기의 컴포넌트가 분리, 중첩, 그리고 React 스키마에 존재하는 모든 옵션과 props에 간주된다는 이점을 보았습니다.
몇 년간 저는 이미 마크업 후 레이어와 그룹을 모델링 해왔습니다. — 중첩, 배치, 레이어 네이밍, 클래스 네임 미러링 — 그래서 디자인 파일에 코드 구조를 미러링 하는 것이 그렇게 미친 것처럼 보이진 않았습니다.
코드부터 시작해서 다시 작업하는 사치(?)를 누렸지만, 교훈은 있었습니다. 코드를 미러링 하는 디자인 그리고 그 반대 역시 파워가 있다는 점입니다. 그것은 정적인 것과 실제적인 것을 더 근사치에 가깝게 만듭니다.
예로 어떻게 form input을 구성하는지 잘 보여주기 위해 일련의 중첩된 컴포넌트를 사용해보겠습니다.
FormGroup > Input > Label 이런 식으로 진행이 됩니다.
Input과 Label은 마스터 컴포넌트를 가지고 있습니다. 그리고 이러한 Input과 Label 인스턴스는 FormGruop 마스터 컴포넌트 안에 구성되어 있습니다.
React와 유사하게, 컴포넌트의 독립적인 관리와 통합을 가능하게 합니다. 다양한 Variation을 가질 수 있는 컴포넌트를 다루거나 React의 “props’를 시뮬레이션하려고 할 때, 간단한 on/off 토글이면 충분할 것입니다.
dependency level에서 Stack Mirroring
저는 여기서 멈추지 않았습니다. 우리의 front-end 코드 스택(Node, npm, React, Javascript, markup 등)을 우리의 디자인 스택(Figma, Figma Libraries, Fimga Components, 레이어 및 그룹 등)에 반영할 기회를 발견했습니다.
이전에는 element level에서 미러링을 했지만, 지금은 dependency level에서 미러링 하는 방법에 대해 생각하기 시작했습니다. npm 같은 플랫폼은 외부적으로 관리되는 package와 dependency를 제한없이 포함할 수 있습니다. 예를 들어, 앞서 언급했던 컴포넌트 라이브러리는 우리가 내부적으로 Happy UI라고 부르는 dependency입니다. 이것은 front-end 컴포넌트 라이브러리로, Figma의 공유 라이브러리와 다르지 않게 우리 웹 제품의 전반에 걸쳐 공유됩니다. 이러한 정렬은 미러링이 향상되는 또 다른 기회라 볼 수 있습니다.
node 프로젝트의 package.json 파일에 dependency가 포함될 수 있는 것처럼, Figma의 팀 라이브러리 역시 같은 방법으로 생각할 수 있습니다. 우리는 Happy UI dependency를 다음과 같은 몇 가지 다른 프로젝트로 구분했습니다. -> Core, Web, Native.
Happy UI Core는 브랜드 에셋, 컬러, 아이콘 그리고 유틸리티 컴포넌트와 같은 기본 원칙을 공유합니다. Happy UI Web은 웹 인터페이스를 구축하기 위한 모든 기능적 컴포넌트를 갖추고 있으며, Core와 결합하면 효과적으로 사용할 수 있습니다. 그래서 만약 웹을 위한 새로운 온보딩 플로우를 작업한다고 하면, Web과 Core를 사용하면 되고 아주 간단합니다.
UI 엔지니어 또는 소프트웨어 엔지니어들과 함께 작업할 때, 우리는 빠르게 진행되는 환경 안에서 확장성, 효율성 그리고 반복성을 용이하게 하기 위해 공유된 namespace와 model을 사용합니다. Stack Mirroring과 함께라면, 이러한 목표들을 성취할 수 있는 방법과 수단에서 패닉과 혼란을 덜 느낄 수 있을 것입니다.
디자인과 개발이 namespace, tool, model이 서로 싱크가 잘 맞을 때 좀 더 나은 작업을 할 수 있다고 믿습니다. 우리가 정신적 비용을 줄일 때, 팀은 Feature를 빠르게 구축하고 내보내는 동안 퀄리티에 대해 타협할 필요가 없습니다. 개발과 디자인이 동시에 공존하는 것은 유지, 테스트 그리고 업데이트 하기가 더 쉽다는 것을 의미합니다. 무엇을 기다리고 계시나요? 지금 바로 당신의 개발자와 협력하여 Stack Mirroring을 시작하세요!
동료 디자이너님이 공유해주신 글인데 유용한 글이라 번역을 해보았다. 한 마디로 미러링을 통해 디자인과 개발의 갭 그리고 그들 사이의 커뮤니케이션 비용을 줄여주는 동기화 과정이라고 볼 수 있겠다. 회사에서 디자인 시스템을 아주 조금씩(…) 시작하고 있는데, 해당 내용을 개발자 분들께 공유해서 처음부터 싱크를 같이 맞춰나가면 확실히 좋을 것 같다.
다만, 디자인 시스템이라는 게 디자이너가 주도해야 하는 입장이라, 본문에서 보이듯이 프로그래밍적으로 생각하고 접근하기 위해선 어느 정도 React에 관해 알고 있는 게 효율 및 생산성 측면에서 좀 더 용이하지 않을까? 하는 생각도 든다.
끝으로 이 글이 디자인 시스템에 대해 고민하는 모든 디자이너 분들께 조금이나마 도움이 되었으면 하는 바람이다. :-)
