한 에이전시 리더가 PageSpeed 점수가 담긴 CSV 파일을 ChatGPT에 붙여넣고 클라이언트 요약본을 요청합니다. 한 번은 잘 작동합니다. 하지만 다음 주가 되면 내보낸 데이터는 오래된 것이 되고, 열(column)은 어긋나며, 아무도 그 스프레드시트가 제3자 채팅 기록에 남아 있는 것을 원치 않습니다. 우리가 듣는 질문은 어시스턴트(assistant)가 유용한지 여부가 아닙니다. SaaS 제품이 대시보드를 스크래핑 가능한 공개 페이지로 만들지 않으면서, 어떻게 ChatGPT나 Claude가 _이 테넌트(tenant)_의 데이터를 읽을 수 있게 허용해야 하는가에 대한 것입니다.

그것이 바로 우리가 Apogee Watcher의 잠재적인 미래 인터페이스로서 Model Context Protocol (MCP)을 연구하고 있는 이유입니다. 현재 제품에 포함되어 있지는 않습니다. 우리는 여전히 계획 및 초기 개발 단계에 있습니다. 고객용 MCP 엔드포인트(endpoint), OAuth 어시스턴트 흐름(flow), 출시일 모두 정해지지 않았습니다. MCP는 어시스턴트가 당신이 정의한 도구(tool)와 리소스(resource)를 당신이 제어하는 인증(authentication) 하에 호출할 수 있는 방법입니다. 이것은 당신의 데이터베이스 전체를 프롬프트(prompt)로 미러링해도 된다는 허가증이 아닙니다. 다음은 우리가 그 아이디어를 탐구하는 동안 사용하는 프레임워크입니다: 범위 제한된 액세스(scoped access), 테넌트 격리(tenant isolation), 그리고 정직한 한계(honest limits).

멀티 테넌트(multi-tenant) SaaS에서 ChatGPT에 CSV를 붙여넣는 방식이 실패하는 이유

복사-붙여넣기 워크플로우는 통합 작업을 건너뛰기 때문에 빠르게 느껴집니다. 하지만 에이전시에서 사용하는 모니터링 제품의 경우, 본격적인 클라이언트 업무가 시작되는 첫 주에 세 가지 측면에서 실패를 드러내며, 이 중 어느 것도 "모델이 충분히 똑똑하지 않아서" 발생하는 문제가 아닙니다. 실패의 원인은 운영상의 문제입니다: 오래된 데이터, 과도하게 큰 내보내기(export), 그리고 붙여넣기 이후에 액세스를 취소할 방법이 없다는 점입니다.

첫째, 데이터는 앱을 떠나는 순간부터 틀려집니다. 배포(deploy) 이후에는 점수가 변동되지만, 붙여넣은 테이블은 일정(schedule)이 없는 스냅샷일 뿐입니다. 둘째, 영향 범위(blast radius)가 너무 넓습니다. 내보낸 데이터에는 종종 클라이언트 URL, 조직 이름, 그리고 채팅 로그가 유출될 경우 포트폴리오를 재구성할 수 있을 만큼 충분한 컨텍스트(context)가 포함됩니다. 셋째, 어시스턴트가 무엇을 볼 수 있도록 허용되었는지에 대한 감사 추적(audit trail)이 없습니다. 한 번 붙여넣은 것은 취소할 수 없습니다.

MCP는 그 구조를 뒤집습니다. 어시스턴트가 이름이 지정된 도구(tool)나 리소스(resource)를 요청하면, 귀하의 서버는 사용자, 조직, 그리고 범위를 확인한 후 해당 호출에 필요한 정보만을 반환합니다. 권한 취소(Revocation)는 토큰과 범위(scope)의 변경을 통해 이루어지며, 누군가가 채팅을 삭제하기를 바라는 요행에 의존하지 않습니다.

MCP가 모니터링 SaaS에 의미하는 것 (그리고 의미하지 않는 것)

