도구가 많은 에이전트가 더 좋을까요? Copilot Studio를 확장하는 네 가지 설계 원칙
잘 동작하는 에이전트에 도구 하나를 더 붙이고, 지식 소스를 추가하고, 예외 처리 지침을 넣습니다. 하나하나는 필요한 기능입니다. 그런데 어느 순간부터 엉뚱한 도구를 고르거나, 같은 작업을 여러 번 호출하거나, 비슷한 요청에도 결과가 달라지기 시작합니다.
Microsoft Copilot Studio Blog의 Are bigger agents better? How to design agents that scale은 이 문제를 기능 부족이 아니라 설계 문제로 다룹니다. “할 수 있는 일이 많다”와 “올바른 일을 안정적으로 한다”는 서로 다른 특성이기 때문입니다.
핵심은 무조건 작은 에이전트를 만드는 것이 아닙니다. 에이전트가 무엇을 보고, 무엇을 판단하며, 무엇을 위임하는지 의도적으로 설계하는 것입니다. 한국 조직의 메이커와 개발자에게도 적용하기 쉬운 공급업체 온보딩 사례로 내용을 풀어보겠습니다.
에이전트가 커질 때 나타나는 네 가지 문제
처음에는 공급업체 정보를 수집하고, 필수 항목을 확인하고, 승인 절차를 시작하는 에이전트였다고 가정해 보겠습니다. 여기에 ERP 조회, 세금 검증, 제재 목록 확인, 은행 정보 검증, 계약 저장, 서비스 티켓, 메일, 보고 기능을 추가하면 어떨까요?
“새 공급업체를 등록해 줘”라는 요청 앞에 여러 검색 도구, 비슷한 생성·수정 도구, 서로 겹치는 정책 문서가 놓입니다. 필요한 기능은 갖췄지만, 올바른 경로를 고르는 일은 더 어려워집니다.
| 문제 | 실제로 어려워지는 부분 |
|---|---|
| Selection | 비슷한 도구 이름·설명 사이에서 정확한 작업 선택 |
| Context | 유한한 컨텍스트 창을 공유하는 도구 정의·지침·지식·대화·도구 출력 |
| Execution | 늘어난 실행 경로에 따른 불필요한 호출·재시도·결과 불일치 |
| Operations | 더 넓어진 기능 범위의 평가·보안·거버넌스·유지보수 |
원문은 Microsoft Research의 tool-space interference 설명도 연결합니다. 각각 잘 동작하는 도구라도 큰 집합 안에서 서로 겹치면 전체 작업 성능을 떨어뜨릴 수 있다는 이야기입니다.
호출하지 않은 도구도 맥락을 차지합니다
도구의 이름, 설명, 매개변수 스키마를 모델에게 전달하면, 해당 도구를 실제 호출하지 않아도 토큰을 사용합니다. 호출 결과 역시 이후 대화의 맥락에 들어갑니다. 원문은 이런 맥락 증가가 비용 증가와 선택 신뢰성 저하로 이어질 수 있다고 설명합니다.
다만 원문에는 특정 도구 수 제한, 성능 개선 비율, 비용 절감률이 제시되어 있지 않습니다. 우리 시나리오에서의 효과는 직접 평가해야 합니다.
런타임이 도와주는 부분: 모델과 tool search
원문은 Copilot Studio의 GitHub Copilot harness가 에이전트 규모 증가에 따른 복잡성 일부를 관리한다고 설명합니다. 여기서 harness는 모델이 도구와 작업을 실행하도록 지원하는 런타임 체계로 이해하면 됩니다.
새 모델이 제공되면 기존 전체 아키텍처를 다시 설계하지 않고도 시나리오별로 평가하고 채택할 수 있습니다. 모델 선택 역시 필요한 역량과 토큰 사용량을 함께 고려하는 비용 최적화 요소입니다. 더 강한 모델이라는 이유만으로 불명확한 지침과 겹치는 도구 문제가 사라지는 것은 아닙니다.
Tool search는 외부 도구의 전체 정의를 처음부터 모두 넣는 대신, 필요한 정의를 요청 시점에 불러오는 방식입니다. 공급업체 등록 요청이라면 조회·검증·등록에 관련된 도구만 좁혀 볼 수 있습니다.
이 런타임은 도구, skills, workflows, MCP servers, 파일, connected agents를 가로질러 계획하고 진행 중 경로를 조정할 수 있다고 원문은 설명합니다. 하지만 도구 검색이 책임 경계를 대신 설계해 주지는 않습니다.
먼저 구성 요소의 역할을 구분하세요
| 구성 요소 | 적합한 책임 |
|---|---|
| Tool | 입력과 출력이 명확한 제한된 작업·조회 |
| Workflow | 일정한 순서, 승인, 업무 규칙의 일관된 실행 |
| Skill | 특정 작업에만 필요한 전문 지침 |
| Connected agent | 맥락·소유권·요구사항이 구분되는 전문 영역 |
| Main agent | 결과 조율, 정보 수집, 판단, 예외 처리 |
이 구성 요소들은 서로 대체 가능한 만능 블록이 아닙니다. 유연성, 지연 시간, 비용, 보안, 유지보수의 차이가 있으므로 책임을 명확하게 맡길 수 있는 가장 단순한 구성 요소를 선택하는 것이 원문의 권고입니다.
원칙 1: 선택지가 서로 구별되게 만드세요
도구·지식 소스·에이전트의 이름과 설명에는 무엇을 하는지뿐 아니라 언제 사용하는지도 담아야 합니다. 중복 기능은 합치거나 제거하고, 같은 의도를 처리하는 범용 도구를 여러 개 노출하는 일을 피합니다.
원문의 예를 한국어로 풀면, 단순한 Search보다 “법인명 또는 세금 ID로 ERP에서 공급업체 검색”이 더 명확합니다. 같은 공급업체 데이터를 조회하는 구현이 두 개라면 모델이 구현 차이를 고민하게 하기보다 명확한 하나의 경로를 제공하는 편이 낫습니다.
Tool search 자체도 이름·설명·매개변수 메타데이터를 사용하므로, 좋은 메타데이터는 검색과 최종 선택 모두에 도움이 됩니다.
원칙 2: 전문 지침은 필요할 때만 불러오세요
특정 지역의 공급업체 실사 규정을 매번 주 에이전트의 지침에 넣으면, 그 지역과 무관한 요청에서도 컨텍스트를 차지합니다.
Skills는 전문 지침을 따로 묶고 작업에 필요할 때 로드하는 방법입니다. 공급업체의 지역에 따라 해당 실사 지침만 불러오는 식입니다.
여기서 목표는 중요한 규칙을 빼는 것이 아니라, 현재 판단과 관계있는 맥락은 가까이 두고 관계없는 맥락은 분리하는 것입니다.
원칙 3: 진짜 경계가 있는 곳에서만 에이전트를 나누세요
에이전트가 커졌다는 이유만으로 분할하지 않습니다. 맥락, 담당 조직, 보안, 요구사항에 의미 있는 경계가 있는지 먼저 확인합니다.
원문은 connected agents를 통해 주 에이전트가 자체 지침·지식·도구·오케스트레이션 맥락을 가진 다른 Copilot Studio 에이전트에 제한된 작업을 위임하는 구조를 설명합니다.
공급업체 온보딩에서는 다음처럼 나눌 수 있습니다.
- 위험 관리팀이 소유한 컴플라이언스 에이전트: 규정 준수 평가
- ERP 접근 권한을 가진 재무 운영 에이전트: 공급업체 레코드 생성
- 자체 템플릿과 정책을 가진 법무 운영 에이전트: 계약 준비
주 에이전트는 수십 개의 하위 도구 대신 몇 개의 명확한 업무 역량을 선택합니다. 각 전문 영역은 별도로 평가하고 보안을 설정하며 배포·개선할 수 있습니다.
또한 원문은 런타임과 시나리오에 따라 지원되는 외부 에이전트를 Agent2Agent 프로토콜로 연결하는 개방형 구조를 설명합니다. 모든 외부 에이전트를 모든 런타임에서 연결할 수 있다는 의미는 아닙니다. 실제 구현에서는 지원 조합을 확인해야 합니다.
원칙 4: 고정된 순서는 workflow가 책임지게 하세요
다음 단계에 판단이 필요하면 에이전트를 사용하고, 순서·승인·통제가 일정해야 하면 workflow를 사용합니다.
원문의 공급업체 온보딩 예시는 다음과 같은 핵심 순서입니다.
- 필수 필드를 검증합니다.
- 기존 공급업체가 있는지 확인합니다.
- 의무적인 컴플라이언스 검사를 실행합니다.
- 레코드를 생성합니다.
- 승인 경로로 전달합니다.
이 순서는 workflow가 맡고, 에이전트는 시작 시점 판단, 누락 정보 수집, 예외 처리를 맡습니다. 승인, 재시도, 감사 요구사항을 한 곳에서 관리하면서 모델이 내려야 할 하위 판단도 줄일 수 있습니다.
도입 체크포인트: 도구 개수가 아니라 결과를 평가하세요
이 방식에도 대가가 있습니다. Skills와 workflows는 관리할 구성 요소를 늘립니다. Connected agents는 소유권과 보안 경계를 명확하게 만들 수 있지만, 위임할 때마다 토큰 사용, 새로운 실패 지점, 거버넌스 대상이 추가됩니다.
따라서 분할 전후를 비교할 때는 원문이 제시한 업무 결과, 신뢰성, 비용, 통제를 기준으로 삼아야 합니다. 실무에서는 동일한 대표 요청과 예외 요청으로 올바른 도구 선택, 중복 호출, 승인 준수, 인계 실패를 확인하는 식으로 평가 항목을 구체화할 수 있습니다. 이 점검 방식은 원문의 원칙을 적용한 제안이지 원문에 제시된 측정 결과는 아닙니다.
원문은 설계 가이드이며 각 기능의 GA·프리뷰 상태, 라이선스 조건, 일괄 출시 일정을 명시하지 않습니다. 기존 환경에 바로 적용할 수 있다고 단정하지 말고, 연결된 제품 문서와 테넌트에서 사용할 수 있는 런타임·기능을 확인한 뒤 구현해야 합니다.
마무리: 가장 큰 에이전트가 아니라 책임이 선명한 시스템
좋은 확장은 기능을 없애는 것이 아니라 책임을 재배치하는 일입니다. 주 에이전트는 전체 결과를 조율하고, tool search는 필요한 도구를 찾아주며, skills는 필요한 지침을 공급합니다. 고정 절차는 workflows가, 의미 있는 전문 영역은 connected agents가 맡습니다.
원문의 결론은 명확합니다. 에이전트 확장은 도구 개수 경쟁이 아닙니다. 적절한 비용과 명확한 소유권 아래 올바른 업무를 안정적으로 수행하는 조합을 만드는 것이 목표입니다.
출처: Microsoft Copilot Studio Blog, Are bigger agents better? How to design agents that scale.
자세한 내용은 원문 참조.