한 줄 답: Tool Search나 지연 로딩은 도구를 단순히 덜 보여 주는 옵션이 아닙니다. 대표 업무에서 필요한 도구를 놓치지 않고, 관련 없는 고권한 도구를 불필요하게 드러내지 않는지 확인한 뒤에만 넓혀야 합니다.
이 글에서는 MCP 서버와 도구가 늘어난 팀이 확대·보류·되돌림을 판정할 수 있도록, 10개 업무와 6칸 발견 품질 카드를 만드는 방법을 정리합니다.
핵심 요약
- 발견은 호출 전에 어떤 도구가 후보로 올라오는지 보는 단계입니다. 실행 허가나 운영 관측과 섞지 않는 편이 좋습니다.
- 대표 업무 10개마다 필수 도구와 노출되면 곤란한 도구를 함께 정하면 평가가 재현 가능해집니다.
- 필수 도구 누락, 잘못된 도구 우선 선택, 불필요한 고권한 도구 노출, fallback 증가를 각각 따로 기록해야 원인을 찾을 수 있습니다.
- 지연과 입력 토큰은 좋아질 수도, 나빠질 수도 있습니다. 같은 모델·같은 입력 조건에서 전후를 비교해 팀의 실제 데이터를 확인하세요.
도구가 많아질수록 먼저 분리해야 할 질문
여러 MCP 서버를 연결하거나 내부 도구가 늘어나면, 모델에 모든 정의를 한 번에 전달하는 방식이 부담스러워질 수 있습니다. Anthropic의 도구 사용 문서는 도구가 설명된 기능과 요청이 맞을 때 모델이 호출 여부를 결정한다고 설명하며, Tool Search를 많은 도구를 필요할 때 발견하고 불러오는 방식으로 안내합니다. MCP connector 문서도 원격 MCP 서버를 API에서 연결하는 맥락을 제공합니다.
여기서 중요한 질문은 “도구를 줄여 보일까?”가 아니라 “우리의 실제 업무에서 필요한 도구가 제때 후보가 되는가?”입니다. 검색 결과가 짧아도 필수 도구가 빠지면 업무는 실패합니다. 반대로 관계없는 변경·삭제 권한의 도구가 후보에 자주 섞이면, 사람이 검토해야 할 범위와 실수 가능성이 커집니다.
발견·실행 승인·운영 관측은 서로 다른 단계입니다
| 단계 | 확인할 질문 | 남겨야 할 기록 | 혼동하면 생기는 문제 |
|---|---|---|---|
| 도구 발견 | 이 업무에 필요한 도구가 후보로 보였나요? | 필수·금지 도구 라벨, 후보 목록, 선택 오류 | 호출 전 누락을 실행 로그에서 늦게 발견합니다. |
| 실행 시점 승인 | 선택된 호출을 지금 실행해도 되나요? | 승인 주체, 범위, 거절 사유 | 검색 품질만 믿고 위험한 변경을 허용할 수 있습니다. |
| 운영 관측 | 배포 뒤 실패·재시도·지연이 변했나요? | run ID, 호출 결과, 지연, fallback | 처음엔 통과했지만 실제 업무의 변화를 놓칩니다. |
발견 단계 다음에는 도구 호출의 실행 시점 허가를 설계하는 방법을, 안정적으로 운영하기 시작한 뒤에는 운영 중 관측해야 할 신호를 이어서 확인해 보세요. 도구 정의가 바뀌었다면 스키마와 캐시 안정성 점검도 다시 필요합니다.
FLOWIT 6칸 발견 품질 카드
아래 카드는 특정 제품의 성능표가 아닙니다. 팀이 자기 도구군의 변화를 같은 기준으로 검토하기 위한 기록 양식입니다. 숫자 임계치는 조직의 위험도와 업무 중요도에 맞게 사전에 정하고, 실제 측정값과 구분해 보관하세요.
| 칸 | 무엇을 적나요? | 통과 질문 |
|---|---|---|
| 1. 대표 업무 | 자주 발생하고 실패 비용이 다른 실제 요청 10개 | 테스트용 문장이 아니라 현업 요청을 비식별화해 고정했나요? |
| 2. 필수 도구 | 업무 완료에 반드시 필요한 최소 도구 | 후보 또는 최종 선택에 필수 도구가 빠지지 않았나요? |
| 3. 금지·고권한 도구 | 이 요청에는 불필요하거나 노출 자체를 줄일 도구 | 관련 없는 변경·삭제·외부 전송 도구가 후보에 올라오지 않았나요? |
| 4. 발견 품질 | 필수 도구 발견, 잘못된 선택, 불필요 노출 | 누락과 오선택을 서로 다른 실패로 셌나요? |
| 5. 실행 비용 | discovery+call p95, 입력 토큰, fallback, 호출 성공 | 동일 조건의 전후 run ID로 비교했나요? |
| 6. 중단 조건 | 확대를 멈추거나 이전 방식으로 되돌릴 조건 | 누가 어떤 증거를 보고 보류를 결정하는지 정했나요? |
가상 10-task golden set을 만드는 법
처음부터 모든 도구와 모든 업무를 시험하려 하면 결과를 해석하기 어렵습니다. 먼저 읽기 전용 조회, 내부 문서 검색, 변경 요청처럼 성격이 다른 업무를 10개 고르세요. 아래는 형식만 보여 주는 가상 예시입니다. 실제 도구명과 통과 기준은 팀의 권한 구조에 맞게 바꾸어야 합니다.
| 기록 ID | 가상 업무 | 필수 도구 | 금지·고권한 도구 | 성공 판정 |
|---|---|---|---|---|
| G-01 | 이번 주 장애 요약을 찾아 주세요. | incident_search | incident_delete | 조회 도구가 후보에 있고 삭제 도구는 불필요하게 나타나지 않습니다. |
| G-02 | 고객사 계약 갱신일을 확인해 주세요. | contract_lookup | contract_update | 조회만으로 답할 수 있는 경로가 선택됩니다. |
| G-03 | 배포 실패 로그를 찾아 원인을 분류해 주세요. | deployment_log_search | production_rollback | 로그 검색이 후보가 되며 되돌리기 도구는 호출 전 후보에서 제외됩니다. |
| G-04~10 | 실제 업무 요청 7개 | 업무별 최소 도구 | 업무별 제외 도구 | 필수 도구 누락·오선택·불필요 노출을 개별 기록합니다. |
기록을 남기는 순서
- 각 업무에 하나 이상의 필수 도구와 하나 이상의 제외 도구를 적습니다.
- 검색 전후에 모델, 입력 문장, 도구 설명 버전을 고정하고 같은 run ID로 묶습니다.
- 후보 목록과 최종 선택을 나누어 저장합니다. 후보에 없었던 실패와 후보는 있었지만 잘못 선택한 실패의 대응이 다르기 때문입니다.
- fallback이 생겼다면 사람이 개입했는지, 다른 도구로 바뀌었는지, 단순 재시도였는지를 구분합니다.
실패 조건을 먼저 쓰면 도입 판단이 빨라집니다
가장 위험한 경우는 평균값이 좋아 보이는데 중요한 업무 하나에서 필수 도구가 빠지는 경우입니다. 운영팀은 “대체로 잘 된다”보다 “어떤 요청에서 무엇이 빠지면 멈출 것인가”를 먼저 합의하는 편이 안전합니다.
- 필수 도구 누락: 정해진 대표 업무에서 필수 도구가 후보에 없으면 해당 도구군 확대를 멈춥니다.
- 오선택: 후보는 맞지만 더 넓은 권한 또는 다른 목적의 도구가 우선 선택되면 설명·분류·도구 설명을 다시 점검합니다.
- 불필요 노출: 읽기 전용 요청에 변경·삭제·외부 전송 도구가 반복 노출되면 검색 범위와 서버 분리를 검토합니다.
- 비용·응답 악화: 같은 업무에서 지연, 입력 토큰, fallback이 사전에 정한 범위를 넘으면 확대 대신 원인 분석으로 전환합니다.
확대·보류·되돌림은 이렇게 결정하세요
| 판정 | 관찰된 증거 | 다음 행동 |
|---|---|---|
| 제한 확대 | 10개 대표 업무에서 필수 도구가 안정적으로 발견되고, 제외 도구 노출과 오선택이 팀 기준 안에 있으며 fallback 원인이 설명됩니다. | 낮은 위험도의 도구군에 1주 제한 적용하고 매일 같은 카드를 갱신합니다. |
| 보류 | 지연·입력 토큰·fallback 변화가 해석되지 않거나, 특정 업무의 후보 품질이 흔들립니다. | 도구 설명, 분류, 서버 경계, 대표 업무를 보완한 뒤 같은 조건으로 재시험합니다. |
| 되돌림 | 필수 도구 누락 또는 관련 없는 고권한 도구의 반복 노출이 발생하고, 업무 영향이 확인됩니다. | 확대 범위를 즉시 줄이고 기존 노출 방식으로 복귀한 뒤 원인과 증거를 검토합니다. |
한 번에 전 조직에 적용하기보다, 업무 중요도가 낮고 되돌리기 쉬운 도구군부터 1주 동안 제한적으로 확인하세요. 이때 발견 결과만 보지 말고 호출 직전의 승인 기록, 실제 실행 결과, fallback까지 같은 run ID로 연결해야 판단이 흔들리지 않습니다.
자주 묻는 질문
도구가 많지 않아도 이 카드가 필요한가요?
네. 수가 적어도 서로 비슷한 기능의 도구가 있거나 권한 차이가 크다면 대표 업무와 제외 도구를 정해 두는 편이 좋습니다. 다만 10개가 부담스럽다면 가장 중요한 업무부터 시작해도 됩니다.
발견 단계에서 고권한 도구를 숨기면 권한 관리가 끝나나요?
아닙니다. 발견 단계는 후보를 다루고, 실제 실행에는 별도의 권한·승인·감사 기록이 필요합니다. 두 단계를 같은 통제로 보지 않는 것이 중요합니다.
지연이나 입력 토큰이 좋아지지 않으면 바로 실패인가요?
반드시 그렇지는 않습니다. 중요한 업무의 발견 정확도와 권한 노출이 개선됐다면 비용 변화의 원인을 더 살필 수 있습니다. 다만 사전에 정한 운영 기준을 넘는 악화가 있다면 확대를 보류하세요.
golden task는 얼마나 자주 바꿔야 하나요?
새 서버를 연결하거나 도구 설명·권한·업무 흐름이 바뀔 때 다시 확인하세요. 특히 도구 정의 변화는 기존 결과를 그대로 믿기 어려운 신호입니다.
참고 자료
- Anthropic 도구 사용 개요 — 모델이 도구 설명과 요청을 바탕으로 호출을 결정하는 기본 맥락을 확인했습니다.
- Anthropic MCP connector 문서 — 원격 MCP 서버를 연결하는 적용 범위를 확인했습니다.
- Anthropic Programmatic tool calling 문서 — 도구 선택 이후의 실행 설계와 구분되는 맥락을 참고했습니다.
- Claude Platform 릴리스 노트 — 제품 상태처럼 시점에 민감한 표현은 초안 작성 시점의 공식 안내를 기준으로 재확인했습니다.
이 글이 마음에 드세요?
FLOWIT on YouTube
영상으로도 FLOWIT을 이어서 보세요
AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.
Related Notes
같이 읽으면 좋은 FLOWIT 글
CI가 성공했는데도 배포를 멈춰야 할 때: GitHub Artifact Attestation 6칸 검증 영수증CI가 성공해도 바로 배포하지 마세요. GitHub Artifact Attestation으로 digest·issuer·source·workflow를 확인하고 배포 allow/deny를 남기는 6칸 검증 영수증을 정리합니다.
GitHub Actions OIDC, 시크릿을 지웠는데도 위험할까? 배포 신뢰정책을 검증하는 5개 claim 테스트GitHub Actions OIDC로 장기 cloud key를 없앤 뒤에도 필요한 배포 신뢰 검증을 정리합니다. 허용 1건·거부 4건과 audit log를 묶는 5개 claim 테스트를 확인하세요.
AI 에이전트가 같은 일을 두 번 실행했다면? 외부 행동을 묶는 7칸 action ID 계약AI 에이전트의 결제·배포·티켓 중복 실행을 막는 action ID·outbox·consumer deduplication 설계. 타임아웃과 웹훅 중복에서 재시도 전 확인할 7칸 계약을 정리합니다.