Step Functions AgentCore 연동, 승인 가능한 에이전트 단계

AI 요약

• 무슨 일: AWS가 Step Functions에서 AgentCore harness를 호출하는 optimized integration을 공개했습니다.
  • 2026년 6월 3일 발표이며, harness preview region인 N. Virginia, Oregon, Frankfurt, Sydney에서 사용할 수 있습니다.
• 운영 변화: 에이전트 reasoning을 workflow의 Task state로 넣고 승인, 병렬 실행, 재시도, execution history와 묶을 수 있습니다.
• 주의점: Step Functions 응답은 final assistant message 중심이며, tool use와 reasoning block은 output content에 남지 않습니다.
  • 문서는 InvokeHarness Task state 최대 실행 시간이 15분이고, Task timeout 뒤에도 harness가 자체 timeout까지 계속 실행될 수 있다고 적습니다.

AWS가 2026년 6월 3일 Step Functions에 AgentCore-powered agentic reasoning step을 추가했습니다. 발표문은 짧지만, 개발팀이 에이전트를 운영 시스템에 넣을 때 마주치는 질문 하나를 정면으로 다룹니다. 에이전트가 언제 실행되고, 실패하면 누가 재시도하며, 위험한 액션 앞에서 승인 절차를 어떻게 넣고, 비용과 reasoning trace를 어디서 확인할 것인가입니다.

이번 업데이트의 대상은 Amazon Bedrock AgentCore의 managed harness입니다. AWS 문서에서 harness는 모델 추론, tool use, multi-turn conversation을 orchestration하는 managed runtime입니다. Step Functions 쪽에서는 이 harness를 arn:aws:states:::bedrockagentcore:invokeHarness라는 Task state resource로 호출합니다. 개발자는 Workflow Studio에서 AgentCore InvokeHarness state를 찾고, Quick Create Harness로 새 harness와 execution role을 만들거나 기존 harness ARN을 선택할 수 있습니다.

Step Functions는 이미 분산 애플리케이션, ETL, 마이크로서비스, 보안 대응 절차를 visual workflow로 묶는 서비스입니다. AWS의 Step Functions 제품 페이지는 220개 이상 AWS 서비스 통합, built-in error handling, parallel processing, human-in-the-loop control을 장점으로 적습니다. AgentCore harness가 여기에 들어오면 에이전트는 별도 챗봇 UI나 독립 실행 서비스가 아니라, 기존 workflow의 한 단계가 됩니다.

이 차이는 엔터프라이즈 AI 팀에 꽤 직접적입니다. 많은 에이전트 데모는 모델이 tool을 부르고 결과를 반환하는 순간 끝납니다. 실제 운영 절차는 그 뒤가 더 깁니다. 문서 분류 에이전트가 confidence가 낮은 값을 냈을 때 사람이 확인해야 하는지, 송장 추출 에이전트가 비용 센터를 바꿨을 때 승인 step을 거쳐야 하는지, 두 개의 전문 에이전트를 병렬로 돌린 뒤 어느 결과를 신뢰할지, 실패한 tool call을 몇 번 재시도할지 결정해야 합니다. Step Functions 통합은 이런 결정을 agent prompt 내부가 아니라 workflow definition 쪽으로 옮깁니다.

AWS가 발표문에서 든 예시는 문서 분류와 비정형 form element extraction입니다. 이 예시가 평범해 보이는 이유는 의도적입니다. agentic reasoning이 꼭 로봇 같은 자율 행동을 뜻하지 않아도 됩니다. 입력 문서를 보고 분류 기준을 적용하거나, 표준 양식이 아닌 문서에서 항목을 뽑고, confidence와 결과를 다음 workflow step에 넘기는 작업도 production에서는 에이전트가 됩니다. 이때 팀이 필요한 것은 더 화려한 conversation이 아니라 실행 조건, 실패 처리, 감사 가능성입니다.

Step Functions 문서는 optimized AgentCore harness integration의 제약을 명확히 적습니다. 지원되는 integration pattern은 Request Response뿐입니다. .sync로 long-running job completion을 기다리거나 callback task token으로 외부 승인 신호를 직접 받는 방식은 이 AgentCore Task state 자체에서는 지원되지 않습니다. 다만 workflow 전체 관점에서는 Step Functions의 다른 state와 approval pattern을 조합할 수 있습니다. AgentCore 호출은 reasoning step이고, 승인과 분기와 재시도는 Step Functions의 외부 control logic으로 둘 수 있습니다.

