(삼정 KPMG future academy 6기 수업) AI agent 2

# Model is 두뇌

 

 

# 모델 추론 방식

방식	구조	특징	적합한 사용 예
CoT	선형(Linear)	단계별 추론	수학, 논리적 문제
ReAct	순환(Reason–Action)	추론과 행동 교차	검색, 에이전트 시스템
ToT	분기(Tree)	다중 탐색	전략적/창의적 문제

 

1. CoT (Chain of Thought) :

모델이 논리적 추론 단계를 순차적으로 따라가는 방식

 

2. ReAct (Reasoning + Action) :

추론과 행동을 번갈아 수행하는 구조.

모델이 생각(Reasoning) 을 통해 다음에 할 행동(Action) 을 결정하고, 그 결과를 다시 다음 추론의 입력으로 사용.
- 단점 : 정확한 판단을 내리지만 시간이 오래 걸림, 리소스 많이 필요하며 제어도 복잡해짐

- ex) 네비 경로 재탐색하고 바꾸고..

 

 

3. ToT (Tree of Thoughts) :

모델이 하나의 경로가 아닌, 여러 아이디어 가지(branch) 를 탐색하며 최적의 해답을 찾는 구조

CoT는 한줄로 생각한다면 ToT는 병렬적으로 생각, 평가하여 가장 우수한 방안을 채택

 

 

# Tools is 손,발

 

1. Tools - extension : 외부 API 연결자(브릿지 역할)

 

• Agent가 직접 API를 호출하는 게 아니라, Extension이 API와 Agent를 연결하는 중간 계층
• 예를 들어, Agent는 “항공권 정보를 찾아줘”라고 명령하면, Flights Extension이 내부적으로 Flights API(Google Flights 등) 를 호출해 결과를 반환
•  

 

 

2. Tools - fuction : 내부 코드 실행용

• Agent가 호출할 수 있는 함수 명세(JSON Schema 기반), 즉 에이전트가 실행할 수 있는 명령어 목록
• 항공권 검색 요청 예시
  1) 사용자가 “서울에서 도쿄 가는 비행기표 찾아줘”
  2) Agent는 Function spec을 보고 → get_flights 호출
  3) get_flights Function 내부는 실제 Google Flights Extension을 통해 Flights API 호출
  4) 결과(JSON)를 받아 Agent가 “이 날짜엔 OO항공이 제일 저렴합니다”라고 응답

 

 

 

# AI Agent 시스템의 요청~응답 전체 생명주기(lifecycle)

① User 단계

• 사용자가 “스키 여행지 추천해줘”처럼 자연어로 요청 전송

② Client side UI 단계

• 사용자의 요청을 Agent에게 전달하는 인터페이스(UI) (예: 웹앱, 챗봇 UI, 앱 화면 등)
• 여기서는 사용자의 Query를 그대로 Agent로 전송
• API call을 왜 여기서 보내는지? 모델이 직접 외부 API를 호출하지 않도록 보안·권한을 분리하기 위해서임
  (API 키·인증 정보가 모델 내부로 들어가면 유출 위험이 있음. 따라서 클라이언트(UI/서버) 쪽에서 안전하게 관리)
  - LLM(Model) 은 단지 “무엇을 해야 하는지”만 판단 -> API 키, 인증, 네트워크 접근 권한은 모델이 직접 갖지 않음
   -> 실제 API 호출은 Client Side(또는 백엔드 시스템)에서 대신 실행

③ Agent 단계 : Agent는 사용자의 요청을 해석하고 Model에 보낼 Prompt를 구성. 조율자 역할

• Prompt에는 “예시(Examples)”와 “지시(Instruction)”가 포함.
• 이때 Function이나 Extension을 이용해 어떤 기능을 써야 할지 결정
• 예를 들어 Agent가 display_cities라는 함수를 호출하도록 모델을 유도할 수 있음.

④ Model 단계 (언어 모델 - LLM)

• Model(예: GPT)이 Prompt를 받아서
  → “이건 display_cities라는 함수를 호출해야겠다” 라고 판단
  → JSON 형식의 함수 호출 명령(Function Call JSON) 을 생성
• 즉, 모델은 직접 API를 부르지 않고, “어떤 함수를 호출해야 하는지”를 JSON 형태로 반환

⑤ Client side (API 호출)

• 클라이언트(혹은 백엔드)가 이 JSON을 받아서 “display_cities → Google Places API 호출” 로 해석
• 따라서 모델이 아닌 시스템(앱) 이 외부 API를 실제로 호출

⑥ Google Places API 단계

• Google Places API가 요청에 맞는 결과(JSON) 를 반환 (예: 스키 리조트 이름, 위치, 이미지 URL 등)

⑦ 결과 반환

