제1장 — AI 통합 위기와 에이전트형 아키텍처의 부상

LLM Primer IV: MCP로 설계하는 AI 인지를 챕터별로 따라가는 워크스루의 첫 번째 글입니다. 2024년경 지배적이었던 패턴 — 긴 시스템 프롬프트, 한 줌의 도구, 모든 일을 다 하라고 요청받는 단일 컨텍스트 윈도 — 이 알아볼 만한 순서로 실패하는 모습을 보고, 그 실패가 사실은 학계가 조용히 향해 가던 프로토콜 층을 가리키고 있었음을 함께 짚어 보겠습니다.

이 장이 존재하는 이유

약 2년 동안 LLM 애플리케이션의 표준 레시피는 이러했습니다. 긴 시스템 프롬프트를 쓰고, 한 줌의 도구를 붙이고, 그것을 에이전트라 부른다. 이 레시피는 데모를 출하했습니다. 그리고 예측 가능하게, 표면적이 자라면서 무너졌습니다. 프롬프트가 6천 토큰을 넘어 기어갔습니다. 도구 목록이 마흔을 넘었습니다. 팀은 패치하고, 감사하고, 회귀 테스트를 돌렸고, 어느 시점에서 기능을 더하는 일이 예전보다 기하급수적으로 비싸졌다는 사실을 알아챘습니다. 진단은 게으름이나 나쁜 엔지니어링이 아니었습니다. 모든 관심사를 하나의 공유 자원 — 모델의 컨텍스트 — 을 통과시키도록 강요한 아키텍처였고, 그 아래에 더 깊은 조합론적 문제가 숨어 있었습니다.

이 장은 팀이 실제로 마주치는 순서대로 실패 모드를 걸어 가고, 각각에 이름을 붙인 다음, 아키텍처적 출구를 짜 봅니다. 출구는 두 가지입니다. 모델과 도구가 맞춤 글루 없이 서로를 찾을 수 있게 해 주는 프로토콜 층, 그리고 모델의 시야를 자유로운 텍스트 필드가 아니라 관리되는 예산으로 다루는 규율 — 컨텍스트 엔지니어링. 두 발상 모두 이 책의 나머지를 떠받칩니다.

1.1 모놀리식 에이전트와 그 시스템 프롬프트가 결국 깨지는 까닭

1세대 프로덕션 LLM 애플리케이션은 아키텍처적으로 단순한 모양을 했습니다. 수천 토큰짜리 시스템 프롬프트가 역할, 도구, 제약, 어조, 예외 사례를 기술했습니다. 좁은 표면에서는 잘 통했습니다. 팀이 한 단락씩 기능을 더해 가는 동안 그 프롬프트는 코드베이스에서 가장 긴 단일 산출물이 되었고, 무언가를 빼는 일이 위험해 보이는 탓에 거의 덧붙이기로만 편집되었습니다.

이 프롬프트가 내부에서 무엇을 하고 있었는지는 어텐션을 통해 가장 잘 이해됩니다. 트랜스포머는 시스템 프롬프트의 모든 토큰을 포함해 컨텍스트의 모든 토큰에 대해 어텐션 가중치를 계산합니다. 6천 토큰짜리 프롬프트는 훑어지지 않습니다 — 평균화됩니다. 프롬프트가 길어질수록 현재 단계와 무관한 명령에 어텐션 질량이 더 많이 흩어집니다. 이 현상에는 이름이 있습니다. 컨텍스트 희석, 명령 충돌, 능력 표류. 팀은 회귀를 관찰하지만 원인을 국소화하지 못합니다 — 원인이 세 개의 새 규칙과 두 스프린트 전에 추가된 한 절의 상호작용이기 때문입니다.

관련 실패는 도구 층에서 나타납니다. 도구가 열 개일 때 모델은 정확히 고릅니다. 마흔 개가 되면 선택 정확도가 떨어지는데, 가끔은 뚜렷하게 떨어집니다. 팀은 구별을 주는 표현을 더해 패치하고, 그 결과 프롬프트가 길어지며, 어텐션이 더 희석됩니다. 시스템은 이제 자기 자신과의 피드백 루프에 들어가 있습니다.

1.2 전문화, 그리고 잘못된 방향으로 휘는 유지보수 곡선

프롬프트 문제 아래에는 더 깊은 문제가 있습니다. 프런티어 범용 모델은 강한 제너럴리스트지만, 제너럴리스트 성능은 거대한 표면에 대한 평균이고, 평균은 절벽을 가립니다. 법무 계약 리뷰, 구조화된 의료 코딩, 재무 대사 — 각각은 자체 용어와 자체 규칙, 그리고 일반 학습이 최적화하지 않은 오류 허용도를 가집니다. 본능은 프롬프트를 통해 전문화하는 것입니다. 비용은 더 많은 어텐션 예산이 더 적은 수익을 위해 소진된다는 점입니다. 진짜 전문화는 자체의 집중된 컨텍스트를 가진 자체 컴포넌트를 원하는데, 모놀리식 에이전트에는 그것을 놓을 자리가 없습니다.

유지보수도 같은 방향으로 잘못 늘어납니다. 네 개 도메인에 걸쳐 도구 50개를 가진 모놀리식 에이전트는, 도구 다섯 개와 도메인 하나를 가진 에이전트의 열 배 유지보수 부하를 갖지 않습니다 — 더 많습니다. 모든 기능이 공유 프롬프트를 통해 다른 모든 기능과 상호작용하기 때문입니다. 팀의 속도는 새 능력을 짓는 비용이 아니라, 기존 표면을 일관되게 유지하는 비용에 의해 결정됩니다. 추론 비용은 컨텍스트 길이에 비례하므로, 프롬프트를 줄이려는 경제적 압력과 늘리려는 엔지니어링 압력은 반대 방향으로 잡아당깁니다.

