DEVOCEAN

이전 아래 글에 이어지는 (실습) 편입니다.

• 이제는 Agent 시대! RAG와 함께 Bedrock Agent를 활용해보자 - 1 (이론)

서론

지난번에 살펴본 AI Agent에 대해 간단히 정리해보고, Amazon Bedrock Agent 서비스로 이를 구현해 보겠습니다.

AI Agent 정의

AI Agent는 특정 목표를 달성하기 위해 자율적으로 행동하고 결정을 내리는 AI 시스템을 말합니다.

• 자율성: Agent는 사람의 직접적인 개입 없이 자체적인 판단으로 작업을 수행할 수 있습니다.

• 목표 지향성: 주어진 목표를 달성하기 위해 데이터를 수집하고 계획을 세우고 실행합니다.

• 환경 인식: 주변 환경을 인식하고 그에 따라 행동을 조절합니다.

• 학습 능력: 경험을 통해 학습하고 성능을 개선합니다.

• 상호작용: 다른 Agent나 시스템과 소통하고 협력할 수 있습니다.

참고 문서 : AI 에이전트란 무엇일까요?

여기에서 주목할 점은 상호작용 부분입니다. Agent는 API 호출을 통해 LLM 환경의 Sandbox를 벗어나 외부 환경인 실세계에 개입하여 작업을 할 수 있게 됩니다.

현실 세계의 IoT 장비의 값을 읽어 올 수도 있고, 서비스 운영 환경을 자동화할 수도 있고, 게임 내의 세계를 조율하는 AI 운영자가 될 수도 있습니다.

기존의 단순한 언어 인식 기반의 정형화된 AI Agent에서,

LLM이 적용되면서 사용자의 언어를 이해하고 논리적으로 정리하고 실행할 수 있게 됨으로 AI Agent는 놀라운 가능성을 가지게 되었습니다.

AWS Bedrock 플랫폼은 지식 검색(RAG)과 API 스키마를 사용해서 이런 LLM 기반의 에이전트의 기능을 확장 지원합니다.

Bedrock Agent 구성 요소

Amazon Bedrock Agent의 주요 구성 요소는 아래와 같습니다.

작업 그룹 (Action Group)

• Agent의 외부 세계 확장을 위한 핵심기능으로, 바로 AWS Lambda 함수를 호출 할 수 있는 기능입니다.

• Action Group 하나는 AWS Lambda 함수 한개와 직접 연결됩니다.

• OpenAPI Schema를 통해서 Agent는 이 Lambda 함수가 무엇을 할 수 있고, input과 output은 어떻게 정의 되는지 알 수 있습니다.

지식 기반 (Knowledge bases)

• 지식 기반에는 Agent가 검색해서 사용할 수 있는 데이터가 들어 있습니다. 에이전트가 지식 기반을 쿼리하여 응답을 증가시키거나 작업 그룹을 호출하는 효율성을 개선할 수 있습니다.

• 데이터 소스 : S3, 웹 크롤링을 직접 지원하며, Confluence, Salesforce, Sharepoint를 연결해서 사용할 수 있습니다.

• 청킹 및 구분 분석 : 다양한 청킹 전략과 더불어 Lambda 함수를 통해 청킹 및 문서 메타데이터 처리를 사용자 정의할수 도 있습니다.

• 벡터 데이터베이스 : Amazon OpenSearch Serverless, Amazon Aurora, Pinecone, Redis Enterprise Cloud을 지원합니다.

Memory

• 기본적으로 에이전트는 단일 대화 내의 정보만 기억합니다. 메모리를 활성화하면 에이전트는 최대 30일 동안 여러 세션에 걸쳐 정보를 기억할 수 있습니다

가드레일 (Guardrail)

• 사용 사례와 책임 있는 AI 정책을 기반으로 보호 기능을 구현하는 데 사용됩니다.

• 거부할주제를 구성하여 바람직하지 않은 주제를 피할 수 있습니다.

• 콘텐츠 필터를 구성하여 입력 및 모델 응답에서 유해한 콘텐츠를 차단할 수 있습니다

고급 프롬프트 (Advanced prompts)

• 응답을 위한 각 진행 단계인 전처리, 지식 기반 응답 생성, 오케스트레이션, 후처리 별로 각각 프롬프트 및 파라미터를 설정해서 더욱 효과적으로 제어할 수 있게 합니다.

목적 및 실습 개요

아래 실습에서는 AI 에이전트와 대화하며 Kubernetes 클러스터의 보안을 점검합니다.

