인프라 드리프트 탐지와 복구 가이드: Terraform·GitOps 설정 어긋남을 막는 기준
결론부터 말하면, 인프라 드리프트 탐지는 ‘코드와 실제 설정이 다른지 찾는 작업’에서 끝나면 안 됩니다. 작은 팀이 실제로 필요한 것은 Terraform 상태 점검, GitOps 동기화 상태, 클라우드 콘솔 변경 이벤트, Slack 알림, 승인 기반 복구 플레이북을 하나의 운영 루프로 묶는 것입니다. 그리고 모든 드리프트를 자동 복구하면 오히려 장애 대응 중 필요한 임시 변경까지 되돌릴 수 있으므로, 자동 복구할 변경과 사람이 승인해야 할 변경을 먼저 나눠야 합니다.

운영 원칙은 단순합니다. 코드는 의도, 상태 파일은 기록, 클라우드 감사 로그는 증거입니다. 세 가지가 서로 다를 때는 먼저 증거를 보존하고, 그다음 keep, revert, import, ignore 중 하나를 선택해야 합니다.
1. 인프라 드리프트란 무엇인가: 실제로는 세 가지 기준이 어긋난다
Terraform을 쓰는 팀에서 드리프트는 보통 세 층에서 발생합니다. 첫째는 Terraform 코드, 둘째는 Terraform state, 셋째는 클라우드의 실제 리소스입니다. 누군가 콘솔에서 보안그룹을 열었거나, 장애 대응 중 인스턴스 타입을 바꾸었거나, 수동으로 생성한 리소스를 나중에 코드에 반영하지 않으면 이 세 기준이 갈라집니다. HashiCorp 공식 문서는 Terraform이 관리하는 리소스를 수동 변경하면 state와 실제 인프라가 어긋날 수 있고, 이후 Terraform이 이를 맞추려다 의도치 않은 destroy 또는 recreate를 유발할 수 있다고 설명합니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift))
GitOps 환경에서는 기준이 조금 다릅니다. Git에 있는 manifest가 의도 상태이고, 클러스터의 live object가 실제 상태입니다. Argo CD는 Git의 desired manifest와 클러스터 live state가 다를 때 자동 동기화할 수 있지만, live cluster에서 발생한 변경을 자동으로 되돌리려면 self-heal 같은 옵션을 의도적으로 켜야 합니다. 또한 prune은 안전장치 때문에 기본적으로 자동 삭제하지 않도록 설계되어 있습니다. ([argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/))
세 번째 축은 클라우드 거버넌스 기준입니다. 예를 들어 태그, IAM 권한, public access, 로그 보존, 암호화 설정은 Terraform에 모두 정의되어 있지 않을 수 있습니다. 이 경우 Terraform plan만으로는 ‘회사 운영 기준에서 벗어난 상태’를 전부 찾지 못합니다. 그래서 드리프트 탐지는 IaC 도구의 diff와 클라우드 감사·구성 변경 이벤트를 함께 봐야 합니다.
| 드리프트 유형 | 예시 | 주요 탐지 신호 | 첫 조치 |
|---|---|---|---|
| 수동 긴급 변경 | 장애 대응 중 RDS 파라미터 조정 | CloudTrail, change event, Terraform refresh-only diff | 티켓 확인 후 keep 또는 revert 결정 |
| 실수 변경 | SSH 22번 포트를 0.0.0.0/0으로 개방 | 보안그룹 diff, AWS Config rule, Slack 경고 | 위험도 높으면 승인된 runbook으로 즉시 복구 |
| 컨트롤러 변경 | HPA가 Deployment replicas 변경 | Argo CD OutOfSync, Flux drift log | 좁은 ignore 규칙 검토 |
| 미관리 리소스 | 콘솔에서 만든 임시 S3 버킷 | 클라우드 inventory, cost tag 누락 | 소유자 확인 후 import 또는 삭제 |
| 정책 자동복구 충돌 | 보안 정책 도구가 Terraform 설정을 계속 수정 | 반복되는 plan diff, 동일 리소스 잦은 이벤트 | 소스 오브 트루스 재정의 |
2. 작은 팀의 최소 구조: 탐지 도구보다 운영 루프가 먼저다
전담 SRE가 없는 팀은 드리프트를 매일 콘솔로 점검할 수 없습니다. 따라서 최소 구조는 ‘누가 바꿨는지 찾아내기’보다 ‘바뀌면 자동으로 모이고, 위험도별로 처리 방식이 정해지는 것’에 가깝습니다.

