Amazon Bedrock AgentCore로 멀티 데이터소스 자연어 질의 에이전트를 프로덕션에 배포하기

본 글은 AWS Summit Seoul 세션 “200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS”의 내용을 기반으로 작성되었습니다.

개요

생성형 AI는 실험적 프로토타입에서 벗어나, 이제 프로덕션 환경에서 대규모로, 실제 성능 제약 속에서 안정적으로 동작할 것을 요구받고 있습니다. Strands Agents SDK, LangGraph, CrewAI, LlamaIndex 같은 오픈소스 프레임워크의 등장으로 누구나 하루 만에 인상적인 에이전트 프로토타입을 만들 수 있게 되었습니다. 이들 프레임워크는 오케스트레이션, 도구 실행, 멀티 에이전트 협업, 컨텍스트 관리까지 에이전트 개발에 필요한 핵심 기능을 제공합니다.

그러나 실제 서비스를 운영하려고 하면 이야기가 완전히 달라집니다. 프로토타입과 프로덕션 사이에는 분명한 간극이 존재합니다. 수백 명의 동시 사용자에게 안정적으로 응답해야 하고(성능), 새로운 에이전트나 데이터소스가 추가될 때 유연하게 대응해야 하며(확장성), 운영 환경의 민감 데이터에 대한 접근 제어가 되어 있어야 하고(보안), 에이전트가 어떤 판단을 내렸고 어떤 도구를 호출했는지 추적할 수 있어야 합니다(거버넌스).

이 글에서는 삼성전자 TV Apps Service 팀이 LangGraph로 구축한 자연어 질의 에이전트를 기존 코드를 거의 그대로 유지하면서 Amazon Bedrock AgentCore 위에 올려 프로덕션 수준의 운영 자동화를 확보한 과정을 공유합니다. 다른 팀이 같은 전환을 시도할 때 바로 참고할 수 있도록, 실제 구성과 코드, 그리고 시행착오에서 얻은 교훈을 함께 담았습니다.

배경: 프로토타입에서 프로덕션으로 가는 길

삼성 Smart TV 앱 생태계와 비즈니스 과제

삼성 Smart TV의 앱 서비스는 앱 설치와 스토어 운영을 담당하는 대규모 콘텐츠 배포 플랫폼입니다. 그 규모는 전 세계 200여 개국, 수천 종의 앱, 수만 종의 TV 모델과 펌웨어 버전에 이릅니다. 각 앱은 TV 환경에 따라 지원 여부가 결정되고 환경마다 설치되는 최상위 버전이 달라지기 때문에, 데이터 조합의 경우의 수가 대단히 큽니다.

이 방대한 데이터를 여러 팀의 담당자 수백 명이 매일 조회하며 업무를 수행합니다. 문제는 데이터가 한곳에 있지 않다는 점입니다. 검증계·운영계 관계형 DB, 사내 API, 그리고 KPI 분석용 데이터 스토어 등 서로 다른 시스템에 정보가 파편화되어 있습니다. 매일 이런 문의가 쏟아집니다.

문의 하나당 담당자가 검증계 DB, 운영계 DB, KPI 시스템을 개별적으로 조회해야 했고, 응답까지 수십 분이 소요됐습니다. 데이터 파편화로 같은 질문이 여러 담당자에게 분산되어 도착하는 비효율도 컸습니다. 즉, 문제는 “데이터가 없다”가 아니라 “데이터가 어디에 있는지, 어떻게 조합해야 하는지를 사람이 매번 찾아야 한다”는 데 있었습니다.

팀은 이를 해결하기 위해 LangGraph 기반의 자연어 질의 에이전트를 PoC로 구축했습니다. Supervisor 아래에 KPI 조회, 앱 지원 확인, 앱 검색을 담당하는 하위 에이전트를 두는 멀티 에이전트 구조였습니다. PoC는 자동화의 가능성을 성공적으로 입증했습니다.

에이전트 프레임워크의 프로덕션 전환 시 한계

PoC를 실제 프로덕션으로 옮기려 하자 다섯 가지 구조적 한계가 드러났습니다. 이는 어떤 에이전트 프레임워크로 PoC를 하든 프로덕션 문턱에서 공통적으로 마주치는 한계입니다. 프레임워크는 에이전트의 로직(두뇌)을 만드는 도구이지, 그 로직을 안전하고 확장 가능하게 운영하는 레이어까지 책임지도록 설계된 것은 아니기 때문입니다.

