배경
MSA 환경에서는 서비스가 여러 개로 나뉘기 때문에
각 서비스가 동일한 로직을 반복 구현하면 유지보수가 매우 힘들어진다.
예를 들어, 다음과 같은 코드들을 중복될 수 있습니다.
- BaseEntity (공통 감사 필드)
- GlobalExceptionHandler
- ApiResponse
- ErrorCode
JitPack을 이용한 공통 모듈 관리
JitPack은 GitHub 레포지터리를 직접 Maven/Gradle 의존성으로 배포해주는 무료 서비스입니다.
즉, 따로 저장소를 구축하지 않아도 단 몇 줄로 모듈을 재사용할 수 있습니다.
장점
항목 설명
| ✅ 배포 편의성 | GitHub push & tag 만으로 배포 |
| ✅ 버전 관리 | Git 태그(1.0.0, 1.1.0)로 의존성 버전 고정 |
| ✅ 독립성 | 다른 프로젝트에서 손쉽게 가져다 쓸 수 있음 |
| ✅ 유지보수 용이 | 공통 모듈 변경 시 버전만 올리면 모든 서비스에 반영 가능 |
프로젝트 구조 예시
app/
├── gabojago/
└── gabojago-common/ ← ✅ 공통 관심사 모듈 (JitPack 배포 대상)
베이스 엔티티 예시
@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class BaseEntity {
@CreatedDate
@Column(updatable = false)
private LocalDateTime createdAt;
@CreatedBy
@Column(updatable = false)
private UUID createdBy;
@LastModifiedDate
private LocalDateTime updatedAt;
@LastModifiedBy
private UUID updatedBy;
private LocalDateTime deletedAt;
private UUID deletedBy;
public void delete(UUID deletedBy) {
this.deletedAt = LocalDateTime.now();
this.deletedBy = deletedBy;
}
public void restore(UUID updatedBy) {
this.deletedAt = null;
this.deletedBy = null;
this.updatedAt = LocalDateTime.now();
this.updatedBy = updatedBy;
}
public boolean isDeleted() {
return deletedAt != null || deletedBy != null;
}
}
JitPack 설정 방법 요약
build.gradle
plugins {
id 'java'
id 'maven-publish'
}
group = 'com.gbg'
version = '1.0.0' // Tag와 동일하게 설정
...
afterEvaluate {
publishing {
publications {
mavenJava (MavenPublication) {
from (components.java)
}
}
}
}
이후 GitHub에 푸시하고 Tag 올려주세요!
git add .
git commit -m "feat: BaseEntity 생성"
git tag 1.0.0
git push origin main
git push origin 1.0.0
JitPack
JitPack | Publish JVM and Android libraries
JitPack makes it easy to release your Java or Android library. Publish straight from GitHub or Bitbucket.
jitpack.io
사이트에 접속하여 Look up 부분에 repo 이름을 적어서 검색해주시면 됩니다.

위 사진 처럼 명시한 버전이 나올 거고, 아래 코드들은 다른 서비스에 의존성 추가할 때 사용해주시면 됩니다.
다른 서비스에 의존성 추가 및 설정
의존성 추가
repositories {
mavenCentral()
maven { url 'https://jitpack.io' }
}
dependencies {
implementation 'com.github.GBG-Gaboja-Go:gabojago-common:1.0.0'
}
JpaAuditing
@Configuration
@EnableJpaAuditing
public class JpaConfig {
}
서비스에 @EnableJpaAuditing 설정해주는 Config 클래스가 있어야 적용이 된다!
JitPack을 사용할때와 다른 방법의 차이점
| 배포 구조 | GitHub → 외부 의존성 | Gradle 멀티모듈 |
| 유지보수 | 버전만 바꾸면 끝 | 코드 직접 복사/참조 필요 |
| 프로젝트 독립성 | 완전 독립된 레포로 관리 가능 | 루트 Gradle에 강하게 결합 |
| 장점 | 서비스 간 독립 유지, 재사용성↑ | 초기 설정 간단 |
| 단점 | GitHub 공개 필요(또는 Private 토큰 필요) | 규모 커지면 빌드/의존성 꼬임 발생 |
결론
초기에는 멀티모듈 구조로도 충분할 거 같지만 서비스가 많아지고 CI/CD파이프라인이 분리된다고 하면 JitPack 방식이 훨씬 유리하다고 한다..
초기 설정은 조금 더 복잡한 거 같지만 적용하고 나면 베이스 엔티티 뿐 아니라 전역 예외 처리, 로깅등 각 서비스에서 필요한 기능들을 한 곳에서 관리할 수 있어서 편해지는거같습니다!!
'BACKEND & SERVER > Spring Boot MSA' 카테고리의 다른 글
| [Spring Boot] 스프링 부트 슬랙 API 연동하고 이메일 인증하기 (1) | 2025.11.11 |
|---|---|
| [Spring Boot] JitPack | MSA Project GateWay Swagger 구현 (0) | 2025.11.05 |
| [Spring Boot] DTO에 Serializable을 사용하는 이유 (0) | 2025.10.30 |
| [Spring Boot] Spring Cloud GateWay & Filter (0) | 2025.10.27 |
| [Spring Boot] Resilience4j | 서킷브레이커 (0) | 2025.10.27 |
