구글과 메타, 개인 AI 에이전트 개발에 나선다. 앤트로피와 오픈AI가 선두를 달린다

구글의 "Remy"와 메타의 "Hatch"는 브라우저 자동화 기반의 1세대 에이전트(예: Mariner, Operator)와 달리, 이메일·캘린더·쇼핑 같은 핵심 서비스 내부에 직접 통합되는 형태의 개인 AI 에이전트다. 기존 브라우저 에이전트는 DOM을 파싱하고 시각적 그라운딩(스크린샷 + 좌표 추론)을 통해 사용자 인터페이스를 흉내내는 방식이라 지연시간이 길고 실패율이 높았다. 반면 통합형 에이전트는 Gmail·Calendar·Commerce 같은 내부 API에 직접 접근하므로 의도 파싱(intent parsing) → 도구 호출(tool calling) → 상태 추적(state management) 파이프라인이 훨씬 결정론적으로 동작한다. 구글이 Mariner를 종료하고 Remy로 자원을 집중한 것도, 범용 브라우저 조작보다는 자사 생태계 내 컨텍스트(메모리, 사용자 데이터, 인증된 권한)를 활용하는 것이 정확도와 비용 모두에서 유리하다는 판단으로 해석할 수 있다.

엔지니어 입장에서 이 전환은 통합 지점이 "브라우저 DOM"에서 "플랫폼 API와 MCP 서버"로 이동하고 있음을 의미한다. Anthropic의 Claude Skills/MCP, OpenAI의 ChatGPT Apps SDK처럼 에이전트가 외부 시스템과 대화하는 표준이 빠르게 정착하면서, 기존에 우리가 만들던 REST API/웹훅 위에 "에이전트가 호출하기 좋은 형태"의 인터페이스 레이어를 추가로 설계해야 하는 상황이 됐다. 특히 한국 개발자들이 다루는 SaaS, 커머스, 사내 툴링은 향후 Gmail/Calendar 같은 빅테크 에이전트의 호출 대상(downstream tool)이 될 가능성이 높다. 이 경우 OAuth 스코프 최소화, idempotent한 mutation 엔드포인트, 자연어로 설명 가능한 스키마(JSON Schema의 description 필드 품질) 같은 요소가 단순 모범 사례가 아니라 에이전트 호환성의 전제 조건이 된다.

실무적으로 지금 점검해야 할 것은 세 가지다. 첫째, 자사 서비스가 MCP 서버 또는 OpenAI Apps SDK 형태로 노출 가능한지 — 즉 핵심 워크플로우가 깔끔한 도구 단위로 분해되는지를 검토해야 한다. 둘째, 에이전트가 사용자 대신 액션을 수행할 때 발생하는 권한·감사(audit) 문제로, "사람이 클릭한 요청"과 "에이전트가 트리거한 요청"을 구분하는 헤더/토큰 체계와 rate limiting 전략을 미리 잡아둘 필요가 있다. 셋째, 브라우저 자동화 기반 RPA에 의존 중이라면 마이그레이션 경로를 그려둘 시점이다 — Mariner의 종료가 시사하듯 이 방식은 빅테크조차 비용 대비 효율을 포기하는 추세이며, API/이벤트 기반 통합으로 옮기지 않으면 1~2년 내 유지보수 부채로 전환될 가능성이 크다.