만약 우리가 Watcher를 위한 MCP 서버를 출시하게 된다면, 우리는 의도적으로 도구 세트를 작게 유지할 것입니다. 호출자가 접근할 수 있는 사이트 목록, 특정 페이지의 최근 실험 결과(lab results) 가져오기, 조직의 예산 초과 사항 요약하기, 그리고 해당 수치들을 바탕으로 짧은 고객 메모 초안 작성하기 등이 포함될 수 있습니다. 리소스(Resources)는 가공되지 않은 덤프 엔드포인트(raw dump endpoints)가 아니라, 문서화된 스키마(schemas)나 도움말 텍스트를 가리킬 것입니다. 이러한 구조는 아직 설계 스케치 단계이며, 출시된 API는 아닙니다.

MCP가 의미하지 않는 것:

1. "컨텍스트가 도움이 된다"는 이유로 모델에게 모든 고객 테이블에 대한 전역 읽기(global read) 권한을 부여하는 것.
2. 별도의 더 엄격한 승인 경로 없이 어시스턴트가 쓰기 작업(write actions)을 임의로 생성하도록 허용하는 것.
3. 로그인된 앱에 대한 브라우저 자동화(browser automation)를 프로토콜의 대체제로 취급하는 것. 대시보드를 스크래핑(Scraping)하는 것은 범위(scopes), 속도 제한(rate limits), 그리고 안정적인 계약(stable contracts)을 건너뛰는 행위입니다.

마지막 포인트가 중요한 이유는 에이전트 기반 브라우징(agentic browsing)과 실험실 점수 산정(lab scoring)은 별개의 문제이기 때문입니다. Lighthouse 에이전트 기반 브라우징에 관한 Watcher의 글에서는 크롤러와 어시스턴트가 실험실 환경에서 페이지를 어떻게 점수화하는지 다룹니다. SaaS를 위한 MCP는 그 반대 방향입니다. 즉, 어시스턴트가 귀하의 UI를 API인 것처럼 가장하는 대신, 자격 증명(credentials)을 가지고 귀하의 API로 직접 찾아오는 것입니다.

ChatGPT와 Claude를 위한 MCP 액세스 보안 방법

MCP를 초기 프로토타입 단계를 넘어 확장한다면, 우리는 이미 앱 내의 사용자들에게 적용하고 있는 동일한 멀티 테넌트(multi-tenant) 규칙부터 시작할 것입니다. 프로토콜이 이러한 규칙을 대체하는 것이 아니라, 모든 도구 호출(tool call) 시 해당 규칙을 강제해야 합니다. 만약 사용자 UI가 이미 조직별로 범위를 제한하고 있다면, 어시스턴트의 모든 경로 또한 예외 없이 동일하게 범위를 제한해야 합니다.

모든 도구 호출(tool call)을 인증하십시오. 어시스턴트가 여러 조직에 걸쳐 사용되는 공유 "봇 키 (bot key)"가 아니라, 지정된 사용자(named user)로서 동작할 수 있도록 OAuth(또는 그에 상응하는 위임된 로그인)를 권장합니다. 공유 서비스 계정은 한 대행사의 채팅 세션이 다른 고객의 URL을 읽기 시작하게 만드는 원인이 됩니다. 지정된 사용자를 사용하면 권한 취소(revocation) 과정도 단순하고 신뢰할 수 있게 됩니다.

도구의 범위를 가장 작은 유효 단위로 제한하십시오. "사이트 X의 최신 점수 읽기"는 "조직의 모든 과거 JSON 데이터 내보내기"와는 다른 위험 등급입니다. 기본값은 읽기(read)로 설정하십시오. 쓰기(write) 작업이 필요한 경우, 별도의 범위(scope)가 필요하며 더 명확한 확인 절차를 거쳐야 합니다.

테넌트 격리(tenant isolation)는 프롬프트가 아닌 서버에서 유지하십시오. 모델에게 "조직 42만 조회해"라고 요청해서는 안 됩니다. 서버는 응답이 생성되기 전에 인증된 조직 외부의 행(row)을 거부해야 합니다. 프롬프트 지침은 액세스 제어(access-control) 계층이 아닙니다.

