AI를 시스템으로 잇는 법: Context Engineering·MCP·Multi-Agent를 비개발자 눈높이로

메일 초안 하나를 잘 뽑는 것과 회사 전체가 AI로 굴러가는 것 사이에는 한 단어가 있습니다. 연결입니다. AI를 회사 시스템으로 잇는 기술은 세 가지로 정리됩니다. 맥락 설계(Context Engineering) 로 AI 에게 무엇을 보여줄지 관리합니다. MCP 로 AI 를 사내 도구와 데이터에 표준 방식으로 꽂습니다. 다중 에이전트(Multi-Agent) 로 여러 AI 가 역할을 나눠 일하게 합니다. 코드 한 줄 없이, 의사결정자가 알아야 할 만큼만 설명하겠습니다. 2025~2026년 채택·표준화 데이터로 왜 지금인지도 함께 봅니다.

왜 “똑똑한 AI”가 회사에선 잘 안 통할까

먼저 현실을 직시할 필요가 있습니다. 도입률은 높지만 성과로 이어진 비율은 처참할 만큼 낮습니다.

맥킨지의 2025년 ‘State of AI’ 조사(105개국 1,993명 응답)에 따르면, 적어도 한 개 이상의 업무에서 AI를 정기적으로 쓴다는 기업은 88%로 1년 전 78%에서 늘었습니다. 그러나 AI 에이전트를 전사적으로 확장(scaling)한 기업은 23%에 그쳤습니다. 더 뼈아픈 숫자는 성과 쪽입니다. AI로 EBIT(영업이익)에 조금이라도 영향을 봤다고 답한 기업은 39%였지만, 그중 대다수는 그 영향이 전체 EBIT의 5% 미만이라고 답했고, 5% 이상의 의미 있는 성과를 본 ‘고성과 기업’은 전체의 약 6%에 불과했습니다(McKinsey, The state of AI in 2025). 가트너는 한발 더 나아가, 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 비용 급증·불분명한 사업 가치·미흡한 리스크 통제 때문에 취소될 것이라고 전망했습니다(Gartner, 2025-06-25).

도입은 했는데 왜 안 될까요. 원인은 거의 항상 연결이 없다는 데 있습니다. 모델이 모자란 것이 아니라, 그 모델이 우리 회사의 데이터와 도구, 업무 흐름에 닿지 못하고 개인 채팅창에 갇혀 있습니다. 우리가 현장에서 반복적으로 목격하는 실패는 세 가지 패턴으로 나타납니다. 첫째, AI 활용이 개인에게 흩어져 표준이 없습니다. 둘째, 한 사람이 잘 쓴 노하우가 조직에 축적되지 않습니다. 셋째, AI가 결재·CRM·메일 같은 실제 시스템과 단절돼 있습니다. 이 세 가지를 푸는 기술적 해답이 차례로 Context Engineering, Multi-Agent, MCP입니다.

Context Engineering: AI에게 “무엇을 보여줄지”를 설계한다

한때 모든 관심은 “프롬프트를 어떻게 쓰느냐”에 쏠렸습니다. 2025년 들어 무게중심이 옮겨갔습니다. 핵심 질문이 “어떻게 물어볼까”에서 “AI가 답할 때 그 작업 공간에 무엇을 올려둘까”로 바뀐 것입니다. 이것이 Context Engineering입니다.

Anthropic은 2025년 이 개념을 공식화하며, 프롬프트 엔지니어링이 “효과적인 프롬프트, 특히 시스템 프롬프트를 쓰는 법”이라면, Context Engineering은 “추론 과정에서 최적의 토큰(정보) 집합을 선별하고 유지하는 전략의 총체” 라고 정의했습니다(Anthropic, Effective context engineering for AI agents). 쉽게 말해, 프롬프트가 “질문하는 법”이라면 Context Engineering은 “AI 책상 위에 어떤 자료를 펼쳐 둘지”를 관리하는 일입니다.

왜 이게 중요할까요. 맥락은 무한하지 않기 때문입니다. Anthropic은 두 가지 현상을 지목합니다. 하나는 ‘컨텍스트 부패(context rot)’ — 맥락 창에 토큰이 많아질수록 모델이 그 안의 정보를 정확히 떠올리는 능력이 떨어진다는 것입니다. 다른 하나는 ‘주의 예산(attention budget)’ — 사람의 작업기억처럼 모델도 토큰이 늘어날수록 집중력이 고갈된다는 것입니다. 자료를 무조건 많이 넣는 게 답이 아니라, “꼭 필요한 것만, 제때” 올려두는 큐레이션이 성능을 좌우합니다.

