Spring Cloud Config 완벽 가이드

마이크로서비스 아키텍처에서 설정을 중앙에서 관리하는 Spring Cloud Config를 초급 개발자도 쉽게 이해할 수 있도록 실무 스토리와 함께 설명합니다. Config Server 구축부터 환경별 설정 관리까지 단계별로 알아봅니다.

1. 외부 설정의 필요성

어느 날 김개발 씨가 회사에서 개발한 쇼핑몰 서비스를 배포하려고 했습니다. 개발 환경에서는 잘 동작하던 애플리케이션이 운영 서버에 올리니 데이터베이스 연결 오류가 발생했습니다.

알고 보니 운영 데이터베이스 주소를 바꾸는 것을 깊어 잊었던 것입니다.

외부 설정이란 애플리케이션 코드와 분리하여 설정 값을 관리하는 방식입니다. 마치 집 열쇠를 현관문에 붙여두지 않고 따로 보관하는 것과 같습니다.

이렇게 하면 환경에 따라 설정을 유연하게 변경할 수 있고, 보안도 강화됩니다.

다음 코드를 살펴봅시다.

// application.properties (개발 환경)
spring.datasource.url=jdbc:mysql://localhost:3306/dev_db
spring.datasource.username=dev_user
spring.datasource.password=dev_password

// 운영 환경으로 배포할 때마다 이 값들을 수동으로 변경해야 했습니다
// 문제: 실수 가능성, 보안 위험, 재배포 필요
// 해결: 외부 설정 관리 시스템 도입

김개발 씨는 입사 4개월 차 백엔드 개발자입니다. 오늘은 처음으로 혼자 개발한 주문 서비스를 운영 서버에 배포하는 날입니다.

긴장된 마음으로 배포 버튼을 눌렀는데, 갑자기 서비스가 제대로 동작하지 않습니다. 로그를 확인해 보니 데이터베이스 연결 오류가 발생했습니다.

"이상하다, 분명 개발 환경에서는 잘 됐는데..." 김개발 씨는 당황했습니다. 선배 개발자 박시니어 씨가 다가와 코드를 살펴봅니다.

"아, 설정 파일을 보니 개발 DB 주소가 하드코딩되어 있네요. 운영 DB 주소로 바꿔야 해요." 그렇다면 설정을 외부로 분리한다는 것은 정확히 무엇일까요?

쉽게 비유하자면, 설정 외부화는 마치 옷장을 정리하는 것과 같습니다. 여름옷과 겨울옷을 한 곳에 뒤섞어 두면 계절이 바뀔 때마다 찾기 힘듭니다.

하지만 계절별로 분류해서 보관하면 필요할 때 쉽게 꺼낼 수 있습니다. 애플리케이션도 마찬가지로 환경별 설정을 분리해서 관리하면 훨씬 편리합니다.

설정을 코드 안에 넣던 시절에는 어땠을까요? 개발자들은 환경이 바뀔 때마다 코드를 직접 수정해야 했습니다.

개발 환경에서 운영 환경으로 배포할 때마다 데이터베이스 주소, API 키, 포트 번호 등을 일일이 찾아서 바꿔야 했습니다. 이 과정에서 실수가 발생하기 쉬웠고, 한 번 실수하면 전체 서비스가 중단되는 대형 사고로 이어질 수 있었습니다.

더 큰 문제는 보안이었습니다. 데이터베이스 비밀번호나 API 키 같은 민감한 정보가 소스 코드에 그대로 노출되었습니다.

코드를 Git에 올리면 누구나 볼 수 있는 상황이었습니다. 실제로 많은 회사에서 이런 실수로 인해 보안 사고를 겪었습니다.

또한 설정 값을 바꾸려면 매번 코드를 수정하고 다시 컴파일해서 배포해야 했습니다. 간단한 포트 번호 하나를 바꾸는데도 전체 애플리케이션을 재배포해야 하는 비효율이 발생했습니다.

바로 이런 문제를 해결하기 위해 외부 설정 관리라는 개념이 등장했습니다. 외부 설정을 사용하면 코드 수정 없이 환경별로 다른 설정을 적용할 수 있습니다.

개발, 테스트, 운영 환경마다 별도의 설정 파일을 두고, 배포할 때 환경에 맞는 설정을 자동으로 선택하게 만들 수 있습니다. 또한 민감한 정보를 코드와 분리할 수 있어 보안이 강화됩니다.

데이터베이스 비밀번호는 별도의 안전한 저장소에 보관하고, 애플리케이션은 실행 시점에 이를 읽어오는 방식입니다. 무엇보다 설정 변경이 필요할 때 코드를 재배포하지 않아도 됩니다.

설정 파일만 수정하면 애플리케이션이 새로운 설정을 읽어와 적용합니다. 이는 운영 환경에서 매우 중요한 장점입니다.

마이크로서비스 아키텍처에서는 이런 필요성이 더욱 커집니다. 예를 들어 쇼핑몰 서비스가 주문, 결제, 배송, 재고 관리 등 10개의 작은 서비스로 나뉘어 있다고 가정해봅시다.

각 서비스마다 설정 파일이 있고, 데이터베이스 주소를 바꿔야 한다면 10개 서비스의 설정을 모두 수정해야 합니다. 이는 엄청난 수작업이며 실수할 가능성도 높습니다.

하지만 설정을 중앙에서 관리하면 어떨까요? 한 곳에서 설정을 바꾸면 모든 서비스가 자동으로 새로운 설정을 적용받습니다.

이것이 바로 Spring Cloud Config가 해결하려는 문제입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨는 이렇게 조언했습니다. "앞으로는 설정을 외부로 분리해서 관리하세요.

특히 마이크로서비스 환경에서는 Config Server를 사용하는 게 좋습니다." 설정 외부화의 필요성을 제대로 이해하면 더 안전하고 유지보수하기 쉬운 애플리케이션을 만들 수 있습니다. 이제 본격적으로 Spring Cloud Config를 배워볼 시간입니다.

실전 팁

💡 - 절대로 민감한 정보(비밀번호, API 키)를 코드에 하드코딩하지 마세요

환경별로 다른 설정이 필요하다면 프로파일(dev, test, prod)을 활용하세요
설정 변경 이력을 추적할 수 있도록 Git 같은 버전 관리 시스템을 사용하세요

2. Config Server 소개

김개발 씨는 이제 10개의 마이크로서비스를 관리하게 되었습니다. 각 서비스마다 설정 파일이 있고, 데이터베이스 주소가 바뀔 때마다 10개 파일을 수정해야 했습니다.

"더 좋은 방법이 없을까요?" 김개발 씨가 박시니어 씨에게 물었습니다.

Spring Cloud Config Server는 분산 시스템의 설정을 중앙에서 관리하는 서버입니다. 마치 도서관 사서가 모든 책을 한곳에서 관리하고 필요한 사람에게 제공하는 것처럼, Config Server는 모든 마이크로서비스의 설정을 중앙 저장소에서 관리하고 각 서비스에 제공합니다.

다음 코드를 살펴봅시다.

// Config Server 메인 애플리케이션
@SpringBootApplication
@EnableConfigServer  // Config Server 활성화
public class ConfigServerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigServerApplication.class, args);
    }

    // 이것만으로 Config Server가 준비됩니다
    // Git 저장소의 설정을 읽어서 클라이언트에게 제공합니다
}

박시니어 씨가 웃으면서 대답했습니다. "그럴 줄 알았어요.

바로 Spring Cloud Config Server를 쓰면 됩니다." 김개발 씨는 고개를 갸우뚱했습니다. "Config Server요?

그게 뭔가요?" 박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. "상상해보세요.

우리 회사에 10개의 팀이 있고, 각 팀마다 업무 매뉴얼이 있어요. 회사 정책이 바뀌면 10개 팀의 매뉴얼을 모두 수정해야겠죠?" 김개발 씨가 고개를 끄덕였습니다.

"네, 엄청 귀찮겠네요." "맞아요. 하지만 중앙 문서 관리 시스템이 있다면 어떨까요?

한 곳에서 정책을 업데이트하면 모든 팀이 자동으로 새로운 정책을 볼 수 있습니다. Config Server가 바로 이런 역할을 합니다." 그렇다면 Config Server는 정확히 어떻게 동작할까요?

Config Server는 중앙 집중식 설정 관리 서버입니다. Git 같은 버전 관리 시스템에 설정 파일을 저장하고, 각 마이크로서비스는 Config Server에 접속해서 자신에게 필요한 설정을 가져옵니다.

전통적인 방식에서는 각 서비스마다 설정 파일이 있었습니다. 주문 서비스에 application.properties, 결제 서비스에 application.properties, 배송 서비스에도 application.properties가 있었습니다.

모든 서비스가 같은 데이터베이스를 사용한다면, 데이터베이스 주소를 10번 중복해서 적어야 했습니다. 문제는 이 주소를 바꿔야 할 때 발생했습니다.

10개 파일을 모두 열어서 하나씩 수정해야 했고, 하나라도 빠뜨리면 그 서비스는 오류가 발생했습니다. 김개발 씨도 이런 실수로 몇 번이나 야근을 했습니다.

Config Server를 도입하면 이런 문제가 깔끔하게 해결됩니다. 모든 설정을 Git 저장소 한 곳에 모아둡니다.

예를 들어 config-repo라는 저장소에 order-service.properties, payment-service.properties 같은 파일을 저장합니다. 그리고 Config Server를 띄워서 이 Git 저장소를 바라보게 만듭니다.

각 마이크로서비스는 시작할 때 Config Server에 접속합니다. "안녕하세요, 저는 주문 서비스입니다.

제 설정 좀 주세요." 그러면 Config Server는 Git 저장소에서 order-service.properties를 읽어서 전달합니다. 이제 데이터베이스 주소를 바꿔야 한다면 어떻게 할까요?

Git 저장소의 설정 파일 하나만 수정하면 됩니다. 각 서비스는 재시작하거나 설정을 다시 읽어오면 자동으로 새로운 주소를 적용받습니다.

Config Server의 장점은 이것뿐만이 아닙니다. 첫째, 버전 관리가 가능합니다.

