SaaS MCP 연동 5단계 | 자사 SaaS 2개로 굳힌 구현의 정형

SaaS의 MCP 연동란?

SaaS의 MCP 연동이란 자사의 기존 REST API 위에, Claude나 Cursor 같은 AI 클라이언트에서 직접 조작할 수 있는 MCP 서버 계층을 추가하는 것입니다. 저희는 자사 SaaS 2개(툴 8개 구성의 CMS와 메일 API)로 구현·프로덕션 운영하며, API를 다시 만들지 않고도 대응할 수 있음을 확인했습니다.

안녕하세요. AI 웹사이트 제작과 AI 개발 회사 “Webharu”를 운영하고 있는 마사토입니다. 자사 SaaS로 CMS와 메일 API를 개발·운영하고 있습니다.

“고객사로부터 MCP 연동을 요구받고 있다”, “임원 회의에서 AI 에이전트 대응이 경쟁사 대비 과제로 지적되었다” — 이런 상담이 기존 SaaS나 회원 기반을 운영하는 기업으로부터 늘고 있습니다. 이 글은 저희가 자사 SaaS 2개 — CMS(MCP 툴 8개)와 메일 API — 를 실제로 MCP 연동시키고 프로덕션에서 운영하는 과정에서 굳어진 구현의 정형을 정리한 것입니다. 독자는 기존 SaaS·업무 시스템·회원 기반을 이미 운영하고 있는 기업의 CTO·프로덕트 책임자를 상정하고 있습니다. 앞으로 새로 프로덕트를 만드는 개인·소규모 개발자는 이 글의 대상이 아닙니다(개인 개발자용으로는 별도 상품인 교재를 준비 중입니다).

먼저 결론입니다. SaaS의 MCP 연동은 기존 REST API 위에 얇은 MCP 계층을 더하는 구성이 기본입니다. API를 다시 만들 필요도 없고, MCP를 위해 별도의 시스템을 세울 필요도 없습니다. 작업량의 대부분을 차지해야 하는 것은 구현 그 자체가 아니라 “툴의 세분성”, “위험한 조작을 멈추는 방법”, “키와 권한”이라는 3가지 설계입니다.

SaaS의 MCP 연동이란

SaaS의 MCP 연동이란 자사의 기존 REST API 위에, Claude나 Cursor 같은 AI 클라이언트에서 직접 조작할 수 있는 MCP 서버 계층을 추가하는 것입니다. MCP(Model Context Protocol)는 AI가 외부 시스템을 조작하기 위한 공통 규격이므로, 한 번 대응해 두면 특정 AI 서비스 전용으로 만들어 넣는 일이 되지 않습니다.

MCP라는 규격 자체의 해설과, 저희가 1번째(CMS)를 만들었을 때의 설계 판단의 전말은 MCP 서버를 자사 CMS에 구현한 글에 적었습니다. 이 글은 그 후속편으로, 2번째인 메일 API까지 만들어 재현성을 확인할 수 있었던 “SaaS 쪽의 방법론”에 초점을 맞춥니다.

SaaS MCP 연동, 구현의 정형 5단계

5단계의 내용을 순서대로 설명하겠습니다. 참고로 툴 정의를 쓰는 방법 등 코드 수준의 절차는 MCP 서버 만드는 법에 관한 글로 분리했습니다. 이 글은 판단과 설계에 초점을 맞춥니다.

① 기존 REST API의 정리 — 정본은 어디까지나 API

MCP 서버는 그 자체가 비즈니스 로직을 갖지 않습니다. MCP는 API의 번역 계층이며, 정본은 어디까지나 REST API입니다. 그래서 MCP 연동의 첫 번째 일은 MCP 코드를 쓰는 것이 아니라, 기존 API를 “AI에게 건넬 수 있는 상태”로 정리하는 것입니다. 인증 방식이 통일되어 있는가, 에러가 구조화되어 반환되는가, 조작의 단위가 갖춰져 있는가.

저희 CMS에서는 브라우저의 에디터·REST API·MCP 중 어디에서 써도 같은 검증·이력·감사 로그를 통과하는 구조로 만들었습니다. 입구마다 동작이 다르면 “에디터에서는 막히는데 API에서는 통과한다”는 구멍이 되기 때문입니다. 기존 외부용 API가 없는 SaaS라면 먼저 API부터 만듭니다. 순서는 건너뛸 수 없습니다.

② 툴의 세분성 설계 — 너무 많은 툴은 컨텍스트를 다 먹어치운다

MCP 연동에서 가장 “설계다운” 일입니다. 결론은 단순해서, 툴 수를 줄이고, 툴 하나가 반환하는 정보를 작게 유지한다는 것입니다.

근거는 저 자신의 실측입니다. 외부 SaaS의 범용 MCP(Webflow MCP 1.0)를 실제 프로젝트에서 사용하려 했을 때, 접속하는 것만으로 대량의 정보가 읽혀 들어와 AI의 컨텍스트 대부분을 소비했고, 실용에는 이르지 못했습니다(실측의 경위는 Webflow MCP를 시험한 글에 적어 두었습니다). 툴 정의와 반환 데이터는 AI의 “작업 책상”을 직접 차지합니다. 책상이 자료로 가득 찬 AI는 정작 중요한 일을 하지 못합니다.

