View a markdown version of this page

도구 범위 - AWS 권장 가이드
세분화대략적MCP 도구 크기 조정 모범 사례

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

도구 범위

도구를 개발하는 방법에는 세분화된 방식과 대략적인 방식이라는 두 가지가 있습니다.

세분화

세분화된 접근 방식에서는 API, 작업 또는 쿼리별로 도구를 생성합니다. 예를 들어 Git 리포지토리에 대한 , create_issue get_issueadd_label, assign_issue, 및 close_issue 도구를 생성할 수 있습니다. 이렇게 하면 LLM이 각 API를 세부적으로 호출하고 필요에 따라 각 API를 오케스트레이션할 수 있습니다. '쿼리가 부분 결과만 반환합니다'라는 제품 서비스에 대한 문제를 생성하고, 버그 및 높은 우선 순위로 레이블을 지정하고, Alice에 할당합니다.'라는 프롬프트를 생각해 보세요. 다음 이미지는 tool-per-API 접근 방식이이 프롬프트에 어떻게 응답하는지 보여줍니다.

API당 도구를 사용한 세분화된 접근 방식.

이 접근 방식에서는 시스템 프롬프트와 등록된 모든 도구 정의가 각 호출 시 LLM에 제공됩니다. 이렇게 하면 추가 컨텍스트가 사용되며 각 도구 호출이 LLM에 대한 개별 호출을 나타내기 때문에 지연 시간 페널티가 발생합니다. 또한 워크플로 내에서 오류를 처리하는 복잡성을 높입니다.

대략적

대략적이거나 워크플로 중심의 접근 방식은 워크플로 지향적인 도구입니다. 이 도구는 API 구조를 통한 end-to-end 사용자 의도에 중점을 둡니다. tool-per-API 대신 많은 APIs. 이전 Git 리포지토리 예제를 사용하여 에이전트가 한 번 호출하는 create_and_setup_issue 도구를 생성할 수 있습니다. 도구 구현은 문제를 생성하고, 레이블을 추가하고, 도구에 제공된 파라미터를 기반으로 사용자에게 할당합니다. 다음 이미지는 대략적인 접근 방식이 동일한 프롬프트를 처리하는 방법을 보여줍니다.

도구가 워크플로 지향적인 대략적인 접근 방식입니다.

이 접근 방식은 LLM 계층에서 모든 복잡성을 숨기는 방법을 보여줍니다. 오케스트레이션 로직이 도구 구현에 포함되면 모든 순차적 단계, 로깅, 재시도 로직, 회로 차단기 및 속도 제한이 도구에서 결정론적으로 수행됩니다. 워크플로 기반 접근 방식을 사용하면 LLM이 올바른 파라미터를 사용하여 올바른 도구를 더 간단하게 호출할 수 있습니다. Amazon EC2 APIs와 같은 일부 RunInstances API는 이미 워크플로 의도를 제공할 수 있습니다. 이러한 경우 tool-per-API 원하는 워크플로 지향 설계를 제공할 수 있습니다.

그러나 도구도 너무 거칠어질 수 있습니다. 단일 워크플로 도구가 너무 많은 작업을 시도하고 가능한 파라미터가 많은 경우 LLM은 도구를 올바르게 사용하는 방법을 추론하는 데 어려움을 겪을 수 있습니다. 또한 파라미터 선택 및 오류 처리와 관련된 문제를 일으킬 수 있습니다. 따라서 도구 개발은 사용자 의도에 부합하고 단일 도구에서 기능이 너무 적거나 너무 많지 않도록 균형을 맞춰야 합니다. 전체 사용자 워크플로, 일반적으로 함께 발생하는 번들링 작업(예: 3개 이상의 API 직접 호출)을 중심으로 도구를 설계하는 것이 좋습니다. 또한 8개 이상의 파라미터를 초과하거나 여러 개의 고유한 사용자 의도를 처리하는 도구를 분해하는 것이 좋습니다. 실제 프롬프트로 테스트하여 에이전트가 각 도구를 올바르게 사용할 수 있는지 확인합니다.

