https://youtu.be/57FJoXsbf2s?si=BODwcCcNgN-vDdnQ

헤일러의 Terraform으로 인프라 자동화하기

헤일러의 Terraform으로 인프라 자동화하기

Terraform으로 인프라 자동화하기: 왜 필요한가, 무엇이 좋은가

애플리케이션 코드는 Git으로 관리하면서도, 인프라는 여전히 콘솔에서 클릭으로 관리하는 경우가 많다. 초기에는 이 방식이 가장 빠르고 편해 보인다. AWS 콘솔에서 EC2를 만들고, VPC를 만들고, 보안 그룹을 설정하는 일은 익숙해지면 그리 어렵지 않다.

문제는 서비스가 조금만 커져도 시작된다. 환경이 Dev, Prod 두 개에서 끝나지 않고 Staging까지 늘어나고, 팀원이 늘어나고, 리소스가 많아질수록 “기억에 의존한 수동 관리”는 금방 한계에 부딪힌다.

이때 필요한 것이 바로 IaC(Infrastructure as Code) 이고, 그 대표 도구가 Terraform 이다. Terraform은 인프라를 코드로 정의하고, 그 코드대로 실제 리소스를 생성하고 관리하게 해준다. 결과적으로 인프라 운영의 일관성, 재현성, 협업 효율성을 크게 높일 수 있다.

인프라란 무엇인가

여기서 말하는 인프라는 IT 인프라다. 즉, 서비스를 제공하고 운영하기 위해 필요한 모든 기반 요소를 말한다.

대표적으로는 다음과 같은 것들이 포함된다.

하드웨어
소프트웨어
네트워크 같은 논리적 리소스

우리가 웹 서비스를 운영할 때 필요한 서버, 데이터베이스, 스토리지, 네트워크 설정, 로드밸런서 같은 것들이 모두 인프라에 해당한다.

인프라는 어떻게 관리되어 왔을까

예전에는 온프레미스 방식이 일반적이었다. 회사가 자체적으로 서버를 보유하고, 그 위에 애플리케이션 실행 환경까지 직접 구성하고 운영하는 방식이다.

온프레미스는 자유도가 높지만 단점도 분명하다.

초기 투자 비용이 크다
확장이 쉽지 않다
운영 부담이 크다

그래서 빠른 출시와 유연성이 중요한 스타트업이나 빠르게 실험해야 하는 서비스에서는 부담이 크다. 이런 배경에서 클라우드가 등장했고, 이제는 서버, 스토리지, 데이터베이스, 네트워크 같은 핵심 리소스를 클라우드 서비스로 제공받는 것이 일반적이 되었다.

하지만 클라우드가 있다고 해서 인프라 관리 문제가 완전히 사라지는 것은 아니다. 오히려 리소스를 쉽게 만들 수 있기 때문에, 시간이 지날수록 더 많은 리소스가 쌓이고 관리 복잡도는 커질 수 있다.

수동 인프라 관리가 왜 문제일까

작은 프로젝트에서는 AWS 콘솔 같은 웹 UI로도 충분히 인프라를 관리할 수 있다. Dev 환경 하나, Prod 환경 하나 정도는 손으로 만들어도 큰 무리가 없다.

하지만 다음과 같은 상황을 떠올려보면 문제가 분명해진다.

처음에는 Dev와 Prod 두 개 환경만 운영했다. 서비스가 성장하면서 Staging 환경이 필요해졌다. 기존 Prod 환경과 거의 동일하게 만들어야 하는데, 사용 중인 리소스가 너무 많다. 하나씩 다시 만들다 보니 시간이 이틀, 사흘씩 걸린다. 게다가 태그 이름 하나에 오타가 있거나, 보안 그룹 설정이 달라지거나, 서브넷 연결을 빠뜨리는 작은 실수도 쉽게 발생한다.

이게 바로 수동 관리의 본질적인 문제다. 영상과 자료에서도 이 점을 강조한다. 수동으로 인프라를 관리하면 다음 문제가 반복된다.

동일한 인프라를 재현하기 어렵다

처음 만들 때는 어떻게 했는지 기억나지만, 시간이 지나면 점점 잊어버린다. 문서가 있더라도 최신 상태가 아닐 수 있다. 결국 “대충 비슷하게” 다시 만들게 되고, 환경 간 차이가 발생한다.

반복 작업에 시간이 너무 많이 든다

