1부 · 툴·MCP & 서브에이전트

4. 툴 / 커넥터 (+ MCP 업계 표준)

4.1 툴 = 에이전트의 손발

루프가 “관찰→판단”이라면, 툴은 에이전트가 실제로 행동하는 통로입니다. 메일 보내기, DB 조회, 티켓 생성, 승인 처리 등. 도구가 없으면 에이전트는 “생각만 하는 머리”에 그칩니다.

4.2 Anthropic의 툴 설계 3원칙 — 메이커가 반드시 새길 것

짚고 가기: 비대한 도구 추가가 가장 흔한 실패 원인이다.

Effective context engineering 문서는 툴 설계를 직접 다루고, 이건 2부 실습(도구 붙이기)에 그대로 적용됩니다.

• 툴은 토큰 효율적이어야 한다 — 결과를 간결하게 반환
• 기능이 겹치지 않아야 한다 — “엔지니어조차 어떤 툴을 써야 할지 단언 못 하면, 에이전트는 절대 더 못 한다.”
• 최소 viable 툴셋으로 큐레이션하라 — 가장 흔한 실패가 비대한 툴셋(기능 과잉·모호한 선택 지점)

→ 실습 시사점: 커넥터/도구를 무지성으로 다 붙이지 마세요. 목적당 최소 도구만. 도구가 10개면 에이전트는 매 턴 “뭘 쓸지” 헷갈립니다.

4.3 두 개의 축 — 커넥터와 MCP

MCP가 왜 중요한가: MCP는 Anthropic이 제안해 업계 표준으로 자리잡은 “에이전트가 도구·데이터에 연결하는 규격”입니다. New Copilot Studio가 MCP 서버 생태계(Preview)를 지원한다는 건: 커넥터로 못 닿는 광범위한 도구·앱을, 표준 방식으로 붙이되, Microsoft 보안·권한·컴플라이언스 경계 안에서 실행한다는 의미입니다.

4.4 워크플로우 안에서도

워크플로우 노드가 MCP 도구를 호출하고, 필요하면 사용자 승인(휴먼인더루프)을 끼워 실행 가능 (Preview 06/2026).

한 줄 정리: “도구 = 커넥터(Microsoft 자산) + MCP(업계 표준)”. 둘 다 같은 거버넌스 경계 안. 그리고 적을수록 좋다.

5. 서브에이전트 — connected agents + 스킬

5.1 업계 원리 — sub-agent는 왜 쓰는가

짚고 가기: 메인 에이전트의 컨텍스트를 더럽히지 않기 위해서다.

메인 에이전트가 고수준 계획을 잡고, 전문 sub-agent가 깨끗한 컨텍스트에서 집중 작업합니다. 각 sub-agent는 수만 토큰을 써가며 깊이 탐색하지만, 압축된 요약(보통 1,000~2,000 토큰)만 반환합니다. 상세 탐색 컨텍스트는 sub-agent 안에 격리되고, 메인은 종합·분석에 집중 → “관심사의 분리”. — Anthropic, Effective context engineering / Multi-agent research system

또 harness design 문서의 planner·generator·evaluator 3-에이전트 구조(GAN형)는 역할 분리 설계의 정석입니다. 각 에이전트가 “직전 실행에서 발견한 특정 약점”을 메우도록 설계됐습니다.

5.2 New Copilot Studio의 멘탈모델 변화

클래식의 child agent(자식 에이전트) 개념이 그대로 오지 않았습니다. 대신:

• 스킬 = 재사용 가능한 역량을 패키징
• 연결된 에이전트(connected agents) = 다른 에이전트를 끌어와 협업

왜 더 나은가: child agent는 자기 컨텍스트 안에서만 돌아 인터럽트·의도 전환에 약했습니다. 스킬 기반 구성은 인터럽트, 의도 전환, 멀티 인텐트 질의(“A도 하고 B도 해줘”)에 훨씬 자연스럽게 대응합니다.

5.3 현재 제약

• GA 시점엔 Copilot Studio 에이전트끼리만 연결 가능
• Microsoft Foundry · M365 Agents SDK · A2A 프로토콜 기반 외부 에이전트 연결은 곧 추가 예정(외부 자료엔 “확장 예정”으로만)