응답 형식도 운영 설계에 영향을 줍니다. 문서에 따르면 response는 Converse-shaped JSON으로 변환되고, final assistant message만 반환됩니다. multi-turn conversation의 earlier turns는 버려지고, tool use와 reasoning blocks는 Output.Message.Content에 포함되지 않습니다. 대신 token usage는 InputTokens, OutputTokens, TotalTokens로 모든 message에 걸쳐 집계됩니다. latency는 Metrics.LatencyMs에 기록됩니다. agent가 어떤 tool을 왜 불렀는지까지 애플리케이션 payload로 저장하려면 CloudWatch trace와 별도 artifact 전략을 함께 설계해야 합니다.

15분 제한도 작지 않습니다. Step Functions 문서는 InvokeHarness Task state의 최대 실행 시간이 900초라고 적습니다. 더 긴 TimeoutSeconds를 넣어도 Step Functions Task state는 15분 제한을 갖습니다. 더 까다로운 경고는 execution 중지와 timeout의 관계입니다. 문서는 Task state가 timeout되거나 execution이 멈춰도 harness는 자체 timeout에 도달할 때까지 계속 실행될 수 있다고 설명합니다. 비용을 예측하려면 workflow timeout과 harness timeout을 같은 사고방식으로 맞춰야 합니다.

이 부분은 에이전트 운영에서 자주 빠지는 세부 사항입니다. 사람이 보는 workflow는 실패했는데, model inference와 tool loop가 뒤에서 계속 돌면 토큰 비용과 side effect가 남을 수 있습니다. 예를 들어 browser tool이나 code interpreter가 연결된 harness가 외부 시스템을 조회하거나 파일을 만들고 있다면, Step Functions 쪽 timeout만으로 충분한 중단 보장이 되지 않을 수 있습니다. AWS 문서가 “unexpected costs”를 피하려면 harness timeout이 15분을 넘지 않도록 하라고 적은 이유입니다.

권한 모델도 두 층으로 나뉩니다. Step Functions execution role은 특정 harness ARN을 호출할 수 있어야 합니다. 문서의 IAM 예시는 bedrock-agentcore:InvokeHarness와 bedrock-agentcore:InvokeAgentRuntime 권한을 특정 harness resource로 좁힙니다. 반면 gateway, browser, code interpreter 같은 tool 권한은 Step Functions execution role이 아니라 harness execution role에 설정됩니다. 워크플로 작성자와 agent tool 운영자가 분리된 조직에서는 이 경계가 승인 체계의 기준점이 됩니다.

AgentCore harness 자체는 더 넓은 실행 환경입니다. AWS의 AgentCore harness 문서는 모델, system prompt, tools, memory, skills를 harness 아래에 놓습니다. 그 밑에는 Runtime, Identity, Observability가 배치됩니다. harness session은 stateful이고, isolated microVM 안에서 filesystem과 shell을 가질 수 있습니다. short-term·long-term memory와 파일도 session 간 유지할 수 있습니다. 모델도 Bedrock, OpenAI, Google Gemini, OpenAI-compatible API를 쓸 수 있다고 문서는 설명합니다.

Step Functions 통합은 이 harness를 업무 프로세스의 특정 지점에 배치합니다. 예를 들어 계약서 검토 워크플로에서는 OCR 이후 InvokeHarness가 clause risk를 요약하고, risk score가 일정 기준을 넘으면 human approval step으로 보낼 수 있습니다. 고객 지원 workflow에서는 주문 상태 조회 에이전트를 호출한 뒤, refund 권한이 필요한 경우 별도 approval branch로 갈 수 있습니다. 데이터 파이프라인에서는 Map state로 여러 문서 묶음을 병렬 처리하고, 실패 항목만 retry policy에 태울 수 있습니다.

per-invocation override는 이 통합의 실무 가치를 키웁니다. 같은 harness를 재사용하면서 model, system prompt, tools를 invocation마다 바꿀 수 있기 때문입니다. Step Functions 문서의 예시는 기본 invocation에서 SystemPrompt, Model, MaxIterations, TimeoutSeconds를 Task state 안에 넣습니다. browser tool 예시에서는 Tools 배열에 agentcore_browser를 지정합니다. workflow의 입력값, 고객 등급, 데이터 민감도에 따라 model과 tool set을 바꾸는 설계가 가능합니다.

RuntimeSessionId는 conversation continuity를 다루는 작은 필드처럼 보이지만, multi-step workflow에서는 상태 관리의 핵심입니다. 같은 session ID를 여러 invocation에 넘기면 conversation을 이어갈 수 있습니다. 한 workflow execution 안에서 문서를 읽고, 보완 질문을 만들고, 사람이 답한 뒤 같은 context로 최종 판단을 내리는 구조를 만들 수 있습니다. 반대로 session ID를 매번 새로 만들면 각 agent step은 독립 판단으로 남습니다. 감사와 개인정보 보관 정책에 따라 어떤 쪽이 맞는지 정해야 합니다.

