에이전트 워크플로우 기술의 전환점: MCP와 브라우저 기반 접근의 현재와 미래

에이전트 워크플로우의 진화와 새로운 국면

최근 인공지능 에이전트 기반 워크플로우 기술이 급격한 변화를 맞이하고 있다. 2025년 초까지만 해도 산업 전반에서는 MCP (Model Context Protocol) 기반 에이전트 기술이 차세대 표준으로 주목받았다. 대형 기술 기업들이 공통된 에이전트 API 표준을 정립하려는 움직임을 보이며, AI 에이전트를 기존 시스템에 통합하는 방식이 MCP 표준 중심으로 재편될 것으로 기대되었다. 그러나 약 20일 전 중국에서 등장한 새로운 서비스 Manus가 판도를 뒤흔들며, 에이전트 워크플로우에 대한 접근 방식에 큰 변화를 가져왔다. 특히 Manus는 브라우저 기반의 혁신적 방식으로 별도의 전용 에이전트 없이도 복잡한 작업을 수행하는 사례를 보여주어 업계에 신선한 충격을 주고 있다. 본 분석에서는 MCP 기반 에이전트 기술의 개념과 업계 동향, 그리고 Manus로 대표되는 브라우저 기반 접근의 등장과 영향에 대해 살펴본 뒤, 두 접근 방식의 장단점을 비교하고 향후 에이전트 기술의 발전 방향을 전망해본다. 이를 통해 기술 업계 종사자들이 현 상황을 구조적으로 이해하고 향후 전략을 모색하는 데 필요한 시사점을 제공하고자 한다.

MCP 기반 에이전트 기술: 부상 배경과 업계의 기대

MCP (Model Context Protocol)는 AI 모델(에이전트)과 외부 데이터·도구를 연결하기 위한 개방형 표준 프로토콜이다. Anthropic이 2024년 11월에 공개한 이 프로토콜은, AI가 여러 데이터 소스와 툴에 표준화된 방식으로 접근하여 문맥(Context)을 얻고 작업을 수행하도록 설계되었다. 쉽게 말해 MCP는 AI 에이전트와 다양한 외부 시스템(예: 데이터베이스, 클라우드 애플리케이션, 파일 저장소 등) 사이에 양방향 연결을 맺어주는 통신 규약이다. 이를 통해 개별 애플리케이션마다 별도 통합을 구현하지 않더라도, 하나의 프로토콜로 다양한 리소스에 접근할 수 있게 된다.

이 MCP 개념이 등장하게 된 배경에는, 거대 언어 모델(LLM)의 성능이 높아졌음에도 “고립된 지능”에 머무르는 한계가 있다는 업계 인식이 있었다. AI가 실제 환경에서 유용해지려면 훈련된 지식 외에 실시간 데이터 접근과 도구 활용 능력이 필수적인데, 그동안 이는 각자도생식 구현에 의존해왔다. MCP는 이러한 문제를 해결할 표준 인터페이스로 부상한 것이다. 마치 컴퓨터 세계에서 HTTP나 TCP/IP 같은 통신 표준이 서로 다른 시스템 연결을 가능케 했듯, MCP가 AI 에이전트 생태계에서 “AI용 HTTP” 역할을 할 것으로 기대되었다. 실제로 MCP의 사양에는 서버(툴 제공자)가 호스트(LLM 에이전트 애플리케이션)에 표준 명령 세트를 통해 데이터를 주고받는 구조가 정의되어 있어, 지리적으로 떨어진 서버에 있는 데이터베이스나 서비스도 공통 명령으로 사용할 수 있다. 이러한 통합 방식 덕분에 에이전트는 추가 커스텀 코드 없이도 전세계 어떤 MCP 호환 도구든 활용할 수 있고, 맥락을 풍부하게 파악해 더 정교한 응답을 생성할 수 있다.

업계는 MCP 기반 에이전트 기술에 큰 기대를 걸었다. 2025년 초에는 여러 AI 분야 커뮤니티와 전문가들이 MCP를 “게임 체인저”로 언급할 정도로 화제가 되었으며, MCP가 기존 에이전트 프레임워크들을 뛰어넘는 데팩토 표준으로 자리잡을 것이라는 전망도 나왔다. 즉, MCP를 활용하면 에이전트가 필요 시 문맥을 동적으로 수혈받아가며 작업할 수 있으므로, 더 이상 LLM의 지식 한계를 걱정하지 않아도 되고 작동 범위가 크게 넓어질 것으로 본 것이다. 예를 들어, 금융 리포트를 생성하는 에이전트라면 MCP를 통해 최신 시장 데이터베이스나 사내 문서에 접속해 바로 필요한 정보를 인출하고, 고객 이메일에 답변하는 어시스턴트는 회사 내부 지식베이스에 질의해 정확한 내용을 참고하는 식이다. 이러한 맥락 통합형 에이전트는 기존의 정적 프롬프트 기반 모델보다 훨씬 실용적이고 신뢰도 높은 AI 어시스턴트를 만들 수 있을 것으로 기대되었다.

빅테크의 표준화 움직임: “AI계의 USB-C”를 향하여

MCP가 공개된 이후, 주요 기술 기업들과 AI 오픈소스 커뮤니티는 앞다투어 이 표준에 호응했다. Anthropic이 선도한 MCP 이니셔티브에 Microsoft, Google, OpenAI 등의 업계 리더들도 관심을 보이며, 에이전트 도구 생태계를 표준화하려는 움직임이 본격화되었다. 실제로 Microsoft는 자사 Copilot과 Azure OpenAI 서비스에 MCP를 통합하기 위한 실험을 진행하며, MCP를 “AI용 USB-C”에 비유하기도 했다. USB-C 규격이 기기 간 물리적 연결을 하나로 통합했듯이, MCP가 LLM/에이전트와 외부 리소스 간의 범용 인터페이스 역할을 할 수 있다는 비전이다. 이와 함께 Microsoft는 MCP를 활용하여 클라우드 상에서 여러 툴 커넥터를 운영하는 방안을 모색하는 등, 엔터프라이즈 환경에서 MCP 적용을 적극 검토하였다.

