기업 SaaS의 MCP 대응 전략

기업 SaaS의 MCP 대응 전략

SaaS의 경쟁 단위가 화면에서 호출 가능한 업무 단위로 이동한다

B2B SaaS의 지난 흐름은 대체로 세 가지 축 위에서 성장했다. 첫째, 사용자가 로그인해 화면에서 업무를 처리하는 제품 경험. 둘째, 다른 시스템과 데이터를 주고받는 API. 셋째, 마켓플레이스와 플러그인을 통한 생태계 확장이다. CRM, 협업툴, 데이터 분석, 마케팅 자동화, 고객지원, 문서 관리 SaaS는 모두 이 구조 안에서 제품을 설계했다. 사용자는 SaaS 화면에 들어와 검색하고, 필터를 걸고, 리포트를 만들고, 승인하고, 발송했다. 개발자는 API를 이용해 데이터를 동기화했다. 파트너는 플러그인으로 기능을 확장했다.

AI 에이전트 시대에는 이 전제가 흔들린다. 사용자가 반드시 SaaS 화면에서 업무를 시작하지 않을 수 있기 때문이다. 사용자는 “이번 분기 이탈 위험이 높은 고객을 찾아 영업팀에 공유해줘”, “최근 고객지원 티켓 중 반복 이슈를 요약하고 제품팀에 전달할 초안을 만들어줘”, “광고 캠페인 성과가 나빠진 원인을 찾아 다음 액션을 제안해줘”처럼 자연어로 목표를 말한다. 그러면 에이전트가 여러 SaaS의 데이터와 기능을 호출해 업무 흐름을 구성한다. 이때 SaaS는 단순히 화면을 제공하는 애플리케이션이 아니라, 에이전트가 이해하고 호출할 수 있는 업무 기능의 공급자가 된다.

Model Context Protocol, 즉 MCP가 중요한 이유는 여기에 있다. MCP는 LLM 애플리케이션과 외부 데이터 소스·도구를 연결하기 위한 개방형 프로토콜로 설명된다. 공식 문서는 MCP를 AI 애플리케이션이 외부 컨텍스트와 도구를 사용할 수 있게 하는 표준화된 연결 방식으로 제시한다. 또한 MCP 아키텍처는 host, client, server 구조를 통해 AI 애플리케이션이 여러 MCP server가 제공하는 도구와 리소스를 사용할 수 있게 한다. 이 설명을 SaaS 제품 관점으로 번역하면, MCP server는 “우리 SaaS의 어떤 기능과 데이터를 에이전트가 어떤 규칙으로 사용할 수 있는가”를 외부에 제공하는 제품 표면이다. 출처:What is the Model Context Protocol?, 출처:Architecture – Model Context Protocol

중요한 점은 “MCP 서버를 만든다”가 곧바로 전략이 아니라는 것이다. MCP 대응의 본질은 API를 하나 더 노출하는 일이 아니다. 에이전트가 호출해도 되는 기능 단위를 정의하고, 사용자·조직·권한·승인·감사·과금 체계를 제품 정책으로 재설계하는 일이다. 기존 API 경제가 “개발자가 시스템을 연결하는 경제”였다면, 에이전트 호출 경제는 “AI가 사용자의 의도를 해석해 SaaS 기능을 업무 단위로 조합하는 경제”에 가깝다. SaaS 기업이 준비해야 할 것은 프로토콜 지원보다 먼저, 자사 제품을 호출 가능한 업무 단위로 다시 읽는 작업이다.

API가 있는데 왜 MCP가 필요한가

많은 SaaS 기업은 이미 REST API, GraphQL API, 웹훅, 자동화 연동, 플러그인 SDK, 앱 마켓플레이스를 갖고 있다. 그래서 “이미 API가 있는데 MCP 서버가 왜 필요한가”라는 질문은 자연스럽다. 답은 API와 MCP의 목적이 다르다는 데 있다.

기존 API는 주로 개발자를 위한 인터페이스다. 엔드포인트, 인증 토큰, 파라미터, 응답 스키마, 페이지네이션, 에러 코드, rate limit을 이해하는 사람이 시스템 간 연동을 만든다. API의 이상적인 소비자는 백엔드 개발자이거나 통합 플랫폼이다. 반면 MCP는 AI 애플리케이션과 에이전트가 외부 도구, 데이터, 리소스를 더 일관된 방식으로 발견하고 사용할 수 있게 하는 연결 계층이다. GitHub 문서도 MCP를 Copilot 같은 AI 도구가 외부 컨텍스트와 기능에 접근하는 방식으로 설명하며, MCP server가 AI 시스템에 도구와 리소스를 제공하는 위치에 있음을 강조한다. 출처:About Model Context Protocol – GitHub Docs, 출처:Architecture overview – Model Context Protocol

제품 관점에서 보면 API는 “무엇을 호출할 수 있는가”를 낮은 수준에서 제공한다. MCP는 “에이전트가 어떤 목적의 업무로 이해하고 호출할 수 있는가”를 더 전면에 둔다. 예를 들어 CRM API에 `GET /contacts`, `PATCH /deals/{id}`, `POST /notes`가 있다고 하자. 이것만으로 에이전트가 안전하게 “이탈 위험 고객을 분석하고 담당자에게 공유”할 수 있는 것은 아니다. 에이전트가 알아야 할 것은 고객 조회, 계정 활동 요약, 거래 상태 확인, 위험 신호 탐지, 공유 초안 생성, 승인 요청 같은 업무 단위다. 또한 어떤 단계는 읽기만 가능하고, 어떤 단계는 사용자의 명시적 승인이 있어야 실행되어야 한다.

