TL;DR — submit 한 모듈만 고쳐도 서버 전체가 재빌드·재배포되던 단일 모듈 구조를, 책임 단위 5개 Gradle 멀티 모듈로 분리하고 CI에 paths-filter를 붙여 변경된 모듈만 배포하도록 바꿨다. 목표는 빌드 속도가 아니라 배포 범위(blast radius) 축소.

배경

• 프로젝트/기능: CodeQuest 백엔드 — 호서대 컴퓨터공학부 수업에서 실제 사용하는 코딩 테스트 플랫폼. 연구실 선배에게 데모 단계 인수.
• 환경: Spring Boot, Gradle, Docker, Kubernetes, GitHub Actions
• 왜 문제였나: 인수 시점엔 단일 모듈이라 데모로는 충분했지만, 수업에서 실사용이 시작되며 잦은 변경의 배포 비용이 커짐

문제 (증상)

• submit 코드 한 줄만 바꿔도 auth·course·gateway까지 전부 재빌드·재배포
• 변경 없는 서비스까지 매 배포마다 재기동 → 불필요한 다운타임·리스크
• 근본 원인: 단일 모듈 = 빌드 산출물 1개. "변경 범위 ≠ 배포 범위"라 무엇이 바뀌었는지 CI가 구분할 수 없음

원인 분석

• 배포를 변경에 맞춰 좁히려면, 먼저 코드가 "구분 가능한 단위"로 쪼개져 있어야 함
• 즉 빌드/배포 단위를 책임 단위와 일치시키는 게 선결 과제

해결

1) Gradle 멀티 모듈 분리 (common·gateway·auth·course·submit) — settings.gradle

['common', 'gateway', 'auth', 'course', 'submit'].each { name ->
    include name
    project(":${name}").projectDir = new File("modules/${name}")
}

• Phase 1~9로 단계 분리: 구조 세팅 → git mv로 파일 이동(히스토리 유지) → 패키지/Application 분리 → SRP·모듈 의존성 정리 → 모듈별 application.properties·Dockerfile 분리 → K8s 매니페스트 → CI/CD 대응 → 빌드·테스트 검증
• 쪼갠 뒤 터진 부작용 해결: 모듈마다 @SpringBootApplication 자동 설정 충돌(8621d05), 전환 후 테스트 컴파일 오류(15d4f57)

2) CI 선택 배포 — deploy-server.yml

- uses: dorny/paths-filter@v3
  id: filter
  with:
    filters: |
      common:  ['modules/common/**', 'build.gradle', 'settings.gradle']
      gateway: ['modules/gateway/**']
      auth:    ['modules/auth/**']
      course:  ['modules/course/**']
      submit:  ['modules/submit/**']

• 개별 모듈만 변경 → 그 모듈만 배포 / common·빌드 스크립트 변경 → 전체 배포(공유 코드라 영향이 전체로 번짐) / 수동 workflow_dispatch → 전부