데이터 분석

[MCP9탄] MCP서버를 출시해 6개월 운영한 3개 SaaS 회사의 배움과 후회 (OneSignal, Customer.io, HG Insights)

마켓핏랩 솔루션즈

2026.07.08 08:00

158

한눈에 보는 핵심요약
MCP 서버를 6~9개월 운영한 SaaS 3사의 솔직한 회고를 담았습니다. 도입 효과부터 한계, 다시 시작한다면 바꾸고 싶은 점까지 소개합니다.

MCP 서버를 만들어 6개월 운영한 회사들의 후기

— 샌프란시스코 SaaS 기업 3사(Customer.io·OneSignal·HG Insights)의 운영 후기 6가지(Mixpanel MXP 2026 패널 토크)

📚 마켓핏랩 Mixpanel MCP 시리즈 안내

이 글은 마켓핏랩이 진행 중인 Mixpanel MCP 시리즈의 10편입니다.
1~9편까지는 Mixpanel MCP를 한국 PM·DA·그로스 마케터의 실무에 어떻게 붙일 수 있는지를 다뤘다면,
10편은 잠시 시야를 넓혀서 "MCP를 실제로 만든 사람들은 지금 무슨 생각을 하고 있는가"를 들여다보는 글이예요.
전체 시리즈가 궁금하시다면 링크 (목록보기가 있을까요?)를 참조해주세요.

MCP서버를 만들어 6개월 운영한 사람들의 배움은 뭘까?

새 툴이 나오면 두 종류의 글이 가장 빨리 쏟아집니다.
"이게 뭐고 왜 중요한가"를 정리한 입문 글, "한번 붙여봤더니 이런 게 가능하더라"는 첫인상 후기 같은 글…
지금 검색해서 나오는 글의 대부분이 이 둘 중 하나입니다.

MCP도 마찬가지예요.

그런데 어떤 도구든 처음 쓸 때 보이는 것과, 한참 굴려보고 나서 느끼는 것은 다릅니다.
진짜 효용도, 진짜 한계도 결국 시간을 두고 부딪혀본 사람한테만 명확히 보이기 때문이죠.
그래서 6개월 이상 오래 쓴 사람들의 후기가 잘 안 나오지 않습니다.
6개월 넘게 운영해본 회사가 아직 많지 않고, 있다 해도 외부엔 시행착오보다 정제된 마케팅 메시지만 내보내거든요.

그래서 2026년 5월 12일, 샌프란시스코에서 열린 Mixpanel MXP 컨퍼런스의 MCP 패널 토크를 소개해드리려고 합니다.

이 세션에서는 제품에 MCP 서버를 연결해 6개월 이상 출시-운영해본 3개 회사
OneSignal, Customer.io, HG Insights의 VP들이 무대에 올라서,
6개월 운영보며 알게된 잘못 세운 가설, 예상과 달랐던 점, 다시 시작한다면 무엇을 바꿀지를 소개했어요

이 글에서 만나실 솔직한 한 마디들을 먼저 소개합니다

“MCP를 사용하고 나니까 곧바로 뒤처졌다는 느낌이 들었어요.

그 느낌은 사라지지 않는데, 이제는 그 감각 자체를 좋아하게 됐습니다.”

— Paul Senechko · Customer.io

“LinkedIn이나 X에서 보이는 거 믿지 마세요. MCP 별로네, 써봤네 하는 사람이 잔뜩 있지만 실제로 뭘 해본 사람은 거의 없어요.

만약 당신이 MCP로 진짜 문제를 하나라도 해결해봤다면, 당신은 그 떠드는 사람들 대다수보다 훨씬 앞서 있는 거예요.”

— Francis Brero · HG Insights

원문 출처: Mixpanel 공식 블로그 — "Feeling behind on MCP? Here's what three insiders shared at MXP San Francisco." (2026.05.13, Brandon Weaver) / 행사 페이지: MXP San Francisco 2026

MXP 샌프란시스코 MCP 패널 토크에 참여한 기업

어떤 사람들이 이야기를 나눴을까

이번 행사에는 어떤 사람들이, 어떤 회사를 대표해서 이야기를 나눴는지 먼저 간단히 소개해볼게요.
국내에서는 아직 익숙하지 않은 회사들도 있어서, 발표 내용을 보기 전에 맥락부터 함께 보면 훨씬 이해가 쉬워집니다.

