에이전트 시스템 디자인 패턴

에이전트 시스템을 빌드하려면 LLM 호출, 데이터 검색 및 외부 작업이 함께 흐르는 방식을 오케스트레이션해야 합니다. 복잡성과 자율성의 연속체에서, 결정적 체인에서부터 동적 의사 결정을 내릴 수 있는 단일 에이전트 시스템을 지나(내부적으로 여러 LLM 호출을 포함할 수 있음), 여러 특수 에이전트를 조정하는 다중 에이전트 아키텍처까지, 에이전트 시스템에 대한 디자인 패턴을 생각할 수 있습니다.

도구 호출

디자인 패턴을 살펴보기 전에 도구 호출을 단순에서 복잡한 에이전트 시스템에 사용할 수 있는 기본 기능으로 이해하는 것이 중요합니다. 도구 호출은 에이전트 시스템이 외부 함수, 데이터 원본 또는 서비스와 상호 작용할 수 있도록 하는 메커니즘입니다. 이를 활성화할 수 있습니다.

• SQL 쿼리, CRM 페치 또는 벡터 인덱스 검색과 같은 라이브 데이터 조회
• 전자 메일을 보내거나 레코드를 업데이트하는 등의 작업입니다.
• Python 함수 또는 API를 통한 임의 논리 또는 변환

따라서 도구 호출은 선택한 디자인 패턴에 관계없이 LLM이 외부 데이터 또는 API를 "인식"할 수 있는 강력한 메커니즘을 제공합니다.

에이전트 도구에 대한 자세한 내용은 AI 에이전트 도구참조하세요.

아래 섹션에서는 각각 도구 호출을 서로 다른 각도로 활용할 수 있는 세 가지 에이전트 시스템 디자인 패턴에 대해 설명합니다.

Gen AI 앱 디자인 패턴 비교

Gen AI 앱(에이전트) 디자인 패턴은 복잡성 순서대로 표시됩니다.

디자인 패턴	사용 시기	장점	단점
결정적 체인	잘 정의된 작업 기본 RAG와 같은 정적 파이프라인 즉석에서 결정할 필요가 없습니다.	매우 간단합니다. 감사하기 쉬운	융통성이 없는 적응하려면 코드 변경이 필요합니다.
단일 에이전트 시스템	동일한 도메인의 중간 난이도에서 고난도의 쿼리 여러 특수 에이전트의 오버헤드 없이 일부 동적 의사 결정.	유연한 다중 에이전트보다 더 간단합니다. 좋은 기본값	예측 가능하지 않습니다. 반복되거나 잘못된 도구 호출을 방지해야 합니다.
다중 에이전트 시스템	대규모 또는 교차 기능 도메인; 여러 "전문가" 에이전트; 고유 논리 또는 대화 컨텍스트; 고급 리플렉션 패턴	고도로 모듈식 큰 도메인으로 확장	조율하기 복잡한 추적 및 디버그하기가 더 어렵습니다.

단일 에이전트 시스템

단일 에이전트 시스템은 들어오는 요청을 처리하기 위해 여러 LLM 호출을 오케스트레이션하는 하나의 조정된 논리 흐름을 제공합니다. 에이전트는 다음을 수행할 수 있습니다.

1. 사용자 쿼리 및 대화 기록과 같은 관련 컨텍스트와 같은 요청을 수락합니다.
2. 외부 데이터 또는 작업에 대한 도구를 호출할지 여부를 선택적으로 결정하는 가장 적합한 응답 방법에 대한 이유입니다.
3. 필요한 경우 목표를 달성하거나 유효한 데이터 수신 또는 오류 해결과 같은 특정 조건이 충족될 때까지 LLM(및/또는 동일한 도구)을 반복적으로 호출하여 반복합니다.
4. 도구 출력을 대화에 통합합니다.
5. 응집력 있는 응답을 출력으로 반환합니다.

많은 사용 사례에서 LLM 추론의 단일 라운드(종종 도구 호출)로 충분합니다. 그러나 고급 에이전트는 원하는 결과에 도달할 때까지 여러 단계를 반복할 수 있습니다.

"하나의" 에이전트만 있더라도 이 단일 통합 흐름에서 관리되는 여러 LLM 및 도구 호출(계획, 생성, 확인 등)을 계속 사용할 수 있습니다.

