Claude에게 인프라 코드 작성을 부탁해 봤습니다.
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번 블로그에서는 Claude에게 인프라 코드 작성을 부탁해 봤습니다.
Claude와 관련된 블로그는 아래를 참고해 주세요.
Claude로 실제 결과물 만들어보기
지금까지는 간단한 기능이나 문서 생성 중심의 활용을 살펴봤다면, 이번에는 한 단계 더 나아가 실제 인프라 전체 구성을 생성하는 예시를 살펴보겠습니다.
Claude는 단순한 코드 생성 수준을 넘어, 요구사항을 기반으로 VPC, 서브넷, 라우팅, EC2까지 포함된 인프라 구조 전체를 설계할 수 있습니다.
다음과 같이 프롬프트를 구체화해서 질문을 던져봤습니다.
너는 AWS 인프라 엔지니어야.
다음 요구사항을 만족하는 CloudFormation 템플릿을 작성해줘.
- VPC 생성 (CIDR: 10.0.0.0/16)
- 퍼블릭 서브넷 1개 (10.0.1.0/24)
- 인터넷 게이트웨이 연결
- 라우팅 테이블 설정 (인터넷 통신 가능)
- EC2 인스턴스 1대 생성 (Amazon Linux 2, t3.micro)
- ap-northeast-1 리전
- SSH(22), HTTP(80) 포트 오픈
- 퍼블릭 IP 할당
- 태그(Name: web-server)
YAML 형식으로 작성해줘.
먼저 구축할 인프라의 전체 구성도를 생성해 주었습니다.
구성도를 통해 전체 아키텍처를 확인한 뒤, 이어서 생성되는 리소스 목록과 순서도 함께 확인할 수 있었습니다.
| 리소스 | 논리 ID | 주요 설정 |
|---|---|---|
| VPC | MyVPC | 10.0.0.0/16, DNS 활성화 |
| Internet Gateway | MyIGW | VPC에 자동 Attach |
| Public Subnet | PublicSubnet | 10.0.1.0/24, ap-northeast-1a, 퍼블릭 IP 자동 할당 |
| Route Table | PublicRouteTable | 0.0.0.0/0 → IGW 경로 추가 |
| Security Group | WebServerSG | 인바운드: TCP 22, 80 / 아웃바운드: 전체 허용 |
| EC2 Instance | WebServerInstance | Amazon Linux 2, t3.micro, Name: web-server |
이어서 CloudFormation 코드는 다음과 같습니다.
AWSTemplateFormatVersion: '2010-09-09'
Description: >
VPC + Public Subnet + IGW + EC2 (Amazon Linux 2, t3.micro) stack
Region: ap-northeast-1
# ---------------------------------------------------------------------------
# Parameters
# ---------------------------------------------------------------------------
Parameters:
KeyName:
Type: AWS::EC2::KeyPair::KeyName
Description: EC2 인스턴스에 사용할 키 페어 이름을 입력하세요.
# ---------------------------------------------------------------------------
# Mappings – Amazon Linux 2 AMI (ap-northeast-1)
# ---------------------------------------------------------------------------
Mappings:
RegionMap:
ap-northeast-1:
AMI: ami-0599b6e53ca798bb2 # Amazon Linux 2 (2024 기준, 최신 AMI로 교체 권장)
# ---------------------------------------------------------------------------
# Resources
# ---------------------------------------------------------------------------
Resources:
# ── VPC ──────────────────────────────────────────────────────────────────
MyVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: my-vpc
# ── Internet Gateway ─────────────────────────────────────────────────────
MyIGW:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: my-igw
AttachIGW:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref MyVPC
InternetGatewayId: !Ref MyIGW
# ── Public Subnet ─────────────────────────────────────────────────────────
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref MyVPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: ap-northeast-1a
MapPublicIpOnLaunch: true # 퍼블릭 IP 자동 할당
Tags:
- Key: Name
Value: public-subnet
# ── Route Table ──────────────────────────────────────────────────────────
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref MyVPC
Tags:
- Key: Name
Value: public-rtb
PublicRoute:
Type: AWS::EC2::Route
DependsOn: AttachIGW
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref MyIGW
SubnetRouteTableAssoc:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTable
# ── Security Group ───────────────────────────────────────────────────────
WebServerSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Allow SSH and HTTP inbound traffic
VpcId: !Ref MyVPC
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: 0.0.0.0/0 # 운영 환경에서는 특정 IP로 제한 권장
Description: SSH access
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
Description: HTTP access
SecurityGroupEgress:
- IpProtocol: -1
CidrIp: 0.0.0.0/0
Description: Allow all outbound
Tags:
- Key: Name
Value: web-server-sg
# ── EC2 Instance ─────────────────────────────────────────────────────────
WebServerInstance:
Type: AWS::EC2::Instance
Properties:
ImageId: !FindInMap [RegionMap, !Ref AWS::Region, AMI]
InstanceType: t3.micro
KeyName: !Ref KeyName
SubnetId: !Ref PublicSubnet
SecurityGroupIds:
- !Ref WebServerSG
Tags:
- Key: Name
Value: web-server
UserData:
Fn::Base64: |
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from web-server (ap-northeast-1)</h1>" > /var/www/html/index.html
# ---------------------------------------------------------------------------
# Outputs
# ---------------------------------------------------------------------------
Outputs:
VpcId:
Description: 생성된 VPC ID
Value: !Ref MyVPC
Export:
Name: !Sub "${AWS::StackName}-VpcId"
PublicSubnetId:
Description: 퍼블릭 서브넷 ID
Value: !Ref PublicSubnet
Export:
Name: !Sub "${AWS::StackName}-PublicSubnetId"
InstanceId:
Description: EC2 인스턴스 ID
Value: !Ref WebServerInstance
PublicIp:
Description: EC2 퍼블릭 IP 주소
Value: !GetAtt WebServerInstance.PublicIp
PublicDns:
Description: EC2 퍼블릭 DNS
Value: !GetAtt WebServerInstance.PublicDnsName
이어서 배포 명령어와 주의사항도 같이 안내해 주는 것을 확인할 수 있었습니다.
배포 명령어
bashaws cloudformation deploy \
--template-file vpc-ec2-stack.yaml \
--stack-name web-stack \
--parameter-overrides KeyName=<your-key-pair> \
--region ap-northeast-1
주의사항 두 가지
- KeyName 파라미터는 해당 리전에 미리 생성된 키 페어 이름을 입력해야 합니다.
- AMI ID(ami-0599b6e53ca798bb2)는 시점에 따라 변경될 수 있으니, 배포 전 AWS 콘솔 → EC2 → AMI Catalog에서 최신 Amazon Linux 2 AMI ID를 확인하는 것을 권장합니다. UserData에 Apache(httpd) 자동 설치 및 기본 index.html 생성 스크립트도 포함되어 있습니다.
실제로 구축해 보자
Claude로 전달받은 코드가 실제로 동작하는지 AWS 상에서 구축해 보도록 합시다.
먼저 CloudFormation 스택은 성공적으로 생성되는 것을 확인할 수 있습니다.
마지막으로 지정한 키 페어를 바탕으로 EC2에 SSH 접속을 시도해 보면, 성공적으로 접속되는 것을 확인할 수 있습니다.
Run "/usr/bin/dnf check-release-update" for full release and version update info
, #_
~\_ ####_ Amazon Linux 2023
~~ \_#####\
~~ \###|
~~ \#/ ___ https://aws.amazon.com/linux/amazon-linux-2023
~~ V~' '->
~~~ /
~~._. _/
_/ _/
_/m/'
[ec2-user@ip-xx-x-x-xxx ~]$
이 과정을 통해 느낀 점
이번 실습을 통해 확인할 수 있었던 가장 큰 포인트는, Claude가 단순한 코드 생성 도구를 넘어 실제 인프라 구축까지 이어질 수 있는 수준의 결과물을 만들어낸다는 점이었습니다.
단순한 한 줄 요청에서 시작했지만
인프라 구성도 생성리소스 목록 정리CloudFormation 코드 작성배포 명령어 안내주의사항 정리
까지 이어지면서, 실제로 AWS 환경에 배포 가능한 수준의 결과물이 만들어졌습니다.
특히 인상적인 부분은, 단순히 코드를 생성하는 것이 아니라 구성 → 설계 → 실행 → 검증까지 이어지는 흐름을 자연스럽게 연결해준다는 점이었습니다.
생성형 AI를 이렇게 활용하자
이번 사례를 통해 얻을 수 있는 가장 중요한 인사이트는 다음과 같습니다.
막연한 요청이 아니라,구체적인 요구사항을 전달할 것- 단순 코드 요청이 아니라,
역할 + 결과물을 함께 지정할 것 - 생성된 결과는 그대로 사용하는 것이 아니라
초안 → 검토 → 수정과정으로 활용할 것
이러한 방식으로 접근하면, 생성형 AI는 단순한 보조 도구가 아니라 실제 업무를 함께 수행하는 파트너로 활용할 수 있습니다.
마무리
이번 글에서는 생성형 AI를 활용하여 요구사항 정의부터 시작해 아키텍처 설계, 코드 생성, 그리고 실제 AWS 환경에 배포하는 과정까지 하나의 흐름으로 이어지는 경험을 살펴보았습니다.
이 과정을 통해 가장 중요하게 느낄 수 있는 점은 단순히 결과를 얻는 것이 목적이 아니라, 어떤 방식으로 요청을 구성하느냐에 따라 결과물의 수준과 완성도가 크게 달라진다는 부분입니다. 같은 “인프라를 만들어줘”라는 요청이라 하더라도, 환경 조건, 구조 설계, 제약 사항 등을 얼마나 구체적으로 정의하느냐에 따라 전혀 다른 결과가 만들어집니다.
특히 이번 예시처럼 구조 설계에서 시작해 인프라 코드 생성으로 이어지고, 실제 AWS 배포까지 연결되는 흐름을 경험해보면 생성형 AI를 바라보는 관점 자체가 달라지게 됩니다. 단순히 필요한 내용을 대신 작성해주는 도구가 아니라, 전체 시스템을 설계하고 구현하는 과정에서 함께 사고를 확장시키는 도구로 인식이 변화하게 됩니다.
또한 이 과정에서 중요한 변화는 작업의 중심이 점점 코드 작성 자체에서 벗어난다는 점입니다. 이전까지는 리소스를 하나하나 구성하고 문법을 맞추는 것이 핵심이었다면, 이제는 어떤 구조가 필요한지, 어떤 흐름으로 구성할 것인지와 같은 설계 단계가 더 중요한 역할을 하게 됩니다. 그리고 그 설계를 기반으로 생성형 AI가 구체적인 구현을 빠르게 도와주는 형태로 역할이 분리됩니다.
이러한 변화는 단순히 개발 생산성을 높이는 수준을 넘어서, 인프라와 시스템을 바라보는 방식 자체를 바꾸는 경험으로 이어질 수 있습니다. 반복적인 작업이나 초기 구성 단계는 AI가 빠르게 처리하고, 사람은 그 위에서 구조를 설계하고 방향성을 결정하는 역할에 집중하는 구조로 변화합니다.
결국 앞으로의 작업 방식은 단순히 질문을 던지고 답을 받는 형태가 아니라, 원하는 결과를 먼저 명확하게 정의하고, 그 결과를 만들어가는 과정을 AI와 함께 진행하는 형태로 변화하고 있다고 볼 수 있습니다. 이러한 접근 방식에 익숙해질수록 생성형 AI는 단순한 보조 도구가 아니라 실제 업무 흐름 안에서 중요한 역할을 담당하는 도구로 자리 잡게 됩니다.
이 글에서 다룬 내용은 결국 하나의 흐름으로 정리할 수 있습니다. 어떻게 요청하느냐에 따라 결과가 달라지고, 그 결과는 단순한 코드나 문서가 아니라 실제 시스템 구조까지 확장될 수 있다는 점입니다. 그리고 그 중심에는 생성형 AI를 어떻게 활용하느냐에 대한 사고 방식의 변화가 있습니다.