웹훅과도 다르다. 웹훅은 이벤트 발생 시 외부 시스템에 알림을 보내는 구조다. “고객이 결제 실패”, “티켓 상태 변경”, “문서 생성 완료” 같은 이벤트 중심이다. 에이전트 호출은 이벤트만이 아니라 목표 지향적이다. 사용자가 요청하면 에이전트가 필요한 데이터를 찾고, 여러 도구를 순차 호출하고, 중간 결과를 해석해 다음 호출을 결정한다. 웹훅이 수동적 통지라면, MCP 기반 도구 호출은 능동적 업무 수행에 가깝다.

플러그인 구조와도 차이가 있다. 전통적인 SaaS 플러그인은 특정 앱 안에 기능을 설치하거나 UI를 확장하는 방식이 많다. 반면 MCP server는 특정 호스트 안에서만 쓰이는 기능 확장이라기보다, 여러 AI 클라이언트와 에이전트가 표준화된 방식으로 SaaS 기능을 발견하고 호출하게 만드는 외부 접점이다. 물론 MCP가 모든 플러그인과 API를 대체한다는 뜻은 아니다. 실무적으로는 API가 내부 구현과 기존 연동의 기반으로 남고, MCP는 에이전트 친화적 업무 표면을 제공하는 상위 계층이 되는 구도가 더 현실적이다.

구분 기존 API 웹훅 플러그인·앱 마켓플레이스 MCP server
주 사용자 개발자, 통합 플랫폼 외부 시스템 파트너 개발자, 제품 사용자 AI 에이전트, AI 애플리케이션
중심 단위 엔드포인트, 리소스 이벤트 앱 확장 기능 도구, 리소스, 프롬프트/컨텍스트
호출 방식 명시적 프로그래밍 이벤트 발생 시 통지 설치 후 UI·기능 확장 에이전트가 목적에 맞게 도구 호출
제품 설계 초점 데이터·기능 접근성 상태 변화 전달 생태계 확장 안전한 업무 단위와 권한 경계
핵심 리스크 오남용, 과도한 권한 이벤트 유실, 중복 처리 품질 관리, 보안 에이전트 오판, 고위험 액션 자동화

따라서 SaaS 기업이 던져야 할 질문은 “우리에게 API가 있는가”가 아니다. “우리 기능은 에이전트가 이해 가능한 업무 단위로 정리되어 있는가”, “읽기와 쓰기, 추천과 실행, 초안과 발송이 분리되어 있는가”, “AI가 호출했을 때 사용자에게 설명 가능하고 감사 가능한가”가 더 중요하다.

에이전트 호출 경제에서 SaaS는 무엇을 잃고 무엇을 얻는가

SaaS의 전통적 유통 구조에서는 사용자가 제품을 발견하고, 계정을 만들고, 화면에서 기능을 익히고, 반복 사용을 통해 락인이 형성된다. 하지만 에이전트가 업무 출발점이 되면 사용자는 개별 SaaS의 화면보다 “나의 업무를 처리해주는 에이전트”에 더 오래 머물 수 있다. 이 경우 SaaS의 노출면은 줄어들 수 있다. 사용자는 CRM 화면을 열지 않고도 CRM 데이터를 조회하고, 분석 도구 화면을 열지 않고도 리포트를 받고, 고객지원 도구에 들어가지 않고도 티켓 요약과 답변 초안을 받을 수 있다.

이 변화는 위협이지만 동시에 기회다. 화면 방문 빈도가 줄어도, SaaS 기능이 더 많은 업무 흐름에 삽입될 수 있기 때문이다. 과거에는 사용자가 자발적으로 특정 SaaS에 들어와야 기능이 사용됐다. 앞으로는 에이전트가 “이 업무에는 이 SaaS의 데이터가 필요하다”고 판단하는 순간 호출이 발생한다. 제품의 경쟁 단위가 UI 체류 시간에서 업무 흐름 내 호출 빈도와 신뢰도로 이동할 수 있다.

특히 B2B SaaS는 이 변화에 민감하다. 업무 데이터가 여러 시스템에 흩어져 있고, 실제 업무는 시스템 간 경계를 넘나들기 때문이다. 고객지원 이슈 하나만 봐도 티켓 시스템, CRM, 제품 분석, 문서 저장소, 협업툴, 데이터 웨어하우스가 얽힌다. 에이전트는 이런 복합 업무를 처리하기 위해 여러 도구를 호출한다. Snowflake는 Natoma 인수 의향 발표에서 Natoma를 기업용 MCP 플랫폼으로 설명하고, Snowflake의 거버넌스 범위를 데이터 자산에서 AI 액션과 상호작용까지 확장하겠다고 밝혔다. 이는 MCP가 단순 개발자 편의 기능이 아니라 기업 운영 통제 계층과 연결된다는 신호로 읽을 수 있다. 출처:Snowflake Announces Intent to Acquire Natoma