가격 구조는 발표문이 짧게 정리합니다. harness integration에 별도 추가 요금은 없습니다. Step Functions workflow execution에는 표준 Step Functions pricing이 적용되고, model inference와 AgentCore resource에는 Bedrock 및 AgentCore 비용이 붙습니다. 비용을 산정할 때는 state transition만 보면 안 됩니다. agent loop의 iteration 수, tool call 횟수, CloudWatch trace, memory와 browser 같은 AgentCore capability 사용량이 함께 쌓입니다.

개발자 경험에서 눈에 띄는 부분은 Workflow Studio입니다. 발표문은 기존 harness를 재사용하거나 Workflow Studio에서 새 harness를 직접 만들 수 있다고 설명합니다. 이는 “agent를 배포한 뒤 workflow에 연결”하는 절차를 줄입니다. 그러나 production에서는 이 편의성이 곧바로 governance를 대체하지 않습니다. Quick Create로 만든 execution role의 tool permission을 확인해야 합니다. 특정 workflow가 호출할 수 있는 harness ARN, dev·staging·prod의 session memory 분리 방식도 함께 점검해야 합니다.

CloudWatch 연결은 이 발표의 운영 단서입니다. Step Functions execution details view에는 agent step 옆에 CloudWatch link가 표시됩니다. 문서에 따르면 그 링크에서 tool use를 포함한 turn-by-turn reasoning view를 볼 수 있습니다. 애플리케이션 payload에는 final assistant message만 남지만, 운영자는 CloudWatch에서 상세 trace를 확인합니다. 이 구조는 product log와 operational trace를 분리합니다. 보안팀은 trace retention과 접근 권한을 따로 정해야 합니다.

이번 발표에서 AgentCore의 AWS 내 위치가 더 선명해졌습니다. AgentCore는 모델 API wrapper가 아니라 runtime, memory, identity, gateway, browser, code interpreter, observability를 묶은 agent execution substrate입니다. Step Functions는 그 substrate 바깥에서 sequencing, branching, approval, retry를 맡습니다. AWS가 선택한 모양은 “모델이 모든 control flow를 prompt로 결정한다”가 아니라, “에이전트는 reasoning step이고 업무 절차는 workflow engine이 통제한다”에 가깝습니다.

경쟁 제품과 비교하면 Temporal이나 Durable Functions도 오래전부터 retry, timeout, compensation, human workflow를 다뤄 왔습니다. LangGraph와 LangSmith는 agent graph와 trace에 강합니다. Vercel Workflow 같은 durable workflow 도구도 agent 작업을 오래 실행하고 재개하는 방향으로 갑니다. AWS의 차별점은 Step Functions가 이미 AWS IAM, CloudWatch, service integration, approval pattern, enterprise account boundary 안에 있다는 점입니다. AWS 계정 안에서 agent runtime을 쓰려는 팀에는 procurement와 security review가 짧아질 수 있습니다.

반대로 AWS 밖의 도구를 많이 쓰는 팀에는 lock-in과 trace portability가 질문으로 남습니다. AgentCore harness는 Strands Agents 기반이며, model provider를 바꿀 수 있다고 문서는 말합니다. 그러나 Step Functions Task state, CloudWatch trace, harness execution role, AgentCore Browser ARN은 AWS operational plane에 붙어 있습니다. LangGraph나 CrewAI로 만든 agent graph를 이미 운영 중인 팀은 어느 부분을 AgentCore harness로 옮기고 어느 부분은 기존 orchestrator에 남길지 판단해야 합니다.

이 발표를 개발자 관점에서 읽는 가장 좋은 방법은 “에이전트가 더 똑똑해졌다”가 아닙니다. 변화는 에이전트 실행이 배치될 장소입니다. AWS는 reasoning step을 Step Functions라는 오래된 workflow primitive 안에 넣었습니다. 그 결과 agent step은 approval, retry, branch, execution history, token usage, CloudWatch trace와 같은 운영 언어로 설명됩니다. 앞으로 enterprise agent 플랫폼 경쟁은 모델 이름보다 agent action을 업무 절차와 감사 체계에 얼마나 낮은 위험으로 연결하는지에 걸릴 수 있습니다.

출처:

• AWS What’s New
• Step Functions AgentCore integration documentation
• AgentCore harness documentation
• AWS Step Functions product page