Project Mariner와 관리형 MCP로 보는 엔터프라이즈 웹 에이전트 아키텍처
Project Mariner의 웹 브라우징 구조와 관리형 MCP, Apigee 인가 게이트웨이를 중심으로 엔터프라이즈 에이전트 통제 체계를 정리한다.
2026-08-14 · 최초 발행 2026-08-02
웹 에이전트가 관리형 인프라로 들어간 배경
구글은 2026년 Cloud Next에서 Vertex AI를 Gemini Enterprise Agent Platform으로 재편하면서, 웹 브라우징 에이전트 Project Mariner와 관리형 MCP(Model Context Protocol)를 플랫폼의 핵심 요소로 제시했다. 소비자용 단독 Mariner 서비스는 2026년 5월에 종료됐고, 해당 기술은 Gemini Agent, AI 모드, Chrome으로 옮겨졌다. 자율 웹 브라우징이 독립형 데모를 넘어 관리형 인프라의 일부로 편입되는 흐름이다.
Mariner는 Google DeepMind가 Gemini 2.0 기반 연구 프로토타입으로 공개한 기술로, 브라우저 안에서 태스크를 자율 수행하는 데 초점을 뒀다. labs.google.com/mariner 랜딩 페이지 기준으로는 17개월 운영 뒤 2026년 5월 4일 서비스가 끝났다.
같은 흐름에서 ADK(Agent Development Kit) v1.0 안정화, Agent Studio 로우코드 빌더, A2A(Agent2Agent) 프로토콜 v1.0도 발표됐다. A2A는 150개 조직에 프로덕션 적용됐으며, Box, Workday, Salesforce, ServiceNow 등의 파트너 에이전트는 Anthropic Claude를 포함한 Model Garden 200여 개 모델과 통합됐다. 이제 경쟁의 초점은 자율 브라우징 기능 하나가 아니라, 이를 누가 관리형 환경에서 안전하게 운영하느냐에 가깝다.
화면 해석부터 사내 도구 호출까지
Mariner의 동작은 웹 페이지를 인식하고 행동하는 루프, 그리고 그 맥락을 엔터프라이즈 도구와 연결하는 관리형 MCP 계층으로 나눠 볼 수 있다.
브라우저 단계에서는 스크린샷의 시각 정보와 DOM 구조를 함께 분석한다. 텍스트, 이미지, 폼, 코드 블록이 섞인 페이지를 해석한 뒤 클릭·입력·스크롤·탭 전환 같은 원자적 액션을 순서대로 조합한다. 실행은 사용자 로컬 브라우저가 아니라 클라우드 가상 머신에서 격리되므로, 사용자는 다른 작업을 병행할 수 있다.
고정 셀렉터에 의존하지 않고 시각적으로 다시 추론하는 방식도 기존 RPA와 다른 부분이다. 사이트 레이아웃이 바뀌었을 때 대응할 여지가 생기지만, 동시에 그 판단 과정과 결과를 통제할 장치가 필요해진다.
태스크별 컨텍스트에는 사용자 지시, 과거 상호작용, 엔터프라이즈 정책 문서가 시스템 프롬프트와 검색 결과를 통해 결합된다. 비동기 구조로 최대 10개 태스크를 동시에 처리하며, 진행 단계·중간 결과·오류 지점은 별도 세션으로 관리해 장시간 태스크를 다시 시작할 수 있다. ADK의 그래프 프레임워크는 다중 에이전트가 하위 태스크를 나누고 결과를 병합하는 역할을 맡는다.
관리형 MCP는 Drive, Calendar 같은 Workspace 도구를 구글 운영 MCP 서버로 제공한다. 조직이 개별 커넥터를 직접 만들 필요를 줄이는 구조다. Apigee의 API-투-에이전트 브리지는 기존 REST/SOAP API 자산을 MCP 인터페이스로 자동 변환해 레거시 시스템도 에이전트 도구로 노출한다. 이때 Apigee는 인증·인가·레이트리밋을 API 트래픽 중앙에서 통제하는 게이트웨이로 동작한다. A2A 프로토콜은 벤더가 다른 에이전트 사이에서도 태스크 위임과 결과 공유를 표준화한다.
민감 행동 앞에 승인 지점을 둔다
결제, 로그인, 개인정보 입력처럼 위험도가 높은 행동은 사전에 정의된 규칙으로 분류할 수 있다. 해당 단계에 진입하면 자율 실행을 멈추고 사용자 승인을 요구하는 휴먼 게이트를 둔다. 클라우드 VM 샌드박스는 로컬 자격 증명과 파일 시스템에 직접 접근하지 못하게 하는 경계가 된다.
실행이 끝난 뒤에는 액션, 그 근거, 호출한 도구를 구조화된 로그로 남긴다. 감사 기록은 문제가 발생했을 때 단순히 결과만 확인하는 수단이 아니라, 에이전트가 어떤 지시를 받아 어떤 경로로 행동했는지를 복원하는 기반이다.
권한·감사·공급망을 함께 설계하는 운영 체계
에이전트는 임의의 웹 페이지와 내부 시스템을 오가므로, 도입의 핵심은 기능 활성화보다 데이터 접근, 인증, 감사의 경계를 정하는 일이다.
에이전트 계정에는 태스크 수행에 필요한 최소 권한만 부여하고, 전사 SSO 계정을 직접 위임하지 않는다. OAuth 스코프 기반 위임 토큰으로 사용자를 대신해 행동하게 하되 권한 범위를 명시한다. 브라우저 세션과 토큰 수명은 짧게 두고 태스크가 끝나면 즉시 폐기한다. 페이지 접근과 API 호출 이력은 기존 IAM 로그에 통합해 하나의 감사 뷰에서 확인할 수 있어야 한다.
감사 설계에서는 스크린샷, DOM 스냅샷, 액션 시퀀스를 태스크 단위로 보관한다. 이를 통해 사후 재현과 분쟁 대응이 가능해진다. 전수 검수가 어려운 환경이라면 결제·계약·데이터 변경 같은 고위험 카테고리를 우선 표본 추출해 정기적으로 검수한다. 평소와 다른 페이지 접근, 반복 실패, 비정상 시간대 실행은 자동 플래그 대상으로 둘 수 있다. 지시-실행-결과의 3단 로그는 에이전트 오작동과 사용자 지시 오류의 책임을 구분하는 데 필요하다.
관리형 MCP도 공급망 통제 대상이다. 제공 주체의 SOC 2 등 보안 인증과 데이터 처리 위치를 계약서에 명시하고, 에이전트가 호출 가능한 도구는 조직 정책의 화이트리스트로 제한한다. 에이전트가 수집하거나 전달하는 데이터에는 기존 DLP 정책을 적용한다. Apigee 브리지로 노출된 레거시 API의 취약점은 에이전트 공격면으로 이어질 수 있으므로 API 보안 스캔을 병행해야 한다.
실행 비용과 자원 사용도 통제 범위에 포함된다. 태스크별 최대 액션 수, 실행 시간, 재시도 횟수를 제한하면 무한 루프와 과도한 소모를 막을 수 있다. 병렬 실행 쿼터는 조직 단위로 두고, 태스크당 토큰·API 호출·VM 실행 시간을 계측한다. 예산을 넘기면 자동 다운시프트 또는 승인 요청으로 전환한다. 권한 확대는 정보 수집이나 양식 작성 보조 같은 저위험 반복 업무에서 출발하는 편이 맞다.
Mariner, Operator, RPA가 다른 지점
| 항목 | Project Mariner | OpenAI Operator | 기존 RPA |
|---|---|---|---|
| 기반 모델/방식 | Gemini 멀티모달 추론 | CUA(Computer-Using Agent, GPT-4o 계열) | 규칙 기반 스크립트/매크로 |
| 실행 방식 | 클라우드 VM 비동기, 최대 10태스크 병렬 | 별도 브라우저 창에서 사용자와 함께 실행 | 사전 정의 시나리오 순차 실행 |
| 페이지 이해 | 스크린샷+DOM 멀티모달 해석 | 스크린샷 기반 시각 추론 | 고정 셀렉터·좌표 의존 |
| 레이아웃 변경 대응 | 시각적 재추론으로 자가 적응 | 시각적 재추론으로 자가 적응 | 셀렉터 변경 시 즉시 실패 |
| 도구 연동 | 관리형 MCP·Apigee 게이트웨이·A2A | 플러그인·액션 API | 개별 커넥터/드라이버 구축 |
| 2026년 상태 | 소비자 단독 상품 종료(5월), 엔터프라이즈 플랫폼 흡수 | 단독 상품 조기 종료, ChatGPT Agent로 흡수 | 유지보수 부담 지속, 점진적 에이전트 대체 |
| 감사 체계 성숙도 | 신규 구축 중(로그 표준화 진행형) | 신규 구축 중 | 성숙(로그 표준 확립) |
Mariner와 Operator는 모두 소비자 단독 상품으로는 오래 유지되지 않고 Gemini Agent와 ChatGPT Agent의 구성요소로 흡수됐다는 공통점을 보인다. 반면 Mariner는 클라우드 VM 기반 백그라운드 병렬 실행에, Operator는 사용자와 동기적으로 상호작용하는 방식에 각각 강점이 있다.
RPA는 결정적인 절차 실행에 맞춰져 있어 안정성은 높지만 UI 변경에 취약하다. 자율 웹 에이전트는 반대로 유연하지만 행동의 예측 가능성과 감사 체계가 상대적으로 미성숙하다.
| 리스크 항목 | 자율 웹 에이전트 (Mariner류) | 스크립트 자동화 (RPA) |
|---|---|---|
| 사이트 변경 대응력 | 시각적 재추론으로 자가 적응 가능 | 셀렉터 변경 시 즉시 실패 |
| 행동 예측 가능성 | 낮음(추론 기반 비결정적 행동) | 높음(사전 정의된 결정적 절차) |
| 감사 추적 성숙도 | 액션·근거 로그 체계 신규 구축 필요 | 로그 표준화 이미 성숙 |
| 오작동 파급력 | 페이지 오인식 시 데이터 유출·오조작 가능성 | 스크립트 버그 범위로 국한 |
| 통제 수단 | 휴먼 게이트·인가 게이트웨이·실행 샌드박스 | 권한 최소화·버전 관리·회귀 테스트 |
| 도입 난이도 | 초기 신뢰 확보 필요, 단계적 확대 권장 | 시나리오별 개발 공수 필요 |
에이전트 보안 거버넌스가 향하는 곳
웹 브라우징 에이전트는 애플리케이션 경계를 가로질러 움직인다. 기존 IAM, DLP, API 보안 정책도 에이전트의 권한 위임과 도구 호출을 기준으로 다시 해석해야 한다.
관리형 MCP는 도구 연동을 표준화해 개발 생산성을 높이지만, 단일 MCP 게이트웨이의 장애나 침해가 전사 도구 접근에 영향을 줄 수 있는 단일 실패점이 되기도 한다. 따라서 자율 실행의 근거를 재현 가능한 로그로 남기는 능력은 규제와 내부통제 대응력을 좌우하는 자산이 된다.
2026년의 흐름은 단독 소비자 웹 에이전트 경쟁보다 관리형 MCP, A2A 프로토콜, 인가 게이트웨이를 갖춘 엔터프라이즈 에이전트 플랫폼 사이의 거버넌스 경쟁에 가깝다. Project Mariner는 페이지 인식과 DOM 조작의 진전만큼이나, 그것을 관리형 MCP와 인가 게이트웨이로 감싸는 구조가 도입 성패를 좌우한다는 점을 보여준다.
Sources
- https://thenextweb.com/news/google-cloud-next-ai-agents-agentic-era
- https://en.wikipedia.org/wiki/Project_Mariner
- https://nerova.ai/news/google-shuts-down-project-mariner-gemini-agent-browser-2026
- https://deepmind.google/models/project-mariner/
- https://finance.biggo.com/news/202604231020_Google_Gemini_Enterprise_Agent_Platform_launch
- https://epinium.com/en/blog/google-kills-project-mariner-the-visual-web-agent-era-just-ended/
- https://www.digitaltrends.com/computing/google-pulls-the-plug-on-project-mariner-the-ai-agent-that-browsed-the-web-like-a-human/
- https://www.androidheadlines.com/2026/05/google-shuts-down-project-mariner-ai-agent.html
- https://research.aimultiple.com/ai-agents/
- https://www.awaynear.com/post/the-battle-of-ai-agents-2025-google-mariner-vs-openai-operator
- https://ai2.work/blog/google-kills-project-mariner-as-the-industry-pivots-to-api-first-agents