이 실패에서 배워, 저희 CMS는 글의 작성·조회·수정·삭제, 카테고리, 이미지 업로드 같은 기본 조작을 8개의 툴에 담았습니다. “API의 엔드포인트 전부에 1대1로 툴을 만든다”는 것은 가장 하기 쉬우면서 실용성을 가장 떨어뜨리는 설계입니다.

③ 위험한 조작의 2단계화 — 프롬프트가 아니라 구조로 막는다

메일 API(HaruMail)에서 철저히 지킨 설계입니다. 발송 계열 툴은 전부 “초안 작성”까지만 할 수 있고, 실제 발송은 confirm_send라는 별도의 툴로만 실행할 수 있습니다. AI가 한 번에 메일을 보낼 수 있는 경로가 애초에 존재하지 않는 구조입니다.

“발송 전에 반드시 확인해 줘”라고 프롬프트로 부탁하는 방식은 채용하지 않았습니다. 지시는 대화가 길어지면 옅어지고, 쓰는 사람에 따라 작성 방식도 달라집니다. 돌이킬 수 없는 조작은 부탁해서 막는 것이 아니라 구조로서 2단계로 나눈다. 발송·공개·삭제·과금 — 자사 SaaS 안에서 “한 번에 실행되면 사고가 되는 조작”을 찾아내고, 확인용 툴을 한 겹 끼워 넣습니다. 설계로서는 작은 한 수지만, AI 연동의 안전성은 완전히 달라집니다.

④ 키와 권한 — 멈추면 전부 멈추는 설계

AI 클라이언트에 건네는 API 키는 설정 파일에 적힌 채 오래 살아남는 만큼, 사람의 로그인보다 허술하게 다뤄지기 쉽습니다. 저희의 설계는 3가지입니다.

• pk(공개 키)와 sk(비밀 키)의 분리. 프런트에 둘 수 있는 것과 서버 쪽에서만 가져야 하는 것을 이름 단계에서 구분한다
• 멤버를 정지시키면 그 사람이 발급한 키도 자동으로 실효. “퇴사자의 계정은 정지했는데 그 사람이 만든 API 키로는 아직 쓸 수 있다”는 구멍을, 운영 규칙이 아니라 구조로 막는다
• 모든 쓰기 조작을 감사 로그에 기록. 언제·어느 키가·무엇을 했는지를 나중에 반드시 추적할 수 있는 상태로 둔다

AI 연동의 사고는 “AI가 폭주했다”보다 “권한이 넓은 키가 살아남아 있었다”는 형태로 일어납니다. 키의 라이프사이클을 사람에 연결해 두는 것이 MCP 연동의 보이지 않는 본체입니다.

⑤ 문서와 llms.txt — 독자는 AI

MCP 연동을 한 SaaS의 문서를 읽는 것은 사람만이 아닙니다. 도입하는 쪽도 자사의 AI 에이전트에게 “사용법을 읽고 붙여 넣어 줘”라고 지시하는 시대입니다. 저희는 사람용 개발자 문서에 더해 AI가 요점을 읽어 낼 수 있는 llms.txt까지 일반 공개했습니다. 실물은 CMS의 공개 문서에서 그대로 볼 수 있습니다.

기계 판독이 가능한 문서가 있으면 도입 기업 쪽의 AI가 사양을 읽고 연동 코드까지 쓸 수 있게 됩니다. 문서의 기계 판독 가능성이 그대로 도입의 쉬움, 즉 도입률이 되는 구조입니다.

MCP 연동을 하면 무슨 일이 일어나는가

마지막으로 시점을 한 단계 올려 보겠습니다. MCP 연동은 단순한 기술 대응이 아니라 채널의 추가입니다.

MCP 연동을 하면 자사 프로덕트가 “AI 에이전트를 통해 사용되는” 상태가 됩니다. 사용자는 관리 화면을 열지 않고, 손에 있는 AI에게 “초안을 만들어서 공개까지 진행해 둬”라고 말하기만 하게 됩니다. 조작의 주체가 사람에서 AI로 옮겨 가면, 프로덕트가 선택되는 기준도 “화면이 쓰기 편한가”에서 “AI에서 쓰기 편한가”로 넓어집니다.

또 하나, AI 클라이언트는 영업 채널도 됩니다. 잠재 고객의 AI가 llms.txt와 문서를 읽고 도입 코드까지 쓸 수 있다면, “트라이얼 등록 → 튜토리얼 → 정착”의 마찰이 통째로 사라집니다. 경쟁사가 아직 관리 화면밖에 갖고 있지 않을 때 API + MCP + 기계 판독 가능한 문서를 갖추는 것은 기능 추가보다 효과적인 차별화라고 판단해, 저희는 자사 SaaS 2개 모두 이 구성으로 만들었습니다.

반대로 “SaaS를 제공하는 쪽”이 아니라 “AI 에이전트를 자사 업무 시스템에 연결하는 쪽”의 설계는 AI 에이전트와 기존 시스템의 연동에 관한 글에 적어 두었습니다.

