프로젝트 계층 기반 패키지 → 기능 기반 패키지로 변경하기

※ 이 글은 주관적으로 작성된 글입니다. 틀리거나 추가적으로 보완할 내용이 있다면 댓글로 알려주세요.

+) 코드블럭에 텍스트 색이 적용 안 되어서 내용 이해가 안 되고 보기 불편하신 분들은 아래에서 글 봐주세욥

🚩 들어가며

프로젝트 초기에 우리 팀은 계층 기반 패키기 구조를 선택했었다. 아니 선택이라기보다는, 처음 개발 시에는 아키텍처라는 걸 고려하진 않았었다. 그냥 처음 스프링 프레임워크를 학습할 때 배웠던 controller, service, dao, domain 이 구조를 별 고민없이 계층형 패키지 구조(당시에는 이런 용어가 있는 줄도 몰랐다.) 그대로 쇼핑몰 프로젝트를 진행했었다.

이 구조대로 진행하다 우리 팀이 겪게된 문제가.. 관리자와 사용자 화면 기능을 분리할 것인가 말 것인가에 대한 논의를 하면서 처음으로 패키지 구조에 대해서 고민을 해보았다

1) 일단 첫번째로 관리자와 사용자 화면 기능을 분리할 것인가 말 것인가 → 각 기능의 성격이 너무 다르기 때문에 분리하기로 결정하였다.

BOS = Back Office = 관리자

FOS = Front Office = 사용자

전

controller
	ㄴ member
	ㄴ product
	ㄴ order
	ㄴ cs

후

controller
	ㄴ bos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
	ㄴ fos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs

2) 두 번째로 이걸 계기로 패키지 구조에 대해 여러 자료들을 찾아보고 고민을 해보았는데, 이 과정에서 계층 기반 패키지와 기능 기반 패키지라는 두 개의 주요 방법을 발견했다.

두 구조를 작성해 비교를 해보았을 때, 당시에는 오른쪽 방법인 기능 기반 패키지 방법을 적용했을 때 쓸데없이 controller, service, dao 패키지가 너무 많이 반복되는 것 같아 비효율적이어보였다.

그래서 왼쪽 방식인 계층형 방식을 선택해 프로젝트를 진행했었었다.

계층 기반 패키지

controller
	ㄴ bos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
	ㄴ fos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
service
	ㄴ bos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
	ㄴ fos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
dao
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs

기능 기반 패키지

bos
	ㄴ member
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ product
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ cs
		ㄴ controller
		ㄴ service
		ㄴ dao
fos 
	ㄴ member
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ product
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao
	ㄴ cs
		ㄴ controller
		ㄴ service
		ㄴ dao

그런데 프로젝트가 마무리되고 포트폴리오를 준비하면서 프로젝트 구조를 다시 살펴보니, 이때의 선택이 최선이었나하는 의문이 들었다. 당시의 선택 기준이 합리적이진 않아보았다. 위의 관점이라면 왼쪽인 계층 기반 패키지 구조도 쓸데없이 모듈(기능)이 반복되고 있는 것이 마찬가지였으니까.. 사실 당시에는 프로젝트 일정에 쫓겨 충분한 시간을 들여서 장단점을 비교하고, 명확한 기준으로 선택하지 못했었다. 이번 기회에 관련 공부도 하고 다양한 자료를 찾아보면서 장단점을 정확히 비교해 나만의 기준을 가지고 방법을 선택해보려고 한다.

🏗️ 계층 기반 패키지 vs. 기능 기반 패키지 장단점 비교

계층 기반 패키지

전통적인 수평 계층형 아키텍처이다. 기술적인 관점에서 해당 코드가 하는 일에 기반해 그 코드를 분할한다.

controller, service, dao, domain을 기준으로 각각 별도의 패키지에 속한다.

controller
	ㄴ OrderController.java
	ㄴ ProductController.java
service
	ㄴ OrderService.java
	ㄴ ProductService.java
dao
	ㄴ OrderDao.java
	ㄴ ProductDao.java
domain
	ㄴ OrderDTO.java
	ㄴ ProductDTO.java

📈 장점

