[AWS] Developing Generative AI Applications with Amazon Bedrock

Agent는 Prompt + Model + Tool이다.

Agentic AI를 구축할 때는 컨텍스트가 섞이지 않도록 개별 Agent를 만들고 Orchestrator 하도록 하는 방향으로 구현한다.

S3 스토리지에 보통 정책이나 지식문서를 담고, S3 Vector를 사용하여 Vector 데이터를 담고, Bedrock KnowledgeBase에 담고 조회하여 사용하는데, KnowledgeBase는 Agent에는 하나의 Tool에 해당한다. Lambda 함수 또한 하나의 Tool이 될 수 있다. Dynamo DB가 직접 하나의 Tool이 될 수가 있다.

Tool은 MCP(Model Context Protocol, LLM에 Tool 정보를 제공하는 표준화된 메시지 포멧) 포멧의 Tool로 Agent를 구현한다.

 

AgentCore (MCP) Gateway란?

Agent에 Tool을 직접 붙일 수 있으나, Gateway가 Hub 역할을 해서 LLM과 MCP Tool 목록을 자연스럽게 연결시켜준다.

 

Multi Agent의 대표 유형

1. Multi Agent가 주로 Orchestrator - Special(Sub) Agents 방식[Agent as tool]으로 동작하지만, 모든 Multi Agent를 Orchestrator 방식으로 구현할 필요 없다. Workflow(순차적) 방식으로 구현해도 되고, Parellel(병렬적) 방식, Swarm(병렬로 수행하고 가장 잘한것을 선택하는 방식), Graph 방식도 있다.

 

2. Swarm(군체 지능) 방식 에는 정보와 context를 공유하여, 여러 Agent에게 작업을 분배해 병렬로 문제를 해결

여러가지 모드가 있다. 자율적 병렬 작업(각 Agent가 상급자 없이 작업하며, 협력으로 고난도 문제 해결)

- Collaborate(협력) : 각자 병렬로 수행하든지 각자 한 작업으로 협력하는 것

- Competive(경쟁) : 각자 병렬로 수행하고, 무엇이 나은지 결정해서 결과 반환

- Hand-off(인계) : 각 Agent의 프롬프트에서는 A업무는 A Agent를 호출하고, B업무는 B Agent를 호출하라는 프롬프트가 들어감

Entry agent를 지정해서, 초기 사용자 쿼리를 입력 받을 Agent를 결정해주어야 한다. Orchestrator Agent는 아니다.

 

3. Agent Graph 방식이란 분기가 있는 것을 의미한다. Workflow 방식은 한 방향으로만 흐른다. 

Graph는 Node와 Node간에 연결이 있어서, SubAgent가 SubAgent를 특정 조건에 호출도 가능하다.

SubAgent를 Node로 만들고, 분기 조건을 Condition으로 정의해서 연결하여 workflow의 진행 방향을 정의

 

4. Workflow 방식

 

Bedrock 서비스는 Foundation Model을 제공하는게 주된 목적인 서비스이다.

Bedrock은 AWS가 Managed 하게 배포한 것이고, 사용자는 배포된 것을 사용할 뿐이다.

Bedrock에서 Agent를 가볍게 만들어볼 수 있고, 여러가지 빌더 기능들을 제공한다.

그러나 Agent를 배포하고 있는 주체가 AWS Bedrock 서비스 내에 있기 때문에, 내 PC나 다른 곳에서 Bedrock 서비스만으로는 수행하려면 한계가 있다. Strands Agent Framework가 도움을 줄 수 있다.

 

Agent를 만들 수 있는 여러가지 방법

- 코딩을 통해서..

- Managed Service를 통해서..

 

Bedrock Guardrail 

- Bedrock 서비스의 입출력의 규칙을 정한다.(어떻게 필터링하나요?)

- 5가지 영역의 해로운 컨텐츠를 Block할 것인지, Detect할 것인지 결정할 수 있다.
- 컨텐츠, 단어 필터

- PII (개인정보) 마스킹, Block 처리

- 프롬프트 해킹 방지

- 그라운딩 체크 (참조 소스 체크해서 신뢰도가 있는 수준을 정하여 결과를 응답을 못하도록 할 수 있다.)

- Reasoning Check (Automated Reasoning 정책 [사용자가 규칙들을 명시]을 결정하여, RAG 응답이 온 것을 규칙에 맞게 검토하여 정확하게 응답했는지 체크한다.)

 

AgentCore 는 Production Agent 배포*운영을 돕기 위한 서비스이다.

- Agent를 만드는 것은 쉽지만, 인프라적으로 완전히 안정적으로 서비스되도록 지원해준다.

 

AgentCore Runtime

- 해당 서비스에 올리면 서버리스처럼 동작하여, 안정적으로 동작하게 해준다.

 

MCP (Agent(LLM)와 Tool 간에 통신 규약, 2024년 등장)

 

A2A (Agent와 Agent 간에 통신 규약, 2025년 등장)

 

Orchestrator에 Agent 목록을 등록해도 되고, A2A Server를 통해서도 가능

 

AgentCore Registry는 Agent들/MCP 도구들/MCP Server/A2A Server를 등록하고, Orchestrator가 참조하도록 한다.

 

AgentCore Gateway에 AgentCore Registry를 등록해서 A2A Server 처럼도 사용할 수 있다.

 

Agentic AI의 고려할 점

- 사용자 인증

- 아무 Agent나 어떤 Tool을 호출할 수 있으면 안되도록 인증을 해야한다.

 

AgentCore Identity

- Agent가 접근할 수 있는지 인증을 관리

- AWS Cognito를 연동시킬 수 있다.

 

AgentCore Observability(Cloud Watch)

 

