Build autonomous AI agents with Amazon Bedrock and Spring AI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock과 Spring AI를 결합해 Java 기반 자율 에이전트를 구현하고, Amazon Bedrock AgentCore의 운영 인프라를 활용하는 방법을 여행 도우미와 다중 에이전트 문서 처리 사례로 설명한다.

📌 핵심 요약

• Spring AI는 자동 구성, 의존성 주입, 조합 가능한 어드바이저 등 익숙한 Spring 패턴으로 AI 기능을 제공하며, Amazon Bedrock AgentCore는 프레임워크와 모델에 종속되지 않는 관리형 런타임, 메모리, 브라우저 자동화, 코드 실행, ID 관리 기능을 제공한다.
• 원문은 에이전트를 계획, 도구 사용, 메모리를 결합해 목표 지향적 반복을 수행하는 시스템으로 설명하고, 검색이라는 제한된 도구 사용은 있지만 계획 루프가 없는 RAG 애플리케이션과 구분한다.
• 권장 출발점인 여행 도우미는 단일 Spring Boot 애플리케이션에서 날씨 조회와 일정 검색, SSE 스트리밍, 세션 내 단기 메모리와 세션 간 장기 메모리를 결합한다.
• IDP 시스템은 Lawyer, Mortgage, Insurance, Tax, General의 다섯 전문 에이전트와 분류기, SpEL 규칙 엔진, AlertService를 결합한다. 기본 구현은 라우터와 평가자 패턴을 사용하고 배치 문서를 순차 처리하며, 병렬 팬아웃은 선택적 확장이다.
• AgentCore 런타임은 POST /invocations와 GET /ping을 요구하며, @AgentCoreInvocation이 엔드포인트 구성과 JSON·SSE 처리를 자동화한다. 장기 실행 작업은 HealthyBusy 상태를 알려야 하고, 여러 인수를 사용하는 도구 호출에는 블로킹 call()로 응답을 완성한 뒤 청크로 나누어 스트리밍하는 방식을 권고한다.

🧩 주요 포인트

1. 기존 JVM 개발 관행과 AgentCore 운영 기능의 결합 → Java 팀이 익숙한 Spring 개발 방식을 유지하면서 에이전트 배포와 운영에 필요한 인프라를 활용하는 접근이다.
2. IDP의 전문 에이전트·SpEL 규칙·사람 검토 분리 → 문서 추출 결과를 업무 규칙과 신뢰도에 따라 후속 처리하며, 병렬 팬아웃의 지연 시간 이점은 선택적 확장을 적용할 때의 효과다.
3. 런타임 상태 보고와 도구 인수 바인딩 제약 → 장기 작업의 축소 위험과 다중 인수 도구 호출의 신뢰성을 고려해 상태 관리 및 스트리밍 방식을 설계해야 한다.

🧠 상세 정리

1. Java 팀의 운영 과제와 제안하는 접근

원문은 Java 팀이 JVM 도구, CI/CD 파이프라인, 운영 경험과 개발 패턴을 이미 갖추고 있어도 AI 에이전트를 시제품에서 운영 환경으로 옮기는 일은 어렵다는 문제에서 출발한다. 에이전트 프레임워크만으로는 확장성, 거버넌스, 보안과 운영 문제가 기본적으로 해결되지 않으며, 이를 보완하는 조합으로 Amazon Bedrock과 Spring AI를 제시한다. Spring AI는 자동 구성, 의존성 주입, 조합 가능한 어드바이저를 통해 REST API, 보안, 데이터 접근에 사용하던 Spring 개발 방식을 AI 구현으로 이어 준다. Amazon Bedrock AgentCore는 특정 프레임워크나 기반 모델에 종속되지 않고 관리형 런타임, 메모리, 브라우저 자동화, 코드 실행과 ID 관리 기능을 제공한다. 글은 spring-ai-agentcore를 사용한 Java 구현을 중심으로 단일 여행 도우미와 다중 에이전트 문서 처리 시스템의 핵심 패턴을 설명한다.

2. 에이전트의 세 가지 능력과 참조 처리 흐름

원문은 에이전트의 핵심을 계획, 도구 사용, 메모리의 결합으로 정의한다. 계획은 목표를 단계로 나누고 우선순위를 정하며 새로운 정보에 따라 수정하는 능력이고, 도구 사용은 API, 데이터베이스, 코드 인터프리터 같은 외부 기능을 선택하고 호출하는 능력이다. 메모리는 대화 차례 사이의 단기 맥락과 세션 사이의 장기 맥락을 유지하며, 세 능력은 작업을 끝내거나 더 진행할 수 없다고 판단할 때까지 목표 지향적 반복 안에서 작동한다. 이 설명에서 RAG 애플리케이션은 검색이라는 제한된 도구 사용은 있지만 계획 루프가 없는 것으로 구분된다. 11단계 참조 파이프라인은 문서와 질문을 받아 인증·요청 제한, 입력 가드레일, 분류와 전문 에이전트 처리를 거쳐 근거에 기반한 답변을 반환하며, 신뢰도가 낮거나 표시된 결과는 사람 검토로 보낸다. 복원력, 관측 가능성, 로깅과 최소 권한 IAM은 전체 단계에 적용되는 공통 관심사다.