SaaS 기업이 얻을 수 있는 기회는 세 가지다. 첫째, 자사 기능이 더 넓은 업무 흐름의 기본 도구로 편입될 수 있다. 둘째, 사용량 기반 과금이나 에이전트 경유 호출 과금 같은 새로운 수익 모델을 설계할 수 있다. 셋째, 고객사의 AI 도입 과정에서 신뢰할 수 있는 데이터·액션 공급자로 자리 잡을 수 있다. 반대로 잃을 수 있는 것은 사용자 접점, 브랜드 체감, 화면 기반 업셀 기회다. 그래서 MCP 대응은 개발팀의 사이드 프로젝트가 아니라 제품·사업·보안·고객성공 조직이 함께 다뤄야 할 전략 과제다.

MCP server는 앱 전체가 아니라 업무 동사를 노출해야 한다

가장 흔한 오해는 “우리 SaaS의 모든 API를 MCP로 감싸면 된다”는 생각이다. 이 접근은 위험하다. 에이전트에게 필요한 것은 데이터베이스 리소스 전체가 아니라 목적에 맞게 제한된 업무 동사다. SaaS 기업은 앱 전체를 열기보다, 에이전트가 호출해도 안전하고 가치가 분명한 기능 단위부터 정의해야 한다.

우선순위는 읽기, 검색, 요약, 분석, 초안 생성, 상태 확인 같은 저위험 작업에서 시작하는 것이 합리적이다. 예를 들어 CRM SaaS라면 “고객 기본 정보 조회”, “최근 상호작용 요약”, “갱신 예정 계정 검색”, “이탈 위험 신호 설명”, “영업 미팅 준비 브리프 생성”이 1차 후보가 된다. 고객지원 SaaS라면 “티켓 검색”, “반복 문의 클러스터 요약”, “SLA 위험 티켓 조회”, “답변 초안 작성”, “에스컬레이션 후보 추천”이 적합하다. 문서 관리 SaaS라면 “문서 검색”, “권한 있는 문서 요약”, “관련 문서 묶음 추천”, “회의용 요약 생성”이 시작점이다.

반대로 결제, 삭제, 대량 발송, 권한 변경, 고객 데이터 수정, 법적 효력이 있는 승인, 외부 공개 게시, 개인정보 대량 추출은 처음부터 자동 실행 도구로 열면 안 된다. 이런 기능은 사용자의 명시적 확인, 조직 정책, 감사 로그, 복구 절차가 함께 설계된 뒤 제한적으로 제공해야 한다. 에이전트는 그럴듯한 판단을 내릴 수 있지만, 제품 책임을 대신 져주지는 않는다. 특히 B2B 환경에서는 잘못된 대량 이메일 발송, 고객 등급 변경, 계약 조건 수정, 데이터 삭제가 곧 고객 신뢰와 법적 리스크로 이어진다.

기능 단위 설계에서 실무적으로 유용한 기준은 “동사-대상-위험도-승인 필요성”이다.

기능 후보 예시 위험도 MCP 노출 방식
조회 특정 고객의 계약 상태 확인 낮음 기본 제공 가능. 사용자 권한 상속 필수
검색 조건에 맞는 티켓·고객·문서 찾기 낮음~중간 결과 범위 제한, 민감 필드 마스킹
요약 최근 활동·문서·이슈 요약 낮음~중간 출처 링크와 근거 포함
초안 작성 답변 메일, 리포트, 캠페인 문안 초안 중간 초안까지만 허용, 발송은 별도 승인
상태 변경 티켓 상태, 거래 단계 변경 중간~높음 정책 기반 승인 또는 사용자 확인
외부 발송 이메일, 메시지, 캠페인 발송 높음 기본 비활성. 승인·샘플링·취소 절차 필요
삭제·권한 변경 데이터 삭제, 역할 부여 매우 높음 원칙적으로 제한. break-glass 정책 필요

이 표의 핵심은 기능을 API 리소스 기준이 아니라 업무 리스크 기준으로 다시 나누는 것이다. SaaS 내부 API에서는 `updateCustomer`, `deleteFile`, `sendCampaign`이 모두 평범한 엔드포인트일 수 있다. 하지만 에이전트 호출 표면에서는 전혀 다른 정책을 가져야 한다. MCP server는 기존 API 위의 얇은 변환 레이어가 아니라, 제품 정책을 반영한 안전한 업무 카탈로그가 되어야 한다.

권한 모델은 사용자 권한 상속만으로 부족하다

MCP 공식 사양은 HTTP 기반 transport에서 권한 부여를 다루며, MCP client가 resource owner를 대신해 제한된 MCP server에 요청할 수 있는 authorization capabilities를 제공한다고 설명한다. 공식 권한 문서는 OAuth 2.1 기반의 보안 구현을 설명하고, 보호 대상 리소스와 권한 서버 메타데이터 같은 개념을 다룬다. 이는 MCP 대응에서 인증·인가가 표준적으로 중요한 영역임을 보여준다. 하지만 SaaS 제품 관점에서는 프로토콜 수준의 authorization만으로 충분하지 않다. 출처:Authorization – Model Context Protocol, 출처:Understanding Authorization in MCP

첫 번째 원칙은 사용자 권한 상속이다. 에이전트가 어떤 사용자를 대신해 호출한다면, 그 사용자가 SaaS 화면에서 볼 수 없는 데이터는 MCP를 통해서도 볼 수 없어야 한다. 조직, 워크스페이스, 프로젝트, 팀, 역할, 레코드 수준 권한이 그대로 적용되어야 한다. “AI용 별도 슈퍼 토큰”을 만들어 모든 데이터에 접근시키는 방식은 초기 데모에는 편하지만 운영 환경에서는 위험하다.