무엇이 호출되었는지 기록하십시오. 대행사들은 어떤 데이터가 제품 외부로 나갔는지 물을 것입니다. 도구 호출 감사(tool-call audit: 누가, 언제, 어떤 사이트나 페이지를, 어떤 도구로 호출했는지)는 첫 사고가 발생한 후에 추가하는 선택적인 운영 편의 사항이 아니라, 모든 진지한 설계의 일부여야 합니다. 이러한 로그가 없다면 고객 지원 팀은 간단한 보안 설문지에도 답변할 수 없습니다.

속도 제한(Rate-limit) 및 결과 페이지 처리(page results)를 적용하십시오. 어시스턴트는 재시도(retry)를 합니다. 제한 없는 목록 도구는 의도치 않은 데이터 펌프(data pump)가 될 수 있으므로, 페이지네이션(pagination)과 할당량(quota)은 설계 첫날부터 서버 설계에 포함되어야 합니다. 채팅 세션을 루프(loop)를 돌 수 있는 다른 API 클라이언트와 동일하게 취급하십시오.

이 중 MCP에만 고유한 내용은 없습니다. 이는 고객 대상 API를 구축할 때 필요한 것과 동일한 규율입니다. MCP는 단지 소비자를 커스텀 스크립트 대신 LLM 호스트로 만들 뿐이며, 이는 부주의한 기본 설정에 따르는 비용을 높입니다.

MCP가 대행사의 PageSpeed 모니터링에 계층화되는 방식

대행사들은 이미 일회성 내보내기가 아닌 지속적인 점검을 원하고 있습니다. 이것이 바로 여러 사이트에 걸친 자동화된 PageSpeed 모니터링 설정의 핵심입니다. 즉, 스케줄(schedules), 기준선(baselines), 그리고 인간이 신뢰할 수 있는 포트폴리오 뷰(portfolio view)를 구축하는 것입니다. 이러한 중추가 없다면, 어시스턴트는 혼란만을 가속화할 뿐입니다.

미래의 설계에서 MCP는 해당 루프를 대체하는 것이 아니라, 그 옆에 위치하게 될 것입니다. 모니터링 제품이 여전히 탐지(discovery), 스케줄, 예산(budgets), 그리고 이력(history)을 관리할 것입니다. 어시스턴트는 MCP를 사용하여 해당 데이터(truth)에 대해 좁고 구체적인 질문을 던질 것입니다: "이번 주에 우리의 상위 10개 URL 중 모바일 LCP(Largest Contentful Paint)를 통과하지 못한 것은 무엇인가요?" 또는 "월요일 이후 고객 A의 예산 위반 사항을 요약해 주세요." 답변은 앱이 보여주는 것과 동일한 수치를 인용해야 하며, 사용자의 기기 분할(device splits)이나 URL 목록을 무시한 채 공개된 PageSpeed Insights를 새로 스크래핑(scrape)한 결과여서는 안 됩니다.

우리는 이를 '대체'가 아닌 '계층화(layer)'라고 설명합니다. ChatGPT나 Claude는 테스트를 실행하고 결과를 저장하는 모니터링 시스템이 아닙니다. Watcher(또는 귀사의 유사 제품)가 여전히 그 시스템으로 남습니다. 만약 우리가 MCP를 출시한다면, 이는 초안 작성 및 분류(triage)를 위해 이미 어시스턴트 UI를 사용 중인 사람들을 위한 통제된 읽기 경로(read path)가 될 것입니다. 현재 Watcher에는 그러한 경로가 존재하지 않으며, 고객들은 앱, 내보내기(exports), 그리고 이미 실행 중인 보고서들을 사용합니다.

SaaS 사용자 데이터를 위한 MCP의 솔직한 한계

