Asynchronous patterns for calling Amazon Bedrock AgentCore agents in serverless pipelines

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

에이전트의 긴 처리 시간 동안 호출자 컴퓨팅을 점유하지 않도록 대기를 오케스트레이션 계층에 맡기면, 서버리스 파이프라인의 유휴 비용을 줄이면서 결과 수신 후 작업을 이어갈 수 있다.

📌 핵심 요약

• 에이전트 응답 시간은 프롬프트, 모델, 문서에 따라 달라지며, 동기 호출을 수행한 람다 함수나 컨테이너는 응답을 기다리는 동안에도 전체 컴퓨팅 자원을 점유하고 비용이 발생한다.
• Amazon Bedrock AgentCore 런타임은 모델 생성이나 도구 호출을 기다릴 때 메모리 비용은 부과하지만 유휴 CPU 비용은 부과하지 않으므로, 핵심 낭비 지점은 에이전트가 아니라 차단된 호출자이다.
• 예시 파이프라인은 추출, 식별, 경로 선택, 문서 정리·검증, 결과 처리의 다섯 단계로 구성되며, 네 가지 접근법에서 에이전트를 호출하는 검증 분기만 교체한다.
• 태스크 토큰 콜백 패턴은 디스패처 함수를 짧게 실행한 뒤 Step Functions를 일시 정지하고, 직접 서비스 통합 패턴은 디스패처 함수 없이 Step Functions가 AgentCore를 직접 호출한다.
• 람다 내구성 함수 패턴은 파이프라인을 코드로 표현하면서 콜백 대기 중 실행을 중단하므로, 에이전트가 처리되는 동안 함수 컴퓨팅 비용을 부과하지 않는다.

🧩 주요 포인트

1. 동기 호출은 구현이 단순하지만 호출자의 과금 시간이 에이전트 처리 시간과 거의 같아지므로, 긴 추론 지연이 그대로 유휴 컴퓨팅 비용으로 이어진다.
2. 태스크 토큰이나 직접 서비스 통합을 사용하면 대기 책임이 Step Functions로 이동하므로, 람다 실행 시간을 짧은 디스패치 구간으로 제한하거나 람다 자체를 호출 경로에서 제거할 수 있다.
3. 내구성 함수는 상태 머신 대신 하나의 코드 흐름으로 단계를 구성하면서도 콜백 대기 중 실행을 중단하므로, 코드 중심 오케스트레이션과 비차단 비용 구조를 함께 제공한다.

🧠 상세 정리

1. 에이전트 지연이 만드는 호출 비용 문제

에이전트는 전통적인 파이프라인 단계와 달리 답을 내기 전에 일정 시간 추론하며, 처리 시간은 프롬프트와 모델, 입력 문서에 따라 달라진다. 가장 흔한 초기 구현은 람다 함수 같은 컴퓨팅 서비스가 에이전트를 동기 호출한 뒤 응답이 올 때까지 기다리는 방식인데, 이 시간 동안 함수는 실질적인 작업을 하지 않더라도 계속 실행 중인 것으로 간주된다. AgentCore 런타임은 대규모 언어 모델의 응답이나 도구·모델 컨텍스트 프로토콜 호출을 기다릴 때 메모리 비용은 발생하지만 유휴 CPU에는 비용을 부과하지 않는 소비 기반 구조를 사용한다. 반면 호출자인 람다 함수, 컨테이너 또는 EC2 인스턴스는 열린 연결을 유지하며 할당된 컴퓨팅 자원의 비용을 계속 부담하므로, 낭비의 중심은 에이전트보다 차단된 호출자에 있다. 따라서 해결 방향은 에이전트 작업을 시작한 직후 호출자 컴퓨팅을 해제하고, 결과가 준비됐을 때만 파이프라인을 재개하는 것이다.

2. 비교에 사용된 문서 검증 파이프라인

글은 부동산 금융 업무에서 문서를 검증하는 단순한 가상 파이프라인을 네 가지 호출 방식에 공통으로 적용해 차이를 비교한다. 추출 단계에서는 람다 함수가 광학 문자 인식과 텍스트 추출을 수행하며, 실제 문서 없이도 실행할 수 있도록 추출 과정은 모의 처리된다. 식별 단계는 문서 유형을 분류하고 정리 및 검증 여부를 나타내는 라우팅 플래그를 설정하며, 경로 선택 단계의 Choice 상태가 이 플래그에 따라 흐름을 나눈다. 이후 Parallel 상태에서 한 분기는 문서를 정리하고 다른 분기는 AgentCore 에이전트로 문서를 검증하며, 마지막 결과 단계가 에이전트의 판정을 바탕으로 승인 또는 수정 요청을 결정한다. 모든 비교에서 전체 파이프라인은 그대로 유지되고, 정리 작업과 병렬로 실행되는 검증 분기의 에이전트 호출 방식만 바뀐다.