두 번째 원칙은 에이전트 권한의 별도 축이다. 사용자가 어떤 데이터를 볼 수 있다고 해서 에이전트가 그 데이터를 대량으로 추출하거나 외부로 전송해도 된다는 뜻은 아니다. SaaS는 사람 사용자 권한과 에이전트 실행 권한을 분리해야 한다. 예를 들어 영업 매니저는 모든 계정 정보를 볼 수 있지만, 에이전트가 한 번에 전체 고객 목록을 외부 파일로 내보내는 것은 제한할 수 있어야 한다. 즉 “사용자 권한”, “에이전트 권한”, “액션 위험도”, “데이터 민감도”가 함께 평가되어야 한다.

세 번째 원칙은 읽기와 쓰기의 분리다. MCP server가 제공하는 도구는 read-only, draft-only, write-with-approval, write-autonomous 같은 등급으로 나눌 수 있다. 초기에는 read-only와 draft-only 중심으로 시작하고, 고객별 정책이 성숙한 뒤 제한적 쓰기 기능을 열어야 한다. 특히 `초안 작성`과 `발송`은 분리해야 한다. “고객에게 보낼 답변을 작성해줘”는 허용 가능하지만, “작성한 답변을 고객에게 보내줘”는 승인 흐름이 필요하다.

네 번째 원칙은 조직 정책의 우선 적용이다. B2B SaaS에서는 개인 사용자의 선호보다 조직의 보안 정책이 우선한다. 관리자는 어떤 MCP client를 허용할지, 어떤 도구를 활성화할지, 어떤 데이터 범위를 노출할지, 어떤 액션에 승인이 필요한지 설정할 수 있어야 한다. GitHub의 MCP 설명도 엔터프라이즈 환경에서 Copilot이 MCP를 통해 외부 도구와 컨텍스트를 연결할 수 있다는 점을 다루는데, 기업 도입에서는 연결 자체보다 관리와 통제가 핵심이다. 출처:Model Context Protocol and GitHub Copilot coding agent

감사 로그는 부가 기능이 아니라 제품 신뢰의 핵심 화면이다

에이전트 호출 경제에서 감사 로그는 보안팀용 후처리 기능이 아니다. 사용자가 에이전트가 한 일을 이해하고, 관리자가 조직 내 사용을 통제하며, 장애나 오작동이 발생했을 때 복구할 수 있게 하는 핵심 제품 기능이다.

기존 API 로그는 대개 개발자 친화적이다. 요청 시간, 엔드포인트, 상태 코드, latency, client id, IP 주소, 에러 메시지 중심이다. MCP 시대의 로그는 여기에 업무 맥락을 더해야 한다. 누가 요청했는가. 어떤 AI client 또는 host를 통해 호출됐는가. 어떤 tool이 선택됐는가. 어떤 입력 요약이 전달됐는가. 어떤 데이터 범위가 조회됐는가. 어떤 결과가 반환됐는가. 쓰기 액션이라면 어떤 변경이 발생했는가. 승인자는 누구였는가. 실패했다면 어느 단계에서 멈췄는가. 사용자가 취소하거나 되돌릴 수 있는가.

실무적으로는 로그를 세 계층으로 나누는 것이 좋다. 첫째, 보안·컴플라이언스 로그다. 관리자와 보안팀이 보는 로그로 인증, 권한 거부, 민감 데이터 접근, 대량 조회, 고위험 액션을 기록한다. 둘째, 사용자 활동 로그다. 최종 사용자가 “에이전트가 내 계정으로 무엇을 했는지” 이해할 수 있게 보여준다. 셋째, 운영 디버깅 로그다. 개발·SRE 조직이 tool 호출 실패, timeout, rate limit, downstream API 오류를 분석하는 데 쓴다.

감사 로그에는 “AI가 왜 그랬는가”를 완벽히 설명하려는 욕심보다 “무엇을 호출했고 어떤 상태 변화가 있었는가”를 정확히 남기는 것이 우선이다. LLM의 내부 추론을 기록하는 방식은 제품·보안·개인정보 측면에서 조심해야 한다. 대신 도구 호출의 입력, 출력 요약, 근거 리소스, 변경 전후 상태, 승인 이벤트를 구조화해 남겨야 한다. 사용자는 자연어 요청을 했지만, 기업 시스템은 구조화된 책임 기록을 요구한다.

운영 제어: rate limit보다 중요한 것은 실패와 복구 설계다

SaaS 기업은 MCP 대응을 시작할 때 흔히 인증, rate limit, API gateway, monitoring을 먼저 떠올린다. 모두 필요하다. 하지만 에이전트 호출에서는 일반 API보다 실패 양상이 복잡하다. 에이전트는 하나의 사용자 요청을 처리하기 위해 여러 도구를 연속 호출할 수 있고, 중간 결과에 따라 다음 호출을 바꿀 수 있다. 따라서 단일 엔드포인트 성공·실패만 보는 운영 모델로는 충분하지 않다.

