Spring Cloud Config 서버 구성 완벽 가이드

마이크로서비스 환경에서 설정을 중앙화하여 관리하는 Spring Cloud Config 서버 구성 방법을 단계별로 학습합니다. Git 백엔드부터 암호화까지 실무에 필요한 모든 내용을 다룹니다.

1. Git 백엔드 설정

김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 회사가 MSA로 전환하면서 마이크로서비스가 10개로 늘어났습니다.

그런데 서비스마다 설정 파일이 달라서 배포할 때마다 혼란스럽습니다. "분명 개발 환경에서는 잘 돌아갔는데..." 라며 한숨을 쉬던 김개발 씨에게 박시니어 씨가 다가왔습니다.

"Config 서버를 구축해보는 게 어때요?"

Git 백엔드 설정은 Spring Cloud Config 서버가 설정 파일을 Git 저장소에서 가져오도록 구성하는 것입니다. 마치 도서관 사서가 중앙 서고에서 책을 찾아오는 것처럼, Config 서버는 Git 저장소에서 설정 파일을 찾아 각 마이크로서비스에 제공합니다.

이를 통해 모든 설정을 한 곳에서 버전 관리하고, 변경 이력을 추적할 수 있습니다.

다음 코드를 살펴봅시다.

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

spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/company/config-repo
          # 기본 브랜치 설정
          default-label: main
          # 검색할 경로 패턴
          search-paths: '{application}'
          # Git 인증이 필요한 경우
          username: ${GIT_USERNAME}
          password: ${GIT_PASSWORD}

김개발 씨는 마이크로서비스가 늘어나면서 겪는 문제를 박시니어 씨에게 털어놓았습니다. "각 서비스마다 application.yml이 다른데, 데이터베이스 주소가 바뀌면 10개를 다 수정해야 해요." 박시니어 씨는 고개를 끄덕였습니다.

"그래서 Config 서버가 필요한 거예요. Git에 설정 파일을 올려두고, 각 서비스가 Config 서버를 통해 가져가도록 하는 거죠." Config 서버란 무엇일까요? 쉽게 비유하자면, Config 서버는 마치 회사의 총무팀과 같습니다.

각 부서(마이크로서비스)가 필요한 물품(설정)을 요청하면, 총무팀(Config 서버)이 창고(Git 저장소)에서 찾아서 전달해주는 것입니다. 이렇게 하면 모든 부서가 제각각 물품을 보관할 필요가 없고, 총무팀만 관리하면 됩니다.

Git을 백엔드로 사용하는 이유 Config 서버가 없던 시절에는 어땠을까요? 개발자들은 각 서비스의 설정 파일을 직접 수정해야 했습니다.

운영 서버의 데이터베이스 주소가 바뀌면, 10개 서비스의 설정 파일을 일일이 찾아 수정해야 했습니다. 더 큰 문제는 누가 언제 무엇을 바꿨는지 추적이 어렵다는 것이었습니다.

프로젝트가 커질수록 이런 혼란은 눈덩이처럼 불어났습니다. Git 백엔드의 등장 바로 이런 문제를 해결하기 위해 Git을 백엔드로 사용하는 Config 서버가 등장했습니다.

Git을 사용하면 버전 관리가 가능해집니다. 누가 언제 어떤 설정을 바꿨는지 모든 이력이 남습니다.

또한 협업도 쉬워집니다. Pull Request를 통해 설정 변경을 리뷰하고 승인할 수 있습니다.

무엇보다 롤백이 간단하다는 큰 이점이 있습니다. 설정 변경 후 문제가 생기면 즉시 이전 버전으로 되돌릴 수 있습니다.

코드 분석 위의 설정을 한 줄씩 살펴보겠습니다. 먼저 spring.cloud.config.server.git.uri는 설정 파일이 저장된 Git 저장소 주소를 지정합니다.

이 주소만 바꾸면 다른 저장소를 사용할 수 있습니다. 다음으로 default-label은 어떤 브랜치를 사용할지 정합니다.

예전에는 master였지만 요즘은 main을 많이 씁니다. search-paths는 특히 중요합니다.

여기서 **{application}**은 플레이스홀더로, 각 서비스 이름에 맞는 폴더를 찾아갑니다. 예를 들어 user-service가 설정을 요청하면 user-service 폴더에서 찾는 것입니다.

마지막으로 private 저장소라면 username과 password로 인증해야 합니다. 보안을 위해 환경 변수로 주입하는 것이 좋습니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다.

주문 서비스, 결제 서비스, 배송 서비스가 있고, 각각 다른 데이터베이스를 사용합니다. Git 저장소에 order-service, payment-service, delivery-service 폴더를 만들어 각각의 설정을 넣어둡니다.

이제 데이터베이스 주소가 바뀌면 Git에서 해당 파일만 수정하고 커밋하면 됩니다. Config 서버가 자동으로 변경을 감지하고, 서비스들에게 알려줍니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 민감한 정보를 평문으로 Git에 올리는 것입니다.

데이터베이스 비밀번호나 API 키를 그대로 넣으면 보안 문제가 발생할 수 있습니다. 따라서 다음 섹션에서 배울 암호화 기능을 반드시 사용해야 합니다.

또 다른 실수는 Git 저장소를 public으로 만드는 것입니다. 회사의 모든 설정이 공개되면 큰 문제가 됩니다.

반드시 private 저장소를 사용하고, 접근 권한을 제한해야 합니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 Config 서버를 쓰는 거군요!" Git 백엔드를 제대로 구성하면 마이크로서비스의 설정을 체계적으로 관리할 수 있습니다.

변경 이력이 남고, 협업이 쉬워지며, 문제가 생겨도 바로 롤백할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - Git 저장소는 반드시 private으로 설정하고, 팀원들에게만 접근 권한을 부여하세요.

search-paths에 {application}/{profile} 패턴을 사용하면 환경별로 폴더를 분리할 수 있습니다.
설정 변경 후 서비스를 재시작하지 않으려면 @RefreshScope를 활용하세요.

2. 로컬 파일 시스템

김개발 씨는 Config 서버를 개발 환경에서 테스트하려고 합니다. 그런데 매번 Git에 커밋하고 푸시해야 하니 번거롭습니다.

"개발할 때는 좀 더 빠르게 테스트할 수 없을까요?" 박시니어 씨가 웃으며 답했습니다. "로컬 파일 시스템을 사용하면 돼요."

로컬 파일 시스템은 Config 서버가 Git 대신 로컬 디렉토리에서 설정 파일을 가져오도록 구성하는 것입니다. 마치 도서관에 가지 않고 집 책장에서 책을 꺼내는 것처럼, Git 저장소 없이 바로 파일을 읽어올 수 있습니다.

개발 환경에서 빠르게 테스트할 때 매우 유용합니다.

다음 코드를 살펴봅시다.

// 로컬 파일 시스템을 사용하는 Config Server 설정
server:
  port: 8888

spring:
  application:
    name: config-server
  profiles:
    active: native  # native 프로파일 활성화
  cloud:
    config:
      server:
        native:
          # 로컬 설정 파일 경로
          search-locations: file:///config-repo
          # 또는 classpath 사용
          # search-locations: classpath:/config

김개발 씨는 Config 서버 개발을 시작했습니다. 설정 파일을 하나 추가할 때마다 Git에 커밋하고 푸시하니 시간이 오래 걸렸습니다.

"이렇게 하면 개발이 너무 느려요." 박시니어 씨가 화면을 보더니 말했습니다. "개발할 때는 native 프로파일을 쓰세요.

로컬 파일을 바로 읽어오니까 훨씬 빨라요." 로컬 파일 시스템이란? 쉽게 비유하자면, 로컬 파일 시스템은 마치 집에서 요리하는 것과 같습니다. 레스토랑(Git 저장소)에 가지 않고 냉장고(로컬 디렉토리)에 있는 재료로 바로 요리하는 것입니다.

시간도 절약되고, 맛을 보면서 바로 간을 조절할 수 있습니다. Config 서버도 마찬가지입니다.

로컬 디렉토리의 파일을 읽어오므로 Git 통신 없이 즉시 변경사항을 확인할 수 있습니다. 왜 필요한가? Git 백엔드만 사용하면 어떤 불편함이 있을까요?

개발자들은 설정 파일을 수정할 때마다 커밋하고 푸시해야 했습니다. 오타를 고치는 작은 수정에도 여러 단계를 거쳐야 했습니다.

더 큰 문제는 인터넷이 느리거나 Git 서버에 문제가 있으면 개발을 진행할 수 없다는 것이었습니다. 로컬 파일 시스템의 장점 바로 이런 문제를 해결하기 위해 로컬 파일 시스템 모드가 있습니다.

native 프로파일을 활성화하면 로컬 디렉토리를 사용할 수 있습니다. 설정 파일을 수정하고 저장만 하면 바로 적용됩니다.

또한 네트워크 연결이 필요 없어서 오프라인 환경에서도 개발할 수 있습니다. 무엇보다 빠른 피드백을 받을 수 있다는 큰 이점이 있습니다.

코드 분석 위의 설정을 한 줄씩 살펴보겠습니다. 먼저 spring.profiles.active: native가 핵심입니다.

이 한 줄로 Config 서버가 Git 대신 로컬 파일 시스템을 사용하게 됩니다. 다음으로 search-locations는 어디서 파일을 찾을지 지정합니다.

file:/// 프로토콜을 사용하면 절대 경로를 지정할 수 있습니다. 예를 들어 file:///Users/kim/config-repo처럼 쓸 수 있습니다.

또는 classpath:/ 프로토콜을 사용하면 프로젝트 내부의 resources 폴더를 사용할 수 있습니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

많은 팀에서 환경별로 다른 백엔드를 사용합니다. 개발자의 로컬 환경에서는 native 프로파일을 사용하고, 테스트 서버와 운영 서버에서는 Git 백엔드를 사용하는 것입니다.