정리: MCP 계층은 얇게, 설계는 두껍게

SaaS의 MCP 연동의 정형을 다시 적어 둡니다.

• ① 기존 REST API의 정리(정본은 API. 없으면 API부터)
• ② 툴의 세분성 설계(수를 줄이고, 반환하는 정보를 작게)
• ③ 위험한 조작의 2단계화(초안 + 확인 툴이라는 구조로 막는다)
• ④ 키와 권한(pk/sk 분리·정지 시 자동 실효·감사 로그)
• ⑤ 문서와 llms.txt(AI에게 읽힌다는 전제로 공개)

저희는 자사 2개의 구현을 그대로 상품화해, API·MCP 개발로서 인증·레이트 리밋·감사 로그·공개 문서까지 일체로 수주하고 있습니다. 요금은 MCP 스타터(읽기 전용) 250만 엔, API + MCP 풀 패키지 500만 엔, 업무 시스템 전체를 연결하는 풀 통합은 1,000만 엔부터(모두 세금 별도·개별 견적)입니다. 첫걸음으로 권하는 것은 스타터 구성입니다. 기존 REST API에 읽기 전용 MCP 계층을 씌우기만 하므로, 쓰기 사고의 리스크를 구조째로 배제한 상태에서(기준 4~6주) 자사 프로덕트가 “AI에서 사용되는” 모습을 임원과 고객에게 보여 줄 수 있습니다. “우리 SaaS의 경우에는 어떻게 진행하지?”라는 판단 단계에서도 무료 상담으로 문의해 주세요.

자주 묻는 질문

SaaS의 MCP 연동에는 어느 정도의 작업량이 드나요?

기존 REST API의 정리 상태로 거의 결정됩니다. 인증·에러 형식이 갖춰진 API가 이미 있다면 MCP 계층 자체는 얇고, 5단계 중 무거운 것은 툴의 세분성 설계와 키·권한의 설계입니다. 저희 수주에서는 기존 API에 읽기 전용 MCP 계층을 씌우는 MCP 스타터가 250만 엔(세금 별도·기준 4~6주), 인증 인가·감사 로그·공개 문서까지 포함하는 API + MCP 풀 패키지가 500만 엔(세금 별도)입니다.

외부용 API가 아직 없는 SaaS도 MCP 연동이 가능합니까?

가능하지만 순서는 API가 먼저입니다. MCP 서버는 비즈니스 로직을 갖지 않는 번역 계층이므로, 정본이 되는 REST API(인증·에러 구조·감사 로그)를 먼저 설계하고 그 위에 MCP 계층을 더합니다. API 쪽을 정리해 두면 AI 이외의 외부 연동에도 그대로 쓸 수 있으므로 헛되지 않습니다.

AI에게 조작을 맡겨도 오발송이나 임의 삭제를 막을 수 있나요?

막는 방법은 3가지로, ① 위험한 조작의 2단계화 ② 키의 권한 분리 ③ 감사 로그입니다. 저희 메일 API에서는 발송 계열 툴을 전부 초안 작성까지로 한정하고, 실제 발송은 confirm_send라는 별도의 툴로만 실행할 수 있습니다. AI가 한 번에 보낼 수 있는 경로를 구조로서 없애는 것이 원칙이며, 프롬프트의 주의 문구에는 의존하지 않습니다.

MCP 서버의 툴 수는 몇 개가 기준입니까?

저희 CMS는 작성·조회·수정·삭제·카테고리·이미지 업로드의 기본 조작을 8개의 툴에 담았습니다. 기본적인 읽고 쓰기와 확인 계열로 한 자릿수에 담기는 세분성가 제 기준입니다. 툴 정의와 반환 데이터는 AI의 컨텍스트를 직접 소비하므로, 엔드포인트 전부에 1대1로 툴을 만들면 실용성이 떨어집니다.

구현에는 어떤 SDK를 쓰면 됩니까?

MCP의 공식 SDK(TypeScript나 Python 등)가 공개되어 있으므로, 기존 API와 같은 언어·스택에 맞추는 것이 기본입니다. MCP는 공통 규격이므로 어떤 SDK로 구현해도 대응 AI 클라이언트에서는 같은 툴로 보입니다. SDK 선정보다 툴의 세분성와 권한의 설계에 시간을 쓰기를 권합니다.

사내에 AI 개발 인력이 없습니다. MCP 연동을 외주할 수 있나요?

가능합니다. 저희는 자사 SaaS 2개의 구현·프로덕션 운영으로 굳어진 정형을 그대로 사용해, 인증·레이트 리밋·감사 로그·공개 문서(llms.txt 포함)까지의 API + MCP 풀 패키지를 500만 엔(세금 별도)에 수주하고 있습니다. 우선 작게 시작하고 싶은 경우에는 읽기 전용 MCP 계층으로 좁힌 MCP 스타터 250만 엔(세금 별도)부터 단계적으로 도입할 수 있습니다. 기존 API가 있는 경우에는 MCP 계층의 추가부터, 없는 경우에는 API 설계부터 대응합니다.