이를 위해 실무에서 쓰는 기법들은 비개발자도 직관적으로 이해할 수 있습니다. 컴팩션(compaction) 은 길어진 대화 기록을 요약해 압축본으로 다시 시작하는 것, 구조화된 메모(note-taking) 는 맥락 창 밖의 메모리에 기록을 남겨 나중에 꺼내 쓰는 것, 적시 검색(just-in-time retrieval) 은 모든 데이터를 미리 욱여넣는 대신 필요한 순간 도구로 불러오는 것입니다. 회사 관점에서 이 작업은 “흩어진 개인 활용”을 “표준화된 맥락 설계”로 바꾸는 첫 단추입니다. 결재 한 건을 30분에서 3분으로 줄이려면, AI에게 사내 결재 규정·이전 사례·예외 처리 기준이라는 정확한 맥락을 매번 깔아줘야 하는데, 그 설계가 바로 Context Engineering입니다.

MCP: AI를 회사 도구에 꽂는 “USB-C 표준”

Context Engineering이 “무엇을 보여줄지”라면, MCP(Model Context Protocol)는 “어디서 그 무엇을 가져올지”를 해결합니다. MCP는 AI 모델을 사내 데이터·도구·시스템에 연결하는 개방형 표준입니다. 흔히 “AI를 위한 USB-C”에 비유합니다. 예전에는 AI를 메일에 연결하려면 메일용 어댑터, CRM에 연결하려면 CRM용 어댑터를 따로 개발해야 했습니다. MCP는 그 모든 연결을 하나의 규격으로 통일합니다.

주목할 점은 채택 속도입니다. 2024년 11월 Anthropic이 발표한 지 1년 만에, MCP는 경쟁하는 거대 기업들이 모두 받아들이는 사실상의 산업 표준이 됐습니다. 2025년 3월 OpenAI가 Agents SDK·Responses API·ChatGPT 데스크톱에 MCP를 채택했고(“People love MCP” — Sam Altman), 4월에는 Google DeepMind의 데미스 허사비스가 Gemini 지원을 확인했으며, Microsoft는 Build 2025에서 Windows 11의 MCP 도입을 예고했습니다. MCP 서버 다운로드는 2024년 11월 약 10만 건에서 2025년 4월 800만 건 이상으로 폭증했고, 5,800개 이상의 서버와 300개 이상의 클라이언트가 생태계를 이룹니다(The New Stack, Why the Model Context Protocol Won). 2025년 12월에는 Anthropic이 MCP를 리눅스 재단 산하 새 재단(Agentic AI Foundation)으로 이관하고 OpenAI·Block이 공동 설립자로, AWS·Google·Microsoft 등이 지원사로 참여했습니다(Pento, A Year of MCP). OpenAPI나 OAuth가 비슷한 수준의 교차 벤더 채택에 수년이 걸렸던 것과 비교하면 이례적인 속도입니다.

의사결정자에게 이 표준화가 의미하는 바는 명확합니다. 특정 AI 벤더에 종속되지 않고, 한 번 만든 연결을 여러 모델에 재사용할 수 있다는 것. AI를 결재·CRM·메일·내부 위키에 잇는 작업이 “매번 새로 짜는 일회성 개발”에서 “표준 부품 조립”으로 바뀝니다. 우리가 구축한 사례에서도, PDF를 파싱해 거래처를 등록하는 자동화는 브라우저 자동화와 자가복구 로직을 도구화했기에 최종 승인만 사람이 맡고 나머지를 AI가 흐름째로 처리할 수 있었습니다.

Multi-Agent: 한 명의 천재 대신, 역할을 나눈 팀

세 번째 조각은 협업입니다. 복잡한 업무를 AI 하나에 다 맡기면 맥락이 넘치고 집중력이 흩어집니다(앞서 본 context rot). 대안은 사람 조직과 똑같습니다. 총괄(오케스트레이터)이 일을 쪼개 전문 담당(서브에이전트)에게 나눠주고, 각자 결과를 요약해 올리는 구조 입니다.

이 방식의 위력은 Anthropic 자체 사례에서 드러납니다. 리서치 시스템에서 Claude Opus가 총괄 역할을, 여러 Claude Sonnet이 서브에이전트 역할을 맡는 오케스트레이터-워커 구조는, 단일 에이전트 대비 내부 리서치 평가에서 90.2% 더 높은 성능 을 기록했습니다. 총괄이 여러 서브에이전트를 동시에 띄우고 각 에이전트가 병렬로 도구를 호출해, 복잡한 질의의 처리 시간을 크게 단축했습니다(Anthropic 리서치 시스템 분석, ZenML LLMOps Database). 폭넓은 탐색이 필요한 과제에서 특히 강했습니다.