코드의 재사용성이 높다.
계층 기반 패키지를 적용한다면 dao를 재사용할 수 있다.
현재 내 프로젝트는 계층 기반 패키지 아래에 관리자(bos)/사용자(fos)로 나뉘어져 있는데, 기능 중심으로 변경하게 될 경우에 bos/fos별 dao를 또 따로 만들어줘야 하며, 공통된 기능(ex. 회원 정보 조회, 재고수량 조회 등) 이 많음에도 불구하고 코드를 중복으로 작성해야 한다.
계층 기반 패키지
```
controller
	ㄴ bos
		ㄴ order
	ㄴ fos
		ㄴ order
service
	ㄴ bos
		ㄴ order
	ㄴ fos
		ㄴ order
dao
		ㄴ order # bos, fos 재사용 가능
```
기능 기반 패키지
```
bos
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao # 재사용 불가 중복 선언
fos 
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao # 재사용 불가 중복 선언
```

~~프로젝트에 이해가 낮아도 전체적인 구조를 빠르게 파악할 수 있다~~
많은 블로그들에서 계층형의 장점으로 설명하던데, 크게 공감되진 않았다.
웹개발 분야에서는 MVC 패턴이 거의 표준처럼 쓰이고 있고, 모르는 사람이 거의 없을 정도다. 그런데 이게 장점인지는 잘 모르겠다.
Java + Spring이 아닌 다른 프레임워크로 개발했을 때는 MVC 패턴 말고 다른 방법을 사용하는지는 모르겠지만 아무튼 그렇다.

📉 단점

낮은 응집도와 높은 패키지간의 결합도
기능 찾기/수정 시 여러 패키지를 왔다갔다해야 해야 하는 단점.
이 부분도 완벽하게 공감되지 않았다. 솔직히 개발하면서 IDE의 이동과 탐색 기능을 이용해 필요한 기능을 찾아내는데에 크게 어렵지 않았다. 하지만 내가 계층 기반 패키지 구조에 익숙해져 있어서 가지는 편견일 수도 있겠다는 생각도 들었다.
확실히 기능 기반 패키지로 변경을 하게 된다면 시각적으로 한눈에 파악이 가능하기도 하고 단축키로 타고타고 가는 게 아닌 패키지에서 파일들을 한번에 빠르고 편하게 열 수 있을 것 같긴한다.

위와 같은 이유로, 기능 삭제 시 여러 계층에 걸쳐있는 관련 파일을 모두 찾아서 삭제해야 한다.
모여있지 않다면 삭제 시 누락될 수도 있는 부분이기도 하고 한 곳에 모여있으면 명확하니 누락될 확률이 확실히 줄어들 것 같긴하다.

추후 서비스가 커지게 되어 모듈별로 분리되어 업무가 분담될 경우, 현 구조에서는 이슈가 생길 수 있다.
프로젝트의 현재 구조가 유지된다면 문제가 없겠지만, 장기적인 시야로 보았을 때 문제가 될 수 있다.

상위 패키지를 보았을 때, 어떤 기능들이 존재하는지 있는지 한눈에 파악되지 않는다.

기능 기반 패키지

서로 연관된 기능, 도메인 개념, Aggregate Root(도메인 주도 설계 용어라고 함)에 기반하여 수직의 얇은 조각으로 코드를 나누는 방식이다.

상위 구조가 controller, service, dao가 아니라 업무 도메인에 대한 이해를 제공한다.

아래 사진을 보면 계층 기반 패키지와 달리 orders라는 하나의 패키지에 묶여져있는 것을 볼 수 있다.

order
	ㄴ OrderController.java
	ㄴ OrderService.java
	ㄴ OrderDao.java
	ㄴ OrderDTO.java
product
	ㄴ ProductController.java
	ㄴ ProductService.java
	ㄴ ProductDao.java
	ㄴ ProductDTO.java

📈 장점

높은 응집도와 낮은 패키지간의 결합도
기능이 패키지 단위로 모여있기 때문에 검색/수정/삭제가 쉽고 간단한다.

추후 서비스가 커지게 되어 모듈별로 분리하게 될 경우 분리가 쉽다.

상위 패키지를 보았을 때, 어떤 기능들이 존재하는지 있는지 한눈에 파악이 가능하다.

효율적인 협업
기능 단위로 나누어 작업할 때 유리하다. 같은 패키지 내 파일을 수정할 확률이 낮아져 git 충돌 가능성이 줄어든다.

