SaaS MCP 연동, 구현의 정형 5가지: 자사 제품 2개를 프로덕션에서 돌려 굳힌 결과

주식회사 Webharu 대표이사 구리타입니다. 자사에서 헤드리스 CMS “HaruCMS”와 메일 API “HaruMail”을 만들어 운영하고 있습니다.

먼저 결론입니다. SaaS의 MCP 연동은 API를 다시 만들지 않습니다. 기존 REST API 위에 얇은 MCP 계층을 한 장 더하기만 하면 됩니다.

시간을 들여야 하는 것은 코드가 아니라 설계 3가지입니다. 툴의 세분성, 위험한 조작을 멈추는 방법, 키와 권한입니다. 저는 자사 제품 2개 모두 이 형태로 MCP 연동시켜 매일 AI에서 사용하고 있습니다. 그 과정에서 굳어진 정형을 그대로 적습니다.

이 글을 읽었으면 하는 대상은 이미 SaaS나 업무 시스템, 회원 기반을 운영하고 있는 기업의 CTO·프로덕트 책임자입니다. “고객사로부터 MCP 연동을 요구받고 있다”, “임원 회의에서 AI 에이전트 대응이 과제로 지적되었다”. 이런 상담이 늘고 있습니다.

이 글의 요점

SaaS의 MCP 연동란?

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

목차

SaaS의 MCP 연동이란: 기존 API에 AI의 손을 더하는 것

SaaS의 MCP 연동이란 자사의 REST API 위에, Claude나 Cursor 같은 AI 클라이언트가 직접 조작할 수 있는 MCP 서버 계층을 더하는 것입니다.

MCP(Model Context Protocol)는 AI가 외부 시스템을 조작하기 위한 공통 규격입니다. API가 “시스템의 입구”라면, MCP는 “AI가 그 입구를 쓰기 위한 손”입니다. 거기에 AI가 읽을 수 있는 설명서(문서)까지 갖춰져야, AI는 비로소 보기만 하는 상담 상대에서 한 걸음 나아갑니다.

API만으로는 부족했던 이유

“API가 있으면 AI도 쓸 수 있는 것 아닌가”라고 생각하실 겁니다. 저도 처음에는 그렇게 생각했습니다.

실제로는 API만 있는 상태로 AI에게 쓰게 하면, 엔드포인트 설명·인증 전달 방법·응답 읽는 법을 매번 프롬프트로 가르쳐야 합니다. 대화가 바뀌면 잊어버리고, 사람마다 설명 방식이 달라 결과도 흔들립니다. MCP로 만들어 두면 툴 목록과 인자의 형태를 AI 쪽이 구조로 받아들이기 때문에 이런 편차가 사라집니다.

또 하나는 규격이 공통이라는 점입니다. 특정 AI 서비스 전용으로 만들어 넣으면 다른 AI로 바꿀 때마다 다시 만들어야 합니다. MCP라면 쓰는 AI를 바꿔도 접속 입구는 그대로 쓸 수 있습니다. 오래 쓰는 업무 시스템일수록 이 차이가 크게 작용합니다.

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

결론부터 말하면 순서는 아래 5가지입니다. 모두 자사 제품 2개에서 실제로 통과한 절차입니다.

① 기존 REST API를 정리한다: 정본은 API

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

HaruCMS에서는 브라우저 에디터·REST API·MCP 중 어디에서 써도 같은 검증·이력·감사 로그를 통과하도록 만들었습니다. 입구마다 동작이 다르면 “에디터에서는 막히는데 API에서는 통과한다”는 구멍이 생기기 때문입니다.

입구의 형태도 하나로 좁혔습니다. 글 본문은 Markdown만 받고, HTML로의 변환은 서버 쪽에서 합니다. 외부에서 HTML을 그대로 흘려 넣을 수 있으면 깨진 마크업이나 예상치 못한 태그가 운영 환경에 섞입니다. AI가 생성한 것을 흘려 넣는다면 더욱 그렇습니다. 외부용 API가 아직 없는 SaaS라면 API부터 만듭니다. 이 순서는 건너뛸 수 없습니다.

② 툴의 세분성을 정한다: 툴이 너무 많으면 AI의 책상이 가득 찬다

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

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

그래서 HaruCMS는 글의 작성·조회·수정·삭제, 카테고리, 이미지 업로드 같은 기본 조작을 8개의 툴에 담았습니다. API의 엔드포인트 전부에 1대1로 툴을 만드는 것이 가장 하기 쉬우면서, 가장 쓸 수 없게 만드는 설계입니다.

