인프라 드리프트 탐지와 복구 가이드: Terraform·GitOps 설정 어긋남을 막는 기준 > 인사이트

본문 바로가기

인사이트

#클라우드·DevOps

인프라 드리프트 탐지와 복구 가이드: Terraform·GitOps 설정 어긋남을 막는 기준

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

Terraform과 GitOps 드리프트를 점검하는 클라우드 운영 대시보드
코드, 상태 파일, 실제 클라우드 설정이 어긋나는 순간을 빠르게 확인할 수 있어야 합니다.

운영 원칙은 단순합니다. 코드는 의도, 상태 파일은 기록, 클라우드 감사 로그는 증거입니다. 세 가지가 서로 다를 때는 먼저 증거를 보존하고, 그다음 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 GitOps 클라우드 이벤트를 Slack과 승인 플레이북으로 연결한 운영 흐름도
드리프트 탐지는 도구 하나가 아니라 코드, 이벤트, 판단 기준, 복구 권한의 연결 구조입니다.
  1. 소유자 지도: 계정, 프로젝트, 클러스터, Terraform workspace, GitOps Application별 담당자를 지정합니다.
  2. Terraform 감지: 운영 workspace마다 scheduled terraform plan -refresh-only를 실행하고 결과를 저장합니다.
  3. GitOps 감지: Argo CD 또는 Flux의 OutOfSync, Drifted, Reconciliation 실패 이벤트를 알림으로 연결합니다.
  4. 클라우드 변경 이벤트: AWS Config·CloudTrail, Google Cloud Asset Inventory, Azure Resource Graph 같은 변경 이벤트를 별도 증거로 남깁니다.
  5. 분류 규칙: security, availability, cost, compliance, noise로 라벨링합니다.
  6. 복구 플레이북: 자동 복구, 승인 후 복구, 코드 반영, 무시 규칙 등록 중 하나로 처리합니다.

이미 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 리뷰, applystate만 맞추고 코드를 방치하면 다음 배포에서 다시 어긋남
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 differencesHPA, 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 변경경고하지 않거나 좁은 ignoreHPA가 명확히 소유한 필드일 때replicas가 비용·성능 사고와 연결된 경우
DB storage, backup, deletion protection 변경승인 후 복구거의 없음데이터 유실, 성능, 비용 영향이 큰 경우
namespace, PVC, bucket 삭제복구 절차 우선테스트 환경의 ephemeral 리소스일 때운영 데이터 또는 고객 파일이 있을 때

7. 복구 플레이북: apply 전에 증거와 의도를 맞춘다

드리프트를 발견했을 때 가장 위험한 행동은 ‘일단 apply’입니다. 작은 팀일수록 다음 절차를 고정해 두는 것이 좋습니다.

  1. 증거 수집: Terraform refresh-only plan, GitOps diff, 클라우드 change event, 배포 로그를 저장합니다.
  2. 변경 주체 확인: actor, role, client type, source IP, 관련 티켓을 확인합니다.
  3. 영향 범위 판단: 보안, 가용성, 비용, 데이터 유실 가능성을 분류합니다.
  4. 결정: keep, revert, import, replace, ignore 중 하나를 선택합니다.
  5. 검증: 운영 전 dev 또는 staging에서 plan, dry-run, sync preview를 확인합니다.
  6. 복구 실행: 가능하면 콘솔이 아니라 PR, pipeline, GitOps sync를 통해 복구합니다.
  7. 사후 조치: 권한, 알림 조건, 문서, 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만으로도 충분히 시작할 수 있습니다. 계정·클러스터·서비스가 늘어나면 승인 대시보드와 이력 관리가 필요해질 수 있습니다.

자주 묻는 질문

Terraform 드리프트 탐지는 얼마나 자주 돌려야 하나요?
운영 환경은 최소 하루 1회, 변경이 잦은 서비스는 배포 전후 또는 업무 시간 중 몇 시간 단위로 확인하는 구조가 현실적입니다. 단, 리소스 수가 많으면 API 호출·비용·알림 노이즈가 커지므로 워크스페이스를 서비스·환경 단위로 나누고 보안 핵심 리소스부터 우선 적용하는 편이 좋습니다.
드리프트가 발견되면 Terraform apply로 바로 되돌리면 되나요?
바로 apply부터 실행하면 안 됩니다. 먼저 누가 왜 변경했는지 CloudTrail, 감사 로그, 배포 이력, 장애 티켓을 확인해야 합니다. 의도된 긴급 변경이면 코드를 수정하거나 import로 관리 범위에 넣고, 실수나 위험 변경이면 코드 기준으로 복구합니다.
Argo CD selfHeal을 켜면 모든 Kubernetes 드리프트가 자동 복구되나요?
selfHeal은 live cluster가 Git의 의도 상태와 달라졌을 때 재동기화를 시도하는 옵션이지만, 모든 필드에 무조건 적합한 것은 아닙니다. HPA의 replicas, mutating webhook이 주입하는 필드, 컨트롤러가 관리하는 status성 필드는 좁은 ignore 규칙을 두는 것이 안전합니다.
클라우드 콘솔 수동 변경을 완전히 금지해야 하나요?
운영 원칙은 금지가 맞지만, 장애 대응용 break-glass 경로는 남겨야 합니다. 대신 사유 입력, 시간 제한 권한, 변경 후 티켓 작성, 다음 영업일 코드 반영 같은 규칙이 필요합니다. 수동 변경 자체보다 수동 변경이 코드와 운영 기록에 반영되지 않는 것이 더 큰 문제입니다.
작은 팀도 별도 드리프트 탐지 도구를 꼭 도입해야 하나요?
처음부터 전용 도구가 필수는 아닙니다. Terraform refresh-only plan, GitOps 상태 알림, 클라우드 변경 이벤트, Slack triage만으로도 기본 체계를 만들 수 있습니다. 다만 계정·프로젝트·클러스터가 늘어나면 승인 워크플로와 대시보드가 필요해질 수 있습니다.
  • Company. 주식회사 에이전트밋
  • Addr.부산광역시 남구 전포대로 133, 11층 102호(문현동) CEO. 윤성훈 Email. agentmit@naver.com
  • BR. 333-87-04232 TEL. 0507-1314-2790
Copyright © 2026 ~ 에이전트밋. All rights reserved.