Blog

Agent Toolkit for AWS를 활용한 바이브코딩 앱 배포 실습

Agent Toolkit for AWS를 활용한 바이브코딩 앱 배포 실습
Agent Toolkit for AWS를 활용한 바이브코딩 앱 배포 실습

바이브코딩으로 만든 로컬 앱을 AWS에 배포하려면 서비스 선택, CDK 작성, 보안 설정, 시크릿 관리 등 고려할 사항이 많습니다. AI 에이전트에게 위임할 수 있지만, 에이전트의 AWS 지식이 오래되었거나 보안 기본값을 누락하거나 로컬 CLI 실행으로 추적이 어려운 문제가 있습니다.

2026년 5월에 GA된 Agent Toolkit for AWS는 MCP 서버, 스킬, 규칙 파일을 통해 에이전트가 최신 AWS 모범 사례를 따르도록 하고, 모든 작업을 CloudTrail에 기록하며, IAM 조건 키로 에이전트의 권한을 별도 제한할 수 있는 도구입니다.

본 글에서는 바이브코딩으로 만든 팀 공지 게시판을 Agent Toolkit for AWS로 실제 배포하고, 그 과정에서 확인한 결과를 공유합니다.

확인 항목

Agent Toolkit for AWS가 실제로 어디까지 해주는지, 네 가지 관점에서 확인하였습니다.

  • ① AWS를 몰라도 배포할 수 있는가 — 사람이 개입한 횟수와 내용
  • ② 최신 모범 사례를 따르는가 — 생성된 인프라의 보안 및 비용 설정
  • ③ 통제 및 기록이 가능한가 — IAM 조건 키, CloudTrail
  • ④ 사용 시 주의할 점은 무엇인가 — 툴킷의 리전 제한, 인증 설정의 자동화 범위

진행 방식

  • 바이브코딩 단계에서는 AWS를 전혀 언급하지 않고, 로컬에서 동작하는 앱을 먼저 완성한 후 별도 세션에서 배포를 진행하였습니다.
  • Claude Code, 서울 리전(ap-northeast-2) 환경에서 실습하였습니다.

전체 소요 시간

단계소요 시간비고
바이브코딩~30분AWS 언급 없이 로컬 앱 완성
환경 준비 (CLI, 툴킷 설치)~15분aws configure agent-toolkit 포함
규칙 파일 전후 비교~10분동일 프롬프트로 Before/After 비교
배포 (cdk synth + cdk deploy)~15분synth 재시도 포함
배포 후 버그 수정 + 재배포~5분multer 누락 수정, 재배포 21초
실패 대응 테스트~10분환경변수 고장 → CloudWatch 진단
통제 검증 (조건 키 테스트)~10분IAM 정책 생성 → MCP/CLI 비교
합계~1시간 30분

01. 대상 앱: 팀 공지 게시판

팀 내부에서 사용할 공지 게시판으로, React + Express + SQLite 기반으로 구성하였습니다. 바이브코딩으로 약 30분 만에 완성하였으며, 이 단계에서는 AWS를 전혀 언급하지 않았습니다.

주요 기능:

  • 공지 조회: 누구나 공지 목록과 상세 내용을 확인할 수 있습니다.
  • 공지 작성/수정/삭제: 관리자(admin)로 로그인한 경우에만 가능합니다.
  • 첨부파일 업로드: 이미지, PDF 등의 파일을 공지에 첨부할 수 있습니다.
  • JWT 인증: 관리자/일반 사용자를 구분하는 간단한 로그인 기능을 포함합니다.
바이브코딩으로 만든 로컬 앱 화면
바이브코딩으로 완성한 팀 공지 게시판. 로컬에서 Express + SQLite로 동작합니다.

이 앱은 AWS 배포를 전혀 고려하지 않고 만든 “평범한 로컬 앱”입니다. 에이전트가 배포 과정에서 다음 항목들을 스스로 판단하고 전환해야 합니다.

로컬 구성 요소배포 시 에이전트가 처리해야 할 항목
Express 서버Lambda/컨테이너 판단
SQLite 파일 DBDynamoDB/RDS 전환
uploads/ 로컬 저장S3 전환 및 보안 설정
.env의 API 키, JWT 시크릿Secrets Manager 이전
JWT 로그인공개 앱 인증 경고 여부

02. 환경 준비

사전 요구사항

  • AWS CLI 2.35.0 이상 (aws configure agent-toolkit 명령에 필요)
  • Claude Code
  • Node.js, uv

툴킷 설치

설치 경로는 두 가지입니다.