• API 결과가 다시 Client → Agent → User 순으로 전달되어 사용자에게 “여기 추천 스키 리조트 목록이에요”처럼 출력

 

 

# Tools - Data stores 

RAG (Retrieval-Augmented Generation) 구조를 구현하는 핵심 구성요소

 

# Agent 흐름

 

* 사람 할 일 : Task를 주고, 도구 제공

* LLM 할 일 : 검색이 필요한건지, 추론이 필요한건지 등등 스스로 Reasoning - 도구 선택, 실행 - 결과 판단 후 반복 또는 종료

 

 

# 다중 에이전트 

 

1. 다중 에이전트 시스템(Multi-Agent System, MAS)은 크게 두 가지 축으로 나뉨

구분	설명
조직형 구조 (Organized, Centralized)	하나의 중심 에이전트(감독자/Orchestrator)가 전체를 통제하는 방식
자율형 구조 (Distributed, Decentralized)	여러 에이전트가 서로 대등한 관계에서 협력하는 방식

2. 각 범주 안의 세부 구조

	세부 구조 유형	설명
조직형 (Centralized)	- Single Agent - Supervisor - Hierarchical	중앙에서 지시하고 하위 에이전트들이 실행하는 형태. Supervisor 구조는 여기 속함.
자율형 (Decentralized)	- Network - Peer-to-Peer	모든 에이전트가 동등하게 연결되어 서로 요청·응답하는 형태. Peer-to-Peer 구조는 여기 속함.
기타 맞춤형 (Custom)	- Hybrid / Custom	특정 업무 목적에 맞게 조직형과 자율형을 혼합한 형태. 예: Supervisor + P2P 혼합 구조

 

3. 추가 유형별 설명

구조 유형	설명
단일 에이전트 (Single Agent)	한 모델이 여러 툴을 직접 사용하는 가장 기본형 구조. 예: ChatGPT가 검색, 계산, 번역 툴을 직접 호출.
네트워크형 (Network)	여러 에이전트가 서로 동등한 위치에서 자유롭게 통신·협력하는 구조. (예: 각자 역할은 다르지만, 서로 요청과 응답이 가능)
감독자형 (Supervisor)	중앙의 ‘감독자’ 에이전트가 하위 작업자 에이전트들을 관리·조율하는 계층적 구조. (예: 프로젝트 매니저형)
감독자 as 도구 (Supervisor as Tools)	감독자가 하위 에이전트를 ‘툴처럼’ 호출해서 사용. 즉, 에이전트가 또 다른 에이전트를 도구처럼 활용.
계층형 (Hierarchical)	감독자 구조와 유사하지만 더 엄격한 위계질서 존재. 상위 → 하위로 명확한 지시와 피드백 경로가 있음.
사용자 정의형 (Custom)	특정 프로젝트나 목표에 맞춰 맞춤형으로 설계된 구조. (예: 협업 방식, 통신 규칙 등을 상황에 맞게 설계)

 

(사용해볼 것 - 참고) 

https://skywork.ai/

MGX (MetaGPT X) – Your AI Dev Team for Vibe Coding | MetaGPT X (MGX)

MetaGPT X (MGX)

 

 

(실습)

- 프롬프트따라 답변 생성 - model -  output

                               + vector DB  +  Tool 을 붙인다. 

 

- 랭체인 에이전트

https://docs.langchain.com/oss/python/langchain/agents

 

 

(참고) 구글에서 만든 AI agent 가이드북

ai_agents_handbook.pdf

5.88MB

 

개요

• AI 에이전트(AI Agent)는 단순한 챗봇이나 자동화 도구를 넘어, 사용자의 업무 의도를 이해하고 데이터를 분석해 스스로 행동(행동 실행, 의사결정)을 수행하는 차세대 AI
• 2028년까지 기업용 소프트웨어의 33%가 Agentic AI를 포함할 것으로 예측되며, 일상적 업무의 15% 이상이 자율적으로 처리될 전망
• 핵심 플랫폼: Google Agentspace + Gemini + Vertex AI
  

AI 에이전트의 주요 활용 10가지

01. 엔터프라이즈 데이터 탐색

• 문제: 기업 내부의 수많은 데이터(Drive, CRM, 이메일 등)를 통합적으로 검색하기 어려움.
• 해결: Google Agentspace의 멀티모달 검색으로 사내 문서, 메일, 시스템 정보를 통합 탐색.
• 효과: 지식 그래프 기반 개인화 검색 → 더 빠른 의사결정.

02. 복잡한 문서를 오디오 콘텐츠로 변환

• 문제: 긴 보고서를 읽을 시간 부족.
• 해결: NotebookLM을 통해 문서를 요약하고 음성 팟캐스트로 변환.
• 활용 예시: 재무 보고서 요약, 투자 분석 비교, 고객 피드백 분석.

03. 아이디어 생성 가속화