다른 기업들도 MCP 표준화 흐름에 동참했다. Anthropic은 Claude 모델에 MCP 서버/클라이언트 지원을 내장했으며, 앞서 공개한 MCP 서버 오픈소스 목록에는 Google Drive, Slack, GitHub 등 주요 플랫폼에 대한 커넥터들이 이미 다수 포함되었다. 이는 Anthropic이 초기에 MCP 사양 발표와 함께 수십 개 기업 애플리케이션에 대한 통합 저장소를 제공한 것으로, 경쟁사인 OpenAI와 Google 관련 서비스들까지 망라되었다. 다시 말해, MCP는 태생부터 경쟁 벤더도 함께 쓸 수 있는 개방형 표준으로 추진되었으며, 실제로 그 코드와 도구들이 공개되어 누구나 기여할 수 있게 되었다. 그 결과 MCP 발표 직후에는 반응이 미미했지만, 2025년 2월경부터 개발자들 사이에서 갑자기 관심이 폭발적으로 증가해 수천 개의 MCP 서버가 인터넷상에 등장했고, 인기 소프트웨어(예: Gmail, Slack 등)를 위한 커넥터가 속속 개발되었다. 에이전트 프레임워크 제공업체들도 자사 제품에 MCP 어댑터를 채택하기 시작하여, LangChain과 같은 툴에도 MCP 지원 플러그인이 도입되는 등 사실상의 표준 수용 움직임이 보였다.

이러한 업계의 공조는 에이전트 API의 통합 표준화를 위한 중요한 진전으로 평가된다. 여러 기업이 동참함에 따라 MCP는 단순한 한 회사의 솔루션이 아니라, AI 생태계 전체의 협력 표준으로 떠오르고 있다. 비유하자면, 과거 월드와이드웹이 HTTP라는 단일 표준을 통해 폭발적인 성장과 혁신을 이뤘듯이, 에이전트 세계에서도 MCP 같은 공통 언어를 통해 새로운 “에이전트 웹(Agentic Web)”의 시대를 열 수 있다는 기대다. 요컨대 2025년 초까지는 MCP를 중심으로 에이전트 기술이 구조화된 발전 궤도에 들어서는 듯 보였고, 업계의 화두는 얼마나 빨리 MCP 생태계를 구축하고 활용할 수 있는지가 되었다.

중국 Manus의 등장: 브라우저 기반 에이전트의 가능성

이렇듯 MCP 표준화에 이목이 집중되던 차에, 2025년 3월 초 중국의 한 스타트업이 선보인 Manus는 전혀 다른 접근 방식으로 센세이션을 일으켰다. Manus는 중국 스타트업 Monica.im이 공개한 종합 AI 에이전트 서비스로, 출시 직후부터 “서방의 도구들을 능가할 미래형 AI”라는 평가를 받으며 폭발적인 관심을 모았다. Manus가 내세운 가장 큰 특징은 사용자가 텍스트로 명령만 내리면, 마치 사람처럼 컴퓨터를 조작하여 복잡한 일들을 척척 해낸다는 점이다. 예컨데 지원자들의 이력서를 열람해 최적의 후보를 추천하고, 그 결과를 요약 문서나 스프레드시트로 정리해주거나, 주어진 예산·지역 조건에 맞는 부동산 시장 조사 보고서를 자동 작성하고 주변 편의시설 정보까지 덧붙여주는 식이다. 심지어 주가 상관관계 분석을 수행해 투자 리포트를 쓰고, 웹에서 수집한 데이터로 인터랙티브 웹사이트까지 생성하는 데 수십 분이 채 걸리지 않는 모습을 시연해 모두를 놀라게 했다. 이러한 데모를 접한 초기 사용자들은 “키보드 앞에 인간 조수가 앉아 눈 깜짝할 사이에 일을 처리하는 것 같다”고 평했는데, 그만큼 Manus는 기존 챗봇과 달리 실제 행위를伴한 능동적 작업 수행을 선보였다.

Manus의 또 다른 혁신은 브라우저 기반의 동작이다. Manus 서비스의 백엔드는 일종의 가상 워크스테이션(클라우드 상의 Ubuntu 데스크탑)으로, 이 에이전트는 그 안에서 웹 브라우저를 열고 직접 사이트에 방문하거나 양식을 채워넣는 방식으로 업무를 처리한다. 즉, 인간이 컴퓨터 앞에서 할 법한 대부분의 작업(웹 검색, 폼 입력, 파일 다운로드 등)을 Manus가 자동화된 브라우저 조작으로 대신하는 것이다. 예를 들어 Manus는 필요시 자체적으로 수십 개의 브라우저 탭을 동시에 열어가며 웹에서 자료를 찾아내고, 그것들을 종합 분석한 후 결과물을 만들어낸다는 보고가 있다. 이러한 웹 UI 자동화 접근 덕분에 Manus는 특정 API나 공식 통합 없이도 인터넷상의 거의 모든 서비스와 상호작용할 수 있었다. 다시 말해, 별도의 에이전트 소프트웨어를 설치하거나 MCP 같은 표준 인터페이스를 미리 구현하지 않아도, Manus는 웹을 인간처럼 탐색함으로써 사실상 어떤 작업이든 수행하는 범용성을 보여준 것이다.

Manus의 등장으로 업계 판도에는 미묘한 변화가 생겼다. 그동안 MCP를 통한 정교한 통합을 추구하던 분위기 속에서, Manus는 오히려 비표준적인 접근(웹 브라우저 흉내내기)으로도 상당한 수준의 자동화를 달성할 수 있음을 증명했다. 특히 Manus가 자체 벤치마크에서 서구 기업들의 에이전트 도구보다 빠른 수행 속도를 내세우고, 실제 사용 사례에서도 엄청난 병렬 처리로 순식간에 결과를 뽑아내는 모습을 보이자, 업계는 충격과 함께 이 새로운 방향을 주목하기 시작했다. Manus를 개발한 팀 역시 자사를 “세계 최초의 범용 AI 에이전트”라고 칭하면서, 기존의 대화형 챗봇이나 워크플로우 도구와는 완전히 다른 자율적 행위자 패러다임을 열겠다고 강조했다. 이러한 선언은 일부 과장된 면이 있지만, Manus가 브라우저를 매개로 한 에이전트 실행이라는 틀을 대중화시킨 것은 분명하다. 물론 초기 Manus에는 한계와 문제점도 드러났다. 제한된 프리뷰 방식으로 공개된 Manus는 초대 코드를 구하려는 열풍을 불러일으켰고 며칠 만에 공식 디스코드에 13만 명이 몰릴 정도로 관심을 끌었지만, 정작 써본 사용자들 중에는 오류와 지연을 겪은 이들도 있었다. 예를 들어 어떤 사용자는 Manus를 통해 간단한 패스트푸드 배달 주문을 시도했는데, 10분 넘게 헤매다 시스템이 크래시났고 재시도 후에도 주문을 완결짓지 못했다고 한다. 또 다른 테스트에서는 경쟁 도구인 OpenAI의 Deep Research가 15분도 안 걸린 웹 리서치 작업을 Manus가 50분 넘게 시도하다 실패하는 사례도 보고되었다. 이러한 초기 불안정성에도 불구하고, Manus는 브라우저 기반 에이전트의 가능성을 실용 수준에서 보여줬다는 점에서 의의가 있다. 특히 일반 사용자 입장에선 복잡한 설정 없이 웹 인터페이스에서 프롬프트만 입력하면 Manus가 알아서 여러 웹서비스를 넘나들며 결과를 내놓는 경험이 신선했다. 이는 향후 에이전트 기술의 대중화 측면에서 중요한 전환점으로 평가된다.

