[내일배움캠프 TIL] Spring Cloud Config Server 설정 파일 관리 방식: Native vs Git 분리 (우리의 선택과 기술적 명분)

MSA(마이크로서비스 아키텍처) 기반 프로젝트를 진행하면서, 각 서비스의 환경 변수와 설정 파일(YAML)을 중앙 집중형으로 관리하기 위해 Spring Cloud Config를 도입했습니다.

이때 핵심적인 아키텍처 고민이 발생했습니다. "설정 파일들을 어디에 두고 관리할 것인가?"에 대한 문제였습니다. 두 가지 선택지를 두고 장단점을 비교한 후, 현재 우리 프로젝트 단계에 맞는 최종 의사결정을 내렸습니다.

 

🔍 1. 두 가지 방식의 장단점 비교

📦 방식 A. 프로젝트 멀티모듈 내부에 포함 (Native 방식)

Config Server 모듈 내의 resources/ 폴더에 모든 마이크로서비스(user, payment, coupon 등)의 설정 파일을 한데 모아 로컬 파일 시스템으로 읽어오는 방식입니다.

• 👍 장점:
  • 극도의 편리함과 빠른 개발 속도: 프로젝트 레포지토리 하나만 열면 소스 코드와 설정을 동시에 조작할 수 있어 초기 셋업이 빠르고 로컬 테스트가 매우 편리합니다.
• 👎 단점:
  • 설정 변경 시 무조건 재배포: 사소한 설정(예: 선착순 쿠폰 발급 수량 조절 등) 하나를 바꾸려 해도 메인 프로젝트를 다시 빌드하고 도커 이미지를 빌드해 서버를 통째로 재배포해야 합니다.
  • 보안 취약: 개발 참여자 모두에게 DB 패스워드나 결제 Private Key 같은 민감 정보가 그대로 노출됩니다.

📁 방식 B. 설정 전용 외부 Git 레포지토리 분리

메인 소스 코드와 완전히 격리된 별도의 독립된 Private Git 레포지토리를 만들고, Config Server가 이 외부 Git을 바라보게 하는 방식입니다.

• 👍 장점:
  • 재배포 없는 실시간 설정 반영: 운영 중 설정이 바뀌어도 메인 코드를 재빌드·재배포할 필요 없이 설정 Git에 커밋 후 /actuator/refresh나 Spring Cloud Bus를 통해 실시간 반영할 수 있습니다.
  • 보안성 극대화: 민감한 자격 증명 정보가 담긴 설정 레포지토리의 접근 권한을 인프라 담당자 등으로 격리할 수 있습니다.
• 👎 단점:
  • 레포지토리가 찢어지므로 초기 자격 증명(SSH Key, Access Token) 연동 등 인프라 구축 오버헤드가 발생합니다.

🛠️ 우리의 선택: 거부(Reject)를 통한 실용적 노선 채택

시중의 많은 기술 가이드나 실무 표준(Best Practice)에서는 운영 안정성과 보안을 이유로 '방식 B(외부 Git 분리)'를 강력히 권장합니다. 하지만 우리 팀은 고심 끝에 이 가이드를 거부(Reject)하고 '방식 A(멀티모듈 내부 포함 - Native)'를 채택했습니다.

우리가 피드백을 거부하고 현실적인 대안을 선택한 구체적인 기술적 판단 근거는 다음과 같습니다.

🎯 아키텍처 결정서 (Architecture Decision Record)

• 검증 항목: Config Server 관리 아키텍처 기조 설정
• 수용 여부: ❌ 거부 (Reject)
• 판단 근거:
  1. 초기 개발 단계에서의 생산성 극대화 (YAGNI 원칙): 현재 프로젝트는 초기 빌드 및 MVP(최소 기능 제품) 기능을 빠르게 완성해야 하는 단계입니다. 아직 발생하지 않은 운영 효율(실시간 갱신 파이프라인 등)을 위해 인프라 고도화에 시간을 쏟는 것보다, 하나의 레포지토리 안에서 비즈니스 로직을 빠르게 검증하는 것이 효율적이라고 판단했습니다.
  2. 멀티모듈 아키텍처의 유연한 확장성: 현재 구조는 모듈 간 격리가 잘 이루어져 있습니다. 향후 서비스가 안정화되고 운영 환경 분리가 필수적인 시점이 오면, 자바 소스 코드의 변경 없이 내부 YAML 설정 파일들만 그대로 복사해 외부 Git으로 언제든지 쉽게 분리가 가능합니다. 즉, 나중에 분리하더라도 기술적 부채나 리스크가 거의 없습니다.
  3. 로컬 개발 및 디버깅 편의성: 팀원들이 각자 로컬 환경에서 복사된 MSA 인프라를 띄우고 테스트해야 하므로, 외부 네트워크(Git 자격 증명 등)에 종속되지 않는 Native 방식이 개발 환경 통일에 유리합니다.

💡 오늘의 한 줄 뼈때리는 깨달음 (Takeaway)

무조건 기술적인 '실무 표준(Best Practice)'을 맹신하며 초반부터 헤비한 인프라를 구축하는 것보다, 현재 프로젝트의 개발 단계와 생산성 밸런스를 고려해 '지연 가능한 아키텍처(Deferrable Architecture)'를 설계하는 것 또한 시니어 엔지니어가 갖춰야 할 중요한 의사결정 능력임을 배웠다.

지금은 속도감 있게 내부에 응집시켜 개발하고, 서비스 규모가 커지면 코드 수정 없이 설정 파일만 외부 Git 레포지토리로 싹 분리해 낼 것이다!