시장도 이 방향으로 빠르게 움직입니다. 가트너는 다중 에이전트 시스템(MAS) 관련 문의가 2024년 1분기에서 2025년 2분기 사이 1,445% 급증했다고 밝혔습니다(Gartner, Multiagent Systems in Enterprise AI). 또한 가트너는 2025년 5% 미만이던 ‘업무 특화 AI 에이전트를 탑재한 엔터프라이즈 앱’이 2026년 말 40%까지 늘 것으로 전망합니다(Gartner, 2025-08-26). 다만 1,445%라는 숫자는 ‘배포’가 아니라 ‘문의(관심)‘의 증가폭이라는 점은 함께 기억할 필요가 있습니다.

다중 에이전트는 만능이 아닙니다. 같은 Anthropic 사례에서 이 시스템은 단일 채팅 대비 약 15배 많은 토큰을 소비했습니다. 즉, 병렬로 깊게 탐색해야 가치가 큰 업무(리서치·교차 검증·복잡한 의사결정 지원)에는 적합하지만, 단순 반복 작업에 다중 에이전트를 붙이면 비용만 늘 뿐입니다. 무엇을 자동화하고 무엇을 사람에게 남길지 선별하는 판단이 그래서 중요합니다. 반복적이고·연결돼 있고·축적되며·복구 가능한 일은 자동화에 맞고, 최종 결정·신뢰·창의가 걸린 일은 사람의 몫으로 남깁니다.

세 조각을 하나로: 시스템이 되는 순간

이제 세 가지가 어떻게 맞물리는지 정리해 봅시다. 비유하자면, MCP는 AI가 회사 도구에 닿는 손과 발, Context Engineering은 그 손발이 무엇을 집어들지 판단하는 눈, Multi-Agent는 일을 나눠 맡는 조직 입니다. 셋이 함께여야 개인 채팅창의 AI가 회사의 시스템이 됩니다.

실제로 이렇게 작동합니다. 우리가 구축한 영업 대시보드는, 영업사원이 음성으로 미팅 내용을 말하면(입력), AI가 CRM 맥락을 불러와(Context Engineering + MCP) 기록을 구조화하고, 별도 에이전트가 주간 보고서를 작성합니다(Multi-Agent). 그 결과 음성 기록은 30분에서 5분으로, 주간 보고는 1시간에서 10분으로 줄었습니다. HubSpot CRM 55개 시트를 QBR과 사업계획서로 자동 변환하는 작업, 위키 150개 문서를 3개 에이전트가 운영하며 재계약 196건을 관리하는 통합 운영도 같은 원리입니다. 어느 것도 “더 똑똑한 모델 하나”로는 불가능했고, 연결·맥락·협업의 조합으로만 가능했습니다.

여기서 한 가지 안전장치를 강조해야 합니다. AI가 실제 시스템을 건드리는 순간, 권한·감사·롤백·한도 라는 통제 장치(Harness Engineering)가 필수입니다. 가트너가 지적한 프로젝트 취소의 주요 원인이 바로 “미흡한 리스크 통제”였음을 기억하세요. 거래처 등록 자동화에서 최종 승인만 사람이 맡긴 것도 이 원칙 때문입니다. 자동화의 속도와 통제의 안전을 동시에 잡는 설계가 성공과 취소를 가릅니다.

회사의 AI 전환이 지금 어느 단계에 있는지, 무엇을 먼저 시스템으로 이어야 하는지 막막하다면 AI 활용 진단으로 현재 위치부터 확인해 보시기 바랍니다. 이 세 가지 개념이 실제로 무엇을 바꾸는지 더 큰 그림이 궁금하다면 에이전틱 AI란 무엇인가를 함께 읽어 보세요.

한국 기업은 어디쯤 와 있나

