서론
인간은 복잡한 패턴을 인식하는 데 뛰어난 능력을 보입니다. 그러나 결론을 내리기 전에 책이나 인터넷 검색, 계산기 같은 툴들을 활용해 기존 지식을 보완하곤 합니다. 생성형 AI 모델 역시 인간처럼 실시간 정보에 접근하거나 실제 행동을 제안하기 위해 툴 사용법을 학습할 수 있습니다.
예를 들어, 모델이 데이터베이스 검색 툴을 활용해 고객의 구매 기록 같은 구체적인 정보에 접근함으로써 맞춤형 상품을 추천할 수 있습니다.
또한 사용자의 요청에 따라 동료에게 이메일을 보내거나 금융 거래를 처리하기 위해 다양한 API를 호출할 수도 있습니다. 이를 위해서는 모델이 외부 툴에 대한 접근 권한을 가질 뿐만 아니라, 모든 작업을 자율적으로 계획하고 실행할 수 있는 능력이 필요합니다.
이처럼 생성형 AI 모델의 추론, 논리, 외부 정보 접근이 결합된 개념이 바로 에이전트입니다. 즉, 생성형 AI 모델의 독립적 기능을 넘어서는 프로그램을 의미하죠. 이 백서에서는 이러한 측면들을 더 자세히 살펴보고자 합니다.
에이전트란 무엇인가?
가장 기본적인 의미에서 생성형 AI 에이전트는 주변 환경을 관찰하고 가용한 툴들을 활용해 목표를 달성하고자 하는 응용 프로그램이라 할 수 있습니다. 에이전트는 자율성을 지니며, 특히 달성해야 할 적절한 목표나 목적이 주어졌을 때 인간의 개입 없이도 독자적으로 행동할 수 있습니다. 또한 에이전트는 목표 달성을 위해 능동적인 접근 방식을 취할 수 있습니다.
인간의 구체적인 지시가 없더라도, 에이전트는 궁극적인 목표 달성을 위해 다음 단계를 스스로 판단할 수 있습니다. AI 분야에서 에이전트의 개념은 매우 포괄적이고 강력하지만, 이 백서는 발간 시점에 생성형 AI 모델이 구현할 수 있는 특정 유형의 에이전트들에 초점을 맞추고 있습니다.
에이전트의 작동 방식을 이해하기 위해, 먼저 에이전트의 행동, 동작, 의사결정을 이끄는 핵심 구성요소들을 소개하겠습니다. 이러한 구성요소들의 조합은 인지 아키텍처로 설명될 수 있으며, 이 구성요소들을 다양하게 조합하여 여러 아키텍처를 구현할 수 있습니다. 핵심 기능에 초점을 맞추면, 그림 1과 같이 에이전트의 인지 아키텍처에는 세 가지 필수 구성요소가 있습니다.
모델
에이전트 관점에서 모델이란 에이전트 프로세스의 중심 의사결정자 역할을 하는 언어 모델(LM)을 의미합니다. 에이전트가 사용하는 모델은 크기와 관계없이(대형/소형) 하나 또는 여러 개의 LM이 될 수 있으며, 리액트(ReAct), 체인오브솟(Chain-of-Thought), 트리오브솟(Tree-of-Thoughts)과 같은 지시 기반 추론 및 논리 프레임워크를 따를 수 있습니다. 모델은 특정 에이전트 아키텍처의 필요에 따라 범용, 멀티모달 또는 미세 조정된 형태를 취할 수 있습니다.
실제로 최상의 결과를 얻기 위해서는 원하는 최종 애플리케이션에 가장 적합하고, 가능하다면 인지 아키텍처에서 사용하고자 하는 툴들과 관련된 데이터로 학습된 모델을 활용해야 합니다.
일반적으로 모델은 에이전트의 특정 구성(즉, 툴 선택, 오케스트레이션/추론 설정)으로 학습되지 않는다는 점을 유의해야 합니다. 다만 다양한 맥락에서 특정 툴이나 추론 단계를 사용하는 에이전트의 예시를 제공함으로써, 에이전트의 작업 수행 능력을 향상시킬 수 있습니다.
툴
파운데이션 모델은 텍스트와 이미지 생성에서 놀라운 성능을 보여주지만, 외부 세계와 상호작용하는 능력은 제한적입니다. 툴은 이러한 한계를 극복하여 에이전트가 외부 데이터 및 서비스와 상호작용할 수 있게 해주며, 파운데이션 모델만으로는 불가능한 더 폭넓은 행동을 가능하게 합니다...
도구는 다양한 형태와 복잡성을 가질 수 있지만, 일반적으로 GET, POST, PATCH, DELETE와 같은 일반적인 웹 API 메소드와 유사합니다.
예를 들어, 툴을 통해 데이터베이스의 고객 정보를 업데이트하거나 에이전트의 여행 추천에 영향을 미치는 날씨 데이터를 가져올 수 있습니다. 툴을 활용하면 에이전트가 실제 세계의 정보에 접근하고 처리할 수 있어, 검색 증강 생성(RAG)과 같은 더 전문화된 시스템을 지원할 수 있습니다.
이는 기초 모델 자체의 능력을 크게 확장시킵니다. 툴에 대해서는 뒤에서 더 자세히 설명하겠지만, 가장 중요한 점은 툴이 에이전트의 내부 능력과 외부 세계를 연결하여 더 넓은 가능성을 제공한다는 것입니다.
오케스트레이션 레이어
오케스트레이션 레이어는 에이전트가 정보를 입력받고, 내부적으로 추론을 수행하며, 이를 바탕으로 다음 행동이나 결정을 내리는 순환적 프로세스를 의미합니다. 일반적으로 이 순환은 에이전트가 목표를 달성하거나 중단점에 도달할 때까지 계속됩니다. 오케스트레이션 레이어의 복잡성은 에이전트와 수행하는 작업에 따라 크게 달라질 수 있습니다.
일부 순환은 단순한 결정 규칙에 따른 계산일 수 있고, 또 다른 것들은 연쇄 논리를 포함하거나, 추가적인 머신러닝 알고리즘을 활용하거나, 다른 확률적 추론 기법을 구현할 수 있습니다. 인지 아키텍처 섹션에서 에이전트 오케스트레이션 레이어의 구체적인 구현 방법에 대해 더 자세히 다룰 예정입니다.
에이전트 vs. 모델
아래 테이블은 에이전트와 모델의 차이를 더 명확히 이해하기 위한 비교표입니다:
모델:
- 지식이 학습 데이터에서 사용 가능한 것으로 제한됨
- 사용자 쿼리에 기반한 단일 추론/예측만 수행
- 모델에 명시적으로 구현되지 않은 경우, 세션 기록이나 연속적인 맥락(예: 채팅 기록) 관리가 없음
- 기본 툴 구현 없음
- 기본 로직 계층 구현 없음
- 사용자는 간단한 질문으로 프롬프트를 구성하거나 CoT, ReAct 등의 추론 프레임워크를 사용하여 모델의 예측을 안내하는 복잡한 프롬프트를 구성할 수 있음
에이전트:
- 툴을 통한 외부 시스템과의 연결로 지식이 확장됨
- 오케스트레이션 계층에서 이루어진 사용자 쿼리와 결정에 기반한 다중 턴 추론/예측을 위해 세션 기록(예: 채팅 기록) 관리. 여기서 '턴'은 상호작용 시스템과 에이전트 간의 상호작용을 의미함(예: 1개의 수신 이벤트/쿼리와 1개의 에이전트 응답)
- 에이전트 아키텍처에 기본적으로 툴이 구현됨
- CoT, ReAct 또는 랭체인과 같은 사전 구축된 에이전트 프레임워크와 같은 추론 프레임워크를 사용하는 기본 인지 아키텍처가 있음
인지 아키텍처: 에이전트의 작동 방식
바쁜 주방의 셰프를 예로 들어보겠습니다. 셰프의 목표는 고객에게 맛있는 요리를 제공하는 것이며, 이는 계획, 실행, 조정의 순환 과정을 포함합니다.
- 셰프는 고객의 주문과 식재료 저장고, 냉장고에 있는 재료들을 확인합니다.
- 이렇게 수집한 정보를 바탕으로 어떤 요리를 만들고 어떻게 맛을 조화시킬지 구상합니다.
- 실제로 야채를 썰고, 양념을 섞고, 고기를 굽는 등의 조리 과정을 수행합니다.
과정마다 셰프는 상황에 맞게 조정하고, 재료가 떨어지거나 고객 피드백을 받으면 계획을 수정하며, 이전 결과를 토대로 다음 행동을 결정합니다. 정보 수집, 계획, 실행, 조정의 이 순환 과정은 셰프가 목표 달성을 위해 사용하는 고유한 인지 아키텍처를 보여줍니다.
셰프처럼 에이전트도 정보를 반복적으로 처리하고, 이를 기반으로 의사결정을 내리며, 이전 결과를 토대로 다음 행동을 개선하면서 최종 목표에 도달하기 위해 인지 아키텍처를 활용합니다. 에이전트 인지 아키텍처의 핵심에는 메모리, 상태, 추론, 계획을 관리하는 오케스트레이션 레이어가 있습니다.
이는 급속도로 발전하는 프롬프트 엔지니어링 분야와 관련 프레임워크를 통해 추론과 계획을 안내하며, 에이전트가 환경과 더 효과적으로 상호작용하고 작업을 완수할 수 있게 합니다. 언어 모델을 위한 프롬프트 엔지니어링 프레임워크와 작업 계획 분야의 연구는 빠르게 진화하고 있으며, 다양한 유망한 접근법을 제시하고 있습니다. 현재 발간 시점에서 가장 주목받는 프레임워크와 추론 기법 몇 가지를 소개합니다:
- ReAct는 언어 모델이 사용자 질의에 대해 추론하고 행동을 취할 수 있는 사고 과정 전략을 제공하는 프롬프트 엔지니어링 프레임워크입니다. 맥락 내 예시 유무와 관계없이 작동하며, 리액트 프롬프팅은 여러 SOTA 기준을 뛰어넘고 LLM의 인간 상호운용성과 신뢰성을 향상시키는 것으로 나타났습니다.
- Chain-of-Thought (CoT)는 중간 단계를 통해 추론 능력을 구현하는 프롬프트 엔지니어링 프레임워크입니다. CoT에는 자기 일관성, 능동 프롬프트, 멀티모달 CoT 등 다양한 세부 기법들이 있으며, 각각 특정 응용 분야에 따른 장단점이 있습니다.
- Tree-of-thoughts (ToT)는 탐색이나 전략적 예측 작업에 적합한 프롬프트 엔지니어링 프레임워크입니다. 이는 CoT 프롬프팅을 일반화하여, 모델이 언어 모델을 활용한 일반적 문제 해결을 위한 중간 단계로서 다양한 사고 체인을 탐색할 수 있게 합니다.
에이전트는 위의 추론 기법들 중 하나를 사용하거나, 여러 기법을 조합하여 주어진 사용자 요청에 대한 최적의 다음 행동을 선택할 수 있습니다. 예를 들어, ReAct 프레임워크를 사용해 사용자 쿼리에 대한 적절한 행동과 툴을 선택하도록 프로그래밍된 에이전트를 살펴보겠습니다. 이벤트 순서는 다음과 같습니다:
- 사용자가 에이전트에 쿼리를 전송
- 에이전트가 ReAct 순서를 시작
- 에이전트가 모델에 프롬프트를 제공하여 다음 ReAct 단계와 해당 출력을 생성하도록 요청:
- 질문: 프롬프트와 함께 제공되는 사용자 쿼리의 입력 질문사고: 다음 단계에 대한 모델의 생각행동: 다음에 취할 행동에 대한 모델의 결정이 단계에서 툴 선택이 이루어질 수 있음예시로, 행동은 [Flights, Search, Code, None] 중 하나가 될 수 있으며, 처음 3개는 모델이 선택할 수 있는 사용 가능한 툴을 나타내고, 마지막은 "툴 선택 없음"을 의미행동 입력: 툴에 제공할 입력에 대한 모델의 결정(있는 경우)관찰: 행동/행동 입력 순서의 결과이 사고/행동/행동 입력/관찰은 필요에 따라 여러 번 반복될 수 있음최종 답변: 원래 사용자 쿼리에 대한 모델의 최종 답변
- 질문: 프롬프트와 함께 제공되는 사용자 쿼리의 입력 질문
- 사고: 다음 단계에 대한 모델의 생각
- 행동: 다음에 취할 행동에 대한 모델의 결정
- 이 단계에서 툴 선택이 이루어질 수 있음예시로, 행동은 [Flights, Search, Code, None] 중 하나가 될 수 있으며, 처음 3개는 모델이 선택할 수 있는 사용 가능한 툴을 나타내고, 마지막은 "툴 선택 없음"을 의미
- 이 단계에서 툴 선택이 이루어질 수 있음
- 예시로, 행동은 [Flights, Search, Code, None] 중 하나가 될 수 있으며, 처음 3개는 모델이 선택할 수 있는 사용 가능한 툴을 나타내고, 마지막은 "툴 선택 없음"을 의미
- 행동 입력: 툴에 제공할 입력에 대한 모델의 결정(있는 경우)
- 관찰: 행동/행동 입력 순서의 결과
- 이 사고/행동/행동 입력/관찰은 필요에 따라 여러 번 반복될 수 있음
- 이 사고/행동/행동 입력/관찰은 필요에 따라 여러 번 반복될 수 있음
- 최종 답변: 원래 사용자 쿼리에 대한 모델의 최종 답변
- ReAct 루프가 종료되고 최종 답변이 사용자에게 전달됨
그림 2에서 볼 수 있듯이, 모델, 툴, 에이전트 구성이 함께 작동하여 사용자의 원래 쿼리를 바탕으로 현실적이고 간단명료한 응답을 제공합니다. 모델이 기존 지식만으로 답변을 추측(환각)할 수도 있었지만, 대신 툴(Flights)을 사용해 실시간 외부 정보를 검색했습니다. 이 추가 정보가 모델에 제공되어 실제 데이터를 기반으로 더 정확한 판단을 내리고 이를 사용자에게 요약할 수 있었습니다.
요약하면, 에이전트 응답의 품질은 모델이 적절한 툴을 선택하는 능력과 툴이 얼마나 잘 정의되었는지를 포함해, 이러한 다양한 작업에 대한 추론 및 실행 능력과 직접적으로 연관됩니다.
신선한 재료로 요리하고 고객 피드백에 귀 기울이는 셰프처럼, 에이전트는 최적의 결과를 제공하기 위해 탄탄한 추론과 신뢰할 수 있는 정보에 의존합니다. 다음 섹션에서는 에이전트가 최신 데이터와 연결되는 다양한 방법에 대해 자세히 살펴보겠습니다.
툴: 외부 세계와의 연결고리
언어 모델은 정보 처리에는 뛰어나지만 실제 세계를 직접 감지하고 이에 영향을 미치는 능력이 부족합니다. 이는 외부 시스템이나 데이터와의 상호작용이 필요한 상황에서 그 활용성이 제한됩니다.
즉, 어떤 면에서 언어 모델은 학습 데이터에서 배운 것 이상을 할 수 없습니다. 모델에 아무리 많은 데이터를 제공하더라도, 외부 세계와 상호작용하는 근본적인 능력은 여전히 부족한 상태입니다.
그렇다면 우리의 모델이 외부 시스템과 실시간으로 맥락을 파악하며 상호작용할 수 있게 하려면 어떻게 해야 할까요? 함수, 확장 기능, 데이터 저장소, 플러그인은 모두 모델에 이러한 핵심 기능을 제공하는 방법입니다. 이들은 다양한 이름으로 불리지만, 툴은 우리의 파운데이션 모델과 외부 세계를 이어주는 다리 역할을 합니다. 외부 시스템 및 데이터와의 이러한 연결을 통해 우리의 에이전트는 더 다양한 작업을 수행하고 더 높은 정확도와 신뢰성을 확보할 수 있습니다.
예를 들어, 툴을 통해 에이전트는 스마트홈 설정을 조정하고, 캘린더를 갱신하며, 데이터베이스에서 사용자 정보를 불러오거나, 지정된 방식으로 이메일을 발송할 수 있습니다. 이 문서 발간 시점을 기준으로, 구글 모델이 상호작용할 수 있는 세 가지 주요 툴 유형이 있습니다: 확장 기능, 함수, 데이터 저장소입니다.
에이전트에 툴을 장착함으로써, 우리는 그들이 세상을 이해할 뿐 아니라 그에 맞게 행동할 수 있는 거대한 잠재력을 열어, 수많은 새로운 응용 분야와 가능성의 문을 열게 됩니다.
확장 기능
확장 기능을 이해하는 가장 쉬운 방법은 이를 API와 에이전트 사이의 간극을 표준화된 방식으로 연결해주는 것으로 보는 것입니다. 이를 통해 에이전트는 기본 구현 방식과 무관하게 API를 원활하게 실행할 수 있습니다.
사용자의 항공권 예약을 돕는 에이전트를 만들었다고 가정해 보겠습니다. 구글 플라이트 API를 사용해 항공편 정보를 검색하고 싶지만, 에이전트가 이 API 엔드포인트를 어떻게 호출할 수 있을지 확실하지 않은 상황입니다.
한 가지 접근 방법은 수신된 사용자 쿼리를 받아 관련 정보를 분석한 후 API를 호출하는 커스텀 코드를 구현하는 것입니다. 예를 들어, 항공권 예약의 경우 사용자가 "오스틴에서 취리히로 가는 항공편을 예약하고 싶습니다"라고 말할 수 있습니다.
이 시나리오에서 우리의 커스텀 코드 솔루션은 API 호출 전에 사용자 쿼리에서 "오스틴"과 "취리히"를 관련 항목으로 추출해야 합니다. 하지만 사용자가 "취리히로 가는 항공편을 예약하고 싶습니다"라고만 하고 출발 도시를 명시하지 않으면 어떻게 될까요?
필요한 데이터가 없어 API 호출이 실패하고, 이런 예외 상황과 특수 케이스를 처리하기 위해 더 많은 코드를 작성해야 할 것입니다. 이러한 접근 방식은 확장성이 떨어지며 구현된 커스텀 코드의 범위를 벗어나는 상황에서 쉽게 실패할 수 있습니다.
더 유연한 접근 방식은 확장 기능을 활용하는 것입니다. 확장 기능은 다음과 같은 방식으로 에이전트와 API 사이의 간극을 메웁니다:
- 예시를 통해 에이전트에게 API 엔드포인트 사용법을 학습시킵니다.
- API 엔드포인트를 성공적으로 호출하는 데 필요한 인자나 매개변수를 에이전트에게 학습시킵니다.
확장 기능은 에이전트와 별도로 만들 수 있지만, 에이전트 구성의 일부로 제공되어야 합니다. 에이전트는 실행 시점에 모델과 예시를 활용하여 사용자의 쿼리 해결에 적합한 확장 기능이 있는지 판단합니다. 이는 확장 기능의 주요 강점인 내장 예시 기능을 보여주며, 이를 통해 에이전트가 작업에 가장 적합한 확장 기능을 동적으로 선택할 수 있습니다.
이는 소프트웨어 개발자가 사용자의 문제를 해결하고 솔루션을 개발하는 과정에서 어떤 API 엔드포인트를 사용할지 결정하는 것과 유사한 방식입니다. 사용자가 항공편을 예약하고 싶다면 개발자는 구글 플라이트 API를 사용할 수 있습니다. 사용자가 자신의 위치에서 가장 가까운 카페를 찾고 싶다면 개발자는 구글 맵스 API를 사용할 수 있습니다.
이와 같은 방식으로 에이전트/모델 스택은 기존의 확장 기능 세트를 활용하여 사용자의 쿼리에 가장 적합한 것을 선택합니다. 확장 기능을 직접 사용해보고 싶다면 제미나이 애플리케이션에서 설정 > 확장 기능으로 이동한 다음 테스트하고 싶은 확장 기능을 활성화하여 시도해볼 수 있습니다.
예를 들어, 구글 플라이트 확장 기능을 활성화한 후 제미나이에게 "다음 주 금요일에 오스틴에서 취리히로 가는 항공편을 보여줘"라고 요청할 수 있습니다.
샘플 확장 기능
확장 기능의 사용을 단순화하기 위해 구글은 프로젝트에 즉시 가져와서 최소한의 설정으로 사용할 수 있는 기본 제공 확장 기능을 제공합니다. 예를 들어, 코드 스니펫 1의 코드 인터프리터 확장 기능을 사용하면 자연어 설명을 파이썬 코드로 변환하고 실행할 수 있습니다.
스니펫 1. 코드 인터프리터 확장 기능은 파이썬 코드를 생성하고 실행할 수 있습니다
요약하면, 확장 기능은 에이전트가 다양한 방식으로 외부 세계를 감지하고, 상호작용하며, 영향을 미칠 수 있게 해줍니다. 이러한 확장 기능의 선택과 호출은 확장 기능 설정의 일부로 정의된 예시들을 통해 이루어집니다.
함수
소프트웨어 엔지니어링 분야에서 함수는 특정 작업을 수행하고 필요할 때 재사용할 수 있는 독립적인 코드 모듈을 의미합니다. 소프트웨어 개발자가 프로그램을 작성할 때, 보통 다양한 작업 수행을 위해 여러 함수를 만듭니다. 또한 function_a와 function_b 중 어떤 것을 언제 호출할지, 그리고 예상되는 입출력을 정의합니다.
함수는 에이전트의 영역에서도 매우 유사하게 작동하지만, 소프트웨어 개발자 대신 모델이 그 역할을 합니다. 모델은 주어진 함수 세트를 가지고 각 함수를 언제 사용할지, 그리고 함수의 명세에 따라 어떤 인자가 필요한지 결정할 수 있습니다.
함수는 몇 가지 측면에서 확장 기능과 차이가 있습니다. 가장 주목할 만한 차이점은:
- 모델이 함수와 그 인자를 출력하지만, 실시간 API 호출은 하지 않습니다.
- 함수는 클라이언트 측에서 실행되는 반면, 확장 기능은 에이전트 측에서 실행됩니다.
다시 구글 플라이트 예시를 들어보면, 함수에 대한 기본적인 설정은 그림 7과 같을 수 있습니다.
여기서 주목할 주요 차이점은 함수나 에이전트 모두 구글 플라이트 API와 직접 상호작용하지 않는다는 점입니다. 그렇다면 API 호출은 실제로 어떻게 이루어질까요? 함수를 사용하면 실제 API 엔드포인트를 호출하는 로직과 실행이 에이전트에서 분리되어 그림 8과 9에서 볼 수 있듯이 클라이언트 측 애플리케이션으로 옮겨집니다. 이를 통해 개발자는 애플리케이션의 데이터 흐름을 더 세밀하게 제어할 수 있습니다.
개발자가 확장 기능 대신 함수를 선택하는 이유는 다양하지만, 주요 사용 사례는 다음과 같습니다:
- API 호출이 에이전트 아키텍처 흐름 밖의 애플리케이션 계층에서 이루어져야 하는 경우 (예: 미들웨어 시스템, 프론트엔드 프레임워크 등)
- 보안이나 인증 제한으로 에이전트가 API를 직접 호출할 수 없는 경우 (예: API가 인터넷에 공개되지 않거나 에이전트 인프라에서 접근이 불가능한 경우)
- 시간이나 작업 순서 제약으로 에이전트가 실시간 API 호출을 할 수 없는 경우 (예: 배치 작업, 사람의 검토 필요 등)
- 에이전트가 처리할 수 없는 추가 데이터 변환이 API 응답에 필요한 경우. 예를 들어, 결과 수 제한 필터링 기능이 없는 API 엔드포인트의 경우, 클라이언트 측 함수를 통해 개발자가 이러한 변환을 수행할 수 있습니다.
- 개발자가 API 엔드포인트용 추가 인프라 배포 없이 에이전트 개발을 반복하고 싶은 경우 (즉, 함수 호출이 API를 임시로 대체할 수 있음)
그림 8에서 볼 수 있듯이 두 접근 방식의 내부 아키텍처 차이는 미묘하지만, 추가적인 제어와 외부 인프라에 대한 독립적인 의존성 덕분에 함수 호출은 개발자에게 매력적인 선택지가 됩니다.
활용 사례
개발자가 API 실행을 언어 모델에 맡기고 싶지 않을 때(확장 기능의 경우처럼), 모델을 활용하여 복잡한 클라이언트 측 실행 흐름을 처리하기 위해 함수를 호출할 수 있습니다. 예를 들어 여행 컨시어지 에이전트를 학습시켜 휴가 여행을 예약하려는 사용자와 상호작용하는 경우를 살펴보겠습니다.
목표는 에이전트가 여행 계획을 위해 미들웨어 애플리케이션에서 이미지, 데이터 등을 내려받을 때 사용할 도시 목록을 생성하는 것입니다. 사용자가 "가족과 함께 스키 여행을 가고 싶은데 어디로 가야 할지 모르겠어요"라고 말할 수 있습니다. 일반적인 모델 프롬프트에서는 다음과 같은 출력이 나올 수 있습니다: "가족 스키 여행에 추천하는 도시 목록입니다:
- 크레스티드 뷰트, 콜로라도, 미국
- 휘슬러, BC, 캐나다
- 체르마트, 스위스"
위의 출력에는 필요한 데이터(도시 이름)가 포함되어 있지만, 파싱하기에 이상적인 형식은 아닙니다. 함수 호출을 사용하면 모델이 이 출력을 다른 시스템이 파싱하기 더 편리한 구조화된 형식(JSON 등)으로 포맷하도록 학습시킬 수 있습니다. 동일한 사용자 입력 프롬프트에 대해, 함수의 JSON 출력 예시는 스니펫 5와 같습니다.
스니펫 5. 도시 목록과 사용자 선호도를 표시하기 위한 함수 호출 페이로드 샘플
이 JSON 페이로드는 모델이 생성하며, 클라이언트 측 서버로 전송되어 원하는 작업을 수행할 수 있습니다. 이 특정 사례에서는 구글 플레이스 API를 호출하여 모델이 제공한 도시들의 이미지를 찾은 후, 사용자에게 서식이 적용된 풍부한 콘텐츠로 제공합니다. 그림 9의 시퀀스 다이어그램은 위 상호작용을 단계별로 자세히 보여줍니다.
그림 9 예시의 결과를 보면, 모델은 구글 플레이스 API를 호출하기 위해 클라이언트 측 UI에 필요한 매개변수를 "채우는" 데 활용됩니다. 클라이언트 측 UI는 모델이 반환한 함수의 매개변수를 사용하여 실제 API 호출을 관리합니다. 이는 함수 호출의 한 가지 사용 사례일 뿐이며, 다음과 같은 다른 시나리오들도 고려할 수 있습니다:
- 코드에 인증 정보를 포함하지 않고 언어 모델이 코드에서 사용할 함수를 제안하기를 원하는 경우. 함수 호출은 함수를 실행하지 않으므로 함수 정보에 인증 정보를 포함할 필요가 없습니다.
- 몇 초 이상 걸리는 비동기 작업을 실행하는 경우. 함수 호출이 비동기 작업이므로 이러한 시나리오에 적합합니다.
- 함수 호출과 인자를 생성하는 시스템과 다른 기기에서 함수를 실행하려는 경우.
함수에 대해 기억해야 할 핵심은 개발자에게 API 호출의 실행뿐 아니라 애플리케이션 전반의 데이터 흐름을 더 많이 제어할 수 있게 해준다는 점입니다. 그림 9의 예시에서 개발자는 에이전트가 앞으로 취할 수 있는 작업과 관련이 없었기 때문에 API 정보를 에이전트에 반환하지 않기로 했습니다.
하지만 애플리케이션 아키텍처에 따라 향후 추론, 로직 및 작업 선택에 영향을 주기 위해 외부 API 호출 데이터를 에이전트에 반환하는 것이 합리적일 수 있습니다. 결국 특정 애플리케이션에 맞는 것을 선택하는 것은 애플리케이션 개발자의 몫입니다.
함수 샘플 코드
위의 스키 휴가 시나리오에서 출력을 얻기 위해 gemini-1.5-flash-001 모델과 함께 작동하도록 각 구성 요소를 구현해 보겠습니다. 먼저 display_cities 함수를 간단한 파이썬 메서드로 정의하겠습니다.
스니펫 6. 도시 목록을 표시할 함수의 파이썬 메서드 샘플
다음으로 모델을 인스턴스화하고 Tool을 구축한 다음, 사용자의 쿼리와 툴을 모델에 전달하겠습니다. 아래 코드를 실행하면 코드 스니펫 하단에 표시된 것과 같은 출력이 생성됩니다.
스니펫 7. Tool 구축, 사용자 쿼리와 함께 모델에 전송 및 함수 호출 허용
요약하면, 함수는 애플리케이션 개발자에게 중요한 입력 생성을 위해 에이전트/모델을 효과적으로 활용하면서 데이터 흐름과 시스템 실행을 세밀하게 제어할 수 있는 간단한 프레임워크를 제공합니다. 개발자는 특정 애플리케이션 아키텍처 요구사항에 따라 외부 데이터를 반환하여 에이전트를 "루프 안"에 둘지, 아니면 제외할지 선택할 수 있습니다.
데이터 저장소
언어 모델을 학습 데이터가 저장된 거대한 도서관이라고 생각해보세요. 하지만 계속해서 새로운 책을 받아들이는 도서관과 달리, 이 도서관은 정적이며 처음 학습된 지식만을 가지고 있습니다.
현실 세계의 지식은 끊임없이 발전하기 때문에 이는 하나의 문제가 됩니다. 데이터 저장소는 이러한 한계를 극복하기 위해 더 동적이고 최신의 정보에 접근할 수 있게 해주며, 모델의 응답이 사실성과 관련성을 유지하도록 합니다. 개발자가 스프레드시트나 PDF 형태로 모델에 소량의 추가 데이터를 제공해야 하는 일반적인 상황을 생각해보세요.
데이터 저장소는 개발자가 에이전트에 원본 형식 그대로 추가 데이터를 제공할 수 있게 해주어, 시간이 많이 걸리는 데이터 변환이나 모델 재학습, 미세 조정이 불필요합니다. 데이터 저장소는 입력된 문서를 벡터 데이터베이스 임베딩 세트로 변환하여 에이전트가 다음 작업이나 사용자 응답을 보완하는 데 필요한 정보를 추출할 수 있게 합니다.
구현 및 응용
생성형 AI 에이전트의 맥락에서 데이터 저장소는 일반적으로 개발자가 에이전트에게 실행 시점에 접근 권한을 주고 싶은 벡터 데이터베이스 형태로 구현됩니다. 여기서는 벡터 데이터베이스를 자세히 다루지 않겠지만, 핵심 개념은 이들이 제공된 데이터를 고차원 벡터나 수학적 표현인 벡터 임베딩으로 저장한다는 것입니다.
최근 언어 모델에서 데이터 저장소 활용의 대표적인 예시는 검색 증강 생성(RAG) 기반 애플리케이션의 구현입니다. 이러한 애플리케이션은 다음과 같은 다양한 형식의 데이터 접근권을 모델에 제공하여 기본 학습 데이터를 넘어 모델의 지식 범위와 깊이를 확장합니다:
- 웹사이트 콘텐츠
- PDF, 워드 문서, CSV, 스프레드시트 등의 구조화된 데이터
- HTML, PDF, TXT 등의 비구조화된 데이터
각 사용자 요청과 에이전트 응답 루프의 기본 프로세스는 일반적으로 그림 13과 같이 모델링됩니다.
- 사용자 쿼리가 임베딩 모델로 전송되어 쿼리의 임베딩 생성
- 스캔(SCaNN)과 같은 매칭 알고리즘을 사용하여 쿼리 임베딩을 벡터 데이터베이스 내용과 매칭
- 매칭된 콘텐츠를 벡터 데이터베이스에서 텍스트 형식으로 가져와 에이전트로 전송
- 에이전트가 사용자 쿼리와 검색된 콘텐츠를 모두 받아 응답이나 작업 구성
- 최종 응답을 사용자에게 전송
최종적으로, 에이전트가 벡터 검색을 통해 사용자의 쿼리를 기존 데이터 저장소와 매칭하고, 원본 콘텐츠를 검색하여 오케스트레이션 계층과 모델에 제공해 추가 처리할 수 있는 애플리케이션이 만들어집니다.
다음 작업은 사용자에게 최종 답변을 제공하거나 결과를 더 정제하기 위해 추가 벡터 검색을 수행하는 것일 수 있습니다. ReAct 추론/계획이 포함된 RAG를 구현하는 에이전트와의 샘플 상호작용은 그림 14에서 확인할 수 있습니다.
그림 14. ReAct 추론/계획이 포함된 RAG 기반 애플리케이션 샘플
툴 리캡
정리하자면, 확장기능, 함수, 데이터 저장소는 에이전트가 실행 시점에 사용할 수 있는 여러 툴 유형을 구성합니다. 각각 고유한 목적이 있으며 에이전트 개발자의 판단에 따라 함께 또는 독립적으로 사용될 수 있습니다.
실행 방식:
- Extensions: 에이전트 측 실행
- Function Calling: 클라이언트 측 실행
- Data Stores: 에이전트 측 실행
사용 사례:
- Extensions:
- 개발자가 에이전트로 API 엔드포인트와의 상호작용을 제어하고자 할 때기본 제공되는 Extensions 활용 시 유용(예: Vertex Search, Code Interpreter 등)다중 단계 계획 수립 및 API 호출(다음 에이전트 동작이 이전 동작/API 호출의 출력에 의존하는 경우)
- 개발자가 에이전트로 API 엔드포인트와의 상호작용을 제어하고자 할 때
- 기본 제공되는 Extensions 활용 시 유용(예: Vertex Search, Code Interpreter 등)
- 다중 단계 계획 수립 및 API 호출(다음 에이전트 동작이 이전 동작/API 호출의 출력에 의존하는 경우)
- Function Calling:
- 보안이나 인증 제한으로 에이전트가 API를 직접 호출할 수 없는 경우시간 제약이나 작업 순서 제약으로 에이전트가 실시간 API 호출을 할 수 없는 경우(예: 배치 작업, 사람 개입 검토 등)API가 인터넷에 노출되지 않았거나 구글 시스템에서 접근할 수 없는 경우
- 보안이나 인증 제한으로 에이전트가 API를 직접 호출할 수 없는 경우
- 시간 제약이나 작업 순서 제약으로 에이전트가 실시간 API 호출을 할 수 없는 경우(예: 배치 작업, 사람 개입 검토 등)
- API가 인터넷에 노출되지 않았거나 구글 시스템에서 접근할 수 없는 경우
- Data Stores: 개발자가 다음과 같은 데이터 유형으로 검색 증강 생성(RAG)을 구현하고자 할 때:
- 사전 인덱싱된 도메인과 URL의 웹사이트 콘텐츠PDF, Word 문서, CSV, 스프레드시트 등의 구조화된 데이터관계형/비관계형 데이터베이스HTML, PDF, TXT 등의 비구조화된 데이터
- 사전 인덱싱된 도메인과 URL의 웹사이트 콘텐츠
- PDF, Word 문서, CSV, 스프레드시트 등의 구조화된 데이터
- 관계형/비관계형 데이터베이스
- HTML, PDF, TXT 등의 비구조화된 데이터
목표 학습을 통한 모델 성능 향상
모델을 효과적으로 사용하는 데 있어 중요한 점은, 특히 실제 서비스 환경에서 툴을 대규모로 사용할 때 출력 생성을 위해 적절한 툴을 선택하는 능력입니다. 일반적인 학습이 모델의 이러한 기술 개발에 도움이 되지만, 실제 상황에서는 흔히 학습 데이터를 넘어서는 지식이 필요합니다.
이는 기본적인 요리 기술과 특정 요리의 숙달의 차이와 같습니다. 둘 다 기본적인 요리 지식이 필요하지만, 후자는 더 정교한 결과를 위해 목표 학습이 필요합니다. 모델이 이러한 특정 지식에 접근할 수 있도록 돕는 여러 접근 방식이 있습니다:
- 문맥 내 학습: 일반화된 모델에 프롬프트, 툴, 소수의 예시를 추론 시점에 제공하여 특정 작업에서 이러한 툴을 언제 어떻게 사용할지 '즉석에서' 학습할 수 있게 합니다. ReAct 프레임워크는 자연어에서 이 방식의 예시입니다.
- 검색 기반 문맥 내 학습: 외부 메모리에서 가장 관련성 높은 정보, 툴, 관련 예시를 검색하여 모델 프롬프트를 동적으로 채우는 기술입니다. 버텍스 AI 확장의 '예시 저장소'나 앞서 언급한 데이터 저장소 RAG 기반 아키텍처가 이러한 예시입니다.
- 미세 조정 기반 학습: 추론 전에 특정 예시의 더 큰 데이터셋으로 모델을 학습시키는 방법입니다. 이는 모델이 사용자 쿼리를 받기 전에 특정 툴을 언제 어떻게 적용할지 이해하는 데 도움이 됩니다.
각 목표 학습 접근 방식에 대한 추가 이해를 돕기 위해 요리 비유를 다시 살펴보겠습니다.
- 셰프가 고객에게서 특정 레시피(프롬프트), 몇 가지 주요 재료(관련 툴), 몇 가지 예시 요리(few-shot 예시)를 받았다고 생각해보세요. 이 제한된 정보와 요리에 대한 일반적인 지식을 바탕으로, 셰프는 레시피와 고객의 선호도에 가장 잘 맞는 요리를 '즉석에서' 만드는 방법을 알아내야 합니다. 이것이 문맥 내 학습입니다.
- 이번에는 셰프가 다양한 재료와 요리책(예시와 툴)이 가득한 잘 갖춰진 저장고(외부 데이터 저장소)가 있는 주방에 있다고 생각해보세요. 셰프는 저장고에서 재료와 요리책을 동적으로 선택하여 고객의 레시피와 선호도에 더 잘 맞출 수 있습니다. 이를 통해 셰프는 기존 지식과 새로운 지식을 모두 활용하여 더 정교한 요리를 만들 수 있습니다. 이것이 검색 기반 문맥 내 학습입니다.
- 마지막으로, 셰프를 새로운 요리나 요리 세트(특정 예시의 더 큰 데이터셋에 대한 사전 학습)를 배우기 위해 학교로 다시 보냈다고 생각해보세요. 이를 통해 셰프는 앞으로 마주할 고객의 레시피에 더 깊은 이해를 가지고 접근할 수 있습니다. 이 방식은 셰프가 특정 요리(지식 도메인)에서 전문성을 갖추길 원할 때 이상적입니다. 이것이 미세 조정 기반 학습입니다.
이러한 각 접근 방식은 속도, 비용, 지연 시간 측면에서 고유한 장단점이 있습니다. 하지만 에이전트 프레임워크에서 이러한 기술들을 결합함으로써, 우리는 다양한 강점을 활용하고 약점을 최소화하여 더 강력하고 유연한 솔루션을 만들 수 있습니다.
랭체인으로 시작하는 에이전트 퀵스타트
실제 작동하는 에이전트의 예시를 보여주기 위해, 랭체인과 랭그래프 라이브러리로 빠른 프로토타입을 만들어보겠습니다. 이 인기 있는 오픈소스 라이브러리들을 사용하면 로직, 추론, 툴 호출의 순서를 "연결"하여 사용자의 쿼리에 답변하는 맞춤형 에이전트를 구축할 수 있습니다.
스니펫 8에서 보이는 것처럼 다단계 사용자 쿼리에 답변하기 위해 gemini-1.5-flash-001 모델과 몇 가지 간단한 툴을 사용할 것입니다. 우리가 사용하는 툴은 서프API(구글 검색용)와 구글 플레이스 API입니다. 스니펫 8의 프로그램을 실행한 후, 스니펫 9에서 샘플 출력을 확인할 수 있습니다.
스니펫 8. 툴이 포함된 랭체인 및 랭그래프 기반 에이전트 샘플
스니펫 9. 스니펫 8 프로그램의 출력
이는 비교적 단순한 에이전트의 예시이지만, 특정 목표를 달성하기 위해 함께 작동하는 모델, 오케스트레이션, 툴의 기본 구성 요소를 보여줍니다. 마지막 섹션에서는 이러한 구성 요소들이 버텍스 AI 에이전트와 제너레이티브 플레이북과 같은 구글 규모의 관리형 제품에서 어떻게 통합되는지 살펴보겠습니다.
버텍스 AI 에이전트를 활용한 프로덕션 애플리케이션
이 백서에서 에이전트의 핵심 구성 요소를 살펴보았지만, 실제 서비스급 애플리케이션을 구축하기 위해서는 사용자 인터페이스, 평가 프레임워크, 지속적 개선 메커니즘 같은 추가 툴과의 통합이 필요합니다.
구글의 버텍스 AI 플랫폼은 앞서 다룬 모든 기본 요소가 포함된 완전 관리형 환경을 제공하여 이 프로세스를 단순화합니다. 개발자는 자연어 인터페이스를 사용해 목표, 작업 지침, 툴, 작업 위임을 위한 하위 에이전트, 예시와 같은 에이전트의 핵심 요소를 빠르게 정의하여 원하는 시스템 동작을 쉽게 구축할 수 있습니다.
또한 이 플랫폼은 테스트, 평가, 에이전트 성능 측정, 디버깅, 개발된 에이전트의 전반적인 품질 향상을 위한 개발 툴 세트를 제공합니다.
이를 통해 개발자는 인프라, 배포, 유지보수의 복잡성은 플랫폼이 관리하는 동안 에이전트 구축과 개선에 집중할 수 있습니다. 그림 15에서는 버텍스 에이전트 빌더, 버텍스 확장, 버텍스 함수 호출, 버텍스 예시 저장소 등 다양한 기능을 사용하여 버텍스 AI 플랫폼에 구축된 에이전트의 샘플 아키텍처를 보여줍니다.
이 아키텍처에는 실제 서비스 준비가 된 애플리케이션에 필요한 다양한 구성 요소가 포함되어 있습니다.
공식 문서에서 이 미리 구축된 에이전트 아키텍처의 샘플을 테스트해볼 수 있습니다.
요약
이 백서에서는 생성형 AI 에이전트의 기본 구성 요소, 구성, 인지 아키텍처 형태로 구현하는 효과적인 방법을 다뤘습니다. 주요 내용은 다음과 같습니다:
- 에이전트는 실시간 정보에 접근하고, 실제 작업을 제안하며, 복잡한 작업을 자율적으로 계획하고 실행하기 위해 툴을 활용함으로써 언어 모델의 기능을 확장합니다. 에이전트는 하나 이상의 언어 모델을 활용하여 상태 간 전환 시기와 방법을 결정하고, 외부 툴을 사용해 모델이 단독으로 수행하기 어렵거나 불가능한 복잡한 작업을 완수할 수 있습니다.
- 에이전트 운영의 핵심은 추론, 계획, 의사결정을 구조화하고 작업을 안내하는 인지 아키텍처인 오케스트레이션 계층입니다. ReAct, Chain-of-Thought, Tree-of-Thoughts와 같은 다양한 추론 기법은 오케스트레이션 계층이 정보를 받아들이고, 내부 추론을 수행하며, 정보에 기반한 결정이나 응답을 생성하기 위한 프레임워크를 제공합니다.
- 확장 기능, 함수, 데이터 저장소와 같은 툴은 에이전트가 외부 시스템과 상호작용하고 학습 데이터를 넘어선 지식에 접근할 수 있게 해주는 외부 세계로의 연결 통로입니다. 확장 기능은 에이전트와 외부 API를 이어주는 다리 역할을 하여 API 호출 실행과 실시간 정보 검색을 가능하게 합니다. 함수는 작업 분할을 통해 개발자에게 더 세밀한 제어를 제공하여 에이전트가 생성한 함수 매개변수를 클라이언트 측에서 실행할 수 있게 합니다. 데이터 저장소는 에이전트에게 구조화되거나 비구조화된 데이터에 대한 접근을 제공하여 데이터 기반 애플리케이션을 가능하게 합니다.
에이전트의 미래는 흥미진진한 발전을 담고 있으며, 우리는 가능성의 표면만을 살짝 건드렸을 뿐입니다. 툴이 더 정교해지고 추론 능력이 향상됨에 따라, 에이전트는 점점 더 복잡한 문제를 해결할 수 있게 될 것입니다.
더욱이 '에이전트 체이닝'이라는 전략적 접근 방식은 계속해서 탄력을 받을 것입니다. 특정 도메인이나 작업에서 뛰어난 전문화된 에이전트들을 결합함으로써, 우리는 다양한 산업과 문제 영역에서 뛰어난 결과를 제공할 수 있는 '에이전트 전문가 조합' 방식을 만들 수 있습니다.
복잡한 에이전트 아키텍처를 구축하려면 반복적인 접근이 필요하다는 점을 기억해야 합니다. 특정 비즈니스 사례와 조직의 요구사항에 맞는 솔루션을 찾기 위해서는 실험과 개선이 핵심입니다.
아키텍처의 기반이 되는 파운데이션 모델의 생성적 특성으로 인해 두 개의 에이전트가 동일하게 만들어지지는 않습니다. 하지만 이러한 기본 구성 요소들의 강점을 활용함으로써, 우리는 언어 모델의 기능을 확장하고 실제 가치를 창출하는 영향력 있는 애플리케이션을 만들 수 있습니다.
본 콘텐츠는 2025년 1월 6일 구글에서 작성한 "Agents" 백서를 번역한 것입니다.
저는 전문 번역가가 아니기 때문에 오역이 있을 수 있습니다. 또한 본 글은 원저작자의 요청에 따라 불시에 삭제될 수 있습니다. 감사합니다.
의견을 남겨주세요