여기어때 Secret 플랫폼 구축기 Part 2: 시크릿 저장소를 전체 서비스에 적용하기까지

문제 상황

• EKS와 EC2로 나뉜 배포 환경에서 Secret 적용 방식과 CI/CD 표준화 수준이 서로 달라 전사 확산 전략 필요
• 민감 정보 변경 시 수동 배포 부담과 운영 복잡도 증가 가능성 존재
• Spring Boot 프로젝트별 설정 차이와 공통 라이브러리 의존성 충돌 우려

구조와 흐름

• EKS 환경을 선행 적용 대상으로 선정해 안정성과 확산 속도 확보
• External Secrets Operator로 Secrethub 값을 Kubernetes Secret으로 자동 동기화
• 로컬은 Loader가 직접 조회, EKS는 ESO가 중계하는 이중 흐름 구성

선택 이유

• Secrethub 접근 키를 AWS Secret Manager에 분리 저장해 순환 참조 방지
• 단일 JSON 파일 방식으로 Secret 구조 유지, 애플리케이션 처리 단순화, GitOps 관리 비용 절감
• Shadow Jar로 내부 의존성 격리해 공통 라이브러리의 Classpath 오염 방지

주의할 점

• 실패 케이스별 Kubernetes Secret, ExternalSecret 반응을 사전에 검증할 필요
• 팀별 Spring 설정 차이를 공통 라이브러리로 흡수하되 프레임워크 버전 의존성 최소화 필요
• PropertySource 우선순위와 주입 시점 검증으로 기존 설정 충돌 방지 필요