Manus의 기술 원리 공개: Open Manus와 코드 유출

Manus 열풍이 거세지자, 그 기술적 비밀에 대한 관심도 크게 높아졌다. 출시 직후 여러 개발자 그룹이 Manus와 유사한 AI 에이전트를 만들기 위해 리버스 엔지니어링을 시도했고, 불과 며칠 만에 의미있는 결과들이 나타나기 시작했다. 한 중국 사용자는 Manus에게 자체 시스템 폴더 내용을 출력하도록 프롬프트를 보내 내부 파일 정보를 유출시켰는데, 이를 통해 Manus의 런타임 코드 일부가 공개되는 일이 벌어졌다. 이 유출 내용을 분석한 결과, Manus는 예상대로 하나의 거대 모델이 아니라 여러 개의 AI 모델과 툴을 조합한 시스템이었다. 구체적으로 Anthropic Claude 3.5 Sonnet과 Alibaba의 Qwen 등 기존 모델들을 파인튜닝해 사용하고 있었으며, 총 29개의 도구 모듈을 탑재해 다양한 작업을 수행하도록 구성되어 있었다. 눈길을 끄는 점은, Manus에 쓰인 도구 중에는 오픈소스 프로젝트인 Browser Use도 포함되어 있었다는 것이다. 이는 앞서 언급한 Manus의 브라우저 조작 기능이 사실상 공개 라이브러리인 Browser Use를 활용한 것임을 시사한다. (Browser Use는 웹사이트의 버튼, 입력창 등 UI 요소를 추출하여 외부 AI가 조작하기 쉽게 해주는 툴로, Manus가 이 기술을 적극 도입한 것으로 보인다.) Manus 개발팀은 이러한 시스템 프롬프트 유출 사건에 즉각 대응하며 몇 가지 내부사항을 확인해주었다. Manus의 공동창업자 겸 수석과학자 Ji Yichao는 “사용자마다 격리된 샌드박스 환경에서 Manus를 돌리고 있으며, 그 샌드박스 내 코드는 오로지 명령 수신을 위한 것으로 약간의 난독화를 했을 뿐 비밀은 없다”고 밝혔다. 또한 “Manus의 툴 설계는 특별히 비공개할 만한 것이 아니며 일반적인 학계 접근과 유사”하고, “오픈소스 코드도 활용하고 있으며 앞으로 더 많은 부분을 오픈소스화할 계획”이라고 언급했다. 실제로 Manus팀은 기본 모델로 사용한 Claude 3.5의 버전과 Qwen 파인튜닝 모델에 대해서도 투명하게 밝혔다. 요컨대 Manus의 기술적 토대는 완전히 새로운 알고리즘이라기보다는, 기존에 알려진 대규모 언어모델과 브라우저 자동화 기술을 정교하게 결합한 시스템인 셈이다.

이런 가운데 오픈소스 진영에서도 재빠르게 대응에 나섰다. Manus 출시 불과 2주 내에 GitHub에는 Open Manus라는 이름의 오픈소스 프로젝트가 등장했고, 개발자 커뮤니티에서 큰 반향을 일으켰다. Open Manus 프로젝트는 MetaGPT 등 에이전트 개발 커뮤니티의 핵심 멤버들이 주도하여 공개되었는데, 불과 몇 일 만에 GitHub 스타 2만8천여 개, 포크 4천여 개를 얻으며 폭발적인 호응을 얻었다. “철옹성이 아니라 열린 광장”이라는 모토를 내건 Open Manus는, Manus와 유사한 범용 AI 에이전트 프레임워크를 누구나 접근 가능하도록 공개함으로써 개발자들의 참여를 이끌어냈다. 공개된 코드와 문서를 통해 드러난 Open Manus의 구조는 Manus의 원리와 맥을 같이한다. 여러 언어 모델을 조합하여 역할 분담형 멀티에이전트 시스템을 이루고, Browser Use와 같은 도구를 활용해 웹 UI 상호작용을 수행하도록 한 것이다. 놀라운 것은 이 팀이 초기 프로토타입을 단 3시간 만에 구현했다고 밝힌 점인데, 이는 Manus의 핵심 아이디어가 재현 가능할 정도로 간결한 아키텍처였음을 방증한다. 나아가 Open Manus 진영은 강화학습(RL)을 통한 LLM 에이전트 성능 개선 연구(OpenManus-RL 프로젝트)까지 병행하며, 짧은 기간에 기술적 완성도를 높여가고 있다.

Manus 코드의 해킹 유출과 Open Manus의 등장은 업계에 두 가지 의미를 남겼다. 첫째, 에이전트 기술의 민주화가 가속화되었다. 이제 폐쇄된 환경에 있던 Manus 수준의 에이전트를 오픈소스로도 구현할 수 있게 되어, 스타트업이나 개인 개발자들도 유사한 서비스를 비교적 쉽게 만들어볼 수 있는 여건이 형성되었다. 둘째, Manus가 촉발한 브라우저 기반 접근의 유효성이 공식적으로 입증되었다. 즉, 대규모 표준화 없이도 현존 도구들을 조합해 상당히 강력한 에이전트를 만들 수 있다는 사실이 공개 사례로 확인된 것이다. 이는 MCP 위주로 흘러가던 에이전트 워크플로우 논의 지형에 하나의 균열을 내며, 보다 다각적인 기술 전략에 대한 고민을 불러일으키고 있다.

MCP 방식 vs 브라우저 기반 방식: 속도, 효율성, 확장성 비교

이제 MCP 기반 접근과 브라우저 기반 접근을 세 가지 측면에서 비교해보자. 두 방식은 목표는 유사하지만 접근 철학이 다르기 때문에, 성능과 구현 양상에서 뚜렷한 장단점을 보인다.