③ 위험한 조작을 2단계로 만든다: 프롬프트가 아니라 구조로 막는다

첫 번째 제품인 HaruCMS에서는 기본값으로 멈췄습니다. 상태를 지정하지 않은 작성은 반드시 초안이 됩니다. AI가 대화 흐름 중에 임의로 공개하는 일은 없습니다.

두 번째 제품인 HaruMail에서는 한 단계 더 나갔습니다. 발송 계열 툴은 전부 초안을 만드는 데까지만 하고, 실제 발송은 confirm_send라는 별도의 툴로만 실행됩니다. AI가 한 번에 메일을 보낼 수 있는 경로가 애초에 존재하지 않는 구조입니다.

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

④ 키와 권한: 하나를 멈추면 전부 멈추는 설계

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

• pk(공개 키)와 sk(비밀 키)를 분리한다. 프런트에 둘 수 있는 것과 서버 쪽에서만 가져야 하는 것을 이름 단계에서 구분한다
• 키가 통하는 범위를 사이트 1개 분으로 좁힌다. 다른 사이트의 데이터나 관리 기능에는 닿지 않는다
• 멤버를 정지시키면 그 사람이 발급한 키도 자동으로 멈춘다. 삭제가 아니라 정지이므로, 잘못 멈추더라도 되돌릴 수 있다
• 쓰기 조작은 전부 감사 로그에 남긴다. 언제·어느 키가·무엇을 했는지 나중에 추적할 수 있다

세 번째가 눈에 띄지 않지만 중요합니다. 키가 계정과 별도로 살아 있으면 “로그인은 멈췄는데 외부 API로는 아직 쓸 수 있다”는 상태가 만들어집니다. AI 연동의 사고는 “AI가 폭주했다”보다 “권한이 넓은 키가 살아남아 있었다”는 형태로 일어납니다. 키의 수명을 사람에게 묶어 두는 것이 MCP 연동의 보이지 않는 본체입니다.

⑤ 문서와 llms.txt: 읽는 쪽은 AI

MCP 연동을 마친 SaaS의 문서를 읽는 것은 사람만이 아닙니다. 도입하는 쪽도 자사의 AI 에이전트에게 “사양을 읽고 연동해 줘”라고 부탁하는 시대입니다.

HaruCMS에서는 사람이 읽는 레퍼런스에 더해, AI에게 요점을 건네는 llms.txt와 사양 전문을 한 파일로 모은 llms-full.txt까지 일반에 공개했습니다. 실물은 HaruCMS의 공개 문서에서 그대로 볼 수 있습니다. 전문을 건네고 “이걸로 글을 올리는 기능을 만들어 줘”라고 하면, 도입하는 쪽의 AI가 연동 코드까지 씁니다. 문서가 기계로 읽히는지가 그대로 도입의 쉬움이 된다는 이야기입니다.

SaaS를 MCP 연동시키면, AI가 고객의 입구가 된다

MCP 연동은 기술 대응이라기보다 채널이 하나 늘어나는 이야기입니다.

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

잠재 고객의 AI가 llms.txt와 문서를 읽고 연동 코드까지 쓸 수 있다면, 트라이얼 등록부터 튜토리얼, 정착까지의 마찰이 통째로 사라집니다. 경쟁사가 아직 관리 화면밖에 갖추지 못했을 때 API·MCP·기계로 읽히는 문서를 갖추는 것은 기능을 하나 더하는 것보다 효과적인 차별화라고 생각해, 그래서 자사 제품 2개 모두 이 구성으로 만들었습니다.

SaaS를 제공하는 쪽이 아니라, AI 에이전트를 자사 업무 시스템에 연결하는 쪽의 이야기는 AI 에이전트와 기존 시스템 연동에 관한 글에 있습니다.

SaaS의 MCP 연동을 외주할 경우의 요금

Webharu에서는 자사 제품 2개에서 통과한 정형을 그대로 사용해 API·MCP 개발을 수주하고 있습니다(2026년 10월 기준·세금 별도).

