Amazon Bedrock AgentCore로 대화형 데이터 분석 에이전트를 프로덕션 아키텍처로 전환하기: SD바이오센서 사례

본 사례는 AWS 3A(Agentic AI Acceleration) 프로그램을 통해 고객과 진행하였습니다. 3A 프로그램은 생성형 AI 에이전트를 프로덕션에 적용하려는 고객을 대상으로, 아키텍처 리뷰와 참조 구현을 제공하는 AWS의 기술 지원 프로그램입니다.

들어가며

에스디바이오센서(SD Biosensor)는 체외진단(IVD)과 바이오센서 분야의 글로벌 기업으로, 진단 장비와 센서에서 생성되는 대규모 데이터를 다룹니다. 이러한 데이터를 담당자가 직접 쿼리를 작성하지 않고 자연어 질문만으로 조회하고 분석할 수 있다면, 데이터 활용의 진입 장벽이 크게 낮아집니다. 이 목표를 위해 대화형 데이터 분석 에이전트를 구축하는 과정에서, 초기 프로토타입은 몇 가지 공통적인 과제를 드러냈습니다. 같은 질문에도 실행 결과가 달라지는 재현성 문제, 여러 에이전트가 컨텍스트를 주고받는 과정에서 발생하는 지연과 비용, 그리고 운영 중 문제가 발생했을 때 원인을 추적하기 어려운 관측성 부족이 대표적입니다.

이러한 과제는 특정 도메인에 국한된 것이 아니라, 대화형 에이전트를 실험 단계에서 프로덕션 단계로 옮길 때 대부분의 팀이 마주치는 공통 주제입니다. 프로토타입 환경에서는 유사한 답변을 생성하는 것으로 충분하지만, 프로덕션에서는 같은 질문에 같은 답을 주는 재현성, 예측 가능한 응답 시간과 비용, 그리고 문제가 생겼을 때 원인을 되짚을 수 있는 추적성이 함께 요구됩니다.

이 글에서는 AWS가 3A 프로그램을 통해 함께 정리한 아키텍처 개선 방향을 기술 관점에서 소개합니다. 특정 업무 로직이 아니라, 대화형 에이전트를 프로덕션 수준으로 끌어올릴 때 일반적으로 적용할 수 있는 설계 패턴에 초점을 맞춥니다. 핵심 실행 기반은 Amazon Bedrock AgentCore이며, 에이전트 로직은 Strands Agents SDK로 구성하였습니다.

전체 아키텍처 개요

먼저 전체 구성을 조망하면 다음과 같습니다. 사용자의 자연어 질의는 AgentCore Runtime에서 실행되는 단일 에이전트로 전달되고, 에이전트는 버전이 고정된 도구 카탈로그를 호출해 데이터를 조회하고 계산합니다. 데이터 저장소와 기반 모델, 그리고 각종 AWS API 호출은 모두 Amazon VPC의 프라이빗 경로를 통해 이루어지며, 실행 흐름은 표준 관측성 계층으로 수집됩니다.

그림 1. 전체 시스템 아키텍처. 단일 에이전트가 AgentCore Runtime에서 실행되고, VPC 엔드포인트를 통해 기반 모델과 데이터 저장소에 프라이빗 경로로 접근하며, 실행 트레이스는 관측성 계층으로 전달된다.

이어지는 절에서는 이 구성을 이루는 개별 설계 결정을, 그 결정이 어떤 문제를 풀기 위한 것이었는지와 함께 하나씩 살펴봅니다.

멀티 에이전트에서 싱글 에이전트로

초기 구조는 오케스트레이터가 요청을 분류해 여러 하위 에이전트(사용자 응대 에이전트, 관리자 에이전트, 코드 실행 에이전트)로 분배하는 멀티 에이전트 형태였습니다. 멀티 에이전트는 역할 분리가 명확하고 각 에이전트의 프롬프트를 독립적으로 관리할 수 있다는 장점이 있지만, 데이터 조회와 수치 계산이 중심인 워크로드에서는 그 장점이 잘 발휘되지 않습니다. 에이전트 사이를 오가며 컨텍스트를 전달할 때마다 추가적인 모델 호출이 발생해 지연과 토큰 비용이 늘어나고, 각 단계에서 대규모 언어 모델(LLM)이 자유롭게 판단하는 지점이 많아질수록 동일 입력에 대한 결과 편차가 발생합니다. 하나의 요청을 처리하기 위해 오케스트레이터가 하위 에이전트를 호출하고, 그 하위 에이전트가 다시 오케스트레이터에 컨텍스트를 넘기는 왕복이 반복되면, 응답 경로가 길어지고 어느 단계에서 값이 달라졌는지 추적하기도 어려워집니다.

