MCP 서버를 출시했다면, 사용자들은 그것을 어떻게 사용하고 있는지 어떻게 알 수 있을까?

MCP (Model Context Protocol)는 사람들이 소프트웨어와 상호작용하는 방식을 변화시키고 있습니다.

사용자들이 애플리케이션을 열고 메뉴를 탐색하며 버튼을 클릭하는 대신, 이제 ChatGPT, Claude, Cursor와 같은 AI 어시스턴트를 통해 제품과 직접 상호작용할 수 있게 되었습니다.

개발자에게는 이것이 흥미로운 일입니다. 개발자는 MCP 서버를 통해 제품의 기능을 노출하고 사용자들이 이미 작업하고 있는 모든 곳에서 접근 가능하게 만들 수 있습니다.

하지만 MCP를 출시한 후, 새로운 질문들이 생겨납니다.

실제로 누가 사용하고 있을까요? 그들은 무엇을 달성하려고 노력하고 있나요? 어떤 사용 사례가 인기를 얻고 있나요? 어떤 기능을 요청하고 있나요? 그리고 어디에서 막히고 있나요?

이러한 질문들은 전통적인 제품 분석(product analytics)이 웹사이트와 애플리케이션에 대해 답하는 데 도움을 주었던 것들입니다.

하지만 사용자 인터페이스가 다른 사람의 것이라면 어떻게 될까요?

MCP는 새로운 제품 배포 채널이 되고 있다

CRM을 구축하고 있다고 상상해 보세요.

역사적으로, 사용자는 연락처를 검색하거나, 거래를 관리하거나, 보고서를 작성하기 위해 자체 애플리케이션에 로그인했습니다.

개발자는 페이지뷰(pageviews), 기능 사용량(feature usage), 퍼널(funnels), 사용자 여정(user journeys)을 통해 도입률을 측정할 수 있었습니다.

이제 MCP 서버를 출시했다고 상상해 보세요.

고객들은 애플리케이션을 열지 않고도 ChatGPT에게 유망한 리드를 찾거나, 기회를 업데이트하거나, 파이프라인을 요약하도록 요청할 수 있습니다.

이는 제품을 배포하는 강력하고 새로운 방식입니다.

하지만 함정이 있습니다.

더 이상 전체 사용자 경험(user experience)을 통제하지 못합니다.

대화는 ChatGPT나 Claude 내부에서 발생합니다. MCP 서버는 툴 호출(tool calls)을 받고 결과를 반환하지만, 그 상호작용 주변의 모든 것을 반드시 볼 수 있는 것은 아닙니다.

지난주에 search_contacts가 5,000번 호출되었다는 것은 알 수 있습니다.

하지만 그것이 사람들이 리드 발굴(prospecting)을 하고 있었는지, 회의를 준비하고 있었는지, CRM을 정리하고 있었는지, 아니면 제품이 지원하지 않는 무언가를 달성하려고 노력하고 있었는지는 알려주지 않습니다.

툴 사용량은 제품 사용량을 이해하는 것과는 다릅니다.

실제로 무엇을 측정해야 할까?