Git을 사용하므로 설정 변경 이력이 모두 기록됩니다. "누가 언제 무엇을 바꿨는지" 명확하게 추적할 수 있고, 문제가 생기면 이전 버전으로 쉽게 되돌릴 수 있습니다.

둘째, 환경별 설정을 깔끔하게 관리할 수 있습니다. 개발, 테스트, 운영 환경마다 다른 설정을 Git의 브랜치나 프로파일로 관리할 수 있습니다.

셋째, 보안이 강화됩니다. 민감한 정보는 암호화해서 저장할 수 있고, Config Server만 복호화 키를 갖고 있어 안전하게 관리됩니다.

실제 현업에서는 어떻게 활용할까요? 대형 이커머스 회사를 예로 들어봅시다.

수십 개의 마이크로서비스가 있고, 각 서비스는 데이터베이스, 캐시, 메시지 큐 등 다양한 외부 시스템과 연결됩니다. Config Server를 사용하면 한 곳에서 모든 연결 정보를 관리할 수 있습니다.

예를 들어 블랙프라이데이 같은 대규모 행사를 앞두고 데이터베이스를 업그레이드한다고 해봅시다. 새로운 DB 주소로 바꿔야 하는데, Config Server를 쓰면 설정 파일 하나만 수정하고 각 서비스를 재시작하면 됩니다.

수작업으로 수십 개 파일을 수정하는 것에 비하면 엄청난 시간 절약입니다. 구현 방법도 매우 간단합니다.

위의 코드를 보면 @EnableConfigServer 애노테이션 하나만 추가하면 Config Server가 만들어집니다. Spring Boot의 자동 설정 덕분에 복잡한 설정 없이도 쉽게 구축할 수 있습니다.

물론 주의할 점도 있습니다. Config Server가 중단되면 모든 서비스가 설정을 가져올 수 없게 됩니다.

따라서 Config Server 자체의 가용성을 높이는 것이 중요합니다. 보통 Config Server를 여러 개 띄워서 이중화하거나, 각 서비스에 설정 캐시를 두어 Config Server가 잠시 다운되어도 동작할 수 있게 만듭니다.

김개발 씨는 눈을 빛냈습니다. "와, 정말 편리하네요!

당장 우리 프로젝트에 적용하고 싶어요." 박시니어 씨가 웃으며 말했습니다. "좋아요.

그럼 지금부터 Config Server를 직접 만들어봅시다."

실전 팁

💡 - Config Server는 단일 장애점이 될 수 있으므로 반드시 이중화하세요

Git 커밋 메시지를 명확하게 작성하여 설정 변경 이력을 추적하기 쉽게 만드세요
민감한 정보는 반드시 암호화하여 저장하세요 (Spring Cloud Config의 암호화 기능 활용)

3. 프로젝트 생성

김개발 씨는 드디어 Config Server를 만들어보기로 했습니다. 하지만 어디서부터 시작해야 할지 막막했습니다.

"Spring Boot 프로젝트를 만들고, 의존성을 추가하고..." 박시니어 씨가 옆에서 차근차근 알려주기 시작했습니다.

Config Server 프로젝트는 일반 Spring Boot 프로젝트에 Config Server 의존성을 추가하여 만듭니다. Spring Initializr를 사용하면 몇 번의 클릭만으로 기본 구조를 생성할 수 있고, 설정 파일에 Git 저장소 정보만 추가하면 바로 사용할 수 있습니다.

다음 코드를 살펴봅시다.

// pom.xml - Config Server 의존성
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-config-server</artifactId>
</dependency>

// application.yml - Config Server 설정
server:
  port: 8888

spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/yourname/config-repo
          # Git 저장소 주소를 지정합니다

박시니어 씨가 브라우저를 열었습니다. "먼저 start.spring.io에 접속하세요.

Spring 프로젝트를 쉽게 만들어주는 사이트예요." 김개발 씨는 Spring Initializr 화면을 처음 봤습니다. "와, 이렇게 편한 도구가 있었네요!" "네, 요즘은 이걸 안 쓰는 개발자가 없죠.

자, 하나씩 설정해봅시다." 프로젝트 메타데이터를 입력하는 것부터 시작합니다. Project는 Maven이나 Gradle 중 선택할 수 있는데, 회사에서 주로 쓰는 빌드 도구를 선택하면 됩니다.

김개발 씨의 회사는 Maven을 사용하므로 Maven Project를 선택했습니다. Language는 당연히 Java입니다.

Spring Boot Version은 가장 안정적인 최신 버전을 선택합니다. 보통 SNAPSHOT이나 M(Milestone)이 붙지 않은 정식 릴리스 버전을 고릅니다.

Group은 회사의 도메인을 거꾸로 쓴 것이 관례입니다. 예를 들어 회사 도메인이 example.com이라면 com.example로 적습니다.

Artifact는 프로젝트 이름인데, config-server라고 적으면 됩니다. 이제 중요한 부분인 의존성 추가입니다.

오른쪽의 "ADD DEPENDENCIES" 버튼을 클릭하고 "Config Server"를 검색합니다. Spring Cloud Config Server가 나타나면 선택합니다.

이것 하나면 충분합니다. "이게 끝인가요?" 김개발 씨가 놀라워했습니다.

"네, 기본적으로는 이게 다예요. GENERATE 버튼을 누르면 프로젝트 zip 파일을 다운로드할 수 있어요." 다운로드한 파일을 압축 해제하고 IntelliJ나 Eclipse에서 열면 기본 프로젝트 구조가 보입니다.

src/main/java 아래에 메인 클래스가 있고, src/main/resources에 application.properties가 있습니다. 메인 클래스를 열어봅시다.

기본적으로 @SpringBootApplication 애노테이션이 붙어 있습니다. 여기에 @EnableConfigServer를 추가하기만 하면 Config Server가 됩니다.

정말 간단하지 않나요? 다음은 설정 파일을 작성할 차례입니다.

application.properties 대신 application.yml을 사용하는 것을 추천합니다. YAML 형식이 더 읽기 쉽고 계층 구조를 표현하기 좋습니다.

application.properties를 삭제하고 application.yml을 만듭니다. 위의 코드를 보면 설정이 매우 간단합니다.

server.port는 Config Server가 사용할 포트 번호입니다. 관례적으로 8888을 많이 사용합니다.

다른 포트를 써도 상관없습니다. spring.cloud.config.server.git.uri가 핵심입니다.

여기에 설정 파일이 저장된 Git 저장소 주소를 적습니다. GitHub, GitLab, Bitbucket 등 어떤 Git 서비스든 사용할 수 있습니다.

Git 저장소는 어떻게 준비할까요? GitHub에 새 저장소를 만듭니다.

이름은 config-repo라고 짓겠습니다. Public으로 만들면 별도의 인증 없이 사용할 수 있어 테스트하기 편리합니다.

실무에서는 당연히 Private 저장소를 사용하고 인증 정보를 추가해야 합니다. 저장소를 만들었으면 간단한 설정 파일을 하나 추가해봅시다.

application.yml이라는 파일을 만들고 다음처럼 작성합니다. message: Hello from Config Server 이 파일을 커밋하고 푸시합니다.

이제 Config Server가 이 파일을 읽을 수 있습니다. Private 저장소를 사용한다면 인증 정보를 추가해야 합니다.

spring: cloud: config: server: git: uri: https://github.com/yourname/config-repo username: your-username password: your-personal-access-token GitHub는 비밀번호 대신 Personal Access Token을 사용합니다. GitHub 설정에서 토큰을 생성하고 여기에 입력하면 됩니다.

이제 Config Server를 실행해봅시다. IDE에서 메인 클래스를 실행하거나, 터미널에서 mvn spring-boot:run을 입력합니다.

애플리케이션이 시작되고 8888 포트에서 대기합니다. 브라우저에서 http://localhost:8888/application/default에 접속해봅시다.

Git 저장소에 있는 설정이 JSON 형식으로 표시됩니다. message 속성이 "Hello from Config Server"로 나타나면 성공입니다!

김개발 씨는 신기해하며 화면을 바라봤습니다. "와, 정말 Git 저장소의 설정을 읽어오네요!" "맞아요.

이제 이 Config Server에 다른 마이크로서비스를 연결하면 됩니다. 하지만 그 전에 설정 저장소를 좀 더 체계적으로 구성해봅시다."

실전 팁

💡 - Spring Initializr를 사용하면 프로젝트 생성 시간을 크게 줄일 수 있습니다

application.properties보다 application.yml을 사용하면 가독성이 좋습니다
Config Server 포트는 8888을 사용하는 것이 관례이지만, 필요에 따라 변경 가능합니다

4. 설정 저장소 구성

Config Server는 잘 실행되었지만, Git 저장소에 application.yml 하나만 있어서는 여러 서비스를 관리할 수 없습니다. 김개발 씨는 주문 서비스, 결제 서비스, 배송 서비스의 설정을 각각 분리하고 싶었습니다.

"어떻게 구성하면 좋을까요?" 박시니어 씨가 체계적인 구조를 알려주기 시작했습니다.

설정 저장소 구성은 각 서비스별로 별도의 설정 파일을 만들고, 공통 설정은 application.yml에 두는 방식입니다. 마치 회사에서 전사 공통 규정과 부서별 규정을 나누어 관리하는 것처럼, Config Server도 공통 설정과 서비스별 설정을 분리하여 관리합니다.

다음 코드를 살펴봅시다.

# config-repo 저장소 구조
config-repo/
  application.yml          # 모든 서비스의 공통 설정
  order-service.yml        # 주문 서비스 전용 설정
  payment-service.yml      # 결제 서비스 전용 설정
  shipping-service.yml     # 배송 서비스 전용 설정

# application.yml - 공통 설정
logging:
  level:
    root: INFO

# order-service.yml - 주문 서비스 설정
server:
  port: 8081
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/order_db

박시니어 씨가 화이트보드에 폴더 구조를 그렸습니다. "설정 저장소를 잘 구성하는 것이 정말 중요해요.

