MSA에서 공통코드 관리하기

🔍 목적, 배경

내가 있었던 팀의 백엔드는 MSA 구조를 가지고 있다. 많은 곳에서 레포까지 나누기도 하지만, 우리팀은 모듈만 나누어 멀티모듈 구조로 운영하고 있다.

여러 모듈을 관리하다 보니 중복코드가 발생할 수 밖에 없었고, 중복코드 관리의 필요성을 느끼고 있었다.

중복코드가 뭐가 있냐? 싶을 수 있지만, security 설정, 인증필터, swagger 설정 등 모든 모듈에서 적용되는 설정부터 시작해서
거래소 조회 기능, 파일 업로드 기능, 엑셀 생성 및 다운로드 기능 등 기능 단위로 중복 코드가 발생했다.

중복코드는 많아질수록 기능을 수정할 때 모든 모듈에 들어가서 확인을 해야하기 때문에 수정을 놓치기 쉽다. 하나라도 놓치면 장애로 이어질 수 있는 폭탄과 같은 존재이다! 💣

 

중복 코드를 관리해야할 필요성은 충분히 느낀 것 같고, 그럼 어떻게 관리하는게 좋을까?

1. Core 모듈
   multi module 프로젝트에 core 모듈을 두는 것에 대한 찬반 논란이 꽤 있는 것으로 알고 있다.
   통합어드민을 구축할 때도 마찬가지로 많은 논쟁과 토론이 있었지만, 결국 core 모듈을 만들기로 했었다.
   
   그로 인해 우리팀은 core 모듈을 이미 가지고 있었고, 모든 모듈에 공통적으로 적용되어야만 하는 핵심적인 기능들만 모아두었다.
   (core 모듈에 코드가 추가되는 PR이 올라오면, 그 날은 토론의 장이 열린다 🤣)
   
   그러나 엑셀 생성과 같은 기능을 core에 넣기는 부담스럽다고 생각했다. 엑셀의 기능이 바뀐다고 모든 모듈이 영향을 받아야하나? 라는 생각을 해보면 모든 사람들이 그건 좀.. 이런 생각을 할 것이다.
   
   그럼 핵심 기능을 제외한 공통 코드는... 어디에 넣지...?
   
   
2. Common 모듈
   common 모듈은 이름 그대로 공통되는 코드를 모으는 모듈이다.
   내가 생각했던 사용 예시는 다음과 같다.
   
   멀티 모듈에서는 모듈끼리 통신이 필수적이기 때문에, User 모듈 호출에 사용할 VO는 다른 모듈에서도 공통적으로 사용할 법 하다.
   그럼 UserVO 클래스는 common에 넣어야지~
   
   그러나 이런 모듈이 생기게 되면 굉장히 위험한 일이 발생한다. "공통코드 모음"이기 때문에 모든 모듈은 common 모듈을 import하고 있을 수 밖에 없다. 그럼 common에 기능 하나가 변경되어도 모든 모듈에 영향이 발생하게 된다!
   
   그럼 이런 의문이 들 수 있다. core도 코드 바뀌면 모든 모듈 영향 받는건 똑같잖아? 뭐가 다른데?
   다르다. core는 이름에서 주는 "핵심" 이라는 압박감과, "필수 공통 기능만 추가"라는 팀 컨벤션으로 맞춰진 hard한 코드리뷰로 정제된다.
   이와 반대로 common은 쉽게 수정할 수 있으며, core와 같이 팀원들의 심리적 압박감도 없기 때문에 잘못된 코드가 발생할 확률이 높다.
   
   common은 리스크가 너무 크다!
   
   
3. Library 모듈
   library는 이름 그대로, 기능 단위의 코드를 묶어서 제공하는 모듈이다.
   기능을 제공하기 위함이 목적이니만큼, 무차별적인 변경은 일어나지 않을 것이다.
   또한 기능별로 제공하기 때문에 코드 응집성도 높일 수 있고, 원하던 공통 코드를 관리하기에 적합하다!

이러한 흐름으로 우리팀은 핵심코드는 Core 모듈에, 기능단위 중복코드는 Library 모듈에 만들기로 하였다!

그렇게 파일 업로드, 엑셀, 암호화 등 다양한 기능이 개발되었다.

신나게 사용하던 중, 한 팀원이 JPA 기능의 sort 기능을 편하게 사용할 수 있도록 library 모듈에 코드를 추가하였다.
library 코드가 수정되면 library를 사용하는 모든 모듈이 재빌드되어 배포되는 방식인데, 한 서버가 뜨지 못하고 계속 죽고 있었다.

원인을 살펴보니, library에 JPA 의존성이 추가되었는데, 해당 서버에서는 DB를 사용하지 않아 datasource 설정이 없어서 발생하는 문제였다.

코드하나 추가했는데 어딘지 모르는 어떤 서버에서 문제가 생긴다는건 굉장히 큰 문제라고 느껴졌다.

프로젝트 구조를 바꿔야겠다...!

 

문제점

프로젝트 구조를 바꾸기 전, 라이브러리 모듈의 문제점을 나열해보았다.

1. 라이브러리 기능끼리 의존성이 강하다
   라이브러리 구조를 바꾸려고 코드를 확인해보니, 기능단위로 끊어 놓았다고 생각했던 코드들이 스파게티처럼 엮여 있었다.
   기능끼리 의존성을 가지다 보니 library를 더더욱 덜어내기 어려워졌고, 기능끼리의 의존성을 끊어야겠다고 생각했다.