범위 최소화
모든 기능이 한 패키지 내에 존재하기 때문에 접근 제어자를 public에서 default나 protected로 좁혀 캡슐화의 이점을 더욱 활용할 수 있다.

📉 단점

코드의 재사용성이 떨어진다. 각 모듈에 중복된 코드가 발생할 가능성이 높다.
상세한 이유는 ‘계층 기반 패키지’의 장점 부분에 있으니 참고

💡응집도: 모듈에 포함된 내부 요소들이 연관돼 있는 정도

💡결합도: 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많이 알고 있는지

✔️ 선택 기준

프로젝트가 현재 구조로 계속 유지되고 발전될 가능성이 없다면 계층 기반 패키지로 계속 가도 문제가 없다. 하지만 이 프로젝트가 실제로 운영되는 서비스라고 가정한다면 서비스가 성장하게되면서 업무가 모듈 단위로 나뉘게 될 가능성이 높아진다.

이런 이유로 기능 기반 패키지 구조로 변경을 하기로 결정하였다. 비록 현재 사이트 프로젝트 수준에서는 계층형 구조가 문제는 없지만, 실제 서비스라고 가정을 해보고 다양한 시나리오를 고려해보고 실제로 적용해보는 것은 좋은 경험이 될 것 같았다.

🔥 계층 기반 패키지 → 기능 기반 패키지 변경 과정

1) ‘기능 단위’의 범위가 어디까지일까?

기능 기반 패키지로 변경하기로 결정한 후, 구조를 그려보는 과정에서 제일 먼저 의문지 들었던 지점이 ‘기능 단위’의 범위였다.

현재 내 프로젝트는 계층형이지만, 1단계를 계층으로 2단계를 기능(모듈) 단위로 나누었었다. 이때 이 기능(모듈)을 DB 모델링 시 도출했던 ‘주제영역’을 기준으로 했었는데, 주제영역은 member, product, order, cs 이렇게 4개였었다.

기존의 계층형(1단계) 모듈형(2단계) 방식

controller
	ㄴ fos
		ㄴ member
			ㄴ DlvAddrController.java
			ㄴ LoginController.java
			ㄴ RegisterController.java
		ㄴ product
		ㄴ order
			ㄴ CartController.java
			ㄴ OrderController.java
		ㄴ cs

기능의 범위와 정의가 모호하니 어떤 기준으로 분리할 것인지 결정하기가 어려웠다.

장바구니와 주문 기능으로 예를 들어보자면, 이전 구조에서는 2단계에서 기능형으로 나누었을 때 주제영역을 기준으로 했었기 때문에 order 패지키에 장바구니와 주문이 같이 존재했었다.(왼쪽 참고) 하지만 정말 말 그대로 ‘기능’단위로 분리를 하게되면 오른쪽처럼될텐데, 장바구니와 주문 기능은 엄연히 다른 기능이긴 하지만 밀접하게 연관되어있다. 하지만 이걸 너무 세분화해서 오른쪽처럼 분리해버리면 관리와 개발 측면에서 오히려 독이 될 것 같았다.

‘기능’의 기준을 ‘주제영역’으로 가기로 하고 order 패키지 안에 주문 기능과 장바구니 기능을 포함시키기로 해서 왼쪽으로 가기로 했다.

주제영역단위

order
	ㄴ controller
		ㄴ OrderController.java
		ㄴ CartController.java
	ㄴ service
		ㄴ OrderService.java
		ㄴ CartService.java
	ㄴ dao
		ㄴ OrderDao.java		
		ㄴ CartDao.java
	domain
		ㄴ OrderDTO.java
		ㄴ CartDTO.ja

기능단위

order
	ㄴ OrderController.java
	ㄴ OrderService.java
	ㄴ OrderDao.java
	ㄴ OrderDTO.java
cart
	ㄴ CartController.java
	ㄴ CartService.java
	ㄴ CartDao.java
	ㄴ CartDTO.java

그래서 이번 프로젝트의 기능 단위는 주제영역 단위라고 할 수 있을 것 같다.. 물론 서비스가 더 커지면 주제영역이 아닌 핵심 엔티티 단위로 쪼개 구성을 하게 될 것 같다.