멀티 데이터소스 관리 복잡 : 검증계·운영계 DB, KPI 스토어 각각에 대한 연결 코드를 별도로 유지해야 했고, 데이터소스가 추가될 때마다 에이전트 코드를 수정해야 했습니다.
에이전트 기능 동적 확장 불가 : 신규 기능을 추가하려면 에이전트와 Tool 코드를 모두 수정한 뒤 각각 재배포해야 했습니다.
블랙박스 실행 : 실행 과정이 불투명해 응답이 느릴 때 어느 단계가 병목인지 식별할 수 없었습니다.
인프라 운영 부담 : 컨테이너 기반 실행 환경을 직접 관리하고, 스케일링·가용성을 팀이 직접 담당해야 했습니다.
메모리 관리 부담 : 멀티턴 세션을 위해 별도의 상태 저장소를 운영하고 세션 관리 코드를 직접 구현해야 했습니다.

정리하면, 에이전트 프레임워크는 에이전트의 “두뇌”를 만드는 데는 훌륭하지만, 그 두뇌를 안전하고 확장 가능하게 “운영”하는 레이어는 팀이 처음부터 직접 쌓아야 합니다. 삼성전자 팀이 LangGraph에서 겪은 것도 정확히 이 지점이었습니다. 이 다섯 가지는 모두 PoC 단계에서는 보이지 않다가 프로덕션을 향해 갈수록 비용으로 작용하는 항목들입니다.

왜 Amazon Bedrock AgentCore인가

Amazon Bedrock AgentCore는 이 “운영 레이어”의 간극을 메우기 위해 설계된 완전 관리형 플랫폼입니다. Runtime, Gateway, Memory, Identity, Observability, Evaluations, Policy 등 프로덕션에 필요한 구성 요소를 제공하며, 각 서비스를 독립적으로 또는 조합해서 사용할 수 있는 모듈형 구조가 특징입니다.

가장 중요한 점은, AgentCore가 기존 에이전트를 대체하지 않는다는 것입니다. 이미 개발한 LangGraph(또는 Strands, CrewAI 등) 코드를 AgentCore라는 운영 레이어 위에 올리는 구조입니다. MCP(Model Context Protocol), A2A(Agent-to-Agent), AG-UI, OpenTelemetry(OTel) 같은 개방형 표준을 지원하고 주요 프레임워크와 호환되므로, 특정 프레임워크나 모델에 종속되지 않으면서 프로덕션에 필요한 인프라와 거버넌스를 AWS가 제공합니다.

AgentCore의 서비스는 에이전트 라이프사이클에 따라 세 단계로 나뉩니다.

단계	구성 요소	역할
빌드 (Build)	Gateway, Memory, Browser, Code Interpreter, Harness	에이전트가 도구를 사용하고, 기억하고, 웹을 탐색하고, 코드를 실행할 수 있게 합니다
배포 (Deploy)	Runtime, Identity, Policy, Payments	에이전트를 안전하게 대규모로 배포합니다
운영 (Operate)	Observability, Evaluations, Optimization, AWS Agent Registry	에이전트를 지속적으로 모니터링하고 품질을 관리합니다

※ AgentCore는 기능 추가가 빠른 서비스입니다. 위 분류는 집필 시점(2026년 8월) 기준이며, 최신 구성은 공식 문서를 참고하세요.

여기서 주목할 점은, 삼성전자 팀이 기존 LangGraph 그래프 구조(Supervisor + KPI, 앱 지원, 앱 검색 하위 에이전트)를 그대로 유지한 채, 운영 레이어만 AgentCore로 얹는 방향을 택했다는 것입니다. 새로 다 개발하는 것이 아니라, 기존 개발은 살리고 운영을 정리하는 접근입니다.

솔루션 아키텍처

TO-BE 전체 구성

전체 아키텍처는 아래 그림과 같습니다.

