[FE면접/React] 아토믹 디자인 패턴과 리액트 폴더구조에 관하여
프로젝트를 새로 들어가면서 페어와 디렉토리 구조 개편(?)에 대해 논의해보았다. 어떤 디렉토리 구조가 과연 좋은 것일까..🤔
폴더 구조에 정답은 없다고 하지만... 분명 보다 나은 방법은 있을 것이라 생각해 이것저것 찾아보았다.
그러다 발견하게 된 "아토믹 디자인 패턴" !!
실제 현업에서도 많이 사용된다고하니 이참에 한 번 알아보기로 하자.
0. 들어가기 전
이전에는 개발을 할 때 페이지 단위로 디자인 하였기에, "재사용이 가능한 컴포넌트를 만들어 조립하는 방식으로 디자인한다." 라는 대중적인 인식이 생기게 된 시기는 그리 오래되지 않는다.
하지만, 개발자들도 항상 쓰이던 놈은 쓰이고 또 쓰인다는 것을 알고 있었을 것이다.
반복해서 쓰이는 부품들을 잘 정리만 할 수 있다면 효율적으로 개발을 할 수 있지 않을까? 에서 시작된 것이 디자인 시스템입니다.
그렇다면 어떻게 하면 잘 정리할 수 있을까?
우리가 개발을 하다보면 컴포넌트 간의 계층이 있는 것을 알게 된다. 이 컴포넌트들은 목적, 도메인, 레이아웃 등 다양한 계층에 따라 구분된다.
따라서 우리는 자연스레 이 계층에 맞는 폴더를 만들고 싶어 한다.
그렇지만, 계층과 컴포넌트의 카테고리를 분리하는 단위가 계층, 목적, 재사용성, 범위 등 여러 개로 존재하는 반면, 폴더 구조는 하나이기에 때때로 개념과 폴더구조가 실제로 잘 일치하지 않는다.
또한, 사람마다 주관적인 기준이 많이 다르기 때문에 좋은 폴더 구조를 만드는 것 역시 어렵다. (좋은 폴더구조가 뭔데 ㅆㄷ아)
아토믹 디자인패턴이 정답은 아닐지언정.. 고민에 약간의 실마리를 줄 수 있을 것이라 생각하며 글을 들어가겠다.
1. 아토믹 디자인 패턴(Atomic Design Pattern)이란?
💡 아토믹 디자인패턴이란?
: 가장 작은 컴포넌트 단위를 원자(Atoms)로 설정하고, 이를 바탕으로 상위 컴포넌트를 만들어 코드 재사용을 최대화하는 방법론이다.
우리에게 레고블록이 있다면 그것을 조립해서 효율적으로 다양한 것들을 만들 수 있는 것처럼, 재사용이 가능한 컴포넌트를 먼저 만들어 두면 이를 조립하여 다양한 다른 프로그램을 만들 수 있게 된다.
이처럼 디자인에서도 재사용이 가능한 디자인 부품을 먼저 만들어서 이를 조립하는 방법을 우리는 디자인 시스템이라고 부른다.
Atomic Design Pattern에서는 '디자인 부품을 만들어 조립한다.' 는 개념을 화학적 용어를 이용해서 설명한다.
아토믹 디자인은 원자(Atoms), 분자(Molecules), 유기체((Organisms), 템플릿(Templates), 페이지(Pages)로 효과적인 인터페이스 시스템을 만든다.
1. 원자(Atoms)
원자 컴포넌트는 디자인과 기능의 최소 단위라 이해할 수 있다. 앞으로 만들 상위 컴포넌트에 재사용해야하기 때문에 가장 작고, 미니멀하게 제작한다.
대표적인 원자 컴포넌트는 레이블(Lable), 텍스트(Text), 컨테이너(Container), 버튼(Button), 아이콘(Icon) 등이 있다.
2. 분자(Molecules)
원지보다 한 단계 위의 컴포넌트이다.
입력 폼(Input foems), 네비게이션(Navigation), 카드(Card) 등을 예로 들 수 있다.
보통 프론트 개발자들이 컴포넌트를 만들 때 가장 많이 만드는 단위가 분자 수준의 컴포넌트라 할 수 있다.
3. 유기체(Organisms)
분자를 묶어 관리하는 컴포넌트이다.
입력 폼과 함께 헤더를 감싸거나, 여러 카드를 관리하는 그리드(Grid), 캐러셀(Carousel) 등을 예로 들 수 있다.
유기체부터는 명확히 컴포넌트의 사이즈를 설명하기 어렵다.
프로젝트별로 유기체에 해당하는 컴포넌트 단위는 다를 수 있고, 이를 유기체 단위가 아닌 더 상위 컴포넌트라 할 수 있는 템플릿과 페이지로 관리할 수도 있다.
4. 템플릿(Templetes)
템플릿은 여러 유기체가 모여있고, 페이지보다는 낮은 단위이다.
아직 데이터는 연결되어 있지 않은 최종 레이아웃의 형태를 뜻한다.
여러 카드 그리드를 묶어 하나의 템플릿 컴포넌트를 만들 수 있다.
5. 페이지(Pages)
템플릿에 실제 데이터가 결합이 되어 사용자에게 전달이 되는 최종 디자인 형태를 뜻한다.
정리하자면 다음과 같다.
아토믹 디자인 패턴에 대해 고민하다보니....
매일 페어와 "킹사용할 수 있는 컴포넌트는 common 컴포넌트로 빼자!" 라고 염불을 외웠었는데, 나도.. 사실은 아토믹 디자인 패턴을 사용하고 있었던 것을 알 수 있었다.
물론, 위와 같이 체계적으로 구성을 하고 개발을 하지는 않았지만, 아토믹 비슷하게 했다고 생각한다...^^...
2. 그렇다면 실제 디렉토리 구조는 어떻게 될까?
일단 무작정 Atomic Design Pattern으로 폴더를 만들고 무작정 시작하면 된다.
A,M, O, T 디렉토리명이 영어 순서에 맞게 이쁘게 맞아 떨어지기 때문에 직관적으로 폴더구조를 이해하기 쉬우며, 아래 디렉토리로 갈수로 상위 컴포넌트가 된다.
3. 아토믹 디자인패턴의 장단점
그래서 장점이 뭔데?
- 계층별로 순서대로 예쁘게 정렬되는 폴더 이름과 구조
- 어플리케이션과 분리하여 컴포넌트를 개발하고 테스트할 수 있음
- 설계 변경이 필요한 경우 더 빠르고 유연성 있는 빌드 프로세스를 가질 수 있음
- 기존 컴포넌트들을 재사용하고 있기 때문에 디자인을 일관성 있게 통일할 수 있음
- 특정 컴포넌트에 CSS가 강하게 결합되어 있기 때문에 CSS를 훨씬 더 잘 관리할 수 있음
단점도 있음?
- 원자에 해당하는 컴포넌트가 파편화되고, 난잡해질 수 있음
: 수 많은 원자 컴포넌트가 각각 어떤 기능을 하는지 명확히 구분하기 어려워진다. - molecules와 organism을 나누는 기준의 모호함
: 프로젝트가 커지고 조립하는 단계가 많아질수록 그 경계가 모호해진다. 아토믹 지다인 단위를 나누는 기준은 주관적이기 때문에 팀원들끼리 개발하는 명확한 기준점이 필요하게 된다.
4. 아토믹 디자인패턴에 대한 고민
과연 그렇다면 고민하게 만드는 컨벤션이 좋은 컨벤션일까?
아토믹 디자인은 어느 정도의 변화 또는 대형 변화에는 최적화된 패턴이라 할 수 있다.
하지만, 변화가 누적되면서 각각을 구성하는 컴포넌트가 많아질 때는 손을 쓸 수가 없게 된다.
심지어 컴포넌트 간 의존성이 상하로 발생하기 때문에 하위 컴포넌트에서 예상치 못한 에러가 발생하게 되면 모든 상위 컴포넌트가 엉망이 되는 일이 발생하게 된다.
즉, 프로젝트가 클수록 고작 5개의 분류만으로 그 많은 컴포넌트들을 구분하는 것은 굉장히 어려운 상황이 된다.
그렇다면 그냥 컴포넌트를 한 곳에 모은다면?
어짜피 컴포넌트를 작성하면 IDE가 자동적으로 import해주는 거.. 굳이 디렉토리 구조를 짤 필요가 있을까?
이 방식이 내가 두 번의 프로젝트를 진행할 때 사용했던 방식이다.
모든 컴포넌트들은 /components 디렉토리에 담고, 필요에 의해 재사용되는 컴포넌트들만 /components/common 디렉토리에 담았다.
그 이외에는 기능 단위로 컴포넌트들을 구분하였다.
이렇게 되니 생긴 문제점이 컴포넌트 간의 계층이 눈에 보이지 않았다.
디렉토리 구조는 책으로치면 목차와도 같은 존재이다. 사실 책을 읽는 동안에는 목차를 그리 신경을 쓰면서 읽지는 않지만, 나중에 필요한 것들을 찾으려고 할 때 목차가 없으면 내가 원하던 것들이 어디있는지 그리고 전체적인 구조가 눈에 보이지 않는다.
디렉토리 구조는 곧 생각의 체계이다.
그래서 결론이 뭔데?
모든 컴포넌트들을 A, M, O, T 로 구분하기 보다는 기능별로 컴포넌트를 구분하되, 그 하위 디렉토리에 아토믹 디자인 패턴을 적용하면 훨씬 수월하게 해당 디렉토리에 접근할 수 있게 된다.
공통적으로 사용하는 컴포넌트의 경우 이전에 사용했던 /common 디렉토리를 만들어주면 된다.
5. 마무리하며..
폴더 구조에는 정답이 없지만.. 그럼에도 개발자들의 고민은 계속된다!
그러는 나도 이번 프로젝트에서 아토믹 디자인패턴을 사용하지는 않게 되었지만, 이전에 있었던 계층구조를 파악하기 어렵다는 문제점을 보완하고자 새로운 디렉토리 구조를 적용해보기로 했다! (나.. 성장한걸까..😚)
나중에는 꼭 한 번 적용해보고 싶은 디자인패턴이기에 이렇게 글을 작성하며 개념에 대해 알게 되었다.
리액트 공식문서에 나온 폴더구조에 대한 조언을 끝으로 이 글을 마무리하고자 한다.
디렉토리 구조에 5분이상 고민하지 마세요!
그럼에도 단일 프로젝트에서 폴더의 중첩은 최대 3개 또는 4개로 제한할 것을 권장한답니다.