VPC, 서브넷, 보안 그룹, EC2, RDS, 로드밸런서 등을 매번 클릭으로 만드는 것은 매우 비효율적이다. 특히 환경이 여러 개일수록 이 비용은 기하급수적으로 늘어난다.

휴먼 에러 가능성이 높다

수동 작업은 본질적으로 실수하기 쉽다. 이름 오타, CIDR 설정 오류, 태그 누락, 잘못된 리전 선택 같은 사소한 실수가 배포 실패나 장애로 이어질 수 있다.

즉, 클라우드 자체가 문제라기보다, 클라우드를 수동으로 관리하는 방식이 한계를 가진다.

IaC란 무엇인가

이 문제를 해결하기 위해 등장한 개념이 IaC(Infrastructure as Code) 이다.

말 그대로 인프라를 코드로 관리하는 방식이다. 코드를 작성하면 그 코드가 곧 인프라 정의가 되고, 실행하면 실제 인프라가 그 코드대로 만들어진다.

즉, “클릭해서 만들던 인프라”를 “코드로 선언해서 만들게” 바꾸는 것이다.

이 변화는 단순 자동화 이상이다. 애플리케이션 개발에서 코드가 갖는 장점을 인프라에도 그대로 가져오는 방식이라고 볼 수 있다.

IaC를 사용하면 무엇이 좋아질까

IaC의 가장 큰 장점은 재현성이다. 같은 코드를 실행하면 같은 인프라를 만들 수 있다.

이건 생각보다 굉장히 큰 가치다.

Dev 환경을 만들 때 쓰던 코드로 Staging 환경도 만들 수 있다
장애 복구를 위해 새 환경을 띄워야 해도 같은 코드로 재구성할 수 있다
팀원이 바뀌어도 환경 차이가 줄어든다

자료에서도 IaC의 장점으로 다음을 제시한다.

코드와 실제 리소스의 일치 보장

현재 인프라가 어떤 상태인지 코드 기준으로 확인할 수 있다. 즉, 운영 환경이 “누가 콘솔에서 어떻게 바꿨는지 모르는 상태”가 아니라 “코드로 추적 가능한 상태”가 된다.

형상 관리 가능

인프라 코드도 Git으로 관리할 수 있다. 누가 언제 어떤 리소스를 추가했고, 어떤 설정을 바꿨는지 변경 이력을 남길 수 있다.

코드 리뷰 가능

애플리케이션 코드처럼 인프라 코드도 Pull Request를 올리고 리뷰할 수 있다. 이건 단순 편의가 아니라, 운영 사고를 줄이는 중요한 장치다.

롤백과 복구가 쉬워진다

설정이 잘못되었으면 이전 커밋으로 되돌려 다시 적용할 수 있다. 수동으로 기억을 더듬으며 복구하는 것보다 훨씬 안전하다.

CI/CD와 통합 가능

애플리케이션 배포처럼 인프라 변경도 자동화 파이프라인에 넣을 수 있다. 즉, 인프라 변경도 사람이 콘솔에서 직접 작업하지 않고 승인된 코드 흐름 안에서 관리할 수 있다.

결국 IaC는 “편리함”보다 “운영 가능성”을 만들어주는 방식이다.

Terraform이란 무엇인가

IaC 도구는 여러 가지가 있지만, 그중 가장 대표적인 것이 Terraform이다.

Terraform은 사람이 읽기 쉬운 설정 파일로 인프라 리소스를 정의하는 IaC 도구다. HashiCorp가 만들었고, HCL(HashiCorp Configuration Language) 이라는 자체 언어를 사용한다.

Terraform 코드의 특징은 두 가지로 요약할 수 있다.

선언적이다

Terraform은 “어떻게 만들지”보다 “원하는 상태가 무엇인지”를 적는다.

예를 들어 VPC, 서브넷, 인스턴스를 만들 때 우리는 각 리소스의 관계만 선언하면 된다. Terraform은 그 참조 관계를 보고, VPC를 먼저 만들고 그다음 서브넷, 그다음 인스턴스를 생성하는 순서를 스스로 판단한다.

즉, 개발자가 일일이 생성 순서를 절차적으로 작성하지 않아도 된다.

읽기 쉽다

HCL은 block과 argument 중심 구조라 사람이 읽고 이해하기 쉽다. 그래서 코드 리뷰나 협업에도 유리하다.

Terraform이 특히 강한 이유

Terraform이 실무에서 많이 쓰이는 이유는 단순히 유명해서가 아니다. 몇 가지 실질적인 강점이 있다.

