조직의 AI 전환(AX)을 위해서는 구성원이 AI로 업무에 필요한 정보를 찾고, 그 과정에서 만든 도구와 지식을 다른 구성원도 활용할 수 있어야 합니다. 또한 조직은 누가 얼마나 썼는지 알아야 하고, 사내 시스템과 안전하게 연결되어야 하고, 한 팀이 만든 것을 다른 팀이 다시 만들지 않아야 합니다. 이 문제가 해결되지 않으면 에이전트는 개인 PC 안에 머물고, 조직의 AX는 시작되지 않습니다.

이 설계 목표는 새로운 업무가 추가될 때 기존 시스템과의 연결과 운영 체계를 재사용하는 데 있습니다. 데이터를 연결하는 방식, 에이전트를 실행하는 환경, 조직 안에서 공유하는 절차를 공통 기반으로 만들고, 각 업무에 필요한 지식과 도구를 그 위에 더할 수 있도록 했습니다. 이 글에서는 그 기반을 어떻게 구성했는지, 각 설계가 조직의 AI 활용에 어떤 의미를 갖는지 살펴봅니다.

1. 조직의 AX 도입이 요구하는 세 가지

개인이 AI를 쓰는 것과 조직이 AI를 쓰는 것은 다른 문제입니다. 개인은 브라우저에서 챗봇을 열고 질문하면 됩니다. 하지만 조직에서는 질문에 답할 데이터가 사내 시스템 안에 있고, 그 데이터에 접근할 권한이 사람마다 다릅니다. 그리고 개인이 만든 도구가 다른 사람에게 공유되지 않으면, 유사한 에이전트나 MCP를 중복해서 만드는 일이 반복됩니다. 조직에서 사용하는 에이전트가 수십 개가 되었을 때, 조직의 AX 관점에서 에이전트를 운영하고 공유하기 위한 플랫폼 기반이 필요합니다. 이를 위해 경신홀딩스가 AI 플랫폼을 설계하며 정리한 요구사항은 다음 세 가지였습니다.

1.1 사내 데이터를 안전하게 연결하는 방식

업무에 필요한 답은 대부분 사내 시스템 안에 있습니다. 경신홀딩스의 경우 생산과 품질 데이터는 MS-SQL 서버에, 구매와 회계 데이터는 SAP에 있었습니다. 에이전트가 자연어 질문을 받아 이 시스템들을 대신 조회하려면, 각 시스템으로 연결되는 구성이 먼저 만들어져야 합니다.

문제는 이 연결이 부서와 업무마다 따로 만들어지기 쉽다는 점입니다. 품질팀 에이전트가 MS-SQL에 연결하는 코드를 만들고, 생산팀 에이전트가 같은 서버에 다른 방식으로 연결하면, 접속 정보는 여러 곳에 흩어지고 보안 정책을 바꿀 때마다 모든 곳을 고쳐야 합니다. 조직에 필요한 것은 데이터 소스마다 한 번 연결하고, 그 연결을 여러 에이전트가 공통으로 사용하는 구조입니다. 인증 정보는 에이전트 코드가 아니라 플랫폼이 관리하고, 어떤 사용자가 어떤 데이터에 접근할 수 있는지도 연결 지점에서 중앙 관리되어야 합니다.

1.2 에이전트를 실행하고 운영하는 환경

에이전트를 만드는 것과 운영하는 것은 별개의 일입니다. 개인 PC에서 동작하던 에이전트를 조직 단위로 운영하려면 사용자별 세션 격리, 로그인과 역할, 대화 기억, 도구 연결, 사용량과 비용 집계, 유해 입력 차단 등을 공통으로 처리하고 운영을 위한 확장을 고려해야 합니다.

실행과 운영 환경은 하나로 표준화하고, 각 팀은 그 위에 자신의 에이전트 로직만 올리는 방식이어야, 모니터링과 비용 관리가 한 곳에서 이루어지고, 새로운 에이전트를 추가할 때 인프라를 다시 고민하지 않게 됩니다.

1.3 공통 애셋을 조직 안에서 공유하는 절차

