어시스턴트로 하는 이메일 작업에는 MCP를, 애플리케이션 이벤트에는 REST API를 쓰세요. 인증, 승인, 재시도, Brew 워크플로를 비교해요.
팀의 개발자가 이메일 플랫폼을 Claude에 연결하고, 채팅 창에서 다음 주 캠페인 초안을 써요. 다음 날 아침, 누군가 가입 웰컴 이메일도 같은 방식으로, 그러니까 어시스턴트를 통해 돌릴 수 있는지 물어요. 플랫폼 문서에는 MCP 서버와 REST API가 나란히 나와 있어요.
에이전트를 지원하는 이메일 플랫폼은 이제 대부분 이 두 가지 접근 방법을 제공해요. MCP 서버는 AI 어시스턴트가 대화 중에 플랫폼의 도구를 호출할 수 있게 해 줘요. REST API는 코드가 직접 호출할 수 있는 작업을 제공해요. 둘은 내부적으로 같은 엔드포인트에 닿는 경우가 많아서, 결국 누가 언제 작업하느냐의 문제예요.
사람이 어시스턴트를 통해 작업할 때는 MCP를, 아무도 지켜보지 않는 상태에서 제품이 이메일을 보내야 할 때는 REST API를 쓰세요. 대부분의 팀은 결국 둘 다 쓰게 돼요.
MCP(Model Context Protocol)는 Claude, ChatGPT, Cursor 같은 AI 클라이언트에 도구를 제공하기 위한 개방형 표준이에요. 클라이언트는 설명과 스키마가 붙은 도구 목록을 읽고, 요청에 따라 어떤 도구를 호출할지 골라요. Brew 서버는 https://brew.new/api/mcp 주소에 있고 OAuth를 지원하므로, 키를 다루는 대신 로그인하고 브랜드를 고르면 돼요.
REST API는 코드가 호출하는 HTTP 엔드포인트의 모음이에요. Brew는 API에 대한 OpenAPI 명세, TypeScript SDK, 일반 텍스트로 된 에이전트 가이드를 공개하고 있어요. 모든 호출에는 API 키가 들어가고, 무엇을 언제 호출할지는 코드가 정해요.
다른 업체들도 같은 방식을 따라요. Customer.io의 MCP 서버는 API를 읽기, 쓰기, 삭제 도구로 나눠 감싸요. Brevo는 OpenAPI 명세에서 MCP 도구를 생성해요.
| MCP | REST API | |
|---|---|---|
| 주도하는 쪽 | 어시스턴트를 통해 사람이 | 코드 |
| 대표 작업 | 이메일 초안 작성과 수정, 오디언스 구성, 캠페인 예약, 분석 읽기 | 이벤트 트리거 실행, 연락처 생성·업데이트(upsert), 트랜잭션 이메일 발송, 발송 상태 폴링 |
| 인증 | OAuth 로그인, OAuth가 없는 클라이언트는 API 키 | 브랜드나 조직 범위의 API 키 |
| 안전장치 | OAuth 및 조직 단위 연결에서는 확인할 때까지 Brew가 실제 발송 보류 | 코드가 결정, 멱등성 키와 자체 검토 단계 사용 |
| 실패 처리 | 어시스턴트가 오류를 읽고 다시 시도하거나 사용자에게 질문 | 고정된 오류 코드로 분기하고 백오프를 두고 재시도 |
| 응답 크기 | 어시스턴트의 컨텍스트 창에 따라 제한 | 페이지네이션 외에는 제한 없음 |
| 적합한 경우 | 판단이나 반복 수정이 필요한 작업 | 매번 같은 방식으로 실행돼야 하는 작업 |
대화로 진행되는 작업이라면 MCP를 쓰세요.
create_email, edit_email, test: true 옵션을 넣은 send_email, 그다음 scheduledAt 값을 넣은 send_email 도구를 차례로 호출하고, 승인을 받으려고 멈춰요.search_contacts, 필드 조회, create_audience 도구를 조합해요.get_email_analytics 도구의 결과와 자동화 성과를 읽어요.Brew에서는 MCP로 생성한 이메일도 앱에서 생성한 이메일과 같은 브랜드 문서를 써요. 클라이언트 설정은 Brew MCP 글에서 다뤄요.
MCP 응답은 어시스턴트의 컨텍스트에 들어가야 해요. Brew의 플로우 글에서 짚었듯이, MCP로 전체 HTML을 요청하면 긴 시퀀스의 처음 한두 단계만 돌아오지만, REST 경로는 모든 본문을 돌려줘요.
이메일이 제품의 일부라면 API를 쓰세요.
POST /v1/automations/triggers/{triggerEventId}/fire 엔드포인트를 호출해요. 나머지는 게시된 자동화가 처리해요.POST /v1/contacts 엔드포인트는 요청당 연락처를 최대 1,000개까지 생성하거나 업데이트해요.GET /v1/sends/{sendId} 엔드포인트는 대시보드나 알림에 쓸 상태와 통계를 돌려줘요.이를 지원하는 엔드포인트에서는 문서에 명시된 24시간 기간 안에 재시도할 때 같은 Idempotency-Key 헤더와 요청 본문을 그대로 다시 쓰세요(트리거 이벤트는 이 키를 기준으로 90일 동안 중복이 제거돼요). 논리적으로 다른 작업에는 다른 키를 쓰고, 쓰기 요청이 멱등성 키로 보호된다고 가정하기 전에 엔드포인트 명세를 읽어 보세요. 요청 한도 헤더는 언제 요청 속도를 늦춰야 하는지 알려 줘요. API 오류 응답에는 분기 처리에 쓸 수 있는 code 값(예: CONSENT_REQUIRED)이 들어 있어요. 네트워크 실패는 따로 처리하세요. 이 모든 내용은 Brew의 API 가이드에 나와 있어요.
터미널에서 일하는 코딩 에이전트에게는 두 방법보다 CLI가 더 잘 맞는 경우가 많아요. Brew CLI는 터미널에 연결되지 않은 상태에서는 API 응답을 JSON 한 줄로 돌려주고, 에이전트가 판단에 쓸 수 있는 종료 코드를 사용해요. 코드 4는 확인이 필요하다는 뜻이고, 이때 CLI는 승인 후 --yes 플래그를 붙여 다시 실행할 정확한 명령을 출력해요. 또 brew-cli types 명령으로 타입이 지정된 페이로드 정의를 생성해서, 백엔드의 트리거 호출이 트리거 스키마와 어긋나지 않게 해 줘요.
SaaS 팀이 작업을 나누는 한 가지 방법을 예로 들어 볼게요.
user_signed_up 트리거와 웰컴 자동화를 만들고, test_automation 도구로 테스트한 다음 게시해요.1단계와 3단계에서는 사람이 어시스턴트의 작업을 검토해요. 2단계와 4단계는 아무도 지켜보지 않는 상태에서 가입이 있을 때마다, 또는 매일 밤 실행돼요.
사용자와 엔드포인트 사이에 어시스턴트가 끼므로 요청 하나에 거치는 단계가 많아지고, 어시스턴트가 엉뚱한 도구를 고를 수도 있어요. 대화형 작업에는 괜찮지만, 매번 반드시 실행돼야 하는 가입 이벤트에는 맞지 않아요.
Brew는 OAuth 및 조직 단위 연결에서 실제 발송 전에 확인을 요구해요. 브랜드 API 키로 연결한 클라이언트라면 자체 승인 정책을 설정하세요. API를 쓸 때는 키를 환경 변수로 보호하고, 가능하면 브랜드 전용 키를 쓰고, 재시도하는 모든 쓰기 요청에 멱등성 키를 넣으세요.
네. Brew의 에이전트 연동 가이드에서 API 엔드포인트를 함수 호출 도구로 연결하는 방법을 설명해요. 인증과 재시도는 SDK가 처리해요.
두 방식을 모두 써 보려면, 캠페인 작업용으로 어시스턴트에 MCP 서버를 연결하고, 백엔드가 실행할 트리거용 API 키를 하나 만드세요.
