184. 중앙 집중화된 구성 관리 (Externalized Configuration)

⚠️ 이 문서는 데이터베이스 비밀번호나 외부 API 주소 같은 시스템 환경 설정값들을 소스 코드나 컨테이너 이미지 안에 하드코딩(Hard-coding)하지 않고, 애플리케이션과 완벽히 분리된 별도의 중앙 서버(Config Server)에 저장하여 런타임에 동적으로 주입해 주는 MSA의 핵심 설계 패턴을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 설정(Config)을 코드와 분리하는 것이다. 코드는 변하지 않지만, 배포되는 환경(개발망, 테스트망, 운영망)에 따라 달라져야 하는 DB 주소와 암호 등의 변숫값들을 외부에서 주입받도록 추상화하는 기법이다.
  2. 가치: 수백 개의 마이크로서비스가 돌아가는 환경에서 DB 패스워드가 바뀔 때마다 모든 소스 코드를 열어 수정하고 다시 빌드(Build)하는 대재앙을 막아준다. 설정 서버의 값만 바꾸면 즉시 모든 서비스에 변경 사항이 전파된다.
  3. 기술 체계: 소스 코드는 형상관리(Git)로 관리하되, Spring Cloud Config나 HashiCorp Vault, AWS Parameter Store 같은 중앙 집중식 설정 서버에서 환경 정보를 Pull 또는 Push 방식으로 끌어오는 구조를 가진다.

Ⅰ. 설정 하드코딩의 저주 (Why Externalize?)

환경 설정값을 앱 안에 우겨 넣으면 배포 파이프라인이 붕괴한다.

  1. 코드와 설정의 분리 위반:
    • application.properties 파일에 운영 DB 비밀번호를 적어놓고 Jar 파일로 묶어서(빌드) 배포했다고 치자.
    • 만약 보안 규칙 때문에 한 달에 한 번씩 DB 비밀번호를 바꿔야 한다면? 매달 소스 코드를 수정하고, 다시 컴파일(빌드)하고, 테스트를 거쳐 컨테이너 이미지를 새로 찍어내야 한다. 설정 하나 바뀌었는데 엄청난 리소스가 낭비된다.
  2. 다중 환경 배포의 어려움:
    • 개발망(Dev), 스테이징망(Staging), 운영망(Prod)은 각기 다른 DB 주소를 쓴다.
    • 설정이 분리되지 않으면, 개발용 소스 코드와 운영용 소스 코드가 다르게 존재해야 하는 끔찍한 파편화 현상이 발생한다.
  3. The Twelve-Factor App 원칙:
    • 클라우드 네이티브 앱을 만들기 위한 제3원칙은 "설정(Config)을 환경(Environment) 변수에 저장하라"이다. 코드는 하나만 유지하고, 실행될 때 어떤 환경의 설정을 먹일지 밖에서 결정해야 한다.

📢 섹션 요약 비유: 로봇(코드)을 만들 때 배터리(설정)를 몸통 안에 용접해 버리면(하드코딩), 배터리가 다 닳았을 때 로봇 전체를 분해해서 새로 조립해야 합니다. 대신 배터리 삽입구(외부화)만 만들어두면 로봇은 그대로 둔 채 언제든 새 배터리를 갈아 끼울 수 있습니다.

Ⅱ. Config Server 아키텍처의 작동 원리

수백 개의 로봇에 일괄적으로 주파수를 맞춰주는 사령탑이다.

  1. 중앙 집중형 설정 저장소:
    • Git이나 SVN 같은 버전 관리 시스템에 payment-dev.yml, payment-prod.yml 처럼 각 서비스와 환경별 설정 파일을 모아둔다. (누가 언제 설정을 바꿨는지 이력 추적 가능)
  2. Config Server (설정 서버):
    • 이 Git 저장소를 바라보고 있는 중앙 API 서버(예: Spring Cloud Config)를 띄운다.
    • 수백 개의 마이크로서비스(Client)들은 자신이 켜질 때 제일 먼저 이 Config Server에 접근하여 "나는 결제 서비스(payment)고, 지금 운영망(prod)에서 켜졌어. 내 설정값 좀 줘"라고 요청한다.
  3. 런타임 동적 갱신 (Dynamic Reload):
    • 서비스가 돌아가는 도중에 관리자가 Git의 DB 주소를 수정하면, 서비스들을 재부팅할 필요 없이 메시지 버스(RabbitMQ 등)를 통해 갱신 이벤트가 쫙 퍼진다. 각 서비스는 메모리에 떠 있던 낡은 설정을 실시간으로 새 설정으로 갈아치운다 (예: Spring의 @RefreshScope).

📢 섹션 요약 비유: 군대에서 소대장들(마이크로서비스)이 작전 지시서(설정)를 수첩에 적어가는 대신, 실시간 무전기를 차고 나가는 것입니다. 작전 도중 적의 위치(DB 주소)가 바뀌면 지휘소(Config Server)에서 무전으로 즉각 변경된 위치를 쏴주어 작전 중단(재부팅) 없이 방향을 바꾸게 합니다.

Ⅲ. 보안 저장소와의 통합 (Secret Management)

일반 설정과 '비밀(Secret)' 설정은 취급이 완전히 다르다.

  1. 평문 저장의 위험:
    • 로깅 레벨이나 캐시 타임아웃 같은 일반 설정은 Git에 평문으로 올려도 무방하다.
    • 하지만 DB 비밀번호, AWS Secret Key 같은 민감 정보를 Git에 올리면 대형 보안 사고가 터진다.
  2. HashiCorp Vault 등 비밀 관리 시스템:
    • 민감한 데이터는 암호화 전문 저장소인 Vault, AWS Secrets Manager, KMS(Key Management Service)에 안전하게 격리 보관한다.
    • Config Server는 Git에서 일반 설정을 가져올 때, Vault에서 민감한 비밀번호를 암호화된 채로 가져와 서비스 기동 시점에 메모리 안에서만 평문으로 주입(Injection)되도록 아키텍처를 구성한다.

📢 섹션 요약 비유: 지휘소(Config Server)가 부대원들에게 매뉴얼(일반 설정)은 팩스로 쫙 돌려도 되지만, 금고 비밀번호(Secret)만큼은 팩스에 적지 않고 극비 문서 금고(Vault)에서 암호학적으로 안전하게 빼내와 귀에다 살짝 속삭여 주는 이원화된 정보 전달 체계입니다.