이렇게 하면 개발 속도를 높이면서도 운영 환경의 안정성을 보장할 수 있습니다. 구체적으로 application.yml에는 운영 설정을, application-dev.yml에는 개발 설정을 넣습니다.

개발자는 -Dspring.profiles.active=dev 옵션으로 서버를 띄우면 로컬 파일을 사용하게 됩니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 운영 환경에서 native 프로파일을 사용하는 것입니다. 로컬 파일은 서버가 재시작되면 사라질 수 있고, 여러 대의 서버에 동일한 파일을 배포하기도 어렵습니다.

따라서 native 프로파일은 개발 환경에서만 사용해야 합니다. 또 다른 주의점은 절대 경로의 사용입니다.

file:///Users/kim/config처럼 개발자 개인의 경로를 하드코딩하면 다른 팀원이 실행할 수 없습니다. 상대 경로나 환경 변수를 활용하는 것이 좋습니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. native 프로파일을 적용한 김개발 씨는 감탄했습니다.

"와, 정말 빨라졌어요!" 로컬 파일 시스템을 제대로 활용하면 개발 생산성을 크게 높일 수 있습니다. 빠른 피드백을 받으며 설정을 다듬고, 완성되면 Git에 커밋해서 팀원들과 공유하면 됩니다.

여러분도 개발 환경에서는 native 프로파일을 적극 활용해 보세요.

실전 팁

💡 - 프로파일을 활용해서 개발 환경(native)과 운영 환경(git)을 분리하세요.

classpath를 사용하면 설정 파일을 프로젝트에 포함시켜 팀원과 공유할 수 있습니다.
환경 변수를 사용해 경로를 동적으로 설정하면 여러 환경에서 유연하게 대응할 수 있습니다.

3. 설정 파일 구조

김개발 씨는 Config 서버를 띄우는 데 성공했습니다. 그런데 설정 파일을 어떤 구조로 만들어야 할지 막막합니다.

"파일 이름을 어떻게 지어야 하죠? 폴더는 어떻게 나눠야 하나요?" 박시니어 씨가 화이트보드를 꺼내며 설명을 시작했습니다.

설정 파일 구조는 Config 서버가 어떤 규칙으로 설정 파일을 찾아오는지에 대한 체계입니다. 마치 도서관의 분류 체계처럼, 특정한 규칙에 따라 파일 이름과 폴더를 정리해야 합니다.

Spring Cloud Config는 {application}-{profile}.yml 형식을 기본으로 사용하며, 우선순위에 따라 설정을 병합합니다.

다음 코드를 살펴봅시다.

// Git 저장소 또는 로컬 디렉토리의 파일 구조
config-repo/
  ├── application.yml              # 모든 서비스의 공통 설정
  ├── application-dev.yml          # 개발 환경 공통 설정
  ├── application-prod.yml         # 운영 환경 공통 설정
  ├── user-service.yml             # user-service 전용 설정
  ├── user-service-dev.yml         # user-service 개발 환경 설정
  ├── user-service-prod.yml        # user-service 운영 환경 설정
  ├── order-service.yml            # order-service 전용 설정
  └── order-service-prod.yml       # order-service 운영 환경 설정

// user-service가 dev 프로파일로 요청하면
// 다음 순서로 설정을 병합합니다:
// 1. application.yml
// 2. application-dev.yml
// 3. user-service.yml
// 4. user-service-dev.yml (가장 높은 우선순위)

김개발 씨는 user-service.yml, user-dev.yml, user-prod.yml 등 파일을 만들어봤지만 Config 서버가 제대로 읽어오지 못했습니다. "왜 안 되는 거죠?" 박시니어 씨가 파일 이름을 보더니 고개를 저었습니다.

"파일 이름 규칙을 지켜야 해요. Spring Cloud Config는 정해진 패턴으로만 파일을 찾아요." 설정 파일 구조란? 쉽게 비유하자면, 설정 파일 구조는 마치 도서관의 청구기호 체계와 같습니다.

책을 찾으려면 분류 기호를 알아야 하듯이, Config 서버도 정해진 규칙에 따라 파일을 찾습니다. 예를 들어 인문 000, 사회과학 300처럼 번호가 정해져 있는 것처럼, Config 서버도 {서비스명}-{환경}.yml 같은 규칙이 있습니다.

명명 규칙의 중요성 제멋대로 파일 이름을 짓면 어떻게 될까요? 개발자들은 각자 편한 방식으로 파일을 만들었습니다.

user_service.yml, user-prod-config.yaml, UserServiceConfig.yml 등 제각각이었습니다. Config 서버는 이런 파일들을 인식하지 못했고, 서비스는 설정을 가져오지 못해 오류가 발생했습니다.

팀원들은 서로 다른 규칙을 사용해서 혼란스러웠습니다. 표준 구조의 등장 바로 이런 문제를 해결하기 위해 표준 구조가 정의되었습니다.

Spring Cloud Config는 {application}-{profile}.yml 패턴을 사용합니다. 여기서 application은 서비스 이름, profile은 환경(dev, prod 등)을 의미합니다.

이 규칙을 따르면 Config 서버가 자동으로 올바른 파일을 찾아서 병합해줍니다. 우선순위 이해하기 설정 파일의 우선순위는 어떻게 될까요?

가장 먼저 application.yml이 로드됩니다. 이 파일은 모든 서비스가 공유하는 공통 설정을 담고 있습니다.

예를 들어 로그 레벨, 타임존 같은 것들이죠. 다음으로 application-{profile}.yml이 로드되어 환경별 공통 설정을 덮어씁니다.

그다음 {application}.yml이 로드됩니다. 특정 서비스만의 설정이 여기 들어갑니다.

마지막으로 {application}-{profile}.yml이 가장 높은 우선순위로 로드되어 최종 설정을 결정합니다. 코드 분석 위의 구조를 실제로 이해해봅시다.

user-service가 dev 프로파일로 Config 서버에 요청하면 어떻게 될까요? Config 서버는 먼저 application.yml에서 기본 설정을 읽습니다.

그다음 application-dev.yml의 설정으로 일부를 덮어씁니다. 그리고 user-service.yml의 설정을 추가로 적용합니다.

마지막으로 user-service-dev.yml의 설정이 최우선으로 적용됩니다. 만약 같은 키가 여러 파일에 있다면 어떻게 될까요?

더 구체적인 파일의 값이 선택됩니다. 예를 들어 application.yml에 db.host=localhost가 있고, user-service-dev.yml에 db.host=dev-db.company.com이 있다면, 최종적으로 dev-db.company.com이 사용됩니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 대부분의 회사에서는 공통 설정을 application.yml에 넣습니다.

모든 서비스가 같은 타임존을 쓰고, 같은 로그 포맷을 사용한다면 여기에 정의하는 것입니다. 그리고 환경별로 달라지는 공통 설정은 application-dev.yml, application-prod.yml에 분리합니다.

각 서비스의 고유한 설정은 user-service.yml 같은 파일에 넣습니다. 예를 들어 user-service만 사용하는 외부 API 키나 특별한 옵션들이죠.

환경마다 다른 값이 필요하면 user-service-prod.yml처럼 프로파일을 붙입니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 공통 설정을 만드는 것입니다. 모든 것을 application.yml에 넣으면 특정 서비스에서 원하지 않는 설정까지 받게 됩니다.

공통 설정은 정말 모든 서비스가 필요한 것만 넣어야 합니다. 또 다른 실수는 파일 확장자를 혼용하는 것입니다.

yml과 yaml, properties를 섞어 쓰면 헷갈립니다. 팀 내에서 하나로 통일하는 것이 좋습니다.

요즘은 yml을 많이 사용하는 추세입니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

파일 이름을 바르게 고친 김개발 씨는 드디어 설정을 받아오는 데 성공했습니다. "이제 이해했어요!" 설정 파일 구조를 제대로 이해하면 체계적으로 설정을 관리할 수 있습니다.

공통 설정과 서비스별 설정을 분리하고, 환경별로 다른 값을 깔끔하게 관리할 수 있습니다. 여러분도 표준 구조를 따라 설정 파일을 정리해 보세요.

실전 팁

💡 - 파일 이름은 반드시 {application}-{profile}.yml 패턴을 따르세요.

공통 설정은 최소한으로 유지하고, 서비스별 설정을 우선하세요.
yml 형식을 사용하면 계층 구조를 시각적으로 표현하기 좋습니다.

4. 설정 암호화

김개발 씨는 설정 파일을 Git에 올리려다가 깜짝 놀랐습니다. 데이터베이스 비밀번호가 평문으로 적혀 있었기 때문입니다.

"이걸 그냥 올리면 안 되겠는데요?" 박시니어 씨가 고개를 끄덕이며 말했습니다. "당연하죠.

암호화해서 올려야 해요."

설정 암호화는 민감한 정보를 암호화하여 저장하고, Config 서버가 복호화해서 클라이언트에게 전달하는 기능입니다. 마치 편지를 암호로 쓰고 받는 사람만 해독할 수 있게 하는 것처럼, 비밀번호나 API 키를 안전하게 보관할 수 있습니다.

Spring Cloud Config는 대칭키와 비대칭키 두 가지 방식을 지원합니다.

다음 코드를 살펴봅시다.

// 1. 먼저 Config Server에 encrypt.key 설정
// application.yml
encrypt:
  key: my-secret-encryption-key-12345

// 2. 암호화할 값을 /encrypt 엔드포인트로 전송
// curl localhost:8888/encrypt -d mysecretpassword
// 결과: AQBkKz1...암호화된문자열...

// 3. 설정 파일에 암호화된 값 사용
// user-service.yml
spring:
  datasource:
    username: admin
    # {cipher} 접두사로 암호화된 값임을 표시
    password: '{cipher}AQBkKz1...암호화된문자열...'

// 4. 클라이언트가 요청하면 자동으로 복호화되어 전달됨
// GET http://localhost:8888/user-service/dev
// 응답에는 복호화된 평문이 포함됨