예를 들어 에이전트가 고객 브리프를 만들기 위해 CRM 조회, 티켓 조회, 사용량 조회, 문서 검색, 요약 생성을 순서대로 수행한다고 하자. 이 중 하나가 실패했을 때 전체 작업을 중단할지, 일부 결과만 보여줄지, 재시도할지, 사용자에게 어떤 수준으로 설명할지 정해야 한다. 특히 쓰기 작업이 포함된 경우 부분 실행 실패는 더 위험하다. 캠페인 대상 세그먼트는 생성됐지만 발송 승인이 실패하거나, 티켓 상태는 바뀌었지만 알림 전송이 실패하는 상황을 처리해야 한다.

운영 설계의 핵심은 idempotency, 단계별 상태 기록, rollback 가능성, 사용자 재확인이다. 같은 요청이 반복 호출돼도 중복 발송이나 중복 변경이 발생하지 않아야 한다. 긴 작업은 job id를 부여해 상태를 추적해야 한다. 쓰기 작업은 변경 전후를 기록하고, 가능한 경우 되돌리기 경로를 제공해야 한다. 자동 재시도는 읽기 작업과 안전한 작업에 제한하고, 외부 발송·결제·삭제 같은 고위험 작업에는 재확인 절차를 둬야 한다.

또 하나의 운영 이슈는 비용과 부하다. 에이전트는 사람보다 더 자주, 더 넓게, 더 반복적으로 도구를 호출할 수 있다. 한 사용자가 같은 자연어 요청을 여러 번 시도하면 유사한 조회가 중복될 수 있다. 따라서 캐싱, 쿼리 제한, 결과 페이지네이션, 대량 작업 큐잉, 비용 기반 rate limit, 조직별 quota가 필요하다. AWS Labs가 AWS 관련 MCP server들을 공개 저장소로 제공하고, AWS가 Kiro를 활용한 RDS/Aurora 장애 분석 자동화 예시를 다루는 흐름은 클라우드·운영 영역에서도 MCP와 에이전트형 도구 호출이 운영 제어 문제와 맞닿아 있음을 보여준다. 출처:awslabs/mcp, 출처:Part 1: Kiro로 RDS/Aurora 장애 분석 자동화하기

고객 데이터 보호: 에이전트 친화성과 최소 노출의 균형

에이전트가 좋은 결과를 내려면 충분한 컨텍스트가 필요하다. 하지만 SaaS는 모든 데이터를 통째로 넘길 수 없다. 이 긴장이 MCP 설계의 중심에 있다. 특히 B2B SaaS는 개인정보, 영업비밀, 계약정보, 내부 문서, 고객 대화, 재무 데이터 같은 민감 정보를 다룬다. 에이전트 호출이 늘어날수록 데이터 노출 경로도 늘어난다.

첫 번째 대응은 리소스 단위의 최소 노출이다. 에이전트가 “고객 이탈 위험을 분석”할 때 전체 고객 DB가 필요한 것은 아니다. 최근 사용량, 계약 갱신일, 지원 티켓 수, 만족도, 담당자 메모의 일부 등 목적에 맞는 필드만 필요할 수 있다. SaaS는 tool별로 반환 필드를 제한하고, 민감 필드는 기본 마스킹하며, 필요 시 별도 승인 후 확장 노출하는 방식을 설계해야 한다.

두 번째 대응은 목적 기반 접근이다. 같은 데이터라도 목적에 따라 허용 범위가 달라진다. “내일 미팅 준비”를 위한 고객 요약에는 최근 활동과 공개 가능한 계약 상태가 충분할 수 있다. “법무 검토”를 위한 계약 리스크 분석에는 다른 권한과 기록이 필요하다. MCP server의 tool 설명과 권한 정책은 이 목적 차이를 반영해야 한다.

세 번째 대응은 출력 제어다. 에이전트가 조회한 데이터를 어디에 출력할 수 있는지도 중요하다. 사내 협업툴에 요약을 게시하는 것, 외부 고객에게 이메일로 발송하는 것, 로컬 파일로 내보내는 것은 위험도가 다르다. 따라서 SaaS는 데이터 조회 권한뿐 아니라 결과 사용 경로에 대한 정책도 고려해야 한다. 이 영역은 전통 API 권한보다 제품 정책에 더 가깝다.

네 번째 대응은 tenant isolation이다. 멀티테넌트 SaaS에서 MCP server가 조직 경계를 잘못 처리하면 치명적이다. 기존 API 계층에서 이미 테넌트 격리를 하고 있더라도, MCP tool에서 여러 내부 API를 조합하는 과정에서 필터 누락이 발생할 수 있다. MCP 계층은 기존 권한 체계를 재사용하되, tool 조합 과정에서 테넌트·프로젝트·레코드 범위가 유지되는지 별도 테스트해야 한다.

과금: 좌석 수만으로 설명되지 않는 사용량이 생긴다

SaaS 과금은 전통적으로 좌석 수, 기능 플랜, 저장 용량, 사용량, API 호출량, 워크플로우 실행량을 조합해왔다. 에이전트 호출 경제에서는 이 조합이 더 복잡해진다. 사용자가 화면에 로그인하지 않아도, 에이전트가 SaaS 기능을 호출해 가치를 소비할 수 있기 때문이다.

첫 번째 질문은 에이전트 경유 사용량을 어떻게 측정할 것인가다. 같은 고객 데이터 조회라도 사람이 화면에서 본 것인지, 내부 자동화가 호출한 것인지, 외부 AI client가 MCP를 통해 호출한 것인지 구분해야 한다. 이를 구분하지 못하면 원가 분석, quota 관리, 고객별 ROI 설명, abuse 탐지가 어려워진다.

