Secrets Manager vs 하드코딩: DB 비밀번호를 코드에 넣으면 안 되는 이유
레포지토리가 private이니까 괜찮다고 생각했던 DB 비밀번호가 GitHub 유출 사고의 주인공이 되는 건 순식간이다. Secrets Manager를 왜 써야 하는지, 자동 로테이션이 실제로 어떻게 동작하는지 운영 관점에서 정리한다. TL;DR: 핵심 비교 항목 하드코딩 / 환경변수 AWS Secrets Manager 비밀번호 노출 경로 코드, 로그, CI/CD 환경변수 API 호출 시점에만 메모리 접근 로테이션 수동 (배포 필요) 자동 (Lambda 기반, 무중단) 감사 추적 없음 CloudTrail로 모든 접근 기록 접근 제어 코드 접근 권한 = 비밀번호 접근 IAM 정책으로 세분화 비용 0원 (보안 사고 비용 제외) 시크릿당 월 과금 — AWS 공식 문서 확인 왜 Secrets Manager가 필요한가 — 하드코딩의 실제 위협 모델 'private 레포니까 괜찮다'는 가정이 깨지는 시나리오는 생각보다 많다. 팀원 계정 탈취, 실수로 public 전환, CI/CD 파이프라인 로그 노출, 컨테이너 이미지 레이어 분석 — 이 중 하나라도 발생하면 비밀번호가 코드에 있는 순간 게임 오버다. 환경변수도 완전한 해결책이 아니다. docker inspect , /proc/<pid>/environ , 애플리케이션 에러 로그에 환경변수가 그대로 출력되는 사례는 실제 운영 환경에서 반복적으로 발생한다. 비밀번호를 '어디에 두느냐'가 아니라 '누가, 언제, 어떤 경로로 접근하느냐'를 제어하는 것이 핵심이다. 하드코딩은 자물쇠 없는 금고다. 금고가 지하실에 있다고 안전한 게 아니다 — 지하실 문이 열리는 순간 모든 게 노출된다. Secrets Manager 동작 원리 Secrets Manager는 단순한 키-값 저장소가 아니다. 시크릿 값 자체...