# 트랜잭션 이메일이란? 정의와 보내는 방법

정식 URL: https://brew.new/ko/blog/transactional-emails
글쓴이: Thomas Park
게시일: 2026-08-22
수정일: 2026-09-28

트랜잭션 이메일은 거래나 고객 관계에 관한 정보를 전해요. 영수증, 사용자가 요청한 비밀번호 재설정, 배송 업데이트, 계정 보안 알림 같은 이메일이에요. 구매나 재방문을 권하는 캠페인과는 목적이 달라요.

이 구분은 메시지 내용에 달려 있어요. 발송 도구에서 이메일을 ‘트랜잭션’으로 지정한다고 해서 법적 성격이 정해지지는 않아요.

## 주된 목적 판단 기준 적용하기

[FTC의 CAN-SPAM 가이드](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business)는 거래 메시지와 관계 메시지의 범주를 좁게 정의해요. 상업적 내용과 거래 관련 내용이 섞인 메시지라면, 합리적인 수신자가 제목을 보고 무엇이라고 이해할지, 거래 정보가 어디에 나오는지를 따져요.

제목이 홍보성이면 섞인 메시지가 상업용 이메일로 분류될 수 있어요. 짧은 홍보성 푸터가 있다고 해서 자동으로 그렇게 되지는 않아요. FTC는 그런 푸터가 있어도 주로 거래 관련 메시지로 남는 계좌 명세서를 예로 들어요. 중요한 건 [규칙](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-316/section-316.3)과 실제 메시지예요.

꼭 필요한 정보는 눈에 잘 띄게 두세요. 프로모션이 영수증이나 보안 알림의 내용을 흐린다면, 보통은 마케팅 이메일을 따로 보내는 편이 더 명확한 선택이에요. 이 내용은 미국 가이드라인이므로, 내 수신자와 비즈니스에 적용되는 요건을 확인하세요. 출처 확인일: 2026년 9월 28일.

## 자주 나오는 사례

| 메시지 | 일반적인 목적 | 검토할 점 |
| --- | --- | --- |
| 주문 영수증 또는 환불 안내 | 트랜잭션 | 정확한 주문 정보, 적절한 수신자 |
| 사용자가 요청한 비밀번호 재설정 | 계정 보안 | 실제 요청 여부, 유효한 링크, 주의를 흐리는 혜택 없음 |
| 배송 업데이트 | 트랜잭션 | 기존 주문에 관한 정보 |
| 장바구니 이탈 리마인더 | 마케팅 | 수신 동의, 현재 장바구니 상태, 수신 거부 처리 |
| 체험 종료를 앞둔 업그레이드 권유 | 마케팅 | 실제 제안 내용, 수신자가 아직 대상에 해당하는지 여부 |

계정 상태 안내와 업그레이드 권유는 같은 체험 기간을 다루면서도 목적이 다를 수 있어요. 이메일이 독자에게 무엇을 하라고 요청하는지 살펴보세요.

## 여전히 적용되는 메일 서비스 제공업체 규칙

[Gmail의 가이드라인](https://support.google.com/mail/answer/81126)은 마케팅 메일과 구독 메일에 대한 원클릭 수신 거부 요건을 트랜잭션 메시지와 구분해요. 인증과 평판은 양쪽 모두에 여전히 중요해요.

[Yahoo](https://senders.yahooinc.com/best-practices/)는 대량 마케팅 메일과 트랜잭션 메일을 IP로, 그리고 필요하면 도메인으로도 분리하라고 권장해요. 새 하위 도메인 하나만으로 독립된 평판이 생긴다고 가정하지 말고, 사용하는 이메일 제공업체의 설정 방식을 따르세요.

마케팅 메일의 경우 [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html)이 원클릭 헤더 방식을 정의해요. 푸터 링크와 헤더 기반 수신 거부는 역할이 달라요. 실제로 받은 메시지에서 동작을 테스트하세요.

## Brew로 거래 이벤트 보내기

Brew에서는 이 워크플로에 게시된 자동화와 그 트리거를 써요. 발송 용도를 알맞게 설정한 인증된 발신 도메인을 준비하고, 트리거 페이로드를 선언한 다음, 그 도메인을 쓰는 ‘이메일 보내기’ 단계를 만드세요. 도메인 설정은 Brew의 발송 방식을 정할 뿐, 홍보성 콘텐츠를 법적으로 트랜잭션 이메일로 만들어 주지는 않아요.

자동화를 테스트하고 게시한 뒤에는 자체 백엔드에서 트리거를 실행해요. 아래 예시는 트리거에 `order_id`와 `ship_date`가 선언되어 있다고 가정해요:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_ORDER_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1234-shipped" \
  -d '{"payload":{"email":"ada@example.com","order_id":"1234","ship_date":"Tuesday"}}'
```

실제 트리거 식별자와, 이벤트별로 바뀌지 않는 멱등성 키를 쓰세요. 이메일에서는 `{{ trigger.order_id }}` 같은 문법으로 선언된 페이로드 필드를 읽을 수 있어요. [개인화 태그 문서](https://docs.brew.new/create-emails/merge-tags)를 확인하고, 값이 비어 있는 경우도 테스트하세요.

실행 기록과 받은 이메일을 확인하세요. 재시도 동작을 테스트하고, 마케팅 수신 거부가 발송 용도에 맞게 처리되는지 확인하세요. 발송 제외 같은 다른 보호 장치도 여전히 중요해요. 트랜잭션으로 설정했다고 해서 모든 주소로 전달된다는 보장은 아니에요.

게시와 상태 확인은 [자동화 가이드](/ko/blog/email-marketing-automation-guide)에서 다뤄요. 어시스턴트가 템플릿을 작성한다면 같은 [발송 검토](/ko/blog/agent-email-deliverability) 기준이 적용돼요.