/툴 리뷰/Vault vs AWS Secrets Manager vs SOPS 비용 비교와 선택 기준
툴 리뷰시크릿 관리비밀정보 관리

Vault vs AWS Secrets Manager vs SOPS 비용 비교와 선택 기준

Vault·AWS Secrets Manager·SOPS의 시크릿 관리 비용과 운영 부담을 비교합니다. 시크릿 30·300·1000개 시나리오의 비용 산식, 키 관리와 감사 로그, 쿠버네티스 연동 방식으로 선택 기준을 정리합니다.

Vault vs AWS Secrets Manager vs SOPS 비용 비교와 선택 기준

"시크릿 관리 뭐 쓰세요?"에 정답이 없는 진짜 이유

시크릿 관리 도구 비교 글은 넘쳐나는데, 읽고 나면 항상 같은 자리로 돌아옵니다. 기능표에는 Vault가 압도적으로 많은 체크 표시를 받고, 그래서 Vault를 도입해야 할 것 같은데, 막상 우리 팀 시크릿은 30개 남짓이고 인프라 담당자는 1.5명입니다.

문제는 비교 기준이 잘못됐다는 데 있습니다. 도구 선택의 실제 비용은 월 인프라 청구서 + 운영 인건비 + 장애 시 복구 시간의 합인데, 대부분의 비교표는 첫 번째 항목조차 계산해주지 않습니다. 시크릿 30개짜리 팀이 Vault HA 3노드를 올리면, EC2 비용보다 unseal 절차를 문서화하고 Raft 스냅샷 복구를 리허설하는 데 들어가는 인건비가 몇 배 더 나옵니다.

이 글은 세 도구를 다음 기준으로만 판정합니다.

  • 시나리오별 월 청구서를 산식 그대로 공개
  • 새벽 3시에 장애가 났을 때 영향 범위(블라스트 반경)
  • ISMS-P 심사에서 어떤 증적을 제출할 수 있는가

쿠버네티스 연동 아키텍처 자체를 더 깊게 보고 싶다면 쿠버네티스 시크릿 보안 취약점, Vault와 CSI Driver로 완벽히 관리하는 방법Kubernetes 비밀 관리, Vault vs AWS Secrets Manager 비교 및 최적 아키텍처 가이드를 함께 보시면 됩니다. 이 글은 아키텍처가 아니라 돈과 사람 쪽에 집중합니다.

셋은 애초에 다른 종류의 물건입니다

가장 먼저 정리할 것: SOPS는 시크릿 저장소가 아니라 암호화 포맷입니다. Vault와 ASM은 "시크릿을 보관하고 API로 내주는 서버"지만, SOPS는 "YAML/JSON 파일의 값 부분만 암호화하는 CLI 도구"입니다. 저장소는 여러분의 Git 리포지토리가 담당합니다. 이 차이를 놓치면 비교 자체가 성립하지 않습니다.

HashiCorp VaultAWS Secrets ManagerSOPS + age
중앙 서버필수 (셀프호스트 또는 HCP)관리형, 서버 운영 없음서버 없음 (파일 + Git)
동적 시크릿지원 (DB·클라우드 크레덴셜 TTL 발급)미지원 (정적 값 + 로테이션)미지원
감사 로그audit device (file/syslog/socket)CloudTrail 이벤트Git 커밋 히스토리로 대체
자동 로테이션내장 (엔진별 rotate)Lambda 기반 로테이션수동 (재암호화 후 커밋)
K8s 연동Vault Agent Injector 사이드카 주입 / Secrets Store CSI DriverExternal Secrets Operator가 폴링해 Secret 생성kustomize-sops가 빌드 타임 복호화
멀티클라우드클라우드 중립AWS 종속클라우드 중립 (KMS/age 선택)

여기서 갈리는 결정적 축은 동적 시크릿입니다. "DB 접속 계정을 요청 시점에 1시간짜리로 발급하고 자동 폐기"라는 요구가 실제로 있다면 Vault 외의 선택지는 사실상 없습니다. 반대로 그 요구가 없다면, Vault가 가진 기능표 우위의 상당 부분은 우리 팀에 청구되지 않는 가치입니다.

월 비용 계산: 단가와 산식을 그대로 공개합니다

계산 기준 시점: 2026년 8월 / 리전: 서울(ap-northeast-2) / 온디맨드 기준. AWS 단가는 변경될 수 있으므로 최종 판단 전 AWS 공식 요금 페이지에서 반드시 재확인하시기 바랍니다.

핵심 산식은 세 줄입니다.

  • AWS Secrets Manager: 시크릿 수 × $0.40 + (API 호출 수 ÷ 10,000) × $0.05
  • SOPS + age: KMS를 병행할 경우 키 개수 × $1.00 + 복호화 API 호출 비용. age 키만 쓰면 인프라 비용 $0
  • Vault 셀프호스트: EC2 인스턴스비 + EBS + NLB + 운영 인건비(월 투입 시간 × 시급)

