[설계이론] Project Structure - 프로젝트 구성을 어떻게 설계해야 할까? (패키지 분리기준)

이 글은 김영한(우아한Tech)님의 '배달의민족 마이크로서비스 여행기' 세미나 영상과 76K의 Star 를 받은 'nodebestpractices' 를 참고하여 필자의 주관을 담아 정리한 글입니다.

따라서 이 포스팅을 보고 참고만 하시고 맹목적으로 보시지 않으셨으면 좋겠습니다.

 

가장 일반적인 프로젝트의 구성 

아래는 인터넷강의를 보면 가장 일반적으로 목격되는 프로젝트의 구조이다.
왼쪽은 김영한님의 강의용 프로젝트 구성이고, 오른쪽은 필자의 첫 Spring 프로젝트의 구성이다.

 

이러한 방식으로 프로젝트를 구성했을 때, 하나의 비지니스컴포넌트(예를 들면 '주문(Order)')에 변경사항이 생기게되면
주문(Order)과 관련된 파일들을 수정해야하는 경우가 생길 수 있는데, 그 파일들이 각각 다른 패키지(폴더)에 나눠져 있다는 특징이 있다.

 

 

 

Scaling 을 고려한 프로젝트의 구성 (From Git. nodebestpractices)

rluvaton 이라는 contributor 가 작성한 프로젝트 설계에 관한 내용을 읽어보면
중소규모 이상의 애플리케이션에서는 monolith를 지양하자는 의견을 피력하면서 MSA 설계에 대한 이야기를 덧붙이고 있다.

요약하자면 자급자족(self-contained)할 수 있는 비지니스 컴포넌트로 나누어 프로젝트를 구성하여 컴포넌트 사이에 경계를 둔다면
의존성 지옥을 방지하여 미래에 앱이 마이크로서비스로 전환할 수 있는 초석을 만들 수 있다고 이야기 한다.

그러니까, 프로젝트를 열었을 때 폴더(패키지)만 보고도 이것이 회계시스템인지, 주문시스템인지 알 수 있게 하자는 것이다.
그리고 최소한의 파일로만 구성해야한다고 말한다. (API, 서비스, 데이터 접근, 테스트 등) 

글로만 보면 이해가 안되기에 아래에 사진을 첨부한다.
왼쪽이 rluvaton 이 추구하는 컴포넌트기반 구성의 좋은 예시이며, rluvaton이 나쁜 예시로 제시한 기술적역할기반 구성의 나쁜 예시이다. 

https://github.com/goldbergyoni/nodebestpractices/blob/master/sections/projectstructre/breakintcomponents.md

 

 

스프링 프로젝트로의 적용

영한님의 '배달의민족 마이크로서비스 여행기' 우아콘 영상을 보고 난 후
rluvaton 의 글을 읽다보면 rluvaton 의 의견에 동의할 수 밖에 없다.

이유는 아래와 같다.

첫째, 컴포넌트로 분리하였기에 의존성 관리에 용이하다.
둘째, 마이크로서비스로의 마이그레이션 비용이 현저히 감소한다. 

하지만, 어떠한 시스템이 최소한의 파일구성으로 구성되지 못하거나 또는 프로젝트의 구성원들이 
이러한 구조에 익숙하지 않다고 가정한다면 무작정 이러한 기준을 강요할 수는 없는 노릇이다.

거기다 필자는 아직 자바진영에서는 신생아와 같기에 아직 잘 모르지만,
경험많은 분들이 자바프로젝트를 기술적역할기반으로 구성한데에는 이유가 있을거라고 생각한다.
(인터프리트언어와 컴파일언어의 차이일까 싶었지만, JS V8도 JIT컴파일 방식을 사용하기에 아닌 것 같다.
이 부분은 필자가 성장해서 꼭 이유를 밝혀내 재포스팅을 할 것이다.)

그래서 필자는 아래와 같이 구성하는게 기존 자바진영의 프로젝트 구성방식의 틀을 깨지않으면서 
동시에 Scaling에 용이하도록 하는 방법이라 생각한다.

 

 

 

 

 

# Reference

1. GitHub) nodebestpractices

GitHub - goldbergyoni/nodebestpractices: The Node.js best practices list (February 2022)

 

2. 우아콘) 김영한님의 '배달의민족 마이크로서비스 여행기'