나중에 서비스가 많아지면 관리가 힘들어지거든요." 김개발 씨는 메모를 준비하며 집중했습니다. "어떻게 구성하면 좋을까요?" "먼저 파일 이름 규칙을 알아야 해요.

Config Server는 특정한 규칙으로 파일을 찾습니다." Config Server는 파일 이름으로 어떤 서비스의 설정인지 판단합니다. 기본 규칙은 이렇습니다.

서비스 이름이 order-service라면, Config Server는 order-service.yml 파일을 찾습니다. 서비스 이름이 payment-service라면 payment-service.yml을 찾습니다.

매우 직관적이죠? 여기서 재미있는 점은 application.yml은 특별한 파일이라는 것입니다.

모든 서비스가 공통으로 사용하는 설정을 이 파일에 넣습니다. 예를 들어 로깅 레벨, 공통 데이터베이스 설정, 캐시 설정 같은 것들입니다.

각 서비스가 Config Server에 접속하면 무슨 일이 벌어질까요? 주문 서비스가 접속하면 Config Server는 먼저 application.yml을 읽습니다.

그다음 order-service.yml을 읽습니다. 두 파일의 설정을 합쳐서 주문 서비스에 전달합니다.

만약 같은 속성이 두 파일에 모두 있다면 order-service.yml의 값이 우선합니다. "아, 그럼 공통 설정은 application.yml에 두고, 서비스별로 다른 부분만 각 파일에 두면 되겠네요!" 김개발 씨가 이해했습니다.

"정확해요! 이렇게 하면 중복을 최소화하고 관리도 쉬워집니다." 실제로 파일을 만들어봅시다.

config-repo 저장소에 application.yml을 만들고 모든 서비스가 공통으로 사용할 설정을 넣습니다. 예를 들어 로깅 레벨을 INFO로 통일하고, 모든 서비스가 같은 Redis 서버를 사용한다면 Redis 주소를 여기에 넣습니다.

다음으로 order-service.yml을 만듭니다. 주문 서비스의 포트는 8081이고, 주문 전용 데이터베이스는 order_db입니다.

이런 서비스별 정보를 이 파일에 넣습니다. payment-service.yml도 비슷하게 만듭니다.

포트는 8082, 데이터베이스는 payment_db입니다. 결제 API 키 같은 결제 서비스만 필요한 설정도 여기에 넣습니다.

이렇게 구성하면 어떤 장점이 있을까요? 첫째, 중복이 줄어듭니다.

로깅 레벨 같은 공통 설정을 10번 반복해서 쓸 필요가 없습니다. application.yml에 한 번만 쓰면 모든 서비스가 사용합니다.

둘째, 변경이 쉬워집니다. 로깅 레벨을 DEBUG로 바꾸고 싶다면 application.yml 한 곳만 수정하면 됩니다.

모든 서비스가 자동으로 새 설정을 적용받습니다. 셋째, 서비스별 커스터마이징이 가능합니다.

특정 서비스만 로깅 레벨을 WARN으로 바꾸고 싶다면 그 서비스의 yml 파일에만 추가하면 됩니다. 공통 설정을 덮어쓸 수 있습니다.

폴더 구조로 정리할 수도 있습니다. 서비스가 많아지면 파일도 많아집니다.

이때는 폴더로 분류하면 좋습니다. 예를 들어 order, payment, shipping 폴더를 만들고 각 폴더 안에 설정 파일을 넣습니다.

하지만 이 경우 Config Server 설정에 search-paths를 추가해야 합니다. spring: cloud: config: server: git: uri: https://github.com/yourname/config-repo search-paths: '{application}' 이렇게 하면 order-service를 찾을 때 order 폴더 안을 검색합니다.

폴더 구조가 깔끔해지지만 설정이 조금 복잡해지는 단점이 있습니다. 서비스가 10개 이하라면 폴더 없이 평평하게 두는 것을 추천합니다.

실무에서는 어떻게 구성할까요? 대부분의 회사에서는 팀별로 저장소를 나눕니다.

주문팀은 order-config-repo, 결제팀은 payment-config-repo를 사용합니다. 각 팀이 자기 설정을 독립적으로 관리할 수 있어 편리합니다.

이 경우 Config Server에 여러 Git 저장소를 등록합니다. Spring Cloud Config는 패턴 매칭으로 어떤 저장소를 사용할지 결정할 수 있습니다.

order로 시작하는 서비스는 order-config-repo를 보고, payment로 시작하는 서비스는 payment-config-repo를 봅니다. 주의할 점도 있습니다.

파일 이름과 서비스 이름이 정확히 일치해야 합니다. order-service라는 이름으로 서비스를 등록했는데 파일 이름이 orderservice.yml이면 Config Server가 찾지 못합니다.

하이픈 하나도 중요합니다. 또한 YAML 문법을 정확히 지켜야 합니다.

들여쓰기가 틀리면 파일을 제대로 읽지 못합니다. 온라인 YAML 검증 도구를 사용해서 문법을 확인하는 것이 좋습니다.

김개발 씨는 열심히 메모했습니다. "공통 설정과 서비스별 설정을 나누고, 파일 이름 규칙을 지키는 게 중요하군요!" 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. 이제 환경별 설정을 나누는 방법도 배워봅시다."

실전 팁

💡 - 공통 설정은 application.yml에, 서비스별 설정은 {서비스명}.yml에 분리하세요

파일 이름과 서비스 이름(spring.application.name)이 정확히 일치해야 합니다
YAML 문법 오류를 방지하기 위해 온라인 검증 도구를 활용하세요

5. 환경별 설정

김개발 씨의 주문 서비스는 개발 환경에서 localhost 데이터베이스를 사용하지만, 운영 환경에서는 AWS RDS를 사용해야 합니다. 하나의 설정 파일로 어떻게 두 환경을 모두 지원할 수 있을까요?

"프로파일을 사용하면 됩니다." 박시니어 씨가 설명하기 시작했습니다.

환경별 설정은 Spring Profile을 활용하여 dev, test, prod 등 환경마다 다른 설정을 적용하는 방식입니다. 마치 여름옷과 겨울옷을 나누어 보관하듯이, 개발 환경 설정과 운영 환경 설정을 분리하여 관리하면 실수를 줄이고 배포를 안전하게 할 수 있습니다.

다음 코드를 살펴봅시다.

# order-service.yml - 기본 설정
server:
  port: 8081

# order-service-dev.yml - 개발 환경
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/order_db
    username: dev_user

# order-service-prod.yml - 운영 환경
spring:
  datasource:
    url: jdbc:mysql://prod-db.aws.com:3306/order_db
    username: prod_user

# 서비스 시작 시 프로파일 지정
# java -jar order-service.jar --spring.profiles.active=prod

박시니어 씨가 실제 사고 사례를 이야기했습니다. "예전에 한 동료가 개발 DB 주소를 운영에 배포한 적이 있어요.

운영 서비스가 개발 DB에 접속해서 난리가 났죠." 김개발 씨는 얼굴이 하얘졌습니다. "어떻게 그런 일이..." "설정을 환경별로 제대로 분리하지 않았기 때문이에요.

수동으로 바꾸다 보면 실수하게 마련입니다. 그래서 프로파일이 필요합니다." Spring Profile은 환경을 구분하는 강력한 기능입니다.

기본 개념은 간단합니다. 같은 서비스라도 dev, test, prod 같은 프로파일을 지정하면 각각 다른 설정을 사용할 수 있습니다.

애플리케이션을 시작할 때 어떤 프로파일을 사용할지 지정하면 됩니다. Config Server에서 프로파일을 사용하는 방법도 매우 직관적입니다.

파일 이름에 프로파일을 붙이면 됩니다. order-service.yml은 기본 설정이고, order-service-dev.yml은 dev 프로파일 설정, order-service-prod.yml은 prod 프로파일 설정입니다.

서비스를 시작할 때 --spring.profiles.active=dev를 추가하면 dev 프로파일이 활성화됩니다. Config Server는 먼저 application.yml을 읽고, 그다음 order-service.yml을 읽고, 마지막으로 order-service-dev.yml을 읽습니다.

나중에 읽은 파일의 값이 이전 값을 덮어씁니다. "그럼 운영 환경에서는 prod를 지정하면 되겠네요?" 김개발 씨가 물었습니다.

"정확해요. --spring.profiles.active=prod로 시작하면 order-service-prod.yml의 설정을 사용합니다." 각 프로파일 파일에는 무엇을 넣을까요?

개발 환경(dev)에는 로컬 데이터베이스 주소, 더미 API 키, 디버그 로깅 레벨 같은 것을 넣습니다. 개발자가 로컬에서 쉽게 테스트할 수 있도록 설정합니다.

테스트 환경(test)에는 테스트 서버의 주소, 테스트 계정 정보 같은 것을 넣습니다. QA 팀이 테스트할 때 사용하는 환경입니다.

운영 환경(prod)에는 실제 데이터베이스 주소, 진짜 API 키, 경고 이상의 로깅 레벨 같은 것을 넣습니다. 가장 신중하게 관리해야 하는 설정입니다.

파일 구조를 정리해봅시다. config-repo 저장소에 다음 파일들이 있습니다: application.yml, application-dev.yml, application-prod.yml, order-service.yml, order-service-dev.yml, order-service-prod.yml.

application.yml에는 모든 환경에서 공통으로 사용하는 설정을, application-dev.yml에는 모든 서비스의 개발 환경 공통 설정을 넣습니다. 예를 들어 모든 서비스가 개발 환경에서는 DEBUG 로깅을 사용한다면 application-dev.yml에 넣으면 됩니다.

우선순위는 어떻게 될까요? 가장 낮은 우선순위는 application.yml입니다.

그다음이 application-{profile}.yml, 그다음이 {서비스명}.yml, 가장 높은 우선순위는 {서비스명}-{profile}.yml입니다. 나중에 적용되는 설정이 이전 설정을 덮어씁니다.

예를 들어 로깅 레벨이 application.yml에는 INFO, application-dev.yml에는 DEBUG, order-service-dev.yml에는 TRACE라고 되어 있다면 최종적으로 TRACE가 적용됩니다. 실무에서는 보안이 중요합니다.