개선의 방향은 구조를 단일 에이전트로 단순화하고, 결정론이 필요한 작업을 모델에서 코드로 옮기는 것이었습니다. 단일 에이전트는 버전이 고정된 도구 카탈로그를 직접 호출하며, LLM의 역할은 어떤 도구를 어떤 인자로 부를지 선택하고 그 결과를 자연어로 정리하는 데 한정됩니다. 날짜 구간 계산, 계정 식별, 통계 산출 같은 작업은 모두 순수 함수 도구가 담당하고, 각 도구는 입력 해시(input hash)와 버전을 결과에 함께 기록합니다.

그림 2. 멀티 에이전트 구조와 단일 에이전트 구조의 비교. 왼쪽은 에이전트 사이의 컨텍스트 왕복이 반복되는 구조, 오른쪽은 단일 에이전트가 버전 고정 도구 카탈로그를 직접 호출하는 구조이다.

이 전환으로 얻은 효과는 다음과 같습니다. 동일한 입력에 대해 도구가 항상 동일한 출력을 반환하므로 결과 재현성이 확보되고, 불필요한 에이전트 간 호출이 사라져 지연과 비용이 줄며, 실행 경로가 단순해져 관측과 디버깅이 쉬워집니다. 역할 분리가 필요한 부분은 별도의 에이전트를 두는 대신 도구 카탈로그 안에서 함수 단위로 나누어, 구조의 복잡도를 늘리지 않고도 관심사를 분리할 수 있었습니다.

이러한 판단은 이번 사례에만 국한된 것이 아니라, 업계에서 정리된 일반적인 관점과도 부합합니다. Anthropic은 멀티 에이전트 시스템을 언제·어떻게 사용해야 하는지 다룬 글에서, 적절한 도구를 갖춘 잘 설계된 단일 에이전트만으로도 대부분의 엔터프라이즈 워크플로우를 충분히 처리할 수 있으며, 멀티 에이전트 아키텍처는 컨텍스트 오염 방지, 병렬 처리, 전문화라는 세 가지 조건이 명확할 때에만 추가되는 조율 비용을 상쇄할 만한 가치를 낸다고 설명합니다. 실제로 같은 작업을 수행할 때 멀티 에이전트 구현이 단일 에이전트보다 대체로 3~10배 더 많은 토큰을 소비한다는 관찰도 함께 제시합니다. 데이터 조회와 수치 계산이 중심인 이번 워크로드는 이 세 가지 조건 중 어디에도 뚜렷하게 해당하지 않았고, 오히려 재현성과 결정론이 더 중요한 요구사항이었습니다. 따라서 단일 에이전트로의 단순화는 특정 사례에 맞춘 임기응변이 아니라, 이러한 일반 원칙에 부합하는 설계 선택이었다고 볼 수 있습니다.

결정론을 코드로 옮기기, 그리고 재현성

재현성 문제의 뿌리는 결정론이 필요한 계산을 LLM의 자유로운 판단에 맡긴 데 있었습니다. 예를 들어 기간을 다루는 계산에서 경계값을 모델이 매번 새로 해석하면, 같은 질문이라도 실행할 때마다 미세하게 다른 구간을 대상으로 삼아 결과가 달라질 수 있습니다. 해법은 이러한 계산을 버전이 고정된 순수 함수로 옮기고, 함수의 입력을 표준 형식으로 고정(정규화)한 뒤 그 해시를 결과에 함께 남기는 것입니다. 입력이 표준 형식으로 고정되면 같은 질문은 항상 같은 입력이 되고, 같은 입력은 같은 버전의 함수에서 같은 출력을 보장합니다. 해시는 이 과정을 사후에 검증할 수 있게 하는 추적 장치입니다.

여기에 더해, 답변을 생성한 직후 도구 실행 로그와 응답에 담긴 수치를 대조하는 후처리 검증 게이트를 두었습니다. 이 게이트는 에이전트의 오케스트레이션을 수정하지 않고 출력 단계에 붙이는 독립 계층(비침습적 계층)으로, 도구가 산출하지 않은 수치가 사용자에게 전달되는 것을 차단하는 역할만 담당합니다. 검증은 한 번의 대화 턴이 끝나는 시점에 동작합니다. 그 턴에서 실행된 도구의 입력과 출력을 구조화된 로그로 모으고, 답변 텍스트에서 뽑아낸 수치가 이 로그에 실제로 존재하는지 대조합니다. 근거가 없는 수치가 발견되면 검증 결과를 실패로 기록한 뒤, 도구 산출값을 다시 제시해 답변을 한 차례 재생성하고 같은 검증을 반복합니다. 요청한 기간에 비해 유효한 데이터가 부족한데도 답변이 이를 알리지 않은 경우에는 경고로 표시하고 결측 안내 문구를 덧붙입니다. 검증과 생성을 분리했기 때문에 검증 로직을 독립적으로 강화하거나 교체할 수 있고, 에이전트 본체의 변경 없이도 신뢰성 요건을 높일 수 있습니다.

