AI SDK + MCP: 프로덕션 에이전트 시스템을 위한 실전 통합 가이드

2026년 4월 7일Lin Ivan

핵심 요점

AI SDK + MCP 통합은 단순히 "연결하고 호출"하는 일이 아닙니다. 핵심은 범위 제한, 전송 방식, 재시도, 인증, 관측 가능성입니다.
가장 안전한 출발점은 좁은 discovery, 명시적인 tool allowlist, 그리고 요청별 명확한 실행 예산입니다.
MCP는 discovery와 invocation 경계를 더 깔끔하게 만들지만, 어떤 workflow에 어떤 tool을 노출할지는 여전히 애플리케이션 책임입니다.
프로덕션 에이전트 시스템은 timeout, fallback, logging을 사고 후가 아니라 사전에 설계해야 합니다.
puppyone은 같은 workflow 안에서 governed context와 MCP 도구를 함께 다뤄야 할 때 특히 유용합니다.

왜 데모에서는 쉬워 보이고 운영에서는 어려워지는가

데모의 흐름은 늘 비슷합니다.

AI SDK를 MCP 서버에 연결한다
몇 개의 도구를 노출한다
모델이 도구를 호출하게 한다

프로토타입으로는 괜찮습니다. 하지만 아직 프로덕션 통합은 아닙니다.

프로덕션에서 늘어나는 것은 코드보다 운영상의 결정입니다.

이 에이전트는 어떤 도구를 볼 수 있는가?
이 환경에서 어떤 transport가 적절한가?
인증과 자격 증명 회전은 어떻게 할 것인가?
MCP 서버가 느릴 때 어떻게 할 것인가?
도구 호출이 실패하면 fallback은 무엇인가?
어떤 호출은 사람 승인 대상인가?
문제가 생긴 뒤 실행을 어떻게 설명할 것인가?

최소한으로 필요한 아키텍처

user request
  -> 앱 내부 agent runtime
  -> workflow별 tool policy
  -> MCP client
  -> 하나 이상의 MCP server
  -> 외부 시스템 또는 governed context
  -> 결과 조합
  -> logs, approvals, traces

많은 팀이 빠뜨리는 줄은 tool policy입니다.

discovery는 프로토콜 기능이고, exposure는 제품 결정입니다.

정말 중요한 다섯 가지 결정

1. Discovery는 permission이 아니다

SDK가 20개의 도구를 찾을 수 있다고 해서 그 workflow가 20개를 모두 봐야 하는 것은 아닙니다.

Discovery는 상한 집합으로, runtime allowlist는 실제 실행 경계로 다뤄야 합니다.

2. Transport는 신뢰성 결정이다

현재 AI SDK 문서는 프로덕션에는 HTTP transport를, 로컬 서버에는 stdio를 권장합니다. 이는 방화벽, 재시도, 프록시, 운영 ownership에 직접 영향을 줍니다.

좋은 규칙은 단순합니다.

환경이 안정적으로 운영할 수 있는 가장 단순한 transport를 쓴다
재시도 횟수를 제한한다
timeout 동작을 명시한다

3. Tool 설명은 모델 행동을 바꾼다

설명이 모호하면 사용 방식도 모호해집니다. 겹치는 도구가 많으면 모델은 문제 해결보다 선택에 토큰을 씁니다.

신중한 운영자처럼 설명해야 합니다.

무엇을 하는가
무엇을 하지 않는가
언제 호출해야 하는가
어떤 입력이 필요한가
실패는 어떻게 보이는가

4. 모든 tool call에는 예산이 필요하다

모델이 다음을 마음대로 하게 두면 안 됩니다.

두 개면 될 일을 열 개 호출하기
끝없이 재시도하기
거대한 payload를 prompt로 가져오기
읽기 도구와 쓰기 도구를 무분별하게 섞기

5. 로그는 기능의 일부다

"모델이 잘못 판단했다"만으로는 충분하지 않습니다. 최소한 다음이 필요합니다.

request ID
노출된 도구 목록
실제 선택된 도구
전달된 인자
지연과 실패
필요한 경우 승인 상태

많은 실수를 줄여주는 표

선택	팀이 좋아하는 이유	어디서 깨지는가
발견된 도구를 모두 로드	프로토타입이 빠름	프로덕션에는 너무 넓음
명시적으로 schema와 bundle 정의	더 강한 제어와 리뷰	유지 비용 증가

실무 규칙은 이렇습니다.