[TaskStock] Atomic Design Pattern 도입기

프롤로그

프로젝트	TaskStock
기간	기획, 개발 : 2023.11.7~2024.3 베타테스트 : 2024.2.22~3.14 정식 출시 : 2024.3
플랫폼	iOS, Android
언어	FE: TypeScript / BE: JavaScript
프레임워크	FE: React Native / BE: Node.js Express
라이브러리	Redux Toolkit

 

React Native를 3주 만에 학습하고 투입된 피로그래밍 앱개발 프로젝트에선 정말 중구난방으로 컴포넌트를 관리했다. 컴포넌트를 따로 폴더를 만들어 관리해야 한다는 필요성조차 알지 못했던 시절이다. 공개하기 부끄럽지만 피로그래밍 앱의 /components 폴더 안에서 관리되고 있는 컴포넌트들은 성격에 상관없이 한 계층에서 모두 관리되고 있다. 모달, input, loader... 또 무슨 컴포넌트가 있을지 전혀 예측할 수 없다...이게 큰 문제인 것이 의존성이 있는 컴포넌트를 찾으려면 코드를 들여다보지 않으면 알 수 없다는 것이다. 가독성도 너무 떨어진다. 
또한 screen 파일 안에서 쓴 컴포넌트들을 따로 분리하지 않고 그 파일 안에서 그때그때 만들어 사용해 같은 모양의 컴포넌트를 여러 번 만들기 일쑤였다. (왜 그랬지..) 더군다나 components 파일 안에 있다고 해서 재사용이 가능한 것들만 있는것도 아니다.ㅋㅋㅋ
생각해 보면 우리 어플은 기능이나 화면이 적은 편이 아닌데 /components 폴더 안에 파일이 저거밖에 나오지 않았다는 건 말이 안 되긴 한다.. (그만큼 재사용을 하지 않았다는 뜻이다..) 

 
내가 느낀 컴포넌트를 깔끔하게 관리해야 하는 이유는 다음과 같이 정리할 수 있겠다. 

1. 재사용성
2. 가독성 
3. 유지보수의 용이성
4. 코드 충돌 감소
5. 프로젝트 확장성 

 
 
새로운 프로젝트를 시작하기 전, 협업을 할 때에 폴더를 어떻게 구성하고 파일을 어떻게 관리할지 우리만의 약속, "명확한 기준"이 필요했다. 그러다 카카오 기술블로그에서 좋은 글을 발견했다. 
 
https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/

아토믹 디자인을 활용한 디자인 시스템 도입기 | 카카오엔터테인먼트 FE 기술블로그

---

Atomic Design Pattern이 뭐야? 

Brad Frost가 처음 개발한 방법론으로, 디자인을 구성하는 가장 작은 단위부터 시작하여 점점 더 큰 단위로 조합해 나가는 방식을 제안한다. 웹상에 공개되어 있는 책이니 시간 나면 읽어보길 바란다. 
https://atomicdesign.bradfrost.com/

Atomic Design by Brad Frost

Frost는 Henry Ford가 자동차 제조 과정에서 부품을 모듈화함으로써, 각각의 차량을 수작업으로 만드는 대신 더 안정적이고 일관된 품질의 제품을 더 빠르게 생산할 수 있게 된 사례를 언급한다. 화학적으로도 비유를 하는데, 물질을 이루는 가장 작은 단위인 원자가 모여 특정 성질을 띄는 분자가 되고, 분자가 모여 의미 있는 하나의 유기체가 된다고 설명한다. 여기서 핵심은 우주의 모든 물질은 유한한 원자 요소 집합으로 분해될 수 있다는 것이다. 비슷한 원리로, 앱이던 웹이던 모든 인터페이스는 동일한 HTML element들로 구성된다는 것을 생각해볼 수 있다. 

신소재 전공자로서 너무 반가웠던 Periodic Table.. 개발공부하면서 첨봄.. 
 
Frost는 atoms, molecules, organisms, templates, pages라는 다섯 단계를 소개한다. 이제, 각 단계가 어떤 역할을 하는지 알아보자. 

Atoms - 컴포넌트들의 기초가 되는 블록이며, 더 이상 분해할 수 없고 재사용이 가능한 최소 단위. ex) 버튼, 제목, 텍스트 입력 필드
Molecules - 하나 이상의 원자가 결합해 하나의 단위로 함께 동작하는 UI 컴포넌트들의 단순한 그룹 ex) 텍스트 입력 필드 + 아이콘으로 구성된 검색 컴포넌트
Organisms - 여러 분자 또는 원자가 모여 보다 복잡한 UI 섹션을 형성하는 상대적으로 복잡한 구성 요소
Templates - 조직체와 분자들을 포함하는 페이지 레벨의 객체
Pages - 템플릿에 실제 data가 연결되어 사용자에게 전달되는 최종 형태 

 
이렇게만 보면 되게 명확하게 구분할 수 있을 것 같은데, 프로젝트 규모가 커지고 컴포넌트의 종류가 다양해질수록 각 단계의 경계가 모호하다는 생각을 많이 하게 된다. 
예를 들어보자. 

• Icon(atom)과 Button(atom)을 합친 IconButton이 있다고 하자. atom의 집합이므로 원리상 molecule이지만, 기능적으론 atom이다. 
• 그림자를 추가한 모달 컨테이너는 어디에 포함해야 할까? 
• tooltip은 어디에 포함해야 할까?

정해진 명확한 답은 존재하지 않고, 결국 우리 팀만의 규칙을 정해야 한다. 

---

TaskStock에 적용하며 생긴 여러가지 이슈

1. 폴더 구성에 대한 고민 