그림 3. 결정론 도구 실행과 후처리 검증. 정규화된 입력이 재실행 사이의 결과 일관성을 보장하고, 입력 해시가 이를 사후에 검증할 수 있게 하며, 후처리 게이트가 도구 로그와 응답 수치를 대조한다.

이 구조에서 LLM은 여전히 중요한 역할을 합니다. 사용자의 모호한 표현을 해석해 적절한 도구와 인자를 선택하고, 도구가 돌려준 결과를 사람이 읽기 좋은 설명으로 정리합니다. 다만 값 자체를 만들어 내는 책임은 지지 않습니다. 판단은 모델이, 계산은 코드가 담당하는 이 분업이 재현성 확보의 핵심입니다.

코드 실행 레인 분리, Code Interpreter와 SageMaker Processing

에이전트가 실행하는 코드는 성격이 서로 다릅니다. 분포를 그리거나 간단한 요약 통계를 계산하는 경량 작업이 있고, 대량 데이터를 처리하거나 머신러닝 모델을 학습하고 추론하는 장시간 작업이 있습니다. 이 둘을 하나의 실행 환경에 몰아넣으면, 짧은 요청이 무거운 작업의 대기열에 묶이거나 반대로 무거운 작업이 대화형 응답 시간을 초과하는 문제가 생깁니다.

이를 위해 코드 실행을 세 개의 레인으로 나누었습니다. 검증이 필요한 핵심 수치는 에이전트 프로세스 안의 결정론 도구가 즉시 계산합니다. 자유형 그래프처럼 그때그때 코드를 생성해야 하는 가벼운 작업은 Amazon Bedrock AgentCore Code Interpreter의 관리형 샌드박스에서 수 초 내에 실행합니다. Code Interpreter는 격리된 환경에서 임의의 파이썬 코드를 안전하게 실행하고, 데이터는 세션에 결정론적으로 주입되므로 에이전트가 직접 데이터베이스에 접근할 필요가 없습니다. 반면 대규모 스캔, AI 모델 정확도 지표 산출, 시계열 예측 모델 학습처럼 오래 걸리는 작업은 Amazon SageMaker Processing 잡으로 분리해 비동기로 실행합니다.

그림 4. 코드 실행 레인 분리. 사전에 정의한 범위표를 기준으로 검증용 수치는 결정론 도구로, 경량 작업은 Code Interpreter로, 장시간 작업은 SageMaker Processing으로 라우팅하며, 결정론 도구와 SageMaker Processing은 동일 버전의 분석 카탈로그 코드를 실행한다.

라우팅은 모델의 즉흥적인 판단에 맡기지 않았습니다. 분석 항목마다 어느 레인에서 실행할지를 미리 정해 둔 범위표를 두고, 에이전트가 실행 전에 이 표를 도구로 조회해 레인을 결정합니다. 검증이 필요한 수치는 결정론 도구, 가볍고 빠른 통계와 자유형 그래프는 Code Interpreter, 머신러닝 학습과 규제 대응 정확도 산출처럼 오래 걸리는 작업은 SageMaker Processing으로 배정됩니다. 실행 위치를 미리 고정한 덕분에 대화형 응답 시간은 무거운 작업의 영향을 받지 않고, 무거운 작업은 대화 흐름을 막지 않은 채 충분한 리소스에서 실행됩니다. 결정론 도구 레인과 SageMaker Processing 레인은 동일한 버전의 분석 카탈로그 코드를 실행하도록 설계하여, 어느 경로로 실행하든 결과가 일치하고 사후에 재현할 수 있습니다.

AgentCore Runtime 기반 배포

에이전트는 Amazon Bedrock AgentCore Runtime에 배포하였습니다. AgentCore Runtime은 에이전트를 서버리스로 실행하고 세션 단위로 격리하는 관리형 실행 환경으로, 인프라 운영 부담 없이 확장이 가능합니다. 세션 격리는 사용자별 요청이 서로의 상태에 영향을 주지 않도록 보장하며, 서버리스 실행 모델은 트래픽이 없을 때 유휴 비용을 발생시키지 않습니다.

