더 적은 수의 도구로 GitHub Copilot을 더욱 스마트하게 만드는 방법

VS Code에서 GitHub Copilot Chat은 MCP(모델 컨텍스트 프로토콜)를 통해 코드베이스 분석 도구부터 Azure 관련 유틸리티에 이르기까지 수백 가지 도구에 액세스할 수 있습니다. 그러나 상담원에게 너무 많은 도구를 제공한다고 해서 상담원이 항상 더 똑똑해지는 것은 아닙니다. 때로는 속도가 느려질 수도 있습니다.

VS Code에서 이 스피너를 본 적이 있다면 한 번에 너무 많은 도구를 추론하려는 모델의 한계에 도달한 것입니다.

이 문제를 해결하기 위해 우리는 내장형 도구 라우팅과 적응형 도구 클러스터링이라는 두 가지 새로운 시스템을 구축했으며 기본 40개 기본 제공 도구를 13개 핵심 도구로 줄이는 축소된 도구 세트를 출시할 예정입니다. GPT-5 및 Sonnet 4.5를 모두 사용하는 SWE-Lancer 및 SWEbench-Verified와 같은 벤치마크에서 이러한 변경 사항은 성공률을 2~5% 포인트 향상시킵니다. 온라인 A/B 테스트에서는 응답 지연 시간을 평균 400밀리초 단축합니다.

VS Code의 기본 도구 세트는 일반 명령줄 유틸리티부터 Jupyter Notebook용 특수 도구에 이르기까지 약 40개의 기본 제공 도구로 구성됩니다. MCP 서버를 포함하면 그 수가 수백 개로 늘어날 수 있습니다. 종종 MCP 서버는 일부 모델의 API 제한을 초과할 수 있는 너무 많은 도구를 가져옵니다.

우리는 에이전트의 기능을 제한하지 않으면서 사용자의 쿼리와 가장 관련성이 높은 도구만 제공하기 위해 도구 세트를 필터링하는 방법을 모색했습니다. 특히, 우리는 더 짧은 지연 시간을 달성하기 위해 사용자 경험을 희생하지 않도록 해야 했습니다.

이를 달성하기 위해 우리는 “가상 도구”라는 중간 접근 방식을 설계했습니다. 여기에는 채팅 상담원이 필요에 따라 확장할 수 있는 하나의 “가상 도구” 아래 유사한 도구를 기능적으로 그룹화하는 것이 포함됩니다. 이를 관련 도구가 포함된 디렉토리로 생각하십시오. 이를 통해 모델은 수백 개의 도구 이름을 너무 많이 사용하지 않고도 사용 가능한 것에 대한 일반적인 감각을 얻을 수 있습니다. 또한 유사한 도구가 함께 사용되고 활성화될 가능성이 높기 때문에 모델이 개별 도구를 검색할 경우 예상되는 캐시 실패율도 줄어듭니다.

적응형 도구 클러스터링

처음에 우리는 사용 가능한 모든 도구를 LLM에 제공하고 이를 그룹화하고 요약하도록 요청했습니다. 하지만 여기에는 두 가지 큰 문제가 있었습니다.

• 생성된 그룹 수를 제어할 수 없었고 때로는 모델 제한을 초과했습니다.
• 속도가 매우 느리고 막대한 토큰 비용이 발생했습니다. 또한 모델은 때때로 특정 도구를 분류하는 것을 ‘잊어서’ 재시도를 강제합니다.

이 문제를 해결하기 위해 의미론적 유사성 작업에 최적화된 내부 Copilot 임베딩 모델을 적용하여 각 도구에 대한 임베딩을 생성하고 코사인 유사성을 사용하여 그룹화했습니다. 이 클러스터링 방법을 사용하면 정확하고 안정적이며 재현 가능한 그룹이 가능해졌습니다. 예를 들어, 임베딩 공간에서 GitHub MCP 서버 도구에 대한 가능한 임베딩 그룹 중 하나는 다음과 같습니다.

우리는 여전히 모델 호출을 사용하여 각 클러스터를 요약하지만 이 단계는 모델에 모든 것을 처음부터 분류하도록 요청하는 것보다 훨씬 빠르고 저렴합니다. 도구 임베딩 및 그룹 요약은 로컬로 캐시되므로 다시 계산하는 비용이 비교적 저렴합니다.

상황에 맞는 도구 선택

도구가 그룹화되면 또 다른 문제에 직면하게 됩니다. 모델을 모두 확인하지 않고 어떤 그룹을 열어야 할지 어떻게 알 수 있을까요? 우리는 대부분의 경우 모델이 결국 작업에 적합한 도구를 찾으세요. 그러나 가상 도구를 호출할 때마다 여전히 캐시 누락, 추가 왕복이 발생하고 소수의 에이전트 작업이 실패할 가능성이 있습니다.

예를 들어 사용자가 다음과 같이 말할 때: “이 버그를 수정하고 dev 브랜치에 병합하세요.”

모델이 자주 열립니다 검색 도구그 다음에 문서화 도구그 다음에 로컬 Git 도구마침내 그것이 실제로 필요하다는 것을 깨닫기 전에 GitHub MCP 도구 그룹 내의 병합 도구 작업을 완료합니다.

컨텍스트에서 올바른 그룹이 상당히 분명하더라도 잘못된 그룹 조회가 있을 때마다 대기 시간과 오버헤드가 추가됩니다.