처리 속도 측면: MCP 방식은 통상 정형화된 API 통신을 통해 데이터를 주고받으므로, 필요한 정보만 쿼리해서 가져오기에 낮은 지연과 상대적으로 빠른 응답 시간을 기대할 수 있다. 특히 MCP 서버가 직접 데이터베이스나 애플리케이션과 연결되어 있다면 브라우저 렌더링이나 HTML 파싱 같은 부가 작업 없이 바로 결과를 반환하므로, 한 번의 액션 자체는 가볍다. 반면 브라우저 기반 에이전트는 실제 웹페이지를 불러오고 조작해야 하므로, 페이지 로딩 시간이나 DOM 처리 시간 등 오버헤드가 있다. 예를 들어 Manus가 어떤 작업을 수행할 때 브라우저를 여러 개 띄워 순차적으로 폼 입력, 버튼 클릭을 해야 한다면, API 호출로 한번에 데이터를 얻는 것보다 시간이 더 걸릴 수 있다. 실제로 Manus 초기 버전은 복잡한 주문 작업에 10분 이상 소요되다 실패하는 등 속도 면에서 불안정한 모습을 보이기도 했다. 그러나 브라우저 접근은 대규모 병렬화로 이를 만회할 잠재력이 있다. Manus 사례에서 한 사용자가 관찰한 바에 따르면, Manus 에이전트는 정보를 수집할 때 50개 가까운 브라우저 창을 동시에 열어 광범위한 웹 크롤링을 수행했고, 그렇게 모은 데이터를 일괄 분석해 결과를 빠르게 도출해냈다. 이렇듯 병렬 처리와 동시성을 극대화하면, 여러 데이터 소스를 직렬적으로 호출하는 MCP보다 오히려 전체 완료 시간은 단축될 수 있다. 따라서 속도 측면에서는 작업 단위당 지연은 MCP가 유리하나, 대규모 수집·탐색 작업에서는 브라우저 방식도 충분히 경쟁력을 가질 수 있다. 실제 성능은 작업 유형과 구현 최적화 정도에 크게 좌우될 것이다.
효율성 측면: 여기서 말하는 효율성이란 자원 활용과 개발 효율 두 가지를 모두 고려한다. 자원 활용 측면에서 MCP는 필요 데이터만 주고받기에 대역폭과 연산 효율이 높다. 예를 들어 슬랙 메시지를 읽는 기능을 MCP로 구현하면, 해당 채널의 메시지 텍스트만 JSON으로 받아오지만, 브라우저 접근은 슬랙 웹 클라이언트를 통째로 렌더링하고 자바스크립트를 실행해야 할 수 있다. 따라서 대규모로 서비스할 경우 MCP 쪽이 서버 자원 소모를 최소화하는 데 유리하다. 반면 브라우저 기반은 범용성의 효율이 뛰어나다. 새로운 통합 대상을 추가할 때 MCP는 해당 API 또는 데이터 소스에 맞는 커넥터(MCP 서버)를 개발해야 하지만, 브라우저 방식은 사람이 웹사이트를 이용하듯 바로 상호작용하면 된다. 이는 개발 효율 측면에서 브라우저 접근이 갖는 강점으로, 각 서비스별로 API가 없어도 웹 UI만 있으면 통합 작업을 수행할 수 있으므로 초기 구현이 간편하다. 또한 브라우저 자동화 스크립트는 때로 API 구현보다 직관적일 수 있어, 빠르게 프로토타이핑하기에 좋다. 요약하면 운영 효율성은 MCP 쪽이 높고, 개발 및 적응 효율성은 브라우저 쪽이 높다.
확장성 측면: 여기서는 지원 범위의 확장성과 시스템 스케일링 두 측면을 함께 다룬다. 지원 범위 측면에서 브라우저 기반 접근은 사실상 제한이 없다. 새로운 웹서비스나 UI가 나타나도, 사람이 웹을 쓰는 방식과 동일하게 접근할 수 있으므로 에이전트가 곧바로 다룰 수 있다. 반면 MCP는 해당 서비스 제공자가 API나 MCP 서버를 제공하지 않으면 접근이 불가능하다. 현재 MCP로 연결 가능한 툴들은 빠르게 늘고 있지만, 웹에 존재하는 수많은 서비스를 모두 커버하기에는 한계가 있다. 이때 브라우저 자동화는 일종의 만능 어댑터 역할을 하여, 표준 커넥터의 공백을 메워줄 수 있다. 한편 시스템 스케일링 측면에서는 MCP가 다수 사용자, 다수 작업을 처리하기에 용이하다. MCP 서버들은 각 기능별로 분리되어 있고 stateless하게 설계될 수 있으므로, 마이크로서비스처럼 확장(스케일 아웃)하면 된다. 이에 비해 브라우저 방식은 동시에 많은 세션을 처리하려면 대량의 브라우저 인스턴스를 띄워야 하고, 메모리/CPU 부담이 커진다. 또한 브라우저 자동화는 웹페이지 구조 변화나 네트워크 상태에 취약하여, 대규모 운영 시 안정성 확보가 어렵다는 지적이 있다. 그러나 최근에는 헤드리스 브라우저 기술과 컨테이너 오케스트레이션의 발전으로, 수백 개 이상의 브라우저를 병렬 관리하는 것도 불가능하지 않다. 따라서 확장성 면에서도 각 접근법은 트레이드오프가 존재한다. MCP는 기능 커버리지 확장에 시간이 걸리지만 운영은 안정적이고, 브라우저 방식은 커버리지는 광범위하지만 운영상 튜닝과 모니터링이 더 필요하다. 요약하면, MCP 표준 접근은 구조화된 효율성과 안정성을, 브라우저 접근은 범용 적응력과 신속성을 장점으로 가진다. 각 기업이나 서비스가 추구하는 우선순위(예: 신속한 서비스 론칭 vs. 대규모 안정 운용)에 따라 적합한 방식을 선택하거나 결합하게 될 것이다.

MCP 표준의 기술적 장점과 한계

표준화된 MCP 방식이 주목받은 이유와, 동시에 드러난 한계점을 좀 더 정리해 보자. 기술적 관점에서 MCP의 주요 강점은 다음과 같다:

인터페이스 표준화로 인한 상호운용성: MCP 도입의 가장 큰 이점은 한 번 연결로 여러 곳에서 활용할 수 있다는 것이다. 동일 MCP 프로토콜을 준수하는 한, 어떤 에이전트든 해당 MCP 서버에 요청을 보내 기능을 사용할 수 있으므로, 도구와 에이전트 간 호환성이 극대화된다. 이는 개발자 입장에서 모듈식 에이전트 구성을 가능케 하여, 레고 블록처럼 필요한 기능을 조합해 워크플로우를 구축할 수 있게 한다. 예를 들어 Salesforce용 MCP 커넥터 하나 만들면 사내 챗봇이든 자동 보고 생성 에이전트든 공통으로 활용할 수 있다. 이런 재사용성은 개발 효율과 신뢰성을 동시에 높여준다.
전문 도구 활용 및 성능 최적화: MCP를 통해 LLM 에이전트가 외부 도구를 쓸 수 있게 되면서, AI는 자신의 약점을 보완할 수 있다. 복잡한 계산은 계산기 도구에, 웹 브라우징은 전용 크롤러 도구에 맡기는 식으로 전문화된 툴을 호출함으로써, 에이전트는 본연의 추론에 집중하고 나머지는 도구 성능을 끌어쓴다. 이는 결과적으로 에이전트의 처리 품질과 속도를 향상시킨다. 또한 MCP 서버는 각 기능 수행에 최적화되어 있으므로, HTML 파싱이나 API 호출을 가볍고 신속하게 처리하여 LLM에 필요한 최소 정보만 전달해줄 수 있다. 이런 구조 덕에 MCP 기반 에이전트는 불필요한 리소스 낭비 없이 실시간성과 정확성을 높일 수 있다.
보안과 권한 관리의 용이: 표준 인터페이스를 사용하면 그 위에 일관된 보안계층을 구축하기가 수월하다. 실제 운영 환경에서 AI 에이전트가 여러 시스템에 접근할 때는 인증, 권한, 로깅이 중요한데, MCP는 프로토콜 차원에서 권한 토큰 전달이나 요청 로깅을 체계화할 수 있다. 현재도 MCP 생태계에는 MCP Guardian 등 보안 모니터링 도구가 등장하여 에이전트의 MCP 사용내역을 기록하고 정책을 적용하는 시도가 이뤄지고 있다. 이처럼 표준화된 틀 내에서 보안을 강화할 수 있으므로, 기업들이 AI 에이전트를 도입할 때 데이터 유출이나 오남용을 통제하기가 용이해진다. 반대로 브라우저 자동화는 일일이 웹페이지 단의 보안에 의존해야 하므로, 중앙 관리가 어렵고 위험 통제가 분산되는 문제가 있다.
지속 가능하고 투명한 생태계: MCP는 오픈소스로 명세와 구현체가 공개되어 있어, 누구나 기여하고 개선할 수 있다. 이런 개방성은 빠른 발전을 가능케 할 뿐만 아니라, 특정 업체 종속이 없는 중립적 표준으로서 수명이 길 수 있다. 또한 커뮤니티 주도로 다양한 커넥터가 추가되면서, MCP 서버/클라이언트는 시간이 지날수록 풍부한 에코시스템을 형성하게 된다. 이는 향후 새로운 AI 모델이 나오더라도 기존 MCP 자원을 그대로 활용할 수 있게 해주므로, 투자 보호 측면에서도 이점이 된다. 실제로 Anthropic 외에 OpenAI, MS 등 여러 진영에서 MCP 지원을 논의하는 것은 이 표준을 모두가 윈윈하는 공용 인프라로 바라보고 있기 때문이다. 이러한 장점들에도 불구하고, MCP에는 몇 가지 기술적 한계와 도전과제가 존재한다.
다중 서버 관리의 복잡성: MCP를 도입하면 AI 에이전트는 내부적으로 수많은 MCP 툴 서버들과 통신해야 하는데, 이것을 운영 측면에서 관리하는 일이 만만치 않다. 개발 및 테스트 환경에서는 로컬 MCP 서버로 기능을 붙이는 것이 편리하지만, 막상 프로덕션 환경에서 이를 확장하려면 각 MCP 서버의 가용성, 확장성, 장애 대응을 모두 고려해야 한다. 예컨대 기업이 10개의 MCP 커넥터를 사용한다면, 10개 서비스 모두 상시 동작하고 적절히 스케일링되는지 신경써야 한다. 이는 기존 단일 API 통합보다 복잡한 분산 시스템 운영 문제로 다가올 수 있다.
클라우드/멀티유저 환경에서의 과제: MCP는 원래 개인 PC나 로컬 환경에서도 동작할 수 있게 설계되었지만, 멀티유저 클라우드 서비스로 확장될 때 몇 가지 문제가 나타난다. 예를 들어 상태 유지 여부: MCP 서버들은 기본적으로 상태가 없도록 권장되지만, 현실적으로는 사용자 별 세션이나 컨텍스트를 다뤄야 할 수도 있다. 또한 다중 사용자가 하나의 MCP 서버를 통해 민감 데이터를 요청한다면, 세션 분리와 데이터 접근 제어가 필요하다. 현재 커뮤니티에서는 MCP를 보다 stateless하고 분산 친화적으로 개선하려는 논의가 있지만, 완전히 해결된 문제는 아니다.
도구 활용의 난이도: MCP가 도구 접근을 표준화해줘도, 모델이 그 도구를 제대로 사용할 수 있을지는 별개의 문제다. 과거의 다양한 에이전트 프레임워크 실험에서, LLM이 툴을 언제 어떻게 쓸지 판단하는 로직은 많은 어려움이 따랐다. MCP는 각 도구에 구조화된 스펙과 사용법을 제공함으로써 이 문제를 완화하려 하지만, 결국 프롬프트 설계와 모델의 이해 능력이 핵심이다. 도구 설명이 부실하거나 모델이 장황한 스펙을 해석 못 하면, 연결된 툴이 많아도 제대로 활용하지 못하고 헤맬 수 있다. 이는 MCP 자체의 한계라기보다는 에이전트 설계 전반의 한계이지만, MCP 도입으로 모든 문제가 해결되는 것은 아니라는 점을 보여준다.
UI 및 인간 인터페이스와의 통합 한계: MCP는 디지털 인터페이스상의 행동을 규격화하는 데에는 초점을 두지 않는다. 웹사이트 클릭이나 GUI 조작 같은 부분은 MCP 사양 바깥인데, 정작 많은 실제 업무는 이런 UI 상에서 이뤄진다. Anthropic이 Puppeteer MCP 서버도 제공하고 있지만, 이는 MCP로 UI 문제를 푸는 임시방편일 뿐 근본적으로 MCP가 웹 UI 전체를 구조화해서 이해시키는 것은 아니다. 그래서 MCP만으로는 웹 래핑 방식이 해줄 수 있는 유연한 UI 활용을 모두 대체하기 어렵다. 이 점은 MCP와 브라우저 접근의 협업 필요성으로 이어지는 부분이다. 결국 MCP는 에이전트 통합의 필수 인프라로서 강력한 도구이지만, 만능 해결사는 아니다. 초기의 높은 관심에도 불구하고, 현재 업계에서는 MCP를 신중히 시험하면서 점진적으로 확산시키려는 분위기다 . 다행히 오픈소스 기반이라는 속성상 활발한 커뮤니티가 형성되어 문제 개선이 빠르게 이루어지고 있으므로, 이러한 한계들은 시간과 함께 극복되거나 방향이 조정될 것으로 보인다.

