[Refactor/Architecture] 좋은 폴더구조를 찾기 위한 여정

* 코드스테이츠 메인 프로젝트로 진행한 "JOYING: 세상의 모든 OTT 컨텐츠를 한 곳에 보여조잉"을 팀원들과 함께 리팩토링하면서 작성한 일지입니다.

메인프로젝트 소개와 회고 보기

 

왜 폴더구조를 바꿔야 했나?

폴더구조를 바꿔야겠다고 생각한 가장 큰 이유는 파일을 찾기가 어려운 것 때문이었다.

components 폴더 아래에 페이지별 폴더와 ui에 해당하는 폴더들이 섞여 있어서 어떤 파일을 어디서 찾을 수 있을지 알기가 어려웠다.

 

어떤 폴더구조를 만들려고 했나?

폴더구조를 개편할 때 두가지 목표를 가지고 시작했다.

• 도메인별로 폴더가 구분돼 있어 큰 줄기를 잡을 수 있어야 한다.
• 아토믹 디자인의 개념상 서로 다른 계층에 속하는 컴포넌트끼리 서로 구분돼 있어야 한다.

첫번째 목표에서 사용한 '도메인'이라는 단어는 DDD(Domain Driven Development)에서 '해결하고자 하는 문제 영역'을 가리킬 때 사용하는 말에서 가져왔다. 구글에서 검색하면 온라인 서점의 도메인이 상품, 회원, 주문, 정산 배송 등의 도메인으로 나뉘어 있다는 예시를 많이 볼 수 있다. 이것을 우리 프로젝트에 적용을 해 보자면 미디어, 멤버, 댓글, 추천, 북마크, 관리자 등의 도메인으로 나뉘어 있다고 볼 수 있을 것 같다.

 

다만, 이렇게 폴더를 나누려고 했다고 해서 DDD 모델을 그대로 우리 프로젝트에 적용하려 한 것은 아니었다. DDD 모델의 장점은 훨씬 더 복잡한 비즈니스 모델을 두고 도메인 전문가와 개발자가 협업할 때 협업을 좀 더 용이하게 만들어주고, 도메인별로 독립성이 강한 애플리케이션을 개발함으로써 기능의 확장 또는 폐기가 쉽다는 것이라고 이해했는데 두 장점 모두 우리 프로젝트에 적용하기에는 큰 메리트가 없고 오히려 배보다 배꼽이 큰 격이라고 느껴졌기 때문이다.

 

폴더구조 개편을 위한 두번째 목표를 보자면, 사실 첫번째 목표와 완전히 상반되는 요구사항이다. 한 도메인 안에 atom, molecule, organism, template, page가 당연히 섞여 있기 때문이다. 그럼에도 크고 작은 컴포넌트들이 하나의 폴더에 섞여 있는 것이 혼란스러웠다. 서로 상반되는 두 목표를 적절히 조화시킨 폴더구조를 만들어 내면 좋겠다고 생각했다.

 

결과물

개편 전 폴더구조

 

개편 후 폴더구조

.
├── api
├── assets
│   └── fonts
├── components
│   ├── @common
│   │   ├── InfiniteScroll
│   │   ├── Itemcard
│   │   ├── button
│   │   ├── slider
│   │   ├── toast
│   │   └── topbutton
│   ├── @layout
│   │   ├── banners
│   │   ├── footer
│   │   ├── header
│   │   ├── mobileGNB
│   │   └── navigators
│   ├── admin
│   ├── authentication
│   ├── comments
│   ├── mediaDetail
│   │   ├── bookmark
│   │   ├── recommend
│   │   ├── relatedMedia
│   │   └── report
│   ├── member
│   │   ├── MemberInfo
│   │   ├── memberContents
│   │   └── profileModal
│   └── recommend
│       ├── buttons
│       └── questions
├── constant
├── hooks
├── pages
├── recoil
│   └── atoms
├── styles
├── types
└── utils

먼저 components 폴더 아래 layout과 common 폴더를 생성했다. layout은 말 그대로 레이아웃 컴포넌트(헤더, 푸터 등)를 모아둔 폴더이고, common은 여러 페이지에서 공통으로 사용되면서 아토믹 디자인 개념상 atom 또는 molecule 정도에 해당하는 컴포넌트들을 모아두었다. 이렇게 함으로써 재사용성이 높은 컴포넌트들을 구분하고 여러 페이지에서 공통으로 사용할 수 있게 했다.

 

components 아래의 나머지 폴더들은 페이지별 구분을 따랐다. 도메인별이라고 거창하게 부를 수도 있겠으나 일관되게 도메인별로 구분헀다기에는 조금 맞지 않는 부분도 있고, 정확하게 말하자면 단순한 페이지별 구분에 더 가깝다. 페이지별 구분이 현재로서는 어느 정도 도메인별 구분과 성격이 겹치기도 하고, 지금처럼 페이지가 많지도 않은 프로젝트에서는 페이지별로 구분했을 때 원하는 파일을 찾기 가장 쉽다고 생각했기 때문이다.

 

어쨌든 기존의 전혀 기준을 알 수 없는 폴더구조에서 한층 깔끔하고 나름의 기준이 있는 폴더구조로 정리돼서 마음이 아주 편안하다. 앞으로 리팩토링을 진행하면서 바뀌는 컴포넌트와 파일들에 따라서 더 적합한 폴더구조가 무엇인지 계속 고민을 이어 나갈 계획이다.