제8장 — 아키텍처 배포 레이아웃

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 여덟 번째 글입니다. 동일한 오케스트레이션 로직을 가진 두 시스템이 프로덕션에서 매우 다르게 행동한다는 것이 드러나는데, 그 이유는 「모델이 실제로 어디서 도는가」라는 질문이 세 가지 다른 방식으로 답해지고, 각 답이 다른 지연 시간, 비용, 보안 천장을 두기 때문입니다.

이 장이 존재하는 이유

제6장과 제7장은 에이전트가 조율하는 방식을 명세했습니다. 시스템의 실제 행동 중 같은 만큼을 결정하는 질문에 대해서는 침묵했습니다. 각 에이전트는 어디서 돌며, 언어 모델, MCP 서버, 도구는 네트워크에 걸쳐 어떻게 배치됩니까? 이 장의 아키텍처적 결정은 모든 요청과 모든 달러에 닿습니다. 2025년에서 2026년에 걸쳐 MCP 생태계에서 세 가지 크게 다른 레이아웃이 떠올랐고, 그 셋 중 어느 것도 보편적으로 옳지 않습니다. 각각은 다른 제약 조합에 최적화되어 있으며, 선택은 엔지니어가 그것을 내리기 전에 또렷이 표현할 수 있어야 할 결과를 가집니다.

8.1 재사용 가능한 AI 에이전트: 서버와 함께 패키지된 모델

첫 번째 레이아웃은 언어 모델을 MCP 서버와 함께 패키지하고, 그 조합을 단일 블랙박스 능력으로 노출합니다. 클라이언트는 도구를 호출하듯 「이 풀 리퀘스트를 리뷰하라」를 호출합니다. 내부에서는 전체 에이전트 루프가 서버 측에서 돌며, 모델을 호출하고, 내부 도구를 부르고, 최종 출력만 반환합니다. 이 패턴은 조직이 전문화된 에이전트 — 연구, 코드 리뷰, 금융 분석 — 를 지어, 각자가 내부를 이해할 필요 없이 많은 다른 호스트 애플리케이션에 노출하고 싶을 때 떠올랐습니다.

강점은 실제적입니다. 캡슐화는 에이전트 저자가 클라이언트에 보이는 어떤 변경도 없이 모델을 교체하거나 오케스트레이션을 재구성할 수 있게 합니다. 호스트 애플리케이션에 걸친 재사용성은 단일 에이전트가 Claude Code, 엔터프라이즈 앱, 그리고 고객 대면 챗봇을 동일한 인터페이스를 통해 섬기게 합니다. 비용도 똑같이 실제적입니다. 불투명성은 디버깅을 어렵게 만듭니다. 에이전트가 잘못된 결정을 내릴 때 클라이언트는 왜인지 볼 수 없습니다. 지연 시간은 서버 측 루프가 매 호출 돌기 때문에 쌓입니다. 그리고 이중 예산이 구조적입니다. 에이전트 운영자는 자기 모델 호출 비용을 내고 클라이언트는 자기 자신 것을 내며, 상호작용당 총 비용은 어느 쪽도 처음에 깨닫지 못한 것보다 더 높을 수 있습니다.

다중 테넌트 변종 — 많은 클라이언트 조직을 섬기는 한 에이전트 프로세스 — 은 테넌트에 걸쳐 고정 비용을 분산해 운영 경제를 실질적으로 개선합니다. 또한 교차 테넌트 데이터 누설을 일급 실패 모드로 도입합니다. 2025년의 여러 공개된 사고가 정확히 이것을 포함했고, 운영자는 요청 사이의 누설을 잡으려고 코드 리뷰에 의지하기보다 테넌시를 런타임에 설계해 넣어야 합니다.

8.2 엄격한 MCP 순수성: 클라이언트 안의 모델

두 번째 레이아웃은 언어 모델을 엄격히 클라이언트에 둡니다. MCP 서버는 데이터와 도구만 노출합니다 — 추론은 없습니다. 호스트가 모델을 돌리고, 오케스트레이션 결정을 내리며, 컨텍스트를 모으고 행동을 실행하려고 서버를 호출합니다. 동기는 프로토콜의 원래 설계 합리성입니다. MCP는 모델과 도구 사이의 균일한 인터페이스를 제공해 N 곱하기 M 통합 문제를 풀려고 존재하며, 자체 모델을 돌리는 서버는 프로토콜이 풀려던 문제를 재도입합니다.