요청은 다음 순서로 처리됩니다. 사용자의 자연어 질문은 먼저 Amazon Cognito에서 발급받은 JWT 토큰과 함께 전달되고, AgentCore Inbound authorizer가 이 토큰을 검증합니다. 인증된 요청은 AgentCore Runtime 위에서 실행되는 기존 LangGraph 그래프(Supervisor + 하위 에이전트)로 전달됩니다. 에이전트는 데이터가 필요할 때 여러 데이터소스를 직접 알지 않고 AgentCore Gateway 단일 엔드포인트만 호출합니다. 도구가 많을 때는 에이전트가 Gateway의 시맨틱 검색으로 관련 도구를 먼저 찾고, 선택한 도구를 호출하면 Gateway가 검증계·운영계 DB와 KPI 스토어 중 해당 target으로 요청을 전달합니다. 대화 맥락은 AgentCore Memory가 세션 단위로 유지하고, 모든 실행 단계는 AgentCore Observability를 통해 CloudWatch로 수집됩니다. 여기에 AgentCore Policy(Cedar 기반 read-only 강제)와 AgentCore Evaluations(CI 품질 게이트)가 각각 런타임 보안과 배포 전 품질 검증을 담당합니다.

핵심은 이 모든 운영 레이어가 기존 LangGraph 코드를 감싸는 형태로 사용했다는 점입니다. 에이전트의 핵심 로직은 그대로 두고, 인증·라우팅·메모리·관측·품질 관리를 AgentCore가 담당하는 구조입니다.

AgentCore 컴포넌트 매핑

컴포넌트	역할	삼성전자 적용 방식
Runtime	LangGraph 에이전트 실행 환경	기존 그래프를 코드 변경 없이 마이그레이션, microVM 세션 격리
Gateway	MCP 단일 진입점	검증계·운영계 DB, KPI 스토어, 사내 API를 모두 MCP targets로 통합
Memory	멀티턴 세션 상태 관리	별도 상태 저장소 자체 운영 → 관리형 Short-Term Memory 전환
Observability	실행 trace 수집	OTel 기반 CloudWatch 연동
Evaluations	품질 자동 평가	CI/CD 통합, Tool 선택·응답 품질 검증
Identity	인증/권한	Cognito 연동 인바운드 인증
Policy	Gateway 경유 도구 호출에 대한 인가 정책	자연어로 기술한 규칙을 Cedar 정책으로 생성·검증해 read-only Tool만 허용

구현 상세

발표에서 특히 강조한 Gateway, Observability, Evaluations를 중심으로, Runtime·Memory·Policy까지 다른 팀이 그대로 따라 할 수 있도록 구체적으로 살펴봅니다.

Gateway: 멀티 데이터소스를 하나로 추상화

현업에서 도구를 붙여 쓰려면 시스템마다 인증 방식이 다르고 API 형식도 다릅니다. 이걸 에이전트마다 매번 새로 붙이면 금방 복잡해집니다. 이전 LangGraph 구성에서는 에이전트가 검증계·운영계 각각의 endpoint를 직접 알고 호출했고, 환경이 바뀌거나 새 데이터소스가 추가되면 에이전트 코드를 수정해야 했습니다. AgentCore Gateway 도입 후에는 에이전트가 Gateway 하나만 바라봅니다.

AgentCore Gateway는 세 가지 target 카테고리를 지원합니다.

MCP targets : 여러 백엔드를 하나의 가상 MCP 서버로 집계(aggregation). 시맨틱 검색과 capability 동기화를 지원. 하위 타입으로 Lambda 함수, API Gateway 스테이지, OpenAPI/Smithy 스키마, MCP 서버, 내장 커넥터(Managed Knowledge Base·Web Search) 등이 있습니다.
HTTP targets : 프로토콜 변환 없이 트래픽을 직접 전달.
Inference targets : 여러 모델 공급자로 라우팅.

삼성전자는 세 데이터소스를 모두 MCP targets 카테고리로 등록해, 하나의 통합된 tools/list로 노출되도록 했습니다. 이것이 이후 설명할 시맨틱 검색이 데이터소스 종류와 무관하게 동작하는 핵심 이유입니다.

새 데이터소스가 필요하면 target을 추가하기만 하면 됩니다. 에이전트 코드 변경이나 재배포 없이 새 도구가 즉시 에이전트에게 노출됩니다.

다음은 KPI 조회용 데이터소스를 Lambda function target으로 등록할 때의 일반적인 구성 예시입니다. 고객의 실제 코드가 아니라 공식 문서의 create_gateway_target Boto3 패턴을 기반으로 한 참고용이며, 실제 필드 스키마는 Gateway 지원 target 문서에서 최신 버전을 확인하세요.