하지만 왼쪽으로 가게되면 기능 기준 패키지 적용 시 얻을 수 있는 public에서 default나 protected로 변경했을 때의 캡슐화의 이점은 얻지 못하지만 개발 편의성이 우선이라고 생각했다.

2) 관리자와 사용자 코드의 분리

<기존 구조>

1단계: 계층

2단계: bos(관리자)/fos(사용자)

3단계: 기능

만약 사용자와 관리자 백오피스가 아예 분리될 수도 있는 케이스를 고려했을 때 현재 구조는 관리자와 사용자의 코드가 계층을 기준으로 묶여있기 때문에 이 구조는 좋지 않아보였다.

계층형 방식

controller
	ㄴ bos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
	ㄴ fos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
service
	ㄴ bos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs
	ㄴ fos
		ㄴ member
		ㄴ product
		ㄴ order
		ㄴ cs

그래서 관리자와 사용자의 코드를 제일 최상위 수준에서 아예 분리하기로 했다

<변경 구조>

1단계: bos(관리자)/fos(사용자)

2단계: 기능

3단계: 계층

위 기준을 통해 변경된 패키지 구조는 아래와 같다.

변경 전

syusyu
├── controller
│   ├── bos
│   │   ├── cs
│   │   │   └── mypage
│   │   ├── dashboard
│   │   ├── member
│   │   ├── order
│   │   ├── product
│   │   └── statistics
│   └── fos
│       ├── cs
│       │   └── mypage
│       ├── member
│       ├── order
│       └── product
└── service
    ├── base
    │   ├── order
    │   └── product
    ├── bos
    │   ├── cs
    │   │   └── impl
    │   ├── member
    │   │   └── impl
    │   ├── order
    │   │   └── impl
    │   ├── product
    │   │   └── impl
    │   └── statistics
    │       └── impl
    └── fos
        ├── cs
        │   └── impl
        ├── member
        │   └── impl
        ├── order
        │   └── impl
        └── product
            └── impl

변경 후

syusyu
├── bos(관리자)
│   ├── cs
│   │   └── mypage
│   │       └── controller
│	  │   │   └── service
│		│   │       └── impl
│   ├── member
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   ├── order
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   └── product
│       ├── controller
│       └── service
│           └── impl
├── fos(사용자)
│   ├── cs
│   │   └── mypage
│   │       ├── controller
│   │       └── service
│		│   │       └── impl
│   ├── member
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   ├── order
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   └── product
│       ├── controller
│       └── service
│           └── impl

3) DAO의 거취는…?

위처럼 분리하고 다 끝난 줄 알고 좋아했으나..^^ DAO라는 문제가 남아있었다.

기존에 controller와 service는 원래부터 사용자와 관리자에서 사용하는 기능이 워낙 달라 애초에 파일을 다르게 사용하고 있었는데, dao는 사용자와 관리자 기능이 공통으로 사용하고 있어 이부분에서 어떻게 해야 할지 고민이 되었다..

DTO는 당연히 공통으로 써야 하기 때문에 이부분은 고민거리가 아니었지만.. dao가 문제…😢

기능형의 단점 중에 코드의 재사용성이 떨어진다는 게 있었는데 이게 그거구나 하고 확 와닿았다.

syusyu
├── bos
│   ├── cs
│   │   └── mypage
│   │       └── controller
│   ├── member
│   │   ├── controller
│   │   └── service
│   ├── order
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   └── product
│       ├── controller
│       └── service
│           └── impl
├── fos
│   ├── cs
│   │   └── mypage
│   │       ├── controller
│   │       └── service
│   ├── member
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   ├── order
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   └── product
│       ├── controller
│       └── service
│           └── impl
├── dao
│   ├── cs
│   │   └── impl
│   ├── member
│   │   └── impl
│   ├── order
│   │   └── impl
│   └── product
│       └── impl
├── domain
│   ├── cs
│   ├── member
│   ├── order
│   │   └── request
│   └── product
├── common
│   ├── config
│   ├── core
│   ├── util
│   └── web
│       ├── filter
│       ├── interceptor
│       └── listener

오른쪽처럼 가게되면 완벽하게 이상적인(?) 기능 기반 패키지 구조이지만, DAO에는 비즈니스 로직이 아닌 CRUD 코드만 존재하기 때문에 관리자와 사용자에서 사용되는 공통 부분이 많아 공통으로 사용했었다.

