제13장 — 프레임워크와 클라우드 통합

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 열세 번째 글입니다. 아무도 원시 프로토콜에서 프로덕션 MCP를 짓지 않으며, 2025~2026의 정직한 질문은 어느 프레임워크에 표준화할지로 바뀌고, 답은 기능보다는 시스템의 나머지가 어느 클라우드에 사는지에 더 의존하는 것으로 드러납니다.

이 장이 존재하는 이유

팀이 인증, 전송, 세션 상태, 오류 재시도, 구조화된 로깅, 그리고 데모와 운영 가능한 서비스를 가르는 열두 가지 자잘한 세부 사항을 배선할 즈음, 「우리는 HTTP 위에서 MCP를 그냥 말할 것이다」로 시작된 것이 자체의 작은 프레임워크 — 보통 이미 존재하는 프레임워크보다 나쁜 것 — 가 되어 있습니다. 엔지니어링 질문은 어느 공개 프레임워크에 표준화할지, 각각이 무엇을 올바르게 하는지, 그리고 그것들이 상태를 보유하는 클라우드 서비스에 어떻게 연결되는지입니다. 이 장은 풍경을 체계적으로 걸어 갑니다. Amazon Bedrock과 함께한 Strands, 상태와 검색을 위해 그것을 둘러싸는 AWS 서비스, Microsoft의 Agent Framework·LangChain·Semantic Kernel을 다른 프로덕션 옵션으로, 그리고 참조 아키텍처가 자리잡은 통합 패턴. 목표는 승자를 등극시키는 것이 아니라 각 프레임워크가 실제로 무엇을 위한 것인지를 기술하는 것입니다.

13.1 Strands Agents와 Amazon Bedrock

Strands는 AWS가 2025년에 출시한 오픈소스 에이전트 프레임워크로, 이제 Amazon Q, AWS Support, AWS Glue 어시스턴트 안에서 돕니다. 프레이밍은 의도적입니다. Strands는 모델 주도이며, 다음에 무엇을 할지 결정하는 루프가 프레임워크가 위에 강요하는 플래너 그래프가 아니라 모델 자신의 도구 호출 루프라는 뜻입니다. 프레임워크의 일은 그 루프를 프로덕션에서 신뢰성 있게 만드는 것입니다 — 도구 호출을 처리하고, 세션 상태를 관리하고, MCP 서버를 MCPClient를 통해 일급 도구 출처로 꽂고, 모든 것을 Bedrock의 호스팅된 모델 카탈로그로 라우팅. 모델 층은 플러그형 — Anthropic API, OpenAI, Ollama, LiteLLM — 이지만 Bedrock이 기본이자 감사 이야기입니다.

다중 에이전트 이야기는 Strands가 프로덕션 평판을 얻는 자리입니다. 세 가지 조합 패턴이 이전 장의 오케스트레이션 모양에 깔끔히 대응합니다. Agents-as-Tools(가장 단순한 모양, 다른 에이전트가 호출할 수 있는 도구로 감싼 에이전트), Swarm(공유 작업 메모리가 있는 P2P), 그리고 Graph(모델이 각 노드를 채우는 결정적 토폴로지). 패턴들은 프로덕션에서 중첩됩니다. 운영적 세금은 관측 가능성에서 지불되며, Strands는 모든 에이전트 호출, 도구 호출, 모델 호출에 대해 OpenTelemetry 스팬을 내보내 그것을 지불합니다. 4단계 조합이 단계별 계측 없이 로그에서 재구성됩니다. Bedrock은 접근 경계 이야기를 더합니다. IAM이 주어진 에이전트가 호출할 수 있는 모델을 통제하고, CloudTrail이 사용을 기록합니다. Bedrock Guardrails가 게이트웨이에서 콘텐츠 필터링을 처리하고, Knowledge Bases가 관리되는 검색을 주며, AgentCore — AWS의 2025 프리미티브 집합 — 가 완전 관리 런타임을 원하는 팀을 위해 메모리, 신원, 런타임 관심사를 형식화합니다.

13.2 상태 층으로서의 AWS