import boto3

# AgentCore Control 클라이언트 생성
agentcore_client = boto3.client('bedrock-agentcore-control')

# KPI 조회용 Athena Lambda를 MCP target(Lambda function target)으로 등록
target = agentcore_client.create_gateway_target(
    gatewayIdentifier=GATEWAY_ID,
    name='AthenaKpiTarget',
    description='KPI 조회용 Athena Lambda Target',
    targetConfiguration={
        "mcp": {
            "lambda": {
                "lambdaArn": ATHENA_LAMBDA_ARN,
                "toolSchema": {
                    "inlinePayload": [
                        {
                            "name": "get_app_install_kpi",
                            "description": "국가/앱 단위 설치 및 DAU 등 KPI를 Athena에서 조회합니다.",
                            "inputSchema": {
                                "type": "object",
                                "properties": {
                                    "country": {"type": "string", "description": "ISO 국가 코드"},
                                    "appId": {"type": "string", "description": "앱 식별자"}
                                },
                                "required": ["country"]
                            }
                        }
                    ]
                }
            }
        }
    },
    credentialProviderConfigurations=[
        {"credentialProviderType": "GATEWAY_IAM_ROLE"}
    ]
)

참고로 Gateway를 통해 노출되는 도구 이름에는 AthenaKpiTarget___get_app_install_kpi처럼 target 이름 prefix가 붙습니다. Lambda 함수 안에서는 이 prefix를 직접 제거한 뒤 도구 이름을 분기 처리해야 합니다.

연결이 되면 그 다음 문제는 “무엇을 써야 하느냐”입니다. 도구가 많아질수록 에이전트는 어떤 도구를 써야 하는지 헷갈립니다. 서비스 하나가 수백 개의 도구를 가질 수도 있는데, 모든 도구 정의를 LLM 컨텍스트에 한 번에 넣으면 토큰 비용이 비효율적이고 정확도도 떨어집니다.

Gateway 생성 시 시맨틱 검색을 활성화하면, MCP targets에 등록된 도구가 자동으로 인덱싱됩니다. 에이전트는 전체 도구 목록을 컨텍스트에 싣는 대신 x_amz_bedrock_agentcore_search 도구를 자연어 질의로 호출해 관련성 높은 소수의 도구만 받아온 뒤, 그중 하나를 선택해 실행합니다.

Runtime: 기존 LangGraph를 그대로, 안전하게

에이전트 로직을 완성하는 것과 운영 가능한 서비스로 만드는 것은 다른 문제입니다. 다수의 동시 사용자를 수용하려면 응답 속도, 비용 효율, 보안이 모두 안정적으로 보장되어야 하며, 이 시점부터는 에이전트의 품질만큼 운영 인프라의 완성도가 중요해집니다.

AgentCore Runtime은 테스트 단계의 에이전트를 운영 가능한 형태로 넘겨주는 계층입니다. 프레임워크에 종속되지 않으므로 기존 LangGraph 그래프를 그대로 옮길 수 있고, AgentCore CLI(@aws/agentcore)의 명령 몇 줄로 에이전트를 AgentCore Runtime에 서버리스 방식으로 배포할 수 있습니다. 기존 Python 기반 bedrock-agentcore-starter-toolkit CLI(agentcore configure, agentcore launch)는 공식 저장소 안내에 따라 더 이상 지원되지 않습니다. 기존 Starter Toolkit 프로젝트는 AWS가 관리하는 AgentCore Samples의 마이그레이션 안내를 참고하고, 신규 프로젝트는 AgentCore CLI 공식 개발자 가이드를 참고하세요. 세션별 microVM 격리, 자동 스케일링, 장기 실행 워크로드, 비동기 처리, 양방향 스트리밍, PrivateLink, VPC 기반 보안을 제공합니다. ECS, ALB, Auto Scaling 정책을 직접 구성할 필요가 없습니다.

아래는 LangGraph 그래프를 AgentCore Runtime에 올릴 때의 일반적인 구성 예시입니다. 고객의 실제 코드가 아니라 공식 SDK/CLI 패턴을 기반으로 한 참고용이며, 실제 사용 전 최신 문서로 확인하세요.

from bedrock_agentcore.runtime import BedrockAgentCoreApp

