누군가 먼저 하기 전에 에이전트의 속도를 제한하세요
1,000건의 발송 중 스팸 신고가 한 건이라도 발생하면 이메일 계정은 검토 대상이 됩니다. 스팸 신고율이 0.5%에 도달하면 플랫폼은 발송을 일시 중단합니다. 바운스(Bounces)도 마찬가지입니다. 이러한 한계치에 도달하면 단순히 타이머가 끝나기를 기다릴 수 없습니다. 반드시 해결책에 대한 증거를 가지고 고객 지원팀에 문의해야 합니다.
플랫폼의 제한 수치를 목표로 삼지 마세요. 그것을 최후의 방어선으로 사용하세요. 스스로 더 엄격한 제한을 설정해야 합니다.
자율 에이전트는 전통적인 코드와 다르게 작동합니다. 모델이 루프에 빠질 수 있습니다. 답장이 웹훅(webhook)을 트리거하고, 그 웹훅이 또 다른 답장을 트리거할 수 있습니다. 작은 버그가 몇 분 만에 수천 통의 이메일로 이어질 수 있습니다. 모델은 자신이 너무 많이 보내고 있는지 알지 못합니다. 인프라 자체에 이러한 인지 능력을 구축해야 합니다.
워크스페이스를 보호하기 위해 정책(policy)을 사용하세요. 정책을 통해 다음을 설정할 수 있습니다: • 일일 발송 할당량 (Daily send quotas) • 저장 용량 제한 (Storage caps) • 데이터 보관 기간 (Retention windows) • 스팸 설정 (Spam settings)
스스로 설정한 할당량은 스로틀링(throttling)이 아닙니다. 그것은 하나의 단언(assertion)입니다. 만약 지원 에이전트가 하루에 150통의 이메일만 필요로 한다면, 151통이라는 제한은 무언가 잘못되었다는 것을 알려줍니다. 이는 회로 차단기(circuit breaker)와 같은 역할을 합니다. 오류가 비용이 많이 드는 문제가 되기 전에 가시화해 줍니다.
또한 아웃바운드 규칙(outbound rules)을 사용하여 방향을 제어할 수 있습니다. 특정 도메인을 차단하거나 에이전트가 새로운 스레드를 시작하는 것을 방지할 수 있습니다. 이러한 규칙은 메시지가 나가기 전에 평가됩니다. 규칙을 확인하는 동안 시스템에 오류가 발생하면 fail closed(차단 후 종료) 방식으로 작동합니다. 즉, 안전하지 않은 발송의 위험을 감수하는 대신 메시지를 차단한다는 의미입니다.
안전을 유지하려면 다음 단계를 따르세요: • 메시지 전달(delivery), 바운스(bounce), 불만(complaint), 거부(rejection) 웹훅을 구독하세요. • 자체 텔레메트리(telemetry)에서 이러한 비율을 모니터링하세요. • 비율이 상승하면 아웃바운드 로직을 수동으로 일시 중지하세요.
"플랫폼이 우리를 중단시켰다"라고 말하는 것보다 "우리가 스스로를 중단시켰다"라고 말하는 것이 더 나은 사고 보고(incident report)입니다.
볼륨 급증이 걱정된다면 할당량을 막다른 길로 만들지 마세요. 에스컬레이션 경로(escalation path)로 만드세요. 에이전트가 한계에 도달하면 사람에게 알림을 보내거나 승인을 위해 메시지를 대기열에 넣으세요. 이메일이 지연되는 것은 사소한 문제지만, 파괴된 발신자 평판을 복구하는 데는 몇 주가 걸립니다.
다음 단계: 최대 볼륨의 2배로 일일 할당량이 설정된 정책을 만드세요. 이를 워크스페이스에 연결하세요. 스테이징(staging) 환경에서 할당량을 트리거해 보세요. 만약 알림이 울리지 않는다면, 허점을 발견한 것입니다.
Source: https://dev.to/qasim157/rate-limit-your-own-agent-before-someone-else-does-33cb
Optional learning community: https://t.me/GyaanSetuAi