웹 래핑(UI 에이전트) 방식: 빠른 확장성과 구현의 유연함

한편 Web Wrapping 또는 UI 에이전트 방식은 앞서 본 MCP 접근과는 다른 궤도로, 최근 Manus를 통해 그 가치가 재조명되고 있다. 웹 래핑이란 쉽게 말해 사람이 UI에서 하던 일을 AI 에이전트가 똑같이 흉내 내어 수행하도록 하는 방식이다. 과거부터 존재했던 RPA(Robotic Process Automation) 기술이 유사한 개념으로, 전산 시스템에 직접 접근할 수 없을 때 화면 상의 버튼 클릭, 입력 등으로 작업을 자동화했던 것과 맥락을 같이한다. 최근의 AI 발전은 이 UI 자동화를 더 똑똑하고 범용적으로 만들었는데, Manus는 그 대표적인 사례다.

웹 래핑 방식의 가장 큰 강점은 범용성이다. 현대 비즈니스 환경에는 API가 제공되지 않는 레거시 시스템이나 서드파티 웹 애플리케이션이 많다. 이런 것들도 사람이 쓰는 인터페이스가 있는 한, 에이전트가 웹 래핑을 통해 조작할 수 있다. 이를테면 인터넷 뱅킹 사이트에 로그인해서 자료를 다운로드받는 일이나, 경쟁사 웹사이트에서 공개 정보를 스크랩하는 일은, MCP 커넥터가 없더라도 브라우저 자동화로 처리가 가능하다. 따라서 커버할 수 있는 활용 분야의 폭이 대단히 넓다. 기업 입장에서는 기존 시스템을 전면 개조하지 않고도 UI 에이전트를 투입해 업무 자동화를 달성할 수 있기에, 단기간에 에이전트 도입을 확대하기 쉬워진다.

둘째, 웹 래핑은 실제 구현에서의 유연함을 제공한다. 개발자가 명령어 몇 줄로 “이 버튼을 클릭하고, 나타나는 표에서 데이터를 읽어와”라고 지시하면 LLM이 이를 이해해 실제 브라우저에서 수행하도록 할 수 있다. Browser Use와 같은 도구는 웹페이지의 HTML 요소들을 구조화해 제공함으로써, AI가 사전 학습된 포맷을 이용해 UI를 다루게 해준다. 이는 복잡한 API 호출보다는 오히려 인간의 관점에 가까운 방식이기에, 자연어 지시와의 매핑도 수월하다. 예를 들어 “구글 문서에 편지를 쓰고 PDF로 저장해줘”라는 명령을 받으면, AI는 브라우저를 열어 Google Docs 사이트에 접속→문서 작성→파일 저장을 차례로 실행하게 된다. 이런 일련의 행동은 개발자가 일일이 절차를 하드코딩하지 않아도, AI가 맥락에 따라 판단하며 진행할 수 있다. UI 에이전트는 그래서 특정 워크플로우를 만들 때 일일이 API 시퀀스를 설계하는 대신, 목표 지향적인 설계를 가능케 한다. 이는 사용자 요구사항 변화에 기민하게 대응할 수 있음을 의미한다.

또한 웹 래핑 접근은 확장 속도 면에서 매우 빠르다. 앞서 Manus 사례에서 보았듯이, 브라우저 제어 기술의 저변이 넓어지면서 기존에 몰랐던 서비스도 하루아침에 에이전트 작업 대상에 포함시킬 수 있다. 사실 Manus 성공의 숨은 공신 중 하나가 Browser Use라는 오픈소스 툴의 활용인데, Manus 발표 이후 Browser Use의 깃허브 다운로드 수가 일주일 새 5천 건에서 2만8천 건으로 폭증하며 개발자들의 큰 호응을 얻었다. 이는 Manus가 Browser Use를 어떻게 활용했는지 소개한 게시물이 SNS상에서 240만 뷰를 기록하며 입소문을 탄 덕분으로, 웹 에이전트에 대한 관심이 개발자 커뮤니티에 급격히 확산되었음을 보여준다. Browser Use를 만든 개발자들도 “2025년에 웹 에이전트가 큰 흐름이 될 것으로 보고 작은 프로젝트로 시작했는데, 금세 로켓처럼 성장했다”라고 놀라움을 표했다. 실제로 이들은 해당 툴을 브라우저 에이전트의 기반 층으로 자리매김시켜, “올해 말이면 웹 에이전트가 인간 사용자를 수로 앞지를 것”이라는 대담한 전망까지 내놓고 있다. 다소 과장된 예측이지만, 그만큼 UI 에이전트 방식이 폭발적인 성장 잠재력을 지녔다고 업계가 판단하고 있다는 방증이다.

웹 래핑 접근의 구현 유연성은 특히 사용자 경험(UX) 측면에서 매력적이다. 에이전트가 사람과 동일한 화면을 보며 작업하기 때문에, 필요하면 중간 과정을 사람이 개입해서 확인하거나 수정하기가 쉽다. 예를 들어 MCP 기반으로 API 호출만 하는 에이전트는 내부 진행 상황이 추상적이지만, 브라우저를 통해 실행하는 에이전트는 사람이 그 진행 화면을 모니터링할 수 있다. 이는 휴먼-에이전트 협업을 자연스럽게 해주는 장점이다. 또한 웹 래핑 에이전트는 사람과 동일한 출력(예: 웹 리포트 화면)을 만들어내므로, 결과물 인계도 수월하다.

물론 웹 래핑 방식도 한계가 없진 않다. UI 변경에 대한 취약성, 브라우저 자동화의 환경 의존성, 대규모 운영 시 리소스 과다 사용 등은 기술적으로 극복해야 할 과제다. 그러나 LLM의 강력한 자연어 처리와 추론 능력이 이러한 취약점을 상당 부분 보완해준다. 예컨대 UI가 약간 바뀌어도 AI가 문맥상 비슷한 버튼을 찾아내도록 프롬프트 엔지니어링할 수 있고, 에러가 발생하면 유연하게 재시도하거나 예외 처리하도록 설계할 수 있다. 즉, 과거의 단순 RPA보다 훨씬 유연하고 지능적인 UI 자동화가 가능해진 것이다. 이로써 웹 래핑 방식은 기술적으로 충분히 실용화 가능한 수준에 올라섰으며, Manus 이후 업계 전반에 “일단 브라우저로 시도해보자”는 분위기를 형성하게 될것으로 보여진다.

