Agent의 개념과 주요 구성 요소에 대해 파악하기

들어가며

구글에서 발표한 Agent에 대한 백서를 정리해 보면서 Agent란 무엇인지, Agent의 핵심 구성 요소와 동작원리 등에 대해서 알아보겠다. 아래의 링크를 통해서 전체 원문을 참고하면 좋겠다.

 

Agent란 무엇인가?

인간은 특정 일을 수행하기 위해서 책, Google 검색, 계산기 등을 사용하여 필요한 정보를 찾거나 계산을 수행한다. 에이전트는 기존 LLM의 단순히 주어진 질문에 답하거나 데이터를 처리하는 능력을 넘어서, 주어진 환경을 관찰하고 이를 바탕으로 자신이 가진 도구를 사용하여 목표를 달성하려고 시도하는 애플리케이션을 의미한다.

특히 에이전트는 달성해야 할 목표가 제공될 때, 자율적으로 인간의 개입 없이 독립적으로 행동할 수 있다는 것이 특징이다. 궁극적인 목표를 달성하기 위해 ‘다음에 무엇을 해야 할지’ 추론하고, ‘외부 세계와 상호 작용’하여 더욱 복잡한 작업을 수행할 수 있다.

 

기존 LLM 모델과 Agent의 차이?

그러면 전통 LLM의 생성 방식과 Agent의 차이점에 대해 알아보자. 본문에서는 기존 LLM 모델과 agent의 차이를 표로 정리하고 있어 이를 한국어로 다시 정리했다.

 

Models	Agents
학습한 데이터에 대해서 지식이 제한됨	tool를 활용해 외부 시스템과 연결하여 지식 확장 가능
일반적으로 사용자 쿼리를 기반으로 단일 추론 또는 예측을 수행하며, 세션 기록이나 지속적인 컨텍스트 관리 없음	Orchestration Layer에서 관리되는 세션 기록을 통해 멀티턴 추론/예측이 가능 (여기서 '턴'은 시스템과 에이전트 간의 상호 작용을 의미)
tool 사용하지 않음	tool이 구현 되어있음
기본 논리 계층이 없으며, 사용자의 prompt engineering(Chain-of-Thought, ReAct)을 사용하여 모델의 예측 유도를 할 수 있음	Chain-of-Thought, ReAct 또는 LangChain과 같은 사전 구축된 에이전트 프레임워크를 사용하는 기본 인지 아키텍처(Cognitive Architecture)를 갖고 있음

 

Agent의 필수 구성요소

그러면 에이전트의 action과 의사 결정을 주도하는 기본 개요를 살펴보자.

핵심 기능은 세 가지 필수 구성 요소로 이루어져 있는데 모델, 도구, orchestration으로 구성 되어있다.

 

동작 과정은 다음과 같다. 유저의 쿼리가 들어오면 orchestration layer에서 처리가 된다. orchestration layer는 에이전트를 구성할 때 미리 정의해 둔 에이전트의 ‘생각의 구조’라고 이해하고 일단 넘어가면 될 것 같다. 그 안에는 정의해둔 instruction이나 메모리 처리방식, 모델의 reasoning과 planning에 대한 단계가 포함된다.

 

유저의 Task를 처리하는 과정에서 추가적인 데이터나 외부와 상호작용이 필요하다면, tool이나 api call을 통해 필요한 정보를 획득할 수 있다. 그리고 모델은 사전 지식을 바탕으로 답을 추측하는 대신 도구를 이용해 실시간으로 얻은 외부 정보를 바탕으로 정확한 결정을 내리고, 이를 요약하여 사용자에게 다시 정보를 제공하게 된다.

 

각각의 구성 요소에 대한 자세한 설명을 뒤에서 다시 설명하도록 하겠다.

 

어떻게 agent가 operation 하는가?

이제 우리는 어떻게 Agent가 생각의 과정을 거치는지에 대해서 알아볼 것이다. 이를 ‘인지 아키텍처’(Cognitive Architectures)라고 하며, 결국 에이전트의 두뇌가 정보를 처리하고 의사 결정을 내리며 행동하는 방식을 정의하는 기본 구조에 대해 알아볼 것이다.

 

에이전트가 정보를 처리하고 의사결정을 내리는 데 필요한 대표적인 세 가지 구조가 있다.

1. ReAct (Reasoning + Acting)
   LLM이 추론(Reasoning)과 행동(Acting)을 동시에 수행하도록 유도하는 방법이다.
   모델이 먼저 추론(생각 단계)을 하고, 이 추론을 기반으로 행동(정보 검색, tool calling)을 실행한다.
