글을 시작하며 사내에서 백오피스 프론트엔드 프로젝트에 타입스크립트가 적용되면서 내부 컨벤션이 정의되며, 구조에 대해 한번 더 생각할 기회가 있었다. 이 과정에서 초기 사내 백오피스 프론트엔드 프로젝트의 폴더 구조는 아래와 같이 도메인 별 1:1 매핑되는 구조로 가져고 있었다. 프로젝트를 진행하다보니 이 구조가 기능 도메인이 점차 커질수록 많은 문제점을 야기한다는 것을 알게되었다. 위에 코드는 실제 프로젝트로 기존에 구성되어있던 구조이다. 초기에는 프로젝트 도메인 별로 구분이 되어있다는 느낌을 받으면서 직관적이고 모든 API는 api/ 폴더 안에, 그리고 모든 페이지를 구성하는 뷰(페이지)는 views/ 폴더 안으로 구성하면되니 일관성을 확보할 수 있었다. 다만 점차 프로젝트의 기능 별 도메인이 많아지면서 백오피스에서 관리해야하는 영역들이 많아지고 있음을 느꼈다. 그리고 이런 문제점들이 발생했다. 기능 별 도메인이 추가될 때마다 views 폴더 안에 관련 폴더를 만들어주고, api , components , composable 과 관련된 폴더들에서도 동일한 이름으로 만들어줘야한다. 이 과정에서 네이밍 규칙이나, lookAlike 라는 기능 도메인을 lookAlikeDomain 과 같이 자유분방한 이름으로 통일성이 지켜지지 않는 경우가 있다. components , util 과 같은 우리가 평소 쓸만한 폴더 명이 아니기도 하면서, 익숙하지 않기 때문이다. 기능이 2~30개 정도가 되면 한 views 폴더 안에서 해당 컴포넌트를 찾기 위해서 여러 파일들을 탐색해야하는 경우가 생기는데, 이 과정이 점점 오래 걸리기 시작한다. 기능을 수정할 때도 동일하다. views 폴더에서 컴포넌트로 이동을 했다가 또 views 파일로 이동을 하는 반복적인 과정들이 생긴다. 레이어(기술 중심) 폴더로 설계를 하다보니, 각 폴더를 "무엇을 하는가" 에 따라 분류하면서 낮은 응집도와 확장성, 그리고 네이밍 중복에 대한 문제가 발생한다. 어떻게 해결할 수 있을까? 처음 백오피스 구조를 살펴보면 여러 컴포넌트들과 컴포저블들은 궁극적으로 views 폴더 안에 존재하는 기능 도메인 파일을 위해 구성되는 여러 요소들이다. 이 목적성에 따라 views 를 기점으로, 그러니까 각 기능 별 도메인을 기준으로 폴더를 구성한다. Intelligence 기능 도메인을 구현하기 위해 api , components , composable 폴더 및 파일들이 존재하게 되는 것이다. 이런 구조로 개발을 진행하게 되면 초기 폴더 구성 및 체계를 구조화하는데 시간이 조금은 걸릴 수 있겠지만, 기능 별 도메인 단위가 커지더라도 Intelligence 기능 도메인을 구현하기 위해 다른 트리들의 폴더들을 일일히 보지 않아도 되는 장점을 얻을 수 있다. Intelligence 기능 도메인의 views 폴더만 펼치면 이를 구성하기 위한 관련 요소들이 모두 노출되기 때문이다. 위의 코드처럼 이렇게 Featured-based(기능 중심)로 폴더 구조를 설계하게 되면 관련 코드가 한 곳에 모여있어 기능 수정 시에 탐색 시간을 단축할 수 있고, 각 기능 도메인의 범위가 명확하게 정의되어있어서 협업 시에도 충돌을 최소화 할 수 있다. 또 새로운 기능이 추가될 때 독립적인 폴더만을 구성하면 되기 때문에 편리하게 사용할 수 있다고 생각했다. 글을 마치며 좋은 폴더 구조를 구성하기 위해 현재 백오피스 프론트엔드 프로젝트의 구조를 신규 체계와 같이 변경을 진행하고 있다. 더 좋은 방법이 생각난다면 적용을 해보겠지만, 실제 개발을 진행하면서 여러 폴더를 움직이는 것이 아닌 하나의 폴더에서 구성된 트리들만을 보니 개발 피로도가 확실히 줄어들었다. 프로젝트를 진행하면서 정말 여러 변천사들을 겪는다. 이 구조가 좋은 구조라고 생각이 들었지만, 또 몇 년 후에는 더 좋은 구조라고 생각이 드는 것들이 또 새롭게 등장한다. 물론 많은 테크 기업들이 공감하는 구조도 물론 좋은 구조라고 할 수 있겠지만, 당장 내가 속한 조직에서 정말 적합한 구조를 채택하고 도입하는 것이 정말 좋은 구조가 아닐까라는 생각을 한번 더 하게 되었던 순간이었다.