결정적 도구로 쉽게 캡슐화할 수 없는 복잡하고 동적인 워크플로가 있는 경우 agent-as-tool 패턴을 사용하는 것이 좋습니다. 기본 에이전트가 워크플로에서 복잡한 작업을 오케스트레이션하려고 하는 대신 특수 에이전트가 도구 역할을 할 수 있습니다. 이러한 유형의 도구는 고급 의사 결정 및 분기를 구현할 수 있으며, 오류를 처리하고 결정적 코드에서 쉽게 관리할 수 없는 로직을 재시도할 수 있습니다. 이는 Agent2Agent(A2A) 프로토콜과 유사하지만 구별됩니다. A2A 프로토콜은 상호 보완적이며 에이전트 프레임워크에서 에이전트 간의 상호 운용성과 협업을 제공합니다.

각 에이전트에 필요한 핵심 기능을 식별하기 위해 가장 일반적인 사용자 워크플로를 매핑하여 워크플로 분석을 시작하는 것이 좋습니다. 이렇게 하면 실행 가능한 최소 도구 세트가 설정됩니다. 대규모로 MCP 서버를 개발한 경험에 따라 다음 사례를 따르는 것이 좋습니다. 이러한 관행이 충돌하는 경우 사용자 의도와 워크플로의 우선순위를 지정합니다.

MCP 도구 크기 조정 모범 사례

  • 사용자 스토리를 생각하고 일반적인 작업을 번들링 - 도구는 여러 작업을 오케스트레이션할 필요 없이 사용자 상호 작용을 완료하도록 직접 매핑해야 합니다. 워크플로에 일반적으로 3개 이상의 개별 호출이 필요한 경우 이를 단일 도구로 결합합니다. 이렇게 하면 LLM의 인지 부하가 줄어들고, 도구 호출 수가 최소화되며, 작업을 완료하는 데 필요한 컨텍스트 소비와 지연 시간이 줄어들고, 정확도와 지연 시간이 향상됩니다.

  • 파라미터를 8개 이하로 제한 - 도구가 8개의 파라미터를 초과하는 경우 여러 도구로 분해합니다. LLMs 복잡성이 증가함에 따라 파라미터 선택에 어려움을 겪습니다.

    참고

    번들링 작업에 8개 이상의 파라미터가 필요한 경우 워크플로를 간소화하는 것이 엄격한 파라미터 제한보다 더 중요하므로 파라미터 수보다 번들링을 우선시하세요.

  • 별도의 읽기 및 쓰기 작업 - 데이터를 읽고 수정할 수 있는 다양한 도구를 제공합니다. 이러한 분리는 에이전트가 잠재적으로 파괴적인 작업을 수행할 때 이를 명시적으로 만들고, 다양한 권한 부여 정책을 활성화하며, 정보 수집 중에 의도하지 않은 수정의 위험을 줄입니다.

  • 합리적인 기본값 제공 - LLM이 개별 요청과 관련된 파라미터만 지정하도록 도구를 설계합니다. 기본값은 LLM이 고려해야 하는 정보를 최소화하여 파라미터 복잡성을 줄이고 도구 선택 정확도를 개선합니다.

  • 결정론적 실행 선호 - 가능하면 도구 실행 및 출력을 결정론적으로 만듭니다. 결정적 도구는 더 안정적이고 테스트하기 쉽습니다. 결정적 코드에서 쉽게 관리할 수 없는 지능형 오케스트레이션, 분기 로직 또는 고급 오류 처리가 필요한 복잡한 워크플로의 경우 특수 에이전트를 도구로 사용하는 것이 좋습니다. 그러나이 패턴은 복잡성을 추가하므로 선택적으로 사용합니다.