김개발 씨는 고민에 빠졌습니다. 설정 파일에는 데이터베이스 비밀번호, 외부 API 키, OAuth 시크릿 같은 민감한 정보가 가득했습니다.

이걸 평문으로 Git에 올리면 누구나 볼 수 있습니다. 박시니어 씨가 말했습니다.

"Config 서버의 암호화 기능을 쓰면 돼요. 암호화해서 Git에 올리고, 서버가 알아서 복호화해줍니다." 설정 암호화란? 쉽게 비유하자면, 설정 암호화는 마치 비밀 편지를 쓰는 것과 같습니다.

편지를 암호로 작성해서 우체국(Git 저장소)에 맡깁니다. 우체부(Config 서버)는 편지를 받아 암호를 해독한 뒤, 수신인(마이크로서비스)에게 평문으로 전달합니다.

중간에 누가 편지를 훔쳐봐도 암호문이라 알아볼 수 없습니다. 암호화가 없으면 어떻게 될까? 예전에는 개발자들이 민감한 정보를 평문으로 저장했습니다.

설정 파일에 password: admin1234처럼 그대로 적었습니다. Git 저장소가 실수로 공개되거나, 퇴사한 직원이 접근 권한을 유지하면 큰 문제가 발생했습니다.

실제로 GitHub에 AWS 키를 올렸다가 몇 시간 만에 수백만 원의 요금이 청구된 사례도 있습니다. 암호화의 등장 바로 이런 보안 문제를 해결하기 위해 설정 암호화 기능이 등장했습니다.

Spring Cloud Config는 /encrypt 엔드포인트를 제공합니다. 평문을 POST로 전송하면 암호화된 문자열을 돌려줍니다.

이 암호문을 설정 파일에 {cipher} 접두사와 함께 넣으면 됩니다. Config 서버는 자동으로 이를 인식하고 복호화합니다.

암호화 사용법 실제로 어떻게 사용할까요? 먼저 Config 서버의 application.yml에 encrypt.key를 설정합니다.

이 키로 암호화와 복호화를 수행합니다. 그다음 터미널에서 curl 명령으로 암호화할 값을 전송합니다.

코드 분석 위의 과정을 단계별로 살펴보겠습니다. 첫 번째로 encrypt.key를 설정합니다.

이 키는 절대로 Git에 올리면 안 됩니다. 환경 변수나 외부 파일로 주입해야 합니다.

두 번째로 /encrypt 엔드포인트에 평문을 보냅니다. 서버는 설정된 키로 암호화하여 결과를 반환합니다.

세 번째로 암호화된 문자열을 설정 파일에 '{cipher}...' 형식으로 넣습니다. 작은따옴표를 꼭 붙여야 YAML 파서가 제대로 인식합니다.

마지막으로 클라이언트가 설정을 요청하면 Config 서버가 자동으로 복호화해서 전달합니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

대부분의 회사에서는 암호화 키를 Kubernetes Secret이나 AWS Secrets Manager에 보관합니다. Config 서버를 띄울 때 환경 변수로 주입하는 것입니다.

이렇게 하면 Git 저장소에는 암호문만 올라가고, 암호화 키는 안전하게 분리 보관됩니다. 또한 CI/CD 파이프라인에서 자동으로 암호화하는 경우도 많습니다.

개발자가 평문으로 작성하면, 빌드 과정에서 자동으로 암호화해서 Git에 커밋하는 것입니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 암호화 키를 Git에 함께 올리는 것입니다. 설정 파일은 암호화했지만 키도 같이 있으면 아무 의미가 없습니다.

키는 반드시 별도로 관리해야 합니다. 또 다른 주의점은 {cipher} 접두사를 빼먹는 것입니다.

접두사가 없으면 Config 서버가 평범한 문자열로 인식해서 복호화하지 않습니다. 반드시 '{cipher}암호문' 형식을 지켜야 합니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. 암호화를 적용한 김개발 씨는 안도의 한숨을 쉬었습니다.

"이제 안심하고 Git에 올릴 수 있겠어요!" 설정 암호화를 제대로 사용하면 민감한 정보를 안전하게 보호할 수 있습니다. Git 저장소가 유출되더라도 암호문만 노출되므로 피해를 최소화할 수 있습니다.

여러분도 반드시 민감한 정보는 암호화해서 관리하세요.

실전 팁

💡 - 암호화 키는 절대 Git에 올리지 말고, 환경 변수나 외부 시크릿 관리 도구를 사용하세요.

{cipher} 접두사를 빼먹지 않도록 주의하고, 작은따옴표로 감싸야 합니다.
/decrypt 엔드포인트로 암호문이 제대로 복호화되는지 테스트할 수 있습니다.

5. JCE와 대칭키 암호화

김개발 씨는 암호화를 적용하려다 오류를 만났습니다. "java.security.InvalidKeyException: Illegal key size" 라는 메시지가 떴습니다.

박시니어 씨가 화면을 보더니 말했습니다. "아, JCE 정책 파일이 필요하네요."

**JCE(Java Cryptography Extension)**는 자바의 암호화 기능을 확장하는 라이브러리입니다. 대칭키 암호화는 암호화와 복호화에 같은 키를 사용하는 방식으로, 빠르고 간단하다는 장점이 있습니다.

Spring Cloud Config의 기본 암호화 방식이며, encrypt.key에 설정한 값으로 양방향 암호화를 수행합니다.

다음 코드를 살펴봅시다.

// 1. JCE Unlimited Strength Policy 확인
// Java 8u151 이상에서는 기본으로 포함됨
// 이전 버전은 별도 설치 필요

// 2. 대칭키 설정 (application.yml)
encrypt:
  key: ThisIsMySecretEncryptionKey1234567890

// 3. 암호화 테스트
// curl -X POST http://localhost:8888/encrypt -d 'mysecretpassword'
// 결과: 682bc583aa69...암호화된문자열...

// 4. 복호화 테스트
// curl -X POST http://localhost:8888/decrypt -d '682bc583aa69...'
// 결과: mysecretpassword

// 5. 설정 파일에 적용
spring:
  datasource:
    password: '{cipher}682bc583aa69...'

김개발 씨는 encrypt.key를 설정하고 /encrypt 엔드포인트를 호출했습니다. 그런데 갑자기 오류가 발생했습니다.

"왜 키 길이가 문제가 되는 거죠?" 박시니어 씨가 설명했습니다. "예전 자바 버전에는 암호화 키 길이에 제한이 있었어요.

JCE Unlimited Strength Policy를 설치하거나, 최신 자바를 사용하면 해결돼요." JCE란 무엇인가? 쉽게 비유하자면, JCE는 마치 자물쇠의 업그레이드 키트와 같습니다. 기본 자물쇠는 간단한 4자리 번호만 지원하지만, 업그레이드하면 16자리 복잡한 비밀번호를 사용할 수 있게 됩니다.

자바도 기본적으로는 약한 암호화만 지원하지만, JCE를 사용하면 강력한 암호화가 가능해집니다. 대칭키 암호화의 원리 대칭키 암호화는 어떻게 작동할까요?

**대칭키(Symmetric Key)**는 암호화할 때 쓴 키와 복호화할 때 쓰는 키가 동일합니다. 마치 집 열쇠처럼 문을 잠글 때와 열 때 같은 키를 사용하는 것입니다.

이 방식은 매우 빠르고 효율적이라는 장점이 있습니다. Spring Cloud Config에서 encrypt.key에 설정한 문자열이 바로 대칭키입니다.

이 키로 평문을 암호화하고, 같은 키로 암호문을 복호화합니다. JCE가 없으면 어떻게 될까? 예전 자바 버전에서는 미국 수출 규제 때문에 강력한 암호화가 제한되었습니다.

개발자들은 짧은 키만 사용할 수 있었고, 이는 보안에 취약했습니다. 해커가 쉽게 암호를 해독할 수 있었습니다.

이 문제를 해결하려면 Oracle 웹사이트에서 별도의 정책 파일을 다운로드해서 설치해야 했습니다. 최신 자바의 개선 다행히 Java 8u151 이상 버전부터는 이 문제가 해결되었습니다.

JCE Unlimited Strength Policy가 기본으로 포함되어 있어 별도 설치가 필요 없습니다. 긴 키를 자유롭게 사용할 수 있고, AES-256 같은 강력한 알고리즘도 지원합니다.

요즘 프로젝트에서는 거의 문제가 없습니다. 코드 분석 위의 과정을 단계별로 살펴보겠습니다.

먼저 encrypt.key에 충분히 긴 문자열을 설정합니다. 보안을 위해서는 최소 32자 이상을 권장합니다.

그다음 /encrypt 엔드포인트로 암호화할 값을 전송합니다. Config 서버는 내부적으로 AES 알고리즘을 사용해 암호화합니다.

반환된 암호문을 /decrypt 엔드포인트로 보내면 원래 평문이 나옵니다. 이를 통해 암호화가 제대로 작동하는지 확인할 수 있습니다.

마지막으로 설정 파일에 {cipher} 접두사와 함께 암호문을 넣으면 됩니다. 실무 활용 사례 실제 현업에서는 어떻게 활용할까요?

많은 회사에서 대칭키 방식을 기본으로 사용합니다. 설정이 간단하고 성능이 좋기 때문입니다.

encrypt.key는 Kubernetes Secret이나 환경 변수로 주입합니다. 개발 환경, 스테이징, 운영 환경마다 다른 키를 사용해서 환경 간 격리를 강화하기도 합니다.

예를 들어 운영 환경의 키가 유출되더라도 개발 환경의 데이터는 안전합니다. 각 환경마다 독립적인 키를 관리하는 것입니다.

주의사항 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 짧은 키를 사용하는 것입니다.

"1234" 같은 간단한 키는 쉽게 뚫립니다. 최소 32자 이상의 무작위 문자열을 사용해야 합니다.