AgentCore Evaluation

- Agent가 잘 동작했는지 테스트해보는

 

AWS SSM(SystemS Manager) Parameter Store 서비스란?

- AWS에 변수를 저장해 놓고 사용하고 싶을 때

 

Strands 프레임워크에서는 debugging할 수 있도록, 로깅할 수 있는 기능들을 제공한다.

 

Embeddling Model도 LLM Model 이지만, Encoder만 있는 모델이고, 일반적인 LLM Model은 Decoder까지 포함된 모델이다.

이미지나 동영상이 있는 컨텐츠의 경우, Multimodal Embedding LLM Model을 써야하고, 그것을 기반으로 텍스트화 시키고 Chunk 단위(말뭉치)로 쪼개서 Vector화 시킨다.

 

Chunking의 방식

1. Fixed

2. Semantic -> 유사한 데이터가 여러 군데 흩뿌려져있을 경우, chunking 단계부터 LLM? 이 사용되어 의미론적으로 유사한 것끼리 묶어서 chunk를 분류해준다.

3. Hierarchical -> 

 

AWS Sdk로 서비스를 사용/조작하려면...

- 먼저 boto3 라이브러리로 해당 서비스와의 session을 만들고, 리소스 엔드포인트를 알아야 한다.

```

// 보통은 서비스명이 서비스 엔드포인트명이랑 동일

boto3.client('s3')

```

- bedrock은 다른 aws 서비스와 다르게, 6개의 service endpoint가 존재한다.

```

boto3.client('bedrock') : Bedrock 제어 영역(모델 설정)

boto3.client('bedrock-runtime') : Bedrock 데이터 영역(모델 호출), Invoke_model(), converse().

boto3.client('bedrock-agent-runtime') : Bedrock에서 만들어 놓은 Agent들을 호출하고 싶다면.

```

 

Q. invoke_model과 converse 함수의 차이는 무엇일까?

- 초기에는 invoke_model이 있었고, 일반적으로 응답을 모델별로 처리해야 했음

- converse 함수는 내부적으로 foundation model별 처리를 내장하고 있어. response를 더 쉽게 사용 가능함(단, 호완되지 않는 model은 invoke_model을 사용해야 함

 

---

모듈 1: LLM에서 에이전트까지의 변천사

인공 지능 발전의 여정

1. Rule-based Data Processing : 룰 기반 AI. 앨런 튜링이 컴퓨터가 인간처럼 되려면, 대화가 가능해야된다고 생각함. 현실적으로는 어려웠음

2. Machine Learning : 정답지 기반 분류 / 예측 모델 기법 -> 특성을 미리 사람들이 정의하여 주어야 함. 사람이 모든 속성과 특성을 추출하기에는 어려움

3. Neural Network (Deep Learning) : 인공신경망, 인간의 시각, 청각, 언어 학습 방식을 모방 -> 미리 특성을 정의하여 전달하지 않고, 모델이 가중치를 내부적으로 결정. 모델이 수많은 속성과 특성을 추출

- Convolutional Neural Network : 인간의 시각, 청각을 모방

- Recurrent Neural Network : 인간의 언어를 모방해서 다음 단어들을 예측하도록 함

- Generative Adversarial Network : 이미지를 생성하는 모델 기법 / 내부적으로 요청된 텍스트와 관련된 이미지를 만들고 판단하고 아닌지 계속 반복적으로 생성해서 최종 결과를 반환하는 알고리즘

4. Transformer : Recurrent Neural Network의 단점 (순차적으로 Sequential 하게 처리하니까, 너무 느리고, 앞의 문맥을 잃어버림)을 극복하기 위한 알고리즘의 등장(2017), 지금의 언어 모델들은 다 Transformer 알고리즘을 통해 학습을 시킴

기존 RNN은 단어 정도는 알고, 말을 할 수 있었지만 사람 처럼 전체 의미와 문맥을 이해 및 파악하고 처리할 수는 없었다.

 

===

이 때까지는 모델을 "의도된 Task"를 가지고 학습시키고 발전시켰는데, LLM Foundation Model은 처음에는 다음 언어를 생성할 수 있게끔 하려고 만들어진 것이었는데, 공학적으로 의도하지 않은 사고 능력이 발현되었음.

CPU로 학습 시키다가, weight 계산 처리하기 위한 병렬 GPU가 학습시키는 것이 더 좋다는 사실을 발견함

그래픽의 픽셀처리도 그렇기 때문에, 픽셀 하나가 가중치 하나 계산하는 것과 비슷하다고 판단되어, GPU로 학습을 함.

의도치 않게 "대량의 학습 데이터", "막대한 GPU 리소스"로 학습 시켰더니 성능이 너무 좋게 나옴.

인간의 뇌처럼 베일에 가려진 사고 능력의 발현 원리가 LLM 모델에 나타남. 위험하네.

===

5. GPT/BERT

6. Agentic AI

 

LLM 자체는 목표가 없는 모델이니까, 특정한 목적을 가진 Agent를 만들어 수행하게 하고, 검토하는 것까지 LLM을 사용한다.

Agent = LLM + Tools

---

모듈 2: 에이전틱 AI 살펴보기

---

모듈 3: Amazon Bedrock을 사용한 프로그래밍

---

모듈 4: AWS 에이전틱 개발 및 생산성 도구

---

모듈 5: Agentic AI 프레임워크 구현

- AWS Strand Agent [Agentic AI 프레임워크] <-> LangGraph, LangChain

- AWS Bedrock Agent Core [AI 앱 배포] -> Fully Managed Service (AI Agent가 안정적으로 동작하도록 인프라를 제공 서비스)

Runtime 기능은 컨테이너 서버리스 기능