코드와 실제 서버가 따로 노는 순간, 서비스는 무너집니다 — 설정 드리프트(Configuration Drift)의 공포

사소한 수동 수정이 어떻게 거대한 시스템 장애와 보안 구멍으로 이어지는지, 그리고 이를 자동화로 해결하는 방법을 다룹니다.

제가 12년 동안 인프라를 관리하면서 뼈저리게 느낀 게 하나 있어요. 정말 많은 장애를 겪어봤지만, 사실 그 어떤 단일 소프트웨어 버그보다 더 무섭고 빈번하게 시스템을 무너뜨리는 건 바로 ‘설정 드리프트’였습니다 [7]. 코드는 멀쩡한데 서버가 죽어있고, 분명히 설정을 바꿨는데 반영이 안 되는 그 당혹스러운 순간들 말이죠.

결국 설정 드리프트라는 건 어느 날 갑자기 터지는 큰 사고가 아니에요. “이번 한 번만 그냥 콘솔에서 고치고 나중에 반영하자” 같은, 무해해 보이는 작은 수동 변경들이 조금씩 쌓여 발생하는 ‘정적 상태의 붕괴’입니다. 이걸 막는 유일한 방법은 IaC(Infrastructure as Code)를 기반으로 상태를 지속적으로 감지하고, 강제로 동기화하는 체계를 만드는 것뿐입니다.

설정 드리프트: 소리 없이 다가오는 인프라의 ‘침식’

설정 드리프트를 쉽게 설명하자면, 우리가 승인하고 기록해둔 ‘기준점(코드)’과 ‘실제 서버의 상태’가 시간이 흐르면서 조금씩 어긋나는 현상을 말해요.

“Configuration drift refers to the gradual divergence of cloud resources from approved baselines.” [2]

(설정 드리프트란 클라우드 리소스가 승인된 베이스라인에서 점진적으로 벗어나는 것을 의미합니다.)

이게 무서운 이유는 하룻밤 사이에 쾅 하고 일어나는 게 아니라, 아주 천천히 그리고 조용히 진행되기 때문입니다 [1].

처음에는 아주 작은 설정 하나를 바꾼 걸 거예요. 그런데 그런 일이 몇 번 반복되면 어떻게 될까요? 결국 엔지니어는 손에 ‘낡은 설계도(코드)’를 들고 있지만, 정작 운영 중인 ‘실제 시스템’은 설계도와 완전히 다른 모습이 되어버립니다. 설계도를 믿고 배포를 눌렀는데 예상치 못한 곳에서 에러가 터지는 이유가 바로 여기에 있죠 [2].

왜 코드를 짰는데도 ‘수동 수정’의 유혹에 빠지는가?

분명히 IaC를 도입했고 코드로 관리하고 있는데, 왜 우리는 자꾸 콘솔(GUI)에 접속해서 마우스 클릭을 하게 될까요? 사실 실무에서는 그럴 수밖에 없는 상황이 정말 많습니다.

가장 흔한 케이스는 긴급 장애 대응 상황이에요. 서비스가 죽어가고 있는데 CI/CD 파이프라인을 태우고 코드 리뷰를 기다릴 여유가 있을까요? 일단 콘솔에서 빠르게 값을 수정해서 불부터 끄고 보죠. 문제는 그 ‘임시 수정’이 정식 코드로 다시 반영되지 않은 채 잊혀진다는 겁니다 [2].

그 외에도 이런 이유들이 있어요.

• 콘솔의 편리함: 코드 몇 줄 쓰고 terraform apply를 기다리는 것보다 클릭 한 번이 훨씬 빠르니까요.
• 관리 체계의 부재: 여러 팀이 겹치는 IaC 설정을 사용하거나, 정해진 워크플로우 밖에서 돌아가는 별도의 자동화 스크립트가 있을 때 드리프트는 더 심해집니다 [6].

결국 “지금 당장 해결하는 것”에 매몰되다 보면, 인프라의 진실의 원천(Source of Truth)인 코드를 외면하게 되는 함정에 빠지게 됩니다.

방치된 드리프트가 초래하는 치명적 결과

“뭐, 조금 달라도 작동만 하면 되는 거 아니야?”라고 생각하실 수 있어요. 하지만 이 작은 간극이 나중에는 감당할 수 없는 리스크로 돌아옵니다.

첫째로, 시스템 동작을 예측할 수 없게 됩니다. 스테이징 환경과 운영 환경의 코드는 똑같은데 실제 상태가 다르다면? 스테이징에서 성공한 배포가 운영에서만 실패하는 ‘귀신 곡할 노릇’인 상황이 벌어집니다 [3].