몇 시간을 돌고 어제 일어난 일을 기억하는 에이전트는 프로세스를 넘어 사는 저장소를 필요로 합니다. 프로덕션에 자리잡은 패턴은 런타임 상태(현재 세션, 작업 원장, 진행 중 도구 호출)를 빠른 키 접근을 위해 DynamoDB에, 산출물 상태(생성된 문서, 중간 작업)를 자연스러운 IAM 경계와 무료 버전 관리를 주는 세션 접두사 키 구조와 함께 S3에, 의미적 상태(장기 메모리, 이전 대화)를 벡터 저장소에 — 핫 작업 메모리에는 OpenSearch Service, 콜드 또는 아카이브 메모리에는 새 S3 Vectors에 — 둡니다. S3와 DynamoDB의 2층 분리는 성급한 최적화가 아닙니다. DynamoDB 항목을 400KB 아래로 유지하고, 매 단계 읽기 증폭을 피하며, 각 층이 독립적으로 확장되게 합니다.

상태 층의 선택은 전체 시스템의 실패 모드를 결정합니다. 상태가 프로세스 메모리에만 있는 에이전트는 재시작에 모든 것을 잃습니다. 메모리가 내구성 있지만 인덱스가 동기화되지 않은 에이전트는 더 이상 찾을 수 없는 문서에 대한 참조를 회상합니다. 프로덕션 배포는 이를 별도의 일관성 계약으로 다룹니다. 상태 원자성을 위한 DynamoDB 트랜잭션, 산출물 계약을 위한 S3의 강한 읽기 후 쓰기, 검색이 아직 존재하지 않는 무언가를 가리킬 수 없도록 벡터를 업서트하기 전에 문서를 S3에 게시하는 인덱싱 파이프라인. 보안 경계도 같은 주의를 받을 가치가 있습니다. AWS 자체의 Strands 지침은 최종 사용자 데이터 도구 호출에 대해 런타임 역할을 재사용하기보다 STS를 통한 세션별 자격 증명을 권장합니다 — AgentCore Identity가 이를 자동화합니다 — 파괴적 행동 뒤의 AWS 수준 신원이 공유 에이전트 역할이 아니라 실제 최종 사용자가 되도록. 규제 환경에서는 그것이 유일하게 받아들일 만한 답입니다.

13.3 Microsoft Agent Framework, LangChain, Semantic Kernel

풍경의 Microsoft와 오픈소스 측은 다르게 자리잡았습니다. Microsoft Agent Framework는 2025년 후반에 Semantic Kernel과 AutoGen의 명시적 병합 — SK의 플러그인 모델과 .NET 통합에 AutoGen의 다중 에이전트 패턴과 Python 우선 DX — 으로 도착했습니다. MCP 통합은 MCPStdioTool과 MCPStreamableHTTPTool을 통해 내장되어 있고, Azure AI Foundry가 호스팅된 본거지로 AWS 세계의 Bedrock에 해당합니다. Strands 대비 구별되는 기능은 에이전트 사이의 대화 그래프가 명시적이고 재생 가능한 객체라는 점입니다 — 평가에 엄청나게 중요한데, 실패한 대화를 수정된 프롬프트로 다시 돌리고 턴별로 비교할 수 있기 때문입니다. 비용은 Strands가 부과하는 것보다 더 많은 구조입니다. 성숙한 배포에서는 알맞은 거래, 탐색적 작업에서는 잘못된 거래.

2026년의 LangChain은 2023년의 LangChain과 다른 동물입니다. 원래 체인 추상화는 부차적이 되었습니다. 주된 표면은 오케스트레이션을 위한 LangGraph와 관측 가능성·평가를 위한 LangSmith입니다. 강점은 폭 — 모든 모델, 데이터베이스, 도구가 어댑터를 가진 듯 — 과 LangSmith의 평가 성숙도입니다. 실무자가 정직하게 이름 붙이는 약점은 표면적입니다. 프레임워크의 고수준 추상화는 작업 첫 90%에 훌륭하고, 마지막 10%는 보통 팀이 각 층이 무엇을 하는지 이해할 때까지 층을 벗겨내며 합니다. 이 전환을 계획하는 팀이 추상화에 맞서는 팀보다 더 빨리 출하합니다. Semantic Kernel은 .NET 팀을 위한 프레임워크로 남고, [KernelFunction] 플러그인 모델이 .NET 서비스 호스트에 깔끔히 들어맞습니다. 셋 모두에 걸쳐 떠오른 패턴: 얇은 에이전트, 두꺼운 MCP — 능력은 프로토콜 경계 뒤에 살고, 프레임워크는 얇은 프록시가 되며, 같은 MCP 서버가 AWS의 Strands, Azure의 Microsoft Agent Framework, 그리고 개발자 노트북의 LangChain에서 이식 작업 없이 소비됩니다. 그것이 프로토콜이 가능하게 하도록 설계된 궤도입니다.

