<div id="readability-page-1" class="page"><div>
  
  
  <p><span>2025년 07월 01일 작성</span></p><h2 id="tldr">TL;DR</h2>

<ul>
  <li>에이전트에 MCP 서버를 붙이면 MSA 가 된다.</li>
  <li>결국 MCP도 모놀리스→MSA 전환과 똑같이 조직·플랫폼·운영을 함께 성숙시켜야 한다.</li>
  <li>MCP 에서 제공하는 툴은 에이전트에 컨텍스트로 전달된다.</li>
  <li>결국 MCP 를 몇 개 붙일지가 아니라, MCP 가 제공하는 툴 개수가 중요하다.</li>
</ul>

<h2 id="시작하며">시작하며</h2>

<p>최근에 MCP 기반으로 챗봇을 만들어보는 프로젝트를 하게 되었다.</p>

<p>그런데 막상 프로덕션에 올려보니 고려해야할 내용이 꽤 많았다.</p>

<p>개인적인 경험을 토대로 MCP 서버를 이용한 에이전트를 개발할 때 고려할 점  몇 개를 정리해본다.</p>

<h2 id="중요한-포인트">중요한 포인트</h2>

<p>가장 중요한 포인트 2개만 짚으라면 아래 두 가지이다.</p>

<ol>
  <li>옵저버빌리티</li>
  <li>컨텍스트 관리</li>
</ol>

<h2 id="1-리모트-mcp-서버-도입은-msa-도입과-같다">1. 리모트 MCP 서버 도입은 MSA 도입과 같다</h2>

<p>기존에 툴을 사용해서 에이전트를 개발할 때는 모든 로그가 한 서버에 모여있어서 디버깅이 쉬웠다.</p>

<p>MCP 를 stdio 로 사용하는 것은 해당이 없지만 보통 이런식으로 사용하는 일은 개인 사용이나, 디버깅용 외에는 드물다.
오히려 streamable http 방식으로 리모트 MCP 서버를 연결하는 것이 일반적일 것이다.</p>

<p>하지만 이렇게 리모트 MCP 서버를 이용하면 로그가 여러 서버로 분산되기 때문에 디버깅이 어려워진다. 그리고 그 서버를 다른 팀에서 관리하고 있다면 더더욱 디버깅이 어려워진다.</p>

<p>결국 리모트 MCP 서버를 도입하는 것은 여러가지 측면에서 MSA 를 도입하는 것과 같았고, 이런 환경에서 옵저버빌리티(로그·메트릭·트레이스) 없으면 디버깅이 어려운 블랙박스가 된다.</p>

<p>따라서 MSA 수준의 개발/운영 경험이 없다면 기존 툴 방식과의 장단점을 더욱 신중하게 고려해서 MCP 서버 방식을 도입해야 한다.</p>

<table>
  <thead>
    <tr>
      <th>단계</th>
      <th>해야 할 일</th>
      <th>내가 쓰고 있는 스택</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>① 로그</strong></td>
      <td>구조화된 JSON 로그, <code>trace_id</code> 반드시 포함</td>
      <td>Fluent Bit → Loki / CloudWatch Logs</td>
    </tr>
    <tr>
      <td><strong>② 메트릭</strong></td>
      <td>툴 호출 TPS·지연시간·오류율·토큰 사용량</td>
      <td>Prometheus + Grafana</td>
    </tr>
    <tr>
      <td><strong>③ 트레이싱</strong></td>
      <td>OpenTelemetry로 LLM → Agent → 툴 전구간 추적</td>
      <td>Jaeger, 1% 샘플링부터 시작</td>
    </tr>
    <tr>
      <td><strong>④ 서비스 맵</strong></td>
      <td>의존성 자동 시각화</td>
      <td>Jaeger Service Dependencies</td>
    </tr>
    <tr>
      <td><strong>⑤ 알람</strong></td>
      <td>95-퍼센타일 지연 &gt; X ms, 오류율 &gt; Y%</td>
      <td>PagerDuty → Slack</td>
    </tr>
    <tr>
      <td><strong>⑥ 헬스체크</strong></td>
      <td>각 툴마다 <code>/healthz</code> 엔드포인트</td>
      <td>서비스 메시 Liveness probe</td>
    </tr>
    <tr>
      <td><strong>⑦ 환경분리</strong></td>
      <td>프로덕션 토큰 등 민감정보 스테이징 격리</td>
      <td>Terraform으로 환경 분리</td>
    </tr>
  </tbody>