Paul Senechko

Customer.io · VP of Engineering

Customer.io는 미국 포틀랜드에 있는 메시징 플랫폼이에요. 이메일·푸시·SMS·인앱 알림을 한곳에서 자동화하는 도구로, 8,000개가 넘는 회사가 고객사로 쓰고 있습니다.

2025년 9월에는 연 매출 약 $100M, 한화 약 1,400억 원 규모를 넘어섰는데, 외부 투자는 약 $40M, 한화 약 560억 원 정도만 받고 성장한 자력 성장형 회사로 잘 알려져 있어요.

개발자가 데이터를 자유롭게 다루며 캠페인을 설계할 수 있게 만든 점이 Customer.io의 가장 큰 강점 중 하나입니다.

Ellen Wong

OneSignal · VP of Engineering

OneSignal은 실리콘밸리(샌마테오)에 본사를 둔 메시징 플랫폼이에요. 푸시 알림 하나로 시작해서 이메일·SMS·인앱까지 확장했고, 지금은 하루 100억 건의 메시지를 보내는 규모입니다.

170만 곳이 가입해서 쓰고 있으며, SignalFire, Y Combinator, HubSpot Ventures 같은 유명 투자사로부터 약 $84M, 한화 약 1,200억 원 규모의 투자를 받았습니다.

무료 플랜이 잘 갖춰져 있어서 작은 스타트업도 부담 없이 시작할 수 있다는 점이 OneSignal의 가장 큰 강점 중 하나예요.

‍

Francis Brero

HG Insights · VP of AI & Strategy

HG Insights는 미국 산타바버라에 있는 B2B 영업·마케팅 데이터 회사예요.

“어떤 기업이 어떤 IT 도구를 쓰고 있고, 얼마를 쓰며, 다음에 무엇을 살 가능성이 높은가” 같은 정보를 데이터로 제공하는 서비스인데, 마이크로소프트·구글·세일즈포스 같은 글로벌 IT 대기업 100곳 중 90곳이 고객사입니다.

연 매출은 약 $118M, 한화 약 1,600억 원 규모예요.

한국에서 정확히 대응되는 회사를 떠올리긴 어렵지만, “B2B 영업팀이 의지하는 외부 기업 데이터 회사” 정도로 이해하시면 됩니다.

Q1. MCP, 어떻게 출시하게 됐나요?

세 회사 다 MCP 출시를 마스터플랜에서 출발한 사람이 없었으며 각자 다른 사정으로 떠밀려서 시작했고,
빌드하는 속도보다 배우는 속도가 더 빨랐다고 합니다.

Paul Senechko

Customer.io

MCP 서버를 출시하게 된 이유는 크게 두 가지였어요.

하나는 사내 마케팅팀이 AI 활용에 점점 익숙해지면서, “이제는 Claude 안에서 바로 우리 서비스를 쓰고 싶다” 는 요청을 계속하기 시작한 거였고요.

다른 하나는, 업계 전체의 흐름 자체가 이미 그 방향으로 움직이고 있다는 감각 때문이었습니다.

그래서 2025년 4월, read-only 버전으로 먼저 MCP를 출시했어요.

출시하자마자 “고객이 가고 싶어 하는 곳”과 “우리가 지금 있는 곳” 사이의 간격을 체감했다고 이야기했습니다.

“MCP를 내고 나니까 곧바로 뒤처졌다는 느낌이 들었어요.

그 느낌은 지금도 사라지지 않지만, 이제는 그 감각 자체를 좋아하게 됐습니다.”

Ellen Wong

OneSignal

사실 처음부터 MCP를 만들 계획이 있었던 건 아니었어요. 당시 GTM(Go-to-Market) 전략 방향과도 아주 잘 맞는다고 보진 않았거든요.

그런데 어느 날, 한 고객이 직접 MCP를 만들어서 가져왔어요.

“우리는 OneSignal을 정말 잘 쓰고 있고, 이걸 MCP 형태로도 쓰고 싶었습니다. 그래서 일단 직접 만들어봤으니, 이제 여러분이 가져가서 더 잘 다듬어주세요.”

그 한마디가 계기가 됐고, 결국 MCP가 로드맵에 들어가 실제 출시까지 이어지게 됐습니다.