이번 구성에서는 Amazon VPC의 프라이빗 서브넷에서 ARM64로 런타임을 구동하고, 데이터베이스와 시크릿, 그리고 각종 AWS API 호출은 인터페이스 및 게이트웨이 VPC 엔드포인트를 통해 프라이빗 경로로 처리하였습니다. 트래픽이 퍼블릭 인터넷을 경유하지 않으므로 데이터 이동 경로가 VPC 내부로 제한되고, 보안 그룹과 엔드포인트 정책으로 접근 범위를 세밀하게 통제할 수 있습니다. 응답은 스트리밍으로 전달되어 사용자는 답변이 생성되는 즉시 확인할 수 있습니다.

기반 모델은 Amazon Bedrock에서 제공하는 최신 Anthropic Claude 모델을 사용하였고, 데이터는 Amazon RDS for PostgreSQL에, 대화 이력과 알림은 Amazon DynamoDB에, 스냅샷과 산출물은 Amazon S3에 저장하였습니다. 각 저장소는 데이터의 접근 패턴에 맞추어 선택하였으며, 관계형 조회가 필요한 데이터는 PostgreSQL, 키 기반의 빠른 조회가 필요한 대화와 알림은 DynamoDB, 대용량 바이너리 산출물은 S3가 담당합니다.

비동기 작업 완료 알림

SageMaker Processing 잡처럼 수 분이 걸리는 작업은 대화형 요청과 응답의 틀에 담기 어렵습니다. 사용자가 매번 완료 여부를 되묻지 않도록, 작업 완료를 이벤트 기반으로 감지해 채팅으로 되돌리는 통로를 구성하였습니다. 잡 상태 변경은 Amazon EventBridge 이벤트로 감지하고, AWS Lambda 함수가 완료 알림을 DynamoDB 인박스에 적재합니다.

그림 5. 비동기 작업 완료 알림 흐름. 예약 또는 요청으로 실행된 비동기 작업의 상태 변경을 EventBridge가 감지하고, Lambda가 완료 알림을 DynamoDB 인박스에 적재하며, 채팅 세션이 이를 비소진 방식으로 조회한다.

알림에는 대상과 기간 정보를 함께 실어 여러 작업을 동시에 실행해도 어떤 요청의 결과인지 구분할 수 있게 하였습니다. 또한 알림은 조회하더라도 소진되지 않고 이력으로 보존되므로, 사용자가 자리를 비운 사이 지나간 결과도 다시 확인할 수 있고 세션이 바뀌어도 이전 작업의 결과를 되찾을 수 있습니다. 이 설계는 비동기 작업의 결과가 사용자에게 도달하지 못한 채 사라지는 상황을 방지합니다.

예약 및 반복 작업

정기 리포트나 조건부 감시처럼 사람이 매번 요청하지 않아도 실행되어야 하는 작업은 Amazon EventBridge Scheduler로 예약합니다. 매일 정해진 시각의 반복 실행, 일정 간격의 폴링, 특정 시각 1회 실행, 조건 충족 시에만 알림을 보내는 임계 감시를 지원합니다. 예약된 작업 역시 앞 절에서 설명한 비동기 알림 통로를 그대로 사용하므로, 사용자가 접속해 있지 않은 시점에 실행된 결과도 다음 접속 시 확인할 수 있습니다.

예약 시각을 모델이 직접 계산하지 않고 사용자의 표현을 코드가 정확한 스케줄 식으로 확정하도록 하여, 상대 시각이나 반복 규칙이 어긋나는 오류를 방지하였습니다. 이는 결정론을 코드로 옮긴다는 앞서의 원칙을 예약 영역에도 동일하게 적용한 것으로, 자연어로 표현된 일정을 해석하는 일은 모델이, 그 일정을 정확한 실행 규칙으로 고정하는 일은 코드가 담당합니다.

멀티모달 입력

사용자는 텍스트 질문뿐 아니라 이미지나 문서를 첨부해 질문할 수 있습니다. 첨부 파일은 S3에 저장한 뒤 런타임이 이를 조회하여, Amazon Bedrock의 멀티모달 모델에 이미지 블록 또는 문서 블록으로 전달합니다. 이를 통해 화면 캡처나 보고서 형태의 PDF를 그대로 첨부해 내용을 확인하고 질문에 반영할 수 있습니다.

첨부 파일을 다룰 때는 클라이언트가 보고한 형식을 그대로 신뢰하지 않고 파일의 실제 바이트를 확인해 형식을 판별하도록 하여, 잘못된 형식이나 위험한 콘텐츠가 그대로 저장되고 노출되는 경로를 차단하였습니다. 이렇게 판별된 이미지와 문서만이 모델 입력으로 구성되므로, 멀티모달 입력 경로가 새로운 보안 취약점이 되지 않도록 관리할 수 있습니다.