</table>

<h3 id="실무에서-도움된-팁">실무에서 도움된 팁</h3>

<ul>
  <li>OpenTelemetry 트레이스를 통해 툴 호출 전구간을 추적할 수 있다. (대부분의 LLM 추적 도구들은 OpenTelemetry 를 기본으로 지원하는 추세이다.)</li>
  <li>Trace ID 연동하면 로그 ↔ 트레이스 UI 이동이 한 클릭으로 가능하다.</li>
  <li>Token Usage를 <code>input_tokens</code>, <code>output_tokens</code> 별도 그래프로 만들어두면 비용 최적화할 때 유용하다.</li>
  <li>실패한 Trace payload 저장해서 재현 테스트에 활용할 수 있다.</li>
</ul>

<p>개인적으로는 Arize Phoenix 를 옵저버빌리티에 사용하고 있다.</p>

<h2 id="2-mcp-와-툴은-컨텍스트">2. MCP 와 툴은 컨텍스트</h2>

<p>에이전트에 툴을 쓰든 MCP 서버를 붙이든 결국 LLM 이 호출된다는 사실에는 변함이 없다.</p>

<p>그리고 툴이나 MCP 가 API 상에 필드를 별도로 입력받는다고 해서 LLM 이 뭔가 추가적인 기능을 갖는 것은 아니다.</p>

<p>LLM 은 결국 텍스트를 입력받고 텍스트를 출력하는 기계이다. 해당 입출력 텍스트를 우리는 컨텍스트라고 부른다.</p>

<p>따라서 내가 클라이언트에서 어떤 방식으로 툴을 입력을 하든(하드코딩된 프롬프트, MCP, API 의 JSON 필드), 결국 컨텍스트 형태로 LLM 에게 전달되어 실행되기 때문에 컨텍스트 관점에서 툴을 봐야 한다.</p>

<h3 id="툴이-늘어나면-생기는-문제들">툴이 늘어나면 생기는 문제들</h3>

<p>우리는 LLM 의 입력 컨텍스트가 커질수록 정확도가 떨어지고 레이턴시가 증가하며, 비용이 커진다는 것을 알고 있다.</p>

<p>툴도 마찬가지로 툴 개수가 많아질수록 비용이 증가하고 지연시간이 증가한다. 특히 툴 개수가 많아질수록 툴 선택 정확도가 떨어진다.</p>

<p>아래는 이를 툴 관점에서 실험한 결과이다. (GPT-4o-32k, 함수 호출 모드, 동일 질의 1,000회 평균)</p>

<table>
  <thead>
    <tr>
      <th>툴 개수</th>
      <th>툴 설명 토큰</th>
      <th>1회 호출시 추가 토큰</th>
      <th>응답 지연</th>
      <th>툴 선택 정확도</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>2개</td>
      <td>120개</td>
      <td>+240개</td>
      <td>+80ms</td>
      <td>98%</td>
    </tr>
    <tr>
      <td>6개</td>
      <td>110개</td>
      <td>+660개</td>
      <td>+320ms</td>
      <td>92%</td>
    </tr>
    <tr>
      <td>15개</td>
      <td>105개</td>
      <td>+1,575개</td>
      <td>+900ms</td>
      <td>78%</td>
    </tr>
    <tr>
      <td>30개</td>
      <td>95개</td>
      <td>+2,850개</td>
      <td>+1,800ms</td>
      <td>63%</td>
    </tr>
  </tbody>