경로 1: 플러그인 설치 (Claude Code 전용)

/plugin install aws-core@claude-plugins-official

경로 2: AWS CLI에서 직접 설정

AWS_REGION=us-east-1 aws configure agent-toolkit
실습 결과, 경로 1만으로는 MCP 도구가 세션에 노출되지 않았습니다. 경로 2를 추가 실행하고 세션을 재시작한 후 aws___run_script, aws___search_documentation 등 도구가 정상 노출되었습니다. aws configure agent-toolkit은 us-east-1에서만 동작하는 점에 유의해야 합니다.

연결 확인을 위해 AWS 공식 예시 프롬프트 “What AWS Regions are available?”을 실행하였습니다.

MCP 서버 연결 확인 — 리전 조회
MCP 서버를 통해 17개 AWS 리전을 조회한 결과. ap-northeast-2(서울)이 기본 리전으로 설정되어 있습니다.

03. 규칙 파일 적용 전후 비교

동일한 배포 프롬프트를 규칙 파일(aws-agent-rules.md) 적용 전후로 실행하여 차이를 비교하였습니다.

프롬프트: “팀 공지 게시판을 AWS에 배포해 줘. 서버리스로 구성하고, CDK로 배포해. 서울 리전에 올리고, 예상 비용을 먼저 알려 줘.”

Before — 규칙 파일 미적용

에이전트가 Lambda + API Gateway, S3 + CloudFront, DynamoDB를 제안하였습니다. 서비스 구성 자체는 적절했으나, 누락된 항목이 다수 확인되었습니다.

“.env의 AI_API_KEY는 Secrets Manager 또는 SSM Parameter Store에 저장합니다”

시크릿 저장 방식을 확정하지 못했으며, S3 퍼블릭 차단, 암호화, API Gateway 10MB 제한, 인증 경고, IAM 최소 권한은 전부 언급되지 않았습니다. 예상 비용도 시크릿 1개 기준 $0.55/월로 부정확하였습니다.

After — 규칙 파일 적용

에이전트가 스킬을 먼저 검색하였습니다. aws-serverless, aws-secrets-manager 스킬을 로드한 후 구성을 제안하였습니다.

“Secrets Manager에 저장하되, get-secret-value 직접 호출은 금지합니다. Lambda 환경변수에 ARN만 전달하고 런타임에 참조합니다”

“S3 버킷은 BlockPublicAccess.BLOCK_ALL을 기본으로 하고, 파일 업로드는 presigned URL로 처리합니다. API Gateway의 10MB 페이로드 제한을 우회하기 위해서입니다”

“JWT 자체 구현은 프로토타입용입니다. 운영 환경에서는 Amazon Cognito 또는 외부 IdP를 권장합니다”
항목BeforeAfter
Lambda 구성Express를 Lambda에 넣겠다는 언급만Express 전체를 Lambda 1개에 통째로 올리는 Lambdalith 패턴 명시
파일 업로드“S3에 저장”S3 직접 접근 차단 + 업로드 시에만 임시 URL(presigned URL) 발급
시크릿 관리“Secrets Manager 또는 SSM 중 하나”Secrets Manager 확정, 시크릿 값을 코드에서 직접 조회하지 않고 ARN으로 참조
S3 보안언급 없음버킷 공개 차단 + 서버 측 암호화 + CloudFront만 접근 허용(OAC)
인증 경고없음JWT 자체 구현의 한계를 경고하고 Cognito/외부 인증 서비스 권장
IAM 권한없음각 서비스별로 필요한 권한만 부여 (grant* 메서드)
예상 비용$0.55 (시크릿 1개 기준)$0.95 (시크릿 2개 반영, 더 정확)

규칙 파일 하나로 에이전트의 응답이 “대략적 제안”에서 “보안과 제약을 반영한 구체적 설계”로 변화한 것을 확인할 수 있습니다.

04. 배포 수행

에이전트가 구성한 아키텍처

