
1. 설정 파일 관리의 필요성
현재 마이크로 서비스들의 설정 파일들은 각각의 애플리케이션 내부에 존재한다.
이렇게 설정 파일들이 각 마이크로 서비스 내부에 존재하는 경우 생산성, 운영적 측면에서 문제가 발생하게 되는데
예를 들어
1. 성능 테스트를 위해 설정 파일에서 어떤 설정의 수치를 조절해가며 테스트해야 하는 상황
이런 상황에서 애플리케이션 내부에 설정파일들이 존재한다면 어떤 일이 일어날까?
수치를 한 번 조정하고 테스트할 때마다 애플리케이션을 새로 빌드하고 배포해야하는 과정이 필요하게 된다.
단지 설정 값을 조정하는 작업 하나 때문에 애플리케이션을 다시 빌드하고 배포해야 하는 것이다.
2. 여러 설정 파일에 공통으로 있는 어떤 설정 값을 변경해야 하는 상황
이런 상황은 또 어떨까?
예를 들어 인증을 위한 시크릿키를 여러 서비스들이 공통적으로 사용하고 있다고 해보자
시크릿 키는 같은 시크릿 키를 통해 암호화, 복호화해야 정상적으로 작동하는 대칭키 방식이기 때문에 모든 서비스에서 동일한 시크릿 키를 사용해야 한다.
그런 시크릿 키를 하나의 서비스에서 바꿔야하는 상황이 온다면 다른 서비스에서도 설정파일을 변경하기 위해 설정파일이 있는 애플리케이션에 직접 접속해서 수정하거나,
CD 파이프라인에서 설정파일을 관리한다면 애플리케이션 별 CD 파이프라인을 다 접속해서 변경해야 할 것이다.
이렇게 각 서버 내부에 설정파일이 존재하게 되면 불편한 상황들이 많이 생기게 되니 서버 외부에서 설정 파일을 한 번에 관리해주는 라이브러리의 필요성이 생기는 것이 당연하고
이를 위한 라이브러리가 바로 Spring Cloud Config다.
2. Spring Cloud Config란?
Spring Cloud Config는 앞서 말했듯 서버 외부에서 설정 파일을 한번에 관리해주는 라이브러리다.
세부적으로는 다음과 같은 역할을 하는데
- 분산 시스템에서 서버, 클라이언트 구성에 필요한 설정 정보(Application.yml)을 외부 시스템에서 관리
- 하나의 중앙화된 저장소에서 구성요소 관리 가능
- 각 서비스를 다시 빌드하지 않고, 바로 적용 가능
- 어플리케이션 배포 파이프라인을 통해 DEV(개발)-UAT(테스트)-PROD(배포) 각 환경에 맞는 구성 정보 사용
이 중 가장 중요한 역할은 역시 하나의 저장소에서 구성요소를 관리하는 기능이고 이 저장소는 Local 저장소 혹은 Local/Remote 환경의 git을 통해 관리된다.

Spring Cloud Config 환경은 이런 형태로 구성되는데 API Gateway 때와 같이 하나의 Config Server에 여러 개의 Config Client를 등록하게 되고 이 서버는 저장소에서 구성요소 설정파일을 가지고 와 원하는 Client에 뿌려주는 방식으로 작동하게 된다.
3. Spring Cloud Config 적용해보기
3-1. Spring Cloud Config Server 생성
우선 서버에 해당하는 Config-service 애플리케이션을 하나 만들어 준다.
3-1-1. Dependency 추가
dependencies {
implementation 'org.springframework.cloud:spring-cloud-config-server'
}
3-1-2. com.example.configservice.ConfigServiceApplication
package com.example.configservice;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.config.server.EnableConfigServer;
@SpringBootApplication
@EnableConfigServer
public class ConfigServiceApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServiceApplication.class, args);
}
}
EnableConfigServer 어노테이션을 부착해 Config Server임을 표시해준다.
3-1-3. Application.yml
server:
port: 8888
spring:
application:
name: config-service
profiles:
active: native
cloud:
config:
server:
native:
search-locations: file:///C:\Users\j3261\OneDrive\Desktop\CODE\native-file-repo
git:
uri: github repository 주소
username: github 아이디
password: github 패스워드
여기서 Local에 있는 저장소를 활용할 것인지 Remote 환경의 gitHub의 저장소를 활용할 것인지 설정할 수 있다.
spring.profiles.active를 통해 지정할 수 있으며 지금은 Local 저장소를 사용할 것이기 때문에
cloud.config.server.native.serarch-location의 값을 Local 저장소의 경로로 설정해주고 active: native로 설정 해준다.
만약 git repository를 사용하고 싶다면 spring.profiles.active 값을 설정하지 않은 상태에서
cloud.config.server.git.uri에 Local git 폴더의 경로나 github repository의 주소를 설정해 주면 된다.
나는 추가로 private repository를 설정해줬기 때문에 repository 접속을 위해 username과 password도 설정해줬다.
3-1-4. 저장소 및 설정파일 생성

