How Bayer Crop Science built an agentic decision engine on Amazon Bedrock AgentCore with AWS Unified Operations
Quick Summary
Bayer Crop Science는 Amazon Bedrock AgentCore 기반의 다중 에이전트 인터페이스 ADE를 구축해 기존 CDE의 분석·운영 정보에 자연어로 접근하게 하고, 초기 단계에서 사용자 질문의 약 80%를 엔지니어 개입 없이 해결했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Bayer Crop Science는 Amazon Bedrock AgentCore 기반의 다중 에이전트 인터페이스 ADE를 구축해 기존 CDE의 분석·운영 정보에 자연어로 접근하게 하고, 초기 단계에서 사용자 질문의 약 80%를 엔지니어 개입 없이 해결했다.
📌 핵심 요약
- Bayer Crop Science는 유전체·포장 시험·이미지·환경·모델 출력 데이터를 다루는 ML 워크플로 플랫폼 CDE 위에 ADE를 구축했다. ADE는 질문을 전문 에이전트로 연결하며, 초기 단계에서 사용자 질문의 약 80%를 엔지니어 개입 없이 해결한다.
- ADE는 Amazon Bedrock AgentCore의 세션 격리 런타임, IAM 범위의 도구 접근, 프레임워크에 구애받지 않는 설계를 활용한다. LangGraph가 에이전트를 조율하며, AWS Unified Operations의 TAM과 생성형 AI DSE가 설계부터 운영까지 지원했다.
- 운영 환경의 22개 전문 에이전트가 개념 설명, 실시간 워크플로 조회, 장애 진단, 시각화 등을 담당한다. Troubleshooting Agent를 통한 진단은 수동 로그 탐색과 엔지니어 지원 대기로 1시간 넘게 걸리던 작업에서 10분 미만으로 단축됐다.
- 핵심 설계는 DynamoDB를 통한 워크플로 상태 영속화, 사용자·서비스·도구 간 인증 및 권한 경계 분리, 모델 인터페이스 호환성 검증, 에이전트별 도구 범위 제한, 복잡한 시각화 기능의 전문 에이전트 전환이다. CDE는 500개가 넘는 모델 구성을 관리한다.
- 운영 준비에서는 HTTP 성공과 실제 작업 성공을 구분하도록 CloudWatch 사용자 정의 지표·경보·추적을 보강했다. 비용 측면에서는 청구 귀속과 요청 단위 텔레메트리를 함께 봐야 한다고 설명하지만, 제공된 본문은 Amazon Bedrock 비용 귀속 설계 설명 도중 끝난다.
🧩 주요 포인트
- CDE 위에 22개 전문 에이전트를 배치함으로써, 분석 실행 이후의 정보 탐색과 장애 해석을 자연어 기반의 도메인별 지원으로 전환했다.
- 세션 격리와 DynamoDB 상태 영속화, 인증 및 권한 경계 분리, 모델 인터페이스 호환성 검증, 도구 범위 제한을 결합해 실행 복원성과 접근 통제, 변경 안정성을 확보하는 구조다.
- CloudWatch의 작업 실패 관측과 Amazon Bedrock 비용의 요청 단위 귀속은 다중 에이전트 운영의 품질·경제성을 판단하는 축이며, 비용 귀속의 구체적 구현은 제공된 본문만으로 확인할 수 없다.
🧠 상세 정리
1. CDE의 확산으로 바뀐 병목과 ADE의 역할
Bayer Crop Science의 육종 의사결정은 유전체, 포장 시험, 이미지, 환경 조건, 모델 출력 등 여러 종류의 데이터에 의존하며, 작물·지역·팀별로 수백 개의 ML 모델 구성을 실행하므로 재현성과 거버넌스가 필요했다. 이를 위해 구축한 Connected Decision Engine(CDE)은 ML 워크플로의 배포·조율·모니터링·재사용을 지원하고, 육종가와 분석가, 연구자, 데이터 과학자, 데이터 엔지니어에게 실행 이력과 운영 통제를 유지하는 공통 실행 방식을 제공했다. 그러나 사용이 늘자 병목은 워크플로 실행에서 결과 이해로 옮겨갔고, 실패 원인이나 모델 동작, 결과의 출처를 설명하려면 API·문서·메타데이터 저장소·대시보드·로그를 직접 찾아 연결해야 했다. Agentic Decision Engine(ADE)은 CDE 위에 자연어 기반 다중 에이전트 인터페이스를 추가해, 감독 에이전트가 질문을 전문 에이전트로 보내고 해당 시스템의 맥락을 가져오게 했다. 초기 단계에서 ADE는 사용자 질문의 약 80%를 엔지니어 개입 없이 해결한다.
2. AgentCore 선택과 AWS Unified Operations의 참여
ADE는 다양한 프레임워크와 모델로 에이전트를 구축·연결·최적화할 수 있는 Amazon Bedrock AgentCore에서 실행되며, 이를 통해 팀은 자체 호스팅과 세션 격리, 도구 접근 계층을 운영하는 부담을 줄이고 에이전트 동작에 집중했다. 선택을 이끈 세 가지 기능은 사용자별 세션을 격리하는 관리형 런타임, IAM 범위의 도구 접근을 제공하며 인증·인가를 에이전트 코드 밖에 두는 AgentCore Gateway, 자체 LangGraph 조율과 모델 선택을 허용하는 프레임워크 독립성이었다. Bayer는 출시 준비와 이후 운영을 위해 AWS Unified Operations와 협력했고, 전담 Technical Account Manager(TAM)와 생성형 AI Domain Specialist Engineer(DSE)가 설계부터 운영 환경 적용까지 팀의 일원처럼 참여했다. TAM은 Bayer의 운영 방식과 사업 우선순위에 대한 이해를 제공했고, DSE는 AWS 생성형 AI 전문성과 ADE 워크로드에 대한 실무 이해를 바탕으로 주 3회 기술 스탠드업에서 설계 판단을 지원했다. 이 협업은 사후 에스컬레이션에 그치지 않고 설계 확정 전에 AWS 서비스 동작을 검증하는 방식이었으며, 아키텍처 소유권과 최종 결정권은 Bayer에 남았다.
3. 네 계층 아키텍처와 데이터 저장소의 책임 분리
ADE는 사용자 경험, 에이전트 조율, 전문 에이전트, 도구 및 데이터 소스의 네 계층으로 구성되며, 사용자는 React 웹 화면과 Microsoft Entra ID용 신원 프록시를 거쳐 에이전트에 접근한다. GitHub Actions는 에이전트 컨테이너 이미지를 빌드해 Amazon ECR에 올리고 AgentCore 런타임에 배포하며, 런타임 위에서는 명시적인 그래프 제어 흐름과 체크포인팅을 제공하는 LangGraph가 동작한다. 진입점인 Supervisor Agent는 요청을 분류하고 전문 에이전트를 선택하며, 여러 도메인에 걸친 질문에서는 결과를 결합한다. 데이터 계층도 역할을 나눠 DynamoDB는 LangGraph 체크포인트, Aurora PostgreSQL은 세션 기록·사용자 피드백·분석 정보, ElastiCache는 TTL이 설정된 응답 캐시를 저장한다. S3의 도메인 콘텐츠는 Amazon Titan Text Embeddings V2로 임베딩해 OpenSearch Serverless에 색인하고 RAG에 활용하며, CloudWatch는 실행·애플리케이션 텔레메트리를 수집하고 AgentCore Gateway는 백엔드 API를 MCP 도구로 노출한다.
4. 22개 전문 에이전트와 장애 진단의 변화
ADE는 운영 환경에서 22개 전문 에이전트를 실행하며, 각 에이전트는 특정 도메인과 그에 필요한 도구·데이터 소스로 범위를 제한한다. Domain Expert Agent는 RAG로 개념 질문에 답하고, Operational Agent는 CDE의 실시간 워크플로 상태와 결과를 조회하며, Troubleshooting Agent는 운영 텔레메트리를 분석하고 Visualization Agent는 차트나 기존 대시보드를 제공한다. 고객 맞춤형 Models as Skill 패턴은 모델 코드와 문서를 중앙 레지스트리의 스킬 정의로 변환해, 모델별 질문에 일반적인 모델 지식이 아니라 실제 구현을 근거로 답하도록 한다. 예를 들어 육종가가 전날 표현형 분석 워크플로의 실패 이유를 물으면, 감독 에이전트는 Troubleshooting Agent로 요청을 보내고 해당 에이전트는 CloudWatch 텔레메트리와 Gateway를 통해 조회한 CDE API 상태를 함께 분석해 실패 지점을 진단한다. 사용자가 직접 로그를 검색할 필요가 없어지면서, 수동 로그 탐색과 엔지니어 지원 대기로 1시간 넘게 걸리던 진단이 10분 미만으로 줄었다.
5. 실행 상태의 영속화와 신원·권한 경계의 분리
첫 번째 설계 결정은 AgentCore 런타임을 단순한 무상태 환경으로 보지 않으면서도, 워크플로 재개에 필요한 상태를 외부에 영속화하는 것이었다. 런타임의 격리된 세션은 수명주기 안에서 호출 간 실행 맥락을 유지하지만 다단계 워크플로의 영구 저장소는 아니므로, ADE는 LangGraph 체크포인트를 DynamoDB에 기록해 확장·재시작·세션 경계 이후에도 실행 환경 하나에 의존하지 않고 그래프를 재개한다. 두 번째 결정은 모든 신뢰 경계에 하나의 토큰을 강제로 적용하지 않고, Microsoft Entra ID를 사용자 신원의 기준으로 유지하면서 서비스 간 호출은 IAM으로 인가하고 하위 CDE 서비스 접근은 AgentCore Gateway의 아웃바운드 인가로 처리하는 것이었다. 요청 인터셉터인 AWS Lambda 함수는 사용자 정의 검증을 수행하고 하위 도구에 필요한 인가 속성을 전달하며, 팀은 DSE와 각 단계의 토큰 계약을 검토했다. 원문은 사용자·에이전트·도구 신원 사이의 전환에서 문제가 집중될 수 있으므로, 각 단계의 발급자·대상·클레임·범위·자격 증명 유효기간을 명시해야 한다고 강조한다.
6. 모델 교체의 호환성과 도구 목록의 제어
세 번째 설계 결정은 모델 선택을 인터페이스 계약으로 다루는 것으로, 팀이 추론 모드를 켠 더 새로운 모델 버전을 평가했을 때 ADE가 의존하는 도구 사용과 구조화된 출력의 조합이 기존 에이전트 구현과 호환되지 않았다. DSE가 이 제약을 확인한 뒤 팀은 출시 버전에 기존 모델을 유지했으며, 원문은 도구 호출·구조화된 출력·스트리밍·추론 기능·지연시간·할당량·모델별 요청 의미를 함께 검증해야 한다고 설명한다. 네 번째 결정은 500개가 넘는 모델 구성을 관리하는 CDE의 API마다 전용 MCP 서버를 만드는 대신, OpenAPI 명세를 AgentCore Gateway에 등록해 REST 작업을 MCP 도구로 노출하는 것이었다. 이 방식에서는 API 추가나 변경을 새 서버 배포 대신 스키마와 Gateway 설정 변경으로 처리할 수 있어 배포·인증·버전 관리 부담을 줄인다. 동시에 도구 스키마와 설명이 입력 토큰을 차지하고 모델의 선택 범위를 넓히므로 에이전트별 도구 범위를 제한했으며, 더 큰 목록에는 전체 도구를 매번 불러오지 않고 관련 도구를 찾는 Gateway의 의미 기반 도구 검색을 활용할 수 있다고 제시한다.
7. 복잡해진 시각화 기능을 전문 에이전트로 전환
다섯 번째 설계 결정은 복잡한 기능을 단순 도구에서 독립적인 에이전트로 승격하는 것이었으며, 시각화가 그 사례였다. 처음에는 다른 에이전트가 호출하는 도구였지만, 기능이 커지면서 자체 데이터 조회와 차트 선택 로직, 재시도, 오류 처리뿐 아니라 새 차트를 만들지 기존 대시보드를 반환할지 판단하는 책임까지 필요해졌다. 팀은 이 기능을 Visualization Agent로 분리하고, 샌드박스 코드 실행 환경인 AgentCore Code Interpreter에서 matplotlib과 Plotly를 사용해 요청에 맞는 차트를 생성하도록 했다. 에이전트는 Amazon S3를 통해 코드 실행 환경과 데이터를 교환하며, 사전 구축된 대시보드가 더 적절한 답이면 기존 Amazon Quick 또는 Power BI 자산을 반환한다. 원문이 제시한 구분 기준은 도구가 한정된 작업을 수행하는 데 비해, 상태·재시도·계획·정책·표현 방식의 판단을 맡기 시작한 기능은 에이전트로 모델링해야 한다는 것이다.
8. 실제 작업 실패의 관측과 비용 귀속의 과제
출시가 가까워지면서 ADE 팀의 초점은 에이전트 실패 탐지, 추론 비용 귀속, 배포 강화 등 운영 가능성으로 이동했으며, 감독 에이전트 구조에서는 하나의 요청이 여러 모델 호출·도구 호출·에이전트 인계로 이어진다는 점이 핵심 과제였다. 모든 HTTP 요청이 성공해도 최종 답변은 틀릴 수 있는데, 실제로 애플리케이션 예외 처리기가 에이전트 오류를 잡아 응답을 반환하면서 모니터링에는 성공으로 집계되는 문제가 발생했다. 팀은 DSE와 이를 재현한 뒤 실패 경로 안에 CloudWatch 사용자 정의 지표를 추가하고, 도구 호출 오류·스로틀링·모델 시간 초과·구조화된 출력 검증 실패에 대한 에이전트별 경보를 구성했으며, 추적과 호출 로그로 감독 에이전트부터 전문 에이전트까지 요청을 따라가게 했다. 따라서 관측은 전송 성공 여부를 넘어 작업 완료 여부, 결과에 영향을 준 에이전트나 도구, 예상한 출처의 사용 여부를 보여줘야 한다는 것이 원문의 원칙이다. 비용 측면에서는 ADE 요청 하나가 여러 모델과 도구를 호출하므로 계정 수준의 Amazon Bedrock 지출만으로 요청당 경제성을 설명할 수 없어 청구 귀속과 요청 단위 텔레메트리를 결합해야 한다고 제시하지만, 제공된 본문은 그 설계 설명 도중 끝나 구체적인 구현과 후속 운영 내용은 확인할 수 없다.
🧾 핵심 주장 / 시사점
- ADE의 성과는 ML 워크플로 실행 기능을 추가한 데서보다, CDE에 흩어진 운영 맥락을 전문 에이전트가 연결해 사용자의 해석 부담을 줄인 데서 드러난다.
- 관리형 AgentCore 런타임을 사용해도 워크플로 복원을 위한 영속 상태, 경계별 인가, 모델과 도구의 인터페이스 호환성은 별도로 설계해야 한다.
- 다중 에이전트의 운영 품질을 평가하려면 응답 반환 여부를 넘어 작업 성공과 근거 사용을 관측해야 하며, 비용 역시 계정 총액에서 요청 단위로 연결할 필요가 있다.
✅ 액션 아이템
- ADE의 22개 전문 에이전트별 도구 범위와 모델 인터페이스 호환성을 함께 점검.
- DynamoDB 상태 영속화와 인증 및 권한 경계 분리가 실행 복원성과 접근 통제에 부합하는지 검토.
- CloudWatch의 작업 실패 관측과 Amazon Bedrock 비용의 요청 단위 귀속을 연결할 수 있는지 검토.
❓ 열린 질문
- ADE의 사용자 질문 약 80% 자체 해결률은 어떤 질문 범위와 평가 기준으로 측정됐는가?
- 모델 인터페이스 호환성 검증과 에이전트별 도구 범위 제한은 어떤 기준으로 판단하는가?
- Amazon Bedrock 비용의 요청 단위 귀속은 구체적으로 어떻게 구현됐는가?