벤더 중립적이다

AWS만 다루는 것이 아니라, Azure, GCP 같은 클라우드도 지원한다. 뿐만 아니라 Cloudflare, Datadog 같은 서비스도 Provider를 통해 함께 관리할 수 있다.

즉, 예를 들어 컴퓨팅은 AWS EC2, CDN은 Cloudflare, 모니터링은 Datadog처럼 여러 서비스를 조합하는 구조도 Terraform 하나로 정의할 수 있다.

Provider가 매우 많다

벤더 중립적인 IaC 도구 중에서도 지원 범위가 넓은 편이다. 이 말은 Terraform을 도입했을 때 특정 클라우드 서비스에만 갇히지 않고, 다양한 외부 서비스와 함께 운영하기 좋다는 뜻이다.

커뮤니티가 활발하다

사용자가 많다는 것은 실무에서 매우 중요하다. 예제, 모듈, 트러블슈팅 자료가 풍부하고, 문제가 생겼을 때 참고할 수 있는 정보가 많다.

Terraform의 기본 워크플로우

Terraform의 흐름은 크게 세 단계로 볼 수 있다.

Write

먼저 인프라를 정의하는 코드를 작성한다.

Plan

그다음 실행 계획을 확인한다. 이 단계에서는 어떤 리소스가 새로 생성되는지, 어떤 리소스가 변경되는지, 어떤 리소스가 삭제되는지를 미리 볼 수 있다.

발표에서는 이 과정을 MySQL의 EXPLAIN 에 비유했다. 실제로 실행하기 전에 결과를 예측해볼 수 있다는 점에서 꽤 적절한 비유다.

Apply

마지막으로 실제 리소스를 생성한다. 이렇게 인프라를 실제 사용할 수 있는 상태로 준비하는 과정을 프로비저닝(provisioning) 이라고 부른다.

이 구조 덕분에 Terraform은 “실행 전에 무엇이 바뀌는지 확인할 수 있다”는 중요한 안정성을 제공한다.

Terraform 코드의 핵심 구성 요소

Terraform을 이해할 때 자주 나오는 핵심 개념들이 있다.

Provider

어떤 클라우드나 서비스를 사용할지 정의한다. 예를 들어 AWS, Cloudflare 같은 Provider를 선언하면, Terraform은 해당 서비스용 플러그인을 사용해 리소스를 제어한다.

Resource

실제로 생성할 인프라 객체다. 예를 들어 VPC, EC2, 보안 그룹, RDS 같은 것들이 Resource가 된다.

Variable

같은 모듈 안에서 재사용할 입력값을 정의한다. 예를 들어 Dev와 Prod가 거의 같은 구조지만 인스턴스 타입만 다르다면, 그 차이를 Variable로 분리할 수 있다.

Backend

Terraform state 파일을 어디 저장할지 결정한다. 이 state는 실제 인프라의 현재 상태를 기록한 파일이며, Terraform은 이 state와 코드의 차이를 비교해 변경 작업을 수행한다.

로컬에 저장하면 혼자 쓰기에는 편하지만 협업에는 적합하지 않다. 그래서 팀 단위에서는 보통 S3나 Terraform Cloud 같은 원격 저장소를 Backend로 사용한다.

Module

재사용 가능한 코드 패키지다. 예를 들어 EC2 생성 로직을 하나의 Module로 만들어두면, Dev와 Prod에서 입력값만 바꿔 재사용할 수 있다. 이건 Terraform 운영에서 굉장히 중요하다. 모듈화를 잘하면 중복을 줄이고 유지보수성을 크게 높일 수 있다.

Output

생성된 리소스의 결과값을 외부 모듈에서 쓸 수 있게 노출한다. 예를 들어 네트워크 모듈에서 생성된 VPC ID나 Subnet ID를 애플리케이션 모듈에서 참조해 EC2를 만들 때 사용할 수 있다.

Terraform 명령어는 어떻게 쓰는가

핵심 명령어는 네 가지다.

init

초기화 단계다. Backend 설정을 읽고, 필요한 Provider 플러그인을 설치한다.

plan

실행 계획을 보여준다. 무엇이 생성되고, 변경되고, 삭제되는지를 미리 확인할 수 있다. 실무에서는 이 단계가 매우 중요하다. Apply 전에 반드시 의도한 변경인지 검토해야 하기 때문이다.

apply

실제로 인프라를 생성하거나 변경한다. 기본적으로는 사용자 확인을 받지만, 옵션으로 자동 승인도 가능하다.