AX가 확산되는 조직에서는 구성원 스스로 에이전트를 만들기 시작합니다. 개인이 만든 MCP 서버나 스킬 문서를 다른 팀이 찾아 쓰려면 카탈로그가 있어야 하고, 사내 데이터에 연결된 도구를 누가 승인해서 공개하는지 정해야 합니다. 승인 절차 없이 공유하면 검증하지 않은 도구가 사내 데이터에 연결될 수 있습니다. 그래서 에이전트를 등록하고, 검색하고, 다른 구성원이 가져다 쓸 수 있는 절차가 필요합니다. 등록 시점에 이 에이전트가 어떤 데이터에 접근하고 어떤 권한이 필요한지 확인되어야 하며, 공유된 뒤에는 누가 사용하는지 추적되어야 합니다. 이 절차가 있어야 한 팀의 경험이 조직의 자산으로 축적됩니다.

데이터 연결이 공통화되어야 실행 환경에서 재사용할 수 있고, 실행 환경이 표준화되어야 등록과 공유에 의미가 있습니다. 경신홀딩스는 Amazon Bedrock AgentCore를 활용해 이 세 가지 요구사항을 하나의 플랫폼으로 구성했습니다. 다음 섹션에서는 이 플랫폼의 전체 구조를 살펴봅니다.

2. 전체 아키텍처

개발자에게 필요한 것은 모델이고, 임직원에게 필요한 것은 사내 데이터에 연결된 에이전트입니다. 그래서 조직이 통제하는 단위도 다릅니다.

그림 1. 개인 도구 경로와 업무 에이전트 경로, 그리고 공통 거버넌스 레이어

2.1 LLM Gateway: 모델 호출을 통제

Claude Code는 이미 완성된 도구입니다. 조직이 그 안에서 일어나는 일을 관리할 필요는 없고, 모델 호출만 통제하면 됩니다. 누가 어떤 모델을 얼마나 사용했는지, 접근 키를 어떻게 발급하고 회수하는지가 관리의 핵심입니다. 이를 위해 Amazon Elastic Kubernetes Service(Amazon EKS) 위에 LLM Gateway를 구축했습니다. 개발자는 Microsoft Entra ID로 인증한 뒤 Virtual Key (VK)를 발급받고, Claude Code는 이 키로 Gateway를 거쳐 Bedrock의 Claude 모델을 호출합니다. 모든 사용량이 VK 키에 귀속되므로 조직은 개인별 모델 사용 현황을 바로 얻습니다. LLM Gateway 구축에 대한 자세한 아키텍처는 이 블로그 글을 참조할 수 있습니다.

2.2 Agent Gateway: 에이전트 호출을 통제

일반 임직원에게 필요한 것은 모델 호출이 아니라 사내 데이터에 연결된 업무용 에이전트입니다. 여기서 조직이 알고 싶은 것은 “누가 어떤 에이전트로 어떤 데이터에 접근했는가”입니다. 임직원은 회사 시스템과 동일한 SSO로 인증해 에이전트 플랫폼에 접속하고, 플랫폼에 등록되어 있는 업무용 에이전트를 호출합니다. 에이전트는 자율적으로 움직이며 턴 별 사용량을 예측하기가 더욱 어렵기에, Agent Gateway를 통해 에이전트를 호출 단위로 통제하여, 누가 어떤 에이전트를 몇 턴 호출했고 토큰과 도구 호출이 얼마였는지를 사용자 기준으로 기록합니다.

2.3 전체 아키텍처

개발자가 접속하는 LLM Gateway 와 일반 임직원이 접속하는 에이전트 플랫폼의 경로는 구분됩니다. 이 글은 에이전트 플랫폼과 웹 검색이 가능한 범용 에이전트, 사내 시스템과 연결되는 업무용 에이전트가 어떻게 구현되어 있는지에 집중하여 서술합니다.

그림 2. 전체 아키텍처: LLM Gateway와 에이전트 플랫폼, 업무용 에이전트 2종

에이전트 플랫폼은 임직원이 업무용 에이전트를 사용하는 진입점으로, 구축된 에이전트들은 플랫폼을 통해 질의할 수 있습니다. 대표적인 업무용 에이전트는 사내 DB 시스템에 저장된 내용들을 분석 및 조회하기 위한 Text-2-SQL 에이전트와 SAP 조회를 위한 에이전트 두 가지입니다. 상세 구현 내용은 아래에서 단계별로 소개합니다.

에이전트 플랫폼의 전체 데모는 아래 영상으로 확인할 수 있습니다.

2.4 에이전트를 사내 시스템과 연결하기 위한 방법

