약속 잡기 SaaS Calendly의 MCP 커넥터를 연결해봤습니다. 읽기 전용 도구 24개, 쓰기/삭제 도구 11개. 총 35개. System of Record도 아닌 도구가 이렇게까지 열어놓을 이유가 뭘까요? SaaSpocalypse 시대의 생존은 에이전트한테 선택받느냐에 달려 있습니다.
클로드 설정 화면에서 커넥터 탭을 열었습니다.
어떤 도구들이 연결 가능한지 하나씩 살펴보다가, Calendly를 연결해봤어요. 약속 잡기 도구니까 기능이 뭐 몇 개 있겠거니 싶었는데 — 스크롤이 끝나질 않더라고요.
읽기 전용 도구 24개. 쓰기/삭제 도구 11개. 총 35개.
get_user_availability_schedule, list_event_type_available_times, create_single_use_scheduling_link, cancel_event, create_organization_invitation...
약속 잡기 도구에 조직 멤버 초대/삭제 도구까지 있습니다. 라우팅 폼 제출 내역 조회 도구도 있고요.
다른 커넥터를 연결해보면 이 차이가 두드러져요. 제가 쓰고 있는 커넥터들의 도구 수를 세봤습니다. Salesforce 15개, Fireflies 14개, Slack 13개, Figma 12개, Google Calendar 9개, Gmail 7개. 대부분 7~15개 범위예요. Calendly의 35개는 이 중 가장 많습니다. 읽기뿐 아니라 쓰기와 삭제까지, 할 수 있는 거의 모든 동작을 잘게 쪼개서 에이전트한테 열어놓았어요.
그리고 이 세분화가 만들어내는 효과가 있어요. 클로드의 커넥터는 도구마다 개별적으로 권한을 설정할 수 있는데 — 이건 어떤 MCP 커넥터든 동일합니다 — Calendly가 도구를 35개로 잘게 쪼갰기 때문에 이 권한 시스템이 훨씬 정밀하게 작동해요. 가용 시간 조회는 자동 허용하되, 미팅 취소나 조직 멤버 삭제는 매번 승인받게 하는 식이죠. 만약 "Calendly 전체" 하나로 뭉뚱그려 열어놨다면, 이런 세밀한 통제는 불가능했을 거예요.
이 회사, 자기가 위험하다는 걸 정확히 알고 있구나.
저의 개인적인 해석이지만 제 머릿속에 떠오른 첫 생각이었습니다.
약속 잡기 SaaS는 SaaSpocalypse에서 가장 취약한 카테고리입니다
저는 SaaS의 생존력을 판단할 때, 그 도구가 System of Record인지 System of Engagement인지를 먼저 봅니다.
System of Record는 "이 데이터는 여기가 원본이다"라고 조직 전체가 합의한 시스템이에요. Salesforce의 고객 파이프라인, SAP의 재무 데이터처럼요. 한 번 자리 잡으면 빼기가 거의 불가능하죠.
System of Engagement는 다릅니다. 업무 흐름을 편하게 해주는 도구예요. 안에 원천 데이터가 쌓이지 않아요. 대체재가 나오면 교체가 비교적 쉽습니다.
Calendly는 전형적인 System of Engagement입니다.
약속 잡기라는 워크플로우를 편하게 해줄 뿐, 고객 데이터나 거래 이력 같은 원천 데이터가 쌓이는 구조가 아니에요. AI 에이전트가 "너 대신 일정 잡아줄게"라고 하는 순간, Calendly의 UI 가치는 증발할 수 있는 포지션입니다.
이전에 "System of Record라는 방패가 당신을 구원하지 않는 이유"에서 System of Record조차 안전하지 않다고 썼습니다. 그런데 System of Record도 아닌 도구는요? SaaSpocalypse 관점에서 보면 가장 먼저 사라질 수 있는 가능성이 높은 카테고리예요.
그래서 Calendly의 움직임은 더욱 분석해 볼 의미가 있다고 생각했습니다.
생존을 위해서 빠르게 움직이고 있거든요.
Calendly의 생존 공식: 개방성 × 접근성 × 통제 가능성
35개 도구를 뜯어보면, Calendly의 전략이 세 축으로 나뉘는 게 보입니다.
첫 번째 축: 개방성 — "우리 고객이 아니어도 써라"
Calendly는 예전부터 "상대방은 Calendly 계정이 없어도 된다"는 구조였어요. 이건 SaaS의 전통적인 시트 기반 과금과 정반대 방향입니다. 벽을 치지 않아요. AI 에이전트 시대에 벽을 치면 에이전트가 다른 도구를 쓸 뿐이니까요.
두 번째 축: 접근성 — "에이전트가 편하게 쓸 수 있게"
35개 MCP 도구는 사람이 UI에서 클릭하던 거의 모든 동작을 에이전트가 API로 할 수 있게 만든 겁니다. 가용 시간 조회, 이벤트 타입 생성과 수정, 일회용 스케줄링 링크 생성, 라우팅 폼 관리까지. MCP 서버를 직접 만들어본 경험이 있어서 아는 건데, 이 수준으로 도구를 잘게 쪼개서 여는 건 만만한 일이 아닙니다. "Calendly 접근" 하나로 뭉뚱그릴 수도 있었는데, 의도적으로 세분화한 거예요.
세 번째 축: 통제 가능성 — "세분화가 곧 통제다"
도구별 권한 설정 자체는 클로드 플랫폼이 제공하는 기능이에요. 어떤 MCP 커넥터든 도구마다 허용/승인/차단을 걸 수 있죠. 그런데 Calendly가 읽기 24개와 쓰기/삭제 11개로 명확하게 분리해놨기 때문에, 이 플랫폼 기능이 제대로 작동합니다. "내 가용 시간 조회는 열되, 미팅 취소는 매번 확인받겠다"는 세밀한 통제가 가능한 건, Calendly가 도구를 그만큼 잘게 쪼갰기 때문이에요. 보안 관점에서 최소 권한 원칙(Least Privilege)이 실현되는 구조입니다.
이 세 개가 동시에 작동해야 하는 이유가 있어요. 개방만 하면 보안 불안, 접근성만 높이면 무분별한 사용, 통제만 강화하면 에이전트가 제대로 못 움직여요. 셋이 균형을 이뤄야 "에이전트 시대의 인프라"로 포지셔닝이 성립합니다.
UI 제품에서 에이전트 인프라로의 전환
Calendly는 "일정 잡기 UI 제품"에서 "스케줄링 인프라 레이어"로 포지셔닝을 전환하고 있습니다.
아키텍처를 그려보면 구조가 선명해져요.
[사용자] ← 여기서 Calendly의 UI 가치가 있었다
↓
[Calendly UI] → 일정 잡기 → 완료이 구조에서는 AI 에이전트가 직접 일정을 잡아주면 Calendly가 필요 없어져요. UI가 곧 제품이니까요.
그런데 Calendly가 지금 만들고 있는 구조는 이겁니다.
[AI 에이전트] → Calendly MCP (35개 도구) → 스케줄링 실행
↓
[사용자는 결과만 확인]에이전트가 Calendly를 통해 일정을 잡으면 — UI는 안 쓰더라도 — Calendly는 여전히 그 트랜잭션의 중심에 있어요. 사람이 안 들어가도 가치가 유지되는 구조. 이건 제가 "세일즈포스에 로그인을 안 합니다"에서 말한 것과 정확히 같은 방향입니다. UI가 아닌 백엔드 구조가 진짜 가치인 시대.
"살아남기 힘들다"는 판단과 "그래서 죽는다"는 별개입니다
저는 여전히 System of Engagement 도구가 System of Record보다 대체 위험이 높다고 봅니다. 그 관점은 바뀌지 않았어요. Calendly 안에 원천 데이터가 쌓이는 구조가 아닌 건 사실이니까요.
그런데 위협을 인지하고 빠르게 전환하는 회사는 오히려 더 강해질 수 있습니다.
"System of Record가 구원하지 않는 이유" 글에서 Jason Lemkin의 말을 인용했어요.
"오늘 80% 수준의 AI 에이전트는, 18개월 후 99% 완벽한 에이전트보다 10배 더 가치가 있다."
Calendly가 지금 하고 있는 게 정확히 이겁니다. 완벽한 MCP 서버를 만들기보다, 35개 도구를 빠르게 열어놓았어요. 이 속도 자체가 메시지예요.
그러면 System of Record 플레이어들은 어떻게 하고 있을까요? Salesforce도 움직이고 있긴 합니다. 공식 DX MCP 서버에 60개 넘는 도구가 있고, Hosted MCP Server도 파일럿으로 나왔어요. 도구 수만 보면 Calendly보다 많죠.
그런데 성격이 다릅니다. Salesforce DX MCP는 개발자 워크플로우 — 코드 배포, 스크래치 오그 생성, 테스트 실행 — 중심이에요. Calendly가 연 건 개발자 도구가 아니에요. 약속 잡기, 가용 시간 조회, 미팅 취소 — 비즈니스 사용자의 일상 동작 자체를 에이전트한테 열어놓은 겁니다. 비즈니스 사용자가 매일 쓰는 기능을 에이전트한테 여는 것과, 개발자 도구를 에이전트한테 여는 건 다른 레벨의 개방이에요.
그리고 속도의 차이가 있어요. Salesforce는 직원 약 76,000명, 시가총액 약 1,800억 달러의 기업이고, MCP 도입에도 파일럿, 베타, GA 같은 단계를 밟고 있어요. 반면 Calendly는 직원 약 550명, 밸류에이션 30억 달러, 매출 약 2.8억 달러 규모의 회사인데 — 35개 도구를 바로 프로덕션에 열어놓았습니다. 작은 회사가 아니에요. 그런데 Salesforce 대비 조직 규모가 작고 의사결정이 빠르기 때문에 가능한 속도예요.
안전하다고 느끼는 곳에서 안일함이, 위험하다고 느끼는 곳에서 속도가 나옵니다.
이 움직임이 한국 B2B 시장에 던지는 질문
Calendly 하나의 사례를 넘어서, 근본적인 구조에 대한 질문입니다.
"AI 에이전트한테 선택받지 못하는 SaaS는 어떻게 되는가?"
지금 B2B 세일즈 현장에서 에이전트가 업무를 자동화할 때, 에이전트는 API가 열려 있고, 도구가 잘 설계되어 있고, 권한이 세분화된 SaaS를 선택합니다. 그 조건을 충족하지 못하는 도구는 에이전트의 워크플로우에서 빠져요.
한국 B2B SaaS 중에 이 수준의 MCP 도구 설계를 갖춘 제품이 몇 개나 될까요?
저는 매일 Salesforce, Slack, Fireflies, Gmail, Google Drive, Calendly를 MCP로 연결해서 에이전트가 소비하는 구조로 일하고 있어요. 이 구조에서 확실히 느끼는 게 있습니다. 에이전트한테 주는 데이터의 양과 구조가 아웃풋의 퀄리티를 결정한다는 것. 그리고 그 데이터를 주려면 도구가 열려 있어야 한다는 것.
Calendly의 35개 도구는 "열어놓으면 에이전트가 알아서 쓴다"는 걸 보여주는 실험입니다. 그리고 그 실험이 작동하면, 열지 않은 도구들은 에이전트의 선택지에서 사라져요.
SaaSpocalypse 시대의 생존 공식
SaaS의 생존을 가르는 건 에이전트 시대의 인프라로 전환할 의지와 속도입니다.
Calendly는 그걸 증명하고 있어요. 가장 취약한 포지션에서, 가장 빠르게, 가장 세분화된 형태로 에이전트한테 자신을 열어놓았습니다.
지금 SaaS를 만들고 있거나, SaaS를 도입하려는 분들에게 남기는 질문 세 가지예요.
1. 당신의 제품은 AI 에이전트가 소비할 수 있는 구조인가요? UI만 있고 API가 불완전하다면, 에이전트는 당신을 건너뜁니다.
2. 도구 권한을 사용자가 세분화해서 통제할 수 있나요? "전체 접근" 하나로 뭉뚱그려놓으면, 보안 우려로 에이전트 연결 자체가 거부됩니다. 기업 AI 도입을 막는 건 보안이 아니라 학습된 무감각이라고 했지만, 보안 설계가 안 되어 있으면 도입 자체가 막히는 건 사실이에요.
3. 지금 움직이고 있나요, 아니면 "우리는 괜찮다"고 생각하고 있나요? 오늘 80%의 속도가, 18개월 후 99%의 완벽함보다 10배 가치가 있습니다. Calendly는 이미 움직였어요.
SaaSpocalypse에서 살아남는 방법에 대한 정답에 관해서는 모두 의견이 다를 수 있습니다. 저의 현재 의견은 더욱 더 개방하고 문을 여는 겁니다. 다만, 누구에게 얼마만큼 열지를 사용자가 결정할 수 있게 하면서요.