3. 하나의 에이전트가 여러 반환 방식을 처리하는 구조

네 가지 접근법은 모두 동일한 AgentCore 에이전트를 사용하며, 에이전트는 호출 입력에 포함된 신호를 검사해 결과 반환 방식을 결정한다. Step Functions 태스크 토큰이 있으면 해당 토큰으로 실행을 깨우고, 내구성 함수의 콜백 식별자가 있으면 그 식별자를 통해 중단된 함수를 재개하며, 두 값이 모두 없으면 판정을 동기 응답으로 돌려준다. 판정 도구는 승인 여부, 문제 목록, 요약, 출처를 포함하는 결과 객체를 만들고, 태스크 토큰이 있는 경우 SendTaskSuccess를 호출해 Step Functions에 결과를 전달한다. 콜백 식별자가 있으면 SendDurableExecutionCallbackSuccess를 호출하며, 비동기 신호가 없는 호출에서는 결과를 인라인으로 처리한다. 진입점 역시 토큰이나 콜백 식별자가 있으면 백그라운드 작업을 시작한 뒤 즉시 수락 상태를 반환하고, 그렇지 않으면 에이전트 실행이 끝날 때까지 기다리므로 오케스트레이션 방식을 바꿔도 에이전트를 다시 배포할 필요가 없다.

4. 기준선인 차단 호출 안티패턴

차단 방식은 람다 함수가 InvokeAgentRuntimeCommand를 보내고 에이전트 응답을 같은 호출 안에서 기다리는 가장 직접적인 구현이다. 구조가 단순하고 정상적으로 작동하기 때문에 흔히 사용되지만, 에이전트가 추론하는 전체 시간 동안 함수가 살아 있으며 할당된 컴퓨팅 자원에 대한 비용도 계속 발생한다. 이 방식에서는 함수의 청구 실행 시간이 에이전트의 실제 처리 시간과 거의 같아져, 에이전트 응답이 길어질수록 호출자의 유휴 비용도 함께 증가한다. 에이전트 런타임 측에서 유휴 CPU 과금을 피하더라도 호출 람다가 열린 연결을 유지하는 비용은 사라지지 않으므로, 런타임 한쪽의 효율만으로 전체 파이프라인 비용을 최적화할 수 없다. 글은 이 접근법을 기준선이자 안티패턴으로 두고, 이후 세 방식이 호출자의 대기 비용을 어떻게 제거하는지 비교한다.

5. 패턴 1: 태스크 토큰과 디스패처 함수

태스크 토큰 패턴은 사용자 정의 호출 로직을 위해 람다 함수를 경로에 남겨두되, 에이전트 응답을 기다리는 유휴 실행 시간은 제거한다. Step Functions가 waitForTaskToken 통합으로 디스패처 함수를 호출하면서 태스크 토큰을 전달하면, 함수는 이 토큰을 에이전트 요청에 포함해 작업을 시작하고 몇 초 안에 반환한다. 함수가 반환되어도 해당 단계가 완료되는 것은 아니며, Step Functions 실행은 에이전트가 같은 토큰으로 SendTaskSuccess를 호출할 때까지 일시 정지된 상태를 유지한다. 예시 상태 정의는 최대 120초의 제한 시간과 60초의 하트비트를 설정해, 에이전트가 응답하지 않을 때 실행이 무기한 대기하지 않고 명확하게 실패하도록 한다. 비용은 짧은 디스패치 실행에만 발생하고 이후 대기는 유휴 컴퓨팅 비용을 부과하지 않는 Step Functions가 보유하므로, 함수 비용이 에이전트 처리 시간에 비례하지 않는다.

6. 패턴 2: Step Functions 직접 서비스 통합

에이전트 호출 전후에 별도의 사용자 정의 코드가 필요하지 않다면 디스패처 함수를 제거하고 Step Functions가 AgentCore를 직접 호출할 수 있다. 제시된 ValidateDirect 상태는 AWS SDK 서비스 통합의 invokeAgentRuntime 작업을 사용하며, 에이전트 런타임 식별자와 실행 식별자를 해시한 세션 값, JSON 문자열로 변환한 입력을 전달한다. 에이전트 응답은 ResultSelector를 통해 다음 판정 파싱 상태로 전달되고, 작업에는 120초의 제한 시간이 적용된다. 이 구성에서는 람다 함수가 호출 경로에 존재하지 않으므로 에이전트 응답을 기다리는 람다 컴퓨팅 비용 자체가 발생하지 않는다. 대기는 Step Functions가 담당하며 Standard 워크플로는 대기 시간에 따른 컴퓨팅 사용량이 아니라 상태 전환을 기준으로 과금되므로, 처리 중 의미 있는 실행 비용은 주로 에이전트 측에 남는다.