에이전트가 구성한 AWS 배포 아키텍처
  • CloudFront → 모든 요청의 진입점. HTTPS 강제 적용
  • S3 (Frontend) → React 정적 파일 제공. CloudFront를 통해서만 접근 가능
  • HTTP API → Lambda → API 요청(/api/*) 처리. Express 앱 전체를 Lambda 1개에 구동
  • DynamoDB → 공지 및 사용자 데이터 저장
  • S3 (Uploads) → 첨부파일 저장. 임시 URL(presigned URL)로 업로드
  • Secrets Manager → JWT 시크릿, AI API 키를 ARN으로 참조
AWS 서비스용도
Lambda (NodejsFunction)Express 서버 (Lambdalith 패턴)
HTTP API (API Gateway v2)API 엔드포인트
DynamoDB (on-demand)사용자 테이블, 공지 테이블
S3 (2개)프론트엔드 정적 파일 + 첨부파일 업로드
CloudFront (OAC)CDN + HTTPS
Secrets ManagerJWT 시크릿, AI API 키

에이전트가 생성한 CDK 코드 (발췌)

에이전트가 작성한 notice-board-stack.ts에서 핵심 부분을 발췌하였습니다. 전체 190줄의 스택 파일을 사람이 수정하지 않았습니다.

S3 버킷 — 퍼블릭 차단 + 암호화 기본 적용

const uploadBucket = new s3.Bucket(this, 'UploadBucket', {
  blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
  encryption: s3.BucketEncryption.S3_MANAGED,
  removalPolicy: cdk.RemovalPolicy.DESTROY,
  autoDeleteObjects: true,
});

IAM 최소 권한 — grant* 메서드로 리소스별 권한 부여

usersTable.grantReadWriteData(apiFunction);
noticesTable.grantReadWriteData(apiFunction);
uploadBucket.grantReadWrite(apiFunction);
jwtSecret.grantRead(apiFunction);        // 읽기만
aiApiKeySecret.grantRead(apiFunction);   // 읽기만

Secrets Manager — Lambda에 ARN만 전달

environment: {
  JWT_SECRET_ARN: jwtSecret.secretArn,
  AI_API_KEY_ARN: aiApiKeySecret.secretArn,
  // 평문 시크릿은 환경변수에 넣지 않음
},

CloudFront — OAC + HTTPS 강제 + API 프록시

const distribution = new cloudfront.Distribution(this, 'Distribution', {
  defaultBehavior: {
    origin: origins.S3BucketOrigin.withOriginAccessControl(frontendBucket),
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
  },
  additionalBehaviors: {
    '/api/*': {
      origin: new origins.HttpOrigin(
        `${httpApi.httpApiId}.execute-api.${this.region}.amazonaws.com`),
      cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED,
    },
    '/uploads/*': {
      origin: origins.S3BucketOrigin.withOriginAccessControl(uploadBucket),
    },
  },
});

별도로 보안 설정을 요청하지 않았음에도, 규칙 파일과 스킬이 위 코드를 생성하였습니다. 에이전트가 자동 적용한 보안 설정은 S3 퍼블릭 차단 + 암호화, CloudFront OAC + HTTPS 강제, Secrets Manager ARN 참조, IAM grant* 최소 권한 총 6개 항목입니다.

배포 과정 및 결과

cdk synth 단계에서 빌드 오류가 발생하였으나, 에이전트가 에러 로그를 분석하여 자동으로 수정하였습니다.

synth 통과 후 cdk deploy는 약 4분 30초 만에 완료되었습니다. 바이브코딩부터 배포 완료까지 약 1시간, 테스트 및 검증까지 포함하면 약 1시간 30분이 소요되었습니다.

배포 결과:

  • CloudFront 배포 완료 (HTTPS 자동 적용)
  • HTTP API 엔드포인트 생성
  • 프론트엔드 정상, API 헬스체크 정상, 로그인 JWT 발급 성공
CloudFront로 배포된 공지 목록
배포 완료 후 CloudFront URL로 접속한 화면. 5건의 공지가 정상 표시됩니다.
공지 상세 화면
공지 상세 화면. 본문과 첨부파일이 정상 표시됩니다.

배포 후 발생한 버그 및 수정

공지 등록 시 “제목과 내용을 입력하세요” 에러가 발생하였습니다. 사람이 한 것은 “공지 등록하니까 에러 나”라고 전달한 것뿐이며, 원인이 multer인지, FormData 파싱인지, DynamoDB 전환 시 누락된 항목인지는 파악하지 못했습니다.

에이전트가 원인을 진단하여(SQLite에서 DynamoDB 전환 시 multer 미들웨어 누락) 코드를 수정하고 재배포까지 21초 만에 완료하였습니다.

다만 에이전트가 처음부터 완벽하게 전환하지는 못하였으므로, 배포 후 직접 동작을 확인하는 과정은 필수입니다. 문제를 전달하면 수정도 에이전트가 처리합니다.

05. 장애 대응 테스트

의도적으로 Lambda 환경변수 USERS_TABLE을 WRONG-TABLE-NAME으로 변경한 후, AWS 공식 예시 프롬프트를 그대로 사용하였습니다.

“My deployment failed and I can’t tell why. Can you take a look?”

에이전트가 CloudWatch Logs를 확인하고 즉시 원인을 특정하였습니다.

AccessDeniedException: User is not authorized to perform dynamodb:GetItem
on resource: arn:aws:dynamodb:ap-northeast-2:***:table/WRONG-TABLE-NAME

IAM 최소 권한(grant*)이 정확히 동작한 결과입니다. 에이전트가 지정한 테이블에만 권한을 부여하였기 때문에, 잘못된 테이블 접근은 자동으로 거부됩니다. 환경변수를 원래 값으로 복구한 후 정상 동작을 확인하였습니다.

06. 통제 검증: 에이전트 권한 제한

CloudTrail 기록 확인

배포 과정의 모든 API 호출이 CloudTrail에 기록되었습니다. 주체(lab_user, aws-cdk), 작업(CreateStack, PutItem, UpdateFunctionConfiguration), 시점을 전부 추적할 수 있습니다.

IAM 조건 키 테스트: aws:ViaAWSMCPService

에이전트(MCP 경유)의 쓰기만 차단하고, 사람(CLI 직접 호출)의 쓰기는 허용할 수 있는지 확인하였습니다.

테스트용 IAM 인라인 정책:

{
  "Effect": "Deny",
  "Action": ["dynamodb:PutItem", "dynamodb:DeleteItem", "dynamodb:UpdateItem"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:ViaAWSMCPService": "true"
    }
  }
}
테스트경로작업결과
①MCP (aws___run_script)DynamoDB PutItem거부 (AccessDeniedException)
②CLI (aws dynamodb put-item)DynamoDB PutItem허용 (성공)
③MCP (aws___run_script)DynamoDB GetItem허용 (읽기 성공)

aws:ViaAWSMCPService 조건 키를 통해 MCP 경유 작업에만 쓰기를 차단할 수 있음을 확인하였습니다. CLI 직접 호출은 영향을 받지 않으며, MCP 경유 읽기도 정상 허용됩니다.

07. 검증 결과 요약

① AWS를 몰라도 배포할 수 있는가

→ 가능합니다. 배포 중 에러가 여러 차례 발생하였으나, 사람이 직접 수정한 건은 없습니다. 사람이 한 것은 “에러 나”라고 전달한 1회뿐이었습니다. 서비스 선택, CDK 작성, 보안 설정, 에러 수정, 배포 실행까지 전부 에이전트가 처리하였습니다.

② 최신 모범 사례를 따르는가

→ 규칙 파일 적용 후에는 그렇습니다. 규칙 파일 없이는 S3 보안, IAM 최소 권한, 시크릿 관리 등 기본 항목도 누락되었습니다. 규칙 파일이 적용되면 에이전트가 스킬을 먼저 검색하고 보안 설정을 자동으로 반영합니다. 규칙 파일은 선택이 아닌 필수입니다.

③ 통제 및 기록이 가능한가

→ 가능합니다. CloudTrail에 모든 작업이 기록되며, aws:ViaAWSMCPService 조건 키를 통해 에이전트 경유 작업에 대해서만 별도로 권한을 제한할 수 있습니다.

④ 주의점은 사실인가

주의점확인 결과
MCP 엔드포인트 서울 미지원사실. aws configure agent-toolkit은 us-east-1에서만 동작. 단, 배포 대상 리전은 서울(ap-northeast-2)로 지정 가능
공개 앱은 인증을 별도로 구성해야 함사실. 규칙 파일 적용 후 에이전트가 Cognito/IdP 권장 경고를 출력하였으나, 직접 적용하지는 않음

08. 예상 비용

항목월 예상 비용
Lambda$0.00
DynamoDB (on-demand)$0.00
S3 (2개 버킷)$0.02
CloudFront$0.00
Secrets Manager (2개)$0.80
합계~$0.95/월

마무리

Agent Toolkit for AWS는 바이브코딩 앱의 AWS 배포를 상당 부분 자동화할 수 있는 도구입니다. 규칙 파일을 적용하면 에이전트가 보안과 모범 사례를 자동으로 반영하고, 조건 키로 권한을 제한할 수 있으며, 모든 작업이 CloudTrail에 기록됩니다.

다만 규칙 파일 없이는 에이전트의 판단이 불완전하며, 배포 후 동작 확인은 사람이 직접 수행해야 합니다.

실습 환경

Claude Code AWS CLI 2.35.2 CDK ap-northeast-2 (서울)

참고 자료

조회수 : 11