2025년 7월 21일·7분
Terraform과 Vagrant: 인프라와 배포를 잇는 다리
Mitchell Hashimoto의 HashiCorp 도구인 Terraform과 Vagrant가 팀이 인프라를 표준화하고 반복 가능한 배포 워크플로를 만드는 데 어떻게 도움이 되는지 알아보세요.
Mitchell Hashimoto의 HashiCorp 도구인 Terraform과 Vagrant가 팀이 인프라를 표준화하고 반복 가능한 배포 워크플로를 만드는 데 어떻게 도움이 되는지 알아보세요.
반복 가능한 배포는 단지 코드를 배포하는 것만이 아닙니다. 확신을 가지고 대답할 수 있어야 합니다: 무엇이 바뀌는가? 왜 바뀌는가? 그리고 내일도 같은 방식으로 할 수 있는가? 인프라를 수작업으로 만들거나 개발자 머신이 시간에 따라 달라지면 배포는 추측 게임이 됩니다: 환경이 제각각, 결과는 달라지고, "내 노트북에서는 동작한다"는 말이 많아집니다.
Terraform과 Vagrant가 여전히 의미 있는 이유는 불확실성을 두 방향에서 줄여주기 때문입니다: 공유 인프라와 공유 개발 환경.
Terraform은 인프라(클라우드 리소스, 네트워킹, 관리형 서비스, 때로는 SaaS 설정까지)를 코드로 기술합니다. 콘솔을 이곳저곳 클릭하는 대신 원하는 것을 정의하고, 플랜을 검토한 뒤 일관되게 변경을 적용합니다.
목표는 "멋져 보이는 것"이 아닙니다. 인프라 변경을 가시화하고, 검토 가능하게 하며, 반복 가능하게 만드는 것입니다.
Vagrant는 일관된 개발 환경을 만들어 줍니다. macOS, Windows, Linux 어디에서나 동일한 기본 설정(OS, 패키지, 설정)을 실행하도록 도와줍니다.
매일 VM을 사용하지 않더라도 Vagrant의 핵심 아이디어는 여전히 중요합니다: 개발자는 소프트웨어가 실제로 실행되는 방식과 일치하는 알려진 정상 상태에서 시작해야 합니다.
이 글은 유행어보다 명확함이 필요한 비전문가를 위한 실용적 안내서입니다. 다룰 내용:
끝까지 읽으면 Terraform, Vagrant 또는 두 도구가 팀에 적합한지, 그리고 복잡성의 새로운 층을 만들지 않고 어떻게 도입할지 평가할 수 있을 것입니다.
Mitchell Hashimoto는 Vagrant를 만들고 HashiCorp를 공동 창업한 사람으로 잘 알려져 있습니다. 지속적인 기여는 단일 제품이 아니라 도구가 팀의 워크플로를 공유 가능하고, 검토 가능하며, 반복 가능한 형태로 부호화할 수 있다는 아이디어입니다.
사람들이 "도구는 다리다"라고 말할 때, 같은 결과를 원하지만 일상 언어가 다른 두 그룹 사이의 간극을 메우는 것을 의미합니다:
Hashimoto의 관점은 HashiCorp 도구 전반에 반영되어 있습니다: 다리는 모두가 볼 수 있는 워크플로입니다. 티켓이나 부족한 지식을 통해 지시를 전달하는 대신, 팀은 구성 파일에 결정을 캡처하고 버전 관리를 통해 체크인하며 동일한 명령을 동일한 순서로 실행합니다.
도구는 심판자가 됩니다: 단계를 표준화하고, 무엇이 변경되었는지 기록하며, "내 로컬에서 되는데" 논쟁을 줄여줍니다.
공유 워크플로는 인프라와 환경을 제품과 같은 인터페이스로 바꿉니다:
이런 프레이밍은 배포에 초점을 맞추게 합니다: 도구는 단순한 자동화가 아니라 합의를 만들기 위한 것입니다. Terraform과 Vagrant는 의도된 상태를 명시적으로 만들고 버전 관리, 검토, 반복 실행 같은 관행을 장려하기 때문에 이 사고방식에 잘 맞습니다.
대부분의 배포 고통은 "나쁜 코드"에서 오는 것이 아닙니다. 환경 불일치와 아무도 완전히 기술할 수 없는 보이지 않는 수작업 단계가 원인입니다—문제가 발생할 때까지는요.
팀은 종종 동작하는 설정으로 시작한 뒤 작은 합리적 변경을 합니다: 여기 패키지 업그레이드, 저기 방화벽 설정 변경, 서버에서의 일회성 핫픽스. 몇 주가 지나면 개발자 노트북, 스테이징 VM, 프로덕션이 조금씩 달라집니다.
그 차이는 재현하기 어려운 실패로 나타납니다: 로컬에선 테스트가 통과하지만 CI에서는 실패; 스테이징은 동작하지만 프로덕션은 500 에러; 롤백해도 이전 동작을 복원하지 못함—기저 시스템이 변경되었기 때문입니다.
환경이 수작업으로 만들어지면 실제 프로세스는 부족한 지식에 머뭅니다: 어떤 OS 패키지를 설치할지, 어떤 서비스를 시작할지, 어떤 커널 설정을 조정할지, 어떤 포트를 열지—그리고 어떤 순서로 할지.
신입은 "충분히 비슷한" 머신을 만드는 데 며칠을 잃습니다. 시니어 엔지니어는 기본 설정 질문에 대한 병목이 됩니다.
실패 원인은 종종 평범합니다:
.env에 복사하지만 프로덕션에서는 다른 방식으로 가져옴—배포가 실패하거나, 더 나쁘게는 비밀이 유출됩니다.이 문제들은 온보딩 지연, 리드타임 증가, 예기치 못한 서지, 고통스러운 롤백으로 이어집니다. 팀은 더 적게, 덜 자신 있게 배포하고, 환경 차이를 진단하는 데 더 많은 시간을 쓰게 됩니다.
Terraform은 인프라를 코드로(IaC) 만드는 도구입니다: 클라우드 콘솔을 여기저기 클릭하고 모든 설정을 기억하려고 애쓰는 대신, 파일에 인프라를 기술합니다.
그 파일들은 일반적으로 Git에 보관되어 변경이 가시화되고, 검토 가능하며, 반복 가능합니다.
Terraform 구성은 인프라에 대한 "빌드 레시피"처럼 생각하세요: 네트워크, 데이터베이스, 로드밸런서, DNS 레코드, 권한 등. 당신은 사후에 무엇을 했는지를 문서화하는 것이 아니라, 무엇이 존재해야 하는지를 정의합니다.
그 정의는 명시적이기 때문에 중요합니다. 동료가 동일한 환경이 필요하면 같은 구성을 사용할 수 있습니다. 사고 후 환경을 재구축해야 할 때도 같은 소스에서 복원할 수 있습니다.
Terraform은 원하는 상태를 선언하는 것에서 출발합니다: 원하는 것을 선언하면 Terraform이 그 상태에 도달하기 위해 어떤 변경이 필요한지 계산합니다.
일반적인 루프:
이 "미리보기 후 적용" 방식은 코드 리뷰, 승인, 예측 가능한 롤아웃을 가능하게 해 팀에서 Terraform이 빛을 발하는 지점입니다.
"IaC는 완전 자동화다." 꼭 그런 것은 아닙니다. 특히 프로덕션 변경에는 인간의 체크포인트를 두는 것이 좋습니다. IaC는 사람을 제거하는 것이 아니라 반복 가능성과 명확성을 제공하는 것입니다.
"한 도구가 모든 문제를 해결한다." Terraform은 프로비저닝과 인프라 변경에 탁월하지만 좋은 아키텍처, 모니터링, 운영 규율을 대체하진 않습니다. 모든 리소스를 동일하게 잘 다루는 것도 아니므로 더 넓은 워크플로의 일부로 사용하는 것이 좋습니다.
Vagrant의 역할은 단순합니다: 모든 개발자에게 단일 구성 파일에서 즉시 동일한 작업 환경을 제공하는 것.
중심에는 Vagrantfile이 있으며 여기서 기본 이미지(박스), CPU/RAM, 네트워킹, 공유 폴더, 머신이 어떻게 구성될지 기술합니다.
코드이기 때문에 환경은 검토 가능하고 버전 관리되며 공유하기 쉽습니다. 새 팀원은 리포를 클론하고 한 명령을 실행하면 올바른 OS 버전, 패키지, 서비스, 기본값이 포함된 예측 가능한 환경을 얻습니다.
컨테이너는 앱과 그 종속성을 패키징하는 데 훌륭하지만 호스트 커널을 공유합니다. 그래서 네트워킹, 파일시스템 동작, 백그라운드 서비스, OS 수준 도구에서 차이를 여전히 경험할 수 있습니다—특히 프로덕션이 컨테이너 런타임보다 전체 리눅스 VM에 더 가깝다면 더욱 그렇습니다.
Vagrant는 일반적으로 VirtualBox, VMware, Hyper-V 같은 프로바이더를 통해 가상 머신을 사용합니다. VM은 자체 커널과 init 시스템을 가진 실제 컴퓨터처럼 동작합니다. 시스템 서비스, 커널 설정, iptables 규칙, 다중 NIC 네트워킹, "Ubuntu 22.04에서만 깨지는 문제" 같은 사례를 테스트할 때 VM이 더 적합합니다.
이건 경쟁이 아닙니다: 많은 팀이 앱 패키징에는 컨테이너를, 현실적인 전체 시스템 개발·테스트에는 Vagrant를 사용합니다.
요약하면 Vagrant는 "가상화 자체를 위한 가상화"가 아니라 개발 환경을 팀 전체가 신뢰할 수 있는 공유 워크플로로 만드는 데 더 가깝습니다.
Terraform과 Vagrant는 다른 문제를 해결하지만 함께 사용하면 "내 환경에서 되던 것이 모두에게 안정적으로 실행되는 상태"로 가는 명확한 경로를 만듭니다. 그 다리는 동등성(parity)입니다: 앱의 가정은 동일하게 유지하면서 대상 환경만 바뀝니다.
Vagrant는 현관문입니다. 각 개발자에게 동일한 로컬 환경을 제공합니다—같은 OS, 같은 패키지, 같은 서비스 버전—그래서 앱은 알려진 기준선에서 시작합니다.
Terraform은 공유된 기반입니다. 네트워크, 데이터베이스, 컴퓨트, DNS, 접근 규칙 같은 팀이 함께 의존하는 인프라를 정의합니다. 그 정의는 테스트와 프로덕션의 진실의 원천이 됩니다.
연결은 단순합니다: Vagrant는 현실을 닮은 환경에서 앱을 빌드하고 검증하도록 도우며, Terraform은 현실(테스트/프로덕션)을 일관되고 검토 가능한 방식으로 프로비저닝하고 변경되게 합니다.
모든 대상에 같은 도구를 쓰는 것이 아니라 같은 계약을 씁니다.
DATABASE_URL, REDIS_URL 같은 환경 변수를 기대합니다.Vagrant는 로컬에서 그 계약을 강제합니다. Terraform은 공유 환경에서 그것을 강제합니다. 앱은 그대로 유지되고 단지 "어디서" 실행되는지가 바뀝니다.
노트북(Vagrant): 개발자가 vagrant up을 실행하면 앱 런타임과 Postgres, Redis가 포함된 VM을 얻습니다. 빠르게 반복하며 로컬에서의 문제를 조기에 잡습니다.
테스트(Terraform): PR이 Terraform을 업데이트하여 테스트 데이터베이스와 앱 인스턴스를 프로비저닝합니다. 팀은 실제 인프라 제약과 맞춰 동작을 검증합니다.
프로덕션(Terraform): 동일한 Terraform 패턴을 프로덕션 설정(더 큰 용량, 엄격한 접근, 고가용성)으로 적용합니다. 설정을 재발명하지 않고 적용할 수 있습니다.
이것이 다리입니다: 반복 가능한 로컬 동등성이 반복 가능한 공유 인프라로 이어져 배포가 각 단계에서 재발명되지 않고 통제된 진행이 됩니다.
견고한 Terraform/Vagrant 워크플로는 명령 외우기가 아니라 변경을 검토하고 반복하고 롤백하기 쉽게 만드는 것입니다.
목표: 개발자가 로컬에서 시작해 앱 변경과 함께 인프라 변경을 제안하고, 최소한의 놀라움으로 환경을 통해 그 변경을 승격(promote)할 수 있게 하는 것.
많은 팀은 애플리케이션과 인프라를 같은 리포에 두어 배포 스토리를 일관되게 유지합니다:
/app — 애플리케이션 코드, 테스트, 빌드 자산/infra/modules — 재사용 가능한 Terraform 모듈(네트워크, DB, 앱 서비스)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — 얇은 환경 레이어/vagrant — Vagrantfile 및 프로비저닝 스크립트로 ‘실제’ 의존성을 모방중요한 패턴은 "얇은 env, 두꺼운 모듈": 환경은 주로 입력(크기, 카운트, DNS 이름)을 선택하고, 공통 모듈이 실제 리소스 정의를 보관합니다.
단순한 trunk 기반 접근이 잘 맞습니다: 짧게 유지되는 기능 브랜치, 풀 리퀘스트로 병합.
리뷰에서 요구할 두 가지 아티팩트:
terraform fmt, validate를 실행하고 PR용 terraform plan 출력을 생성리뷰어는 로컬에서 다시 생성하지 않고도 "무엇이 바뀌는가?"와 "안전한가?"에 답할 수 있어야 합니다.
동일한 모듈 세트를 dev → test → prod로 승격하되, 차이는 명시적이고 작게 유지하세요:
환경별로 디렉터리를 복사하는 것을 피하세요. 리소스 정의를 다시 쓰지 말고 변수를 변경해 승격하세요.
앱 변경이 새로운 인프라를 요구하면(예: 큐 추가), 앱과 인프라를 같은 PR로 배포하여 하나의 단위로 검토하세요.
인프라가 여러 서비스에 공유된다면 모듈을 제품처럼 취급하세요: 버전(태그/릴리스)을 만들고 입력/출력을 계약으로 문서화하여 팀이 의도적으로 업그레이드하도록 합니다.
Terraform의 실력은 단순히 인프라를 생성하는 것이 아니라 시간에 걸쳐 안전하게 변경할 수 있다는 점입니다. 이를 위해 Terraform은 자신이 만든 것과 존재한다고 "생각하는 것"을 기억해야 합니다.
Terraform 상태는 구성과 실제 리소스를 매핑하는 파일(또는 저장 데이터)입니다: 어떤 DB 인스턴스가 어떤 aws_db_instance에 대응하는지, ID가 무엇인지, 마지막으로 적용된 설정은 무엇인지 등.
상태가 없으면 Terraform은 모든 것을 다시 스캔하며 어떤 것이 존재하는지 추측해야 합니다. 이는 느리고, 신뢰할 수 없으며 때로는 불가능합니다. 상태가 있으면 Terraform은 안전한 계획을 계산할 수 있습니다: 무엇이 추가/변경/파괴될지.
상태에는 리소스 식별자나 가끔은 노출하고 싶지 않은 값이 포함될 수 있으므로 자격 증명처럼 취급해야 합니다. 누군가 상태를 읽거나 수정할 수 있다면 Terraform이 무엇을 변경할지 영향을 줄 수 있습니다.
드리프트는 콘솔 수동 편집, 새벽 2시의 핫픽스, 자동화된 프로세스 등이 원인입니다.
드리프트는 이후의 플랜을 놀랍게 만들 수 있습니다: Terraform이 수동 변경을 "되돌리려" 하거나 가정이 맞지 않아 실패할 수 있습니다.
팀은 보통 상태를 원격에 저장하여 모두가 동일한 진실의 원천을 기준으로 플랜하고 적용합니다. 좋은 원격 설정은 또한 다음을 지원합니다:
안전한 배포는 대부분 지루합니다: 하나의 상태, 통제된 접근, 플랜을 거친 변경.
Terraform은 동일한 블록을 복사하는 대신 공통 패턴을 모듈로 패키징할 때 진정한 힘을 발휘합니다.
모듈은 입력(예: VPC CIDR 범위, 인스턴스 크기)을 받고 출력(서브넷 ID, DB 엔드포인트 등)을 생성하는 재사용 가능한 Terraform 코드 번들입니다. 보상은 중복 감소, 스노우플레이크 설정 감소, 팀이 알려진 정상 상태 빌딩 블록에서 시작해 더 빠르게 배포할 수 있다는 점입니다.
모듈이 없으면 인프라 코드는 복사/붙여넣기로 변질됩니다: 어떤 리포는 보안 그룹 규칙을 수정하고, 다른 리포는 암호화 설정을 잊고, 또 다른 리포는 다른 프로바이더 버전을 고정합니다.
모듈은 결정을 인코딩하고 시간이 지남에 따라 개선할 수 있는 단일 장소를 만듭니다. 리뷰도 쉬워집니다: 네트워크 200줄을 매번 재심사하는 대신 작은 모듈 인터페이스(입력/출력)를 리뷰하고 모듈 자체가 진화할 때만 재심사하면 됩니다.
좋은 모듈은 솔루션의 형태를 표준화하되 의미 있는 차이는 허용합니다.
모듈화할 가치가 있는 패턴 예시:
모든 옵션을 담으려 하지 마세요. 모듈에 입력이 40개나 된다면 아마도 지나치게 많은 용도를 담으려는 것입니다. 합리적 기본값과 적은 수의 정책 결정을 선호하고, 탈출구는 드물고 명시적으로 만드세요.
누군가 조금씩 다른 버전을 게시하면(“vpc-basic”, “vpc-basic2”, “vpc-new”) 모듈은 미로가 됩니다. 확산은 보통 소유자가 불명확하거나 버전 관리 규율이 없을 때, 언제 새 모듈을 만들지 혹은 기존 모듈을 개선할지에 대한 지침이 없을 때 발생합니다.
실용적 가드레일:
잘 하면 모듈은 Terraform을 공유 워크플로로 바꿉니다: 팀은 "올바른 방법"을 패키지화된 형태로 찾아 빠르게 시작할 수 있습니다.
Terraform과 Vagrant는 환경을 재현 가능하게 만들지만 실수도 동일하게 재현합니다. 리포에 유포된 토큰 한 개가 노트북, CI 작업, 프로덕션 변경에 퍼질 수 있습니다.
몇 가지 간단한 습관이 대부분의 일반적인 실패를 막습니다.
"무엇을 만들 것인가"(구성)와 "어떻게 인증할 것인가"(비밀)를 분리하세요.
인프라 정의, Vagrantfile, 모듈 입력은 리소스와 설정을 설명해야지 비밀번호나 API 키, 개인 인증서를 담아서는 안 됩니다. 대신 검증된 시크릿 스토어(전용 볼트 서비스, 클라우드 시크릿 매니저, 혹은 엄격히 통제된 CI 시크릿 스토어)에서 런타임에 가져오세요. 이렇게 하면 코드 리뷰가 가능하고 민감한 값의 감사도 쉬워집니다.
각 행위자에게 필요한 권한만 부여하세요:
terraform plan을 실행할 수 있는 개발자가 자동으로 프로덕션을 적용할 권한을 가질 필요는 없습니다. 승인과 실행을 분리해 책임을 명확히 하세요.공유 키는 책임 추적을 지웁니다.
이 가드레일은 배포를 늦추지 않습니다—문제가 생겼을 때 영향 범위를 줄입니다.
CI/CD는 Terraform이 "한 사람이 실행하는 도구"에서 팀 워크플로로 바뀌는 지점입니다: 모든 변경이 보이고, 검토되고, 항상 같은 방식으로 적용됩니다.
실용적인 기본선은 세 단계이며 PR과 배포 승인에 연결됩니다:
terraform fmt -check와 terraform validate를 실행해 명백한 실수를 초기에 잡습니다.terraform plan을 생성하고 출력을 PR에 게시합니다(아티팩트 또는 코멘트). 리뷰어는 "무엇이 바뀌는가? 어디에서? 왜?"에 답할 수 있어야 합니다.terraform apply를 실행합니다.# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
핵심은 분리입니다: PR은 증거(플랜)를 만들고, 승인은 변경을 승인(적용)합니다.
Vagrant는 CI를 대체하지 않지만 로컬 테스트를 CI 수준으로 느끼게 만들 수 있습니다. "내 로컬에서 된다"는 버그 리포트가 나오면 공유 Vagrantfile을 통해 누구나 동일한 OS, 패키지, 서비스 버전으로 부트해 재현할 수 있습니다.
특히 유용한 상황:
팀이 배포 워크플로를 표준화하려 할 때 Terraform과 Vagrant 같은 도구는 일관된 애플리케이션 스캐폴딩과 반복 가능한 릴리스 단계와 짝을 이룰 때 더 잘 작동합니다.
Koder.ai는 바이브 코딩 플랫폼으로서 챗에서 작동하는 웹/백엔드/모바일의 작동 가능한 베이스라인을 생성하고 소스 코드를 내보내어 위에서 설명한 Git 기반 워크플로(모듈, CI 플랜/적용 게이트 포함)에 바로 연결할 수 있게 도와줄 수 있습니다. Terraform이나 Vagrant를 대체하는 것이 아니라 초기 커밋까지의 시간을 줄이면서 인프라와 환경 관행을 명시적이고 검토 가능하게 유지하는 방법입니다.
자동화가 우발적 자동화가 되지 않게 하려면:
이 가드레일을 통해 Terraform과 Vagrant는 "설명하고 반복할 수 있으며 신뢰할 수 있는" 변경을 지원합니다.
훌륭한 도구도 "한번 설정하면 끝"으로 취급되면 새로운 문제가 생길 수 있습니다. Terraform과 Vagrant는 범위를 분명히 하고 몇 가지 가드레일을 적용하며 모든 세부를 모델링하려는 충동을 억제할 때 가장 잘 작동합니다.
장기적 드리프트: 콘솔에서 "이번 한 번만" 변경한 인프라가 Terraform과 조용히 달라질 수 있습니다. 몇 달 후 다음 apply는 위험해집니다.
과도하게 복잡한 모듈: 모듈은 재사용에 훌륭하지만 수십 개의 변수와 중첩된 모듈, 한 사람만 이해하는 "마법" 기본값으로 느려질 수 있습니다.
느린 로컬 VM: Vagrant 박스가 시간이 지날수록 무거워질 수 있습니다(큰 이미지, 많은 서비스, 느린 프로비저닝). 개발자가 VM을 건너뛰면 "반복 가능한 환경"이 옵션이 되고, 결국 프로덕션에서 문제가 생깁니다.
Vagrant 유지: 전체 OS 수준의 동작(시스템 서비스, 커널 차이)이 필요하고 팀이 알려진 정상 상태 기준선에서 이득을 본다면 유지하세요.
컨테이너로 이동: 앱이 도커에서 잘 동작하고 더 빠른 시작을 원하며 전체 VM 경계가 필요 없을 때 고려하세요.
둘 다 사용: 호스트를 에뮬레이트하는 VM이 필요하지만 앱은 VM 내부에서 컨테이너로 실행하고 싶다면 속도와 현실성의 균형을 맞출 수 있습니다.
추천 링크: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform은 인프라 변경을 명확하게, 검토 가능하게, 반복 가능하게 만듭니다. 콘솔 클릭이나 런북에 의존하는 대신 구성 파일을 버전 관리에 커밋하고 terraform plan으로 영향 범위를 미리 확인한 뒤, 일관되게 변경을 적용합니다.
여러 사람이 공동으로 관리하는 인프라를 시간이 지나도 안전하게 변경해야 할 때 가장 큰 가치를 발휘합니다.
Vagrant는 모든 개발자에게 단일 Vagrantfile로 정의된 알려진 정상 상태의 OS 수준 환경을 제공합니다. 이는 온보딩 시간을 줄이고 “내 로컬에서는 되는데”라는 드리프트를 줄이며 OS 패키지, 서비스, 네트워킹에 기인한 버그를 재현하는 데 도움을 줍니다.
프로덕션 가정이 컨테이너가 아니라 VM에 더 가깝다면 특히 유용합니다.
Vagrant는 로컬 환경(OS, 서비스, 기본값)을 표준화하고, Terraform은 네트워크, DB, 컴퓨트, DNS, 권한 같은 공유 환경을 표준화합니다.
연결 아이디어는 포트, DATABASE_URL 같은 환경 변수, 서비스 가용성처럼 고정된 “계약”입니다. 이 계약은 노트북 → 테스트 → 프로덕션으로 이동해도 유지됩니다.
재사용 가능한 빌딩 블록과 환경별 설정을 분리하는 구조로 시작하세요:
/infra/modules에 보관/infra/envs/dev, /infra/envs/prod 등)/vagrant에 보관이렇게 하면 환경 간 승격은 대부분 으로 이루어지며 복사/붙여넣기 재작성은 피할 수 있습니다.
Terraform 상태(state)는 구성과 실세계 리소스를 연결짓는 기억장치입니다. Terraform은 어떤 aws_db_instance가 어떤 데이터베이스 인스턴스와 연결되는지, 리소스 ID가 무엇인지 등을 상태를 통해 추적합니다.
상태는 자격 증명처럼 민감할 수 있으므로:
드리프트는 인프라가 Terraform 외부에서 변경될 때 발생합니다(콘솔 수동 편집, 긴급 핫픽스, 자동화된 프로세스 등).
드리프트는 이후의 plan을 예측 불가능하게 만들며 Terraform이 수동 변경을 되돌리려고 하거나 실패하게 할 수 있습니다.
드리프트를 줄이는 실천 방안:
plan을 실행하기모듈은 공통 패턴(네트워킹, 데이터베이스, 서비스 배포 등)을 표준화하여 코드 중복을 줄이고 ‘스노우플레이크’를 방지합니다. 좋은 모듈의 특징:
피해야 할 점: 입력 변수가 40개나 되는 과도하게 복잡한 모듈. 이는 생산성을 떨어뜨립니다.
모듈 확산을 막는 실용적 규칙:
구성(configuration)과 비밀(secrets)을 분리하세요.
Vagrantfile에 비밀번호, API 키, 개인 인증서를 커밋하지 마세요plan과 apply 권한을 분리하고, 프로덕션 권한은 더 엄격하게 관리하세요또한 상태 파일에는 민감한 식별자가 포함될 수 있으니 접근을 제한하세요.
확인 가능하고 검토 가능한 변경을 만들려면 CI 파이프라인을 활용하세요. 권장 최소 파이프라인:
terraform fmt -check 및 terraform validateterraform plan 생성 및 PR에 출력 게시(아티팩트 또는 코멘트)terraform apply 실행이 분리는 증거(플랜)와 권한(승인)을 분리해 변경을 감사 가능하게 합니다.
Vagrant를 유지할지, 컨테이너로 전환할지, 둘 다 쓸지는 다음을 기준으로 결정하세요:
많은 팀이 앱 패키징은 컨테이너로, 호스트 수준의 현실성은 Vagrant로 해결합니다.