기술적 시사점: 브라우저 기반 접근의 단기적 파급력

Manus와 Open Manus의 등장은 단기적으로 에이전트 워크플로우 시장의 급속한 확대를 이끌 가능성이 크다. 앞서 언급한 웹 래핑 방식의 강점 덕분에, 기업들은 복잡한 표준 도입 절차 없이도 비교적 손쉽게 AI 에이전트를 업무에 시범 적용해볼 수 있게 되었다. 예를 들어 어떤 회사가 고객 지원에 AI를 도입하려 할 때, MCP 표준을 기다리거나 모든 시스템에 API를 마련하는 대신, 기존 웹 고객지원 포털을 자동화하는 에이전트를 투입해 단기간에 PoC(개념증명)를 해볼 수 있다. 이런 사례가 성공적으로 쌓이면, 업계 전반에 에이전트 활용에 대한 심리적 진입장벽이 낮아지고 수요가 증폭될 것이다.

현재 이미 조짐이 나타나고 있다. Deloitte 등의 조사에 따르면 기업들의 절반 정도가 향후 2~3년 내에 AI 에이전트를 현업에 도입할 것으로 예상되며, 2029년에는 전세계 AI 에이전트 시장 규모가 420억 달러에 달할 것으로 전망된다. 이러한 거대한 성장 예측은 MCP 등장 이전부터 제기되었지만, Manus 사건을 계기로 그 시계가 더욱 앞당겨졌다는 평가가 나온다. 특히 중국 정부가 Manus와 같은 자국 AI 에이전트를 적극 지원하려는 움직임을 보이고 (예: Manus가 중국 규제당국에 정식 등록되고 대형 기술 기업과 파트너십 체결), 서구권에서도 유사한 종합 에이전트가 속속 등장할 것이라는 관측이 있다. 다시 말해, Manus가 촉발한 에이전트 경쟁 구도가 전세계적으로 형성되어 기술 발전의 가속도가 붙고 있는 것이다.

단기적으로 브라우저 기반 접근의 파급력이 큰 이유는, 사용자 경험 면에서 매력적이기 때문이다. 누구나 쓰는 웹 인터페이스에서 AI가 인간과 비슷하게 행동하는 모습은 이해하기 쉽고 데모 효과도 크다. 이는 경영진 설득이나 투자 유치 관점에서도 도움이 되어, 관련 스타트업과 프로젝트에 자금이 몰릴 것으로 예상된다. 실제로 Manus 공개 이후 AI 에이전트 분야에 크고 작은 투자 소식이 이어지고 있다. Open Manus와 유사한 오픈소스 에이전트 프로젝트들이 우후죽순 생겨나는 한편, 전통 RPA 업체들도 생성형 AI와 결합한 UI 에이전트 솔루션을 잇따라 발표하며 시장 선점을 노리고 있다. 요컨대 에이전트 워크플로우의 춘추전국시대가 개막된 셈이다.

이러한 급성장은 한편으로 혼란과 시행착오도 수반할 것이다. 브라우저 기반 에이전트들은 초기엔 화려한 데모로 각광받지만, 실제 현업 적용에서는 예기치 않은 문제(웹사이트 정책 변경, 데이터 품질 이슈 등)로 어려움을 겪을 수 있다. 따라서 기업들은 단기적 실험을 통해 가능성과 한계를 명확히 파악하는 것이 중요하다. 다행히 웹 래핑 방식은 빠르게 시도해보고 교훈을 얻기 좋으므로, 작은 프로젝트부터 적용해 “작게 시작해 빨리 실패하고 배운 후 크게 확장”하는 애자일 접근이 가능하다. 이는 MCP 표준을 기다리며 시간을 보내는 것보다 나은 전략일 수 있다. 결과적으로 단기적 파급력 측면에서 브라우저 기반 접근은 에이전트 도입의 저변 확대를 주도하고, 이를 통해 업계 전체의 학습곡선을 가속화하는 긍정적 효과를 가져올 것으로 기대된다.

향후 전망: MCP와 브라우저 접근의 공존 및 하이브리드 방향

에이전트 기술의 미래는 MCP 표준 접근과 브라우저 기반 접근이 공존하는 하이브리드 형태로 진화할 가능성이 높다. 두 접근법 모두 일장일단이 있기 때문에, 상호 보완을 통해 각각의 강점을 살리는 쪽으로 발전 방향이 잡힐 것으로 보인다.

단기적으로 브라우저 기반 접근이 폭넓은 적용을 이끌겠지만, 장기적으로는 MCP와의 통합이 불가피하다. 이는 양 진영이 경쟁 관계라기보다는 문제 영역이 다소 다르기 때문이다. MCP는 데이터 연결의 표준화, 브라우저 접근은 UI 상호작용의 범용화라는 별개의 가치를 지니므로, 최종적으로 에이전트 에코시스템에는 두 가지 모두가 필요하다. 예를 들어 한 에이전트가 사내 데이터베이스 질의는 공식 MCP 커넥터를 통해 수행하면서, 동시에 외부 웹사이트 정보 수집은 브라우저 자동화로 처리하는 식으로 혼합 워크플로우를 구성할 수 있을 것이다. 실제로 Anthropic이 발표한 MCP 서버 목록에 Puppeteer 커넥터를 포함시킨 것은, 표준 프로토콜 내에 웹 브라우징 기능을 흡수하려는 시도로 해석된다. 향후 이러한 노력이 확장되어, MCP 표준 내에서 웹 래핑을 위한 서브 프로토콜이나 권고안이 마련될 가능성도 있다. 그렇게 되면 브라우저 기반 접근도 MCP 생태계의 일부로 편입되어 보다 체계적인 지원을 받게 될 것이다.

반대로, 브라우저 기반 에이전트 쪽에서도 MCP를 활용하는 방향으로 진화가 예상된다. 현재 Open Manus 같은 프로젝트들은 신속히 기능 구현에 집중하느라 표준보다는 편의 위주로 구성되어 있지만, 차츰 안정화 단계에 이르면 내부 모듈을 MCP 호환으로 바꾸는 작업을 시도할 수 있다. 예컨대 Open Manus의 데이터 수집 모듈이나 이메일 발송 모듈을 MCP 서버 호출로 대체하면, 나중에 더 좋은 모델이나 서비스가 등장했을 때 쉽게 교체 가능해진다. 이는 오픈소스 커뮤니티가 추구하는 모듈화와 호환성 철학과도 일치한다. 이미 LangChain 같은 프레임워크의 MCP 어댑터가 등장한 만큼, 미래의 에이전트 플랫폼들은 표준을 지원하는 범용 에이전트 + 특수 상황에서의 UI 자동화라는 하이브리드 구성을 기본 탑재할 것으로 전망된다.

