안녕하세요, 외주 개발사 에그코드입니다.
서버 한 대를 띄우려면 클라우드 콘솔에서 클릭을 몇 번이나 해야 할까요.
VPC를 만들고, 서브넷을 나누고, 보안 그룹을 열고, 그 위에 인스턴스를 올립니다.
한 번은 할 만합니다.
문제는 두 달 뒤에 생깁니다.
똑같은 환경을 하나 더 만들어 달라는 요청이 오면, 그때 무엇을 어떤 순서로 눌렀는지 정확히 기억하는 사람이 아무도 없습니다.
이 불편을 풀려고 쓰는 도구가 테라폼(Terraform)입니다.
오늘은 테라폼이 무엇인지, 왜 쓰는지, 그리고 실무에서 함께 쓰는 관리툴은 무엇인지 정리해 보겠습니다.
무엇을 하는 도구인가
테라폼은 HashiCorp가 만든 IaC(Infrastructure as Code) 도구입니다.
이름 그대로, 인프라를 코드로 정의하는 도구입니다.
서버와 네트워크와 데이터베이스처럼 그동안 손으로 만들던 자원을 설정 파일에 적어 두면, 테라폼이 대신 만들어 줍니다.
핵심은 선언형이라는 점입니다.
"이걸 만들고, 그다음 저걸 만들어라"처럼 순서를 지시하지 않습니다.
대신 최종 상태가 이래야 한다만 적습니다.
순서는 도구가 알아서 정합니다.
자원끼리 서로를 참조하는 관계를 읽어 의존성 그래프를 만들고, 무엇을 먼저 만들어야 하는지 스스로 판단합니다.
실제 작업은 Write → Plan → Apply 세 단계로 흐릅니다.
plan은 실행 계획을 미리 보여 주는 단계입니다.
무엇이 새로 생기고, 무엇이 바뀌고, 무엇이 지워질지를 목록으로 뽑아 줍니다.
이때 자기가 저장해 둔 기록만 믿지 않는다는 점이 중요합니다.
실제 클라우드 API를 조회해 현재 상태를 확인한 뒤, 그것과 코드를 비교합니다.
apply는 그렇게 만들어진 계획을 실제 인프라에 반영하는 단계입니다.
다만 -auto-approve 옵션을 붙이면 사람이 확인하는 단계 없이 곧바로 실행됩니다. CI/CD 파이프라인에서는 흔히 쓰는 방식입니다.
장점 4가지
1. 여러 클라우드를 같은 방식으로 다룹니다
provider라는 플러그인이 각 서비스의 API를 대신 호출합니다.
AWS와 Azure와 GCP는 물론, 쿠버네티스나 깃허브 같은 서비스도 같은 문법으로 다룰 수 있습니다.
레지스트리에 등록된 provider는 6,877개입니다.
다만 이 숫자를 그대로 믿으면 안 됩니다. HashiCorp가 직접 관리하는 official은 34개, 검증된 파트너가 관리하는 partner는 393개입니다. 나머지는 누구나 등록할 수 있는 커뮤니티 등급이라 품질과 유지보수 편차가 큽니다.
다만 오해하기 쉬운 부분이 있습니다.
코드까지 클라우드 사이를 옮겨 다니지는 않습니다. AWS용으로 쓴 자원 정의를 GCP가 그대로 알아듣지는 못합니다.
"하나의 도구로 여러 클라우드를 다룬다"는 뜻이지, "한 번 써 두면 아무 데나 배포된다"는 뜻은 아닙니다.
옮겨 다니는 건 코드가 아니라 일하는 방식입니다.
2. 인프라를 코드 리뷰할 수 있습니다
설정 파일이 Git에 들어갑니다.
방화벽을 한 줄 여는 일도 PR로 남고, 누가 언제 무엇을 바꿨는지가 기록됩니다.
3. 같은 환경을 그대로 복제합니다
개발·스테이징·운영 환경을 같은 코드로 찍어냅니다.
"개발에서는 됐는데 운영에서는 안 되는" 문제의 상당부가 여기서 줄어듭니다.
4. 무엇이 바뀔지 미리 봅니다
plan 없이 콘솔을 만지는 건, 결과를 모르는 채로 저장 버튼을 누르는 것과 같습니다.
실행하기 전에 무엇이 바뀔지 먼저 보여 준다는 것, 이게 생각보다 큰 차이를 만듭니다.
관리툴 7종
테라폼 하나만으로 팀 단위 운영을 감당하기는 어렵습니다.
상태 파일은 어디에 둘지, apply는 누가 실행할지, 비용은 얼마나 나올지 같은 문제가 곧바로 따라오기 때문입니다.
그래서 주변에 도구 생태계가 붙습니다.
| 도구 | 하는 일 |
|---|---|
| HCP Terraform | HashiCorp 공식 SaaS. 원격 실행, 상태 보관, 정책 검사 |
| OpenTofu | 오픈소스 포크. 상태 파일 암호화를 자체 지원 |
| Terragrunt | 환경마다 반복되는 설정을 제거하고 여러 모듈을 함께 배포 |
| Atlantis | PR에 댓글로 plan과 apply를 실행 |
| TFLint | 존재하지 않는 인스턴스 타입 같은 설정 오류를 검출 |
| Checkov | 보안 오설정을 스캔. 내장 정책이 1,000개가 넘습니다 |
| Infracost | 배포하기 전에 예상 비용을 계산해 PR에 표시 |
TFLint와 Checkov는 비슷해 보이지만 보는 곳이 다릅니다.
TFLint는 코드가 잘못 쓰였는지를 보고, Checkov는 보안상 위험한 설정인지를 봅니다.
지금 tfsec을 쓰고 계신다면 확인이 필요합니다. 공식 저장소가 Trivy로 옮겨 갈 것을 안내하고 있고, 마지막 릴리스는 2025년 5월에 멈춰 있습니다.
진짜 위험은 상태 파일입니다
코드와 실제 자원을 연결해 주는 건 state(상태 파일)입니다.
코드에 적힌 서버가 실제로는 어떤 ID를 가진 자원인지, 그 대응 관계를 이 파일이 기억합니다.
선택 기능이 아닙니다. 이 파일이 없으면 테라폼은 아예 동작하지 않습니다.
그리고 여기에 함정이 있습니다.
상태 파일은 평문으로 저장됩니다. 설정에 넣은 데이터베이스 비밀번호가 파일 안에 그대로 들어갑니다.
그래서 HashiCorp 공식 문서도 두 가지를 분명하게 경고합니다.
상태 파일을 Git에 올리지 말 것. 잠금과 접근 제어가 없는 저장소를 쓰면 데이터 손실이나 시크릿 노출로 이어질 것.
기본값은 작업자 컴퓨터에 파일로 저장하는 방식입니다.
혼자 쓸 때는 편하지만, 팀 작업에는 맞지 않습니다.
그래서 잠금을 지원하는 원격 저장소를 씁니다. S3, GCS, Azure Blob, HCP Terraform 같은 곳입니다.
여기서 한 가지 더 주의할 점이 있습니다.
S3를 쓴다고 잠금이 자동으로 켜지지는 않습니다. use_lockfile 옵션의 기본값은 꺼짐입니다.
직접 켜 주지 않으면, 두 사람이 동시에 apply를 실행해도 아무것도 막아 주지 않습니다.
라이선스와 OpenTofu
2023년 8월, 테라폼의 라이선스가 오픈소스(MPL 2.0)에서 BUSL 1.1로 바뀌었습니다.
1.6.0 버전부터 적용됐고, 이때부터 테라폼은 엄밀히 말해 오픈소스가 아닙니다.
여기서 오해가 많이 생깁니다.
"이제 상업적으로 못 쓴다"는 말은 사실이 아닙니다. 회사가 자기 인프라를 만들려고 쓰는 것은 그대로 허용됩니다.
금지되는 건 테라폼을 경쟁 제품으로 만들어 파는 경우입니다.
이 변화에 반발해 갈라져 나온 것이 OpenTofu입니다.
Linux Foundation이 관리하는 오픈소스 포크이고, 기존 테라폼 코드 대부분이 수정 없이 그대로 동작합니다.
2025년 2월 IBM이 HashiCorp 인수를 마쳤지만, 라이선스는 지금도 그대로입니다.
정리하며
테라폼이 모든 상황의 정답은 아닙니다.
AWS만 쓴다면 CloudFormation이 더 간단할 수 있습니다.
익숙한 프로그래밍 언어로 인프라를 짜고 싶다면 Pulumi가 나은 선택이고, 이미 만들어진 서버의 내부를 설정하는 일은 Ansible의 영역입니다.
그래도 인프라를 사람의 기억이 아니라 코드로 남기고 싶다면, 테라폼은 여전히 가장 무난한 출발점입니다.
Stack Overflow의 2025년 개발자 설문에서도 응답자의 17.8%가 최근 1년 사이에 테라폼을 사용했다고 답했습니다.
저희 에그코드도 웹·SaaS·MVP를 만들면서 인프라를 이런 방식으로 관리하고 있습니다.
그리고 2026년 6월, HashiCorp는 Terraform MCP Server 1.0을 공개했습니다.
AI 에이전트가 인프라 코드를 직접 다루기 시작한 셈입니다.
함께 읽어보세요 — 무중단 배포로 서비스를 멈추지 않는 방법 · AI로 만든 서비스, 배포 현실은 · 에그코드 외주 개발 서비스