---
title: "사례 연구: 어느 AI 지원 에이전트의 도구 부담을 약 90% 줄이다 — onemcp"
description: "어느 예시적 지원 팀의 AI 에이전트는 컨텍스트의 대부분을 MCP 도구 정의에 소진하고 있었다. onemcp의 Code Mode를 통해 도구를 다루자 요청당 부담이 약 90% 줄고 응답이 더 빠르고 저렴해졌다."
ogTitle: "사례 연구: 토큰 다이어트 중인 AI 지원 에이전트"
ogDescription: "어느 지원 자동화가 onemcp의 Code Mode로 요청당 도구 부담을 약 90% 줄인 방법 — 더 빠르고, 더 저렴하고, 더 안정적으로."
url: "https://onemcp.dev/ko/case-studies/support-agent-token-diet"
eyebrow: "사례 연구 · 고객 지원 자동화"
headline: "그 지원 에이전트는 티켓보다 도구 정의에 더 많은 컨텍스트를 소진하고 있었다."
summary: "어느 지원 팀의 AI 에이전트는 십수 개의 MCP 서버에 연결되어 모든 프롬프트를 도구 스키마로 뒤덮었다. onemcp의 Code Mode로 옮기자 컨텍스트는 다시 고객의 문제로 향했고, 응답당 비용과 지연도 함께 낮아졌다."
industry: "SaaS 고객 지원"
teamSize: "약 15명 규모의 지원 조직"
stack: "Zendesk · Stripe · Postgres · 사내 주문 API · Slack"
illustrative: "본 글은 일반적인 onemcp 배포에 기반한 예시적 시나리오이다. 등장하는 팀은 복합적으로 구성한 가상의 사례이며 실재하는 고객이 아니다. 수치는 실측값이 아니라 대표적인 참고치이다."
results:
  - "요청당 도구 부담 약 90% 절감"
  - "호출당 도구 스키마가 약 15,000 토큰에서 약 500 토큰으로"
  - "모든 응답에서 비용과 지연이 감소"
quote: "전환한 그날부터 에이전트는 더 빨라지고 저렴해졌습니다. 그런데 우리는 도구를 하나도 없애지 않았습니다. 다만 그 모두를 매 메시지마다 지고 다니는 일을 그만두었을 뿐입니다."
quoteAttribution: "지원 운영 책임자(예시)"
---

## 배경

어느 SaaS 지원 팀은 티켓을 분류하고 답변하는 AI 에이전트를 구축했다. 실제로 일하려면 넓은 도달 범위가 필요했다. 티켓에는 Zendesk, 결제에는 Stripe, 계정 상태에는 Postgres와 사내 주문 API, 에스컬레이션에는 Slack. 이들은 모두 MCP 서버였고, 에이전트에 직접 연결되어 있었다.

에이전트는 첫날부터 유용했다. 동시에 무언가 온전히 설명하기 어려운 방식으로 느리고 비쌌다 — 각 프롬프트에 실제로 무엇이 담기는지 살펴보기 전까지는.

## 과제

에이전트가 연결한 각 MCP 서버는 요청마다 **도구 스키마 전체**를 컨텍스트에 주입했다. 십수 개의 서버가 연결된 상태에서, 그것은 수백 개의 도구·매개변수 정의가 — 그 티켓이 그것들을 필요로 하든 아니든 — 모든 티켓에 딸려 온다는 뜻이었다.

그 대가는 세 가지 형태로 나타났다.

- **컨텍스트의 낭비.** 고객의 실제 물음에 앞서, 약 15,000 토큰의 도구 상용구가 모든 프롬프트의 서두를 차지했다. 긴 스레드에서는 정의가 대화 자체를 밀어냈다.
- **더 높은 비용과 지연.** 이 입력 토큰은 매 턴마다 청구·처리되었고, 주당 수천 건의 티켓으로 곱해졌다.
- **더 넓은 오류의 여지.** 더 크고 어수선한 프롬프트는 모델이 잘못된 도구를 고르거나 여러 단계의 티켓에서 갈피를 잃을 여지를 넓혔다.

## 접근

팀은 에이전트의 모든 서버를 단일 onemcp **포털** 뒤에 두고, 에이전트가 **Code Mode**를 통해 통신하도록 전환했다.

포털은 모든 정의를 미리 적재하는 대신 세 개의 메타 도구만 노출한다.

- `search` — 눈앞의 티켓과 관련된 도구를 찾는다.
- `describe` — 그 도구들의 정확한 시그니처를 필요할 때 가져온다.
- `execute` — 그것들을 호출하는 짧은 스크립트를 한 번의 왕복으로 실행한다.

이로써 환불 티켓은 필요한 Stripe와 주문 도구만 적재하고 그 밖에는 적재하지 않는다. 전체 카탈로그는 여전히 사용할 수 있으며, 단지 매 프롬프트로 끌려 들어오지 않을 뿐이다.

## 성과

- **요청당 도구 부담 약 90% 절감.** 호출당 도구 스키마는 약 15,000 토큰에서 약 500 토큰으로 낮아졌다. 이 절감은 모든 티켓의 매 턴에서 되풀이된다.
- **더 저렴하고 빠른 응답.** 호출당 입력 토큰이 줄어 청구액은 낮아지고 첫 응답은 빨라졌으며, 에이전트의 도달 범위는 조금도 줄지 않았다.
- **더 안정적인 다단계 처리.** 컨텍스트가 도구함이 아니라 티켓을 향하자, 에이전트는 환불, 계정 조회, 에스컬레이션 전 과정에서 갈피를 유지했다.

> 전환한 그날부터 에이전트는 더 빨라지고 저렴해졌습니다. 그런데 우리는 도구를 하나도 없애지 않았습니다. 다만 그 모두를 매 메시지마다 지고 다니는 일을 그만두었을 뿐입니다.

## 관련 사례 연구

- [어느 플랫폼 팀이 20개의 MCP 서버를 단일 엔드포인트 뒤에 통합하다](/ko/case-studies/platform-team-mcp-gateway)
- [자격 증명을 흘리지 않고 셀프서비스 데이터 에이전트를 구현하기](/ko/case-studies/data-team-secure-agents)