두 업무 에이전트는 사내 데이터와 연결된 기존 시스템을 바꾸지 않고, 그 앞에 AgentCore Gateway를 두는 방식으로 사내 데이터를 MCP 도구로 만들었습니다. AgentCore Gateway는 AWS Lambda함수, OpenAPI 명세, Smithy 모델, Amazon API Gateway REST API, 기존 MCP 서버, 그리고 Web Search와 Knowledge Bases 같은 빌트인 커넥터를 타깃으로 등록하면 이를 MCP 도구 목록으로 노출하고, 인바운드 인가(AWS Identity and Access Management(IAM) 또는 사용자 정의 JWT)를 한곳에서 처리합니다.

그림 3. AgentCore Gateway를 통한 사내 데이터의 MCP 도구 노출 패턴

데이터베이스처럼 API가 없는 시스템은 Lambda로 감싸서 등록하고, OpenAPI 타깃에는 프라이빗 엔드포인트를 지정해 Amazon Virtual Private Cloud(Amazon VPC) 안이나 VPC에 연결된 온프레미스 자원에 인터넷 노출 없이 연결할 수 있습니다. 에이전트는 MCP 클라이언트로 Gateway에 사내 데이터들을 MCP로 호출할 수 있습니다.

인바운드 인가는 Amazon Cognito 사용자 풀의 M2M(machine-to-machine) 클라이언트가 발급한 JWT로 처리합니다. AgentCore Runtime의 에이전트는 AWS Secrets Manager에서 클라이언트 자격 증명을 읽어 토큰을 받고, 그 토큰으로 Gateway에 접속합니다. 에이전트 코드에는 DB 접속 정보도, SAP 인증 로직도 없습니다. 기존 시스템 쪽 변경은 MS-SQL에 읽기 전용 계정 하나를 추가한 것과 SAP API 서버의 OpenAPI 명세를 정리한 것뿐입니다.

3. 업무 에이전트 구성

그림 4. Agent Platform Chats 화면: Registry에 등록된 에이전트를 선택하여 대화

경신홀딩스는 하나의 에이전트에 모든 기능을 붙이는 대신, 명확히 직무가 정해진 특화 에이전트 3종을 만들었습니다. 사내 DB와 SAP와 연결되는 에이전트는 각각이 구분되고, 이 에이전트들은 에이전트 플랫폼 내에서 호출됩니다.

3.1 웹 검색이 가능한 범용 에이전트

그림 5. 범용 에이전트 대화 화면: 에이전트별 토큰 사용량 분석과 Code Interpreter 실행 결과

기본이 되는 에이전트는 일반적인 지식에 대해 질의할 수 있는 범용 에이전트입니다. 외부 AI서비스를 사용하지 않더라도 Bedrock을 통해 외부 모델에 데이터가 전달되지 않는 시스템을 구성하고, 최신 정보를 검색하기 위한 검색 도구를 사용합니다. 모든 임직원이 사용하는 에이전트로써 잘못된 요청에 대한 차단과 추적이 필요합니다.

그림 6. 웹 검색이 가능한 범용 에이전트 구성

플랫폼의 기본 에이전트는 Gateway의 내장 Web Search Tool 커넥터와 유틸 도구 Lambda 함수의 도구 3종(계산, 현재 시각, URL 조회)을 호출합니다. AgentCore Web Search Tool은 외부 검색 API 키나 쿼터 관리가 필요 없는 완전관리형 도구입니다. AWS는 검색 쿼리를 서드파티 검색 엔진으로 보내지 않고 AWS 안에서 처리합니다. AWS가 소유한 인덱스로 검색하며, 질의를 서드파티 검색 엔진으로 보내거나 AWS 바깥으로 라우팅하지 않습니다. 이 에이전트에는 Amazon Bedrock Guardrails를 적용해 입력을 필터링합니다.

3.2 Text-to-SQL 에이전트

그림 7. Text-to-SQL 에이전트 대화 화면: 자연어 질문에 대한 SQL 실행 결과와 차트 생성

Text-to-SQL 에이전트는 사내 정보시스템(MS-SQL)에 자연어로 질문하면 SQL을 만들어 실행하고 표, 차트, 자연어로 답합니다. 대상은 사내망에 위치한MS-SQL 데이터베이스로, 기존 DB는 변경하지 않고 그대로 MCP 서버로서 활용할 수 있도록 구성했습니다. Strands Agents 단일 에이전트로 구현되었고, 배포 기본 모델은 Claude Opus 5입니다. 구현된 에이전트는 AgentCore Runtime를 통해 배포되어, 세션마다 격리된 microVM에서 에이전트를 실행합니다.

아키텍처 구성

