# MCP vs REST API: 이메일 마케팅에는 어떤 워크플로가 맞을까요?

정식 URL: https://brew.new/ko/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use
글쓴이: Thomas Park
게시일: 2026-09-23
수정일: 2026-09-29

팀의 개발자가 이메일 플랫폼을 Claude에 연결하고, 채팅 창에서 다음 주 캠페인 초안을 써요. 다음 날 아침, 누군가 가입 웰컴 이메일도 같은 방식으로, 그러니까 어시스턴트를 통해 돌릴 수 있는지 물어요. 플랫폼 문서에는 MCP 서버와 REST API가 나란히 나와 있어요.

에이전트를 지원하는 이메일 플랫폼은 이제 대부분 이 두 가지 접근 방법을 제공해요. MCP 서버는 AI 어시스턴트가 대화 중에 플랫폼의 도구를 호출할 수 있게 해 줘요. REST API는 코드가 직접 호출할 수 있는 작업을 제공해요. 둘은 내부적으로 같은 엔드포인트에 닿는 경우가 많아서, 결국 누가 언제 작업하느냐의 문제예요.

사람이 어시스턴트를 통해 작업할 때는 MCP를, 아무도 지켜보지 않는 상태에서 제품이 이메일을 보내야 할 때는 REST API를 쓰세요. 대부분의 팀은 결국 둘 다 쓰게 돼요.

## 핵심 요약

- MCP는 판단이 많이 필요한 대화형 작업에 맞아요. 캠페인 초안 작성, 오디언스 구성, 발송 성과가 기대에 못 미친 이유 묻기 같은 일이에요.
- REST API는 실서비스 경로에 맞아요. 사용자 가입 시 트리거 실행, 연락처 동기화, 영수증 발송 같은 일이에요.
- CLI는 그 중간에 있어요. API처럼 스크립트로 자동화할 수 있고, 코딩 에이전트가 읽기도 쉬워요.
- Brew의 MCP는 OAuth 및 조직 단위 연결에서 실제 발송 전에 확인을 요구해요. 브랜드 API 키로 연결한 클라이언트에는 자체 승인 정책이 필요해요. API 코드는 검토, 멱등성, 재시도를 직접 갖춰야 해요.

## 각각의 정의

MCP(Model Context Protocol)는 Claude, ChatGPT, Cursor 같은 AI 클라이언트에 도구를 제공하기 위한 개방형 표준이에요. 클라이언트는 설명과 스키마가 붙은 도구 목록을 읽고, 요청에 따라 어떤 도구를 호출할지 골라요. Brew 서버는 `https://brew.new/api/mcp` 주소에 있고 OAuth를 지원하므로, 키를 다루는 대신 로그인하고 브랜드를 고르면 돼요.

