AI 에이전트가 CloudFormation Express 모드를 사용하여 직접 AWS 스택을 설계, 배포 및 수정하게 해보았습니다

2026년 6월 30일, AWS는 CloudFormation Express mode를 발표했습니다. 이는 모든 리소스가 완전히 안정화 (stabilize)될 때까지 기다리는 대신, CloudFormation이 리소스 구성을 적용 (applied)하자마자 제어권을 반환하는 새로운 배포 모드입니다. AWS의 자체 예시에 따르면 SQS 큐 + DLQ의 경우 64초(Standard 모드)에서 10초(Express 모드)로 단축됩니다.

출시 포스트는 제가 거부할 수 없는 유스케이스를 구체적으로 언급했습니다: 바로 **인프라를 구축하는 AI 에이전트 (AI agents building infrastructure)**입니다. 만약 에이전트가 CloudFormation 템플릿을 반복 작업한다면 — 배포, 에러 읽기, 수정, 재배포 — 안정화를 기다리는 매 초는 에이전트(그리고 당신)가 로딩 스피너를 바라보며 보내는 시간이 됩니다. 그래서 저는 이 아이디어를 구현할 수 있는 가장 작은 버전을 구축하고, 출시 포스트의 약속이 아닌 실제로 어떤 일이 일어나는지 확인하기 위해 실제 AWS 계정에 연결해 보았습니다.

설정 (The setup)

에이전트 프레임워크 없이 약 150줄의 Python 하네스 (harness)로 구성되었습니다:

• 모델 (Model): Amazon Bedrock의 Claude Sonnet 4.6 (us.anthropic.claude-sonnet-4-6)을 사용하며, 단일 도구 (tool)와 함께 Converse API를 통해 호출됩니다.
• 모델이 받는 유일한 도구: deploy_stack(template_yaml). 이 도구는 ap-northeast-1 리전에서 DeploymentConfig={"Mode": "EXPRESS", "DisableRollback": true}를 사용하여 실제 CloudFormation 스택을 생성하거나 업데이트합니다. 매초 DescribeStacks를 폴링하며, 만약 스택이 실패 상태에 빠지면 실패한 DescribeStackEvents 사유를 가져와 도구 결과값으로 반환합니다.
• 루프 (The loop): 모델에게 평이한 영어로 목표를 부여하고, 모델이 필요한 만큼 deploy_stack을 호출하게 합니다. 실패 사유를 도구 결과로 다시 피드백하며, 스택이 CREATE_COMPLETE 또는 UPDATE_COMPLETE 상태에 도달하면 중단합니다.

result = deployer.deploy(
    STACK_NAME, template_yaml, mode="EXPRESS", disable_rollback=True
)
...

스캐폴딩(Scaffolding)도, 미리 작성된 템플릿도 없습니다. 모델은 명세(Spec)로부터 유효한 CloudFormation을 직접 작성해야 하며, 자신이 작성한 YAML의 결과에 책임을 져야 합니다.

제가 준 지침 (The brief I gave it)

단순한 "Hello World" 수준의 Lambda를 요청하지 않았습니다. 그것은 흥미를 끌기에 너무 쉬운 과제입니다. 제가 준 지침은 작지만 주관이 뚜렷한 (opinionated) 서버리스 API를 요구했습니다:

• API Gateway HTTP API 뒤에 위치한 Lambda 함수 (Python 3.13), GET /health → {"status": "ok"}.
• 전용 IAM 역할 (dedicated IAM role). AWSLambdaBasicExecutionRole 관리형 정책을 명시적으로 금지하며, 함수의 자체 로그 그룹에 범위가 제한된 인라인 최소 권한 (least-privilege permissions)만 허용할 것.
• 함수 생성 전에 생성되는, 7일 보존 기간을 가진 명시적인 AWS::Logs::LogGroup.
• 적절한 AWS_PROXY 통합, 자동 배포 기능이 있는 $default 스테이지, 그리고 API Gateway를 위한 리소스 범위가 지정된 Lambda::Permission.
• 호출 URL (invoke URL) 출력.

이 IAM 제약 조건은 매우 중요합니다. CloudWatch Logs 권한에는 CreateLogStream을 위한 로그 그룹 ARN이 필요하지만, 스트림 수준에서의 PutLogEvents/CreateLogStream을 위해서는 :log-stream:* 접미사가 필요합니다. 이는 저를 포함한 많은 사람들이 끊임없이 실수하는 세부 사항입니다.

발생한 일

에이전트는 완전한 템플릿을 작성하고 deploy_stack을 단 한 번 호출했습니다. CloudFormation Express 모드는 25.6초 만에 CREATE_COMPLETE를 보고했으며, 첫 시도에 IAM ARN 범위를 정확하게 맞추었습니다:

Resource:
  - !GetAtt LambdaLogGroup.Arn
  - !Sub '${LambdaLogGroup.Arn}:log-stream:*'

더 중요한 점은, Express 모드의 "설정 적용 완료"가 거짓이 아니었다는 것입니다. API는 이미 트래픽을 처리하고 있었습니다:

$ curl -s -w "\nHTTP_STATUS:%{http_code} TIME:%{time_total}s\n" \
    https://8p7jv0cjt7.execute-api.ap-northeast-1.amazonaws.com/health
{"status": "ok"}
...