Francis Brero

HG Insights

저희는 사실 명확한 use case를 정해두고 MCP를 출시한 건 아니었어요.

오히려 고객들이 MCP를 통해 서비스를 어떻게 활용하는지 직접 관찰해보고 싶다는 의도가 더 컸죠.

그렇게 6~9개월 정도 운영하면서 가장 크게 느낀 점 중 하나는, 생각보다 “만지작거리는 사람(tinkerer)”이 정말 많다는 거였어요.

MCP 자체에 관심을 갖고, 생태계 변화에 흥분하고, 직접 이것저것 연결해보려는 사람들은 굉장히 많았습니다.

그런데 그 관심이 곧바로 HG Insights의 유료 고객 전환으로 이어지지는 않더라는 거죠.

“MCP는 그 자체가 목적지가 아닙니다.

Agent로 가기 위한 디딤돌에 더 가깝습니다.”

Q2. MCP에서 진짜 차별점은 어디서 나오나요?

세 회사 모두 비슷한 결론에 도달했습니다.이제 기술 자체는 점점 평준화되고 있고,
진짜 차별점은 MCP 위에 어떤 전문성을 얹느냐에 달려 있다는 거였죠.

Francis Brero

HG Insights

이 자리에서 가장 강조하고 싶었던 이야기는 바로 이 부분이었어요.

단순히 API를 MCP로 감싸는 것 자체는 사실 그렇게 어려운 일이 아닙니다. 엔지니어라면 누구나 구현할 수 있는 수준이고, 그 자체로는 차별화 포인트가 되기 어렵죠.

그렇다면 MCP의 진짜 가치는 어디에 있을까요?

핵심은 prompts, resources, context를 통해 도메인 전문성을 툴 안에 녹여내는 것에 있었습니다.

LLM에게 단순히 “무엇을 해야 하는가”만 전달하는 게 아니라, “왜 그렇게 해야 하는지”, “어떤 맥락에서 판단해야 하는지”까지 함께 가르치는 영역이라는 거죠.

그래서 단순히 기술적인 도구만 제공하는 건 고객 입장에서 큰 의미가 없다고 이야기했습니다.

오히려 MCP 프로토콜이 흥미로운 이유는, prompts와 resources를 활용해 각 회사가 가진 전문성과 워크플로를 하나의 사용 경험 안에 압축할 수 있기 때문이라고요.

결국 고객이 원하는 건 단순 기능이 아니라, 그 기능 뒤에 축적된 도메인 전문성이라는 이야기였습니다.

SaaS Positioning

이 이야기를 비즈니스 포지셔닝 관점까지 확장하면 더 흥미로워져요. 요즘 SaaS를 검토하는 기업들의 예산 회의에서는 거의 빠지지 않고 이런 질문이 나온다고 합니다.

“이거… 우리 엔지니어 한 명이 주말에 AI로 비슷하게 만들 수 있는 거 아닌가요?”

— CFO의 단골 질문

그리고 이제 SaaS 회사들은 이 질문에 예전처럼 답하기 어려워졌다는 거예요.
“저희 제품에는 이런 기능이 있고, 저런 capability가 있습니다” 같은 방식으로는 더 이상 설득이 되지 않는다는 거죠.

그래서 앞으로의 경쟁력은 기능(feature) 자체가 아니라,그 제품 안에 얼마나 깊은 도메인 전문성이 녹아 있는가로 이동하게 된다고 이야기했습니다.

Paul Senechko (Customer.io)

저희도 비슷해요. 이런 이슈를 실제 비즈니스 의사 결정으로 풀었어요.
외부 벤더와 6자리 계약을 앞두고 있었는데, 어느 순간 "이거 우리가 AI 활용해서 며칠이면 만들겠는데?" 싶은거죠.
그 순간 좀 무섭더라구요. 우리가 그렇게 할 수 있다면, 우리 고객도 우리한테 똑같이 할 수 있는 거 아닌가?

MCP 기술 자체에 대한 프리미엄은 사라졌지만, 인사이트에 대한 프리미엄은 여전히 유효해요.