- 소유자 지도: 계정, 프로젝트, 클러스터, Terraform workspace, GitOps Application별 담당자를 지정합니다.
- Terraform 감지: 운영 workspace마다 scheduled
terraform plan -refresh-only를 실행하고 결과를 저장합니다. - GitOps 감지: Argo CD 또는 Flux의 OutOfSync, Drifted, Reconciliation 실패 이벤트를 알림으로 연결합니다.
- 클라우드 변경 이벤트: AWS Config·CloudTrail, Google Cloud Asset Inventory, Azure Resource Graph 같은 변경 이벤트를 별도 증거로 남깁니다.
- 분류 규칙: security, availability, cost, compliance, noise로 라벨링합니다.
- 복구 플레이북: 자동 복구, 승인 후 복구, 코드 반영, 무시 규칙 등록 중 하나로 처리합니다.
이미 GitOps 기반 배포 자동화를 고민 중이라면 GitOps로 하는 소규모 팀 배포 자동화에서 다룬 저장소 구조와 권한 설계를 먼저 정리해 두는 것이 좋습니다. 드리프트 탐지는 배포 자동화의 다음 단계가 아니라, 배포 자동화가 잘못된 상태를 계속 밀어 넣지 않도록 보정하는 운영 장치입니다.
3. Terraform 드리프트 탐지: refresh-only를 경고용과 복구용으로 구분한다
Terraform에서 드리프트 확인의 기본은 terraform plan -refresh-only입니다. Terraform 문서는 refresh-only planning mode가 Terraform state와 root module output을 Terraform 외부에서 변경된 remote object 상태에 맞추는 목적의 계획이라고 설명합니다. 또한 -refresh-only 옵션은 Terraform v0.15.4 이후 지원됩니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/cli/commands/plan))
작은 팀에서는 우선 다음처럼 ‘적용하지 않는 탐지 작업’으로 시작하는 것이 안전합니다.
terraform init -input=false
terraform plan -refresh-only -detailed-exitcode -no-color-detailed-exitcode는 자동화에서 유용합니다. Terraform plan 문서는 0을 empty diff, 1을 error, 2를 non-empty diff로 정의합니다. 즉 2가 나오면 Slack 알림 또는 이슈 생성을 트리거할 수 있습니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/cli/commands/plan))
주의할 점은 terraform refresh를 습관적으로 쓰지 않는 것입니다. Terraform refresh 명령은 deprecated 되었고, 사실상 terraform apply -refresh-only -auto-approve와 유사하게 동작하며 state를 자동으로 바꾸기 때문에 잘못된 provider credential 상황에서 위험할 수 있습니다. 공식 문서도 변경 내용을 검토할 수 있는 terraform apply -refresh-only를 권장합니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/cli/commands/refresh))
HCP Terraform을 쓰는 조직이라면 health assessments도 검토할 수 있습니다. 공식 튜토리얼에 따르면 health assessment는 non-actionable refresh-only plan으로 실제 설정을 workspace state의 리소스와 비교하며, state나 infrastructure configuration을 직접 업데이트하지 않습니다. 다만 drift detection은 configuration에 정의된 resource attribute 변경만 보고하므로, 운영상 중요한 attribute는 provider 기본값에 의존하지 말고 코드에 명시해야 합니다. ([docs.hashicorp.com](https://docs.hashicorp.com/terraform/tutorials/cloud/drift-detection))
Terraform 드리프트가 발견됐을 때의 선택지
| 선택 | 언제 쓰나 | 실무 절차 | 주의점 |
|---|---|---|---|
| Revert | 수동 변경이 실수이거나 보안 위험일 때 | main branch 기준 plan 확인 후 apply | 현재 장애 대응 중인 변경인지 먼저 확인 |
| Keep | 긴급 변경이 운영상 필요한 값으로 확정됐을 때 | HCL 수정, PR 리뷰, apply | state만 맞추고 코드를 방치하면 다음 배포에서 다시 어긋남 |
| Import | 수동 생성 리소스를 계속 관리해야 할 때 | resource block 작성 후 import, plan 검토 | 속성 누락 시 다음 apply에서 대규모 변경 가능 |
| Replace | 리소스가 손상됐거나 불변 인프라 패턴이 적합할 때 | 영향 범위 확인 후 replace 계획 수립 | 데이터 리소스는 백업·복원 검증이 먼저 |
| Ignore | 외부 시스템이 의도적으로 관리하는 필드일 때 | lifecycle 또는 정책 예외 문서화 | 보안 필드를 광범위하게 ignore하지 말 것 |
특히 -target은 복구용 임시 도구로만 봐야 합니다. Terraform plan 문서는 -target을 routine operation에 사용하면 감지되지 않은 configuration drift와 실제 상태에 대한 혼란을 만들 수 있다고 경고합니다. -refresh=false 역시 외부 변경을 무시해 불완전하거나 부정확한 plan을 만들 수 있습니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/cli/commands/plan))
4. GitOps 드리프트: self-heal과 prune을 분리해서 본다
Kubernetes에서는 드리프트가 더 자주 ‘정상 동작’처럼 보입니다. HPA가 replicas를 바꾸고, service mesh나 보안 webhook이 sidecar·annotation을 주입하고, cert-manager 같은 컨트롤러가 Secret을 갱신합니다. 따라서 GitOps에서 중요한 질문은 ‘왜 Git과 다르지?’가 아니라 ‘이 차이가 애플리케이션 의도에서 벗어난 위험한 차이인가?’입니다.
Argo CD는 automated sync로 Git과 live state 차이를 감지해 동기화할 수 있지만, 자동 pruning은 기본 안전장치 때문에 별도 설정이 필요합니다. self-heal도 별도로 켜야 live cluster 변경을 자동 동기화 대상으로 다룹니다. critical namespace나 shared resource 삭제는 Prune=confirm처럼 수동 확인을 요구하는 옵션을 두는 편이 안전합니다. ([argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/))
반면 Argo CD diff customization은 ‘노이즈 줄이기’에 유용하지만, 너무 넓게 쓰면 실제 위험을 숨깁니다. 공식 문서는 mutating webhook, Helm의 랜덤 템플릿 함수, HPA metrics reorder 같은 이유로 OutOfSync가 발생할 수 있고, 필요한 경우 특정 JSON path나 managedFields manager 기준으로 차이를 무시할 수 있다고 설명합니다. ([argo-cd.readthedocs.io](https://argo-cd.readthedocs.io/en/stable/user-guide/diffing/))
Flux의 HelmRelease는 .spec.driftDetection으로 cluster-state drift를 감지하고, mode: enabled일 때 server-side dry-run apply 결과를 바탕으로 drift correction을 시도할 수 있습니다. 또한 HPA의 replicas처럼 의도적으로 변하는 필드는 ignore rule로 제외할 수 있습니다. 운영에 바로 enabled를 적용하기보다 warn 또는 알림 모드로 먼저 노이즈를 확인하는 것이 실무적으로 안전합니다. ([fluxcd.io](https://fluxcd.io/flux/components/helm/helmreleases/))
| GitOps 설정 | 적합한 상황 | 주의점 |
|---|---|---|
| OutOfSync 알림만 | 도입 초기, 운영 노이즈 파악 | 사람이 계속 확인하지 않으면 경고 피로가 쌓임 |
| Self-heal | 앱 manifest를 Git이 명확히 소유 | 장애 대응 수동 패치를 되돌릴 수 있음 |
| Auto prune | 리소스 소유권이 명확한 namespace | 공유 리소스, namespace, PVC에는 확인 절차 필요 |
| Prune confirm | 삭제 영향이 큰 리소스 | 승인 지연 시 sync가 대기 상태로 남을 수 있음 |
| Ignore differences | HPA, webhook, controller-managed field | 보안·권한·네트워크 필드를 넓게 ignore하지 말 것 |
5. 클라우드 콘솔 변경은 Terraform과 별도로 기록해야 한다
Terraform plan은 Terraform이 관리하는 리소스의 관점입니다. 하지만 누가 콘솔에서 바꿨는지, 어떤 API client가 호출했는지, 관리되지 않는 리소스가 생겼는지는 클라우드 감사 로그가 더 잘 보여줍니다.
AWS에서는 AWS Config와 CloudTrail을 함께 보는 구성이 일반적입니다. AWS Config는 지원 리소스가 생성·변경·삭제될 때 configuration item으로 기록할 수 있고, continuous recording과 daily recording을 선택할 수 있습니다. 단, ephemeral workload가 많으면 기록량과 평가가 늘어날 수 있으므로 모든 리소스를 무조건 켜기보다 핵심 리소스부터 범위를 정하는 편이 좋습니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html))
CloudTrail Event history는 AWS 계정 생성 시 기본으로 사용할 수 있고, AWS Management Console, CLI, SDK, API를 통한 management event를 최근 90일 범위에서 조회할 수 있습니다. 다만 Event history는 단일 계정·단일 Region 검색 등 한계가 있으므로 조직 단위 장기 보존과 복합 쿼리가 필요하면 별도 trail 또는 event data store를 설계해야 합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/en_en/awscloudtrail/latest/userguide/view-cloudtrail-events.html))
Google Cloud에서는 Cloud Asset Inventory feed를 Pub/Sub와 연결해 지원 리소스, IAM policy, access policy, organization policy 변경 알림을 받을 수 있습니다. 공식 문서는 feed를 통해 specified assets 변경 시 Pub/Sub 메시지를 받을 수 있고, Cloud Run 함수 등을 연결해 변경 감지 후 되돌림 작업을 수행할 수도 있다고 설명합니다. 다만 자동 되돌림은 사전 승인된 필드에만 적용해야 합니다. ([docs.cloud.google.com](https://docs.cloud.google.com/asset-inventory/docs/monitor-asset-changes?authuser=19))
Azure에서는 Azure Resource Graph changes를 통해 리소스 변경을 쿼리할 수 있습니다. change event에는 changedBy, clientType, operation 같은 필드가 포함되어 변경 주체와 경로를 추적하는 데 유용합니다. Resource Graph overview는 최근 14일의 리소스 configuration change를 볼 수 있다고 설명합니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/governance/resource-graph/changes/get-resource-changes))
6. 자동 복구 기준: 되돌릴 수 있다고 해서 모두 되돌리면 안 된다
자동 복구는 빠른 해결책처럼 보이지만, 운영에서는 두 가지 위험이 있습니다. 첫째, 장애 대응 중 필요한 임시 변경을 자동으로 없앨 수 있습니다. 둘째, Terraform과 보안 정책 도구가 서로 다른 값을 계속 적용하면서 반복 루프를 만들 수 있습니다. AWS Config auto remediation도 manual 또는 automatic remediation을 지원하지만, 공식 문서는 compliance data snapshot이 주기적으로 캡처되기 때문에 경우에 따라 이미 compliant한 리소스에도 remediation이 시작될 수 있다고 주의합니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/config/latest/developerguide/setup-autoremediation.html))
Azure Policy도 modify 또는 deployIfNotExists definition assignment에 대해 remediation task로 non-compliant resource를 compliance 상태로 가져올 수 있습니다. 하지만 이는 policy assignment identity와 scope, failure threshold, resource discovery mode를 포함한 별도 운영 설계가 필요한 기능입니다. ([learn.microsoft.com](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/remediation-structure))