에이전트와의 자연스러운 대화를 통해 Kubernetes Api call을 하며, Trivy 솔루션을 이용해

생성된 복잡한 CIS(Center for Internet Security) Kubernetes 벤치마크 보고서의 결과를 Agent가 요약해서 알려줍니다.

Trivy는 컨테이너 및 구성 파일의 취약점을 빠르게 검사 관리할 수 있는 오픈 소스 보안 스캐닝 도구입니다.

아키텍처 설명

• Amazon Bedrock : 다양한 Foundation Model을 사용해 RAG 및 Agent를 쉽게 사용 할 수 있게 제공 해주는 플랫폼.

• Kubernetes : 우리의 API 컨트롤 대상

• OpenAPI Schema : Agent가 호출할 API Spec 정의 - Kubernetes API 사용

• OpenSearch : 시맨틱 검색을 위한 Vector DB와 키워드 검색을 모두 지원하는 RAG의 Database로 사용

• Trivy : 컨테이너 취약점 진단 도구

사전 환경 구성

Foundation Model 및 Region 선택

• LLM으로 Claude Sonnet 3.5를 사용 합니다.

  • 서울리전은 아직 지원을 하지 않아서, 버지니아(us-east-1), 오레곤(us-west-2) 또는 도쿄(ap-northeast-1)으로 해야 합니다.

  • 저희는 지연이 좀 더 짧은 도쿄 리전을 사용하겠습니다.

• 텍스트 임베딩을 위한 모델로 Titan Embeddings G1 - Text을 사용합니다.

  • Titan Text Embeddings V2 을 사용할 경우 한글도 잘 지원 되고, 임베딩 성능이 훨씬 좋습니다.

    다만 버지니아 또는 오레곤 리전에서 실행해야 합니다.

• 참고 사항으로 Meta Llama 3.1 405B 등을 포함한 가장 다양한 FM모델을 지원하는 리전은 오레곤(us-west-2)입니다

Foundation Model Access 요청

먼저 Bedrock에서 사용되는 기반 모델(Foundation Model)을 액세스 할수 있도록 요청해야 합니다.

상단 서비스 검색에서 Bedrock 을 검색에서 해당 서비스 메뉴로 들어가신 후 인쪽 메뉴 제일 아래의 모델 액세스 를 선택 후

상단에 있는 Enable all models 를 선택합니다. 실제 사용 할 다음 모델 두개만 해도 됩니다.

Titan Embeddings G1 - Text , Claude 3.5 Sonnet

요청은 Marketplace의 구독으로 관리되지만, 모델 액세스는 Bedrock 메뉴에서 관리 가능합니다.

참고로, Sonnet 3.5 의 경우 사용자에 따라 아래 처럼 사용 불가로 나오는 경우도 있는데,

사용 불가 링크에 걸려 있는 티켓 생성 링크를 열어서 Claude 3.5 Sonnet에 대한 Access 요청 티켓을 열어주셔야 됩니다.

아래는 액세스 권한이 부여된 결과 화면입니다.

실행 환경 - CloudShell

• 환경 구성은 단기간 사용이고, 실습 환경 통일을 위해서 기본 제공하는 AWS Cloud Shell을 사용하겠습니다.

  물론 개인 PC에서도 가능하며 이 경우 API Key를 미리 적용 해두어야 합니다.

• Cloud Shell의 권한은 현재 로그인한 사용자나 역할 정보를 그대로 따르므로 Bedrock, EKS, OpenSearch등을 생성할 수 있는 충분한 권한이 현재 계정에 있어야 합니다.

CLI Tool 설치

• 아래 커맨드로 eksctl 및 helm을 설치합니다.

  mkdir -p $HOME/.local/bin
  
  # eksctl 설치
  curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C $HOME/.local/bin/
  
  # helm 설치
  curl -s https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | HELM_INSTALL_DIR="$HOME/.local/bin" bash
  
  export AWS_REGION=ap-northeast-1
  
  # cli 실행 확인 
  eksctl version
  helm version
  aws --version

  
  

관련 소스 다운로드

• AWS Sample Code에서 데이터 소스를 더하고 일부 수정하여 github에 새로 올려두었습니다.

  git clone으로 다운 받습니다.

  git clone https://github.com/mungi/devocean-bedrock-agent

실습 환경 셋업

EKS 구성

