AWS Step Functions 워크플로를 AgentCore Gateway로 AI 에이전트 도구로 사용: 단계 순서는 상태 머신이 결정

AWS는 2026년 10월 29일 AWS Step Functions 워크플로를 Amazon Bedrock AgentCore Gateway를 통해 AI 에이전트의 도구로 쓸 수 있게 됐다고 발표했다. 에이전트가 워크플로를 언제 실행할지와 어떤 입력을 넘길지를 정하고, Step Functions는 정의된 대로 각 단계를 정확히 실행한다. 기존 Standard와 Express 워크플로를 그대로 도구로 쓸 수 있고, 요금은 Step Functions와 AgentCore Gateway의 표준 요금이다.

가치는 역할 분담에 있다. AgentCore Gateway는 모델 컨텍스트 프로토콜(MCP)로 에이전트와 도구를 잇고, Step Functions는 여러 단계의 업무 절차를 정해진 순서로 실행한다. AWS의 예는 고객 지원 에이전트가 환불 워크플로를 시작하면 Step Functions가 자격 확인, 관리자 승인, 크레딧 지급 단계를 차례로 실행해 모든 환불이 정책을 따르게 하는 것이다. 운영 에이전트는 워크플로 실행 기록도 조회해 당직 엔지니어에게 간밤에 어떤 주문이 어느 단계에서 실패했는지 알려 줄 수 있다. 발표는 Step Functions가 220개 이상의 AWS 서비스를 오케스트레이션할 수 있다고 하는데, 이는 AWS가 직접 내놓은 숫자다. 이 기능은 AgentCore Gateway를 쓸 수 있는 모든 리전에서 이용할 수 있다.

개발자 가이드는 작동 방식을 설명한다. 게이트웨이 대상을 만들 때 내장 Step Functions 커넥터를 고른다. Lambda 함수나 MCP 서버를 쓸 필요도, 도구를 직접 정의할 필요도 없다. 게이트웨이가 도구 스키마를 만들고 에이전트를 대신해 Step Functions를 호출한다. 커넥터는 열 가지 작업을 노출한다. 그중 네 가지는 대상을 만들 때 고정해 둔 상태 머신에 작용한다. StartExecution, StartSyncExecution, ListExecutions, DescribeStateMachine이다. 에이전트는 고정된 상태 머신을 볼 수도 바꿀 수도 없고 stateMachineArn을 넘기면 게이트웨이가 호출을 거부한다. 나머지 여섯 가지인 DescribeExecution, StopExecution, GetExecutionHistory, SendTaskSuccess, SendTaskFailure, SendTaskHeartbeat는 에이전트가 제공하는 실행 ARN이나 작업 토큰에 작용한다. 고정된 상태 머신에 제한되지 않으므로 게이트웨이 서비스 역할의 IAM 정책만이 이를 통제한다.

권한 경계는 눈여겨봐야 한다. 문서는 이 정책을 가능한 한 좁게 하라고 권한다. 예컨대 DescribeExecution, StopExecution, GetExecutionHistory는 노출하는 상태 머신의 실행 ARN으로 제한하고 states:*를 부여하지 않는다. 세 가지 SendTask 작업은 IAM에 리소스 수준 권한이 없어 “*”로 허용해야 하므로 작업 토큰이 유일한 통제 수단이 되며, 토큰은 비밀로 다뤄야 한다. 고정 가능한 작업을 stateMachineArn 없이 포함하면 게이트웨이가 대상을 만들 수는 있어도 도구가 호출할 때마다 실패한다.

두 워크플로 유형은 쓸 수 있는 작업이 다르다. StartSyncExecution은 Express에서만 되고 Standard에서는 실패한다. ListExecutions는 Standard에서만 되며 Express에서는 StateMachineTypeNotSupported가 나온다. DescribeExecution, GetExecutionHistory, StopExecution은 Standard 실행에서만 되는데, Express 실행은 시작한 뒤 ARN으로 지정할 수 없기 때문이다. StartExecution, DescribeStateMachine과 SendTask 계열은 둘 다 쓸 수 있다. Standard 워크플로는 각 단계를 실행 기록에 남기고 최대 1년까지 실행되므로 감사나 사람의 승인이 필요한 긴 절차에 맞다. 워크플로가 .waitForTaskToken에서 멈추고 토큰을 에이전트의 애플리케이션에 넘기면, 에이전트가 작업을 마친 뒤 SendTaskSuccess나 SendTaskFailure를 호출해 재개시킨다. Express와 StartSyncExecution은 동기식 요청과 응답에 맞는다. 여기서 ‘두 유형 모두’는 커넥터 작업을 뜻한다. .waitForTaskToken 콜백 자체는 Standard 워크플로에서만 지원되고 Express에서는 지원되지 않는다.

튜토리얼은 이를 여섯 단계로 나눈다. 상태 머신 만들기, 게이트웨이용 서비스 역할 만들기, 게이트웨이와 Step Functions 커넥터 대상 만들기, 게이트웨이로 실행 시작하기, 결과 확인하기, 리소스 정리하기다. 열 가지 작업 중 여섯 가지를 설정하고 awscurl로 에이전트와 같은 MCP 요청을 보낸다. 에이전트는 먼저 tools/list를 호출해 설정된 작업마다 하나씩 있는 도구를 찾고, 고정된 매개변수는 도구 스키마에 나타나지 않아서 예컨대 StartExecution은 input만 알린다. 개발자 가이드가 드는 전형적인 호출 순서는 StartExecution, 반환된 ARN으로 상태를 보는 DescribeExecution, 각 단계를 보는 GetExecutionHistory다. 에이전트와 워크플로의 협력은 두 가지다. 에이전트가 워크플로를 시작하고 진행을 확인하며 필요하면 멈추거나, 워크플로가 .waitForTaskToken에서 멈추고 에이전트가 작업을 마치기를 기다린다. 작업 하나에 상태 머신 하나만 고정할 수 있으므로 같은 작업에 여러 상태 머신을 노출하려면 각각 대상을 만들어야 하고, 한 대상에서 StartExecution은 Standard에, StartSyncExecution은 Express 상태 머신에 고정할 수도 있다. 에이전트가 stateMachineArn을 넘기면 게이트웨이는 Invalid request parameters: cannot set parameter(s): [/stateMachineArn] 오류로 거부한다. 문서는 실행 이력이 필요하거나 오래 걸리거나 사람의 승인이 필요한 절차에는 Standard를, 결과를 바로 받아야 하는 요청에는 Express와 StartSyncExecution을 쓰라는 취지로 설명한다.

튜토리얼은 Pass 상태 하나뿐인 Standard 상태 머신을 쓰고 awscurl로 에이전트와 같은 MCP 호출을 한다. 모든 리소스는 같은 리전에 만들어야 하는데, 게이트웨이가 자기 리전의 Step Functions를 호출하기 때문이다. 튜토리얼 리소스는 삭제할 때까지 상태 전환과 도구 호출 요금이 발생한다. AWS 페이지에는 지연 시간, 규모, 고객 수치가 없으므로 이는 성능 보고가 아니라 기능 설명이다. 실제 가치는 워크플로가 이미 잘 정의돼 있는지와 게이트웨이 역할을 얼마나 좁게 잡는지에 달렸다.