openssl rand -base64 32 명령으로 안전한 키를 생성할 수 있습니다. 또 다른 주의점은 키를 정기적으로 교체하지 않는 것입니다.

같은 키를 몇 년씩 사용하면 위험합니다. 분기별 또는 반기별로 키를 교체하고, 설정 파일을 재암호화하는 것이 좋습니다.

대칭키의 한계 대칭키 방식에는 한 가지 근본적인 문제가 있습니다. 암호화하는 쪽과 복호화하는 쪽이 같은 키를 공유해야 합니다.

키를 안전하게 전달하는 것이 어렵습니다. 만약 키가 유출되면 모든 암호문이 노출됩니다.

이런 문제를 해결하려면 다음 섹션에서 배울 비대칭키 암호화를 사용할 수 있습니다. 정리 다시 김개발 씨의 이야기로 돌아가 봅시다.

자바 버전을 확인한 김개발 씨는 최신 버전을 사용하고 있어서 별도 설치가 필요 없었습니다. "다행이네요!" 대칭키 암호화를 제대로 사용하면 빠르고 효율적으로 설정을 보호할 수 있습니다.

충분히 긴 키를 사용하고, 안전하게 관리한다면 대부분의 상황에서 충분합니다. 여러분도 JCE를 활용해 강력한 암호화를 적용해 보세요.

실전 팁

💡 - Java 8u151 이상 버전을 사용하면 JCE 정책 파일을 별도로 설치할 필요가 없습니다.

대칭키는 최소 32자 이상으로 설정하고, openssl rand -base64 32로 생성하세요.
키를 정기적으로 교체하고, 교체 시 모든 암호문을 재암호화해야 합니다.

6. 비대칭키 암호화

김개발 씨는 대칭키 암호화를 운영에 적용했습니다. 그런데 박시니어 씨가 우려스러운 표정을 지었습니다.

"Config 서버가 해킹당하면 키가 노출돼요. 비대칭키를 사용하는 게 더 안전할 거예요."

비대칭키 암호화는 암호화할 때 쓰는 공개키(Public Key)와 복호화할 때 쓰는 비밀키(Private Key)가 서로 다른 방식입니다. 마치 우체통은 누구나 편지를 넣을 수 있지만(공개키), 열쇠를 가진 사람만 꺼낼 수 있는(비밀키) 것과 같습니다.

대칭키보다 안전하지만 설정이 복잡하고 성능이 느린 편입니다.

다음 코드를 살펴봅시다.

// 1. RSA 키 쌍 생성 (터미널)
// keytool -genkeypair -alias config-server-key \
//   -keyalg RSA -keysize 2048 \
//   -keystore config-server.jks \
//   -storepass mypassword

// 2. Config Server 설정 (application.yml)
encrypt:
  key-store:
    location: classpath:/config-server.jks
    password: mypassword
    alias: config-server-key
    secret: mypassword

// 3. 공개키로 암호화 (개발자 PC)
// curl -X POST http://localhost:8888/encrypt -d 'mysecretpassword'
// 결과: AQAT8fh...암호화된문자열...

// 4. 비밀키로 복호화 (Config Server)
// Config 서버만 비밀키를 가지고 있어 복호화 가능

// 5. 설정 파일에 적용
spring:
  datasource:
    password: '{cipher}AQAT8fh...'

김개발 씨는 대칭키 방식의 문제를 이해했습니다. Config 서버에 같은 키로 암호화하고 복호화하니, 서버가 뚫리면 모든 비밀이 노출됩니다.

"더 안전한 방법은 없을까요?" 박시니어 씨가 말했습니다. "비대칭키를 쓰면 돼요.

암호화는 공개키로 하고, 복호화는 비밀키로만 가능하게 만드는 거죠." 비대칭키란 무엇인가? 쉽게 비유하자면, 비대칭키는 마치 은행 야간 금고와 같습니다. 누구나 금고에 돈을 넣을 수 있습니다(공개키로 암호화).

하지만 꺼낼 수 있는 사람은 열쇠를 가진 은행 직원뿐입니다(비밀키로 복호화). 이렇게 하면 입금은 자유롭지만 출금은 통제할 수 있습니다.

Config 서버도 마찬가지입니다. 개발자들은 공개키로 비밀번호를 암호화해서 Git에 올립니다.

Config 서버만 비밀키를 가지고 있어서 복호화할 수 있습니다. 대칭키의 한계 대칭키는 왜 위험할까요?

대칭키 방식에서는 하나의 키로 암호화도 하고 복호화도 합니다. Config 서버에 이 키가 있으면, 서버가 해킹당했을 때 공격자도 같은 키를 얻게 됩니다.

그러면 Git 저장소의 모든 암호문을 해독할 수 있습니다. 마치 집 열쇠를 도둑이 얻으면 집 안의 모든 것에 접근할 수 있는 것과 같습니다.

비대칭키의 등장 바로 이런 보안 문제를 해결하기 위해 비대칭키 방식이 등장했습니다. **공개키(Public Key)**는 누구에게나 공개됩니다.

개발자들이 이 키로 비밀번호를 암호화합니다. 하지만 **비밀키(Private Key)**는 Config 서버만 가지고 있습니다.

공개키로 암호화한 데이터는 비밀키로만 복호화할 수 있습니다. 만약 Git 저장소가 유출되더라도 암호문만 있을 뿐, 복호화할 비밀키가 없으므로 안전합니다.

Config 서버가 해킹당하더라도 이미 Git에 있는 암호문은 공개키로 만들어진 것이라 재암호화할 수 없습니다. RSA 키 쌍 생성 비대칭키를 사용하려면 어떻게 해야 할까요?

먼저 keytool 명령으로 RSA 키 쌍을 생성합니다. 이 도구는 JDK에 포함되어 있어 별도 설치가 필요 없습니다.

-keysize 2048은 키의 길이를 지정하는데, 보안을 위해 최소 2048비트 이상을 권장합니다. 생성된 config-server.jks 파일에는 공개키와 비밀키가 모두 들어있습니다.

이 파일을 Config 서버의 classpath에 넣고, 설정 파일에서 참조하면 됩니다. 코드 분석 위의 설정을 단계별로 살펴보겠습니다.

먼저 encrypt.key-store.location은 키 저장소 파일의 위치를 지정합니다. classpath:/ 접두사를 사용하면 리소스 폴더에서 찾습니다.

password는 키 저장소 자체의 비밀번호이고, secret은 특정 키 엔트리의 비밀번호입니다. alias는 키 저장소 안에서 어떤 키를 사용할지 지정합니다.

Config 서버가 시작되면 이 설정을 읽어서 키를 로드합니다. /encrypt 엔드포인트는 공개키로 암호화를 수행하고, 클라이언트 요청 시에는 비밀키로 복호화합니다.

실무 활용 사례 실제 현업에서는 어떻게 활용할까요? 많은 금융권이나 보안이 중요한 회사에서 비대칭키 방식을 사용합니다.

개발자들은 공개키만 받아서 로컬에서 암호화합니다. 비밀키는 운영팀만 관리하며, Config 서버에만 배포합니다.

이렇게 하면 권한을 분리할 수 있습니다. 또한 HSM(Hardware Security Module) 같은 하드웨어 보안 장치에 비밀키를 저장하는 경우도 있습니다.

이러면 서버가 해킹당해도 비밀키를 추출할 수 없습니다. 주의사항 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 키 저장소 파일을 Git에 올리는 것입니다. jks 파일에는 비밀키가 들어있으므로 절대 Git에 올려서는 안 됩니다.

운영 서버에 직접 배포하거나 시크릿 관리 도구를 사용해야 합니다. 또 다른 주의점은 비밀번호를 평문으로 설정 파일에 쓰는 것입니다.

key-store.password도 민감한 정보이므로 환경 변수로 주입하는 것이 좋습니다. 대칭키 vs 비대칭키 그렇다면 어떤 방식을 선택해야 할까요?

대칭키는 설정이 간단하고 성능이 좋습니다. 작은 프로젝트나 보안 요구사항이 낮은 경우 적합합니다.

비대칭키는 설정이 복잡하지만 더 안전합니다. 금융, 의료 등 보안이 중요한 분야에서 사용합니다.

실무에서는 두 가지를 혼합하기도 합니다. 설정 파일은 비대칭키로 암호화하고, 내부 통신은 대칭키를 사용하는 식입니다.

정리 다시 김개발 씨의 이야기로 돌아가 봅시다. 비대칭키를 적용한 김개발 씨는 안심했습니다.

"이제 훨씬 안전하네요!" 비대칭키 암호화를 제대로 사용하면 최고 수준의 보안을 달성할 수 있습니다. 공개키와 비밀키를 분리해서 권한을 나누고, 유출 시 피해를 최소화할 수 있습니다.

여러분도 보안이 중요한 프로젝트에서는 비대칭키를 적극 활용해 보세요.

실전 팁

💡 - 키 저장소(jks) 파일은 절대 Git에 올리지 말고, 운영 서버에만 안전하게 배포하세요.

RSA 키 길이는 최소 2048비트, 가능하면 4096비트를 사용하세요.
비밀번호도 환경 변수로 주입하여 설정 파일에 평문으로 남기지 마세요.

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

#Spring#Config Server#Microservices#Encryption#Git Backend#Spring Cloud

Spring Cloud Config 서버 구성 완벽 가이드