• eks cluster를 만듭니다. 테스트용이므로 비용을 줄이기 위해 Spot Instance를 사용하고, 몇가지 자주 쓰는 다양한 설정들과 함께 만들어 봅니다.

  • version 1.30

  • VPC - 미지정으로 기본 구성 생성 (192.168.0.0/16, public subnet x 2, private subnet x 2, Nat GW x 1)

  • spot instance, t4g.medium, ebs 20GB, 노드 1대, private subnet

  • oidc 활성화

  • 완료 되는데 20분 정도 걸립니다.

  eksctl create cluster --name devocean-agent-eks --version 1.30 \
         --managed --node-type t4g.medium --spot \
         --nodes 1 --nodes-min 1 --nodes-max 3  \
         --node-volume-type gp3 --node-volume-size 30 \
         --node-private-networking \
         --nodegroup-name ng-devocean-agent \
         --instance-name eksng-devocean-amd64 \
         --asg-access --full-ecr-access --with-oidc

• 에러 없이 EKS 구성이 완료되었다면 아래 커맨드로 현재 구성이 잘 보이는지 체크 해 봅니다.

  kubectl get node,pod,svc -A

  
  

• Helm으로 Trivy 설치 후 Compliance Report의 결과 요약만 출력해봅니다.

  helm repo add aqua https://aquasecurity.github.io/helm-charts/
  helm repo update
  
  helm install trivy-operator aqua/trivy-operator \
      --namespace trivy-system \
      --create-namespace \
      --version 0.21.1 \
      --set="compliance.cron=*/5 * * * *"
  
  kubectl get clustercompliancereport -o json | jq -r '.items[] | "\(.metadata.name): \(.status.summary)"'

  
  

RAG Data Upload - 지식 기반 Data Source

• Amazon Bedrock의 RAG 구현체는 지식 기반(Knowledge Base) 입니다.

• 지식 기반은 아래 5가지의 데이터 소스를 가질수 있습니다. 이 중 S3를 사용 합니다.

  • Amazon S3

  • Web Crawler

  • Confluence (3rd Party)

  • Salesforce (3rd Party)

  • Sharepoint (3rd Party)

• RAG에서 검색 소스로 사용 할 데이터는 아래 링크의 내용입니다.

  • Kubernetes Documentation

    • https://github.com/kubernetes/website

  • Amazon EKS Best Practices:

    • https://github.com/aws/aws-eks-best-practices

  • Amazon EKS PDF Documents:

    • https://docs.aws.amazon.com/pdfs/eks/latest/userguide/eks-ug.pdf

    • https://docs.aws.amazon.com/pdfs/eks/latest/APIReference/eks-api.pdf

  • AWS Knowledge Center content tagged with Amazon Elastic Kubernetes Service

    • https://repost.aws/tags/knowledge-center/TA4IvCeWI1TE66q4jEj4Z9zg

• 실습 편의를 위해 미리 받아서 git에 같이 올려 두었습니다. 상기 clone 받은 소스에서 data_sources 디렉토리를 S3로 업로드 합니다.

  AWS_ACCOUNT=$(aws sts get-caller-identity --query "Account" --output text)
  
  # Bucket 생성
  BUCKET_KB_DS=devocean-bedrock-knowledge-base-data-source-${AWS_ACCOUNT}
  aws s3 mb s3://$BUCKET_KB_DS --region $AWS_REGION
  
  cd devocean-bedrock-agent
  aws s3 sync ./data_sources s3://$BUCKET_KB_DS \
   --region us-east-1 \
   --exclude "*" \
   --include "*.txt" \
   --include "*.md" \
   --include "*.html" \
   --include "*.pdf"

API Schema 업로드

• 에이전트가 API 작업을 지정하는 데 사용되는 API Schema를 정의한 open-api-schema.json를 업로드 합니다.

  BUCKET_API_SCHEMA=devocean-bedrock-agent-openapi-schema-${AWS_ACCOUNT}
  aws s3 mb s3://$BUCKET_API_SCHEMA --region $AWS_REGION
  aws s3 cp open-api-schema.json s3://$BUCKET_API_SCHEMA --region $AWS_REGION

• API Schema는 테스트를 위해 아래 처럼 kubernetes API로 namspaces, get-pods , cis report를 얻는 3가지가 정의 되어 있습니다.

  
  

코드 배포 및 내용 분석

AWS Lambda 함수 아티팩트 준비

./lambda-build.sh

• 실행시 AWS Lambda 아티팩트를 설치하고 패키징하여 S3 버킷에 저장합니다.

• Custom Resource와 Action Group을 위한 cr_lambda_build 와 ag_lambda_build를 각각 생성.