1안	2안
/components ㄴ/atoms    ㄴA    ㄴB ㄴ/molecules    ㄴA    ㄴB ㄴ/organisms    ㄴA    ㄴB ㄴ/templates    ㄴA    ㄴB	/components ㄴA   ㄴ/atoms   ㄴ/molecules    ㄴ/organisms   ㄴ/templates ㄴB   ㄴ/atoms   ㄴ/molecules    ㄴ/organisms   ㄴ/templates
atomic -> group	group -> atomic

 
 
https://velog.io/@teo/Atomic-Design-Pattern 테오님도 같은 고민을 하신 것 같다. 테오님은 2안을 선택하셨는데, 우리는 1안을 선택했다. 무엇이 나은 지는 솔직히 잘 모르겠다. 
1안은 여러 스크린에서 공유하는 컴포넌트 수가 많을 때 좀 더 적합해 보이고, 2안은 feature별로 분위기가 다를 때, 그러니까 스크린별로 공유하는 컴포넌트가 적을 때 사용하기 깔끔해 보인다. 또한 2안은 서로 연관 있는 것들끼리 물리적으로 거리가 가까워 관리하기가 편하다는 장점을 들 수 있다. 또한 테오님은 1안에서 제시하는 공통 컴포넌트를 찾기 위한 방안으로 @공통 폴더를 만들어 해결하신 것이 인상깊다. 
 
우리는 어떻게 했나?
우리 프로젝트는 스크린별로 공유하는 컴포넌트가 많은 편이었다. 스크린 간 공통으로 사용하는 것들은 폴더 안에 넣지 않고 따로 뺐다. 예를 들어, 화면 A와 화면 B가 공유하는 molecule은 

ㄴ/molecules
   ㄴ/A
   ㄴ/B
   ㄴ공통1.tsx
   ㄴ공통2.tsx

   
와 같은 방식으로 관리했다. 지금 생각해 보니 atoms, molecules, organisms, templates별로 /공통 폴더를 만들어 관리했어도 좋았을 것 같다. 

2. atom은 최대한 유연하게. 

재사용성을 높이려면 여러 조건에서 유연하게 쓸 수 있어야 한다. 그러기 위해서는 props를 많이 전달해야 하는데, 자주 사용하는 것들은 default값을 설정해두고, typescript를 적극적으로 이용했다. 미처 생각하지 못한 props는 개발 중에 추가하기도 했다. 
예를 들어 Text 컴포넌트가 있다고 하자. props로 fontSize, color, fontWeight를 받는다. 가장 많이 사용하는 fontSize, color, fontWeight를 default값으로 설정해두고, color는 typescript type을 사용해 특정 색상만 사용할 수 있게 제한한다. 

3. 재사용성에 집착하지 말자.

개발을 진행할수록 관리해야 할 컴포넌트가 많아진다. 코드를 깔끔하게 관리하기 위해 atomic design pattern을 도입했는데 재사용성을 고려하느라 코드가 더러워지고 있다는 생각을 하게 되었다. Atoms을 제외한 molecules, organisms, templates에서는 어느 정도 재사용성을 포기하고 유연하게 관리했다. 

4. Props drilling 이슈

재사용성과 유연성을 위해 props을 사용할 수 밖에 없는데, atomic system으로 컴포넌트를 관리하다 보면 발생할 수 있는 치명적인 문제가 있다. 바로 templates -> organisms -> molecules -> atoms로 props를 전달해야 하는 props drilling 문제다. 우리는 각 단계 안에 스크린별로 폴더를 나누고, redux toolkit과 custom hook을 적극적으로 만들어 props drilling을 최소화했다. 
 

---

Atomic design pattern의 장단점 정리

장점

• 확실히 체계가 잡힌 느낌이다. 전체적인 구조가 직관적으로 한눈에 보인다. 
• 변화에 유연하다. 프로젝트를 하다 보면 디자인적 요구사항이 바뀌는 경우가 많은데, 패턴이 있기 때문에 유연하게 대응할 수 있고 일관성 있는 디자인을 제공할 수 있다. 

 
단점

• 각 단계의 기준이 모호하다. 사람마다 구분하는 기준이 달라 사전 협의가 필요하다.  
• 재사용성을 지나치게 고려하다 보면 잘 사용하지 않는 props를 추가해야 하는 경우가 생긴다.
• props drilling이 발생한다. 

---

그래서 좋은 폴더 구조란? 

좋은 폴더 구조에 대해선 끊임없이 고민해 나가야 할 주제이며 정답이 존재하지 않는다. 프로젝트의 구조에 따라 적합한 폴더 구조를 잘 설계하는 것도 중요한 능력이다. 
Atomic design pattern이 TaskStock 프로젝트에 적합한 패턴이었나 생각해 보면 yes라고 답할 수 있을 것 같다. 코드를 짜면서 불편함은 딱히 못 느꼈고, 대체로 직관적으로 와닿았다. 굳이 단점을 꼽자면 Atomic Design Pattern은 컴포넌트를 관리하기 위한 좋은 가이드를 제공했지만, 프롤로그에서 언급했던 우리가 원하던 "명확한 기준"을 충족시켜 줬다고는 보기 힘들 것 같다.(각 컴포넌트들의 소속이 모호하므로) 하지만 컴포넌트의 정확한 분류보다는 '최소 단위 컴포넌트의 재활용'에 초점을 맞추는 것이 더 중요해 보이고, 이러한 관점에서는 우리 프로젝트에 적합한 디자인 시스템이라고 볼 수 있겠다. 

---

Reference
https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/
https://atomicdesign.bradfrost.com/
https://velog.io/@teo/Atomic-Design-Pattern

---

‎TaskStock

TaskStock - Google Play 앱