Flowlines(https://flowlines.ai)를 구축하기 시작했을 때, 우리는 모든 MCP 서버를 운영하는 팀이 답변할 수 있어야 한다고 믿는 다섯 가지 질문으로 계속 돌아갔습니다.

1. 누가 당신의 MCP를 사용하고 있나요?

첫 번째 질문은 간단하게 들립니다.

사용자가 몇 명이나 되나요? 신규 사용자인가요, 아니면 재방문 사용자인가요? 어떤 조직들이 당신의 MCP를 도입하고 있나요? 사람들이 ChatGPT, Claude, Cursor 또는 다른 클라이언트를 통해 접속하고 있나요?

이러한 지표들은 채택(adoption)을 이해하기 위한 출발점을 제공합니다.

하지만 누군가 당신의 MCP에 연결하는 것과 누군가가 그것을 유용하다고 느끼는 것 사이에는 중요한 차이가 있습니다.

1,000개의 설치가 반드시 1,000명의 활성 사용자를 의미하지는 않습니다.

마찬가지로, 수많은 도구 호출(tool call)을 생성하는 소수의 사용자라고 해서 광범위한 채택을 나타내는 것은 아닙니다.

사용자, 계정, 세션 수준에서 사용 현황을 파악하는 것이 당신의 MCP가 어떻게 성장하고 있는지에 대해 더 의미 있는 그림을 제공합니다.

2. 사람들은 실제로 무엇을 달성하려고 하나요?

여기서부터 흥미로워집니다.

당신의 MCP가 다음과 같은 도구들을 노출한다고 가정해 봅시다:

search_contacts, get_company, create_note, 그리고 update_deal.

도구 호출 지표를 보면 어떤 도구가 인기 있는지 알 수 있습니다.

하지만 여러 개의 다른 워크플로우가 동일한 도구를 사용할 수 있습니다.

한 사용자는 영업 미팅을 준비하고 있을 수 있습니다. 또 다른 사용자는 잠재 고객을 검증하고 있을 수 있습니다. 세 번째 사용자는 CRM을 풍부하게 만들려고 시도할 수도 있습니다.

도구는 같지만, 근본적인 의도는 완전히 다릅니다.

만약 세션 전반에 걸쳐 이러한 의도를 식별하고 그룹화할 수 있다면, 훨씬 더 가치 있는 질문들에 답하기 시작합니다:

가장 일반적인 사용 사례는 무엇인가요? 어떤 워크플로우가 성장하고 있나요? 사람들이 당신이 예상하지 못했던 방식으로 MCP를 사용하고 있나요?

개별 도구들을 고립적으로 최적화하는 대신, AI 비서(AI assistants)를 통해 사람들이 실제로 제품을 어떻게 사용하는지 이해할 수 있습니다.

3. 사용자들은 무엇을 요청하고 있는데 당신은 아직 구축하지 않았나요?

제품 피드백의 가장 가치 있는 출처 중 하나는 고객들이 달성하려고 하지만 할 수 없는 것입니다.

전통적인 애플리케이션의 경우, 이러한 정보는 지원 티켓(support tickets), 고객 인터뷰(customer interviews), 기능 요청(feature requests) 또는 사용자 리서치(user research)에서 얻을 수 있습니다.

MCP를 사용하는 경우, 사용자는 단순히 AI 비서에게 귀하의 제품이 지원하지 않는 작업을 수행해 달라고 요청할 수도 있습니다.

어쩌면 귀하가 노출하지 않는 데이터를 필요로 하는 보고서를 생성하고 싶을 수도 있습니다.

혹은 현재 도구로는 어렵게 만드는 여러 작업을 워크플로우(workflow)로 결합하려고 할 수도 있습니다.

아니면 존재하지 않는 기능을 반복적으로 찾고 있을 수도 있습니다.

이러한 요청들은 충족되지 않은 수요(unmet demand)를 드러낼 수 있습니다.

그리고 유사한 요청들이 여러 사용자 및 세션에 걸쳐 나타날 때, 이는 다음에 무엇을 구축할지 결정하는 데 특히 유용한 신호가 됩니다.

명시적인 피드백(explicit feedback)에만 의존하기보다, 사람들이 MCP와 어떻게 상호작용하는 것에서 배울 수 있습니다.

4. 사용자는 어디서 막히는가?

물론 기술적 관측 가능성(technical observability)은 여전히 중요합니다.

오류(errors), 지연 시간(latency), 가용성(availability) 및 개별 도구 호출(individual tool calls)을 모니터링해야 합니다.

하지만 모든 성공하지 못한 경험이 오류를 발생시키는 것은 아닙니다.

사용자는 결과가 유용하지 않아서 요청을 반복적으로 수정할 수 있습니다.

에이전트(agent)는 의도한 결과를 얻지 못하고 여러 도구를 호출할 수도 있습니다.

누군가는 여러 세션에 걸쳐 동일한 워크플로우로 어려움을 겪을 수도 있습니다.

각 도구 호출은 기술적으로 성공적일 수 있지만, 전반적인 경험은 여전히 좌절감을 줄 수 있습니다.

이러한 패턴을 이해하는 것은 인프라 메트릭(infrastructure metrics)만으로는 명확하지 않은 마찰 지점(friction)을 식별하는 데 도움이 됩니다.

목표는 전통적인 모니터링을 대체하는 것이 아닙니다.

MCP 위에서 발생하는 워크플로우에 대한 더 나은 이해로 이를 보완하는 것입니다.

5. 팀이 행동해야 할 시점은 언제인가?

분석(Analytics)은 행동으로 이어질 때 특히 가치가 높아집니다.

ChatGPT를 통해 제품을 탐색하며 엔터프라이즈 기능에 대해 문의하는 잠재 고객을 상상해 보세요.

혹은 중요한 고객이 특정 워크플로우에서 반복적으로 어려움을 겪는 경우를 생각해 보세요.

혹은 수십 명의 사용자가 현재 제품이 지원하지 않는 기능을 요청하는 경우도 있습니다.

이것들은 단순히 흥미로운 지표가 아닙니다.

이는 영업(sales), 제품(product), 고객 성공(customer success) 팀에 잠재적으로 유용한 신호입니다.

매일 아침 누군가 대시보드를 검사할 필요 없이, 이러한 이벤트는 중요한 일이 발생했을 때 알림을 트리거할 수 있습니다.

여러분의 MCP는 더 이상 단순한 통합이 아닙니다.

고객 및 제품 인텔리전스(intelligence)의 또 다른 원천이 됩니다.

MCP 관측 가능성에서 실행 가능한 통찰력으로

이것이 Flowlines에서 우리가 작업하고 있는 문제입니다.

우리는 개발자들이 MCP 서버를 출시한 후 무슨 일이 일어나고 있는지 이해하는 데 도움을 주기 위해 MCP 분석 및 관측 가능성을 구축했습니다.

Flowlines는 OpenTelemetry 기반의 계측(instrumentation)을 사용하여 MCP 상호 작용을 수집하고 세션을 재구성합니다.

여기서부터 사용자 및 세션 전반의 활동을 분석하여 다음과 같은 반복되는 패턴을 도출합니다:

• 사용자 의도 및 사용 사례: 사람들이 어떤 도구를 호출했는지뿐만 아니라, 무엇을 달성하려고 하는지 이해합니다.
• 채택률 및 사용자 여정(user journeys): 사용자들이 다양한 AI 클라이언트에서 여러분의 MCP와 어떻게 상호 작용하는지 확인합니다.
• 오류 및 마찰 지점: 주의가 필요한 반복적인 문제와 워크플로우를 식별합니다.
• 충족되지 않은 수요: 사용자가 찾고 있는 기능과 제품 개선 사항을 발견합니다.
• 비즈니스 신호: 관련 고객 활동을 도출하고 중요한 일이 발생했을 때 알림을 트리거합니다.

중요한 부분은 개별 상호 작용을 더 큰 그림에 연결하는 것입니다.

단일 트레이스(trace)는 한 세션에서 무슨 일이 일어났는지 이해하는 데 도움을 줄 수 있습니다.

세션 전반의 패턴을 분석하면 제품 전체에서 무슨 일이 일어나고 있는지 이해하는 데 도움이 됩니다.

시작하기 위해 MCP를 재구축할 필요는 없습니다

관측 가능성은 또 다른 인프라 프로젝트가 되어서는 안 됩니다.

우리는 기존 MCP 서버를 계측하는 데 도움을 주기 위해 코딩 에이전트(coding agents)와 작동하는 온보딩 도구를 구축했습니다.

계정을 만들고, 온보딩 절차를 따르기만 하면 코딩 에이전트가 대부분의 계측 작업을 처리할 수 있습니다.

내부적으로 Flowlines는 OpenTelemetry를 사용하므로, 개발자들은 확립된 관측 가능성 표준(observability standard)을 기반으로 구축할 수 있습니다.

MCP가 트래픽을 받기 시작하면, 세션을 탐색하고, 사용 패턴을 이해하며, 경험 개선 기회를 식별할 수 있습니다.

여기서 시도해 보세요: Flowlines로 시작하기.

MCP를 배포하는 것은 시작에 불과합니다

MCP는 소프트웨어 제품이 AI 어시스턴트 내부의 사용자에게 직접 도달하도록 더 쉽게 만듭니다.

하지만 유통(distribution)은 첫 번째 단계일 뿐입니다.

사람들이 여러분의 MCP를 사용하기 시작하면, 그들이 이를 채택하고 있는지, 어떤 워크플로우가 중요하며, 어디서 어려움을 겪는지, 그리고 다음에 무엇을 원하는지 이해해야 합니다.

웹사이트와 애플리케이션에 제품 분석(product analytics)이 필수적이었던 것과 동일한 원칙들이 MCP 서버에도 점점 더 중요해지고 있습니다.

차이점은 사용자 경험의 많은 부분이 이제 여러분 자신의 인터페이스 외부에서 발생한다는 것입니다.

여러분의 MCP는 수천 건의 도구 호출(tool calls)을 받고 있을 수 있습니다. 진짜 질문은 그 호출들이 여러분의 사용자와 제품에 대해 무엇을 알려주고 있느냐 하는 것입니다.

이것이 바로 저희 Flowlines에서 구축하고 있는 것입니다.

만약 MCP 서버를 운영하고 계시다면, 어떻게 채택률(adoption)을 측정하고 사용자들이 실제로 그것으로 무엇을 하는지 이해하는지 듣고 싶습니다.