예: 지원 센터 도우미

• 사용자가 간단한 질문("반환 정책이란?)을 묻는 경우 에이전트는 LLM의 지식에서 직접 응답할 수 있습니다.
• 사용자가 주문 상태를 원하는 경우 에이전트는 함수 lookup_order(customer_id, order_id)호출합니다. 해당 도구가 "잘못된 주문 번호"로 응답하는 경우 에이전트는 최종 답변을 제공할 수 있을 때까지 계속하여 사용자에게 올바른 ID를 다시 시도하거나 프롬프트를 표시할 수 있습니다.

사용 시기:

• 다양한 사용자 쿼리가 예상되지만 여전히 응집력 있는 도메인 또는 제품 영역 내에 있습니다.
• 특정 쿼리 또는 조건은 고객 데이터를 가져올 시기 결정과 같은 도구 사용을 보증할 수 있습니다.
• 결정적 체인보다 더 많은 유연성을 원하지만 다른 작업에는 별도의 특수 에이전트가 필요하지 않습니다.

장점:

• 에이전트는 호출할 도구(있는 경우)를 선택하여 신규 또는 예기치 않은 쿼리에 적응할 수 있습니다.
• 에이전트는 반복된 LLM 호출 또는 도구 호출을 반복하여 완전한 다중 에이전트 설정 없이 결과를 구체화할 수 있습니다.
• 이 디자인 패턴은 동적 논리 및 제한된 자율성을 허용하면서 다중 에이전트 설정보다 디버그하는 것이 더 간단한 엔터프라이즈 사용 사례의 유용한 지점인 경우가 많습니다.

고려 사항:

• 하드 코딩된 체인에 비해 반복되거나 잘못된 도구 호출을 방지해야 합니다. (무한 루프는 모든 도구 호출 시나리오에서 발생할 수 있으므로 반복 제한 또는 시간 제한을 설정합니다.)
• 애플리케이션이 근본적으로 다른 하위 도메인(재무, devops, 마케팅 등)에 걸쳐 있는 경우 단일 에이전트는 기능 요구 사항으로 다루기 힘들거나 오버로드될 수 있습니다.
• 에이전트에 초점을 맞추고 관련성을 유지하기 위해 신중하게 디자인된 프롬프트 및 제약 조건이 여전히 필요합니다.

결정적 체인(하드 코딩된 단계)

이 패턴에서 개발자는 호출되는 구성 요소, 순서 및 매개 변수를 정의합니다. 어떤 도구를 호출할 또는 어떤 순서가 대한 동적 의사 결정은 없습니다. 시스템은 모든 요청에 대해 미리 정의된 워크플로를 따르므로 매우 예측 가능합니다.

일반적으로 "체인"이라고 하는 흐름은 기본적으로 다음과 같은 단계의 고정 체인입니다.

1. 항상 사용자의 요청을 검색하고 관련 컨텍스트에 대한 벡터 인덱스에서 검색합니다.
2. 해당 컨텍스트를 사용자의 요청과 최종 LLM 프롬프트로 결합합니다.
3. LLM을 호출하고 응답을 반환합니다.

예제: 기본 RAG 체인

결정적 RAG 체인은 항상 다음을 수행할 수 있습니다.

1. 들어오는 사용자의 요청(검색)을 사용하여 벡터 인덱스에서 상위 k 결과를 검색합니다.
2. 검색된 조각을 프롬프트 템플릿(향상된)으로 서식을 지정합니다.
3. 증강된 프롬프트를 LLM에 전달합니다 (생성).
4. LLM의 응답을 반환합니다.

사용 시기:

• 예측 가능한 워크플로가 있는 잘 정의된 작업의 경우
• 일관성 및 감사가 최우선 순위인 경우
• 오케스트레이션 결정에 대한 여러 LLM 호출을 방지하여 대기 시간을 최소화하려는 경우.

장점:

• 가장 높은 예측 가능성 및 감사 가능성.
• 일반적으로 대기 시간이 짧아집니다(오케스트레이션에 대한 LLM 호출 감소).
• 더 쉽게 테스트하고 유효성을 검사할 수 있습니다.

고려 사항:

• 다양하거나 예기치 않은 요청을 처리하는 유연성이 제한됩니다.
• 논리 분기가 증가함에 따라 복잡하고 유지 관리하기 어려울 수 있습니다.
• 새로운 기능을 수용하기 위해 상당한 리팩터링이 필요할 수 있습니다.

다중 에이전트 시스템

다중 에이전트 시스템에는 메시지를 교환하거나 작업을 공동 작업하는 두 개 이상의 특수 에이전트가 포함됩니다. 각 에이전트에는 고유한 도메인 또는 작업 전문 지식, 컨텍스트 및 잠재적으로 고유한 도구 집합이 있습니다. 다른 LLM 또는 규칙 기반 라우터일 수 있는 별도의 "코디네이터"는 요청을 적절한 에이전트로 보내거나 한 에이전트에서 다른 에이전트로 전달할 시기를 결정합니다.

예: 특수 에이전트가 있는 엔터프라이즈 도우미

• 고객 지원 에이전트: CRM 조회, 반환 및 배송을 처리합니다.
• Analytics 에이전트: SQL 쿼리 및 데이터 요약에 중점을 둡니다.
• 감독자/라우터: 지정된 사용자 쿼리 또는 전환 시기에 가장 적합한 에이전트를 선택합니다.

각 하위 에이전트는 고유한 프롬프트 또는 대화 기록을 요구하는 자체 도메인(예: lookup_customer_account 또는 run_sql_query) 내에서 도구 호출을 수행할 수 있습니다.

사용 시기:

• 코딩 에이전트 또는 재무 에이전트와 같은 고유한 문제 영역 또는 기술 집합이 있습니다.
• 각 에이전트는 대화 기록 또는 도메인별 프롬프트에 액세스해야 합니다.
• 하나의 에이전트의 스키마에 모두 맞추는 것은 실용적이지 않은 도구가 너무 많습니다. 각 에이전트는 하위 집합을 소유할 수 있습니다.
• 전문 에이전트 간에 성찰, 비평 또는 상호 협력을 구현하려고 합니다.

장점:

• 이 모듈식 접근 방식은 좁은 도메인을 전문으로 하는 별도의 팀에서 각 에이전트를 개발하거나 유지 관리할 수 있습니다.
• 단일 에이전트가 통합적으로 관리하기 어려워할 수 있는 크고 복잡한 엔터프라이즈 워크플로를 처리할 수 있습니다.
• 고급 다단계 또는 다각적 추론을 용이하게 합니다. 예를 들어 한 에이전트가 답변을 생성하고 다른 에이전트가 이를 확인합니다.

고려 사항:

• 여러 엔드포인트에서 로깅, 추적 및 디버깅을 위한 오버헤드와 에이전트 간의 라우팅 전략이 필요합니다.
• 하위 에이전트 및 도구가 많은 경우 어떤 에이전트가 어떤 데이터 또는 API에 액세스할 수 있는지 결정하는 것이 복잡해질 수 있습니다.
• 에이전트는 신중하게 제한하지 않으면 상호 간에 작업을 무기한 주고받을 수 있습니다.
  • 무한 루프 위험은 단일 에이전트 도구 호출에도 존재하지만 다중 에이전트 설정은 디버깅 복잡성의 또 다른 계층을 추가합니다.

실용적인 조언

선택한 디자인 패턴에 관계없이 안정적이고 유지 관리 가능한 에이전트 시스템을 개발하기 위한 다음 모범 사례를 고려합니다.

1. 간단한 시작: 간단한 체인만 필요한 경우 결정적 체인을 빠르게 빌드할 수 있습니다.
2. 점점 더 복잡해집니다. 더 많은 동적 쿼리 또는 유연한 데이터 원본이 필요하므로 도구 호출을 사용하여 단일 에이전트 시스템으로 이동합니다.
3. 다중 에이전트로 이동: 명확하게 고유한 도메인 또는 작업, 여러 대화 컨텍스트 또는 단일 에이전트의 프롬프트에 비해 너무 큰 큰 도구 집합이 있는 경우에만 가능합니다.

간단한 RAG 체인처럼 사용 사례가 작게 시작되는 경우 하드 코딩된 체인으로 시작합니다. 요구 사항이 진화함에 따라 동적 의사 결정을 위한 도구 호출 논리를 추가하거나 작업을 여러 특수 에이전트로 분할할 수 있습니다. 실제로 많은 실제 에이전트 시스템은 패턴을 결합합니다. 예를 들어 대부분 결정적 체인을 사용하지만 필요한 경우 LLM이 단일 단계에서 특정 API를 동적으로 호출하도록 허용합니다.

Mosaic AI 에이전트 프레임워크 선택하는 패턴에 관계없이 애플리케이션이 성장함에 따라 디자인 패턴을 쉽게 발전시킬 수 있습니다.

개발 지침

• 프롬프트
  • 모순된 지시를 피하고, 정보를 산만하게 하고, 환각을 줄이기 위해 프롬프트를 명확하고 최소화합니다.
  • 바인딩되지 않은 API 집합이나 관련이 없는 대규모 컨텍스트가 아닌 에이전트에 필요한 도구와 컨텍스트만 제공합니다.
• 로깅 & 관찰 가능성
  • 각 사용자 요청, 에이전트 계획 및 도구 호출에 대한 자세한 로깅을 구현합니다. MLflow 추적은 디버깅을 위해 구조화된 로그를 캡처하는 데 도움이 될 수 있습니다.
  • 로그를 안전하게 저장하고 대화 데이터의 PII(개인 식별 정보)를 염두에 두어야 합니다.
• 모델 업데이트 및 버전 고정 설정
  • 공급자가 백그라운드에서 모델을 업데이트할 때 LLM 동작이 바뀔 수 있습니다. 버전 고정 및 빈번한 회귀 테스트를 사용하여 에이전트 논리가 견고하고 안정적으로 유지되도록 합니다.
  • MLflow와 Mosaic AI 에이전트 평가를 결합하여 에이전트의 버전 관리와 품질 및 성능을 정기적으로 평가하는 효율적인 방법을 제공합니다.

테스트 및 반복 지침

• 오류 처리 & 대체 논리
  • 도구나 LLM의 실패에 대비한 계획을 세우세요. 시간 제한, 잘못된 형식의 응답 또는 빈 결과가 워크플로를 중단할 수 있습니다. 고급 기능이 실패할 때 재시도 전략, 대체 논리 또는 더 간단한 대체 체인을 포함합니다.
• 반복 프롬프트 엔지니어링
  • 시간이 지남에 따라 프롬프트 및 체인 논리를 구체화해야 합니다. 버전 간에 성능을 롤백하거나 비교할 수 있도록 각 변경 내용(Git 및 MLflow 사용)을 버전화합니다.
  • DSPy 같은 프레임워크를 사용하여 에이전트 시스템 내에서 프롬프트 및 기타 구성 요소를 프로그래밍 방식으로 최적화합니다.

프로덕션 지침

• 대기 시간 및 비용 최적화
  • 각 추가 LLM 또는 도구 호출은 토큰 사용량 및 응답 시간을 증가합니다. 가능한 경우 단계를 결합하거나 반복된 쿼리를 캐시하여 성능과 비용을 관리하기 쉽게 유지합니다.
• 보안 및 샌드박싱
  • 에이전트가 레코드를 업데이트하거나 코드를 실행할 수 있는 경우 해당 작업을 샌드박스로 만들거나 필요한 경우 사용자 승인을 적용합니다. 이는 의도하지 않은 피해를 방지하기 위해 엔터프라이즈 또는 규제 환경에서 매우 중요합니다.
  • Databricks는 샌드박스 실행을 위해 Unity 카탈로그 도구를 권장합니다. Unity 카탈로그 함수 도구와 에이전트 코드 도구참조하세요. Unity 카탈로그를 사용하면 임의의 코드 실행을 격리할 수 있으며 악의적인 행위자가 에이전트를 속여 다른 요청을 방해하거나 도청하는 코드를 생성하고 실행하는 것을 방지합니다.

이러한 지침에 따라 도구 잘못 호출, LLM 성능 저하 또는 예기치 않은 비용 급증과 같은 가장 일반적인 오류 모드를 많이 완화하고 보다 안정적이고 확장 가능한 에이전트 시스템을 빌드할 수 있습니다.