운영 환경의 데이터베이스 비밀번호나 API 키는 절대 평문으로 Git에 올리면 안 됩니다. Config Server의 암호화 기능을 사용하거나, Vault 같은 별도의 보안 저장소를 사용해야 합니다.

Config Server는 {cipher}로 시작하는 암호화된 값을 자동으로 복호화해줍니다. 설정 파일에는 암호화된 값을 넣고, Config Server만 복호화 키를 갖고 있으면 안전합니다.

환경별 배포는 어떻게 할까요? Docker를 사용한다면 환경 변수로 프로파일을 지정할 수 있습니다.

ENV SPRING_PROFILES_ACTIVE=prod 같은 방식입니다. Kubernetes라면 ConfigMap이나 Secret에 프로파일을 저장하고 Pod에 주입합니다.

개발자 로컬 환경에서는 IDE 설정에 프로파일을 지정하면 편리합니다. IntelliJ의 Run Configuration에서 Active Profiles에 dev를 넣으면 항상 dev 프로파일로 실행됩니다.

주의할 점도 있습니다. 프로파일 파일이 너무 많아지면 관리가 힘들어집니다.

dev, test, prod 정도로 최소화하는 것이 좋습니다. 개발자마다 다른 프로파일을 만들면 혼란스러워집니다.

또한 프로파일을 잘못 지정해서 배포하는 실수를 방지해야 합니다. CI/CD 파이프라인에서 환경에 맞는 프로파일이 지정되었는지 자동으로 검증하는 것이 좋습니다.

김개발 씨는 이제 확신이 생겼습니다. "프로파일로 환경을 나누면 실수할 일이 없겠네요!" "맞아요.

하지만 설정 우선순위를 제대로 이해해야 혼란을 피할 수 있어요. 다음으로 우선순위를 자세히 알아봅시다."

실전 팁

💡 - 환경은 dev, test, prod 정도로 최소화하여 관리 복잡도를 줄이세요

운영 환경의 민감한 정보는 반드시 암호화하거나 별도 보안 저장소를 사용하세요
CI/CD 파이프라인에서 프로파일이 올바르게 설정되었는지 자동 검증하세요

6. 설정 우선순위

김개발 씨는 설정 파일이 점점 많아지면서 혼란스러워졌습니다. application.yml, order-service.yml, order-service-dev.yml에 같은 속성이 여러 번 정의되어 있는데, 최종적으로 어떤 값이 적용되는지 헷갈렸습니다.

"이럴 때 우선순위를 정확히 알아야 해요." 박시니어 씨가 설명을 시작했습니다.

설정 우선순위는 여러 설정 파일에 같은 속성이 있을 때 어떤 값을 사용할지 결정하는 규칙입니다. 마치 법에서 헌법이 법률보다 우선하고, 법률이 시행령보다 우선하는 것처럼, Config Server도 명확한 우선순위 규칙이 있습니다.

다음 코드를 살펴봅시다.

# 우선순위 (낮음 → 높음)
# 1. application.yml (모든 서비스 공통 기본 설정)
# 2. application-{profile}.yml (모든 서비스 프로파일 설정)
# 3. {서비스명}.yml (특정 서비스 기본 설정)
# 4. {서비스명}-{profile}.yml (특정 서비스 프로파일 설정)

# 예시: order-service를 dev 프로파일로 실행
# application.yml
logging.level.root: INFO

# application-dev.yml
logging.level.root: DEBUG

# order-service.yml
logging.level.root: WARN

# order-service-dev.yml
logging.level.root: TRACE

# 최종 결과: TRACE (가장 높은 우선순위)

박시니어 씨가 4장의 카드를 꺼내 책상에 놓았습니다. "이 카드들이 설정 파일이라고 생각해보세요.

아래에 있는 카드일수록 우선순위가 높습니다." 김개발 씨는 카드를 하나씩 살펴봤습니다. "맨 아래가 order-service-dev.yml이네요?" "맞아요.

가장 구체적인 설정일수록 우선순위가 높습니다. 이게 핵심 원칙이에요." 우선순위를 이해하는 가장 쉬운 방법은 구체성입니다.

가장 일반적인 설정은 application.yml입니다. 모든 서비스, 모든 환경에 적용되는 설정입니다.

따라서 우선순위가 가장 낮습니다. 그다음은 application-dev.yml입니다.

모든 서비스에 적용되지만 dev 환경에만 적용됩니다. 조금 더 구체적이므로 application.yml보다 우선순위가 높습니다.

order-service.yml은 주문 서비스에만 적용되는 설정입니다. 특정 서비스를 지정했으므로 더 구체적입니다.

application-dev.yml보다 우선순위가 높습니다. 가장 구체적인 것은 order-service-dev.yml입니다.

특정 서비스(order-service)의 특정 환경(dev) 설정입니다. 따라서 우선순위가 가장 높습니다.

실제 예제로 이해해봅시다. 로깅 레벨을 설정한다고 가정합니다.

application.yml에는 INFO, application-dev.yml에는 DEBUG, order-service.yml에는 WARN, order-service-dev.yml에는 TRACE로 되어 있습니다. order-service를 dev 프로파일로 실행하면 어떻게 될까요?

Config Server는 4개 파일을 모두 읽습니다. 읽는 순서는 우선순위가 낮은 것부터입니다.

먼저 application.yml을 읽어서 로깅 레벨을 INFO로 설정합니다. 그다음 application-dev.yml을 읽어서 DEBUG로 덮어씁니다.

그다음 order-service.yml을 읽어서 WARN으로 덮어씁니다. 마지막으로 order-service-dev.yml을 읽어서 TRACE로 덮어씁니다.

최종 결과는 TRACE입니다. "아, 나중에 읽은 값이 이전 값을 덮어쓰는 거네요!" 김개발 씨가 이해했습니다.

"정확해요. 마치 페인트를 여러 번 칠하는 것과 같습니다.

마지막 칠한 색이 보이는 거죠." 같은 속성이 일부 파일에만 있다면 어떻게 될까요? 예를 들어 데이터베이스 URL은 order-service-dev.yml에만 있고 다른 파일에는 없다면, 당연히 order-service-dev.yml의 값을 사용합니다.

덮어쓸 이전 값이 없으니까요. 반대로 로깅 레벨이 application.yml에만 있고 다른 파일에는 없다면, application.yml의 값을 사용합니다.

아무도 덮어쓰지 않았으니까요. 이런 방식 덕분에 중복을 최소화할 수 있습니다.

공통 설정은 application.yml에 한 번만 쓰고, 특정 환경이나 서비스에서 다른 값이 필요할 때만 해당 파일에 추가하면 됩니다. 모든 파일에 모든 속성을 반복해서 쓸 필요가 없습니다.

실무에서 자주 하는 실수가 있습니다. 우선순위를 잘못 이해하고 application-dev.yml에 중요한 설정을 넣었는데, order-service.yml에도 같은 속성이 있어서 덮어써진 경우입니다.

개발자는 dev 프로파일을 썼으니 application-dev.yml의 값이 적용될 거라고 생각하지만, 실제로는 order-service.yml의 값이 적용됩니다. 이런 혼란을 피하려면 명확한 규칙을 정해야 합니다.

공통 설정은 application.yml에만 넣습니다. 환경별로 다른 값이 필요하면 application-{profile}.yml에 넣습니다.

서비스별로 다른 값이 필요하면 {서비스명}.yml에 넣습니다. 서비스와 환경 모두 구체적으로 지정해야 한다면 {서비스명}-{profile}.yml에 넣습니다.

Config Server는 실제로 어떤 설정을 적용했는지 확인할 수 있습니다. 브라우저에서 http://localhost:8888/order-service/dev에 접속하면 JSON 형식으로 최종 설정을 보여줍니다.

어떤 파일에서 읽었는지, 최종 값이 무엇인지 명확하게 나옵니다. 설정이 예상과 다를 때 이 방법으로 디버깅할 수 있습니다.

스프링 부트 액추에이터를 사용하면 더 자세한 정보를 볼 수 있습니다. /actuator/env 엔드포인트에 접속하면 모든 설정의 출처와 값을 보여줍니다.

어떤 파일에서 왔는지, 시스템 환경 변수인지, 커맨드 라인 인자인지 모두 표시됩니다. 설정 문제를 해결할 때 매우 유용합니다.

김개발 씨는 머리가 정리되었습니다. "구체적일수록 우선순위가 높다는 원칙만 기억하면 되겠네요!" 박시니어 씨가 미소 지었습니다.

"맞아요. 이제 Config Server의 핵심을 모두 배웠어요.

실제 프로젝트에 적용해보세요. 설정 관리가 정말 편해질 거예요." 김개발 씨는 자신감이 생겼습니다.

이제 마이크로서비스 환경에서 설정을 체계적으로 관리할 수 있을 것 같았습니다. Config Server는 복잡해 보였지만, 원리를 이해하고 나니 매우 직관적이었습니다.

가장 중요한 것은 명확한 규칙을 정하고 일관성 있게 적용하는 것입니다. 공통 설정, 환경별 설정, 서비스별 설정을 체계적으로 나누고, 우선순위 원칙을 지키면 혼란 없이 관리할 수 있습니다.

실전 팁

💡 - 구체적일수록 우선순위가 높다는 원칙을 기억하세요

설정이 예상과 다를 때는 Config Server의 엔드포인트로 최종 설정을 확인하세요
팀 내에서 명확한 설정 파일 규칙을 정하고 문서화하여 혼란을 방지하세요

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Spring Cloud#Config Server#Microservices#Configuration Management#Git Repository

Spring Cloud Config 완벽 가이드

