지난달 저는 Claude를 제 이메일 인프라에 연결했습니다. "Claude가 이메일 초안을 작성하면 제가 어딘가에 붙여넣는" 방식이 아니라, 에이전트가 채팅창에서 직접 제 도메인 상태를 확인하고, 이메일을 보내며, 배송 이벤트(delivery events)를 다시 읽어오는 방식입니다.

이것을 가능하게 만드는 접착제는 MCP (Model Context Protocol)이며, 전체 설정에는 약 5분 정도가 소요됩니다. 여기에는 정확한 방법과 함께, 에이전트가 실제로 프로덕션 인프라(production infrastructure)를 다룰 수 있게 되었을 때 저를 놀라게 했던 점들이 담겨 있습니다.

MCP란 실제로 무엇인가

MCP는 AI 클라이언트 (Claude, Cursor, Windsurf, 혹은 여러분의 자체 에이전트)가 서버에 의해 노출된 도구(tools)를 호출할 수 있게 해주는 작은 JSON-RPC 프로토콜입니다. 서버는 JSON 스키마(JSON schemas)로 자신의 도구를 설명하고, 모델은 도구를 선택하여 인자(arguments)를 채우며, 클라이언트는 호출을 실행합니다.

중요한 설계 결정 사항은 서버가 어디에서 실행되는가입니다. 많은 MCP 서버는 기기마다 설치해야 하는 로컬 stdio 프로세스입니다. 호스팅된 API와 통신하는 모든 경우에는 **호스팅된 MCP 서버 (hosted MCP server)**가 더 나은 형태입니다. 설치할 것이 없고, API 키가 인증 역할을 하며, HTTP를 사용하는 모든 클라이언트가 이를 사용할 수 있기 때문입니다.

저는 트랜잭션 이메일(transactional email)을 위해 SMTPfast를 사용하는데, 이는 https://smtpfa.st/api/mcp에 호스팅된 MCP 엔드포인트를 제공합니다. 예제에서는 이것을 사용하겠지만, 이 패턴은 모든 호스팅된 MCP 서버에 적용됩니다.

1단계: Claude Code 연결하기

단 한 줄의 명령어로 가능합니다:

claude mcp add --transport http smtpfast https://smtpfa.st/api/mcp \
  --header "Authorization: Bearer sf_your_api_key"

Cursor의 경우, .cursor/mcp.json에 들어가는 스니펫(snippet) 형태입니다:

{
  "mcpServers": {
    "smtpfast": {
...

이것이 설치의 전부입니다. npm 패키지도, 로컬 프로세스도, 기기 간의 버전 차이(version drift)도 없습니다.

2단계: 에이전트가 무엇을 할 수 있는지 확인하기

MCP 서버는 스스로를 설명(self-describe)합니다. curl을 사용하여 도구 목록을 확인해 볼 수 있습니다:

curl -sS https://smtpfa.st/api/mcp \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sf_your_api_key" \
...

SMTPfast 서버는 send_email, list_emails, get_email, list_domains, verify_domain, list_suppressions, get_analytics, list_contacts의 8가지 도구 (tools)를 노출합니다. 모델은 이러한 스키마 (schemas)를 읽고 나머지는 스스로 파악합니다.

3단계: 그냥 요청하기

서버가 연결되면, Claude에게 다음과 같이 입력할 수 있습니다:

"내 도메인이 인증되었는지 확인한 다음, hello@mydomain.com에서 내 개인 주소로 테스트 이메일을 보내고, 전송이 완료되면 알려줘."

배후에서 에이전트 (agent)는 list_domains를 호출하여 DKIM 상태를 확인하고, send_email을 호출한 뒤 기다렸다가, get_email을 호출하여 전송 이벤트 (delivery events)를 읽습니다. 저는 각 도구 호출 (tool call)이 진행되는 것을 지켜보며 승인합니다. SDK도, 글루 코드 (glue code)도, 메시지 ID를 복사해서 붙여넣을 필요도 없습니다.

디버깅 워크플로 (debugging workflow)는 이 방식이 진정으로 유용해지는 지점입니다:

"어제 jane@example.com으로 보낸 이메일이 왜 반송(bounce)되었지?"

에이전트는 이메일을 가져와 SMTP 진단 코드 (diagnostic code)와 함께 반송 이벤트를 읽고, 해당 주소가 차단 목록 (suppression list)에 있는지 확인한 후, 이를 평이한 언어로 설명해 줍니다. 예전에는 대시보드를 클릭하며 5분 동안 수행해야 했던 작업입니다.

놀라웠던 점

1. 승인 단계가 예상보다 더 중요합니다. 대부분의 MCP 클라이언트 (clients)는 도구가 실행되기 전에 각 도구 호출을 보여줍니다. 읽기 전용 도구 (read tools)의 경우 이는 번거롭게 느껴질 수 있습니다. 하지만 send_email의 경우에는 정확히 적절합니다. 저는 API 키의 권한 범위를 먼저 제한하지 않고는, 전송 기능이 있는 도구를 무인으로 작동하는 에이전트에 연결하지 않을 것입니다.

2. 에이전트는 체이닝 (chaining)에는 뛰어나지만, 절제에는 서툽니다. 모호한 질문을 던지면 에이전트는 하나면 충분할 상황에서도 기꺼이 네 개의 도구를 호출합니다. 서버에서의 정교한 도구 설명 (tool descriptions)은 좋은 프롬프트 (prompts)만큼이나 중요합니다.

3. 서버는 쉬운 부분입니다. 만약 당신의 제품에 이미 REST API가 있다면, MCP 서버는 대부분 번역 계층 (translation layer)에 불과합니다: 도구 스키마 (tool schema)를 입력받아 API 호출 (API call)을 내보내는 역할입니다. 어려운 작업들 (인증 (auth), 속도 제한 (rate limits), 검증 (validation))은 이미 API에 존재합니다. 이것이 제가 stdio보다 호스팅된 (hosted) MCP를 선호하는 이유이기도 합니다. 호스팅된 MCP는 API가 이미 강제하고 있는 모든 것들을 재사용하며, 여기에는 유출된 키를 한 곳에서 무효화할 수 있다는 점도 포함됩니다.

직접 시도해보기

이 과정을 처음부터 끝까지 재현해보고 싶다면: 무료 SMTPfast 계정 (월 3,000통 이메일, 카드 불필요)을 생성하고, 도메인을 인증한 뒤, API 키를 생성하고, 위의 claude mcp add 명령어를 실행하세요. MCP 문서에서 도구 스키마 (tool schemas)와 몇 가지 프롬프트 (prompts) 예시를 확인할 수 있습니다.

그리고 만약 당신이 직접 개발 도구 (dev tool)를 만들고 있다면: 호스팅된 MCP 엔드포인트 (endpoint)를 배포하세요. 주말 정도의 작업량으로, 고객들이 이미 사용 중인 모든 AI 에이전트 (AI agent)가 당신의 제품을 사용할 수 있게 만들어 줍니다.