• 각 경로에 requirements.txt에 있는 pip 패키지 설치.

• Lamda Layer 업로드할 devocean-bedrock-agent-lambda-artifacts-${AWS_ACCOUNT} Bucket 생성.

• devocean-bedrock-agents-for-eks-tpl.yaml CFN 템플릿을 기반으로 실행에 사용할 devocean-bedrock-agents-for-eks-cfn.yaml 생성.

스택 배포하기

    aws cloudformation deploy \
     --template-file devocean-bedrock-agents-for-eks-cfn.yaml \
     --stack-name devocean-bedrock-agent-for-eks \
     --capabilities CAPABILITY_NAMED_IAM \
     --region $AWS_REGION

• 앞에서 생성된 devocean-bedrock-agents-for-eks-cfn.yaml 파일을 배포합니다. 아래 내용이 실행됩니다.

  • Serverless 타입의 OpenSearch를 생성.

  • Lambda 함수 관련 리소스 두개 생성 및 설정.

    • CustomResourceFunction

    • ActionGroupFunction

  • BedrockKnowledgeBase 생성 및 설정.

AWS Lambda 함수 리소스

CustomResourceFunction

• 경로 및 파일 : cr_lambda/indices_custom_resource.py

• 목적 : OpenSearch Serverless컬렉션에 필요한 벡터 인덱스를 자동 관리.

1. on_create():

   • 인덱스 생성.

   • index_data 호출해 OpenSearch 인덱스 생성.

   • 텍스트 필드, 메타데이터 필드, KNN 벡터 필드 설정.

2. on_update(), on_delete():

   • 업데이트 , 삭제 요청 시 처리. 현재는 로그만 남김.

ActionGroupFunction

• 경로 및 파일 : ag_lambda/lambda_function.py

• 목적 : 에이전트가 EKS 클러스터에 프로그래밍 방식으로 접근할 수 있도록 API 요청을 처리하는 프록시 역할 수행

• 구현 내용 설명

  1. get_cluster_info() - EKS 클러스터 엔드포인트와 인증서 가져오기.

  2. get_bearer_token() - STS를 사용해 Kubernetes 인증 토큰 생성.

  3. lambda_handler()

  • get-pods: 네임스페이스의 파드 목록 가져오기.

  • namespaces: 네임스페이스 목록 가져오기.

  • reports/cis: 사용자 정의 리소스(CIS 보고서) 가져오기.

  • 기타: 유효하지 않은 API 요청 시 에러 응답.

    4. CloudFormation 응답 수행:

  • 응답 상태와 메시지 전송.

Role 생성

• Lambda와 Bedrock 서비스 실행시 필요한 Role을 생성합니다. 세부 권한은 생성된 Role의 권한을 참고하세요.

• Lambda 서비스용 역할

  • devocean-bedrock-agent-for-eks-CustomResourceRole

  • BedrockAgentLambdaFunctionRole

• Bedrock 서비스용 역할

  • AmazonBedrockExecutionRoleForAgents

  • AmazonBedrockExecutionRoleForKnowledgeBase

프롬프트 설정

• 에이전트를 위한 지침 프롬프트

  • System Prompt로 페르소나와 실제 동작해야 할 가이드를 지정합니다. 영문으로 적기는 했지만 Claude Sonnet 3.5의 경우 한글로 해도 잘 동작합니다.

You are a Kubernetes expert that can answer questions about Kubernetes and Amazon EKS. You can also query the API Server of an Amazon EKS cluster in order to tell users what namespaces exist on the cluster, what pods have been deployed within each namespace, and retrieve details of the CIS Benchmark compliance report checks. Always provide your answers in Korean.

당신은 Kubernetes와 Amazon EKS에 대한 질문에 답변할 수 있는 Kubernetes 전문가입니다. 또한 Amazon EKS 클러스터의 API 서버에 쿼리하여 사용자에게 클러스터에 어떤 네임스페이스가 존재하는지, 각 네임스페이스 내에 어떤 파드가 배포되었는지, 그리고 CIS 벤치마크 준수 보고서 검사의 세부 사항을 검색할 수 있습니다. 항상 한국어로 답변을 제공하세요.

• 지식 기반을 위한 지침 프롬프트

  • 지식 기반 검색 결과인 $search_results$를 활용합니다.