두 번째 질문은 어떤 단위를 과금할 것인가다. 모든 MCP 호출에 단순 과금을 붙이면 고객 반발이 생길 수 있다. 반대로 무제한으로 열면 고비용 분석·요약·대량 조회가 원가를 잠식할 수 있다. 실무적으로는 저위험 조회·검색은 기존 플랜에 포함하고, 고비용 분석, 대량 리포트 생성, 외부 발송, 고빈도 자동화, 프리미엄 데이터 접근은 별도 quota나 add-on으로 묶는 방식이 현실적이다.

세 번째 질문은 가치 기준이다. 에이전트 호출은 API call 수와 고객 가치가 반드시 비례하지 않는다. “문서 여러 개를 검색해 하나의 의사결정 브리프를 만드는 작업”은 호출 수보다 결과물 가치가 크다. 반대로 단순 상태 확인은 호출이 많아도 낮은 가치일 수 있다. SaaS 기업은 호출량 기반 원가 회수와 업무 결과 기반 패키징 사이에서 균형을 찾아야 한다.

네 번째 질문은 파트너 유통이다. AI 에이전트 플랫폼, 클라우드, 협업툴, 산업별 vertical agent가 SaaS 기능을 호출하는 유통 채널이 될 수 있다. 이때 SaaS는 기존 앱 마켓플레이스처럼 인증된 MCP client 목록, 파트너별 quota, 수익 배분, 고객 동의 흐름, 로그 공유 범위를 설계해야 한다. Cloudflare는 Stripe와 함께 에이전트가 Cloudflare 계정 생성, 도메인 구매, 배포 흐름을 처리할 수 있는 사례를 소개했다. 이는 에이전트가 단순한 보조 인터페이스를 넘어 서비스 가입·결제·배포 같은 상거래와 운영 흐름에도 들어오고 있음을 보여준다. 출처:Agents can now create Cloudflare accounts, buy domains, and deploy

제품 로드맵: MCP 대응은 네 단계로 나누어야 한다

MCP 대응을 “서버를 만들 것인가 말 것인가”로 접근하면 실행이 흐려진다. 제품 로드맵은 네 단계로 나누는 것이 좋다.

1단계: 에이전트가 호출할 가치가 있는 업무 목록화

먼저 자사 SaaS에서 반복적이고 정보 집약적이며 자연어 요청과 잘 맞는 업무를 찾는다. CRM이라면 계정 브리핑, 갱신 위험 분석, 미팅 준비. 고객지원이라면 티켓 요약, 반복 이슈 탐지, 답변 초안. 데이터 분석 SaaS라면 지표 해석, 이상 탐지, 리포트 초안. 문서 관리라면 권한 내 문서 검색, 회의 전 자료 요약, 정책 문서 비교가 후보가 된다.

이 단계에서 중요한 것은 “기능명”이 아니라 “사용자 요청 문장”으로 정리하는 것이다. 예를 들어 “티켓 API 제공”이 아니라 “최근 VIP 고객의 미해결 티켓을 요약해줘”처럼 작성해야 한다. 에이전트 호출은 사용자의 업무 언어에서 출발하기 때문이다. 특정 기간이나 기준을 넣어야 한다면 제품 정책, 고객 설정, 실제 데이터 보존 조건에서 확인되는 값만 사용해야 한다.

2단계: 기능을 위험도별로 분류

각 업무를 읽기, 분석, 초안, 상태 변경, 외부 발송, 삭제·권한 변경으로 나눈다. 그리고 도구별로 허용 범위, 필요한 권한, 승인 필요 여부, 로그 수준, rate limit, 복구 가능성을 정의한다. 이 단계에서 고위험 작업은 과감히 뒤로 미뤄야 한다. 초기 MCP 대응의 성공 기준은 “많이 여는 것”이 아니라 “안전하게 유용한 것을 여는 것”이다.

3단계: 기존 API 위에 제품 정책 계층 구성

MCP server는 기존 API를 재사용할 가능성이 높다. 하지만 그대로 노출하면 안 된다. 기존 API 위에 tool 정의, 입력 검증, 출력 필드 제한, 권한 확인, 승인 흐름, 감사 로그, idempotency, 실패 복구를 포함한 정책 계층을 둬야 한다. 이 계층이 없으면 MCP는 API의 위험을 더 넓은 에이전트 생태계로 확산시키는 통로가 된다.

4단계: 고객 관리자용 제어판 제공

B2B 고객은 MCP 기능을 켜고 끄는 관리 기능을 요구할 것이다. 어떤 AI client를 허용할지, 어떤 tool을 사용할 수 있는지, 어떤 부서에 열지, 민감 데이터는 어떻게 마스킹할지, 고위험 액션 승인자는 누구인지, 월별 quota는 얼마인지 설정해야 한다. 이 제어판은 부가 기능이 아니라 엔터프라이즈 판매의 핵심 신뢰 요소가 된다.

실무 시나리오: SaaS별 MCP 기능은 이렇게 시작한다

시나리오 1: CRM의 갱신 위험 계정 브리핑

상황: 영업 매니저가 “이번 달 갱신 예정 고객 중 위험 신호가 있는 계정을 정리해줘”라고 에이전트에 요청한다.

