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