쉬운 설명
옛날엔 새 서버를 만들 때 AWS 콘솔에서 클릭하고, 보안 그룹을 설정하고, 누군가 그 과정을 기억하길 바랐습니다. 시간이 지나면 '왜 이렇게 설정했더라'를 아무도 모르고, 같은 환경을 다른 리전에 재현하는 게 며칠짜리 작업이 됐습니다. IaC는 이걸 다르게 풉니다.
IaC의 발상은 '인프라도 코드처럼 다룬다'입니다. Terraform·Pulumi·CloudFormation·AWS CDK 같은 도구의 코드로 'EC2 인스턴스 3대, t3.medium, 보안 그룹 X, 로드밸런서 뒤에' 같은 내용이 git에 들어가 있고, 변경은 PR로 리뷰되고, 적용은 자동으로 됩니다.
장점이 큽니다. ① 같은 환경을 손쉽게 재현(스테이징·복구·신규 리전), ② 변경 추적 가능(누가 언제 무엇을 바꿨나 git log로 확인), ③ 사고 후 복구가 빠름(코드로 다시 만들면 됨), ④ 팀원 사이 환경 차이가 사라짐, ⑤ 인프라 변경을 사람이 리뷰할 수 있게 됨.
두 가지 큰 접근이 있습니다. ① 선언적(declarative): Terraform·CloudFormation처럼 '최종 상태'를 적으면 도구가 차이를 계산해 적용. 가장 흔한 방식. ② 명령형(imperative): 'A를 만든 다음 B를 만들어'처럼 순서를 적음. AWS CDK·Pulumi는 일반 프로그래밍 언어(타입스크립트·파이썬)로 쓰면서 내부적으로 선언적 모델을 생성하기도 합니다.
단점도 분명합니다. 처음 도입에 학습 비용이 들고, 잘못 적용하면 운영을 한 번에 망가뜨릴 수 있어 적용 전 dry-run(terraform plan)·승인 절차가 필요합니다. 또 인프라 코드와 실제 상태가 어긋날 수 있어(drift), 정기적으로 확인하는 운영 습관이 함께 필요합니다.
비유로 보면
IaC는 정원의 청사진을 만드는 일과 비슷합니다. 어떤 나무를 어디에 심고 어떤 모양으로 가지치기할지를 종이에 적어 두면, 정원사가 누구든 같은 모양으로 정원을 만들 수 있고, 폭풍에 망가져도 청사진을 보고 같은 정원을 다시 만들 수 있습니다.
어디에서 만나나
멀티 리전·멀티 환경(스테이징·프로덕션)을 운영하는 회사, 컴플라이언스 요구가 있는 금융·의료(인프라 변경 이력이 필수), 사고 후 복구가 빠르게 필요한 서비스, 새 환경 생성·삭제가 잦은 머신러닝·연구 환경. 현대 클라우드 운영의 표준 도구가 됐습니다.
작은 예시
한 회사가 미국 리전에서 서비스를 잘 운영하고 있다가, 일본에도 같은 환경을 깔아야 하는 일이 생겼습니다. IaC가 없었다면 며칠~몇 주가 걸렸을 일이, Terraform 코드 변수 한두 개만 바꿔 적용하면 한두 시간 만에 똑같은 환경이 일본 리전에 생깁니다.
자주 하는 오해
한 줄 정리
IaC의 진짜 가치는 '인프라 결정의 흔적을 남긴다'에 있습니다. 코드로 적힌 인프라는 토론·복구·재현이 모두 단순해집니다.