</table>

<p>보다시피 툴이 늘어날수록 선형이 아니라 <strong>계단식으로</strong> 비용·지연이 상승한다. 모델도 유사한 툴들 간에 혼동을 많이 한다.</p>

<p>특히 여러 MCP 서버가 서로 다른 조직에서 작성되고 관리되는 경우, 툴의 설명을 통일감있게 작성하는 것이 매우 중요한데, 툴 설명에 사용되는 단어가 서로 다른 의미로 사용하거나, 설명이 겹치거나, 모호하게 작성된 경우 정확도가 더욱 내려간다.</p>

<p>LLM 프로바이더에 따라 최대 128개 툴을 등록할 수는 있지만, <strong>실제로는 10개 이상부터 성능 저하가 발생</strong>한다.</p>

<p>MCP 서버 하나당 보통 3~4개 툴을 제공하니까, <strong>최대 3개 MCP 서버 정도가 적당</strong>하다.</p>

<h3 id="툴-다이어트-전략">툴 다이어트 전략</h3>

<p>해당 내용을 상세히 적으려면 엄청 길게 적을 수도 있고, 짧게 적으려면 아래와 같이 짧게 적을 수도 있다.</p>

<p>대부분 직관적인 내용들이라 짧게 적어본다. 중요한 것은 MCP 가 제공하는 툴의 개수와 범위(bounded context)를 적절한 크기로 유지하는 것이다.</p>

<ul>
  <li><strong>탑다운 방식</strong>으로 툴 경계를 잡는 게 바텀업보다 훨씬 좋다.</li>
  <li><strong>툴은 API가 아니다.</strong> 더 적은 툴로 더 많은 작업을 할 수 있게 설계하자.</li>
  <li>파라미터가 너무 커지면 차라리 <strong>코드로 직접 쿼리</strong>하는 게 나을 수도 있다. (python repl, sql, graphql 등)</li>
</ul>

<h3 id="토큰비용-폭증-완화-전략">토큰·비용 폭증 완화 전략</h3>

<p>아래 내용은 에이전트 기반 어플리케이션에서 사용하는 일반적인 내용이지만, MCP 에서도 동일하므로 적어본다.</p>

<ol>
  <li><strong>동적 툴 필터링</strong>
    <ul>
      <li>라우터 모델이나 룰 기반으로 현재 질의에 필요한 툴만 프롬프트에 포함</li>
    </ul>
  </li>
  <li><strong>툴 메타데이터 다이어트</strong>
    <ul>
      <li>설명·파라미터 문구 축약, 예시 JSON 최소화</li>
    </ul>
  </li>
  <li><strong>대화 컨덴싱</strong>
    <ul>
      <li>오래된 대화 → 요약문으로 교체, Retrieval만 사용</li>
    </ul>
  </li>
  <li><strong>캐싱 적극 활용</strong>
    <ul>
      <li>Semantic/프롬프트 툴 캐시로 동일 질의·툴 결과 재사용</li>
    </ul>
  </li>
  <li><strong>가드레일 설정</strong>
    <ul>
      <li><code>max_tool_calls</code> 설정으로 무한 루프 방지</li>
      <li>검색 툴, 결제 툴 등은 전용 에이전트로 분리해서 필요시에만 마운트</li>
    </ul>
  </li>
</ol>

<h2 id="poc--프로덕션-체크리스트">PoC → 프로덕션 체크리스트</h2>

