AI 에이전트를 위한 발송 제한 설계하기

API에 대한 속도 제한(rate limit)은 사용자로부터 당신을 보호합니다. 이메일 에이전트에 대한 발송 제한(send limit)은 다른 모든 사람들을 당신의 에이전트로부터 보호합니다.

이러한 비대칭성 때문에 할당량 설계는 단순히 '절대로 도달하지 않을 만큼 높게 설정한다'는 것보다 더 많은 고민을 필요로 합니다. LLM이 루프(loop) 안에 있는 자율 발신자는 인간의 발신자가 갖지 못하는 실패 모드를 가지고 있습니다. 동일한 메시지를 재전송하는 재시도 폭풍(retry storms), 메일러 데몬에 답장하는 분류 버그(classification bugs), 에이전트를 누군가의 스팸 대포로 만드는 프롬프트 주입 지침(prompt-injected instruction) 등이 그것입니다. 할당량은 이 모든 것들에 대한 폭발 반경 제어 장치입니다.

기본값과 그 용도

Nylas Agent Accounts(베타 기능)의 경우, 무료 플랜에서는 계정당 일일 200개 메시지가 상한선이며, 유료 플랜은 기본적으로 일일 제한이 없습니다. 더 엄격한 계정별 할당량은 정책(policy)을 통해 설정할 수 있습니다. 정책은 일일 발송 할당량을 저장 공간, 보존 기간, 첨부 파일 제한과 함께 묶어 관리하며, 워크스페이스에 연결되어 해당 워크스페이스의 모든 계정이 동일한 상한선을 물려받게 합니다. 정책의 모든 제한 사항은 선택 사항이며, 하나를 생략하면 플랜의 최대값으로 기본 설정됩니다.

이러한 '더 엄격한' 방향성이 핵심입니다. 플랫폼은 사용자가 플랜보다 높은 수준으로 제한을 올리는 것을 허용하지 않고, 오직 아래로만 제약할 수 있습니다. 따라서 설계 질문은 다음과 같습니다: 각 에이전트 아키타입(agent archetype)이 견딜 수 있는 가장 낮은 할당량은 무엇인가? 수신 메일에 응답하는 지원 분류 에이전트는 정당하게 전체 볼륨을 필요로 할 수 있습니다. 금요일 오후에 배포한 프로토타입은 아마도 20개로 제한해야 할 것입니다. 문서는 각 에이전트 아키타입별로 별도의 워크스페이스를 사용하는 것이 좋다고 권장하며, 이는 각 그룹이 모든 것을 포괄하는 하나의 정책 대신 자체 정책을 갖도록 하기 위함입니다.

아무도 설정하지 않는 제한: 반송률과 불만 접수율

팀들이 놀라는 점은 다음과 같습니다. 일일 할당량(daily quota)이 결코 가장 큰 제약 조건이 아니라는 것입니다. 평판 임계값(Reputation thresholds)이 그렇습니다. 플랫폼은 각 계정의 누적 반송률(rolling bounce rate)과 불만 접수율(complaint rate)을 추적하며, 시행 강도는 사용량 제한 페이지에 문서화된 대로 높아집니다:

신호 (Signal)	검토 중 (Under review)	전송 일시 중지 (Sending paused)
반송률 (Bounce rate) (하드 반송 / 최근 전송량)	5% 이상	10% 이상
불만 접수율 (Complaint rate) (스팸 신고 / 최근 전송량)	0.1% 이상	0.5% 이상

