브라우저 속 AI 에이전트: 웹 경험을 재정의할 WebMCP, 과연 혁명일까? (데모 🚀)
2026. 9. 22.
브라우저 속 AI 에이전트: 웹 경험을 재정의할 WebMCP, 과연 혁명일까? (데모 🚀)
솔직히 요즘은 글 쓸 여유가 전혀 없었습니다. 머릿속이 꽉 차 있었거든요. 몇 가지 이유가 있었지만, 가장 큰 건 AGNTCon + MCPCon Europe 컨퍼런스에서 WebMCP에 대해 발표한 경험이었죠.
발표는 어땠냐고요? 정말 좋았습니다! 많은 분이 찾아주셨고, 질문도 쏟아졌어요. 이보다 더 바랄 게 있을까요? 😅 컨퍼런스 자체도 훌륭해서, 몇 개의 글을 더 쓸 만한 영감을 가득 안고 돌아왔습니다. 아직 멋진 사진은 없지만, 다음 주쯤에는 올릴 수 있지 않을까 싶네요!
2,000명이 넘는 참석자가 모인 행사였던 만큼, 청중의 스펙트럼은 엄청나게 다양했습니다. 복잡한 멀티 에이전트 아키텍처에 깊이 파고들고 싶어 하는 분들도 계셨지만, 이미 꽤 괜찮은 제품에 AI 기능을 추가해서 어떻게 더 개선할 수 있을지 궁금해하는 분들도 많았어요. 제 WebMCP 발표는 주로 이 두 번째 그룹의 관심을 사로잡았습니다.
WebMCP는 도대체 뭘까요?
간단히 말해, WebMCP는 웹사이트가 AI 에이전트가 호출할 수 있는 도구를 명시적으로 노출하도록 해주는 실험적인 브라우저 API입니다. 이전에 WebMCP 라이브 데모: 웹사이트 구축 방식, 이렇게 바뀔까?라는 글에서 이미 다룬 내용이라 너무 많이 반복하고 싶지는 않네요.
물론, 그 글은 3개월도 더 된 자료라 에이전트 AI의 세계에서는 문법이 이미 구식입니다. xD 다행히 요즘은 최신 문법을 빠르게 확인하는 게 그리 어렵지 않고, 앞으로도 몇 번 더 바뀔 가능성이 크다는 점을 염두에 둬야죠. 😅 하지만 핵심 아이디어는 여전히 유효합니다.
네, 아직 초기 단계의 기술인 건 맞습니다. 그런데 컨퍼런스에서 WebMCP를 개발하는 분 중 한 명(안녕, 도미닉!)을 만나 이야기를 나눠보니, 내년 1월이나 2월쯤에는 최소한 Chromium 환경에서 상당히 안정화될 거라고 하더군요. 그러니 시간은 흐르고 있습니다! 제가 실무에서 이 부분을 테스트해 봤을 때, 기존 웹 서비스에 AI 기능을 통합하려는 기업들이 특히 반길 만한 접근 방식이라고 느꼈습니다. 전체 시스템을 갈아엎을 필요 없이 '추가적인 능력'을 부여하는 거니까요.
WebMCP는 '진정한' MCP와는 조금 달라요
"클래식" MCP(아직 이렇게 어린 기술을 '클래식'이나 '전통적'이라고 부를 자격이 있는지 모르겠지만요 🤣)와 달리, WebMCP는 브라우저 컨텍스트 내에서 작동합니다.
웹사이트가 열려 있어야 하고, 인증이 필요한 경우 사용자가 로그인해야 합니다. 그래야만 에이전트가 해당 페이지에서 노출된 도구들을 호출할 수 있어요. 이는 에이전트 브라우저나 Chrome 확장 프로그램 등을 통해 WebMCP를 활용할 수 있다는 뜻이죠. 흥미롭게도 최근 ChatGPT는 자체 내장 브라우저에서 WebMCP 기반 사이트 도구 지원을 추가했는데, 이 기술이 분명히 주목받고 있다는 증거입니다!
그래서 제 생각에 WebMCP의 가장 흥미로운 사용 사례는 단순히 웹사이트를 스크래핑하는 멀티 에이전트 시스템이 아닐 수도 있습니다. 저는 이를 일반 사용자들이 이미 사용하는 제품과 상호작용하는 방식을 돕는 도구로 보고 있습니다. 물론, 개발자 10명에게 새로운 API를 주면 아마 11가지 아이디어가 나올 테지만요. 😉
제 비전 있는 리더를 소개합니다: AI CEO 시뮬레이터
어떤 분들은 기억하시겠지만, 제 WebMCP 데모는 지루한 addToCart() 예시가 아닙니다. 제가 애정하는 비전 있는 리더, 바로 AI CEO 시뮬레이터입니다. AI가 우리 회사를 운영하게 뒀을 때 어떤 일이 벌어질지 보여주는 거죠.
스크린샷에서 보시듯이, 현금, 월간 매출, 직원 수, 생산성 문제, 직원 행복도, 그리고 당연히 '하이프 레벨' 같은 전형적인 스타트업 지표들이 있습니다.
또한 AI 도입, 에이전트로 피벗, 러스트로 다시 작성, 직원 해고, 직원 고용 등과 같은 이사회 결정 옵션도 있습니다.
즉, 전형적인 스타트업 경영 시뮬레이션입니다. 그리고 물론, 활동 로그도 있고요.
중요한 점은 이것이 여전히 완전히 '정상적인' 웹사이트라는 것입니다. 직접 클릭하고 수동으로 모든 기능을 사용할 수 있죠. 제가 WebMCP를 좋아하는 이유 중 하나가 바로 이겁니다. 기존 웹사이트에 추가적인 기능을 부여하는 것이지, AI를 위해 제품을 완전히 재구축할 필요가 없다는 점이죠.
GitHub: https://github.com/sylwia-lask/ai-ceo-webMCP 데모: https://sylwia-lask.github.io/ai-ceo-webMCP/
좋아요, 그런데 그 도구들을 어떻게 호출하나요?
모든 것이 훌륭하게 들리지만, 한 가지 현실적인 문제가 있습니다. 그 도구들을 실제로 어떻게 호출하느냐는 거죠? 특히 컨퍼런스 발표 중에 실시간으로 호출하고 싶을 때는 더욱 흥미로운 문제가 됩니다.
물론 ChatGPT나 공개된 확장 프로그램을 통해 가능하지만, 클라우드 기반 솔루션은 인터넷 접속이 필수적입니다. 인터페이스도 발표용으로 항상 이상적인 건 아니죠. 사람들이 큰 화면으로 데모를 볼 때는 모든 것이 크고 따라가기 쉬워야 하니까요.
그리고 당연히, 저는 로컬 모델로의 폴백(fallback)을 원했습니다!
그래서 WebMCP 로컬 에이전트라는 Chrome 확장 프로그램을 직접 만들었습니다.
GitHub: https://github.com/sylwia-lask/webmcp-local-agent
아직 Chrome 웹 스토어에 게시되지는 않았지만, 언젠가 개발자 등록비 5달러를 지불할 날이 오겠죠. 😅💸 지금은 관심 있는 분들은 소스 코드를 다운로드해서 로컬에서 실행해볼 수 있습니다. 솔직히 말씀드리면, 라이브 데모를 준비하면서 클라우드 서비스의 불안정성에 대한 걱정이 가장 컸습니다. 특히 인터넷 환경이 완벽하지 않은 컨퍼런스에서는 더욱 그랬죠. 그래서 오프라인 환경에서도 안정적으로 시연할 수 있는 대안이 절실했습니다.
정말 에이전트가 맞나요?
그렇다면 이 플러그인 — 혹은 에이전트 — 는 실제로 무엇을 할까요?
매우 간단합니다. 사용자의 의도를 받아들이고, 현재 페이지에서 사용 가능한 WebMCP 도구들을 확인한 다음, 적절하다고 판단되는 도구들을 호출합니다.
에이전트가 기본적으로 루프에 불과하다는 사실은 우리 모두 알고 있죠. 이 부분에 대해서는 AI 에이전트의 숨겨진 비밀 (데모 🚀)이라는 글에서 더 자세히 다루기도 했습니다.
이 확장 프로그램도 정확히 그렇게 작동합니다. 모델은 사용자의 의도와 사용 가능한 도구들을 받아들여 무엇을 호출할지 결정하고, 결과를 받은 다음 다음에 무엇을 할지 다시 결정할 수 있습니다. 기본적으로 에이전트는 이 루프를 최대 10번 반복하지만, 설정에서 변경할 수 있습니다.
보시다시피, 이것은 단순한 멋진 이름을 가진 챗봇이 아닙니다. 진정한 작은 에이전트인 셈이죠.
살짝 이기적인 동기도 유용한 결과로 이어질 수 있습니다
네, 제 원래 동기는 꽤 단순했고 어쩌면 약간 이기적이기도 했습니다. 😉 하지만 의심스러운 동기에서도 좋은 결과가 나올 수 있죠. 골룸조차도 반지의 제왕의 해피 엔딩에 기여했으니까요. xDDD
제 확장 프로그램은 로컬 모델로 실행될 수 있기 때문에, 로컬 프로바이더를 사용할 경우 프롬프트와 모델 추론이 사용자 머신에 그대로 머무릅니다. 이는 모든 상호작용을 클라우드 모델로 전송하는 것과 비교했을 때 매우 흥미로운 프라이버시 이점을 제공합니다.
이는 또 다른 문제 해결에도 도움이 됩니다. AI 모델에 대한 접근성이 모든 곳에서 동일하게 신뢰할 수 있는 것은 아니죠. 제 친애하는 DEV 친구 @dannwaneri도 얼마 전 이 문제를 언급했습니다. 유럽에서 우리가 꽤 좋은 인프라와 클라우드 AI 서비스 접근성을 가지고 있다고 해서, 전 세계 모든 곳의 상황이 똑같이 좋다는 의미는 아닙니다.
로컬 모델은 우리에게 또 다른 선택지를 제공합니다.
세 가지 제공자, 하나의 에이전트
보시다시피, 제 WebMCP 플러그인은 현재 세 가지 모드를 지원합니다.
첫 번째는 Google의 Prompt API로, Chromium이 관리하는 Gemini Nano를 사용합니다. 모델이 한 번 다운로드되면 추론은 로컬에서 이루어지며, Google이나 다른 제3자에게 프롬프트를 전송하지 않고 API 키도 필요 없습니다.
두 번째 옵션은 Ollama로, 역시 로컬에서 실행됩니다. 제 경우에는 Llama 3.1을 사용하고 있지만, 원한다면 다른 모델을 선택할 수도 있습니다. 이상적으로는 도구 호출(tool calling)에 잘 작동하는 모델을 선택하는 것이 좋겠죠.
그리고 마지막으로 하나의 클라우드 제공자가 있습니다. 제 경우에는 오래된 Gemini Flash 모델인데, 이는 API 키가 필요합니다. 솔직히 말해서, 현재로서는 클라우드 모델이 탁월한 기능과 속도를 얻는 가장 쉬운 방법인 경우가 많으니까요. 문제는 항상 사용 가능하지는 않다는 점이죠.
물론, 원하는 대로 다른 모델이나 제공자를 추가할 수 있습니다. 확장 프로그램 소스 코드에 몇 줄만 추가하면 됩니다. ☺️
그리고 네, 로컬 모델도 실제로 작동합니다
보시다시피, 로컬 제공자들도 놀랍도록 잘 작동합니다.
여기 Google의 Prompt API 결과입니다:
그리고 여기 Llama 3.1 결과입니다:
하지만 경고 하나 드리자면, Llama 3.1은 — 드물게 발생하긴 하지만 — 가끔 JSON 대신 마크다운이나 추가적인 "도움이 되는" 주석을 제가 정말로 원했다고 판단할 때가 있습니다. 그게 바로 LLM과의 작업이 주는 즐거움이죠. 😅
또한, 플러그인이 기본적으로 에이전트 루프를 최대 10번 반복하도록 허용한다는 점을 다시 한번 언급할 가치가 있습니다. 이 숫자는 설정에서 늘리거나 줄일 수 있습니다.
잠깐만요. 이거 위험한 거 아닌가요?
WebMCP에 대해 자주 듣는 우려 중 하나는 우리가 상호작용 모델을 바꾸고 있다는 점입니다. 사용자는 더 이상 자신이 원하는 모든 것을 명시적으로 클릭하지 않습니다. 대신 '의도'를 표현하죠.
그러면 모델은 계획을 세우고, 도구를 호출하며, 우리는 그 결과에 대처해야 합니다. 만약 우리가 단순히 거기서 멈춘다면, 그것은 재앙의 지름길이 될 수 있습니다.
listEmployees()와 같이 비교적 무해한 도구도 있지만, fireEmployees()와 같이 훨씬 더 심각한 결과를 초래할 수 있는 도구들도 있습니다.
제 AI CEO가 저에게 묻지도 않고 회사 절반을 해고하여 '활주로'(자본 소진 기간)를 개선하기로 결정했다는 사실을 알고 싶지는 않을 겁니다. 🤯
중대한 작업에는 확인이 필요합니다
다행히 WebMCP 개발자들은 커뮤니티의 의견에 귀 기울이고 있으며, API는 이제 consequentialHint와 같은 유용한 도구 주석을 포함하고 있습니다. 제 플러그인도 이를 지원합니다.
이러한 최신 WebMCP 기능 지원은 사용 중인 Chromium 버전과 실험적인 WebMCP 가용성에 따라 달라지므로, API가 아직 진화 중인 동안 테스트하는 경우 필요한 WebMCP 지원이 활성화된 충분히 최신 버전의 Chrome/Chromium을 실행 중인지 확인하세요.
이제 직원들을 해고하는 시도를 해봅시다.
보시다시피, 저희 에이전트는 도구 호출이 '중대한' 것으로 표시되어 있음을 알아차리고, 진행하기 전에 확인 프롬프트를 표시했습니다. 사용자는 이 작업을 승인하거나 거부할 수 있습니다.
AI CEO가 회사를 재편하기 시작할 때는 아마도 현명한 선택일 겁니다. 😉
그리고 물론, 이 모든 것은 Kiro로 만들었습니다
그리고 자존심 있는 AWS 커뮤니티 빌더로서, 이 모든 것을 세계 최고의 IDE인 Kiro의 도움을 받아 만들었습니다. 😅 고백하자면, 처음 Kiro를 설치한 건 Claude Code 비용을 절약하고 싶어서였습니다. 하지만 이제는 @corey_aws가 내일 당장 저를 커뮤니티 빌더 프로그램에서 제외시킨다고 해도, 기꺼이 제 주머니를 털어 Kiro를 계속 사용할 겁니다. 😂
Kiro는 믿을 수 없을 만큼 다양한 모델을 선택할 수 있게 해줄 뿐만 아니라, 제가 정말 높이 평가하게 된 스펙 기반 개발(spec-driven development)도 지원합니다. 컨퍼런스 발표 불과 두 시간 전에 처리해야 했던 마지막 API 변경 사항까지 포함해서, 끊임없이 변화하는 WebMCP API를 놀랍도록 잘 처리해 주었죠. 😅
그러니 AWS: 훌륭합니다. 당신이 저를 사로잡았네요. 👏
어쩌면 우리는 혁명이 필요 없을지도 모릅니다
보시다시피, 사용자 친화적이고 에이전트 친화적인 환경을 만들기 위해 기존 프로젝트에 거대한 아키텍처 변경이나 완전한 혁명이 반드시 필요한 건 아닙니다.
우리 웹사이트는 여전히 웹사이트일 수 있습니다. 사람들은 여전히 버튼을 클릭하고, 양식을 채우고, 이전과 똑같이 UI를 사용할 수 있죠. WebMCP는 단지 에이전트에게 웹사이트와 상호작용하는 또 다른 구조화된 방법을 제공할 뿐입니다.
컨퍼런스에서 어떤 분이 이런 말을 했습니다. 이것은 말을 자동차로 대체하는 것과 같은 혁명이 아니라고요.
그냥...
더 빠른 말일 뿐이라고요.
하지만 어쩌면 '더 빠른 말'이 지금 우리에게 정확히 필요한 것일 수도 있지 않을까요?
원문: https://dev.to/sylwia-lask/what-if-your-ai-agent-never-had-to-leave-the-browser-demo--5g 수집일: 2026-09-22 02:04:54