• 문제: 아이디어 회의에 시간과 자원 낭비.
• 해결: Idea Generation Agent가 수백 개의 아이디어 생성 → 자가 평가 및 랭킹.
• 활용 예시: 신제품 콘셉트 도출, 앱 기능 개선, 협업 파트너 발굴.

04. 전문가 수준의 리서치 자동화

• 해결: Deep Research Agent가 수백 개 웹·사내 데이터를 기반으로 보고서 생성.
• 활용 예시: 시장 분석, 경쟁사 동향, 산업별 벤치마크 조사.

05. 고객 경험 개인화 (멀티에이전트 활용)

• 문제: 콜센터 및 고객 응대 과부하.
• 해결: 다중 AI 에이전트가 자동응답, 상담지원, 실시간 코칭, 인사이트 제공.
• 효과: 고객 만족도 향상, 응답시간 단축, 상담사 교육 효율화.

06. 마케팅 참여율 및 전환율 향상

• 해결: AI가 고객 데이터 분석 → 맞춤형 카피·이미지 자동 생성.
• 활용: Google Ads, HubSpot 등과 연동해 캠페인 성과 분석 및 개선.

07. 세일즈 사이클 단축

• 해결: 고객 기록, 문의, 거래 현황을 자동 수집·요약해 영업팀에 제공.
• 효과: 중복데이터 제거, 리드 스코어링, 빠른 고객 인사이트 확보.

08. 코드 디버깅 및 개발 지원

• 문제: 오류 추적과 수정에 많은 시간 소요.
• 해결: Gemini Code Assist가 코드 로그를 분석해 오류 지점 탐지·수정 제안.
• 활용: 자동 보일러플레이트 코드 생성, 코드 문서화, 성능 개선.

09. HR 온보딩 및 인사관리 자동화

• 해결: 계약·교육·시스템 접근 설정 등 반복 업무를 AI가 자동 처리.
• 활용: 인재 온보딩, 설문 분석, 직원 이탈 원인 분석, 개인 맞춤형 교육 추천.

10. 직접 AI 에이전트 만들기

• 방법:
  • No-code: Agent Designer를 이용해 비전문가도 자체 워크플로우용 에이전트 제작 가능.
  • Developer: Vertex AI Agent Builder로 커스텀 개발 가능.
• 추가 기능: Agent2Agent 프로토콜을 통한 다양한 에이전트 간 상호작용.

 

 

(실습 정리)

* AI agent 3대 요소 : model, memory, tool

 

* 어떤 툴을 어떻게 연결해주느냐가 젤 중요!

@tool  - 이 코드를 넣어줘야 LLM이 툴이라고 인식
""" """ - tool 사용 설명서

 

* langchain 안에 내장되어있는 tool이 있음. ex) 검색 툴

1) 검색툴 달고

2) csv 파일 또는 DB로 저장 (내장된 tool 이용 DB- SQlite)

3) 단일 tool 2개 생성 → tool 여러개 모여있으면 toolkit 생성

 

 

 

 

(참고) 8개월간의 Production RAG 구축 경험 개요

https://news.hada.io/topic?id=23812&utm_source=discord&utm_medium=bot&utm_campaign=3807

• 총 9백만 페이지(Usul AI), 4백만 페이지(모 익명 법률 AI 기업) 등 대규모 데이터셋에서 RAG 시스템을 구축 및 운영하는 경험을 공유함
• 초기에는 YouTube 튜토리얼을 따라 Langchain에서 Llamaindex로 옮기며 며칠 만에 프로토타입을 완성했으나, 실제 배포시 사용자만이 알아챌 수 있는 낮은 성능 문제가 드러남
• 몇 달에 걸쳐 시스템 구성 요소를 부분적으로 고치며 최적의 성능에 도달했음

 

 

* 로컬을 사용하는 이유? ( https://lmstudio.ai/ )

LM Studio - Local AI on your computer

 

- 보안 때문에 네트워크 막혀있을 경우 (금융, 은행 등) 사용

- 데이터 프라이버시 & 보안 제어 : 로컬에서 실행하면 민감한 입력 / 출력 데이터가 외부 클라우드 서버로 전송되지 않으므로, 데이터 유출 위험이 줄어요. 기업 내부 문서, 사용자 개인정보, 규제 대상 데이터 등을 다룰 때 유리

- 맞춤형 및 커스터마이즈 가능성 : 로컬에서 돌리면 모델을 특정 도메인, 특정 언어, 내부 데이터에 맞춰 튜닝(fine-tuning) 하거나 프롬프트 엔지니어링을 강하게 하기

- 외부 API 호출이나 클라우드 모델 사용 시 종량요금(pay-per-token) 등이 부담이 될 수 있는데, 로컬이라면 그런 비용 모델에서 벗어날 수 있음