<ul>
  <li><strong>옵저버빌리티 스택 완성</strong> (로그·메트릭·트레이스 대시보드 &amp; 알람)</li>
  <li><strong>캐시 시스템 도입</strong> (툴 캐시, 프롬프트 캐시)</li>
  <li><strong>툴 필터 라우터</strong> 적용, 프롬프트 토큰 &lt; N k 제한</li>
  <li><strong>각 툴 TPS 제한</strong> 레이트 리밋·서킷 브레이커 설정</li>
  <li><strong>월간 토큰 예산 알람</strong> (비용 5% 초과시 Slack 경보)</li>
  <li><strong>롤백 플랜</strong> (새 툴 배포 실패시 자동 언마운트)</li>
  <li><strong>보안 게이트</strong> (툴 등록 PR → LLM 세이프가드 체크 후 병합)</li>
  <li><strong>부하 테스트</strong> (예상 피크 TPS × 2배 트래픽)</li>
  <li><strong>DR/HA 전략</strong> (MCP 서버 및 툴 컨테이너 멀티 AZ 배치, RTO ≤ 15분)</li>
</ul>

<h2 id="마치며">마치며</h2>

<p>MCP는 LLM의 USB 포트 라는 말 처럼, 다양한 툴을 연결할 수 있다는 점에서 매력적이다. 그리고 진짜 물리적인 USB 포트수에 한계가 있는 것처럼, LLM 에 MCP 를 연결할 수 있는 물리적인 한계도 존재한다.</p>

<p>이러한 포트 수는 결국 LLM 이 처리할 수 있는 유효 컨텍스트 크기이며, 컨텍스트 증가에 따른 정확도 문제가 같이 개선되지 않으면, 컨텍스트 크기가 커지고 가격만 내려간다고 해서 포트 수가 늘어나지는 않을 것이다.</p>

<p>따라서 단일 에이전트가 여러 MCP 를 통해서 여러가지 일을 한다는 전략은 대부분의 경우 유효하지 않을 가능성이 높다.</p>

<p>앞으로는 도메인 별 멀티에이전트가 해당 도메인에 맞는 툴을 사용하는 것이 정답이 될 가능성이 높으며, 이러한 경우 옵저버빌리티의 중요성이 더욱 증가할 것이다.</p>

</div></div>

Haandol

TL;DR
에이전트에 MCP 서버를 붙이면 MSA 가 된다.
결국 MCP도 모놀리스→MSA 전환과 똑같이 조직·플랫폼·운영을 함께 성숙시켜야 한다.
MCP 에서 제공하는 툴은 에이전트에 컨텍스트로 전달된다.
결국 MCP 를 몇 개 붙일지가 아니라, MCP 가 제공하는 툴 개수가 중요하다.
시작하며
최근에 MCP 기반으로 챗봇을 만들어보는 프로젝트를 하게 되었다.
그런데 막상 프로덕션에 올려보니 고려해야할 내용이 꽤 많았다.
개인적인 경험을 토대로 MCP 서버를 이용한 에이전트를 개발할 때 고려할 점  몇 개를 정리해본다.
중요한 포인트
가장 중요한 포인트 2개만 짚으라면 아래 두 가지이다.
옵저버빌리티
컨텍스트 관리
1. 리모트 MCP 서버 도입은 MSA 도입과 같다
기존에 툴을 사용해서 에이전트를 개발할 때는 모든 로그가 한 서버에 모여있어서 디버깅이 쉬웠다.
MCP 를 stdio 로 사용하는 것은 해당이 없지만 보통 이런식으로 사용하는 일은 개인 사용이나, 디버깅용 외에는 드물다.
오히려 streamable http 방식으로 리모트 MCP 서버를 연결하는 것이 일반적일 것이다.
하지만 이렇게 리모트 MCP 서버를 이용하면 로그가 여러 서버로 분산되기 때문에 디버깅이 어려워진다. 그리고 그 서버를 다른 팀에서 관리하고 있다면 더더욱 디버깅이 어려워진다.
결국 리모트 MCP 서버를 도입하는 것은 여러가지 측면에서 MSA 를 도입하는 것과 같았고, 이런 환경에서 옵저버빌리티(로그·메트릭·트레이스) 없으면 디버깅이 어려운 블랙박스가 된다.
따라서 MSA 수준의 개발/운영 경험이 없다면 기존 툴 방식과의 장단점을 더욱 신중하게 고려해서 MCP 서버 방식을 도입해야 한다.
단계
      해야 할 일
      내가 쓰고 있는 스택
    
