Ask GN: MCP 도구를 여러 개 붙여 에이전트를 운영하시는 분들 중 중복 실행 겪어보신분 계실까요? — 에이전트 운영 노하우 정리

Ask GN 원문 요약: 공개 벤치마크 트레이스에서 에이전트의 중복 실행을 측정해봤습니다. 같은 도구를 같은 인자로 두 번 호출하고 결과까지 같은 경우를 세는 방식입니다. 6,780개 트레이스에서 8,042건이 나왔는데, 절반 가까이는 작업 완료 선언 반복 같은 것 빼면 4,249건이었습니다. 그중 상태를 변…

1. MCP 도구 통합의 일상 — 왜 갑자기 '중복 실행'이 문제가 되는가

Ask GN에 올라온 이번 질문은, MCP(Model Context Protocol) 기반 도구를 여러 개 동시에 연결해 운영 중인 개발자들이 흔히 격는 현실적인 운영 이슈를 다룬다. 한두 개 도구를 붙이는 시점까진 별 탈이 없다. 도구가 3~5개로 늘어나고, 그중 일부는 서로 기능이 겹치는 카테고리(파일 검색, 메모리/노트, 코드 검색, 웹 검색)에 들어가면, 같은 의도의 호출이 서로 다른 도구로 동시에 발사되는 현상이 발생한다. 결과적으로 (a) 토큰 비용 중복 (b) 응답 latency 증가 (c) 결정의 비결정성 (A 도구와 B 도구가 다른 답을 줄 때 어떤 걸 믿을지) 세 가지가 누적된다.

이건 도구의 '버그'라기보다 '아키텍처의 경계가 모호해진 상태'다. MCP는 도구와 에이전트 사이의 표준 프로토콜일 뿐, 어느 도구가 우선시돼야 하는지, 같은 카테고리 안에서 호출 순서를 어떻게 결정할지는 명시하지 않는다. 그래서 운영자가 명시적으로 (a) 우선순위 (b) 폴백 (c) 호출 캐시 세 가지 정책을 설계하지 않으면, 도구가 늘어날수록 노이즈가 선형이 아니라 조합적으로 늘어난다.

2. 실제로 가장 자주 겪는 중복 실행 패턴 4가지

GN 답변과 코멘트에서 반복적으로 등장한 패턴을 정리하면 다음과 같다:

• 패턴 1: 같은 카테고리 도구 동시 호출 (예: filesystem MCP + memory MCP가 둘 다 '메모 검색' 후보) — LLM이 함수 시그니처만 보고 둘 다 호출한 뒤 결과를 합친다. 사용자 입장에서는 '왜 두 번이나 물어봤지?'가 된다. 해결: 도구 description에 '이미 같은 카테고리 도구가 있을 때 호출 생략' 힌트를 박거나, 운영자가 명시적으로 우선순위 dict를 주입한다.
• 패턴 2: 호출 결과 캐시 미스 (같은 URL/같은 파일을 1초 안에 두 번 크롤링) — 웹 검색 도구와 fetch MCP가 동시에 같은 URL을 가져온다. 해결: 래퍼 레벨에서 짧은 TTL(예: 60초) in-memory cache를 두고, 동일 입력이면 두 번째 호출을 dedupe한다.
• 패턴 3: 도구 간 CROSS-Ref 때문에 한쪽 결과가 다른 쪽을 깨뜨림 — 예를 들어 '코드 검색' MCP가 '파일 검색' MCP의 출력 포맷을 의존하는데, 한쪽이 버전업돼 스키마가 바뀌면 둘 다 깨진다. 해결: 도구간 의존 그래프를 별도 YAML로 관리하고, 변경 시 일괄 점검.
• 패턴 4: LLM이 '혹시 모르니까' 호출 (안전 마진) — LLM이 확신이 없을 때 대비용으로 같은 도구를 다른 파라미터로 두 번 부른다. 해결: 도구 description에 '중복 호출 비권장' 명시 + temperature 0 + 시스템 프롬프트에 '동일 의도 도구 1회만 호출' 규칙.

3. 운영자가 명시적으로 정해야 할 세 가지 정책

MCP 도구가 늘어나도 노이즈가 선형으로만 증가하도록 만들려면, 운영자가 다음 세 가지를 사전에 결정해야 한다:

• 우선순위 매트릭스 (Priority Matrix) — 카테고리별로 '1순위 / 2순위 / 폴백' 도구를 명시한다. LLM은 1순위가 실패하거나 결과가 비었을 때만 하위로 내려간다. 운영자가 권위 있는 사양으로 유지보수한다.
• 호출 TTL 캐시 (Short-Lived Cache) — 동일 입력(URL/path/query)에 대해 30~90초 TTL을 두고 결과를 캐시한다. 캐시 키는 (tool_name, args_hash). 이걸로 패턴 2의 1초 내 중복 호출을 대부분 잡을 수 있다.
• 의존성 맵 (Dependency Graph) — 도구 A가 도구 B의 출력 포맷에 의존한다면, A 호출 직전에 B의 응답 포맷을 정규화하는 어댑터를 둔다. 도구 B가 업데이트돼도 어댑터만 수정하면 된다.

4. 실전 예시 — 우선순위 매트릭스 코드 한 조각

아래는 카테고리별 우선순위 + 폴백을 단일 dict로 관리하는 최소 구현이다. 운영자는 config 파일 하나만 수정하면 도구 추가/교체 시 MCP 통합을 다시 디자인할 필요가 없다.

from typing import Any, Callable, Awaitable

from dataclasses import dataclass, field

@dataclass
class ToolPriority:
"""카테고리별 우선순위 + 폴백 체인."""
primary: Callable[..., Awaitable[Any]]
fallback: list[Callable[..., Awaitable[Any]]] = field(default_factory=list)
cache_ttl_sec: int = 60

class MCPRouter:
def __init__(self, matrix: dict[str, ToolPriority]):
self.matrix = matrix
self._cache: dict[tuple, tuple[float, Any]] = {}

async def dispatch(self, category: str, query: str) -> Any:
prio = self.matrix.get(category)
if not prio:
raise ValueError(f"no tool for category: {category}")
1) cache hit
key = (category, query)
now = time.time()
if key in self._cache and now - self._cache[key][0] < prio.cache_ttl_sec:
return self._cache[key][1]
2) primary
try:
result = await prio.primary(query)
except Exception as e:
3) fallback chain
for fb in prio.fallback:
try:
result = await fb(query)
break
except Exception:
continue
else:
raise RuntimeError(f"all tools failed for {category}") from e
self._cache[key] = (now, result)
return result

핵심은 (a) primary가 실패하면 fallback 리스트를 순서대로 시도 (b) TTL cache_ttl_sec 동안 같은 입력은 캐시 결과를 재사용 (c) 새 카테고리 도구가 추가되면 matrix dict에 한 줄 추가만 하면 된다. LLM은 이 라우터의 인터페이스만 알고, 실제 어떤 MCP 서버가 선택될지는 운영자가 결정한다.

5. 결론 — 도구가 늘어날 때 흔들리지 않는 운영 패턴

MCP 도구 통합은 '많을수록 좋다'가 아니라 '명확한 경계가 있는 만큼 좋다'가 옳다. Ask GN에서 여러 개발자가 합의한 운영 원칙은 다음과 같이 요약된다:

• 카테고리당 1순위 + 1폴백으로 시작하고, 같은 카테고리에 3개 이상 붙이지 않는다.
• 도구 description에 '중복 호출 비권장', '같은 의도일 때 단독 호출' 같은 운영 힌트를 박는다.
• 60~90초 TTL의 짧은 캐시로 패턴 2(같은 입력 반복)를 차단한다.
• 도구별 의존성은 YAML/코드 한 곳에 명시적으로 적어둔다. 도구가 업데이트될 때 어댑터만 패치.
• 온콜 운영 시 '도구 호출 trace'를 남겨서, 어떤 시점에 어떤 도구가 중복 발사됐는지 회귀 분석할 수 있게 한다.

이 패턴들은 MCP뿐 아니라 OpenAI function calling, Anthropic tool use, LangChain Tools 전반에 동일하게 적용된다. 도구가 늘어난다고 매번 에이전트 코드를 다시 짤 필요 없이, 라우터 한 곳에서 도구 우선순위와 캐시 정책만 조정하면 된다.

한 줄 요약: MCP 도구 통합의 안정성은 '도구 개수'가 아니라 '우선순위 + 캐시 + 의존성' 세 가지 정책을 얼마나 명시적으로 운영하느냐에서 결정된다.

---

📰 원본 출처 · https://news.hada.io/topic?id=31946 (#N=31946)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.