# 장점
1.
운영 자동화
인프라 셋업 시간 단축 가능
# 새 게임 출시마다 동일 인프라 자동 생성 가능
terraform apply -var="game=lostark-season2"
HCL
복사
2.
버전 관리
문제 발생 시 롤백 가능 : git checkout <commit id> → terraform apply
git log infrastructure/
# "2024-01-15: VM 크기 B2s → B4ms (트래픽 증가)"
# "2024-02-01: 리전 추가 (일본 서버)"
HCL
복사
3.
트래킹 용이
•
변경 전, terraform plan을 통해 검증 가능
•
누가 콘솔에서 몰래 수정했는지도 확인 가능
4.
환경 일관성
# dev, staging, prod 모두 동일한 모듈 사용
# → 환경 차이로 인한 버그 원천 차단
module "server" {
source = "./modules"
}
HCL
복사
5.
협업 용이
PR 리뷰로 인프라 변경 검증 가능
# 단점
1.
학습 비용
•
HCL 문법, 각 Cloud Provider 문법(Azure, AWS 등)을 학습해야함
•
인프라 기본 개념 + 상세한 네트워크, 보안 지식 필요
2.
잘못된 설정으로 인한 버그
이건 양날의 검에 가깝다. 오히려 콘솔에서 잘못 클릭해놓고 즉시 반영하면 더 위험할 수도 있다.
테라폼은 잘못 작성한 경우 terraform plan 을 통해 확인 가능하니 더 안전하다고 할 수 있다.
결국 트레이드오프 문제에 가깝다. 그럼에도 많은 기업이 도입하는 이유는 다음과 같다고 생각한다 :
1.
클라우드 보편화 → 인프라가 API화
과거라면 서버실에서 물리 케이블을 꽂아야했겠지만, 현재는 API 호출로 VM을 생성하는 시대가 되었다. 코드화가 가능해졌으니 IaC가 더 장점이 된 게 아닐까?
2.
컨테이너 + 마이크로서비스화 → 리소스수 폭증
모놀리식일 경우 3대의 서버면 충분했다면, MSA의 경우 “서비스 개수 x 컨테이너 x 리전 개수”이므로 관리 대상이 수 백개가 된다. 이는 수동으로 관리가 불가능함을 의미하고, 곧 자동화가 필요해진 게 아닐까?
3.
사람으로부터 발생하는 리스크 최소화
1,2번에 의해 다양해지고 방대해진 리소스들이 과연 여러 사람이 모인다고 관리가 가능해질까 싶다면 아니라고 생각한다. 그렇게 생각해본다면, 코드로 관리해 인적 리스크를 최소화하는 것도 좋지 않을까?