우리만의 데이터 시그널, 복잡한 툴간 인터그레이션 경험, 캠페인이 어떻게 작동하는지를 수 년에 걸쳐 이해해온 누적 경험… 이런 건 한번의 주말 작업으로 복제되지 않아요. 그래서 Customer.io는 지금 저희가 오랜 시간 쌓아온 분야별 노하우를 제품 안에 녹여 넣는데 초점을 맞추고 있습니다.

Q3. MCP를 쓰게 되면 UI는 죽게 될까요?

자리의 모든 PM이 숨죽인 질문이었어요.
사용자가 Claude나 ChatGPT를 통해서만 우리 제품에 접근하고 우리 인터페이스에 한 번도 로그인하지 않는다면,
어떻게 사용자를 유지할까요? 우리는 도대체 우리는 무엇을 만들고 있는 걸까 싶거든요.

‍

Ellen Wong (OneSignal)

‍가장 현실적인 답을 드리면, 저희가 실제로 OneSignal 고객 행동을 들여다봤을 때, 대다수의 고객은 "모든 걸 직접 커스텀하고 만들 수 있는 최대한의 유연성"을 원하지 않았어요. 그들이 원한 건 그냥 잘 작동하는 거예요. 정리하면 세 가지예요.

- 매끄러운 워크플로우
- 신뢰할 수 있는 전송 결과
- 다시 제품을 사용할 이유

다시 UI가 죽게 될까?에 답한다면고객이 OneSignal에 오직 MCP를 통해서만 접근하더라… 저희는 그런 경험을 한 적이 없어요.

Francis Brero (HG Insights)

저는 질문 자체를 좀 뒤집고 싶어요. "UI냐 UI가 아니냐"는 기술 중심 질문이고, 잘못된 출발점입니다. 형식은 use case가 결정해야 해요.

비유를 하나 들어볼게요. 초기 Tesla는 모든 물리적인 손잡이(노브)를 터치스크린으로 바꿨어요. 기술적으로는 인상적이었죠. 그런데 온도 조절 노브가 늘 같은 자리에 있으면 운전자는 그걸 쳐다보지 않고도 돌릴 수 있는데, 터치스크린은 시선을 둬야 작동하게 만들 수 있습니다.

"기술적으로 대단해 보이는 게 반드시 좋은 사용자 경험은 아닙니다."어떤 형태의 인터페이스를 만들지는 사용자가 진짜로 해결하려는 일에 맞춰야지, 지금 한창 떠도는 유행을 따라가서는 안 됩니다

튀는 사례나 흐름의 변화를 한눈에 잡아내야 하는 일이라면, 올드하다고 여겨지는 차트나 그래프 같은 시각 화면이 텍스트로는 보이지 않는 걸 잘 보여주죠.

Q4. MCP의 성과를 어떻게 측정하나요?

또 하나 흥미로웠던 질문은 이거였어요.

“만약 고객이 MCP만 쓰고 우리 UI에는 한 번도 들어오지 않는다면, 제품이 잘 쓰이고 있는 건 어떻게 판단할까?
ROI는 어떻게 증명할까?”

패널의 답은 꽤 솔직했습니다.“어렵고, 아직은 명확한 답이 없다고 인정하는 게 맞다”는 거였죠.

그리고 세 회사 모두 공통적으로 이야기한 건, MCP 호출 수 같은 표면 지표는 큰 의미가 없다는 점이었어요.

중요한 건 얼마나 많이 호출됐는지가 아니라, 사용자가 어떤 의도(prompts·resources)로 활용했고, 그 결과 실제 딜·고객 만족·업무 속도 같은 outcome이 어떻게 달라졌는가라는 이야기였습니다.

Francis Brero

HG Insights

가장 눈에 띄는 지표는 결국 tool call 호출 횟수입니다. 하지만 그 숫자 자체만으로는 거의 의미가 없다고 이야기했어요.

예를 들어 “구독 상태 조회” 같은 도구의 호출 수만 봐서는, 사용자가 실제로 무엇을 하려 했는지 알 수 없다는 거죠.

대신 어떤 prompts와 resources가 함께 호출되고 있는지를 보면, 사용자의 의도와 워크플로우를 훨씬 더 깊게 이해할 수 있다고 설명했습니다.

“호출 횟수가 중요한 게 아닙니다. 왜 그 도구가 호출됐는지, 어떤 프롬프트가 그 호출을 만들었는지가 더 중요해요. 거기서 사람들이 실제로 무엇을 하려는지에 대한 훨씬 많은 인사이트가 나옵니다.”

