06. 학습의 단계_AWS Bedrock_ 두번째 강의 - 2일차 -
2025년 4월 29일
- Bedrock 두번째 강의 수강 시작.
1단계. 학습의 단계
1. AWS Bedrock
첫번째 강의) Building Multi-Agentic AI Workflows on AWS Bedrock: 수강완료 (2025/4/13~04/16)
두번째 강의) Learn Agentic AI Basics, Amazon Bedrock Multi-Agent Framework, Build 2 Use Cases- Hotel Booking & Multi-Agent Travel App: 수강시작 (2025/4/29~)
I. 수강 전 기대
첫번째 강의에서 아쉬웠던 Hands-on을 조금 더 해볼 수 있을 것으로 기대함. 커리큘럼을 보니 간단하지만 Bedrock에서 만든 multi agent를 프론트로 배포하는 것도 배울 수 있는 것으로 보임.
II. 수업내용
1일차(4/29): 앞으로 배울 내용 개괄 + AI Agent 5가지 요소 (Planning, Tools & Actions, Memory, Guardrails, Agent Communication)
2일차(4/30). 어제 배운 AI Agent의 기능 중 첫번째 Planning에 관한 Demo ~ Agent Communication
두번째 요소인 Tools & Action에 대한 세부 내용
: AWS Bedrock 관점에서 각 AI Agent는 예를 들어 AWS Lambda를 툴로 사용하여 특정 작업을 수행할 수 있다. 이를 통해 수행할 수 있는 부분은 다음과 같다.
(강의에 소개된 예시들 목록)
Tool to access DB,
Google search,
RAG(Retrieval-Augmented Generation)-SharePoint,
Code Interpreter for running custom code,
Weather API,
Travel Booking 등.
일반적으로 클로드와 같은 LLM은 그 자체로는 "지금 현재 특정 지역의 날씨"를 안내할 수 없다.
그러나 Tools calling 이나 Function calling을 통해 이러한 작업들을 수행할 수 있다. 이를 가능하게 하는 부분이 AWS Lambda, RAG App - Bedrock Knowledge Bases 등이며, (강의에 등장하진 않지만) MCP 또한 AI Agent가 Tool 또는 Function을 수행하도록 돕는다.
그렇다면 AI Agent는 사용자의 요청을 기반으로, 어떻게 어떤 Tool 또는 Function을 Call해야하는지 판단할 수 있을까? 이 부분은 간단히 말해 Powered by LLM이다. 첫번째 강의에서 만들었던 Supervisor Agent처럼 사용자의 요구사항을 분석하고 요구사항을 기반으로 어떤 작업을 수행할지 판단하는, 그리고 각 작업의 결과물(Observation)들을 취합하여 사용자에게 답변을 제공하는 Agent가 존재한다.
두번째 강의 예시에서는 Tool calling 개념을 설명하기 위해서 더 다양한 예시를 제공한다.
사용자로부터 휴가기간 동안 머무를 숙소를 예약해달라는 요청을 받았을 때, 해당 AI Agent는
- 휴가 정책에 대해서는 AWS Knowledge Base에 등록해놓은 정책 문서를 참조하여 판단하고,
- 잔여 휴가일자를 확인하기 위해서는 AWS Lambda에 설정된 Action Group(API 2)를 활용하여 사용자의 잔여 휴가일자를 DynamoDB에서 확인 후 불러오고
- 호텔 예약을 위해서 AWS Lambda에 설정된 Action Group(API 1)를 활용하여 예약 후 예약정보를 불러왔다.
이 모든 것은 서비스 제공자(공급자)가 사전에 구축해놓은 MAS(Multi Agent System) 덕분이며, MAS에 AI Agent, Knowledge Bases, Action Groups, DynamoDB를 사전 셋업 해놓았기 때문에 가능하다.
그 다음으로는 세번째 요소인 Memory에 대해 학습한다.
Memory는 크게 Short Term Memory와 Long Term Memory로 나뉜다. 사람으로 치자면 작업기억과 장기기억 정도가 될듯 싶다. AI Agent에서 말하는 각각의 Memory는 어떤 역할을 하는지, 또 어떻게 사전에 세팅할 수 있는 것인지 궁금하다.
LLMs are stateless (No memory). 본래 기본적으로 LLM들은 메모리가 없다고 한다. (왜 그렇지?)
Short term memory는 특정 세션 안에서만 사용자와의 대화 및 인풋을 기억하는 것을 의미한다. 특정 세션이란 LLM에서 부여하는 session ID를 의미한다.
실제로 AWS Bedrock에서 Agent와 쳇을 하게 되면, Trace 옆 탭에 Session summaries 라는 탭이 존재하고, 해당 탭에서는 이전의 interaction 내역들을 session ID 별로 요약하여 저장하고 있음을 알 수 있다.
Long term memory는 이전의 모든 Interaction 안에서의 대화들을 기억한다. 그러나 LLM 관점에서는 문자 그대로 사용자와의 모든 대화를 기억하는 것은 아니고(만일 이렇다면 엄청나게 많은 저장 공간이 필요해질 것이다.), 각 세션이 완료될 때마다 해당 인터렉션을 요약한 이후에 요약된 정보를 저장한다.
AI Agent의 네번째 요소는 Guardrails다.
Guardrail을 통해 보다 안정적인(responsible) AI application을 만들 수 있다.
Guardrail은 특정 도메인에 한정된 AI 서비스를 만들 때 유용하고 (예: 보험, 금융 등), 해롭거나 공격적인 또는 부적절한 내용들에 대해 인식하고 이러한 내용이 AI 서비스의 성능을 저해하지 않도록 제어한다. 또한 LLM의 한계 중 하나인 Hallucination을 예방한다.
마지막 다섯번째 요소는 Agent communication이다.
여기서는 Single AI Agent와 Multi AI Agent 간의 차이를 설명한다.
Single Agent 역시 사용자의 요구사항을 decomposition하는 작업을 동일하게 하고, 다양한 Tool calling을 통해 외부 서비스를 활용한 답변들을 받을 수도 있다. 그러나, Single Agent는 복잡한 사용자 질문에 대해서 혼동할 가능성이 높고, 이 경우 부정확한 수행 또는 답변을 제공할 수 있다.
현재 수강 중인 Section2: Evolution of AI Agents and Core Capabilities 의 마지막 순서는 강사 분이 많이 받는 질문 중 하나인 'Generative AI vs Agentic AI'에 대한 내용이다.
기본적으로 생성형 AI를 활용하여 Agent를 만들고, 이러한 Agent를 기반으로 작업 수행 등을 하도록 하는 것이 Agentic AI가 아닌가? 따라서, 아직 강의를 듣기 전 현재의 나로서는, 생성형 AI가 더 큰 범주이고 이를 통해 Agentic AI를 구현하는 것이라고 이해하고 있다.
강사 분의 설명에 따르면, Generative AI 와 Agentic AI 는 모두 LLM을 기반으로 만들어지지만 다음과 같은 부분에서 다르다. 가장 큰 차이는 Generative AI는 말그대로 무언가를 생성하기 위한 AI다. 따라서 Text, Image, Code를 생성한다. 그에 반해 Agentic AI는 "사람의 개입을 최소화"하면서 복잡한 작업들을 자동으로 수행하는 것에 초점을 맞춘다.
내일부터 배우게 될 Section 3의 주제는 Deep Dive - Amazon Bedrock Agents 다.
첫번째 강의에서 개괄적으로 배웠던 내용과 어떤 부분에서 차이가 있을지 기대된다. 또는 비슷한 작업을 한다고 하더라도 복습한다는 생각으로 다시 빠르게 수강해봐야겠다.
댓글
댓글 쓰기