둘째는 보안과 컴플라이언스 문제예요. 누군가 테스트를 위해 잠시 열어둔 보안 그룹(Security Group) 포트가 드리프트로 인해 방치되었다고 생각해보세요. GDPR이나 HIPAA 같은 엄격한 규정을 준수해야 하는 환경이라면, 이런 작은 실수 하나가 막대한 벌금이나 법적 책임, 심지어 데이터 유출로 이어질 수 있습니다 [3].

마지막으로 복구 시간(MTTR)이 급격히 늘어납니다. 장애가 났을 때 가장 먼저 하는 게 코드를 보고 상태를 파악하는 것이죠. 그런데 코드가 거짓말을 하고 있다면? 실제 서버에 일일이 접속해서 설정을 대조해야 합니다. 트러블슈팅 난이도가 안드로메다로 가는 거죠 [3].

안티패턴: ‘나중에 코드에 반영하면 되겠지’라는 생각

제가 현장에서 가장 많이 본 위험한 생각 중 하나가 바로 “일단 고치고, 나중에 한꺼번에 업데이트하자”는 태도입니다.

냉정하게 말씀드리면, ‘나중’은 절대 오지 않습니다. 장애가 해결되고 나면 다들 바빠지거든요. 그렇게 수동으로 처리된 변경사항들은 시스템의 보이지 않는 흉터처럼 남게 됩니다. 결국 제어되지 않은 프로세스 외부의 변경은 시스템의 불안정성을 높이고 다운타임을 증가시키는 주범이 됩니다 [3].

또한, 드리프트 감지 도구 없이 사람이 일일이 체크하는 ‘수동 감사(Audit)’에만 의존하는 것도 전형적인 안티패턴이에요. 사람이 수천 개의 리소스를 일일이 대조하는 건 불가능에 가깝고, 실수할 확률만 높습니다. “작동하니까 됐다”는 믿음은 인프라 엔지니어에게 가장 위험한 신호입니다.

드리프트를 잡는 기술적 전략: 감지에서 강제화까지

그럼 어떻게 해야 이 ‘조용한 침식’을 막을 수 있을까요? 핵심은 감지(Detection) $\rightarrow$ 알림(Alert) $\rightarrow$ 강제 동기화(Enforcement)의 파이프라인을 구축하는 것입니다.

가장 대표적인 방법은 상태 파일(State File)을 이용하는 거예요. Terraform 같은 도구는 tfstate 파일을 통해 인프라 상태를 추적하며, 실제 리소스와 이 파일이 어긋나면 바로 드리프트로 간주합니다 [6]. AWS CloudFormation을 쓴다면 detect-stack-drift 명령어를 통해 템플릿과 실제 리소스를 비교할 수 있습니다 [6].

여기서 한 단계 더 나아가면, 코드 외의 변경사항을 자동으로 리셋하는 ‘강제 동기화’ 전략을 쓸 수 있습니다 [5]. 아래는 Terraform을 이용해 드리프트를 감지하고 해결하는 기본적인 워크플로우 예시입니다.

# 예시: 간단한 S3 버킷 설정
# 이 코드가 '진실의 원천'이 됩니다.
resource "aws_s3_bucket" "app_storage" {
  bucket = "my-company-app-storage"
  
  tags = {
    Environment = "Production"
    ManagedBy   = "Terraform" # 누가 관리하는지 명시하여 수동 수정 방지 유도
  }
}

# [드리프트 해결 프로세스]
# 1. terraform plan: 실제 상태와 코드를 비교하여 차이점(Drift)을 찾아냅니다.
# 2. 만약 누군가 콘솔에서 태그를 바꿨다면, plan 결과에 '수정 필요'라고 뜹니다.
# 3. terraform apply: 코드를 기준으로 실제 리소스를 다시 덮어써서 동기화합니다.

이 설정의 핵심은 ManagedBy 같은 태그를 붙여 “이건 코드로 관리되는 리소스이니 건드리지 마세요”라고 명시하는 것과, 정기적으로 terraform plan을 실행해 차이점을 찾아내는 자동화 파이프라인을 돌리는 것입니다. Ansible의 경우 에이전트리스 아키텍처를 통해 시스템 상태를 주기적으로 체크하고 원래 설정으로 되돌리는 방식을 사용할 수 있습니다 [4].

짚고 넘어갈 한계와 현실적인 타협점

물론 모든 상황에 ‘코드 강제화’가 정답은 아닙니다. 현실적인 제약들이 있거든요.

우선, 정말 급박한 장애 상황에서 모든 것을 CI/CD 파이프라인을 통해 수정하는 건 너무 느릴 수 있습니다. 가용성이 최우선인 상황에서는 수동 수정이 불가피할 때가 있죠 [2]. 이럴 때는 ‘수동 수정 $\rightarrow$ 즉시 코드 반영’이라는 엄격한 사후 프로세스가 반드시 작동해야 합니다.