app = BedrockAgentCoreApp()

@app.entrypoint
def invoke(payload, context):
    user_input = payload.get("prompt")
    session_id = context.session_id or "local-session"
    # 기존 LangGraph 그래프를 그대로 호출
    return supervisor_graph.invoke(
        {"messages": [("user", user_input)]},
        config={"configurable": {"thread_id": session_id}}
    )

if __name__ == "__main__":
    app.run()

npm install -g @aws/agentcore
 
agentcore create --framework LangChain_LangGraph  # 신규 프로젝트 스캐폴딩
agentcore dev                                     # 로컬 실행 (핫 리로드)
agentcore deploy                                # AgentCore Runtime에 배포
agentcore invoke "질문을 입력하세요"

특히 다수의 사용자가 동시에 질의를 던지는 환경에서는 세션 격리가 중요합니다. 사용자별 대화와 실행 환경이 섞이면 곧바로 보안 위협이 됩니다.

Runtime은 세션마다 전용 microVM(컴퓨팅, 메모리, 파일)을 할당하고 세션 종료 후 삭제합니다. 덕분에 세션 간 데이터가 섞이거나 상태가 남아 다른 사용자에게 노출될 위험, 그리고 권한 상승 위험을 구조적으로 차단합니다.

Memory: 자체 운영에서 관리형으로

기존에는 멀티턴 대화를 위해 별도의 상태 저장소를 운영하고 세션 관리 코드를 직접 구현해야 했습니다. AgentCore Memory로 전환하면서 이 인프라 운영 부담이 사라졌습니다. Short-Term Memory는 session_id(및 actor_id)를 기준으로 대화 컨텍스트를 자동 관리하므로, 팀은 세션 저장소를 직접 운영하지 않고 에이전트 로직에만 집중할 수 있게 되었습니다. LangGraph와의 연동 시 코드 변경이 거의 필요 없었다는 점 또한 도입 결정의 핵심 요인이었습니다.

Observability: 블랙박스에서 완전 가시화로

에이전트를 운영할 때 가장 무서운 것은 블랙박스입니다. 왜 이런 답이 나왔는지, 어디서 느려졌는지, 어떤 도구 호출에서 문제가 났는지 모르면 운영이 불가능합니다. 기존 LangGraph 환경에서는 응답이 느릴 때 어느 단계가 병목인지 알 수 없었습니다.

AgentCore Observability는 OpenTelemetry 표준으로 에이전트 실행의 모든 단계를 자동 수집합니다.

Sub-Agent 라우팅 흐름 (Supervisor가 어떤 하위 에이전트를 호출했는지)
LLM 호출 (프롬프트, 응답, 토큰 사용량)
Tool 호출 (입력 파라미터, 출력 결과, 실행 시간)
각 span의 실행 시간(duration) – OpenTelemetry 표준 span 속성

이 데이터는 Amazon CloudWatch의 GenAI Observability 대시보드와 Transaction Search에서 즉시 확인할 수 있습니다. OpenTelemetry 호환이므로 CloudWatch뿐 아니라 Datadog 등 기존 모니터링 도구와도 바로 연동됩니다.

Evaluations: 품질을 운영 체계로

가시화만으로는 끝이 아닙니다. 품질을 지속적으로 평가해야 사용자에게 정확한 결과를 주고 신뢰를 쌓을 수 있습니다. 에이전트는 한 번 잘 되는 것보다 계속 기대한 수준을 유지하는 것이 더 중요합니다. AgentCore Evaluations는 기본 제공 평가기(Builtin.Helpfulness 등)와 사용자 정의 평가기를 함께 제공합니다. 평가기는 두 종류로 나뉩니다.

품질, 유용성처럼 판단이 필요한 지표는 LLM 심사자(judge)를 호출해 점수와 심사 근거를 함께 기록하고, Builtin.TrajectoryExactOrderMatch처럼 도구 호출 순서를 검사하는 평가기는 LLM 호출 없이 결정론적으로 통과/실패를 판정합니다. CI 품질 게이트에는 판정이 흔들리지 않는 후자를 하드 게이트로, 전자를 추세 관찰용으로 조합하는 구성이 유용합니다.

평가는 실행 방식에 따라 다음과 같이 나뉩니다.

	On-Demand Evaluation (개발, 조사)	Online Evaluation (프로덕션 모니터링)	Batch Evaluation (회귀, 전후 비교)
