📌 개요
프로젝트에 사용할 기술스택과 마이크로서비스의 구조가 어느정도 확정되었으니, 이제 프로젝트를 어떻게 관리할지, 팀과 협업한다면 어떠한 식으로 진행할지 등을 정해보자.
특히나, 이러한 것들은 실제로 프로젝트를 하며 몸소 느꼈던 점들이 많이 반영되기 때문에, 뭔가 비효율적인데? 싶은 것들은 항상 이유가 있었다..
아무튼 Git 부터 살펴보자
1️⃣ Git Repository
깃 레포지토리 구조를 모노레포 방식으로 사용하기로 했다.
이유는 쉬운 통합 관리와 이후 쿠버네티스와의 연계를 쉽게 하기 위해서이다.
특히나, 쿠버네티스를 사용하는 과정에서 여러개의 마이크로서비스가 각자의 레포지토리를 갖게 된다면, 각 레포지토리에서 전부 젠킨스에 웹훅을 걸어줘야하는.. 매우 귀찮은 일들이 발생하므로 개인적으로는 모노레포를 사용하는 것을 조금 선호하는 편이다.
이는 나만의 생각이 아니고, 실제 토스 기술 블로그를 참고하면 모노레포를 통해 총 200개의 마이크로서비스를 관리하고 있는 것을 확인할 수 있다.
2️⃣ 멀티 모듈
나의 옛날 글에서 보았듯이 멀티모듈은 굉장히 효율적인 방법이다.
특히나, 마이크로서비스가 서로 FeignClient를 통해 데이터를 교환한다면 해당 API의 DTO들을 전부 각 마이크로서비스가 갖고 있어야되는 정말 불편하고 짜증나는 상황이 발생한다.
실제로 나는 특화프로젝트에서 이렇게 진행했었는데, 코드 복붙을 한번에 할 수가 없었다... 추가적으로 가져와야할 DTO들이 너무나도 많았으며, 이 DTO의 버전을 관리하는 것이 매우 힘들었다. (팀원이 살짝만 수정해도 다른 마이크로서비스에서 터져버림)
그래서 이 프로젝트에서는 멀티모듈을 도입하기로 했다.
구현 방법은 간단하다.
먼저 그냥 스프링부트 프로젝트를 하나 판 후에
src를 지워버린다
이후 프로젝트를 우클릭하여 모듈을 생성한다.
적당히 만들어서 넣는다
서브모듈의 setting.gradle을 지운다.
이유는 gradle이 최상단의 setting.gradle을 읽고 하나의 프로젝트로 인식하기 위해서다.
서브모듈에서도 setting.gradle이 존재한다면 별개의 프로젝트로 인식한다고 한다.
이제 최상단 setting.gradle로 와서 서브모듈의 이름을 include 시켜주면 모듈 생성이 끝이 난다.
마지막으로 각 프로젝트의 build.gradle에 해당 구문을 추가해주면 끝이나는데
bootJar {
enabled = true
}
jar {
enabled = false
}여기서 bootJar는 실제로 실행할 서버 라고 생각하면 된다. Spring Boot로 실행 가능한 JAR 파일을 생성할지 여부를 결정하는 것이다.
jar는 해당 모듈을 라이브러리로 만들 것인지를 물어보는 것이다. 일반적인 JAR 파일(라이브러리 JAR)을 생성할지 여부를 결정하는 것이다. 즉, 실행 가능한 JAR이 아닌 라이브러리 형태의 JAR 파일만 생성된다.
➕ 만약 gradle 빌드 과정에서 이러한 에러가 나타난다면
tasks.register("prepareKotlinBuildScriptModel"){}build.gradle 마지막에 해당 구문을 넣어주자.
저 에러가 발생하는 이유를 많이 찾아봤는데, 일단 gradle은 build.gradle.kts 파일이 있다면 Kotlin DSL로 시도하고 없다면 Groovy DSL로 시도한다.
그러나 인텔리제이 내부 오류로 인해 서브모듈을 실행할 때, 코틀린으로 먼저 시도하고 이후에 다시 Groovy DSL로 시도한다. (해당 오류는 2021년에도 식별되었으나, 인텔리제이 측에서 재현이 불가능하단 이유로 패싱되었다..)
따라서, 그냥 Kotlin DSL이 오류를 내지 않게 해당 구문을 추가하여 스킵하도록 하자.
🔚 최종 구조
일단 대충 이정도로 만들어봤다.
물론 알림서비스와 같은 모듈도 추가되어야 하지만 일단은 이 선에서 끝내고 추후에 추가하고자 한다.
