인프라를 코드로 관리하면서 가장 많이 놓치는 부분 중 하나가 바로 버전 지원 종료 시점(EOS/EOL)입니다. 저도 한때 운영 중이던 Terraform 버전이 지원 종료되어 급하게 업그레이드를 진행했던 경험이 있는데요, 그때의 아찔함이란… 오늘은 Terraform의 버전 지원 정책을 속속들이 살펴보면서, 어떻게 하면 안전하게 버전을 관리할 수 있을지 함께 알아보겠습니다.
1. Terraform, 정확히 무엇을 하는 도구일까?
Terraform은 HashiCorp에서 개발한 Infrastructure as Code(IaC) 플랫폼입니다. 쉽게 말해, 서버, 네트워크, 데이터베이스 같은 인프라 구성을 코드로 작성하고 관리할 수 있게 해주는 도구죠.
기존에는 AWS 콘솔이나 Azure 포털에 접속해서 클릭 몇 번으로 리소스를 만들었다면, Terraform은 이 모든 과정을 코드로 정의합니다. 코드로 작성하면 버전 관리가 가능하고, 팀원들과 협업도 쉬워지며, 같은 인프라를 여러 환경에 일관되게 배포할 수 있다는 큰 장점이 있습니다.
Terraform은 BUSL-1.1 라이선스 하에 배포되는 인프라 코드 소프트웨어 도구로, 선언적 설정 파일을 통해 API를 코드화할 수 있습니다. 2023년 8월 이전까지는 Mozilla Public License 2.0으로 제공되었으나, 현재는 Business Source License로 변경되었습니다.
2. HashiCorp의 버전 지원 철학 – 알고 있어야 하는 핵심 원칙
Terraform의 버전 지원 정책을 이해하려면 HashiCorp의 전체적인 지원 철학을 먼저 알아야 합니다.
HashiCorp는 모든 GA(Generally Available) 릴리즈에 대해 최대 2년간 지원을 제공합니다. 이게 무슨 의미냐면, 특정 버전이 정식 출시되면 그때부터 최대 2년 동안은 보안 패치나 중요 버그 수정을 받을 수 있다는 뜻입니다.
여기서 주의할 점이 있습니다. 코드 수정이나 핫픽스는 최신 major 릴리즈로부터 2개 릴리즈 이내에만 제공됩니다. 버전 표기법은 X.Y.Z 형식을 따르는데, 여기서 X나 Y가 변경되면 major 릴리즈로 간주합니다.
예를 들어, 현재 최신 버전이 1.13이라면:
- 1.13.x → 최신 버전 (Full Support)
- 1.12.x → 1개 이전 버전 (Support)
- 1.11.x → 2개 이전 버전 (Support)
- 1.10.x 이하 → 공식 지원 종료
제품 종료(End of Life) 시에는 최소 12개월 전에 사전 공지를 제공합니다. 이는 충분한 마이그레이션 준비 시간을 갖도록 하기 위함입니다.
3. 전체 Terraform 버전별 상세 릴리즈 및 지원 정보
2025년 10월 기준 Terraform의 모든 주요 버전에 대한 상세 정보를 정리했습니다.
3-1. Terraform 1.x 버전 (2021년 6월 ~ 현재)
Terraform 1.0은 2021년 6월에 GA(Generally Available) 상태를 달성하며, 워크플로우 유지 관리 자동화, 업그레이드 단순화, 상호 운용성 측면에서 주요 이정표를 세웠습니다.
| 버전 | 최신 패치 | 릴리즈 날짜 | 예상 EOL | 지원 상태 | 주요 특징 |
|---|---|---|---|---|---|
| 1.13 | 1.13.3 | 2025년 8월 | 2027년 8월 | ✅ Active | Stacks 명령어, 파일시스템 함수 검증 강화 |
| 1.12 | 1.12.2 | 2025년 5월 | 2027년 5월 | ✅ Active | Linux 커널 3.2+ 요구, 클라우드 통합 개선 |
| 1.11 | 1.11.4 | 2025년 1월 | 2027년 1월 | ✅ Active | 모듈 출력 민감도 개선 |
| 1.10 | 1.10.5 | 2024년 11월 | 2026년 11월 | ⚠️ Limited | 성능 최적화, 버그 수정 |
| 1.9 | 1.9.8 | 2024년 6월 | 2026년 6월 | ⚠️ Limited | Test 명령어 병렬 실행 지원 |
| 1.8 | 1.8.5 | 2024년 4월 | 2026년 4월 | ⚠️ Limited | Provider 함수 지원 |
| 1.7 | 1.7.5 | 2024년 1월 | 2026년 1월 | ⚠️ Limited | Config-driven import, remove 블록 |
| 1.6 | 1.6.6 | 2023년 10월 | 2025년 10월 | ⚠️ Limited | Test 명령어 GA, S3 state 잠금 개선 |
| 1.5 | 1.5.7 | 2023년 6월 | 2025년 6월 | ⚠️ Limited | Import 블록, Check 블록 추가 |
| 1.4 | 1.4.7 | 2023년 3월 | 2025년 3월 | ⚠️ Limited | Static evaluation 개선 |
| 1.3 | 1.3.10 | 2022년 9월 | 2024년 9월 | ❌ EOL | 선택적 속성, 함수 개선 |
| 1.2 | 1.2.9 | 2022년 5월 | 2024년 5월 | ❌ EOL | Precondition/Postcondition |
| 1.1 | 1.1.9 | 2021년 12월 | 2023년 12월 | ❌ EOL | 리팩토링 블록, moved 블록 |
| 1.0 | 1.0.11 | 2021년 6월 | 2023년 6월 | ❌ EOL | 첫 GA 버전, 호환성 약속 시작 |
참고: ✅ Active = 전체 지원, ⚠️ Limited = 제한적 지원 (보안 패치만), ❌ EOL = 지원 종료
3-2. Terraform 0.x 버전 (2014년 ~ 2021년)
0.x 버전들은 모두 공식 지원이 종료된 레거시 버전입니다.
| 버전 | 최종 패치 | 릴리즈 날짜 | EOL 상태 | 주요 특징 |
|---|---|---|---|---|
| 0.15.x | 0.15.5 | 2021년 4월 | ❌ EOL | 민감 변수 처리 개선, 콘솔 UTF-8 지원 |
| 0.14.x | 0.14.11 | 2020년 12월 | ❌ EOL | Lock 파일(.terraform.lock.hcl) 도입 |
| 0.13.x | 0.13.7 | 2020년 8월 | ❌ EOL | Provider 소스 주소 명시화, for_each 모듈 지원 |
| 0.12.x | 0.12.31 | 2019년 5월 | ❌ EOL | HCL2 구문 개선, for 표현식, 동적 블록 |
| 0.11.x | 0.11.15 | 2017년 11월 | ❌ EOL | Workspace 도입, 모듈 레지스트리 |
| 0.10.x | 0.10.8 | 2017년 8월 | ❌ EOL | Provider 분리 시작 |
| 0.9.x | 0.9.11 | 2017년 3월 | ❌ EOL | State 환경 개선 |
| 0.8.x | 0.8.8 | 2016년 12월 | ❌ EOL | Remote state 데이터 소스 |
| 0.7.x | 0.7.13 | 2016년 8월 | ❌ EOL | Provider 플러그인 아키텍처 |
| 0.6.x 이하 | – | 2016년 이전 | ❌ EOL | 초기 버전들 |
Oracle Cloud Infrastructure Resource Manager는 2025년 11월 1일부터 Terraform 1.5.x 이전 버전으로 스택을 생성하거나 작업을 실행할 수 없도록 변경할 예정입니다.
3-3. 버전별 중요 Breaking Changes 요약
| 업그레이드 경로 | 주요 변경사항 | 난이도 |
|---|---|---|
| 0.11 → 0.12 | HCL 구문 대폭 변경, first-class expressions | ⚠️⚠️⚠️ 높음 |
| 0.12 → 0.13 | Provider source 명시 필수, for_each 모듈 | ⚠️⚠️ 중간 |
| 0.13 → 0.14 | Lock 파일 도입, 민감 변수 처리 | ⚠️ 낮음 |
| 0.14 → 0.15 | Deprecated 기능 제거 | ⚠️ 낮음 |
| 0.15 → 1.0 | 안정성 강화, breaking change 거의 없음 | ✅ 매우 낮음 |
| 1.x → 1.y | 호환성 약속 유지, 점진적 기능 추가 | ✅ 매우 낮음 |
4. Terraform Enterprise의 특별한 지원 정책
Terraform Enterprise를 사용하시는 분들은 조금 다른 지원 정책을 확인해야 합니다.
Terraform Enterprise의 Replicated Native Scheduler 배포 방식은 2025년 3월이 마지막 릴리즈이며, 2027년 3월까지 지원됩니다. 이는 일반 Terraform OSS와는 다른 타임라인이므로, Enterprise 사용자라면 반드시 체크해야 할 사항입니다.
4-1. Terraform Enterprise 주요 일정
| 항목 (Item) | 날짜 (Date) | 비고 (Notes) |
|---|---|---|
| Replicated 마지막 릴리즈 (Final Replicated Release) | 2025년 3월 | FDO로 마이그레이션 권장 |
| Replicated 지원 종료 (Replicated EOS) | 2026년 4월 1일 | 이후 보안 패치 중단 |
| 권장 마이그레이션 완료 시점 (Recommended Migration) | 2024년 11월 이전 | 충분한 테스트 시간 확보 |
Enterprise 사용자는 Flexible Deployment Options (FDO)로의 마이그레이션을 검토해야 합니다. FDO는 Docker, Kubernetes, Podman, Nomad 등 다양한 배포 옵션을 제공합니다.
참고 자료: Terraform Enterprise 릴리즈 정보 | HashiCorp 지원 정책
5. 클라우드 제공업체별 Terraform 지원 현황
주요 클라우드 제공업체들도 각자의 Terraform 버전 지원 정책을 운영합니다.
5-1. 주요 클라우드 서비스별 최소 지원 버전
| 클라우드 서비스 | 최소 지원 버전 | 권장 버전 | 비고 |
|---|---|---|---|
| AWS (Terraform Cloud) | 1.5.x | 1.11.x 이상 | 최신 AWS 리소스는 1.9+ 권장 |
| Azure (Resource Manager) | 1.0.x | 1.10.x 이상 | AzureRM Provider 4.x는 1.9+ 필요 |
| GCP (Cloud Foundation) | 1.3.x | 1.11.x 이상 | GKE Autopilot은 1.6+ 권장 |
| Oracle Cloud Infrastructure | 1.5.x | 1.11.x 이상 | 2025년 11월 1일부터 1.5 미만 차단 |
| IBM Cloud Schematics | 0.13.x | 1.9.x 이상 | 레거시 0.x 지원 단계적 종료 |
6. 버전 업그레이드, 이렇게 준비하세요
버전 지원 종료가 다가오면 업그레이드를 고려해야 하는데, 이 과정이 생각보다 까다로울 수 있습니다. 몇 가지 실용적인 팁을 공유하겠습니다.
6-1. 현재 사용 버전 확인하기
먼저 현재 환경에서 어떤 버전을 사용하는지 확인해야 합니다:
terraform version
이 명령어를 실행하면 설치된 Terraform CLI 버전과 사용 중인 provider 버전들이 출력됩니다.
6-2. 단계별 업그레이드 전략
Terraform 업그레이드는 한 번에 여러 major 버전을 건너뛰기보다는 단계적으로 진행하는 것이 안전합니다:
- 테스트 환경 구축 – 운영 환경에 바로 적용하지 말고 개발 환경에서 먼저 테스트
- State 파일 백업 – 업그레이드 전 반드시 terraform state 파일을 백업
- Provider 버전 확인 – Terraform 버전과 provider 버전의 호환성 체크
- Plan 실행 및 검증 –
terraform plan명령으로 변경 사항이 없는지 확인 - 점진적 롤아웃 – 작은 단위로 나누어 업그레이드 진행
6-3. 버전 고정 (Version Pinning) 활용하기
terraform 블록에서 버전을 명시적으로 지정하면 팀 전체가 동일한 버전을 사용할 수 있습니다:
terraform {
required_version = ">= 1.11.0, < 1.14.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
이렇게 하면 의도치 않은 버전 업그레이드로 인한 문제를 예방할 수 있습니다.
6-4. CI/CD 파이프라인에서의 버전 관리
CI/CD 환경에서는 Docker 이미지나 버전 관리 도구(tfenv, asdf 등)를 활용해 일관된 Terraform 버전을 사용하는 것이 좋습니다:
# tfenv로 특정 버전 설치
tfenv install 1.13.3
tfenv use 1.13.3
7. 지원 종료 버전 사용 시 리스크
오래된 버전을 계속 사용하면 어떤 문제가 발생할 수 있을까요?
보안 취약점 노출 지원이 종료된 버전은 새로 발견되는 보안 취약점에 대한 패치를 받을 수 없습니다. 특히 인프라 관리 도구인만큼 보안은 매우 중요합니다.
신규 Provider 기능 사용 불가 클라우드 제공업체들이 새로운 서비스를 출시할 때, 이를 지원하는 provider는 최신 Terraform 버전을 요구하는 경우가 많습니다.
커뮤니티 지원 감소 Stack Overflow나 GitHub Issues에서 오래된 버전 관련 질문에 대한 답변을 얻기 어려워집니다.
마이그레이션 부담 증가 버전을 오래 방치할수록 나중에 업그레이드할 때 한 번에 해야 할 작업이 많아지고, Breaking Changes도 누적됩니다.
8. 자주 묻는 질문 (FAQ)
Q. Terraform 버전을 업그레이드하면 기존 인프라에 영향이 있나요? A. State 파일 형식은 하위 호환성을 유지하지만, 일부 provider나 문법 변경사항이 있을 수 있습니다. 반드시 terraform plan으로 먼저 확인하고 진행하세요.
Q. 1.0 미만 버전을 사용 중인데, 어떻게 업그레이드해야 하나요? A. 0.15 → 1.0 → 1.5 → 1.11 식으로 단계적으로 업그레이드하는 것을 권장합니다. 각 버전의 Upgrade Guide를 참고하세요.
Q. Terraform Cloud와 Terraform Enterprise의 버전 정책이 다른가요? A. 기본적으로 같은 정책을 따르지만, Enterprise의 Replicated 배포 방식은 별도의 EOL 일정이 있습니다.
Q. 지원되는 버전 목록은 어디서 확인할 수 있나요? A. endoflife.date/terraform에서 실시간으로 업데이트되는 정보를 확인할 수 있습니다.
Q. 현재 1.3이나 1.4 버전을 사용 중인데 언제까지 괜찮나요? A. 1.3과 1.4는 이미 2년 지원 기간이 지나 공식 EOL 상태입니다. 보안 패치를 받을 수 없으므로 최소 1.11 이상으로 업그레이드를 권장합니다.
Terraform의 버전 지원 정책은 단순해 보이지만, 실제 운영 환경에서는 provider 호환성, 클라우드 제공업체 지원, 팀 내 표준화 등 고려해야 할 요소가 많습니다.
핵심은 정기적인 모니터링과 계획적인 업그레이드입니다. 지원 종료 6개월 전부터 업그레이드 계획을 수립하고, 충분한 테스트를 거쳐 안전하게 진행하는 것이 최선의 방법입니다.
현재 사용 중인 Terraform 버전이 어떤 지원 상태인지 지금 바로 확인해보시기 바랍니다. 혹시 1.10 이하 버전을 사용 중이라면, 이번 기회에 1.11 이상으로 업그레이드를 고려해보는 것은 어떨까요?
관련 자료 링크: