# 에이전트가 이메일을 보낼 때도 여전히 적용되는 원칙

정식 URL: https://brew.new/ko/blog/agent-email-deliverability
글쓴이: Thomas Park
게시일: 2026-09-27
수정일: 2026-09-28

에이전트도 사람과 같은 발송 인프라로 캠페인을 시작할 수 있어요. Gmail이 보는 건 여전히 발신자, 도메인, 메시지예요.

메일 서비스 제공업체가 평가하는 건 **도메인, IP, 스팸 신고율**이에요. 사람이 ‘보내기’를 눌렀는지는 평가하지 않아요. 에이전트가 프로모션 본문을 트랜잭션 IP로 내보내면, 사람이 직접 했을 때와 똑같은 문제를 떠안게 돼요. 다만 더 빨리 떠안을 뿐이에요.

이 글은 [전달성 가이드](/ko/blog/email-deliverability)를 대신하는 글이 아니라 함께 읽는 글이에요. 그 글은 평판, 인증, 리스트 정리를 다뤄요. 이 글은 발송 버튼을 누르는 쪽이 소프트웨어일 때 생기는 실수를 다뤄요.

## 에이전트를 따로 다루지 않는 법률

[CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)은 상업용 메시지에 적용돼요. [주된 목적 판단 기준](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3)이 보는 건 누가 입력했느냐가 아니라 제목과 본문이에요.

인보이스와 혜택이 섞인 메시지라면 주된 목적이 무엇인지 따져 보세요. 제목, 계정 정보가 놓인 위치, 프로모션이 얼마나 두드러지는지가 판단을 좌우해요. 짧은 프로모션 푸터가 붙었다고 해서 명세서 이메일이 자동으로 상업용 메시지가 되지는 않아요. FTC 가이드에 예시가 나와 있어요. 상업용 메시지에는 거짓 없는 헤더와 제목, 실제 우편 주소, 제대로 작동하는 수신 거부 수단이 있어야 해요.

반대도 마찬가지예요. 실제 보안 이벤트를 계기로 에이전트가 보낸 비밀번호 재설정 이메일은, 본문이 그 이벤트에서 벗어나지 않는 한 여전히 트랜잭션 이메일이에요.

## Gmail과 Yahoo가 실제로 요구하는 것

[Gmail의 발신자 요건](https://support.google.com/mail/answer/81126)에는 모든 발신자에게 적용되는 규칙과, 개인 Gmail 계정으로 하루 약 **5,000통**을 보내는 대량 발신자에게 적용되는 더 엄격한 규칙이 있어요. 더 엄격한 요건은 다음과 같아요.

- SPF, DKIM, 그리고 `p=none` 또는 그보다 엄격한 정책의 DMARC 정렬.
- [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html)에 따른 원클릭 수신 거부, `List-Unsubscribe` 및 `List-Unsubscribe-Post` 헤더.
- 스팸률 **0.1%** 미만 유지, 어떤 경우에도 **0.3%** 도달 금지.

트랜잭션 메일은 원클릭 규칙에서 면제돼요. 하지만 인증에서는 면제되지 않고, 템플릿을 세일 홍보로 채우면 스팸 신고도 피할 수 없어요.

[Yahoo](https://senders.yahooinc.com/best-practices/)는 대량 발신자에게 마케팅 메일과 트랜잭션 메일을 **서로 다른 IP**로, 가능하면 서로 다른 도메인으로 보내 달라고 요청해요. 에이전트가 어떤 발신자 정보를 쓸지 애매한 기본값에 맡기지 말고 직접 확인하세요.

## 에이전트에게 맡길 범위

캠페인과 자동화에는 에이전트에게 **프로모션용** 발신자 정보를 주세요. 직접 워밍업해 온 도메인, 스팸 신고가 들어올 것을 감안하고 쓰는 IP, 테스트를 마친 수신 거부 헤더를 갖춘 발신자 정보예요.

**트랜잭션** 메일은 별도의 발신자 정보로 보내세요. Brew에서는 발송 용도가 트랜잭션인 도메인이 그 발신자 정보이고, 메일 자체는 트리거가 있는 게시된 자동화예요. 템플릿은 에이전트가 작성해도 돼요. 하지만 이벤트마다 메일이 나가는 경로는 여전히 JSON 페이로드를 담은 `POST /v1/automations/triggers/{triggerEventId}/fire` 요청이어야 해요. “이 초안을 리스트에 보내 주세요” 같은 지시가 그 경로가 되어서는 안 돼요.

인증된 도메인 여러 개 중에서 “어디가 잘 도착하는지 보려고” 에이전트가 From 주소를 고르게 두지 마세요. 그러면 평판 두 개를 동시에 쌓으면서 어느 쪽도 제대로 이해하지 못하게 돼요.

## 사람이 지켜보지 않는 첫 발송 전 검토

실패는 오타로 나타나지 않아요. 한 번도 공개한 적 없는 수치를 인용하는 매끄러운 문단이나, 영수증처럼 보이는 제목으로 나타나요.

에이전트가 검토 대기열 없이 보내게 하기 전에 다음을 확인하세요.

1. 첫 캠페인을 원래 브리프와 대조해 읽으세요. 모든 수치는 직접 관리하는 문서에 나와 있어야 해요.
2. Gmail, Yahoo, Outlook 주소가 포함된 시드 리스트로 보내 보세요.
3. 프로모션 메일에는 원클릭 수신 거부 헤더가 있고, 트랜잭션 메일에서는 의도적으로 뺐는지 확인하세요.
4. 프로모션 메일 푸터에 실제 우편 주소가 있는지 확인하세요.

Harmonya의 Cory Nelson은 [Noah Adelstein](https://thegtmengineer.substack.com/p/how-to-turn-email-marketing-into)에게 이 루프를 믿기 전에 첫 캠페인을 직접 읽어 검토했다고 말했어요. 이게 올바른 순서예요.

## 핵심 요약

도메인을 인증하고, 알맞은 발신자 정보를 고르고, 첫 캠페인을 승인된 브리프와 대조해 검토하세요. 어시스턴트의 권한과 확인 설정도 점검하세요. 모든 MCP 클라이언트가 같은 방식으로 승인을 요청하지는 않아요.

지어낸 수치를 막는 브리프는 [이메일 에이전트에게 브리프 쓰는 법](/ko/blog/how-to-brief-an-email-agent)에 정리했어요. Harmonya가 첫 캠페인을 어떻게 읽어 검토했는지는 [Harmonya가 뉴스레터를 라이프사이클 프로그램으로 바꾼 방법](/ko/blog/harmonya-lifecycle-email)에서 볼 수 있어요.