또한, 모든 리소스를 IaC로 관리하는 게 항상 효율적인 건 아닙니다. 오버헤드가 너무 크거나, 값이 계속 변하는 동적 리소스의 경우 드리프트 감지 대상에서 제외하는 유연함이 필요합니다 [6].

핵심 요약

• 설정 드리프트는 ‘작은 수동 변경’이 쌓여 발생하는 인프라의 침식 과정입니다.
• 수동 수정은 당장은 빠르지만, 결국 보안 구멍과 시스템 불안정이라는 부메랑으로 돌아옵니다.
• IaC 도입이 끝이 아닙니다. ‘지속적인 감지’ 프로세스가 없으면 코드는 그냥 문서에 불과합니다.
• Terraform 상태 파일, AWS Config, Ansible 등을 활용해 실제 상태와 코드의 간극을 실시간으로 모니터링하세요.
• 가장 좋은 방법은 모든 변경을 코드로 수행하고, 코드 외 변경을 허용하지 않는 팀 문화를 만드는 것입니다.

처음에는 모든 것을 코드로 관리하고, 작은 수정 하나에도 PR을 올리는 과정이 정말 번거롭게 느껴지실 거예요. 하지만 제가 겪어보니, 어느 날 새벽 3시에 원인 모를 장애로 깨어났을 때 나를 구해줄 유일한 생명줄은 “내 코드가 곧 실제 서버 상태다”라는 확신뿐이더라고요. 결국 원칙을 지키는 것이 가장 빠른 길입니다.

---

참고 자료 (References)

1. [zanishdigital.medium.com] Detecting Configuration Drift: Early Warning Signs Every Beginner Should Know — https://zanishdigital.medium.com/detecting-configuration-drift-early-warning-signs-every-beginner-should-know-eb8b27bebd46?source=rss——artificial_intelligence-5 2. [statetechmagazine.com] What Is Configuration Drift, and How Can Governments Manage It? — https://statetechmagazine.com/article/2026/04/what-configuration-drift-and-how-can-governments-manage-it-perfcon 3. [spacelift.io] What is Configuration Drift? Tools, Causes & Risks — https://spacelift.io/blog/what-is-configuration-drift 4. [josys.com] Automating Configuration Drift Detection: Tools and Techniques for IT Managers — https://www.josys.com/article/article-saas-security-automating-configuration-drift-detection-tools-and-techniques-for-it-managers 5. [reddit.com] Drift Detection Tools : r/devops — https://www.reddit.com/r/devops/comments/1i3a66u/drift_detection_tools 6. [env0.com] Drift Detection in IaC: Stop Infra Breaks — https://www.env0.com/blog/drift-detection-in-iac-prevent-your-infrastructure-from-breaking 7. [sabbat.pro] Declarative Infrastructure Auditing: Actionable Strategies to Prevent Configuration Drift — https://www.sabbat.pro/posts/declarative-infrastructure-auditing-actionable-strategies-to-prevent-configuration-drift

관련 글 추천

• https://infobuza.com/2026/06/17/20260617-myjrgm/
• https://infobuza.com/2026/06/17/20260617-ko935l/

FAQ

설정 드리프트(Configuration Drift)란 무엇인가요?

승인되고 기록된 기준점(코드)과 실제 서버의 상태가 시간이 흐르면서 조금씩 어긋나는 현상을 말합니다.

왜 IaC를 도입했음에도 수동 수정의 유혹에 빠지게 되나요?

긴급 장애 대응 시 CI/CD 파이프라인을 기다릴 여유가 없어 콘솔에서 빠르게 수정하는 경우가 많으며, 코드 작성보다 콘솔 클릭이 더 편리하거나 관리 체계가 부재한 경우에 발생합니다.

설정 드리프트를 방치했을 때 어떤 위험이 있나요?

시스템 동작을 예측할 수 없게 되어 스테이징과 운영 환경의 결과가 달라질 수 있고, 보안 그룹 포트 방치 등으로 인한 보안 및 컴플라이언스 문제가 발생하며, 장애 시 코드가 실제 상태를 반영하지 못해 복구 시간(MTTR)이 급격히 늘어납니다.

설정 드리프트를 해결하기 위한 기술적 전략은 무엇인가요?

감지, 알림, 강제 동기화 파이프라인을 구축하는 것입니다. Terraform의 상태 파일(tfstate)이나 AWS CloudFormation의 `detect-stack-drift` 명령어를 통해 차이점을 찾아내고, `terraform apply` 등을 통해 코드를 기준으로 실제 리소스를 다시 덮어써 동기화할 수 있습니다.

모든 상황에서 코드 강제화가 정답인가요?

아닙니다. 가용성이 최우선인 매우 급박한 장애 상황에서는 수동 수정이 불가피할 수 있으며, 오버헤드가 너무 크거나 값이 계속 변하는 동적 리소스의 경우 드리프트 감지 대상에서 제외하는 유연함이 필요합니다.