그런데 기능 기반 패키지 구조를 적용하려고 DAO를 또 각각 중복으로 코드를 작성하는 게.. ~~귀찮은 것도 있었지만~~ 무엇보다도 유지보수성이 최악이었다.

계층 기반 패키지

controller
	ㄴ bos
		ㄴ order
	ㄴ fos
		ㄴ order
service
	ㄴ bos
		ㄴ order
	ㄴ fos
		ㄴ order
dao
		ㄴ order # bos, fos 재사용 가능

기능 기반 패키지

bos
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao # 재사용 불가 중복 선언
fos 
	ㄴ order
		ㄴ controller
		ㄴ service
		ㄴ dao # 재사용 불가 중복 선언

그래서 DTO와 마찬가지로 DAO는 common 패키지에 넣어 공통으로 사용하기로 결정하였다. 아래처럼 제일 큰 구분 단위인 bos, fos와 같은 뎁스에 common 폴더를 생성하고 core 패키지 안에 DAO와 domain(DTO)를 넣어주었다.

이렇게!

.
├── bos
├── common
│   ├── core
│   │   ├── dao
│   │   │   ├── cs
│   │   │   │   └── impl
│   │   │   ├── member
│   │   │   │   └── impl
│   │   │   ├── order
│   │   │   │   └── impl
│   │   │   └── product
│   │   │       └── impl
│   │   └── domain
│   │       ├── cs
│   │       ├── member
│   │       ├── order
│   │       │   └── request
│   │       └── product
└── fos

4) bos와 fos가 공통으로 사용하는 service 코드

하지만 아직 남은 문제가 또 있었는데..

기존에 base라고 관리자와 사용자 화면에서 공통으로 사용하던 service 코드를 공통화를 해두었던 부분이 문제가 되었다. service의 base 부분이 갈 길을 읽고 있었던 것…

.
├── bos
├── fos
└── service
    └── base
        ├── order
        └── product

이런 코드들이 있었음

/**
 * 각 주문의 주문상태를 업데이트하고 주문상태이력을 추가한다.
 * 각 주문에 대해서 순차적으로 주문상태를 업데이트하고 주문상태이력을 추가한다.
 *
 * @param ordDtlNoList 주문상태를 업데이트할 주문상세번호를 담은 리스트
 * @param mbrId        사용자 ID
 * @param ordStus      변경될 주문상태
 * @throws Exception 주문상태 업데이트 또는 주문상태이력 추가 도중 발생할 수 있는 예외
 * @author min
 * @since 2023/07/31
 */
@Transactional(rollbackFor = Exception.class)
public void processUpdateOrderStatus(List<Integer> ordDtlNoList, int mbrId, String ordStus) throws Exception {
    for (Integer ordDtlNo : ordDtlNoList) {
        boolean isSuccess = updateOrderStatusAndAddHistory(ordDtlNo, mbrId, ordStus);

        if (!isSuccess)
            throw new Exception("주문 번호 " + ordDtlNo + "의 주문 상태 변경 처리에 실패하였습니다. 주문 상태가 변경되거나 추가된 주문 이력의 수가 1이 아닙니다.");
    }
}

얘도 DAO와 마찬가지로 일단 공통쪽에 넣어두기로 했다. 추후 확장성을 위해 구조를 변경하고 있는데 계속 공통 부분에 대한 이슈가 계속 생기는 것 같다.

.
├── bos
│   ├── cs
│   ├── dashboard
│   ├── member
│   ├── order
│   ├── product
│   └── statistics
├── common
│   ├── config
│   ├── core
│   │   └── base
│   │       ├── order
│   │       └── product
│   ├── dao
│   │   ├── cs
│   │   │   └── impl
│   │   ├── member
│   │   │   └── impl
│   │   ├── order
│   │   │   └── impl
│   │   └── product
│   │       └── impl
│   ├── domain
│   │   ├── cs
│   │   ├── member
│   │   ├── order
│   │   │   └── request
│   │   └── product
│   ├── util
│   └── web
│       ├── filter
│       ├── interceptor
│       └── listener
└── fos
    ├── cs
    ├── member
    ├── order
    └── product

5) common 디렉토리 구조 변경

