생성형 AI IaC로 클라우드 비용을 잡는 법: 절감이 아니라 변경 비용 통제

# 생성형 AI IaC로 클라우드 비용을 잡는 법: 절감이 아니라 변경 비용 통제  비용 최적화는 ‘절약’이 아니라 **변경 비용을 통제하는 운영 기술**로 다뤄야 한다. 클라우드 비용이 폭증하는 순간은 대개 리소스가 늘어서가 아니다. 변경이 통제되지 않아서다. IaC는 변경을 코드로 고정하고, 생성형 AI는 그 변경을 읽고 설명하는 비용을 낮춘다. 이 글은 도구 소개가 아니라 운영 기록에 가깝다. “갑자기 비용이 튄 주”를 하나의 시나리오로 두고, 변경 내역에서 원인을 좁혀가는 흐름을 정리한다. 결론은 단순하다. 돈은 결과 지표이고, 진짜 레버는 변경의 품질이다. ## 비용이 튀는 주의 공통점: 변경이 먼저 있었다 비용 알람이 울리는 날은 대개 배포가 몰린 날이었다. 이 상관관계는 감상이 아니라 구조다. 클라우드는 사용량 기반이므로, 작은 변경이 지출 곡선을 꺾는다. 문제는 “누가 무엇을 바꿨는지”가 흐릿해지는 순간부터 시작된다. 운영에서 반복되는 비용 누수 지점은 이미 정해져 있다. 태그가 빠지고, 환경별 파라미터가 드리프트되고, 테스트 계정이 방치된다. 스팟과 온디맨드가 섞이며, 로그 보관 정책이 없고, 데이터 전송이 통제되지 않는다. 이 항목들은 체크리스트로는 잘 사라지지 않는다. 구조적 원인은 간단하다. 변경이 ‘사건’으로만 기록되고 ‘판단’으로는 축적되지 않기 때문이다. 그래서 비용 최적화의 단위는 리소스가 아니라 변경이어야 한다. ## IaC의 역할: 표준화를 통해 변경을 “검증 가능”하게 만든다 IaC의 가치는 자동 생성에 있지 않다. 가치는 변경을 텍스트로 만들고, 그 텍스트를 검증 가능하게 만드는 데 있다. 콘솔에서의 클릭은 흔적을 남기지만, 논리를 남기지 않는다. 운영에서 필요한 것은 “언제든 되돌릴 수 있음”이다. 한 번은 큰 규모의 데이터 마이그레이션을 하면서, 자동화는 속도가 아니라 되돌림에 투자해야 한다는 걸 배웠다. IaC도 같은 원리로 작동한다. 빠르게 만드는 것보다, 안전하게 바꾸는 것이 우선이다.  다만 IaC만으로는 부족하다. IaC는 바뀐 내용을 보여주지만, 그 변화가 비용에 어떤 압력을 주는지는 사람이 해석해야 한다. 여기서 리뷰 비용이 폭증한다. 그리고 그 폭증이 곧 통제 상실로 이어진다. ## 생성형 AI의 역할: 코드를 대신 쓰는 것이 아니라 리뷰의 밀도를 올린다 생성형 AI를 IaC에 붙이는 이유를 “코드 작성 자동화”로 두면 금방 한계를 만난다. 운영에서 더 본질적인 병목은 작성이 아니라 검토다. 즉, AI는 작성자가 아니라 **검토 비용을 낮추는 보조 장치**로 위치해야 한다. 나는 적용 지점을 세 단계로 나눠 생각한다. 작성 단계, 검토 단계, 운영 단계다. 각 단계의 목표는 다르지만, 공통된 목적은 하나다. 변경의 품질을 표준화하는 것.  ### 1) 작성 단계: 모듈 초안이 아니라 “정책이 묻은 초안”을 만든다 작성 단계에서 AI가 할 일은 템플릿을 뽑는 것이 아니다. 명명 규칙, 태그 정책, 환경 분리 원칙을 반영한 초안을 만드는 일이다. 사람이 매번 기억에 의존하면, 비용 누수는 재현된다. 여기서 핵심은 입력이다. 팀의 태그 체계, 비용 센터 기준, 환경별 기본값이 먼저 문서화돼야 한다. 정책이 빈약하면, AI는 그 빈약함을 더 빠르게 복제한다. ### 2) 검토 단계: PR에서 비용 영향 요약과 위험 리소스 탐지를 자동화한다 검토 단계는 비용 최적화의 중심이다. PR이 열리는 순간이 유일하게 “변경을 멈출 수 있는 지점”이기 때문이다. 운영 단계에서 잡으면 이미 돈이 나갔다. 이때 AI가 할 수 있는 일은 명확하다. 변경된 리소스를 읽고, 비용에 민감한 항목을 요약한다. 대표적으로 NAT 게이트웨이, 로드밸런서, 데이터 전송, RDS의 구성 같은 것들이 여기에 들어간다. 중요한 것은 ‘정답 판정’이 아니다. AI 코멘트는 승인 도장이 아니라, 리뷰어의 시선을 비용 위험에 고정하는 장치다. 리뷰의 밀도가 올라가면, 변경은 느려지지 않고 오히려 안정된다. 아래는 구현 형태를 단순화한 예시다. 제품은 무엇이든 가능하다. 요지는 “PR에 비용 가드레일을 내장한다”는 구조다. ```yaml # 예시: PR 파이프라인에 IaC 플랜과 AI 요약을 붙이는 흐름(개념) steps: - run: terraform fmt -check - run: terraform validate - run: terraform plan -out=tfplan - run: terraform show -json tfplan > plan.json - run: policy_check plan.json # 정책 as 코드(예: OPA)로 1차 차단 - run: ai_cost_review plan.json # AI가 변경 요약/위험 포인트/질문 생성 - run: post_comment_to_pr review.md ``` 정책 as 코드가 1차 차단을 맡고, AI가 2차 해석을 맡는다. 이 분업은 현실적이다. 정책은 규칙을 강제하고, AI는 맥락을 언어로 만든다. 둘 중 하나만으로는 운영이 흔들린다. ### 3) 운영 단계: 비용 이상 징후를 “설명 가능한 문장”으로 만든다 운영 단계에서 가장 비싼 일은 장애 대응만이 아니다. 비용 증가의 원인 규명이 길어질 때, 조직은 기술이 아니라 정치로 흔들린다. 회계와 기획은 숫자를 묻고, 운영은 변경을 설명해야 한다. 여기서 AI는 보고서를 대신 쓰는 도구가 아니다. 변경 이력과 비용 지표를 연결해 “왜 늘었는지”를 설명하는 초안을 만든다. 설명 비용이 낮아지면, 대응은 빨라지고 논쟁은 줄어든다. 단, 이 단계는 욕심을 버려야 한다. 정교한 예측을 약속하면 신뢰가 깨진다. 보통은 “최근 변경 상위 N개 + 비용 민감 리소스 + 확인해야 할 질문”이면 충분하다. ## 실전 시나리오: 비용이 튄 주에, 무엇부터 붙잡았는가 가정은 단순하다. 주간 비용이 눈에 띄게 올랐다. 이때 사람은 흔히 리소스 목록부터 뒤진다. 그러면 원인은 흩어지고, 결론은 “좀 줄이자”로 끝난다. 나는 순서를 바꾼다. 비용이 아니라 변경을 먼저 본다. IaC 리포지토리에서 지난주 머지된 PR을 시간순으로 모은다. 그다음 AI 요약 코멘트와 정책 체크 결과를 함께 본다. 여기서 자주 잡히는 패턴이 있다. - 태그 누락: 비용 분리가 깨지고, 비용 책임이 흐려진다. - 환경 파라미터 드리프트: 스테이징이 프로덕션처럼 비싸진다. - 테스트 계정 방치: “잠깐” 만든 리소스가 상시 비용이 된다. - 로그 보관 정책 부재: 저장 비용이 완만하게, 그러나 확실히 쌓인다. 이 패턴들은 기술 문제가 아니다. 운영의 기억력 문제다. IaC는 기억을 코드로 만들고, AI는 그 기억을 읽기 쉬운 언어로 만든다. 그래서 대응은 “리소스를 줄이자”가 아니라 “변경의 품질을 올리자”로 수렴한다. 수정 PR은 보통 작고 단단해야 한다. 태그를 강제하고, 기본값을 낮추며, 보관 기간을 명시한다. 그리고 반드시 되돌림 경로를 남긴다. 선택은 언제나 포기를 동반한다. ## 지표 설계: 돈만 보면 다시 흔들린다 비용 최적화의 지표를 비용 하나로 두면, 운영은 다시 감각에 의존한다. 돈은 결과다. 결과만 보면 원인을 놓친다. 그래서 나는 지표를 세 축으로 둔다: 비용, 변경, 운영. 비용 지표는 기본을 지킨다. 월/주 단위 추세, 서비스별 분리, 환경별 분리를 최소 단위로 둔다. 태그 정책이 여기서 효력을 발휘한다. 변경 지표는 통제력을 측정한다. 배포 빈도, 롤백 횟수, 핫픽스 비율은 운영의 품질을 드러낸다. 비용이 내려가도 롤백이 늘면, 그 절감은 빚이다. 운영 지표는 효율을 측정한다. MTTR, 알람 노이즈 비율, 리소스 드리프트 발생 건수를 본다. IaC와 AI가 제대로 작동하면, 이 지표들이 먼저 좋아진다. 이 구성을 취하면 비용 최적화는 캠페인이 아니라 체계가 된다. FinOps가 ‘조직’이 아니라 ‘파이프라인’에 내장된다는 말은, 결국 이 뜻이다. 통제는 회의실이 아니라 PR에서 발생한다. ## 트레이드오프: 더 빠른 확신은 더 빠른 전염이기도 하다 AI가 PR 코멘트를 달면 리뷰는 빨라진다. 그러나 정책이 빈약하면, 잘못된 확신이 더 빨리 전파된다. 따라서 AI를 먼저 붙이기보다, 최소한의 정책부터 고정해야 한다. 또 하나의 비용이 있다. 리뷰가 촘촘해지면, 초기에는 개발자가 답답함을 느낀다. 이때 운영이 해야 할 일은 통제의 이유를 숫자가 아니라 변경의 언어로 설명하는 것이다. 정책과 AI는 서로를 보완해야 한다. 정책은 “안 된다”를 말하고, AI는 “왜 안 되는가”를 말한다. 둘이 합쳐질 때, 통제는 강제가 아니라 학습이 된다. ## 결론: 비용은 숫자지만, 통제의 단위는 변경이다 클라우드 비용 최적화는 절감 기법의 모음이 아니다. 변경을 코드로 고정하고, 그 변경을 검토 가능한 구조로 만드는 일이다. IaC는 표준화를 제공하고, 생성형 AI는 리뷰와 설명의 비용을 낮춘다. 돈은 결과 지표이고, 운영 효율은 과정 지표다. 과정을 통제하면 결과는 따라온다. 비용은 숫자지만, 통제의 단위는 언제나 **변경**이다.