Ellen Wong

OneSignal

Ellen은 조금 더 정성적인 관점을 강조했어요.

“관심을 보이는 것”과 “실제로 사용하고 있는 것”은 완전히 다르다는 거죠.

그래서 결국 고객과 가까이 붙어서, MCP가 실제 워크플로우를 단순하게 만들고 있는지, 그리고 실제 성과로 이어지고 있는지를 관찰해야 한다고 이야기했습니다.

중요한 건 사람들이 한 번 연결해봤는지가 아니라, 정말로 업무 방식이 달라지고 있는가라는 거였어요.

Paul Senechko

Customer.io

Paul은 조금 의외의 지표를 이야기했어요. 바로 “딜(deal)”입니다.

Customer.io에서는 실제로 MCP와 AI 기능이 신규 계약이나 갱신 계약에 점점 더 큰 영향을 미치고 있다고 해요.

아직 ROI를 완벽하게 정량화하긴 어렵지만, 고객들이 구매 결정을 내릴 때 AI 기능을 중요한 판단 기준으로 보기 시작했다는 거죠.

“우리에게 정말 의미 있는 지표는, 결국 우리 feature set 때문에 더 많은 딜이 클로징되고 있다는 사실입니다.”

Q5. MCP에 대해 솔직하게 평가한다면?

세 사람 모두 MCP 자체의 가능성은 높게 평가했지만, 지금의 MCP는 아직 굉장히 거칠다고 이야기했어요. 그리고 결국 흐름은 agent 방향으로 갈 거라고 보고 있었고요.

Paul Senechko

Customer.io

“저는 여전히 MCP를 좋아하고, 잠재력도 크다고 생각해요. 하지만 솔직히 지금의 사용자 경험은 정말 거칠어요.”

느리고, 다루기 까다롭고, tool call 사이의 state 관리도 어렵다는 거죠.

Customer.io는 API → CLI → 제품 내 agent → MCP 서버까지 차곡차곡 기반을 쌓고 있었지만, 그 모든 걸 갖춰도 아직 기대했던 미래가 완전히 오진 않았다고 이야기했어요.

“유용할 것 같은 가능성이 잠깐 보였다가 사라져요. 답답함이 있습니다.

제 spicy take는, MCP는 체크박스 기능이 아니라 제품이라는 거예요. 그렇게 다뤄야 합니다.”

Francis Brero

HG Insights

Francis는 이 담론 자체에 약간 제동을 걸고 싶다고 이야기했어요.

그는 지금 시장에 “AI 연극”이 굉장히 많다고 표현했습니다. 겉으로는 엄청 인상적인 데모와 셋업처럼 보이지만, 막상 “그래서 실제로 누가 뭘 하고 있나요?”라고 물어보면 답이 없는 경우가 많다는 거죠.

게다가 보안 문제도 아직 충분히 진지하게 다뤄지지 않고 있다고 이야기했습니다.

그리고 무엇보다, 고객이 원하는 건 MCP 자체가 아니라는 점도 강조했어요. MCP는 결국 그 목적지로 가기 위한 하나의 방법일 뿐이라는 거죠.

“LinkedIn이나 X에서 보이는 걸 너무 믿지 마세요. MCP로 단 하나의 문제라도 해결했다면, 이미 대부분의 사람들보다 한참 앞서 있는 겁니다.”

“1년 안에 이 대화의 중심은 MCP에서 AI Agent로 옮겨갈 거라고 봅니다.

SaaS가 충분히 좋아졌을 때 사람들이 API를 의식하지 않게 된 것처럼, MCP 같은 프로토콜도 결국 사용자가 인식하지 않는 배경 기술이 될 거예요.”

Ellen Wong

OneSignal

Ellen은 개인적인 경험도 하나 공유했어요.

처음 MCP 여러 개를 연결했을 땐, 굉장히 자유로워진 느낌이었다고 합니다. 심지어 기존에 돈 내고 쓰던 SaaS 제품들도 안 쓰게 됐다고 해요.

그런데 시간이 지나면서 환경이 점점 복잡해지고, 관리도 어려워졌어요. 결국 다시 기존 SaaS 제품들로 돌아가게 됐다고 합니다.

