지난 봄, 여름에 걸쳐 혼자서 디자인 시스템을 만들면서 수 많은 고민을 하고 작은 결정과 선뜻 답을 내기 어려운 어려운 문제들을 만나곤 했다.
머리를 맞대고 궁리해도 아직까지도 알쏭달쏭한 문제들도 있지만, 컴포넌트 개발 중 했던 많은 고민과 참고한 소스코드 등을 바탕으로 나름대로의 기준을 만들어가게 되었다.
그러던 중, 디자인 시스템 컴포넌트 설계 경험을 바탕으로 다른 팀원분의 MR에 코드리뷰를 하면서 비슷한 내용의 코멘트를 달게 되는 일들이 생겼고, 내가 했던 고민의 시간을 다른 팀원이 반복하지 않았으면 했다. 설계 측면에서 네이밍이나 설계 측면에서 모두가 쉽게 놓칠수 있는 부분에서 발생하는 코스트를 줄이고, 나 또한 코드리뷰 리소스도 최소화하고자 했다.
또한 가이드라인이 있을 때 서로 다른 코드 스타일, 네이밍 습관에 따라 API또한 파편화 되는 것을 막을 수 있다. 일관된 API가 제공된다면, 처음 사용하는 컴포넌트더라도 사용자가 예상하는 방식으로 구현되어 문서를 굳이 찾아 읽거나 레포를 찾아 본다든지 하는 비용을 최소화 할 수 있다.
이러한 사용자 측면의 비용과 기여 측면의 비용을 최소화할 수 있도록 ’디자인 시스템 설계 가이드라인‘을 만들어야겠다고 생각하게 되었다.
그러한 생각이 든지 얼마 안되어, MUI의 API design Guideline을 발견하게 되었다.
신기하게도, 해당 문서에는 그동안 내가 컴포넌트를 설계하면서 했던 고민들이나 일관되지 않아 궁금했던 API 네이밍에 해당하는 원칙, rule들이 적혀있었다.
EDS(Elice Design System)은 Material-UI를 기반으로 만들어졌기 때문에, 우리는 최대한 MUI의 컴포넌트 네이밍, 프롭 네이밍을 참고하여 사용자의 러닝커브를 최소화하고 있다.
예를 들어, 한 컴포넌트가 특정 프롭에 따라 다른 종류의 형태를 갖게 된다면
type , shape 보다는 variant 라는 네이밍을 사용한다.
또한, 전 세계의 수많은 사용자를 보유한 MUI사에서는 컴포넌트 네이밍 하나에도 많은 고민이 담겨있을 것이기 때문에, 이들의 가이드라인은 신뢰할만 하다고 생각했다. (물론 레거시도 존재..)