[Spring] MSA 설정 중앙화: Spring Cloud Config와 다중 프로필 전략

마이크로서비스 아키텍처(MSA)를 운영하다 보면 소스 코드 자체보다 토큰 만료 시간, API 주소, 게이트웨이 정책 같은 설정값이 훨씬 자주 바뀐다는 것을 실감하게 된다.
하지만 서비스가 수십 개로 쪼개진 환경에서 각 서비스마다 application.yml을 따로 관리하는 것은 운영상의 큰 리스크를 동반한다. 똑같은 DB 주소를 여러 곳에 복사해두었다가 누락이 발생하거나, 환경(dev/prod) 분리가 시작되면서 파일 관리의 복잡도가 제어 불능 상태에 빠지기 때문이다.
오늘은 이러한 문제를 해결하고 설정을 '운영 자산'으로 다루게 해주는 Spring Cloud Config의 핵심 메커니즘과 실무 전략을 상세히 정리해 보았다.

 

1. Spring Cloud Config를 사용하는 이유

Spring Cloud Config의 핵심 목적은 설정을 애플리케이션 코드에서 분리하여 중앙 서버에서 관리하고, 이를 Git으로 버전 관리하여 운영의 안정성을 높이는 데 있다. 즉, 설정을 단순한 '파일'이 아니라 추적 가능한 '운영 자산'으로 취급하게 해준다. 이 구조에서 각 컴포넌트는 다음과 같은 명확한 역할을 수행한다.

• Config Server: 설정을 제공하는 중앙 허브 역할을 하며, 클라이언트의 요청에 맞는 설정을 전달한다.
• Config Client: 서버로부터 설정을 받아 실행되는 실제 마이크로서비스들(user-service 등)이다.
• Git Repo: 설정의 '단일 진실 원천(SSOT)'으로, 모든 설정값이 버전별로 저장되는 원본 저장소다.

 

2. 전체 아키텍처와 부팅 시퀀스

서비스가 기동될 때 외부 설정을 가져오는 부팅 시퀀스를 이해하는 것은 매우 중요하다. Spring Boot 2.4 이전에는 bootstrap.yml이 그 주인공이었지만, 이제는 application.yml의 spring.config.import 구문이 그 역할을 완전히 대체했다.

과거에는 "설정 서버 정보를 알기 위해" 별도의 부트스트랩 파일을 먼저 읽어야 했으나, 이제는 애플리케이션의 메인 설정 파일인 application.yml을 읽는 도중 외부 설정을 가로채서(Intercept) 가져오는 방식으로 표준화되었다.

1. Client 기동: bootstrap.yml을 로딩하여 Config Server의 주소와 필요한 설정 이름(name), 프로필(profile) 정보를 확인한다.
2. 설정 조회: Config Server는 Git 저장소에서 해당 조건에 맞는 설정 파일을 조회한다.
3. Environment 구성: Client는 원격에서 전달받은 설정을 바탕으로 최종 Environment를 구성하고 본격적인 애플리케이션 로직을 시작한다.

 

3. 상세 가이드: 설정 및 동적 반영

더 이상 bootstrap.yml을 관리하는 번거로움 없이, application.yml에 직접 설정 서버의 위치를 명시한다. optional: 접두사를 붙여 설정 서버에 문제가 생기더라도 서비스 기동 자체는 실패하지 않도록 유연하게 대처할 수 있다.

🔍 Config Client 설정 (application.yml)

더 이상 bootstrap.yml을 만들지 않고, 아래와 같이 spring.config.import 구문을 사용하여 서버 연결 정보를 정의한다. optional: 접두사를 붙이면 설정 서버가 일시적으로 꺼져 있더라도 애플리케이션 기동이 실패하지 않도록 방어할 수 있다.

spring:
  application:
    name: user-service # Config Server에서 찾을 설정 파일의 이름
  config:
    # configserver 주소를 지정하여 외부 설정을 가져오도록 설정한다.
    import: "optional:configserver:http://localhost:8888" 
  cloud:
    config:
      # 서버의 URI와 타임아웃 등 상세 설정을 추가할 수 있다.
      uri: http://localhost:8888
  profiles:
    active: dev # 적용할 환경 프로필 (dev/prod 등)

이 설정을 통해 클라이언트는 부팅 시 Config Server로부터 user-service-dev.yml 파일을 찾아 자동으로 병합한다.

 

🔍 Actuator refresh: 런타임 반영 전략

