바이브 코딩으로 "우리만의 툴"을 만들고 싶은 마음은 이해합니다.
"기존 SaaS는 우리 입맛에 맞지 않아."
"주말에 시간 들이면 AI로 금방 만들 수 있잖아."
"토큰 비용도 많이 나가는데 돈 아끼자."
그런데 직접 해보니까 보이는 게 있었어요. 우리가 이미 쓰고 있는 SaaS들이 생각보다 훨씬 복잡하고 정교하게 만들어져 있었습니다.
Salesforce의 SOQL은 관련 데이터를 한 번의 쿼리로 가져오는 구조이고, Fireflies의 API는 회의록을 키워드·날짜·참석자로 필터링해서 돌려주고, Google Drive API는 문서를 프로그래매틱하게 생성할 수 있어요. 수십 년에 걸쳐, 수천 개 조직이 쓰면서 다듬어온 깊이입니다. 이걸 새로 만들 이유가 없었어요.
지금 제 Claude 워크스페이스에는 열두 개 이상의 SaaS가 MCP 커넥터로 연결되어 있습니다. "지난주 A사 미팅 찾아줘" 하면 Fireflies에서 회의록이 나오고, "이 딜 스테이지 확인해줘" 하면 Salesforce에서 데이터가 올라오고, "팔로업 이메일 초안 만들어줘" 하면 Gmail 초안이 잡혀요. 어디에도 로그인하지 않습니다. 이미 잘 만들어진 SaaS들의 API가 열려 있었고, MCP로 연결했을 뿐이에요.
새로 만드는 게 아니라, 이미 존재하는 SaaS를 연결해서 누구보다 빨리 AI 네이티브 워크스페이스를 구축하는 것. 이게 지금 할 일입니다. AI 네이티브는 당신 회사의 워크스페이스 아키텍처의 속성이에요. 그리고 이 연결을 시작하려면, 제품을 보기 전에 먼저 해야 할 일이 있습니다.
SaaS 도입 전에 데이터 구조부터 파악하세요
SaaS 도입을 앞두고 "이 제품 기능이 더 많아" "저 제품 평점이 더 높아"부터 비교하는 회사들이 많아요. 자기 회사 상황은 모른 채 제품 스펙만 비교하고 있는 거죠. B2B 세일즈에서 고객 상황 파악 없이 기능부터 나열하는 걸 feature dumping이라고 부르는데, SaaS 도입도 같은 실수를 합니다.
SaaS 선택의 출발점은 "우리 회사의 데이터가 지금 어디에 있는가?"입니다.
대부분의 회사는 이미 여러 개의 SaaS를 쓰고 있어요. 데이터는 이미 분산되어 있습니다. 문제는 분산 자체가 아니에요. 그 분산 구조를 인식하지 못하는 것이 문제입니다.
세 가지 질문부터 시작하세요.
당신 회사에서 가장 소중한 데이터는 무엇인가요?
그 데이터는 지금 어디에 저장되어 있나요?
그 데이터가 비즈니스 의사결정으로 변환되는 과정에서 몇 개의 툴을 거치나요?
이 세 질문에 답하는 순간, SaaS 선택은 "기능 비교"에서 "역할 배치"로 바뀝니다.
SaaS 데이터 흐름 설계: 원본 저장소, 비즈니스 저장소, AI 워크스페이스
데이터를 종류(영업 데이터, 마케팅 데이터, CS 데이터)로 나누면 끝이 안 납니다. 데이터를 흐름의 단계로 분류하면, 어떤 SaaS가 어떤 역할을 해야 하는지가 보이기 시작해요.
1차 저장소는 Raw Data, 가공되지 않은 원본입니다. 현실 세계에서 발생한 데이터가 최초로 디지털 형태로 저장되는 곳이에요. 비정형이고, 날것이고, 그러나 가장 풍부한 맥락을 담고 있습니다. AI에게 CRM에 적힌 "미팅 완료, 긍정적" 한 줄을 주면 한 줄 수준의 분석이 나옵니다. 같은 AI에게 미팅 녹취 전문을 주면 고객의 우려, 예산 타임라인, 경쟁사 언급까지 뽑아내요. 차이를 만드는 건 AI 모델이 아니라 원본의 존재 여부입니다.
2차 저장소는 Business Context, 구조화된 비즈니스 데이터에요. 1차의 비정형 원본에서 비즈니스 의미를 추출해서 정리한 곳입니다. "이 고객이 뭘 원하는지, 딜이 어디에 있는지, 다음 액션이 뭔지"가 여기에 들어갑니다. 결과물(회의록, 제안서, 리포트)도 여기서 만들어지고 저장됩니다.
그리고 이 모든 저장소를 연결하는 허브가 AI 워크스페이스입니다. 1차든 2차든 MCP 커넥터로 하나의 대화창에 연결돼요. 각 SaaS에 로그인하는 게 아니라, 자연어로 전체 데이터 흐름을 오케스트레이션하는 구조입니다.
이 흐름이 왜 중요한가. 모든 비즈니스 의사결정은 데이터 위에 서 있습니다. 1차 원본이 정확하게 2차로 흘러가야 그 위에서 내리는 판단이 정확해요. 1차 원본이 없으면 2차에서 기억과 추측이 들어가고, 추측 위에 세운 판단은 감 기반 의사결정의 시작입니다. 데이터 흐름도를 그리는 건 SaaS를 잘 고르기 위해서만이 아니에요. 올바른 의사결정을 내리기 위한 데이터 인프라를 설계하는 것입니다.
엔트리에이아이의 실제 데이터 흐름도
1차 저장소부터. 데이터 종류별로 각각 다른 SaaS가 원본을 보관합니다.
Fireflies — 음성 데이터. 모든 고객 대화, 내부 회의, 코칭 세션의 녹음 원본과 트랜스크립트
Gmail · Slack — 텍스트 커뮤니케이션. 음성으로 남지 않는 비동기 대화의 원본
Google Calendar — 타임라인 데이터. 누구와 언제 만났는지의 시간 축. "관계의 빈도와 밀도"가 여기에 남아요.
LinkedIn — 네트워킹 데이터. 외부 관계망, 콘텐츠 배포에 대한 반응
GA · GSC — 인바운드 마케팅 데이터. 블로그에 누가 어떤 경로로 왔고, 어떤 글을 얼마나 읽었는지의 원본
BigQuery — 마케팅 분석 데이터. GA·GSC의 원본 데이터가 더 세밀한 대규모 분석이 필요할 때 여기로 흘러옵니다.
이게 전부 1차 저장소입니다. 가공 전 날것.
2차 저장소는 두 곳이에요. Salesforce가 세일즈 데이터를 구조화합니다. 1차에서 흘러온 비정형 대화 데이터가 Account, Contact, Opportunity, Activity라는 비즈니스 구조로 변환되는 곳입니다. "어제 한 통화가 어떤 딜의 어떤 스테이지에 영향을 미치는가"가 여기서 정의돼요. 세일즈포스에 로그인을 안 합니다 글에서 쓴 것처럼, UI에는 거의 안 들어가지만 데이터 저장소로서의 가치는 막대합니다. Google Drive는 회의록, 제안서, 내부 공유 문서를 저장해요. 음성 데이터를 기반으로 만든 결과물이 여기서 구조화됩니다.
그리고 이 모든 저장소가 연결되는 곳이 Claude, 즉 AI 워크스페이스입니다.
1차 저장소도, 2차 저장소도 MCP 커넥터로 하나의 대화창에 연결돼요. 각 SaaS에 로그인할 필요 없이, 자연어로 전체 데이터 흐름을 오케스트레이션하는 허브입니다.
이 흐름도를 그리는 순간, "이 흐름에서 각 단계의 역할을 가장 잘 수행하는 SaaS는 무엇인가?"가 질문이 됩니다. 제품 기능 비교에서, 데이터 역할 기반 선택으로 전환됩니다.
그리고 1차에서 2차로, 2차에서 Claude 워크스페이스로 데이터가 흘러가야 하는데 — 이 파이프가 연결되느냐? 자기 회사의 데이터 흐름을 그리면, "이 두 저장소 사이를 어떻게 연결하지?"라는 질문이 자연스럽게 나옵니다. 여기서 API와 MCP가 필요해집니다.
SaaS 선택의 두 가지 기준: API 구조와 데이터 모델
데이터 흐름도를 그렸으면, 이제 각 저장소 사이의 연결을 평가해야 합니다. 좋은 소식은 이미 수십 년에 걸쳐 검증된 SaaS들이 존재한다는 겁니다. 우리가 생각하는 것보다 훨씬 잘 만들어져 있어요. 다만 그 깊이를 알려면 두 가지를 봐야 합니다.
기준 1: API가 AI에게 읽히는 구조인가
"API가 있다"와 "API가 AI에게 읽히는 구조다"는 완전히 다른 이야기입니다.
MCP 서버를 직접 만들면서 배운 겁니다. JSON 스펙에 쓰는 tool description이 AI에게 보내지는 프롬프트의 일부라는 사실이에요. description 몇 줄을 고쳤더니 AI가 도구를 선택하는 정확도가 완전히 달라졌습니다. 잘 만든 제품은 "AI가 이 도구를 어떻게 써야 하는지"까지 설계한 거고, 그렇지 않은 제품은 API 엔드포인트를 기계적으로 나열만 한 겁니다. 같은 API를 보고도 MCP 서버 설계에 따라 도구 수와 세분화 수준이 달라지며, 이 차이가 AI 에이전트의 실제 성능을 결정합니다.
API 응답 구조도 마찬가지입니다. 어떤 B2B SaaS의 API를 열어봤는데, 페이지네이션도 필터링도 없이 전체 데이터를 한 번에 쏟아붓는 구조였어요. 사람이 UI로 쓸 때는 문제가 안 보입니다. lazy loading으로 화면에 조금씩 보여주니까요. 그런데 AI가 이 API를 호출하면 응답 데이터가 컨텍스트 윈도우를 한 번에 채워버립니다. 대화 자체가 불가능해지는 거죠. 반면 잘 설계된 SaaS는 쿼리 하나에 필요한 데이터만 깔끔하게 돌아와요.
수십 년간 수천 개 조직이 쓰면서 엣지 케이스를 잡아온 제품들이에요. 이 깊이는 몇 주 만에 만들 수 있는 게 아닙니다. 좋은 제품인지 확인하려면 API를 열어봐야 압니다.
기준 2: 데이터 모델에 설계 의도가 있는가
4개 CRM의 데이터 모델을 비교 분석하면서 발견한 겁니다. Salesforce는 Account(회사)를 중심에 놓는 Tree 구조, Pipedrive는 Deal(거래)을 중심에 놓는 Star 구조, HubSpot은 Contact(사람)을 중심에 놓는 Mesh 구조, Attio는 Process(프로세스)를 중심에 놓는 Layer 구조입니다. 같은 "CRM"인데 데이터를 보는 세계관이 전부 달라요.
각 토폴로지는 창업 철학에서 나왔습니다. "거래는 일시적이지만 회사와의 관계는 영속적이다"는 세계관이 Salesforce의 Account-centric 구조를 만든 거고, "세일즈맨의 오늘 할 일이 가장 중요하다"는 철학이 Pipedrive의 Deal-centric 구조를 만든 겁니다. 이런 깊이는 수년에 걸친 고객 피드백과 설계 결정이 축적된 결과예요.
"어떤 CRM이 당신 조직의 질문에 가장 잘 답하느냐"가 맞는 질문이에요. "이 회사와 우리의 전체 관계 히스토리가 궁금하다"면 Salesforce가 답이고, "지금 내가 추진하는 딜들의 상태가 궁금하다"면 Pipedrive가 답입니다. CRM뿐 아니라 모든 SaaS에 적용되는 원칙이에요. "이 제품이 데이터를 어떤 세계관으로 구조화하는가?" — 이 질문에 명확하게 답할 수 있는 제품을 골라야 AI가 의미 있는 결과를 내놓습니다.
이 두 기준은 독립적인 축입니다. 기준 1은 "파이프의 품질" — 데이터가 잘 흐르느냐. 기준 2는 "저장소의 구조" — 데이터가 의미 있게 저장되느냐. API가 아무리 잘 열려 있어도 데이터 모델이 맞지 않으면 쓸모없고, 데이터 모델이 좋아도 API가 막혀 있으면 AI가 접근을 못 합니다.
SaaS를 MCP로 연결한 AI 워크스페이스 실전 구조
도입부에서 보여드린 팔로업 워크플로우를 이 구조에 대입해볼게요.
Claude에 "A사 미팅 찾아줘"라고 하면 1차 저장소(Fireflies)에서 원본 녹취를 꺼냅니다. "이 딜 스테이지 확인해줘"라고 하면 2차 저장소(Salesforce)에서 Account와 Opportunity 데이터를 조회해요. "회의록 요약 만들고 팔로업 이메일 초안 잡아줘"라고 하면 2차 저장소(Google Drive)에 문서가 저장되고, Gmail로 초안이 잡힙니다. 이 모든 게 Claude 워크스페이스 안에서 일어납니다.
4개의 SaaS 중 어디에도 로그인하지 않았어요. 각각은 독립적인 SaaS인데, API가 잘 열려 있으니까 AI 허브에서 하나의 시스템처럼 작동하는 겁니다. 데이터 흐름도를 먼저 그렸기 때문에, 각 SaaS가 어떤 역할을 하는지가 명확하고, 연결도 깔끔해집니다.
인블로그 MCP 서버를 직접 만들어서 UI에 안 들어가고 발행까지 끝내는 워크플로우도 같은 원리입니다. API 스펙 하나로 MCP 서버를 만들었고, 그 순간부터 인블로그 UI에 들어갈 이유가 사라졌어요. 이 모든 SaaS는 이미 존재했습니다. 연결만 했을 뿐이에요.
바이브 코딩으로 직접 만들면 생기는 문제: 데이터 연결의 단절
바이브 코딩으로 만든 툴은 단독으로는 작동합니다. 그런데 위에서 그린 데이터 흐름도에 연결하려면 API를 또 만들어야 해요. 그리고 그 API가 AI에게 읽히는 품질이 되려면, 수십 년간 수천 개 조직이 다듬어온 SaaS와 같은 수준의 설계가 필요합니다. 2년 넘게 개발된 B2B SaaS도 API를 열어보면 페이지네이션조차 없는 경우가 있었어요. 바이브 코딩으로 며칠 만에 만든 블로그도 콘텐츠 50개를 넘기면 테크니컬 SEO 구조적 부채가 터집니다.
단일 기능은 바이브 코딩이 나을 수 있어요. 이미지 변환이나 간단한 자동화 같은 유틸리티 영역은 가능합니다. 이 글에서 말하는 건 메인 데이터 저장소가 되는 툴들 — CRM, 커뮤니케이션, 프로젝트 관리, 분석처럼 데이터 흐름도의 1차·2차 저장소에 해당하는 것들이에요.
이 역할을 하는 SaaS는 이미 존재합니다. 그리고 우리가 생각하는 것보다 훨씬 깊게 만들어져 있어요. 에코시스템 서비스 비용(보안, 규정, 연동, 커뮤니티)은 직접 개발 시 고스란히 자기 몫이 됩니다. 새로 만드는 데 쓸 시간을, 이미 만들어진 것들을 연결하는 데 쓰는 게 훨씬 빠른 길입니다.
SaaS 연결로 AI 네이티브 업무 환경을 시작하는 세 가지 방법
데이터 흐름도를 그리세요. 화이트보드나 메모장에 당신 회사의 데이터가 어디서 생기고(1차), 어디서 구조화되고(2차), 그걸 어떤 AI 워크스페이스에서 연결할지 그려보세요. "우리 비즈니스에서 가장 소중한 원본 데이터는 무엇인가?"부터 시작하면 됩니다. 이건 오늘 당장 할 수 있습니다.
이미 쓰고 있는 SaaS를 두 가지 기준으로 재평가하세요. API가 AI에게 읽히는 구조인가? 데이터 모델에 설계 의도가 있는가? 흐름도를 그린 뒤에 이 질문을 대입하면, 어떤 SaaS를 유지하고 어떤 SaaS를 교체해야 하는지가 보입니다. 이미 잘 만들어진 SaaS가 생각보다 많다는 걸 발견할 거예요.
AI 허브에 연결하세요. Claude든, 당신이 쓰는 AI 워크스페이스든 — 각 SaaS를 MCP나 커넥터로 연결해보세요. 열 개의 SaaS에 각각 들어가서 UI를 만지는 방식에서, 하나의 허브에서 데이터 흐름 전체를 오케스트레이션하는 방식으로 바뀌는 순간, "AI 네이티브"가 실제 작동하는 업무 방식이 됩니다.
조직의 데이터 흐름에 대한 구조와 상황을 모르는 상태에서 "이 제품이 좋대, 저 제품이 좋대" 하는 건 결국 큰 의미가 없습니다.
데이터 흐름도가 명확해지면 의사결정의 근거가 정확해지고, 근거가 정확하면 판단이 빨라집니다. 지금 이 순간에도 잘 만들어진 SaaS들이 API를 열고 기다리고 있어요. 새로 만들 필요가 없습니다.
잘 연결하면 됩니다.
다음 SaaS 도입 회의에서, 제품 데모를 보기 전에 이 질문을 먼저 꺼내보세요.
"이 제품의 데이터는 우리의 데이터 흐름도에서 어디에 위치하고, 어떻게 연결되는가?"