이름만 들어도 좋은회사에서 취직할것같은 기술
테라폼
과연 테라폼이 무엇일까?
1. IaC(Infrastructure as Code)
테라폼은 대표적인 IaC 도구이다.
IaC란 마우스 클릭으로 일일이 만드는게 아니라, 코드를 작성하여 자동으로 생성하고 관리하는 도구를 말한다.
테라폼은 사실상 이 IaC분야의 표준으로 자리를 잡았는데,
이는 단순히 테라폼이 먼저 나왔기 때문이 아니라, 클라우드 생태계 전반의 현실적인 요구를 충족했기 때문이다.
Aws의 CloudFormation,
Google Cloud Deployment Manager,
Azure Resource Manager 등
각각 클라우드 서비스만의 고유한 전용 IaC들이 있지만
유독 테라폼이 각광받고 사랑받는 이유가 무엇일까?
1.1 멀티 클라우드 지원
Aws, Google Cloud Platform, Azure 전용 IaC들이 나왔음에도
테라폼은 위 메이저 클라우드들을 모두 커버할뿐만 아니라,
테라폼은
깃헙, 쿠버네티스, 카프카, Datadog, Cloudflare 등 수백 개의 외부 시스템을
한 언어(HCL)로 관리할 수 있다.
이런식으로 설계된것을 벤더 중립적으로 설계되었다고 하는데,
테라폼의 이런 선택은 시장의 요구와 정확하게 맞아 떨어졌다.
1.2 HCL 문법의 낮은 러닝커브
테라폼의 DSL(HCL)은 아래와 같은 특징들을 가지는데,
1. JSON / YAML보다 읽고 쓰기 쉬운 구조
2. 리소스 간 의존성을 자동으로 추적
3. 변수, 모듈, 로컬 변수 구조가 매우 직관적
4. 개발자, 인프라 엔지니어 모두 쉽게 접근 가능
이러한 특장점들 때문에,
팀 규모가 커지더라도 유지보수성이 높다.
특히 Pulumi라는 IaC와 비교했을때,
Pulumi는 프로그래밍 언어로 작성하지만,
그만큼 복잡성이 증가하기 때문에, 조직 전체의 표준으로 삼기엔 다소 무거울 수 있다.
1.3 압도적인 프로바이더의 생태계
테라폼의 핵심이라고도 할 수 있는 Provider 시스템은
IaC의 본질을 꿰뚫고 있다.
IaC는 위에서도 언급했듯 클라우드 리소스를 코드로 수정, 생성 삭제 하는 도구인데,
우리네 클라우드는 지속적으로 새로운 리소스를 출시한다.
ex)
- Aws에서 새로운 타입의 Lambda 기능 출시
- Cloudflare가 새로운 CDN 옵션 추가
- Github에서 새로운 API기능 오픈
이렇듯 새로운 리소스들이 마구 생겨날때, IaC도구가 이 기능을 빠르게 지원하지 않으면,
코드 기반 관리의 IaC의 목적이 무너진다.
즉 리소스 지원 속도 = IaC의 핵심이라고도 할 수 있는데,
테라폼은 주요 클라우드에서 발표하는 서비스가 빠르게 지원되기 때문에 큰 강점이 있고, 더 널리 사용되게 되었다.
ex)
1. AWS -> 새 서비스 출시
2. AWS Provider 팀 -> Provider 업데이트
3. 테라폼 레지스트리 -> 업데이트 반영
4. 사용자 -> 즉시 infra.tf 코드에서 사용 가능
2. 테라폼 사용 요령
코드로 인프라 세팅이나 설정을 관리한다는건 대충 알겠다.
그렇다면 어떤식으로 작성하고 이용하는것일까?
천천히 알아보자.
우리가 도커파일이나 도커컴포즈를 아키텍처 패키지에 포함시킬 필요 없듯이,
테라폼 코드의 위치도 굳이 백엔드 코드안에 둘 필요 없다.
project-root/
├── backend/ # Spring Boot 소스
│ └── src/...
├── frontend/ # React 소스
│ └── src/...
└── infra/ # 여기에 Terraform 코드 작성
├── main.tf # 핵심 리소스 정의 파일
├── variables.tf # 변수 정의
├── outputs.tf # 출력값 정의
├── provider.tf # AWS 같은 provider 설정
└── terraform.tfstate # 실제 인프라 상태 저장 파일
(*간단한 테라폼 인프라 패키지를 포함한 프로젝트 세팅)
조금만 더 자세히 살펴보자.
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}
위 코드는 Aws의 EC2인스턴스를 실행시키는 main.tf 코드이다.
t2.micro나 익숙한 용어들이 보이기 때문에 대충 무슨뜻인지는 알겠으나,
어떻게 저 코드로 EC2 인스턴스를 띄운다는걸까?
테라폼 코드는 우리에게 익숙한 명령형 방식이 아니라 선언형 방식을 사용하는데 중점적으로 살펴봐야한다.
즉 위 코드는 "EC2 인스턴스가 있어야 한다"라는 목표 상태를 표현한것이다.
따라서 위 테라폼 파일을 작성하고,
실제 실행을 위해서는 실행 명령어를 CLI로 때려줘야한다.
*명령어 순서
# 최초 1회
terraform init # Provider 다운로드 및 초기화
# 이후 작업 시마다
terraform plan # 변경 사항 미리보기
terraform apply # 실제 인프라 생성/변경
+
terraform destroy # 생성한 모든 리소스 삭제
*실 작업 순서
1. terraform apply 실행
↓
2. Terraform이 main.tf 파싱
↓
3. Provider 설정 확인 (AWS 자격증명, 리전 등)
↓
4. AWS Provider가 Terraform 코드(HCL)를
AWS API 호출로 변환
↓
5. AWS SDK를 통해 실제 EC2 생성 요청
↓
6. AWS에서 EC2 생성 완료
↓
7. Terraform이 생성된 리소스 ID, 속성 등을
terraform.tfstate에 저장
그리고 실제로 주로 이용되는 워크플로우는 아래와 같다.

*init은 최초 1회 또는 Provider 변경 시
** plan은 필수
결론:
메이저 클라우드 플랫폼을 사용하며 계정을 여러가지 사용하여 반복적인 인프라 구성 작업을 하거나,
중요한 인프라설정인 경우
테라폼을 이용하여 코드로 관리하게된다면 큰 이점들이 많다.
다음번에 테라폼을 실제로 사용하는 내용들을 작성해보도록 하겠다.
'공부 > 인프라' 카테고리의 다른 글
| 네트워크 기본 (쉬운 도커3) (0) | 2025.08.12 |
|---|---|
| ModSecurity 도입기 2(Trouble Shooting) (2) | 2025.08.06 |
| ModSecurity 도입기 (5) | 2025.08.02 |
| 백지에서 따라가며 배우는 젠킨스 & EC2 (4) (0) | 2024.01.14 |
| 백지에서 따라가며 배우는 젠킨스 & EC2 (3) (0) | 2024.01.14 |