앱 설정과 비밀번호를 한데 섞어 두면 언젠가 시크릿이 로그나 저장소에 새어 나갑니다. App Configuration과 Key Vault의 역할을 용도·보안·비용 기준으로 비교하고, 설정과 시크릿을 어떻게 나눠 관리할지 정리했습니다.
- App Configuration : 민감하지 않은 설정값·기능 플래그의 중앙 저장소. 버전·레이블·실시간 갱신에 강함.
- Key Vault : 비밀번호·연결 문자열·인증서·암호화 키의 금고. 엄격한 접근 통제와 감사.
- 권장 : 함께 쓰되, App Configuration엔 Key Vault 참조만 두어 시크릿은 금고에 남긴다.
두 서비스는 경쟁 관계가 아니라 역할 분담입니다. “이 값이 노출되면 위험한가?”가 갈림길입니다. 위험하면 Key Vault, 아니면 App Configuration. 실무에서는 대부분 둘을 함께 쓰고, 그 연결 방식이 설계의 핵심입니다.
두 서비스 한눈에 비교
| 기준 | App Configuration | Key Vault |
|---|---|---|
| 저장 대상 | 설정값, 기능 플래그 | 시크릿, 키, 인증서 |
| 민감도 | 낮음(비밀 아님) | 높음(비밀) |
| 암호화·격리 | 기본 암호화 | HSM 지원·강한 격리 |
| 버전·레이블 | 레이블로 환경 분리 강력 | 시크릿 버전 관리 |
| 실시간 갱신 | 동적 새로 고침 지원 | 회전(rotation) 중심 |
| 접근 통제 | RBAC | RBAC/액세스 정책 + 감사 로그 |
| 주 용도 | 앱 동작 제어 | 비밀 보호 |
정리하면 App Configuration은 “앱이 어떻게 동작할지“를, Key Vault는 “앱이 무엇으로 인증할지“를 담당합니다. 전자는 자주 바꾸고 넓게 공유해도 되지만, 후자는 최소 권한으로 좁게 통제해야 합니다.
기능 플래그와 동적 설정
App Configuration의 강점은 기능 플래그와 동적 새로 고침입니다. 코드를 재배포하지 않고 특정 기능을 켜고 끄거나, 일부 사용자에게만 신규 기능을 노출할 수 있습니다. 또 설정값을 바꾸면 애플리케이션이 재시작 없이 새 값을 반영하도록 구성할 수 있어, 운영 중 튜닝이 쉽습니다. 레이블(예: dev, prod)로 환경별 설정을 한 저장소에서 깔끔하게 나눌 수도 있습니다.
권장 패턴: Key Vault 참조
가장 좋은 조합은 App Configuration에 Key Vault 참조를 두는 것입니다. 시크릿의 실제 값은 Key Vault에만 저장하고, App Configuration에는 “이 설정의 값은 여기 Key Vault에 있다”는 포인터만 넣습니다. 애플리케이션은 App Configuration 한 곳만 바라보면 되면서도, 시크릿은 Key Vault의 접근 통제·감사·회전 기능을 그대로 누립니다.
# App Configuration에 일반 설정 저장
az appconfig kv set --name myAppConfig \
--key "App:MaxRetries" --value "3"
# Key Vault에 시크릿 저장
az keyvault secret set --vault-name myVault \
--name "DbPassword" --value "***"
# App Configuration에 Key Vault 참조 등록 (값이 아니라 참조)
az appconfig kv set-keyvault --name myAppConfig \
--key "App:DbPassword" \
--secret-identifier "https://myVault.vault.azure.net/secrets/DbPassword"여기에 관리 ID를 결합하면 애플리케이션이 연결 문자열이나 키 없이 App Configuration과 Key Vault에 접근할 수 있어, 시크릿 노출 지점을 근본적으로 줄일 수 있습니다.
민감하지 않은 설정·기능 플래그는 App Configuration, 비밀번호·키·인증서는 Key Vault. 그리고 App Configuration엔 시크릿 값 대신 Key Vault 참조만 두어 앱은 한 곳만 바라보게 하세요.
비용 감각
Key Vault는 시크릿·키 작업(operation) 수에 따라 과금되므로, 매 요청마다 Key Vault를 직접 호출하면 비용과 지연이 쌓입니다. 그래서 값을 캐시하고 일정 주기로만 새로 고치는 패턴이 중요합니다. App Configuration도 요청·저장에 요금이 있지만, 설정을 앱 시작 시 로드하고 동적 새로 고침 간격을 적절히 두면 비용을 낮게 유지할 수 있습니다.
흔한 실수
- 시크릿을 App Configuration에 평문으로 넣는다 — App Configuration은 시크릿용 금고가 아닙니다. 비밀값은 Key Vault에 두고 참조만 넣으세요.
- 매 요청마다 Key Vault를 호출한다 — 작업당 과금·지연이 누적됩니다. 캐시 + 주기적 회전으로 호출을 줄이세요.
- 연결 문자열·키를 코드나 앱 설정에 하드코딩한다 — 소스 유출 시 그대로 노출됩니다. 관리 ID로 인증해 시크릿 자체를 코드에서 없애세요.
- 접근 권한을 넓게 준다 — Key Vault는 최소 권한이 핵심입니다. 필요한 앱·사람에게만, 필요한 시크릿에만 권한을 부여하세요.
- 회전 계획 없이 시크릿을 방치한다 — 오래된 비밀번호·키는 위험입니다. 회전 주기를 정하고, 참조 방식으로 두면 값만 바꿔도 앱이 자동 반영합니다.
어떻게 나눌지 한 문장 기준
모호할 때는 이 질문 하나면 충분합니다. “이 값이 깃 저장소나 로그에 찍혀도 괜찮은가?” 괜찮으면 App Configuration, 아니면 Key Vault입니다. 최대 재시도 횟수·타임아웃·기능 플래그는 전자, 비밀번호·API 키·인증서 개인 키는 후자입니다.
자주 묻는 질문
- Q. App Configuration과 Key Vault는 무엇이 다른가요?
App Configuration은 기능 플래그·동작 옵션 같은 일반 설정을 중앙 관리하고, Key Vault는 비밀번호·연결 문자열·인증서·키를 암호화해 저장하며 접근을 엄격히 통제합니다. - Q. 둘을 함께 써야 하나요?
권장됩니다. App Configuration에 설정을 두되 시크릿은 Key Vault에 저장하고 App Configuration엔 참조만 넣으면, 앱은 한 곳만 보면서 시크릿은 금고의 보호를 받습니다. - Q. 연결 문자열은 어디에 두나요?
비밀번호·키가 포함되면 시크릿이므로 Key Vault, 서버 주소·DB 이름처럼 민감하지 않은 부분만이면 App Configuration에 둘 수 있습니다. - Q. 시크릿을 코드에서 완전히 없앨 수 있나요?
관리 ID로 App Configuration·Key Vault에 인증하면 연결 문자열·키 없이 접근할 수 있어, 코드와 설정에서 시크릿을 제거할 수 있습니다.
정리하면, 설정과 시크릿은 같은 서랍에 넣지 않는 것이 원칙입니다. 동작을 제어하는 값은 App Configuration에서 유연하게, 노출되면 위험한 값은 Key Vault에서 엄격하게. 둘을 참조로 연결하고 관리 ID를 얹으면, 편의와 보안을 동시에 챙길 수 있습니다.