React 프로젝트 구조화 2 - atomic 디자인 적용의 한계와 반성

회사의 컨텐츠 관리 어드민 페이지를 react로 마이그레이션하는 프로젝트에서 컴포넌트의 구조를 atomic 디자인의 구조를 적용했었고 개발이 거의 완료되어가고 있는 이 시점에 개발 과정을 되돌아보며 반성을 해보기로 했다.

 

1. atomic 디자인의 도입은 현재 프로젝트의 규모에서는 올바른 선택은 아니었다. 

• 우선 admin 페이지이기에 UI 디자인에 대한 요구사항이 없었다. 실제로 외주에서 만들어줘서 사용하고 있던 angular 로 만들어진 admin 페이지도 material UI 라이브러리를 디자인 변경없이 사용하고 있었고 마이그레이션도 React의 MUI의 컴포넌트들을 거의 대부분 변경없이 사용했다. 
• UI 라이브러리의 기본 컴포넌트들이 필요한 대부분의 기능을 제공하다보니 atom을 정의하기가 곤란해졌다. 
  • 예를 들어 MUI의 Button / TextField 컴포넌트들을 개념상 atom으로 본다면 우리 프로젝트에서 atom을 어떻게 정의 해야할지 애매해진다. 
  • atom이 애매하니 당연히 moculars, organisms... 모두 애매해졌다. 
• 개인적으로 atomic 디자인을 적용할 때 구성원들이 bottom-up 방식의 component 개발에 익숙한 것이 핵심이라고 생각한다. 사실상 주니어 개발자 2명이 진행한 프로젝트이고 학습과 프로덕션 개발을 병렬적으로 진행하니 제대로된 아키텍처가 나올리 만무했다. 

2. hooks / service / util 의 모호함

• UI와 관련된 공통 로직은 hooks, 외부 라이브러리 사용은 service, 그외에 잡다한 여기저기서 사용하는 함수들은 util에 때려박기로 하고 프로젝트를 진행했는데 aws-sdk 같은 외부 라이브러리를 사용할 때 UI의 상태에 따라 인스턴스를 생성하고 해제하는게 편해서 커스텀훅으로 만들다보니 service와 hooks의 경계가 무너졌다. 
• 커스텀 훅 내부에 선언되어야할 util에 선언되어야 할 함수의 구분도 코드가 많아지면서 모호함을 가지게 되었다. 

3. 스토리북의 View / 로직 / 데이터 분리 문제 

• 컴포넌트 하나는 해당 컴포넌트를 위한 커스텀훅, 그리고 view 로직으로 나누어서 구현되어있는데, 이벤트 로직이나 표시되어야할 데이터를 해당 컴포넌트의 훅에서 뷰로 주입하는 구조가 되다보니 스토리북에서도 redux 스토어를 업데이트를 해야하는 문제가 발생했다. 
• 완전히 view 로직을 분리하고 wrapper 컴포넌트에서 hooks에서 내뱉는 함수나 데이터를 주입시켜주도록 구성하고 스토리북에는 view 로직만 있는 컴포넌트로 개발할 수 있지만 쓸데없이 복잡도만 증가시키는 것 같다고 생각한다.