입력: 조직 내 권한이 있는 계정 범위, 갱신 예정일, 최근 활동, 지원 티켓, 사용량 신호.

실행 흐름: 에이전트는 CRM MCP server의 계정 검색 tool을 호출하고, 고객지원 SaaS 또는 내부 데이터와 연결된 요약 tool을 호출한 뒤, 위험 근거를 묶어 브리프를 만든다. CRM은 고객별 민감 필드를 제한하고, 담당자 권한이 없는 계정은 반환하지 않는다.

출력: “갱신 위험 상위 계정”, “위험 근거”, “권장 후속 액션”, “담당자별 follow-up 초안”.

주의점: 에이전트가 거래 단계나 갱신 확률을 자동 변경하게 해서는 안 된다. 상태 변경은 담당자 승인 후 실행해야 한다.

시나리오 2: 고객지원 티켓의 반복 이슈 탐지

상황: CX 리더가 “최근 반복된 장애성 문의를 제품팀에 공유할 수 있게 요약해줘”라고 요청한다.

입력: 티켓 제목, 본문 일부, 태그, 고객 등급, SLA 상태, 제품 영역.

실행 흐름: 고객지원 SaaS MCP server는 권한 내 티켓 검색과 클러스터 요약 tool을 제공한다. 에이전트는 반복 패턴을 묶고, 근거 티켓 링크를 포함한 제품팀 공유 초안을 생성한다.

출력: 반복 이슈 목록, 빈도 추세, 영향 고객군, 대표 티켓, 제품팀 전달 초안.

주의점: 고객 개인정보와 민감 대화 원문은 기본적으로 마스킹해야 한다. 외부 채널 게시나 고객 공지는 별도 승인 흐름이 필요하다.

시나리오 3: 데이터 분석 SaaS의 지표 이상 원인 분석

상황: PM이 “이번 주 활성 사용자 수가 떨어진 이유를 찾아줘”라고 묻는다.

입력: 제품 지표, 릴리스 일정, 캠페인 일정, 오류 로그 요약, 세그먼트별 사용량.

실행 흐름: 분석 SaaS는 지표 조회, 세그먼트 비교, 리포트 생성 tool을 제공한다. 에이전트는 관련 지표를 순차 조회하고, 이상 구간을 찾고, 가능한 원인을 가설로 정리한다.

출력: 지표 변화 요약, 영향을 받은 세그먼트, 가능한 원인, 확인해야 할 추가 데이터, 의사결정용 리포트 초안.

주의점: 에이전트의 분석은 통계적 확정이 아니라 가설일 수 있다. 제품은 수치 근거, 쿼리 조건, 비교 기간을 함께 제공해야 한다. 확인되지 않은 원인을 단정하는 표현은 피해야 한다.

시나리오 4: 마케팅 자동화 SaaS의 캠페인 초안 생성

상황: 마케터가 “휴면 고객 재참여 캠페인 초안을 만들어줘”라고 요청한다.

입력: 세그먼트 조건, 과거 캠페인 성과, 수신 동의 상태, 브랜드 가이드, 금지 문구.

실행 흐름: MCP server는 세그먼트 조회와 캠페인 초안 생성까지 허용한다. 실제 발송은 승인 요청 tool로 넘기고, 관리자나 담당자가 검토한 뒤 실행한다.

출력: 대상 세그먼트 요약, 메시지 초안, 예상 리스크, 승인 요청.

주의점: 대량 발송은 고위험 작업이다. 수신 동의, 빈도 제한, 법적 문구, opt-out 처리를 자동 검증해야 한다.

시나리오 5: 문서 관리 SaaS의 회의 준비 브리프

상황: 임원이 “내일 파트너 미팅 전에 관련 문서와 최근 논의 내용을 정리해줘”라고 요청한다.

입력: 캘린더 참석자, 문서 권한, 최근 공유 문서, 회의록, 관련 프로젝트.

실행 흐름: 문서 관리 SaaS의 MCP server는 권한 내 문서 검색, 문서 요약, 관련 문서 추천 tool을 제공한다. 에이전트는 문서 원문 전체를 외부로 넘기지 않고 필요한 요약과 링크를 구성한다.

출력: 회의 목적 추정, 관련 문서 목록, 핵심 쟁점, 미확정 사항, 질문 목록.

주의점: 권한 없는 문서는 존재 여부도 노출하지 않는 것이 원칙이다. 요약 결과에는 원문 링크와 접근 권한이 함께 유지되어야 한다.

MCP 대응의 조직 설계: 개발팀만의 일이 아니다

MCP server를 만드는 작업은 기술적으로는 플랫폼·백엔드 팀이 주도할 수 있다. 그러나 어떤 기능을 열지, 어떤 액션을 승인 대상으로 둘지, 어떤 로그를 고객에게 보여줄지, 어떤 사용량을 과금할지는 제품·보안·법무·고객성공·사업 전략의 공동 의사결정이다.

PM과 PO는 에이전트가 호출할 업무 단위를 정의해야 한다. “우리 제품의 핵심 화면은 무엇인가”가 아니라 “사용자가 에이전트에게 어떤 업무를 맡길 것인가”를 기준으로 기능을 재정렬해야 한다. 서비스기획자는 승인 흐름, 취소 흐름, 관리자 설정, 사용자 안내 문구를 설계해야 한다. 백엔드 개발자는 기존 권한 모델과 MCP tool 호출 사이의 일관성을 보장해야 한다. 보안팀은 민감 데이터 노출, 외부 client 허용, 감사 로그 보존 정책을 검토해야 한다. 사업팀은 에이전트 경유 사용량이 기존 플랜과 충돌하지 않도록 가격 정책을 정리해야 한다.

