식물 육종 의사결정은 유전체학, 포장 시험, 영상, 환경 조건, 모델 출력에 걸쳐 있는 데이터에 의존합니다. Bayer Crop Science는 작물, 지역, 팀에 걸쳐 이 데이터에 대해 수백 가지 머신 러닝(ML) 모델 구성을 실행하며, 각 실행은 반복 가능하고 거버넌스가 적용되어야 합니다. 이 요구 사항을 충족하기 위해 Bayer는 ML 워크플로를 배포, 오케스트레이션, 모니터링, 재사용하기 위한 시스템인 Connected Decision Engine(CDE)을 구축했습니다. CDE는 육종가, 분석가, 연구자, 데이터 사이언티스트, 데이터 엔지니어에게 실행 이력과 운영 통제를 보존하면서 분석을 실행할 수 있는 일관된 방법을 제공합니다.
도입이 확대되면서 병목 현상은 워크플로 실행에서 워크플로 이해로 이동했습니다. 결과를 설명하려면 API, 문서, 메타데이터 저장소, 대시보드, 로그에서 맥락을 조합해야 했습니다. 워크플로가 실패한 이유, 모델이 무엇을 했는지, 결과가 어디에서 왔는지 알고 싶어 하는 사용자는 여전히 어떤 시스템을 살펴봐야 하는지 알아야 했습니다. 이 격차를 해소하기 위해 Bayer는 CDE 위에 구축된 멀티 에이전트 자연어 인터페이스인 Agentic Decision Engine(ADE)을 구축했습니다. 슈퍼바이저 에이전트가 각 질문을 전문 에이전트에게 라우팅하고, 전문 에이전트가 관련 시스템에서 맥락을 검색하며, 사용자는 운영 스택을 탐색하지 않고도 답변을 받습니다. 첫 번째 단계에서 ADE는 엔지니어의 개입 없이 사용자 질문의 약 80 퍼센트를 해결합니다.
ADE는 Amazon Bedrock AgentCore에서 실행됩니다. 이는 어떤 프레임워크나 모델로도 대규모로 에이전트를 구축, 연결, 최적화할 수 있는 AWS 서비스입니다. AgentCore 덕분에 팀은 자체 에이전트 호스팅, 세션 격리, 도구 접근 계층을 구축하고 운영하는 대신 에이전트 동작에 집중할 수 있었습니다. 이 선택을 이끈 세 가지 AgentCore 기능은 다음과 같습니다. 각 사용자 세션을 격리하는 관리형 런타임, Amazon Bedrock AgentCore의 기능인 AgentCore Gateway를 통한 AWS Identity and Access Management(IAM) 범위 도구 접근으로 인증과 권한 부여를 에이전트 코드 외부에 유지, 그리고 팀이 자체 LangGraph 오케스트레이션과 모델 선택을 가져올 수 있게 한 프레임워크에 구애받지 않는 설계입니다.
출시를 준비하고 이후 ADE를 운영하기 위해 Bayer는 AWS Unified Operations에 참여했습니다. 이 계약을 통해 지정된 Technical Account Manager(TAM)와 생성형 AI Domain Specialist Engineer(DSE)가 제공되었고, 이들은 설계부터 프로덕션까지 ADE 팀의 확장 형태로 일했습니다. TAM은 Bayer의 전략 자문 역할을 하며 Bayer의 운영 모델과 사업 우선순위에 대한 확립된 이해를 제공했습니다. DSE는 AWS에 대한 생성형 AI 도메인 전문 지식을 제공했습니다. 매주 세 번의 기술 스탠드업에서 팀은 검토하고 설계 결정을 내렸습니다. DSE는 ADE 워크로드와 Bayer 팀의 운영 방식에 대한 실무 지식을 쌓아 기술 지침이 AWS 서비스 동작과 Bayer의 맥락을 모두 반영하도록 했습니다. 이 게시물은 그 여정을 따릅니다. ADE 아키텍처, 구축 과정에서 이루어진 다섯 가지 설계 결정, 플랫폼의 프로덕션 준비 작업, 그리고 출시 후 운영 방법입니다.
아키텍처 개요
ADE는 네 개의 계층으로 구성됩니다. 사용자 경험, 에이전트 오케스트레이션, 전문 에이전트, 그리고 해당 에이전트가 호출하는 도구 및 데이터 소스입니다(그림 1). 사용자는 React 웹 프런트 엔드를 통해 ADE에 접근하며, 요청은 에이전트에 도달하기 전에 Microsoft Entra ID용 ID 프록시를 통과합니다. GitHub Actions는 에이전트 컨테이너 이미지를 빌드하고 Amazon Elastic Container Registry(Amazon ECR)로 푸시한 후, Amazon Bedrock AgentCore의 기능인 AgentCore 런타임에 배포합니다.
Amazon Bedrock AgentCore 런타임이 에이전트를 호스팅하며, 이 런타임은 프레임워크에 구애받지 않기 때문에 팀은 자체 LangGraph 기반 오케스트레이션을 런타임 위에서 직접 구동합니다. 팀은 명시적인 그래프 기반 제어 흐름과 멀티 스텝 워크플로를 위한 체크포인팅 덕분에 LangGraph를 선택했습니다. LangGraph가 워크플로를 오케스트레이션하며, Supervisor Agent가 진입점이 되어 각 요청을 분류하고, 전문 에이전트를 선택하고, 질문이 여러 도메인에 걸쳐 있을 때 결과를 결합합니다. 데이터 플레인은 책임별로 분리되어 있습니다. Amazon DynamoDB 는 LangGraph 체크포인트 상태를 저장합니다. Amazon Aurora PostgreSQL은 세션 기록, 사용자 피드백, 분석 데이터를 저장합니다. Amazon ElastiCache 는 만료 시간(TTL)을 두고 에이전트 응답을 캐싱합니다. Amazon Simple Storage Service (Amazon S3) 의 도메인 콘텐츠는 Amazon Titan Text Embeddings V2로 임베딩되어 Retrieval Augmented Generation(RAG)을 위해 Amazon OpenSearch Serverless에 인덱싱됩니다. Amazon CloudWatch 는 런타임 및 애플리케이션 텔레메트리를 수집합니다. AgentCore Gateway는 백엔드 API를 Model Context Protocol(MCP) 도구로 에이전트에 노출하고, 인증 및 권한 부여를 에이전트 코드 외부에 유지합니다.
그림 1: Amazon Bedrock AgentCore 기반 Agentic Decision Engine 아키텍처
ADE는 프로덕션에서 22개의 전문 에이전트를 운영하며, 각 에이전트는 자체 도구와 데이터 소스를 갖춘 하나의 도메인으로 범위가 한정됩니다. 예를 들어 Domain Expert Agent는 RAG를 통해 개념적 질문에 답변합니다. Operational Agent는 CDE에서 실시간 워크플로 상태와 결과를 조회합니다. Troubleshooting Agent는 운영 텔레메트리를 분석합니다. Visualization Agent는 차트를 생성하거나 기존 대시보드를 반환합니다. 고객별 Models as Skill 패턴은 모델 코드와 문서를 중앙 레지스트리에 저장되는 스킬 정의로 변환하여, 에이전트가 일반적인 모델 지식이 아닌 모델의 구현을 근거로 모델별 질문에 답변하도록 합니다.
육종가가 “어제 제 표현형 분석(phenotyping) 워크플로가 왜 실패했나요?”라고 물으면, 슈퍼바이저가 의도를 분류하고 요청을 Troubleshooting Agent로 라우팅합니다. 해당 에이전트는 CloudWatch에서 워크플로의 텔레메트리를 읽고 AgentCore Gateway를 통해 CDE API에서 상태를 조회하며, 실패 지점을 파악하고 슈퍼바이저를 통해 진단 결과를 반환합니다(그림 2). 육종가는 더 이상 로그를 직접 검색하지 않습니다. Troubleshooting Agent를 통해, 한때 수동 로그 탐색과 엔지니어 지원 대기로 한 시간 이상 걸리던 진단이 이제는 10분 이내에 완료됩니다.
그림 2: ADE 요청 흐름: 의도 분류, 캐시 조회, 전문 에이전트 라우팅, 응답
프로덕션으로 가는 길목의 다섯 가지 설계 결정
Unified Operations TAM과 DSE는 사후 에스컬레이션 지점이 아니라 작업 팀의 멤버로서 다음 결정에 참여했습니다. 이를 통해 Bayer는 아키텍처의 소유권과 최종 결정권을 유지하면서 각 설계를 AWS 서비스 동작에 대해 커밋 전에 검증할 수 있었습니다.
1. 런타임을 스테이트리스로 취급하지 않으면서 오케스트레이션 상태의 외부화
AgentCore 런타임은 세션 수명 주기 내에서 여러 호출에 걸쳐 실행 컨텍스트를 보존하는 격리된 세션을 제공합니다. 하지만 그 컨텍스트는 멀티 스텝 워크플로를 위한 내구성 있는 저장소가 아닙니다. ADE는 LangGraph 체크포인트를 DynamoDB에 기록하여, 스케일아웃 이벤트, 재시작 또는 세션 경계 이후에도 특정 실행 환경의 가용성에 의존하지 않고 그래프가 재개될 수 있도록 합니다.
원칙: 활성 실행에는 런타임 세션을 사용하고, 워크플로를 재개하거나 재구성하는 데 필요한 상태는 내구성 있는 서비스에 저장하십시오.
2. 엔터프라이즈 아이덴티티, 게이트웨이 접근, 다운스트림 권한 부여의 분리
Bayer는 사용자 아이덴티티를 위해 Microsoft Entra ID로 표준화하는 반면, ADE의 서비스들은 AWS 네이티브 메커니즘으로 서로를 권한 부여합니다. 하나의 토큰을 모든 신뢰 경계에 걸쳐 강제로 사용하는 대신, 팀은 각 경계에 자체 메커니즘을 부여했습니다.
Entra ID는 사용자 아이덴티티의 소스로 유지됩니다. AWS Identity and Access Management(IAM)는 서비스 간 호출을 권한 부여합니다. AgentCore Gateway의 아웃바운드 권한 부여가 다운스트림 CDE 서비스에 대한 접근을 처리합니다. AWS Lambda 요청 인터셉터 함수가 사용자 지정 검증을 수행하고 다운스트림 도구가 필요로 하는 권한 부여 속성을 전달합니다. 팀은 DSE와 함께 각 홉에서 토큰 계약을 정리했습니다.
원칙: 에이전트 시스템에서 아이덴티티 장애는 사용자 아이덴티티, 에이전트 아이덴티티, 도구 아이덴티티 사이의 전환 지점에 집중됩니다. 한 경계에서 유효한 토큰을 다음 경계에서 재사용하는 대신, 모든 홉에서 발급자, 대상(audience), 클레임, 범위(scope), 자격 증명 수명을 정의하십시오.
3. 모델 선택을 인터페이스 계약으로 취급
구축 과정에서 팀은 추론 모드가 활성화된 최신 모델 버전을 평가했습니다. 해당 버전에서는 ADE가 의존하는 도구 사용과 구조화된 출력의 조합이 에이전트 구현 방식과 호환되지 않았습니다. DSE가 이 제약을 확인했고, 팀은 현재 모델을 릴리스에 유지했습니다.
원칙: 도구를 사용하는 에이전트의 경우, 모델 선택은 전체 인터페이스의 제약을 받습니다: 도구 호출, 구조화된 출력, 스트리밍 동작, 추론 기능, 지연 시간, 할당량 가용성, 모델별 요청 의미론. 더 최신 모델이 자동으로 기존 모델을 갈아 끼울 수 있는 드롭인 대체품이 되는 것은 아닙니다.
4. 도구 표면이 프롬프트를 지배하기 전에 도구 표면을 통제하라
CDE는 500개가 넘는 모델 구성을 관리합니다. API마다 전용 MCP 서버를 두는 방식은 배포, 인증, 버전 관리 오버헤드를 추가했을 것입니다. 대신 ADE는 OpenAPI 사양을 AgentCore Gateway에 등록하고, 이 게이트웨이가 REST 작업을 MCP 도구로 노출합니다. API를 추가하거나 변경하는 일이 새 서버 배포가 아닌 스키마 및 게이트웨이 구성 변경으로 처리됩니다.
도구 스키마와 설명 역시 입력 토큰을 소비하며 사용자 요청 및 검색된 컨텍스트와 경쟁합니다. ADE는 모든 에이전트에 전체 카탈로그를 제공하는 대신 전문 에이전트별로 도구 범위를 지정합니다. 더 큰 카탈로그의 경우 AgentCore Gateway가 시맨틱 도구 검색을 지원하므로, 에이전트가 매 턴마다 전체 카탈로그를 로드하지 않고도 관련 도구를 찾을 수 있습니다.
원칙: 도구 카탈로그는 에이전트별로 범위를 지정하십시오. 모든 도구 정의는 토큰을 추가하고 모델의 결정 공간을 넓힙니다.
5. 복잡한 기능을 도구에서 에이전트로 승격
시각화는 다른 에이전트가 호출하는 도구로 시작했습니다. 성장하면서 자체적인 데이터 검색, 차트 선택 로직, 재시도, 오류 처리, 그리고 차트를 생성할지 기존 대시보드를 반환할지에 대한 판단이 필요해졌습니다. 팀은 이를 전문 Visualization Agent로 이전했습니다. 이 에이전트는 샌드박스 코드 실행 환경을 제공하는 Amazon Bedrock AgentCore의 기능인 AgentCore Code Interpreter에서 matplotlib와 Plotly로 온디맨드 차트를 생성하고, Amazon S3를 통해 데이터를 주고받습니다. 사전 구축된 대시보드가 더 나은 답변일 때는 에이전트가 기존의 Amazon Quick 또는 Power BI 자산을 반환합니다.
원칙: 도구는 범위가 한정된 작업을 수행합니다. 어떤 기능이 상태, 재시도, 계획, 정책 또는 표현 결정을 담당하기 시작하면 에이전트로 모델링하십시오.
ADE의 프로덕션 준비
빌드가 출시 단계로 이동하면서 초점은 설계에서 운영 가능성으로 옮겨갔습니다. 에이전트 장애 감지, 추론 비용 귀속, 배포 강화가 그것입니다.
관측성: 예외가 아닌 작업 실패를 측정
슈퍼바이저 아키텍처는 하나의 사용자 요청을 모델 호출, 도구 호출, 에이전트 핸드오프의 연쇄로 바꿉니다. 모든 HTTP 요청이 성공했더라도 최종 답변은 틀릴 수 있습니다. ADE는 이를 직접 경험했습니다. 애플리케이션 예외 핸들러가 에이전트 오류를 잡아 모니터링이 성공으로 집계하는 응답을 반환한 것입니다. DSE와 함께 이 문제를 재현한 후, 팀은 실패 경로 내부에 사용자 지정 CloudWatch 지표와 에이전트별 조건(도구 호출 오류, 스로틀링, 모델 타임아웃, 구조화된 출력 검증 실패)에 대한 알람을 추가했습니다. 트레이스와 호출 로그가 슈퍼바이저와 전문 에이전트 전반에서 각 요청을 추적합니다.
원칙: 전송 성공과 작업 성공을 구분하십시오. 에이전트 관측성은 작업이 완료되었는지, 어떤 에이전트나 도구가 결과를 바꿨는지, 응답이 기대한 소스를 사용했는지를 보여주어야 합니다.
비용 귀속: 청구 귀속과 요청 수준 텔레메트리 결합
ADE 요청 하나가 여러 모델과 도구를 호출할 수 있으므로, 계정 수준의 Amazon Bedrock 지출만으로는 단위 경제성을 설명할 수 없습니다. 팀은 DSE와 함께 서로 다른 질문에 답하는 세 가지 메커니즘으로 귀속 방식을 설계했습니다. Amazon Bedrock 애플리케이션 추론 프로파일은 청구되는 모델 사용량을 애플리케이션이나 워크로드에 귀속시킵니다. 요청 메타데이터와 모델 호출 로깅은 토큰 사용량을 특정 에이전트, 기능 또는 요청과 연결합니다. IAM 보안 주체 귀속은 아이덴티티 차원을 추가합니다. 이들을 함께 사용하면 팀은 상호작용당 비용을 추산하고, 비용이 많이 드는 에이전트를 식별하고, 프롬프트, 검색된 컨텍스트, 도구 정의 중 무엇이 토큰 사용을 주도하는지 판단할 수 있습니다. 실제로 MCP 도구와 여러 도구 호출에 의존하는 Visualization 및 Operational 에이전트가 가장 많은 토큰을 소비했습니다.
동일한 텔레메트리는 출시 준비 중에 큰 반복 입력 접두사가 있으면서 프롬프트 캐시 활동이 없는 워크로드를 드러냈습니다. 지원되는 모델의 경우, 안정적인 지침과 도구 정의를 캐시 가능한 프롬프트 접두사에 배치하면 반복 입력 처리가 줄어들어 지연 시간과 토큰 비용이 낮아집니다. ADE의 경우 안정적인 프롬프트 접두사를 캐싱하여 입력 토큰 비용을 20~30퍼센트 절감했습니다.
보안 및 출시 준비성
IAM 역할은 각 에이전트의 책임에 맞게 범위가 지정됩니다. Troubleshooting Agent는 진단에 필요한 운영 데이터를 읽을 수 있지만 워크플로를 수정할 수 없습니다. Domain Expert Agent는 자체 검색 인덱스를 쿼리할 수 있지만 관련 없는 CDE API는 호출할 수 없습니다. 오늘날 프로덕션에서 ADE의 에이전트 응답은 최소 권한, 에이전트별로 범위가 지정된 읽기 전용 도구 액세스, 에이전트 응답에 대한 구조화된 출력 검증, 그리고 개방형 생성이 아닌 검색된 CDE 데이터와 텔레메트리에 근거한 답변에 따라 관리됩니다. Bayer는 또한 CDE 멀티턴 워크플로에서 이미 사용 중인 사용자 지정 안전 검사를 보완하는 추가 계층으로 Amazon Bedrock Guardrails를 평가할 계획입니다.
출시 전에 Unified Operations는 ADE 팀과 함께 Critical Workload Review와 생성형 AI 렌즈를 적용한 Well-Architected 리뷰를 수행했습니다. DSE가 이미 워크로드를 알고 있었기 때문에 두 리뷰 모두 일반적인 모범 사례가 아닌 ADE의 특정 실패 모드, 용량 위험, 배포 공백에 초점을 맞췄습니다. 발견 사항에는 슈퍼바이저와 전문 에이전트 전반의 장애 가시성 부족, 변경 가능한 컨테이너 이미지 태그, 제한적인 이미지 추적성, 취약점 스캔 부재가 포함되었습니다. 팀은 더 강력한 알람, 불변의 버전 지정 이미지, Amazon ECR의 푸시 시 스캔, 미사용 이미지에 대한 수명 주기 정책으로 대응했습니다.
DSE는 또한 팀과 함께 확장 및 할당량 요구 사항을 검토했습니다. 부하 테스트는 애플리케이션과 서비스 할당량 모두를 검증했으며, 빈 응답을 반환하는 네트워킹 실패 모드를 드러냈고, 팀은 프로덕션 이벤트 전에 이를 수정했습니다. 출시 시점까지 팀은 Unified Operations와 함께 35개의 차단 요소를 해결까지 추적했습니다.
출시, 운영, 그리고 다음 단계
Bayer는 ADE를 조직 전체에 한 번에 개방하는 대신 게이트가 설정된 그룹에 출시했습니다. 출시 이후 Bayer Crop Science 전반에서 100명 이상의 사용자가 육종가, 분석가, 연구원, 데이터 사이언티스트, 엔지니어를 포함해 ADE를 사용해 왔습니다. ADE는 22개의 전문 에이전트와 함께 약 20개의 API 도구를 노출하며, 확장됨에 따라 서드파티 에이전트를 호스팅할 수 있습니다. API별 전용 서버 대신 AgentCore Gateway를 통해 이러한 API를 노출함으로써 API당 통합 오버헤드를 99퍼센트 이상 줄였습니다. 첫 번째 단계에서 ADE는 엔지니어의 개입 없이 사용자 질문의 약 80퍼센트를 해결했습니다.
CDE는 분석을 위한 거버넌스가 적용된 실행 계층으로 남아 있습니다. ADE는 그 위에 자연어 계층을 추가하여, 사용자가 각 기반 시스템의 위치나 인터페이스를 배우지 않고도 워크플로우 상태, 결과, 모델 동작, 장애에 대해 질문할 수 있습니다.
이후 협업은 출시 준비에서 지속적인 운영으로 전환되었습니다. DSE는 계속 팀과 미팅하므로, 이슈 분류와 운영 검토는 새로운 램프업 없이 ADE에 대한 기존 지식에서 시작됩니다. ADE의 중요 CloudWatch 알람, 앞서 설명한 에이전트별 알람을 포함하여,는 AWS Incident Detection and Response에 온보딩되었습니다. 알람이 발동되면 AWS Incident Management Engineers가 5분 이내에 개입하여 처음부터 다시 시작하는 것이 아니라 워크로드의 컨텍스트에서 출발합니다. 보안 측면에서는 AWS Security Incident Response 엔지니어가 잠재적 또는 활성 보안 이벤트 중에 팀을 지원하므로, ADE는 운영 및 보안 문제 모두에 대해 AWS의 모니터링과 대응 커버리지를 갖추게 됩니다.
에이전트 간 통신이 이미 갖추어진 가운데, Bayer는 다음으로 하이브리드 클라우드 에이전트 상호 운용성에 주력하고 있습니다. 팀은 서로 다른 환경에서 실행되는 에이전트가 수동 구성 없이 서로를 발견하고 통신할 수 있는 방법을 탐색하고 있습니다.
결론
Bayer는 분석 플랫폼을 ADE로 대체하지 않았습니다. CDE를 더 쉽게 쿼리하고 운영할 수 있도록 만든 것입니다. 프로덕션 작업의 대부분은 프롬프트 밖에 있었습니다: 내구성 있는 상태, 아이덴티티 경계, 도구 범위 지정, 작업 수준의 관측성, 비용 귀속, 출시 준비가 그것입니다. Bayer는 아키텍처와 그 각각의 결정을 소유했습니다. AWS Unified Operations를 통해 지정된 DSE 및 TAM과 협력하면서 팀은 설계 단계에서 이러한 결정들을 AWS 서비스 동작에 대해 검증했고, 동일한 컨텍스트를 프로덕션으로 가져갔습니다.
자세히 알아보려면 다음을 살펴보세요 Amazon Bedrock AgentCore, Amazon Bedrock cost attribution, AWS Well-Architected Generative AI guidance그리고 AWS Unified Operations.
저자들은 ADE의 설계, 개발, 출시에 기여한 Sijie Shi, Jorge Gomes, Naveen Reddy, Iago Fonseca, Mateus Silva, Sushimitha Jarugula에게 감사를 전합니다.