여기어때, 시크릿 관리 자동화로 보안과 생산성 두 마리 토끼를 잡다!

본문에서는 Secrethub에 저장된 Secret을 EKS 환경에 적용하기 위해 External Secrets Operator(ESO)를 도입하여 자동 동기화 구조를 구축했다. ESO는 외부 저장소의 Secret을 Kubernetes Secret으로 자동 동기화해주는 컨트롤러로, 애플리케이션이 Secrethub를 직접 호출할 필요 없이 기존처럼 Kubernetes Secret을 사용하도록 설계되었다. 특히, Secrethub 접근 키는 AWS Secret Manager에 저장하여 데이터 격리 아키텍처(Data Isolation Architecture)를 구현하고, 순환 참조 문제를 해결했다. 이러한 구조는 민감 정보 변경 시 수동 배포의 부담을 줄이고, 운영 효율성을 높이는 데 기여한다.

여기어때는 ESO 도입 전, 발생 가능한 모든 실패 케이스를 정의하고 각 케이스별로 Kubernetes Secret 생성 여부, 기존 Secret 업데이트 여부 등을 확인하는 철저한 테스트(Thorough Testing)를 수행했다. 이러한 사전 조사를 통해 운영 중 관련 오류 발생 시 원인을 즉시 분류할 수 있는 기반을 마련했다. 특히, 사용자 요청 오류에 따른 ExternalSecret 응답 상태를 명확히 정의함으로써, 문제 해결 시간 단축(Reduce Troubleshooting Time)과 시스템 안정성 확보에 기여했다. 이는 단순히 기능 구현을 넘어, 운영 환경에서의 안정성을 고려한 설계의 중요성을 보여준다.

여기어때는 Secret을 Kubernetes에 저장하는 방식으로 단일 JSON 파일 제공 방식을 선택했다. 이 방식은 Secrethub에 저장된 JSON 구조를 그대로 Pod에 전달할 수 있으며, 애플리케이션은 파일 하나만 읽으면 되므로 구현 단순성(Implementation Simplicity)을 확보했다. 또한, key별로 개별 매핑하는 방식과 비교하여 Secret key가 추가되어도 values.yaml을 수정할 필요가 없어 GitOps 관리 비용 절감(Reduce GitOps Management Cost) 효과를 얻었다. 전사 적용이라는 목표를 고려했을 때, 이러한 단순함은 Secret 관리의 효율성을 높이는 핵심 요소로 작용했다.

Spring Boot 환경에서 Secret을 쉽게 사용할 수 있도록 공통 Loader 라이브러리를 개발하고, Shadow Jar 방식을 적용하여 의존성 충돌 문제를 해결했다. EnvironmentPostProcessor를 활용하여 애플리케이션 시작 시점에 Secret을 자동으로 주입하도록 설계하여, 애플리케이션 코드 수정 없이 Secret을 사용할 수 있도록 했다. Shadow Jar는 라이브러리 내부 의존성을 외부에 노출하지 않도록 패키지 경로를 재작성하는 방식으로, Classpath 오염(Classpath Pollution)을 방지하고 공통 라이브러리의 안전한 배포를 가능하게 했다. 이는 플랫폼 라이브러리가 기존 애플리케이션에 미치는 영향을 최소화하는 데 기여했다.

본문에서는 Secrethub를 단순한 Secret 저장소가 아닌, 플랫폼 차원에서 기준을 만드는 작업으로 정의하고 있다. 특히, 공통 라이브러리 설계 시 특정 팀의 기술 스택에 종속되지 않도록(Technology Stack Independence) 설계하고, 의존성 충돌을 방지하기 위한 Shadow 전략을 적용한 점을 강조한다. 이는 전사 적용이라는 목표 아래, 운영 환경에서 발생할 수 있는 문제들을 예측하고, 지속 가능한 구조(Sustainable Architecture)를 설계하려는 노력의 일환이다. 플랫폼 라이브러리 설계는 개발 생산성 향상뿐만 아니라, 시스템의 안정성과 확장성을 확보하는 데 중요한 역할을 한다.