기존 common 패키지에 이미 많은 요소들이 존재했는데, DTO, DAO, base를 common 패키지로 옮겨오면서 안 그래도 뭐가 많은 common 패키지가 더 복잡해지게 되었다. 그래서 새로운 분류 기준을 통해 구조를 변경하기로 했다.

HTTP 요청의 전처리 및 후처리와 관련된 filter, interceptor, listener는 'web'이라는 새로운 패키지로 분류했고 ‘core’라는 패키지를 생성해 dao와 domain을 위치시켰다.

변경 전

syusyu
├── bos
│   ├── cs
│   ├── dashboard
│   ├── member
│   ├── order
│   ├── product
│   └── statistics
├── common
│   ├── dao
│   ├── domain
│   ├── base
│   ├── config
│   ├── filter
│   ├── interceptor
│   ├── listener
│   └── util
└── fos
    ├── cs
    ├── member
    ├── order
    └── product

변경 후

syusyu
├── bos
│   ├── cs
│   ├── dashboard
│   ├── member
│   ├── order
│   ├── product
│   └── statistics
├── common
│   ├── config
│   ├── core
│   │   ├── base
│   │   ├── dao
│   │   └── domain
│   ├── util
│   └── web
│       ├── filter
│       ├── interceptor
│       └── listener
└── fos
    ├── cs
    ├── member
    ├── order
    └── product

🔚 최종 변경 구조

여러가지 상황을 고려하다보니 결과적으로 완벽한 기능 기반 패키지는 아니게 완성되었다.

변경된 것 중에 핵심은 관리자와 사용자의 코드를 완전히 분리하였고, 기능 기반 패키지를 도입해 구조만 보아도 어떤 기능이 존재하는지 한눈에 파악할 수 있게 되었다.

<변경 전>

syusyu
├── controller
│   ├── bos
│   │   ├── cs
│   │   │   └── mypage
│   │   ├── dashboard
│   │   ├── member
│   │   ├── order
│   │   ├── product
│   │   └── statistics
│   └── fos
│       ├── cs
│       │   └── mypage
│       ├── member
│       ├── order
│       └── product
└── service
    ├── base
    │   ├── order
    │   └── product
    ├── bos
    │   ├── cs
    │   │   └── impl
    │   ├── member
    │   │   └── impl
    │   ├── order
    │   │   └── impl
    │   ├── product
    │   │   └── impl
    │   └── statistics
    │       └── impl
    └── fos
        ├── cs
        │   └── impl
        ├── member
        │   └── impl
        ├── order
        │   └── impl
        └── product
            └── impl
├── dao
│   ├── cs
│   │   └── impl
│   ├── member
│   │   └── impl
│   ├── order
│   │   └── impl
│   └── product
│       └── impl
├── domain
│   ├── cs
│   ├── member
│   ├── order
│   │   └── request
│   └── product

├── common
│   ├── config
│   ├── filter
│   ├── interceptor
│   ├── listener
│   └── util

<변경 후>

syusyu
├── bos
│   ├── cs
│   │   └── mypage
│   │       ├── controller
│   │       └── service
│   │           └── impl
│   ├── dashboard
│   │   └── controller
│   ├── member
│   │   ├── controller
│   │   └── service
│   ├── order
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   ├── product
│   │   ├── controller
│   │   └── service
│   │       └── impl
│   └── statistics
│       ├── controller
│       └── service
│           └── impl
└── fos
    ├── cs
    │   ├── controller
    │   ├── mypage
    │   │   ├── controller
    │   │   └── service
    │   └── service
    │       └── impl
    ├── member
    │   ├── controller
    │   └── service
    │       └── impl
    ├── order
    │   ├── controller
    │   └── service
    │       └── impl
    └── product
        ├── controller
        └── service
            └── impl
├── common
│   ├── config
│   ├── core
│   │   ├── base
│   │   │   ├── order
│   │   │   └── product
│   │   ├── dao
│   │   │   ├── cs
│   │   │   │   └── impl
│   │   │   ├── member
│   │   │   │   └── impl
│   │   │   ├── order
│   │   │   │   └── impl
│   │   │   └── product
│   │   │       └── impl
│   │   └── domain
│   │       ├── cs
│   │       ├── member
│   │       ├── order
│   │       │   └── request
│   │       └── product
│   ├── util
│   └── web
│       ├── filter
│       ├── interceptor
│       └── listener

🔜 나가며