특히 고객성공 조직의 역할이 중요해진다. MCP 기능은 고객사가 내부 AI 도입을 확대할수록 “어떻게 안전하게 쓸 것인가”라는 질문을 동반한다. 고객성공팀은 고객의 업무 흐름을 파악해 어떤 tool을 활성화할지, 어떤 부서부터 시작할지, 어떤 성공 지표를 볼지 제안해야 한다. 단순 기능 교육에서 AI 업무 흐름 설계 컨설팅으로 역할이 확장될 수 있다.

도입 체크리스트: 지금 SaaS 기업이 물어야 할 질문

MCP 대응을 준비하는 SaaS 기업은 다음 질문부터 점검해야 한다.

  • 에이전트가 호출할 만한 핵심 업무 시나리오가 정의되어 있는가.
  • 각 시나리오가 조회, 검색, 요약, 초안, 변경, 발송, 삭제 중 어디에 해당하는가.
  • 기존 사용자 권한과 조직 권한을 MCP tool 호출에 그대로 적용할 수 있는가.
  • read-only tool과 write tool이 명확히 분리되어 있는가.
  • 고위험 액션에 사용자 승인, 관리자 승인, 2인 승인 같은 정책을 붙일 수 있는가.
  • tool 호출마다 사용자, 조직, client, 입력 요약, 조회 범위, 결과, 상태 변경을 로그로 남길 수 있는가.
  • 에이전트 경유 호출량을 기존 API 호출량과 구분해 측정할 수 있는가.
  • 대량 조회, 반복 호출, 실패 재시도, 부분 실행 실패에 대한 제한과 복구 절차가 있는가.
  • 민감 필드 마스킹, 목적별 데이터 최소화, tenant isolation 테스트가 준비되어 있는가.
  • 고객 관리자에게 MCP 기능 활성화, client 허용, tool별 권한, quota를 설정할 화면을 제공할 계획이 있는가.
  • 에이전트 경유 사용량을 기존 플랜에 포함할지, add-on이나 usage-based 모델로 분리할지 원칙이 있는가.
  • 외부 AI 플랫폼이나 파트너가 자사 MCP server를 호출할 때 인증, 계약, 수익 배분, 지원 범위가 정의되어 있는가.

이 체크리스트의 핵심은 기술 구현보다 제품 운영 체계다. MCP server가 동작하는 데모를 만드는 것은 상대적으로 빠를 수 있다. 그러나 엔터프라이즈 고객이 안심하고 쓰게 만드는 데 필요한 권한, 승인, 감사, 과금, 지원 체계는 훨씬 오래 걸린다.

결론: MCP는 API의 대체재가 아니라 SaaS 제품 표면의 재구성이다

MCP를 과장해서 볼 필요는 없다. 모든 SaaS가 곧 AI 에이전트에 대체되는 것도 아니고, MCP server 하나가 제품 경쟁력을 자동으로 만들어주는 것도 아니다. 많은 업무는 여전히 화면, 워크플로우, 대시보드, 협업 기능을 필요로 한다. 기존 API와 웹훅, 플러그인 생태계도 계속 중요하다.

그러나 방향은 분명하다. AI 에이전트가 업무의 출발점이 되는 순간, SaaS는 더 이상 “사용자가 들어와 조작하는 앱”으로만 존재할 수 없다. 에이전트가 안전하게 이해하고 호출할 수 있는 업무 기능의 공급자가 되어야 한다. 이때 API는 내부 기반이고, MCP는 에이전트 친화적 제품 표면이다.

따라서 SaaS 기업의 MCP 대응 전략은 다음 한 문장으로 정리할 수 있다. “우리 제품의 핵심 가치를 에이전트가 호출 가능한 안전한 업무 단위로 재설계하라.” 여기에는 기능 개방 우선순위, 권한·승인 모델, 감사 로그, 운영 제어, 데이터 최소화, 과금 구조, 파트너 유통 전략이 모두 포함된다.

PM·PO와 서비스기획자는 화면 중심 제품 사고에서 업무 호출 중심 제품 사고로 이동해야 한다. 플랫폼·백엔드 개발자는 기존 API를 그대로 노출하는 대신 정책 계층을 설계해야 한다. 사업·전략 담당자는 좌석 수와 화면 사용량을 넘어 에이전트 경유 가치 소비를 측정해야 한다. 경영진은 MCP를 단기 유행이 아니라 B2B SaaS 유통 구조가 바뀌는 신호로 보아야 한다.

API 경제에서 승자는 좋은 개발자 경험과 안정적인 연동을 제공한 SaaS였다. 에이전트 호출 경제에서 승자는 에이전트가 신뢰하고, 사용자가 승인할 수 있으며, 기업 관리자가 통제할 수 있는 업무 단위를 제공하는 SaaS가 될 가능성이 높다. MCP server는 그 전환의 출발점일 뿐이다. 진짜 경쟁력은 그 뒤에 있는 제품 정책, 운영 체계, 신뢰 설계에서 나온다.

참고 출처