# Spring Cloud Config 완벽 가이드 마이크로서비스 아키텍처에서 설정을 중앙에서 관리하는 Spring Cloud Config를 초급 개발자도 쉽게 이해할 수 있도록 실무 스토리와 함께 설명합니다. Config Server 구축부터 환경별 설정 관리까지 단계별로 알아봅니다. --- ## 목차 1. [외부_설정의_필요성](#외부-설정의-필요성) 2. [Config_Server_소개](#config-server-소개) 3. [프로젝트_생성](#프로젝트-생성) 4. [설정_저장소_구성](#설정-저장소-구성) 5. [환경별_설정](#환경별-설정) 6. [설정_우선순위](#설정-우선순위) --- ## 1. 외부_설정의_필요성 어느 날 김개발 씨가 회사에서 개발한 쇼핑몰 서비스를 배포하려고 했습니다. 개발 환경에서는 잘 동작하던 애플리케이션이 운영 서버에 올리니 데이터베이스 연결 오류가 발생했습니다. 알고 보니 운영 데이터베이스 주소를 바꾸는 것을 깊어 잊었던 것입니다. **외부 설정**이란 애플리케이션 코드와 분리하여 설정 값을 관리하는 방식입니다. 마치 집 열쇠를 현관문에 붙여두지 않고 따로 보관하는 것과 같습니다. 이렇게 하면 환경에 따라 설정을 유연하게 변경할 수 있고, 보안도 강화됩니다. 다음 코드를 살펴봅시다. ```java // application.properties (개발 환경) spring.datasource.url=jdbc:mysql://localhost:3306/dev_db spring.datasource.username=dev_user spring.datasource.password=dev_password // 운영 환경으로 배포할 때마다 이 값들을 수동으로 변경해야 했습니다 // 문제: 실수 가능성, 보안 위험, 재배포 필요 // 해결: 외부 설정 관리 시스템 도입 ``` 김개발 씨는 입사 4개월 차 백엔드 개발자입니다. 오늘은 처음으로 혼자 개발한 주문 서비스를 운영 서버에 배포하는 날입니다. 긴장된 마음으로 배포 버튼을 눌렀는데, 갑자기 서비스가 제대로 동작하지 않습니다. 로그를 확인해 보니 데이터베이스 연결 오류가 발생했습니다. "이상하다, 분명 개발 환경에서는 잘 됐는데..." 김개발 씨는 당황했습니다. 선배 개발자 박시니어 씨가 다가와 코드를 살펴봅니다. "아, 설정 파일을 보니 개발 DB 주소가 하드코딩되어 있네요. 운영 DB 주소로 바꿔야 해요." 그렇다면 설정을 외부로 분리한다는 것은 정확히 무엇일까요? 쉽게 비유하자면, 설정 외부화는 마치 옷장을 정리하는 것과 같습니다. 여름옷과 겨울옷을 한 곳에 뒤섞어 두면 계절이 바뀔 때마다 찾기 힘듭니다. 하지만 계절별로 분류해서 보관하면 필요할 때 쉽게 꺼낼 수 있습니다. 애플리케이션도 마찬가지로 환경별 설정을 분리해서 관리하면 훨씬 편리합니다. 설정을 코드 안에 넣던 시절에는 어땠을까요? 개발자들은 환경이 바뀔 때마다 코드를 직접 수정해야 했습니다. 개발 환경에서 운영 환경으로 배포할 때마다 데이터베이스 주소, API 키, 포트 번호 등을 일일이 찾아서 바꿔야 했습니다. 이 과정에서 실수가 발생하기 쉬웠고, 한 번 실수하면 전체 서비스가 중단되는 대형 사고로 이어질 수 있었습니다. 더 큰 문제는 보안이었습니다. 데이터베이스 비밀번호나 API 키 같은 민감한 정보가 소스 코드에 그대로 노출되었습니다. 코드를 Git에 올리면 누구나 볼 수 있는 상황이었습니다. 실제로 많은 회사에서 이런 실수로 인해 보안 사고를 겪었습니다. 또한 설정 값을 바꾸려면 매번 코드를 수정하고 다시 컴파일해서 배포해야 했습니다. 간단한 포트 번호 하나를 바꾸는데도 전체 애플리케이션을 재배포해야 하는 비효율이 발생했습니다. 바로 이런 문제를 해결하기 위해 **외부 설정 관리**라는 개념이 등장했습니다. 외부 설정을 사용하면 코드 수정 없이 환경별로 다른 설정을 적용할 수 있습니다. 개발, 테스트, 운영 환경마다 별도의 설정 파일을 두고, 배포할 때 환경에 맞는 설정을 자동으로 선택하게 만들 수 있습니다. 또한 민감한 정보를 코드와 분리할 수 있어 보안이 강화됩니다. 데이터베이스 비밀번호는 별도의 안전한 저장소에 보관하고, 애플리케이션은 실행 시점에 이를 읽어오는 방식입니다. 무엇보다 설정 변경이 필요할 때 코드를 재배포하지 않아도 됩니다. 설정 파일만 수정하면 애플리케이션이 새로운 설정을 읽어와 적용합니다. 이는 운영 환경에서 매우 중요한 장점입니다. 마이크로서비스 아키텍처에서는 이런 필요성이 더욱 커집니다. 예를 들어 쇼핑몰 서비스가 주문, 결제, 배송, 재고 관리 등 10개의 작은 서비스로 나뉘어 있다고 가정해봅시다. 각 서비스마다 설정 파일이 있고, 데이터베이스 주소를 바꿔야 한다면 10개 서비스의 설정을 모두 수정해야 합니다. 이는 엄청난 수작업이며 실수할 가능성도 높습니다. 하지만 설정을 중앙에서 관리하면 어떨까요? 한 곳에서 설정을 바꾸면 모든 서비스가 자동으로 새로운 설정을 적용받습니다. 이것이 바로 **Spring Cloud Config**가 해결하려는 문제입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨는 이렇게 조언했습니다. "앞으로는 설정을 외부로 분리해서 관리하세요. 특히 마이크로서비스 환경에서는 Config Server를 사용하는 게 좋습니다." 설정 외부화의 필요성을 제대로 이해하면 더 안전하고 유지보수하기 쉬운 애플리케이션을 만들 수 있습니다. 이제 본격적으로 Spring Cloud Config를 배워볼 시간입니다. **실전 팁** 💡 - 절대로 민감한 정보(비밀번호, API 키)를 코드에 하드코딩하지 마세요 - 환경별로 다른 설정이 필요하다면 프로파일(dev, test, prod)을 활용하세요 - 설정 변경 이력을 추적할 수 있도록 Git 같은 버전 관리 시스템을 사용하세요 --- ## 2. Config_Server_소개 김개발 씨는 이제 10개의 마이크로서비스를 관리하게 되었습니다. 각 서비스마다 설정 파일이 있고, 데이터베이스 주소가 바뀔 때마다 10개 파일을 수정해야 했습니다. "더 좋은 방법이 없을까요?" 김개발 씨가 박시니어 씨에게 물었습니다. **Spring Cloud Config Server**는 분산 시스템의 설정을 중앙에서 관리하는 서버입니다. 마치 도서관 사서가 모든 책을 한곳에서 관리하고 필요한 사람에게 제공하는 것처럼, Config Server는 모든 마이크로서비스의 설정을 중앙 저장소에서 관리하고 각 서비스에 제공합니다. 다음 코드를 살펴봅시다. ```java // Config Server 메인 애플리케이션 @SpringBootApplication @EnableConfigServer // Config Server 활성화 public class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); } // 이것만으로 Config Server가 준비됩니다 // Git 저장소의 설정을 읽어서 클라이언트에게 제공합니다 } ``` 박시니어 씨가 웃으면서 대답했습니다. "그럴 줄 알았어요. 바로 Spring Cloud Config Server를 쓰면 됩니다." 김개발 씨는 고개를 갸우뚱했습니다. "Config Server요? 그게 뭔가요?" 박시니어 씨는 화이트보드에 그림을 그리기 시작했습니다. "상상해보세요. 우리 회사에 10개의 팀이 있고, 각 팀마다 업무 매뉴얼이 있어요. 회사 정책이 바뀌면 10개 팀의 매뉴얼을 모두 수정해야겠죠?" 김개발 씨가 고개를 끄덕였습니다. "네, 엄청 귀찮겠네요." "맞아요. 하지만 중앙 문서 관리 시스템이 있다면 어떨까요? 한 곳에서 정책을 업데이트하면 모든 팀이 자동으로 새로운 정책을 볼 수 있습니다. Config Server가 바로 이런 역할을 합니다." 그렇다면 Config Server는 정확히 어떻게 동작할까요? Config Server는 중앙 집중식 설정 관리 서버입니다. Git 같은 버전 관리 시스템에 설정 파일을 저장하고, 각 마이크로서비스는 Config Server에 접속해서 자신에게 필요한 설정을 가져옵니다. 전통적인 방식에서는 각 서비스마다 설정 파일이 있었습니다. 주문 서비스에 application.properties, 결제 서비스에 application.properties, 배송 서비스에도 application.properties가 있었습니다. 모든 서비스가 같은 데이터베이스를 사용한다면, 데이터베이스 주소를 10번 중복해서 적어야 했습니다. 문제는 이 주소를 바꿔야 할 때 발생했습니다. 10개 파일을 모두 열어서 하나씩 수정해야 했고, 하나라도 빠뜨리면 그 서비스는 오류가 발생했습니다. 김개발 씨도 이런 실수로 몇 번이나 야근을 했습니다. Config Server를 도입하면 이런 문제가 깔끔하게 해결됩니다. 모든 설정을 Git 저장소 한 곳에 모아둡니다. 예를 들어 config-repo라는 저장소에 order-service.properties, payment-service.properties 같은 파일을 저장합니다. 그리고 Config Server를 띄워서 이 Git 저장소를 바라보게 만듭니다. 각 마이크로서비스는 시작할 때 Config Server에 접속합니다. "안녕하세요, 저는 주문 서비스입니다. 제 설정 좀 주세요." 그러면 Config Server는 Git 저장소에서 order-service.properties를 읽어서 전달합니다. 이제 데이터베이스 주소를 바꿔야 한다면 어떻게 할까요? Git 저장소의 설정 파일 하나만 수정하면 됩니다. 각 서비스는 재시작하거나 설정을 다시 읽어오면 자동으로 새로운 주소를 적용받습니다. Config Server의 장점은 이것뿐만이 아닙니다. 첫째, **버전 관리**가 가능합니다. Git을 사용하므로 설정 변경 이력이 모두 기록됩니다. "누가 언제 무엇을 바꿨는지" 명확하게 추적할 수 있고, 문제가 생기면 이전 버전으로 쉽게 되돌릴 수 있습니다. 둘째, **환경별 설정**을 깔끔하게 관리할 수 있습니다. 개발, 테스트, 운영 환경마다 다른 설정을 Git의 브랜치나 프로파일로 관리할 수 있습니다. 셋째, **보안**이 강화됩니다. 민감한 정보는 암호화해서 저장할 수 있고, Config Server만 복호화 키를 갖고 있어 안전하게 관리됩니다. 실제 현업에서는 어떻게 활용할까요? 대형 이커머스 회사를 예로 들어봅시다. 수십 개의 마이크로서비스가 있고, 각 서비스는 데이터베이스, 캐시, 메시지 큐 등 다양한 외부 시스템과 연결됩니다. Config Server를 사용하면 한 곳에서 모든 연결 정보를 관리할 수 있습니다. 예를 들어 블랙프라이데이 같은 대규모 행사를 앞두고 데이터베이스를 업그레이드한다고 해봅시다. 새로운 DB 주소로 바꿔야 하는데, Config Server를 쓰면 설정 파일 하나만 수정하고 각 서비스를 재시작하면 됩니다. 수작업으로 수십 개 파일을 수정하는 것에 비하면 엄청난 시간 절약입니다. 구현 방법도 매우 간단합니다. 위의 코드를 보면 `@EnableConfigServer` 애노테이션 하나만 추가하면 Config Server가 만들어집니다. Spring Boot의 자동 설정 덕분에 복잡한 설정 없이도 쉽게 구축할 수 있습니다. 물론 주의할 점도 있습니다. Config Server가 중단되면 모든 서비스가 설정을 가져올 수 없게 됩니다. 따라서 Config Server 자체의 가용성을 높이는 것이 중요합니다. 보통 Config Server를 여러 개 띄워서 이중화하거나, 각 서비스에 설정 캐시를 두어 Config Server가 잠시 다운되어도 동작할 수 있게 만듭니다. 김개발 씨는 눈을 빛냈습니다. "와, 정말 편리하네요! 당장 우리 프로젝트에 적용하고 싶어요." 박시니어 씨가 웃으며 말했습니다. "좋아요. 그럼 지금부터 Config Server를 직접 만들어봅시다." **실전 팁** 💡 - Config Server는 단일 장애점이 될 수 있으므로 반드시 이중화하세요 - Git 커밋 메시지를 명확하게 작성하여 설정 변경 이력을 추적하기 쉽게 만드세요 - 민감한 정보는 반드시 암호화하여 저장하세요 (Spring Cloud Config의 암호화 기능 활용) --- ## 3. 프로젝트_생성 김개발 씨는 드디어 Config Server를 만들어보기로 했습니다. 하지만 어디서부터 시작해야 할지 막막했습니다. "Spring Boot 프로젝트를 만들고, 의존성을 추가하고..." 박시니어 씨가 옆에서 차근차근 알려주기 시작했습니다. **Config Server 프로젝트**는 일반 Spring Boot 프로젝트에 Config Server 의존성을 추가하여 만듭니다. Spring Initializr를 사용하면 몇 번의 클릭만으로 기본 구조를 생성할 수 있고, 설정 파일에 Git 저장소 정보만 추가하면 바로 사용할 수 있습니다. 다음 코드를 살펴봅시다. ```java // pom.xml - Config Server 의존성 org.springframework.cloud spring-cloud-config-server // application.yml - Config Server 설정 server: port: 8888 spring: cloud: config: server: git: uri: https://github.com/yourname/config-repo # Git 저장소 주소를 지정합니다 ``` 박시니어 씨가 브라우저를 열었습니다. "먼저 start.spring.io에 접속하세요. Spring 프로젝트를 쉽게 만들어주는 사이트예요." 김개발 씨는 Spring Initializr 화면을 처음 봤습니다. "와, 이렇게 편한 도구가 있었네요!" "네, 요즘은 이걸 안 쓰는 개발자가 없죠. 자, 하나씩 설정해봅시다." 프로젝트 메타데이터를 입력하는 것부터 시작합니다. Project는 Maven이나 Gradle 중 선택할 수 있는데, 회사에서 주로 쓰는 빌드 도구를 선택하면 됩니다. 김개발 씨의 회사는 Maven을 사용하므로 Maven Project를 선택했습니다. Language는 당연히 Java입니다. Spring Boot Version은 가장 안정적인 최신 버전을 선택합니다. 보통 SNAPSHOT이나 M(Milestone)이 붙지 않은 정식 릴리스 버전을 고릅니다. Group은 회사의 도메인을 거꾸로 쓴 것이 관례입니다. 예를 들어 회사 도메인이 example.com이라면 com.example로 적습니다. Artifact는 프로젝트 이름인데, config-server라고 적으면 됩니다. 이제 중요한 부분인 의존성 추가입니다. 오른쪽의 "ADD DEPENDENCIES" 버튼을 클릭하고 "Config Server"를 검색합니다. Spring Cloud Config Server가 나타나면 선택합니다. 이것 하나면 충분합니다. "이게 끝인가요?" 김개발 씨가 놀라워했습니다. "네, 기본적으로는 이게 다예요. GENERATE 버튼을 누르면 프로젝트 zip 파일을 다운로드할 수 있어요." 다운로드한 파일을 압축 해제하고 IntelliJ나 Eclipse에서 열면 기본 프로젝트 구조가 보입니다. src/main/java 아래에 메인 클래스가 있고, src/main/resources에 application.properties가 있습니다. 메인 클래스를 열어봅시다. 기본적으로 `@SpringBootApplication` 애노테이션이 붙어 있습니다. 여기에 `@EnableConfigServer`를 추가하기만 하면 Config Server가 됩니다. 정말 간단하지 않나요? 다음은 설정 파일을 작성할 차례입니다. application.properties 대신 application.yml을 사용하는 것을 추천합니다. YAML 형식이 더 읽기 쉽고 계층 구조를 표현하기 좋습니다. application.properties를 삭제하고 application.yml을 만듭니다. 위의 코드를 보면 설정이 매우 간단합니다. server.port는 Config Server가 사용할 포트 번호입니다. 관례적으로 8888을 많이 사용합니다. 다른 포트를 써도 상관없습니다. spring.cloud.config.server.git.uri가 핵심입니다. 여기에 설정 파일이 저장된 Git 저장소 주소를 적습니다. GitHub, GitLab, Bitbucket 등 어떤 Git 서비스든 사용할 수 있습니다. Git 저장소는 어떻게 준비할까요? GitHub에 새 저장소를 만듭니다. 이름은 config-repo라고 짓겠습니다. Public으로 만들면 별도의 인증 없이 사용할 수 있어 테스트하기 편리합니다. 실무에서는 당연히 Private 저장소를 사용하고 인증 정보를 추가해야 합니다. 저장소를 만들었으면 간단한 설정 파일을 하나 추가해봅시다. application.yml이라는 파일을 만들고 다음처럼 작성합니다. ``` message: Hello from Config Server ``` 이 파일을 커밋하고 푸시합니다. 이제 Config Server가 이 파일을 읽을 수 있습니다. Private 저장소를 사용한다면 인증 정보를 추가해야 합니다. ``` spring: cloud: config: server: git: uri: https://github.com/yourname/config-repo username: your-username password: your-personal-access-token ``` GitHub는 비밀번호 대신 Personal Access Token을 사용합니다. GitHub 설정에서 토큰을 생성하고 여기에 입력하면 됩니다. 이제 Config Server를 실행해봅시다. IDE에서 메인 클래스를 실행하거나, 터미널에서 `mvn spring-boot:run`을 입력합니다. 애플리케이션이 시작되고 8888 포트에서 대기합니다. 브라우저에서 `http://localhost:8888/application/default`에 접속해봅시다. Git 저장소에 있는 설정이 JSON 형식으로 표시됩니다. message 속성이 "Hello from Config Server"로 나타나면 성공입니다! 김개발 씨는 신기해하며 화면을 바라봤습니다. "와, 정말 Git 저장소의 설정을 읽어오네요!" "맞아요. 이제 이 Config Server에 다른 마이크로서비스를 연결하면 됩니다. 하지만 그 전에 설정 저장소를 좀 더 체계적으로 구성해봅시다." **실전 팁** 💡 - Spring Initializr를 사용하면 프로젝트 생성 시간을 크게 줄일 수 있습니다 - application.properties보다 application.yml을 사용하면 가독성이 좋습니다 - Config Server 포트는 8888을 사용하는 것이 관례이지만, 필요에 따라 변경 가능합니다 --- ## 4. 설정_저장소_구성 Config Server는 잘 실행되었지만, Git 저장소에 application.yml 하나만 있어서는 여러 서비스를 관리할 수 없습니다. 김개발 씨는 주문 서비스, 결제 서비스, 배송 서비스의 설정을 각각 분리하고 싶었습니다. "어떻게 구성하면 좋을까요?" 박시니어 씨가 체계적인 구조를 알려주기 시작했습니다. **설정 저장소 구성**은 각 서비스별로 별도의 설정 파일을 만들고, 공통 설정은 application.yml에 두는 방식입니다. 마치 회사에서 전사 공통 규정과 부서별 규정을 나누어 관리하는 것처럼, Config Server도 공통 설정과 서비스별 설정을 분리하여 관리합니다. 다음 코드를 살펴봅시다. ```java # config-repo 저장소 구조 config-repo/ application.yml # 모든 서비스의 공통 설정 order-service.yml # 주문 서비스 전용 설정 payment-service.yml # 결제 서비스 전용 설정 shipping-service.yml # 배송 서비스 전용 설정 # application.yml - 공통 설정 logging: level: root: INFO # order-service.yml - 주문 서비스 설정 server: port: 8081 spring: datasource: url: jdbc:mysql://localhost:3306/order_db ``` 박시니어 씨가 화이트보드에 폴더 구조를 그렸습니다. "설정 저장소를 잘 구성하는 것이 정말 중요해요. 나중에 서비스가 많아지면 관리가 힘들어지거든요." 김개발 씨는 메모를 준비하며 집중했습니다. "어떻게 구성하면 좋을까요?" "먼저 파일 이름 규칙을 알아야 해요. Config Server는 특정한 규칙으로 파일을 찾습니다." Config Server는 파일 이름으로 어떤 서비스의 설정인지 판단합니다. 기본 규칙은 이렇습니다. 서비스 이름이 order-service라면, Config Server는 order-service.yml 파일을 찾습니다. 서비스 이름이 payment-service라면 payment-service.yml을 찾습니다. 매우 직관적이죠? 여기서 재미있는 점은 application.yml은 특별한 파일이라는 것입니다. 모든 서비스가 공통으로 사용하는 설정을 이 파일에 넣습니다. 예를 들어 로깅 레벨, 공통 데이터베이스 설정, 캐시 설정 같은 것들입니다. 각 서비스가 Config Server에 접속하면 무슨 일이 벌어질까요? 주문 서비스가 접속하면 Config Server는 먼저 application.yml을 읽습니다. 그다음 order-service.yml을 읽습니다. 두 파일의 설정을 합쳐서 주문 서비스에 전달합니다. 만약 같은 속성이 두 파일에 모두 있다면 order-service.yml의 값이 우선합니다. "아, 그럼 공통 설정은 application.yml에 두고, 서비스별로 다른 부분만 각 파일에 두면 되겠네요!" 김개발 씨가 이해했습니다. "정확해요! 이렇게 하면 중복을 최소화하고 관리도 쉬워집니다." 실제로 파일을 만들어봅시다. config-repo 저장소에 application.yml을 만들고 모든 서비스가 공통으로 사용할 설정을 넣습니다. 예를 들어 로깅 레벨을 INFO로 통일하고, 모든 서비스가 같은 Redis 서버를 사용한다면 Redis 주소를 여기에 넣습니다. 다음으로 order-service.yml을 만듭니다. 주문 서비스의 포트는 8081이고, 주문 전용 데이터베이스는 order_db입니다. 이런 서비스별 정보를 이 파일에 넣습니다. payment-service.yml도 비슷하게 만듭니다. 포트는 8082, 데이터베이스는 payment_db입니다. 결제 API 키 같은 결제 서비스만 필요한 설정도 여기에 넣습니다. 이렇게 구성하면 어떤 장점이 있을까요? 첫째, **중복이 줄어듭니다**. 로깅 레벨 같은 공통 설정을 10번 반복해서 쓸 필요가 없습니다. application.yml에 한 번만 쓰면 모든 서비스가 사용합니다. 둘째, **변경이 쉬워집니다**. 로깅 레벨을 DEBUG로 바꾸고 싶다면 application.yml 한 곳만 수정하면 됩니다. 모든 서비스가 자동으로 새 설정을 적용받습니다. 셋째, **서비스별 커스터마이징**이 가능합니다. 특정 서비스만 로깅 레벨을 WARN으로 바꾸고 싶다면 그 서비스의 yml 파일에만 추가하면 됩니다. 공통 설정을 덮어쓸 수 있습니다. 폴더 구조로 정리할 수도 있습니다. 서비스가 많아지면 파일도 많아집니다. 이때는 폴더로 분류하면 좋습니다. 예를 들어 order, payment, shipping 폴더를 만들고 각 폴더 안에 설정 파일을 넣습니다. 하지만 이 경우 Config Server 설정에 search-paths를 추가해야 합니다. ``` spring: cloud: config: server: git: uri: https://github.com/yourname/config-repo search-paths: '{application}' ``` 이렇게 하면 order-service를 찾을 때 order 폴더 안을 검색합니다. 폴더 구조가 깔끔해지지만 설정이 조금 복잡해지는 단점이 있습니다. 서비스가 10개 이하라면 폴더 없이 평평하게 두는 것을 추천합니다. 실무에서는 어떻게 구성할까요? 대부분의 회사에서는 팀별로 저장소를 나눕니다. 주문팀은 order-config-repo, 결제팀은 payment-config-repo를 사용합니다. 각 팀이 자기 설정을 독립적으로 관리할 수 있어 편리합니다. 이 경우 Config Server에 여러 Git 저장소를 등록합니다. Spring Cloud Config는 패턴 매칭으로 어떤 저장소를 사용할지 결정할 수 있습니다. order로 시작하는 서비스는 order-config-repo를 보고, payment로 시작하는 서비스는 payment-config-repo를 봅니다. 주의할 점도 있습니다. 파일 이름과 서비스 이름이 정확히 일치해야 합니다. order-service라는 이름으로 서비스를 등록했는데 파일 이름이 orderservice.yml이면 Config Server가 찾지 못합니다. 하이픈 하나도 중요합니다. 또한 YAML 문법을 정확히 지켜야 합니다. 들여쓰기가 틀리면 파일을 제대로 읽지 못합니다. 온라인 YAML 검증 도구를 사용해서 문법을 확인하는 것이 좋습니다. 김개발 씨는 열심히 메모했습니다. "공통 설정과 서비스별 설정을 나누고, 파일 이름 규칙을 지키는 게 중요하군요!" 박시니어 씨가 고개를 끄덕였습니다. "맞아요. 이제 환경별 설정을 나누는 방법도 배워봅시다." **실전 팁** 💡 - 공통 설정은 application.yml에, 서비스별 설정은 {서비스명}.yml에 분리하세요 - 파일 이름과 서비스 이름(spring.application.name)이 정확히 일치해야 합니다 - YAML 문법 오류를 방지하기 위해 온라인 검증 도구를 활용하세요 --- ## 5. 환경별_설정 김개발 씨의 주문 서비스는 개발 환경에서 localhost 데이터베이스를 사용하지만, 운영 환경에서는 AWS RDS를 사용해야 합니다. 하나의 설정 파일로 어떻게 두 환경을 모두 지원할 수 있을까요? "프로파일을 사용하면 됩니다." 박시니어 씨가 설명하기 시작했습니다. **환경별 설정**은 Spring Profile을 활용하여 dev, test, prod 등 환경마다 다른 설정을 적용하는 방식입니다. 마치 여름옷과 겨울옷을 나누어 보관하듯이, 개발 환경 설정과 운영 환경 설정을 분리하여 관리하면 실수를 줄이고 배포를 안전하게 할 수 있습니다. 다음 코드를 살펴봅시다. ```java # order-service.yml - 기본 설정 server: port: 8081 # order-service-dev.yml - 개발 환경 spring: datasource: url: jdbc:mysql://localhost:3306/order_db username: dev_user # order-service-prod.yml - 운영 환경 spring: datasource: url: jdbc:mysql://prod-db.aws.com:3306/order_db username: prod_user # 서비스 시작 시 프로파일 지정 # java -jar order-service.jar --spring.profiles.active=prod ``` 박시니어 씨가 실제 사고 사례를 이야기했습니다. "예전에 한 동료가 개발 DB 주소를 운영에 배포한 적이 있어요. 운영 서비스가 개발 DB에 접속해서 난리가 났죠." 김개발 씨는 얼굴이 하얘졌습니다. "어떻게 그런 일이..." "설정을 환경별로 제대로 분리하지 않았기 때문이에요. 수동으로 바꾸다 보면 실수하게 마련입니다. 그래서 프로파일이 필요합니다." Spring Profile은 환경을 구분하는 강력한 기능입니다. 기본 개념은 간단합니다. 같은 서비스라도 dev, test, prod 같은 프로파일을 지정하면 각각 다른 설정을 사용할 수 있습니다. 애플리케이션을 시작할 때 어떤 프로파일을 사용할지 지정하면 됩니다. Config Server에서 프로파일을 사용하는 방법도 매우 직관적입니다. 파일 이름에 프로파일을 붙이면 됩니다. order-service.yml은 기본 설정이고, order-service-dev.yml은 dev 프로파일 설정, order-service-prod.yml은 prod 프로파일 설정입니다. 서비스를 시작할 때 `--spring.profiles.active=dev`를 추가하면 dev 프로파일이 활성화됩니다. Config Server는 먼저 application.yml을 읽고, 그다음 order-service.yml을 읽고, 마지막으로 order-service-dev.yml을 읽습니다. 나중에 읽은 파일의 값이 이전 값을 덮어씁니다. "그럼 운영 환경에서는 prod를 지정하면 되겠네요?" 김개발 씨가 물었습니다. "정확해요. `--spring.profiles.active=prod`로 시작하면 order-service-prod.yml의 설정을 사용합니다." 각 프로파일 파일에는 무엇을 넣을까요? 개발 환경(dev)에는 로컬 데이터베이스 주소, 더미 API 키, 디버그 로깅 레벨 같은 것을 넣습니다. 개발자가 로컬에서 쉽게 테스트할 수 있도록 설정합니다. 테스트 환경(test)에는 테스트 서버의 주소, 테스트 계정 정보 같은 것을 넣습니다. QA 팀이 테스트할 때 사용하는 환경입니다. 운영 환경(prod)에는 실제 데이터베이스 주소, 진짜 API 키, 경고 이상의 로깅 레벨 같은 것을 넣습니다. 가장 신중하게 관리해야 하는 설정입니다. 파일 구조를 정리해봅시다. config-repo 저장소에 다음 파일들이 있습니다: application.yml, application-dev.yml, application-prod.yml, order-service.yml, order-service-dev.yml, order-service-prod.yml. application.yml에는 모든 환경에서 공통으로 사용하는 설정을, application-dev.yml에는 모든 서비스의 개발 환경 공통 설정을 넣습니다. 예를 들어 모든 서비스가 개발 환경에서는 DEBUG 로깅을 사용한다면 application-dev.yml에 넣으면 됩니다. 우선순위는 어떻게 될까요? 가장 낮은 우선순위는 application.yml입니다. 그다음이 application-{profile}.yml, 그다음이 {서비스명}.yml, 가장 높은 우선순위는 {서비스명}-{profile}.yml입니다. 나중에 적용되는 설정이 이전 설정을 덮어씁니다. 예를 들어 로깅 레벨이 application.yml에는 INFO, application-dev.yml에는 DEBUG, order-service-dev.yml에는 TRACE라고 되어 있다면 최종적으로 TRACE가 적용됩니다. 실무에서는 보안이 중요합니다. 운영 환경의 데이터베이스 비밀번호나 API 키는 절대 평문으로 Git에 올리면 안 됩니다. Config Server의 암호화 기능을 사용하거나, Vault 같은 별도의 보안 저장소를 사용해야 합니다. Config Server는 {cipher}로 시작하는 암호화된 값을 자동으로 복호화해줍니다. 설정 파일에는 암호화된 값을 넣고, Config Server만 복호화 키를 갖고 있으면 안전합니다. 환경별 배포는 어떻게 할까요? Docker를 사용한다면 환경 변수로 프로파일을 지정할 수 있습니다. `ENV SPRING_PROFILES_ACTIVE=prod` 같은 방식입니다. Kubernetes라면 ConfigMap이나 Secret에 프로파일을 저장하고 Pod에 주입합니다. 개발자 로컬 환경에서는 IDE 설정에 프로파일을 지정하면 편리합니다. IntelliJ의 Run Configuration에서 Active Profiles에 dev를 넣으면 항상 dev 프로파일로 실행됩니다. 주의할 점도 있습니다. 프로파일 파일이 너무 많아지면 관리가 힘들어집니다. dev, test, prod 정도로 최소화하는 것이 좋습니다. 개발자마다 다른 프로파일을 만들면 혼란스러워집니다. 또한 프로파일을 잘못 지정해서 배포하는 실수를 방지해야 합니다. CI/CD 파이프라인에서 환경에 맞는 프로파일이 지정되었는지 자동으로 검증하는 것이 좋습니다. 김개발 씨는 이제 확신이 생겼습니다. "프로파일로 환경을 나누면 실수할 일이 없겠네요!" "맞아요. 하지만 설정 우선순위를 제대로 이해해야 혼란을 피할 수 있어요. 다음으로 우선순위를 자세히 알아봅시다." **실전 팁** 💡 - 환경은 dev, test, prod 정도로 최소화하여 관리 복잡도를 줄이세요 - 운영 환경의 민감한 정보는 반드시 암호화하거나 별도 보안 저장소를 사용하세요 - CI/CD 파이프라인에서 프로파일이 올바르게 설정되었는지 자동 검증하세요 --- ## 6. 설정_우선순위 김개발 씨는 설정 파일이 점점 많아지면서 혼란스러워졌습니다. application.yml, order-service.yml, order-service-dev.yml에 같은 속성이 여러 번 정의되어 있는데, 최종적으로 어떤 값이 적용되는지 헷갈렸습니다. "이럴 때 우선순위를 정확히 알아야 해요." 박시니어 씨가 설명을 시작했습니다. **설정 우선순위**는 여러 설정 파일에 같은 속성이 있을 때 어떤 값을 사용할지 결정하는 규칙입니다. 마치 법에서 헌법이 법률보다 우선하고, 법률이 시행령보다 우선하는 것처럼, Config Server도 명확한 우선순위 규칙이 있습니다. 다음 코드를 살펴봅시다. ```java # 우선순위 (낮음 → 높음) # 1. application.yml (모든 서비스 공통 기본 설정) # 2. application-{profile}.yml (모든 서비스 프로파일 설정) # 3. {서비스명}.yml (특정 서비스 기본 설정) # 4. {서비스명}-{profile}.yml (특정 서비스 프로파일 설정) # 예시: order-service를 dev 프로파일로 실행 # application.yml logging.level.root: INFO # application-dev.yml logging.level.root: DEBUG # order-service.yml logging.level.root: WARN # order-service-dev.yml logging.level.root: TRACE # 최종 결과: TRACE (가장 높은 우선순위) ``` 박시니어 씨가 4장의 카드를 꺼내 책상에 놓았습니다. "이 카드들이 설정 파일이라고 생각해보세요. 아래에 있는 카드일수록 우선순위가 높습니다." 김개발 씨는 카드를 하나씩 살펴봤습니다. "맨 아래가 order-service-dev.yml이네요?" "맞아요. 가장 구체적인 설정일수록 우선순위가 높습니다. 이게 핵심 원칙이에요." 우선순위를 이해하는 가장 쉬운 방법은 구체성입니다. 가장 일반적인 설정은 application.yml입니다. 모든 서비스, 모든 환경에 적용되는 설정입니다. 따라서 우선순위가 가장 낮습니다. 그다음은 application-dev.yml입니다. 모든 서비스에 적용되지만 dev 환경에만 적용됩니다. 조금 더 구체적이므로 application.yml보다 우선순위가 높습니다. order-service.yml은 주문 서비스에만 적용되는 설정입니다. 특정 서비스를 지정했으므로 더 구체적입니다. application-dev.yml보다 우선순위가 높습니다. 가장 구체적인 것은 order-service-dev.yml입니다. 특정 서비스(order-service)의 특정 환경(dev) 설정입니다. 따라서 우선순위가 가장 높습니다. 실제 예제로 이해해봅시다. 로깅 레벨을 설정한다고 가정합니다. application.yml에는 INFO, application-dev.yml에는 DEBUG, order-service.yml에는 WARN, order-service-dev.yml에는 TRACE로 되어 있습니다. order-service를 dev 프로파일로 실행하면 어떻게 될까요? Config Server는 4개 파일을 모두 읽습니다. 읽는 순서는 우선순위가 낮은 것부터입니다. 먼저 application.yml을 읽어서 로깅 레벨을 INFO로 설정합니다. 그다음 application-dev.yml을 읽어서 DEBUG로 덮어씁니다. 그다음 order-service.yml을 읽어서 WARN으로 덮어씁니다. 마지막으로 order-service-dev.yml을 읽어서 TRACE로 덮어씁니다. 최종 결과는 TRACE입니다. "아, 나중에 읽은 값이 이전 값을 덮어쓰는 거네요!" 김개발 씨가 이해했습니다. "정확해요. 마치 페인트를 여러 번 칠하는 것과 같습니다. 마지막 칠한 색이 보이는 거죠." 같은 속성이 일부 파일에만 있다면 어떻게 될까요? 예를 들어 데이터베이스 URL은 order-service-dev.yml에만 있고 다른 파일에는 없다면, 당연히 order-service-dev.yml의 값을 사용합니다. 덮어쓸 이전 값이 없으니까요. 반대로 로깅 레벨이 application.yml에만 있고 다른 파일에는 없다면, application.yml의 값을 사용합니다. 아무도 덮어쓰지 않았으니까요. 이런 방식 덕분에 중복을 최소화할 수 있습니다. 공통 설정은 application.yml에 한 번만 쓰고, 특정 환경이나 서비스에서 다른 값이 필요할 때만 해당 파일에 추가하면 됩니다. 모든 파일에 모든 속성을 반복해서 쓸 필요가 없습니다. 실무에서 자주 하는 실수가 있습니다. 우선순위를 잘못 이해하고 application-dev.yml에 중요한 설정을 넣었는데, order-service.yml에도 같은 속성이 있어서 덮어써진 경우입니다. 개발자는 dev 프로파일을 썼으니 application-dev.yml의 값이 적용될 거라고 생각하지만, 실제로는 order-service.yml의 값이 적용됩니다. 이런 혼란을 피하려면 명확한 규칙을 정해야 합니다. 공통 설정은 application.yml에만 넣습니다. 환경별로 다른 값이 필요하면 application-{profile}.yml에 넣습니다. 서비스별로 다른 값이 필요하면 {서비스명}.yml에 넣습니다. 서비스와 환경 모두 구체적으로 지정해야 한다면 {서비스명}-{profile}.yml에 넣습니다. Config Server는 실제로 어떤 설정을 적용했는지 확인할 수 있습니다. 브라우저에서 `http://localhost:8888/order-service/dev`에 접속하면 JSON 형식으로 최종 설정을 보여줍니다. 어떤 파일에서 읽었는지, 최종 값이 무엇인지 명확하게 나옵니다. 설정이 예상과 다를 때 이 방법으로 디버깅할 수 있습니다. 스프링 부트 액추에이터를 사용하면 더 자세한 정보를 볼 수 있습니다. `/actuator/env` 엔드포인트에 접속하면 모든 설정의 출처와 값을 보여줍니다. 어떤 파일에서 왔는지, 시스템 환경 변수인지, 커맨드 라인 인자인지 모두 표시됩니다. 설정 문제를 해결할 때 매우 유용합니다. 김개발 씨는 머리가 정리되었습니다. "구체적일수록 우선순위가 높다는 원칙만 기억하면 되겠네요!" 박시니어 씨가 미소 지었습니다. "맞아요. 이제 Config Server의 핵심을 모두 배웠어요. 실제 프로젝트에 적용해보세요. 설정 관리가 정말 편해질 거예요." 김개발 씨는 자신감이 생겼습니다. 이제 마이크로서비스 환경에서 설정을 체계적으로 관리할 수 있을 것 같았습니다. Config Server는 복잡해 보였지만, 원리를 이해하고 나니 매우 직관적이었습니다. 가장 중요한 것은 명확한 규칙을 정하고 일관성 있게 적용하는 것입니다. 공통 설정, 환경별 설정, 서비스별 설정을 체계적으로 나누고, 우선순위 원칙을 지키면 혼란 없이 관리할 수 있습니다. **실전 팁** 💡 - 구체적일수록 우선순위가 높다는 원칙을 기억하세요 - 설정이 예상과 다를 때는 Config Server의 엔드포인트로 최종 설정을 확인하세요 - 팀 내에서 명확한 설정 파일 규칙을 정하고 문서화하여 혼란을 방지하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Spring Cloud

언어: Java

태그: Spring Cloud, Config Server, Microservices, Configuration Management, Git Repository

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

Spring Cloud Config 완벽 가이드

목차

1. 외부 설정의 필요성

2. Config Server 소개

3. 프로젝트 생성

4. 설정 저장소 구성

5. 환경별 설정

6. 설정 우선순위

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

Helm 마이크로서비스 패키징 완벽 가이드

관찰 가능한 마이크로서비스 완벽 가이드

Prometheus 메트릭 수집 완벽 가이드