검색부터 행동까지: Apigee Hybrid의 MCP 지원이 검색 여정 최적화에 어떻게 도움을 줄 수 있는가

AI 기반 발견(discovery)과 실시간 비즈니스 데이터, 제어된 액션, 측정 가능한 결과 연결.

유용한 검색 경험은 누군가가 진전을 이루도록 도와야 합니다. 답을 찾는 것은 한 단계일 뿐입니다. 그 답이 자신의 상황에 적용되는지 확인하고 다음 행동을 취하는 것 또한 똑같이 중요합니다.

가까운 의료 제공자를 찾는 사람을 생각해 봅시다. 디렉토리는 옵션을 발견하도록 도울 수 있지만, 여정을 완료하려면 보험 가입 여부를 확인하고, 예약 가능한 진료 시간을 찾고, 예약을 해야 할 수도 있습니다.

이것이 바로 **검색 여정 최적화(Search Journey Optimization)**의 기회이며, 여기서 '여정'은 사용자의 초기 질문부터 성공적인 결과까지의 전체 경로를 개선하는 것을 의미합니다.

Google이 Apigee hybrid에서 Model Context Protocol (MCP) 지원을 발표한 것은 이러한 접근 방식을 지원할 수 있는 인프라를 제공합니다. 검색 여정 최적화와의 연결고리는 Google이 도입하는 검색 기능이라기보다는, 해당 발표의 아키텍처적 응용 사례입니다.

Google이 발표한 내용

Apigee hybrid 1.17.0은 조직 자체 Kubernetes 클러스터에서 실행되는 MCP 데이터 플레인(data plane)을 도입합니다. 이를 통해 기업들은 기존 런타임 인프라와 함께 에이전트가 접근 가능한 기능을 제공할 수 있습니다.

Apigee는 OpenAPI 사양을 사용하여 API 작업을 MCP 도구로 노출합니다. 호환되는 클라이언트는 tools/list를 통해 사용 가능한 도구를 발견하고, tools/call을 통해 이를 호출할 수 있습니다. 이는 AI 애플리케이션과 비즈니스 서비스 간의 표준화된 연결을 만듭니다.

검색 여정 최적화에 대한 잠재력은 간단합니다. 어시스턴트가 단순히 서비스를 설명하는 것을 넘어, 사용자가 그 서비스와 상호작용하도록 돕는 단계로 나아갈 수 있다는 것입니다.

발견과 유용한 다음 단계 연결하기

고객이 다음과 같이 질문한다고 상상해 봅시다:

저 근처에 이 제품을 오늘 픽업할 수 있는 매장이 어디 있나요?

이는 Apigee가 자동으로 제공하는 도구가 아니라 제안된 애플리케이션 기능입니다.

연결된 어시스턴트(connected assistant)는 사용자의 위치, 제품 선호도, 픽업 요구 사항 등을 상호작용 전반에 걸쳐 유지할 수 있습니다. 사용자는 정보를 반복하거나 연결되지 않은 시스템 사이를 이동하는 데 드는 노력을 줄일 수 있습니다.

설계 목표는 연속성(continuity)입니다. 모든 답변은 다음 유용한 단계를 더 쉽게 만들어야 합니다.

여정에 최신 정보 가져오기

어떤 질문들은 자주 변경되는 정보에 의존합니다.

제품 설명은 품목이 무엇을 하는지 설명할 수 있는 반면, 재고 서비스(inventory service)는 현재 사용 가능한지 여부를 결정합니다. 서비스 페이지는 예약 옵션을 설명할 수 있지만, 스케줄링 시스템(scheduling system)은 어떤 슬롯이 남아 있는지 결정합니다.

제안된 검색 여정 아키텍처(search journey architecture)는 서술적 콘텐츠와 목표 지향적인 API 호출을 결합할 것입니다. 콘텐츠는 이해를 지원하고, 도구(tools)는 의사결정에 필요한 운영 세부 사항을 검증합니다.

이를 통해 오래되거나 불완전한 비즈니스 정보에 기반한 답변은 줄어들 수 있습니다. 하지만 애플리케이션은 여전히 도구 결과를 확인하고, 누락된 데이터를 처리하며, 불확실성을 전달해야 합니다. API 접근 권한이 있다고 해서 AI가 생성한 답변이 자동으로 정확해지는 것은 아닙니다.