| 변경 유형 | 권장 대응 | 자동 복구 가능 조건 | 사람 승인 필요 조건 |
|---|---|---|---|
| SSH, DB 포트 public open | 즉시 알림 후 복구 | 허용 CIDR 기준이 명확하고 break-glass 티켓이 없을 때 | 마이그레이션, 장애 대응 티켓이 연결된 경우 |
| IAM admin 권한 부여 | 즉시 보안 담당자 호출 | 정책상 금지된 attachment를 제거하는 runbook이 검증된 경우 | 권한 체계 개편 중이거나 외부 IdP 변경과 관련된 경우 |
| 필수 태그 누락 | 자동 태그 또는 이슈 생성 | owner, cost-center를 계정·repo에서 확정할 수 있을 때 | 소유자를 알 수 없거나 비용 부서 배분이 필요한 경우 |
| HPA replicas 변경 | 경고하지 않거나 좁은 ignore | HPA가 명확히 소유한 필드일 때 | replicas가 비용·성능 사고와 연결된 경우 |
| DB storage, backup, deletion protection 변경 | 승인 후 복구 | 거의 없음 | 데이터 유실, 성능, 비용 영향이 큰 경우 |
| namespace, PVC, bucket 삭제 | 복구 절차 우선 | 테스트 환경의 ephemeral 리소스일 때 | 운영 데이터 또는 고객 파일이 있을 때 |
7. 복구 플레이북: apply 전에 증거와 의도를 맞춘다
드리프트를 발견했을 때 가장 위험한 행동은 ‘일단 apply’입니다. 작은 팀일수록 다음 절차를 고정해 두는 것이 좋습니다.
- 증거 수집: Terraform refresh-only plan, GitOps diff, 클라우드 change event, 배포 로그를 저장합니다.
- 변경 주체 확인: actor, role, client type, source IP, 관련 티켓을 확인합니다.
- 영향 범위 판단: 보안, 가용성, 비용, 데이터 유실 가능성을 분류합니다.
- 결정: keep, revert, import, replace, ignore 중 하나를 선택합니다.
- 검증: 운영 전 dev 또는 staging에서 plan, dry-run, sync preview를 확인합니다.
- 복구 실행: 가능하면 콘솔이 아니라 PR, pipeline, GitOps sync를 통해 복구합니다.
- 사후 조치: 권한, 알림 조건, 문서, runbook을 업데이트합니다.
예를 들어 보안그룹이 열린 경우 Slack 알림에는 최소한 account, region, resource id, changed field, old value, new value, actor, detected by, suggested action, approval link가 포함되어야 합니다. 단순히 ‘drift detected’라고 보내면 운영자가 다시 콘솔을 열어야 하고, 그 사이 복구가 지연됩니다.
비밀키·DB 비밀번호·API key 변경과 드리프트는 자주 연결됩니다. credential rotation이 수동으로 처리되면 state, secret store, 애플리케이션 환경변수가 서로 어긋날 수 있으므로 비밀관리 자동 회전 가이드처럼 비밀 관리 체계도 함께 정리해야 합니다. 또한 deletion protection, backup retention, bucket policy 같은 설정 드리프트는 복구 테스트와 이어지므로 백업 복원 테스트 자동화 가이드에서 다룬 복원 검증까지 연결하는 것이 좋습니다.
8. 2주 안에 시작하는 작은 팀 체크리스트

