시스템

요즘 회사에서 핫 이슈는 디자인 시스템이다. 가끔 채널에 관련 피그마 링크가 올라오면 종종 들어가 보곤한다. 생각보다 시스템을 만들어서 얻을 수 있는 이득이 많아 보이지 않았다. 현재 프로덕트에 포함된 모든 에셋을 포함하는 시스템을 만들다보니 경우의 수가 너무 많아졌고 사실상 시스템 없는 시스템처럼 보였다. 

 

시스템을 너무 빡빡하게 잡으면 새로운 디자인을 추가하거나 변경하는게 어렵고 시스템을 너무 널널하게 잡으면 시스템이 있으나 마나가 된다. 결국 디자인 시스템이란 유연성과 시스템의 엄격함 사이를 적절히 타협해 효율을 내는 것일 텐데 현재의 디자인 시스템은 너무 널널한 기준으로 잡아 사실상 복잡성이 증가한 경우 같았다. 생물들을 종속과문강문계로 나누지 않고 개, 고양이, 호랑이 이런식으로 하나씩 분류하는 것과 같다.

 

결국 중요한 것은 적절히 유연하면서 적절히 빡빡한 정보의 위계를 세우는 것이다. 가장 기본 단위인 아이콘, 버튼, 텍스트, 색과 같은 요소들이 있겠고 이들을 합친 컴포넌트가 있고 이들을 적절히 위치시키면 하나의 페이지가 된다... 적다보니 내가 뭐라고 이런 생각을 하나 싶다.

 

디자인 시스템을 보면서 느낀건, 먼저 작업한 부서의 작업방식이 다음 부서의 작업에 영향을 주어 비효율로 직결되곤 하는데 이는 부서간 약속으로 해결할 수 있다. 물론 구두나 문서로 작성된 약속이여도 좋지만 이를 시스템으로 만들면 정말 큰 임팩트를 낼 수 있다고 생각했다.

 

글을 적다보니 객체 지향 프로그래밍과도 비슷한 면이 있는 듯하다. 부서는 적절히 캡슐화 되어 있어야되고 부서와 부서는 시스템이라는 인터페이스에 의존해야한다. 그래야 부서의 실제 구현이 변경되어도 문제 없이 동작한다.