프로젝트 패키지 구조는 어떤 공식처럼 절대적인 정답은 없다. 이것 뿐만 아니라 어떤 것이든.. 현재 회사의 상황, 비용 등을 고려해 무조건 Best Practice가 아닌 가장 효율적이며 리소스 투입이 낮은 해결책을 선정해야 한다.

현재 프로젝트 상황을 고려해 정말 완벽한 기능 기반 패키지를 도입하는 것이 아닌 유지보수성을 고려해 공통화 할 것은 하고 적당히 타협하는 것도 중요하다는게 내 의견이다.

이번 프로젝트에서는 계층형 구조와 기능형 패키지 구조를 모두 적용해보았다. 현재 상황에서는 사실 변경이 필요하지 않았지만, 실제 서비스된다고 가정하고 확장성을 고려해 기능형 패키지 구조로 변경을 시도해보았다. 덕분에 패키지 구조에 대해 깊게 고민할 수 있는 학습 소스가 되었다.

그리고 bos, fos를 제일 큰 카테고리로 분리한 건 정말 잘한 선택이었다고 생각한다. 비록 현재 당장은 모듈 단위로 분리를 고려할 일은 없지만, 서비스가 커지게 된다면 이런 구조가 중요해질 것 같다.

클린 아키텍처에서도 패키지 구조에 대해서 언급하고 있는 부분이 있어 그 부분도 읽어보며 계층형, 기능형 말고도 '포트와 어댑터', '컴포넌트 기반 패키지' 같은 방법에 대해서도 알게 되었지만.. 솔직히 읽으면서 뭔소린지 이해가 잘 안 됐다. 이 부분은 추가로 좀 더 찾아보고 공부를 해야 될 것 같다.

초기 단계, 특히 설계에 해당하는 것들은 정말 신중한 논의가 필요하구나라는 생각을 많이 하게 됐다. 뒤늦게 뒤짚어 엎으려니 정말 너ㅜㅁ 힘들었다. 사이드프로젝트라 엄청난 큰 부담이 없었지만.. 실무였다면 변경을 도입하는 과정에서 기존 기능에 문제가 생기면 고객의 신뢰를 잃게되는 문제가 발생할 수 있기 때문에 신경써야 할 것도 정말 많겠지… 여기서도 테스트 코드의 중요성을 깨닫게 되는군..

주저리주저리
패키지 구조에 대해서 깊게(?) 고민하면서 느낀 점은.. 이런 경험들이 하나둘 쌓여서 나를 성장시키는 것 같다. 과정에서 재밌기도 했고 ㅋㅋ 이때 아니면 언제 이런 고민을 시간들여서 깊게 해보겠어?라는 생각을 많이 했다.
사실 빨리 포트폴리오 만들어야 하는데 포폴만들다 패키지 구조에 물음표가 생겨서 3일째 풀타임으로 구조 변경하고 글쓰는데 시간을 다 보내서 이거 맞나싶긴햇는데.. 취준 기간을 너무 조급하게 여기지 말고 내가 하고 싶은 거 다 해보자!! 예전에 교수님이 조언해주신 이제 나이가 깡패라는 말을 하기엔 시기가 많이 지났지만 ㅋㅋㅋ 그래도 아직도 어리니까 괜찮다고 너무 조급하게 생각하지 마라는 H님의 조언을 뇌에 새기자…
입사하게되면 내 삶의 메인은 이제 취준과 공부가 아닌 업무로 바뀌게 될텐데 제한된 시간 때문에 깊게 파고들어 공부하고 싶은 부분을 그냥 넘어가야 할 때도 있을 것이다. 전회사에서 했던 고민을 또 하게되겠지.. 취준하면서 너무 자괴감에 빠져있지말고 나에대해 알아가는 시간이라고 생각하고 하고 싶은 거 다 해보자!
취준 시작한지 한달밖에 안 됐는데 좋은 결과를 바라는 게 어리석은 거 좀 늦어도 괜찮아~!!
반복에 지치지 않는 자가 승리한다! 꾸준히 하다보면 좋은 결과가 찾아올 것

ㅇ ㅏ… 그리고 N2T 코드블럭안에 있는 텍스트 색은 변경이 안 되네.. 그리고 캡션도 ㅜㅜ 강조할 부분 다 표시해놨었는데 아쉽다