이러한 하이브리드 에이전트는 구체적으로 어떻게 작동할까? 예를 들어 사용자 지시를 받은 에이전트는 우선 MCP 카탈로그를 조회해 적절한 툴이 있는지 찾는다. 있어서 사용할 수 있으면 MCP를 통해 작업하고, 없거나 실패하면 플랜 B로 브라우저 자동화를 시도하는 식이다. 또는 반대로, 기본은 인간 행동 방식으로 브라우저를 쓰되, 명백히 API로 하는 게 나은 작업은 MCP로 최적화하는 루틴을 둘 수도 있다. 궁극적으로는 AI 에이전트 스스로가 각 방법의 이점을 판단해 적응적으로 양쪽을 병용할 수 있게 발전할 것이다. 이는 마치 사람에게 PC 작업을 가르칠 때, 단축키가 있는 건 알려주면 빠르게 처리하고 그렇지 않은 건 마우스로 직접 하도록 가르치는 것과 유사하다. AI 에이전트도 툴박스에 “MCP 표준 도구”와 “브라우저 에이전트 도구”를 모두 갖춘 상태로, 상황에 맞게 가장 효율적인 경로를 선택하는 지능을 갖춰갈 것으로 기대된다.

산업적인 측면에서도 MCP와 브라우저 접근의 공존은 리스크 완화와 포괄적 서비스 제공 차원에서 필요하다. 기업 입장에서는 표준 기반 솔루션은 장기적 안정성을, 브라우저 기반 솔루션은 단기적 효과를 준다. 둘 중 하나만 택하는 것은 극단일 수 있으며, 균형 잡힌 전략이 요구된다. 예컨대 내부 중요 시스템에 연결되는 부분은 MCP로 엄격히 관리하면서, 외부 저위험 작업에는 브라우저 에이전트를 활용하는 식으로 이원화할 수 있다. 시간 흐름에 따라 두 접근법의 경계는 점차 옅어지고, 인력과 기술의 융합도 이뤄질 것이다. 이미 MCP 분야 전문 개발자와 RPA/웹자동화 전문가가 한 팀으로 협업하는 사례도 나타나고 있어, 크로스도메인 지식을 갖춘 인재 수요가 높아질 것으로 보인다. 마지막으로, 에이전트 기술의 궁극적인 발전 방향은 단순히 MCP vs 브라우저의 선택을 넘어 고차원적인 자율성을 향해 갈 것이다. MCP와 브라우저 접근은 모두 에이전트의 행동(Action) 부분에 해당하는 기술들이다. 향후 에이전트가 진정한 자율 에이전트로서 인간 수준의 유연성을 얻으려면, 지각(Observation), 추론(Reasoning), 메모리(Memory), 학습(Reflection) 등 여러 요소가 함께 발전해야 한다. MCP와 브라우저 기반 혁신은 그 중 환경과의 인터페이스 측면에서 크게 진일보한 것이지만, 다른 구성 요소들과 조화를 이루어야 비로소 의미있는 결과를 낳는다. 따라서 미래에는 MCP로 다양한 데이터에 접근하고, 브라우저로 실제 행위를 수행하며, 고도화된 플래닝 알고리즘으로 둘을 조합하고, 수행 결과를 메모리와 피드백으로 축적하여 점점 똑똑해지는 종합 에이전트 플랫폼들이 등장할 것이다. 결국 MCP 표준화된 세계와 브라우저 에이전트의 세계는 통합되어, 사람의 두 손과 두 발처럼 AI 에이전트의 외부 활동을 담당하는 필수 수단으로 자리잡을 것이다.

결론: 에이전트 기술 혁신의 방향성

정리하면, 2025년 현재 에이전트 기반 워크플로우 기술은 MCP 표준화라는 체계적 진화와 브라우저 기반이라는 창의적 돌파구가 공존하는 양상이다. MCP는 에이전트를 디지털 생태계와 깊이 연결시켜줄 든든한 교량이며, 브라우저 접근은 현실 세계의 복잡성을 유연히 가로지르는 만능열쇠와 같다. 기술 업계 종사자들은 이 두 흐름을 상호 배타적으로 보기보다는, 단기 vs 장기, 개방성 vs 안정성 등 관점에서 균형잡힌 시각을 가질 필요가 있다.

단기적으로는 Manus가 촉발한 브라우저 기반 접근의 붐을 활용하여, 다양한 실용 사례들을 발굴하고 에이전트 도입 효과를 극대화하는 것이 중요하다. 이를 통해 축적된 경험은 표준화에도 귀중한 피드백으로 작용할 것이다. 중장기적으로는 MCP를 중심으로 한 표준 인프라를 탄탄히 다져서, 에이전트 기술이 신뢰성과 보안성을 갖추고 주류 IT 아키텍처에 녹아들도록 해야 할 것이다. 이는 개별 기업의 노력뿐 아니라 업계 전반의 협력과 거버넌스가 필요한 부분으로, 오픈소스 커뮤니티와 컨소시엄 등이 지속적으로 역할을 할 것으로 기대된다.

궁극적으로, 에이전트 워크플로우의 미래는 특정 접근법의 승리가 아닌 융합과 통합의 방향으로 흐를 것이다. MCP와 브라우저 접근의 병존은 그 과도기적 모습이며, 최종적으로는 사용자에게 보이지 않는 형태로 가장 적절한 방식이 선택되어 동작하는 에이전트들이 우리 업무와 생활 속에 자연스럽게 스며들 것이다. 오늘날의 변화는 그 거대한 흐름의 초기 신호일 뿐이다. 기술 트렌드를 면밀히 살피고 유연하게 대처하는 기업만이 이 에이전트 혁명에서 주도권을 잡을 수 있을 것이다. 앞으로 수년간 우리는 MCP 표준의 성숙, 웹 자동화의 고도화, 그리고 이 둘을 아우르는 혁신적인 에이전트 아키텍처의 등장을 목격하게 될 것이다. 지금은 그 격변의 서막에 서 있으며, 방향을 통찰하고 대비하는 자에게는 새로운 기회의 창이 열리고 있다.