운영 인건비를 별도 행으로 분리하는 게 이 계산의 핵심입니다. 시급은 계산 편의상 50,000원(약 $36) 으로 잡았습니다. 팀 실제 인건비로 바꿔 다시 계산해 보세요.

시나리오 ① 시크릿 30개 / API 5만 콜 / 개발자 3명

항목Vault(셀프호스트 단일노드)AWS Secrets ManagerSOPS + age
인프라t3.small 1대 ≈ $19 + EBS 20GB ≈ $2$0$0
시크릿/API-30 × $0.40 = $12 + (50,000÷10,000)×$0.05 = $0.25 → $12.25$0
운영 인건비월 8시간 × $36 = $288월 1시간 = $36월 1시간 = $36
월 합계약 $309약 $48약 $36

30개 규모에서 Vault는 인프라비($21)보다 운영 인건비($288)가 13배 큽니다. 이 구간에서 Vault를 올리는 건 명백한 과잉투자입니다.

시나리오 ② 시크릿 300개 / API 200만 콜 / 서비스 15개

항목Vault(HA 3노드)AWS Secrets ManagerSOPS + age
인프라t3.medium ×3 ≈ $114 + EBS ≈ $9 + NLB ≈ $20 → $143$0$0
시크릿/API-300 × $0.40 = $120 + (2,000,000÷10,000)×$0.05 = $10 → $130$0
운영 인건비월 20시간 × $36 = $720월 4시간 = $144월 16시간 = $576
월 합계약 $863약 $274약 $612

여기가 뒤집히는 지점입니다. SOPS는 인프라 비용이 계속 $0이지만, 시크릿이 300개를 넘고 서비스가 15개로 갈라지면 "누가 어떤 키로 무엇을 복호화할 수 있는가"를 .sops.yaml의 creation_rules로 관리하는 부담이 급격히 커집니다. 개발자 입퇴사 시 age 수신자 목록에서 키를 빼고 전체 파일을 재암호화해야 하는데, 이 작업 하나가 파일 수에 비례합니다.

경험적으로 손익분기는 시크릿 100~150개 구간에 놓입니다. ASM은 시크릿 개수에 선형($0.40)으로 비용이 붙지만 운영 시간은 거의 늘지 않는 반면, SOPS는 비용이 0이어도 운영 시간이 시크릿 수에 거의 선형으로 늘기 때문입니다. 150개 × $0.40 = $60을 인건비 1.7시간과 맞바꾸는 셈인데, 재암호화 한 번이 그 시간을 넘깁니다.

시나리오 ③ 시크릿 1,000개 / 멀티리전·멀티클라우드

항목Vault(HA 3노드 ×2리전)AWS Secrets Manager(복제)SOPS + age
인프라약 $290$0$0
시크릿/API-1,000 × $0.40 = $400 + 복제 리전 추가 과금 + API 비용 → $450 이상$0
운영 인건비월 40시간 = $1,440월 8시간 = $288실질적으로 관리 불가
월 합계약 $1,730약 $738권장하지 않음

이 구간에서 SOPS는 비용이 아니라 운영 가능성에서 탈락합니다. 반대로 AWS 단일 클라우드라면 ASM이 여전히 유리하고, 멀티클라우드거나 동적 크레덴셜이 필수라면 Vault의 $1,730이 정당화됩니다.

돈 말고 사람: 러닝커브와 블라스트 반경

항목VaultAWS Secrets ManagerSOPS + age
초기 구축 시간HA 구성 기준 며칠반나절 (ESO 연동 포함)30분
봉인(Seal) 운영unseal 키 분산 보관 필요, Auto-unseal(KMS) 전환 권장해당 없음해당 없음
장애 시 영향 범위Vault seal → 신규 배포·재기동 전면 중단AWS 리전 장애 시 ESO 동기화 실패 (기존 Secret은 유지)이미 배포된 워크로드 무영향 (빌드 타임 복호화)
백업·복구Raft snapshot 저장·복구 리허설 필수관리형, 삭제 대기기간 내 복구 가능age 개인키 백업이 전부 (단, 분실 시 전량 복구 불가)
사고 유형운영 실수형 (seal, 토큰 만료, 정책 오류)권한/한도형 (IAM, 스로틀링)키 분실형 (되돌릴 수 없음)

블라스트 반경만 놓고 보면 SOPS가 가장 안전합니다. 복호화가 배포 파이프라인에서 끝나므로 런타임 의존성이 없습니다. 반대로 Vault는 런타임 의존성이 가장 크고, 그래서 Auto-unseal은 선택이 아니라 사실상 필수입니다. 수동 unseal 체제로 운영하면 새벽 장애 때 unseal 키 3개를 가진 사람 3명을 동시에 깨워야 합니다.

