여기어때 Secret 플랫폼 구축기 Part 2: 시크릿 저장소를 전체 서비스에 적용하기까지
Summary
"모든 EKS 서비스의 시크릿을 한 번에!" 여기어때가 민감 정보를 관리하는 스마트한 방법
ESO와 Shadow Jar를 활용해 복잡한 설정 없이 전사 시크릿 동기화를 자동화한 기술적 여정
여기어때 DevOps팀이 SecretHub 저장소를 전사 EKS 환경에 확산시킨 구체적인 전략을 소개합니다. 단순히 저장소를 구축하는 것을 넘어, 자동 동기화와 공통 라이브러리 설계를 통해 개발 생산성과 운영 안정성을 동시에 잡은 기술적 노하우를 담고 있습니다.
- 01배달원 ESO 도입: 외부 저장소 시크릿을 Kubernetes Secret으로 자동 동기화하여 수동 배포 지옥 탈출
- 02순환 참조 해결: AWS Secret Manager를 활용한 인증키 분리 관리로 보안성 및 안정성 강화
- 03단일 JSON 전략: GitOps 관리 효율을 극대화하고 values.yaml 설정의 복잡도를 획기적으로 개선
- 04Shadow Jar의 마법: 공통 라이브러리 배포 시 발생할 수 있는 의존성 충돌을 원천 차단
- 05실패 시나리오 정의: 도입 전 철저한 장애 테스트로 운영 중 발생할 이슈를 예측 가능한 범위로 제어
RECOMMENDATION
인프라 시크릿 관리 자동화를 고민하는 DevOps 엔지니어나, 다수의 마이크로서비스에 공통 라이브러리를 안전하게 배포하고 싶은 백엔드 개발자에게 이 아티클을 강력히 추천합니다.
The Problem
시크릿 정보를 중앙 저장소(Secrethub)에서 관리하면서, 이를 EKS 환경의 수많은 애플리케이션에 자동으로 동기화하고 코드 수정 없이 주입해야 하는 과제가 발생했습니다. 특히 민감 정보 변경 시마다 수동으로 재배포해야 하는 운영 부담과 다양한 개발 환경 간의 일관된 시크릿 설정 방식의 부재가 주요 문제였습니다.
The Solution
External Secrets Operator(ESO)를 도입하여 외부 저장소의 시크릿을 Kubernetes Secret으로 자동 동기화하는 구조를 설계하고, AWS Secret Manager를 활용해 순환 참조 문제를 해결했습니다. 또한 Spring Boot 환경에서 코드를 수정하지 않고도 시크릿을 인식할 수 있도록 EnvironmentPostProcessor 기반의 공통 로더 라이브러리를 개발하고, Shadow Jar 방식을 적용해 의존성 충돌을 방지했습니다.
The Result
전사 EKS 환경의 모든 애플리케이션에 Secrethub를 성공적으로 적용하여 민감 정보 변경 시 자동 반영 체계를 구축했습니다. 단일 JSON 파일 제공 전략을 통해 GitOps 관리 비용을 절감했으며, 공통 라이브러리를 통해 로컬, EC2, EKS 등 모든 환경에서 동일한 시크릿 사용 방식을 확보했습니다.
Trade-off
시크릿 인증키 관리 시 순환 참조 문제로 인해 AWS Secret Manager를 병행 사용해야 하는 관리 복잡성이 존재합니다. 또한 본문에 구체적으로 명시되지 않았으나, 공통 라이브러리 배포 시 각 프로젝트의 다양한 프레임워크 버전(Spring Boot 2.x/3.x)에 대응하기 위한 지속적인 유지보수 비용이 수반될 것으로 보입니다.
Key Concepts
More from 여기어때
View all posts from 여기어때
AI 수석회의
LLMAI AgentMCP18시간 전
JVM heap은 멀쩡한데 왜 메모리가 터질까? — Docker 환경 네이티브 메모리 삽질기 (Part 2)
JVMDockerMemory Leak1주 전
JVM heap은 멀쩡한데 왜 메모리가 터질까? — Docker 환경 네이티브 메모리 삽질기 (Part 1)
JVMDockerMemory Leak1주 전
Spring Data Redis: Repository vs RedisTemplate — 실전 성능 비교
Spring Data RedisRedisTemplatePerformance Optimization1주 전
AI 시대의 브랜드 그래픽 시스템 구축기
Generative AIVisual IdentityPrompt Engineering3주 전
