AWS Agent day

AWS Agent day 에 참석하고, 듣고 생각났던것들을 그대로 적은 글..

Agenda

  • 머신러닝부터 LLM까지
  • Agentic AI의 4가지 디자인 패턴
  • AWS의 Agentic AI

머신러닝부터 LLM까지

이전에는 단순하고 간단한 물체를 학습하고 인지할 수 있다가 2015년의 딥러닝임
그 이후, 알파고가 이세돌을 이기게 되면서 공포가 생김.
한편으로는 아직도 인공지능은 치와와이미지와 블루베리머핀을 구분 못하는데? 이야기도 물론 나옴

이후 논문이 나왔는데, attention is all you need 21세기 가장 많이 인용된 논문이라는것 같음.
이 논문 기준으로 트랜스포머라는 새로운 딥러닝 아키텍쳐가 생김
AI가 무엇을 잘하게 만들 것인가.
트랜스포머 이전에는 주어진 입력에 대해 정답을 맞추거나 행동을 선택하도록 학습만 시켰음.
고양이사진? 이 뉴스 스포츠? ➡️ 이미지, 텍스트 각각을 기준으로

결과적으로는, 특정 작업에 특화된된 ai를 따로따로 만들었어야

트랜스포머 이후, ai가 단순 정답을 맞추는게 아닌, 맥락을 이해하도록 해보자.
단어들의 앞 뒤 관계성을 이해하고 주어를 찾도록 하자.
이미지나 음성을 모두 처리할 수 있도록 확장
앞 뒤 관계성을 파악할 수 있어서 병렬로 처리하고 이해하고 빨라지고 긴 문맥을 이해할 수 있음
➡️ 창의적인 결과물을 낼 수 있음. 코드를 생성하고, 이미지를 생성하고

트랜스포머 모델(이해하고 생각하고 생성하고) 출시 이후 대규모 처리가 가능해지면서 gpt 모델이 나옴 빠르고 다양한 llm 탄생, 발전함
사실 gpt가 눈에 띄긴 했지만, 이전부터 정~ 말 많은 ai 모델이 연구되었음.
아직까지는 텍스트 기반이였으나 최근부터는 사람같은 ai가 나옴

Agentic AI의 등장

스스로 생각하고, 기억하며, 여러 단계를 실행 조율할 수 있는 AI 시스템

Agentic AI의 사고 과정

Chain of Thought(CoT): AI가 단계별로 추론하는 능력

  • 패러다임 전환: 연산 -> 추론
    • 빠른 답을 내는게 중요 목표였으나, 논리적 사고가 필요한 문제인 경우는 못풀었음.
    • 이전에는 나는 10개 사과 1개 먹고 2개 줌, 계산 못함
    • 이후 추론을 하며 생각하기때문에, 중간 단계를 하나씩 텍스트로 지가 생각함
      • 2개 빠져서 8개, 1개 먹어서 7개
    • 답을 낼 때, 자료를 내가 추거나 좀 더 잘 생각해봐 라는 텍스트를 내가 주었을 때 얘가 고민하고 더 나은 답을 내놓는 과정 자체가 CoT임.(llm의 성능을 높이기 위한 여런 방법)

Reasoning and Acting(ReAct): 생각을 하고, 답을 내고, 스스로 검증함

  • 네비게이션 기준 생각을 하고(북쪽으로 감) 어 근데 북쪽 막혀있음. 검증을 함. 여기 아닌것같음. 동쪽으로 가자. 빨라짐. 결과 동쪽으로 가라
  • 사람이 시행착오를 하고 더 나은 답을 내는것처럼 행동함
  • 생각 후 행동이 맞는지 검증까지 하면서, 아니라면 다시 생각함.
  • 비교적 최근 모델이기 때문에, Reasoning 기법이 없는 모델도 있음

Agentic AI의 4가지 핵심 패턴

  • Reflection Pattern
    • 상태 관찰에 기반해 행동을 선택하고 실행
    • 지 결과물을 평가해서 점수를 냄. 심지어 다른 llm에게 평가해달라고도 함
    • 이 점수를 돌아보며 자신이 내린 판단을 평가함
  • Tool Use Pattern
    • llm이 외부 도구를 사용하여 더 많은 정보를 사용할 수 있음
    • 최신의 데이터를 받아오게 함.
    • api를 호출하고 웹 검색을 하고 etc.. (MCP 서버 구축할 때 외부 데이터 연결하는것같은느낌?)
  • Planning Pattern
    • 내가 이 작업을 할 때 어떤 단계가 필요한지 생각하고 작업계획을 구성함
    • 정보부족이나 시간부족등 작업계획을 수정하고 변경하기까지 함
  • MultiAgent Pattern
    • 하나의 ai agent가 모든걸 잘 할수는 없다는걸 알게됨(사람처럼) 정확도도 떨어지고 병목현상도 생김
    • 그러면 여러개의 agent? 그러면 많아진 agent를 관리하는건 어떻게할꺼? 그리고 서로간 통신을 하지 않기 때문에 중복된 작업이 생기거나 상충점도 생김
    • 작업을 하는 여러 agent 상위에 이들을 관리하는 agent가 추가됨. 그냥 관리자 agent로서 따른 일을 하지는 않는데, 관리하는 agent들과 소통을 하고 관리함.

