시크릿 관리 도구 얘기가 나오면 늘 "그거 Vault로 하면 되잖아요" 아니면 "AWS 쓰면 Secrets Manager가 편하지" 두 진영으로 갈린다. 우리 팀도 작년까지는 그랬다. 지금은? 둘 다 쓴다. 하이브리드로 굴러가는 지 반 년쯤 됐고, 나름 안정화됐다. 그 과정에서 알게 된 것들을 정리한다.
작년 초 IBM이 HashiCorp을 인수하면서 Vault Enterprise 라이선스 정책이 조금씩 바뀌기 시작했다. 우리는 커뮤니티 에디션을 쓰고 있었지만, 로드맵이 IBM 포트폴리오와 얽히기 시작한 게 살짝 불안하긴 했다. 그렇다고 AWS Secrets Manager로 다 옮기자니 우리 워크로드가 AWS 온리도 아니었다. 온프렘 DB가 아직 남아있고, GCP에도 워크로드가 조금 있다.
각각의 강점, 실무 관점에서
Vault의 진짜 강점은 dynamic secrets다. 여기서 dynamic이라는 게 "회전(rotation)"이 아니라, 요청 시점에 실제로 새 크리덴셜을 만들어서 짧은 TTL로 발급한다는 뜻이다. 예를 들면 개발자가 PostgreSQL에 붙어야 할 때, Vault가 그 순간 read-only 유저를 새로 만들고 30분 TTL을 걸어서 준다. 30분 지나면 유저가 사라진다. 크리덴셜이 유출돼도 30분 안에 무효화된다.
이걸 AWS Secrets Manager로 흉내 내려고 하면 Lambda rotation function을 붙여야 하는데, 그건 그냥 기존 시크릿의 값을 주기적으로 바꾸는 거지 진짜 dynamic이 아니다. 크리덴셜이 살아있는 시간이 여전히 며칠 단위다.
반면 AWS Secrets Manager는 IAM과의 통합에서 압도적이다. EC2 인스턴스 프로파일이든 EKS의 IRSA든, 별도 인증 설정 없이 바로 시크릿을 읽는다. Vault를 AWS에 심으려면 auth method로 aws-iam을 설정하고, role을 매핑하고, 정책을 짜고... 초기 셋업이 꽤 무겁다. 이걸 다 겪어봤는데, 팀에 Vault를 진지하게 굴릴 수 있는 사람이 없으면 정말 애매하다.
우리가 나눈 기준
결국 우리는 이런 식으로 갈랐다.
Vault로 관리하는 것들:
- DB 크리덴셜 (특히 개발자가 임시로 프로덕션 read replica 붙어야 하는 케이스)
- PKI (내부 서비스간 mTLS 인증서 발급)
- 온프렘 시스템 시크릿
- 여러 클라우드에 걸쳐 있는 CI/CD 파이프라인의 크리덴셜
AWS Secrets Manager로 관리하는 것들:
- Lambda 환경 변수로 주입되는 API 키
- RDS 마스터 크리덴셜 (자동 회전이 그냥 편함)
- 개별 서비스가 자기 리전 안에서 소비하는 서드파티 API 키
- KMS와 엮어서 encryption context가 필요한 것들
기준을 한 줄로 요약하면 "TTL이 짧아야 하고 다양한 시스템이 접근하는가 → Vault, AWS 안에서만 살고 IAM으로 붙는 게 자연스러운가 → Secrets Manager"다.
하이브리드가 만든 새로운 문제
근데 두 개를 같이 쓰니까 새로운 문제가 생겼다. 시크릿이 어디에 있는지 개발자가 헷갈리기 시작했다. "이 API 키 어디 있어요?"라는 질문이 한 달에 세 번 나오면 이미 실패다.
우리는 두 가지 조치를 했다.
첫째, 시크릿 카탈로그를 만들었다. 스프레드시트 수준의 소박한 문서인데, "시크릿 이름 / 저장소(Vault or ASM) / 경로 / 소유 팀 / 회전 주기" 다섯 컬럼이다. 별거 아닌데 이게 정말 유용하다. 사람들이 뭘 찾을 때 여기부터 본다.
둘째, External Secrets Operator를 K8s 클러스터에 깔았다. 이게 뭐냐면 Vault든 ASM이든 뭐든 백엔드로 붙여서 Kubernetes Secret 리소스로 동기화해주는 오퍼레이터다. 개발자 입장에서는 그냥 K8s Secret을 쓰면 되고, 어디에 있는지는 ExternalSecret 매니페스트에만 명시된다. 이걸 도입하고 나서 "시크릿 어디 있어요?" 질문이 확 줄었다.
비용은 어땠나
솔직히 이 부분은 예상보다 복잡했다. Vault Community 자체는 무료지만, Raft storage로 3-node HA 구성하면 EC2 비용이 붙는다. 우리는 t3.medium 3대로 굴리는데 한 달에 대략 100달러 정도. AWS Secrets Manager는 시크릿당 월 0.40달러 + API 콜 비용이다. 시크릿 200개면 월 80달러 + API 비용 붙어서 100달러 초반.
숫자만 보면 비슷한데, Vault에는 운영 인력 시간이 숨어있다. 우리 팀에서 대략 주 4시간 정도가 Vault 운영(백업, 업그레이드, 정책 리뷰)에 들어간다. 그거까지 계산하면 Vault가 확실히 더 비싸다.
그래서 결론이 뭐냐
지금 새로 시작하는 팀이라면 나는 이렇게 말하겠다. 워크로드가 90% 이상 AWS에 있고, 팀에 시크릿 관리 전담자가 없으면 그냥 Secrets Manager로 시작해라. dynamic secrets가 정말 필요한 순간이 오면 그때 Vault를 추가로 고민해도 늦지 않다.
우리처럼 이미 두 개를 굴리고 있다면 억지로 하나로 통합하려 하지 말고, 명확한 기준으로 나누고 카탈로그와 ESO 같은 추상화를 얹는 게 낫다. 통합의 유혹이 강한데, 실제로 마이그레이션해보면 얻는 것보다 잃는 게 더 많은 경우가 많다.
혹시 다른 조합으로 굴리시는 분 있으면 어떻게 나누셨는지 궁금하다.
'IT > DevSecOps' 카테고리의 다른 글
| cosign keyless signing, 이거 모르는 분 꽤 많더라 (1) | 2026.08.17 |
|---|---|
| External Secrets Operator, IRSA로 시작하는 실전 가이드 (1) | 2026.08.13 |
| Kyverno CEL 전환, 지금부터 준비하는 법 (0) | 2026.08.05 |
| ClusterSecretStore 하나가 죽으니 클러스터가 조용해졌다 (0) | 2026.08.03 |
| External Secrets Operator vs Vault Agent Injector, 뭘 쓸까 (0) | 2026.07.29 |