자체 편지함을 갖춘 이메일 고객 지원 분류(Triage) 에이전트 구축하기

모든 공유 고객 지원 편지함은 결국 분류(Triage) 문제에 직면하게 됩니다. 읽지 않은 메시지 80개, 무엇이 "긴급"한지에 대한 합의 부재, 그리고 어떤 고객이 이탈(Churn)할지 알고 있는 유일한 담당자가 휴가(PTO) 중인 상황 말이죠. 팀들은 라벨을 붙이거나 영웅적인 노력으로 이 문제를 계속 해결해 왔습니다. 하지만 LLM(대규모 언어 모델)이 안전하게 머물 곳만 있다면, 이 작업은 LLM에 더 적합합니다.

분류 에이전트에게 자체 메일함을 제공하는 것이 바로 그 해결책입니다. Nylas Agent Accounts (현재 베타 버전)는 API를 통해 완전히 생성할 수 있는 호스팅된 메일함입니다. support@yourcompany.com 형태의 Agent Account는 모든 인바운드 고객 지원 이메일을 수신하며, 기본적으로 6개의 시스템 폴더(inbox, sent, drafts, trash, junk, archive)를 제공하고, 연결된 모든 Gmail 또는 Outlook 계정과 동일한 grant_id 기반 엔드포인트를 노출합니다.

생성하는 방법은 단 한 번의 요청으로 가능합니다:

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

응답에서 grant_id를 저장하세요. 다른 모든 호출은 이 ID를 기반으로 이루어집니다.

5개보다는 4개의 버킷이 낫다

이메일 분류 에이전트 레시피의 분류 체계는 메일을 정확히 4가지 카테고리로 분류합니다:

버킷 (Bucket)	의미	작업
URGENT	운영 장애(Production incident), 경영진 요청	1시간 이내에 답장 초안 작성
...

4개라는 숫자는 의도된 것입니다. 3개는 정확도(Fidelity)가 떨어져 모든 것이 "중요"로 뭉뚱그려집니다. 5개 이상이 되면 모델이 인접한 카테고리를 혼동하기 시작합니다.

프롬프트는 temperature=0 및 max_tokens=10 설정으로 실행되며, 모델은 전체 본문이 아닌 발신자 + 제목 + 200자 이내의 스니펫(Snippet)만 확인합니다. 이것만으로도 90% 이상의 정확도를 확보할 수 있습니다. 다음은 레시피에 포함된 프롬프트 원문입니다:

이메일을 다음 네 가지 카테고리 중 하나로 분류하세요:

URGENT — 운영 장애, 경영진 요청; 1시간 이내에 답장할 것
...

출력값을 네 가지 유효한 문자열과 대조하여 검증하세요 (LLM은 가끔 존재하지 않는 카테고리를 만들어내기도 합니다). 인식되지 않는 모든 항목에 대해서는 FYI로 대체합니다.

비용 계산을 해보면 거의 오차 범위 수준입니다. GPT-4o-mini는 입력 토큰 100만 개당 약 0.15달러가 소요됩니다. 200자 정도의 스니펫(snippet)과 프롬프트를 합치면 대략 150토큰이므로, 이메일 100통은 약 15K 토큰이며 비용은 약 0.002달러입니다. 초안 작성(Drafting)에는 더 강력한 모델(GPT-4o, 입력 토큰 100만 개당 약 2.50달러)을 사용하지만, 이는 일반적으로 받은 편지함의 20% 미만인 URGENT 및 ACTION 하위 집합에 대해서만 수행됩니다. 읽지 않은 이메일이 200통에 달하는 바쁜 날에도 비용은 대략 5센트(a nickel) 정도입니다. 만약 일부 메일이 인프라 외부로 나갈 수 없다면, 동일한 OpenAI 클라이언트를 로컬 Ollama 엔드포인트로 지정하세요. Llama 3.1은 이 작업에서 GPT-4o-mini만큼이나 잘 분류하지만, 초안 작성 품질은 70B 파라미터 모델 미만으로 눈에 띄게 떨어집니다.

초안 작성은 두 번째 게이트를 추가하는 단계입니다

잘못 분류하는 것은 비용이 적게 들지만, 잘못 답장하는 것은 비용이 많이 듭니다. 고객 지원 에이전트 패턴(support agent pattern)은 초안이 생성되기 전에 두 가지 독립적인 검증 단계를 거칩니다.

지식 베이스(knowledge-base) 일치 여부에 따른 신뢰도 게이팅(Confidence gating): 점수가 0.85 이상이면 일치하는 문서를 바탕으로 직접 초안을 작성합니다. 0.60에서 0.85 사이라면 보수적으로 초안을 작성하고, 검토자가 확인할 수 있도록 문서 내용을 인라인(inline)으로 인용합니다. 0.60 미만이면 초안을 작성하지 마세요. 대신 가장 적절해 보이는 문서를 첨부하여 수동 처리가 필요하도록 플래그를 지정합니다.

