Terraform 도입 이유
Naver Cloud Platform(NCP)을 사용하면서 여러 SI 프로젝트를 진행해왔다.
처음에는 클라우드 콘솔에서 직접 인프라를 생성하고 운영하는 방식으로 작업했다.
프로젝트 수가 많지 않았을 때는 크게 불편하지 않았고, 빠르게 환경을 만들 수 있어서 오히려 편하다고 느꼈다.
하지만 프로젝트가 점점 늘어나면서 같은 작업을 계속 반복하고 있다는 느낌이 들기 시작했다.
반복되는 인프라 작업
프로젝트를 새로 시작할 때마다 비슷한 작업을 계속 반복해야 했다.
- VPC 생성
- Subnet 생성
- 서버 생성
- DB 생성
- Bastion 설정
작업 자체가 어렵지는 않았지만, 프로젝트가 늘어날수록 같은 작업을 계속 반복하는 것이 점점 부담이 됐다.
비슷하지만 항상 조금씩 다른 인프라
또 하나 불편했던 점은 프로젝트마다 인프라 구성이 조금씩 달랐다는 점이었다.
- 어떤 프로젝트는 NAT Gateway가 있었고
- 어떤 프로젝트는 없었고
- Subnet 구성도 조금씩 달랐고
- 서버 구성도 프로젝트마다 조금씩 달랐다
처음에는 큰 문제라고 생각하지 않았지만, 프로젝트가 많아질수록 관리가 점점 어려워졌다.
환경을 다시 만들어야 할 때 느꼈던 한계
가장 크게 한계를 느꼈던 순간은 기존 환경을 다시 만들어야 하는 상황이었을 때였다.
이론적으로는 같은 구성을 다시 만들 수 있어야 했다. 하지만 실제로는 설정을 다시 확인하고, 하나씩 다시 만들어야 했다.
이 과정을 반복하다 보니 자연스럽게 이런 고민이 들기 시작했다.
“이걸 좀 더 편하게 만들 수는 없을까?”
그리고 그 고민은 결국 이런 생각으로 이어졌다.
“이걸 코드로 관리해야 하지 않을까?”
그래서 Terraform을 도입하게 되었다
Terraform을 선택한 이유는 단순했다.
- 반복 작업을 줄이고 싶었고
- 같은 환경을 다시 만들 수 있어야 했고
- 인프라 구성을 코드로 관리하고 싶었다
물론 Terraform 말고도 Ansible, Pulumi 같은 다양한 도구가 있었지만, 현재 환경에서는 Terraform이 가장 현실적으로 적용하기 쉬운 선택이었다.
처음부터 큰 구조를 만들려고 하지는 않았고 간단하게 만들려고 생각했다.
- 기존 프로젝트 구조는 최대한 유지
- 신규 인프라는 Terraform 기반으로 생성
- 반복되는 인프라 작업부터 코드화
앞으로 정리해볼 내용
- 프로젝트가 늘어나면서 어떤 문제가 생겼는지
- 공통 리소스를 관리해야겠다고 느꼈던 시점
- Terraform / Terragrunt 구조를 잡으면서 겪었던 시행착오