브라우저 '속' AI 에이전트의 시대: WebMCP로 본 웹의 미래 (데모 🚀)

솔직히 말하면, 요즘 글을 쓸 정신이 없었습니다. 여러 이유가 있었지만, 가장 큰 이유는 AGNTCon + MCPCon Europe 컨퍼런스에서 WebMCP에 대해 강연을 해야 했기 때문이죠.

어땠냐고요? 정말 좋았습니다! 많은 분이 찾아와 주셨고, 질문도 끊이지 않았으니 더 바랄 게 있을까요? 😂 컨퍼런스 자체도 훌륭했고, 덕분에 앞으로 몇 개의 글을 더 쓸 수 있을 만큼 충분한 영감을 얻었습니다. 아직 멋진 사진은 없지만, 다음 주쯤에는 올라올지도 모르겠네요!

2,000명이 넘는 참석자가 모인 행사였던 만큼, 청중의 스펙트럼은 상상 이상으로 넓고 관심사도 각양각색이었습니다. 정교한 멀티 에이전트 아키텍처를 탐구하려는 분들 옆에는, 이미 꽤 괜찮은 자사 제품에 AI 기능을 어떻게 더할 수 있을지 고민하는 분들도 많았죠.

이 두 번째 그룹에 속한 꽤 많은 분이 제 WebMCP 강연에 참석하셨습니다.

WebMCP, 도대체 뭘까요?

간단히 말해, WebMCP는 웹사이트가 AI 에이전트가 호출할 수 있는 도구를 명시적으로 노출하도록 허용하는 실험적인 브라우저 API입니다. 이전에 '미래의 웹사이트는 이렇게 만들어질까? WebMCP 라이브 데모'라는 글에서 자세히 다뤘으니, 너무 길게 반복하진 않겠습니다.

그 글이 벌써 3개월도 더 되었는데, 에이전트 기반 AI의 세계에서는 문법이 이미 구식이 되었다는 뜻이죠. 🤣 다행히 요즘은 최신 문법을 빠르게 확인하는 게 그리 어렵지 않고, 어차피 앞으로도 몇 번 더 바뀔 수 있습니다. 핵심 아이디어는 여전히 그대로입니다.

네, 아직은 초기 단계의 기술이 맞습니다. 하지만 컨퍼런스에서 WebMCP를 개발하는 분 중 한 명(안녕, 도미닉!)을 만났는데, 내년 1월이나 2월쯤에는 적어도 Chromium에서 상당히 안정화될 거라고 하더군요. 그러니 시간은 흐르고 있습니다!

WebMCP는 '진짜' MCP와 조금 다릅니다

'클래식' MCP(아직 이처럼 어린 기술에 '클래식'이나 '전통적'이라는 수식어를 붙일 자격이 있는지 모르겠지만 🤣)와 달리, WebMCP는 브라우저의 컨텍스트 안에서 작동합니다.

웹사이트가 열려 있어야 하고, 인증이 필요하다면 사용자가 로그인한 상태여야 합니다. 그래야만 에이전트가 해당 페이지에서 노출된 도구들을 호출할 수 있죠. 즉, 에이전트용 브라우저나 Chrome 확장 프로그램 등을 통해 WebMCP를 활용할 수 있다는 뜻입니다. 흥미롭게도 최근 ChatGPT의 내장 브라우저가 WebMCP 기반 사이트 도구를 지원하기 시작했는데, 이 기술이 확실히 탄력을 받고 있다는 증거겠죠!

이것이 제가 WebMCP의 가장 흥미로운 사용 사례가 단순히 웹사이트를 스크래핑하는 멀티 에이전트 시스템에만 국한되지 않는다고 보는 이유이기도 합니다. 저는 이것이 일반적인 일상 사용자들이 이미 쓰고 있는 제품들과 상호작용하는 방식을 돕는 데 훨씬 더 유용하다고 생각해요. 제가 실무에서 고객 서비스 데스크를 담당하는 분들과 이야기 나눠봤을 때, 단순 반복 작업에 AI를 도입하고 싶어 하는 니즈가 정말 컸습니다. WebMCP는 이런 지점을 정확히 파고들 수 있다고 봅니다. 물론, 개발자 열 명에게 새로운 API를 주면 아마 열한 가지 다른 아이디어가 나올 테지만요. 😉