그림 8. Text-to-SQL 에이전트 구성: AgentCore Gateway로 연결된 사내 MS-SQL 접속 MCP 도구

AgentCore Gateway는 DB 서버당 AWS Lambda 함수 1개를 타깃 1개로 등록하여 각각을 MCP 도구로 노출하고, DB에 접속하기 위한 인증 정보는 AWS Secrets Manager에 저장하여 사용합니다. VPC 피어링을 통해 외부 인터넷을 통하지 않고 AWS 인프라 위의 사내 DB 시스템과 안전하게 연결됩니다.

사용자와의 대화 기록을 유지하기 위해 AgentCore Memory를 사용하고, SQL문을 통해 얻어온 데이터를 분석하기 위해 AgentCore의 내장 툴인 Code Interpreter tool을 사용합니다.

이 에이전트의 설계 기준은, 새로운 DB 테이블이 추가되어도 에이전트의 로직을 변경하지 않고 쉽게 에이전트에 도메인 지식을 주입하는 것이었습니다. 에이전트가 스스로 접근 가능한 DB를 조회하고, 테이블과 컬럼에 대한 정보를 획득하여 질의에 맞는 SQL을 생성할 수 있도록 구성하였습니다. 추가로 도메인 전문가가 테이블 설명을 마크다운 형태의 Skills 문서로 작성하면, 에이전트가 해당 문서를 참고하여 빠르고 정석적으로 SQL문을 생성할 수 있도록 설계했습니다. 에이전트가 접근하기 위한 읽기 전용 권한 작업과 담당자의 Skills 작성 작업 두 가지만으로, 기존 DB 시스템을 에이전트가 접근하기 위한 MCP 서버로 전환할 수 있었습니다.

Lambda에 구현되어 Gateway로 노출된 MCP 도구는 7종입니다.

에이전트 동작 과정

동작 과정은 다음과 같습니다. “2025년 업체별 금형비 지급 랭킹을 보여줘”라는 질문이 들어오면 에이전트는 다음 순서로 움직입니다.

1. 시스템 프롬프트에 정의된 작업 순서와 MS-SQL 문법 규칙, 자가 검증 규칙을 따릅니다. 어떤 DB를 볼 수 있는지도 여기서 확인합니다.
2. 해당 도메인의 스키마 정보를 담은 스킬 문서를 읽습니다.
3. 도구를 호출해 탐색합니다. 서버와 DB 목록 조회, 테이블 후보 선택, 컬럼 설명 확인, 관계(FK) 확인, 샘플 행을 확인합니다.
4. 검증된 예시 쿼리(도메인 전문가가 작성한 Skills)를 참조해 SQL을 생성하고, 실행 전 문법을 검증한 뒤 실행합니다.
5. 오류가 나면 오류 메시지를 바탕으로 쿼리를 교정합니다.
6. 결과를 표와 차트, 자연어 해석으로 돌려줍니다. 차트 생성과 수치 검증 코드는 AgentCore Code Interpreter 샌드박스에서 실행합니다.

초기 멀티 에이전트 구조에서 단일 에이전트와 Skills 조합으로 아키텍처를 변경 했을 때, 실행 시간은 약 3배에서 5배까지 개선되었고 (172 초 → 56 초, 140~190 초 → 약 30 초), 도메인 전문가가 작성한 Skills을 도입했을 때 동일 질문에 대한 에이전트의 도구 호출 횟수는 8회에서 1회까지 감소되었습니다.

보안 검토

사용하고 있는 사내 DB에 에이전트가 접근하는 작업이다보니, 아래와 같은 보안 요소들을 검토 및 도입했습니다.

• DB 계정은 읽기 전용이며, Lambda는 Secrets Manager에서 이 계정의 자격 증명만 읽을 수 있습니다.
• Lambda는 SQL 파서(sqlglot)로 SELECT만 허용하고 DDL과 DML은 실행 전에 거부합니다.
• Lambda는 VPC 프라이빗 서브넷에 있고, Secrets Manager와 Amazon CloudWatch Logs 호출은 VPC 엔드포인트를 씁니다.
• 실행된 모든 SQL과 거부된 시도는 CloudWatch Logs에 감사 로그로 남습니다.

3.3 SAP 에이전트

