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

여기어때는 Secret 저장소 Secrethub를 전사에 확산하기 위해, 먼저 표준화가 잘 된 EKS 환경부터 적용했다. CI/CD 구조가 제각각인 EC2보다 빠르게 안정성을 확보할 수 있는 경로였기 때문이다.

EKS에서는 애플리케이션이 Secrethub를 직접 호출하지 않도록 하고, External Secrets Operator(ESO) 를 통해 Secrethub의 값을 Kubernetes Secret으로 자동 동기화했다. Secrethub 접근용 API Key는 순환 참조를 피하기 위해 AWS Secret Manager에 저장했고, ClusterSecretStore가 이를 조회한 뒤 ESO가 Secrethub를 읽어 Kubernetes Secret으로 변환하는 구조를 만들었다.

운영 적용 전에는 실패 시나리오를 먼저 정리했다. 각 오류 상황에서 Kubernetes Secret이 새로 생성되는지, 기존 Secret이 갱신되는지, 아니면 변화 없이 유지되는지를 확인하고, ExternalSecret 상태까지 함께 검증해 장애 원인을 ESO 문제 / Secrethub 문제 / 사용자 요청 문제로 구분할 수 있게 했다.

Secret 저장 방식은 여러 대안을 비교한 끝에 단일 JSON 파일 전략을 택했다. Secrethub의 JSON 구조를 그대로 전달할 수 있고, 애플리케이션은 파일 하나만 읽으면 되며, key가 늘어날 때마다 values.yaml을 수정해야 하는 GitOps 부담도 크게 줄어들기 때문이다.

Spring Boot 적용을 위해서는 Secrethub Loader라는 공통 라이브러리를 별도로 만들었다. 이 라이브러리는 순수 Java로 구현해 Spring Boot 2.x / 3.x 모두를 지원하고, EnvironmentPostProcessor를 이용해 애플리케이션 시작 시점에 Secret을 자동 주입한다. 덕분에 @Value와 @ConfigurationProperties를 기존 설정처럼 그대로 사용할 수 있고, 로컬·EC2·EKS에서도 같은 방식으로 동작한다.

공통 라이브러리의 최대 고민은 의존성 충돌이었다. 이를 피하기 위해 Shadow Jar 방식을 선택해 Jackson 같은 내부 의존성을 com.secrethub.shaded...처럼 독립 네임스페이스로 재작성했고, 결과적으로 Spring Boot의 Jackson과 충돌하지 않으면서 classpath 오염 없이 안전하게 배포할 수 있게 했다.

핵심은 단순히 Secret을 중앙화하는 데서 끝나지 않았다. 운영 중 발생할 수 있는 실패 상황까지 정의하고, 팀마다 다른 설정 방식을 존중하면서도 설명 가능한 표준 구조를 만드는 데 집중했다. Secrethub는 저장소가 아니라, 플랫폼 차원의 기준을 세우는 작업으로 완성됐다.