중앙화만으로는 부족하다. 운영 중에 설정을 변경했을 때 서비스 재기동 없이 이를 반영하는 것이 실무의 핵심이다. management.endpoints.web.exposure.include에 refresh를 열어두면, 설정 변경 후 특정 엔드포인트로 POST 요청을 보내는 것만으로 실시간 갱신이 가능하다.

# 설정 변경 후 특정 서비스에 반영 요청 (POST)
curl -X POST http://localhost:{service-port}/actuator/refresh

 

4. Multiple Profiles와 설정 우선순위

Multiple Profiles(다중 프로필)는 MSA 환경에서 코드의 재사용성과 환경의 독립성을 동시에 잡는 핵심 전략이다. 단순히 파일을 나누는 것을 넘어, 어떤 값이 최종적으로 주입되는지 그 우선순위 계층을 이해해야 설정 충돌을 막을 수 있다.

설정 우선순위의 법칙

Spring Cloud Config는 '가장 구체적인 설정이 가장 일반적인 설정을 덮어쓴다(Override)'는 원칙을 따른다. 서버가 여러 파일을 병합하여 클라이언트에게 줄 때 결정되는 순위는 다음과 같다.

순위	설정 소스 위치	파일명 예시 (name: user-service, profile: dev)	비고
1	원격 서비스별 프로필 설정	user-service-dev.yml	특정 서비스의 특정 환경 값 (가장 강력)
2	원격 서비스별 공통 설정	user-service.yml	특정 서비스의 모든 환경 공통 값
3	원격 전역 프로필 설정	application-dev.yml	모든 서비스의 특정 환경(dev) 공통 값
4	원격 전역 공통 설정	application.yml	모든 서비스, 모든 환경의 기본값
5	로컬 환경별 설정	src/main/resources/application-dev.yml	로컬 배포 시 사용되는 임시 값
6	로컬 기본 설정	src/main/resources/application.yml	최하위 베이스라인 값

핵심 포인트: 기본적으로 원격(Git)의 설정이 로컬의 설정을 완전히 무시하고 덮어쓴다. 만약 로컬 설정이 우선되어야 한다면 spring.cloud.config.override-local=false 설정을 별도로 조정해야 한다.

 

5. 실무 보충: 효율적인 운영을 위한 3가지 포인트

① 'default' 프로필의 영리한 활용

프로필을 지정하지 않았을 때 기본적으로 default라는 이름이 붙는다. Git 저장소에 application.yml 외에 application-default.yml을 만들어두면, 로컬 개발 시 아무 프로필을 주지 않아도 자동으로 적용되는 '개발자 로컬 표준'을 배포하기 용이하다.

② Search Paths를 통한 저장소 구조화

서비스가 100개가 넘어가면 Git 루트 디렉토리가 매우 지저분해진다. 이때 Config Server 설정에서 search-paths를 사용하면 폴더별로 체계적인 관리가 가능하다.

spring:
  cloud:
    config:
      server:
        git:
          uri: ...
          search-paths: 'user-service, order-service, common' # 폴더별 탐색 허용

③ 설정값의 암호화 (Encrypt/Decrypt)

실무에서는 DB 비밀번호나 API Key를 Git에 평문으로 올리는 것은 절대 금물이다. Config Server는 자체적으로 {cipher} 키워드를 이용한 암복호화를 지원한다.

• Git 저장소: password: '{cipher}AJKBDS...' 형태로 저장
• 복호화 주체: 서버가 전달할 때 복호화해서 주거나, 클라이언트가 직접 받아서 복호화하도록 설정할 수 있어 보안 사고를 미연에 방지할 수 있다.

6. 마무리하며

MSA에서 설정 관리는 단순히 파일을 옮기는 작업이 아니라, 시스템의 유연성과 안정성을 결정짓는 '논리적 연결 구조'를 설계하는 과정이다. Spring Cloud Config를 통해 설정 변경을 코드 배포와 분리하고, 버전 관리와 런타임 반영이 가능한 운영 흐름을 구축함으로써 비로소 성숙한 MSA 시스템이 완성된다.

오늘 정리한 계층적 우선순위 전략의 핵심은 "공통점은 최대한 아래 레이어(application.yml)로 내리고, 차이점은 최대한 위 레이어({service}-{profile}.yml)로 올리는 것"이다. 이 원칙이 잘 지켜진다면 서비스가 수백 개로 늘어나도 단 한 번의 Git 커밋으로 전체 시스템의 정책을 안전하게 변경할 수 있을 것이다.