2부 · 도구 & 참고자료
손발(커넥터·MCP)의 최소 큐레이션과, RAG에서 코드 실행으로 바뀐 참고자료.
3. 도구 (Tools) — 에이전트의 손발
▶ 포인트 — 도구는 에이전트가 외부에서 실제로 행동하는 통로다(1부 4장). 두 축 — 커넥터(Microsoft 자산) + MCP(업계 표준) — 로 이해하고, 최소 큐레이션(겹치는 도구 금지)을 지켜라. 많이 붙일수록 좋아지는 게 아니라 오히려 망친다.
3.1 개념 — 도구 = 행동 통로
루프가 “관찰→판단”이라면, 도구는 에이전트가 메일을 보내고·파일을 올리고·DB를 조회하는 실제 행동입니다. 도구가 없으면 “생각만 하는 머리”에 그칩니다.
3.2 어떤 도구를 붙일까 — 선택 기준
도구는 “이 작업에 꼭 필요한가”로 판단합니다. 자주 쓰는 유형:
| 유형 | 필요 판단 | 메모 |
|---|---|---|
| 코드 실행(코드 인터프리터) | 데이터 계산·파일 생성이 있으면 ✅ 필수 | 엑셀 집계·문서 생성의 엔진(1부 9.4·9.5) |
| 지식 연결(SharePoint 등) | 참고할 파일·문서가 있으면 ✅ | 자료가 들어오는 통로(4장) |
| 메일/메시지(MCP·커넥터) | 외부로 보내야 하면 ✅ | 발송엘 확인 게이트 필수 |
| 파일 저장소(OneDrive 등) | 산출물을 링크로 공유·첨부하면 ✅ | 큰 파일 첨부 우회에 사용 |
| 문서 생성 커넥터 | 보통 ❌ | docx/pptx/HTML은 코드로 직접 생성(1부 9.5) |
| 같은 일을 하는 두 번째 도구 | ❌ 금지 | 기능 중복 → 선택 혼란 |
3.3 핵심 원칙 — 최소 큐레이션
짚고 가기: 1부 4.2 Anthropic 경고 — “엔지니어조차 어떤 툴을 쓸지 단언 못 하면, 에이전트는 절대 더 못 한다.”
- 목적당 최소 도구만. 도구가 10개면 에이전트는 매 턴 “뭘 쓸지” 헷갈립니다.
- 기능 중복 금지. 같은 일을 하는 도구를 둘 붙이면(예: 메일 커넥터 + 메일 MCP) 어느 걸 쓸지 모호해집니다. 목적당 하나만.
- 코드로 되는 건 도구로 안 붙인다. docx/pptx/HTML 생성은 컨테이너의 사전설치 라이브러리로 충분(1부 9.5) → 커넥터 불필요.
3.4 커넥터 vs MCP
| 축 | 정체 | 예 |
|---|---|---|
| 커넥터 | Power Platform 1,000+ 검증된 연결 | SharePoint, Outlook |
| MCP | 에이전트-도구 연결 업계 표준 | Work IQ Mail, OneDrive |
둘 다 같은 Microsoft 보안·거버넌스 경계 안에서 실행됩니다. MCP 덕에 커넥터로 못 닿는 도구도 표준 방식으로 붙입니다.
실전 교훈: 파일 저장소 같은 도구는 “처음부터 계획한 도구”가 아니라 문제를 풀다 추가되는 경우가 많다(예: 직접 첨부가 토큰 한계로 막혀 링크 첨부로 우회). 도구는 시나리오가 막히는 지점에서 최소로 추가하는 게 정석이다.
4. 참고자료 (Knowledge) — RAG에서 코드 실행으로
▶ 포인트 — 참고자료는 에이전트가 읽는 지식(엑셀·문서)이다. New CLI 코어의 가장 큰 변화가 여기 있다(1부 9.4) — 클래식은 검색 스니펫으로 답했지만, 신규는 원본 파일을 직접 열어 코드로 처리한다. 그래서 엑셀 집계가 정확해진다.
4.1 개념 — 두 종류의 참고자료
| 종류 | 성ꈁ | 어떻게 쓰나 |
|---|---|---|
| 데이터 파일(엑셀·CSV) | 숫자 — 집계해야 답이 나옴 | 코드로 계산해 정확한 값 |
| 문서(Word·PDF) | 형식·톤·정책 — 참고용 | 말투·규칙을 인용(출처 명시) |
규칙: 숫자는 항상 데이터 파일에서, 말투·형식은 문서에서. 섞지 않습니다.
4.2 왜 코드 실행이 정확한가 — RAG의 한계
클래식(RAG)은 파일을 통째로 받지 않고, 질문과 유사한 청크(조각)만 꺼내 답합니다.
클래식(RAG): "제조사별 평균가?" → 관련 텍스트 조각 → 근사치 ❌
New CLI: "제조사별 평균가?" → 원본 엑셀을 코드로 전체 집계 → 정확값 ✅
표 전체를 합산·평균해야 하는 질문은 청크 검색으로는 구조적으로 틀립니다. 신규 코어는 원본을 열어 전체 행을 계산하므로 정확합니다(1부 9.4).
4.3 토큰 걱정 없이 큰 파일 다루기
“수천 행을 다 읽으면 토큰이 터지지 않나?” → 안 터집니다. 에이전트가 파일을 컨텍스트에 붓는 게 아니라 코드로 처리하고 요약만 보기 때문입니다(1부 9.4).
- 메이커가 할 일: 지침에 “눈대중 말고 실제로 계산“만 적으면 됩니다.
- 나머지(선택 로드·집계·요약)는 에이전트가 알아서.
4.4 SharePoint에 올릴 때
- 엑셀·Word를 SharePoint 사이트에 두고, 그 사이트를 Knowledge로 연결합니다.
- 엑셀(바이너리)은 검색 스니펫이 비어 경로만 옵니다 → 정상. 에이전트가 다운로드해 코드로 처리합니다.
- 컬럼 의미가 헷갈릴 수 있으면 “열 설명” 같은 보조 문서를 스킬에 동봉하면 품질이 올라갑니다(없어도 동작).