AWS는 SAP S/4HANA와 ECC의 OData 서비스를 MCP 도구로 노출하는 AWS for SAP MCP Server를 제공합니다. 다만 경신홀딩스는 SAP 데이터를 REST API로 노출하는 자체 API 서버를 이미 운영하고 있었기 때문에, SAP에 직접 붙는 대신 이 API 서버를 경유했고, 에이전트가 연결되기 위해 SAP시스템과 REST API 서버 모두 그대로 사용했습니다.

아키텍처 구성

그림 9. SAP 에이전트 구성: OpenAPI 타깃과 REQUEST Interceptor를 통한 사내 인증 주입

기존 시스템을 MCP서버로 사용하기 위해 OpenAPI 명세를 정리해 Amazon Simple Storage Service(Amazon S3)에 올리고 Gateway 타깃으로 등록하면, 그대로 MCP 서버화 하여 사용할 수 있습니다. 기존API 서버의 모든 API를 노출할 필요 없이 OpenAPI 명세서에 기입된 API만 MCP 도구로써 노출됩니다.

MCP 도구 호출을 위한 인증

경신홀딩스는 고유의 인증 절차를 갖고 있습니다. 인증 API 서버에서 발급하는 특수한 토큰을 발급받아야 하고, 토큰은 일정 시간 후 만료되며, 매 요청마다 토큰과 서비스 식별 헤더를 함께 보내야 합니다. 표준 OAuth 흐름이 아니므로 Gateway의 기본 아웃바운드 인증으로는 처리할 수 없습니다.

여기에 AgentCore Gateway의 Interceptor를 사용했습니다. Interceptor는 Gateway가 타깃을 호출하기 전(REQUEST)과 응답을 돌려주기 전(RESPONSE)에 실행되는 Lambda 함수로, 요청과 응답을 검증하거나 변형할 수 있습니다. 경신홀딩스 구성의 REQUEST Interceptor는 다음을 수행합니다.

1. Secrets Manager에서 경신홀딩스 인증서버에 접근하기 위한 자격 증명을 읽습니다.
2. 캐시된 토큰이 유효하면 재사용하고, 만료되었으면 토큰 API를 호출해 갱신합니다. 활성 토큰 충돌로 401이 돌아오면 캐시를 무효화하고 다시 발급합니다.
3. 요청 헤더에 토큰과 서비스 식별자를 삽입해 Gateway에 돌려줍니다.

Gateway는 보강된 요청을 프라이빗 엔드포인트로 내보냅니다. OpenAPI 타깃은 인터넷에 없는 사내 서버이므로 Amazon VPC Lattice 리소스 게이트웨이를 프라이빗 엔드포인트로 쓰고, 요청 시 Interceptor Lambda 함수는 VPC 서브넷에서 AWS Transit Gateway로 사내망에 도달합니다. 인증 서버를 통과한 요청만 SAP 데이터에 접근하고, 에이전트는 이 과정을 알지 못합니다. 토큰 수명과 갱신 로직은 Lambda 한 곳에만 있습니다.

4. 에이전트를 만들고 운영하는 플랫폼: 에이전트 플랫폼

에이전트 하나를 만드는 일과 조직이 에이전트를 운영하는 일은 다릅니다. 구성원이 늘수록 원하는 에이전트의 형태가 달라지고, 각자가 특화된 에이전트를 직접 만들어 쓰는 형태로 발전하게 됩니다. 이를 위해 조직은 AX의 기반이 되는 에이전트 플랫폼이 필요합니다. 에이전트 플랫폼은 임직원들이 새로운 에이전트를 등록하고, 사용하고, 공유하는 중앙 허브입니다.

4.1 Amazon Bedrock AgentCore 기반 에이전트 플랫폼 아키텍처

그림 10. Amazon Bedrock AgentCore 기반 Agent Platform 전체 아키텍처​

에이전트가 여러 사용자가 쓰는 운영 환경으로 가면 세션 격리, 컨테이너 관리, 스케일링, 인증과 인가, 도구 연결 코드, 로그와 추적, 대화 메모리 저장소가 관리되어야 합니다. 이 영역을 Amazon Bedrock AgentCore의 관리형 기능을 활용합니다.

플랫폼 자체는 Amazon Elastic Container Service(Amazon ECS) Fargate 위의 Next.js 프런트엔드와 FastAPI 백엔드로 구현됩니다. Application Load Balancer는 web만 노출하고 server는 프라이빗 서브넷에 있으며, web이 /api 요청을 server로 프록시합니다. 플랫폼의 상태값은 Amazon DynamoDB 테이블에 저장되고, 에이전트가 참조하거나 생성하는 문서들을 저장하기 위해 Amazon S3를 사용합니다. 사용자는 Entra ID를 통해 로그인하고, 인증된 사용자는 채팅 요청에 따라 백엔드 서버를 통해 AgentCore Runtime에 배포된 에이전트를 호출하고, 에이전트는 Gateway의 MCP 도구를 호출합니다. 모델 호출에는 Amazon Bedrock Guardrails를 적용합니다.