이때, 주의할 점은 설정 파일 이름을 Spring Cloud Config Server의 요청 EndPoint에 맞춰서 생성해야 한다는 것이다.
/{application }/{profile}[/{label}]
- {application}-{profile}.yml
- /{label}/{application}-{profile}.yml
- /{application}-{profile}.properties
- /{label}/{application}-{profile}.properties
이 중 label이 없는 첫 번째 형식을 사용했고 profile을 따로 적지 않는다면 기본값 default로 설정된다.
이렇게 설정했을 때 설정파일은
- 애플리케이션 내부의 application.yml
- 저장소의 application.yml(default)
- 애플리케이션 내부의 application-{profile}.yml
- 저장소의 application-{profile}.yml
다음과 같은 순서로 읽어지며 나중에 읽어지는 것이 우선순위가 높다.
즉 순서대로 읽어지다가 동일한 설정 정보에 대해서 나중에 읽어지는 설정파일의 값을 덮어씌우게 된다는 뜻이다.
3-1-5. Spring Cloud Config 요청 테스트
자 이제 config-service를 실행시키고 잘 적용되었는지 확인해보자
localhost:8888/application/{profile}로 접속하면 되고 따로 profile 값을 설정하지 않았기 때문에 default로 접속했다.

cloud.config.server.native.serarch-location에 설정했던 경로의 application.yml파일을 잘 불러온 모습이다.
3-2. Spring Cloud Config Client 설정
이제 위의 요청에 대한 응답을 받아서 설정 정보를 저장하는 Spring Cloud Config Client를 설정해보자
3-2-1. Dependency 추가
Spring Cloud Config Server에서 설정파일을 받아 사용할 각 마이크로 서비스들에 일괄적으로 추가해주면 된다.
dependencies {
implementation 'org.springframework.cloud:spring-cloud-config-client'
}
3-2-2. application.yml 설정
Client에서는 이제 밖으로 꺼낸 설정 파일에 있는 설정 정보는 굳이 필요하지 않기 때문에 이제 지워줘도 상관없다.
다만 이때 주의해야 할 점은 server.port설정과 spring.application.name설정은 애플리케이션 내부에서 설정해주어야 한다.
왜냐하면 포트는 Config Server에서 응답을 받기 전에 결정되고 Eureka에서 서비스들을 등록해야 하기 때문이다.
server:
port: 8021
spring:
application:
name: apigateway-service
config:
import: optional:configserver:http://localhost:8888
저번에 만들었던 Api Gateway Service의 application.yml파일이다.
이렇게 설정할 경우 기본적으로 application.yml 파일을 불러오며
spring.application.name의 값에 따라 apigateway-service.yml 혹은 spring.profiles.active을 추가로 설정해 apigateway-service-{profile}.yml의 설정 정보를 추가로 불러올 수 있다.
spring.config.import 설정은 Spring Cloud Config Server를 불러오는 설정으로 optional:configserver:{config-server의 URL}값을 넣어 불러와주면 된다.
optional prefix를 설정하지 않으면 config server에 연결할 수 없는 경우 애플리케이션이 종료된다.
'Develop > Java & Spring' 카테고리의 다른 글
[MSA] MSA 전환 프로젝트 - 6. 마이크로 서비스 간 통신 with Spring Cloud OpenFeign (0) | 2025.03.26 |
---|---|
[MSA] MSA 전환 프로젝트 - 5. Spring Cloud Bus (0) | 2025.03.26 |
[MSA] MSA 전환 프로젝트 - 3. API Gateway & Spring Cloud Gateway (0) | 2025.03.26 |
[MSA] MSA 전환 프로젝트 - 2. Service Discovery & Eureka (0) | 2025.03.26 |
[MSA] MSA 전환 프로젝트 - 1. MSA란? (0) | 2025.03.26 |