July 01, 2025
AWS Agent day 에 참석하고, 듣고 생각났던것들을 그대로 적은 글..
이전에는 단순하고 간단한 물체를 학습하고 인지할 수 있다가 2015년의 딥러닝임
그 이후, 알파고가 이세돌을 이기게 되면서 공포가 생김.
한편으로는 아직도 인공지능은 치와와이미지와 블루베리머핀을 구분 못하는데? 이야기도 물론 나옴
이후 논문이 나왔는데, attention is all you need 21세기 가장 많이 인용된 논문이라는것 같음.
이 논문 기준으로 트랜스포머라는 새로운 딥러닝 아키텍쳐가 생김
AI가 무엇을 잘하게 만들 것인가.
트랜스포머 이전에는 주어진 입력에 대해 정답을 맞추거나 행동을 선택하도록 학습만 시켰음.
고양이사진? 이 뉴스 스포츠? ➡️ 이미지, 텍스트 각각을 기준으로
결과적으로는, 특정 작업에 특화된된 ai를 따로따로 만들었어야
트랜스포머 이후, ai가 단순 정답을 맞추는게 아닌, 맥락을 이해하도록 해보자.
단어들의 앞 뒤 관계성을 이해하고 주어를 찾도록 하자.
이미지나 음성을 모두 처리할 수 있도록 확장
앞 뒤 관계성을 파악할 수 있어서 병렬로 처리하고 이해하고 빨라지고 긴 문맥을 이해할 수 있음
➡️ 창의적인 결과물을 낼 수 있음. 코드를 생성하고, 이미지를 생성하고
트랜스포머 모델(이해하고 생각하고 생성하고) 출시 이후 대규모 처리가 가능해지면서 gpt 모델이 나옴 빠르고 다양한 llm 탄생, 발전함
사실 gpt가 눈에 띄긴 했지만, 이전부터 정~ 말 많은 ai 모델이 연구되었음.
아직까지는 텍스트 기반이였으나 최근부터는 사람같은 ai가 나옴
스스로 생각하고, 기억하며, 여러 단계를 실행 조율할 수 있는 AI 시스템
Chain of Thought(CoT): AI가 단계별로 추론하는 능력
Reasoning and Acting(ReAct): 생각을 하고, 답을 내고, 스스로 검증함
Agentic AI의 4가지 핵심 패턴
위 내용의 패턴들을 AWS 사이트에서 정리해둔게 있음
다양한 툴과 데이터를 ai와 규격화 된 소통 방식. 소통 프로토콜임
각 agent ai가 지들이 필요한 데이터를 각각 설정을 해줘야 했으나, 통합된 방식을 구축하여 더 빠르게 개발할 수 있음. 통일화된 소통방식이기 때문에 보급도 용이함 Mcp 서버 내에서 받아오는 정보처의 변경을 수렴, 반영하기 때문에 각각의 app 단위에서는 고려할 필요 없음.
생성형 ai: 단순 콘텐츠를 생성함 실시간 적응 없음 에이전트형 ai: 더 자율성이 있고, 주도적으로 작업을 계속, 실행함
2017년 트랜스포머 개념이 생기고, 2022년 말 생성형 ai가 생기고 정말 빠르게 바뀌고있음. 작년 능동적으로 생각하는 agent ai 개념까지 하지만 아직도 시작단계임.
상품이미지를 받고, 속성(티셔츠, 네이비, 화이트, 긴 소매…)을 추출하고 번역을 하고.. —> Agent는 아님. 그냥 이미지를 보고 상품속성 뽑고, 번역을 하고 그냥 워크플로우라고 볼 수 잇음
그러면
속성 추출, 번역을 하는 과정에 검수를 하고 개선을 한다는건 Agent라고 할 수 있을까? —> 얘도 이렇게 정해진 흐름을 따라가는거라면 Agent라고 보기 어려움
근데 검수와 개선을 우리가 정해준게 아니라 스스로 생각하고 판단해서 한다면 Agent라고 볼 수 있음.
즉, 스스로 생각하고 판단하고 수행한다면 Agent라고 볼 수 있음
그래서 결국 단순 워크플로우가 아니라 스스로 추론하고 계획을 세우고 과제를 해결하는것이 Agent 임
이 둘의 차이점은 스스로 판단하고 결과를 바꾸거나 수정하는점과 정해진 틀을 따라가는것
Agent
워크플로
코드기반으로 Agent를 만들 수 있는 sdk임 한번도 사용해보지 않은 파이선..
어쨌든, 대충 예시 보니깐 어렵지 않음. 어떤 툴(내가 보기엔 어디에서 정보를 가져올 지)을 연결된 에이전트를 만들 수 있음
확장성 기준으로 단일 Agent는 한계가 있음 여러가지 툴들을 주면서 agent가 사용하는 툴이 늘어나기만 한다면 agent가 헷갈려하기 시작함 병렬로 수행할 수 있는 기능인데 하나의 agent에게 다 주면 오래걸릴 수 있음. > 하지만, 이제 에이전트 내 에서 사용되는 툴 자체도 병렬로 가능해져서 좀 완화된 상태라고는 함
분석 툴, 차트 툴, 검색 툴, 전문가 연결 툴, db 검색 툴 등등등등.. 여러개를 하나의 Agent에게 작업 요청을 함 이것들을 사용해서 재생에너지 보고서를 써줘 근데, 이 많은 툴들 중에서 두개정도 쪼금만 깔짝 써서 보고서를 씀
agent를 여러개로 구분해서 검색 에이전트 ,분석 에이전트, 검증 에이전트, 프레젠테이션 에이전트를 나누고 이 에이전트들을 통괄적으로 조율하는 에이전트 하나 동일하게 재생에너지 보고서를 써줘 하면 각 에이전트들이 자신의 일에 집중해서 단계적으로 진행하는것을 볼 수 있음.
이 Mulie Agents들을 사용하는 패턴이 있다고 함. 이러한 패턴들은 위 Strands Agents sdk에 구현도 되어있다 함.
기능을 부여한 각 에이전트들이 자기 일을 끝내면 다른 에이전트가 참고할 데이터를 연결해줄 수 있음. 즉, 위에서 검색에이전트의 결과를 분석에이전트가 사용할 수 있도록 작성해두면 됨 —> 누가 누구의 결과를 참조… 단계가 있음. 이를 통해 결과 도출
마케팅전략 에이전트들, 비판해주는 에이전트 하나 해서 각자의 전략을 서로 비판(?)하며 토론을 함 이 토론을 주최할 에이전트도 물론 있음 이 토론된 내용을 가지고 뭐.. 타이틀 뽑는 에이전트, 내용 랭킹 정리하는 에이전트 등등.. 으로 요약 함
근데 가끔 절망적으로, 토론을 하는 에이전트들끼리의 토론이 완료되지 않는 경우가 있음. 끝없이 토론을 함. 그래서 이 토론의 제한횟수를 주는것도 중요. Etc 10번이상 넘기지 마.
연구하는 에이전트, 창작 에이전트, 비판 에이전트, 요약 에이전트 각각 에이전트들에 질문을 던져줌. 각각의 에이전트들에 다른 에이전트들의 의견을 참고하라고 달아줌. 이 다른에이전트들의 의견을 참고하여서 전략을 다시세움 이렇게 각각의 에이전트가 서로간 의견을 참고하여 의견을 수정하여 결과를 냄 요약하는 에이전트들이 이 결과를 요약함
가장 흔함. 질문을 했을 때, 상위에서 받아서 적합한 에이전트들이 일을 처리
근데 잘못하면 시간이 오래걸림
어케 개선할 수 있음? Llm 호출 최소화하여 호출횟수를 줄여야 응답을 빨리받을 수 있음
그냥 처리 자체를 병렬로
라우팅 토큰을 구현함(에이전트와는 거리가 멈)
그러면 agent 별로임..?
아님. Scientific agent ai 사례
과학자들의 연구를 도와주는 AI agent를 구글에서 발표함 웹이나 학술 db를 검색하는 에이전트 팩트체크하는 에이전트 이미 만들어진 아이디어 기반으로 발전시키는 에이전트 비슷한것들을 합쳐주는 에이전트 여러 연구 아이디어들로 토너먼트를 해서 랭킹을 세우는 에이전트
➡️ 사용해보니 우리가 몇달 몇일을 고민하여 결정을 내렸던것을 얘는 몇시간만에 해주더라.. 라는 의견을 남김
이거 근데 패턴들 보니깐 왜이렇게 사람들같냐
이후, Amazon Q, Amazon QuickSight, AWS Bedrock 등 소개가 있었고, Aws Bedrock은 실습하는 과정이 있었음. AWS에서 제공하고있는 서비스를 소개하는 내용들이였어서 개인적으로는 소장하고있으나, 해당 글에 담지는 않는것으로..
내가 이 AWS Bedrock을 제안, 적용해볼줄은.. 저땐 몰랐지..