위 내용의 패턴들을 AWS 사이트에서 정리해둔게 있음

  1. Reflection: AI가 자신의 출력을 평가하고 개선하는 능력을 향상시키는 패턴입니다. 이를 통해 AI는 더 정확하고 신뢰할 수 있는 결과를 제공할 수 있습니다.
  2. Tool Use: AI가 외부 도구와 리소스를 활용하여 능력을 확장하는 패턴입니다. 이를 통해 AI는 실시간 데이터 접근, 복잡한 계산 수행 등 더 다양한 작업을 수행할 수 있습니다.
  3. Planning: AI가 복잡한 작업을 체계적으로 접근하고 효율적으로 해결하기 위해 단계별 계획을 수립하는 패턴입니다. 이는 장기 프로젝트 관리나 복잡한 문제 해결에 특히 유용합니다.
  4. Multi Agent: 여러 AI 에이전트가 협력하여 복잡한 작업을 수행하는 패턴입니다. 각 에이전트가 특정 역할을 맡아 전체적인 목표를 달성하는 데 기여합니다.

MCP

다양한 툴과 데이터를 ai와 규격화 된 소통 방식. 소통 프로토콜임

각 agent ai가 지들이 필요한 데이터를 각각 설정을 해줘야 했으나, 통합된 방식을 구축하여 더 빠르게 개발할 수 있음. 통일화된 소통방식이기 때문에 보급도 용이함 Mcp 서버 내에서 받아오는 정보처의 변경을 수렴, 반영하기 때문에 각각의 app 단위에서는 고려할 필요 없음.

generative ai vs agentic ai

생성형 ai: 단순 콘텐츠를 생성함 실시간 적응 없음 에이전트형 ai: 더 자율성이 있고, 주도적으로 작업을 계속, 실행함

2017년 트랜스포머 개념이 생기고, 2022년 말 생성형 ai가 생기고 정말 빠르게 바뀌고있음. 작년 능동적으로 생각하는 agent ai 개념까지 하지만 아직도 시작단계임.

Multi-Agent Collaboration

What are AI Agents

상품이미지를 받고, 속성(티셔츠, 네이비, 화이트, 긴 소매…)을 추출하고 번역을 하고.. —> Agent는 아님. 그냥 이미지를 보고 상품속성 뽑고, 번역을 하고 그냥 워크플로우라고 볼 수 잇음

그러면

속성 추출, 번역을 하는 과정에 검수를 하고 개선을 한다는건 Agent라고 할 수 있을까? —> 얘도 이렇게 정해진 흐름을 따라가는거라면 Agent라고 보기 어려움

근데 검수와 개선을 우리가 정해준게 아니라 스스로 생각하고 판단해서 한다면 Agent라고 볼 수 있음.

즉, 스스로 생각하고 판단하고 수행한다면 Agent라고 볼 수 있음

그래서 결국  단순 워크플로우가 아니라 스스로 추론하고 계획을 세우고 과제를 해결하는것이 Agent 임

언제 Agent를 사용? 언제 워크플로를 사용?

이 둘의 차이점은 스스로 판단하고 결과를 바꾸거나 수정하는점과 정해진 틀을 따라가는것

  • Agent

    • 유연성
    • 추론을 하는 과정에 토큰을 많이 사용함
    • 토큰을 많이 사용하기 때문에 빠르진 않음
  • 워크플로

    • 하나의 태스크를 빠르게 수행
    • 토큰을 많이 사용하지 않음
    • 정해진 틀을 벗어나지 못함. 틀렸다고 해서 잘못됨을 생각하거나 처음으로 돌아갈 수 는 없음

Multi Agents 만들어보자 / Strands Agents

코드기반으로 Agent를 만들 수 있는 sdk임 한번도 사용해보지 않은 파이선..

어쨌든, 대충 예시 보니깐 어렵지 않음. 어떤 툴(내가 보기엔 어디에서 정보를 가져올 지)을 연결된 에이전트를 만들 수 있음

왜 Multi Agents?

확장성 기준으로 단일 Agent는 한계가 있음 여러가지 툴들을 주면서 agent가 사용하는 툴이 늘어나기만 한다면 agent가 헷갈려하기 시작함 병렬로 수행할 수 있는 기능인데 하나의 agent에게 다 주면 오래걸릴 수 있음.   > 하지만, 이제 에이전트 내 에서 사용되는 툴 자체도 병렬로 가능해져서 좀 완화된 상태라고는 함