• MCP 스타터(읽기 전용) 250만 엔: 기존 REST API에 읽기 전용 MCP 계층을 씌운다. 쓰기가 없으므로 사고의 경로가 구조째로 없다. 기준 4~6주
• API + MCP 풀 패키지 500만 엔: REST API 설계부터 인증·레이트 리밋·감사 로그·위험한 조작의 2단계화·MCP 서버·개발자 문서와 llms.txt까지 일체
• 풀 통합 1,000만 엔부터: 쓰기까지 열기·복수의 AI 클라이언트·업무 시스템별 통합. 개별 견적

첫걸음이라면 스타터를 추천합니다. 자사 프로덕트가 AI에서 사용되는 모습을, 쓰기 사고의 리스크 없이 임원과 고객에게 보여 줄 수 있기 때문입니다. 외주 시세와 견적에서 확인해야 할 5가지 항목은 MCP 서버 개발 비용 시세에 관한 글에 정리했습니다.

다음으로 읽을 것

• MCP 서버 개발 비용 시세와, 외주 전에 물어볼 5가지
• 메일 발송 시스템을 직접 만든 이유(confirm_send의 2단계 발송을 넣은 HaruMail)
• Webflow MCP를 시험해 보고, 컨텍스트가 가득 찬 이야기

자사 SaaS 개발의 후속 이야기와 글에는 싣지 않은 숫자는 뉴스레터에 쓰고 있습니다. MCP나 API를 만들고 있는 개발자라면 뉴스레터 구독을 부탁드립니다. “우리 SaaS라면 어떻게 진행할까” 하는 단계라면 무료 상담부터 문의해 주세요.

제작 실적

주식회사 PonTech Lab

AI(Claude Code)로 Next.js×Cloudflare 구축. 제작 과정 기록도 공개

닛폰테레비 주최

Figma 디자인을 Webflow로 고정밀 변환. 표시 속도와 반응형을 최적화

JTB Americas

북미 거점 사이트를 전면 리뉴얼. 운영팀이 직접 업데이트하는 체계까지 구축

자주 묻는 질문

SaaS의 MCP 연동에는 어느 정도의 기간과 비용이 드나요?

기존 REST API에 읽기 전용 MCP 계층을 씌우는 구성이라면 기준 4~6주입니다. Webharu의 요금은 MCP 스타터 250만 엔, 인증·감사 로그·공개 문서까지 포함하는 API + MCP 풀 패키지 500만 엔, 업무 시스템별 풀 통합은 1,000만 엔부터입니다(모두 세금 별도·2026년 10월 기준).

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

Webharu의 CMS는 작성·조회·수정·삭제·카테고리·이미지 업로드의 기본 조작을 8개의 툴에 담았습니다. 한 자릿수가 기준입니다. 툴 정의와 반환 데이터는 AI의 컨텍스트를 직접 소비하므로, 엔드포인트 전부에 1대1로 툴을 만들면 쓸 수 없게 됩니다.

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

가능합니다. 순서는 API가 먼저입니다. MCP 서버는 업무 로직을 갖지 않는 번역 계층이므로, 인증·구조화된 에러·감사 로그를 갖춘 REST API를 먼저 만들고 그 위에 MCP 계층을 더합니다. 만든 API는 AI 이외의 외부 연동에도 그대로 쓸 수 있습니다.

AI가 잘못 발송하거나 임의로 공개하는 것을 막는 방법이 있나요?

있습니다. Webharu의 설계는 2단계입니다. CMS는 상태를 지정하지 않은 작성이 반드시 초안이 됩니다. 메일 API는 발송 계열 툴을 초안 작성까지로 한정하고, 실제 발송은 confirm_send라는 별도의 툴로만 실행됩니다. 프롬프트의 주의 문구에는 의존하지 않습니다.

MCP와 API는 무엇이 다른가요?

API는 시스템의 입구이고, MCP는 AI가 그 입구를 쓰기 위한 손입니다. API만으로도 프로그램에서는 조작할 수 있지만, AI에게 쓰게 하려면 설명을 매번 프롬프트로 건네야 합니다. MCP로 만들면 툴 목록과 인자의 형태를 AI가 구조로 이해하므로 설명 없이도 안정적으로 작동합니다.

llms.txt는 무엇을 위해 두는 건가요?

도입하는 쪽의 AI 에이전트에게 사양을 읽히기 위해서입니다. Webharu의 CMS는 요점을 담은 llms.txt와 사양 전문의 llms-full.txt 2가지를 공개하고 있습니다. 전문을 AI에게 건네면 연동 코드까지 AI가 쓸 수 있어, 사람이 문서를 읽어들이는 과정이 필요 없어집니다.