한 제품 관리자(Product Manager)가 ChatGPT가 배포 스크립트(deploy script)처럼 "그냥 우리의 API를 호출할 수 있는지"를 묻습니다. 솔직한 대답은 대개 '아니오'입니다. REST 엔드포인트(endpoint)는 적절한 경로(path), 헤더(headers), 그리고 본문(body)이 제공될 때 JSON을 반환합니다. 하지만 어시스턴트(assistant)에게는 이름이 지정된 기능(capability), 이를 언제 사용해야 하는지에 대한 짧은 설명, 인자(arguments)를 위한 스키마(schema), 그리고 멀티 턴 대화(multi-turn chat) 동안 유지되는 권한 경계(permission boundary)가 필요합니다. 이러한 요소들이 바로 Model Context Protocol (MCP)이 노출하도록 설계된 것들입니다. 기존의 API는 여전히 작업을 수행할 수 있지만, MCP는 어시스턴트가 가장 먼저 읽는 계약(contract)입니다.

우리는 보안 및 테넌트 격리(tenant-isolation) 측면에서 SaaS를 위한 MCP 및 안전한 어시스턴트 액세스에 관한 후속 글(CSV 붙여넣기, 스코프(scopes), 권한 취소(revocation))을 작성했습니다. 여기서 질문은 더 좁고 개발자 중심적입니다. 즉, REST가 결정론적 호출자(deterministic callers)에게 이미 제공하는 것은 무엇인지, MCP가 ChatGPT와 Claude를 위해 무엇을 추가하는지, 그리고 왜 "REST 대신 MCP를 출시하라"는 말이 잘못된 갈림길인지에 대한 것입니다. 저희의 제품 사고방식에서는 자동화와 CI를 위해 HTTP를 유지하며, 어시스턴트 대상 도구(assistant-facing tools)를 별도의 접점(surface)으로 취급합니다. 두 가지를 모두 계층화하십시오. OpenAPI를 뜯어내고 교체하지 마십시오.

REST API가 스크립트에는 제공하지만 어시스턴트에게는 여전히 부족한 것

전형적인 SaaS API는 결정론적 호출자(deterministic callers)를 위해 구축되었습니다. 파이프라인(pipeline)은 경로(route)를 알고 있습니다. 웹훅(webhook)은 이벤트를 알고 있습니다. 고객 스크립트는 어떤 쿼리 파라미터(query parameters)를 보내야 하는지 알고 있습니다. OpenAPI(또는 내부 문서)는 사람과 코드 생성기(code generators)를 위한 상태 코드(status codes)와 페이로드(payloads)를 설명합니다. 이는 CI, cron, 그리고 파트너 통합(partner integrations)에는 충분합니다.

Assistant(어시스턴트)는 하드코딩된 경로(route)로 시작하지 않습니다. 이들은 사용자의 문장(예: "이번 주에 어떤 클라이언트 사이트들이 드리프트(drift)되었는지 보여줘")과 호출할 수 있는 도구(tools) 카탈로그로 시작합니다. 도구 이름, 설명, 그리고 입력 스키마(input schemas)가 없다면, 모델은 존재하지 않는 경로에 대해 URL을 임의로 만들어내거나(GET /api/v1/sites?all=true), 사용자에게 curl 명령어를 붙여넣어 달라고 요청하거나, 아니면 대시보드를 스크래핑(scraping)하는 방식으로 회귀하게 됩니다. 스크래핑은 취약하고 느리며, 테넌트 범위(tenant-scoped) 데이터에는 적합하지 않습니다. 여기서 발생하는 격차는 "JSON 대 자연어"의 문제가 아닙니다. 격차는 발견(discovery)과 안전한 호출(safe invocation)에 있으며, 이 격차는 누군가가 도구 카탈로그 없이 채팅창에서 포트폴리오 관련 질문에 답하려고 시도하는 첫 순간에 명확히 드러납니다.

"이미 API가 있습니다"라는 말은 자동화(automation) 티켓은 종결시킬 수 있어도, 어시스턴트(assistant) 티켓을 종결시키지는 못합니다. MCP는 모든 모델에게 귀사의 프라이빗 OpenAPI 파일 형식을 가르치지 않고도, ChatGPT나 Claude가 사용자가 부여한 자격 증명(credentials)을 가지고 동작하기를 원할 때 동일한 도메인 로직(domain logic) 위에 자리 잡습니다.

MCP 도구(tools), 리소스(resources), 프롬프트(prompts) 대 HTTP 동사(verbs)

MCP의 유용한 어휘는 CRUD와는 다릅니다:

