AI 에이전트가 이메일을 발송할 때 도달률(deliverability) 문제는 어떻게 해결하시나요?

너무 깊게 생각하시는 거 아닙니다. 이메일 도구를 단순히 '에이전트가 메일을 보낼 수 있다'는 수준이 아니라, 제약이 있는 런타임으로 취급해야 합니다. 유용한 가드레일로는 도메인별 발송 제한, 폭주 대신 큐를 이용한 발송, 첫 수신자에 대한 승인 절차, 그리고 발송량을 늘리기 전 바운스/회신율 체크 등이 있습니다. 또한 모든 발송에 대해 프롬프트, 수신자 세그먼트, 템플릿 버전을 기록하세요. 저희는 Monadix에서 관련 에이전트 런타임 제어 기능을 개발 중입니다. DM으로 정보 공유하시죠.

아이반, 반가워. 나도 지금 리서치 중이라 실제로 얼마나 골치 아픈 문제인지 파악하는 중이야. 모니닥스에서는 어떤 상황인지 궁금하네. 기존 딜리버러빌리티 툴 대신 에이전트 전용 런타임 제어가 필요하다고 느낀 결정적인 이유가 뭐야? 그리고 이런 문제로 제일 고생하는 팀들은 보통 어떤 곳들이야?

발송용 도메인을 따로 파라. 메인 도메인 평판 지키려면 이게 필수임. 모니터링 안 할 거면 SES보다는 Resend나 Postmark 써라. SES는 블랙리스트 올라가기 전까지 경고도 안 줌. 뭐 보내기 전에 바운스/컴플레인 웹훅부터 설정하고, 2주 동안 문제없이 보낼 때까지 시간당 50건 이하로 속도 제한 걸어라.

이거 진짜 꿀팁이네, 고마워. 솔직히 물어볼게. 도메인, 웹훅, 웜업, 속도 제한, 모니터링까지 매번 세팅하는 거 진짜 일인데, 이거 귀찮아서라도 드롭인 솔루션에 돈 낼 것 같아? 아니면 그냥 업무의 일부라고 생각하고 직접 하는 게 낫다고 봐?

한 가지 팁 주자면, 미리 준비된 응답(canned responses) 세트를 만들어두고 에이전트가 그중에서 고르게 하는 게 제일 좋음. 결정론적(deterministic)으로 처리할 수 있는 부분은 그렇게 하는 게 소통 측면에서도 유리함. 변수 한두 개 정도는 넣게 하되 메시지 자체는 통제해야 함. 검증 없이 에이전트가 알아서 메시지 보내게 두지 마라. 아니면 그냥 준비된 응답만 쓰게 하든가.

좋은 지적이야. 콘텐츠 제어는 또 다른 골칫거리니까. 하나만 더 물어볼게. 너한테는 딜리버러빌리티(인박스 도달률, 도메인 평판)가 문제야, 아니면 에이전트가 엉뚱한 내용을 보내는 게 더 큰 골칫거리야? 뭐가 더 아픈 문제인지 파악 중이라서.