7. 패턴 3: 람다 내구성 함수

상태 머신 대신 한곳의 코드로 전체 오케스트레이션을 표현하려는 경우에는 람다 내구성 함수를 사용할 수 있다. 자바스크립트용 내구성 실행 SDK에서 파이프라인 단계는 context.step 호출로, 병렬 작업은 context.parallel로, 에이전트 결과 대기는 context.waitForCallback으로 구성된다. 검증 단계는 콜백 식별자를 받아 AgentCore 작업을 디스패치한 뒤 최대 120초 동안 중단되며, 에이전트가 SendDurableExecutionCallbackSuccess를 호출하면 전달된 결과로 실행을 재개한다. 이 대기 동안 함수는 활성 컴퓨팅을 계속 점유하지 않으므로 컴퓨팅 비용도 부과되지 않는다. 하나의 함수가 전체 파이프라인 흐름을 보유하지만 실제 과금은 중단 사이에 코드를 실행하는 짧은 구간에 집중되어, 태스크 토큰 방식과 유사한 비차단 비용 구조를 만든다.

8. 세 가지 비동기 패턴의 차이와 공통 효과

세 비동기 패턴의 공통점은 에이전트가 추론하는 동안 호출자 컴퓨팅을 계속 실행하지 않고, 결과가 준비됐을 때만 중단된 흐름을 재개한다는 점이다. 태스크 토큰 방식은 디스패처 함수에 사용자 정의 로직을 유지하면서 람다 실행을 짧게 제한하고, 직접 서비스 통합은 그러한 코드가 필요하지 않을 때 람다를 호출 경로에서 완전히 제거한다. 내구성 함수는 상태 머신 정의 대신 단계와 병렬 처리, 콜백 대기를 하나의 코드 흐름으로 작성하면서 대기 중 실행을 중단한다. 반대로 차단 방식은 에이전트 처리 시간 전체를 호출자 실행 시간으로 만들기 때문에 네 접근법 중 유일하게 호출자의 비용이 추론 지연을 직접 따라간다. 동일한 에이전트가 태스크 토큰과 콜백 식별자의 존재 여부에 따라 반환 경로를 선택하므로, 각 방식의 차이는 에이전트 자체보다 오케스트레이션과 호출 계층에 집중된다.

🧾 핵심 주장 / 시사점

• 비용 최적화의 핵심은 에이전트 실행 시간을 단축하는 것이 아니라, 에이전트가 처리되는 동안 호출자가 열린 연결과 컴퓨팅 자원을 점유하지 않도록 과금 경계를 분리하는 데 있다.
• 태스크 토큰과 콜백 식별자를 입력 신호로 사용하면 하나의 에이전트가 Step Functions, 내구성 함수, 동기 호출을 모두 지원할 수 있어 에이전트와 오케스트레이션 방식을 분리할 수 있다.
• 사용자 정의 디스패치 로직이 필요하면 태스크 토큰, 별도 코드가 필요 없으면 직접 통합, 파이프라인을 코드로 통합하려면 내구성 함수를 사용할 수 있으며 세 방식 모두 대기 중 호출자 컴퓨팅 비용을 피한다.

✅ 액션 아이템

• 동기 호출을 쓰는 람다 또는 컨테이너는 에이전트 응답 대기 동안 과금을 점유하므로, 파이프라인 5단계의 추출·식별·경로 선택 구간에서 동기 블록을 줄인다.
• 태스크 토큰 콜백 패턴으로 디스패처 함수를 짧게 두고 Step Functions가 대기를 맡아 Amazon Bedrock AgentCore 호출을 오케스트레이션 계층으로 이관한다.
• 직접 서비스 통합 패턴과 람다 내구성 함수 패턴을 비교해 검증 분기를 교체하고, 콜백 대기를 Step Functions·코드 흐름에 맡겨 유휴 CPU 과금을 줄인다.

❓ 열린 질문

• 태스크 토큰 콜백 패턴에서 Step Functions가 대기할 때 디스패처 함수의 최대 실행 시간은 어느 값이 적절한가?
• 직접 서비스 통합 패턴으로 Amazon Bedrock AgentCore를 호출할 때 Step Functions의 Timeout·재시도 임계값은 어떻게 둘 것인가?
• 내구성 함수 패턴 사용 시 긴 추론 지연에서 파이프라인 결과 처리 단계의 병목은 어떤 지표로 판단할 것인가?