1.3 N 곱하기 M 통합 문제

분해의 정당성을 받아들이면, 이제 N개의 모델 보유 컴포넌트와 M개의 도구 통합이 있습니다. 공유 프로토콜이 없다면 통합 비용은 N 곱하기 M입니다 — 모든 모델이 모든 도구에 대해 맞춤 어댑터 코드를 필요로 하며, 모든 모델의 특이성이 모든 도구의 특이성과 카르테시안 곱이 됩니다. 새 모델 릴리스는 모든 도구를 다시 테스트해야 함을 뜻합니다. 새 도구는 N개의 어댑터를 써야 함을 뜻합니다.

컴퓨팅의 역사에는 이 모양에 대한 이름과 그 수정에 대한 이름이 있습니다. LSP(2016) 이전에는 모든 에디터가 모든 언어와의 통합을 필요로 했습니다 — 에디터 곱하기 언어. LSP는 프로토콜을 도입했고, 그 행렬은 덧셈 비용으로 무너졌습니다. USB 이전에는 모든 주변기기 범주가 자체 포트를 가졌고 모든 OS가 자체 드라이버를 출하했습니다. USB 이후에는 하나의 호스트, 하나의 디바이스, 그 사이의 공유 프로토콜 하나. Model Context Protocol은 같은 수를 모델과 도구에 적용한 것입니다. 어댑터를 없애지는 않습니다. 어댑터를 표준화합니다. 첫 통합은 더 느립니다. 백 번째는 훨씬 빠릅니다. 천 번째는 도구 체인이 누적된 덕에 본질적으로 무료입니다. 게임 전체가 누적 곡선에 있습니다.

발견을 가진 프로토콜은 더 조용한 두 번째 행렬도 무너뜨립니다 — 기술(description) 행렬. 모델은 더 이상 부팅 시 모든 도구를 시스템 프롬프트에 열거할 필요가 없습니다. 프로토콜에 「지금 무엇이 가능합니까?」를 물어 권위 있는 출처 — 서버 자신 — 에서 구조화된 카탈로그를 받을 수 있습니다.

1.4 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

어휘의 이동이 아키텍처적 이동을 따라갑니다. 2022~2023년의 분야는 프롬프트 엔지니어링이었습니다 — 모델을 원하는 행동으로 살짝 미는 표현을 찾는 일. 2025년에 이르러 프롬프트는 여러 입력 중 하나가 되었습니다. 모델은 검색된 문서, 도구 기술, 이전 턴, 도구 결과, 스크래치패드 노트, 메모리 조각도 봅니다. 각 단계에서 그 컨텍스트에 무엇이 들어가야 하는지는 더 이상 표현으로 답할 수 없습니다. 매 턴 모델이 무엇을 보아야 할지를 결정하는 아키텍처가 답합니다.

자리잡은 용어가 컨텍스트 엔지니어링입니다. 컨텍스트 윈도를 관리되는 예산으로 다룹니다. 현대의 장기 컨텍스트 모델은 백만 토큰 윈도를 광고하지만, 성능은 컨텍스트가 차면서 비선형적으로 저하됩니다 — 가끔 컨텍스트 부패라고 불리는 현상입니다. 답이 그 안에 묻혀 있는 백만 토큰 컨텍스트를 건넨 모델은, 같은 모델에게 신중히 골라 낸 만 토큰을 건넨 경우보다 자주 성능이 더 낮습니다. 중요한 예산은 윈도 크기가 아닙니다. 그것은 실제로 모델 앞에 놓인 무엇이든 그 안에서 유용한 신호의 밀도입니다.

MCP는 부분적으로 컨텍스트 엔지니어링을 가능하게 하는 인프라입니다. 프로토콜은 호스트에게 어떤 도구와 데이터 출처가 있는지 묻고, 적절한 순간에 관련된 것을 가져오고, 모델이 호출할 수 있는 능력을 협상하는 기계를 줍니다. 호스트는 현재 작업이 실제로 요구하는 것에 따라 매 턴 동적으로 컨텍스트를 만듭니다.

제1장이 준비하는 것

진단은 세 부분입니다. 모놀리식 에이전트는 긴 프롬프트가 어텐션을 희석해 실패합니다. 전문화된 능력은 공유 프롬프트 안에 살 수 없습니다. 둘 아래에는 N 곱하기 M 통합 문제가 깔려 있습니다. 각 실패 모드는 같은 방향을 가리킵니다 — 모델 아래에서 모델과 도구가 서로를 찾고, 서로를 기술하고, 무엇을 할 수 있는지 협상하는 방식을 중재하는 층. 제2장은 그 층을 소개합니다. MCP가 정의하는 세 역할, 적은 수의 개념적 프리미티브 집합, 그리고 명시적 능력 협상으로 열리는 세션 라이프사이클.

다음 → 제2장: Model Context Protocol의 베일 벗기. MCP가 무엇이고, 「AI를 위한 USB-C」라는 약칭이 실제로 무엇을 뜻하며, Host, Client, Server의 세 역할 분할, 그리고 동적 발견과 양방향 메시징이 중요한 경우에 MCP가 REST API와 다르게 행동하는 이유.