Vault BSL 전환: 언제 문제가 되고 언제 무관한가

2023년 8월, HashiCorp는 주요 제품 라이선스를 MPL 2.0에서 BSL(Business Source License) 로 변경했습니다. 이후 리눅스 재단 산하에서 OpenBao라는 커뮤니티 포크가 출범해 MPL 계열 라이선스로 개발이 이어지고 있습니다.

판정 기준은 의외로 단순합니다.

  • 무관한 경우: 자사 서비스 운영을 위해 Vault를 내부에 설치해 사내 시크릿을 관리 → 일반적인 내부 사용은 BSL 제한 대상이 아닙니다. 대부분의 스타트업·중견 기업이 여기 해당합니다.
  • 검토가 필요한 경우: Vault를 기반으로 고객에게 시크릿 관리 서비스를 제공하거나, SaaS 상품의 핵심 기능으로 재판매하는 형태 → HashiCorp가 제한하는 "경쟁 제품" 해석에 걸릴 수 있으므로 법무 검토가 필요합니다.

라이선스 조항의 최종 해석은 원문과 법무 검토를 따라야 합니다. 여기서는 판정의 방향만 제시하며, 도입 결정 시 BSL 원문 및 사내 법무 확인을 권합니다. 라이선스 리스크가 신경 쓰이지만 Vault의 동적 시크릿은 필요하다면 OpenBao가 현실적인 대안입니다.

ISMS-P 암호키 관리 통제항목 대응

국내 인증 심사에서 자주 요구되는 증적은 "키 생성·보관·회전·폐기 이력"과 "접근 통제 기록"입니다.

요구 증적VaultAWS Secrets ManagerSOPS + age
접근 기록audit device JSON 로그 (요청자·경로·시각)CloudTrail 이벤트 (GetSecretValue 등)Git 커밋 로그 (누가 언제 변경) — 조회 기록은 없음
키 회전 이력로테이션 로그 + 버전버전 스탬프 + 로테이션 이력재암호화 커밋 이력
권한 분리정책(policy) 문서IAM 정책 + 리소스 정책.sops.yaml creation_rules

SOPS의 약점은 명확합니다. "누가 이 시크릿을 열람했는가"를 남길 수 없습니다. 변경 이력만 있고 조회 이력이 없습니다. 열람 감사 증적이 필수인 심사 항목이 있다면 SOPS 단독은 부적합할 가능성이 높으니, 심사 요구사항 원문을 먼저 확인하시기 바랍니다.

리전·지원 측면에서 AWS Secrets Manager는 서울 리전(ap-northeast-2)을 지원하고 한국어 문서와 유료 서포트 플랜을 통한 한국어 대응이 가능합니다. Vault·SOPS는 커뮤니티 중심이며 공식 문서는 영문 기준입니다.

의사결정표: 5개 질문으로 판정

#질문Yes →No →
1DB 크레덴셜을 요청 시점 TTL로 발급해야 하는가?Vault / OpenBao2번으로
2멀티클라우드 또는 온프레미스 병행인가?Vault / OpenBao3번으로
3AWS 단일 클라우드이고 시크릿 150개 이상인가?ASM + ESO4번으로
4GitOps로 매니페스트와 시크릿을 Git에 함께 두고 싶은가?SOPS + age5번으로
5시크릿 열람 감사 로그 제출이 필수인가?ASM(CloudTrail)SOPS + age

현실적인 조합 패턴도 있습니다. 애플리케이션 설정은 SOPS로 Git에 두고, DB 비밀번호처럼 로테이션이 필요한 것만 ASM에 두는 하이브리드는 시크릿 100~200개 구간에서 비용과 운영 부담이 가장 균형 잡힙니다.

오늘 바로 실행: .env → SOPS 암호화 5줄

Bash
# 1. age 키 생성 (개인키는 절대 커밋 금지)
age-keygen -o ~/.config/sops/age/keys.txt

# 2. 공개키 확인 (age1... 로 시작하는 문자열)
grep "public key" ~/.config/sops/age/keys.txt

# 3. .sops.yaml 작성 — 복수 수신자로 키 분실 대비
cat > .sops.yaml <<'EOF'
creation_rules:
  - path_regex: secrets/.*\.yaml$
    age: >-
      age1abc...개발자A공개키,
      age1def...백업용공개키
EOF

# 4. 평문 YAML 암호화 (값만 암호화, 키 이름은 평문 유지)
sops -e secrets/prod.yaml > secrets/prod.enc.yaml && rm secrets/prod.yaml

# 5. 커밋
git add .sops.yaml secrets/prod.enc.yaml && git commit -m "chore: encrypt prod secrets with SOPS"