오히려 그 제품들이 자체적으로 만든 agent 경험이 더 안정적이고 매끄럽게 느껴졌다는 거죠.

“MCP는 도착지가 아니라 진입점으로 생각하세요.”

Q6. 다시 시작한다면 뭘 바꾸시겠어요?

Paul Senechko

Customer.io

— Tool Chaining(연쇄적 도구 호출)에 너무 기대지 마세요.

도구를 줄줄이 연결해서 정보를 이어가는 방식은 생각보다 훨씬 고통스럽습니다. 관리도 어렵고 디버깅도 어려워요.

저희도 초기에 그 방향으로 갔다가, 결국 read / write / search / execute 같은 단순한 동작 단위가 제품에 더 잘 맞는다는 걸 확인하고 방향을 틀었습니다.

처음부터 다시 만든다면, 연쇄 호출 방식은 아예 선택하지 않을 것 같아요.

Ellen Wong

OneSignal

— 대시보드 사용자보다 API를 직접 쓰는 고객과 더 많이 대화하세요.

만약 처음부터 다시 시작한다면, 일반 대시보드 사용자가 아니라 API를 직접 활용하는 개발자 고객층을 더 깊게 볼 것 같아요.

OneSignal은 그동안 제품 화면 안에서 행동하는 고객을 이해하는 데 집중해왔는데, 정작 API 위에 자기 제품과 워크플로우를 만들어 올리는 고객들은 충분히 보지 못했거든요.

그런데 MCP를 가장 적극적으로 활용하고 실제로 무언가를 만들어낼 가능성이 높은 사람들은 바로 그 고객층이었습니다.

그들이야말로 “우리에게 진짜 필요한 게 무엇인지” 알려줄 사람들이에요.

Francis Brero

HG Insights

— Tools보다 prompts와 resources에 투자하세요.

툴을 만드는 것 자체는 이제 비교적 쉬운 일이 됐습니다.

더 어렵고 더 가치 있는 건, 회사가 가진 도메인 전문성을 도구 안에 녹여 넣는 일이에요.

결국 핵심은 “우리 고객이 실제로 답하고 싶어 하는 질문이 무엇인가” 를 LLM에게 가르치는 거죠.

그리고 AI 에이전트 기반 워크플로우에 투자할 거라면, MCP가 정말 최종 목적지인지도 한 번쯤 고민해볼 필요가 있습니다.

“MCP는 가능성을 탐색할 때는 정말 훌륭합니다.

하지만 워크플로우가 고정되고 운영 단계로 들어가면, 결국 CLI나 API 호출이 더 안정적일 수도 있어요.”

마치며 — MCP 전환을 가장 잘 다루는 팀은, 고객과 가까이 있는 팀

진행자가 토크를 닫으면서 한 말이 다시 곱씹을 만합니다. 이 글을 옮기기로 한 가장 큰 이유이기도 하구요.

"MCP에서 뒤처진 느낌이 든다면, 걱정 마세요. 지금 MCP로 빌드 중인 모든 사람이 똑같이 그렇게 느낍니다." — Marissa Kuhrau

이 전환을 가장 잘 다루고 있는 팀들은, 가장 확신에 차 있는 팀이 아니었습니다.

오히려 노이즈 속에서도 고객과 가까이 붙어 있고, 도메인 전문성은 쉽게 복제되지 않는다는 걸 이해하고,
무엇보다 “우리가 아직 모르는 게 많다”는 사실을 솔직하게 인정하는 팀들이었어요.

한국에서도 종종 “우리만 늦고 있는 것 같다”는 감각이 들 때가 있습니다.
그런데 흥미로웠던 건, 샌프란시스코 무대에서 직접 MCP를 출시한 VP들조차 똑같이 “뒤처진 느낌”을 이야기했다는 점이었어요. 다만 그 누구도 완성된 답이나 마스터플랜을 갖고 있지는 않았습니다. 모두가 직접 부딪히고, 반응을 보면서, 빠르게 배우고 있는 중이었죠.

그래서 지금 시점에서 마켓핏랩이 드리고 싶은 제안도 단순합니다.완성된 전략을 기다리기보다, 작게 시작하고 빠르게 배우세요.

결국 진짜 차별점은 도구 자체가 아니라,그 도구 안에 얼마나 깊은 도메인 전문성을 녹여낼 수 있는가에서 나오니까요.