Pluggable Agentic AI Framework: A seven-layer composable enterprise agentic AI reference architecture on Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Pluggable Agentic AI Framework는 Amazon Bedrock AgentCore 등을 활용하는 교체 가능한 7개 계층을 통해 멀티 에이전트 AI를 개념 검증에서 안전하고 신뢰할 수 있는 운영 환경으로 확장하기 위한 참조 아키텍처다.

📌 핵심 요약

• Pluggable Agentic AI Framework는 데이터·지식, 모델·추론, 오케스트레이션, 보안·가드레일, 애플리케이션, 관측 가능성, 에이전트 운영의 7개 계층을 구분한다. 각 계층은 고유한 책임과 안정적인 인터페이스 계약을 가지며, 제시된 서비스는 필수 선택이 아닌 참조 구현의 예시다.
• 데이터·지식 계층은 관련성 있고 최신인 정보를 검색해 에이전트의 맥락으로 제공한다. 모델·추론 계층은 실제 업무를 대표하는 데이터로 모델을 평가하고, 단순한 작업에는 작고 빠른 모델을, 정교한 추론에는 큰 모델을 사용하며, LiteLLM 같은 공통 인터페이스로 모델 교체와 애플리케이션 로직을 분리한다.
• 단순한 작업에는 단일 에이전트를, 복잡한 다영역 작업에는 감독자와 전문 에이전트의 분업을 권고한다. 전문 에이전트의 자율성을 허용된 도구로 제한하고, 중앙 에이전트 레지스트리와 MCP·A2A 같은 표준 프로토콜로 검색·호출해 재사용과 거버넌스를 지원한다.
• 보안은 설계 첫날부터 반영하며, 외부 콘텐츠를 기본적으로 신뢰하지 않고 모든 요청을 인증한다. 도구 실행 전 세밀한 접근 제어, 임시·범위 제한 자격 증명, PHI·PII 마스킹, 변조 흔적을 확인할 수 있는 감사 기록, 영향이 큰 작업의 사람 승인, 이상 행동을 중단하는 회로 차단기를 제안한다.
• 관측 가능성과 에이전트 운영도 처음부터 구축해 요청별 비용·토큰 사용량·첫 토큰 도착 시간과 전체 실행 추적을 수집하고, 모든 운영 세션의 근거 충실도·정확성·안전성을 평가하며 회귀 검증 관문을 둔다. 소매 고객 지원 참조 구현은 Order 에이전트와 Refund 에이전트가 주문 정보와 환불 정책을 조회하고, AgentCore Gateway와 Policy in AgentCore를 통해 도구 실행 권한을 통제하는 흐름을 보여준다.

🧩 주요 포인트

1. 계층별 안정적인 계약과 기술 교체 가능성 → 기존 보안·관측·추론 도구를 유지하면서 필요한 기능을 점진적으로 도입할 수 있는 아키텍처 중심 접근.
2. 전문 에이전트의 책임·도구 범위 분리 → 맥락과 도구의 과도한 확장을 줄이고, 에이전트별 테스트·확장·보안 통제를 독립적으로 수행할 기반.
3. 얇은 애플리케이션 계층과 지속적인 운영 평가 → 사용자 경험 변경이 백엔드에 미치는 영향을 줄이고, 출시 이후에도 품질·안전성·비용을 확인하는 운영 구조.

🧠 상세 정리

1. 개념 검증과 운영 사이의 간극

원문은 AI 에이전트를 대규모 운영 환경에서 어떻게 실행할 것인지라는 질문에서 출발하며, 수천 건의 동시 요청 처리와 실제 트래픽에서의 신뢰성, 테스트 이후의 품질·안전성 유지 문제를 함께 제기한다. 개념 검증은 모델이 작업을 수행할 수 있음을 보여주지만, 운영 트래픽과 비용 압박, 보안 검토를 견디는 시스템인지는 입증하지 못한다. 많은 프로젝트가 이 간극에서 정체되는 원인은 대개 모델 자체보다 팀마다 라우팅·가드레일·관측 기능을 반복해서 만들고 사후에 덧붙이는 구조에 있다는 것이 글의 진단이다. Pluggable Agentic AI Framework는 이를 해결하기 위해 책임과 안정적인 계약을 갖춘 7개 계층을 제시한다. 각 계층에 등장하는 서비스와 기술은 참조 구현의 선택일 뿐 필수가 아니며, 조직은 기존 인프라와 요구에 맞는 대안을 사용할 수 있다.

