[Terraform 운영] Day 1: State와 소유권 - 실제 인프라를 잇는 장부
이 글은 AI(Claude)의 도움을 받아 작성하고, 작성자가 검토·편집했습니다.
서론: 오늘의 문제
Terraform state는 캐시 파일이 아니라 선언한 주소와 실제 자원을 연결하는 운영 장부다. 저장 위치, 잠금, 접근 권한과 복구 절차를 먼저 설계해야 협업이 안전해진다.
1. State가 저장하는 것
state는 리소스 주소와 원격 객체 식별자를 연결하고 의존성 계산에 필요한 메타데이터를 보관한다. 실제 인프라를 다시 조회할 수 있다는 이유로 state를 임의 삭제하면 안 된다.
2. 원격 Backend
팀 환경에서는 잠금과 버전 관리, 암호화를 지원하는 원격 저장소를 사용한다. 실행 주체마다 다른 로컬 state를 갖게 두면 같은 자원을 중복 생성하거나 서로 덮어쓸 수 있다.
3. State 경계
모든 인프라를 하나의 state에 넣으면 작은 변경도 넓은 잠금과 권한을 요구한다. 변경 주기, 장애 영향, 소유 팀을 기준으로 경계를 나누고 필요한 값만 output으로 연결한다.
4. 민감 정보
provider가 반환한 값이 state에 평문 형태로 포함될 수 있음을 전제로 한다. 저장소 암호화, 최소 권한, 감사 로그와 보존 기간을 비밀 관리 정책에 포함한다.
5. 백업과 복구
버전이 있는 backend를 사용하고 state pull 결과를 안전하게 보관하는 절차를 마련한다. 복구는 마지막 파일을 되돌리는 일뿐 아니라 실제 자원과의 차이를 plan으로 재검증하는 과정이다.
6. 자주 실패하는 방식
state를 Git에 커밋하거나 여러 사람이 잠금 없이 apply하면 비밀 노출과 lost update가 발생할 수 있다. state 경계를 계정 전체로 크게 잡으면 한 팀의 작업이 모든 팀을 막는다.
7. 관측과 검증
잠금 대기 시간, state 크기와 리소스 수, 실패한 apply, 수동 state 명령 실행, backend 접근 거부와 버전 복원 이력을 추적한다. 기준값은 정상 시간대와 변경 전후를 비교해 정하고, 점검 결과가 실제 행동으로 이어지는지 정기적으로 확인한다.
실행 흐름
1
2
3
4
5
6
7
8
9
1. State가 저장하는 것
↓
2. 원격 Backend
↓
3. State 경계
↓
4. 민감 정보
↓
5. 백업과 복구
개별 도구보다 이 순서를 팀의 설계 리뷰와 Runbook에 남기는 것이 중요하다. 상황이 달라져도 판단 근거와 검증 결과가 이어져야 한다.
실전 체크리스트
- State가 저장하는 것: 기준과 책임자를 문서화했다.
- 원격 Backend: 기준과 책임자를 문서화했다.
- State 경계: 기준과 책임자를 문서화했다.
- 민감 정보: 기준과 책임자를 문서화했다.
- 백업과 복구: 기준과 책임자를 문서화했다.
- 실패 패턴을 재현하고 안전한 복구 경로를 확인했다.
- 핵심 신호를 대시보드와 변경 검증에 연결했다.
참고 자료
다음 글
다음 글에서는 Module 설계 - 복사 대신 안정된 계약 만들기를 다룬다.