이 페이지에서는 Agent Framework의 개념적 개요를 제공하여 효과적인 에이전트를 개발하기 위한 핵심 구성요소를 설명합니다.
에이전트란 무엇인가요?
생성형 AI 에이전트는 독립적인 어시스턴트처럼 작동하는 스마트 컴퓨터 프로그램과 같습니다. 목표가 주어지면 데이터나 정보를 통해 주변 환경을 이해할 수 있으며, 인간의 지속적인 감독 없이 다양한 도구를 사용하여 목표를 달성할 수 있습니다. 목표에 더 가까워지기 위한 다음 단계를 계획할 수도 있습니다.
기술적으로 생성형 AI 에이전트는 환경을 관찰하고, 최선의 조치를 추론하고, 사용 가능한 도구로 작업을 실행하여 정의된 목표를 자율적으로 추구하는 소프트웨어 추상화입니다. 각 단계에 대한 직접적인 인간의 지시와는 독립적으로 작동하며 궁극적인 목표를 달성하기 위해 후속 작업을 사전에 결정할 수 있습니다. 이는 에이전트의 추론 및 의사결정 기능을 지원하는 생성형 AI 모델을 통해 가능합니다.
에이전트가 아닌 것은 무엇인가요?
다음은 에이전트처럼 보이지만 실제로는 그렇지 않은 일반적인 경우입니다.
하드 코딩된 'If-Then' 챗봇(안티패턴):
LLM으로 빌드된 챗봇으로, 가능한 모든 사용자 입력과 LLM 응답을 세심하게 사전 정의합니다. 함수 호출을 사용하더라도 로직이 완전히 하드 코딩된 경우 에이전트가 아닙니다. 추론 시스템이 아니라 정교한 결정 트리입니다.
예: 사용자가 '항공편 예약'이라고 말하면 book_flight() 함수를 호출합니다. 이는 에이전트가 아닌 규칙 기반 시스템입니다.
ReAct 프롬프트에 대한 과도한 의존(잠재적 안티패턴):
ReAct(Reason + Act) 프롬프트는 LLM이 단계별로 생각한 후 행동하도록 프롬프트를 구성하는 기법입니다. 이는 에이전트 동작에 더 가깝지만, 개발자가 여전히 가능한 모든 시나리오에 대해 ReAct 프롬프트를 수동으로 작성하는 경우 안티패턴이 될 수 있습니다. 에이전트는 단지 사전 작성된 템플릿을 따르는 것이 아니라 자체 ReAct 스타일 추론을 생성할 수 있어야 합니다. 작동 부분은 단순한 함수 호출로 제한되며 상위 수준의 계획이나 적응은 없습니다.
조치가 없는 연쇄 사고(CoT)(안티패턴):
CoT 프롬프트를 사용하여 LLM이 추론을 설명하도록 하는 것은 유용하지만, 그 추론에 따라 작동하지 않으면 에이전트가 아닙니다. 이는 자율적 항목이 아니라 더 투명한 LLM일 뿐입니다.
에이전트와 LLM 비교
단일 프롬프트:
LLM에게 '로마 제국의 역사를 요약해 줘'라고 요청합니다. 이는 단일 상호작용입니다. Gemini는 프롬프트를 처리하고 응답을 생성합니다. 과거 상호작용에 대한 메모리, 장기 목표, 외부 도구와의 상호작용이 없습니다. 순전히 입력-출력입니다.
연쇄 프롬프트:
그런 다음 '이제 제국 쇠퇴의 주요 원인을 나열해 봐'라고 말할 수 있습니다. 이것이 연쇄 프롬프트입니다. 인간 사용자가 대화를 이끌고 작업을 세분화함으로써 에이전트와 같은 행동을 제공합니다. Gemini는 전체 목표를 더 폭넓게 이해하지 못하고(명시적이고 반복적으로 언급하지 않는 한) 각 프롬프트에 개별적으로 응답합니다. 사용자가 에이전트 역할을 했고 Gemini는 아닙니다.
에이전트:
LLM을 사용하는 에이전트는 근본적으로 다릅니다.
다음과 같은 목표를 가진 '로마 역사 연구 에이전트'를 가정해 보겠습니다.
"로마 제국의 역사, 주요 인물, 문화적 영향, 멸망 이유를 포함하여 로마 제국에 관한 포괄적인 보고서를 작성하세요. 보고서는 학술 자료의 새로운 정보로 매주 업데이트되어야 합니다."
주요 차이점:
- 지속적인 목표: 에이전트는 싱글턴 태스크뿐만 아니라 지속적인 장기 목표를 가지고 있습니다.
- 계획: 에이전트는 다음과 같이 세부적으로 계획할 수 있습니다.
- Gemini를 사용하여 초기에 조사합니다(기록 요약, 주요 인물 파악).
- 학술 데이터베이스를 검색합니다(별도의 도구 사용).
- 여러 출처의 정보를 종합합니다.
- 보고서를 생성합니다.
- 2~4단계를 반복하도록 주간 태스크를 예약합니다.
- 도구 사용: 에이전트가 Gemini 이외의 도구(예: 검색 API, 데이터베이스)를 적극적으로 사용합니다.
- 자율성: 에이전트는 독립적으로 작동하여 수집할 정보와 이를 표시할 방법을 결정합니다.
- 메모리: 에이전트는 발견사항을 정리하고 프롬프트를 자체적으로 개선하기 위해 메모리를 계속해서 유지합니다(데이터베이스에 저장할 수 있음).
중요한 점은 단일/체인 프롬프트 시나리오에서 사용자가 조정자 역할을 한다는 점입니다. 에이전트 시나리오에서 에이전트 자체가 Gemini를 도구 중 하나로 사용하여 조정자 역할을 합니다.
에이전트 워크로드와 일반적인 LLM 워크로드의 구분
에이전트와 일반적인 LLM 워크로드 간의 가장 중요한 차이점은 반복적인 미세 조정과 계획이 있는 자율적이고 목표 지향적인 동작입니다. 다음을 자문해 보세요.
- 지속적인 목표
- 시스템에는 개별 프롬프트에 응답하는 것 외에도 달성하기 위해 노력하는 명확하게 정의된 장기 목표가 있나요?
- 자율적 작업
- 시스템이 모든 작업에 대해 인간의 명시적인 단계별 지시 없이 작업(도구 사용, 결정 내리기)을 실행할 수 있나요?
- 계획 및 추론
- 시스템에서 계획(복잡한 목표를 더 작은 단계로 세분화) 및 추론(상황을 이해하여 결정 내리기)의 증거를 보이나요?
- 반복적인 개선
- 시스템이 접근 방식을 학습하고 개선하나요? 머신러닝일 필요는 없습니다. 관찰을 기반으로 한 자체 프롬프트 개선일 수 있습니다.
- 스테이트풀(Statefulness)
- 시스템이 목표를 향해 계속 진행하기 위해 상태 정보를 유지하고 사용하나요?
이러한 모든 질문에 대한 답변이 '예'인 경우 AI 에이전트를 사용하고 있는 것일 수 있습니다. '아니요'인 경우 보다 정교한 LLM 애플리케이션이 있지만 완전한 에이전트는 아닙니다. 에이전트를 정의하는 것은 이러한 요소 중 하나가 아니라 이러한 요소의 집합입니다. 에이전트는 단순히 일을 하는 것이 아니라 무엇을 할지, 왜 해야 하는지 결정하고 정의된 목표를 달성하기 위해 접근 방식을 조정하는 것입니다.
에이전트의 필수 구성요소:
- 모델: 언어 모델(LM)은 지시 기반 추론 및 로직 프레임워크를 활용하여 중앙 의사 결정자 역할을 합니다.
- 도구: 도구는 에이전트의 내부 기능과 외부 세계 간의 격차를 해소하여 더 다양한 가능성을 열어줍니다. 외부 데이터 및 서비스와의 상호작용을 지원합니다.
- 조정 레이어: 이 레이어는 에이전트가 정보를 수신하고 내부 추론을 실행하며 이러한 추론을 사용하여 다음 작업 또는 결정을 알리는 방식을 관리합니다.
에이전트와 함수 호출 비교
LLM의 함수 호출은 에이전트 동작에 가까운 강력한 단계이지만 완전한 에이전트와는 다릅니다.
LLM + 함수 호출: LLM이 호출할 수 있는 함수(예: get_weather(location), search_wikipedia(topic))를 정의합니다. LLM 응답에서 함수를 사용해야 한다고 나타내면 코드는 해당 함수를 실행하고 결과를 LLM에 다시 제공합니다. 이를 통해 모델이 외부 데이터에 액세스하거나 작업을 실행할 수 있습니다.
LLM + 에이전트:
에이전트는 함수 호출을 기반으로 빌드됩니다. 함수 호출은 에이전트가 사용할 수 있는 메커니즘이지만 에이전트는 다음을 추가합니다.
- 전략적 의사결정: 에이전트는 전반적인 목표와 계획에 따라 함수를 호출할 시점과 이유를 결정합니다. 단일 프롬프트에만 반응하는 것이 아닙니다.
- 다단계 추론: 에이전트는 내부 추론 프로세스에 따라 여러 함수 호출과 Gemini 상호작용을 체이닝할 수 있습니다. 프롬프트당 단일 함수 호출로 제한되지 않습니다.
- 오류 처리 및 적응: 우수한 에이전트는 함수 호출이 실패하거나 예상치 못한 결과를 반환하는 케이스를 처리합니다. 이에 따라 계획을 조정할 수 있습니다.
- 상태 관리: 에이전트는 여러 상호작용에서 유지되는 내부 상태(메모리)를 유지하므로 진행 상황을 추적하고 더 많은 정보를 바탕으로 결정을 내릴 수 있습니다.
함수 호출이 LLM에 외부 세계와 상호작용할 수 있는 능력을 부여하는 것이라고 생각해 보세요. 에이전트는 LLM에 이러한 능력을 효과적으로 사용하여 복잡한 목표를 달성할 수 있는 지능과 자율성을 부여합니다.
LLM 파이프라인 및 체인
이 하위 섹션에서는 파이프라인과 체인을 사용하여 에이전트 내에서 LLM을 구성하고 정리하는 방법을 자세히 살펴봅니다. 복잡한 태스크를 수행하기 위해 LLM 호출, 도구 상호작용, 기타 에이전트 구성요소를 연결하는 다양한 패턴을 알아봅니다. 에이전트 설계와 관련된 일반적인 파이프라인 및 체인 아키텍처에 관한 설명이 나옵니다.
에이전트 빌드 시 안티패턴
이 섹션에서는 에이전트를 개발할 때 피해야 할 일반적인 실수와 함정에 중점을 둡니다. 에이전트 성능, 유지보수성 또는 확장성을 저해할 수 있는 설계 선택사항 또는 구현 전략인 '안티패턴'을 파악하고 설명합니다. 이러한 안티패턴에 대해 알아보면 개발자가 더 강력하고 효과적인 에이전트를 빌드하는 데 도움이 됩니다.
다단계 에이전트와 멀티 에이전트 중 어느 쪽을 선택해야 하나요?
이 섹션에서는 에이전트 복잡성에 대한 두 가지 다른 접근 방식인 다단계 에이전트(일련의 단계로 태스크를 실행하는 에이전트)와 멀티 에이전트 시스템(상호작용하는 여러 에이전트로 구성된 시스템)을 비교하고 대조합니다. 각 접근 방식의 장단점을 논의하고 사용 사례와 원하는 에이전트 동작에 따라 어느 접근 방식을 선택해야 하는지에 관한 안내를 제공합니다.
멀티 에이전트 흐름을 사용해야 하는 경우
이 섹션에서는 멀티 에이전트 시스템을 확장하여 멀티 에이전트 '흐름'을 사용하는 것이 유리한 시나리오를 구체적으로 살펴봅니다. 여러 에이전트 간의 공동작업, 위임 또는 분산된 문제 해결의 이점을 활용하는 사용 사례를 살펴보겠습니다. 이 섹션의 목표는 복잡한 에이전트 시스템에서 멀티 에이전트 흐름의 실용적인 애플리케이션과 이점을 보여주는 것입니다.
여러 도구를 사용하는 에이전트와 멀티 에이전트 비교
이 섹션에서는 단일 에이전트에 여러 도구를 제공하는 것과 멀티 에이전트 시스템을 만드는 것 중에서 선택할 수 있는 설계 옵션을 설명합니다. 단일 에이전트의 도구 모음을 늘리는 것으로 충분한 상황과 여러 에이전트 간에 태스크와 기능을 분산하는 것이 더 효과적인 접근방식이 되는 상황을 분석합니다. 이를 통해 개발자는 복잡성 및 기능 요구사항에 따라 최적의 아키텍처를 결정할 수 있습니다.
사전 정의된 흐름이 있는 에이전트와 자율 에이전트 비교
여기서는 사전 정의된 구조화된 워크플로('흐름')가 있는 에이전트와 운영 시 더 큰 유연성과 의사결정 능력을 보이는 더 자율적인 에이전트를 구분합니다. 제어와 적응성 간의 절충점과 각 유형의 에이전트가 다양한 애플리케이션에서 가장 적합한 경우를 살펴봅니다.
단기 및 장기 메모리
이 섹션에서는 Agent Framework 내의 단기 메모리와 장기 메모리 개념을 설명합니다. 에이전트가 대화 컨텍스트(단기 메모리)를 관리하고 세션 전반에서 지식이나 데이터를 유지하는 방법(장기 메모리)을 알아봅니다. 이러한 메모리 메커니즘을 이해하는 것은 상태를 유지하고 시간이 지남에 따라 학습할 수 있는 에이전트를 빌드하는 데 중요합니다.
단일 단계 계획과 다중 단계 계획 비교
단일 단계 계획(즉각적인 결정)과 다중 단계 계획(전략 수립 및 복잡한 태스크를 시퀀스로 분할)을 비교하여 에이전트의 계획 기능을 살펴봅니다. 이 섹션에서는 각 계획 접근 방식의 이점과 복잡성, 그리고 이러한 접근 방식이 에이전트 행동과 문제 해결 능력에 미치는 영향을 설명합니다.
단일 도구와 여러 도구 그리고 AgentTools 비교
이 섹션에서는 에이전트를 위한 다양한 도구 구성을 비교하여 간략히 설명합니다. 단일 도구, 여러 도구가 장착된 에이전트, 전문 'AgentTools'(다른 에이전트를 호출하는 도구)의 사용을 살펴봅니다. 목적은 각 도구 유형 및 구성의 목적과 사용 시나리오를 명확히 하는 것입니다.
도구와 메모리
이 섹션에서는 에이전트 설계에서 도구와 메모리의 상호작용 및 관계를 설명합니다. 에이전트가 메모리를 활용하여 도구 사용을 알리고, 도구 출력을 저장하고, 시간 경과에 따라 도구 선택을 최적화하는 방법을 살펴봅니다. 이 상호작용을 이해하는 것은 성능을 개선하기 위해 도구와 메모리를 모두 효과적으로 활용하는 에이전트를 빌드하는 데 중요합니다.
에이전트 테스트 및 QA
이 섹션에서는 에이전트를 위한 테스트 및 품질 보증(QA)의 중요한 측면에 중점을 둡니다. 에이전트 동작, 도구 통합, 전반적인 시스템 성능을 엄격하게 테스트하기 위한 전략과 방법론을 논의합니다. 이 가이드의 목적은 배포 전에 에이전트의 안정성과 정확성을 보장하는 방법을 안내하는 것입니다.
에이전트 평가
이 섹션에서는 테스트를 기반으로 에이전트 평가에 대해 구체적으로 설명합니다. 정의된 측정항목과 벤치마크에 따라 에이전트 성능을 체계적으로 측정하고 평가하는 방법을 자세히 살펴봅니다. 평가 프레임워크, 정확성 및 효율성과 같은 측정항목, 평가를 사용하여 에이전트 설계를 개선하는 방법에 관한 논의가 나옵니다.
멀티 에이전트
이 섹션에서는 프레임워크 내 멀티 에이전트 시스템의 개념을 자세히 살펴봅니다. 이전에 언급된 멀티 에이전트 개념을 통합하고 확장하여 아키텍처, 이점, 과제에 관한 포괄적인 개요를 제공합니다. 이는 멀티 에이전트 애플리케이션을 이해하고 설계하는 데 중추적인 리소스로 활용될 것입니다.
흐름
이 섹션에서는 Agent Framework의 '흐름'에 관해 자세히 설명합니다. 사전 정의된 다양한 유형의 흐름(순차, 루프, 자동 등)과 이러한 흐름이 에이전트 동작과 하위 에이전트와의 상호작용을 관리하는 방식을 자세히 설명합니다. 흐름 메커니즘과 맞춤설정 옵션에 대한 명확하고 체계적인 설명을 기대할 수 있습니다.
커뮤니케이션
이 섹션에서는 특히 멀티 에이전트 시스템에서 Agent Framework 내의 커뮤니케이션을 살펴봅니다. 에이전트가 정보를 교환하고, 작업을 조정하고, 공동 목표를 달성하기 위해 협력하는 방법을 논의합니다. 에이전트 간의 효과적인 커뮤니케이션을 위한 메커니즘과 패턴에 중점을 둡니다.
계획
이 섹션에서는 에이전트 내 계획을 더 자세히 살펴봅니다. 다양한 계획 알고리즘, 복잡한 태스크를 분류하기 위한 전략, 에이전트가 계획을 사용하여 작업과 도구 사용을 지시하는 방법을 다룹니다. 에이전트 개발과 관련된 계획 방법론에 관한 보다 기술적인 논의가 있을 예정입니다.
세션 및 상태
이 섹션에서는 Agent Framework의 세션 및 상태 관리에 관해 포괄적으로 설명합니다. 세션이 생성되고 유지되는 방식, 상태 변수가 정보를 저장하고 액세스하는 데 사용되는 방식, 세션 데이터의 수명 주기에 대해 자세히 설명합니다. 세션과 상태를 이해하는 것은 상호작용 전반에서 컨텍스트를 관리하고 연속성을 유지할 수 있는 에이전트를 빌드하는 데 중요합니다.
콜백
마지막으로 이 섹션에서는 Agent Framework 내 콜백에 관한 자세한 설명을 제공합니다. 다양한 유형의 콜백(에이전트 전/후, 모델, 도구), 목적, 개발자가 이를 사용하여 프로세스의 다양한 단계에서 에이전트 동작을 맞춤설정하고 확장하는 방법을 다룹니다. 고급 에이전트 맞춤설정에 콜백을 활용하는 방법을 자세히 알아보세요.