2. 데이터·지식: 관련성 있고 최신인 맥락 제공

데이터·지식 계층은 에이전트가 접근할 수 있는 정보가 답변의 품질을 좌우한다는 전제에서 출발한다. 의료 처방집을 확인하거나 재고를 추적하거나 규정 준수 규칙을 해석하는 경우 모두, 정확한 답변을 위해 관련성 있고 최신인 정보가 필요하다는 설명이다. 이 계층은 검색과 임베딩, 정형·비정형 데이터 접근을 담당하며, 질의를 받아 가장 관련성 높은 정보를 에이전트의 맥락으로 반환하는 명확한 계약을 갖는다. 원문은 이러한 기반을 구성할 수 있는 예시로 Amazon Bedrock Knowledge Base, Vector Engine for Amazon OpenSearch Serverless, Amazon S3 Vectors, Amazon DynamoDB를 제시한다. 핵심은 특정 저장소를 의무화하는 것이 아니라, 에이전트가 필요한 정보를 일관된 방식으로 얻도록 데이터 접근의 책임과 경계를 정하는 데 있다.

3. 모델·추론: 평가와 설정에 따른 모델 선택

모델 선택은 에이전트나 애플리케이션 로직에 고정하기보다 설정을 통해 바꿀 수 있어야 한다는 것이 모델·추론 계층의 원칙이다. 원문은 단순한 작업에는 작고 빠른 모델을, 더 섬세한 추론이 필요한 요청에는 큰 모델을 사용하도록 권고한다. 다만 이러한 선택에 앞서 실제 업무를 현실적으로 대표하는 데이터로 해당 사용 사례에 대한 모델 평가를 충분히 수행해야 한다고 강조한다. 모델 라우팅 계층은 일관된 요청·응답 계약을 제공해 에이전트를 모델 호스팅 환경과 공급자별 API에서 분리한다. LiteLLM 같은 프록시는 여러 공급자에 걸친 공통 인터페이스의 예시로 제시되며, 이를 통해 평가 결과에 따라 모델을 교체하더라도 애플리케이션 로직을 다시 작성할 필요를 줄일 수 있다.

4. 오케스트레이션: 전문화와 제한된 자율성

오케스트레이션 계층은 작업을 어떻게 분배할지 결정하며, 원문은 단순한 작업에는 단일 에이전트를, 복잡한 다영역 작업에는 감독자가 전문 에이전트에 위임하는 구성을 권고한다. 하나의 에이전트에 도구·지침·맥락을 계속 더하면 맥락 창이 커지고 지연이 늘며 정확성이 저하될 수 있고, 도구의 과도한 확장은 의도하지 않은 행동과 보안 침해로 이어질 수 있다는 근거를 든다. 책임을 나누면 각 에이전트의 맥락을 집중시키고 지연을 더 예측 가능하게 만들며, 동작 테스트와 확장, 보안 모델을 독립적으로 관리할 수 있다. 전문 에이전트는 부여받은 도구 범위 안에서만 실행하도록 자율성을 제한하고, 감독자와도 분리해야 한다. 중앙 레지스트리에 도구·스킬·소유자를 등록하고 MCP·A2A 같은 표준 프로토콜로 검색·호출하며, 구현 예시로 Strands Agents, Amazon Bedrock AgentCore harness, AWS Agent Registry, Amazon Bedrock AgentCore Gateway를 제시한다.

5. 보안·가드레일: 요청부터 실행까지 통제

보안·가드레일 계층은 프롬프트 주입과 도구 오용, 메모리·데이터 오염처럼 기존 보안 체계만으로 다루기 어려운 위험을 설계 첫날부터 고려하도록 요구한다. 외부 콘텐츠는 기본적으로 신뢰하지 않으며, 사용자·다른 에이전트·자동화 워크플로에서 온 요청을 모두 인증하고 각 도구 호출을 실행하기 전에 세밀한 접근 권한을 확인한다. 에이전트에는 영구 비밀정보 대신 일시적이고 범위가 제한된 자격 증명을 부여하고, 요청·응답의 PHI와 PII를 마스킹해 민감한 정보가 출력이나 메모리에 남는 것을 방지하도록 제안한다. 책임 추적을 위해 중요한 판단을 변조 흔적을 확인할 수 있는 감사 기록으로 남기고, 영향이 큰 작업에는 사람의 승인을 거치며 이상 행동에는 회로 차단기를 적용한다. 구현 예시에는 Amazon Bedrock Guardrails, Amazon Bedrock AgentCore Identity, Policy in Amazon Bedrock AgentCore와 AWS의 보안·거버넌스 통제가 포함된다.