관측성

에이전트 운영에서 관측성은 선택이 아니라 필수입니다. 턴 단위의 도구 호출, 모델 토큰 사용량과 비용, 세션과 사용자 정보를 OpenTelemetry 표준으로 수집하도록 계측하고, Amazon Bedrock AgentCore Observability로 실행 흐름을 추적할 수 있게 구성하였습니다. 표준 프로토콜로 계측했기 때문에 관측 데이터를 AgentCore Observability와 자체 호스팅 도구로 동시에 전송할 수 있고, 운영 환경의 요건에 따라 수집 대상을 유연하게 확장할 수 있습니다.

그림 6. 관측성 파이프라인. 턴 단위로 계측된 도구 호출과 토큰 사용량, 비용, 세션 정보를 OpenTelemetry로 수집하고, 턴 종료 시점에 강제로 내보내 실행 기록의 유실을 방지한다.

트레이스는 턴 종료 시점에 강제로 내보내도록 하여, 런타임이 응답 후 세션을 종료하더라도 해당 턴의 도구 실행 기록이 유실되지 않습니다. 이를 통해 어떤 질의가 어떤 도구를 호출했고 얼마의 비용이 발생했는지를 운영자가 한눈에 확인할 수 있으며, 문제가 보고되었을 때 해당 턴의 실행 경로를 그대로 되짚어 원인을 좁힐 수 있습니다.

여기서 관측 데이터를 Amazon Bedrock AgentCore Observability와 Langfuse(오픈소스 LLM 관측성 플랫폼) 두 곳으로 함께 보내는 구성이 도구를 중복해서 쓰는 것은 아닌지 의문이 들 수 있습니다. 그러나 두 도구는 서로 다른 강점을 가지며 상호 보완적으로 동작합니다. AgentCore Observability를 사용하면 AgentCore가 제공하는 평가(evaluation)와 최적화(optimization) 기능과 자연스럽게 연계되어, 수집한 트레이스를 에이전트 품질을 개선하는 흐름으로 이어갈 수 있습니다. 반면 Langfuse는 트레이스와 세션을 시각적으로 탐색하고 비교·분석하는 데 강점이 있어, 보다 직관적인 시각적 분석이 필요할 때 유용합니다. 앞서 OpenTelemetry 표준으로 계측했기 때문에 동일한 관측 데이터를 두 도구에 동시에 전송할 수 있고, 운영자는 상황과 목적에 따라 원하는 관측성 도구를 알맞게 골라 사용할 수 있습니다.

도입 효과 정리

이번 개선은 새로운 기능을 더하기보다, 대화형 에이전트가 프로덕션에서 신뢰받기 위한 성질을 구조적으로 확보하는 데 초점을 두었습니다. 개선 전후의 아키텍처 특성을 정리하면 다음과 같습니다.

이 표의 각 항목은 특정 업무 로직이 아니라 에이전트 아키텍처 자체의 성질에 대한 것으로, 유사한 대화형 데이터 분석 워크로드에 공통적으로 적용할 수 있습니다.

마치며

이번 사례의 핵심은 기능의 양을 늘린 것이 아니라, 대화형 에이전트가 프로덕션에서 신뢰받기 위해 필요한 성질을 구조적으로 확보한 것입니다. 결정론이 필요한 부분은 모델에서 코드로 옮겨 재현성을 확보하고, 실행 성격에 따라 코드 실행 레인을 분리하며, 비동기 작업과 예약 작업을 이벤트 기반으로 처리하고, 관측성을 표준으로 갖추는 방향입니다. Amazon Bedrock AgentCore는 이러한 패턴을 서버리스 실행, 격리된 코드 실행 환경, 표준 관측성으로 뒷받침하여, 에이전트 개발팀이 인프라가 아닌 에이전트의 품질에 집중할 수 있게 합니다.

AWS 3A 프로그램은 이처럼 고객이 이미 보유한 아이디어를 프로덕션 아키텍처로 구체화하는 과정을 아키텍처 리뷰, 모범 사례 제시, 참조 구현으로 지원합니다. 유사한 에이전트 워크로드를 준비하는 팀이라면, 여기에서 소개한 설계 패턴이 출발점을 잡는 데 도움이 되기를 바랍니다.

본 사례에서 다루는 데이터는 장비 운영·품질관리·비즈니스 데이터로, 환자 식별정보나 임상 검사결과는 포함하지 않습니다.