동작	span/trace를 직접 지정해 개별 평가	실시간 상호작용 모니터링, 트레이스 지속 샘플링	CloudWatch Logs의 다수 세션을 비동기로 일괄 평가
활용	빌드타임 테스트, 이슈 조사, 수정 검증, 품질 게이트	silent failure 포착, 품질 추세 추적, 배포 후 모니터링	baseline 측정, 프롬프트/모델 변경 전후 비교, 대량 회귀 테스트

삼성전자는 On-Demand Evaluation을 CI/CD 파이프라인에 통합해, 코드 변경이 올라오면 자동으로 평가가 실행되고 품질 기준을 만족하지 못하면 배포가 차단되도록 구성했습니다.

※ 이 구성은 프로젝트 진행 시점(2026년 4월) 기준입니다. 당시에는 On-Demand와 Online 두 가지 방식만 제공되어, 배포 전 품질 게이트로 On-Demand Evaluation을 사용했습니다.

Policy: Read-Only 강제로 사고 차단

사내 사용자가 자연어로 질의를 던지는 환경에서는, LLM이 의도와 다르게 데이터를 변경하는 작업을 시도할 위험을 차단해야 합니다. AgentCore Policy는 정책 엔진(policy engine)을 만들어 Gateway에 연결하는 방식으로 동작하며, Gateway를 경유하는 모든 도구 호출을 가로채 정책을 평가합니다. 정책은 오픈소스 인가 언어인 Cedar로 표현되지만, 개발자가 Cedar 문법을 직접 작성할 필요는 없습니다. “이 에이전트는 읽기 도구만 사용할 수 있고, 삭제·변경 도구는 호출할 수 없다”처럼 자연어로 규칙을 기술하면 서비스가 후보 정책을 생성하고, 도구 스키마에 대해 유효성을 검증한 뒤 자동 추론으로 안전성까지 확인해 줍니다. 덕분에 최소 권한 원칙을 에이전트 코드 수정 없이 적용할 수 있습니다.

정책은 에이전트의 reasoning loop 밖에서, Gateway가 도구 호출을 전달하기 직전에 평가됩니다. 즉 LLM이 어떻게 추론하든 무관하게 허용/차단이 결정론적으로 적용되므로, 프롬프트를 우회하는 시도에도 안전합니다.

실제 동작: 두 가지 데모

데모 1 : Gateway를 통한 멀티 데이터소스 연결

“특정 환경에서 지원되는 앱과 그 KPI를 함께 보여줘” 같은 복합 질문이 들어왔을 때의 실행 과정입니다.

Supervisor가 질문을 분석하고 KPI 조회용 하위 에이전트를 호출합니다.
하위 에이전트가 KPI 조회 쿼리를 작성하고, Gateway의 Lambda function target(KPI 스토어 쿼리 실행)을 호출해 결과를 가져옵니다.
이 결과를 바탕으로 앱 정보, 호환성을 확인하기 위해 별도 하위 에이전트가 호출됩니다. 앱 정보 조회는 Gateway의 MCP server target(DB 쿼리)을 통해 이루어집니다.
호환성 확인 단계에서는 Gateway의 시맨틱 검색을 활용해 특정 환경에서 지원되는 모델을 확인하는 도구를 먼저 찾고, 검색된 도구를 호출해 데이터를 조회합니다.
Supervisor가 여러 하위 에이전트의 결과를 종합해 최종 답변을 생성합니다.

이 구조의 핵심은, Gateway에 동적으로 기능을 확장하더라도 에이전트는 시맨틱 검색을 통해 새로 추가된 도구를 코드 변경 없이 그대로 활용할 수 있다는 점입니다.

데모 2 : Evaluation CI/CD 통합 (실패 → 개선)

CI 파이프라인에서 Evaluation을 실행하면, 에이전트의 입력, Tool 호출 내역, 최종 응답까지 실제 실행 데이터를 기반으로 지표를 측정하고, 조건을 만족하지 못하면 테스트가 실패합니다.

초기 실행 – 실패 케이스 발견

