Parameter Store는 구성 데이터 관리 및 암호 관리를 위한 안전하고 확장 가능한 계층적 저장소를 제공한다. 이를 통해 애플리케이션 코드와 설정 데이터를 완벽히 분리하여 관리할 수 있다.

1. 주요 특징

1.1 데이터 타입

• String: 일반적인 텍스트 데이터를 저장한다. 예를 들어, 마이크로서비스 간 통신을 위한 API 엔드포인트 URL, 애플리케이션의 기본 언어 설정, 또는 INFO, DEBUG와 같은 런타임 로그 레벨 설정이 여기에 해당한다.
• StringList: 쉼표(,)로 구분된 문자열 배열이다. 허용된 IP 화이트리스트(10.0.1.5,10.0.1.10), 서비스가 참조해야 할 다중 서브넷 ID 목록 등을 관리할 때 유용하며, 애플리케이션에서 파싱하기 용이한 구조를 가진다.
• SecureString: KMS(Key Management Service)를 사용하여 데이터를 암호화한 상태로 저장합니다. 데이터베이스 비밀번호, 서드파티 서비스의 API Secret Key, 라이선스 키 등 외부로 노출되어서는 안 되는 민감한 정보를 다룰 때 필수적으로 선택해야 하는 타입이다.

1.2 계층적 구조 (Path 기반)

단순한 키-값 쌍을 넘어, 유닉스 파일 시스템과 유사한 경로 구조를 통해 수만 개의 파라미터를 체계적으로 관리할 수 있다.

• /prod/backend/order-service/db-url
• /prod/backend/payment-service/api-key
• /dev/infra/common/vpc-id
• 이러한 계층 구조를 활용하면 권한 제어(IAM) 시에도 특정 경로(예: /dev/*)에 대해서만 접근을 허용하는 등 매우 세밀한 보안 정책 수립이 가능해진다. 또한 환경별(dev/stage/prod)로 동일한 이름의 파라미터를 유지하면서 값만 다르게 설정할 수 있어 배포 파이프라인 관리가 수월해진다.

1.3 버전 관리 및 이력 추적

• 파라미터 값이 변경될 때마다 자동으로 새로운 버전 번호(v1, v2, v3...)가 할당된다. 이는 "어제까지 잘 되던 서버가 왜 갑자기 안 되지?"와 같은 상황에서 설정 변경 이력을 즉시 확인하고, 필요시 이전 버전의 정상적인 값으로 즉각 복구(Rollback)할 수 있는 안전장치 역할을 한다. 특히 SecureString의 경우 누가 언제 값을 변경했는지에 대한 감사 로그도 함께 관리할 수 있다.

---

2. Secrets Manager vs Parameter Store (비교)

백엔드 인프라 설계 시 가장 자주 고민하게 되는 지점이다. 서비스의 규모와 예산, 보안 요구사항에 따라 선택이 달라진다.

구분	Parameter Store (SSM)	Secrets Manager
주 목적	일반적인 구성 설정 및 가벼운 보안 값 관리	고도의 보안이 필요한 민감 정보 전문 관리
비용	표준 파라미터 기준 무료 (데이터 추가 시 비용 발생)	보안 정보당 월 $0.40 + API 호출당 비용 발생
자동 교체	지원하지 않음 (수동 변경 필요)	기본 지원 (RDS, Redshift 등 암호 자동 로테이션)
복잡성	구조가 단순하여 도입 및 러닝커브가 매우 낮음	로테이션 람다 함수 등 설정할 요소가 상대적으로 많음
데이터 크기	표준 최대 4KB, 고급 최대 8KB	최대 64KB까지 지원

---

3. 백엔드 실무 활용 사례

3.1. 환경별 설정 관리 (Environment-Specific Config)

애플리케이션 코드는 하나지만 배포되는 환경은 다양하다. Parameter Store를 사용하면 배포 시점에 환경 변수를 주입받는 대신, 런타임에 AWS에서 직접 값을 읽어온다.

• 예시: 서버가 시작될 때 APP_PROFILE 환경 변수를 읽어 /prod/myapp/ 또는 /dev/myapp/ 경로 아래의 모든 설정을 한꺼번에 로드하여 DB 접속 정보나 캐시 서버 주소를 동적으로 결정한다.

3.2. 피처 플래그 및 카나리 배포 (Feature Flag)

새로운 기능을 배포한 후, 특정 로직의 활성화 여부를 결정하는 스위치 역할을 한다.

• 실무 시나리오: 신규 결제 모듈을 배포했지만 안정성이 우려될 때, feature.new-payment.enabled 값을 false로 두었다가 운영 중에 모니터링하며 true로 변경한다. 이 과정에서 서버 재시작이나 코드 재배포가 전혀 필요 없어 운영 리스크를 최소화한다.

3.3. 로그 레벨 및 타임아웃의 동적 변경

운영 중에 갑작스러운 장애가 발생했을 때 상세 로그가 필요할 수 있다.

• 동작 방식: 기본 로그 레벨을 INFO로 운영하다가, 특정 이슈 분석이 필요할 때 파라미터 값을 DEBUG로 변경한다. 애플리케이션 내에 파라미터 변경을 감지하는 로직(예: Spring Cloud Bus 등)이 있다면 실시간으로 로그 출력이 변경되어 장애 대응 속도가 빨라진다.

---

4. 백엔드 개발자 실무 팁

1. Spring Boot 연동 최적화: spring-cloud-starter-aws-parameter-store-config 라이브러리를 사용하면 외부 설정 소스로 자동 등록된다. bootstrap.yml이나 application.yml에 경로를 지정해두면 @Value("${db-url}") 처럼 익숙한 방식으로 데이터를 사용할 수 있으며, 프로퍼티 우선순위 전략을 통해 로컬 설정과 클라우드 설정을 유연하게 교체할 수 있다.
2. 보안 및 최소 권한 원칙: 민감한 정보는 반드시 SecureString을 사용하고, 이를 해독하는 데 필요한 KMS 키 권한을 애플리케이션이 구동되는 EC2나 ECS의 IAM Role에 명시적으로 부여해야 한다. 접근 제어 시 Resource: "arn:aws:ssm:*:*:parameter/prod/*"와 같이 와일드카드를 활용해 특정 환경의 파라미터만 접근 가능하도록 제한하는 것이 중요하다.
3. API 호출 효율성 (GetParametersByPath): 수십 개의 설정을 하나하나 GetParameter로 가져오는 것은 네트워크 오버헤드와 비용을 발생시킨다. GetParametersByPath API를 사용하여 특정 접두사(예: /prod/service-a/) 아래의 모든 설정을 한 번의 호출로 가져오는 방식을 권장한다. 또한 빈번한 조회가 발생하는 서비스라면 메모리 내에 짧은 TTL을 가진 캐시를 두어 AWS API 호출 횟수를 조절하는 것이 성능상 유리하다.

---

5. 요약: 언제 무엇을 쓸까?

• 인프라 운영 비용을 최소화하고 싶고, 단순한 문자열 설정(API 주소, 로그 레벨, 일반 옵션 등) 위주로 관리한다면? -> Parameter Store
• 강력한 보안 규정을 준수해야 하며, 데이터베이스 비밀번호를 주기적으로 자동 변경(Rotation)하는 기능이 필수적이라면? -> 비용이 들더라도 Secrets Manager를 선택하는 것이 장기적으로 안전