Building ambient agents with Amazon Bedrock AgentCore: From event-driven signals to human-in-the-loop workflows

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock AgentCore 기반 앰비언트 에이전트는 인프라 이벤트를 작업으로 연결하고, 필요할 때 ask_human으로 사람의 입력을 기다린 뒤 실행을 이어가는 서버리스 패턴이다.

📌 핵심 요약

• 앰비언트 에이전트는 파일 업로드, 데이터베이스 변경, 예약 작업, 시스템 알림 같은 이벤트에 반응하며 여러 이벤트를 병렬로 처리할 수 있다. 사람이 대화를 시작해야 하는 채팅형 에이전트의 한계를 보완하고, 명확화·승인·검토가 필요할 때 사람을 개입시킨다.
• Amazon Bedrock AgentCore Runtime은 컨테이너 기반 실행, 장시간 작업, 세션 격리, Amazon Bedrock 기반 모델 연동을 제공한다. 참조 구현은 각 에이전트 턴을 Lambda의 15분 제한 안에서 실행하며, AWS Lambda와 Amazon DynamoDB를 결합해 서버리스 플랫폼을 구성한다.
• 앰비언트 신호는 이벤트 소스를 에이전트에 연결한다. 기본값인 autoExecute: false는 작업을 idle 상태로 만들어 사람이 검토하고 실행하게 하며, autoExecute: true는 즉시 작업 큐에 넣는다. 참조 샘플은 Amazon S3 업로드와 예약 이벤트를 제공하고, API 웹훅과 데이터베이스 변경은 확장 지점으로 남긴다.
• 사람과의 상호작용은 단일 ask_human 도구와 표준 응답 형식으로 처리한다. completed·interrupted·error 상태는 각각 result·question·error 필드에 대응하며, 중단된 작업은 requiresAction: true로 표시된다. Jobs 화면에서 질문, 승인 대기, 최종 결과, 실패를 함께 확인한다.
• 이벤트 파이프라인은 Amazon S3, Signal Processor Lambda, Amazon DynamoDB 작업 기록, Amazon SQS, Job Execution Lambda, AgentCore Runtime으로 이어진다. Scheduler는 1분 간격으로 실행되며, 배포 전에는 us-east-1 기본 설정, AWS CDK v2, Docker, Python 3.11 이상, Node.js 18 이상, 대상 리전의 Anthropic Claude Sonnet 4.5 접근 권한 등을 준비해야 한다.

🧩 주요 포인트

1. 이벤트 기반 실행과 사람의 선택적 개입 → 수동 분류 부담을 줄이면서 모호한 상황과 승인 필요 작업을 처리하는 구조.
2. autoExecute 기본값과 ask_human 중단·재개 → 실행 전 검토와 실행 중 검토를 구분하고, 작업별 개입 수준을 조절하는 설계.
3. Amazon SQS의 실행 분리와 표준 응답 형식 → 서로 다른 이벤트와 상호작용을 공통 작업 흐름에 연결하되, 15분 턴 제한과 확장 지점을 고려해야 하는 구현.

🧠 상세 정리

1. 수동 분류와 채팅 중심 에이전트의 한계

문서를 대량으로 처리하는 팀에서는 파일이 저장소에 도착하면 사람이 이를 발견하고, 하나씩 열어 필요한 처리를 판단한 뒤 검토 대상으로 전달하는 일이 반복된다. 모니터링 알림도 사람이 대응할 때까지 쌓이므로, 글은 이러한 수동 분류에 소비되는 시간을 앰비언트 에이전트가 해결할 운영 문제로 제시한다. 도입부에서는 Amazon S3 버킷에 문서가 들어온 뒤 수초 안에 Jobs 페이지에 작업이 나타나고, 설정에 따라 실행 준비 상태이거나 이미 실행 중인 상황을 예로 든다. 에이전트는 파일을 분석하고 결과를 제시하며 다음 단계에 앞서 승인을 요청할 수 있으므로, 이벤트 자체가 프롬프트 역할을 한다. 반면 일반적인 채팅형 에이전트는 사용자가 화면을 열고 상황을 설명해야 작동하며, 글은 이 방식이 인프라 전반에서 발생하는 이벤트에 대응하는 데 한계가 있다고 설명한다.

2. 이벤트 기반 실행과 사람의 개입

사용자 주도 에이전트가 사용자·프롬프트·에이전트·응답의 요청과 응답 흐름을 따른다면, 앰비언트 에이전트는 이벤트·신호·에이전트·선택적 사람 개입·행동의 흐름을 따른다. 글은 LangChain 등을 통해 설명된 이 패러다임에서 에이전트가 이벤트 스트림을 듣고 여러 이벤트에 병렬로 대응할 수 있다고 소개한다. 다만 운영 환경에서는 에이전트가 언제 사람에게 명확화, 승인, 검토를 요청할지 신중하게 설계해야 하며, 사람의 개입은 배포 부담을 낮추고 신뢰와 피드백을 통한 개선을 돕는 요소로 제시된다. AWS 환경에는 이미 Amazon S3 이벤트 알림, Amazon EventBridge 규칙, AWS Lambda 트리거, Amazon DynamoDB 스트림 같은 기반이 존재한다. 글은 AWS Step Functions 같은 자동화 파이프라인은 모호성을 추론하거나 추가 질문을 하기 어렵고, 채팅형 에이전트는 사람이 시작해야 하므로, 앰비언트 에이전트가 두 방식 사이의 공백을 연결한다고 주장한다.