분석 툴, 차트 툴, 검색 툴, 전문가 연결 툴, db 검색 툴 등등등등.. 여러개를 하나의 Agent에게 작업 요청을 함 이것들을 사용해서 재생에너지 보고서를 써줘 근데, 이 많은 툴들 중에서 두개정도 쪼금만 깔짝 써서 보고서를 씀

agent를 여러개로 구분해서 검색 에이전트 ,분석 에이전트, 검증 에이전트, 프레젠테이션 에이전트를 나누고 이 에이전트들을 통괄적으로 조율하는 에이전트 하나 동일하게 재생에너지 보고서를 써줘 하면 각 에이전트들이 자신의 일에 집중해서 단계적으로 진행하는것을 볼 수 있음.

이 Mulie Agents들을 사용하는 패턴이 있다고 함. 이러한 패턴들은 위 Strands Agents sdk에 구현도 되어있다 함.

Multi Agents 워크플로우 패턴

기능을 부여한 각 에이전트들이 자기 일을 끝내면 다른 에이전트가 참고할 데이터를 연결해줄 수 있음. 즉, 위에서 검색에이전트의 결과를 분석에이전트가 사용할 수 있도록 작성해두면 됨 —> 누가 누구의 결과를 참조… 단계가 있음. 이를 통해 결과 도출

Multi Agents 그래프 패턴 (그냥 추론/토론 과정이 나뭇가지처럼 쭉.. 이어진다 하여 그래프인듯..?)

마케팅전략 에이전트들, 비판해주는 에이전트 하나 해서 각자의 전략을 서로 비판(?)하며 토론을 함 이 토론을 주최할 에이전트도 물론 있음 이 토론된 내용을 가지고 뭐.. 타이틀 뽑는 에이전트, 내용 랭킹 정리하는 에이전트 등등.. 으로 요약 함

근데 가끔 절망적으로, 토론을 하는 에이전트들끼리의 토론이 완료되지 않는 경우가 있음. 끝없이 토론을 함. 그래서 이 토론의 제한횟수를 주는것도 중요. Etc 10번이상 넘기지 마.

Multi Agents 스웜 패턴

연구하는 에이전트,  창작 에이전트, 비판 에이전트, 요약 에이전트 각각 에이전트들에 질문을 던져줌. 각각의 에이전트들에 다른 에이전트들의 의견을 참고하라고 달아줌. 이 다른에이전트들의 의견을 참고하여서 전략을 다시세움 이렇게 각각의 에이전트가 서로간 의견을 참고하여 의견을 수정하여 결과를 냄 요약하는 에이전트들이 이 결과를 요약함

Multi Agents Supervisor/Orchestrator 패턴

가장 흔함. 질문을 했을 때, 상위에서 받아서 적합한 에이전트들이 일을 처리

근데 잘못하면 시간이 오래걸림

어케 개선할 수 있음? Llm 호출 최소화하여 호출횟수를 줄여야 응답을 빨리받을 수 있음

  • 그냥 처리 자체를 병렬로

    • 청바지 검색해줘
    • 검색에이전트가 검색하고, 상품리뷰를 조회하기위해 담당 에이전트에게 다시 넘겨주고 이 과정이 오래걸림
    • 근데, 그냥 청바지검색해줘 했을 때, 키워드를 이미 아니깐 검색하고 상품리뷰조회까지 병렬로 처리하도록 개발을 하는거임
  • 라우팅 토큰을 구현함(에이전트와는 거리가 멈)

    • 각 예상질문을 추려냄 라우팅 토큰을 만든다는것같음
    • Ex) 대한항공 기내 질문 ai 1: 영화 추천, 2: 점심 추천
    • 이런식으로 하면 빠르게 나옴. 즉, 이 케이스는 질문에 대한 능동적으로 추론하고 그런건 아니기 때문에, agent 는 아님. 즉, agent가 항상 맞는건 아니라 함.

그러면 agent 별로임..?

아님. Scientific agent ai 사례

외부 사용 사례

과학자들의 연구를 도와주는 AI agent를 구글에서 발표함 웹이나 학술 db를 검색하는 에이전트 팩트체크하는 에이전트 이미 만들어진 아이디어 기반으로 발전시키는 에이전트 비슷한것들을 합쳐주는 에이전트 여러 연구 아이디어들로 토너먼트를 해서 랭킹을 세우는 에이전트

➡️ 사용해보니 우리가 몇달 몇일을 고민하여 결정을 내렸던것을 얘는 몇시간만에 해주더라.. 라는 의견을 남김

이거 근데 패턴들 보니깐 왜이렇게 사람들같냐

이후, Amazon Q, Amazon QuickSight, AWS Bedrock 등 소개가 있었고, Aws Bedrock은 실습하는 과정이 있었음. AWS에서 제공하고있는 서비스를 소개하는 내용들이였어서 개인적으로는 소장하고있으나, 해당 글에 담지는 않는것으로..

2025-11-11

내가 이 AWS Bedrock을 제안, 적용해볼줄은.. 저땐 몰랐지..


@SangMin
👆 H'e'story

🚀GitHub