제 비저너리 리더를 소개합니다: AI CEO 시뮬레이터

기억하시는 분들도 있겠지만, 제 WebMCP 데모는 지루한 addToCart() 예제가 아닙니다. 바로 제가 아끼는 비저너리 리더, AI CEO 시뮬레이터입니다. AI에게 우리 회사를 운영하게 하면 어떤 일이 벌어질지 보여주죠.

스크린샷에서 보시듯, 전형적인 스타트업 지표들이 모두 있습니다: 현금, 월 매출, 직원 수, 생산 사고, 직원 행복도, 그리고 물론, 'Hype Level'까지요.

이사회 결정으로는 AI 도입(Adopt AI), 에이전트로 피벗(Pivot to Agents), 러스트로 재작성(Rewrite in Rust), 직원 해고(Fire Employees), 직원 고용(Hire Employees) 등이 있습니다.

말하자면, 전형적인 스타트업 경영 시뮬레이션인 셈이죠.

그리고 당연히 활동 로그도 있습니다.

중요한 점은, 이 모든 것이 여전히 완전히 정상적인 웹사이트라는 겁니다. 직접 클릭하고 수동으로 모든 기능을 사용할 수 있습니다. WebMCP를 제가 좋아하는 이유 중 하나가 바로 이 점입니다. 기존 웹사이트에 추가적인 기능을 덧붙일 뿐, AI 때문에 제품을 완전히 새로 만들 필요가 없습니다.

GitHub: https://github.com/sylwia-lask/ai-ceo-webMCP 데모: https://sylwia-lask.github.io/ai-ceo-webMCP/

좋아요, 그런데 도구는 어떻게 호출하죠?

모든 것이 근사하게 들리지만, 한 가지 실질적인 문제가 있습니다. 실제로 이 도구들을 어떻게 호출할까요? 특히 컨퍼런스 강연 중 라이브로 호출하고 싶을 때는 더욱 흥미로운 문제가 됩니다.

물론 ChatGPT나 공개된 확장 프로그램들을 통해 할 수도 있지만, 클라우드 기반 솔루션은 인터넷 접속이 필수적입니다. 게다가 그들의 인터페이스가 발표용으로 항상 이상적인 것도 아니죠. 사람들이 큰 화면으로 데모를 볼 때는 모든 것이 크고 따라하기 쉬워야 하니까요.

그리고 당연히, 저는 로컬 모델로 폴백할 수 있는 옵션도 원했습니다!

그래서 WebMCP Local Agent라는 Chrome 확장 프로그램을 직접 만들었습니다.

GitHub: https://github.com/sylwia-lask/webmcp-local-agent

아직 Chrome 웹 스토어에 게시되지는 않았지만, 언젠가는 개발자 등록비 5달러를 지불하게 될지도 모르겠네요. 😅💸 지금으로서는 관심 있는 분들은 소스 코드를 다운로드하여 로컬에서 실행할 수 있습니다.

이게 정말 에이전트인가요?

그렇다면 이 플러그인, 또는 에이전트는 실제로 어떤 일을 할까요?

매우 간단합니다. 사용자의 의도를 받아, 현재 페이지에서 사용 가능한 WebMCP 도구들을 확인하고, 적절하다고 판단하는 도구들을 호출합니다.

우리 모두 에이전트는 기본적으로 루프에 불과하다는 것을 알고 있습니다. 제가 이 부분에 대해선 'AI 에이전트 뒤에 숨겨진 더러운 비밀 (데모 🚀)'이라는 글에서 더 자세히 다뤘었죠.

그리고 이 에이전트도 정확히 그렇게 작동합니다. 모델은 사용자의 의도와 사용 가능한 도구를 받아, 무엇을 호출할지 결정하고, 그 결과를 받은 다음 다음에 무엇을 할지 다시 결정하는 식입니다. 기본적으로 이 루프를 최대 10번 반복하도록 설정되어 있지만, 설정에서 변경할 수 있습니다.

