아토믹 디자인에 관하여...

프론트엔드 생태계가 발달하면서 개발 시스템에도 많은 변화가 찾아왔습니다. 앱의 규모가 커질수록 많은 것들이 필요했고, 이것들을 제어하기 위한 방법이 필요했습니다. 

이에 따라 프론트엔드에서는 디자인 시스템이라는 것이 생겨났는데, 요즘 가장 많이 들리는 패턴이 바로 오늘의 주제인 아토믹 디자인입니다.

 

아토믹 디자인?

 

아토믹 디자인 하면, 가장 많이 보이게 되는 그림인데요. 이름 그대로 작은 단위로 나누어서 컴포넌트를 관리하는 방법론입니다.

더 이상 쪼갤 수 없는 단위 까지 쪼갠 것을 보통 atoms로 분류하고, atoms가 모여서 molecules가 되고, organisms 등등으로 만들어져 결국엔 페이지로 관리하게 됩니다.

 

버튼, Input 같은 것들을 보통 atoms로 분류하게 됩니다. 이후에 atoms가 모여서 html 텍스트 필드, 에러 메시지 같은molecules가 되는데요.

 

문제는 여기서 부터 입니다. molecules, organisms가 명확하게 정의되어 있다고 하지만, 막상 개발을 해보면 이 두 관계가 참으로 모호해집니다.

 

그 뿐만 아니라 templates, pages 도 마찬가지입니다. 어쨌든 공통적으로 말하는 건 atoms 이후로 pages까지의 저 단계들에 대해서 어떻게 정의해야 하는가?입니다.

 

실무에서도 마찬가진데. 이 부분에 대해서 많은 고민을 했습니다.

그리고 그 결과 아래와 같이 도달했습니다.

 

Atomic 구분	파일경로	구분기준	역할	스타일	store 접근	단위테스트
Pages	views/pages	route	페이지	페이지별 scss	O	X
Templates	componets/resources	domain	기능단위의 묶음(템플릿)	컴포넌트 내부	O	X
Organisms/Molecules	components/commons	UI	UI단위의 컴포넌트	컴포넌트 내부	가급적 지양	O
Atoms	components/atoms	UI	기본 컴포넌트	컴포넌트 내부	X	O

 

 

 저희는 Templates를 resources라는 폴더에 분류했고, 여기엔 commons가 모여서 만들어지는 기능단위의 묶음으로 분류했습니다. store 접근은 가능하며, 스타일은 컴포넌트 내부에서 선언해서 만들었습니다.

 

Organisms/molecules는 한꺼번에 묶어서 commons로 정의했고, 여기에선 store 접근은 안되지만, 단위테스트는 가능하게 했습니다.

atoms는 위와 마찬가지로 쪼갤 수 없을 정도의 작은 단위이며, commons와 마찬가지로 store 접근은 불가능하지만 단위 테스트는 가능하게 했습니다.

 

그리고 resouces들을 최종적으로 모아 pages를 완성시킵니다. 여기서 나온 페이지는 route에 쓰이고, 페이지의 스타일과 store 접근, 훅 같은 것들을 pages에서 한꺼번에 하는 편입니다.

 

물론 이 방법이 정답은 아닙니다. 더 많은 컨퍼런스들이 있으며 더 좋은 답변이 있을 수도 있습니다.

아래에는 저희가 참조한 아토믹 디자인과 관련된 레퍼런스입니다.

https://kciter.so/posts/effective-atomic-design#atomic-design%EC%9D%B4%EB%9E%80 

Effective Atomic Design

https://ui.toast.com/weekly-pick/ko_20200213

리액트 어플리케이션 구조 - 아토믹 디자인