AI SaaS를 위한 MCP 도구 예산: 에이전트의 토큰, 도구 및 신뢰 소모 방지

AI 에이전트가 비용이 많이 들게 만드는 데는 해킹이 필요하지 않습니다. 때로는 너무 많은 도구, 모호한 권한, 그리고 지출 제한이 없는 것만으로도 충분합니다.

이것이 많은 새로운 AI SaaS 제품 내부에 숨겨진 조용한 위험입니다. 개발자가 에이전트를 CRM, 데이터베이스, 이메일 도구, 분석 API, 결제 시스템 및 내부 지식 베이스에 연결합니다. 데모는 마법처럼 느껴집니다. 그러다 실제 운영 트래픽이 들어옵니다. 모델은 모든 도구 설명을 읽고, 잘못된 엔드포인트(endpoint)를 두 번 호출하며, 느린 워크플로우(workflow)를 재시도하고, 누군가 알아차리기도 전에 토큰 예산을 다 써버립니다.

이 가이드는 AI SaaS 제품을 위한 **MCP 도구 예산 (MCP tool budget)**을 설계하는 방법을 보여줍니다. 이는 에이전트가 볼 수 있는 도구, 각 테넌트(tenant)가 지출할 수 있는 금액, 인간의 승인이 필요한 시점, 그리고 모든 도구 호출이 어떻게 기록되는지를 제한하는 실질적인 제어 계층입니다.

만약 당신의 SaaS가 MCP를 통해 액션(actions)을 노출한다면, 모든 도구를 비용, 권한, 영향 범위(blast radius), 감사(audit) 요구 사항을 가진 작은 운영 API처럼 취급하십시오.

왜 지금 MCP 도구 예산이 중요한가

MCP(Model Context Protocol)는 AI 에이전트가 실제 시스템에 연결하는 방식을 바꾸고 있습니다. 에이전트는 단순히 텍스트를 생성하는 대신, 도구를 발견하고 파일, SaaS API, 데이터베이스, 티켓, 캘린더, 코드 저장소(code repos) 및 내부 서비스에 대해 액션을 호출할 수 있습니다.

이는 유용합니다. 또한 새로운 운영 표면(operating surface)이기도 합니다.

최근의 AI SaaS 신호들은 모두 같은 방향을 가리키고 있습니다. 제품은 채팅 인터페이스에서 **액션 인터페이스 (action interfaces)**로 이동하고 있으며, 구매자들은 비용과 신뢰성에 대해 더 까다로운 질문을 던지고 있고, 개발자들은 코딩 에이전트와 내부 워크플로우에 더 많은 MCP 서버를 연결하고 있습니다.

AI SaaS 제품은 단순히 "모델이 이 도구를 호출할 수 있는가?"라고 물어서는 안 됩니다. 또한 다음과 같은 질문을 던져야 합니다:

이 테넌트가 이 도구를 사용하는 것이 허용되어야 하는가?
이 도구를 지금 모델 컨텍스트(model context)에 로드할 가치가 있는가?
이 워크플로우가 중단되기 전까지 비용이 얼마나 발생할 수 있는가?
이 액션에 인간의 승인이 필요한가?
나중에 무슨 일이 일어났는지 설명할 수 있는가?

이것이 바로 도구 예산이 해결하는 문제입니다.

MCP 도구 예산이란 무엇인가?

**MCP 도구 예산 (MCP tool budget)**은 비용, 컨텍스트 (context), 권한 및 리스크 측면에서 AI 에이전트의 도구 접근을 제어하는 일련의 제한 사항과 정책입니다.

예산 영역	제어 항목	예시
도구 가시성 (Tool visibility)	에이전트가 볼 수 있는 도구	`search_docs` 및 `create_ticket`만 로드
...

도구 예산은 단순히 재무적인 기능만이 아닙니다. 이는 신뢰성 및 보안 기능이기도 합니다.

숨겨진 문제: 도구 비대화가 컨텍스트 비대화로 이어짐

도구는 호출되기 전부터 공짜가 아닙니다.