구축된 에이전트 플랫폼에서 제공하는 기능은 크게 5 가지입니다.

1. Chats메뉴: 특정 에이전트를 선택해 대화합니다.
2. Knowledge 메뉴: 문서를 올려 RAG용 Knowledge Base를 만듭니다.
3. Registry메뉴: 조직에 공유된 에이전트, MCP 서버, 스킬을 검색하고 승인합니다.
4. Agent Harness메뉴: Registry에 등록된 구성 요소를 조합해 No-code로 에이전트를 생성합니다.
5. Insights메뉴: 사용자별 에이전트 사용량과 비용을 확인합니다.

4.2 실행 격리와 대화 기억: AgentCore Runtime과 AgentCore Memory

에이전트는 AgentCore Runtime에 배포되어 사용자별 세션이 microVM 기반으로 격리되어 실행됩니다. 배포된 에이전트에 대한 스케일링, 세션 관리, 보안 격리, 인프라 관리를 AgentCore Runtime에서 처리하기에 에이전트 운영에 있어서 관리에 대한 부담을 덜 수 있습니다.

그리고 에이전트의 대화 이력은 AgentCore Memory가 맡아 별도 저장소를 관리하지 않습니다. Memory의 단기 메모리는 한 세션 안의 턴 단위 상호작용을 저장하고, 장기 메모리는 여러 세션에 걸친 선호와 사실과 요약을 자동으로 추출해 저장합니다. 플랫폼은 세션을 다시 열 때 Memory에서 최근 대화 이력을 복원합니다. Memory 이벤트가 메모리 ID, 행위자 ID, 세션 ID로 스코핑되기 때문에 스레드 하나에는 호출된 에이전트 하나를 고정하여 저장합니다.

4.3 개인 자산에서 전사 자산으로: AWS Agent Registry

조직에서 필요한 에이전트, MCP, Skills 는 유사합니다. 하나의 조직에서 만든 리소스를 다른 조직에서 모르고 있다면 중복된 작업이 발생할 수 있습니다. AWS Agent Registry는 MCP 서버, 도구, 에이전트, 스킬을 검색 가능한 레지스트리에 게시하고 승인 워크플로로 접근을 통제하는 관리형 카탈로그입니다.

​​그림 11. Registry 화면: 에이전트, MCP 서버, 스킬 레코드와 승인 상태​

에이전트 플랫폼의 Registry 탭에서는 Agents, Skills, MCP 서버, Custom 리소스를 검색하고 승인합니다. 만든 즉시 전사에 퍼블리시되지 않고 큐레이션을 거칩니다. 관리자(ADMIN)가 등록과 승인을 하고 일반 사용자(USER)는 승인된 항목만 조회해 대화합니다. 의미 검색과 키워드 검색을 결합한 하이브리드 검색을 제공하고, 관리자가 승인한 레코드만 검색 결과에 노출됩니다.

한 팀이 잘 만든 에이전트, 스킬, MCP 서버가 개인 자산이 아니라 전사 자산이 되게 하는 장치가 이 승인 워크플로입니다.

4.4 코드 없이 설정만으로 만드는 에이전트: AgentCore Harness

AgentCore Harness는 모델, 도구, 스킬, 지시문을 설정으로 선언하면 AgentCore가 실행하는 관리형 에이전트 루프입니다. 개발자가 아니더라도 구성원 누구나 특화 에이전트를 직접 구축하고 조직에 공유할 수 있습니다.

그림 12. Agent Harness 화면: MCP 서버, 스킬, Knowledge Base를 조합하여 에이전트 구성

사내 정보시스템의 MCP 도구를 한 번 만들어 Registry에 올리면, 다른 팀은 코드 없이 그 도구를 조합한 에이전트를 만들 수 있습니다. 모델, 시스템 프롬프트, Registry에 승인된 MCP 서버와 스킬, Knowledge Base, 내장 도구(browser, code_interpreter)를 선택하면 즉시 에이전트를 만들 수 있습니다. 도메인 지식을 가진 담당자가 업무 규칙을 지시문에 적고, 스킬로 지침을 보강하고, MCP 서버로 데이터를 연결하는 것이 에이전트를 만드는 전부입니다.