MCP는 현재 Apogee Watcher의 일부가 아닙니다. 우리는 현재 계획 및 초기 개발 단계에 있으며, 기능을 광고하는 것이 아니라 액세스 모델(access model)을 탐색하고 있는 단계입니다. 백스테이지(Backstage) 포스트는 출시일을 지어내는 것이 아니라 우리가 고민하고 있는 바를 전달해야 합니다. 다른 SaaS 팀들에게 유용한 부분은 누군가 풀 리퀘스트(pull request)를 보내기 전이라도, 이 액세스 체크리스트(access checklist)를 확인하는 것입니다.

우리가 사전에 인정하는 한계는 다음과 같습니다:

• 어시스턴트(Assistants)는 도구 응답(tool response)에 없는 임계값(thresholds)을 추측하도록 요청할 경우 여전히 숫자를 지어낼 것입니다. 측정된 값을 반환해야 하며, 모델에게 예산을 지어내라고 요청하지 마십시오.
• MCP는 빈약한 URL 인벤토리(URL inventory) 문제를 해결해주지 않습니다. 홈페이지 하나만 모니터링한다면, 어시스턴트는 현실의 아주 얇은 단면(thin slice)에 대해 자신 있게 말할 것입니다.
• 보안 검토(Security review)는 여전히 고객의 IT 정책에 달려 있습니다. 일부 기업은 어시스턴트 호스트가 클라이언트 URL을 수신하는 것을 금지할 것입니다. 그런 경우에는 데이터를 앱 내에 유지하고 사람이 작성한 요약본(human-authored summaries)을 사용하십시오.

만약 귀하의 팀이 SaaS에 LLM 호스트를 추가할지 여부를 평가하고 있다면, 데모 프롬프트(demo prompt)를 작성하기 전에 액세스 모델(access model)부터 시작하십시오. 어떤 도구가 존재하는지, 어떤 스코프(scopes)가 역할(roles)에 매핑되는지, 그리고 프리랜서가 퇴사하는 금요일 오후에 권한 취소(revocation)가 어떻게 작동하는지를 결정하십시오. 이러한 결정사항들이 문서화되고 나면, 프로토콜(protocol)은 쉬운 부분이 됩니다.

데모 전에 거부 목록(deny list)을 설계하십시오

우리는 오늘 출시하는 제품의 Watcher 모니터링 중추(monitoring spine)를 유지할 것입니다. 즉, 채팅창에 의존하지 않는 멀티 사이트 일정, 예산 및 알림입니다. MCP는 초기 탐색 단계에서 선택적인 향후 과제로 남아 있습니다. 만약 우리가 계속 진행한다면, 이는 안전하고 스코프가 지정된 읽기(scoped reads)를 위한 후보 인터페이스가 될 것이며, 이를 통해 ChatGPT와 Claude가 CSV 의식(CSV ritual) 없이 귀하의 조직 데이터와 함께 작업할 수 있게 될 것입니다. 모니터링 루프(monitoring loop)는 신뢰할 수 있는 단일 진실 공급원(source of truth)으로 유지될 것이며, 어시스턴트는 인증(auth), 스코프(scopes), 감사(audit)가 신뢰할 수 있을 만큼 충분히 잘 설계된 후에만 그곳으로 들어가는 좁은 문을 얻게 될 것입니다.

귀하의 SaaS를 위해 동일한 인터페이스를 설계하고 있다면, 거부 목록(deny list)을 먼저 작성하십시오. 어떤 필드가 경계(boundary)를 절대 벗어나지 않는지, 어떤 도구가 기본적으로 읽기 전용(read-only)인지, 그리고 응답이 서버를 떠나기 전에 테넌트 체크(tenant checks)가 어떻게 실행되는지를 결정하십시오. 그런 다음 어시스턴트에게 에이전시 워크플로(agency workflows)를 여전히 빠르게 만들어 줄 수 있는 가장 작은 규모의 도구들을 제공하십시오. 그것이 MCP가 계획 단계에서 실제 Watcher 릴리스로 넘어갈 때 우리가 스스로에게 부여할 기준입니다.