13.4 프로덕션 통합 패턴

세 가지 패턴이 2025~2026 참조 아키텍처에 자리잡았습니다. 게이트웨이와 상태 층 패턴은 관리되는 모델 게이트웨이(Bedrock, AI Foundry, LiteLLM)를 모델 층 앞에, 별도의 내구성 있는 상태 층을 뒤에 둡니다. 게이트웨이는 인증, 비율 제한, 콘텐츠 필터링, 감사가 사는 자리이고, 상태 층은 내구성이 사는 자리입니다. 이 패턴이 프로덕션 기본값입니다. 새 배포는 구체적 이유가 없는 한 채택해야 합니다. 게이트웨이를 건너뛰고 모델 제공자를 직접 호출하는 팀은 분기 안에 후회합니다. MCP 서비스 메시 패턴은 MCP 서버를 마이크로서비스로 다루고 mTLS, 재시도, 회로 차단을 처리하는 메시를 통해 노출합니다 — 스케일(서버 10개 초과)이나 네트워크 층 증명을 요구하는 규제 환경에서만 비용이 가치 있습니다. 전체 관리 패턴은 런타임, 메모리, 신원, 도구 레지스트리를 클라우드 관리 에이전트 서비스(Bedrock AgentCore, Azure AI Foundry Agent Service, Vertex AI Agent Builder)에 넘깁니다. 에이전트가 주된 제품이 아닌 내부 자동화와 코파일럿에는 이깁니다. 에이전트가 제품이고 운영 레버가 중요한 팀에는 집니다. 이기지 못한, 부정적 예로 이름 붙일 만한 두 패턴: 모든 것을 LLM 컨텍스트에(메모리가 끊임없이 자라는 시스템 프롬프트인 에이전트), 그리고 프레임워크를 오케스트레이터로(노드 파라미터를 모델이 채우는 경직된 DAG). 둘 다 제9장이 걸은 이유로 프로덕션에서 죽고, 분야가 흡수한 교훈은 프레임워크 구조와 모델 자유 사이의 알맞은 균형이 모델이 더 유능해질수록 모델 쪽으로 더 옮겨 간다는 것입니다.

제13장이 준비하는 것

프레임워크와 클라우드 서비스는 팀이 매번 프로토콜 스택을 다시 쓰지 않고 MCP 기반 에이전트를 출하하게 합니다. 그것들이 그 자체로는 팀에게 알려주지 않는 것은 결과 시스템이 실제로 작동하는가입니다 — 에이전트가 그것이 지어진 작업을 푸는지, 부하 아래 어떻게 행동하는지, 성능 절벽이 어디인지, 그리고 두 경쟁 아키텍처를 정직하게 비교하는 방법. 제14장이 그 질문을 정면으로 다룹니다. MCP-Universe 벤치마크, 벤치마크가 드러낸 두 가지 시스템적 실패 모드(긴 컨텍스트 저하와 미지의 도구 탐색), 그리고 공유 세션 풀과 순진한 세션당 요청 패턴 사이의 격차가 대략 자릿수 하나인 처리량 측면을 걸어 갑니다.

다음 → 제14장: 벤치마킹, 테스트, 성능. 실제 서버 위의 MCP-Universe, 작동하는 긴 컨텍스트와 미지 도구 완화책, 세션당 요청과 공유 세션 풀 사이의 10배 처리량 격차, 그리고 시리즈가 다음에 어디로 가는지.