코드로 구현되어 AgentCore Runtime으로 배포된 에이전트와 No-code로 구축된 Agent Harness 모두 동일한 호출 경로를 가집니다. Agent Harness 세션은 AgentCore Runtime과 같은 방식으로 격리된 환경에서 실행되고, 사용한 AgentCore 기능의 사용량만 과금됩니다. Agent Harness로 만들어진 에이전트는 코드로도 추출이 가능해, 직접 코드를 수정 후 AgentCore Runtime으로 재배포할 수 있습니다.

4.5 S3 기반의 관리형 RAG 파이프라인: Managed Knowledge Base

가지고 있는 문서를 기반으로 RAG 에이전트를 만드는 것은 일반적인 시나리오입니다. Agent Harness에 연결하여 RAG 도구로 활용하기 위해 Amazon Bedrock의 Amazon Bedrock Knowledge Bases의 관리형 옵션을 씁니다. 저장, 인덱싱, 벡터 스토어를 서비스가 관리하는 완전관리형 RAG 파이프라인이라 별도 벡터 스토어 구성이 필요하지 않습니다.

그림 13. Knowledge Base 생성과 KB별 AgentCore Gateway 구성

사용자가 Knowledge 화면에서 문서를 올리거나 S3를 동기화하면, 플랫폼은 지식 베이스마다 AgentCore Gateway를 하나 만들어 검색을 MCP 검색 도구로 등록합니다. 만들어진 Knowledge Base는 MCP 검색 도구로 에이전트에 연결되어 문서를 조회합니다. 파일 업로드와 Harness의 조합만으로도 개인 맞춤형 RAG 에이전트를 구축할 수 있습니다.

그림 14. Knowledge 화면: 문서를 업로드하여 생성한 Knowledge Base 목록

공용으로 사용되는 사내 문서와 개인이 관리해야 하는 문서는 구분되어야 하기에, 플랫폼에서는 사용자에 따라 공유용 지식 베이스와 개인용 지식 베이스를 구분하여 노출시킵니다.

4.6 접근 통제와 운영 가시성을 위한 Insights

에이전트, MCP, SKILLS이 중앙에서 관리되기에, 관리자는 전체 사용량과 비용에 대해 운영 가시성을 높일 수 있고 접근 통제 정책을 수립할 수 있습니다.

그림 15. 사용자 및 에이전트별 사용량 추적 대시보드

플랫폼은 DynamoDB의 사용량 집계와 AWS Cost Explorer의 비용 데이터를 Gateway, Memory, harness 같은 구성 요소별로 묶어 보여 줍니다. 사용자와 에이전트별 호출 수/비용, 입력과 출력 토큰, MCP 도구 호출 수 등 정보를 확인할 수 있습니다. 플랫폼은 DynamoDB의 사용량 집계와 AWS Cost Explorer의 비용 데이터를 Gateway, Memory, harness 같은 구성 요소별로 묶어 보여 줍니다.

그림 16. 사용자 및 에이전트별 사용량 추적 및 평가를 위한 아키텍처

조직에서는 에이전트가 비정상적으로 사용되고 있지는 않은지, 에이전트의 사용량과 품질이 어떤지 관측하고 평가하는 부분이 필수적 입니다. 이를 위해 AgentCore Evaluations와 AgentCore Optimization을 통해 에이전트별 성능 평가를 수행하고 최적화 제안을 받아, 에이전트가 자동으로 개선되는 루프를 쉽게 구성할 수 있습니다. 이를 통해 조직 내 에이전트의 운영 성숙도와 구성원 전반에 걸쳐 AI 리터러시를 향상시킬 수 있습니다.

그림 17. 에이전트 호출 이력 기반 성능 평가 및 최적화 제안

4.7 에이전트 플랫폼 구축을 위한 AgentCore 서비스 요약

정리하면 AX 도입을 위한 에이전트 중앙 관리 플랫폼은 Amazon Bedrock AgentCore를 기반으로 아래와 같이 구현됩니다.