2. Chain-of-Thoughts (CoT)
   모델이 복잡한 문제를 해결할 때 답변을 바로 도출하지 않고, 단계별 추론 과정을 거쳐 최종 답을 도출하도록 유도하는 방법이다.
   논리적 추론, 수학 문제 혹은 답변 과정이 명확해야 하는 상황에서 적합하다.
3. Tree-of-Thoughts (ToT)
   Chain-of-Thougts에서 파생된 프레임워크로 모델이 문제를 해결하는 과정에서 여러 가능성들을 나무처럼 갈래를 분기하여 탐색하는 방법이다.
   이것은 단일 경로에 지나치게 의존하지 않고, 다양한 해결책이나 전략을 고려하는 작업에서 유용하게 사용될 수 있다.

 

그러면 Agent가 ReAct 프레임워크를 선택했다고 가정하고 전체 플로우를 보면 다음과 같다.

1. 유저가 Agent에게 쿼리를 보내면 ReAct 시퀀스가 실행된다.
2. Agent는 프롬프트와 함께 들어온 쿼리를 보고, 생각(Thought)하거나 실행(Action)하는 행동을 결정한다.
3. Thought에서는 다음 단계는 어떤 것을 해야 하는지 생각하여 판단하고,
4. Action에서는 다음 어떤 행동을 할지를 결정한다.
   예를 들어 Action에서 task를 처리하는 과정 속에 툴을 사용할 수 있는 구간이 있는지, 있다면 어떤 툴을 사용해야 하는지를 결정하게 된다.
5. 어떤 툴을 사용할지 정했다면 그다음 input으로 어떤 정보를 툴의 입력으로 넣어줄지 결정한다.
6. observation 단계에서는 action의 결과를 기반으로 또다시 action의 input sequence를 생성한다.
7. 그렇게 thought - action - action input - observation 단계를 계속해서 n만큼 반복한다.
8. 마지막으로 유저의 쿼리 기반의 답변을 생성해서 전달하고 ReAct 루프를 멈추게 된다.

 

Agent의 주요 구성 요소인 Tool을 어떻게 정의할까?

Agent가 실시간으로 맥락에 맞춰 외부 시스템과 상호작용할 수 있도록 하려면 어떻게 할까?

Tool을 통해서 기존의 LLM이 학습하지 못한 정보에 접근하고, 상호작용이 필요한 상황에서 유용성 제공할 수 있다. 이 자료에서는 Tool을 크게 Extensions, Function, Data store로 나누어서 보고 있다.

 

Extensions

Extension은 Agent와 API 사이에 표준화된 방식으로 연결해 주는 역할을 한다. 이는 에이전트가 API의 내부 구현 방식에 상관없이 API를 실행할 수 있도록 도와줄 수 있다.

 

 

예를 들어 항공편 예약 에이전트를 구축한다고 가정했을 때, Extension은 위의 그림과 같이 에이전트가 Google Flights API를 호출하여 항공편 정보를 검색하는 과정 중간에서 도와준다.

만약 Google Flights API를 호출할 때 출발과 도착 장소가 필요한데 사용자가 “오스틴까지 가는 항공편 예약해 줘”라고 요청한다면 출발 정보가 없기 때문에 에이전트는 API 호출에 실패할 것이다. 그래서 이를 방지하기 위해 Extension이 에이전트에게 API 사용법을 예시를 통해 가르치고, API endpoint를 호출하는 데 필요한 매개변수를 알려주는 역할을 한다.

 

 

extension은 그림과 같이 여러 API에 대해서 각각의 extension으로 존재할 수 있고, 각 extension을 독립적으로 개발할 수 있지만 agent’s configuration의 부분으로 제공되어야 한다. (이게 정확히 무슨 말인지는 모르겠다만 agent side에서 동작하도록 설계되어야 한다는 의미인 것 같다)

 

Functions

두 번째로 Function은 에이전트가 특정 작업을 수행할 수 있도록 하는 재사용 가능한 코드 모듈로 정의된다.

예를 들어 에이전트가 우리가 원하는 특정 계산을 할 수 있도록 하고 싶으면 function을 통해서 특정 작업을 수행할 수 있도록 코드 모듈로 정의할 수 있다. (덧셈을 수행하는 코드 모듈을 만들기가 그 예시가 된다)

 

이때 모델은 Function과 매개변수를 출력하지만 실제 API 호출은 하지 않는다. Extension은 에이전트 측에서 자동으로 실행되지만 Function은 클라이언트 측에서 실행되기 때문이다. 이것이 갖는 의미는 개발자가 function을 사용해서 더 쉽게 제어를 한다는 말도 되지만 그만큼 agent의 자유도를 제한하는 것이 된다.

 

 

