누군가 콘솔에서 고쳤다

한 줄 요약

드리프트는 코드가 선언한 상태와 실제 상태가 벌어진 것입니다.
IaC 를 도입한 조직이 실제로 씨름하는 문제의 대부분이 여기 있습니다.

왜 이게 필요했나

금요일 밤에 장애가 났습니다. 누군가 콘솔에 들어가 보안 그룹에 규칙을
하나 추가해 급한 불을 껐습니다. 옳은 판단이었습니다.

문제는 월요일입니다. 다른 사람이 관계없는 변경을 하려고 plan 을 돌리자,
금요일에 추가한 그 규칙을 지우겠다고 나옵니다. 코드에는 그 규칙이
없으니까요. 모르고 apply 하면 장애가 재발합니다.

이게 드리프트입니다. 그리고 이건 도구의 결함이 아니라 당연한 동작
입니다. 선언형 도구는 코드를 진실로 삼고 실제를 거기 맞춥니다.

드리프트가 생기는 경로

| 경로 | 예 | 대응 |
| --- | --- | --- |
| 긴급 수동 변경 | 장애 대응 중 콘솔 조작 | 사후 코드 반영을 절차에 넣기 |
| 다른 팀의 변경 | 보안팀이 정책을 조정 | 소유권 경계를 명확히 |
| 자동 스케일링 | 인스턴스 수가 계속 변함 | ignore_changes 로 제외 |
| 클라우드 기본값 | 생성 시 자동 부여되는 태그 | 코드에 반영하거나 무시 |
| 다른 코드베이스 | 두 저장소가 같은 리소스를 관리 | 절대 금지 — 소유자는 하나 |

마지막 항목이 가장 위험합니다. 두 개의 상태 파일이 같은 리소스를 관리하면
서로를 계속 되돌립니다. 리소스마다 소유자는 반드시 하나여야 합니다.

감지 — plan 은 진단 도구다

plan 은 배포 직전에만 돌리는 게 아닙니다. 주기적으로 돌려
드리프트를 감지하는 것이 좋은 운영입니다.

# 아무 변경도 안 했는데 plan 에 diff 가 있다 = 드리프트plan → 변경 없음  ✅ 코드와 실제가 일치plan → 변경 있음  ⚠️ 조사 필요

CI 에서 매일 plan 을 돌려 결과가 비어 있지 않으면 알림을 보냅니다.
이렇게 하면 금요일의 변경을 월요일이 아니라 토요일 아침에 압니다.

해소 — 세 가지 선택지

드리프트를 발견했을 때 답은 셋 중 하나입니다.

1. 코드로 흡수한다 — 그 변경이 옳았다면 코드에 반영합니다.
가장 흔하고 대개 옳은 선택입니다.

2. 되돌린다 — 그 변경이 잘못됐다면 apply 로 코드 상태를 강제합니다.
단, 왜 그런 변경이 있었는지 먼저 확인해야 합니다.

3. 관리 대상에서 뺀다 — 오토스케일링처럼 원래 변하는 값이면
ignore_changes 로 그 속성만 제외합니다. 리소스 전체를 빼는 게 아니라
속성 단위로 좁히는 게 요령입니다.

임포트 — 이미 있는 것을 코드 안으로

IaC 도입은 보통 백지에서 시작하지 않습니다. 이미 손으로 만들어 둔 자원이
수백 개 있고, 그걸 코드로 옮겨야 합니다.

여기서 절대 하면 안 되는 것: 지우고 다시 만들기. 운영 중인 자원이면
다운타임이고, 데이터가 있으면 유실입니다.

대신 임포트를 씁니다. 실제 자원을 상태 파일에 등록해, 도구가 "이건
내가 관리하는 것" 으로 인식하게 만듭니다.

1. 자원의 실제 설정을 조사한다2. 그와 똑같은 코드를 작성한다3. import 로 상태에 등록한다4. plan 을 돌려 '변경 없음' 이 나올 때까지 코드를 다듬는다

4번이 핵심입니다. plan 이 비어야 임포트가 끝난 것입니다. diff 가 남아
있는 채로 넘어가면 다음 apply 때 그 자원이 바뀝니다.

상태 파일을 다룰 때

상태 파일은 자원의 실제 ID·속성·의존 관계를 담고 있습니다. 자격증명이
평문으로 들어가는 경우도 있습니다.

• 원격 백엔드에 두고 잠금을 켭니다. 두 사람이 동시에 apply 하면

상태가 깨집니다.

• 버전 관리를 켭니다. 잘못된 apply 를 되돌릴 유일한 수단입니다.
• git 에 커밋하지 않습니다. 비밀이 들어갈 수 있습니다.
• 손으로 편집하지 않습니다. 꼭 필요하면 도구가 제공하는 상태 명령을 씁니다.

현장에서 만나는 모습

• 신규 입사자가 처음 apply 했다가 남의 수동 변경을 지움 → plan 을 안 읽었다.
• 오토스케일링 그룹 크기가 매번 diff 로 나옴 → ignore_changes 가 없다.
• 상태 파일이 로컬에 있어 두 사람이 서로 덮어씀 → 원격 백엔드와 잠금 부재.

다음 이론에서 볼 것

이어지는 읽기에서는 드리프트 대응을 여러 환경에 복제할 때 모듈 경계를 어디에
두어야 하는지 살펴봅니다. 흡수·되돌림·제외 중 어떤 결정을 공통 모듈에 넣고 어떤
결정을 호출 환경에 남겨야 변경 폭발 반경을 줄이는지 연결해 보세요.