힛플

팀에 생산성을 높이기 위해서 디자인 시스템을 만들자고 건의했다. 물론 혼자 하는 작업이 아니고 디자이너와 긴밀하게 협업이 필요했고, 컴포넌트 구성을 새로 해야하는 도전 과제가 있었기 때문에 작은 작업은 아니었다. 아무튼 앱 내에서 자주 사용되는 UI 컴포넌트 구성 요소들이 많았기 때문에 Atomic Design 시스템을 적용하는 것으로 팀에서 대화를 통해서 결정하였다.

컴포넌트를 어떻게 나눠야하는거야?

참고

아토믹 디자인 시스템 문서를 보면 atom, molecule, organism, template, page 단위의 컴포넌트들이 있다. 모바일 앱이다 보니 template을 구성할 일은 별로 없었다 (주로 화면 정 중앙에 하나의 컴포넌트가 있는 템플릿을 만드는 경우를 제외하고는 template 을 만드는 경우는 없었다.) atom 단위나 page 단위의 컴포넌트를 만드는 것은 정의하기 쉬었으나 의외로 molecule, organism 단위의 컴포넌트를 결정하는 것이 어려웠다. molecule 의 정의를 보면 한 가지 일을 하는 컴포넌트 라는 것이다. 이 한 가지 일이라는 정의가 팀원들 사이에 혼란을 불러올 수 있을 것 같았다. 때문에 아주 심플하게 atom 단위의 결합이 일어나는 컴포넌트가 molecule, molecule 이상의 컴포넌트 조립이 일어나는 컴포넌트가 organism 이라고 정의를 했다.

상태관리를 어디서 하지?

아토믹 디자인 시스템을 도입한 이유는 컴포넌트들 간의 재사용성을 극대화 하기 위한 목적으로 채택했다. 그러니 가능하면 UI 와 상태관리(로직을 관리)하는 컴포넌트를 분리하고 싶었다. 일단 위의 기준으로 컴포넌트를 분리하고 보니 organism 단위까지는 UI 컴포넌트의 형태로 존재하는 것이 좋아보였다. orgaism 의 정의를 molecule 이상의 단위의 컴포넌트 조합으로 하다보니 organism 컴포넌트가 하나의 기능을 하는 UI 단위 컴포넌트가 되는 경우가 생긴 것이다. 그래서 page 단위에서 상태관리를 하고, 하위의 컴포넌트들은 상태를 받아서 사용하기만 하는 UI 컴포넌트의 형태가 되는 것이다.

그래서 해피 엔딩이었나?

page 단위에서만 상태관리를 하다가 보니 Props drilling 문제가 심각해졌다. 처음에 molecules 단위와 organism 을 나누는 정의를 다시 정의하는게 좋았을걸 하고 생각한다. props drilling 문제를 해결하기 위해서는 아니었지만 좀 더 좋은 해결책을 위해서 Atomic Desing system 을 다른 프로젝트에서 다른 규칙으로 진행해보았다.