3. AgentCore Runtime과 배포 준비 조건

Amazon Bedrock AgentCore는 다양한 프레임워크와 모델로 에이전트를 구축·연결·최적화하는 플랫폼으로 소개되며, AgentCore Runtime은 컨테이너 호스팅, 장시간 워크로드, 세션 격리와 Amazon Bedrock 기반 모델 연동을 제공한다. Runtime의 세션은 신호 발생부터 사람 개입까지의 흐름을 지원하지만, 참조 구현의 각 에이전트 턴에는 Lambda의 15분 제한을 적용하며 글은 이를 실무상 충분한 여유라고 평가한다. 배포에는 IAM 역할과 Lambda, DynamoDB, S3, SQS, API Gateway, CloudFront, Cognito, ECR, AgentCore Runtime을 생성할 권한이 필요하고, 샌드박스 계정의 관리자 접근을 출발점으로 제안한다. AWS CLI에는 계정 자격 증명과 샘플 기본 리전인 us-east-1을 설정하고, AWS CDK v2를 설치해 해당 계정과 리전에서 부트스트랩해야 한다. 로컬 Docker가 실행 중이어야 하며, 백엔드와 에이전트 빌드에는 Python 3.11 이상, React 프런트엔드에는 Node.js 18 이상이 필요하다. 대상 리전에서 Anthropic Claude Sonnet 4.5에 접근할 수 있어야 하고, 모델 지원 여부는 리전마다 다르므로 확인이 필요하며, 이후 모델 변경은 한 줄의 설정 변경으로 가능하다고 설명한다.

4. 앰비언트 신호와 자동 실행 설정

앰비언트 신호는 특정 이벤트 소스를 에이전트에 연결하는 설정이며, 이벤트가 발생하면 플랫폼이 해당 에이전트의 작업을 자동으로 만든다. 이후 작업을 언제 실행할지는 신호의 autoExecute 설정에 따라 달라지고, 기본값인 autoExecute: false에서는 Jobs 페이지에 idle 상태로 나타나 사람이 검토하고 실행할 때까지 기다린다. 글은 입력을 미리 알 수 없거나 에이전트가 중요한 결과를 초래할 도구를 사용할 수 있을 때 이 검토 우선 흐름이 적합하다고 설명한다. autoExecute: true에서는 Signal Processor가 작업을 곧바로 워커 큐에 넣어 에이전트가 즉시 실행되며, 실행 중 ask_human을 호출한 경우에만 사람을 개입시킨다. 따라서 자동 실행 설정은 작업 시작 전의 사람 검토 여부를 결정하고, ask_human은 실행 도중 필요한 판단을 요청하는 수단으로 작동한다.

5. 샘플이 제공하는 이벤트와 확장 범위

참조 샘플이 기본 제공하는 이벤트 소스는 Amazon S3 파일 업로드와 예약 이벤트의 두 종류다. Amazon S3 업로드는 지정한 버킷과 접두사에 파일이 들어왔을 때 에이전트를 실행하는 방식이며, 예약 이벤트는 cron과 유사한 일정에 따라 작업을 시작한다. 다만 예약 이벤트는 Signals 페이지의 신호 정의가 아니라 jobType: "scheduled"를 가진 작업으로 구동된다는 차이가 있다. 외부 시스템의 알림을 받는 API 웹훅과 Amazon DynamoDB 스트림 또는 Amazon RDS 이벤트에 반응하는 데이터베이스 변경은 기본 제공 기능이 아니라 확장 지점으로 제시된다. 글은 이러한 소스를 추가하려면 새로운 핸들러 Lambda 함수와 Signals 페이지의 대응 입력 필드를 작성해야 한다고 설명하므로, 이벤트 기반 패턴의 적용 가능성과 샘플에 이미 구현된 범위를 구분할 필요가 있다.

6. 단일 ask_human 도구와 표준 응답 계약