destroy

Terraform이 관리하는 리소스를 일괄 삭제한다. 테스트 환경을 빠르게 만들고 지우는 흐름에서도 유용하다.

실무에서 Terraform이 특히 유용한 순간

Terraform의 진짜 가치는 단순히 “한 번 만들기 편하다”가 아니다. 오히려 다음 상황에서 빛난다.

환경이 여러 개인 경우

Dev, Staging, Prod를 비슷한 구조로 유지해야 할 때 코드를 재사용하면 각 환경을 같은 기준으로 맞출 수 있다.

인프라 변경 이력을 남겨야 하는 경우

누가 보안 그룹을 바꿨는지, 언제 서브넷이 추가됐는지 추적이 필요할 때 Git 이력과 PR 기록이 큰 도움이 된다.

팀이 함께 인프라를 관리하는 경우

한 명의 기억에 의존하지 않고, 팀이 공통된 코드 베이스를 기준으로 협업할 수 있다.

테스트 환경을 자주 띄우고 지워야 하는 경우

성능 테스트용 Staging, 특정 브랜치용 임시 환경 같은 것을 반복적으로 만들 때 수동 작업과 비교할 수 없을 정도로 효율이 좋아진다.

Terraform과 함께 쓰면 좋은 도구들

자료에서는 Terraform과 함께 사용하면 좋은 보조 도구도 소개한다.

Terraformer

이미 존재하는 인프라를 스캔해서 Terraform 코드로 변환해주는 도구다.

이 도구가 특히 유용한 이유는, 이미 콘솔 기반으로 운영 중인 인프라가 있을 때 Terraform으로 전환하는 초기 비용을 줄여주기 때문이다.

즉, “처음부터 전부 손으로 코드화해야 하나?”라는 부담을 어느 정도 완화할 수 있다.

Infracost

Terraform 코드 기준으로 비용 변화를 예측해주는 도구다.

GitHub PR과 연동하면, 인프라 변경이 월 비용에 어떤 영향을 주는지 자동으로 보여줄 수 있다. 이건 실무적으로 꽤 강력하다. 인프라 변경은 기능 변경보다 비용 영향을 직관적으로 파악하기 어려운데, PR 단계에서 비용까지 함께 리뷰할 수 있기 때문이다.

왜 결국 Terraform을 써야 할까

정리하면 Terraform을 사용하는 이유는 분명하다.

첫째, 인프라를 코드로 정의할 수 있기 때문이다. 둘째, 같은 코드를 통해 같은 환경을 재현할 수 있기 때문이다. 셋째, 수동 작업과 기억 의존에서 벗어나 협업 가능한 인프라 운영 방식으로 바꿀 수 있기 때문이다. 넷째, 변경 이력, 리뷰, 복구, 자동화까지 개발 문화의 장점을 인프라에도 적용할 수 있기 때문이다.

Terraform은 단순히 인프라를 자동으로 만들어주는 도구가 아니다. 인프라를 “운영자의 감”이 아니라 “팀이 공유하는 코드”로 바꾸는 도구다.

결국 인프라가 커질수록 중요한 것은 빠르게 한 번 만드는 능력이 아니라, 반복 가능하고, 예측 가능하고, 함께 관리 가능한 방식으로 운영하는 능력이다.

그 지점에서 Terraform은 충분히 강력한 선택지다.

마무리

처음에는 콘솔에서 클릭 몇 번이면 충분해 보인다. 하지만 서비스가 성장하고, 환경이 늘어나고, 팀 단위 협업이 시작되면 인프라는 더 이상 “누군가 알아서 관리하는 영역”으로 남을 수 없다.

수동 인프라 관리는 결국 다음 문제를 낳는다.

재현이 어렵고
반복 작업이 많고
실수가 잦고
복구가 느리다

IaC는 이 문제를 코드로 해결하려는 접근이고, Terraform은 그 접근을 가장 현실적으로 구현할 수 있는 대표 도구다.

즉, Terraform 도입의 핵심은 자동화 자체보다도 일관성, 재현성, 협업 가능성, 그리고 운영 안정성 확보에 있다.

인프라가 단순할 때는 큰 차이를 못 느낄 수 있다. 하지만 복잡해질수록 “왜 Terraform이 필요한가?”라는 질문의 답은 점점 분명해진다. 결국 콘솔 클릭보다 코드가 더 오래 남고, 더 정확하고, 더 팀 친화적이기 때문이다.