불만 접수율 행을 다시 읽어보세요. 0.1%입니다. 낮은 볼륨의 계정에서 수신자 몇 명이 '스팸으로 표시'하는 것만으로도 검토 대상이 됩니다. 반송률에 포함되는 것은 오직 하드 반송(hard bounces)—존재하지 않는 주소—뿐이며, 사서함 가득 참이나 그레이리스팅 같은 소프트 반송(soft bounces)은 그렇지 않습니다. 두 비율 모두 분모는 고정된 기간이 아니라 최근의 대표적인 전송 볼륨 창(send-volume window)을 사용하므로, 하루에 100개의 메시지를 보내든 백만 개를 보내든 계산이 의미를 유지합니다. 불만 접수는 발신자에게 불만 피드백을 보내는 수신자 도메인에 대해서만 계산되므로, 측정된 불만 접수율은 현실보다 낮게 평가되는 경향이 있습니다—이는 임계값을 넘기지 않아야 하는 또 다른 이유입니다.

이 시스템의 속성 두 가지가 모니터링 방식을 바꿔야 합니다. 첫째, '검토 중(under review)' 상태는 조용합니다: 전송은 계속 성공하며 API 응답에서 계정이 감시되고 있다는 것을 알려주는 것은 아무것도 없습니다. 코드가 받는 첫 번째 확실한 신호는 일시 중지 그 자체입니다. 둘째, 일시 중지는 타이머로 해제되지 않습니다. 일시 중지된 계정은 지원팀이 사용자가 무엇을 고쳤는지 확인한 후에야 해제됩니다. 이는 백오프(back off)할 수 있는 429 에러와는 근본적으로 다른 복구 계약입니다—그래서 자체적인 원격 측정(telemetry, 아래 참조) 시스템을 구축하는 것이 선택 사항이 아닙니다.

코드에서 시행되는 방식 (What enforcement looks like in your code)

전송 경로는 최소한 네 가지 응답을 구별해야 합니다:

• 429 Too Many Requests와 `

내부 운영 매뉴얼(runbook)을 세 가지 복구 계약—셀프 서비스(self-service), 증거 기반 지원(support-with-evidence), 설명 기반 지원(support-with-explanation)—주변으로 구성하는 것이 상태 코드(status codes)를 암기하는 것보다 더 유용합니다.

플랫폼 아래에 자체 트립와이어 구축하기

플랫폼의 임계값(thresholds)은 외부 벽입니다. 당신이 원하는 것은 먼저 작동하는 내부 장치입니다. 네 가지 웹훅 트리거는 비율이 계산되는 정확한 이벤트를 노출합니다—message.transactional.delivered, message.transactional.bounced, message.transactional.complaint, 그리고 message.transactional.rejected:

curl --request POST \
  --url "https://api.us.nylas.com/v3/webhooks" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
...

이 스트림에서 자체적인 이동 평균 반송률(rolling bounce rates)과 불만 접수율(complaint rates)을 계산하고, 예를 들어 플랫폼 임계값의 절반 지점에서 자체적인 아웃바운드 로직을 일시 중지시키십시오. 강제 집행(enforcement)이 그것을 자신들의 시스템에서 발견하기 전에, 당신은 자체 텔레메트리(telemetry)에서 문제를 발견할 수 있습니다—그리고 자가 부과된 일시 정지는 원인을 수정하는 순간 되돌릴 수 있지만, 플랫폼의 일시 정지에는 지원 대화가 필요합니다.

설계 규율로서의 할당량(Quota)

불편한 전제는 이렇습니다. 에이전트가 왜 하루에 N개 이상의 메시지를 보내야 하는지 설명할 수 없다면, 그렇게 할 수 없어야 합니다. 아키타입별 작업 공간 정책(Per-archetype workspace policies)은 이를 단순한 희망 사항이 아닌 강제 가능한 것으로 만들며, 위의 임계값들은 어느 쪽을 설계하든 당신이 안에 설계하는 범위(envelope)를 정의합니다.

구체적인 다음 단계: 지난주 동안 에이전트의 발송량을 가져와서, 일일 최고치보다 대략 2배인 정책 할당량(policy quota)을 설정하고, 네 가지 트랜잭션 트리거를 대시보드에 연결하십시오. 할당량이 예상치 못하게 작동하면, 당신은 전달 가능성 위기(deliverability crisis)가 아닌 통제된 사고(contained incident)를 디버깅하고 있을 것입니다.