[자바 스프링] 멀티 모듈 설계

문제 발단

당시 SellWe 프로젝트를 기획할 때, HTTP 통신과 웹소켓(WS) 통신을 사용할 계획은 있었지만 서버의 구성과 설계적인 측면을 고려하지 않았습니다. 결국 프로젝트에서는 이러한 기능들을 하나의 서버에 넣기로 결정하였습니다. 

그러나 웹소켓의 특성상 지속적인 연결로 인해 더 많은 리소스를 소모하게 되어 서버의 안정성을 위해 다른 대안을 고려하게 되었습니다.

 

 

 

첫 번째 대안은 Nginx를 이용한 로드 밸런싱 기술을 사용하는 것이었습니다. 하나의 서버에 두 기능을 구현하고 Nginx를 통해 클라이언트를 분배하는 방식을 고안했습니다.

 

하지만 Nginx와 로드 밸런싱에 대한 지식 부족으로 다른 대안을 찾아보게 되었습니다.

 

 

 

 

세 번째 대안은 프로젝트를 기능별로 나누어 개발하고, 각각의 기능을 다른 서버에 배포하는 것이었습니다. 이렇게 하면 서버가 기능별로 분리되어 코드 수정 및 에러 디버깅이 용이하며 성능적인 측면에서도 유리하다고 판단했습니다.

 

 

 

 

문제발생

그러나 프로젝트를 개발하는 과정에서 큰 어려움이 발생했습니다. 스프링 시큐리티와 멤버 엔티티 등 몇몇 컴포넌트가 두 프로젝트에 중복해서 사용되었고, 한 프로젝트에서 수정되면 다른 프로젝트에서도 수정이 필요한 상황이 발생했습니다.

 

시간적인 제약으로 인해 멀티모듈의 학습을 뒤로 한채 어려움을 감수하며 프로젝트를 완료하였지만, 이러한 문제를 해결하기 위해 나중에라도 멀티 모듈에 대해 알아보기로 했습니다. 

 

 

 

 

 

문제해결

멀티 모듈은 여러 독립적인 프로젝트를 하나의 프로젝트로 묶어 모듈화하는 구조를 의미합니다. CORE 모듈에 중복 컴포넌트를 모아놓고 웹소켓 및 HTTP API 모듈로 나누는 방식을 선택했습니다. 그러나 CORE 모듈의 범위에 대한 의문이 생겨, 비즈니스 로직의 중복 코드도 CORE 모듈에 포함해야 할지에 대한 고민이 있었습니다.

결국 스프링 시큐리티와 엔티티 등 핵심적인 부분만을 CORE 모듈에 포함시키기로 결정한 뒤, 멀티 모듈을 도입하여 문제를 해결하였습니다. 이러한 설계 방식이 효율적인지에 대해서는 아직 확실하지 않지만, 일단은 이와 같은 방법으로 멀티 모듈을 구현하게 되었습니다.

 

 

 

마무리

결론적으로, SellWe 프로젝트의 초기 기획에서는 기능 구현에만 초점을 두었지만, 시간이 지나며 서버 구성과 설계적인 측면의 중요성을 깨닫게 되었습니다. 다양한 대안을 고려하면서도 어려움에 부딪히며 프로젝트를 발전시키는 데에 많은 노력을 기울였습니다.

 

멀티 모듈을 도입한 결과, 중복 코드와 컴포넌트 관리에 대한 어려움을 극복할 수 있었으며, 프로젝트 기획에서 기능 구현 뿐만 아니라 설계적인 측면도 고려해야 한다는 것을 깨닳게 되었습니다. 

 

 

 

구성 정리

기존의 구성

• Websocket 서버
  • Websocket 통신
  • Websocket 통신과 관련된 기타 HTTP 통신 기능
• HTTP 서버
  • HTTP 통신

 

 

멀티 모듈 적용

• CORE 서버
  • 통합 스프링 시큐리티
  • 통합 엔티티
• Websocket 서버
  • Websocket 통신
  • Websocket 통신과 관련된 기타 HTTP 통신 기능
• HTTP 서버
  • HTTP 통신

 

 

 

기타 자료

참고 블로그 

https://cjw-awdsd.tistory.com/55

https://techblog.woowahan.com/2637/

 

적용된 멀티 모듈

https://github.com/Mason3144/seb44_main_019/tree/main/backend