| 기간 | 해야 할 일 | 완료 기준 |
|---|---|---|
| 1일차 | 운영 계정, Terraform workspace, GitOps app 목록화 | 리소스별 owner와 repo가 표로 정리됨 |
| 2~3일차 | 운영 Terraform workspace에 refresh-only plan job 추가 | exit code 2일 때 Slack 또는 issue 생성 |
| 4~5일차 | Argo CD 또는 Flux 상태 알림 연결 | OutOfSync, Drifted, reconciliation failure가 채널로 들어옴 |
| 1주차 | 보안그룹, IAM, public bucket, 필수 태그부터 클라우드 change event 수집 | 누가 언제 바꿨는지 최소 90일 이상 추적 가능 |
| 2주차 | 자동 복구 후보 3개 이하 선정 | 되돌림 명령, 승인자, 예외 조건이 runbook에 있음 |
| 매월 | 드리프트 drill 실행 | 테스트 변경을 감지하고 복구까지 걸린 시간을 기록 |
9. 구현할 때 자주 놓치는 주의점
- 관리 범위 밖 리소스: Terraform은 자신이 관리하지 않는 리소스를 기본적으로 모두 알지 못합니다. 클라우드 inventory와 태그 정책을 함께 써야 합니다.
- provider default: 운영상 중요한 attribute를 코드에 명시하지 않으면 drift detection이 기대보다 덜 민감하게 동작할 수 있습니다.
- ignore 남용: GitOps의 ignoreDifferences나 Flux ignore rule은 노이즈를 줄이지만, 권한·네트워크·보안 설정을 숨기는 데 쓰면 안 됩니다.
- 자동복구 루프: 보안 도구가 수정하고 Terraform이 되돌리는 패턴이 반복되면 소유권을 재정의해야 합니다.
- 삭제 자동화: prune, delete, replace는 always-on 자동화보다 승인 기반이 안전합니다.
- 알림 피로: 모든 diff를 같은 채널로 보내면 중요한 보안 변경이 묻힙니다. severity와 owner routing이 필요합니다.
10. AgentMit/BizMit 관점: 작은 팀에 맞는 ‘최소 운영 자동화’부터
AgentMit가 이런 프로젝트에서 권하는 방향은 거창한 거버넌스 플랫폼부터 만드는 것이 아닙니다. 운영 계정 1~3개, Terraform workspace 몇 개, GitOps app 몇 개 수준이라면 먼저 scheduled drift check, Slack 알림, 승인 링크, runbook 문서화, 간단한 관리자 화면으로 충분합니다.
다만 SaaS, AI 서비스, 정부지원사업 MVP 이후의 운영 전환 단계에서는 담당자가 매번 콘솔을 확인하기 어렵습니다. 이때 BizMit 기반의 운영 대시보드에 드리프트 이벤트, 승인 상태, 복구 이력, 비용·보안 태그 누락 현황을 묶으면 비개발 PM이나 대표도 위험도를 볼 수 있습니다. AgentMit는 Terraform 상태 점검, GitOps 알림, 클라우드 이벤트 수집, Slack·메일 알림, 승인 기반 복구 플레이북을 작은 팀 규모에 맞게 설계·구현하는 방식으로 지원할 수 있습니다.
참고한 공식 문서
이 글은 2026년 8월 기준 HashiCorp Terraform, Argo CD, Flux, AWS, Google Cloud, Microsoft Azure의 공식 문서를 참고해 작성했습니다. 특히 Terraform refresh-only와 state drift, Argo CD self-heal·prune, Flux HelmRelease driftDetection, AWS Config·CloudTrail, Google Cloud Asset Inventory, Azure Resource Graph와 Policy remediation 문서를 운영 기준 수립에 참고했습니다. ([developer.hashicorp.com](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift))
FAQ
Q1. Terraform 드리프트 탐지는 얼마나 자주 돌려야 하나요?
운영 환경은 최소 하루 1회부터 시작하는 것이 현실적입니다. 변경이 잦은 서비스는 배포 전후 또는 업무 시간 중 몇 시간 단위로 확인할 수 있습니다. 단, 리소스가 많은 계정에서 너무 자주 실행하면 API 호출, 비용, 알림 노이즈가 증가할 수 있으므로 보안 핵심 리소스와 운영 workspace부터 우선 적용하세요.
Q2. 드리프트가 발견되면 Terraform apply로 바로 되돌리면 되나요?
아닙니다. 먼저 변경 주체와 사유를 확인해야 합니다. 장애 대응 중 필요한 임시 변경일 수 있기 때문입니다. 실수나 보안 위험이면 코드 기준으로 되돌리고, 의도된 변경이면 HCL 또는 manifest를 수정한 뒤 PR과 pipeline을 통해 반영해야 합니다.
Q3. Argo CD selfHeal을 켜면 모든 Kubernetes 드리프트가 자동 복구되나요?
selfHeal은 live cluster가 Git의 의도 상태와 다를 때 재동기화를 시도하지만, 모든 차이를 복구 대상으로 보면 안 됩니다. HPA, mutating webhook, controller-managed field는 정상적인 차이일 수 있으므로 좁은 ignore 규칙을 두는 것이 안전합니다.
Q4. 클라우드 콘솔 수동 변경을 완전히 금지해야 하나요?
원칙적으로는 Git과 Terraform을 통해 변경해야 하지만, 장애 대응용 break-glass 권한은 필요합니다. 대신 시간 제한 권한, 사유 기록, 변경 후 PR 반영, 다음 영업일 검토 같은 운영 규칙을 둬야 합니다.
Q5. 작은 팀도 별도 드리프트 탐지 도구를 꼭 도입해야 하나요?
처음부터 필수는 아닙니다. Terraform refresh-only plan, GitOps 상태 알림, 클라우드 변경 이벤트, Slack triage만으로도 충분히 시작할 수 있습니다. 계정·클러스터·서비스가 늘어나면 승인 대시보드와 이력 관리가 필요해질 수 있습니다.

