Springboot kotlin 멀티모듈 구조 적용하기 (기능-서비스 단위 모듈화, 멀티 프로필 application.yml, 모듈간 종속 관계, 모듈간 Bean 주입, Kotlin 사용)
- 이번 포스팅에서는 Springboot 를 사용하여 멀티 모듈 구조를 만들고 테스트 해보겠습니다.
- Springboot 의 멀티 모듈 구조
Springboot 에서 모듈이란, 쉽게 말하자면 전사적인 코드를 블록화 할 수 있도록 코드 분할을 지원하는 기능으로,
예를들어 단일 모듈에서의 Springboot 는 build.gradle, settings.gradle, gradlew, src 폴더 등으로 이루어져서 하나의 설정과 하나의 프로젝트라는 단위로 코드가 종속되어있는데,
멀티 모듈 환경에서는 build.gradle, src 폴더 이렇게 기능을 구현하는데 필수적인 '설정' 과 '구현 코드' 를 묶은 단위를 한 프로젝트 내에서 N 개 생성할 수 있게 만들어줍니다.
이러한 기능이 유용한 이유를 제 경험에 빗대어 설명드리자면,
제가 개인적으로 진행하는 프로젝트에서 기능이 계속 늘어가는 상황에 JPA 코드 부분만 떼어내어 다른 프로젝트에 이식하고 싶었습니다.
하지만 JPA 를 구성하는 코드와 다른 코드들이 섞여있는 상태이고, build.gradle 에서도 다른 라이브러리들과 섞여있는 상태라 번거로웠던 기억이 있습니다.
물론 저의 경우는 프로젝트 구조를 모두 동일하게 가져가고, 주석처리 및 설명도 따로 적어두었기에 그다지 어렵지는 않게 코드를 분리하였지만, 애초에 선행 지식이 필요하며, 번거로운 코드 선별 작업이 필요한 구조는 그다지 좋지 않다는 것은 당연한 소리며, 다른 사람이 해당 프로젝트를 다루게 될 때에는 더욱 그러할 것입니다.
만약 멀티 모듈을 적용한다면, JPA 용으로 따로 떼어놓은 모듈만 빠르게 떼어내어 다른 프로젝트에 이식이 가능했겠죠.
그뿐만이 아니라 코드의 관심사의 분리로 인한 유지보수성 상승 및 보다 깔끔한 구조로 인하여 디버그 및 협업시 작업 범위를 나누기에도 적합할 것입니다.
- 아래 실습에서는, Springboot Kotlin 에서 단일 모듈 구조의 프로젝트를 멀티 모듈로 변경하고,
멀티 프로필을 적용한 application.yml 을 적용한 후, 각 모듈별로 yaml 파일의 설정이 잘 적용되는지를 확인하는 것과 동시에 한 모듈의 Bean 을 다른 모듈에서 주입받아 사용하는 방법까지를 진행하겠습니다.
- 실습
1. 먼저 기본 Springboot 프로젝트를 생성합시다.
저는 https://start.spring.io/ 에서
위와 같은 설정으로 생성하였습니다.
프로젝트를 열어보면 위와 같은 구조를 가질텐데,
저는 기본 구조에서의 src 를 날려버리고 모든 것을 모듈로 구성할 것입니다.
즉, 프로젝트가 실행되는 main 함수 역시 프로젝트를 구성하는 어떤 한 모듈에서 담당하게 됩니다.
(프로세스 실행 스위치가 N개가 될 수 있음)
2. 위에서 src 폴더를 통째로 과감하게 지워버리세요.
그리고 build.gradle 폴더의 내용이 기존에는,
plugins {
kotlin("jvm") version "1.9.25"
kotlin("plugin.spring") version "1.9.25"
id("org.springframework.boot") version "3.3.4"
id("io.spring.dependency-management") version "1.1.6"
}
group = "com.raillylinker"
version = "0.0.1-SNAPSHOT"
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
repositories {
mavenCentral()
}
dependencies {
implementation("org.springframework.boot:spring-boot-starter")
implementation("org.jetbrains.kotlin:kotlin-reflect")
testImplementation("org.springframework.boot:spring-boot-starter-test")
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5")
testRuntimeOnly("org.junit.platform:junit-platform-launcher")
}
kotlin {
compilerOptions {
freeCompilerArgs.addAll("-Xjsr305=strict")
}
}
tasks.withType<Test> {
useJUnitPlatform()
}
위와 같았을텐데,
plugins {
kotlin("jvm") version "1.9.25"
}
group = "com.raillylinker"
version = "0.0.1-SNAPSHOT"
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
repositories {
mavenCentral()
}
kotlin {
compilerOptions {
freeCompilerArgs.addAll("-Xjsr305=strict")
}
}
이렇게 바꿔줍니다.
아주 가벼워졌는데, 루트에서 시작되는 기본 모듈은 없는 것으로 여기고, 루트의 build.gradle 은 그저 모듈들을 모으는 역할로만 사용할 것이기 때문에 이렇게 처리하였습니다.
이곳에서 할 수 있는 다른 설정으로는, 프로젝트에 속한 모든 모듈에 대해 공통적인 설정을 하거나 공통적으로 사용하는 라이브러리 설정도 할 수 있지만, 저의 경우는 모듈은 독립성을 지니는 것이 좋으며, 독립성 있는 모듈이란, 프로젝트 루트 설정에도 구애받지 않고, 말 그대로 독립적으로 존재해야 한다고 생각하기에 이렇게만 처리한 것입니다.
(만약 이곳에서 뭔가 특별한 설정을 해버린다면, 하위 모듈들이 이곳의 설정에 종속되는 것이므로 좋지 않다고 판단한 것입니다.)
위와 같이 설정되었다면 앞으로의 개발 진행에서 루트 경로의 의미란, 그저 모듈들을 모아두는 것이고, 여기서 신경써야 할 것은 gitignore 파일, README 파일, 모듈을 추가했을 때의 settings.gradle 파일 정도밖에 없어지며, 나머지는 모듈 단위로 신경을 쓰시면 됩니다.
3. 이제 모듈을 만들어야 합니다.
여기서 잠깐, 제가 생각하는 모듈 생성 규칙을 말씀드리겠습니다.
1. 프로젝트 내의 모든 기능과 변경은 모듈단위로 이루어진다.
2. 모듈은 되도록 완전 독립 모듈을 지향한다. (모듈 자체만 떼어내어 다른 프로젝트에 이식해도 바로 동작이 가능하도록)
3. 모듈의 종류는 크게 독립 모듈과 종속 모듈로 나뉘며, 종속 모듈중 대표적인 것으로는 서버 프로젝트가 구현하려는 api 모듈이 있다.
위와 같이 모듈화의 근본적인 목적을 살려서 구분을 할 것이며,
이러한 방식은 자연스럽게 기능 중심적인 모듈화가 될 것입니다.(종속성을 없애기 위해선 기능 중심으로 모듈을 나눌 수 밖에 없습니다.)
이렇게 기능 중심적인 모듈화를 먼저 진행하여 독립성을 가질 수 있는 모든 기능이 모듈화 되었다면, 다음으로는 이를 사용하는 모듈, 즉 다른 모듈에 종속성을 가진 모듈을 만들어야 할텐데, 저는 이를 구현하려는 서비스 단위로 나누려 합니다.
예를들어 이번에는 쇼핑몰을 만들기 위해 shopping-mall 이라는 모듈을 만들어서 api 개발 중심의 코드를 이곳에 작성하고, 다음에는 헤어샵 예약 서비스를 만들기 위해 hair-shop 이라는 모듈을 만들 수 있습니다.
위와 같은 방식으로 모듈화가 진행되므로 모듈의 작명 방식을 먼저 정해보자면,
기능 중심의 독립적인 모듈은 접두사로 module-idp-*, 이렇게 하여, 이 폴더가 모듈의 폴더이며, 해당 모듈이 다른 모듈에 대해 독립적인(independent) 모듈이라는 것을 나타내줄 것입니다.
그리고 서비스 단위의 모듈은 api 개발용 모듈이라는 것을 나타내기 위하여, module-api-* 라는 접두사를 사용할 것입니다.
4. 위와 같은 내용을 인지한 상태에서 모듈을 만들어봅시다.
먼저 독립적으로 다른 모듈에 의존하지 않는 모듈을 만들어보겠습니다.
IDE 탐색창의 프로젝트 경로에서 우클릭을 한 후,
위와 같이 새로 만들기 -> 모듈 을 눌러줍니다.
위에서 설명했듯, 독립적인 모듈이므로, module-idp 를 작명하였고, 거기에 저는 jpa 를 떼어내어 내부에서 JPA Entity, Repository 들을 모아둘 생각으로 만들었으므로 위와 같이 module-idp-jpa 라는 이름을 지은 것입니다.
위와 같이 설정하여 생성을 누르면,
이처럼 모듈이 생성되고,
settings.gradle 안에
plugins {
id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0"
}
rootProject.name = "springboot_mvc_template"
// (모듈 모음)
include("module-idp-jpa")
이런식으로 생성된 모듈이 프로젝트에 잘 include 된 것을 확인할 수 있습니다.
(참고로 생성된 모듈을 지우려면 모듈에 우클릭을 하여 모듈 지우기를 선택한 후, settings.gradle 안에서 include 를 지우고 모듈 파일을 삭제하면 됩니다.)
잠시 생성된 모듈을 확인하고 갑시다.
모듈은 src 와 build.gradle 로 이루어져 있습니다.
즉, 개발에 필요한 설정과 코드 공간이라는 충족 요건을 만족하는 것을 확인 가능합니다.
5. 생성된 독립 모듈의 build.gradle 에,
plugins {
kotlin("jvm") version "1.9.25"
kotlin("plugin.spring") version "1.9.25"
id("org.springframework.boot") version "3.3.4"
id("io.spring.dependency-management") version "1.1.6"
}
group = "com.raillylinker.module_idp_jpa"
version = "0.0.1-SNAPSHOT"
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
repositories {
mavenCentral()
}
dependencies {
// (기본)
implementation("org.springframework.boot:spring-boot-starter:3.3.4")
implementation("org.jetbrains.kotlin:kotlin-reflect:2.0.21")
testImplementation("org.springframework.boot:spring-boot-starter-test:3.3.4")
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5:2.0.21")
testRuntimeOnly("org.junit.platform:junit-platform-launcher:1.11.2")
}
kotlin {
compilerOptions {
freeCompilerArgs.addAll("-Xjsr305=strict")
}
}
tasks.withType<Test> {
useJUnitPlatform()
}
위와 같이 설정하고 Gradle 빌드를 합시다.
문제 없이 빌드됨을 알 수 있습니다.
앞서 설명하였듯 모듈의 독립성을 중시하므로 위와 같이 모듈 독립적으로 필요한 설정을 모두 작성한 것입니다.
또한, group 부분을 본다면 루트 설정의 group 의 값에서 뒤에 module_idp_jpa 라고 모듈 이름을 스네이크 패턴으로 표기한 것이 있는데, 모듈의 패키지명을 이렇게 설정한 것입니다.
Main.kt 라는 파일만 덩그러니 있는 src/main/kotlin 폴더 안에,
com.raillylinker.module_idp_jpa 라는 형식으로 본인의 프로젝트 경로를 만들고,
Main.kt 파일을 이동시켜준 후, Main.kt 파일 안의 package 설정을 수정해주시면 하나의 모듈 준비가 끝이났습니다.
6. 다음 모듈을 만들어봅시다.
이번에는 앞서 만든 모듈을 사용하는 api 모듈을 만들 것입니다.
위에서의 작업과 동일하게, 이번에는 module-api-sample 이라는 모듈을 만들어주세요.
다시 환기드리자면, module-api 는 api 개발을 위한 모듈이며,
sample 은 api 서비스의 이름을 의미합니다.
샘플용 api 모듈을 만든 것이죠.
이 모듈의 build.gradle 에는
plugins {
kotlin("jvm") version "1.9.25"
kotlin("plugin.spring") version "1.9.25"
id("org.springframework.boot") version "3.3.4"
id("io.spring.dependency-management") version "1.1.6"
}
group = "com.raillylinker.module_api_sample"
version = "0.0.1-SNAPSHOT"
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
repositories {
mavenCentral()
}
dependencies {
// (모듈)
implementation(project(":module-idp-jpa"))
// (기본)
implementation("org.springframework.boot:spring-boot-starter:3.3.4")
implementation("org.jetbrains.kotlin:kotlin-reflect:2.0.21")
testImplementation("org.springframework.boot:spring-boot-starter-test:3.3.4")
testImplementation("org.jetbrains.kotlin:kotlin-test-junit5:2.0.21")
testRuntimeOnly("org.junit.platform:junit-platform-launcher:1.11.2")
// (Spring Starter Web)
// : 스프링 부트 웹 개발
implementation("org.springframework.boot:spring-boot-starter-web:3.3.4")
}
kotlin {
compilerOptions {
freeCompilerArgs.addAll("-Xjsr305=strict")
}
}
tasks.withType<Test> {
useJUnitPlatform()
}
이처럼 작성해줍시다.
바로 전의 모듈과 동일한데, 한가지 다른점으로는, dependencies 의 첫줄에 앞에서 만든 모듈을 impement 하는 코드가 있다는 것입니다.
이것이 독립 모듈과 아닌 모듈의 차이입니다.
독립 모듈은 다른 모듈을 전혀 사용하지 않고 고려하지도 않기에 다른 모듈을 절대 가져와 사용하지 않지만 독립 모듈이 아닌 모듈은 위와 같이 자신이 사용하려는 모듈을 명시해야만 코드 내에서 해당 모듈에 접근이 가능합니다.
이를 이용해 모듈간 종속성을 컨트롤하고 확인 가능하기에 보다 안전한 코드를 만들 수 있습니다.
자, 이제 api 모듈도 src 폴더 안에 패키지 경로를 생성하면 되는데, 여기서 조금 다른 것이 있습니다.
api 모듈은 서비스단위의 모듈이며, 서버의 시작점이기도 합니다.
즉, 서버를 시작시키는 main 함수를 생성해주어야 합니다.
기존의 Main.kt 파일을 삭제하고, module_api_sample 경로 안에 ApplicationMain.kt 라는 이름의 클래스 파일을 생성해 주세요.
그리고
package com.raillylinker.module_api_sample
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
@SpringBootApplication
class ApplicationMain
fun main(args: Array<String>) {
runApplication<ApplicationMain>(*args)
}
위와 같이,
서버의 시작점이 되는 main 함수를 만들어주면 끝입니다.
IDE 에서 해당 파일에 우클릭을 한 후,
ApplicationMain 시작
이라는 버튼을 누르면,
이처럼 api 모듈이 기존 단일 모듈 서버와 같이 정상적으로 동작함을 확인할 수 있습니다.
7. 이제 멀티모듈에서 핵심적인 기능들을 구현하고 테스트를 진행해보겠습니다.
바로 다른 모듈에 접근하고, 다른 모듈에서 만들어진 Bean 을 주입받아 사용하는 기능과,
application.yml 설정을 모듈별로 적용하는 방식...
이 두가지가 충족된다면 멀티 모듈도 단일 모듈 개발과 크게 다를것이 없게 됩니다.
먼저 jpa 모듈이 생성하는 Bean 을 sample 모듈이 가져와 사용하는 방식부터 알아봅시다.
한 모듈이 다른 모듈의 코드나 Bean 을 가져와 사용하기 위해선 build.gradle 에 앞서와 같은 모듈 주입 설정이 필요합니다.
이는 충족이 된 상태라 넘어가는데, 이렇게만 설정이 되었다면 바로 코드상에 접근하여 함수와 같은 것을 사용은 가능할테지만, 한 모듈이 관리하는 Bean 을 가져올 수는 없는 상태입니다.
api 모듈의 ApplicationMain.kt 파일 안에,
@SpringBootApplication(
scanBasePackages =
[
"com.raillylinker.module_api_sample",
"com.raillylinker.module_idp_jpa"
]
)
class ApplicationMain
fun main(args: Array<String>) {
runApplication<ApplicationMain>(*args)
}
위와 같이 scanBasePakages 라는 설정을 추가하여 이 안에 모듈 자신의 패키지 경로와 Bean 을 가져오려는 패키지명을 설정해주시면 됩니다.
이 설정은 Spring 이 동작할 때 프로젝트 패키지들을 읽어들여 모든 Bean 객체를 생성해둘 때에 어떤 경로에 스캔을 진행할지에 대한 설정으로, 이것을 하지 않는다면 다른 모듈의 Bean 은 api 모듈 내에서 확인할 수 없게 됩니다.
이제 위와 같은 설정이 잘 이루어졌는지 확인하기 위해서,
jpa 모듈 안의 Main.kt 파일 코드를,
import org.springframework.stereotype.Component
@Component
class Main{
fun moduleTest() {
println("complete!!")
}
}
이렇게 바꿔봅시다.
Main 클래스가 생겼으며, 이것이 Springboot 의 Bean 으로 등록되도록 하였고, 해당 객체의 moduleTest 함수를 사용하면 complete!! 라는 문자열이 출력되도록 하였습니다.
이제 이를 api 모듈에서 빈 주입을 받아와서 함수를 실행시켰을 때 정상 동작하는지를 확인하여 모듈간 빈 공유가 되는 것을 테스트 할 수 있을 것입니다.
api 모듈의 ApplicationMain.kt 파일 코드를,
package com.raillylinker.module_api_sample
import com.raillylinker.module_idp_jpa.Main
import jakarta.annotation.PostConstruct
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.boot.runApplication
@SpringBootApplication(
scanBasePackages =
[
"com.raillylinker.module_api_sample",
"com.raillylinker.module_idp_jpa"
]
)
class ApplicationMain(
val moduleMain: Main
) {
@PostConstruct
fun logTestPast() {
moduleMain.moduleTest()
}
}
fun main(args: Array<String>) {
runApplication<ApplicationMain>(*args)
}
위와 같이 변경시켰습니다.
jpa 모듈의 Main 컴포넌트 빈을 주입받아와서 main 함수가 실행이 완료되었을 때, moduleTest 를 실행하도록 하였습니다.
즉, 서버를 실행시켰을 때, 서버 준비 완료 후 complete!! 가 뜬다면 한 모듈에서 다른 모듈의 Bean 을 잘 주입받고 함수를 실행시켰다는 것이 증명되는 것으로,
결과는 위와 같이 성공입니다.
8. 이제 마지막으로 application.yml 파일을 멀티 모듈 환경에서 적용시켜봅시다.
제가 구상하는 것은, 각 모듈별로 resources 안에 application.yml 로 설정을 따로 합니다.
각 설정은 각 모듈별로 적용이 되는데, 여기에 더하여 application.yml 프로필 기능을 더하여 개발 환경 변경에 따른 프로필 설정 변경시에 각 모듈별 다른 설정이 반영되도록 할 것입니다.
혹시나 springboot 프로필에 대해 모르시는 분을 위해 소개드리자면,
프로필은 프로젝트 실행 단계에서 손쉽게 실행 설정을 바꿀 수 있는 기능입니다.
예를들어 우리가 프로젝트를 개발했는데, 개발 서버에서 실행하기 위해 port 번호를 8080 으로 바꾸고, 똑같은 프로젝트로 이번에는 배포 서버에서 실행하기 위해 port 번호를 80 으로 바꾼다면, 프로필 기능을 사용하지 않는다면 우리는 수동으로 코드를 바꾸고 난 후에 빌드를 하여 실행을 시켜야 할 것입니다.
하지만 프로필 기능을 사용하여,
application-dev.yml
application-prod.yml
위와 같이 미리 개발 서버와 배포 서버의 설정값을 지정해두고,
java 실행 명령어의 옵션으로 -Dspring.profiles.active=dev 이처럼 프로필 명만 바꿔주면, 이번에는 dev.yml 에 적힌 설정으로, 다음에는 prod 의 설정으로 손쉽게 바꿀 수 있습니다.
이제 jpa 모듈의 설정부터 봅시다.
여기서 저는 파일을 4개 생성할 것입니다.
프로필에 관계없이 적용되는 설정 파일과,
개발 환경인 dev, 로컬 환경인 local, 배포 환경인 prod 각각의 설정 파일...
application-idp-jpa.yml
application-idp-jpa-dev.yml
application-idp-jpa-local.yml
application-idp-jpa-prod.yml
위와 같이 생성해주세요.
(yml 파일 작명법은, 모듈 이름에서 module 만 뺀 것입니다.)
application-jpa.yml 안에는 아무것도 입력할 필요가 없고,
나머지에는,
test:
past: "hello1"
위와 같은 형태로,
각각 hello1, hello2, hello3 이렇게 값을 변경해주세요.
이렇게 하여 프로필 변경시마다 값을 잘 변경하는지, 프로필 정보를 잘 읽어오는지에 대해 테스트 할 것입니다.
jpa 모듈의 Main.kt 파일 안에,
import org.springframework.beans.factory.annotation.Value
import org.springframework.stereotype.Component
@Component
class Main{
@Value("\${test.past}")
lateinit var testPast: String
fun moduleTest() {
println(testPast)
}
}
위와 같이 application.yml 파일 안의 test.past 라는 값을 가져오고, 이를 출력하도록 하였습니다.
모듈 내에 설정파일이 잘 적용되었다면 위에서 설정한 값이 출력될 것입니다.
자, 먼저 jpa 모듈의 설정 파일부터 생성을 했지만, 사실 이 상태는 전혀 설정이 안된상태입니다.
설정 파일의 존재를, 해당 모듈을 사용하는 주체가 되는 모듈, 즉 main 함수를 가진 모듈에게 알려줘야만 합니다.
springboot 가 실행되면 main 함수가 실행되는 모듈 내의 resources 폴더 안에 application.yml 설정이 먼저 실행되고, 이 설정 내부에, 위와 같은 별도 설정 파일이 있다는 것을 명시해줘야 합니다.
이번에는 api 모듈 안에,
application.yml
application-dev.yml
application-local.yml
application-port80.yml
application-port8080.yml
application-prod.yml
위와 같은 파일을 만들어주시면 됩니다.
application.yml 안에,
# (실행 환경 공통 설정)
# : 개발 환경에 상관 없이 공통으로 적용되는 설정
server:
error:
include-stacktrace: NEVER # 자세한 에러 명세는 클라이언트에게 전달하지 않기
spring:
profiles:
group: # 프로필 그룹 생성 - 새로운 프로필명에, 하위 프로필들을 조합. 생성한 그룹은 spring.config.activate.on-profile 에서 명시해줘야함
local8080: local, port8080, idp-jpa, idp-jpa-local
dev8080: dev, port8080, idp-jpa, idp-jpa-dev
prod80: prod, port80, idp-jpa, idp-jpa-prod
default: local8080 # jar 실행시 프로필 설정이 없을 때 적용할 프로필
# IDE 실행 프로필 설정은, 실행 - 구성편집에서 VM 옵션 안에 -Dspring.profiles.active=dev8080 이렇게 설정 가능
# prod 실행 포트를 나눠둔 이유는 배포 서버의 무중단 배포시 스위칭을 위한 것
위와 같이 적어주면 설정이 끝난 것입니다.
spring.profiles.group 이 바로 앞에서 말했던 다른 설정 파일이 있다는 것을 말해주는 설정으로,
group 의 항목이 바로 프로필명이고, 각 오른쪽 리스트가 구성 목록입니다.
즉, local8080 프로필은 application-local, application-port8080, application-idp-jpa, application-idp-jpa-local 를 합친 것(각 파일의 application- 접두사는 제외하고 설정)이며, -Dspring.profiles.active=local8080 설정으로 실행시킨다면 위와 같은 설정의 결합으로 프로젝트가 실행된다는 것입니다.
여기서 별도 모듈의 설정을 추가하여야만 해당 yml 설정 파일의 내용을 사용할 수 있습니다.
마무리로,
application-dev.yml
# (실행 환경 dev 설정)
# : 개발 환경 개발자들을 위한 환경 설정
spring:
config:
activate: # 프로필명 설정
on-profile: dev
servlet:
multipart:
# !!!multipart 데이터량 설정!!!
maxFileSize: 50MB
maxRequestSize: 50MB
application-local.yml
# (실행 환경 local 설정)
# : 로컬 환경 개발자를 위한 환경 설정 = 서버 개발자가 마음껏 사용 가능 (그냥 IDE 를 실행하면 적용)
spring:
config:
activate: # 프로필명 설정
on-profile: local
servlet:
multipart:
# !!!multipart 데이터량 설정!!!
maxFileSize: 50MB
maxRequestSize: 50MB
application-port80.yml
spring:
config:
activate:
on-profile: port80
server:
# 포트번호
port: 80
application-port8080.yml
spring:
config:
activate:
on-profile: port8080
server:
# 포트번호
port: 8080
application-prod.yml
# (실행 환경 prod 설정)
# : 배포 환경 엄중한 환경 설정
spring:
config:
activate: # 프로필명 설정
on-profile: prod
servlet:
multipart:
# !!!multipart 데이터량 설정!!!
maxFileSize: 50MB
maxRequestSize: 50MB
위와 같이 작성하면 끝입니다.
이제 테스트를 위해 다시 서버를 실행시킨다면,
이처럼 jpa 모듈이 application 프로필 설정 데이터를 잘 가져와서 화면에 보여주는 것을 확인할 수 있습니다.
- 이상입니다.