6. 애플리케이션: 얇은 사용자 접점과 요청 판별

애플리케이션 계층은 채팅 인터페이스와 API, 내장 위젯처럼 최종 사용자 경험이 구현되는 곳이며, 원문은 이 계층을 의도적으로 얇게 유지하라고 권고한다. 책임은 대화를 보여주고 요청을 아래의 오케스트레이션 계층으로 전달하는 데 집중하며, 업무 로직을 넣지 않아야 사용자 경험을 바꿀 때 백엔드의 안정성을 해칠 가능성을 줄일 수 있다는 설명이다. 이 경계에는 빠르고 저렴한 판단 모델을 두어 요청이 범위에 속하는지, 사람의 개입이 필요한지, 긴급한지를 한 번의 호출로 점수화할 수 있다. 모델은 자유 형식 텍스트 대신 확률을 반환하고, 코드는 단순한 임계값을 적용해 주제 밖 요청에 직접 응답하거나 상향 처리가 필요한 요청을 표시한다. 이를 통해 전체 에이전트 실행 과정은 가치가 있을 때만 수행하며, 외부 인터페이스는 사람뿐 아니라 다른 AI 에이전트도 소비하고 상호작용할 수 있도록 설계해야 한다.

7. 관측 가능성: 전체 실행과 비용의 가시화

관측 가능성은 첫 장애가 발생한 뒤 추가할 기능이 아니라, 처음부터 모든 계층을 살펴야 하는 공통 역량으로 제시된다. 로그와 지표뿐 아니라 에이전트가 실제로 작업을 올바르게 수행했는지 확인할 수 있는 전체 실행 추적이 중요하다는 설명이다. 원문은 추적 정보와 함께 요청별 비용과 토큰 사용량, 첫 토큰 도착 시간, 호출의 보안 여부를 수집하고, 운영 시작 전에 지연·오류율·지출을 보여주는 대시보드를 마련하도록 권고한다. 이러한 가시성은 에이전트의 실행 결과뿐 아니라 처리 과정과 운영 부담을 함께 확인하는 근거가 되며, 글은 사후 대응보다 사전 모니터링의 비용이 낮다고 주장한다. 구현 예시로는 OpenTelemetry와 함께 사용하는 Amazon CloudWatch, 그리고 추적과 지표를 위한 Amazon CloudWatch Omni가 제시된다.

8. 에이전트 운영: 출시 이후의 지속 평가

에이전트 운영 계층은 지속적인 평가를 통해 실행 결과를 다시 점검하는 순환 구조를 완성하며, 이 역시 첫날부터 마련해야 한다고 설명한다. 원문은 모든 운영 세션을 근거 충실도와 정확성, 안전성 측면에서 평가하고, 품질 저하가 고객에게 도달하기 전에 잡아내는 회귀 검증 관문을 두도록 권고한다. 이러한 체계가 없으면 출시 시점에 에이전트가 작동했다는 사실만 알 수 있지만, 지속 평가를 적용하면 이후 각 릴리스에서도 작동 상태를 입증할 수 있다는 논리다. 따라서 운영의 목표는 최초 테스트 통과에 머무르지 않고, 변경 이후에도 품질과 안전성이 유지되는지를 반복해서 확인하는 데 있다. 원문은 점수화를 위한 Amazon Bedrock AgentCore Evaluations와 지속적인 성능 조정을 위한 Amazon Bedrock AgentCore optimization을 구현 예시로 제시한다.

9. 소매 고객 지원 참조 구현의 실행 흐름

