– 비용 발생 시점을 통제한 IaC 운영 전략
1. 들어가며: 비용을 ‘줄이는 것’보다 ‘통제하는 것’
척척학사는 학생들의 학사 정보 조회와 졸업 요건 분석을 돕는 서비스로,
별도의 수익 구조 없이 공모전 상금과 개인 비용으로 운영되고 있다.
이미 서버는 t3.micro 기반의 AWS Free Tier 인스턴스를 사용하고 있었기 때문에, 비용 문제의 핵심은 “서버 스펙을 더 줄이는 것”이 아니었다.
문제는 더 구조적인 지점에 있었다.
프리티어가 끝나는 순간,
인프라 비용이 ‘예측 불가능하게’ 발생한다는 점이었다.
그래서 목표를 이렇게 정의했다.
- 비용을 일시적으로 줄이는 것이 아니라
- 비용이 발생하는 시점을 운영 전략 차원에서 통제
- 이를 위해 AWS 계정이 바뀌어도 동일한 인프라를 즉시 재현할 수 있는 구조를 만드는 것
이 목표를 달성하기 위해 인프라를 Terraform(IaC)으로 전환했다.
2. 문제 분석: 돈이 어디서 새고 있었나?
Terraform 도입 이전,
AWS 비용 청구서를 기준으로 월 약 $127(약 17만 원)의 비용이 발생하고 있었다.
문제는 프리티어를 넘는 순간 비용이 쌓이기 시작하는 구조였다.
세부 원인은 다음과 같았다.
- 계정 단위 Free Tier 한계
- Free Tier는 계정 기준으로 적용되며,
만료 이후에는 동일한 구조에서도 비용이 즉시 발생
- Free Tier는 계정 기준으로 적용되며,
- 수동 인프라 관리의 한계
- 콘솔 기반 관리로 인해
인프라 전체 구조를 빠르게 이전하거나 재현하기 어려움
- 콘솔 기반 관리로 인해
- 비용 발생 시점에 대한 통제 불가
- 프리티어 종료 = 곧바로 고정 비용 발생
- ‘필요한 순간에만 비용을 감수한다’는 선택지가 없음
즉, 문제는 리소스 스펙이 아니라 인프라의 재현성과 이동성이었다.
3. 해결 전략: Terraform으로 ‘계정 간 인프라 재현성’ 확보
비용 최적화의 핵심 전략은 다음 한 줄로 정리할 수 있다.
AWS 계정이 바뀌어도 동일한 인프라를 몇 분 안에 다시 만들 수 있게 한다.
이를 위해 Terraform 도입 시 다음 원칙을 세웠다.
- 모든 인프라를 코드로 선언
- EC2, Security Group, 네트워크 설정 등
- 콘솔 수동 설정 제거
- Free Tier 스펙을 코드로 고정
t3.micro등 프리티어 지원 인스턴스만 허용- 실수로 고사양 인스턴스 생성 방지
- 계정 종속 요소 최소화
- 계정 A → 계정 B로 이전 시에도
동일한 인프라 구조를 그대로 재현 가능하도록 설계
- 계정 A → 계정 B로 이전 시에도
이제 인프라는 “계정에 종속된 자산”이 아니라
언제든 옮길 수 있는 코드 상태가 되었다.
4. Implementation: 계정 간 인프라 이전을 전제로 한 Terraform 구성
4-1. 인스턴스 타입을 변수로 고정
Terraform 변수로 인스턴스 타입을 제한하여,
프리티어 외 스펙이 생성되지 않도록 강제했다.
variable "instance_type" {
default = "t3.micro"
}이 설정 하나로,
계정이 바뀌어도 비용 구조는 항상 동일하게 유지된다.
4-2. EC2 및 네트워크 구성 코드화
기존에는 EC2 인스턴스, 보안 그룹, 네트워크 설정을
AWS 콘솔에서 직접 생성·관리하고 있었다.
이 방식의 가장 큰 문제는,
AWS 계정이 변경되면 동일한 인프라를 다시 구성하기가 매우 어렵다는 점이었다.
Terraform을 도입하면서,
기존에 수동으로 관리하던 리소스를 모두 코드로 명세했다.
- EC2 인스턴스 (
aws_instance) - Security Group (
aws_security_group) - 네트워크 및 접근 제어 설정
이제 인프라는 콘솔 설정이 아니라 코드 상태가 되었고,
계정 A에서 사용하던 인프라는
terraform apply명령 한 번으로 계정 B에서도 동일하게 재현 가능해졌다.
이 구조 덕분에,
AWS 계정이 바뀌어도 인프라 구조를 다시 설계할 필요 없이
동일한 환경을 수 분 내에 재구성할 수 있었다.
이로 인해 계정 이전이 ‘마이그레이션 작업’이 아니라 ‘재배포’ 수준의 작업이 되었다.
4-3. 네트워크 비용을 고려한 구조적 선택
Terraform 전환 과정에서, 단순히 기존 인프라를 코드로 옮기는 데 그치지 않고
초기 네트워크 아키텍처 선택 자체를 비용 관점에서 다시 점검했다.
척척학사는 외부 요청을 받아 처리하는 API 서버 중심의 서비스로, 서버가 외부와 통신해야 하는 구조였다.
이 경우 모든 서버를 Private Subnet에 두고 NAT Gateway를 통해 외부 통신을 구성하는 방식은 서비스 규모 대비 과도한 고정 비용을 유발할 수 있다고 판단했다.
이에 따라 인프라를 다음 원칙으로 설계했다.
- EC2 인스턴스를 Public Subnet에 배치
- Security Group을 통해 인바운드/아웃바운드 트래픽을 명시적으로 제한
- NAT Gateway와 같은 상시 과금 네트워크 리소스는 사용하지 않음
이 구조를 Terraform으로 명확히 코드화함으로써,
계정이 변경되더라도 동일한 비용 구조가 유지되도록 했고,
불필요한 네트워크 고정 비용이 발생하지 않는 인프라를 설계 단계에서부터 보장할 수 있었다.
5. 결과: 비용 ‘절감’이 아닌 비용 ‘통제’
Terraform 기반 IaC로 인프라를 전환한 이후,
AWS 비용 구조는 다음과 같이 변화했다.
크롤링 서버의 비용을 제외한
- 변경 전: 월 약 $127
- 변경 후: 월 약 $54
- 차이: 약 $73 절감
특히 서버 컴퓨팅 비용은,
- Free Tier 계정 내에서는 추가 비용 없이 운영 가능했고
- Free Tier 종료 시점에도
계정 이전을 통해 동일한 인프라를 즉시 재구성할 수 있었다.
즉, 비용이 발생하는 시점을
운영자가 선택할 수 있는 구조가 되었다.
6. 이 방식의 핵심 가치
이번 개선의 핵심은
- 인프라를 코드로 관리함으로써 계정 단위로 인프라를 이전할 수 있는 재현성 확보
- 비용이 발생하는 시점을 운영 전략 차원에서 통제
- 불필요한 리소스 생성과 예측 불가능한 과금 리스크 제거
Terraform 도입 이후, 인프라는 특정 AWS 계정에 종속된 자산이 아니라
언제든 재현과 이전 가능한 코드 상태의 자원이 되었다.
7. 마치며
Terraform을 도입한 이유는 단순히 새로운 도구를 사용해보기 위함이 아니었다.
한정된 비용 안에서 서비스를 지속하기 위한, 현실적인 운영 전략이었다.
이번 경험을 통해 분명해진 점은 다음과 같다.
- 비용 최적화는 숫자의 문제가 아니라 구조의 문제
- IaC는 편의성이 아니라 통제력
- 인프라가 코드가 되는 순간, 운영 선택지는 크게 늘어난다