2. 라이브러리가 변경되면 모든 모듈에 영향을 미친다.
   공통 기능을 하나의 모듈로 묶다 보니, 모든 모듈이 library에 의존성을 갖게 되었다.
   그래서 library에 코드를 추가하면 모든 모듈이 배포 되어야하고, 모든 모듈이 영향을 받는다.

해결책

1. Library를 멀티모듈 프로젝트로 분리하기
   library를 github repository로 분리하고, 그 안에서 기능들을 멀티모듈로 만드는 것이다!
   repo를 분리하면서 다른 모듈들과 물리적인 의존성을 끊어내고, 기능끼리의 의존성은 멀티모듈로 끊어내는 방법이다.
2. Github Maven Registry를 활용하여 버저닝하기
   코드 추가 및 수정에 기존 모듈들이 영향을 받지 않게 하려면 버저닝 외에는 방법이 없다.
   손쉽게 할 수 있는 방법 없을까 찾다가 maven repository에 올리면 좋겠다고 생각하였고, github에도 존재하길래 냉큼 사용하였다.

---

🛠️ 프로젝트 구성하기

왜 Github Maven Registry인가?

• private maven repository가 필요하다
• github에 대한 이해도가 높다
• 보안성 검토가 필요 없다.

이 3가지 이유로 채택하였다.

 

GIthub Action 구성하기

모듈 이름과 버전을 받고, github registry에 publish하는 재사용 workflow 예시이다.

on:
  workflow_call:
    inputs:
      module_name:
        required: true
        type: string
      version:
        required: true
        type: string

jobs:
  publish-package:
    runs-on: [ self-hosted ]
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          distribution: 'corretto'
          java-version: '17'
          cache: 'gradle'

      - name: Publish to Github Registry
        run: ./gradlew :${{ inputs.module_name }}:publish
        env:
          MAVEN_USER: ${{ github.repository_owner }}
          MAVEN_PASSWORD: ${{ secrets.GITHUB_TOKEN }}
          VERSION: ${{ inputs.version }}

 

Gradle 설정하기

• Library 프로젝트 Gradle
  소스코드를 같이 포함해서 빌드하여 사용하는 쪽에서 코드를 확인할 수 있도록 구성하였다.

import org.springframework.boot.gradle.tasks.bundling.BootJar

plugins {
	`maven-publish`
}

allprojects {
	apply(plugin = "maven-publish")
	group = "com.test.library"
}

subprojects {
    val sourceSets = the<SourceSetContainer>()
    val sourcesJar = task<Jar>("sourcesJar") {
        from(sourceSets["main"].allSource)
        archiveClassifier.set("sources")
    }

    publishing {
        repositories {
            maven {
                name = "GitHubPackages"
                url = uri("https://maven.pkg.github.com/<ORG_NAME>/library")
                credentials {
                    username = System.getenv("MAVEN_USER")
                    password = System.getenv("MAVEN_PASSWORD")
                }
            }
        }
        publications {
            create<MavenPublication>(project.name) {
                version = System.getenv("VERSION") ?: project.property("VERSION").toString()

                artifacts {
                    artifact(tasks.getByName("jar").outputs.files.singleFile) {
                        builtBy(tasks.getByName("jar"))
                    }
                    artifact(sourcesJar)
                }
            }
        }
    }
}

• API 프로젝트 Gradle
  사용하는 곳의 gradle에는 maven에 github 주소를 넣으면 된다.

allprojects {
	repositories {
        mavenCentral()
        maven {
            url = uri("https://maven.pkg.github.com/<ORG_NAME>/library")
            credentials {
                username = System.getenv("MAVEN_USER")
                password = System.getenv("MAVEN_PASSWORD")
            }
        }
        mavenLocal()
    }
}

 

만든 모듈을 import하려면, 다른 라이브러리 설정하듯이 하면 된다.

implementation("<groupId>:<artifactId>:<version>")

ex) implementation("com.test.library:excel:1.0.0")

 

브랜치 전략 설정하기

다양한 브랜치 전략이 있는데, 나는 Github-flow 전략을 채택하였다. [공식 문서]

라이브러리가 메인 프로젝트가 아니기 때문에 git-flow와 같은 너무 많은 step을 두고 싶지는 않았다. 그러나 버전별로 코드를 관리는 해야하기 때문에 비교적 단순한 github-flow가 적절하다고 생각했다.

내가 생각한 개발 스텝은 다음과 같다.

1. main branch에서 새로운 branch 생성
   브랜치 명 컨벤션은 다음과 같다.
   <module_name>/<버전>
   ex) excel/1.1.0
   
   
2. 해당 브랜치에서 개발 후 PR 생성
3. main branch에 merge 시 github action으로 maven registry에 publish

 

로컬 개발 방법

로컬에서 개발할 경우 잘 동작하는지 확인이 필요하다. 그럴 땐 local maven으로 publish 한 뒤 사용하는 모듈에서 확인해보면 된다.

./gradlew :{{ module_name }}:publishToMavenLocal

ex) ./gradlew :excel:publishToMavenLocal

---

gradle :{{ module_name }}:publishToMavenLocal

ex) gradle :excel:publishToMavenLocal

 

로컬에서는 주의해야할 점이 있다. 로컬에서 개발하기 위해 Local Maven Registry에 이미 publish가 되어있다면, API 개발할 때 Github에서 가져온 것이 아니기 때문에 문제가 발생할 수 있다. 이럴땐 intellij에서 local maven을 찾아 해당 라이브러리를 지우면 된다.