해당 스터디는 90DaysOfDevOps
https://github.com/MichaelCade/90DaysOfDevOps
를 기반으로 진행한 내용입니다.
Day 89 - Seeding Infrastructures: Merging Terraform with Generative AI for Effortless DevOps Gardens
1. 테라폼과 생성형 AI 결합
기존의 Terraform 사용 방식이 인간이 코드를 한 줄씩 작성하고 검증하는 방식이었다면, 생성형 AI의 도입은 이 프로세스를 근본적으로 변화시킨다.
-
코드 생성의 가속화: Amazon Bedrock의 Claude v2나 OpenAI의 GPT 모델들은 자연어 요구사항을 완벽한 테라폼 HCL(HashiCorp Configuration Language) 코드로 변환 가능
-
단계별 추론:
-
AI는 단순히 결과물만 내놓는 것이 아니라, "먼저 VPC를 구성하고, 그 다음 서브넷을 나눈 뒤, EC2를 배치하라"는 식의 순차적 사고가 가능함.
-
AutoGPT나 LangChain과 같은 프레임워크와 결합했을 때 더욱 강력해짐.
-
-
인간-AI-인프라의 조화: AI가 초안을 빠르고 방대하게 작성하면, 인간은 이를 검수하고 전략적 의사결정을 내리는 구조로 업무가 재편
2. Seeding Engine이란?
우리가 흔히 사용하는 ChatGPT나 베드락(Bedrock) 콘솔은 기본적으로 수동적이다.
개발자가 "EC2 인스턴스 하나 만들어줘"라고 입력해야만 비로소 코드를 뱉어낸다.
하지만 시딩 엔진은 능동적이고 지속적이다.
-
정의: 조직의 요구사항과 Best Practice를 입력받아, Terraform 코드를 생성(Seeding)할 뿐만 아니라, 배포된 인프라가 건강하게 유지되도록 지속적으로 관리하고 치유하는 통합 자동화 시스템
-
비유: 마트에서 다 자란 화분을 사 오는 것이 아니라, 유능한 정원사(AI Engine)를 고용하여 씨앗을 심고, 물을 주고, 잡초를 뽑게 하는 것과 같다.
프레젠테이션에서는 해당 시스템이 단순한 질의응답 도구를 넘어선다고 강조한다.
그 차별점은 다음 세 가지로 요약된다.
-
Context을 이해하는 맞춤형 인프라 (RAG 활용)
-
일반적인 AI 모델은 인터넷에 있는 범용적인 지식으로 코드를 짠다. 하지만 시딩 엔진은 RAG(검색 증강 생성) 기술을 접목하여 조직의 특수성을 이해한다.
-
일반 AI: "보안 그룹 만들어줘"라고 하면 0.0.0.0/0을 허용하는 등 범용적이지만 보안에 취약한 코드를 생성할 가능성이 있다.
-
시딩 엔진: 기업 내부의 보안 가이드라인, 기존 아키텍처 문서, 레거시 코드를 참조한다.
따라서 "우리 회사 보안 정책인 22번 포트 폐쇄 및 사내 VPN 대역만 허용"하는 규칙을 준수하며 코드를 생성한다. 즉, 조직의 가드레일 안에서 안전하게 작동한다.
-
-
생성(Day 1)을 넘어선 운영(Day 2)의 자동화
-
코드를 짜고 배포하는 것에서 끝나는 것이 아니라, 인프라가 배포된 이후의 삶(Day 2 Operations)까지 관여한다.
-
프로액티브 관리: 발표된 아키텍처에서 보았듯, 시딩 엔진은 CloudWatch 및 Lambda와 유기적으로 연결되어 있다.
-
작동 시나리오: 트래픽이 급증하여 사이트가 느려지는 상황을 가정해 보자.
-
CloudWatch가 이상 징후를 감지한다.
-
시딩 엔진(Lambda)으로 신호를 보낸다.
-
엔진이 이를 분석하여 "Auto Scaling Group의 Max Capacity를 늘려야 합니다"라고 판단한다.
-
테라폼 코드를 스스로 수정하고 재배포를 자동화한다.
-
-
-
인간과 AI의 협업 프로세스 내재화
-
시딩 엔진은 AI가 독단적으로 행동하지 않도록 설계된다.
-
초안 작성: AI가 복잡한 인프라 구성의 80~90%를 순식간에 구축한다.
-
인간의 검수: 엔지니어는 처음부터 코드를 짜는 것이 아니라, AI가 만든 구조가 전략적으로 맞는지, 보안상 치명적인 문제는 없는지 검토하는 역할로 전환된다.
-
피드백 루프: 인간이 코드를 수정하면, 엔진은 이를 학습하여 다음 배포 때 더 정확한 코드를 생성한다.
-
발표자는 이 개념을 실제 AWS 환경에 구현했다. 그 기술적 흐름은 다음과 같이 이루어진다.
-
입력: 엔지니어가 확장 가능한 웹 앱 인프라 필요라는 자연어 요구사항이나 설정 파일(JSON/YAML)을 입력한다.
-
생성 (Generation via Bedrock): EC2에 호스팅된 엔진(Python 애플리케이션)이 Amazon Bedrock(Claude v2)을 호출한다. 이때 프롬프트 엔지니어링을 통해 테라폼 HCL 문법과 사내 규칙을 준수하도록 강제한다.
-
검증 및 배포 : 생성된 코드는 S3에 저장되고, AWS CodePipeline을 통해
terraform plan->validate->apply과정을 거친다. -
감지 및 대응 : 인프라에 변경이 필요하거나 문제가 생기면, CloudWatch 알람이 다시 엔진(Lambda)을 깨워 코드를 수정하고 인프라를 치유한다.
발표에서 공개된 시딩 엔진의 아키텍처는 AWS의 관리형 서비스들을 유기적으로 결합하여 생성-배포-감지-대응의 완전한 파이프라인을 구축했다.
-
아키텍처 구성 요소 상세
-
Amazon EC2 (Host): 시딩 엔진의 본체(Python 애플리케이션)가 구동되는 서버다. 전체 워크플로우를 조율하는 두뇌 역할을 한다.
-
Amazon Bedrock (Generative AI): Anthropic Claude v2 모델을 사용하여, 보안성을 유지한 채 내부 네트워크로 AI 모델을 호출하고 테라폼 코드를 생성한다.
-
Amazon S3 (Storage & Trigger): 생성된 테라폼 템플릿(
.tf)이 저장된다. 파일이 업로드되거나 수정되는 이벤트가 발생하면, 이를 트리거로 후속 자동화 작업이 시작된다. -
AWS CodeBuild & CodePipeline (CI/CD): S3의 변경 사항을 감지하여 실제로
terraform plan,terraform apply를 수행하는 배포 파이프라인이다. -
Amazon CloudWatch & AWS Lambda:
-
CloudWatch는 인프라의 상태를 실시간으로 감시한다.
-
이상이 감지되면 Lambda가 트리거되어, EC2에 있는 시딩 엔진에게 "코드를 수정하라"는 신호를 보내거나 즉각적인 복구 스크립트를 실행한다.
-
-
AWS Secrets Manager: Bedrock API 키나 DB 접근 정보 등 민감한 데이터를 코드에서 분리하여 안전하게 관리한다.
-
3. 프롬프트 엔지니어링과 코드 구현 전략
시딩 엔진의 아키텍처를 갖췄다면, 이제는 이 엔진을 실제로 똑똑하게 움직이게 할 두뇌를 설계해야 한다.
프레젠테이션에서는 이 과정에서 가장 중요한 것은 AI에게 작업을 지시하는 프롬프트 엔지니어링과 결과를 검증하는 피드백 루프라고 강조한다.
AI의 창의성을 기술적으로 통제하고, 결과물을 엄격하게 검증하는 과정이 없다면 자동화는 오히려 리스크가 될 수 있기 때문이다.
-
구체적 프롬프트: "웹 앱 만들어줘" 같은 추상적 지시는 지양한다. 대신 "EC2, Auto Scaling Group, ELB, RDS, S3, IAM Role, VPC 등을 포함한 아키텍처"와 같이 필요한 구성 요소를 명확히 나열하여 청사진을 제시해야 AI가 정확한 코드를 작성한다.
-
파라미터 튜닝: 인프라 코드는 소설이 아니므로 창의성보다는 팩트와 정확성이 필수다. 모델의
Temperature와Top_P값을 0에 가깝게 설정하여, 존재하지 않는 리소스를 만들어내는 Hallucination 현상을 차단하고 일관된 결과를 얻어야 한다. -
파이썬 구현:
boto3 라이브러리로Bedrock(Claude v2)을 호출하고, 응답받은 JSON에서 코드를 추출해.tf파일로 저장한다. 이후subprocess모듈로terraform init과apply를 연쇄 실행하여 코드 작성부터 배포까지를 하나의 함수로 자동화한다. -
자동화된 테스트: 문법적으로 옳은 코드가 보안적으로도 안전하다는 보장은 없다. 배포 전
Checkov,TFLint,Terratest같은 도구를 파이프라인에 심어 SSH 포트 개방이나 리소스 제한 같은 정책 위반을 기계적으로 걸러내야 한다. -
인간 개입: 기계적인 검증을 넘어 조직적인 피드백이 필요하다. 데이터 분석가나 아키텍트 등 다양한 직군의 요구사항을 반영해 프롬프트를 개선하고, 특히 민감한 보안 설정은 최종적으로 인간의 승인을 거치도록 프로세스를 설계해야 한다.
이처럼 시딩 엔진은 단순히 코드를 생성하는 것을 넘어, "믿어라, 하지만 검증하라(Trust, but Verify)"는 원칙 아래 정교한 지시와 다층적인 검증 과정을 거쳐야 신뢰할 수 있는 시스템으로 완성된다.
4. 케이스 스터디 및 결론
프레젠에이션에서는 급성장하는 웹사이트 프로젝트에 이 시딩 엔진을 도입했다.
그 결과 트래픽 변동에 따라 인프라가 자동으로 확장되는 Adaptive Scaling 환경을 구축했으며, 다운타임과 유지보수 비용을 획기적으로 절감했다.
엔지니어는 단순 코딩 시간은 줄이고 전략적 설계에 집중할 수 있게 되었다.
핵심 요약
-
나만의 엔진 구축: 베드락과 같은 파운데이션 모델을 그대로 쓰지 말고, 조직의 데이터와 가이드라인을 학습시켜 최적화해야 한다.
-
협업 AI : 미래의 데브옵스는 AI가 인간을 대체하는 것이 아니라, 인간이 AI라는 강력한 파트너를 감독하고 협업하는 형태로 진화할 것이다.
-
보안 타협 금지: 자동화의 편리함에 취해 보안을 놓치면 안 된다. 보안 검수는 AI와 인간의 이중 레이어로 철저히 수행되어야 한다.
결론적으로, 시딩 엔진은 인프라를 심고 스스로 자라나게 관리하는 새로운 데브옵스의 지평을 열고 있다.
이제 엔지니어는 Coder에서 AI 엔진의 설계자(Architect)로 역할을 확장해야 할 때다.