# Spring Cloud Config 서버 구성 완벽 가이드 마이크로서비스 환경에서 설정을 중앙화하여 관리하는 Spring Cloud Config 서버 구성 방법을 단계별로 학습합니다. Git 백엔드부터 암호화까지 실무에 필요한 모든 내용을 다룹니다. --- ## 목차 1. [Git 백엔드 설정](#git-백엔드-설정) 2. [로컬 파일 시스템](#로컬-파일-시스템) 3. [설정 파일 구조](#설정-파일-구조) 4. [설정 암호화](#설정-암호화) 5. [JCE와 대칭키 암호화](#jce와-대칭키-암호화) 6. [비대칭키 암호화](#비대칭키-암호화) --- ## 1. Git 백엔드 설정 김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 회사가 MSA로 전환하면서 마이크로서비스가 10개로 늘어났습니다. 그런데 서비스마다 설정 파일이 달라서 배포할 때마다 혼란스럽습니다. "분명 개발 환경에서는 잘 돌아갔는데..." 라며 한숨을 쉬던 김개발 씨에게 박시니어 씨가 다가왔습니다. "Config 서버를 구축해보는 게 어때요?" **Git 백엔드 설정**은 Spring Cloud Config 서버가 설정 파일을 Git 저장소에서 가져오도록 구성하는 것입니다. 마치 도서관 사서가 중앙 서고에서 책을 찾아오는 것처럼, Config 서버는 Git 저장소에서 설정 파일을 찾아 각 마이크로서비스에 제공합니다. 이를 통해 모든 설정을 한 곳에서 버전 관리하고, 변경 이력을 추적할 수 있습니다. 다음 코드를 살펴봅시다. ```java // Config Server의 application.yml 설정 server: port: 8888 spring: application: name: config-server cloud: config: server: git: uri: https://github.com/company/config-repo # 기본 브랜치 설정 default-label: main # 검색할 경로 패턴 search-paths: '{application}' # Git 인증이 필요한 경우 username: ${GIT_USERNAME} password: ${GIT_PASSWORD} ``` 김개발 씨는 마이크로서비스가 늘어나면서 겪는 문제를 박시니어 씨에게 털어놓았습니다. "각 서비스마다 application.yml이 다른데, 데이터베이스 주소가 바뀌면 10개를 다 수정해야 해요." 박시니어 씨는 고개를 끄덕였습니다. "그래서 Config 서버가 필요한 거예요. Git에 설정 파일을 올려두고, 각 서비스가 Config 서버를 통해 가져가도록 하는 거죠." **Config 서버란 무엇일까요?** 쉽게 비유하자면, Config 서버는 마치 회사의 총무팀과 같습니다. 각 부서(마이크로서비스)가 필요한 물품(설정)을 요청하면, 총무팀(Config 서버)이 창고(Git 저장소)에서 찾아서 전달해주는 것입니다. 이렇게 하면 모든 부서가 제각각 물품을 보관할 필요가 없고, 총무팀만 관리하면 됩니다. **Git을 백엔드로 사용하는 이유** Config 서버가 없던 시절에는 어땠을까요? 개발자들은 각 서비스의 설정 파일을 직접 수정해야 했습니다. 운영 서버의 데이터베이스 주소가 바뀌면, 10개 서비스의 설정 파일을 일일이 찾아 수정해야 했습니다. 더 큰 문제는 누가 언제 무엇을 바꿨는지 추적이 어렵다는 것이었습니다. 프로젝트가 커질수록 이런 혼란은 눈덩이처럼 불어났습니다. **Git 백엔드의 등장** 바로 이런 문제를 해결하기 위해 Git을 백엔드로 사용하는 Config 서버가 등장했습니다. Git을 사용하면 **버전 관리**가 가능해집니다. 누가 언제 어떤 설정을 바꿨는지 모든 이력이 남습니다. 또한 **협업**도 쉬워집니다. Pull Request를 통해 설정 변경을 리뷰하고 승인할 수 있습니다. 무엇보다 **롤백**이 간단하다는 큰 이점이 있습니다. 설정 변경 후 문제가 생기면 즉시 이전 버전으로 되돌릴 수 있습니다. **코드 분석** 위의 설정을 한 줄씩 살펴보겠습니다. 먼저 **spring.cloud.config.server.git.uri**는 설정 파일이 저장된 Git 저장소 주소를 지정합니다. 이 주소만 바꾸면 다른 저장소를 사용할 수 있습니다. 다음으로 **default-label**은 어떤 브랜치를 사용할지 정합니다. 예전에는 master였지만 요즘은 main을 많이 씁니다. **search-paths**는 특히 중요합니다. 여기서 **{application}**은 플레이스홀더로, 각 서비스 이름에 맞는 폴더를 찾아갑니다. 예를 들어 user-service가 설정을 요청하면 user-service 폴더에서 찾는 것입니다. 마지막으로 private 저장소라면 **username**과 **password**로 인증해야 합니다. 보안을 위해 환경 변수로 주입하는 것이 좋습니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 주문 서비스, 결제 서비스, 배송 서비스가 있고, 각각 다른 데이터베이스를 사용합니다. Git 저장소에 order-service, payment-service, delivery-service 폴더를 만들어 각각의 설정을 넣어둡니다. 이제 데이터베이스 주소가 바뀌면 Git에서 해당 파일만 수정하고 커밋하면 됩니다. Config 서버가 자동으로 변경을 감지하고, 서비스들에게 알려줍니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **민감한 정보를 평문으로 Git에 올리는 것**입니다. 데이터베이스 비밀번호나 API 키를 그대로 넣으면 보안 문제가 발생할 수 있습니다. 따라서 다음 섹션에서 배울 **암호화 기능**을 반드시 사용해야 합니다. 또 다른 실수는 Git 저장소를 public으로 만드는 것입니다. 회사의 모든 설정이 공개되면 큰 문제가 됩니다. 반드시 private 저장소를 사용하고, 접근 권한을 제한해야 합니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 Config 서버를 쓰는 거군요!" Git 백엔드를 제대로 구성하면 마이크로서비스의 설정을 체계적으로 관리할 수 있습니다. 변경 이력이 남고, 협업이 쉬워지며, 문제가 생겨도 바로 롤백할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - Git 저장소는 반드시 private으로 설정하고, 팀원들에게만 접근 권한을 부여하세요. - search-paths에 {application}/{profile} 패턴을 사용하면 환경별로 폴더를 분리할 수 있습니다. - 설정 변경 후 서비스를 재시작하지 않으려면 @RefreshScope를 활용하세요. --- ## 2. 로컬 파일 시스템 김개발 씨는 Config 서버를 개발 환경에서 테스트하려고 합니다. 그런데 매번 Git에 커밋하고 푸시해야 하니 번거롭습니다. "개발할 때는 좀 더 빠르게 테스트할 수 없을까요?" 박시니어 씨가 웃으며 답했습니다. "로컬 파일 시스템을 사용하면 돼요." **로컬 파일 시스템**은 Config 서버가 Git 대신 로컬 디렉토리에서 설정 파일을 가져오도록 구성하는 것입니다. 마치 도서관에 가지 않고 집 책장에서 책을 꺼내는 것처럼, Git 저장소 없이 바로 파일을 읽어올 수 있습니다. 개발 환경에서 빠르게 테스트할 때 매우 유용합니다. 다음 코드를 살펴봅시다. ```java // 로컬 파일 시스템을 사용하는 Config Server 설정 server: port: 8888 spring: application: name: config-server profiles: active: native # native 프로파일 활성화 cloud: config: server: native: # 로컬 설정 파일 경로 search-locations: file:///config-repo # 또는 classpath 사용 # search-locations: classpath:/config ``` 김개발 씨는 Config 서버 개발을 시작했습니다. 설정 파일을 하나 추가할 때마다 Git에 커밋하고 푸시하니 시간이 오래 걸렸습니다. "이렇게 하면 개발이 너무 느려요." 박시니어 씨가 화면을 보더니 말했습니다. "개발할 때는 native 프로파일을 쓰세요. 로컬 파일을 바로 읽어오니까 훨씬 빨라요." **로컬 파일 시스템이란?** 쉽게 비유하자면, 로컬 파일 시스템은 마치 집에서 요리하는 것과 같습니다. 레스토랑(Git 저장소)에 가지 않고 냉장고(로컬 디렉토리)에 있는 재료로 바로 요리하는 것입니다. 시간도 절약되고, 맛을 보면서 바로 간을 조절할 수 있습니다. Config 서버도 마찬가지입니다. 로컬 디렉토리의 파일을 읽어오므로 Git 통신 없이 즉시 변경사항을 확인할 수 있습니다. **왜 필요한가?** Git 백엔드만 사용하면 어떤 불편함이 있을까요? 개발자들은 설정 파일을 수정할 때마다 커밋하고 푸시해야 했습니다. 오타를 고치는 작은 수정에도 여러 단계를 거쳐야 했습니다. 더 큰 문제는 인터넷이 느리거나 Git 서버에 문제가 있으면 개발을 진행할 수 없다는 것이었습니다. **로컬 파일 시스템의 장점** 바로 이런 문제를 해결하기 위해 로컬 파일 시스템 모드가 있습니다. **native 프로파일**을 활성화하면 로컬 디렉토리를 사용할 수 있습니다. 설정 파일을 수정하고 저장만 하면 바로 적용됩니다. 또한 **네트워크 연결이 필요 없어서** 오프라인 환경에서도 개발할 수 있습니다. 무엇보다 **빠른 피드백**을 받을 수 있다는 큰 이점이 있습니다. **코드 분석** 위의 설정을 한 줄씩 살펴보겠습니다. 먼저 **spring.profiles.active: native**가 핵심입니다. 이 한 줄로 Config 서버가 Git 대신 로컬 파일 시스템을 사용하게 됩니다. 다음으로 **search-locations**는 어디서 파일을 찾을지 지정합니다. **file:///** 프로토콜을 사용하면 절대 경로를 지정할 수 있습니다. 예를 들어 file:///Users/kim/config-repo처럼 쓸 수 있습니다. 또는 **classpath:/** 프로토콜을 사용하면 프로젝트 내부의 resources 폴더를 사용할 수 있습니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 많은 팀에서 **환경별로 다른 백엔드**를 사용합니다. 개발자의 로컬 환경에서는 native 프로파일을 사용하고, 테스트 서버와 운영 서버에서는 Git 백엔드를 사용하는 것입니다. 이렇게 하면 개발 속도를 높이면서도 운영 환경의 안정성을 보장할 수 있습니다. 구체적으로 application.yml에는 운영 설정을, application-dev.yml에는 개발 설정을 넣습니다. 개발자는 -Dspring.profiles.active=dev 옵션으로 서버를 띄우면 로컬 파일을 사용하게 됩니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **운영 환경에서 native 프로파일을 사용하는 것**입니다. 로컬 파일은 서버가 재시작되면 사라질 수 있고, 여러 대의 서버에 동일한 파일을 배포하기도 어렵습니다. 따라서 native 프로파일은 **개발 환경에서만** 사용해야 합니다. 또 다른 주의점은 **절대 경로의 사용**입니다. file:///Users/kim/config처럼 개발자 개인의 경로를 하드코딩하면 다른 팀원이 실행할 수 없습니다. 상대 경로나 환경 변수를 활용하는 것이 좋습니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. native 프로파일을 적용한 김개발 씨는 감탄했습니다. "와, 정말 빨라졌어요!" 로컬 파일 시스템을 제대로 활용하면 개발 생산성을 크게 높일 수 있습니다. 빠른 피드백을 받으며 설정을 다듬고, 완성되면 Git에 커밋해서 팀원들과 공유하면 됩니다. 여러분도 개발 환경에서는 native 프로파일을 적극 활용해 보세요. **실전 팁** 💡 - 프로파일을 활용해서 개발 환경(native)과 운영 환경(git)을 분리하세요. - classpath를 사용하면 설정 파일을 프로젝트에 포함시켜 팀원과 공유할 수 있습니다. - 환경 변수를 사용해 경로를 동적으로 설정하면 여러 환경에서 유연하게 대응할 수 있습니다. --- ## 3. 설정 파일 구조 김개발 씨는 Config 서버를 띄우는 데 성공했습니다. 그런데 설정 파일을 어떤 구조로 만들어야 할지 막막합니다. "파일 이름을 어떻게 지어야 하죠? 폴더는 어떻게 나눠야 하나요?" 박시니어 씨가 화이트보드를 꺼내며 설명을 시작했습니다. **설정 파일 구조**는 Config 서버가 어떤 규칙으로 설정 파일을 찾아오는지에 대한 체계입니다. 마치 도서관의 분류 체계처럼, 특정한 규칙에 따라 파일 이름과 폴더를 정리해야 합니다. Spring Cloud Config는 **{application}-{profile}.yml** 형식을 기본으로 사용하며, 우선순위에 따라 설정을 병합합니다. 다음 코드를 살펴봅시다. ```java // Git 저장소 또는 로컬 디렉토리의 파일 구조 config-repo/ ├── application.yml # 모든 서비스의 공통 설정 ├── application-dev.yml # 개발 환경 공통 설정 ├── application-prod.yml # 운영 환경 공통 설정 ├── user-service.yml # user-service 전용 설정 ├── user-service-dev.yml # user-service 개발 환경 설정 ├── user-service-prod.yml # user-service 운영 환경 설정 ├── order-service.yml # order-service 전용 설정 └── order-service-prod.yml # order-service 운영 환경 설정 // user-service가 dev 프로파일로 요청하면 // 다음 순서로 설정을 병합합니다: // 1. application.yml // 2. application-dev.yml // 3. user-service.yml // 4. user-service-dev.yml (가장 높은 우선순위) ``` 김개발 씨는 user-service.yml, user-dev.yml, user-prod.yml 등 파일을 만들어봤지만 Config 서버가 제대로 읽어오지 못했습니다. "왜 안 되는 거죠?" 박시니어 씨가 파일 이름을 보더니 고개를 저었습니다. "파일 이름 규칙을 지켜야 해요. Spring Cloud Config는 정해진 패턴으로만 파일을 찾아요." **설정 파일 구조란?** 쉽게 비유하자면, 설정 파일 구조는 마치 도서관의 청구기호 체계와 같습니다. 책을 찾으려면 분류 기호를 알아야 하듯이, Config 서버도 정해진 규칙에 따라 파일을 찾습니다. 예를 들어 인문 000, 사회과학 300처럼 번호가 정해져 있는 것처럼, Config 서버도 **{서비스명}-{환경}.yml** 같은 규칙이 있습니다. **명명 규칙의 중요성** 제멋대로 파일 이름을 짓면 어떻게 될까요? 개발자들은 각자 편한 방식으로 파일을 만들었습니다. user_service.yml, user-prod-config.yaml, UserServiceConfig.yml 등 제각각이었습니다. Config 서버는 이런 파일들을 인식하지 못했고, 서비스는 설정을 가져오지 못해 오류가 발생했습니다. 팀원들은 서로 다른 규칙을 사용해서 혼란스러웠습니다. **표준 구조의 등장** 바로 이런 문제를 해결하기 위해 표준 구조가 정의되었습니다. Spring Cloud Config는 **{application}-{profile}.yml** 패턴을 사용합니다. 여기서 application은 서비스 이름, profile은 환경(dev, prod 등)을 의미합니다. 이 규칙을 따르면 Config 서버가 자동으로 올바른 파일을 찾아서 병합해줍니다. **우선순위 이해하기** 설정 파일의 우선순위는 어떻게 될까요? 가장 먼저 **application.yml**이 로드됩니다. 이 파일은 모든 서비스가 공유하는 공통 설정을 담고 있습니다. 예를 들어 로그 레벨, 타임존 같은 것들이죠. 다음으로 **application-{profile}.yml**이 로드되어 환경별 공통 설정을 덮어씁니다. 그다음 **{application}.yml**이 로드됩니다. 특정 서비스만의 설정이 여기 들어갑니다. 마지막으로 **{application}-{profile}.yml**이 가장 높은 우선순위로 로드되어 최종 설정을 결정합니다. **코드 분석** 위의 구조를 실제로 이해해봅시다. user-service가 dev 프로파일로 Config 서버에 요청하면 어떻게 될까요? Config 서버는 먼저 application.yml에서 기본 설정을 읽습니다. 그다음 application-dev.yml의 설정으로 일부를 덮어씁니다. 그리고 user-service.yml의 설정을 추가로 적용합니다. 마지막으로 user-service-dev.yml의 설정이 최우선으로 적용됩니다. 만약 같은 키가 여러 파일에 있다면 어떻게 될까요? 더 구체적인 파일의 값이 선택됩니다. 예를 들어 application.yml에 db.host=localhost가 있고, user-service-dev.yml에 db.host=dev-db.company.com이 있다면, 최종적으로 dev-db.company.com이 사용됩니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 대부분의 회사에서는 **공통 설정을 application.yml에** 넣습니다. 모든 서비스가 같은 타임존을 쓰고, 같은 로그 포맷을 사용한다면 여기에 정의하는 것입니다. 그리고 **환경별로 달라지는 공통 설정**은 application-dev.yml, application-prod.yml에 분리합니다. 각 서비스의 고유한 설정은 user-service.yml 같은 파일에 넣습니다. 예를 들어 user-service만 사용하는 외부 API 키나 특별한 옵션들이죠. 환경마다 다른 값이 필요하면 user-service-prod.yml처럼 프로파일을 붙입니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 많은 공통 설정을 만드는 것**입니다. 모든 것을 application.yml에 넣으면 특정 서비스에서 원하지 않는 설정까지 받게 됩니다. 공통 설정은 정말 모든 서비스가 필요한 것만 넣어야 합니다. 또 다른 실수는 **파일 확장자를 혼용하는 것**입니다. yml과 yaml, properties를 섞어 쓰면 헷갈립니다. 팀 내에서 하나로 통일하는 것이 좋습니다. 요즘은 yml을 많이 사용하는 추세입니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 파일 이름을 바르게 고친 김개발 씨는 드디어 설정을 받아오는 데 성공했습니다. "이제 이해했어요!" 설정 파일 구조를 제대로 이해하면 체계적으로 설정을 관리할 수 있습니다. 공통 설정과 서비스별 설정을 분리하고, 환경별로 다른 값을 깔끔하게 관리할 수 있습니다. 여러분도 표준 구조를 따라 설정 파일을 정리해 보세요. **실전 팁** 💡 - 파일 이름은 반드시 {application}-{profile}.yml 패턴을 따르세요. - 공통 설정은 최소한으로 유지하고, 서비스별 설정을 우선하세요. - yml 형식을 사용하면 계층 구조를 시각적으로 표현하기 좋습니다. --- ## 4. 설정 암호화 김개발 씨는 설정 파일을 Git에 올리려다가 깜짝 놀랐습니다. 데이터베이스 비밀번호가 평문으로 적혀 있었기 때문입니다. "이걸 그냥 올리면 안 되겠는데요?" 박시니어 씨가 고개를 끄덕이며 말했습니다. "당연하죠. 암호화해서 올려야 해요." **설정 암호화**는 민감한 정보를 암호화하여 저장하고, Config 서버가 복호화해서 클라이언트에게 전달하는 기능입니다. 마치 편지를 암호로 쓰고 받는 사람만 해독할 수 있게 하는 것처럼, 비밀번호나 API 키를 안전하게 보관할 수 있습니다. Spring Cloud Config는 대칭키와 비대칭키 두 가지 방식을 지원합니다. 다음 코드를 살펴봅시다. ```java // 1. 먼저 Config Server에 encrypt.key 설정 // application.yml encrypt: key: my-secret-encryption-key-12345 // 2. 암호화할 값을 /encrypt 엔드포인트로 전송 // curl localhost:8888/encrypt -d mysecretpassword // 결과: AQBkKz1...암호화된문자열... // 3. 설정 파일에 암호화된 값 사용 // user-service.yml spring: datasource: username: admin # {cipher} 접두사로 암호화된 값임을 표시 password: '{cipher}AQBkKz1...암호화된문자열...' // 4. 클라이언트가 요청하면 자동으로 복호화되어 전달됨 // GET http://localhost:8888/user-service/dev // 응답에는 복호화된 평문이 포함됨 ``` 김개발 씨는 고민에 빠졌습니다. 설정 파일에는 데이터베이스 비밀번호, 외부 API 키, OAuth 시크릿 같은 민감한 정보가 가득했습니다. 이걸 평문으로 Git에 올리면 누구나 볼 수 있습니다. 박시니어 씨가 말했습니다. "Config 서버의 암호화 기능을 쓰면 돼요. 암호화해서 Git에 올리고, 서버가 알아서 복호화해줍니다." **설정 암호화란?** 쉽게 비유하자면, 설정 암호화는 마치 비밀 편지를 쓰는 것과 같습니다. 편지를 암호로 작성해서 우체국(Git 저장소)에 맡깁니다. 우체부(Config 서버)는 편지를 받아 암호를 해독한 뒤, 수신인(마이크로서비스)에게 평문으로 전달합니다. 중간에 누가 편지를 훔쳐봐도 암호문이라 알아볼 수 없습니다. **암호화가 없으면 어떻게 될까?** 예전에는 개발자들이 민감한 정보를 평문으로 저장했습니다. 설정 파일에 **password: admin1234**처럼 그대로 적었습니다. Git 저장소가 실수로 공개되거나, 퇴사한 직원이 접근 권한을 유지하면 큰 문제가 발생했습니다. 실제로 GitHub에 AWS 키를 올렸다가 몇 시간 만에 수백만 원의 요금이 청구된 사례도 있습니다. **암호화의 등장** 바로 이런 보안 문제를 해결하기 위해 설정 암호화 기능이 등장했습니다. Spring Cloud Config는 **/encrypt 엔드포인트**를 제공합니다. 평문을 POST로 전송하면 암호화된 문자열을 돌려줍니다. 이 암호문을 설정 파일에 **{cipher}** 접두사와 함께 넣으면 됩니다. Config 서버는 자동으로 이를 인식하고 복호화합니다. **암호화 사용법** 실제로 어떻게 사용할까요? 먼저 Config 서버의 application.yml에 **encrypt.key**를 설정합니다. 이 키로 암호화와 복호화를 수행합니다. 그다음 터미널에서 curl 명령으로 암호화할 값을 전송합니다. **코드 분석** 위의 과정을 단계별로 살펴보겠습니다. 첫 번째로 **encrypt.key**를 설정합니다. 이 키는 절대로 Git에 올리면 안 됩니다. 환경 변수나 외부 파일로 주입해야 합니다. 두 번째로 **/encrypt 엔드포인트**에 평문을 보냅니다. 서버는 설정된 키로 암호화하여 결과를 반환합니다. 세 번째로 암호화된 문자열을 설정 파일에 **'{cipher}...'** 형식으로 넣습니다. 작은따옴표를 꼭 붙여야 YAML 파서가 제대로 인식합니다. 마지막으로 클라이언트가 설정을 요청하면 Config 서버가 자동으로 복호화해서 전달합니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 대부분의 회사에서는 **암호화 키를 Kubernetes Secret이나 AWS Secrets Manager**에 보관합니다. Config 서버를 띄울 때 환경 변수로 주입하는 것입니다. 이렇게 하면 Git 저장소에는 암호문만 올라가고, 암호화 키는 안전하게 분리 보관됩니다. 또한 CI/CD 파이프라인에서 자동으로 암호화하는 경우도 많습니다. 개발자가 평문으로 작성하면, 빌드 과정에서 자동으로 암호화해서 Git에 커밋하는 것입니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **암호화 키를 Git에 함께 올리는 것**입니다. 설정 파일은 암호화했지만 키도 같이 있으면 아무 의미가 없습니다. 키는 반드시 별도로 관리해야 합니다. 또 다른 주의점은 **{cipher} 접두사를 빼먹는 것**입니다. 접두사가 없으면 Config 서버가 평범한 문자열로 인식해서 복호화하지 않습니다. 반드시 **'{cipher}암호문'** 형식을 지켜야 합니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 암호화를 적용한 김개발 씨는 안도의 한숨을 쉬었습니다. "이제 안심하고 Git에 올릴 수 있겠어요!" 설정 암호화를 제대로 사용하면 민감한 정보를 안전하게 보호할 수 있습니다. Git 저장소가 유출되더라도 암호문만 노출되므로 피해를 최소화할 수 있습니다. 여러분도 반드시 민감한 정보는 암호화해서 관리하세요. **실전 팁** 💡 - 암호화 키는 절대 Git에 올리지 말고, 환경 변수나 외부 시크릿 관리 도구를 사용하세요. - {cipher} 접두사를 빼먹지 않도록 주의하고, 작은따옴표로 감싸야 합니다. - /decrypt 엔드포인트로 암호문이 제대로 복호화되는지 테스트할 수 있습니다. --- ## 5. JCE와 대칭키 암호화 김개발 씨는 암호화를 적용하려다 오류를 만났습니다. "java.security.InvalidKeyException: Illegal key size" 라는 메시지가 떴습니다. 박시니어 씨가 화면을 보더니 말했습니다. "아, JCE 정책 파일이 필요하네요." **JCE(Java Cryptography Extension)**는 자바의 암호화 기능을 확장하는 라이브러리입니다. **대칭키 암호화**는 암호화와 복호화에 같은 키를 사용하는 방식으로, 빠르고 간단하다는 장점이 있습니다. Spring Cloud Config의 기본 암호화 방식이며, encrypt.key에 설정한 값으로 양방향 암호화를 수행합니다. 다음 코드를 살펴봅시다. ```java // 1. JCE Unlimited Strength Policy 확인 // Java 8u151 이상에서는 기본으로 포함됨 // 이전 버전은 별도 설치 필요 // 2. 대칭키 설정 (application.yml) encrypt: key: ThisIsMySecretEncryptionKey1234567890 // 3. 암호화 테스트 // curl -X POST http://localhost:8888/encrypt -d 'mysecretpassword' // 결과: 682bc583aa69...암호화된문자열... // 4. 복호화 테스트 // curl -X POST http://localhost:8888/decrypt -d '682bc583aa69...' // 결과: mysecretpassword // 5. 설정 파일에 적용 spring: datasource: password: '{cipher}682bc583aa69...' ``` 김개발 씨는 encrypt.key를 설정하고 /encrypt 엔드포인트를 호출했습니다. 그런데 갑자기 오류가 발생했습니다. "왜 키 길이가 문제가 되는 거죠?" 박시니어 씨가 설명했습니다. "예전 자바 버전에는 암호화 키 길이에 제한이 있었어요. JCE Unlimited Strength Policy를 설치하거나, 최신 자바를 사용하면 해결돼요." **JCE란 무엇인가?** 쉽게 비유하자면, JCE는 마치 자물쇠의 업그레이드 키트와 같습니다. 기본 자물쇠는 간단한 4자리 번호만 지원하지만, 업그레이드하면 16자리 복잡한 비밀번호를 사용할 수 있게 됩니다. 자바도 기본적으로는 약한 암호화만 지원하지만, JCE를 사용하면 강력한 암호화가 가능해집니다. **대칭키 암호화의 원리** 대칭키 암호화는 어떻게 작동할까요? **대칭키(Symmetric Key)**는 암호화할 때 쓴 키와 복호화할 때 쓰는 키가 동일합니다. 마치 집 열쇠처럼 문을 잠글 때와 열 때 같은 키를 사용하는 것입니다. 이 방식은 매우 빠르고 효율적이라는 장점이 있습니다. Spring Cloud Config에서 **encrypt.key**에 설정한 문자열이 바로 대칭키입니다. 이 키로 평문을 암호화하고, 같은 키로 암호문을 복호화합니다. **JCE가 없으면 어떻게 될까?** 예전 자바 버전에서는 미국 수출 규제 때문에 강력한 암호화가 제한되었습니다. 개발자들은 짧은 키만 사용할 수 있었고, 이는 보안에 취약했습니다. 해커가 쉽게 암호를 해독할 수 있었습니다. 이 문제를 해결하려면 Oracle 웹사이트에서 별도의 정책 파일을 다운로드해서 설치해야 했습니다. **최신 자바의 개선** 다행히 Java 8u151 이상 버전부터는 이 문제가 해결되었습니다. **JCE Unlimited Strength Policy**가 기본으로 포함되어 있어 별도 설치가 필요 없습니다. 긴 키를 자유롭게 사용할 수 있고, AES-256 같은 강력한 알고리즘도 지원합니다. 요즘 프로젝트에서는 거의 문제가 없습니다. **코드 분석** 위의 과정을 단계별로 살펴보겠습니다. 먼저 **encrypt.key**에 충분히 긴 문자열을 설정합니다. 보안을 위해서는 최소 32자 이상을 권장합니다. 그다음 **/encrypt 엔드포인트**로 암호화할 값을 전송합니다. Config 서버는 내부적으로 AES 알고리즘을 사용해 암호화합니다. 반환된 암호문을 **/decrypt 엔드포인트**로 보내면 원래 평문이 나옵니다. 이를 통해 암호화가 제대로 작동하는지 확인할 수 있습니다. 마지막으로 설정 파일에 **{cipher}** 접두사와 함께 암호문을 넣으면 됩니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 많은 회사에서 **대칭키 방식을 기본으로 사용**합니다. 설정이 간단하고 성능이 좋기 때문입니다. encrypt.key는 Kubernetes Secret이나 환경 변수로 주입합니다. 개발 환경, 스테이징, 운영 환경마다 다른 키를 사용해서 환경 간 격리를 강화하기도 합니다. 예를 들어 운영 환경의 키가 유출되더라도 개발 환경의 데이터는 안전합니다. 각 환경마다 독립적인 키를 관리하는 것입니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 짧은 키를 사용하는 것**입니다. "1234" 같은 간단한 키는 쉽게 뚫립니다. 최소 32자 이상의 무작위 문자열을 사용해야 합니다. openssl rand -base64 32 명령으로 안전한 키를 생성할 수 있습니다. 또 다른 주의점은 **키를 정기적으로 교체하지 않는 것**입니다. 같은 키를 몇 년씩 사용하면 위험합니다. 분기별 또는 반기별로 키를 교체하고, 설정 파일을 재암호화하는 것이 좋습니다. **대칭키의 한계** 대칭키 방식에는 한 가지 근본적인 문제가 있습니다. 암호화하는 쪽과 복호화하는 쪽이 **같은 키를 공유**해야 합니다. 키를 안전하게 전달하는 것이 어렵습니다. 만약 키가 유출되면 모든 암호문이 노출됩니다. 이런 문제를 해결하려면 다음 섹션에서 배울 **비대칭키 암호화**를 사용할 수 있습니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 자바 버전을 확인한 김개발 씨는 최신 버전을 사용하고 있어서 별도 설치가 필요 없었습니다. "다행이네요!" 대칭키 암호화를 제대로 사용하면 빠르고 효율적으로 설정을 보호할 수 있습니다. 충분히 긴 키를 사용하고, 안전하게 관리한다면 대부분의 상황에서 충분합니다. 여러분도 JCE를 활용해 강력한 암호화를 적용해 보세요. **실전 팁** 💡 - Java 8u151 이상 버전을 사용하면 JCE 정책 파일을 별도로 설치할 필요가 없습니다. - 대칭키는 최소 32자 이상으로 설정하고, openssl rand -base64 32로 생성하세요. - 키를 정기적으로 교체하고, 교체 시 모든 암호문을 재암호화해야 합니다. --- ## 6. 비대칭키 암호화 김개발 씨는 대칭키 암호화를 운영에 적용했습니다. 그런데 박시니어 씨가 우려스러운 표정을 지었습니다. "Config 서버가 해킹당하면 키가 노출돼요. 비대칭키를 사용하는 게 더 안전할 거예요." **비대칭키 암호화**는 암호화할 때 쓰는 공개키(Public Key)와 복호화할 때 쓰는 비밀키(Private Key)가 서로 다른 방식입니다. 마치 우체통은 누구나 편지를 넣을 수 있지만(공개키), 열쇠를 가진 사람만 꺼낼 수 있는(비밀키) 것과 같습니다. 대칭키보다 안전하지만 설정이 복잡하고 성능이 느린 편입니다. 다음 코드를 살펴봅시다. ```java // 1. RSA 키 쌍 생성 (터미널) // keytool -genkeypair -alias config-server-key \ // -keyalg RSA -keysize 2048 \ // -keystore config-server.jks \ // -storepass mypassword // 2. Config Server 설정 (application.yml) encrypt: key-store: location: classpath:/config-server.jks password: mypassword alias: config-server-key secret: mypassword // 3. 공개키로 암호화 (개발자 PC) // curl -X POST http://localhost:8888/encrypt -d 'mysecretpassword' // 결과: AQAT8fh...암호화된문자열... // 4. 비밀키로 복호화 (Config Server) // Config 서버만 비밀키를 가지고 있어 복호화 가능 // 5. 설정 파일에 적용 spring: datasource: password: '{cipher}AQAT8fh...' ``` 김개발 씨는 대칭키 방식의 문제를 이해했습니다. Config 서버에 같은 키로 암호화하고 복호화하니, 서버가 뚫리면 모든 비밀이 노출됩니다. "더 안전한 방법은 없을까요?" 박시니어 씨가 말했습니다. "비대칭키를 쓰면 돼요. 암호화는 공개키로 하고, 복호화는 비밀키로만 가능하게 만드는 거죠." **비대칭키란 무엇인가?** 쉽게 비유하자면, 비대칭키는 마치 은행 야간 금고와 같습니다. 누구나 금고에 돈을 넣을 수 있습니다(공개키로 암호화). 하지만 꺼낼 수 있는 사람은 열쇠를 가진 은행 직원뿐입니다(비밀키로 복호화). 이렇게 하면 입금은 자유롭지만 출금은 통제할 수 있습니다. Config 서버도 마찬가지입니다. 개발자들은 공개키로 비밀번호를 암호화해서 Git에 올립니다. Config 서버만 비밀키를 가지고 있어서 복호화할 수 있습니다. **대칭키의 한계** 대칭키는 왜 위험할까요? 대칭키 방식에서는 **하나의 키**로 암호화도 하고 복호화도 합니다. Config 서버에 이 키가 있으면, 서버가 해킹당했을 때 공격자도 같은 키를 얻게 됩니다. 그러면 Git 저장소의 모든 암호문을 해독할 수 있습니다. 마치 집 열쇠를 도둑이 얻으면 집 안의 모든 것에 접근할 수 있는 것과 같습니다. **비대칭키의 등장** 바로 이런 보안 문제를 해결하기 위해 비대칭키 방식이 등장했습니다. **공개키(Public Key)**는 누구에게나 공개됩니다. 개발자들이 이 키로 비밀번호를 암호화합니다. 하지만 **비밀키(Private Key)**는 Config 서버만 가지고 있습니다. 공개키로 암호화한 데이터는 비밀키로만 복호화할 수 있습니다. 만약 Git 저장소가 유출되더라도 암호문만 있을 뿐, 복호화할 비밀키가 없으므로 안전합니다. Config 서버가 해킹당하더라도 이미 Git에 있는 암호문은 공개키로 만들어진 것이라 재암호화할 수 없습니다. **RSA 키 쌍 생성** 비대칭키를 사용하려면 어떻게 해야 할까요? 먼저 **keytool** 명령으로 RSA 키 쌍을 생성합니다. 이 도구는 JDK에 포함되어 있어 별도 설치가 필요 없습니다. **-keysize 2048**은 키의 길이를 지정하는데, 보안을 위해 최소 2048비트 이상을 권장합니다. 생성된 **config-server.jks** 파일에는 공개키와 비밀키가 모두 들어있습니다. 이 파일을 Config 서버의 classpath에 넣고, 설정 파일에서 참조하면 됩니다. **코드 분석** 위의 설정을 단계별로 살펴보겠습니다. 먼저 **encrypt.key-store.location**은 키 저장소 파일의 위치를 지정합니다. classpath:/ 접두사를 사용하면 리소스 폴더에서 찾습니다. **password**는 키 저장소 자체의 비밀번호이고, **secret**은 특정 키 엔트리의 비밀번호입니다. **alias**는 키 저장소 안에서 어떤 키를 사용할지 지정합니다. Config 서버가 시작되면 이 설정을 읽어서 키를 로드합니다. /encrypt 엔드포인트는 공개키로 암호화를 수행하고, 클라이언트 요청 시에는 비밀키로 복호화합니다. **실무 활용 사례** 실제 현업에서는 어떻게 활용할까요? 많은 금융권이나 보안이 중요한 회사에서 **비대칭키 방식을 사용**합니다. 개발자들은 공개키만 받아서 로컬에서 암호화합니다. 비밀키는 운영팀만 관리하며, Config 서버에만 배포합니다. 이렇게 하면 권한을 분리할 수 있습니다. 또한 **HSM(Hardware Security Module)** 같은 하드웨어 보안 장치에 비밀키를 저장하는 경우도 있습니다. 이러면 서버가 해킹당해도 비밀키를 추출할 수 없습니다. **주의사항** 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **키 저장소 파일을 Git에 올리는 것**입니다. jks 파일에는 비밀키가 들어있으므로 절대 Git에 올려서는 안 됩니다. 운영 서버에 직접 배포하거나 시크릿 관리 도구를 사용해야 합니다. 또 다른 주의점은 **비밀번호를 평문으로 설정 파일에 쓰는 것**입니다. key-store.password도 민감한 정보이므로 환경 변수로 주입하는 것이 좋습니다. **대칭키 vs 비대칭키** 그렇다면 어떤 방식을 선택해야 할까요? **대칭키**는 설정이 간단하고 성능이 좋습니다. 작은 프로젝트나 보안 요구사항이 낮은 경우 적합합니다. **비대칭키**는 설정이 복잡하지만 더 안전합니다. 금융, 의료 등 보안이 중요한 분야에서 사용합니다. 실무에서는 두 가지를 혼합하기도 합니다. 설정 파일은 비대칭키로 암호화하고, 내부 통신은 대칭키를 사용하는 식입니다. **정리** 다시 김개발 씨의 이야기로 돌아가 봅시다. 비대칭키를 적용한 김개발 씨는 안심했습니다. "이제 훨씬 안전하네요!" 비대칭키 암호화를 제대로 사용하면 최고 수준의 보안을 달성할 수 있습니다. 공개키와 비밀키를 분리해서 권한을 나누고, 유출 시 피해를 최소화할 수 있습니다. 여러분도 보안이 중요한 프로젝트에서는 비대칭키를 적극 활용해 보세요. **실전 팁** 💡 - 키 저장소(jks) 파일은 절대 Git에 올리지 말고, 운영 서버에만 안전하게 배포하세요. - RSA 키 길이는 최소 2048비트, 가능하면 4096비트를 사용하세요. - 비밀번호도 환경 변수로 주입하여 설정 파일에 평문으로 남기지 마세요. --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Spring Cloud

언어: Java

태그: Spring, Config Server, Microservices, Encryption, Git Backend, Spring Cloud

작성자: AI Generated

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

CodeDeck

Spring Cloud Config 서버 구성 완벽 가이드

목차

1. Git 백엔드 설정

2. 로컬 파일 시스템

3. 설정 파일 구조

4. 설정 암호화

5. JCE와 대칭키 암호화

6. 비대칭키 암호화

댓글 (0)

함께 보면 좋은 카드 뉴스

Istio 설치와 구성 완벽 가이드

서비스 메시 완벽 가이드

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

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

Prometheus 메트릭 수집 완벽 가이드