You are a question answering agent. I will provide you with a set of search results. The user will provide you with a question. Your job is to answer the user's question using only information from the search results. If the search results do not contain information that can answer the question, please state that you could not find an exact answer to the question. Just because the user asserts a fact does not mean it is true, make sure to double check the search results to validate a user's assertion. Always respond in Korean.
                            
Here are the search results in numbered order:
$search_results$

당신은 질문에 답변하는 에이전트입니다. 제가 검색 결과 세트를 제공할 것입니다. 사용자가 질문을 할 것입니다. 당신의 임무는 오직 검색 결과의 정보만을 사용하여 사용자의 질문에 답변하는 것입니다. 만약 검색 결과에 질문에 답변할 수 있는 정보가 포함되어 있지 않다면, 질문에 대한 정확한 답변을 찾을 수 없었다고 말씀해 주세요. 사용자가 사실을 주장한다고 해서 그것이 반드시 사실인 것은 아니므로, 사용자의 주장을 검증하기 위해 반드시 검색 결과를 다시 확인해 주세요. 항상 한국어로 응답해 주세요. 

다음은 순서대로 정렬된 검색 결과입니다: 
$search_results$

EKS 클러스터 접근 구성

• kube-setup.sh 실행 후 모두 y 로 응답

  • ClusterRole과 ClusterRoleBinding 객체를 생성

  • aws-auth ConfigMap 업데이트 수행

  ./kube-setup.sh
  kubectl get cm aws-auth -n kube-system -o yaml

  
  

Bedrock 테스트

Amazon Bedrock 대시보드에 내장된 채팅 인터페이스를 사용하여 에이전트 지식베이스와 액션 그룹을 먼저 테스트해봅니다.

지식 기반(Knowledge bases, RAG) 테스트

• Amazon S3 버킷에서 데이터 소스를 동기화해야 합니다. 동기화는 데이터를 벡터 임베딩으로 변환한 후 지식베이스에 적재하는 과정입니다. 설정에 따라 생성된 OpenSearch Serverless에 저장됩니다.

동기화 (S3 -> OpenSearch)

• Amazon S3 버킷에서 데이터 소스를 동기화해야 합니다. 동기화는 데이터를 벡터 임베딩으로 변환한 후 지식베이스에 적재하는 과정입니다. 벡터 DB는 앞서 CloudFormation에서 OpenSearch Serverless로 선택했었습니다.

• Amazon Bedrock 서비스로 이동 -> 좌측 지식 기반 메뉴 선택 -> 생성된 k8s-docs-knowledge-base 글자를 눌러서 세부 설정 진입

• 데이터 소스 카테고리에 k8s-docs-data-source 앞의 라디오 버튼 체크 후 우측의 동기화 버튼 클릭

• 상태가 Syncing 으로 변한뒤 일정 시간이 지나면 다시 Available 로 변경 됩니다. 데이터 양에 따라서 수분에서 몇 시간 까지도 걸립니다. 본 실습에서는 15분정도 소요됩니다.

• 데이터가 변경되면 변경 분에 대한 동기화가 필요하며, 마지막 동기화 시간을 통해서 동기화 상태를 참고 하실 수 있습니다.

• 현재는 청킹 전략을 Default로 하였지만, 문서 성격에 따라 다양하게 설정할 수있습니다. 다음 문서를 확인해 보세요.

  https://docs.aws.amazon.com/bedrock/latest/userguide/kb-chunking-parsing.html

  
  

Bedrock 지식 기반 사용해 보기

• 동기화가 완료되면 우측의 Test knowledge base 라고 적인 내장된 채팅 인터페이스를 사용할 수 있습니다.

  • 아직 Markdown 및 개행 표시가 제대로 안되어서 가독성이 조금 떨어져 아쉬운 점이 있습니다.

• 모델 선택버튼을 눌러 Claude 3.5 Sonnet 을 선택합니다.

• 상단 왼쪽에 있는 Configurations 아이콘을 선택하면 세부 설정이 가능합니다.

  
  

• Kubernetes 및 EKS 도메인별 지식에 접근할 수 있는 질문을 하여 지식 기반 서비스를 통해 벡터 서치가 잘 되는지 확인해 봅니다.

• 답변 우측 아래 소스 세부 정보 표시 를 누르면 실제 검색된 청크 내용과 원문 위치를 메타데이터에서 확인 할 수 있습니다.

  
  

Bedrock 에이전트 사용해 보기

• Amazon Bedrock -> 에이전트 -> devocean-eks-agent 선택 후 Edit in Agent Builder 버튼을 선택해서 현재 설정된 내용을 살펴 봅니다.

  
  

  
  

  
  