도구 정의는 컨텍스트 (context)를 차지합니다. 만약 에이전트가 50개의 도구를 본다면, 모델은 해당 도구들의 설명을 읽고 순위를 매겨야 합니다. 이는 프롬프트 (prompt) 크기를 증가시키고, 응답 속도를 늦추며, 도구 선택을 혼란스럽게 만들고, 모델이 더 정밀한 도구 대신 광범위한 도구를 선택하게 만들 수 있습니다.

실용적인 MCP 도구 예산은 다음 질문에 답할 수 있어야 합니다:

이 사용자에게, 이 테넌트 (tenant)에서, 이 워크플로 (workflow) 동안,
에이전트가 어떤 도구를 보아야 하는가,
에이전트가 어떤 도구를 호출할 수 있는가,
...

이 문장은 훌륭한 설계 사양 (design spec)입니다.

AI SaaS 앱에서 흔히 발생하는 MCP 예산 실패 사례

1. 모든 요청에 대해 모든 도구를 로드하는 경우

사용자가 "연체된 송장을 요약해줘"라고 요청한다면, 에이전트의 컨텍스트에 GitHub, Slack, 이메일 전송, 사용자 삭제, 데이터베이스 마이그레이션 도구가 모두 포함될 필요는 없습니다.

대신 워크플로 (workflow) 단위로 도구를 로드하세요:

{
  "workflow": "invoice_summary",
  "allowed_tools": ["billing.search_invoices", "billing.get_customer", "docs.search_policy"]
...

작은 도구 세트는 모델이 사용하기 더 쉬울 뿐만 아니라, 팀이 보안을 유지하기에도 더 쉽습니다.

2. 읽기 도구와 쓰기 도구를 동일하게 취급하는 경우

도움말 문서를 읽는 도구는 이메일을 보내거나, CRM 필드를 업데이트하거나, 고객 데이터를 삭제하는 도구와 같지 않습니다.

리스크 (risk)에 따라 도구를 분류하세요:

리스크 계층 (Risk tier)	도구 예시	기본 정책
낮음 (Low)	문서 검색, 공개 메타데이터 가져오기	로깅과 함께 허용
...

이 표 하나만으로도 많은 피해를 방지할 수 있습니다.

3. 에이전트 작업에 정적 자격 증명 (static credentials)을 사용하는 경우

수명이 짧고 범위가 제한된 자격 증명 (scoped credentials)을 우선적으로 사용하세요:

도구가 사용자를 대신하여 동작하는 경우 OAuth를 사용하세요.
백엔드 자동화에는 테넌트 범위 서비스 토큰 (tenant-scoped service tokens)을 사용하세요.
자격 증명 (credentials)을 정기적으로 교체하세요.
하나의 MCP 서버에 모든 고객에 대한 전역 액세스 (global access) 권한을 부여하지 마세요.
비밀 정보 (secrets)는 프롬프트나 도구 설명이 아닌 볼트 (vault)에 저장하세요.

하나의 워크플로 (workflow)가 실패하더라도, 그것이 플랫폼 전체의 장애로 이어져서는 안 됩니다.

4. 테넌트별 비용 상한선 부재 (No per-tenant cost caps)

AI SaaS의 비용 제어는 모델 토큰 (model tokens)에서 끝나서는 안 됩니다. 도구 호출 (tool calls)은 유료 API, 작업 큐 (queue jobs), 벡터 검색 (vector searches), 데이터베이스 읽기 (database reads), 브라우저 세션 (browser sessions), 문서 파싱 (document parsing) 및 백그라운드 워크플로 (background workflows)를 트리거할 수 있습니다.

여러 수준에서 제한을 설정하세요:

{
  "tenant_id": "tenant_123",
  "daily_agent_budget_usd": 25,
...

첫날부터 완벽한 가격 책정이 필요하지는 않습니다. 추정 단위로 시작하세요. 운영 데이터가 들어옴에 따라 모델을 개선해 나가면 됩니다.

5. 최종 답변만 로깅하는 문제 (Logging only the final answer)

에이전트가 실패했을 때, 최종 답변만으로는 충분한 경우가 거의 없습니다.

다음 사항들을 알아야 합니다:

어떤 도구들이 사용 가능했는가?
어떤 도구들이 호출되었는가?
각 호출의 비용은 얼마였는가?
어떤 테넌트와 사용자가 이를 트리거했는가?
출력이 잘렸는가 (truncated)?
에이전트가 재시도 (retry)했는가?
정책 (policy)이 동작을 차단했는가?
사람이 승인했는가?

이 질문들에 답할 수 없다면, 운영 제어권 (operational control)을 갖지 못한 것입니다.

실무적인 MCP 도구 예산 아키텍처

다음은 많은 초기 AI SaaS 팀에 적합한 간단한 아키텍처입니다.

사용자 요청 (User request)
   ↓
의도 분류기 (Intent classifier)
...

1. 의도 분류기 (Intent classifier)

도구를 로드하기 전에 워크플로 (workflow)를 식별하세요.

의도 (intents) 예시:

support_ticket_triage (지원 티켓 분류)
invoice_summary (송장 요약)
crm_update_draft (CRM 업데이트 초안)
knowledge_base_search (지식 베이스 검색)
security_report_export (보안 보고서 내보내기)

작은 분류기 (classifier), 규칙 엔진 (rules engine) 또는 라우트 맵 (route map)만으로도 충분합니다.

2. 워크플로 정책 조회 (Workflow policy lookup)

각 워크플로를 허용된 도구, 제한 사항 및 승인 규칙에 매핑하세요.

{
  "workflow": "crm_update_draft",
  "allowed_tools": [
...

prepare_update와 apply_update 사이의 분리를 주목하세요. 이는 강력한 패턴입니다. 에이전트가 변경 사항을 초안(draft)으로 작성하게 하되, 이를 적용하기 전에는 반드시 확인(confirmation)을 거치도록 하세요.

3. 도구 레지스트리 필터 (Tool registry filter)

여러분의 MCP 서버는 많은 도구를 노출할 수 있습니다. 하지만 에이전트가 그 모든 도구를 볼 필요는 없습니다.

메타데이터를 포함한 레지스트리를 생성하세요:

{
  "name": "billing.refund_payment",
  "description": "정책 검증 후 환불을 처리합니다.",
...

그런 다음 테넌트(tenant), 사용자 역할(user role), 플랜(plan), 워크플로(workflow) 및 리스크(risk)에 따라 필터링하세요.

4. 예산 검사기 (Budget checker)

예산 검사기는 모든 도구 호출(tool call) 전에 실행됩니다.

다음 사항들을 확인합니다:

이 도구가 해당 워크플로에 허용되는가?
이 사용자가 해당 동작을 수행할 권한이 있는가?
테넌트가 일일 예산 범위 내에 있는가?
워크플로가 실행 시간 및 호출 제한 내에 있는가?
이 동작에 승인(approval)이 필요한가?
입력값이 너무 크거나 위험한가?

의사 코드 (Pseudo-code):

type ToolCall = {
  tenantId: string;
  userId: string;
...

이 정책 계층(policy layer)은 모델 외부에 위치해야 합니다.

5. MCP 도구 실행 게이트웨이 (MCP tool execution gateway)

모델이 민감한 백엔드 서비스(backend services)를 직접 호출하게 두지 마세요. 에이전트와 도구 사이에 게이트웨이를 배치하세요.

간단한 래퍼(wrapper)는 다음과 같은 형태일 수 있습니다:

async function executeToolWithBudget(call: ToolCall, args: unknown) {
  const decision = await authorizeToolCall(call);
  await logToolDecision({ call, decision, argsHash: hash(args) });
...

이것은 단순한 기업용 보여주기식 행위(enterprise theater)가 아니라, 기본적인 프로덕션 위생(production hygiene)입니다.

UX를 망치지 않고 제한을 설정하는 방법

엄격한 예산은 에이전트를 더 안전하게 만들 수 있지만, 동시에 에이전트를 짜증 나게 만들 수도 있습니다. 핵심은 실패 원인을 명확히 알리고 다음 단계(next step)를 제시하는 것입니다.

나쁜 예산 실패 사례:

Error: tool_call_limit_exceeded

더 나은 예산 실패 사례:

처음 25개의 인보이스(invoices)를 확인했으나, 이 워크스페이스가 해당 워크플로에 대한 제한에 도달했습니다. 날짜 범위를 좁히거나 관리자에게 더 심층적인 스캔 승인을 요청할 수 있습니다.

UI에 예산 상태를 노출하세요:

"이 작업은 승인이 필요합니다."
"이 워크플로우(Workflow)는 허용된 10개의 도구 호출 중 6개를 사용했습니다."
"개인 정보가 포함되어 있어 대규모 내보내기가 차단되었습니다."
"중복 업데이트를 방지하기 위해 재시도가 중단되었습니다."

경계(Boundaries)가 가시적일 때 사용자는 에이전트(Agent)를 더 신뢰합니다.

AI SaaS 빌더를 위한 시작 체크리스트

도구 설계 (Tool design)

각 도구는 하나의 명확한 작업만을 수행합니다.
읽기 도구(Read tools)와 쓰기 도구(Write tools)가 분리되어 있습니다.
위험한 도구는 기본적으로 비활성화되어 있습니다.
도구 설명(Tool descriptions)에 비밀 정보(Secrets)가 포함되어 있지 않습니다.
도구 입력(Tool inputs)에 엄격한 스키마(Schemas)를 사용합니다.
도구 출력(Tool outputs)이 제한되고 비식별화(Redacted) 처리됩니다.

예산 제어 (Budget controls)

각 워크플로우(Workflow)에 최대 도구 호출 횟수가 설정되어 있습니다.
각 워크플로우(Workflow)에 최대 실행 시간(Runtime)이 설정되어 있습니다.
각 테넌트(Tenant)별로 일간 또는 월간 에이전트(Agent) 제한이 있습니다.
유료 서드파티 API 호출이 추적됩니다.
재시도 제한(Retry limits)이 강제됩니다.
예산 초과 실패 시 사용자에게 유용한 메시지를 반환합니다.

보안 제어 (Security controls)

가능한 경우 OAuth 또는 수명이 짧은 토큰(Short-lived tokens)을 사용합니다.
테넌트 경계(Tenant boundaries)가 모델 외부에서 강제됩니다.
고위험 작업은 승인이 필요합니다.
개인정보(PII) 내보내기가 차단되거나 검토됩니다.
도구 호출(Tool calls)에 속도 제한(Rate-limited)이 적용됩니다.
로그(Logs)에 가공되지 않은 비밀 정보나 민감한 프롬프트(Prompts)가 저장되지 않도록 합니다.

관찰 가능성 제어 (Observability controls)

모든 도구 호출(Tool call)에 추적 ID(Trace ID)가 부여됩니다.
로그(Logs)에 테넌트, 사용자, 워크플로우, 도구, 결정 사항 및 비용이 포함됩니다.
차단된 작업이 추적됩니다.
사람의 승인(Human approvals) 내역이 로그에 기록됩니다.
대시보드(Dashboards)에 테넌트 및 워크플로우별 비용이 표시됩니다.
비정상적인 도구 호출 급증 시 알림(Alerts)이 발생합니다.

예시: 고객 지원 분류 에이전트(Support triage agent) 예산 책정

SaaS 고객 지원 데스크(Helpdesk) 제품을 운영한다고 가정해 봅시다. 티켓을 읽고, 문서를 검색하며, 고객 이력을 요약하고, 답장 초안을 작성할 수 있는 AI 에이전트(Agent)가 필요합니다.

에이전트에게 모든 내부 도구를 다 주지 마세요.

다음 정책으로 시작하십시오:

{
  "workflow": "support_ticket_triage",
  "allowed_tools": [
...

이러한 설정은 에이전트가 검토 없이 심각한 변경을 수행하지 못하게 하면서도, 도움을 줄 수 있는 충분한 권한을 부여합니다.

이제 테넌트 예산(tenant budget)을 추가합니다:

{
  "tenant_id": "acme_support",
  "plan": "growth",
...

이것이 데모와 프로덕션(production) 시스템의 차이입니다.

출시 후 추적해야 할 사항

첫 번째 예산은 틀릴 것입니다. 이는 정상입니다.

다음 지표들을 매주 추적하십시오:

지표	중요성
요청당 평균 로드된 도구 수	컨텍스트 비대화 (context bloat)를 나타냄
...

가장 유용한 지표는 모델 호출당 비용이 아니라, 종종 **성공적인 작업당 비용 (cost per successful task)**입니다.

최종 구현 패턴

이 글에서 단 하나의 패턴만 가져간다면, 다음을 사용하십시오:

의도 분류 (Classify intent) → 워크플로우 도구만 로드 (load only workflow tools) → 테넌트 예산 강제 (enforce tenant budget) → 위험한 작업에 대한 승인 요구 (require approval for risky actions) → 모든 결정 로그 기록 (log every decision)

이 패턴은 AI SaaS 에이전트가 무제한적인 API 호출자가 되지 않도록 하면서도 유용성을 유지하게 해줍니다.

FAQ

MCP 도구 예산(MCP tool budget)이란 무엇인가요?

MCP 도구 예산은 AI 에이전트가 어떤 도구를 보고 호출할 수 있는지, 각 워크플로우에 비용이 얼마나 들 수 있는지, 호출 횟수는 얼마나 허용되는지, 그리고 어떤 작업에 승인이 필요한지를 제한하는 정책 계층(policy layer)입니다.

AI SaaS 제품에 MCP 도구 예산이 왜 필요한가요?

AI SaaS 제품에 도구 예산이 필요한 이유는 에이전트가 실제 API 호출, 유료 서비스, 데이터베이스 읽기, 쓰기 작업 및 긴 워크플로우를 트리거할 수 있기 때문입니다. 제한이 없다면 비용과 리스크가 빠르게 증가할 수 있습니다.

MCP 도구 예산은 토큰 비용에 관한 것뿐인가요?

아니요. 토큰 비용은 일부일 뿐입니다. 완전한 예산은 도구 개수, 제3자 API 비용, 테넌트 지출, 실행 시간 (runtime), 재시도 (retries), 리스크 등급 (risk tiers), 승인 규칙 및 감사 로그 (audit logs)를 모두 포함합니다.

에이전트는 한 번에 얼마나 많은 MCP 도구를 봐야 하나요?

보편적인 숫자는 없지만, 적을수록 일반적으로 더 좋습니다. 사용 가능한 모든 도구를 노출하는 대신 워크플로우별로 도구를 로드하십시오. 작업에 도구 3개가 필요하다면, 컨텍스트에 50개의 도구 설명을 넣지 마십시오.

쓰기 작업(write actions)은 사람의 승인을 요구해야 하나요?

고위험 쓰기 작업(High-risk write actions)은 대개 승인이 필요합니다. 이메일 전송, 데이터 삭제, 환불 처리, 개인정보(PII) 내보내기, 결제 정보 변경 또는 셸 명령(shell commands) 실행 등은 반드시 확인 절차를 거치거나, 범위를 엄격히 제한하거나, 기본적으로 비활성화되어 있어야 합니다.

멀티테넌트(multi-tenant) SaaS 앱에서 MCP 도구 비용을 어떻게 추적하나요?

모든 도구 호출(tool call)에 대해 테넌트 ID(tenant ID), 사용자 ID(user ID), 워크플로우(workflow), 도구 이름, 예상 비용, 실행 시간(runtime), 출력 크기 및 결정 상태를 기록하는 사용 내역 원장(usage ledger)을 만드십시오. 그런 다음 해당 데이터를 테넌트 및 워크플로우별로 집계하십시오.

프롬프트(prompts)로 도구 예산을 안전하게 강제할 수 있나요?

프롬프트는 동작을 안내할 수는 있지만, 강제 계층(enforcement layer)이 되어서는 안 됩니다. 예산 확인, 권한 부여(authorization), 승인 게이트(approval gates) 및 테넌트 제한은 모델 외부의 코드에서 실행되어야 합니다.