백엔드 엔지니어링 관점에서 두 서비스의 내부 동작 방식, 한계점, 그리고 하이브리드 패턴을 깊이 있게 분석한다.

1. 아키텍처 및 암호화 매커니즘 차이

두 서비스 모두 AWS KMS(Key Management Service)를 사용하여 데이터를 암호화하지만, 접근 방식에 미묘한 차이가 있다.

Paramater Store (SSM)

• 구조: 텍스트 저장소에 가깝다. String과 StringList는 평문으로 저장되며, SecureString타입만 KMS를 호출하여 암호화한다.
• KMS 호출: SecureString값을 조회할 때마다 내부적으로 kms:Decrypt가 호출된다. 따라서 대량의 파라미터를 한 번에 조회할 때 KMS 호찰 요청 제한(TPS)에 걸릴 위험이 있다.
• 제약: CloudFormation 템플릿에서 SecureString을 직접 참조하여 다른 리소스에 주입하는 것이 일부 제한적(Dynamic Reference 사용 필요)일 수 있다.

Secrets Manager

• 구조: “보안 객체” 저장소이다. 단순 문자열 뿐만 아니라 바이너리 데이터나 JSON 객체 전체를 하나의 비밀 단위로 암호화한다.
• Envelop Encryption: 데이터 키(Data Key)를 사용하여 데이터를 암호화하고, 그 데이터 키를 KMS 마스터 키로 다시 암호화하는 이중 구조를 가진다.
• Resource Policy: S3 버킷 정책처럼, 시크릿 자체에 리소스 기반 정책(Resource-based Policy)을 붙일 수 있다. “이 비밀번호는 A계정의 B역할만 읽을 수 있다”는 식의 제어가 IAM 제어보다 더 직관적이고 강력하다.

---

2. 처리량(Throughput)과 스케일링 제한 (숨겨진 함정)

대규모 마이크로서비스 환경에서 가장 많이 경험하는 문제이다.

기능	Parameter Store (Standard)	Parameter Store (Advanced)	Secrets Manager
최대 크기	4 KB	8 KB	64 KB
파라미터 수	계정당 10,000개	100,000개	제한 없음 (Soft Limit)
비용	무료	유료 ($0.05/월)	유료 ($0.40/월)
처리량(TPS)	기본 낮음	높은 처리량 설정 가능	기본적으로 높음

분석

• SSM Standard의 4KB 제한: RSA 프라이빗 키나 긴 라이선스 파일등은 4KB를 넘는 경우가 많아 Standard 티어에 저장할 수 없다.
• Throttling(조절): 서버 1000대가 동시에 배포되면서 GetParameter를 호출하면 SSM은 쉽게 스로틀링 에러를 뱉는다. 이때는 ‘처리량 증가’ 옵션을 켜야 하는데, 이 순간부터 비용이 발생한다.
• Secrets Manager 캐싱 필수: Secret Manager는 API 호출당 비용이 발생한다. 트래픽이 많은 서비스에서 매 요청마다 호출하면 요금이 너무 비싸다. 반드시 애플리케이션 메모리에 캐싱해야 한다.

---

3. 자동 교체(Rotation)의 내부 동작

Secret Manager의 가장 강력한 기능인 ‘자동 교체’는 Lambda 함수가 수행하는 상태 머신(State Machine)이다.

1. Create: 람다가 DB에 접속하여 새로운 비밀번호를 생성한다.
2. Set: 생성된 비밀번호를 DB의 ‘Pending’ 계정이나 임시 사용자로 설정한다.
3. Test: 새 비밀번호로 로그인이 되는지 테스트한다.
4. Finish: 새 비밀번호를 정식 버전으로 승격시키고 이전 버전을 내린다.

SSM과의 차이점: SSM으로 이를 구현하려면 위 4단계를 직접 CloudWatch Events와 Lambda로 짜야 한다. Secrets Manager는 이 복잡한 로직을 AWS가 미리 만들어둔 템플릿으로 제공하므로 클릭 몇 번으로 끝낼 수 있다.

---

4. 통합성 (Cross-Account & K8s)

크로스 계정 액세스 (Cross-Account Access)

• 시나리오: 보안 계정(A)에 모든 DB 암호를 두고, 서비스 계정(B)의 EC2가 이를 읽어가야 한다.
• Secrets Manager: 시크릿 자체에 리소스 정책을 붙여 “계정 B의 접근 허용”을 명시하면 끝난다 매우 쉽다.
• SSM: 계정 A에서 B로 IAM Role을 Assume(위임)하는 복잡한 과정이 필요하거나, 최근 추가된 RAM(Resoutce Access Manager) 공유 기능을 써야 하는데 설정이 번거롭다.

Kubernetes (EKS) 통합

• External Secrets Operator (ESO): 쿠버네티스 환경에서는 보통 ESO를 설치하여 AWS 저장소의 값을 K8s Secret으로 동기화한다.
• 두 서비스 모두 ESO와 잘 붙지만, Secrets Manager가 DB 자격 증명(JSON)을 파싱하여 개발 K8s 환경 변수로 매칭하기에 더 구조적으로 유리하다.

---

5. 하이브리드 패턴 (Best Practice)

실무에서는 두 서비스 중 하나만 선택하지 않고 상황에 따라서 적절하게 섞어서 쓰는 것이 정석이다.

추천 아키텍처: 계층형 구성

1. Parameter Store: 애플리케이션의 지도 역할을 한다
   • /prod/payment/db/host -> db-prod.cluster.aws.com
   • /prod/payment/db/port -> 3306
   • /prod/payment/db/timeout -> 5000
2. Secret Manager: 실제 열쇠를 보관한다.
   • prod/payment/db/credentials -> {"user": "admin", "password": "xhfk..."}
3. 애플리케이션 로직
   • 앱은 설정 로딩 시 SSM을 먼저 확인한다
   • SSM 값 중 일부가 Secrets Manager를 가리키고 있다면(참조), 그 때만 Secrets Manager를 호출한다.

요약표

결정 요소	선택 가이드
단순 설정 (URL, 로그 레벨)	Parameter Store (Standard)
DB 비밀번호, OAuth 토큰	Secrets Manager
자동 교체 필요	Secrets Manager
대용량 파일/설정 (> 4KB)	Parameter Store (Advanced) 또는 S3
비용 최우선	Parameter Store
다른 계정과 공유	Secrets Manager (더 편리함)