강점은 제어와 투명성입니다. 모든 모델 호출은 클라이언트의 계측에 관측 가능합니다. 클라이언트는 요청별로 모델을 고르고, 제공자를 가로질러 폴백할 수 있으며, 모든 모델 비용을 직접 부담합니다 — 사슬 안에 두 번째 모델이 없으므로 이중 예산이 없습니다. 클라이언트의 감사 로그가 전체 추론 사슬을 포착해야 하는 규제 산업에서, 엄격한 순수성은 모호함 없이 요구를 충족합니다.

비용도 똑같이 명확합니다. 모든 지능 조각이 모든 클라이언트에 의해 재구현되어야 하며, 이는 많은 호스트 애플리케이션을 가진 조직에 실제 부담입니다. 일부 능력 — 다단계 연구, 반복적 정제 — 은 한 번에 끝나는 도구로 인수분해하기에 어색하고, 그것을 노출하는 일은 복잡한 오케스트레이션을 클라이언트에 밀어 넣거나 서버가 자체 모델을 돌리게 두어 조용히 순수성을 위반합니다. 그리고 클라이언트는 오케스트레이션을 돌릴 수 있어야 하는데, 실제로 이는 루프를 처음부터 굴리기보다 Strands, LangChain, Semantic Kernel, 또는 Microsoft Agent Framework에 기대는 것을 뜻합니다.

8.3 하이브리드: 클라이언트 측 오케스트레이션과 서버 측 실행

세 번째 레이아웃은 차이를 가릅니다. 클라이언트는 오케스트레이션하고 주된 추론을 돌리며, 일부 MCP 서버는 전문화된 하위 작업에 대해 자체 모델 호출을 돌립니다. 가장 분명한 예는 장수명 딥 리서치 도구입니다. 더 넓은 워크플로에 연구 결과를 접어 넣어야 하는 클라이언트는 연구의 모든 단계를 스스로 관리하고 싶지 않습니다. 「X를 연구하고 무엇을 찾았는지 알려라」를 호출하고 합성을 받고 싶습니다. 연구는 다단계, 다출처이며 자체 내부 오케스트레이션의 보상을 받습니다.

하이브리드 패턴은 경계가 의미 있는 봉합선에 그어질 때 작동합니다 — 명확한 입출력을 가진 하위 작업, 서버 측 지능이 클라이언트 조율 없이 끝낼 수 있을 만큼 자족적이고, 일반 오케스트레이터를 거치는 것보다 블랙박스로 돌리는 것을 보상할 만큼 전문화된. 연구, 코드 분석, 문서 합성이 프로파일에 들어맞습니다. 일반 대화는 그렇지 않습니다.

비용은 아키텍처 복잡성입니다. 이제 지능이 도는 두 자리가 있고, 관측 가능성은 경계를 가로질러야 하며, 비용 귀속은 두 순수 패턴 사이에 앉습니다. 유용한 규율은 지능적 서버 수를 제한하고 각자를 잘 정의된 능력에 집중시키는 것입니다. 둘 또는 셋은 운영 가능합니다. 열둘은 어떤 팀도 이해하지 못하는 연합이 됩니다. 하이브리드 배포는 또한 시간이 지남에 따라 스펙트럼의 어느 한 순수 끝으로 진화하는 경향이 있고, 아키텍트는 자기 하이브리드가 안정된 설계인지 과도기적 상태인지에 대해 정직해야 합니다.

제8장이 준비하는 것

제3부의 세 장은 메커니즘 관점에서 다중 에이전트 시스템의 설계 공간을 통과했습니다. 그것들이 아직 다루지 않은 것은 그 아래의 기질입니다. 모든 모델 호출이 받는 컨텍스트와 호출에 걸쳐 지속되는 메모리. 에이전트의 효과성은 행동할 때 무엇을 볼 수 있는지와 이전에 무엇을 했는지에 대해 무엇을 회상할 수 있는지에 달려 있습니다. 컨텍스트 윈도는 유한합니다. 메모리 아키텍처는 설계되어야 합니다. 주의력 예산 관리, 스크래치패드 사용, 일화적·의미적 메모리의 패턴은 조율된 에이전트 집합을 시간 위에 — 시간, 일, 또는 그 이상에 걸쳐 — 유용한 일을 하는 시스템으로 바꾸는 기질입니다.

다음 → 제9장: 주의력 예산 관리. 백만 토큰 윈도가 왜 운영 지점이 아니라 천장 값인지, 예산을 무엇이 먹는지, 그리고 MCP, RAG, 파인튜닝이 어떻게 각각 다른 모양의 간격에 들어맞는지.