프레임워크는 주문 상태와 환불 자격을 다루는 소매 고객 지원 시나리오를 실행 가능한 참조 구현으로 제공하며, 모든 계층을 활용하면서도 팀이 이해하고 바꾸기 쉬운 사례라는 이유로 이를 선택했다고 설명한다. 고객의 환불 요청을 받은 감독자 에이전트는 제한된 도구를 가진 Order 에이전트와 Refund 에이전트에 작업을 위임한다. Order 에이전트는 Amazon DynamoDB에서 배송·구매 정보를 조회하고, Refund 에이전트는 지식 기반에서 고객 등급별 정책을 가져와 배송일·현재 날짜·고객 충성도 등급으로 환불 자격을 계산한다. 이 호출들은 모두 AgentCore Gateway를 거치며, Policy in AgentCore가 도구 실행 전에 세밀한 접근 제어를 적용한다. 관측 계층은 전체 과정을 추적해 계산 오류가 발생한 계층과 판단 지점을 확인할 수 있게 하며, 유사한 감독자·전문가 패턴을 구축하는 팀은 참조 구현을 복제해 계층별로 자신의 업무 로직을 적용할 수 있다.

10. 교체 가능성: 기술보다 아키텍처를 우선

원문은 7개 계층의 가치가 책임 분리에만 있는 것이 아니라, 각 계층을 얼마나 빠르게 발전시킬 수 있는지에도 있다고 강조한다. 신원 확인과 접근 정책, 원격 측정 인터페이스 등 계층 경계의 계약이 안정적이면 나머지 시스템을 다시 설계하지 않고 내부 기술을 바꿀 수 있으므로, 기술 중심보다 아키텍처 중심으로 접근해야 한다는 주장이다. 프레임워크는 추론 계층의 모델·호스팅 공급자, 오케스트레이션 계층의 검색, 애플리케이션 계층의 판단 API, 보안 계층의 가드레일, 관측 계층의 추적·모니터링과 업무 가치·비용 추적에서 제삼자 통합을 보여준다. 기업은 이를 통해 신뢰하는 관측·보안·추론 도구와 기존 투자를 유지하면서 부족한 부분을 채우고 새 기능을 점진적으로 도입할 수 있다. 결론은 작동하는 프로토타입이 에이전트의 수행 가능성을 보여준다면, 잘 설계된 아키텍처는 기업이 그 에이전트에 의존할 수 있는지를 결정한다고 강조하며, 제공된 원문은 이후 운영 설계 요소를 열거하는 도중에 끝난다.

🧾 핵심 주장 / 시사점

• 모델 교체와 공급자 선택의 자유는 계층 경계의 계약이 안정적으로 유지될 때 실질적인 가치가 있다. 이 프레임워크의 중심은 특정 서비스의 조합보다 책임과 인터페이스를 먼저 정하는 설계 원칙이다.
• 전문 에이전트로의 분리는 맥락과 지연을 관리하는 성능 전략인 동시에, 도구 권한과 자율성의 범위를 제한하는 보안 전략이다. 중앙 레지스트리는 이러한 분리가 조직 전체의 재사용과 거버넌스로 이어지도록 돕는다.
• 전체 실행 추적과 지속 평가는 서로 보완적이다. 추적은 오류가 발생한 계층과 판단 지점을 드러내고, 운영 세션 평가는 출시 이후에도 근거 충실도·정확성·안전성이 유지되는지를 확인한다.

✅ 액션 아이템

• 7개 계층의 책임과 안정적인 인터페이스 계약을 기준으로 기존 보안·관측·추론 도구의 유지 및 교체 범위 검토.
• 복잡한 다영역 작업의 감독자·전문 에이전트 분업과 허용된 도구 범위를 정의하고, 중앙 에이전트 레지스트리와 MCP·A2A 적용 검토.
• 요청별 비용·토큰 사용량·첫 토큰 도착 시간 및 전체 실행 추적 수집과 모든 운영 세션의 근거 충실도·정확성·안전성 평가, 회귀 검증 관문 적용.

❓ 열린 질문

• 7개 계층의 안정적인 인터페이스 계약을 유지하면서 기존 보안·관측·추론 도구 중 무엇을 유지하고 무엇을 교체할 것인가?
• 단일 에이전트로 처리할 작업과 감독자·전문 에이전트로 분업할 복잡한 다영역 작업을 어떤 기준으로 구분할 것인가?
• 모든 운영 세션의 근거 충실도·정확성·안전성 평가에서 회귀 검증 관문을 통과할 기준은 어떻게 정할 것인가?