사용자에게 적절한 행동 만들기

좋은 여정은 또한 사용자가 무엇을 할 수 있는지 존중합니다.

Apigee의 MCP 구현은 API 제품(API products)을 통해 기존 API 보안 정책 및 도구 권한(tool entitlements)을 지원합니다. 디스커버리(Discovery)는 클라이언트가 허용된 도구만 볼 수 있도록 필터링될 수 있습니다.

따라서 제안된 구현은 공용 디스커버리와 인증된 행동을 분리할 수 있습니다. 누구나 서비스 카탈로그를 검색할 수 있지만, 계정별 정보는 인증이 필요합니다.

애플리케이션은 정보 읽기와 무언가를 변경하는 것을 구분해야 합니다. 사용 가능한 예약을 확인하는 것과 하나를 예약하는 것은 서로 다른 수준의 사용자 참여가 필요합니다. 예약 흐름(booking flow)은 선택된 세부 정보를 제시하고 요청을 제출하기 전에 확인을 받아야 합니다.

이러한 상호작용 규칙들은 여정 설계와 백엔드 제어에 속합니다.

엔터프라이즈 배포 요구사항 지원

h이브리드 배포 모델은 조직이 기존 시스템 근처에서 런타임 처리가 필요할 때 중요합니다. Google은 MCP 요청 경로가 클러스터 내에 머무르고 구성이 제어 평면(control plane)에서 가져와지는 아키텍처를 설명합니다.

이는 인프라 요구사항으로 인해 도입이 복잡한 조직에게 에이전트 지원 여정(agent-assisted journey)을 실용적으로 만들 수 있습니다.

하지만, 로컬 MCP 처리가 전체 AI 애플리케이션이 로컬이라는 것을 보장하지는 않습니다. 팀은 모델이 어디에서 실행되는지, 프롬프트에 어떤 정보가 들어가는지, 그리고 애플리케이션 로그와 원격 측정(telemetry) 데이터가 어디에 저장되는지를 별도로 평가해야 합니다.

클릭을 넘어선 진행 상황 측정

검색 여정 최적화에는 결과 지표(outcome metrics)가 필요합니다.

Apigee의 발표는 도구 사용, 오류 및 지연 시간에 대한 가시성을 설명합니다. 이러한 운영 신호(operational signals)는 실패했거나 느린 단계를 식별하는 데 도움이 될 수 있습니다.

비즈니스 수준 측정에는 추가적인 애플리케이션 계측(application instrumentation)이 필요합니다. 제안된 대시보드는 다음을 추적할 수 있습니다:

• 작업 완료: 얼마나 많은 사용자가 의도한 결과에 도달하는가?
• 완료 시간: 여정에 시간이 얼마나 걸리는가?
• 반복 노력: 사용자는 정보를 얼마나 자주 다시 말해야 하는가?
• 행동 성공: 시도된 예약이나 예약을 얼마나 많이 성공시키는가?
• 인간 인계(Human handoff): 사용자가 도움이 필요한 곳은 어디인가?

도구 활동만으로는 이러한 질문에 답할 수 없습니다. 성공적인 API 응답이라 할지라도 사용자에게 혼란을 주거나 완료하지 못하게 만들 수도 있습니다.

하나의 여정부터 시작하기

실용적인 첫 구현은 사용 가능한 제품을 찾고 예약하는 것과 같은 좁은 작업에 초점을 맞출 것입니다.

사용자의 질문을 매핑하고, 필요한 비즈니스 서비스를 식별하며, 잘 설명된 소수의 도구를 노출하고, 확인 및 실패 동작을 정의합니다. 그런 다음 연결된 경험과 기존 여정을 비교합니다.

Apigee hybrid의 MCP 지원은 AI 어시스턴트와 엔터프라이즈 서비스 간의 일부 연결 고리를 제공할 수 있습니다. 더 큰 기회는 명확한 사용자 결과(user outcome)를 중심으로 이러한 연결을 설계하는 것에서 나옵니다. 즉, 누군가가 옵션을 발견하고, 그것이 그들의 요구사항을 충족하는지 확인하며, 다음 단계를 자신 있게 완료하도록 돕는 것입니다.