정상 결과: secrets/prod.enc.yaml을 열면 키 이름은 읽히고 값이 ENC[AES256_GCM,data:...] 형태로 바뀌어 있으며, 파일 하단에 sops: 메타데이터 블록이 붙습니다. 값이 평문 그대로라면 .sops.yamlpath_regex가 실제 경로와 맞지 않는 것이니 경로 패턴부터 확인하세요.

복호화 확인은 sops -d secrets/prod.enc.yaml입니다. no matching creation rules 오류가 나면 규칙 미스매치, failed to get the data key 오류가 나면 SOPS_AGE_KEY_FILE 환경변수가 개인키 경로를 가리키지 않는 경우입니다.

ASM을 쓴다면: ESO 최소 YAML

YAML
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secretsmanager
  namespace: prod
spec:
  provider:
    aws:
      service: SecretsManager
      region: ap-northeast-2
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-sa
---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: app-db-secret
  namespace: prod
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secretsmanager
    kind: SecretStore
  target:
    name: app-db-secret
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: prod/app/db
        property: password

적용 후 kubectl get externalsecret -n prod 결과의 STATUS가 SecretSynced면 정상입니다. SecretSyncedError라면 IRSA 서비스 어카운트에 secretsmanager:GetSecretValue 권한이 있는지부터 확인하세요.

실패 분기 3종 체크리스트

① Vault가 seal 되어 배포가 전면 중단됐다

Bash
vault status                      # Sealed: true 확인
vault operator unseal <key-share-1>
vault operator unseal <key-share-2>
vault operator unseal <key-share-3>   # threshold 만큼 반복

재발 방지는 KMS Auto-unseal 전환입니다. 설정 후 재기동하면 사람 개입 없이 unseal 됩니다.

HCL
seal "awskms" {
  region     = "ap-northeast-2"
  kms_key_id = "arn:aws:kms:ap-northeast-2:<account-id>:key/<key-id>"
}

② age 개인키를 분실했다

복구 방법은 없습니다. 사전 대비만이 답입니다. 암호화 시점에 수신자를 복수로 지정해 두세요.

Bash
sops -e --age "age1개발자키,age1백업키,age1CI키" secrets/prod.yaml > secrets/prod.enc.yaml
# 이미 암호화된 파일에 수신자 추가
sops updatekeys secrets/prod.enc.yaml

③ ASM 시크릿을 삭제했는데 같은 이름으로 재생성이 안 된다

ASM은 기본 7~30일의 복구 대기기간을 두므로, 대기 중인 이름은 재사용할 수 없습니다.

Bash
# 복구 (권장)
aws secretsmanager restore-secret --secret-id prod/app/db --region ap-northeast-2

# 즉시 완전 삭제 후 재생성 — 복구 불가, 신중히
aws secretsmanager delete-secret --secret-id prod/app/db \
  --force-delete-without-recovery --region ap-northeast-2

자주 묻는 질문 (FAQ)

Q. 시크릿이 몇 개부터 AWS Secrets Manager로 넘어가는 게 맞나요? A. 비용만 보면 SOPS가 항상 싸지만, 운영 시간을 인건비로 환산하면 시크릿 100~150개 구간에서 역전됩니다. 시크릿 150개면 ASM 요금은 150 × $0.40 = $60인데, 그 정도 규모에서 SOPS 재암호화·키 관리에 드는 시간은 월 2시간을 훌쩍 넘깁니다.

Q. Vault BSL 전환 때문에 지금 쓰던 Vault를 걷어내야 하나요? A. 자사 서비스 운영을 위한 내부 사용이라면 일반적으로 문제되지 않습니다. Vault를 기반으로 고객에게 시크릿 관리 기능을 제공·재판매하는 형태만 법무 검토 대상입니다. 라이선스 리스크 자체를 피하고 싶다면 OpenBao 포크가 대안입니다.

Q. SOPS만으로 ISMS-P 암호키 관리 항목을 통과할 수 있나요? A. 변경 이력(Git 커밋)은 제출할 수 있지만 열람 이력은 남지 않습니다. 조회 감사가 요구되는 항목이 있다면 SOPS 단독은 부족할 수 있으니, 해당 통제항목의 요구 원문을 확인하고 필요하면 ASM(CloudTrail) 또는 Vault audit device를 병행하는 구성을 검토하세요.

확인 정보
✦ ✦ ✦
편집 검토 · Editorial Review

Nodelog는 모든 콘텐츠의 내용과 출처를 공개 전에 검토합니다. 환경(OS·버전)에 따라 결과가 달라질 수 있는 기술 정보는 공식 문서와 함께 확인하며, 검토 기준과 정정 원칙은 편집 정책에서 안내합니다. 오류를 발견하시면 이메일로 제보해 주세요 — 확인 후 신속히 정정합니다.

편집 책임 · Nodelog 기술 편집팀·발행 · ·업데이트 ·

댓글

첫 번째 댓글을 남겨보세요.