• Agent Registry에서 에이전트, 스킬, MCP 서버를 찾고, 시험하고, 등록합니다.
• 사내 문서는 Managed Knowledge Base와 AgentCore Gateway로 한 번 연결해 여러 에이전트가 활용합니다.
• Registry에 등록된 MCP 서버, Skill을 통해 AgentCore Harness로 코드 배포 없이 에이전트를 만들고 수정합니다.
• AgentCore Runtime에 배포된 에이전트가 AgentCore Memory로 연속적인 대화를 이어갑니다.
• AgentCore 빌트인 도구인 Browser와 Code Interpreter가 격리된 세션에서 웹 브라우저 조작 및 복잡한 데이터 분석을 수행합니다.
• Bedrock Guardrail이 위험한 사용자의 요청을 막고 기록에 남깁니다.
• 누가 어떤 에이전트를 얼마나 썼고 비용이 얼마인지 대시보드 화면에서 확인합니다.
• 지속적인 에이전트 개선을 위해 AgentCore Evaluation과 AgentCore Optimization으로 에이전트를 주기적으로 평가 및 최적화 합니다.

5. AX 성숙도를 위한 로드맵

그림 18. AX 성숙도 로드맵: Phase 1(AI 체험)부터 Phase 4(AI-First 조직)까지의 단계별 도입 계획

조직 내에서 AX 성숙도를 높이기 위해서는 안전한 플랫폼 기반 내에서 단계적인 도입이 필요합니다.

• Phase 1: AI 환경이 익숙한 개발자 대상으로 Claude Code on Bedrock과 LLM Gateway를 배포하여, 사내의 통제된 환경에서 AI 사용을 제공합니다.
• Phase 2: 비개발자들도 사내 시스템과 연동된 업무용 에이전트를 활용하도록 제공합니다.
• Phase 3: 에이전트 활용에 익숙해진 구성원들이 직접 MCP 서버를 구축하거나 Knowledge Base를 구성하여, 목적에 맞는 에이전트를 직접 구성 및 공유합니다.
• Phase 4: Registry로 전사 에이전트에 대한 거버넌스를 운영하며, 조직 전체에 AX 문화가 자리잡는 것을 목표로 진행해야 합니다.

6. 정리

에이전트가 개인 PC에 머물면 조직의 AX는 시작되지 않습니다. 조직의 AX는 모델 선택이 아니라 사내 데이터의 표준 경로, 공통된 에이전트 실행 공간과 운영 환경, 등록과 승인과 공유 절차를 먼저 갖추는 일입니다.

• 사내 시스템에는 한 번만 연결하고 인증 정보는 플랫폼이 관리해야 합니다.
• 누가 어떤 에이전트를 얼마나 썼고 비용이 얼마나 발생하고 있는지 알아야 합니다.
• 한 팀이 잘 만든 에이전트와 도구를 다른 팀이 찾아 함께 공유하며 사용할 수 있어야 합니다.
• 에이전트를 조직이 중앙에서 관리하기 위한 플랫폼은 AgentCore를 통해 관리형으로 빠르게 구축할 수 있습니다.

Amazon Bedrock AgentCore를 중심으로 구축한 공통 기반은 조직이 업무 지식과 데이터 활용에 집중할 수 있도록 실행과 연결을 관리형으로 제공합니다. 그 위에 검증된 도구와 스킬을 쌓고, 승인과 공유를 통해 활용 범위를 넓혀 가는 것이 AX를 위한 기반이 됩니다. ​조직의 AX 여정을 빠르게 구축하기 위해 Amazon Bedrock AgentCore 를 중심으로 사내 데이터 연결과 에이전트 운영을 위한 기반 플랫폼 구축을 검토해 보시기 바랍니다.​

참고 자료

• Amazon Bedrock AgentCore 개발자 가이드
• AgentCore Runtime 동작 방식(세션과 microVM 격리)
• AgentCore와 VPC 연결
• AgentCore Gateway 핵심 개념(타깃 유형)
• AgentCore Gateway 인바운드 인가
• AgentCore Gateway Interceptor
• AgentCore Gateway 프라이빗 타깃(VPC Lattice)
• AgentCore Gateway Web Search Tool
• AWS Agent Registry
• AgentCore Harness
• AgentCore Code Interpreter
• AgentCore 저장 데이터 암호화(Memory CMK)
• AgentCore 지원 리전
• AgentCore 요금
• Amazon Bedrock Managed Knowledge Base
• Amazon Bedrock 데이터 보존과 학습 미사용
• Amazon Bedrock 크로스리전 추론
• Amazon Bedrock VPC 인터페이스 엔드포인트
• AWS for SAP MCP Server
• Claude Code on Amazon Bedrock
• Claude Code와 LLM Gateway 연결
• Microsoft Entra ID 토큰 클레임(groups)