마지막으로 국내 현실을 짚겠습니다. 한국은 시작은 빠르지만 내재화에서 막혀 있습니다. OECD 통계상 한국은 10인 이상 사업장의 AI 사용 기업 비율(30.28%)에서 회원국 1위 입니다(덴마크 27.58%, 스웨덴 25.09%가 뒤를 이음, KISDI, 2025년 9월 보고서). 그러나 도입과 내재화 사이의 간극이 큽니다. 국내 조사에 따르면 생성형 AI 도입률은 61%에 달하지만 전사 차원의 조직적 내재화는 6.7%에 그치며, AI 에이전트의 경우 전사 차원 내재화 단계에 도달한 기업은 3.7%에 불과합니다(탐색·준비 39.6%, 시범 도입 25.9% — Carrot Global, 2026 한국기업 AI 활용 현황 디브리핑).

이 숫자가 말하는 바는 분명합니다. 한국 기업의 과제는 “AI를 쓸 것인가”가 아니라 “흩어진 개인 활용을 어떻게 시스템으로 이을 것인가”입니다. 도입률 1위라는 출발선의 이점을, 내재화 3.7%라는 병목을 뚫고 성과로 바꾸는 곳이 향후 경쟁의 승자가 될 것입니다. 그 다리를 놓는 기술이 바로 이 글에서 본 Context Engineering·MCP·Multi-Agent입니다.

자주 묻는 질문

MCP가 정말 표준으로 자리 잡았나요, 아니면 일시적 유행인가요?

표준으로 보는 근거가 충분합니다. 2024년 11월 발표 후 1년 만에 OpenAI·Google·Microsoft·AWS가 모두 채택했고, 서버 다운로드는 10만 건에서 800만 건 이상으로 늘었으며, 2025년 12월 리눅스 재단 산하 재단으로 거버넌스가 이관되며 특정 기업의 소유에서 중립적 공공 표준으로 전환됐습니다(Pento). 경쟁하는 거대 기업들이 동시에 같은 규격을 받아들이고 중립 재단이 관리한다는 점이 일시적 유행과 표준을 가르는 핵심 신호입니다.

Context Engineering과 프롬프트 엔지니어링은 무엇이 다른가요?

프롬프트 엔지니어링은 “어떻게 질문할지”를 다루고, Context Engineering은 “AI가 답할 때 무엇을 작업 공간에 올려둘지”를 다룹니다. Anthropic의 정의로는 추론 과정에서 최적의 토큰 집합을 선별·유지하는 전략 전체를 말합니다(Anthropic). 회사 업무에서는 프롬프트 한 문장보다, 사내 규정·과거 사례·관련 데이터를 정확히 골라 매번 깔아주는 맥락 설계가 성과를 좌우합니다.

다중 에이전트(Multi-Agent)는 모든 업무에 쓰는 게 좋나요?

아닙니다. 폭넓은 탐색·교차 검증·복잡한 의사결정처럼 병렬로 깊게 파야 가치가 큰 업무에 적합합니다. Anthropic 사례에서 단일 에이전트 대비 90.2% 높은 성능을 냈지만 토큰은 단일 채팅 대비 약 15배를 소비했습니다(ZenML). 단순 반복 작업에 다중 에이전트를 붙이면 비용만 늘어납니다. 업무의 성격에 맞춰 단일·다중을 선택하는 판단이 중요합니다.

우리 회사는 어디서부터 시작해야 하나요?

세 가지를 한꺼번에 도입하려 하지 말고 순서를 지키세요. 먼저 반복적이고·연결되며·축적·복구 가능한 업무를 한두 개 골라(자동화 선정 기준), 그 업무에 필요한 맥락을 표준화하고(Context Engineering), 기존 도구와 MCP로 연결한 뒤, 복잡도가 높아질 때 다중 에이전트로 확장합니다. 권한·감사·롤백·한도라는 통제 장치를 처음부터 함께 설계하는 것이 가트너가 지적한 ‘취소되는 40%‘에 들지 않는 비결입니다. 현재 위치 진단은 AI 활용 진단에서 시작할 수 있습니다.

도입률은 높은데 왜 성과가 안 나는 기업이 많나요?

연결과 내재화의 부재 때문입니다. 맥킨지 조사에서 AI를 정기적으로 쓰는 기업은 88%지만 AI로 EBIT에 조금이라도 영향을 봤다고 답한 곳은 39%, 그것도 대부분 EBIT의 5% 미만이었고 의미 있는 성과를 본 고성과 기업은 약 6%였습니다(McKinsey). 국내에서도 도입률 61% 대비 전사 차원의 조직적 내재화는 6.7%에 머뭅니다(Carrot Global). 개인이 잘 쓰는 것과 조직의 업무 흐름·시스템에 AI를 박아 넣는 것은 다른 일이며, 그 간극을 메우는 것이 이 글에서 다룬 세 가지 기술의 역할입니다.