[프로젝트 회고] 파일 구조

프로젝트를 다루면 규모가 커짐에 따라 파일의 역할에 따라 패키지화 한다. 나는 내 프로젝트를 아래와 같은 구조로 나누었다.

withfriend파일구조도

구조도를 보면 알겠지만, 파일이 구현하고 있는 기능별(유저, 결제)로 구조화를 하기보다는 파일이 구현하고 있는 역할(api 호출, 비즈니스 로직)을 먼저 나누고 그 안에서 기능별로 패키징하는 구조를 이루었다. 기존에 경험한 프로젝트들은 기능 -> 역할의 구조로 프로젝트를 다뤘는데 이번에는 다른 방법을 사용해 보았다.

 

사실 처음에는 내가 설계한 기능들을 다 구현했을 때 최종 모습이 많은 로직과 파일들이 개발될지 모르고, 가벼운 마음으로 프로젝트를 구조화 했다. 그러나 기능을 하나하나 구현하다 보니 생각할게 너무 많았고, 생각들을 모두 코드로 적어 내려가고 구조화 하다보니 처음 생각했던 것보다는 규모가 거대해졌다. 

 

여기서 반전이 하나 더 존재하는게, 처음에 단순한게 시작한 파일의 역할 -> 기능의 구조가 규모가 작은 프로젝트에서 효율적이고 규모가 커질수록 비효율적이라 생각했는데, 막상 프로젝트를 진행하며 예상했던 것보다 규모가 커져도 프로젝트를 관리하기 편안했다.

 

즉, 어디서 생긴지 모를 개발자로서 편견은 실제 내가 직접 구현, 경험을 하기 전까지 틀린 생각일 수도 있겠다 라는 좋은 경험을 한것 같다.

 

먼저 이 전에 내가 경험했던 기능 -> 역할의 구조로 프로젝트를 관리했을 때의 장단점은 다음과 같다.

 

장점

• 특정 기능을 구현할 때 해당 기능과 관련된 파일들이 하나의 패키지 내부에 전부 들어있기 때문에 그 기능을 개발할 때 편리하다.
• 예를 들어, 오늘 결제와 게시글에 관련된 기능을 개발할 때, board 패키지 내부에서 다양한 파일들을 관리할 수 있어서 편리하다.

단점

• 기능을 담당하는 패키지 내부에 반복되는 구조가 불편할 수 있다.
• 예를 들어, user 패키지 내부 (controller, service, entity ..) 파일들이 board, payment 패키지 내부에도 반복된다. 이는 패키지화 되는 기능이 많아지면 많아지는 대로 반복이 된다.

다음 역할 -> 기능의 구조의 장단점

 

장점

• 파일의 역할별로 구조화했기 때문에, 본 프로젝트의 경우 파일을 (controller, service, repository, dto, entity)의 구조로 나누었다, 특별한 경우를 제외하고 그 이외에 패키지가 추가로 생기지 않는다.
• 예를 들어, 기능별로 구조화 했을 때는 기능이 추가될 때마다 패키지가 생겼지만 이 경우 기능이 생겨도 초기 구조에 패키지가 추가로 생기지 않는다.

단점

• 그러나 역할 내부마다 동일하게 기능별로 패키지들이 중복된다.
• 예를 들어, controller, service 패키지 내부에 (user, board, payment ..) 등의 구조가 반복될 확률이 높다.

 

최종적으로 내 느낌을 정리하자면 역할을 초기 구조로 삼고 프로젝트 구조를 구성하는게 나에게는 더 맞는거 같다. 우선 두 방식의 가장 큰 차이점으로 초기 구조가 동적인가 정적인가라고 생각하는데 필자의 경우 경험해보니 초기 구조가 정해져 큰 변동이 없는 쪽이 더 잘 맞았다. 역할 우선 구조는 프로젝트에서 사용될 역할들 (controller, service, entity ..등) 이외에 패키지가 생기는 경우가 드물지만, 기능을 우선으로 구조화하면 기능이 추가될 때마다 기능의 패키지를 초기 구조에 추가해야 하므로 불편했다. 아래 깃허브 디렉토리 구조를 보면 차이를 알 수 있다.

 

타 프로젝트 기능 중심 파일 구조

withfriend 역할 중심 파일 구조