질문: “특정 환경에서 지원되는 앱 리스트를 알려주세요”
관찰: 에이전트는 파라미터를 정확히 추출해 Tool을 호출했고, 지원 앱 리스트를 정상 수신했습니다.
문제: 그러나 최종 응답에 Tool로부터 받은 정보가 포함되지 않았습니다.

Tool 선택은 성공했지만 최종 응답 품질에서 실패한, 사람이 일일이 검증하지 않으면 발견하기 어려운 전형적인 silent failure입니다.

개선 후 – 재수행 통과

이 분석을 바탕으로 프롬프트를 개선하고 테스트를 재수행하자, 실패하던 테스트 케이스가 성공으로 기록되고 각 지표가 사전 설정 기준을 만족했습니다. CI 파이프라인을 통과함으로써 서비스 배포에 필요한 신뢰성을 확보했습니다.

주목할 점은, 사람이 일일이 응답을 뜯어보지 않아도 이 silent failure가 CI 단계에서 자동으로 걸러졌다는 것입니다. 문제 발견 → 수정 → 재검증이 배포 프로세스 안에서 데이터로 이뤄지므로, 품질 관리가 일회성 이벤트가 아니라 배포 프로세스의 일부가 됩니다.

전환 효과

항목	LangGraph PoC (Before)	AgentCore 전환 후 (After)
Gateway	환경별(검증계/운영계) 분기 로직이 코드에 포함, 새 데이터소스 추가 시 에이전트 코드 수정	Target 등록만으로 연결, 동적 라우팅 + 시맨틱 검색
Observability	실행 흐름 불투명, 로그 기반 디버깅	모든 trace 가시화(실행 단계별 추적), CloudWatch 실시간 모니터링
Evaluations	수동 테스트, 품질 기준 없음	자동 평가 + CI/CD 통합, 품질 지표 기반 검증
문의 응답 시간	수십 분 (수동 조회)	자연어 질문으로 즉시 응답
인프라 운영	컨테이너 실행 환경 + 상태 저장소 직접 관리	관리형 Runtime + Memory

수동으로 데이터를 조회하던 업무를 효율화하기 위해 AI 챗봇 PoC를 진행했고, 이를 실제 운영 환경에 배포하기 위해 AgentCore를 적용했습니다. 그 결과 개발 복잡도, 모니터링, 인프라 운영 오버헤드를 제거하고 “사용자에게 어떤 가치를 줄 것인가”에만 집중하여 성공적으로 에이전트를 운영할 수 있게 되었습니다.

핵심 가치 요약

삼성전자 사례가 보여주는 프로덕션 에이전트 운영의 네 가지 핵심 가치입니다.

확장성 (Gateway 기반 데이터 확장) – 단일 진입점으로 다양한 데이터·시스템을 안전하게 연결하고, 새 데이터소스를 코드 변경 없이 추가.
가시성 (Observability 기반 운영 가시화) – 전체 에이전트 동작을 추적·가시화하여 문제 대응 시간 단축.
품질 관리 (Evaluation 기반 지속 개선) – 자동 평가와 품질 게이트로 안정적이고 지속적인 품질 유지.
운영 단순화 (관리형 서비스) – 인프라 운영 부담 없이 에이전트 로직에 집중.

결론

오픈소스 프레임워크로 프로토타입을 만드는 것은 쉽습니다. 그러나 프로덕션은 완전히 다른 문제입니다. 수백 명의 동시 사용자, 새 데이터소스의 유연한 추가, 운영 민감 데이터에 대한 접근 제어, 에이전트 판단·도구 이력의 추적까지 모두 챙겨야 합니다.

Amazon Bedrock AgentCore는 이 간극을 메우기 위해 설계된 관리형 플랫폼입니다. 삼성전자 사례에서 본 것처럼, 기존 LangGraph 코드를 거의 그대로 유지하면서 Runtime, Gateway, Memory, Observability, Evaluations, Policy 같은 운영 레이어를 모듈식으로 얹을 수 있습니다.

바로 시작하는 첫걸음으로는, 여러 데이터소스를 Gateway 단일 진입점으로 통합하는 것을 권합니다. 가장 임팩트가 크고, 가장 위험이 낮습니다. 지금 사용 중인 프레임워크와 모델을 바꿀 필요 없이, 기존 코드 그대로 시작해보세요. 이제 중요한 것은 에이전트를 “만드는” 것이 아니라 “잘 운영하는” 것입니다.

AWS 기술 블로그