그렇다면 function이 직접 API 호출을 하지 않으면 예제에서 나온 Google Flights API를 호출하려 하면 어떻게 동작할 수 있을까?

Function을 사용하게 되면 실제 API 엔드포인트를 호출하는 논리와 실행은 agent에서 분리되어 클라이언트 측 애플리케이션으로 다시 전송된다. 아래의 그림은 그 차이를 extension과 비교하여 보여주고 있다.

 

 

그러면 잘 생각해 보면 Function이 extension보다 더 복잡한 단계를 거치고 있는 것 같은데 언제 function을 사용하는 게 더 유용할까?

개발자가 데이터 흐름에 대해 세밀한 제어를 할 수 있다는 장점이 있기 때문에 아래의 세 가지 케이스의 경우, Extension보다 Function이 더 효과적일 수 있다.

• API 호출이 애플리케이션의 또 다른 계층에서 이루어져야 하며, agent의 아키텍처 외부에서 이루어져야 하는 경우 (예: 미들웨어 시스템, 프런트 엔드 프레임워크 등)
• agent가 API를 직접 호출하지 못하게 하는 보안이나 인증 제한이 있는 경우 (예: API가 인터넷에 노출되어 있지 않거나 agent 인프라에서 접근할 수 없는 경우)
• 실시간으로 API 호출을 할 수 없게 하는 작업 순서 제약이 있는 경우 (예: 배치 작업, 사람의 검토 등)
• API 응답에 적용해야 할 추가 데이터 변환 로직이 필요한 경우
  • 예를 들어 web search API에 개수 제한 메커니즘이 포함되어있지 않다고 한다면 모델은 수많은 search 된 결과들을 한 번에 받지 못할 것이다. 그 경우엔 function을 사용해서 클라이언트 측에서 필터링하여 다시 agent로 전달해 주는 것이 더 좋은 선택일 것이다.

 

Data store

마지막으로 Data store는 최신 정보를 바탕으로 더 정확하고 관련성 높은 응답을 제공할 수 있도록 지원하는 요소이다. 쉽게 말해 모델이 학습한 데이터 외에 스프레드시트나 PDF와 같은 다양한 형식의 데이터를 미리 vectorDB에 저장해 두고 RAG를 사용해서 데이터에 접근하도록 하는 것이다.

 

 

RAG의 파이프라인 그대로 1) 유저의 쿼리가 들어오면 vectorDB에 데이터를 삽입할 때 사용한 임베딩 모델을 통해 쿼리를 임베딩한다. 2) 임베딩된 벡터로 3) vectorDB에서 가장 유사한 content를 검색하고 4) agent에 전달하여 5) 답변한다.

 

 

Tool 요약하기

Tool의 세 가지 종류인 Extension, Function, Data store를 비교하는 표로 정리한다.

 

	Extension	Function calling	Data Stores
Execution	에이전트 측 실행	클라이언트 측 실행	에이전트 측 실행
Use Case	- 에이전트가 API와의 상호작용에 자유도를 주고 싶은 경우 - 기본 제공 extension을 사용하는 것이 더 유용한 경우 - Multi-hop planning 및 API 호출하는 경우	- 보안 혹은 인증 제한으로 인해 에이전트가 API를 직접 호출할 수 없는 경우 - API 호출을 실시가능로 수행하는 데에 타임 제약이 있는 경우 - API가 인터넷에 노출되지 않았거나 Google 시스템에 접근할 수 없는 경우	- 개발자가 Retrieval Augmented Generation (RAG)을 구현하려는 경우

 

+ 추가 설명) Extension에서 Multi-hop planning이라는 것은 하나의 목표를 달성하기 위해 여러 단계로 API를 호출하는 것을 의미한다. 그래서 이 경우 이전의 API 결과가 다음 API 호출에 영향을 주기 때문에 extension을 사용하는 것이 더 유용하게 사용된다.

 

마치며

에이전트의 구성 요소와 동작 원리에 대해서 구글이 공개한 Agent 백서를 정리하며 알아보았다. Langchain을 이용한 예제 코드도 확인할 수 있으니 원문을 참고해보면 좋을 것 같다. Langchain의 AgentExecutor를 이용하여 쉽게 tool을 정의하고 LLM에 붙여서 구현할 수 있는데 그렇게 간단한 실습 코드를 수행해보면서 위의 내용을 익히면 더욱 이해가 잘 될 것 같다. 

 

Reference

https://discuss.pytorch.kr/t/google-ai-agents-pdf-42p/5788

https://www.youtube.com/watch?v=HujQhD8J2LQ&t=1080s