3. 실행 환경과 두 시스템의 공통 기반

실습의 선행 조건은 JDK 21, Spring Boot 4.1과 Spring AI 2.0 및 spring-ai-agentcore 2.0, Maven 3.9+, React 프런트엔드용 Node.js 18+, Terraform 1.5+다. 여기에 다중 아키텍처 빌드를 위한 Buildx가 포함된 Docker, 자격 증명이 구성된 AWS CLI v2와 AWS 계정이 필요하다. 두 시스템은 Spring Boot 애플리케이션, Spring AI ChatClient, spring-ai-agentcore와 Amazon Bedrock Converse API를 공통 기반으로 사용한다. AgentCore 런타임 계약으로 관리형 배포에 연결하고, AgentCore 메모리로 단기 및 장기 맥락을 제공하며, @Tool이 붙은 메서드로 도구를 호출한다. 구조화된 출력은 Java 레코드에 매핑하고, AWS Graviton에 최적화된 ARM64 컨테이너 이미지와 모듈식 Terraform을 배포 및 인프라 구성에 활용한다.

4. 단일 에이전트 여행 도우미의 작동 방식

여행 도우미는 글에서 권장하는 시작점으로, 날씨 조회와 일정 검색 도구, 스트리밍 응답, 대화 메모리 및 복원력 패턴을 하나의 자율 에이전트에 결합한다. 단일 Spring Boot 애플리케이션은 React UI용 REST 엔드포인트와 AgentCore 런타임이 요구하는 /invocations 및 /ping 엔드포인트를 함께 제공한다. Spring AI는 Converse API를 통해 Amazon Bedrock 호출을 조율하고, 모델이 요청한 도구 실행은 같은 프로세스 안에서 처리한다. 응답 토큰은 생성되는 대로 Server-Sent Events를 통해 클라이언트에 전달되어 대화 UI에서 스트리밍 응답을 표시할 수 있다. AgentCore 메모리는 세션 안의 단기 맥락과 세션을 넘는 장기 맥락을 제공하므로, 원문은 별도의 외부 상태 관리 없이 대화 이력을 유지하는 구조로 설명한다.

5. IDP 시스템의 전문화와 규칙 기반 후속 처리

IDP 시스템은 Lawyer, Mortgage, Insurance, Tax, General의 다섯 전문 에이전트로 문서를 처리하며, 각 에이전트는 공통 AbstractDocumentAgent 템플릿을 기반으로 구현된다. ClassifierAgent는 문서를 읽고 적합한 전문 에이전트로 전달하며, 전문 에이전트는 Amazon Bedrock의 멀티모달 Converse API를 사용해 신뢰도 점수가 포함된 구조화 JSON을 추출한다. 이어 규칙 엔진이 application.yml에 정의된 Spring Expression Language, 즉 SpEL 표현식을 추출 결과에 적용한다. ALERT 또는 BLOCK 심각도의 규칙이 발동하면 AlertService를 통해 후속 알림과 사람 검토로 연결되고, 신뢰도가 낮은 문서도 사람 검토 대상으로 보낸다. 지표, 감사 추적, 복원력과 관측 가능성은 모든 단계에 적용되며, 이 사례는 단일 에이전트에서 확장된 전문 역할 분담과 운영 패턴을 보여 준다.

6. 라우터·평가자 패턴과 선택적 병렬 팬아웃

원문은 여러 에이전트가 협업할 때 조정 방식이 시스템 동작을 결정한다고 설명하고, 라우터와 평가자를 기본 구현 패턴으로 제시한다. 라우터는 문서 유형 메타데이터를 살펴 다섯 전문 에이전트 중 하나로 요청을 전달하는 경량 계층이며, 자체 도메인 로직은 보유하지 않는다. 평가자는 전문 에이전트의 결과를 구성 가능한 업무 규칙과 대조하고, ALERT 또는 BLOCK이 발생하면 교체 가능한 AlertService를 통해 사람 검토로 연결한다. 기본 배치 엔드포인트는 문서를 순차 처리하므로, 여러 전문가에게 동시에 요청하는 병렬 팬아웃은 이미 구현된 기본 동작이 아니라 선택적으로 추가하는 확장이다. 병렬 팬아웃을 적용하면 전문 에이전트들의 결과를 모은 뒤 규칙 엔진을 실행하며, 원문은 결합 분석의 경과 시간이 각 호출 시간의 합이 아니라 가장 느린 단일 에이전트 호출에 의해 제한된다고 설명한다.