① 로그
      구조화된 JSON 로그, trace_id 반드시 포함
      Fluent Bit → Loki / CloudWatch Logs
    
② 메트릭
      툴 호출 TPS·지연시간·오류율·토큰 사용량
      Prometheus + Grafana
    
③ 트레이싱
      OpenTelemetry로 LLM → Agent → 툴 전구간 추적
      Jaeger, 1% 샘플링부터 시작
    
④ 서비스 맵
      의존성 자동 시각화
      Jaeger Service Dependencies
    
⑤ 알람
      95-퍼센타일 지연 > X ms, 오류율 > Y%
      PagerDuty → Slack
    
⑥ 헬스체크
      각 툴마다 /healthz 엔드포인트
      서비스 메시 Liveness probe
    
⑦ 환경분리
      프로덕션 토큰 등 민감정보 스테이징 격리
      Terraform으로 환경 분리
    
실무에서 도움된 팁
OpenTelemetry 트레이스를 통해 툴 호출 전구간을 추적할 수 있다. (대부분의 LLM 추적 도구들은 OpenTelemetry 를 기본으로 지원하는 추세이다.)
Trace ID 연동하면 로그 ↔ 트레이스 UI 이동이 한 클릭으로 가능하다.
Token Usage를 input_tokens, output_tokens 별도 그래프로 만들어두면 비용 최적화할 때 유용하다.
실패한 Trace payload 저장해서 재현 테스트에 활용할 수 있다.
개인적으로는 Arize Phoenix 를 옵저버빌리티에 사용하고 있다.
2. MCP 와 툴은 컨텍스트
에이전트에 툴을 쓰든 MCP 서버를 붙이든 결국 LLM 이 호출된다는 사실에는 변함이 없다.
그리고 툴이나 MCP 가 API 상에 필드를 별도로 입력받는다고 해서 LLM 이 뭔가 추가적인 기능을 갖는 것은 아니다.
LLM 은 결국 텍스트를 입력받고 텍스트를 출력하는 기계이다. 해당 입출력 텍스트를 우리는 컨텍스트라고 부른다.
따라서 내가 클라이언트에서 어떤 방식으로 툴을 입력을 하든(하드코딩된 프롬프트, MCP, API 의 JSON 필드), 결국 컨텍스트 형태로 LLM 에게 전달되어 실행되기 때문에 컨텍스트 관점에서 툴을 봐야 한다.
툴이 늘어나면 생기는 문제들
우리는 LLM 의 입력 컨텍스트가 커질수록 정확도가 떨어지고 레이턴시가 증가하며, 비용이 커진다는 것을 알고 있다.
툴도 마찬가지로 툴 개수가 많아질수록 비용이 증가하고 지연시간이 증가한다. 특히 툴 개수가 많아질수록 툴 선택 정확도가 떨어진다.
아래는 이를 툴 관점에서 실험한 결과이다. (GPT-4o-32k, 함수 호출 모드, 동일 질의 1,000회 평균)
툴 개수
      툴 설명 토큰
      1회 호출시 추가 토큰
      응답 지연
      툴 선택 정확도
    
2개
      120개
      +240개
      +80ms
      98%
    
6개
      110개
      +660개
      +320ms
      92%
    
15개
      105개
      +1,575개
      +900ms
      78%
    
30개
      95개
      +2,850개
      +1,800ms
      63%
    
