---
title: "Cursor와 Minds MCP로 마케팅 리서치 에이전트 구축하기"
description: "PostHog에서 데이터를 가져오고, Minds 패널을 실행하며, Slack에 게시하는 맞춤형 마케팅 리서치 에이전트를 Cursor에서 구축하는 실무 가이드입니다."
canonical_url: "https://getminds.ai/blog/ko/build-marketing-research-agent-cursor-minds-mcp"
last_updated: "2026-06-02T02:51:22.461Z"
---

# Cursor에서 마케팅 리서치 에이전트 구축하기

이 가이드는 기성 제품을 사용하기보다 맞춤형 마케팅 리서치 에이전트를 직접 구축하려는 분들을 위한 것입니다. 최종 결과물은 Cursor 내에서 작동하는 에이전트로, 평이한 언어로 작성된 리서치 브리프를 받아 PostHog에서 제품 분석 데이터를 가져오고, Minds로 가상 패널을 실행하며, 두 데이터를 교차 분석한 후 Slack에 요약본을 게시합니다. 세 가지 서비스에 계정이 이미 있다면 전체 작업 시간은 약 90분입니다.

핵심은 완성도 높은 제품을 출시하는 것이 아닙니다. 에이전트 기반의 순환 구조를 구체화하는 데 있습니다. 즉, 에이전트가 브리프를 받고, 여러 MCP 서버를 순차적으로 호출하며, 통합된 결과에 대해 추론하고, 다시 보고하는 과정입니다. 이 구조를 한 번 구축하고 나면, 이 패턴을 응용하여 원하는 다른 어떤 것이든 만들 수 있습니다.

## 사전 준비

세 개의 계정과 세 개의 API 키가 필요합니다:

- API 키가 있는 Minds 계정(`minds_…`). 계정이 없다면 getminds.ai에서 가입하세요.
- 개인 API 키가 있는 PostHog 계정.
- 웹훅이나 앱 토큰을 통해 채널에 게시할 수 있는 Slack 워크스페이스.

Cursor 설치 (또는 MCP를 지원하는 모든 편집기. VS Code와 Copilot도 동일하게 작동합니다).

약 30분의 집중적인 설정 시간과 이후 60분간의 에이전트 브리프 및 프롬프트 수정 작업이 필요합니다.

## 1단계: 세 개의 MCP 서버 연결하기

세 서비스 각각은 MCP 서버를 제공합니다. 이 세 가지를 모두 Cursor에 연결할 것입니다.

Cursor에서 설정 → MCP를 열고 세 개의 서버를 추가합니다.

*Minds.* OAuth를 통해 URL `https://getminds.ai/mcp`로 [시장 조사를 위한 Minds MCP 서버](/mcp/overview)를 추가하고 인증합니다. 12개의 Minds 도구(`create_panel`, `ask_panel`, `export_panel` 등)가 도구 선택기에 나타납니다. 클라이언트별 설정 단계는 [Minds MCP 설정 가이드](/mcp/setup)를 참조하세요.

*PostHog.* PostHog는 자체 MCP 서버를 제공합니다. 권장 설정은 `https://app.posthog.com/mcp`의 원격 엔드포인트이며, 역시 OAuth를 사용합니다. 이벤트, 퍼널, 코호트, 대시보드를 다루는 55개의 도구를 사용할 수 있습니다.

*Slack.* Slack MCP 서버는 npm을 통해 사용할 수 있습니다. `npx -y @modelcontextprotocol/server-slack`와 환경 변수에 Slack 봇 토큰을 사용하여 stdio 서버로 추가합니다. `slack_post_message`와 `slack_list_channels` 두 가지 도구면 충분합니다.

Cursor를 다시 시작합니다. 세 서버 모두 에이전트의 도구 목록에 나타나야 합니다. 에이전트에게 패널 목록(Minds), 코호트 목록(PostHog), 채널 목록(Slack)을 요청하여 각각 테스트합니다.

## 2단계: 자동화할 가치가 있는 리서치 워크플로우 선택하기

에이전트는 여러분이 부여하는 워크플로우만큼만 유용합니다. 구체적인 작업을 선택하세요. 우리가 구축할 예시는 다음과 같습니다:

> 기능 이름을 받아, PostHog에서 지난 30일 동안 해당 기능을 사용한 사용자를 찾고, Minds를 통해 가상 페르소나로 특징을 규정한 다음, 그 페르소나에게 해당 기능을 추천할지 여부와 그 이유를 묻고, 요약본을 Slack의 #product-research 채널에 게시하세요.

이 패턴(실제 데이터 기반 + 가상 데이터 보강 + 팀 공유)은 여러 의사결정에 걸쳐 재사용할 수 있습니다. 여러분의 상황에 맞게 수정하여 사용하세요.

## 3단계: 에이전트 프롬프트 작성하기

에이전트 프롬프트를 Cursor `.cursorrules` 파일에 넣거나 에이전트 세션의 시스템 메시지로 설정하세요. 효과적인 구조는 다음과 같습니다:

```text
You are a marketing research agent. Your job is to take a feature name as input
and return a recommendation summary, posted to Slack.

For each request, do the following in order:

1. Use PostHog tools to find users who triggered the feature event in the last
   30 days. Get a count and basic properties (plan tier, account age, region).

2. Build a Minds persona that matches the dominant cohort from step 1. Use
   `create_mind` with a description that captures the cohort's plan tier,
   tenure, and likely role.

3. Create a panel of three personas matching that profile, using `create_panel`
   then `ask_panel`. Ask: "Would you recommend this feature to a colleague?
   Why or why not? What would have to change for it to be a yes?"

4. Cross-reference the panel response against the PostHog data. Look for
   alignment (do the panel's stated reasons match the actual usage patterns?)
   and gaps (does the panel surface concerns the metrics don't show?).

5. Post a summary to #product-research in Slack with three sections:
   - Cohort profile (who used it)
   - Panel verdict (recommend or not, top stated reasons)
   - Recommended action (what to do next)

Keep the Slack summary under 500 words. Link back to the full panel export.
```

이 프롬프트는 의도적으로 세 가지 역할을 합니다:

- 에이전트가 단계를 건너뛰지 않도록 순서를 강제합니다.
- 에이전트에게 단순히 도구를 호출하는 방법뿐만 아니라, 여러 도구의 결과를 종합하는 방법을 알려줍니다.
- Slack 메시지가 실제로 읽기 쉽도록 출력의 양을 제한합니다.

## 4단계: 실제 기능으로 테스트하기

제품에서 실제로 출시한 기능을 선택하고 에이전트를 실행하세요. 예상되는 순서는 다음과 같습니다:

1. 에이전트가 PostHog `events` 쿼리를 호출하여 기능 이름과 지난 30일로 필터링된 `feature_used`를 조회합니다. 사용자 수와 샘플을 반환합니다.
2. 에이전트가 PostHog `cohorts`을 호출하여 사용자를 특성화합니다. 주된 요금제 등급과 평균 계정 사용 기간을 식별합니다.
3. 에이전트가 Minds `create_mind`를 "중간 등급 유료 고객, 플랫폼 사용 기간 6-18개월, <span>

기능 카테고리

</span>

의 주 사용자"와 같은 페르소나 설명과 함께 호출합니다.
4. 에이전트가 Minds `create_panel`를 해당 페르소나 세 명과 함께 호출합니다.
5. 에이전트가 Minds `ask_panel`를 추천 질문과 함께 호출합니다.
6. 에이전트가 응답을 읽습니다. Minds `export_panel`를 호출하여 Slack 링크에 사용할 전체 세션을 저장합니다.
7. 에이전트가 Slack `slack_post_message`을 구조화된 요약 및 내보내기 링크와 함께 호출합니다.

전체 소요 시간: 코호트 크기와 패널 응답 길이에 따라 60초에서 120초. 전체 비용: MCP 호출 비용 약 $0.15에 에이전트 추론 비용 $0.05.

어떤 단계에서든 실패하면 에이전트는 보통 한 번 재시도하거나 다른 방법을 시도합니다. 만약 막히면, 가장 흔한 원인은 4단계의 프롬프트가 너무 경직되어 페르소나 설명이 코호트와 깔끔하게 맞지 않는 경우입니다. 페르소나 설명 프롬프트를 더 유연하게 수정하고 다시 실행하세요.

## 5단계: 예약 실행하기

에이전트는 여러분의 개입 없이 실행될 때 비로소 가치를 창출합니다. 두 가지 방법이 있습니다:

*Slack을 통한 수동 트리거.* Cursor 에이전트를 트리거하는 `/research [feature-name]` 슬래시 명령을 추가합니다. 이것이 가장 간단한 방법이며, 비정기적인 리서치에 적합합니다.

*Cron 트리거.* CI 워크플로우(GitHub Actions, Linear 자동화 등 스케줄에 따라 실행할 수 있는 모든 것)를 사용하여 매주 월요일에 기능 이름 목록을 에이전트 엔드포인트로 보냅니다. 에이전트는 각 기능에 대해 워크플로우를 한 번씩 실행하고 각 요약을 게시합니다. 팀은 사람의 개입 없이 월요일 아침에 리서치 요약본을 받게 됩니다.

가치가 복리로 쌓이는 곳은 바로 cron 방식입니다. 한 분기 동안 출시된 모든 기능에 대해 기능 수준의 리서치를 실행하는 팀은 1년에 한 번 큰 조사를 하는 팀보다 제품에 대해 더 많이 배우며, 비용은 5% 미만으로 절감됩니다.

## 맞춤형 에이전트가 기성 제품보다 나은 점

패키지형 리서치 도구를 사용하는 대신 직접 구축해야 하는 이유는 다음과 같습니다:

*워크플로우 특화성.* 기성 도구는 가장 일반적인 경우에 최적화되어 있습니다. 여러분 팀의 리서치 워크플로우는 가장 일반적인 경우와는 다를 가능성이 높습니다. 맞춤형 에이전트는 여러분의 의사결정 리듬에 정확히 맞춰집니다.

*도구 조합.* 가상 리서치가 실제 제품 데이터와 결합되고, 그 결과가 팀 채널에 공유될 때 흥미로운 움직임이 일어납니다. 이 전체 과정을 수행하는 기성 도구는 없습니다. 세 개의 MCP를 연결하는 맞춤형 에이전트는 가능합니다.

*비용 관리.* 호출 건당, 서비스별로 비용을 지불합니다. 사용자 라이선스나 추가 플랫폼 수수료가 없습니다. 사용량이 많은 경우 팀 규모에서는 패키지 도구보다 저렴하며, 사용량이 적으면 거의 무료입니다.

*개선 속도.* 워크플로우를 변경하는 것은 프롬프트를 변경하는 것과 같습니다. 공급업체의 로드맵이나 기능 요청이 필요 없습니다. 제약은 다른 사람의 출시 주기가 아니라 여러분 자신의 관심입니다.

## 흔히 겪는 문제들

프로덕션 환경에서 이를 실행하며 겪었던 몇 가지 까다로운 문제입니다:

- *호출 간 페르소나 변동.* 실행할 때마다 새로운 Mind를 생성하면 페르소나 프로필이 매번 미묘하게 바뀝니다. Mind를 한 번 영구 저장(ID 캐싱)하고 재사용하세요. Minds MCP는 바로 이 목적을 위해 `list_minds`를 제공합니다.
- *PostHog 쿼리 시간 초과.* 대규모 코호트는 에이전트의 시간 초과를 유발할 수 있습니다. 프롬프트에서 코호트 크기를 제한하거나 대표적인 샘플로 미리 필터링하세요.
- *Slack 메시지 크기 제한.* Slack은 4000자가 넘는 메시지를 자릅니다. 프롬프트의 500단어 제한은 그보다 훨씬 적지만, 에이전트가 이를 무시할 경우 단일 메시지 대신 스레드로 게시하세요.
- *OAuth 토큰 갱신.* 세 서비스 모두 주기적으로 토큰을 갱신합니다. 에이전트가 갑자기 작동을 멈추면 프롬프트를 디버깅하기 전에 각 커넥터를 다시 인증하세요.

## 다음 단계

단일 기능 추천 워크플로우는 시작점일 뿐입니다. 이 워크플로우가 작동하면 동일한 에이전트를 다음과 같이 일반화할 수 있습니다:

- 주간 캠페인 효과 분석 루프 (캠페인 시작 전 가상 광고 반응 테스트, 실제 클릭률과 비교 검증)
- 월간 경쟁사 포지셔닝 분석 (경쟁사 메시지에 대한 가상 패널 실행, 자사 전환 데이터와 교차 분석)
- 분기별 페르소나 업데이트 (관찰된 제품 사용 행태 변화에 기반한 가상 페르소나 업데이트)

각각은 동일한 형태를 가집니다: 실제 데이터 기반, 가상 데이터 보강, 팀 공유. 첫 번째 것을 구축하세요. 나머지는 변형일 뿐입니다.

함께 연결할 만한 다른 것들에 대한 자세한 내용은 [2026년 마케팅 및 리서치 에이전트를 위한 최고의 MCP 서버](/blog/best-mcp-servers-marketing-research-agents-2026)를 참조하세요. 이 분야의 근본적인 개념에 대해서는 [에이전트 기반 시장 조사의 정의](/blog/agentic-market-research-definition)를, 가상 결과물의 신뢰도 문제에 대해서는 [에이전트 기반 리서치 결과 검증하기](/blog/validating-agentic-research-output-eval-frameworks)를 확인하세요.