• 도구(Tools)는 타입이 지정된 입력(typed inputs)을 가진 호출 가능한 동작입니다(예: 예산을 초과한 사이트 목록화, 특정 URL에 대한 최신 실험 실행 결과 가져오기, 주간 요약 정보 요약하기). 어시스턴트는 설명이 사용자의 목표와 일치하기 때문에 도구를 선택합니다.
• 리소스(Resources)는 호스트(host)가 첨부할 수 있는 읽기 가능한 컨텍스트(readable context)입니다(예: 예산 정책 문서, 사이트 목록, 보고서 조각). 이는 채팅창에 CSV 내보내기 파일을 붙여넣어야 하는 필요성을 줄여줍니다.
• 프롬프트(Prompts)는 제품 제작자가 한 번 설정해두면 모든 세션에서 "Core Web Vitals 회귀에 대해 대화하는 방식"을 매번 새로 정의할 필요가 없는 재사용 가능한 지침 템플릿(instruction templates)입니다.

내부적으로는 여전히 HTTP 동사(verbs)가 중요합니다. get_site_latest_run이라는 이름의 도구는 귀사 측의 GET /api/v1/sites/{id}/runs/latest를 호출할 수 있습니다. 어시스턴트는 해당 경로를 알 필요가 전혀 없습니다. 어시스턴트에게 필요한 것은 해당 도구가 존재한다는 사실, 어떤 인자(arguments)가 필요한지, 그리고 호출이 읽기 전용(read-only)인지 여부입니다. OpenAPI는 경로(path)를 설명하지만, MCP는 호스트와 모델이 공유하는 언어로 그 기능(capability)을 설명합니다.

만약 REST만 공개한다면, 모든 어시스턴트 통합은 커스텀 글루(glue) 프로젝트가 됩니다. 즉, 누군가가 사용자의 의도(intent)를 경로(route)에 수동으로 매핑하거나, 프롬프트에 토큰을 직접 붙여넣어야 합니다. 반대로 MCP만 공개하고 REST를 중단한다면, 채팅 호스트를 거칠 필요가 없는 배포 스크립트, 웹훅(webhook), 그리고 파트너 작업들이 중단됩니다. 모니터링의 중추는 HTTP와 스케줄러(scheduler)에 머물러야 하며, 어시스턴트는 사용자가 프롬프트에 OpenAPI를 붙여넣지 않고도 채팅에서 답변을 얻고 싶을 때 그 위에 얹어지는 얇은 도구 계층(tool layer) 역할을 수행하게 됩니다.

CI 파이프라인이 계속해서 HTTP API를 호출해야 하는 경우

빌드 게이트(build gates)와 배포 훅(deploy hooks)에는 안정적이고, 지연 시간이 낮으며, 비대화형(non-interactive)인 호출이 필요합니다. Lighthouse CI 어설션(assertion)이나 배포 후 예산 체크(post-deploy budget check)는 HTTP 엔드포인트(또는 이를 래핑한 CLI)를 호출하여 결과를 기다린 다음, 명확한 종료 코드(exit code)와 함께 작업을 실패시켜야 합니다. 이러한 경로는 도구 발견(tool discovery)이나 다회차 명확화(multi-turn clarification)로부터 이득을 얻지 않습니다. 대신 이미 스크립트에서 사용 중인 것과 동일한 계약(contract)으로부터 이득을 얻습니다.

우리는 이미 웹 성능(webperf)에 대해 이러한 분리에 대해 작성한 바 있습니다. 파이프라인에는 소수의 실험실 체크(lab checks)를 배치하고, 포트폴리오 스케줄과 알림은 모니터링에 유지하는 방식입니다. Watcher 블로그의 CI/CD 성능 예산 가이드에서는 팀들이 현재 Lighthouse CI를 어떻게 연결하는지 다루고 있으며, 테스트를 트리거하고 읽기 위한 고객용 HTTP API가 유료 플랜의 에이전시 자동화를 위해 활발히 개발 중임을 언급하고 있습니다. 해당 API 스토리는 파이프라인과 저장된 결과에 관한 것이지, 대화 도중 ChatGPT가 도구를 선택하는 것에 관한 것이 아닙니다.

다중 사이트 PageSpeed 스케줄의 경우, 운영 가이드는 여전히 모니터링 설정 경로(사이트, URL, 주기, 예산)를 따릅니다. 이는 인간과 스케줄러의 작업이지, 어시스턴트 도구의 작업이 아닙니다. 다중 사이트를 위한 자동화된 PageSpeed 모니터링 설정 방법을 참조하십시오.

저희가 내부적으로 사용하는 경험칙(Rule of thumb)은 다음과 같습니다: 호출자가 고정된 작업을 수행하는 로봇이라면 REST(또는 CLI)를 선호하십시오. 만약 호출자가 인간의 요청을 해석하는 어시스턴트라면, 동일한 도메인 서비스(domain services)를 래핑(wrap)하는 MCP 도구(tools)를 선호하십시오. 하나의 "어시스턴트 전용" 인터페이스에 이러한 호출자들을 혼합하면 일반적으로 CI(지속적 통합)가 불안정해지고 채팅 세션의 권한이 과도하게 부여됩니다.

모니터링 SaaS가 노출해야 할(그리고 거부해야 할) MCP 도구들

멀티 테넌트(multi-tenant) PageSpeed 제품의 경우, 어시스턴트 대상 도구는 대부분 읽기 지향적(read-oriented)인 것이 합리적입니다. 호출 명칭을 정하는 것은 이론보다 카탈로그를 더 빠르게 확정해 줍니다:

• 인증된 사용자가 볼 수 있는 조직(organisations) 또는 사이트 목록 나열.
• 지정된 URL 및 디바이스 폼 팩터(device form factor)에 대한 최신 랩 점수(lab scores) 가져오기.
• 지난 N일 동안 예산을 초과한 URL이 무엇인지 설명.
• 인간이 다음에 열어야 할 정식(canonical) 보고서 URL 가리키기.

저희가 거부하거나 추가 확인 절차를 통해 제한할 도구에는 결제 정보를 변경하거나, 사이트를 삭제하거나, API 키를 교체하거나, 테넌트 가시성(tenant visibility)을 확장하는 모든 것이 포함됩니다. 어시스턴트는 실수를 증폭시킵니다. 채팅 세션에서의 잘못된 DELETE는 잘못된 GET보다 훨씬 더 위험합니다. 권한 범위(Scopes)는 기본적으로 읽기(read)로 설정되어야 하며, 쓰기(write) 도구는 드물어야 하고, 로그가 남아야 하며, 조직별로 쉽게 비활성화할 수 있어야 합니다.

인증(Auth)은 여전히 SaaS OAuth와 유사한 방식을 따릅니다: 사용자가 어시스턴트 호스트를 연결하고 권한 범위(scopes)를 부여하면, MCP 서버는 HTTP API가 하는 것과 동일한 방식으로 테넌트 격리(tenant isolation)를 강제합니다. MCP는 귀하의 권한 부여 모델(authorisation model)을 대체하는 것이 아닙니다. 그것은 해당 모델을 준수해야 하는 또 다른 정문(front door)일 뿐입니다.

페이지 수준의 WebMCP(에이전트 기반 브라우징을 위해 브라우저에 등록된 도구)는 SaaS MCP 서버와는 다른 문제입니다. 하나는 에이전트가 웹사이트 UI를 사용하는 것을 돕고, 다른 하나는 어시스턴트가 사용자가 이미 소유한 제품 데이터를 쿼리(query)하는 것을 돕습니다. 로드맵의 범위를 정할 때 이 둘을 혼동하지 마십시오.

이번 분기에 REST API와 함께 MCP를 출시해야 할까요?

세 가지 실질적인 질문을 던져보십시오:

1. 고객들이 이미 ChatGPT나 Claude에게 우리 데이터와 연동해 달라고 요청하고 있으며, 현재는 데이터 내보내기(export) 파일이나 스크록샷을 붙여넣고 있습니까?
2. 두 번째 제품을 새로 만들지 않고도, 이러한 요청의 80%를 커버할 수 있는 도구(tool)를 10개 이하로 정의할 수 있습니까?
3. MCP를 추가하더라도 CI, 웹훅(webhooks), 파트너 스크립트들이 REST 상에서 변경 없이 계속 작동할 것입니까?

만약 답변이 '예', '예', '예'라면, MCP는 하나의 레이어(layer)입니다. 기존 서비스 위에 얇은 도구 카탈로그(tool catalogue)를 배포하고, 스코프(scope)를 명확히 문서화하며, 자연어(natural language)가 전혀 필요 없는 호출자들을 위해 OpenAPI를 유지하십시오. 만약 (2)번에 답할 수 없다면, 당신은 아직 MCP를 도입할 준비가 되지 않은 것입니다. 당신은 여전히 제품의 표면(product surface)을 명확히 하는 단계에 있습니다.

MCP와 REST API를 나란히 문서화하는 방법

REST는 스크립트, CI, 그리고 결정론적 자동화(deterministic automation)를 위한 올바른 인터페이스로 남을 것입니다. MCP는 어시스턴트가 자신이 무엇을 할 수 있는지 발견(discover)해야 하고, 사용자의 동의 하에 구조화된 인자(structured arguments)로 이를 호출해야 할 때 적합한 인터페이스입니다. 이들은 백엔드 로직(backend logic)을 공유하지만, 동일한 공개 계약(public contract)을 공유하지는 않습니다.

제품 관리자(product manager)에게 "이미 API가 있습니다"라고 말하기 전에, 한 페이지에 두 개의 리스트를 작성해 보십시오. 첫째: CI, cron, 그리고 파트너들이 변경 없이 유지해야 하는 HTTP 경로(routes)와 웹훅(webhooks) 목록입니다. 둘째: 채팅 호스트(chat host)가 발견할 수 있는 10개 이하의 도구 목록으로, 각 도구는 기본적으로 읽기 전용(read-only)이어야 하며 이미 운영 중인 서비스에 매핑되어야 합니다. 만약 두 번째 리스트가 비어 있다면, 당신은 MCP와 REST 사이에서 선택을 하고 있는 것이 아닙니다. 당신은 여전히 어시스턴트가 당신의 제품에 대해 무엇을 알 수 있도록 허용할지를 결정하고 있는 것이며, 그 결정은 누군가 데모 통합(demo integration)을 배포하기 전에 반드시 문서로 정리되어야 합니다.