보시다시피, 단순히 이름만 멋진 챗봇이 아닙니다. 엄연히 제대로 된 작은 에이전트인 거죠.

약간 이기적인 동기도 유용한 결과로 이어질 수 있습니다

네, 제 원래 동기는 아주 단순했고 어쩌면 약간 이기적이었을지도 모릅니다. 😉 하지만 때로는 의심스러운 동기에서 좋은 결과가 나오기도 하죠. 골룸조차도 반지의 제왕의 해피 엔딩에 기여했으니까요. 🤣🤣🤣

제 확장 프로그램은 로컬 모델로 실행될 수 있기 때문에, 로컬 프로바이더를 사용할 경우 프롬프트와 모델 추론이 사용자 머신에 머무를 수 있습니다. 이는 모든 상호작용을 클라우드 모델로 보내는 것과 비교했을 때 매우 흥미로운 프라이버시 이점을 제공합니다.

또한, 또 다른 문제 해결에도 도움이 됩니다. AI 모델에 대한 접근성이 모든 곳에서 동일하게 안정적이지 않다는 점이죠. 제 친애하는 DEV 친구인 @dannwaneri가 얼마 전 이 문제를 언급했습니다. 유럽에서는 꽤 좋은 인프라와 클라우드 AI 서비스 접근성을 가지고 있지만, 전 세계 모든 곳의 상황이 똑같이 좋지는 않으니까요. 제가 과거에 해외 지사 프로젝트를 진행할 때, 특정 지역에서는 클라우드 인프라 접근성이 현저히 떨어져 난항을 겪었던 기억이 납니다. WebMCP와 같은 로컬 모델 활용은 이런 장벽을 허무는 열쇠가 될 수 있습니다. 로컬 모델은 우리에게 또 다른 선택지를 제공합니다.

세 개의 프로바이더, 하나의 에이전트

보시다시피, 제 WebMCP 플러그인은 현재 세 가지 모드를 지원합니다.

첫 번째는 Google의 Prompt API로, Chromium이 관리하는 Gemini Nano를 사용합니다. 모델이 다운로드되면 추론은 로컬에서 이루어지며, Google이나 다른 제삼자에게 프롬프트를 보내지 않고 API 키도 필요 없습니다.

두 번째 옵션은 Ollama로, 역시 로컬에서 실행됩니다. 제 경우에는 Llama 3.1을 사용하고 있지만, 원한다면 다른 모델을 선택할 수 있습니다. 이상적으로는 도구 호출에 잘 작동하는 모델을 선택하는 것이 좋겠죠.

그리고 마지막으로 하나의 클라우드 프로바이더가 있습니다. 제 경우엔 구형 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을 실행하고 있는지 확인해야 합니다.

이제 직원을 해고하는 상황을 시뮬레이션해 봅시다.

보시다시피, 우리 에이전트는 도구 호출이 중요한(consequential) 작업으로 표시되었음을 인지하고, 진행하기 전에 확인 프롬프트를 표시했습니다. 사용자는 이 작업을 승인하거나 거부할 수 있습니다.

AI CEO가 회사를 재편성하기 시작할 때 이런 확인 절차는 아마 아주 좋은 아이디어일 겁니다. 😉

물론, Kiro로 만들었죠!

그리고 자존심 강한 AWS 커뮤니티 빌더로서, 저는 이 모든 것을 세상에서 가장 훌륭한 IDE인 Kiro의 도움을 받아 만들었습니다. 😅 솔직히 고백하자면, 처음에는 Claude Code 비용을 아끼기 위해 Kiro를 설치했습니다. 하지만 지금은 @corey_aws가 내일 저를 커뮤니티 빌더 프로그램에서 내쫓는다 해도, 제 돈을 내고서라도 Kiro를 기꺼이 쓸 겁니다. 😂

Kiro는 선택할 수 있는 엄청난 수의 모델을 제공할 뿐만 아니라, 제가 정말 높이 평가하게 된 스펙 기반 개발도 지원합니다. 컨퍼런스 강연 두 시간 전에 제가 처리해야 했던 마지막 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-23 02:03:55