REST API는 코드가 호출하는 HTTP 엔드포인트의 모음이에요. Brew는 API에 대한 OpenAPI 명세, TypeScript SDK, 일반 텍스트로 된 [에이전트 가이드](https://brew.new/api/v1/llms.txt)를 공개하고 있어요. 모든 호출에는 API 키가 들어가고, 무엇을 언제 호출할지는 코드가 정해요.

다른 업체들도 같은 방식을 따라요. Customer.io의 MCP 서버는 API를 [읽기, 쓰기, 삭제 도구로 나눠](https://docs.customer.io/ai/mcp/get-started/) 감싸요. Brevo는 [OpenAPI 명세](https://developers.brevo.com/docs/mcp-protocol)에서 MCP 도구를 생성해요.

## 나란히 비교하기

| | MCP | REST API |
| --- | --- | --- |
| 주도하는 쪽 | 어시스턴트를 통해 사람이 | 코드 |
| 대표 작업 | 이메일 초안 작성과 수정, 오디언스 구성, 캠페인 예약, 분석 읽기 | 이벤트 트리거 실행, 연락처 생성·업데이트(upsert), 트랜잭션 이메일 발송, 발송 상태 폴링 |
| 인증 | OAuth 로그인, OAuth가 없는 클라이언트는 API 키 | 브랜드나 조직 범위의 API 키 |
| 안전장치 | OAuth 및 조직 단위 연결에서는 확인할 때까지 Brew가 실제 발송 보류 | 코드가 결정, 멱등성 키와 자체 검토 단계 사용 |
| 실패 처리 | 어시스턴트가 오류를 읽고 다시 시도하거나 사용자에게 질문 | 고정된 오류 코드로 분기하고 백오프를 두고 재시도 |
| 응답 크기 | 어시스턴트의 컨텍스트 창에 따라 제한 | 페이지네이션 외에는 제한 없음 |
| 적합한 경우 | 판단이나 반복 수정이 필요한 작업 | 매번 같은 방식으로 실행돼야 하는 작업 |

## MCP가 맞는 경우

대화로 진행되는 작업이라면 MCP를 쓰세요.

- 캠페인 제작. “이 업데이트 내역으로 10월 제품 업데이트 이메일을 쓰고, 테스트 이메일을 보낸 다음, 화요일 9시로 예약해 주세요.” 어시스턴트는 `create_email`, `edit_email`, `test: true` 옵션을 넣은 `send_email`, 그다음 `scheduledAt` 값을 넣은 `send_email` 도구를 차례로 호출하고, 승인을 받으려고 멈춰요.
- 오디언스 질문. “7월 전에 가입했고 지난달에 이메일을 하나라도 연 Pro 고객은 몇 명인가요?” 어시스턴트는 `search_contacts`, 필드 조회, `create_audience` 도구를 조합해요.
- 분석. “클릭률이 가장 낮은 자동화는 무엇이고, 무엇이 달라졌나요?” 어시스턴트는 `get_email_analytics` 도구의 결과와 자동화 성과를 읽어요.
- 일회성 설정. 사람이 단계마다 검토하면서 트리거와 자동화를 한 번 만드는 일이에요.

Brew에서는 MCP로 생성한 이메일도 앱에서 생성한 이메일과 같은 브랜드 문서를 써요. 클라이언트 설정은 [Brew MCP 글](/ko/blog/brew-mcp)에서 다뤄요.

MCP 응답은 어시스턴트의 컨텍스트에 들어가야 해요. Brew의 [플로우 글](/ko/blog/email-flows)에서 짚었듯이, MCP로 전체 HTML을 요청하면 긴 시퀀스의 처음 한두 단계만 돌아오지만, REST 경로는 모든 본문을 돌려줘요.

## REST API가 맞는 경우

이메일이 제품의 일부라면 API를 쓰세요.

- 이벤트 트리거. 사용자가 가입하면 백엔드가 사용자의 이메일과 필드를 담아 `POST /v1/automations/triggers/{triggerEventId}/fire` 엔드포인트를 호출해요. 나머지는 게시된 자동화가 처리해요.
- 트랜잭션 이메일. 영수증과 비밀번호 재설정 이메일도 같은 방식으로, 용도가 트랜잭션인 도메인의 자동화를 통해 발송돼요. [트랜잭션 이메일](/ko/blog/transactional-emails) 글을 참고하세요.
- 연락처 동기화. `POST /v1/contacts` 엔드포인트는 요청당 연락처를 최대 1,000개까지 생성하거나 업데이트해요.
- 모니터링. `GET /v1/sends/{sendId}` 엔드포인트는 대시보드나 알림에 쓸 상태와 통계를 돌려줘요.

이를 지원하는 엔드포인트에서는 문서에 명시된 24시간 기간 안에 재시도할 때 같은 `Idempotency-Key` 헤더와 요청 본문을 그대로 다시 쓰세요(트리거 이벤트는 이 키를 기준으로 90일 동안 중복이 제거돼요). 논리적으로 다른 작업에는 다른 키를 쓰고, 쓰기 요청이 멱등성 키로 보호된다고 가정하기 전에 엔드포인트 명세를 읽어 보세요. 요청 한도 헤더는 언제 요청 속도를 늦춰야 하는지 알려 줘요. API 오류 응답에는 분기 처리에 쓸 수 있는 `code` 값(예: `CONSENT_REQUIRED`)이 들어 있어요. 네트워크 실패는 따로 처리하세요. 이 모든 내용은 Brew의 [API 가이드](https://brew.new/api/v1/llms.txt)에 나와 있어요.

## CLI가 맞는 자리

터미널에서 일하는 코딩 에이전트에게는 두 방법보다 CLI가 더 잘 맞는 경우가 많아요. Brew [CLI](https://docs.brew.new/api-reference/cli/agents)는 터미널에 연결되지 않은 상태에서는 API 응답을 JSON 한 줄로 돌려주고, 에이전트가 판단에 쓸 수 있는 종료 코드를 사용해요. 코드 4는 확인이 필요하다는 뜻이고, 이때 CLI는 승인 후 `--yes` 플래그를 붙여 다시 실행할 정확한 명령을 출력해요. 또 `brew-cli types` 명령으로 타입이 지정된 페이로드 정의를 생성해서, 백엔드의 트리거 호출이 트리거 스키마와 어긋나지 않게 해 줘요.

## 함께 쓰는 워크플로

SaaS 팀이 작업을 나누는 한 가지 방법을 예로 들어 볼게요.

1. 개발자가 Cursor나 Claude에서 MCP로 `user_signed_up` 트리거와 웰컴 자동화를 만들고, `test_automation` 도구로 테스트한 다음 게시해요.
2. 백엔드는 가입이 일어날 때마다 사용자 ID로 만든 멱등성 키를 붙여 REST API로 트리거를 실행해요.
3. 매달 마케터가 MCP로 연결된 Claude에게 제품 업데이트 이메일의 초안 작성과 예약을 요청해요.
4. 예약된 애플리케이션 작업이 현재 활성화 상태나 결제 상태를 확인한 다음, 리마인더 대상임을 알리는 별도의 이벤트를 보내요. 연락처 필드를 동기화하는 것만으로는 이미 진행 중인 플로우의 원래 이벤트 페이로드가 바뀌지 않아요.

1단계와 3단계에서는 사람이 어시스턴트의 작업을 검토해요. 2단계와 4단계는 아무도 지켜보지 않는 상태에서 가입이 있을 때마다, 또는 매일 밤 실행돼요.

## 자주 묻는 질문

### MCP는 API보다 느리거나 덜 안정적인가요?

사용자와 엔드포인트 사이에 어시스턴트가 끼므로 요청 하나에 거치는 단계가 많아지고, 어시스턴트가 엉뚱한 도구를 고를 수도 있어요. 대화형 작업에는 괜찮지만, 매번 반드시 실행돼야 하는 가입 이벤트에는 맞지 않아요.

### 어느 쪽이 더 안전한가요?

Brew는 OAuth 및 조직 단위 연결에서 실제 발송 전에 확인을 요구해요. 브랜드 API 키로 연결한 클라이언트라면 자체 승인 정책을 설정하세요. API를 쓸 때는 키를 환경 변수로 보호하고, 가능하면 브랜드 전용 키를 쓰고, 재시도하는 모든 쓰기 요청에 멱등성 키를 넣으세요.

### 내 제품 안의 에이전트가 API를 도구로 쓸 수 있나요?

네. Brew의 [에이전트 연동 가이드](https://docs.brew.new/integrations/ai-agents/use-brew-with-ai-agents)에서 API 엔드포인트를 함수 호출 도구로 연결하는 방법을 설명해요. 인증과 재시도는 SDK가 처리해요.

## 다음 단계

두 방식을 모두 써 보려면, 캠페인 작업용으로 어시스턴트에 [MCP 서버](/ko/mcp)를 연결하고, 백엔드가 실행할 트리거용 API 키를 하나 만드세요.