한 번에 성공했다는 점은 제가 기대했던 것보다 다소 단조로운 이야기입니다. 저는 실패-수정-재배포(failure-fix-redeploy) 사이클을 보여주고 싶었습니다. 극적인 효과를 위해 가짜 실패를 연출하지 않기 위해 솔직하게 말씀드리자면, 이번 실행에서는 그 과정이 필요하지 않았습니다. 하네스(harness)의 deploy_stack 도구는 실패 원인을 모델에게 직접 다시 전달하도록 설계되어 있으며(그것이 설계의 핵심입니다), 이번에는 그 기능이 실행될 필요가 없었을 뿐입니다. 만약 Sonnet 4.6에게 실제 IAM의 미묘한 차이가 포함된 사양(spec)을 준다면, 모델이 이를 완벽하게 해내더라도 놀라지 마십시오.

실제 속도 향상 수치 격리하기

단일 에이전트 실행은 모델 지연 시간(latency), 템플릿 품질, 그리고 CloudFormation 실행 시간이 뒤섞여 있으므로, Express 모드 자체만을 깔끔하게 측정하기는 어렵습니다. 실제 수치를 얻기 위해, 저는 에이전트가 생성한 템플릿을 가져와 통제된 루프를 통해 실행했습니다: 스택 생성, 삭제, 반복 — 동일한 계정, 동일한 리전에서 Standard 모드로 3회, Express 모드로 3회를 연속으로 수행했습니다.

모드	실행 횟수	평균 배포 시간	개별 실행 시간
STANDARD	3	51.91s	52.03s, 51.78s, 51.93s
EXPRESS	3	25.44s	25.58s, 25.24s, 25.51s

Lambda + API Gateway HTTP API + IAM 역할(role) + 로그 그룹(Log Group) 스택을 기준으로, 일관되게 2.04배 더 빠릅니다. 이는 AWS가 SQS에 대해 발표한 4배 향상이라는 헤드라인 수치는 아닙니다. 리소스마다 안정화되는 방식이 다르기 때문입니다. 하지만 두 모드 모두 실행 간 편차가 0.5초 미만이었으므로, 이 격차는 노이즈가 아닌 실제적이고 재현 가능한 결과입니다. 더 복잡한 것을 구축하면서 수십 번의 반복 및 수정(iterate-and-fix) 사이클을 수행하는 에이전트에게, 매 라운드 트립(round-trip) 시간을 절반으로 줄이는 것은 매우 빠르게 누적됩니다.

디버깅 시간을 아껴줄 주의사항 하나

하네스를 처음 시도했을 때, 다음과 같은 오류와 함께 8번 연속으로 즉시 실패했습니다:

ValidationError: OnFailure cannot be specified with EXPRESS deployment mode.

저는 습관적으로 (개발 스택을 롤백하지 않으려는 오래된 습관 때문에) DeploymentConfig와 함께 OnFailure="DO_NOTHING"을 전달하고 있었습니다. Express 모드는 롤백 동작을 오직 DeploymentConfig.DisableRollback을 통해서만 제어하기를 원합니다. 기존의 OnFailure 파라미터를 혼용하면 즉시 거부되며, 에러 메시지를 자세히 살펴보면 그 이유가 명확히 설명되어 있습니다. 만약 기존의 배포 스크립트를 Express 모드로 이식하고 있다면, 먼저 OnFailure를 검색(grep)해 보세요.

핵심 요약 (Takeaways)

• AI 에이전트 워크플로우를 위한 Express 모드의 약속은 단순한 마케팅이 아니라 실질적입니다. 실제 멀티 리소스 스택에서 동일한 템플릿으로 연속 실행을 측정한 결과, 생성부터 확인까지의 루프 시간이 약 절반 정도로 단축되었습니다.
• "Configuration applied"가 곧 "준비되지 않음"을 의미하지는 않습니다. 제가 curl 명령어를 다 입력하기도 전에 API는 이미 활성화되어 응답하고 있었습니다.
• 모델에게 약간의 주관이 담긴 보안 중심의 명세(관리형 실행 역할 제외, 정확한 ARN 범위 지정 등)를 제공하는 것이 단순한 Hello-world Lambda를 테스트하는 것보다 에이전트의 IaC 기술을 검증하기에 더 좋은 방법입니다. Sonnet 4.6은 별도의 요령을 알려주지 않았음에도 ARN 범위 지정의 미묘한 차이를 정확하게 처리했습니다.
• CloudFormation을 대상으로 에이전트 루프를 구축하고 있다면, 단순히 "실패했다"라고 전달하지 말고 실제 StackEvents의 실패 원인을 도구 결과(tool result)로서 모델에게 다시 전달하세요. 그것이 재시도 루프(retry loop)를 실제 수정 루프(fix loop)로 바꾸는 방법입니다.

배포/폴링(poll) 헬퍼, Bedrock 도구 사용(tool-use) 루프, 벤치마크 스크립트를 포함한 모든 코드는 총 250여 줄이며 GitHub에서 확인할 수 있습니다: yama3133/cfn-express-agent-demo.