이 문제를 해결하기 위해 우리는 내장형 도구 라우팅. 도구 그룹이 확장되기 전에 시스템은 쿼리 임베딩을 모든 도구(및 해당 클러스터)의 벡터 표현과 비교하여 그룹 내부 깊숙이 묻혀 있는 경우에도 의미상 가장 관련성이 높은 후보를 미리 선택할 수 있습니다.

상황 인식 라우팅을 사용하면 모델에 다음이 필요할 가능성이 매우 높다는 것을 처음부터 추론할 수 있습니다. 병합 도구 GitHub MCP 도구 그룹 내에서 후보 세트에 직접 포함하여 불필요한 탐색 호출을 제거하고 대기 시간과 실패율을 크게 줄입니다.

가장 유망한 일치 항목만 표시함으로써 중복 탐색을 줄이면서 모델 검색을 더욱 목표화하고 안정적으로 만듭니다.

임베딩 기반 선택(Copilot 임베딩 모델 기반)

우리는 다음을 통해 임베딩 기반 선택 프로세스의 성공 여부를 계산합니다. 도구 사용 범위, 모델이 필요할 때 올바른 도구를 이미 표시하는 빈도를 측정합니다.

벤치마크에서 임베딩 기반 접근 방식은 94.5%의 도구 사용 범위를 달성하여 LLM 기반 선택(87.5%)과 기본 정적 도구 목록(69.0%)을 모두 능가했습니다.

오프라인이 접근 방식은 적용 범위가 27.5% 절대적으로 개선되어 LLM 기반 방법을 확실히 능가하는 동시에 상담원이 더 빠르게 추론하고 효율성을 유지하는 데 도움이 되었습니다.

온라인 테스트 동일한 패턴을 보여줍니다. 19% 의 안정적인 도구 호출이 이전 방법을 사용하여 성공적으로 사전 확장된 반면, 72% 의 Insiders 도구 호출은 임베딩 기반 일치 덕분에 사전 확장되었습니다. 이는 오프라인에서 관찰된 이득이 실제 사용량에 일관되게 반영된다는 것을 확인시켜 줍니다.

대규모 MCP 서버가 트리거할 수 있는 모델 제한에 도달하지 않더라도 너무 큰 내장 도구 세트는 여전히 성능을 저하시킵니다. 오프라인 벤치마크에서는 에이전트가 전체 내장 도구 세트에 액세스할 수 있을 때 SWE-Lancer를 포함한 벤치마크에서 해결률이 2~5% 감소하는 것을 관찰했습니다. 행동적으로 에이전트는 명시적인 지침을 무시하고 도구를 잘못 사용하며 현재 작업에 불필요한 도구를 호출하게 됩니다.

그래서 목록을 정리했습니다. 도구 사용 통계 및 성능 데이터를 기반으로 13가지 필수 도구의 핵심 도구 세트를 식별했습니다. 이러한 도구에는 높은 수준의 저장소 구조 구문 분석, 파일 읽기 및 편집, 컨텍스트 검색 및 터미널 사용이 포함됩니다.

핵심이 아닌 나머지 기본 제공 도구는 Jupyter 노트북 도구, 웹 상호 작용 도구, VS Code 작업 공간 도구 및 테스트 도구라는 네 가지 가상 범주로 그룹화됩니다. 이런 방식으로 모델은 더 작은 코어 설정을 미리 확인하고 필요한 경우에만 그룹을 확장할 수 있습니다. 결과적으로 축소된 도구 집합을 사용하는 사용자는 TTFT(Time To First Token)에서 평균 190밀리초 감소, TTFT(최종 토큰까지 시간 또는 모델 응답 완료 시간)에서 평균 400밀리초 감소를 경험합니다.

더 작은 도구 세트를 사용하면 에이전트가 더 효과적으로 작동할 수 있습니다. 즉, 추론이 더 단순해지고 응답 시간이 빨라지며 성능이 향상됩니다.

미래 방향: 도구 선택에서 장기 맥락 추론까지

MCP 시스템이 발전함에 따라 문제는 단지 올바른 도구를 선택하는 것이 아니라 시간, 컨텍스트 및 상호 작용에 대한 추론입니다.

진정한 지능형 모델은 쿼리에만 반응해서는 안 됩니다. 그래야 한다 이전 도구 사용을 기억하고, 기록에서 의도를 추론하고, 다단계 작업을 계획합니다. 긴 세션 동안. 이런 의미에서 도구 선택은 장기 맥락 추론의 초기 형태입니다. 오늘날 모델이 올바른 도구로 경로를 지정하는 데 도움이 되는 동일한 메커니즘은 미래에는 수천 차례에 걸쳐 추론하여 행동할 때, 위임할 때, 중지할 때를 결정하는 데 도움이 될 수 있습니다.

다음 단계는 임베딩, 메모리 및 강화 신호를 결합하여 학습하는 상황 인식 에이전트를 만드는 방법을 탐색하는 것입니다. 어떻게 도구를 사용하는 것뿐만 아니라 어느 골라야 할 것.

감사의 말

지속적으로 피드백을 제공하고 GitHub Copilot을 통해 가능한 최고의 에이전트 경험을 제공하도록 격려해 주신 개발자 커뮤니티에 큰 감사를 드립니다. 또한 이 블로그를 작성하는 데 도움을 준 팀의 연구원인 Zijian Jin과 이 작업을 수행한 VS Code 및 GitHub Copilot의 연구원, 엔지니어, 제품 관리자에게도 큰 감사를 드립니다. (또한 응용연구원과 소프트웨어 엔지니어를 채용하고 있으니 편하게 지원해주세요!)

작성자:

수석 소프트웨어 엔지니어