7. AgentCore 런타임 계약과 SDK의 역할

Amazon Bedrock AgentCore 런타임은 에이전트의 수명 주기와 확장을 관리하고, 요청을 에이전트로 전달하며 상태를 감시한다. 애플리케이션은 JSON 또는 SSE 응답을 반환하는 POST /invocations와 Healthy 또는 HealthyBusy 상태를 보고하는 GET /ping을 제공해야 한다. 장기 실행 작업은 바쁜 상태임을 알려야 하며, 이를 알리지 않으면 런타임이 에이전트를 축소할 수 있다는 운영상 주의점이 제시된다. Spring AI AgentCore SDK의 @AgentCoreInvocation은 이 엔드포인트 계약을 자동 구성하고 JSON 직렬화, SSE 프레이밍 및 상태 보고를 처리한다. SDK는 애플리케이션의 ChatClient, @Tool 콜백과 메모리·가드레일 어드바이저를 AgentCore 런타임, 메모리, Browser, Code Interpreter, Evaluations 기능에 연결해 표준 Spring AI 코드와 운영 인프라 사이를 잇는다.

8. 최소 구현 예제와 스트리밍의 주의점

제시된 최소 TravelAgent 예제는 Spring 서비스에서 ChatClient.Builder로 ChatClient를 만들고, @AgentCoreInvocation이 붙은 chat 메서드가 PromptRequest를 받아 Flux<String>을 반환하는 구조다. 메서드는 요청의 프롬프트를 사용자 입력으로 전달한 뒤 stream().content()로 모델 출력 스트림을 그대로 반환하며, 원문은 이런 방식이 대화 UI에 적합하다고 설명한다. 같은 프로젝트가 React UI용 REST 엔드포인트도 제공하므로 하나의 코드베이스에서 브라우저와 AgentCore 런타임 요청을 함께 처리할 수 있다. 다만 여러 인수를 사용하는 도구 호출에서는 인수 바인딩을 안정적으로 처리하기 위해 블로킹 call()로 응답을 완성한 다음 결과를 청크로 나누어 스트리밍하는 방식을 권고한다. 제공된 본문은 이 스트리밍 주의점 뒤에서 문장이 끊겨 있어, 이후의 상세 구현이나 추가 검증 결과까지 확인할 수는 없다.

🧾 핵심 주장 / 시사점

• 이 접근의 핵심은 Java 팀의 개발 방식을 유지하면서 AgentCore의 운영 기능을 연결하는 데 있다. 다만 원문이 강조하는 상태 보고, 최소 권한 IAM, 관측 가능성과 사람 검토까지 함께 고려해야 운영 구조가 완성된다.
• IDP의 역할 분리는 모델의 추출 결과와 업무 규칙의 판정을 구분한다. 신뢰도와 규칙 심각도가 사람 검토로 이어지는 기준이 된다는 점에서, 전문 에이전트의 출력만으로 처리가 끝나는 구조는 아니다.
• 병렬 처리와 스트리밍은 적용 조건을 구분해야 한다. 병렬 팬아웃은 선택적 확장이고, 여러 인수를 사용하는 도구 호출은 응답을 먼저 완성한 뒤 스트리밍하도록 권고되어 있어 모든 경로가 기본적으로 병렬·직접 스트리밍되는 것은 아니다.

✅ 액션 아이템

• 여행 도우미를 시작점으로 Spring AI의 도구 호출, SSE 스트리밍과 AgentCore 단기·장기 메모리의 결합 방식 검토.
• IDP의 순차 배치 처리와 선택적 병렬 팬아웃을 구분하고, SpEL 규칙 및 사람 검토로 이어지는 처리 흐름 확인.
• POST /invocations와 GET /ping 계약, 장기 작업의 HealthyBusy 보고, 다중 인수 도구 호출의 call() 후 스트리밍 방식 점검.

❓ 열린 질문

• 여행 도우미의 AgentCore 단기·장기 메모리는 세션 내 맥락과 세션 간 맥락을 각각 어떻게 유지하는가?
• IDP에서 순차 배치 처리 대신 선택적 병렬 팬아웃을 적용할 필요가 있는 문서는 무엇인가?
• 장기 작업의 HealthyBusy 보고와 다중 인수 도구 호출의 call() 후 스트리밍 방식은 각각 어떻게 구현되는가?