신뢰도와 무관한 리스크 계층화(Risk tiering): 비밀번호 재설정 및 FAQ 형태의 질문은 초안이 작성됩니다. 환불 및 결제 변경 사항은 추가적인 주의를 기울여 초안을 작성합니다. 법적 위협, 규제 문제, 사기 보고는 모델을 완전히 건너뛰고 전체 맥락과 함께 사람에게 에스컬레이션(escalate)됩니다. 환불 질문에 대해 지식 베이스 일치도가 높더라도 여전히 검토 과정을 거칩니다. Air Canada 챗봇 판결은 왜 이 과정이 필요한지를 보여주는 전형적인 사례입니다.

두 레시피 모두에서 에이전트는 절대로 '전송'을 누르지 않습니다. 초안은 임시 저장함 (drafts folder)에 저장되며, 사람이 이를 승인합니다. 에이전트 계정 (Agent Account)에서 해당 임시 저장함은 에이전트 자체의 소유이므로, 검토 대기열 (review queue)과 감사 추적 (audit trail)이 동일한 편지함이 됩니다.

def handle(msg):
    question = extract_question(msg)
    article, conf = kb.search(question)
...

모델이 실행되기 전의 규칙 (Rules) 필터링

이 부분이 바로 기존의 사람 편지함을 빌려 쓰는 방식으로는 할 수 없는 영역입니다. 에이전트 계정은 메일 계층 (mail layer)에서 실행되는 인바운드 규칙 (inbound rules)을 지원합니다. SMTP 단계에서 알려진 스팸 도메인을 차단하거나, assign_to_folder를 사용하여 송장을 재무 폴더로 자동 라우팅하거나, VIP 발신자를 즉시 주의 대상으로 표시할 수 있습니다. 스팸은 분류 프롬프트 (classification prompt)에 도달하지 않으며, 이는 인젝션 (injection)이 포함된 쓰레기 데이터가 모델의 컨텍스트 (context)에 들어오지 않는다는 것을 의미합니다. 규칙 및 허용/차단 목록은 Agent Accounts 개요에서 확인할 수 있습니다.

수신 메일은 표준 message.created 웹훅 (webhook)을 발생시키며, 이는 다른 권한 부여 (grant)에 대한 동일한 이벤트와 형태가 같습니다. 따라서 파이프라인의 트리거 측면은 이미 연결된 계정들을 위해 실행 중인 방식과 동일하게 구성하면 됩니다. 만약 웹훅이 첫날부터 운영하기에 인프라 부담이 크다면 폴링 (polling) 방식도 가능합니다. 고객 지원 레시피에서는 5~15분마다 폴링할 것을 권장하며, 이는 고객 지원 업무에서 허용 가능한 지연 시간 (latency)입니다.

레시피를 통한 배포 조언

레시피를 통한 배포 조언

• KB 매처(matcher)와 리스크 분류기(risk classifier)를 조정하는 동안에는 사이클당 5개의 티켓부터 시작하세요. 오탐률(false-positive rate)이 허용 가능한 수준에 도달하면 20개로 늘리세요.
• 비슷한 티켓들을 그룹화하세요. 에이전트가 연속으로 세 개의 '영수증은 어디 있나요?' 티켓을 본다면, 이들을 배치 처리(batch)하세요. 즉, 동일한 KB 아티클, 동일한 초안 템플릿을 사용하고 한 번의 검토자 승인만 거치면 됩니다.
• 에이전트가 매칭하지 못한 것을 추적하세요. 신뢰도가 낮은 티켓들은 지식 기반(knowledge base)에 구멍이 있는 곳을 알려주는 가장 강력한 신호입니다.
• 발송 제한(send cap)에 유의하세요. 무료 플랜 에이전트 계정은 일일당 계정당 최대 200개의 메시지를 발송할 수 있으며, 유료 플랜은 기본적으로 일일 제한이 없고 정책을 통해 더 엄격한 할당량(quota)을 설정할 수 있습니다.
• 프롬프트에서 회신 길이(reply length)를 제한하세요. 분류 레시피의 초안 작성 프롬프트는 '최대 세 문장'이라고 명시하며, 이 제약 조건은 매우 중요합니다. 이것이 없다면 초안이 예의 바르지만 과도하게 노력하는 인턴처럼 읽힐 수 있습니다.
• 모든 것을 기록하세요 — 모든 분류, KB 조회, 승인 결정 — 그리고 이를 자신만의 스토어에 저장하세요. 지원 업무는 몇 달 후에 '왜 그렇게 했나요?'라는 질문을 받을 수 있는 작업 부하이기 때문입니다.

이것을 평가하는 가장 저렴한 방법은 분류만 일주일 동안 실행하는 것입니다. 에이전트 계정을 만들고, 지원 흐름(support flow)의 사본을 여기에 연결한 다음, 초안 작성 없이 네 가지 버킷 출력을 기록하세요. 실제로 사람이 어떤 것을 우선순위로 지정했는지와 비교해 보세요. 합의율(agreement rate)이 90%를 넘으면, 초안 작성을 활성화할 자격을 얻은 것입니다.