사람과의 구조화된 상호작용은 단일 ask_human 도구와 표준 응답 형식으로 표현되며, 상태별로 어떤 정보를 반환할지가 정해져 있다. status가 completed이면 result, interrupted이면 question, error이면 error 필드가 대응하므로, 플랫폼은 공통 형식으로 완료·질문·실패를 처리할 수 있다. 플랫폼은 모든 응답에 session_id와 job_id도 전달해 후속 턴을 기존 실행과 연결하지만, 글은 이 값들이 에이전트가 구현해야 하는 핵심 계약이 아니라 상관관계 메타데이터라고 명시한다. 에이전트가 interrupted를 반환하면 작업 상태도 interrupted로 바뀌고 requiresAction이 true로 설정되어 사람의 응답이 필요한 상태임을 나타낸다. 사람의 답변이 도착하면 에이전트는 중단했던 지점에서 실행을 이어가므로, 질문과 승인을 별개의 작업으로 흩뜨리지 않고 기존 실행 흐름에 연결한다.

7. Jobs 화면과 상호작용 패턴의 통합

참조 React 프런트엔드는 사람의 응답이 필요한 작업을 Jobs 페이지의 Interrupted 탭에 표시하고, 각 행의 경고 표시로 개입 필요성을 알린다. 같은 화면에서 대기 중인 질문, 승인받아야 할 제안, 최종 결과와 실패한 작업을 볼 수 있으므로, 별도의 검토 큐를 확인하거나 여러 채팅 창과 이메일 대화를 살필 필요를 줄인다. 글은 결과를 알리는 Notify, 명확화를 요청하는 Question, 행동을 제안하고 APPROVE·REJECT·MODIFY를 기다리는 Review, 실패를 기록하고 사람이 재시도 여부를 판단하는 Error 패턴을 설명한다. 이 구분은 에이전트가 질문이나 결과를 작성하는 관례이며, 각각 독립된 런타임 모드가 있는 것은 아니다. 플랫폼 수준에서는 하나의 코드 경로와 하나의 응답 형식으로 이들을 처리하고, 사람과의 상호작용을 단일 ask_human 도구에 연결한다.

8. 서버리스 이벤트 파이프라인의 구성

Amazon S3의 s3:ObjectCreated 알림을 받은 Signal Processor Lambda는 ambient-signals 테이블의 글로벌 보조 인덱스인 GSI를 조회해 이벤트 버킷에 맞는 신호를 찾고, 일치하는 신호마다 작업 기록을 생성한다. API 계층이나 스케줄러가 Amazon SQS에 작업을 넣으면, Job Execution Lambda는 연결된 SQS 이벤트 소스로 큐를 소비하고 작업 맥락을 전달해 AgentCore Runtime을 호출한다. 이 Lambda는 API 요청을 받아 메시지를 큐에 넣는 경로도 담당하며, 실행 결과와 사람 입력 요청은 Amazon DynamoDB에 기록된다. Amazon SQS는 API Gateway 요청과 에이전트 호출을 분리하고, 설정된 재시도 횟수 이후에도 처리하지 못한 메시지는 데드레터 큐인 DLQ에 보관한다. S3 알림 설정에는 접두사와 접미사 필터를 적용해 관련 가능성이 있는 이벤트만 Signal Processor를 호출하게 하며, S3와 CloudFront로 제공되는 React 화면은 API Gateway와 Lambda 계층을 폴링해 상태를 갱신하고 사용자 응답을 받는다. 제공된 본문은 Scheduler가 1분 간격의 cron으로 실행되어 실행 시점이 된 예약 작업을 큐에 넣는다는 설명에서 끝나므로, 이후 구성과 구현 세부사항은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• autoExecute와 ask_human은 서로 다른 시점의 통제 수단이다. 전자는 실행을 시작하기 전의 검토 여부를 정하고, 후자는 실행 중 모호성이나 승인 필요성을 처리한다.
• 단일 도구와 표준 응답 형식은 사람 개입의 종류가 늘어나더라도 플랫폼의 처리 경로를 공통으로 유지하는 설계다. Notify·Question·Review·Error는 별도 런타임 기능보다 에이전트의 표현 관례에 가깝다.
• 이벤트 기반 인프라와 추론 가능한 에이전트를 연결하는 것이 핵심이지만, 참조 샘플의 제공 범위는 Amazon S3와 예약 이벤트에 한정된다. API 웹훅과 데이터베이스 변경을 적용하려면 추가 구현이 필요하다.

✅ 액션 아이템

• Amazon S3 업로드 작업의 실행 전 검토 필요성에 따라 autoExecute: false 또는 autoExecute: true 선택 검토.
• ask_human의 중단·재개와 completed·interrupted·error 응답을 Jobs 화면의 질문·승인·실패 처리에 연결하는 방식 확인.
• 배포 전 us-east-1 설정, Anthropic Claude Sonnet 4.5 접근 권한, Python 3.11 이상·Node.js 18 이상 및 15분 턴 제한 충족 여부 확인.

❓ 열린 질문

• Amazon S3 업로드 작업 중 어떤 입력이나 승인 필요 작업에 autoExecute: false를 적용해야 하는가?
• ask_human이 명확화·승인·검토를 요청해야 하는 조건은 무엇인가?
• 15분 턴 제한과 API 웹훅·데이터베이스 변경의 확장 범위가 목표 작업에 어떤 제약을 주는가?