보다시피 툴이 늘어날수록 선형이 아니라 계단식으로 비용·지연이 상승한다. 모델도 유사한 툴들 간에 혼동을 많이 한다.
특히 여러 MCP 서버가 서로 다른 조직에서 작성되고 관리되는 경우, 툴의 설명을 통일감있게 작성하는 것이 매우 중요한데, 툴 설명에 사용되는 단어가 서로 다른 의미로 사용하거나, 설명이 겹치거나, 모호하게 작성된 경우 정확도가 더욱 내려간다.
LLM 프로바이더에 따라 최대 128개 툴을 등록할 수는 있지만, 실제로는 10개 이상부터 성능 저하가 발생한다.
MCP 서버 하나당 보통 3~4개 툴을 제공하니까, 최대 3개 MCP 서버 정도가 적당하다.
툴 다이어트 전략
해당 내용을 상세히 적으려면 엄청 길게 적을 수도 있고, 짧게 적으려면 아래와 같이 짧게 적을 수도 있다.
대부분 직관적인 내용들이라 짧게 적어본다. 중요한 것은 MCP 가 제공하는 툴의 개수와 범위(bounded context)를 적절한 크기로 유지하는 것이다.
탑다운 방식으로 툴 경계를 잡는 게 바텀업보다 훨씬 좋다.
툴은 API가 아니다. 더 적은 툴로 더 많은 작업을 할 수 있게 설계하자.
파라미터가 너무 커지면 차라리 코드로 직접 쿼리하는 게 나을 수도 있다. (python repl, sql, graphql 등)
토큰·비용 폭증 완화 전략
아래 내용은 에이전트 기반 어플리케이션에서 사용하는 일반적인 내용이지만, MCP 에서도 동일하므로 적어본다.
동적 툴 필터링
    
라우터 모델이나 룰 기반으로 현재 질의에 필요한 툴만 프롬프트에 포함
툴 메타데이터 다이어트
    
설명·파라미터 문구 축약, 예시 JSON 최소화
대화 컨덴싱
    
오래된 대화 → 요약문으로 교체, Retrieval만 사용
캐싱 적극 활용
    
Semantic/프롬프트 툴 캐시로 동일 질의·툴 결과 재사용
가드레일 설정
    
max_tool_calls 설정으로 무한 루프 방지
검색 툴, 결제 툴 등은 전용 에이전트로 분리해서 필요시에만 마운트
PoC → 프로덕션 체크리스트
옵저버빌리티 스택 완성 (로그·메트릭·트레이스 대시보드 & 알람)
캐시 시스템 도입 (툴 캐시, 프롬프트 캐시)
툴 필터 라우터 적용, 프롬프트 토큰 < N k 제한
각 툴 TPS 제한 레이트 리밋·서킷 브레이커 설정
월간 토큰 예산 알람 (비용 5% 초과시 Slack 경보)
롤백 플랜 (새 툴 배포 실패시 자동 언마운트)
보안 게이트 (툴 등록 PR → LLM 세이프가드 체크 후 병합)
부하 테스트 (예상 피크 TPS × 2배 트래픽)
DR/HA 전략 (MCP 서버 및 툴 컨테이너 멀티 AZ 배치, RTO ≤ 15분)
마치며
MCP는 LLM의 USB 포트 라는 말 처럼, 다양한 툴을 연결할 수 있다는 점에서 매력적이다. 그리고 진짜 물리적인 USB 포트수에 한계가 있는 것처럼, LLM 에 MCP 를 연결할 수 있는 물리적인 한계도 존재한다.
이러한 포트 수는 결국 LLM 이 처리할 수 있는 유효 컨텍스트 크기이며, 컨텍스트 증가에 따른 정확도 문제가 같이 개선되지 않으면, 컨텍스트 크기가 커지고 가격만 내려간다고 해서 포트 수가 늘어나지는 않을 것이다.
따라서 단일 에이전트가 여러 MCP 를 통해서 여러가지 일을 한다는 전략은 대부분의 경우 유효하지 않을 가능성이 높다.
앞으로는 도메인 별 멀티에이전트가 해당 도메인에 맞는 툴을 사용하는 것이 정답이 될 가능성이 높으며, 이러한 경우 옵저버빌리티의 중요성이 더욱 증가할 것이다.

MCP 서버 프로덕션에 올리기 전에 고려해야 할 것

댓글