• 우측 테스트 창에서 준비 버튼을 눌러서 Bedrock 에이전트를 준비 상태로 바꾸면 채팅을 시작 할 수 있습니다.

• EKS 클러스터에 대한 쿼리를 수행할 수 있는지 확인합니다. Api가 정의된 네임스페이스, 포드, CIS 벤치마크 규정 준수 보고서 확인과 관련된 질문을 해봅니다.

• Agent에게 질문을 하였을 때 Trace를 해보면 먼저 어떻게 해야 계획을 세우고, 그에 따라 API, RAG를 통해서 실행하는것을 알수 있습니다.

• Pod 현황을 물었을 때 7단계에 걸쳐서 Kubernetes API를 통해 Namespace 리스트를 조회하고, 각 Namespace별 Pod를 조회한뒤 내용을 취합하여 결과를 정리해줍니다.

  
  

  아래 에서 보듯이 Trace Step에서 rationale과 invocationInput 을 따라 가보면 Agent가 어떻게 판단하고 수행하는지 보다 쉽게 알아볼 수 있습니다. ( Step 2~6 은 namespace별 get-pods를 실행하는 부분입니다)

  
  

• 아래는 CIS 리포트 요청 결과 입니다. /reports/cis API를 잘 호출하고 있네요.

  
  

• Agent가 지식 기반(RAG)도 잘 활용하는지 일반적인 질문으로 확인 해 보겠습니다.

  
  

• 더 해볼수 있는 것들.

  • Edit in Agent Builder 를 선택하면 제일 아래쪽에 고급 프롬프트 항목이 있습니다.

    여기에서 전처리 , 오케스트레이션, KB 응답 생성, 후처리 에 대한 프롬프트 및 설정값을 각각 지정해서 더욱 좋은 결과물을 만들어 낼 수 있습니다.

  • 지식 기반을 만들때 청크 방법을 바꿔 가며 결과를 비교해 봅니다.

리소스 삭제

• 실습을 마쳤으므로, 추가적인 비용발생을 막기 위해 생성한 리소스를 모두 삭제합니다.

EKS 삭제 - 10분 소요

eksctl delete cluster --name devocean-agent-eks

S3 Bucket 및 Data 삭제

AWS_ACCOUNT=$(aws sts get-caller-identity --query "Account" --output text)

aws s3 rm s3://devocean-bedrock-knowledge-base-data-source-$AWS_ACCOUNT --recursive --quiet
aws s3 rb s3://devocean-bedrock-knowledge-base-data-source-$AWS_ACCOUNT

aws s3 rm s3://devocean-bedrock-agent-openapi-schema-$AWS_ACCOUNT --recursive --quiet
aws s3 rb s3://devocean-bedrock-agent-openapi-schema-$AWS_ACCOUNT

aws s3 rm s3://devocean-bedrock-agent-lambda-artifacts-$AWS_ACCOUNT --recursive --quiet
aws s3 rb s3://devocean-bedrock-agent-lambda-artifacts-$AWS_ACCOUNT

aws cloudformation delete-stack --stack-name bedrock-agents-for-eks-stack

결론

실습을 통해 Amazon Bedrock 에이전트의 다양한 기능을 확인하고, 예시로 에이전트를 통해 지식기반을 검색하고,

Kubernetes의 상황을 조회하고, Trivy Operator가 생성한 CIS 벤치마크 규정 준수 보고서를 요약하는 기능까지 확장해 보았습니다.

LLM 기반 AI 에이전트인 Amazon Bedrock 에이전트를 통해 자연어를 기반으로 외부 자원에 접근하고 관리하는 새로운 인터페이스를 제공하여

복잡한 시스템 관리에 대한 접근성을 혁신적으로 향상시킬 수 있는 가능성을 보았습니다.

이를 통해 기술적인 배경이 없는 사용자들도 복잡한 시스템을 효율적으로 관리할 수 있게 되며,

이는 기업의 운영 효율성과 비용 절감에도 큰 기여를 할 수 있을것으로 생각됩니다.

미래에는 AI 에이전트가 더욱 지능화되어 다양한 분야에서 자율적으로 의사 결정을 내리고, 에이전트끼리 통신하며 복잡한 문제를 해결할 수 있는 능력을 갖추게 될 것입니다.

이를 통해 AI 에이전트는 인간과 협력하여 새로운 가치를 창출하는 중요한 동반자로서, 미래의 다양한 산업에서 중요한 역할을 할 것으로 기대됩니다.